---
title: SECOM Publicly Trusted Certificate Policy/Certification Practice Statement
subtitle: Version 1.00
author: SECOM Trust Systems Co., Ltd.
date: 2025-05-26
copyright: © 2025 SECOM Trust Systems Co., Ltd. This CP/CPS is licensed under the Creative Commons Attribution 4.0 International license.
---
# Table of Contents
- [Table of Contents](#table-of-contents)
- [1. INTRODUCTION](#1-introduction)
- [1.1 Overview](#11-overview)
- [1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations)
- [1.2 Document name and identification](#12-document-name-and-identification)
- [1.2.1 Revisions](#121-revisions)
- [1.3 PKI Participants](#13-pki-participants)
- [1.3.1 Certification Authorities](#131-certification-authorities)
- [1.3.2 Registration Authorities](#132-registration-authorities)
- [1.3.2.1 Enterprise registration authorities (S/MIME Certificates)](#1321-enterprise-registration-authorities-smime-certificates)
- [1.3.3 Subscribers](#133-subscribers)
- [1.3.4 Relying Parties](#134-relying-parties)
- [1.3.5 Other Participants](#135-other-participants)
- [1.4 Certificate Usage](#14-certificate-usage)
- [1.4.1 Appropriate Certificate Uses](#141-appropriate-certificate-uses)
- [1.4.2 Prohibited Certificate Uses](#142-prohibited-certificate-uses)
- [1.5 Policy administration](#15-policy-administration)
- [1.5.1 Organization Administering the Document](#151-organization-administering-the-document)
- [1.5.2 Contact Person](#152-contact-person)
- [1.5.3 Person Determining CPS suitability for the policy](#153-person-determining-cps-suitability-for-the-policy)
- [1.5.4 CPS approval procedures](#154-cps-approval-procedures)
- [1.6 Definitions and Acronyms](#16-definitions-and-acronyms)
- [1.6.1 Definitions](#161-definitions)
- [1.6.2 Acronyms](#162-acronyms)
- [1.6.3 References](#163-references)
- [1.6.4 Conventions](#164-conventions)
- [2. PUBLICATION AND REPOSITORY RESPONSIBILITIES](#2-publication-and-repository-responsibilities)
- [2.1 Repositories](#21-repositories)
- [2.2 Publication of information](#22-publication-of-information)
- [2.3 Time or frequency of publication](#23-time-or-frequency-of-publication)
- [2.4 Access controls on repositories](#24-access-controls-on-repositories)
- [3. IDENTIFICATION AND AUTHENTICATION](#3-identification-and-authentication)
- [3.1 Naming](#31-naming)
- [3.1.1 Types of names](#311-types-of-names)
- [3.1.2 Need for names to be meaningful](#312-need-for-names-to-be-meaningful)
- [3.1.3 Anonymity or pseudonymity of subscribers](#313-anonymity-or-pseudonymity-of-subscribers)
- [3.1.4 Rules for interpreting various name forms](#314-rules-for-interpreting-various-name-forms)
- [3.1.5 Uniqueness of names](#315-uniqueness-of-names)
- [3.1.6 Recognition, authentication, and role of trademarks](#316-recognition-authentication-and-role-of-trademarks)
- [3.2 Initial identity validation](#32-initial-identity-validation)
- [3.2.1 Method to prove possession of private key](#321-method-to-prove-possession-of-private-key)
- [3.2.2 Authentication of Organization and Domain Identity](#322-authentication-of-organization-and-domain-identity)
- [3.2.2.1 Identity](#3221-identity)
- [3.2.2.1.1 Validating authority over mailbox via domain (S/MIME Certificates)](#32211-validating-authority-over-mailbox-via-domain-smime-certificates)
- [3.2.2.1.2 Validating control over mailbox via email (S/MIME Certificates)](#32212-validating-control-over-mailbox-via-email-smime-certificates)
- [3.2.2.1.3 Validating applicant as operator of associated mail server(s) (S/MIME Certificates)](#32213-validating-applicant-as-operator-of-associated-mail-servers-smime-certificates)
- [3.2.2.2 DBA/Tradename](#3222-dbatradename)
- [3.2.2.2.1 Verification of Applicant's Legal Existence and Identity (EV TLS Server Certificates)](#32221-verification-of-applicants-legal-existence-and-identity-ev-tls-server-certificates)
- [3.2.2.2.1.1 Verification Requirements](#322211-verification-requirements)
- [3.2.2.2.1.2 Acceptable Method of Verification](#322212-acceptable-method-of-verification)
- [3.2.2.2.2 Verification of Applicant's Legal Existence and Identity – Assumed Name (EV TLS Server Certificates)](#32222-verification-of-applicants-legal-existence-and-identity--assumed-name-ev-tls-server-certificates)
- [3.2.2.2.2.1 Verification Requirements](#322221-verification-requirements)
- [3.2.2.2.2.2 Acceptable Method of Verification](#322222-acceptable-method-of-verification)
- [3.2.2.2.3 Verification of Applicant's Physical Existence (EV TLS Server Certificates)](#32223-verification-of-applicants-physical-existence-ev-tls-server-certificates)
- [3.2.2.2.3.1 Address of Applicant's Place of Business](#322231-address-of-applicants-place-of-business)
- [3.2.2.2.4 Verified Method of Communication (EV TLS Server Certificates)](#32224-verified-method-of-communication-ev-tls-server-certificates)
- [3.2.2.2.4.1 Verification Requirements](#322241-verification-requirements)
- [3.2.2.2.4.2 Acceptable Methods of Verification](#322242-acceptable-methods-of-verification)
- [3.2.2.2.5 Verification of Applicant's Operational Existence (EV TLS Server Certificates)](#32225-verification-of-applicants-operational-existence-ev-tls-server-certificates)
- [3.2.2.2.5.1 Verification Requirements](#322251-verification-requirements)
- [3.2.2.2.5.2 Acceptable Methods of Verification](#322252-acceptable-methods-of-verification)
- [3.2.2.2.6 Verification of Applicant's Domain Name (EV TLS Server Certificates)](#32226-verification-of-applicants-domain-name-ev-tls-server-certificates)
- [3.2.2.2.6.1 Verification Requirements](#322261-verification-requirements)
- [3.2.2.2.7 Verification of Name, Title, and Authority of Contract Signer and Certificate Approver (EV TLS Server Certificates)](#32227-verification-of-name-title-and-authority-of-contract-signer-and-certificate-approver-ev-tls-server-certificates)
- [3.2.2.2.7.1 Verification Requirements](#322271-verification-requirements)
- [3.2.2.2.7.2 Acceptable Methods of Verification – Name, Title and Agency](#322272-acceptable-methods-of-verification--name-title-and-agency)
- [3.2.2.2.7.3 Acceptable Methods of Verification – Authority](#322273-acceptable-methods-of-verification--authority)
- [3.2.2.2.7.4 Pre-Authorized Certificate Approver](#322274-pre-authorized-certificate-approver)
- [3.2.2.2.8 Verification of Signature on Subscriber Agreement and EV Certificate Requests (EV TLS Server Certificates)](#32228-verification-of-signature-on-subscriber-agreement-and-ev-certificate-requests-ev-tls-server-certificates)
- [3.2.2.2.8.1 Verification Requirements](#322281-verification-requirements)
- [3.2.2.2.8.2 Acceptable Methods of Signature Verification](#322282-acceptable-methods-of-signature-verification)
- [3.2.2.2.9 Verification of Approval of EV Certificate Request (EV TLS Server Certificates)](#32229-verification-of-approval-of-ev-certificate-request-ev-tls-server-certificates)
- [3.2.2.2.9.1 Verification Requirements](#322291-verification-requirements)
- [3.2.2.2.9.2 Acceptable Methods of Verification](#322292-acceptable-methods-of-verification)
- [3.2.2.2.10 Verification of Certain Information Sources (EV TLS Server Certificates)](#322210-verification-of-certain-information-sources-ev-tls-server-certificates)
- [3.2.2.2.10.1 Verified Legal Opinion](#3222101-verified-legal-opinion)
- [3.2.2.2.10.2 Verified Accountant Letter](#3222102-verified-accountant-letter)
- [3.2.2.2.10.3 Face-to-Face Validation](#3222103-face-to-face-validation)
- [3.2.2.2.10.4 Independent Confirmation From Applicant](#3222104-independent-confirmation-from-applicant)
- [3.2.2.2.10.5 Qualified Independent Information Source](#3222105-qualified-independent-information-source)
- [3.2.2.2.10.6 Qualified Government Information Source](#3222106-qualified-government-information-source)
- [3.2.2.2.10.7 Qualified Government Tax Information Source](#3222107-qualified-government-tax-information-source)
- [3.2.2.2.11 Other Verification Requirements (EV TLS Server Certificates)](#322211-other-verification-requirements-ev-tls-server-certificates)
- [3.2.2.2.11.1 High Risk Status](#3222111-high-risk-status)
- [3.2.2.2.11.2 Denied Lists and Other Legal Block Lists](#3222112-denied-lists-and-other-legal-block-lists)
- [3.2.2.2.11.3 Parent/Subsidiary/Affiliate Relationship](#3222113-parentsubsidiaryaffiliate-relationship)
- [3.2.2.2.12 Final Cross-Correlation and Due Diligence (EV TLS Server Certificates)](#322212-final-cross-correlation-and-due-diligence-ev-tls-server-certificates)
- [3.2.2.2.13 Requirements for Re-use of Existing Documentation (EV TLS Server Certificates)](#322213-requirements-for-re-use-of-existing-documentation-ev-tls-server-certificates)
- [3.2.2.2.13.1 Validation For Existing Subscribers](#3222131-validation-for-existing-subscribers)
- [3.2.2.2.13.2 Re-issuance Requests](#3222132-re-issuance-requests)
- [3.2.2.2.13.3 Age of Validated Data](#3222133-age-of-validated-data)
- [3.2.2.3 Verification of Country](#3223-verification-of-country)
- [3.2.2.4 Validation of Domain Authorization or Control](#3224-validation-of-domain-authorization-or-control)
- [3.2.2.4.1 Validating the Applicant as a Domain Contact](#32241-validating-the-applicant-as-a-domain-contact)
- [3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact](#32242-email-fax-sms-or-postal-mail-to-domain-contact)
- [3.2.2.4.3 Phone Contact with Domain Contact](#32243-phone-contact-with-domain-contact)
- [3.2.2.4.4 Constructed Email to Domain Contact](#32244-constructed-email-to-domain-contact)
- [3.2.2.4.5 Domain Authorization Document](#32245-domain-authorization-document)
- [3.2.2.4.6 Agreed-Upon Change to Website](#32246-agreed-upon-change-to-website)
- [3.2.2.4.7 DNS Change](#32247-dns-change)
- [3.2.2.4.8 IP Address](#32248-ip-address)
- [3.2.2.4.9 Test Certificate](#32249-test-certificate)
- [3.2.2.4.10 TLS Using a Random Value](#322410-tls-using-a-random-value)
- [3.2.2.4.11 Any Other Method](#322411-any-other-method)
- [3.2.2.4.12 Validating Applicant as a Domain Contact](#322412-validating-applicant-as-a-domain-contact)
- [3.2.2.4.13 Email to DNS CAA Contact](#322413-email-to-dns-caa-contact)
- [3.2.2.4.14 Email to DNS TXT Contact](#322414-email-to-dns-txt-contact)
- [3.2.2.4.15 Phone Contact with Domain Contact](#322415-phone-contact-with-domain-contact)
- [3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact](#322416-phone-contact-with-dns-txt-record-phone-contact)
- [3.2.2.4.17 Phone Contact with DNS CAA Phone Contact](#322417-phone-contact-with-dns-caa-phone-contact)
- [3.2.2.4.18 Agreed-Upon Change to Website v2](#322418-agreed-upon-change-to-website-v2)
- [3.2.2.4.19 Agreed-Upon Change to Website - ACME](#322419-agreed-upon-change-to-website---acme)
- [3.2.2.4.20 TLS Using ALPN](#322420-tls-using-alpn)
- [3.2.2.5 Authentication for an IP Address](#3225-authentication-for-an-ip-address)
- [3.2.2.6 Wildcard Domain Validation](#3226-wildcard-domain-validation)
- [3.2.2.7 Data Source Accuracy](#3227-data-source-accuracy)
- [3.2.2.8 CAA Records](#3228-caa-records)
- [3.2.2.9 Multi-Perspective Issuance Corroboration](#3229-multi-perspective-issuance-corroboration)
- [3.2.3 Authentication of individual identity](#323-authentication-of-individual-identity)
- [3.2.3.1 Attribute collection of organization identity (S/MIME Certificates)](#3231-attribute-collection-of-organization-identity-smime-certificates)
- [3.2.4 Non-verified subscriber information](#324-non-verified-subscriber-information)
- [3.2.5 Validation of authority](#325-validation-of-authority)
- [3.2.6 Criteria for Interoperation or Certification](#326-criteria-for-interoperation-or-certification)
- [3.3 Identification and authentication for re-key requests](#33-identification-and-authentication-for-re-key-requests)
- [3.3.1 Identification and authentication for routine re-key](#331-identification-and-authentication-for-routine-re-key)
- [3.3.2 Identification and authentication for re-key after revocation](#332-identification-and-authentication-for-re-key-after-revocation)
- [3.4 Identification and authentication for revocation request](#34-identification-and-authentication-for-revocation-request)
- [4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS](#4-certificate-life-cycle-operational-requirements)
- [4.1 Certificate Application](#41-certificate-application)
- [4.1.1 Who can submit a certificate application](#411-who-can-submit-a-certificate-application)
- [4.1.2 Enrollment process and responsibilities](#412-enrollment-process-and-responsibilities)
- [4.2 Certificate application processing](#42-certificate-application-processing)
- [4.2.1 Performing identification and authentication functions](#421-performing-identification-and-authentication-functions)
- [4.2.2 Approval or rejection of certificate applications](#422-approval-or-rejection-of-certificate-applications)
- [4.2.2.1 Certification authority authorization (CAA) (S/MIME Certificates)](#4221-certification-authority-authorization-caa-smime-certificates)
- [4.2.2.2 Multi-perspective issuance corroboration (S/MIME Certificates)](#4222-multi-perspective-issuance-corroboration-smime-certificates)
- [4.2.3 Time to process certificate applications](#423-time-to-process-certificate-applications)
- [4.3 Certificate issuance](#43-certificate-issuance)
- [4.3.1 CA actions during certificate issuance](#431-ca-actions-during-certificate-issuance)
- [4.3.1.1 Manual authorization of certificate issuance for Root CAs](#4311-manual-authorization-of-certificate-issuance-for-root-cas)
- [4.3.1.2 Linting of to-be-signed Certificate content](#4312-linting-of-to-be-signed-certificate-content)
- [4.3.1.3 Linting of issued Certificates](#4313-linting-of-issued-certificates)
- [4.3.2 Notification to subscriber by the CA of issuance of certificate](#432-notification-to-subscriber-by-the-ca-of-issuance-of-certificate)
- [4.4 Certificate acceptance](#44-certificate-acceptance)
- [4.4.1 Conduct constituting certificate acceptance](#441-conduct-constituting-certificate-acceptance)
- [4.4.2 Publication of the certificate by the CA](#442-publication-of-the-certificate-by-the-ca)
- [4.4.3 Notification of certificate issuance by the CA to other entities](#443-notification-of-certificate-issuance-by-the-ca-to-other-entities)
- [4.5 Key pair and certificate usage](#45-key-pair-and-certificate-usage)
- [4.5.1 Subscriber private key and certificate usage](#451-subscriber-private-key-and-certificate-usage)
- [4.5.2 Relying party public key and certificate usage](#452-relying-party-public-key-and-certificate-usage)
- [4.6 Certificate renewal](#46-certificate-renewal)
- [4.6.1 Circumstance for certificate renewal](#461-circumstance-for-certificate-renewal)
- [4.6.2 Who may request renewal](#462-who-may-request-renewal)
- [4.6.3 Processing certificate renewal requests](#463-processing-certificate-renewal-requests)
- [4.6.4 Notification of new certificate issuance to subscriber](#464-notification-of-new-certificate-issuance-to-subscriber)
- [4.6.5 Conduct constituting acceptance of a renewal certificate](#465-conduct-constituting-acceptance-of-a-renewal-certificate)
- [4.6.6 Publication of the renewal certificate by the CA](#466-publication-of-the-renewal-certificate-by-the-ca)
- [4.6.7 Notification of certificate issuance by the CA to other entities](#467-notification-of-certificate-issuance-by-the-ca-to-other-entities)
- [4.7 Certificate re-key](#47-certificate-re-key)
- [4.7.1 Circumstance for certificate re-key](#471-circumstance-for-certificate-re-key)
- [4.7.2 Who may request certification of a new public key](#472-who-may-request-certification-of-a-new-public-key)
- [4.7.3 Processing certificate re-keying requests](#473-processing-certificate-re-keying-requests)
- [4.7.4 Notification of new certificate issuance to subscriber](#474-notification-of-new-certificate-issuance-to-subscriber)
- [4.7.5 Conduct constituting acceptance of a re-keyed certificate](#475-conduct-constituting-acceptance-of-a-re-keyed-certificate)
- [4.7.6 Publication of the re-keyed certificate by the CA](#476-publication-of-the-re-keyed-certificate-by-the-ca)
- [4.7.7 Notification of certificate issuance by the CA to other entities](#477-notification-of-certificate-issuance-by-the-ca-to-other-entities)
- [4.8 Certificate modification](#48-certificate-modification)
- [4.8.1 Circumstance for certificate modification](#481-circumstance-for-certificate-modification)
- [4.8.2 Who may request certificate modification](#482-who-may-request-certificate-modification)
- [4.8.3 Processing certificate modification requests](#483-processing-certificate-modification-requests)
- [4.8.4 Notification of new certificate issuance to subscriber](#484-notification-of-new-certificate-issuance-to-subscriber)
- [4.8.5 Conduct constituting acceptance of modified certificate](#485-conduct-constituting-acceptance-of-modified-certificate)
- [4.8.6 Publication of the modified certificate by the CA](#486-publication-of-the-modified-certificate-by-the-ca)
- [4.8.7 Notification of certificate issuance by the CA to other entities](#487-notification-of-certificate-issuance-by-the-ca-to-other-entities)
- [4.9 Certificate revocation and suspension](#49-certificate-revocation-and-suspension)
- [4.9.1 Circumstances for revocation](#491-circumstances-for-revocation)
- [4.9.1.1 Reasons for Revoking a Subscriber Certificate](#4911-reasons-for-revoking-a-subscriber-certificate)
- [4.9.1.2 Reasons for Revoking a Subordinate CA Certificate](#4912-reasons-for-revoking-a-subordinate-ca-certificate)
- [4.9.2 Who can request revocation](#492-who-can-request-revocation)
- [4.9.3 Procedure for revocation request](#493-procedure-for-revocation-request)
- [4.9.4 Revocation request grace period](#494-revocation-request-grace-period)
- [4.9.5 Time within which CA must process the revocation request](#495-time-within-which-ca-must-process-the-revocation-request)
- [4.9.6 Revocation checking requirement for relying parties](#496-revocation-checking-requirement-for-relying-parties)
- [4.9.7 CRL issuance frequency](#497-crl-issuance-frequency)
- [4.9.8 Maximum latency for CRLs (if applicable)](#498-maximum-latency-for-crls-if-applicable)
- [4.9.9 On-line revocation/status checking availability](#499-on-line-revocationstatus-checking-availability)
- [4.9.10 On-line revocation checking requirements](#4910-on-line-revocation-checking-requirements)
- [4.9.11 Other forms of revocation advertisements available](#4911-other-forms-of-revocation-advertisements-available)
- [4.9.12 Special requirements re key compromise](#4912-special-requirements-re-key-compromise)
- [4.9.13 Circumstances for suspension](#4913-circumstances-for-suspension)
- [4.9.14 Who can request suspension](#4914-who-can-request-suspension)
- [4.9.15 Procedure for suspension request](#4915-procedure-for-suspension-request)
- [4.9.16 Limits on suspension period](#4916-limits-on-suspension-period)
- [4.10 Certificate status services](#410-certificate-status-services)
- [4.10.1 Operational characteristics](#4101-operational-characteristics)
- [4.10.2 Service availability](#4102-service-availability)
- [4.10.3 Optional features](#4103-optional-features)
- [4.11 End of subscription](#411-end-of-subscription)
- [4.12 Key escrow and recovery](#412-key-escrow-and-recovery)
- [4.12.1 Key escrow and recovery policy and practices](#4121-key-escrow-and-recovery-policy-and-practices)
- [4.12.2 Session key encapsulation and recovery policy and practices](#4122-session-key-encapsulation-and-recovery-policy-and-practices)
- [5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS](#5-management-operational-and-physical-controls)
- [5.1 Physical Security Controls](#51-physical-security-controls)
- [5.1.1 Site location and construction](#511-site-location-and-construction)
- [5.1.2 Physical access](#512-physical-access)
- [5.1.3 Power and air conditioning](#513-power-and-air-conditioning)
- [5.1.4 Water exposures](#514-water-exposures)
- [5.1.5 Fire prevention and protection](#515-fire-prevention-and-protection)
- [5.1.6 Media storage](#516-media-storage)
- [5.1.7 Waste disposal](#517-waste-disposal)
- [5.1.8 Off-site backup](#518-off-site-backup)
- [5.2 Procedural controls](#52-procedural-controls)
- [5.2.1 Trusted roles](#521-trusted-roles)
- [5.2.2 Number of Individuals Required per Task](#522-number-of-individuals-required-per-task)
- [5.2.3 Identification and authentication for each role](#523-identification-and-authentication-for-each-role)
- [5.2.4 Roles requiring separation of duties](#524-roles-requiring-separation-of-duties)
- [5.3 Personnel controls](#53-personnel-controls)
- [5.3.1 Qualifications, experience, and clearance requirements](#531-qualifications-experience-and-clearance-requirements)
- [5.3.2 Background check procedures](#532-background-check-procedures)
- [5.3.3 Training Requirements and Procedures](#533-training-requirements-and-procedures)
- [5.3.4 Retraining frequency and requirements](#534-retraining-frequency-and-requirements)
- [5.3.5 Job rotation frequency and sequence](#535-job-rotation-frequency-and-sequence)
- [5.3.6 Sanctions for unauthorized actions](#536-sanctions-for-unauthorized-actions)
- [5.3.7 Independent Contractor Controls](#537-independent-contractor-controls)
- [5.3.8 Documentation supplied to personnel](#538-documentation-supplied-to-personnel)
- [5.4 Audit logging procedures](#54-audit-logging-procedures)
- [5.4.1 Types of events recorded](#541-types-of-events-recorded)
- [5.4.1.1 Router and firewall activities logs](#5411-router-and-firewall-activities-logs)
- [5.4.1.2 Types of events recorded for Timestamp Authorities](#5412-types-of-events-recorded-for-timestamp-authorities)
- [5.4.2 Frequency of processing audit log](#542-frequency-of-processing-audit-log)
- [5.4.3 Retention period for audit log](#543-retention-period-for-audit-log)
- [5.4.4 Protection of audit log](#544-protection-of-audit-log)
- [5.4.5 Audit log backup procedures](#545-audit-log-backup-procedures)
- [5.4.6 Audit collection System (internal vs. external)](#546-audit-collection-system-internal-vs-external)
- [5.4.7 Notification to event-causing subject](#547-notification-to-event-causing-subject)
- [5.4.8 Vulnerability assessments](#548-vulnerability-assessments)
- [5.5 Records archival](#55-records-archival)
- [5.5.1 Types of records archived](#551-types-of-records-archived)
- [5.5.2 Retention period for archive](#552-retention-period-for-archive)
- [5.5.3 Protection of archive](#553-protection-of-archive)
- [5.5.4 Archive backup procedures](#554-archive-backup-procedures)
- [5.5.5 Requirements for time-stamping of records](#555-requirements-for-time-stamping-of-records)
- [5.5.6 Archive collection system (internal or external)](#556-archive-collection-system-internal-or-external)
- [5.5.7 Procedures to obtain and verify archive information](#557-procedures-to-obtain-and-verify-archive-information)
- [5.6 Key changeover](#56-key-changeover)
- [5.7 Compromise and disaster recovery](#57-compromise-and-disaster-recovery)
- [5.7.1 Incident and compromise handling procedures](#571-incident-and-compromise-handling-procedures)
- [5.7.2 Recovery Procedures if Computing resources, software, and/or data are corrupted](#572-recovery-procedures-if-computing-resources-software-andor-data-are-corrupted)
- [5.7.3 Recovery Procedures after Key Compromise](#573-recovery-procedures-after-key-compromise)
- [5.7.4 Business continuity capabilities after a disaster](#574-business-continuity-capabilities-after-a-disaster)
- [5.8 CA or RA termination](#58-ca-or-ra-termination)
- [6. TECHNICAL SECURITY CONTROLS](#6-technical-security-controls)
- [6.1 Key pair generation and installation](#61-key-pair-generation-and-installation)
- [6.1.1 Key pair generation](#611-key-pair-generation)
- [6.1.1.1 CA Key Pair Generation](#6111-ca-key-pair-generation)
- [6.1.1.2 RA Key Pair Generation](#6112-ra-key-pair-generation)
- [6.1.1.3 Subscriber Key Pair Generation](#6113-subscriber-key-pair-generation)
- [6.1.2 Private key delivery to subscriber](#612-private-key-delivery-to-subscriber)
- [6.1.3 Public key delivery to certificate issuer](#613-public-key-delivery-to-certificate-issuer)
- [6.1.4 CA public key delivery to relying parties](#614-ca-public-key-delivery-to-relying-parties)
- [6.1.5 Key sizes](#615-key-sizes)
- [6.1.6 Public key parameters generation and quality checking](#616-public-key-parameters-generation-and-quality-checking)
- [6.1.7 Key usage purposes (as per X.509 v3 key usage field)](#617-key-usage-purposes-as-per-x509-v3-key-usage-field)
- [6.2 Private Key Protection and Cryptographic Module Engineering Controls](#62-private-key-protection-and-cryptographic-module-engineering-controls)
- [6.2.1 Cryptographic module standards and controls](#621-cryptographic-module-standards-and-controls)
- [6.2.2 Private key (n out of m) multi-person control](#622-private-key-n-out-of-m-multi-person-control)
- [6.2.3 Private key escrow](#623-private-key-escrow)
- [6.2.4 Private key backup](#624-private-key-backup)
- [6.2.5 Private key archival](#625-private-key-archival)
- [6.2.6 Private key transfer into or from a cryptographic module](#626-private-key-transfer-into-or-from-a-cryptographic-module)
- [6.2.7 Private key storage on cryptographic module](#627-private-key-storage-on-cryptographic-module)
- [6.2.8 Activating Private Keys](#628-activating-private-keys)
- [6.2.9 Deactivating Private Keys](#629-deactivating-private-keys)
- [6.2.10 Destroying Private Keys](#6210-destroying-private-keys)
- [6.2.11 Cryptographic Module Rating](#6211-cryptographic-module-rating)
- [6.3 Other aspects of key pair management](#63-other-aspects-of-key-pair-management)
- [6.3.1 Public key archival](#631-public-key-archival)
- [6.3.2 Certificate operational periods and key pair usage periods](#632-certificate-operational-periods-and-key-pair-usage-periods)
- [6.4 Activation data](#64-activation-data)
- [6.4.1 Activation data generation and installation](#641-activation-data-generation-and-installation)
- [6.4.2 Activation data protection](#642-activation-data-protection)
- [6.4.3 Other aspects of activation data](#643-other-aspects-of-activation-data)
- [6.5 Computer security controls](#65-computer-security-controls)
- [6.5.1 Specific computer security technical requirements](#651-specific-computer-security-technical-requirements)
- [6.5.2 Computer security rating](#652-computer-security-rating)
- [6.6 Life cycle technical controls](#66-life-cycle-technical-controls)
- [6.6.1 System development controls](#661-system-development-controls)
- [6.6.2 Security management controls](#662-security-management-controls)
- [6.6.3 Life cycle security controls](#663-life-cycle-security-controls)
- [6.7 Network security controls](#67-network-security-controls)
- [6.8 Time-stamping](#68-time-stamping)
- [7. CERTIFICATE, CRL, AND OCSP PROFILES](#7-certificate-crl-and-ocsp-profiles)
- [7.1 Certificate profile](#71-certificate-profile)
- [7.1.1 Version number(s)](#711-version-numbers)
- [7.1.2 Certificate Content and Extensions](#712-certificate-content-and-extensions)
- [7.1.2.1 Root CA Certificate Profile](#7121-root-ca-certificate-profile)
- [7.1.2.1.1 Root CA Validity](#71211-root-ca-validity)
- [7.1.2.1.2 Root CA Extensions](#71212-root-ca-extensions)
- [7.1.2.1.3 Root CA Authority Key Identifier](#71213-root-ca-authority-key-identifier)
- [7.1.2.1.4 Root CA Basic Constraints](#71214-root-ca-basic-constraints)
- [7.1.2.2 Cross-Certified Subordinate CA Certificate Profile](#7122-cross-certified-subordinate-ca-certificate-profile)
- [7.1.2.2.1 Cross-Certified Subordinate CA Validity](#71221-cross-certified-subordinate-ca-validity)
- [7.1.2.2.2 Cross-Certified Subordinate CA Naming](#71222-cross-certified-subordinate-ca-naming)
- [7.1.2.2.3 Cross-Certified Subordinate CA Extensions](#71223-cross-certified-subordinate-ca-extensions)
- [7.1.2.2.4 Cross-Certified Subordinate CA Extended Key Usage - Unrestricted](#71224-cross-certified-subordinate-ca-extended-key-usage---unrestricted)
- [7.1.2.2.5 Cross-Certified Subordinate CA Extended Key Usage - Restricted](#71225-cross-certified-subordinate-ca-extended-key-usage---restricted)
- [7.1.2.2.6 Cross-Certified Subordinate CA Certificate Certificate Policies](#71226-cross-certified-subordinate-ca-certificate-certificate-policies)
- [7.1.2.3 Technically Constrained Non-TLS Subordinate CA Certificate Profile](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile)
- [7.1.2.3.1 Technically Constrained Non-TLS Subordinate CA Extensions](#71231-technically-constrained-non-tls-subordinate-ca-extensions)
- [7.1.2.3.2 Technically Constrained Non-TLS Subordinate CA Certificate Policies](#71232-technically-constrained-non-tls-subordinate-ca-certificate-policies)
- [7.1.2.3.3 Technically Constrained Non-TLS Subordinate CA Extended Key Usage](#71233-technically-constrained-non-tls-subordinate-ca-extended-key-usage)
- [7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile](#7124-technically-constrained-precertificate-signing-ca-certificate-profile)
- [7.1.2.4.1 Technically Constrained Precertificate Signing CA Extensions](#71241-technically-constrained-precertificate-signing-ca-extensions)
- [7.1.2.4.2 Technically Constrained Precertificate Signing CA Extended Key Usage](#71242-technically-constrained-precertificate-signing-ca-extended-key-usage)
- [7.1.2.5 Technically Constrained TLS Subordinate CA Certificate Profile](#7125-technically-constrained-tls-subordinate-ca-certificate-profile)
- [7.1.2.5.1 Technically Constrained TLS Subordinate CA Extensions](#71251-technically-constrained-tls-subordinate-ca-extensions)
- [7.1.2.5.2 Technically Constrained TLS Subordinate CA Name Constraints](#71252-technically-constrained-tls-subordinate-ca-name-constraints)
- [7.1.2.6 TLS Subordinate CA Certificate Profile](#7126-tls-subordinate-ca-certificate-profile)
- [7.1.2.6.1 TLS Subordinate CA Extensions](#71261-tls-subordinate-ca-extensions)
- [7.1.2.7 Subscriber (Server) Certificate Profile](#7127-subscriber-server-certificate-profile)
- [7.1.2.7.1 Subscriber Certificate Types](#71271-subscriber-certificate-types)
- [7.1.2.7.2 Domain Validated](#71272-domain-validated)
- [7.1.2.7.3 Individual Validated](#71273-individual-validated)
- [7.1.2.7.4 Organization Validated](#71274-organization-validated)
- [7.1.2.7.5 Extended Validation](#71275-extended-validation)
- [7.1.2.7.6 Subscriber Certificate Extensions](#71276-subscriber-certificate-extensions)
- [7.1.2.7.7 Subscriber Certificate Authority Information Access](#71277-subscriber-certificate-authority-information-access)
- [7.1.2.7.8 Subscriber Certificate Basic Constraints](#71278-subscriber-certificate-basic-constraints)
- [7.1.2.7.9 Subscriber Certificate Certificate Policies](#71279-subscriber-certificate-certificate-policies)
- [7.1.2.7.10 Subscriber Certificate Extended Key Usage](#712710-subscriber-certificate-extended-key-usage)
- [7.1.2.7.11 Subscriber Certificate Key Usage](#712711-subscriber-certificate-key-usage)
- [7.1.2.7.12 Subscriber Certificate Subject Alternative Name](#712712-subscriber-certificate-subject-alternative-name)
- [7.1.2.8 OCSP Responder Certificate Profile](#7128-ocsp-responder-certificate-profile)
- [7.1.2.8.1 OCSP Responder Validity](#71281-ocsp-responder-validity)
- [7.1.2.8.2 OCSP Responder Extensions](#71282-ocsp-responder-extensions)
- [7.1.2.8.3 OCSP Responder Authority Information Access](#71283-ocsp-responder-authority-information-access)
- [7.1.2.8.4 OCSP Responder Basic Constraints](#71284-ocsp-responder-basic-constraints)
- [7.1.2.8.5 OCSP Responder Extended Key Usage](#71285-ocsp-responder-extended-key-usage)
- [7.1.2.8.6 OCSP Responder id-pkix-ocsp-nocheck](#71286-ocsp-responder-id-pkix-ocsp-nocheck)
- [7.1.2.8.7 OCSP Responder Key Usage](#71287-ocsp-responder-key-usage)
- [7.1.2.8.8 OCSP Responder Certificate Policies](#71288-ocsp-responder-certificate-policies)
- [7.1.2.9 Precertificate Profile](#7129-precertificate-profile)
- [7.1.2.9.1 Precertificate Profile Extensions - Directly Issued](#71291-precertificate-profile-extensions---directly-issued)
- [7.1.2.9.2 Precertificate Profile Extensions - Precertificate CA Issued](#71292-precertificate-profile-extensions---precertificate-ca-issued)
- [7.1.2.9.3 Precertificate Poison](#71293-precertificate-poison)
- [7.1.2.9.4 Precertificate Authority Key Identifier](#71294-precertificate-authority-key-identifier)
- [7.1.2.10 Common CA Fields](#71210-common-ca-fields)
- [7.1.2.10.1 CA Certificate Validity](#712101-ca-certificate-validity)
- [7.1.2.10.2 CA Certificate Naming](#712102-ca-certificate-naming)
- [7.1.2.10.3 CA Certificate Authority Information Access](#712103-ca-certificate-authority-information-access)
- [7.1.2.10.4 CA Certificate Basic Constraints](#712104-ca-certificate-basic-constraints)
- [7.1.2.10.5 CA Certificate Certificate Policies](#712105-ca-certificate-certificate-policies)
- [7.1.2.10.6 CA Certificate Extended Key Usage](#712106-ca-certificate-extended-key-usage)
- [7.1.2.10.7 CA Certificate Key Usage](#712107-ca-certificate-key-usage)
- [7.1.2.10.8 CA Certificate Name Constraints](#712108-ca-certificate-name-constraints)
- [7.1.2.11 Common Certificate Fields](#71211-common-certificate-fields)
- [7.1.2.11.1 Authority Key Identifier](#712111-authority-key-identifier)
- [7.1.2.11.2 CRL Distribution Points](#712112-crl-distribution-points)
- [7.1.2.11.3 Signed Certificate Timestamp List](#712113-signed-certificate-timestamp-list)
- [7.1.2.11.4 Subject Key Identifier](#712114-subject-key-identifier)
- [7.1.2.11.5 Other Extensions](#712115-other-extensions)
- [7.1.3 Algorithm object identifiers](#713-algorithm-object-identifiers)
- [7.1.3.1 SubjectPublicKeyInfo](#7131-subjectpublickeyinfo)
- [7.1.3.1.1 RSA](#71311-rsa)
- [7.1.3.1.2 ECDSA](#71312-ecdsa)
- [7.1.3.2 Signature AlgorithmIdentifier](#7132-signature-algorithmidentifier)
- [7.1.3.2.1 RSA](#71321-rsa)
- [7.1.3.2.2 ECDSA](#71322-ecdsa)
- [7.1.4 Name Forms](#714-name-forms)
- [7.1.4.1 Name Encoding](#7141-name-encoding)
- [7.1.4.2 Subject Attribute Encoding](#7142-subject-attribute-encoding)
- [7.1.4.3 Subscriber Certificate Common Name Attribute](#7143-subscriber-certificate-common-name-attribute)
- [7.1.4.4 Other Subject Attributes](#7144-other-subject-attributes)
- [7.1.5 Name constraints](#715-name-constraints)
- [7.1.6 Certificate policy object identifier](#716-certificate-policy-object-identifier)
- [7.1.6.1 Reserved Certificate Policy Identifiers](#7161-reserved-certificate-policy-identifiers)
- [7.1.7 Usage of Policy Constraints extension](#717-usage-of-policy-constraints-extension)
- [7.1.8 Policy qualifiers syntax and semantics](#718-policy-qualifiers-syntax-and-semantics)
- [7.1.9 Processing semantics for the critical Certificate Policies extension](#719-processing-semantics-for-the-critical-certificate-policies-extension)
- [7.2 CRL profile](#72-crl-profile)
- [7.2.1 Version number(s)](#721-version-numbers)
- [7.2.2 CRL and CRL entry extensions](#722-crl-and-crl-entry-extensions)
- [7.2.2.1 CRL Issuing Distribution Point](#7221-crl-issuing-distribution-point)
- [7.3 OCSP profile](#73-ocsp-profile)
- [7.3.1 Version number(s)](#731-version-numbers)
- [7.3.2 OCSP extensions](#732-ocsp-extensions)
- [8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS](#8-compliance-audit-and-other-assessments)
- [8.1 Frequency or circumstances of assessment](#81-frequency-or-circumstances-of-assessment)
- [8.2 Identity/qualifications of assessor](#82-identityqualifications-of-assessor)
- [8.3 Assessor's relationship to assessed entity](#83-assessors-relationship-to-assessed-entity)
- [8.4 Topics covered by assessment](#84-topics-covered-by-assessment)
- [8.5 Actions taken as a result of deficiency](#85-actions-taken-as-a-result-of-deficiency)
- [8.6 Communication of results](#86-communication-of-results)
- [8.7 Self-Audits](#87-self-audits)
- [8.8 Review of delegated parties](#88-review-of-delegated-parties)
- [9. OTHER BUSINESS AND LEGAL MATTERS](#9-other-business-and-legal-matters)
- [9.1 Fees](#91-fees)
- [9.1.1 Certificate issuance or renewal fees](#911-certificate-issuance-or-renewal-fees)
- [9.1.2 Certificate access fees](#912-certificate-access-fees)
- [9.1.3 Revocation or status information access fees](#913-revocation-or-status-information-access-fees)
- [9.1.4 Fees for other services](#914-fees-for-other-services)
- [9.1.5 Refund policy](#915-refund-policy)
- [9.2 Financial responsibility](#92-financial-responsibility)
- [9.2.1 Insurance coverage](#921-insurance-coverage)
- [9.2.2 Other assets](#922-other-assets)
- [9.2.3 Insurance or warranty coverage for end-entities](#923-insurance-or-warranty-coverage-for-end-entities)
- [9.3 Confidentiality of business information](#93-confidentiality-of-business-information)
- [9.3.1 Scope of confidential information](#931-scope-of-confidential-information)
- [9.3.2 Information not within the scope of confidential information](#932-information-not-within-the-scope-of-confidential-information)
- [9.3.3 Responsibility to protect confidential information](#933-responsibility-to-protect-confidential-information)
- [9.4 Privacy of personal information](#94-privacy-of-personal-information)
- [9.4.1 Privacy plan](#941-privacy-plan)
- [9.4.2 Information treated as private](#942-information-treated-as-private)
- [9.4.3 Information not deemed private](#943-information-not-deemed-private)
- [9.4.4 Responsibility to protect private information](#944-responsibility-to-protect-private-information)
- [9.4.5 Notice and consent to use private information](#945-notice-and-consent-to-use-private-information)
- [9.4.6 Disclosure pursuant to judicial or administrative process](#946-disclosure-pursuant-to-judicial-or-administrative-process)
- [9.4.7 Other information disclosure circumstances](#947-other-information-disclosure-circumstances)
- [9.5 Intellectual property rights](#95-intellectual-property-rights)
- [9.6 Representations and warranties](#96-representations-and-warranties)
- [9.6.1 CA representations and warranties](#961-ca-representations-and-warranties)
- [9.6.2 RA representations and warranties](#962-ra-representations-and-warranties)
- [9.6.3 Subscriber representations and warranties](#963-subscriber-representations-and-warranties)
- [9.6.4 Relying party representations and warranties](#964-relying-party-representations-and-warranties)
- [9.6.5 Representations and warranties of other participants](#965-representations-and-warranties-of-other-participants)
- [9.7 Disclaimers of warranties](#97-disclaimers-of-warranties)
- [9.8 Limitations of liability](#98-limitations-of-liability)
- [9.9 Indemnities](#99-indemnities)
- [9.10 Term and termination](#910-term-and-termination)
- [9.10.1 Term](#9101-term)
- [9.10.2 Termination](#9102-termination)
- [9.10.3 Effect of termination and survival](#9103-effect-of-termination-and-survival)
- [9.11 Individual notices and communications with participants](#911-individual-notices-and-communications-with-participants)
- [9.12 Amendments](#912-amendments)
- [9.12.1 Procedure for amendment](#9121-procedure-for-amendment)
- [9.12.2 Notification mechanism and period](#9122-notification-mechanism-and-period)
- [9.12.3 Circumstances under which OID must be changed](#9123-circumstances-under-which-oid-must-be-changed)
- [9.13 Dispute resolution provisions](#913-dispute-resolution-provisions)
- [9.14 Governing law](#914-governing-law)
- [9.15 Compliance with applicable law](#915-compliance-with-applicable-law)
- [9.16 Miscellaneous provisions](#916-miscellaneous-provisions)
- [9.16.1 Entire agreement](#9161-entire-agreement)
- [9.16.2 Assignment](#9162-assignment)
- [9.16.3 Severability](#9163-severability)
- [9.16.4 Enforcement (attorneys' fees and waiver of rights)](#9164-enforcement-attorneys-fees-and-waiver-of-rights)
- [9.16.5 Force Majeure](#9165-force-majeure)
- [9.17 Other provisions](#917-other-provisions)
- [APPENDIX A – CAA Contact Tag](#appendix-a--caa-contact-tag)
- [A.1. CAA Methods](#a1-caa-methods)
- [A.1.1. CAA contactemail Property](#a11-caa-contactemail-property)
- [A.1.2. CAA contactphone Property](#a12-caa-contactphone-property)
- [A.2. DNS TXT Methods](#a2-dns-txt-methods)
- [A.2.1. DNS TXT Record Email Contact](#a21-dns-txt-record-email-contact)
- [A.2.2. DNS TXT Record Phone Contact](#a22-dns-txt-record-phone-contact)
- [APPENDIX B – Certificate profile](#appendix-b--certificate-profile)
- [Table : "Security Communication RootCA2" and Subordinate CAs](#table--security-communication-rootca2-and-subordinate-cas)
- [Table : "Security Communication RootCA3" and Subordinate CAs](#table--security-communication-rootca3-and-subordinate-cas)
- [Table : "Security Communication ECC RootCA1" and Subordinate CAs](#table--security-communication-ecc-rootca1-and-subordinate-cas)
- [Table : "SECOM RSA Root CA 2023" and Subordinate CAs](#table--secom-rsa-root-ca-2023-and-subordinate-cas)
- [Table : "SECOM Document Signing RSA Root CA 2023" and Subordinate CAs](#table--secom-document-signing-rsa-root-ca-2023-and-subordinate-cas)
- [Table : "SECOM TLS RSA Root CA 2024" and Subordinate CA](#table--secom-tls-rsa-root-ca-2024-and-subordinate-ca)
- [Table : "SECOM TLS ECC Root CA 2024" and Subordinate CA](#table--secom-tls-ecc-root-ca-2024-and-subordinate-ca)
- [Table : "SECOM SMIME RSA Root CA 2024" and Subordinate CA](#table--secom-smime-rsa-root-ca-2024-and-subordinate-ca)
- [Table : Subscriber Certificates (Client Authentication Certificate and Document Signing Certificates)](#table--subscriber-certificates-client-authentication-certificate-and-document-signing-certificates)
- [Table : Subscriber Certificates (Code Signing Certificates, Not be issued after 2024-05-01)](#table--subscriber-certificates-code-signing-certificates-not-be-issued-after-2024-05-01)
- [Table: Subscriber Certificates (AATL Document Signing Certificates)](#table-subscriber-certificates-aatl-document-signing-certificates)
- [Table: Subscriber Certificates (S/MIME Certificates)](#table-subscriber-certificates-smime-certificates)
- [Table: Security Communication RootCA2 TSA, TA Certificates (Issued before 2018-09-26)](#table-security-communication-rootca2-tsa-ta-certificates-issued-before-2018-09-26)
- [Table: Security Communication RootCA3 TSA, TA Certificates (Issued before 2018-09-26)](#table-security-communication-rootca3-tsa-ta-certificates-issued-before-2018-09-26)
- [Table: Security Communication RootCA3 TimeStamping Subordinate CA Certificates (Issued after 2018-06-07)](#table-security-communication-rootca3-timestamping-subordinate-ca-certificates-issued-after-2018-06-07)
- [Table: SECOM TimeStamping CA2 TSA, TA Certificates](#table-secom-timestamping-ca2-tsa-ta-certificates)
- [Table: SECOM TimeStamping CA3 TSA, TA Certificates](#table-secom-timestamping-ca3-tsa-ta-certificates)
- [Table: SECOM TimeStamping CA4 TSA Certificates (Not issued after 2025-04-15)](#table-secom-timestamping-ca4-tsa-certificates-not-issued-after-2025-04-15)
- [Table: SECOM TimeStamping Service TSA Certificates](#table-secom-timestamping-service-tsa-certificates)
# 1. INTRODUCTION
## 1.1 Overview
This Certificate Policy/Certification Practice Statement (hereinafter, "CP/CPS") shall indicate the purpose of use, scope of application, and user procedures for certificates operated by SECOM Trust Systems Co., Ltd. (hereinafter, "SECOM Trust Systems"), and stipulate policies concerning the certificates.
SECOM Trust Systems provides the certification services as the CAs, including the CA key administration as well as issuance/revocation of Certificates (hereinafter, "the Services").
This CP/CPS shall be revised as necessary in order to reflect any technical or operational developments or improvements pertaining to the CA.
This CP/CPS conforms to the RFC3647 "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework" advocated by the IETF as a CA practice framework”.
This CP/CPS complies with [CCADB Policy](https://www.ccadb.org/policy), the CA MUST provide at least an authoritative English version of CP/CPS which are not originally in English, with version numbers matching the document they are a translation of. The Japanese version of the CP/CPS should be written with the Japanese section name under the English section name.
### 1.1.1 Standards, Criteria and Regulations
The CA shall comply with the latest versions of the Standards, Criteria, and Regulations established by the CA/Browser Forum, as well as the Application Software Supplier.
See [Section 8.4](#84-topics-covered-by-assessment) for the audit scheme that CAs must follow.
Table: Standards, Criteria and Regulations List
| Types of certificates issued by subordinate CAs | Standards, Criteria and Regulations to comply with |
| --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| TLS Server Certificates | [Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates](https://cabforum.org/baseline-requirements-documents/) (hereinafter, "Baseline Requirements")
[Guidelines for the Issuance and Management of Extended Validation Certificates](https://cabforum.org/extended-validation/) (EV Certificates only. hereinafter, "EV Guidelines" )
[Apple Root Certificate Program](https://www.apple.com/certificateauthority/ca_program.html)
[Chrome Root Program Policy](https://www.chromium.org/Home/chromium-security/root-ca-policy/)
[Microsoft Trusted Root Program](https://aka.ms/RootCert)
[Mozilla Root Store Policy](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/) |
| TLS Client Authentication Certificates
(hereinafter, "Client Authentication Certificates") | [Apple Root Certificate Program](https://www.apple.com/certificateauthority/ca_program.html)
[Microsoft Trusted Root Program](https://aka.ms/RootCert) |
| S/MIME Certificates | [Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates](https://cabforum.org/smime-br/) (hereinafter, "S/MIME Baseline Requirements")
[Apple Root Certificate Program](https://www.apple.com/certificateauthority/ca_program.html)
[Microsoft Trusted Root Program](https://aka.ms/RootCert)
[Mozilla Root Store Policy](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/) |
| Code Signing Certificates, Timestamp Certificates for Code Signing Certificates | [Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates](https://cabforum.org/working-groups/code-signing/requirements/) (hereinafter, "Baseline Requirements for Code Signing Certificates")
[Microsoft Trusted Root Program](https://aka.ms/RootCert) |
| AATL Document Signing Certificates, AATL Timestamp Certificates | [Adobe Approved Trust List Technical Requirements](https://helpx.adobe.com/acrobat/kb/approved-trust-list2.html) (hereinafter, "AATL Technical Requirements") |
| Microsoft Document Signing Certificates | [Microsoft Trusted Root Program](https://aka.ms/RootCert) |
\* AATL Document Signing Certificates and Microsoft Document Signing Certificates are collectively referred to as "Document Signing Certificates".
\* Timestamp Certificates for Code Signing Certificates and AATL Timestamp Certificates are collectively referred to as "Timestamp Certificates".
The CA may outsource the part of the certification work to an external business operator that complies with Baseline Requirements (hereinafter, "Delegated Third Party"), and the contract between the two companies shall be stipulated in the service terms.
In the event of any inconsistency between this CP/CPS and the Baseline Requirements, the Baseline Requirements take precedence over this CP/CPS.
## 1.2 Document name and identification
The official name of this CP/CPS is "SECOM Publicly Trusted CP/CPS".
SECOM Trust Systems, which is the provider and operational body of the Services, uses the Object IDentifier (hereinafter, "OID") assigned by ISO.
---
Table: OID (SECOM Trust Systems)
| Name of organization | OID |
| ----------------------------- | -------------- |
| SECOM Trust Systems Co., Ltd. | 1.2.392.200091 |
---
OID used when issuing a subordinate CA certificate from the Root CA
Table: OID (Root CA CP)
| CP | OID |
| --------------------------------------------------------- | ------------------------- |
| Security Communication RootCA2 Subordinate CA CP | 1.2.392.200091.100.901.4 |
| Security Communication RootCA2 Time-Stamp Service CP | 1.2.392.200091.100.901.5 |
| Security Communication RootCA3 Subordinate CA CP | 1.2.392.200091.100.901.6 |
| Security Communication RootCA3 Time-Stamp Service CP | 1.2.392.200091.100.901.7 |
| SECOM RSA Root CA 2023 Subordinate CA CP | 1.2.392.200091.100.901.9 |
| SECOM Document Signing RSA Root CA 2023 Subordinate CA CP | 1.2.392.200091.100.901.10 |
| SECOM TLS RSA Root CA 2024 Subordinate CA CP | 1.2.392.200091.100.901.11 |
| SECOM SMIME RSA Root CA 2024 Subordinate CA CP | 1.2.392.200091.100.901.12 |
| Security Communication ECC RootCA1 Subordinate CA CP | 1.2.392.200091.100.902.1 |
| SECOM TLS ECC Root CA 2024 Subordinate CA CP | 1.2.392.200091.100.902.3 |
---
OID used when issuing EE certificates from a subordinate CA
Table: OID（Subordinate CA CP）
| CP | OID |
| --------------------------------------------------------------------------------------------- | ------------------------- |
| Client Certificate Policy (SHA1)
(Client Authentication Certificates) | 1.2.392.200091.100.381.1 |
| Certificate Policy for Data Signing (SHA1)
(Document Signing Certificates) | 1.2.392.200091.100.381.2 |
| Client Certificate Policy
(Client Authentication Certificates) | 1.2.392.200091.100.381.4 |
| Certificate Policy for Data Signing
(Document Signing Certificates) | 1.2.392.200091.100.381.5 |
| Certificate Policy for Code Signing (SHA256) | 1.2.392.200091.100.381.8 |
| Certificate Policy for AATL Document Signing | 1.2.392.200091.100.382.1 |
| Certificate Policy for S/MIME | 1.2.392.200091.100.383.1 |
| SECOM Passport for Web EV CA CP | 1.2.392.200091.100.721.1 |
| SECOM Passport for Web SR CA CP | 1.2.392.200091.100.751.1 |
| SECOM TLS OV CP | 1.2.392.200091.100.752.1 |
| SECOM TLS DV CP | 1.2.392.200091.100.752.2 |
| SECOM TimeStamping CA2 | 1.2.392.200091.100.931.1 |
| SECOM TimeStamping CA3 | 1.2.392.200091.100.931.3 |
| SECOM TimeStamping CA4 | 1.2.392.200091.100.931.4 |
| SECOM TimeStamping Service | 1.2.392.200091.100.931.5 |
| SECOM Trust Systems Subordinate Advanced CA
(Issued by Security Communication RootCA3) | 1.2.392.200091.100.999.11 |
| SECOM Trust Systems Subordinate Advanced CA
(Issued by Security Communication ECC RootCA) | 1.2.392.200091.100.999.13 |
| SC Domain Validation CA1 | 1.2.392.200091.110.213.1 |
| SC Domain Validation CA2 | 1.2.392.200091.110.213.2 |
| SC Organization Validation CA2
(Issued by Security Communication Root CA2) | 1.2.392.200091.110.214.2 |
| SC Organization Validation CA3
(Issued by Security Communication Root CA2) | 1.2.392.200091.110.214.3 |
| SC Organization Validation CA4
(Issued by Security Communication ECC RootCA1) | 1.2.392.200091.110.214.4 |
---
### 1.2.1 Revisions
| **Ver.** | **Date** | **Description** |
| -------- | ---------- | -------------------------------- |
| 1.00 | 2025-05-26 | Publication of the first version |
## 1.3 PKI Participants
### 1.3.1 Certification Authorities
Certification Authority (CA) is an organization that is responsible for the creation, issuance, revocation, and management of Certificates. CA publishes CRLs (Certificate Revocation Lists) and stores and provides information on Certificate status using the OCSP responder.
Certification Authority (CA) is defined in [Section 1.6](#16-definitions-and-acronyms).
### 1.3.2 Registration Authorities
With the exception of [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) and [Section 3.2.2.5](#3225-authentication-for-an-ip-address), the CA MAY delegate the performance of all, or any part, of [Section 3.2](#32-initial-identity-validation) requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of [Section 3.2](#32-initial-identity-validation).
Before the CA authorizes a Delegated Third Party to perform a delegated function, the CA SHALL contractually require the Delegated Third Party to:
1. Meet the qualification requirements of [Section 5.3.1](#531-qualifications-experience-and-clearance-requirements), when applicable to the delegated function;
2. Retain documentation in accordance with [Section 5.5.2](#552-retention-period-for-archive);
3. Abide by the other provisions of Baseline Requirements that are applicable to the delegated function; and
4. Comply with
a. the CA's Certificate Policy/Certification Practice Statement or
b. the Delegated Third Party's practice statement that the CA has verified complies with Baseline Requirements.
The CA MAY designate an Enterprise RA to verify certificate requests from the Enterprise RA's own organization.
The CA SHALL NOT accept certificate requests authorized by an Enterprise RA unless the following requirements are satisfied:
1. The CA SHALL confirm that the requested Fully-Qualified Domain Name(s) are within the Enterprise
RA's verified Domain Namespace.
2. If the certificate request includes a Subject name of a type other than a Fully-Qualified Domain Name, the CA SHALL confirm that the name is either that of the delegated enterprise, or an Affiliate of the delegated enterprise, or that the delegated enterprise is an agent of the named Subject. For example, the CA SHALL NOT issue a Certificate containing the Subject name "XYZ Co." on the authority of Enterprise RA "ABC Co.", unless the two companies are affiliated (see [Section 3.2](#32-initial-identity-validation)) or "ABC Co." is the agent of "XYZ Co". This requirement applies regardless of whether the accompanying requested Subject FQDN falls within the Domain Namespace of ABC Co.'s Registered Domain Name.
The CA SHALL impose these limitations as a contractual requirement on the Enterprise RA and monitor compliance by the Enterprise RA.
**[Document Signing Certificates and Client Authentication Certificates]**
The LRA is the entity that performs, on behalf of the RA, verification of the existence of the certificate subscriber and verification of the identity, registration of the certificate for issuing and revoking the certificate, and the like. A special organization or entity that has been reviewed by the RA in advance and confirmed by the RA can play that role.
The LRA, like the RA, shall comply with the matters stipulated in this CP/CPS. Note that the LRA may perform a task only when a client certificate policy or a data signature certificate policy is applied.
#### 1.3.2.1 Enterprise registration authorities (S/MIME Certificates)
The CA MAY delegate to an Enterprise Registration Authority (RA) to verify Certificate Requests for Subjects within the Enterprise RA's own organization. The CA SHALL NOT accept Certificate Requests authorized by an Enterprise RA unless the following requirements are satisfied:
1. If the Certificate Request is for a `Mailbox-validated` profile, the CA SHALL confirm that the Enterprise RA has authorization or control of the requested email domain(s) in accordance with [Section 3.2.2.1.1](#32211-validating-authority-over-mailbox-via-domain-smime-certificates) or [Section 3.2.2.1.3](#32213-validating-applicant-as-operator-of-associated-mail-servers-smime-certificates).
The CA SHALL impose these limitations as a contractual requirement on the Enterprise RA and monitor compliance by the Enterprise RA in accordance with [Section 8.8](#88-review-of-delegated-parties).
An Enterprise RA MAY also submit Certificate Requests using the `Mailbox-validated` profile for users whose email domain(s) are not under the delegated organization’s authorization or control. In this case, the CA SHALL confirm that the mailbox holder has control of the requested Mailbox Address(es) in accordance with [Section 3.2.2.1.2](#32212-validating-control-over-mailbox-via-email-smime-certificates).
### 1.3.3 Subscribers
Subscribers shall be any natural person or Legal Entity that receive a Certificate issued by the CA and conforms to the Subscriber Agreement or Term of Use.
Subscribers generate Key Pairs in their own rights, to which Certificates are issued by the CAs. They are qualified as Subscribers upon accepting the issued Certificates after submitting the Certificate applications to the CAs. Subscribers must assess Section in light of their usage purposes, and agree thereto.
### 1.3.4 Relying Parties
Relying Party is any natural person or Legal Entity that relies on a Valid Certificate. An Application Software Supplier is not considered a Relying Party when software distributed by such Supplier merely displays information relating to a Certificate.
Relying Parties are the entities that authenticate the validity of Certificates issued by the CAs. Relying Parts are assumed to be performing the authentication and placing trust upon confirming and agreeing to the contents of Section in light of the Relying Parties' own purposes of use.
"Relying Party" and "Application Software Supplier" are defined in [Section 1.6.1](#161-definitions). Current Members of the CA/Browser Forum who are Application Software Suppliers are listed here:
.
### 1.3.5 Other Participants
Other groups include auditors, and companies or organizations that have service contracts with SECOM Trust Systems, and companies that perform system integration.
## 1.4 Certificate Usage
### 1.4.1 Appropriate Certificate Uses
The CAs are the Certification Authorities functioning as top of the Subordinate CAs and issue Subordinate CA Certificates as Subscriber Certificates. Relying Parties that trust and use the Certificates may authenticate the reliability of such Certificates using the CA public key Certificates.
The certificates issued by the TLS Subordinate CA are intended for establishing Web-based data communication conduits via the TLS protocols and for verifying the authenticity of executable code.
The primary purposes of an EV Certificate are to:
1. Identify the legal entity that controls a Web site:
Provide a reasonable assurance to the user of an Internet browser that the Web site the user is accessing is controlled by a specific legal entity identified in the EV Certificate by name, address of Place of Business, Jurisdiction of Incorporation or Registration and Registration Number or other disambiguating information;
2. Enable encrypted communications with a Web site:
Facilitate the exchange of encryption keys in order to enable the encrypted communication of information over the Internet between the user of an Internet browser and a Web site.
The secondary purposes of an EV Certificate are to help establish the legitimacy of a business claiming to operate a Web site or distribute executable code, and to provide a vehicle that can be used to assist in addressing problems related to phishing, malware, and other forms of online identity fraud. By providing more reliable third-party verified identity and address information regarding the business, EV Certificates may help to:
1. Make it more difficult to mount phishing and other online identity fraud attacks using Certificates;
2. Assist companies that may be the target of phishing attacks or online identity fraud by providing them with a tool to better identify themselves to users;
3. Assist law enforcement organizations in their investigations of phishing and other online identity fraud, including where appropriate, contacting, investigating, or taking legal action against the Subject.
### 1.4.2 Prohibited Certificate Uses
Certificates issued by the TLS Subordinate CA shall not be used for purposes other than server authentication and data encryption in the communication routing.
The CA does not permit the issuance of certificates unless it is confirmed from the domain owner verified in accordance with [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) that the domain owner has the right to use the domain.
EV Certificates focus only on the identity of the Subject named in the Certificate, and not on the behavior of the Subject. As such, an EV Certificate is not intended to provide any assurances, or otherwise represent or warrant:
1. That the Subject named in the EV Certificate is actively engaged in doing business;
2. That the Subject named in the EV Certificate complies with applicable laws;
3. That the Subject named in the EV Certificate is trustworthy, honest, or reputable in its business dealings;
4. That it is “safe” to do business with the Subject named in the EV Certificate.
## 1.5 Policy administration
### 1.5.1 Organization Administering the Document
This CP/CPS is maintained and administered by SECOM Trust Systems.
### 1.5.2 Contact Person
Inquiries concerning this CP/CPS should be directed to:
| Contact Information | CA Support Center, SECOM Trust Systems |
| ------------------- | ------------------------------------------------ |
| Address | 8-10-16 Shimorenjaku, Mitaka-shi, Tokyo 181-8528 |
| Inquiry details | Inquiries for this CP/CPS / Except for Certificate Problem Report |
| --------------- | ------------------------------------------------------------------------------------------------ |
| Email | ca-support [at] secom [dot] co [dot] jp |
| Business hours | 9:00-18:00, except on Saturdays, Sundays, national holidays, and year-end and New Year holidays. |
The Subscribers, Relying Parties, Application Software Suppliers, and other third parties can report suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA revokes certificates when it is determined that it needs to be revoked.
| Inquiry details | Certificate Problem Report |
| --------------- | ------------------------------------------------------- |
| URL | |
| Business hours | 24x7 |
### 1.5.3 Person Determining CPS suitability for the policy
The Certification Services Improvement Committee (hereinafter, "this Committee") determines the suitability of the contents of this CP/CPS. This CP/CPS shall be reviewed and revised at least annually.
### 1.5.4 CPS approval procedures
This CP/CPS shall be published in the repository as developed and revised under approval of the SECOM Certification Services Improvement Committee.
This CP/CPS goes into effect upon approval by this Committee for the CA.
## 1.6 Definitions and Acronyms
### 1.6.1 Definitions
**AATL (Adobe Approved Trust List)**: A program that allows to create digital signatures that are trusted whenever the signed document is opened in Adobe® Acrobat® or Acrobat® Reader® software.
**ADN (Authorization Domain Name)**: Domain name used to obtain authentication for certificate issuance for a particular FQDN.
**Affiliate**: A corporation, partnership, joint venture or other entity controlling, controlled by, or under common control with another entity, or an agency, department, political subdivision, or any entity operating under the direct control of a Government Entity.
**Applicant**: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate is issued, the Applicant is referred to as the Subscriber. For Certificates issued to devices, the Applicant is the entity that controls or operates the device named in the Certificate, even if the device is sending the actual certificate request.
**Applicant Representative**: A natural person or human sponsor who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant:
i. who signs and submits, or approves a certificate request on behalf of the Applicant, and/or
ii. who signs and submits a Subscriber Agreement on behalf of the Applicant, and/or
iii. who acknowledges the Terms of Use on behalf of the Applicant when the Applicant is an Affiliate of the CA or is the CA.
**Application Software Supplier**: A supplier of Internet browser software or other relying-party application software that displays or uses Certificates and incorporates Root Certificates.
**Archive**: Information obtained for the purpose of preserving history for legal or other reasons.
**Attestation Letter**: A letter attesting that Subject Information is correct written by an accountant, lawyer, government official, or other reliable third party customarily relied upon for such information.
**Audit Log**: Behavioral, access and other histories pertaining to the CA systems which are recorded for inspection of access to and unauthorized operation of the CA systems.
**Audit Period**: In a period-of-time audit, the period between the first day (start) and the last day of operations (end) covered by the auditors in their engagement. (This is not the same as the period of time when the auditors are on-site at the CA.) The coverage rules and maximum length of audit periods are defined in [Section 8.1](#81-frequency-or-circumstances-of-assessment).
**Audit Report**: A report from a Qualified Auditor stating the Qualified Auditor's opinion on whether an entity's processes and controls comply with the mandatory provisions of Baseline Requirements.
**Authorization Domain Name**: The FQDN used to obtain authorization for a given FQDN to be included in a Certificate. The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. If a Wildcard Domain Name is to be included in a Certificate, then the CA MUST remove "`*.`" from the left-most portion of the Wildcard Domain Name to yield the corresponding FQDN. The CA may prune zero or more Domain Labels of the FQDN from left to right until encountering a Base Domain Name and may use any one of the values that were yielded by pruning (including the Base Domain Name itself) for the purpose of domain validation.
**Authorized Ports**: One of the following ports: 80 (http), 443 (https), 25 (smtp), 22 (ssh).
**Base Domain Name**: The portion of an applied-for FQDN that is the first Domain Name node left of a registry-controlled or public suffix plus the registry-controlled or public suffix (e.g. "example.co.jp" or "example.com"). For FQDNs where the right-most Domain Name node is a gTLD having ICANN Specification 13 in its registry agreement, the gTLD itself may be used as the Base Domain Name.
**Baseline Requirements**: A document issued by the CA/Browser Forum (available at cabforum.org.) that integrates a set of fundamental requirements for Certificate issuance/administration.
**Business Entity**: Any entity that is not a Private Organization, Government Entity, or Non-Commercial Entity as defined herein. Examples include, but are not limited to, general partnerships, unincorporated associations, sole proprietorships, etc.
**CAA**: From RFC 8659 (): "The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue."
**CA/Browser Forum**: An NPO organized by CAs and Internet browser vendors that works to define and standardize the Certificate issuance requirements.
**CA Key Pair**: A Key Pair where the Public Key appears as the Subject Public Key Info in one or more Root CA Certificate(s) and/or Subordinate CA Certificate(s).
**Certificate**: An electronic document that uses a digital signature to bind a public key and an identity.
**Certificate Approver**: A natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant to
i. act as a Certificate Requester and to authorize other employees or third parties to act as a Certificate Requester, and
ii. to approve EV Certificate Requests submitted by other Certificate Requesters.
**Certificate Data**: Certificate requests and data related thereto (whether obtained from the Applicant or otherwise) in the CA's possession or control or to which the CA has access.
**Certificate Management Process**: Processes, practices, and procedures associated with the use of keys, software, and hardware, by which the CA verifies Certificate Data, issues Certificates, maintains a Repository, and revokes Certificates.
**Certificate Policy (CP)**: A set of rules that indicates the applicability of a named Certificate to a particular community and/or PKI implementation with common security requirements.
**Certificate Problem Report**: Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.
**Certificate Profile**: A set of documents or files that defines requirements for Certificate content and Certificate extensions in accordance with [Section 7](#7-certificate-crl-and-ocsp-profiles), e.g. a Section in a CA’s CPS or a certificate template file used by CA software.
**Certificate Requester**: A natural person who is either the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or a third party (such as an ISP or hosting company) that completes and submits an EV Certificate Request on behalf of the Applicant.
**Certificate Revocation List (CRL)**: A regularly updated time-stamped list of revoked Certificates that is created and digitally signed by the CA that issued the Certificates.
**Certificate Signing Request (CSR)**: CSR stands for Certificate Signing Request, a data file on which the digital certificate issuance is based. A CSR contains the public key of the entity requesting the Certificate signing, to which the issuer's digital signature is affixed upon the issuance thereof.
**Certificate Transparency (CT)**: Certificate Transparency, stipulated in RFC 6962, is an open framework for monitoring/auditing the records of the issued Certificates by registering and publishing them on the log servers.
**Certification Authority (CA)**: An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Root CAs and Subordinate CAs.
**Certification Practice Statement**: One of several documents forming the governance framework in which Certificates are created, issued, managed, and used.
**Certification Services Improvement Committee**: The decision-making body for the operational policy of the Services, including administration of this CP/CPS and modification reviews.
**Code**: A contiguous set of bits that has been or can be digitally signed with a Private Key that corresponds to a Code Signing Certificate.
**Code Signature:** A Signature logically associated with a signed Code.
**Code Signing Certificate:** A digital certificate issued by a CA that contains a Code Signing EKU.
**Confirmation Request**: An appropriate out-of-band communication requesting verification or confirmation of the particular fact at issue.
**Confirming Person**: A position within an Applicant's organization that confirms the particular fact at issue.
**Contract Signer**: A natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements.
**Control**: "Control" (and its correlative meanings, "controlled by" and "under common control with") means possession, directly or indirectly, of the power to: (1) direct the management, personnel, finances, or plans of such entity; (2) control the election of a majority of the directors ; or (3) vote that portion of voting shares required for "control" under the law of the entity's Jurisdiction of Incorporation or Registration but in no case less than 10%.
**Country**: Either a member of the United Nations OR a geographic region recognized as a Sovereign State by at least two UN member nations.
**Cross-Certified Subordinate CA Certificate**: A certificate that is used to establish a trust relationship between two CAs.
**CSPRNG**: A random number generator intended for use in a cryptographic system.
**Delegated Third Party**: A natural person or Legal Entity that is not the CA but is authorized by the CA, and whose activities are not within the scope of the appropriate CA audits, to assist in the Certificate Management Process by performing or fulfilling one or more of the CA requirements found herein.
**Digital Certification Infrastructure**: A platform for operating the CA of SECOM Trust Systems and of the users of the Private CA users.
**DNS CAA Email Contact**: The email address defined in [Appendix A.1.1](#a11-caa-contactemail-property).
**DNS CAA Phone Contact**: The phone number defined in [Appendix A.1.2](#a12-caa-contactphone-property).
**DNS TXT Record Email Contact**: The email address defined in [Appendix A.2.1](#a21-dns-txt-record-email-contact).
**DNS TXT Record Phone Contact**: The phone number defined in [Appendix A.2.2](#a22-dns-txt-record-phone-contact).
**Domain Contact**: The Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record, or as obtained through direct contact with the Domain Name Registrar.
**Domain Label**: From RFC 8499 (): "An ordered list of zero or more octets that makes up a portion of a domain name. Using graph theory, a label identifies one node in a portion of the graph of all possible domain names."
**Domain Name**: An ordered list of one or more Domain Labels assigned to a node in the Domain Name System.
**Domain Namespace**: The set of all possible Domain Names that are subordinate to a single node in the Domain Name System.
**Domain Name Registrant**: Sometimes referred to as the "owner" of a Domain Name, but more properly the person(s) or entity(ies) registered with a Domain Name Registrar as having the right to control how a Domain Name is used, such as the natural person or Legal Entity that is listed as the "Registrant" by WHOIS or the Domain Name Registrar.
**Domain Name Registrar**: A person or entity that registers Domain Names under the auspices of or by agreement with:
i. the Internet Corporation for Assigned Names and Numbers (ICANN),
ii. a national Domain Name authority/registry, or
iii. a Network Information Center (including their affiliates, contractors, delegates, successors, or assignees).
**Enterprise RA**: An employee or agent of an organization unaffiliated with the CA who authorizes issuance of Certificates to that organization.
**Escrow**: Escrow means the placement (entrustment) of an asset in the control of an independent third party.
**EV Authority**: A source other than the Certificate Approver, through which verification occurs that the Certificate Approver is expressly authorized by the Applicant, as of the date of the EV Certificate Request, to take the Request actions described in these Guidelines.
**EV Certificate**: A certificate that contains subject information specified in these Guidelines and that has been validated in accordance with these Guidelines.
**EV Certificate Beneficiaries**: Persons to whom the CA and its Root CA make specified EV Certificate Warranties.
**EV Certificate Renewal**: The process whereby an Applicant who has a valid unexpired and non-revoked EV Certificate makes an application, to the CA that issued the original certificate, for a newly issued EV Certificate for the same organizational name and Domain Name prior to the expiration of the Applicant's existing EV Certificate but with a new 'valid to' date beyond the expiry of the current EV Certificate.
**EV Certificate Reissuance**: The process whereby an Applicant who has a valid unexpired and non-revoked EV Certificate makes an application, to the CA that issued the original certificate, for a newly issued EV Certificate for the same organizational name and Domain Name prior to the expiration of the Applicant's existing EV Certificate but with a 'valid to' date that matches that of the current EV Certificate.
**EV Certificate Request**: A request from an Applicant to the CA requesting that the CA issue an EV Certificate to the Applicant, which request is validly authorized by the Applicant and signed by the Applicant Representative.
**EV Certificate Warranties**: In conjunction with the CA issuing an EV Certificate, the CA and its Root CA, during the period when the EV Certificate is Valid, promise that the CA has followed the requirements of these Guidelines and the CA's EV Policies in issuing the EV Certificate and in verifying the accuracy of the information contained in the EV Certificate.
**EV OID**: An identifying number, in the form of an "object identifier," that is included in the `certificatePolicies` field of a certificate that:
i. indicates which CA policy statement relates to that certificate, and
ii. is either the CA/Browser Forum EV policy identifier or a policy identifier that, by pre-agreement with one or more Application Software Supplier, marks the certificate as being an EV Certificate.
**EV Policies**: Auditable EV Certificate practices, policies and procedures, such as a certification practice statement and certificate policy, that are developed, implemented, and enforced by the CA and its Root CA.
**EV Processes**: The keys, software, processes, and procedures by which the CA verifies Certificate Data under this Guideline, issues EV Certificates, maintains a Repository, and revokes EV Certificates.
**Extended Validation Certificate**: See EV Certificate.
**Expiry Date**: The "Not After" date in a Certificate that defines the end of a Certificate's validity period.
**FIPS140**: The security certification standards developed by the U.S. NIST (National Institute of Standards and Technology) for cryptographic modules.
**HSM (Hardware Security Module)**: The hardware that works as a protecting safe to store private keys used for encryption and digital signing. An HSM computes encryption and digital signing as well as generates private keys and random digits.
**Fully-Qualified Domain Name**: A Domain Name that includes the Domain Labels of all superior nodes in the Internet Domain Name System.
**Government Agency**: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of Private Organizations is established (e.g., the government agency that issued the Certificate of Incorporation). In the context of Business Entities, the government agency in the jurisdiction of operation that registers business entities. In the case of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities.
**Government Entity**: A government-operated legal entity, agency, department, ministry, branch, or similar element of the government of a country, or political subdivision within such country (such as a state, province, city, county, etc.).
**High Risk Certificate Request**: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that the CA identifies using its own risk-mitigation criteria.
**Incorporating Agency**: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of the entity is registered (e.g., the government agency that issues certificates of formation or incorporation). In the context of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities.
**Independent Confirmation From Applicant**: Confirmation of a particular fact received by the CA pursuant to the provisions of the EV Guidelines or binding upon the Applicant.
**Internal Name**: A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA's Root Zone Database.
**Individual**: A natural person.
**INAN (Internet Assigned Numbers Authority)**: The organization that globally manages information related to the Internet, such as IP addresses and port numbers.
**International Organization**: An organization founded by a constituent document, e.g., a charter, treaty, convention or similar document, signed by, or on behalf of, a minimum of two Sovereign State governments.
**Issuing Authority (IA)**: An entity which, of the duties of a CA, mainly handles the issuance/ renewal/ revocation of Certificates, generation and protection of CA private keys, and the maintenance and management of repositories.
**IP Address**: A 32-bit or 128-bit number assigned to a device that uses the Internet Protocol for communication.
**IP Address Contact**: The person(s) or entity(ies) registered with an IP Address Registration Authority as having the right to control how one or more IP Addresses are used.
**IP Address Registration Authority**: The Internet Assigned Numbers Authority (IANA) or a Regional Internet Registry (RIPE, APNIC, ARIN, AfriNIC, LACNIC).
**Issuing CA**: In relation to a particular Certificate, the CA that issued the Certificate. This could be either a Root CA or a Subordinate CA.
**Key Compromise**: A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it.
**Key Generation Script**: A documented plan of procedures for the generation of a CA Key Pair.
**Key Pair**: The Private Key and its associated Public Key.
**LDH Label**: From RFC 5890 (): "A string consisting of ASCII letters, digits, and the hyphen with the further restriction that the hyphen cannot appear at the beginning or end of the string. Like all DNS labels, its total length must not exceed 63 octets."
**Legal Entity**: An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a country's legal system.
**Legal Existence**: A Private Organization, Government Entity, or Business Entity has Legal Existence if it has been validly formed and not otherwise terminated, dissolved, or abandoned.
**Legal Practitioner**: A person who is either a lawyer or a Latin Notary as described in these Guidelines and competent to render an opinion on factual claims of the Applicant.
**Linting**: A process in which the content of digitally signed data such as a Precertificate [RFC 6962], Certificate, Certificate Revocation List, or OCSP response, or data-to-be-signed object such as a `tbsCertificate` (as described in [RFC 5280, Section 4.1.1.1](https://tools.ietf.org/doc/html/rfc5280##section-4.1.1.1)) is checked for conformance with the profiles and requirements defined in Baseline Requirements.
**Major Version Number**: A number to be given to a revision of this CP/CPS (e.g., the underlined digit [1] of Version 1.02) whose magnitude of the amendment(s) thereof is considered to have an obvious impact on the use of the Certificates and the CRLs by Subscribers and Relying Parties.
**Minor Version Number**: A number to be given to a revision of this CP/CPS (e.g., the underlined digit [02] of Version 1.02) whose magnitude of the amendment(s) thereof is considered to have no or less impact on the use of the Certificates and the CRLs by Subscribers and Relying Parties.
**Multi-Perspective Issuance Corroboration**: A process by which the determinations made during domain validation and CAA checking by the Primary Network Perspective are corroborated by other Network Perspectives before Certificate issuance.
**Network Perspective**: Related to Multi-Perspective Issuance Corroboration. A system (e.g., a cloud-hosted server instance) or collection of network components (e.g., a VPN and corresponding infrastructure) for sending outbound Internet traffic associated with a domain control validation method and/or CAA check. The location of a Network Perspective is determined by the point where unencapsulated outbound Internet traffic is typically first handed off to the network infrastructure providing Internet connectivity to that perspective.
**Network Time Protocol (NTP)**: A protocol for correctly adjusting the internal clocks of computers via the networks.
**Non-Reserved LDH Label**: From RFC 5890 (): "The set of valid LDH labels that do not have '`--`' in the third and fourth positions."
**Object Identifier**: A unique alphanumeric or numeric identifier registered under the International Organization for Standardization's applicable standard for a specific object or object class.
**OCSP Responder**: An online server operated under the authority of the CA and connected to its Repository for processing Certificate status requests. See also, Online Certificate Status Protocol.
**Onion Domain Name**: A Fully Qualified Domain Name ending with the RFC 7686 ".onion" Special-Use Domain Name. For example, `2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion` is an Onion Domain Name, whereas `torproject.org` is not an Onion Domain Name.
**Online Certificate Status Protocol**: An online Certificate-checking protocol that enables relying-party application software to determine the status of an identified Certificate. See also OCSP Responder.
**Parent Company**: A company that Controls a Subsidiary Company.
**Pending Prohibition**: The use of a behavior described with this label is highly discouraged, as it is planned to be deprecated and will likely be designated as MUST NOT in the future.
**Place of Business**: The location of any facility (such as a factory, retail store, warehouse, etc) where the Applicant's business is conducted.
**Principal Individual**: An individual of a Private Organization, Government Entity, or Business Entity that is either an owner, partner, managing member, director, or officer, as identified by their title of employment, or an employee, contractor or agent authorized by such entity or organization to conduct business related to the request, issuance, and use of EV Certificates.
**Precertificate**: A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by RFC 6962. A Precertificate is created after a CA has decided to issue a Certificate, but prior to the actual signing of the Certificate. The CA MAY construct and sign a Precertificate corresponding to the Certificate, for purposes of submitting to CT Logs. The CA MAY use the returned Signed Certificate Timestamps to then alter the Certificate’s extensions field, adding a Signed Certificate Timestamp List, as defined in [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) and as permitted by the relevant profile, prior to signing the Certificate.
**Primary Network Perspective**: The Network Perspective used by the CA to make the determination of 1) the CA's authority to issue a Certificate for the requested domain(s) or IP address(es) and 2) the Applicant's authority and/or domain authorization or control of the requested domain(s) or IP address(es).
**Private Organization**: A non-governmental legal entity (whether ownership interests are privately held or publicly traded) whose existence was created by a filing with (or an act of) the Incorporating Agency or equivalent in its Jurisdiction of Incorporation.
**Private Key**: The key of a Key Pair that is kept secret by the holder of the Key Pair, and that is used to create Digital Signatures and/or to decrypt electronic records or files that were encrypted with the corresponding Public Key.
**Public Key**: The key of a Key Pair that may be publicly disclosed by the holder of the corresponding Private Key and that is used by a Relying Party to verify Digital Signatures created with the holder's corresponding Private Key and/or to encrypt messages so that they can be decrypted only with the holder's corresponding Private Key.
**Public Key Infrastructure**: A set of hardware, software, people, procedures, rules, policies, and obligations used to facilitate the trustworthy creation, issuance, management, and use of Certificates and keys based on Public Key Cryptography.
**Publicly-Trusted Certificate**: A Certificate that is trusted by virtue of the fact that its corresponding Root Certificate is distributed as a trust anchor in widely-available application software.
**P-Label**: A XN-Label that contains valid output of the Punycode algorithm (as defined in RFC 3492, Section 6.3) from the fifth and subsequent positions.
**Qualified Auditor**: A natural person or Legal Entity that meets the requirements of [Section 8.2](#82-identityqualifications-of-assessor).
**Qualified Government Information Source**: A database maintained by a Government Entity (e.g. SEC filings) that meets the requirements of [Section 3.2.2.2.10.6](#3222106-qualified-government-information-source).
**Qualified Independent Information Source**: A regularly-updated and current, publicly available, database designed for the purpose of accurately providing the information for which it is consulted, and which is generally recognized as a dependable source of such information.
**Random Value**: A value specified by a CA to the Applicant that exhibits at least 112 bits of entropy.
**Registered Domain Name**: A Domain Name that has been registered with a Domain Name Registrar.
**Registration Authority (RA)**: Any Legal Entity that is responsible for identification and authentication of subjects of Certificates, but is not a CA, and hence does not sign or issue Certificates. An RA may assist in the certificate application process or revocation process or both. When "RA" is used as an adjective to describe a role or function, it does not necessarily imply a separate body, but can be part of the CA.
**Reliable Data Source**: An identification document or source of data used to verify Subject Identity Information that is generally recognized among commercial enterprises and governments as reliable, and which was created by a third party for a purpose other than the Applicant obtaining a Certificate.
**Reliable Method of Communication**: A method of communication, such as a postal/courier delivery address, telephone number, or email address, that was verified using a source other than the Applicant Representative.
**Relying Party**: Any natural person or Legal Entity that relies on a Valid Certificate. An Application Software Supplier is not considered a Relying Party when software distributed by such Supplier merely displays information relating to a Certificate.
**Repository**: An online database containing publicly-disclosed PKI governance documents (such as Certificate Policies and Certification Practice Statements) and Certificate status information, either in the form of a CRL or an OCSP response.
**Request Token**: A value, derived in a method specified by the CA which binds this demonstration of control to the certificate request. The CA SHOULD define within its CPS (or a document clearly referenced by the CPS) the format and method of Request Tokens it accepts.
The Request Token SHALL incorporate the key used in the certificate request.
A Request Token MAY include a timestamp to indicate when it was created.
A Request Token MAY include other information to ensure its uniqueness.
A Request Token that includes a timestamp SHALL remain valid for no more than 30 days from the time of creation.
A Request Token that includes a timestamp SHALL be treated as invalid if its timestamp is in the future.
A Request Token that does not include a timestamp is valid for a single use and the CA SHALL NOT re-use it for a subsequent validation.
The binding SHALL use a digital signature algorithm or a cryptographic hash algorithm at least as strong as that to be used in signing the certificate request.
**Note**: Examples of Request Tokens include, but are not limited to:
i. a hash of the public key; or
ii. a hash of the Subject Public Key Info [X.509]; or
iii. a hash of a PKCS#10 CSR.
A Request Token may also be concatenated with a timestamp or other data. If a CA wanted to always use a hash of a PKCS#10 CSR as a Request Token and did not want to incorporate a timestamp and did want to allow certificate key re-use then the applicant might use the challenge password in the creation of a CSR with OpenSSL to ensure uniqueness even if the subject and key are identical between subsequent requests.
**Note**: This simplistic shell command produces a Request Token which has a timestamp and a hash of a CSR.
``echo `date -u +%Y%m%d%H%M` `sha256sum ): "The period of time from notBefore through notAfter, inclusive."
**WebTrust for CAs**: Standards of internal control and a certification framework based thereon maintained by CPA Canada regarding the reliability of CAs, the security of electronic commerce transactions, and other relevant matters.
**WHOIS**: Information retrieved directly from the Domain Name Registrar or registry operator via the protocol defined in RFC 3912, the Registry Data Access Protocol defined in RFC 7482, or an HTTPS website.
**Wildcard Certificate**: A Certificate containing at least one Wildcard Domain Name in the Subject Alternative Names in the Certificate.
**Wildcard Domain Name**: A string starting with "\*." (U+002A ASTERISK, U+002E FULL STOP) immediately followed by a Fully-Qualified Domain Name.
**XN-Label**: From RFC 5890 (): "The class of labels that begin with the prefix `"xn--"` (case independent), but otherwise conform to the rules for LDH labels."
**X.500**: A series of computer network standards regarding the decentralized directory service.
**X.509**: X.509 ITU-T certificate and CRL format. In X.509 v3 (Version 3), an extension area for holding arbitrary information has been added.
### 1.6.2 Acronyms
| **Acronym** | **Meaning** |
| ----------- | -------------------------------------------------------------- |
| AICPA | American Institute of Certified Public Accountants |
| ADN | Authorization Domain Name |
| CA | Certification Authority |
| CAA | Certification Authority Authorization |
| ccTLD | Country Code Top-Level Domain |
| CICA | Canadian Institute of Chartered Accountants |
| CP | Certificate Policy |
| CPS | Certification Practice Statement |
| CRL | Certificate Revocation List |
| DBA | Doing Business As |
| DNS | Domain Name System |
| FIPS | (US Government) Federal Information Processing Standard |
| FQDN | Fully-Qualified Domain Name |
| IM | Instant Messaging |
| IANA | Internet Assigned Numbers Authority |
| ICANN | Internet Corporation for Assigned Names and Numbers |
| ISO | International Organization for Standardization |
| NIST | (US Government) National Institute of Standards and Technology |
| OCSP | Online Certificate Status Protocol |
| OID | Object Identifier |
| PKI | Public Key Infrastructure |
| RA | Registration Authority |
| S/MIME | Secure MIME (Multipurpose Internet Mail Extensions) |
| SSL | Secure Sockets Layer |
| TLS | Transport Layer Security |
| VoIP | Voice Over Internet Protocol |
### 1.6.3 References
See [Section 1.1](#11-overview)
### 1.6.4 Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in Baseline Requirements shall be interpreted in accordance with RFC 2119.
By convention, this document omits time and timezones when listing effective requirements such as dates. Except when explicitly specified, the associated time with a date shall be 00:00:00 UTC.
# 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
The CA SHALL develop, implement, enforce, and at least once every 366 days update a CP/CPS that describes in detail how the CA implements the latest version of Baseline Requirements.
## 2.1 Repositories
The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with the CP/CPS.
## 2.2 Publication of information
The CA SHALL publicly disclose its CP/CPS through an appropriate and readily accessible online means that is available on a 24x7 basis.
The CP/CPS MUST be structured in accordance with RFC 3647 and MUST include all material required by RFC 3647.
The CA SHALL publicly give effect to Baseline Requirements and represent that it will adhere to the latest published version. The CA MAY fulfill this requirement by incorporating Baseline Requirements directly into its CP/CPS or by incorporating them by reference using a clause such as the following (which MUST include a link to the official version of Baseline Requirements):
SECOM Trust Systems conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates published at . In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document.
The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are
i. valid,
ii. revoked, and
iii. expired.
## 2.3 Time or frequency of publication
The CA shall develop, implement, enforce, and annually update the CP/CPS that describes in detail how the CA implements the latest version of [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations). The CA shall indicate conformance with [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the CP/CPS.
## 2.4 Access controls on repositories
The CA shall make its Repository publicly available in a read-only manner.
# 3. IDENTIFICATION AND AUTHENTICATION
## 3.1 Naming
### 3.1.1 Types of names
The certificate issued by the CA meets the requirements of the X.509 standard, RFC 5280 standard and Baseline Requirements, and the distinguished name assigned to the certificate holder is set according to the X.500 distinguished name format. The following information shall be included in a Certificate issued by the CA:
1. countryName shall be "JP" (uppercase letter), the two-letter ISO 3166-1 country code abbreviation for Japan.
2. organizationName shall be the name of a organization. stateOrProvinceName and localityName include the organization's local information.
**[EV TLS Server Certificates]**
The following notation shall be used in accordance with Appendix D-1 of the EV Guidelines.
- A. The Revised Hepburn method of Romanization, as well as Kunrei-shiki and Nihon-shiki methods described in ISO 3602, are acceptable for Japanese Romanizations.
- B. The CA MAY verify the Romanized transliteration, language translation (e.g. English name), or other recognized Roman-letter substitute of the Applicant's formal legal name with either a QIIS, Verified Legal Opinion, or Verified Accountant Letter.
- C. The CA MAY use the Financial Services Agency to verify a Romanized, translated, or other recognized Roman-letter substitute name. When used, the CA MUST verify that the translated English is recorded in the audited Financial Statements.
- D. When relying on Articles of Incorporation to verify a Romanized, translated, or other recognized Roman-letter substitute name, the Articles of Incorporation MUST be accompanied either: by a document, signed with the original Japanese Corporate Stamp, that proves that the Articles of Incorporation are authentic and current, or by a Verified Legal Opinion or a Verified Accountant Letter. The CA MUST verify the authenticity of the Corporate Stamp.
3. commonName is the main domain name and shall be the domain name existing in the Subject Alternative Name. All domain names are added to subjectAltName extension.
4. If the dNSName entry value in the subjectAltName extension area contains international characters other than ASCII strings, puny-code converted version of the string is used.
### 3.1.2 Need for names to be meaningful
The Subjects' names specified in Certificates shall have association with the organizations or the institutions to an appropriate extent. Subscribers shall not submit Certificate applications with third parties' trademarks or associated names to the CAs.
**[TLS Server Certificates]**
The Common Name used in a Certificate issued by the CA shall be meaningful when the hostname used in the web server DNS for which the relevant Subscriber plans to install the Certificate is assigned.
### 3.1.3 Anonymity or pseudonymity of subscribers
An anonymous or pseudonymous name may not be registered in the Certificate issued by the CA.
### 3.1.4 Rules for interpreting various name forms
DNs are interpreted as defined in [Section 3.1.1](#311-types-of-names) and [Section 3.1.2](#312-need-for-names-to-be-meaningful) hereof.
Rules concerning the interpretation of various name forms are governed by the X.500 Series DN rules.
### 3.1.5 Uniqueness of names
The CA guarantees that the issued certificate can uniquely identify the owner of the certificate by the information contained in the identification name of the Subject. The serial number of the certificate shall be the serial number including the random number generated by CSPRNG. The serial number assigned in the CA is unique.
### 3.1.6 Recognition, authentication, and role of trademarks
The CA does not verify intellectual property rights for the names indicated in Certificate applications. Subscribers may not submit any registered trademark or other trademark-related names of a third party. The CA will not arbitrate or engage itself in the resolution of any dispute between Subscribers and third parties over the registered trademark or any alike. The CA reserves the right to reject a Subscriber Certificate Application or revoke an issued Certificate due to the dispute.
## 3.2 Initial identity validation
### 3.2.1 Method to prove possession of private key
A Subscriber proves possession of the relevant Private Key in accordance with the following method.
The signature on the relevant Certificate Signing Request (hereinafter, "CSR") is authenticated to prove that said CSR is signed with the Private Key corresponding to the Public Key.
### 3.2.2 Authentication of Organization and Domain Identity
If the Applicant requests a Certificate that will contain Subject Identity Information comprised only of the `countryName` field, then the CA SHALL verify the country associated with the Subject using a verification process meeting the requirements of [Section 3.2.2.3](#3223-verification-of-country). If the Applicant requests a Certificate that will contain the countryName field and other Subject Identity Information, then the CA SHALL verify the identity of the Applicant, and the authenticity of the Applicant Representative's certificate request using a verification process meeting the requirements of this [Section 3.2.2.1](#3221-identity). The CA SHALL inspect any document relied upon under this Section for alteration or falsification.
**[EV TLS Server Certificates]**
The verification source used when issuing EV Certificates shall be disclosed at the URL below.
**[S/MIME Certificate]**
When issuing an S/MIME **on or before 2023-08-31**, the CA authenticates that it controls the email account associated with the email address registered in the certificate, or that it is authorized by the email account owner to apply on behalf of, by using the methods described below. The random value described in this section shall consist of a random number of 112 bits or more generated by the CA, and shall be effective for the use of response confirmation for 30 days from the generation.
1. The CA will refer to the registration person（Registrant）information registered in the WHOIS Registry Service in the domain under @ included in the e-mail address, and confirm that the applicant owns the domain (the applicant and the domain owner are the same organization). If the CA confirms that the domain is owned by a third-party organization, it makes sure the account is approved for use, for that the owner of the domain will submit a "domain name use consent form" stamped by the owner organization.
2. The CA confirms that the owner of the e-mail account approves the use of the account by sending a random value by e-mail to the domain contact registered in the WHOIS Registry Service and receiving an acknowledgment containing the random value.
3. Local parts should be 'admin', 'administrator', 'webmaster', 'hostmaster', or ‘postmaster', and by sending a random value to the email address created in the domain below @ included in the email address and receiving the acknowledgment containing the random value, so that CA makes sure that the owner of the email account approves the use of the account.
4. The CA confirms the control of the email account by verifying that the request token or random value is included in the contents of the file. By accessing via the approved port, the CA confirms that a random value is displayed under the "http (or https): // [domains under @ included in the email address] /.well-known/pki-validation" directory, and it receives a successful HTTP or HTTPS response from the request.
5. The CA confirms the control of the email account by verifying that there is a random value or application token in either the DNS CNAME, TXT or CAA record of any of the domains under @ contained in the email address (including the one having a prefix of label with an underscore character at the beginning).
#### 3.2.2.1 Identity
If the Subject Identity Information is to include the name or address of an organization, the CA SHALL verify the identity and address of the organization and that the address is the Applicant's address of existence or operation. The CA SHALL verify the identity and address of the Applicant using documentation provided by, or through communication with, at least one of the following:
1. A government agency in the jurisdiction of the Applicant's legal creation, existence, or recognition;
2. A third party database that is periodically updated and considered a Reliable Data Source;
3. A site visit by the CA or a third party who is acting as an agent for the CA; or
4. An Attestation Letter.
The CA MAY use the same documentation or communication described in 1 through 4 above to verify both the Applicant's identity and address.
Alternatively, the CA MAY verify the address of the Applicant (but not the identity of the Applicant) using a utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.
As a result of the examination, If SECOM Trust Systems determines that it is non-conforming, the submitted official documents will be returned or destroyed. If SECOM Trust Systems has received the application form, SECOM Trust Systems shall destroy it.
##### 3.2.2.1.1 Validating authority over mailbox via domain (S/MIME Certificates)
The CA MAY confirm the Applicant, such as an Enterprise RA, has been authorized by the email account holder to act on the account holder’s behalf by verifying the entity's control over the domain portion of the Mailbox Address to be used in the Certificate.
The CA SHALL use only the approved methods in [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) to perform this verification.
For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate.
##### 3.2.2.1.2 Validating control over mailbox via email (S/MIME Certificates)
The CA MAY confirm the Applicant's control over each Mailbox Field to be included in a Certificate by sending a Random Value via email and then receiving a confirming response utilizing the Random Value.
Control over each Mailbox Address SHALL be confirmed using a unique Random Value. The Random Value SHALL be sent only to the email address being validated and SHALL not be shared in any other way.
The Random Value SHALL be unique in each email. The Random Value SHALL remain valid for use in a confirming response for no more than 24 hours from its creation. The CA MAY specify a shorter validity period for Random Values in its CP and/or CPS.
The Random Value SHALL be reset upon each instance of the email sent by the CA to a Mailbox Address, however all relevant Random Values sent to that Mailbox Address MAY remain valid for use in a confirming response within the validity period described in this Section. In addition, the Random Value SHALL be reset upon first use by the user if intended for additional use as an authentication factor following the Mailbox Address verification.
##### 3.2.2.1.3 Validating applicant as operator of associated mail server(s) (S/MIME Certificates)
The CA MAY confirm the Applicant's control over each Mailbox Field to be included in the Certificate by confirming control of the SMTP FQDN to which a message delivered to the Mailbox Address should be directed. The SMTP FQDN SHALL be identified using the address resolution algorithm defined in [RFC 5321 Section 5.1](https://datatracker.ietf.org/doc/html/rfc5321#section-5.1) which determines which SMTP FQDNs are authoritative for a given Mailbox Address. If more than one SMTP FQDN has been discovered, the CA SHALL verify control of an SMTP FQDN following the selection process at [RFC 5321 Section 5.1](https://datatracker.ietf.org/doc/html/rfc5321#section-5.1). Aliases in MX record RDATA SHALL NOT be used for this validation method.
To confirm the Applicant's control of the SMTP FQDN, the CA SHALL use only the currently-approved methods in [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control).
#### 3.2.2.2 DBA/Tradename
If the Subject Identity Information is to include a DBA or tradename, the CA SHALL verify the Applicant's right to use the DBA/tradename using at least one of the following:
1. Documentation provided by, or communication with, a government agency in the jurisdiction of the Applicant's legal creation, existence, or recognition;
2. A Reliable Data Source;
3. Communication with a government agency responsible for the management of such DBAs or trade names;
4. An Attestation Letter accompanied by documentary support; or
5. A utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.
##### 3.2.2.2.1 Verification of Applicant's Legal Existence and Identity (EV TLS Server Certificates)
###### 3.2.2.2.1.1 Verification Requirements
To verify the Applicant's legal existence and identity, the CA MUST do the following.
1. **Private Organization Subjects**
A. **Legal Existence**: Verify that the Applicant is a legally recognized entity, in existence and validly formed (e.g., incorporated) with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration, and not designated on the records of the Incorporating or Registration Agency by labels such as "inactive", "invalid", "not current", or the equivalent.
B. **Organization Name**: Verify that the Applicant's formal legal name as recorded with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration matches the Applicant's name in the EV Certificate Request.
C. **Registration Number**: Obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Incorporation or Registration.
D. **Registered Agent**: Obtain the identity and address of the Applicant's Registered Agent or Registered Office (as applicable in the Applicant's Jurisdiction of Incorporation or Registration).
2. **Government Entity Subjects**
A. **Legal Existence**: Verify that the Applicant is a legally recognized Government Entity, in existence in the political subdivision in which such Government Entity operates.
B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request.
C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of incorporation, registration, or formation, or the identifier for the legislative act that created the Government Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is a Government Entity.
3. **Business Entity Subjects**
A. **Legal Existence**: Verify that the Applicant is engaged in business under the name submitted by the Applicant in the Application.
B. **Organization Name**: Verify that the Applicant's formal legal name as recognized by the Registration Agency in the Applicant's Jurisdiction of Registration matches the Applicant's name in the EV Certificate Request.
C. **Registration Number**: Attempt to obtain the specific unique Registration Number assigned to the Applicant by the Registration Agency in the Applicant's Jurisdiction of Registration. Where the Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Registration.
D. **Principal Individual**: Verify the identity of the identified Principal Individual.
4. **Non-Commercial Entity Subjects (International Organizations)**
A. **Legal Existence**: Verify that the Applicant is a legally recognized International Organization Entity.
B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request.
C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of formation, or the identifier for the legislative act that created the International Organization Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is an International Organization Entity.
Specifically, register the following values.
If the subscriber is as follows, the CA will set the serialNumber as follows:
| Subscriber | serialNumber |
| ------------------------------------------------------------- | ---------------------------------------------- |
| Registered corporation | Company corporation number or corporate number |
| Central ministries and national agencies | Corporate number or establishment date |
| Local governments and their institutions | Corporate number or establishment date |
| National and public universities and high school institutions | Corporate number or establishment date |
If the corporate number and establishment date cannot be confirmed by the CA, enter the following text in serialNumber.
| Subscriber | serialNumber |
| ------------------------------------------------------------- | ---------------- |
| Central ministries and national agencies | Government |
| Local governments and their institutions | Local Government |
| National and public universities and high school institutions | Public School |
If the subscriber is as follows, the CA will set the businessCategory as follows.
| Subscriber | businessCategory |
| ------------------------------------------------------------- | -------------------- |
| Registered corporation | Private Organization |
| Central ministries and national agencies | Government Entity |
| Local governments and their institutions | Government Entity |
| National and public universities and high school institutions | Government Entity |
###### 3.2.2.2.1.2 Acceptable Method of Verification
1. **Private Organization Subjects**: Unless verified under subsection (6), all items listed in [Section 3.2.2.2.1.1](#322211-verification-requirements) (1) MUST be verified directly with, or obtained directly from, the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Such verification MAY be through use of a Qualified Government Information Source operated by, or on behalf of, the Incorporating or Registration Agency, or by direct contact with the Incorporating or Registration Agency in person or via mail, e-mail, Web address, or telephone, using an address or phone number obtained directly from the Qualified Government Information Source, Incorporating or Registration Agency, or from a Qualified Independent Information Source.
2. **Government Entity Subjects**: Unless verified under subsection (6), all items listed in [Section 3.2.2.2.1.1](#322211-verification-requirements) (2) MUST either be verified directly with, or obtained directly from, one of the following:
i. a Qualified Government Information Source in the political subdivision in which such Government Entity operates;
ii. a superior governing Government Entity in the same political subdivision as the Applicant, or
iii. from a judge that is an active member of the federal, state or local judiciary within that political subdivision.
Any communication from a judge SHALL be verified in the same manner as is used for verifying factual assertions that are asserted by an Attorney as set forth in [Section 3.2.2.2.10.1](#3222101-verified-legal-opinion).
Such verification MAY be by direct contact with the appropriate Government Entity in person or via mail, e-mail, Web address, or telephone, using an address or phone number obtained from a Qualified Independent Information Source.
3. **Business Entity Subjects**: Unless verified under subsection (6), Items listed in [Section 3.2.2.2.1.1](#322211-verification-requirements) (3) (A) through (C) above, MUST be verified directly with, or obtained directly from, the Registration Agency in the Applicant's Jurisdiction of Registration. Such verification MAY be performed by means of a Qualified Government Information Source, a Qualified Governmental Tax Information Source, or by direct contact with the Registration Agency in person or via mail, e-mail, Web address, or telephone, using an address or phone number obtained directly from the Qualified Government Information Source, Qualified Governmental Tax Information Source or Registration Agency, or from a Qualified Independent Information Source. In addition, the CA MUST validate a Principal Individual associated with the Business Entity pursuant to the requirements in subsection (4), below.
4. **Principal Individual**: A Principal Individual associated with the Business Entity MUST be validated in a face-to-face setting. The CA MAY rely upon a face-to-face validation of the Principal Individual performed by the Registration Agency, provided that the CA has evaluated the validation procedure and concluded that it satisfies the requirements of the EV Guidelines for face-to-face validation procedures. Where no face-to-face validation was conducted by the Registration Agency, or the Registration Agency's face-to-face validation procedure does not satisfy the requirements of the EV Guidelines, the CA SHALL perform face-to-face validation.
A. **Face-To-Face Validation**: The face-to-face validation MUST be conducted before either an employee of the CA, a Notary (or equivalent in the Applicant's jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator:
- i. A Personal Statement that includes the following information:
1. Full name or names by which a person is, or has been, known (including all other names used);
2. Residential Address at which he/she can be located;
3. Date of birth; and
4. An affirmation that all of the information contained in the Certificate Request is true and correct.
- ii. A current signed government-issued identification document that includes a photo of the Individual and is signed by the Individual such as:
1. A passport;
2. A driver's license; or
3. A personal identification card;
- iii. At least two secondary documentary evidences to establish his/her identity that include the name of the Individual, one of which MUST be from a financial institution.
1. Acceptable financial institution documents include:
a. A major credit card, provided that it contains an expiration date and it has not expired'
b. A debit card from a regulated financial institution, provided that it contains an expiration date and it has not expired,
c. A mortgage statement from a recognizable lender that is less than six months old,
d. A bank statement from a regulated financial institution that is less than six months old.
2. Acceptable non-financial documents include:
a. Recent original utility bills or certificates from a utility company confirming the arrangement to pay for the services at a fixed address (not a mobile/cellular telephone bill),
b. A copy of a statement for payment of a lease, provided that the statement is dated within the past six months,
c. A certified copy of a birth certificate,
d. A local authority tax bill for the current year.
The Third-Party Validator performing the face-to-face validation MUST:
- i. Attest to the signing of the Personal Statement and the identity of the signer; and
- ii. Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original.
B. **Verification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a Notary (or legal equivalent in the Applicant's jurisdiction), lawyer, or accountant in the jurisdiction of the Individual's residency, and that the Third-Party Validator actually did perform the services and did attest to the signature of the Individual.
C. **Cross-checking of Information**: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that:
- i. the CA confirms their authenticity (not improperly modified when compared with the underlying original) with the Third-Party Validator; and
- ii. electronic copies of similar kinds of documents are recognized as legal substitutes for originals under the laws of the CA's jurisdiction.
5. **Non-Commercial Entity Subjects (International Organization)**: Unless verified under subsection (6), all items listed in [Section 3.2.2.2.1.1](#322211-verification-requirements) (4) MUST be verified either:
A. With reference to the constituent document under which the International Organization was formed; or
B. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or
C. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at .
D. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency.
6. The CA may rely on a Verified Professional Letter to establish the Applicant's information listed in (1)-(5) above if:
i. the Verified Professional Letter includes a copy of supporting documentation used to establish the Applicant's legal existence, such as a certificate of registration, articles of incorporation, operating agreement, statute, or regulatory act, and
ii. the CA confirms the Applicant's organization name specified in the Verified Professional Letter with a QIIS or QGIS.
##### 3.2.2.2.2 Verification of Applicant's Legal Existence and Identity – Assumed Name (EV TLS Server Certificates)
###### 3.2.2.2.2.1 Verification Requirements
If, in addition to the Applicant's formal legal name, as recorded with the applicable Incorporating Agency or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration, the Applicant's identity, as asserted in the EV Certificate, is to contain any assumed name (also known as "doing business as", "DBA", or "d/b/a" in the US, and "trading as" in the UK) under which the Applicant conducts business, the CA MUST verify that:
i. the Applicant has registered its use of the assumed name with the appropriate government agency for such filings in the jurisdiction of its Place of Business (as verified in accordance with these Guidelines), and
ii. that such filing continues to be valid.
###### 3.2.2.2.2.2 Acceptable Method of Verification
To verify any assumed name under which the Applicant conducts business:
1. The CA MAY verify the assumed name through use of a Qualified Government Information Source operated by, or on behalf of, an appropriate government agency in the jurisdiction of the Applicant's Place of Business, or by direct contact with such government agency in person or via mail, e-mail, Web address, or telephone; or
2. The CA MAY verify the assumed name through use of a Qualified Independent Information Source provided that the QIIS has verified the assumed name with the appropriate government agency.
3. The CA MAY rely on a Verified Professional Letter that indicates the assumed name under which the Applicant conducts business, the government agency with which the assumed name is registered, and that such filing continues to be valid.
##### 3.2.2.2.3 Verification of Applicant's Physical Existence (EV TLS Server Certificates)
###### 3.2.2.2.3.1 Address of Applicant's Place of Business
1. **Verification Requirements**: To verify the Applicant's physical existence and business presence, the CA MUST verify that the physical address provided by the Applicant is an address where the Applicant or a Parent/Subsidiary Company conducts business operations (not, for example, a mail drop or P.O. box, or 'care of' (C/O) address, such as an address for an agent of the Organization), and is the address of the Applicant's Place of Business.
2. **Acceptable Methods of Verification**
A. **Place of Business in the Country of Incorporation or Registration**
i. For Applicants whose Place of Business is in the same country as the Applicant's Jurisdiction of Incorporation or Registration and whose Place of Business is NOT the same as that indicated in the relevant Qualified Government Information Source used in [Section 3.2.2.2.1](#32221-verification-of-applicants-legal-existence-and-identity-ev-tls-server-certificates) to verify legal existence:
1. For Applicants listed at the same Place of Business address in the current version of either at least one QGIS (other than that used to verify legal existence), QIIS or QTIS, the CA MUST confirm that the Applicant's address, as listed in the EV Certificate Request, is a valid business address for the Applicant or a Parent/Subsidiary Company by reference to such QGIS, QIIS, or QTIS, and MAY rely on the Applicant's representation that such address is its Place of Business;
2. For Applicants who are not listed at the same Place of Business address in the current version of either at least one QIIS or QTIS, the CA MUST confirm that the address provided by the Applicant in the EV Certificate Request is the Applicant's or a Parent/Subsidiary Company's business address, by obtaining documentation of a site visit to the business address, which MUST be performed by a reliable individual or firm. The documentation of the site visit MUST:
a. Verify that the Applicant's business is located at the exact address stated in the EV Certificate Request (e.g., via permanent signage, employee confirmation, etc.),
b. Identify the type of facility (e.g., office in a commercial building, private residence, storefront, etc.) and whether it appears to be a permanent business location,
c. Indicate whether there is a permanent sign (that cannot be moved) that identifies the Applicant,
d. Indicate whether there is evidence that the Applicant is conducting ongoing business activities at the site (not that it is just, for example, a mail drop, P.O. box, etc.), and
e. Include one or more photos of
- i. the exterior of the site (showing signage indicating the Applicant's name, if present, and showing the street address if possible), AND
- ii. the interior reception area or workspace.
ii. For all Applicants, the CA MAY alternatively rely on a Verified Professional Letter that indicates the address of the Applicant's or a Parent/Subsidiary Company's Place of Business and that business operations are conducted there.
iii. For Government Entity Applicants, the CA MAY rely on the address contained in the records of the QGIS in the Applicant's jurisdiction.
iv. For Applicants whose Place of Business is in the same country as the Applicant's Jurisdiction of Incorporation or Registration and where the QGIS used in [Section 3.2.2.2.1](#32221-verification-of-applicants-legal-existence-and-identity-ev-tls-server-certificates) to verify legal existence contains a business address for the Applicant, the CA MAY rely on the address in the QGIS to confirm the Applicant's or a Parent/Subsidiary Company's address as listed in the EV Certificate Request, and MAY rely on the Applicant's representation that such address is its Place of Business.
B. **Place of Business not in the Country of Incorporation or Registration**: The CA MUST rely on a Verified Professional Letter that indicates the address of the Applicant's Place of Business and that business operations are conducted there.
##### 3.2.2.2.4 Verified Method of Communication (EV TLS Server Certificates)
###### 3.2.2.2.4.1 Verification Requirements
To assist in communicating with the Applicant and confirming that the Applicant is aware of and approves issuance, the CA MUST verify a telephone number, fax number, email address, or postal delivery address as a Verified Method of Communication with the Applicant.
###### 3.2.2.2.4.2 Acceptable Methods of Verification
To verify a Verified Method of Communication with the Applicant, the CA MUST:
A. Verify that the Verified Method of Communication belongs to the Applicant, or a Parent/Subsidiary or Affiliate of the Applicant, by matching it with one of the Applicant's Parent/Subsidiary or Affiliate's Places of Business in:
i. records provided by the applicable phone company;
ii. a QGIS, QTIS, or QIIS; or
iii. a Verified Professional Letter; and
B. Confirm the Verified Method of Communication by using it to obtain an affirmative response sufficient to enable a reasonable person to conclude that the Applicant, or a Parent/Subsidiary or Affiliate of Applicant, can be contacted reliably by using the Verified Method of Communication.
##### 3.2.2.2.5 Verification of Applicant's Operational Existence (EV TLS Server Certificates)
###### 3.2.2.2.5.1 Verification Requirements
The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under [Section 3.2.2.2.1](#32221-verification-of-applicants-legal-existence-and-identity-ev-tls-server-certificates) as verification of a Government Entity's operational existence.
###### 3.2.2.2.5.2 Acceptable Methods of Verification
To verify the Applicant's ability to engage in business, the CA MUST verify the operational existence of the Applicant, or its Affiliate/Parent/Subsidiary Company, by:
1. Verifying that the Applicant, Affiliate, Parent Company, or Subsidiary Company has been in existence for at least three years, as indicated by the records of an Incorporating Agency or Registration Agency;
2. Verifying that the Applicant, Affiliate, Parent Company, or Subsidiary Company is listed in either a current QIIS or QTIS;
3. Verifying that the Applicant, Affiliate, Parent Company, or Subsidiary Company has an active current Demand Deposit Account with a Regulated Financial Institution by receiving authenticated documentation of the Applicant's, Affiliate's, Parent Company's, or Subsidiary Company's Demand Deposit Account directly from a Regulated Financial Institution; or
4. Relying on a Verified Professional Letter to the effect that the Applicant has an active current Demand Deposit Account with a Regulated Financial Institution.
##### 3.2.2.2.6 Verification of Applicant's Domain Name (EV TLS Server Certificates)
###### 3.2.2.2.6.1 Verification Requirements
1. For each Fully-Qualified Domain Name listed in a Certificate which is not an Onion Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 3.2.2.4 of the Baseline Requirements.
SECOM Trust Systems does not issue to an Onion Domain Name.
2. **Mixed Character Set Domain Names**: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization.
##### 3.2.2.2.7 Verification of Name, Title, and Authority of Contract Signer and Certificate Approver (EV TLS Server Certificates)
###### 3.2.2.2.7.1 Verification Requirements
For both the Contract Signer and the Certificate Approver, the CA MUST verify the following.
1. **Name, Title and Agency**: The CA MUST verify the name and title of the Contract Signer and the Certificate Approver, as applicable. The CA MUST also verify that the Contract Signer and the Certificate Approver are agents representing the Applicant.
2. **Signing Authority of Contract Signer**: The CA MUST verify that the Contract Signer is authorized by the Applicant to enter into the Subscriber Agreement (and any other relevant contractual obligations) on behalf of the Applicant, including a contract that designates one or more Certificate Approvers on behalf of the Applicant.
3. **EV Authority of Certificate Approver**: The CA MUST verify, through a source other than the Certificate Approver him- or herself, that the Certificate Approver is expressly authorized by the Applicant to do the following, as of the date of the EV Certificate Request:
A. Submit, and, if applicable, authorize a Certificate Requester to submit, the EV Certificate Request on behalf of the Applicant; and
B. Provide, and, if applicable, authorize a Certificate Requester to provide, the information requested from the Applicant by the CA for issuance of the EV Certificate; and
C. Approve EV Certificate Requests submitted by a Certificate Requester.
###### 3.2.2.2.7.2 Acceptable Methods of Verification – Name, Title and Agency
Acceptable methods of verification of the name, title, and agency status of the Contract Signer and the Certificate Approver include the following.
1. **Name and Title**: The CA MAY verify the name and title of the Contract Signer and the Certificate Approver by any appropriate method designed to provide reasonable assurance that a person claiming to act in such a role is in fact the named person designated to act in such role.
2. **Agency**: The CA MAY verify the agency of the Contract Signer and the Certificate Approver by:
A. Contacting the Applicant using a Verified Method of Communication for the Applicant, and obtaining confirmation that the Contract Signer and/or the Certificate Approver, as applicable, is an employee;
B. Obtaining an Independent Confirmation From the Applicant (as described in [Section 3.2.2.2.10.4](#3222104-independent-confirmation-from-applicant)), or a Verified Professional Letter verifying that the Contract Signer and/or the Certificate Approver, as applicable, is either an employee or has otherwise been appointed as an agent of the Applicant; or
C. Obtaining confirmation from a QIIS or QGIS that the Contract Signer and/or Certificate Approver is an employee of the Applicant.
The CA MAY also verify the agency of the Certificate Approver via a certification from the Contract Signer (including in a contract between the CA and the Applicant signed by the Contract Signer), provided that the employment or agency status and Signing Authority of the Contract Signer has been verified.
###### 3.2.2.2.7.3 Acceptable Methods of Verification – Authority
Acceptable methods of verification of the Signing Authority of the Contract Signer, and the EV Authority of the Certificate Approver, as applicable, include:
1. **Verified Professional Letter**: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by reliance on a Verified Professional Letter;
2. **Corporate Resolution**: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by reliance on a properly authenticated corporate resolution that confirms that the person has been granted such Signing Authority, provided that such resolution is
i. certified by the appropriate corporate officer (e.g., secretary), and
ii. the CA can reliably verify that the certification was validly signed by such person, and that such person does have the requisite authority to provide such certification;
3. **Independent Confirmation from Applicant**: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by obtaining an Independent Confirmation from the Applicant (as described in [Section 3.2.2.2.10.4](#3222104-independent-confirmation-from-applicant));
4. **Contract between CA and Applicant**: The EV Authority of the Certificate Approver MAY be verified by reliance on a contract between the CA and the Applicant that designates the Certificate Approver with such EV Authority, provided that the contract is signed by the Contract Signer and provided that the agency and Signing Authority of the Contract Signer have been verified;
5. **Prior Equivalent Authority**: The signing authority of the Contract Signer, and/or the EV authority of the Certificate Approver, MAY be verified by relying on a demonstration of Prior Equivalent Authority.
A. Prior Equivalent Authority of a Contract Signer MAY be relied upon for confirmation or verification of the signing authority of the Contract Signer when the Contract Signer has executed a binding contract between the CA and the Applicant with a legally valid and enforceable seal or handwritten signature and only when the contract was executed more than 90 days prior to the EV Certificate application. The CA MUST record sufficient details of the previous agreement to correctly identify it and associate it with the EV application. Such details MAY include any of the following:
- i. Agreement title,
- ii. Date of Contract Signer's signature,
- iii. Contract reference number, and
- iv. Filing location.
B. Prior Equivalent Authority of a Certificate Approver MAY be relied upon for confirmation or verification of the EV Authority of the Certificate Approver when the Certificate Approver has performed one or more of the following:
- i. Under contract to the CA, has served (or is serving) as an Enterprise RA for the Applicant, or
- ii. Has participated in the approval of one or more certificate requests, for certificates issued by the CA and which are currently and verifiably in use by the Applicant.
In this case the CA MUST have contacted the Certificate Approver by phone at a previously validated phone number or have accepted a signed and notarized letter approving the certificate request.
6. **QIIS or QGIS**: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by a QIIS or QGIS that identifies the Contract Signer and/or the Certificate Approver as a corporate officer, sole proprietor, or other senior official of the Applicant.
7. **Contract Signer's Representation/Warranty**: Provided that the CA verifies that the Contract Signer is an employee or agent of the Applicant, the CA MAY rely on the signing authority of the Contract Signer by obtaining a duly executed representation or warranty from the Contract Signer that includes the following acknowledgments:
- A. That the Applicant authorizes the Contract Signer to sign the Subscriber Agreement on the Applicant's behalf,
- B. That the Subscriber Agreement is a legally valid and enforceable agreement,
- C. That, upon execution of the Subscriber Agreement, the Applicant will be bound by all of its terms and conditions,
- D. That serious consequences attach to the misuse of an EV certificate, and
- E. The contract signer has the authority to obtain the digital equivalent of a corporate seal, stamp or officer's signature to establish the authenticity of the company's Web site.
###### 3.2.2.2.7.4 Pre-Authorized Certificate Approver
Where the CA and Applicant contemplate the submission of multiple future EV Certificate Requests, then, after the CA:
1. Has verified the name and title of the Contract Signer and that he/she is an employee or agent of the Applicant; and
2. Has verified the Signing Authority of such Contract Signer in accordance with one of the procedures in [Section 3.2.2.2.7.3](#322273-acceptable-methods-of-verification--authority).
The CA and the Applicant MAY enter into a written agreement, signed by the Contract Signer on behalf of the Applicant, whereby, for a specified term, the Applicant expressly authorizes one or more Certificate Approver(s) designated in such agreement to exercise EV Authority with respect to each future EV Certificate Request submitted on behalf of the Applicant and properly authenticated as originating with, or otherwise being approved by, such Certificate Approver(s).
Such an agreement MUST provide that the Applicant shall be obligated under the Subscriber Agreement for all EV Certificates issued at the request of, or approved by, such Certificate Approver(s) until such EV Authority is revoked, and MUST include mutually agreed-upon provisions for:
i. authenticating the Certificate Approver when EV Certificate Requests are approved,
ii. periodic re-confirmation of the EV Authority of the Certificate Approver,
iii. secure procedures by which the Applicant can notify the CA that the EV Authority of any such Certificate Approver is revoked, and
iv. such other appropriate precautions as are reasonably necessary.
##### 3.2.2.2.8 Verification of Signature on Subscriber Agreement and EV Certificate Requests (EV TLS Server Certificates)
Both the Subscriber Agreement and each non-pre-authorized EV Certificate Request MUST be signed. The Subscriber Agreement MUST be signed by an authorized Contract Signer. The EV Certificate Request MUST be signed by the Certificate Requester submitting the document, unless the Certificate Request has been pre-authorized in line with [Section 3.2.2.2.7.4](#322274-pre-authorized-certificate-approver). If the Certificate Requester is not also an authorized Certificate Approver, then an authorized Certificate Approver MUST independently approve the EV Certificate Request. In all cases, applicable signatures MUST be a legally valid and contain an enforceable seal or handwritten signature (for a paper Subscriber Agreement and/or EV Certificate Request), or a legally valid and enforceable electronic signature (for an electronic Subscriber Agreement and/or EV Certificate Request), that binds the Applicant to the terms of each respective document.
###### 3.2.2.2.8.1 Verification Requirements
1. **Signature**: The CA MUST authenticate the signature of the Contract Signer on the Subscriber Agreement and the signature of the Certificate Requester on each EV Certificate Request in a manner that makes it reasonably certain that the person named as the signer in the applicable document is, in fact, the person who signed the document on behalf of the Applicant.
2. **Approval Alternative**: In cases where an EV Certificate Request is signed and submitted by a Certificate Requester who does not also function as a Certificate Approver, approval and adoption of the EV Certificate Request by a Certificate Approver in accordance with the requirements of [Section 3.2.2.2.9](#32229-verification-of-approval-of-ev-certificate-request-ev-tls-server-certificates) can substitute for authentication of the signature of the Certificate Requester on such EV Certificate Request.
###### 3.2.2.2.8.2 Acceptable Methods of Signature Verification
Acceptable methods of authenticating the signature of the Certificate Requester or Contract Signer include the following:
1. Contacting the Applicant using a Verified Method of Communication for the Applicant, for the attention of the Certificate Requester or Contract Signer, as applicable, followed by a response from someone who identifies themselves as such person confirming that he/she did sign the applicable document on behalf of the Applicant;
2. A letter mailed to the Applicant's or Agent's address, as verified through independent means in accordance with these Guidelines, for the attention of the Certificate Requester or Contract Signer, as applicable, followed by a response through a Verified Method of Communication from someone who identifies themselves as such person confirming that he/she did sign the applicable document on behalf of the Applicant;
3. Use of a signature process that establishes the name and title of the signer in a secure manner, such as through use of an appropriately secure login process that identifies the signer before signing, or through use of a digital signature made with reference to an appropriately verified certificate; or
4. Notarization by a notary, provided that the CA independently verifies that such notary is a legally qualified notary in the jurisdiction of the Certificate Requester or Contract Signer.
##### 3.2.2.2.9 Verification of Approval of EV Certificate Request (EV TLS Server Certificates)
###### 3.2.2.2.9.1 Verification Requirements
In cases where an EV Certificate Request is submitted by a Certificate Requester, before the CA issues the requested EV Certificate, the CA MUST verify that an authorized Certificate Approver reviewed and approved the EV Certificate Request.
###### 3.2.2.2.9.2 Acceptable Methods of Verification
Acceptable methods of verifying the Certificate Approver's approval of an EV Certificate Request include:
1. Contacting the Certificate Approver using a Verified Method of Communication for the Applicant and obtaining oral or written confirmation that the Certificate Approver has reviewed and approved the EV Certificate Request;
2. Notifying the Certificate Approver that one or more new EV Certificate Requests are available for review and approval at a designated access-controlled and secure Web site, followed by a login by, and an indication of approval from, the Certificate Approver in the manner required by the Web site; or
3. Verifying the signature of the Certificate Approver on the EV Certificate Request in accordance with [Section 3.2.2.2.8](#32228-verification-of-signature-on-subscriber-agreement-and-ev-certificate-requests-ev-tls-server-certificates).
##### 3.2.2.2.10 Verification of Certain Information Sources (EV TLS Server Certificates)
###### 3.2.2.2.10.1 Verified Legal Opinion
1. **Verification Requirements**: Before relying on a legal opinion submitted to the CA, the CA MUST verify that such legal opinion meets the following requirements:
A. **Status of Author**: The CA MUST verify that the legal opinion is authored by an independent legal practitioner retained by and representing the Applicant (or an in-house legal practitioner employed by the Applicant) (Legal Practitioner) who is either:
i. A lawyer (or solicitor, barrister, advocate, or equivalent) licensed to practice law in the country of the Applicant's Jurisdiction of Incorporation or Registration or any jurisdiction where the Applicant maintains an office or physical facility.
B. **Basis of Opinion**: The CA MUST verify that the Legal Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Legal Opinion are based on the Legal Practitioner's stated familiarity with the relevant facts and the exercise of the Legal Practitioner's professional judgment and expertise;
C. **Authenticity**: The CA MUST confirm the authenticity of the Verified Legal Opinion.
2. **Acceptable Methods of Verification**: Acceptable methods of establishing the foregoing requirements for a Verified Legal Opinion are:
A. **Status of Author**: The CA MUST verify the professional status of the author of the legal opinion by directly contacting the authority responsible for registering or licensing such Legal Practitioner(s) in the applicable jurisdiction;
B. **Basis of Opinion**: The text of the legal opinion MUST make it clear that the Legal Practitioner is acting on behalf of the Applicant and that the conclusions of the legal opinion are based on the Legal Practitioner's stated familiarity with the relevant facts and the exercise of the practitioner's professional judgment and expertise. The legal opinion MAY also include disclaimers and other limitations customary in the Legal Practitioner's jurisdiction, provided that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Legal Practitioner, should the legal opinion prove to be erroneous;
C. **Authenticity**: To confirm the authenticity of the legal opinion, the CA MUST make a telephone call or send a copy of the legal opinion back to the Legal Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Legal Practitioner listed with the authority responsible for registering or licensing such Legal Practitioner, and obtain confirmation from the Legal Practitioner or the Legal Practitioner's assistant that the legal opinion is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Legal Practitioner in records provided by the applicable phone company, QGIS, or QIIS.
In circumstances where the opinion is digitally signed, in a manner that confirms the authenticity of the document and the identity of the signer, as verified by the CA in [Section 3.2.2.2.10.1](#3222101-verified-legal-opinion) (2)(A), no further verification of authenticity is required.
###### 3.2.2.2.10.2 Verified Accountant Letter
1. **Verification Requirements**: Before relying on an accountant letter submitted to the CA, the CA MUST verify that such accountant letter meets the following requirements:
A. **Status of Author**: The CA MUST verify that the accountant letter is authored by an Accounting Practitioner retained or employed by the Applicant and licensed within the country of the Applicant's Jurisdiction of Incorporation, Jurisdiction of Registration, or country where the Applicant maintains an office or physical facility. Verification of license MUST be through the member organization or regulatory organization in the Accounting Practitioner's country or jurisdiction that is appropriate to contact when verifying an accountant's license to practice in that country or jurisdiction. Such country or jurisdiction must have an accounting standards body that maintains full membership status with the International Federation of Accountants.
B. **Basis of Opinion**: The CA MUST verify that the Accounting Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Accountant Letter are based on the Accounting Practitioner's stated familiarity with the relevant facts and the exercise of the Accounting Practitioner's professional judgment and expertise;
C. **Authenticity**: The CA MUST confirm the authenticity of the Verified Accountant Letter.
2. **Acceptable Methods of Verification**: Acceptable methods of establishing the foregoing requirements for a Verified Accountant Letter are listed here.
A. **Status of Author**: The CA MUST verify the professional status of the author of the accountant letter by directly contacting the authority responsible for registering or licensing such Accounting Practitioners in the applicable jurisdiction.
B. **Basis of Opinion**: The text of the Verified Accountant Letter MUST make clear that the Accounting Practitioner is acting on behalf of the Applicant and that the information in the letter is based on the Accounting Practitioner's stated familiarity with the relevant facts and the exercise of the practitioner's professional judgment and expertise. The Verified Accountant Letter MAY also include disclaimers and other limitations customary in the Accounting Practitioner's jurisdiction, provided that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Accounting Practitioner, should the Verified Accountant Letter prove to be erroneous.
C. **Authenticity**: To confirm the authenticity of the accountant's opinion, the CA MUST make a telephone call or send a copy of the Verified Accountant Letter back to the Accounting Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Accounting Practitioner listed with the authority responsible for registering or licensing such Accounting Practitioners and obtain confirmation from the Accounting Practitioner or the Accounting Practitioner's assistant that the accountant letter is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Accountant in records provided by the applicable phone company, QGIS, or QIIS.
In circumstances where the opinion is digitally signed, in a manner that confirms the authenticity of the document and the identity of the signer, as verified by the CA in [Section 3.2.2.2.10.2](#3222102-verified-accountant-letter) (2)(A), no further verification of authenticity is required.
###### 3.2.2.2.10.3 Face-to-Face Validation
1. **Verification Requirements**: Before relying on face-to-face vetting documents submitted to the CA, the CA MUST verify that the Third-Party Validator meets the following requirements:
A. **Qualification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a Notary (or legal equivalent in the Applicant's jurisdiction), Lawyer, or Accountant in the jurisdiction of the individual's residency;
B. **Document Chain of Custody**: The CA MUST verify that the Third-Party Validator viewed the Vetting Documents in a face-to-face meeting with the individual being validated;
C. **Verification of Attestation**: The CA MUST confirm the authenticity of the attestation and vetting documents.
2. **Acceptable Methods of Verification**: Acceptable methods of establishing the foregoing requirements for vetting documents are:
A. **Qualification of Third-Party Validator**: The CA MUST verify the professional status of the Third-Party Validator by directly contacting the authority responsible for registering or licensing such Third-Party Validators in the applicable jurisdiction;
B. **Document Chain of Custody**: The Third-Party Validator MUST submit a statement to the CA which attests that they obtained the Vetting Documents submitted to the CA for the individual during a face-to-face meeting with the individual;
C. **Verification of Attestation**: The CA MUST confirm the authenticity of the vetting documents received from the Third-Party Validator. The CA MUST make a telephone call to the Third-Party Validator and obtain confirmation from them or their assistant that they performed the face-to-face validation. The CA MAY rely upon self-reported information obtained from the Third-Party Validator for the sole purpose of performing this verification process. In circumstances where the attestation is digitally signed, in a manner that confirms the authenticity of the documents, and the identity of the signer as verified by the CA in [Section 3.2.2.2.10.3](#3222103-face-to-face-validation) (1)(A), no further verification of authenticity is required.
###### 3.2.2.2.10.4 Independent Confirmation From Applicant
An Independent Confirmation from the Applicant is a confirmation of a particular fact (e.g., confirmation of the employee or agency status of a Contract Signer or Certificate Approver, confirmation of the EV Authority of a Certificate Approver, etc.) that is:
A. Received by the CA from a Confirming Person (someone other than the person who is the subject of the inquiry) that has the appropriate authority to confirm such a fact, and who represents that he/she has confirmed such fact;
B. Received by the CA in a manner that authenticates and verifies the source of the confirmation; and
C. Binding on the Applicant.
An Independent Confirmation from the Applicant MAY be obtained via the following procedure:
1. **Confirmation Request**: The CA MUST initiate a Confirmation Request via an appropriate out-of-band communication, requesting verification or confirmation of the particular fact at issue as follows:
A. **Addressee**: The Confirmation Request MUST be directed to:
i. A position within the Applicant's organization that qualifies as a Confirming Person (e.g., Secretary, President, CEO, CFO, COO, CIO, CSO, Director, etc.) and is identified by name and title in a current QGIS, QIIS, QTIS, Verified Legal Opinion, Verified Accountant Letter, or by contacting the Applicant using a Verified Method of Communication; or
ii. The Applicant's Registered Agent or Registered Office in the Jurisdiction of Incorporation as listed in the official records of the Incorporating Agency, with instructions that it be forwarded to an appropriate Confirming Person; or
iii. A named individual verified to be in the direct line of management above the Contract Signer or Certificate Approver by contacting the Applicant's Human Resources Department by phone or mail (at the phone number or address for the Applicant's Place of Business, verified in accordance with these Guidelines).
B. **Means of Communication**: The Confirmation Request MUST be directed to the Confirming Person in a manner reasonably likely to reach such person. The following options are acceptable:
i. By paper mail addressed to the Confirming Person at:
- 1. The address of the Applicant's Place of Business as verified by the CA in accordance with these Guidelines, or
- 2. The business address for such Confirming Person specified in a current QGIS, QTIS, QIIS, Verified Professional Letter, or
- 3. The address of the Applicant's Registered Agent or Registered Office listed in the official records of the Jurisdiction of Incorporation, or
ii. By e-mail addressed to the Confirming Person at the business e-mail address for such person listed in a current QGIS, QTIS, QIIS, Verified Legal Opinion, or Verified Accountant Letter; or
iii. By telephone call to the Confirming Person, where such person is contacted by calling the main phone number of the Applicant's Place of Business (verified in accordance with these Guidelines) and asking to speak to such person, and a person taking the call identifies him- or herself as such person; or
iv. By facsimile to the Confirming Person at the Place of Business. The facsimile number must be listed in a current QGIS, QTIS, QIIS, Verified Legal Opinion, or Verified Accountant Letter. The cover page must be clearly addressed to the Confirming Person.
2. **Confirmation Response**: The CA MUST receive a response to the Confirmation Request from a Confirming Person that confirms the particular fact at issue. Such response MAY be provided to the CA by telephone, by e-mail, or by paper mail, so long as the CA can reliably verify that it was provided by a Confirming Person in response to the Confirmation Request.
3. The CA MAY rely on a verified Confirming Person to confirm their own contact information: email address, telephone number, and facsimile number. The CA MAY rely on this verified contact information for future correspondence with the Confirming Person if:
A. The domain of the e-mail address is owned by the Applicant and is the Confirming Person's own e-mail address and not a group e-mail alias;
B. The Confirming Person's telephone/fax number is verified by the CA to be a telephone number that is part of the organization's telephone system, and is not the personal phone number for the person.
###### 3.2.2.2.10.5 Qualified Independent Information Source
A Qualified Independent Information Source (QIIS) is a regularly-updated and publicly available database that is generally recognized as a dependable source for certain information. A database qualifies as a QIIS if the CA determines that:
1. Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and
2. The database provider updates its data on at least an annual basis.
The CA SHALL use a documented process to check the accuracy of the database and ensure its data is acceptable, including reviewing the database provider's terms of use. The CA SHALL NOT use any data in a QIIS that the CA knows is
i. self-reported and
ii. not verified by the QIIS as accurate.
Databases in which the CA or its owners or affiliated companies maintain a controlling interest, or in which any Registration Authorities or subcontractors to whom the CA has outsourced any portion of the vetting process (or their owners or affiliated companies) maintain any ownership or beneficial interest, do not qualify as a QIIS.
###### 3.2.2.2.10.6 Qualified Government Information Source
A Qualified Government Information Source (QGIS) is a regularly-updated and current, publicly available, database designed for the purpose of accurately providing the information for which it is consulted, and which is generally recognized as a dependable source of such information provided that it is maintained by a Government Entity, the reporting of data is required by law, and false or misleading reporting is punishable with criminal or civil penalties. Nothing in these Guidelines shall prohibit the use of third-party vendors to obtain the information from the Government Entity provided that the third party obtains the information directly from the Government Entity.
###### 3.2.2.2.10.7 Qualified Government Tax Information Source
A Qualified Government Tax Information Source is a Qualified Government Information Source that specifically contains tax information relating to Private Organizations, Business Entities or Individuals (e.g., the IRS in the United States).
##### 3.2.2.2.11 Other Verification Requirements (EV TLS Server Certificates)
###### 3.2.2.2.11.1 High Risk Status
The High Risk Certificate requirements of Section 4.2.1 of the Baseline Requirements apply equally to EV Certificates.
###### 3.2.2.2.11.2 Denied Lists and Other Legal Block Lists
1. **Verification Requirements**: The CA MUST verify whether the Applicant, the Contract Signer, the Certificate Approver, the Applicant's Jurisdiction of Incorporation, Registration, or Place of Business:
A. Is identified on any government denied list, list of prohibited persons, or other list that prohibits doing business with such organization or person under the laws of the country of the CA's jurisdiction(s) of operation; or
B. Has its Jurisdiction of Incorporation, Registration, or Place of Business in any country with which the laws of the CA's jurisdiction prohibit doing business.
The CA MUST NOT issue any EV Certificate to the Applicant if either the Applicant, the Contract Signer, or Certificate Approver or if the Applicant's Jurisdiction of Incorporation or Registration or Place of Business is on any such list.
2. **Acceptable Methods of Verification** The CA MUST take reasonable steps to verify with the regulations:
The CA MUST take reasonable steps to verify with all denied lists and export regulations in Japan.
###### 3.2.2.2.11.3 Parent/Subsidiary/Affiliate Relationship
A CA verifying an Applicant using information of the Applicant's Parent, Subsidiary, or Affiliate, when allowed under [Section 3.2.2.2.3.1](#322231-address-of-applicants-place-of-business), [Section 3.2.2.2.4](#32224-verified-method-of-communication-ev-tls-server-certificates), [Section 3.2.2.2.5.1](#322251-verification-requirements), or [Section 3.2.2.2.6.1](#322261-verification-requirements), MUST verify the Applicant's relationship to the Parent, Subsidiary, or Affiliate. Acceptable methods of verifying the Applicant's relationship to the Parent, Subsidiary, or Affiliate include the following:
1. QIIS or QGIS: The relationship between the Applicant and the Parent, Subsidiary, or Affiliate is identified in a QIIS or QGIS;
2. Independent Confirmation from the Parent, Subsidiary, or Affiliate: A CA MAY verify the relationship between an Applicant and a Parent, Subsidiary, or Affiliate by obtaining an Independent Confirmation from the appropriate Parent, Subsidiary, or Affiliate (as described in [Section 3.2.2.2.10.4](#3222104-independent-confirmation-from-applicant));
3. Contract between CA and Parent, Subsidiary, or Affiliate: A CA MAY verify the relationship between an Applicant and a Parent, Subsidiary, or Affiliate by relying on a contract between the CA and the Parent, Subsidiary, or Affiliate that designates the Certificate Approver with such EV Authority, provided that the contract is signed by the Contract Signer and provided that the agency and Signing Authority of the Contract Signer have been verified;
4. Verified Professional Letter: A CA MAY verify the relationship between an Applicant and a Parent, Subsidiary, or Affiliate by relying on a Verified Professional Letter; or
5. Corporate Resolution: A CA MAY verify the relationship between an Applicant and a Subsidiary by relying on a properly authenticated corporate resolution that approves creation of the Subsidiary or the Applicant, provided that such resolution is:
i. certified by the appropriate corporate officer (e.g., secretary), and
ii. the CA can reliably verify that the certification was validly signed by such person, and that such person does have the requisite authority to provide such certification.
##### 3.2.2.2.12 Final Cross-Correlation and Due Diligence (EV TLS Server Certificates)
1. The results of the verification processes and procedures outlined in these Guidelines are intended to be viewed both individually and as a group. Thus, after all of the verification processes and procedures are completed, the CA MUST have a person who is not responsible for the collection of information review all of the information and documentation assembled in support of the EV Certificate application and look for discrepancies or other details requiring further explanation.
2. The CA MUST obtain and document further explanation or clarification from the Applicant, Certificate Approver, Certificate Requester, Qualified Independent Information Sources, and/or other sources of information, as necessary, to resolve those discrepancies or details that require further explanation.
3. The CA MUST refrain from issuing an EV Certificate until the entire corpus of information and documentation assembled in support of the EV Certificate Request is such that issuance of the EV Certificate will not communicate factual information that the CA knows, or the exercise of due diligence should discover from the assembled information and documentation, to be inaccurate,. If satisfactory explanation and/or additional documentation are not received within a reasonable time, the CA MUST decline the EV Certificate Request and SHOULD notify the Applicant accordingly.
4. In the case where some or all of the documentation used to support the application is in a language other than the CA's normal operating language, the CA or its Affiliate MUST perform the requirements of this Final Cross-Correlation and Due Diligence section using employees under its control and having appropriate training, experience, and judgment in confirming organizational identification and authorization and fulfilling all qualification requirements contained in [Section 5.3.2](#532-background-check-procedures). When employees under the control of the CA do not possess the language skills necessary to perform the Final Cross-Correlation and Due Diligence a CA MAY:
A. Rely on language translations of the relevant portions of the documentation, provided that the translations are received from a Translator; or
B. When the CA has utilized the services of an RA, the CA MAY rely on the language skills of the RA to perform the Final Cross-Correlation and Due Diligence, provided that the RA complies with [Section 3.2.2.2.12](#322212-final-cross-correlation-and-due-diligence-ev-tls-server-certificates), Subsections (1), (2) and (3). Notwithstanding the foregoing, prior to issuing the EV Certificate, the CA MUST review the work completed by the RA and determine that all requirements have been met; or
C. When the CA has utilized the services of an RA, the CA MAY rely on the RA to perform the Final Cross-Correlation and Due Diligence, provided that the RA complies with this section and is subjected to the Audit Requirements of [Section 8.7](#87-self-audits) and [Section 8.2](#82-identityqualifications-of-assessor).
In the case of EV Certificates to be issued in compliance with the requirements of [Section 1.3.2](#132-registration-authorities), the Enterprise RA MAY perform the requirements of this Final Cross-Correlation and Due Diligence section.
##### 3.2.2.2.13 Requirements for Re-use of Existing Documentation (EV TLS Server Certificates)
For each EV Certificate Request, including requests to renew existing EV Certificates, the CA MUST perform all authentication and verification tasks required by these Guidelines to ensure that the request is properly authorized by the Applicant and that the information in the EV Certificate is still accurate and valid. This section sets forth the age limitations on for the use of documentation collected by the CA.
###### 3.2.2.2.13.1 Validation For Existing Subscribers
If an Applicant has a currently valid EV Certificate issued by the CA, a CA MAY rely on its prior authentication and verification of:
1. The Principal Individual verified under [Section 3.2.2.2.1.2](#322212-acceptable-method-of-verification) (4) if the individual is the same person as verified by the CA in connection with the Applicant's previously issued and currently valid EV Certificate;
2. The Applicant's Place of Business under [Section 3.2.2.2.3.1](#322231-address-of-applicants-place-of-business);
3. The Applicant's Verified Method of Communication required by [Section 3.2.2.2.4](#32224-verified-method-of-communication-ev-tls-server-certificates) but still MUST perform the verification required by [Section 3.2.2.2.4.2](#322242-acceptable-methods-of-verification) (B);
4. The Applicant's Operational Existence under [Section 3.2.2.2.5](#32225-verification-of-applicants-operational-existence-ev-tls-server-certificates);
5. The Name, Title, Agency and Authority of the Contract Signer, and Certificate Approver, under [Section 3.2.2.2.7](#32227-verification-of-name-title-and-authority-of-contract-signer-and-certificate-approver-ev-tls-server-certificates); and
6. The Applicant's right to use the specified Domain Name under [Section 3.2.2.2.6](#32226-verification-of-applicants-domain-name-ev-tls-server-certificates), provided that the CA verifies that the WHOIS record still shows the same registrant as when the CA verified the specified Domain Name for the initial EV Certificate.
###### 3.2.2.2.13.2 Re-issuance Requests
A CA may rely on a previously verified certificate request to issue a replacement certificate, so long as the certificate being referenced was not revoked due to fraud or other illegal conduct, if:
1. The expiration date of the replacement certificate is the same as the expiration date of the EV Certificate that is being replaced, and
2. The Subject Information of the Certificate is the same as the Subject in the EV Certificate that is being replaced.
###### 3.2.2.2.13.3 Age of Validated Data
1. Except for reissuance of an EV Certificate under [Section 3.2.2.2.13.2](#3222132-re-issuance-requests) and except when permitted otherwise in [Section 3.2.2.2.13.1](#3222131-validation-for-existing-subscribers), the age of all data used to support issuance of an EV Certificate (before revalidation is required) SHALL NOT exceed the following limits:
A. Legal existence and identity – 398 days;
B. Assumed name – 398 days;
C. Address of Place of Business – 398 days;
D. Verified Method of Communication – 398 days;
E. Operational existence – 398 days;
F. Domain Name – 398 days;
G. Name, Title, Agency, and Authority – 398 days, unless a contract between the CA and the Applicant specifies a different term, in which case, the term specified in such contract controls. For example, the contract MAY include the perpetual assignment of EV roles until revoked by the Applicant or CA, or until the contract expires or is terminated.
2. The 398-day period set forth above SHALL begin to run on the date the information was collected by the CA.
3. The CA MAY reuse a previously submitted EV Certificate Request, Subscriber Agreement, or Terms of Use, including use of a single EV Certificate Request in support of multiple EV Certificates containing the same Subject to the extent permitted under [Section 3.2.2.2.8](#32228-verification-of-signature-on-subscriber-agreement-and-ev-certificate-requests-ev-tls-server-certificates) and [Section 3.2.2.2.9](#32229-verification-of-approval-of-ev-certificate-request-ev-tls-server-certificates).
4. The CA MUST repeat the verification process required in these Guidelines for any information obtained outside the time limits specified above except when permitted otherwise under [Section 3.2.2.2.13.1](#3222131-validation-for-existing-subscribers).
#### 3.2.2.3 Verification of Country
If the `subject:countryName` field is present, then the CA SHALL verify the country associated with the Subject using one of the following:
a. the ccTLD of the requested Domain Name;
b. information provided by the Domain Name Registrar; or
c. a method identified in [Section 3.2.2.1](#3221-identity).
#### 3.2.2.4 Validation of Domain Authorization or Control
**[TLS Server Certificates]**
This section defines the permitted processes and procedures for validating the Applicant's ownership or control of the domain.
The CA SHALL confirm that prior to issuance, the CA has validated each Fully-Qualified Domain Name (FQDN) listed in the Certificate as follows:
The CA SHALL validate the FQDN using at least one of the methods listed below.
Completed validations of Applicant authority may be valid for the issuance of multiple Certificates over time. In all cases, the validation must have been initiated within the time period specified in the relevant requirement (such as [Section 4.2.1](#421-performing-identification-and-authentication-functions) of this document) prior to Certificate issuance. For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate.
CAs SHALL maintain a record of which domain validation method, including relevant BR version number, they used to validate every domain.
**Note**: FQDNs may be listed in Subscriber Certificates using `dNSName`s in the `subjectAltName` extension or in Subordinate CA Certificates via `dNSName`s in `permittedSubtrees` within the Name Constraints extension.
##### 3.2.2.4.1 Validating the Applicant as a Domain Contact
SECOM Trust Systems does not use this method.
##### 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact
Confirming the Applicant's control over the FQDN by sending a Random Value via email, fax, SMS, or postal mail and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to an email address, fax/SMS number, or postal mail address identified as a Domain Contact.
Each email, fax, SMS, or postal mail MAY confirm control of multiple Authorization Domain Names.
The CA MAY send the email, fax, SMS, or postal mail identified under this section to more than one recipient provided that every recipient is identified by the Domain Name Registrar as representing the Domain Name Registrant for every FQDN being verified using the email, fax, SMS, or postal mail.
The Random Value SHALL be unique in each email, fax, SMS, or postal mail.
The CA MAY resend the email, fax, SMS, or postal mail in its entirety, including re-use of the Random Value, provided that the communication's entire contents and recipient(s) remain unchanged.
The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.
**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
Effective January 15, 2025:
- When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period.
- When obtaining Domain Contact information for a requested Domain Name the CA:
- if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server.
- if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain.
- MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information.
Effective July 15, 2025:
- The CA MUST NOT rely on this method.
- Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.
##### 3.2.2.4.3 Phone Contact with Domain Contact
SECOM Trust Systems does not use this method.
##### 3.2.2.4.4 Constructed Email to Domain Contact
Confirm the Applicant's control over the FQDN by
1. Sending an email to one or more addresses created by using 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster' as the local part, followed by the at-sign ("@"), followed by an Authorization Domain Name; and
2. including a Random Value in the email; and
3. receiving a confirming response utilizing the Random Value.
Each email MAY confirm control of multiple FQDNs, provided the Authorization Domain Name used in the email is an Authorization Domain Name for each FQDN being confirmed
The Random Value SHALL be unique in each email.
The email MAY be re-sent in its entirety, including the re-use of the Random Value, provided that its entire contents and recipient SHALL remain unchanged.
The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation.
**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
##### 3.2.2.4.5 Domain Authorization Document
SECOM Trust Systems does not use this method.
##### 3.2.2.4.6 Agreed-Upon Change to Website
SECOM Trust Systems does not use this method.
##### 3.2.2.4.7 DNS Change
Confirming the Applicant's control over the FQDN by confirming the presence of a Random Value or Request Token in a DNS CNAME, TXT or CAA record for either
1. an Authorization Domain Name; or
2. an Authorization Domain Name that is prefixed with a Domain Label that begins with an underscore character.
If a Random Value is used, the CA SHALL provide a Random Value unique to the Certificate request and SHALL not use the Random Value after
1. 30 days; or
2. if the Applicant submitted the Certificate request, the time frame permitted for reuse of validated information relevant to the Certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of these Guidelines or Section 3.2.2.14.3 of the EV Guidelines).
CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. Random Value or Request Token) as the Primary Network Perspective.
**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
##### 3.2.2.4.8 IP Address
SECOM Trust Systems does not use this method.
##### 3.2.2.4.9 Test Certificate
SECOM Trust Systems does not use this method.
##### 3.2.2.4.10 TLS Using a Random Value
SECOM Trust Systems does not use this method.
##### 3.2.2.4.11 Any Other Method
SECOM Trust Systems does not use this method.
##### 3.2.2.4.12 Validating Applicant as a Domain Contact
SECOM Trust Systems does not use this method.
##### 3.2.2.4.13 Email to DNS CAA Contact
Confirming the Applicant's control over the FQDN by sending a Random Value via email and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to a DNS CAA Email Contact. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 8659, Section 3.
Each email MAY confirm control of multiple FQDNs, provided that each email address is a DNS CAA Email Contact for each Authorization Domain Name being validated. The same email MAY be sent to multiple recipients as long as all recipients are DNS CAA Email Contacts for each Authorization Domain Name being validated.
The Random Value SHALL be unique in each email. The email MAY be re-sent in its entirety, including the re-use of the Random Value, provided that its entire contents and recipient(s) SHALL remain unchanged. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same selected contact address used for domain validation as the Primary Network Perspective.
**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
##### 3.2.2.4.14 Email to DNS TXT Contact
Confirming the Applicant's control over the FQDN by sending a Random Value via email and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to a DNS TXT Record Email Contact for the Authorization Domain Name selected to validate the FQDN.
Each email MAY confirm control of multiple FQDNs, provided that each email address is DNS TXT Record Email Contact for each Authorization Domain Name being validated. The same email MAY be sent to multiple recipients as long as all recipients are DNS TXT Record Email Contacts for each Authorization Domain Name being validated.
The Random Value SHALL be unique in each email. The email MAY be re-sent in its entirety, including the re-use of the Random Value, provided that its entire contents and recipient(s) SHALL remain unchanged. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same selected contact address used for domain validation as the Primary Network Perspective.
**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
##### 3.2.2.4.15 Phone Contact with Domain Contact
SECOM Trust Systems does not use this method.
##### 3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact
SECOM Trust Systems does not use this method.
##### 3.2.2.4.17 Phone Contact with DNS CAA Phone Contact
SECOM Trust Systems does not use this method.
##### 3.2.2.4.18 Agreed-Upon Change to Website v2
Confirming the Applicant's control over the FQDN by verifying that the Request Token or Random Value is contained in the contents of a file.
1. The entire Request Token or Random Value MUST NOT appear in the request used to retrieve the file, and
2. the CA MUST receive a successful HTTP response from the request (meaning a 2xx HTTP status code must be received).
The file containing the Request Token or Random Value:
1. MUST be located on the Authorization Domain Name, and
2. MUST be located under the "/.well-known/pki-validation" directory, and
3. MUST be retrieved via either the "http" or "https" scheme, and
4. MUST be accessed over an Authorized Port.
If the CA follows redirects, the following apply:
1. Redirects MUST be initiated at the HTTP protocol layer.
a. For validations performed on or after July 1, 2021, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4), or a 308 HTTP status code response, as defined in [RFC 7538, Section 3](https://tools.ietf.org/html/rfc7538#section-3). Redirects MUST be to the final value of the Location HTTP response header, as defined in [RFC 7231, Section 7.1.2](https://tools.ietf.org/html/rfc7231#section-7.1.2).
b. For validations performed prior to July 1, 2021, redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4). CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a.
2. Redirects MUST be to resource URLs with either the "http" or "https" scheme.
3. Redirects MUST be to resource URLs accessed via Authorized Ports.
If a Random Value is used, then:
1. The CA MUST provide a Random Value unique to the certificate request.
2. The Random Value MUST remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.
Except for Onion Domain Names, CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. Random Value or Request Token) as the Primary Network Perspective.
**Note**:
- The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names.
##### 3.2.2.4.19 Agreed-Upon Change to Website - ACME
Confirming the Applicant's control over a FQDN by validating domain control of the FQDN using the ACME HTTP Challenge method defined in Section 8.3 of RFC 8555. The following are additive requirements to RFC 8555.
The CA MUST receive a successful HTTP response from the request (meaning a 2xx HTTP status code must be received).
The token (as defined in RFC 8555, Section 8.3) MUST NOT be used for more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.
If the CA follows redirects, the following apply:
1. Redirects MUST be initiated at the HTTP protocol layer.
a. For validations performed on or after July 1, 2021, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4), or a 308 HTTP status code response, as defined in [RFC 7538, Section 3](https://tools.ietf.org/html/rfc7538#section-3). Redirects MUST be to the final value of the Location HTTP response header, as defined in [RFC 7231, Section 7.1.2](https://tools.ietf.org/html/rfc7231#section-7.1.2).
b. For validations performed prior to July 1, 2021, redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4). CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a.
2. Redirects MUST be to resource URLs with either the "http" or "https" scheme.
3. Redirects MUST be to resource URLs accessed via Authorized Ports.
Except for Onion Domain Names, CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. token) as the Primary Network Perspective.
**Note**:
\* The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs separate validations for each of those other FQDNs using authorized methods. This method is NOT suitable for validating Wildcard Domain Names.
##### 3.2.2.4.20 TLS Using ALPN
SECOM Trust Systems does not use this method.
#### 3.2.2.5 Authentication for an IP Address
**[TLS Server Certificates]**
SECOM Trust Systems does not issue a certificate by authenticating the IP address.
#### 3.2.2.6 Wildcard Domain Validation
**[TLS Server Certificates]**
Before issuing a Wildcard Certificate, the CA MUST establish and follow a documented procedure that determines if the FQDN portion of any
Wildcard Domain Name in the Certificate is "registry-controlled" or is a "public suffix" (e.g. "\*.com", "\*.co.jp", see RFC 6454 Section 8.2 for further explanation).
If the FQDN portion of any Wildcard Domain Name is "registry-controlled" or is a "public suffix", CAs MUST refuse issuance unless the Applicant proves its rightful control of the entire Domain Namespace. (e.g. CAs MUST NOT issue "\*.co.jp" or "\*.local", but MAY issue "\*.example.com" to Example Co.).
Determination of what is "registry-controlled" versus the registerable portion of a Country Code Top-Level Domain Namespace is not standardized at the time of writing and is not a property of the DNS itself. Current best practice is to consult a "public suffix list" such as the [Public Suffix List (PSL)](), and to retrieve a fresh copy regularly.
If using the PSL, a CA SHOULD consult the "ICANN DOMAINS" section only, not the "PRIVATE DOMAINS" section. The PSL is updated regularly to contain new gTLDs delegated by ICANN, which are listed in the "ICANN DOMAINS" section. A CA is not prohibited from issuing a Wildcard Certificate to the Registrant of an entire gTLD, provided that control of the entire namespace is demonstrated in an appropriate way.
#### 3.2.2.7 Data Source Accuracy
Prior to using any data source as a Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification. The CA SHOULD consider the following during its evaluation:
1. The age of the information provided,
2. The frequency of updates to the information source,
3. The data provider and purpose of the data collection,
4. The public accessibility of the data availability, and
5. The relative difficulty in falsifying or altering the data.
Databases maintained by the CA, its owner, or its affiliated companies do not qualify as a Reliable Data Source if the primary purpose of the database is to collect information for the purpose of fulfilling the validation requirements under this [Section 3.2](#32-initial-identity-validation).
#### 3.2.2.8 CAA Records
**[TLS Server Certificates]**
As part of the Certificate issuance process, the CA MUST retrieve and process CAA records in accordance with RFC 8659 for each `dNSName` in the `subjectAltName` extension that does not contain an Onion Domain Name. These practices MUST be described in Section 4.2 of the CA's CP/CPS, including specifying the set of Issuer Domain Names that the CA recognizes in CAA "issue" or "issuewild" records as permitting it to issue.
Some methods relied upon for validating the Applicant's ownership or control of the subject domain(s) (see [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control)) or IP address(es) (see [Section 3.2.2.5](#3225-authentication-for-an-ip-address)) to be listed in a certificate require CAA records to be retrieved and processed from additional remote Network Perspectives before Certificate issuance (see [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration)). To corroborate the Primary Network Perspective, a remote Network Perspective's CAA check response MUST be interpreted as permission to issue, regardless of whether the responses from both Perspectives are byte-for-byte identical. Additionally, a CA MAY consider the response from a remote Network Perspective as corroborating if one or both of the Perspectives experience an acceptable CAA record lookup failure, as defined in this section.
CAs MAY check CAA records at any other time.
When processing CAA records, CAs MUST process the issue, issuewild, and iodef property tags as specified in RFC 8659, although they are not required to act on the contents of the iodef property tag. Additional property tags MAY be supported, but MUST NOT conflict with or supersede the mandatory property tags set out in this document. CAs MUST respect the critical flag and not issue a certificate if they encounter an unrecognized property tag with this flag set.
If the CA issues a certificate after processing a CAA record, it MUST do so within the TTL of the CAA record, or 8 hours, whichever is greater.
RFC 8659 requires that CAs "MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA RRset or (2) an exception specified in the relevant CP or CPS applies." For issuances conforming to these Baseline Requirements, CAs MUST NOT rely on any exceptions specified in their CP or CPS unless they are one of the following:
- CAA checking is optional for certificates for which a Certificate Transparency Precertificate (see [Section 7.1.2.9](#7129-precertificate-profile)) was created and logged in at least two public logs, and for which CAA was checked at time of Precertificate issuance.
- CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant.
CAs are permitted to treat a record lookup failure as permission to issue if:
- the failure is outside the CA's infrastructure; and
- the lookup has been retried at least once; and
- the domain's zone does not have a DNSSEC validation chain to the ICANN root.
CAs MUST document potential issuances that were prevented by a CAA record in sufficient detail to provide feedback to the CA/Browser Forum on the circumstances, and SHOULD dispatch reports of such issuance requests to the contact(s) stipulated in the CAA iodef record(s), if present. CAs are not expected to support URL schemes in the iodef record other than mailto: or https:.
The Certificate Subscribers who want to grant the authority to issue certificates to the FQDN must include the value of **``"secomtrust.net"``** in the property "issue" or “issuewild” of the CAA record for each DNS zone.
If there is already a CAA entry in each DNS zone of the Certificate Subscriber and a certificate is required to be issued by this CA, the value of **``"secomtrust.net"``** must be included in the property "issue" or “issuewild” of the CAA record.
#### 3.2.2.9 Multi-Perspective Issuance Corroboration
**[TLS Server Certificates and S/MIME Certificates]**
Multi-Perspective Issuance Corroboration attempts to corroborate the determinations (i.e., domain validation pass/fail, CAA permission/prohibition) made by the Primary Network Perspective from multiple remote Network Perspectives before Certificate issuance. This process can improve protection against equally-specific prefix Border Gateway Protocol (BGP) attacks or hijacks.
The CA MAY use either the same set, or different sets of Network Perspectives when performing Multi-Perspective Issuance Corroboration for the required 1) Domain Authorization or Control and 2) CAA Record checks.
The set of responses from the relied upon Network Perspectives MUST provide the CA with the necessary information to allow it to affirmatively assess:
- a. the presence of the expected 1) Random Value, 2) Request Token, 3) IP Address, or 4) Contact Address, as required by the relied upon validation method specified in Sections 3.2.2.4 and 3.2.2.5; and
- b. the CA's authority to issue to the requested domain(s), as specified in Section 3.2.2.8.
[Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) describes the validation methods that require the use of Multi-Perspective Issuance Corroboration and how a Network Perspective can corroborate the outcomes determined by the Primary Network Perspective.
Results or information obtained from one Network Perspective MUST NOT be reused or cached when performing validation through subsequent Network Perspectives (e.g., different Network Perspectives cannot rely on a shared DNS cache to prevent an adversary with control of traffic from one Network Perspective from poisoning the DNS cache used by other Network Perspectives). The network infrastructure providing Internet connectivity to a Network Perspective MAY be administered by the same organization providing the computational services required to operate the Network Perspective. All communications between a remote Network Perspective and the CA MUST take place over an authenticated and encrypted channel relying on modern protocols (e.g., over HTTPS).
A Network Perspective MAY use a recursive DNS resolver that is NOT co-located with the Network Perspective. However, the DNS resolver used by the Network Perspective MUST fall within the same Regional Internet Registry service region as the Network Perspective relying upon it. Furthermore, for any pair of DNS resolvers used on a Multi-Perspective Issuance Corroboration attempt, the straight-line distance between the two DNS resolvers MUST be at least 500 km. The location of a DNS resolver is determined by the point where unencapsulated outbound DNS queries are typically first handed off to the network infrastructure providing Internet connectivity to that DNS resolver.
CAs MAY immediately retry Multi-Perspective Issuance Corroboration using the same validation method or an alternative method (e.g., a CA can immediately retry validation using "Email to DNS TXT Contact" if "Agreed-Upon Change to Website - ACME" does not corroborate the outcome of Multi-Perspective Issuance Corroboration). When retrying Multi-Perspective Issuance Corroboration, CAs MUST NOT rely on corroborations from previous attempts. There is no stipulation regarding the maximum number of validation attempts that may be performed in any period of time.
The "Quorum Requirements" Table describes quorum requirements related to Multi-Perspective Issuance Corroboration. If the CA does NOT rely on the same set of Network Perspectives for both Domain Authorization or Control and CAA Record checks, the quorum requirements MUST be met for both sets of Network Perspectives (i.e.,the Domain Authorization or Control set and the CAA record check set). Network Perspectives are considered distinct when the straight-line distance between them is at least 500 km. Network Perspectives are considered "remote" when they are distinct from the Primary Network Perspective and the other Network Perspectives represented in a quorum.
A CA MAY reuse corroborating evidence for CAA record quorum compliance for a maximum of 398 days. After issuing a Certificate to a domain, remote Network Perspectives MAY omit retrieving and processing CAA records for the same domain or its subdomains in subsequent Certificate requests from the same Applicant for up to a maximum of 398 days.
Table: Quorum Requirements
| # of Distinct Remote Network Perspectives Used | # of Allowed non-Corroborations |
| ---------------------------------------------- | ------------------------------- |
| 2-5 | 1 |
| 6+ | 2 |
Remote Network Perspectives performing Multi-Perspective Issuance Corroboration:
MUST:
- Network Hardening
- Rely upon networks (e.g., Internet Service Providers or Cloud Provider Networks) implementing measures to mitigate BGP routing incidents in the global Internet routing system for providing internet connectivity to the Network Perspective.
SHOULD:
- Facility & Service Provider Requirements
- Be hosted from an ISO/IEC 27001 certified facility or equivalent security framework independently audited and certified or reported.
- Rely on services covered in one of the following reports: System and Organization Controls 2 (SOC 2), IASE 3000, ENISA 715, FedRAMP Moderate, C5:2020, CSA STAR CCM, or equivalent services framework independently audited and certified or reported.
- Vulnerability Detection and Patch Management
- Implement intrusion detection and prevention controls to protect against common network and system threats.
- Document and follow a vulnerability correction process that addresses the identification, review, response, and remediation of vulnerabilities.
- Undergo or perform a Vulnerability Scan at least every three (3) months.
- Undergo a Penetration Test on at least an annual basis.
- Apply recommended security patches within six (6) months of the security patch's availability, unless the CA documents that the security patch would introduce additional vulnerabilities or instabilities that outweigh the benefits of applying the security patch.
- System Hardening
- Disable all accounts, applications, services, protocols, and ports that are not used.
- Implement multi-factor authentication for all user accounts.
- Network Hardening
- Configure each network boundary control (firewall, switch, router, gateway, or other network control device or system) with rules that support only the services, protocols, ports, and communications identified as necessary to its operations.
- Rely upon networks (e.g., Internet Service Providers) that: 1) use mechanisms based on Secure Inter-Domain Routing (RFC 6480), for example, BGP Prefix Origin Validation (RFC 6811), 2) make use of other non-RPKI route-leak prevention mechanisms (such as RFC 9234), and 3) apply current best practices described in BCP 194. While It is RECOMMENDED that under normal operating conditions Network Perspectives performing Multi-Perspective Issuance Corroboration forward all Internet traffic via a network or set of networks that filter RPKI-invalid BGP routes as defined by RFC 6811, it is NOT REQUIRED.
Beyond the above considerations, computing systems performing Multi-Perspective Issuance Corroboration are considered outside of the audit scope described in Section 8 of Baseline Requirements.
If any of the above considerations are performed by a Delegated Third Party, the CA MAY obtain reasonable evidence from the Delegated Third Party to ascertain assurance that one or more of the above considerations are followed. As an exception to Section 1.3.2, Delegated Third Parties are not required to be within the audit scope described in Section 8 of Baseline Requirements to satisfy the above considerations.
Phased Implementation Timeline:
- *Effective 2024-09-15*, the CA SHOULD implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives.
- *Effective 2025-03-15*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MAY proceed with certificate issuance if the number of remote Network Perspectives that do not corroborate the determinations made by the Primary Network Perspective ("non-corroborations") is greater than allowed in the Quorum Requirements table.
- *Effective 2025-09-15*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate.
- *Effective 2026-03-15*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least three (3) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate.
- *Effective 2026-06-15*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least four (4) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate.
- *Effective 2026-12-15*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least five (5) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate.
### 3.2.3 Authentication of individual identity
SECOM Trust Systems does not issue Individual Validate certificates (IV certificates) that comply with the following certificate policy identifiers.
{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) individual-validated(3)} (2.23.140.1.2.3)
**[Document Signing Certificates and Client Authentication Certificates]**
SECOM Trust Systems authenticates the identity of applicants or individuals based on official documents issued by national or local governments, investigations conducted, or databases owned by third parties that SECOM Trust Systems trusts, or through other means deemed equally trustworthy by the Certification Services Improvement Committee.
An examination of an applicant and a subscriber may be performed by terms and conditions separately stipulated by SECOM Trust Systems, or a method determined by the LRA based on the SECOM Passport for PublicID LRA Operational Standards (hereinafter, ”LRA Operational Standards”)
**[AATL Document Signing Certificates]**
The following methods shall be used to issue certificates for the AATL Document Signing Certificate.
To authenticate an individual belonging to an organization, the CA shall confirm the existence of the representative or a person delegated by the representative. To authenticate official positions in the civil service, the CA shall confirm the existence of the representative or a person delegated by the representative. The representative or a person authorized by the representative shall be the one who verified the identity of the individual face-to-face and confirmed a match.
The individual identity shall be authenticated through one of the following methods:
1. Confirm the Applicant’s seal impression included with any application received in writing;
2. Verify the Applicant’s identity using official documents;
3. Performing a postal challenge/response to the Applicant using an address obtained from a reliable third party;
4. Performing a telephone challenge/response to the Applicant using a telephone number from a reliable third party;
5. Performing an email challenge/response to the Applicant using an email address from a reliable third party.
Information used for examination can be reused within the period prescribed by the CA.
#### 3.2.3.1 Attribute collection of organization identity (S/MIME Certificates)
The CA or RA SHALL collect and retain evidence supporting the following identity attributes for the Organization:
1. Formal name of the Legal Entity;
1. An address of the Legal Entity (if included in the Subject);
1. Jurisdiction of Incorporation or Registration of the Legal Entity; and
### 3.2.4 Non-verified subscriber information
The information about non-verified certificate subscribers will not be included in the certificates issued by the CA.
### 3.2.5 Validation of authority
If the Applicant for a Certificate containing Subject Identity Information is an organization, the CA SHALL use a Reliable Method of Communication to verify the authenticity of the Applicant Representative's certificate request.
The CA MAY use the sources listed in [Section 3.2.2.1](#3221-identity) to verify the Reliable Method of Communication. Provided that the CA uses a Reliable Method of Communication, the CA MAY establish the authenticity of the certificate request directly with the Applicant Representative or with an authoritative source within the Applicant's organization, such as the Applicant's main business offices, corporate offices, human resource offices, information technology offices, or other department that the CA deems appropriate.
In addition, the CA SHALL establish a process that allows an Applicant to specify the individuals who may request Certificates. If an Applicant specifies, in writing, the individuals who may request a Certificate, then the CA SHALL NOT accept any certificate requests that are outside this specification. The CA SHALL provide an Applicant with a list of its authorized certificate requesters upon the Applicant's verified written request.
**[S/MIME Certificates]**
The CA or RA SHALL use a Reliable Method of Communication to verify the authority and approval of an Applicant Representative to perform one or more of the following:
- to act as an Enterprise RA;
- to request issuance or revocation of Certificates; or
- to assign responsibilities to others to act in these roles.
The CA or RA MAY establish a process that allows an Applicant to specify the individuals who may act as Applicant Representatives on an ongoing basis. The CA SHALL provide an Applicant with a list of its authorized Applicant Representatives upon the Applicant's verified written request.
The CA or RA MAY use the sources listed in [Section 3.2.3.1](#3231-attribute-collection-of-organization-identity-smime-certificates) to verify the Reliable Method of Communication. Provided that the CA or RA uses a Reliable Method of Communication, the CA or RA MAY establish the authenticity of the Certificate Request directly with the Applicant Representative or with an authoritative source within the Applicant's organization, such as the Applicant's main business offices, corporate offices, human resource offices, information technology offices, or other department that the CA or RA deems appropriate.
### 3.2.6 Criteria for Interoperation or Certification
The CA SHALL disclose all Cross-Certified Subordinate CA Certificates that identify the CA as the Subject, provided that the CA arranged for or accepted the establishment of the trust relationship (i.e. the Cross-Certified Subordinate CA Certificate at issue).
## 3.3 Identification and authentication for re-key requests
### 3.3.1 Identification and authentication for routine re-key
Subscribers shall be identified and authenticated for Re-Keying in the same manner as set forth in [Section 3.2](#32-initial-identity-validation) hereof.
### 3.3.2 Identification and authentication for re-key after revocation
A routine Re-Key after Revocation is not supported. The (Re-Keying) application for a Certificate shall be treated as a new submission, and the applicant Subscriber shall be identified and authenticated in the same manner as set forth in [Section 3.2](#32-initial-identity-validation) hereof.
## 3.4 Identification and authentication for revocation request
Accepting the revocation request from the Subscriber or the applicant according to the prescribed procedure, the CA identifies and authenticates the Subscriber.
# 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
## 4.1 Certificate Application
### 4.1.1 Who can submit a certificate application
A person who may submit a certificate application shall be individuals, corporations, other organizations that use certificates, and agents delegated by certificate subscribers (hereinafter referred to as "Applicant").
In accordance with [Section 5.5.2](#552-retention-period-for-archive), the CA SHALL maintain an internal database of all previously revoked Certificates and previously rejected certificate requests due to suspected phishing or other fraudulent usage or concerns. The CA SHALL use this information to identify subsequent suspicious certificate requests.
**[S/MIME Certificates, Document Signing Certificates and Client Authentication Certificates]**
An application for the CA can be made by an LRA and organization that has been certified by SECOM Trust Systems based on “3.2.2 Authentication of Organization Identity”.
Applications for LRA can be made by persons specified by LRA based on the LRA operational standards.
### 4.1.2 Enrollment process and responsibilities
Prior to the issuance of a Certificate, the CA SHALL obtain the following documentation from the Applicant:
1. A certificate request, which may be electronic; and
2. An executed Subscriber Agreement or Terms of Use, which may be electronic.
The CA SHOULD obtain any additional documentation the CA determines necessary to meet [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations).
Prior to the issuance of a Certificate, the CA SHALL obtain from the Applicant a certificate request in a form prescribed by the CA and that complies with [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations). One certificate request MAY suffice for multiple Certificates to be issued to the same Applicant, subject to the aging and updating requirement in [Section 4.2.1](#421-performing-identification-and-authentication-functions), provided that each Certificate is supported by a valid, current certificate request signed by the appropriate Applicant Representative on behalf of the Applicant. The certificate request MAY be made, submitted and/or signed electronically.
The certificate request MUST contain a request from, or on behalf of, the Applicant for the issuance of a Certificate, and a certification by, or on behalf of, the Applicant that all of the information contained therein is correct.
**[S/MIME Certificates]**
Prior to the issuance of a Certificate, the CA SHALL obtain the following documentation from the Applicant:
1. A Certificate Request; and
2. An executed Subscriber Agreement and/or Terms of Use.
The Certificate Request and Subscriber Agreement or Terms of Use SHALL be in a form prescribed by the CA and SHALL comply with these Requirements including [Section 9.6.3](#963-subscriber-representations-and-warranties). The CA SHOULD obtain any additional documentation the CA determines necessary to fulfill these Requirements.
The Certificate Request SHALL contain a request from, or on behalf of, the Applicant for the issuance of a Certificate, and a certification by, or on behalf of, the Applicant that all of the information contained therein is correct.
One Certificate Request MAY suffice for multiple Certificates to be issued to the same Applicant, subject to the validation reuse periods described in [Section 4.2.1](#421-performing-identification-and-authentication-functions), provided that each Certificate is supported by a valid, current Certificate Request signed by the appropriate Applicant Representative on behalf of the Applicant.
A CA may rely on a previously verified Certificate Request to issue a replacement Certificate if:
1. The previous Certificate being referenced was not revoked;
2. The expiration date of the replacement Certificate is the same as the previous Certificate being referenced; and
3. The Subject Information of the Certificate is the same as the previous Certificate being referenced.
## 4.2 Certificate application processing
### 4.2.1 Performing identification and authentication functions
SECOM Trust Systems performs identity verification and authentication of the LRA or the organization in accordance with [Section 3.2](#32-initial-identity-validation). In applying for a certificate accepted from the LRA, the certificate presented by the LRA is verified and authenticated for the identity of the LRA.
The LRA performs identity verification and authentication based on the LRA operational standards in the manner determined by the LRA.
**[TLS Server Certificates]**
The certificate request MAY include all factual information about the Applicant to be included in the Certificate, and such additional information as is necessary for the CA to obtain from the Applicant in order to comply with Baseline Requirements and the CA's CP/CPS. In cases where the certificate request does not contain all the necessary information about the Applicant, the CA SHALL obtain the remaining information from the Applicant or, having obtained it from a reliable, independent, third-party data source, confirm it with the Applicant. The CA SHALL establish and follow a documented procedure for verifying all data requested for inclusion in the Certificate by the Applicant.
Applicant information MUST include, but not be limited to, at least one Fully-Qualified Domain Name to be included in the Certificate's `subjectAltName` extension.
[Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) limits the validity period of Subscriber Certificates. The CA MAY use the documents and data provided in [Section 3.2](#32-initial-identity-validation) to verify certificate information, or may reuse previous validations themselves, provided that the CA obtained the data or document from a source specified under [Section 3.2](#32-initial-identity-validation) or completed the validation itself no more than 825 days prior to issuing the Certificate. For validation of Domain Names according to Section 3.2.2.4, any data, document, or completed validation used MUST be obtained no more than 398 days prior to issuing the Certificate.
In no case may a prior validation be reused if any data or document used in the prior validation was obtained more than the maximum time permitted for reuse of the data or document prior to issuing the Certificate.
The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate's approval, as reasonably necessary to ensure that such requests are properly verified under Baseline Requirements.
If a Delegated Third Party fulfills any of the CA's obligations under this section , the CA SHALL verify that the process used by the Delegated Third Party to identify and further verify High Risk Certificate Requests provides at least the same level of assurance as the CA's own processes.
**[EV TLS Server Certificates]**
The following Applicant roles are required for the issuance of an EV Certificate.
1. **Certificate Requester**: The EV Certificate Request MUST be submitted by an authorized Certificate Requester. A Certificate Requester is a natural person who is either the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or a third party (such as an ISP or hosting company) that completes and submits an EV Certificate Request on behalf of the Applicant.
2. **Certificate Approver**: The EV Certificate Request MUST be approved by an authorized Certificate Approver. A Certificate Approver is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant to
i. act as a Certificate Requester and to authorize other employees or third parties to act as a Certificate Requester, and
ii. to approve EV Certificate Requests submitted by other Certificate Requesters.
3. **Contract Signer**: A Subscriber Agreement applicable to the requested EV Certificate MUST be signed by an authorized Contract Signer. A Contract Signer is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements.
4. **Applicant Representative**: In the case where the CA and the Subscriber are affiliated, Terms of Use applicable to the requested EV Certificate MUST be acknowledged and agreed to by an authorized Applicant Representative. An Applicant Representative is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to acknowledge and agree to the Terms of Use.
The Applicant MAY authorize one individual to occupy two or more of these roles. The Applicant MAY authorize more than one individual to occupy any of these roles.
**[S/MIME Certificates]**
Applicant information SHALL include, but not be limited to, at least one Mailbox Field to be included in the Certificate's `subjectAltName` extension.
[Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) limits the validity period of Subscriber Certificates.
The CA MAY reuse completed validations and/or supporting evidence performed in accordance with [Section 3.2](#32-initial-identity-validation) within the following limits:
1. **Validation of mailbox authorization or control**: Completed validation of the control of a mail server in accordance with [Section 3.2.2.1.1](#32211-validating-authority-over-mailbox-via-domain-smime-certificates) or [Section 3.2.2.1.3](#32213-validating-applicant-as-operator-of-associated-mail-servers-smime-certificates) SHALL be obtained no more than 398 days prior to issuing the Certificate.
In the event of changes to the TLS Baseline Requirements methods specified in [Section 3.2.2.1.1](#32211-validating-authority-over-mailbox-via-domain-smime-certificates), a CA MAY continue to reuse completed validations and/or supporting evidence for the period stated in this section.
Completed validation of control of a mailbox in accordance with [Section 3.2.2.1.2](#32212-validating-control-over-mailbox-via-email-smime-certificates) SHALL be obtained no more than 30 days prior to issuing the Certificate.
A prior validation SHALL NOT be reused if any data or document used in the prior validation was obtained more than the maximum time permitted for reuse of the data or document prior to issuing the Certificate.
**[Document Signing Certificate and Timestamp Certificates]**
The CA MAY reuse completed validations and/or supporting evidence performed in accordance with [Section 3.2](#32-initial-identity-validation) within the following limits:
The validation SHALL be obtained no more than 398 days prior to issuing the Certificate.
### 4.2.2 Approval or rejection of certificate applications
The CA issues a Certificate corresponding to any application that it approves, notifying the relevant Subscriber of the completion thereof and the issuance of the Certificate. In addition, it shall be possible to reject the application for a certificate in which the examination of all items is not completed adequately, and the one including the following reasons shall be rejected.
- Certificate of Applicant or Subscriber who was previously rejected or previously violated the terms of the contract
**[TLS Server Certificates]**
- CAs SHALL NOT issue certificates containing Internal Names or Reserved IP Addresses, as such names cannot be validated according to [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) or [Section 3.2.2.5](#3225-authentication-for-an-ip-address).
#### 4.2.2.1 Certification authority authorization (CAA) (S/MIME Certificates)
**[S/MIME Certificates]**
Starting on September 15, 2024 the CA SHALL state its policy or practice on processing CAA Records for Mailbox Addresses in Section 4.2 of its CP and/or CPS. That policy SHALL be consistent with these Requirements and SHALL clearly specify the set of Issuer Domain Names that the CA recognizes in CAA `issuemail` records as permitting it to issue.Starting on September 15, 2024 prior to issuing a Certificate that includes a Mailbox Address, the CA SHOULD retrieve and process CAA records in accordance with Section 4 of [RFC 9495: Certification Authority Authorization (CAA) Processing for Email Addresses](https://www.rfc-editor.org/rfc/rfc9495.html).
Starting on March 15, 2025 prior to issuing a Certificate that includes a Mailbox Address, the CA SHALL retrieve and process CAA records in accordance with Section 4 of [RFC 9495: Certification Authority Authorization (CAA) Processing for Email Addresses](https://www.rfc-editor.org/rfc/rfc9495.html).
Some methods relied upon for validating the Applicant's control over the domain portion of the Mailbox Address to be used in the Certificate (see [Section 3.2.2.1.1](#32211-validating-authority-over-mailbox-via-domain-smime-certificates) and [Section 3.2.2.1.3](#32213-validating-applicant-as-operator-of-associated-mail-servers-smime-certificates)) require CAA records to be retrieved and processed from additional remote Network Perspectives before Certificate issuance (see [Section 4.2.2.2](#4222-multi-perspective-issuance-corroboration-smime-certificates)). To corroborate the Primary Network Perspective, a remote Network Perspective's CAA check response MUST be interpreted as permission to issue, regardless of whether the responses from both Perspectives are byte-for-byte identical. Additionally, a CA MAY consider the response from a remote Network Perspective as corroborating if one or both of the Perspectives experience an acceptable CAA record lookup failure, as defined in this section.
When processing CAA records, CAs SHALL process the `issuemail` property tag as specified in RFC 9495. Additional property tags MAY be supported, but SHALL NOT conflict with or supersede the authorizations to issue S/MIME Certificates as specified in the `issuemail` property tag.
If the CA issues a Certificate following a CAA check, they SHALL do so within the TTL of the CAA record, or 8 hours, whichever is greater. This stipulation does not prevent the CA from checking CAA records at any other time.
If the Certificate includes more than one Mailbox Address, then the CA SHALL perform the above procedure for each Mailbox Address.
CAA checking is optional for Certificates issued by a Technically Constrained Subordinate CA Certificate as set out in [Section 7.1.5](#715-name-constraints), where the lack of CAA checking is an explicit contractual provision in the contract with the Technically Constrained Subordinate CA Applicant.
The CA SHALL NOT issue a Certificate unless the CA determines that Certificate Request is consistent with the applicable CAA RRset. The CA SHALL log all actions taken, if any, consistent with its CAA processing practice.
CAs are permitted to treat a record lookup failure as permission to issue if:
- the failure is outside the CA's infrastructure; and
- the lookup has been retried at least once; and
- the domain's zone does not have a DNSSEC validation chain to the ICANN root.
Subscribers who wish to be granted permission to issue S/MIME certificates must include the value **``"secomtrust.net"``** in the DNS issuemail property tag.
If the S/MIME subscribers already has a CAA entry in their DNS zone and requires certificate issuance from the CA, the issuemail property tag MUST contain the value **``"secomtrust.net"``**.
#### 4.2.2.2 Multi-perspective issuance corroboration (S/MIME Certificates)
**[S/MIME Certificates]**
CAs SHOULD implement [Section 3.2.2.9](https://github.com/cabforum/servercert/blob/main/docs/BR.md#3229-multi-perspective-issuance-corroboration) of the TLS Baseline Requirements before March 15, 2025. Effective May 15, 2025 CAs SHALL implement [Section 3.2.2.9](https://github.com/cabforum/servercert/blob/main/docs/BR.md#3229-multi-perspective-issuance-corroboration) of the TLS Baseline Requirements.
### 4.2.3 Time to process certificate applications
No stipulation.
## 4.3 Certificate issuance
### 4.3.1 CA actions during certificate issuance
#### 4.3.1.1 Manual authorization of certificate issuance for Root CAs
Certificate issuance by the Root CA SHALL require an individual authorized by the CA (i.e. the CA system operator, system officer, or PKI administrator) to deliberately issue a direct command in order for the Root CA to perform a certificate signing operation.
#### 4.3.1.2 Linting of to-be-signed Certificate content
**[TLS Server Certificates]**
Due to the complexity involved in implementing Certificate Profiles that conform to Baseline Requirements, it is considered best practice for the CA to implement a Linting process to test the technical conformity of each to-be-signed artifact prior to signing it. When a Precertificate has undergone Linting, it is not necessary for the corresponding to-be-signed Certificate to also undergo Linting, provided that the CA has a technical control to verify that the to-be-signed Certificate corresponds to the to-be-signed Precertificate in the manner described by RFC 6962, Section 3.2.
- Effective 2024-09-15, the CA SHOULD implement such a Linting process.
- Effective 2025-03-15, the CA SHALL implement such a Linting process.
**[S/MIME Certificates]**
It is considered best practice for the CA to implement a Linting process to test the technical conformity of each to-be-signed artifact prior to signing it.
- Effective 2025-03-15 the CA SHOULD implement a Linting process testing compliance with S/MIME Baseline Requirements.
- Effective 2025-09-15 the CA SHALL implement a Linting process testing compliance with S/MIME Baseline Requirements.
**[TLS Server Certificates and S/MIME Certificates]**
Methods used to produce a Certificate containing the to-be-signed Certificate content include, but are not limited to:
1. Sign the `tbsCertificate` with a "dummy" Private Key whose Public Key component is not certified by a Certificate that chains to a publicly-trusted CA Certificate; or
2. Specify a static value for the `signature` field of the Certificate ASN.1 SEQUENCE.
CAs MAY implement their own Certificate Linting tools, but CAs SHOULD use the Linting tools that have been widely adopted by the industry (see ).
#### 4.3.1.3 Linting of issued Certificates
The CA MAY use a Linting process to test each issued Certificate.
### 4.3.2 Notification to subscriber by the CA of issuance of certificate
The CA will notify the Certificate Subscriber of the issuance via the website that only the Certificate Subscriber can access, or by e-mail.
**[TLS Server Certificates]**
Some of the TLS server certificates are sometimes provided via the ACME protocol.
## 4.4 Certificate acceptance
### 4.4.1 Conduct constituting certificate acceptance
**[TLS Server Certificates and S/MIME Certificates]**
When the Subscriber downloaded the Certificate, or when the certificate sent by the Subscriber is introduced to the server by other methods, the acceptance thereof shall be deemed complete.
**[Client Authentication Certificates, Document Signing Certificates and Timestamp Certificates]**
If the CA receives a report for receipt from the LRA or the Subscriber, or if no objection is made within 14 days of the CA's distribution of the Certificate, consider that the LRA or Subscriber has received the certificate.
### 4.4.2 Publication of the certificate by the CA
The CA certificate of the CA will be published in the repository.
**[TLS Server Certificates]**
The CA can publish the certificate of the certificate subscriber by registering it in the CT (Certificate Transparency) log.
### 4.4.3 Notification of certificate issuance by the CA to other entities
The CA will not send a notice of Certificate issuance to entities other than the person in charge, who was registered at the time of the Certificate Application submission.
## 4.5 Key pair and certificate usage
### 4.5.1 Subscriber private key and certificate usage
See [Section 9.6.3](#963-subscriber-representations-and-warranties), provisions 2. and 4.
### 4.5.2 Relying party public key and certificate usage
Relying Parties shall acknowledge and agree to the provisions of this CP/CPS before using the CA Certificates.
Relying Parties may use the CA Certificates for assessment of Subscriber Certificates.
## 4.6 Certificate renewal
### 4.6.1 Circumstance for certificate renewal
Certificate renewal may be performed upon the request of the Subscriber or by the CA at its discretion.
### 4.6.2 Who may request renewal
The provisions of [Section 4.1.1 - Who can submit a certificate application](#411-who-can-submit-a-certificate-application) hereof shall apply.
### 4.6.3 Processing certificate renewal requests
The provisions of [Section 4.3.1 - CA actions during certificate issuance](#431-ca-actions-during-certificate-issuance) hereof shall apply.
### 4.6.4 Notification of new certificate issuance to subscriber
The provisions of [Section 4.3.2 - Notification to subscriber by the CA of issuance of certificate](#432-notification-to-subscriber-by-the-ca-of-issuance-of-certificate) hereof shall apply.
### 4.6.5 Conduct constituting acceptance of a renewal certificate
The provisions of [Section 4.4.1 - Conduct constituting certificate acceptance](#441-conduct-constituting-certificate-acceptance) hereof shall apply.
### 4.6.6 Publication of the renewal certificate by the CA
The provisions of [Section 4.4.2 - Publication of the certificate by the CA](#442-publication-of-the-certificate-by-the-ca) hereof shall apply.
### 4.6.7 Notification of certificate issuance by the CA to other entities
The provisions of [Section 4.4.3 - Notification of certificate issuance by the CA to other entities](#443-notification-of-certificate-issuance-by-the-ca-to-other-entities) hereof shall apply.
## 4.7 Certificate re-key
### 4.7.1 Circumstance for certificate re-key
A Certificate is Re-Keyed when the validity period of the Certificate is about to expire or when the Certificate is revoked due to the key compromise.
### 4.7.2 Who may request certification of a new public key
The provisions of [Section 4.1.1 - Who can submit a certificate application](#411-who-can-submit-a-certificate-application) hereof shall apply.
### 4.7.3 Processing certificate re-keying requests
The provisions of [Section 4.3.1 - CA actions during certificate issuance](#431-ca-actions-during-certificate-issuance) hereof shall apply.
### 4.7.4 Notification of new certificate issuance to subscriber
The provisions of [Section 4.3.2 - Notification to subscriber by the CA of issuance of certificate](#432-notification-to-subscriber-by-the-ca-of-issuance-of-certificate) hereof shall apply.
### 4.7.5 Conduct constituting acceptance of a re-keyed certificate
The provisions of [Section 4.4.1 - Conduct constituting certificate acceptance](#441-conduct-constituting-certificate-acceptance) hereof shall apply.
### 4.7.6 Publication of the re-keyed certificate by the CA
The provisions of [Section 4.4.2 - Publication of the certificate by the CA](#442-publication-of-the-certificate-by-the-ca) hereof shall apply.
### 4.7.7 Notification of certificate issuance by the CA to other entities
The provisions of [Section 4.4.3 - Notification of certificate issuance by the CA to other entities](#443-notification-of-certificate-issuance-by-the-ca-to-other-entities) hereof shall apply.
## 4.8 Certificate modification
### 4.8.1 Circumstance for certificate modification
Certificate modification may be performed upon the request of the Subscriber or by CA at its discretion.
### 4.8.2 Who may request certificate modification
The provisions of [Section 4.9.2](#492-who-can-request-revocation) and [Section 4.1.1](#411-who-can-submit-a-certificate-application) hereof shall apply.
### 4.8.3 Processing certificate modification requests
The provisions of [Section 4.3.1 - CA actions during certificate issuance](#431-ca-actions-during-certificate-issuance) hereof shall apply.
### 4.8.4 Notification of new certificate issuance to subscriber
The provisions of [Section 4.3.2 - Notification to subscriber by the CA of issuance of certificate](#432-notification-to-subscriber-by-the-ca-of-issuance-of-certificate) hereof shall apply.
### 4.8.5 Conduct constituting acceptance of modified certificate
The provisions of [Section 4.4.1 - Conduct constituting certificate acceptance](#441-conduct-constituting-certificate-acceptance) hereof shall apply.
### 4.8.6 Publication of the modified certificate by the CA
The provisions of [Section 4.4.2 - Publication of the certificate by the CA](#442-publication-of-the-certificate-by-the-ca) hereof shall apply.
### 4.8.7 Notification of certificate issuance by the CA to other entities
The provisions of [Section 4.4.3 - Notification of certificate issuance by the CA to other entities](#443-notification-of-certificate-issuance-by-the-ca-to-other-entities) hereof shall apply.
## 4.9 Certificate revocation and suspension
### 4.9.1 Circumstances for revocation
#### 4.9.1.1 Reasons for Revoking a Subscriber Certificate
**[TLS Server Certificates]**
The CA MAY support revocation of Short-lived Subscriber Certificates.
With the exception of Short-lived Subscriber Certificates, the CA SHALL revoke a Certificate within 24 hours and use the corresponding CRLReason (see [Section 7.2.2](#722-crl-and-crl-entry-extensions)) if one or more of the following occurs:
1. The Subscriber requests in writing, without specifying a CRLreason, that the CA revoke the Certificate (CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL);
2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization (CRLReason #9, privilegeWithdrawn);
3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise (CRLReason #1, keyCompromise);
4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate, including but not limited to those identified in [Section 6.1.1.3(5)](#6113-subscriber-key-pair-generation) (CRLReason #1, keyCompromise);
5. The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon (CRLReason #4, superseded).
With the exception of Short-lived Subscriber Certificates, the CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days and use the corresponding CRLReason (see [Section 7.2.2](#722-crl-and-crl-entry-extensions)) if one or more of the following occurs:
6. The Certificate no longer complies with the requirements of [Section 6.1.5](#615-key-sizes) and [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking) (CRLReason #4, superseded);
7. The CA obtains evidence that the Certificate was misused (CRLReason #9, privilegeWithdrawn);
8. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use (CRLReason #9, privilegeWithdrawn);
9. The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrant's right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name) (CRLReason #5, cessationOfOperation);
10. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name (CRLReason #9, privilegeWithdrawn);
11. The CA is made aware of a material change in the information contained in the Certificate (CRLReason #9, privilegeWithdrawn);
12. The CA is made aware that the Certificate was not issued in accordance with Baseline Requirements or the CA's Certificate Policy or Certification Practice Statement (CRLReason #4, superseded);
13. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate (CRLReason #9, privilegeWithdrawn);
14. The CA's right to issue Certificates under Baseline Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository (CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL);
15. Revocation is required by the CA's CP/CPS for a reason that is not otherwise required to be specified by this section 4.9.1.1 (CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL); or
16. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed (CRLReason #1, keyCompromise).
**[S/MIME Certificates]**
The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:
1. The Subscriber requests in writing that the CA revoke the Certificate;
2. The Subscriber notifies the CA that the original Certificate Request was not authorized and does not retroactively grant authorization;
3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise;
4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate (such as a Debian weak key, see );
5. The CA obtains evidence that the validation of domain authorization or mailbox control for any Mailbox Address in the Certificate should not be relied upon.
The CA SHOULD revoke a Certificate within 24 hours and SHALL revoke a Certificate within 5 days if one or more of the following occurs:
6. The Certificate no longer complies with the requirements of [Section 6.1.5](#615-key-sizes) and [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking);
7. The CA obtains evidence that the Certificate was misused;
8. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use;
9. The CA is made aware of any circumstance indicating that use of an email address or Fully-Qualified Domain Name in the Certificate is no longer legally permitted (e.g., a court or arbitrator has revoked the right to use an email address or Domain Name, a relevant licensing or services agreement between the Subscriber has terminated, or the account holder has failed to maintain the active status of the email address or Domain Name);
10. The CA is made aware of a material change in the information contained in the Certificate;
11. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA's CP and/or CPS;
12. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate;
13. The CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository;
14. Revocation is required by the CA's CP and/or CPS; or
15. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed.
**[Code Signing Certificates]**
The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:
1. The Subscriber requests in writing that the CA revoke the Certificate;
2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization;
3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise;
4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate;
5. The CA is made aware of a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed; or
6. The CA has reasonable assurance that a Certificate was used to sign Suspect Code.
The CA SHOULD revoke a certificate within 24 hours and SHALL revoke a Certificate within 5 days if one or more of the following occurs:
7. The Certificate no longer complies with the requirements of Section 6.1.5 and Section 6.1.6;
8. The CA obtains evidence that the Certificate was misused.
9. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use.
10. The CA is made aware of a material change in the information contained in the Certificate.
11. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA's Certificate Policy or Certification Practice Statement.
12. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate.
13. The CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository.
14. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement.
The CA MAY delay revocation based on a request from Application Software Suppliers where immediate revocation has a potentially large negative impact to the ecosystem.
**[Client Authentication Certificates, Document Signing Certificates and Timestamp Certificates]**
The CA SHALL revoke a Certificate if one or more of the following occurs:
1. The Subscriber requests in writing that the CA revoke the Certificate;
2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization;
3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise;
4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate;
5. The CA is made aware of a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed; or
6. The Certificate no longer complies with the requirements of Section 6.1.5 and Section 6.1.6;
7. The CA obtains evidence that the Certificate was misused.
8. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use.
9. The CA is made aware of a material change in the information contained in the Certificate.
10. The CA is made aware that the Certificate was not issued in accordance with [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) or the CA's Certificate Policy or Certification Practice Statement.
11. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate.
12. The CA's right to issue Certificates under [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository.
13. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement.
#### 4.9.1.2 Reasons for Revoking a Subordinate CA Certificate
The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs:
1. The Subordinate CA requests revocation in writing;
2. The Subordinate CA notifies the Issuing CA that the original certificate request was not authorized and does not retroactively grant authorization;
3. The Issuing CA obtains evidence that the Subordinate CA's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of [Section 6.1.5](#615-key-sizes) and [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking);
4. The Issuing CA obtains evidence that the Certificate was misused;
5. The Issuing CA is made aware that the Certificate was not issued in accordance with or that Subordinate CA has not complied with this document or the applicable Certificate Policy or Certification Practice Statement;
6. The Issuing CA determines that any of the information appearing in the Certificate is inaccurate or misleading;
7. The Issuing CA or Subordinate CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate;
8. The Issuing CA's or Subordinate CA's right to issue Certificates under [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) expires or is revoked or terminated, unless the Issuing CA has made arrangements to continue maintaining the CRL/OCSP Repository; or
9. Revocation is required by the Issuing CA's CP/CPS.
### 4.9.2 Who can request revocation
The Subscriber, RA, or Issuing CA can initiate revocation. Additionally, Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate.
### 4.9.3 Procedure for revocation request
The CA SHALL provide a process for Subscribers to request revocation of their own Certificates.
The Subscriber submits a revocation request for the Subscriber certificate to the CA according to the prescribed procedure. For the certificates requested and issued by the LRA, a revocation request for a Subscriber certificate shall be made by the method determined by the LRA based on the LRA operational standards. LRA accesses the site provided by SECOM Trust Systems using the LRA certificate, and applies for revocation of the Subscriber certificate to the CA.
The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports.
The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in [Section 1.5.2](#152-contact-person) of their CPS.
### 4.9.4 Revocation request grace period
Actual revocation timelines depend on the reasons for revocation as described in this [section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate) and [section 4.9.1.2](#4912-reasons-for-revoking-a-subordinate-ca-certificate).
### 4.9.5 Time within which CA must process the revocation request
Within 24 hours after receiving a Certificate Problem Report, the CA SHALL investigate the facts and circumstances related to a Certificate Problem Report and provide a preliminary report on its findings to both the Subscriber and the entity who filed the Certificate Problem Report.
After reviewing the facts and circumstances, the CA SHALL work with the Subscriber and any entity reporting the Certificate Problem Report or other revocation-related notice to establish whether or not the certificate will be revoked, and if so, a date which the CA will revoke the certificate. The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation MUST NOT exceed the time frame set forth in [Section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate). The date selected by the CA SHOULD consider the following criteria:
1. The nature of the alleged problem (scope, context, severity, magnitude, risk of harm);
2. The consequences of revocation (direct and collateral impacts to Subscribers and Relying Parties);
3. The number of Certificate Problem Reports received about a particular Certificate or Subscriber;
4. The entity making the complaint (for example, a complaint from a law enforcement official that a Web site is engaged in illegal activities should carry more weight than a complaint from a consumer alleging that they didn't receive the goods they ordered); and
5. Relevant legislation.
### 4.9.6 Revocation checking requirement for relying parties
Relying parties should check the revocation status of all certificates that contain a CRL Distribution Point or OCSP pointer.
### 4.9.7 CRL issuance frequency
CRLs MUST be available via a publicly-accessible HTTP URL (i.e., "published").
**[TLS Server Certificates]**
Within twenty-four (24) hours of issuing its first Certificate, the CA MUST generate and publish either:
- a full and complete CRL; OR
- partitioned (i.e., "sharded") CRLs that, when aggregated, represent the equivalent of a full and complete CRL.
CAs issuing Subscriber Certificates:
1. MUST update and publish a new CRL at least every:
- seven (7) days if all Certificates include an authorityInformationAccess extension with an id-ad-ocsp accessMethod ("AIA OCSP pointer"); or
- four (4) days in all other cases;
2. MUST update and publish a new CRL within twenty-four (24) hours after recording a Certificate as revoked.
**[Client Authentication Certificates, S/MIME Certificates, Code Signing Certificates, Document Signing Certificates and Timestamp Certificates]**
For the status of Subscriber Certificates: the CA SHALL update and reissue CRLs at least once every seven days, and the value of the `nextUpdate` field SHALL NOT be more than ten days beyond the value of the `thisUpdate` field.
**[Common to all certificates]**
CAs issuing CA Certificates:
1. MUST update and publish a new CRL at least every twelve (12) months;
2. MUST update and publish a new CRL within twenty-four (24) hours after recording a Certificate as revoked.
CAs MUST continue issuing CRLs until one of the following is true:
- all Subordinate CA Certificates containing the same Subject Public Key are expired or revoked; OR
- the corresponding Subordinate CA Private Key is destroyed.
### 4.9.8 Maximum latency for CRLs (if applicable)
For the Root CA, a new CRL is issued and published in the Repository within 24 hours after issuance.
The CRLs issued by the CA will be reflected onto the repository within a reasonable time.
### 4.9.9 On-line revocation/status checking availability
The validity interval of an OCSP response is the difference in time between the `thisUpdate` and `nextUpdate` field, inclusive. For purposes of computing differences, a difference of 3,600 seconds shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day, ignoring leap-seconds.
A certificate serial is "assigned" if:
- a Certificate or Precertificate with that serial number has been issued by the Issuing CA; or
- a Precertificate with that serial number has been issued by a Precertificate Signing Certificate, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile), associated with the Issuing CA.
A certificate serial is "unassigned" if it is not "assigned".
The following SHALL apply for communicating the status of Certificates and Precertificates which include an authorityInformationAccess extension with an id-ad-ocsp accessMethod.
OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019. The CA MAY process the Nonce extension (`1.3.6.1.5.5.7.48.1.2`) in accordance with RFC 8954.
For the status of a Subscriber Certificate or its corresponding Precertificate:
- Effective 2025-01-15, an authoritative OCSP response MUST be available (i.e. the responder MUST NOT respond with the "unknown" status) starting no more than 15 minutes after the Certificate or Precertificate is first published or otherwise made available. **[TLS Server Certificates]**
- For OCSP responses with validity intervals less than sixteen hours, the CA SHALL provide an updated OCSP response prior to one-half of the validity period before the nextUpdate.
- For OCSP responses with validity intervals greater than or equal to sixteen hours, the CA SHALL provide an updated OCSP response at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate.
For the status of a Subordinate CA Certificate, the CA SHALL provide an updated OCSP response at least every twelve months, and within 24 hours after revoking the Certificate.
The following SHALL apply for communicating the status of *all* Certificates for which an OCSP responder is willing or required to respond.
OCSP responses MUST conform to RFC 6960 and/or RFC 5019. OCSP responses MUST either:
1. be signed by the CA that issued the Certificates whose revocation status is being checked, or
2. be signed by an OCSP Responder which complies with the OCSP Responder Certificate Profile in [Section 7.1.2.8](#7128-ocsp-responder-certificate-profile).
OCSP responses for Subscriber Certificates MUST have a validity interval greater than or equal to eight hours and less than or equal to ten days.
If the OCSP responder receives a request for the status of a certificate serial number that is "unassigned", then the responder SHOULD NOT respond with a "good" status. If the OCSP responder is for a CA that is not Technically Constrained in line with [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), the responder MUST NOT respond with a "good" status for such requests.
### 4.9.10 On-line revocation checking requirements
No Stipulation.
### 4.9.11 Other forms of revocation advertisements available
The CA allows the subscribers to use OCSP stapling in accordance with RFC4366 (Transport Layer Security (TLS) Extensions), RFC 5246 (The Transport Layer Security (TLS) Protocol Version 1.2), RFC 8446 (The Transport Layer Security (TLS) Protocol Version 1.3).
### 4.9.12 Special requirements re key compromise
See [Section 4.9.1](#491-circumstances-for-revocation).
### 4.9.13 Circumstances for suspension
The Repository MUST NOT include entries that indicate that a Certificate is suspended.
See [Section 7.2.2](#722-crl-and-crl-entry-extensions) for restrictions on use of suspension.
### 4.9.14 Who can request suspension
Not applicable.
### 4.9.15 Procedure for suspension request
Not applicable.
### 4.9.16 Limits on suspension period
Not applicable.
## 4.10 Certificate status services
### 4.10.1 Operational characteristics
Revocation entries on a CRL or OCSP Response MUST NOT be removed until after the Expiry Date of the revoked Certificate.
**[Code Signing Certificates]**
Revocation information shall be confirmed for at least 10 years after the expiration date.
### 4.10.2 Service availability
The CA SHALL operate and maintain its CRL and optional OCSP capability with resources sufficient to provide a response time of ten seconds or less under normal operating conditions.
The CA SHALL maintain an online 24x7 Repository that application software can use to automatically check the current status of all unexpired Certificates issued by the CA.
The CA SHALL maintain a continuous 24x7 ability to respond internally to a high-priority Certificate Problem Report, and where appropriate, forward such a complaint to law enforcement authorities, and/or revoke a Certificate that is the subject of such a complaint.
### 4.10.3 Optional features
No stipulation.
## 4.11 End of subscription
In terminating subscription of the Services, Subscribers are required to proceed with the service subscription termination procedure set forth in the relevant agreement therefor or the like.
Subscribers shall submit a Certificate Revocation Request when ending the certificate use. It will also end if they do not apply for the renewal of the certificate and the validity period of the corresponding certificate has expired.
## 4.12 Key escrow and recovery
### 4.12.1 Key escrow and recovery policy and practices
The CA does not Escrow Subscriber Private Keys.
### 4.12.2 Session key encapsulation and recovery policy and practices
Not applicable.
# 5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS
The CA SHALL develop, implement, and maintain a comprehensive security program designed to:
1. Protect the confidentiality, integrity, and availability of Certificate Data and Certificate Management Processes;
2. Protect against anticipated threats or hazards to the confidentiality, integrity, and availability of the Certificate Data and Certificate Management Processes;
3. Protect against unauthorized or unlawful access, use, disclosure, alteration, or destruction of any Certificate Data or Certificate Management Processes;
4. Protect against accidental loss or destruction of, or damage to, any Certificate Data or Certificate Management Processes; and
5. Comply with all other security requirements applicable to the CA by law.
The Certificate Management Process MUST include:
1. physical security and environmental controls;
2. system integrity controls, including configuration management, integrity maintenance of trusted code, and malware detection/prevention;
3. network security and firewall management, including port restrictions and IP address filtering;
4. user management, separate trusted-role assignments, education, awareness, and training; and
5. logical access controls, activity logging, and inactivity time-outs to provide individual accountability.
The CA's security program MUST include an annual Risk Assessment that:
1. Identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes;
2. Assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and
3. Assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.
Based on the Risk Assessment, the CA SHALL develop, implement, and maintain a security plan consisting of security procedures, measures, and products designed to achieve the objectives set forth above and to manage and control the risks identified during the Risk Assessment, commensurate with the sensitivity of the Certificate Data and Certificate Management Processes. The security plan MUST include administrative, organizational, technical, and physical safeguards appropriate to the sensitivity of the Certificate Data and Certificate Management Processes. The security plan MUST also take into account then-available technology and the cost of implementing the specific measures, and SHALL implement a reasonable level of security appropriate to the harm that might result from a breach of security and the nature of the data to be protected.
## 5.1 Physical Security Controls
### 5.1.1 Site location and construction
The CA has its certification infrastructure system installed within a secure data center. The data center is constructed on a premise hardly vulnerable to water exposures, earthquakes, fires or any other disasters, while structural measures have also been implemented to prevent and protect against such disasters.
### 5.1.2 Physical access
The CA implements appropriate security controls, combining physical and electronic access controls according to the critical level of the certification infrastructure system. In addition, access to the certification infrastructure systems is monitored through the installed surveillance cameras and other sensors.
### 5.1.3 Power and air conditioning
The data center is equipped with uninterruptible power supplies and backup generators as a measure of securing the power supply to enable uninterrupted operation of the certification infrastructure systems even during momentary or extended power outages. Additionally, the systems are installed in an air-conditioned environment where optimum temperature and humidity can be maintained constantly using air conditioners.
### 5.1.4 Water exposures
The CA installs the certification infrastructure systems on the second or a higher floor of the building for the flood control purpose, also deploying the water leakage sensors in the rooms housing the systems for protection against other water exposures.
### 5.1.5 Fire prevention and protection
The rooms in which the certification infrastructure systems are installed are fireproof compartments partitioned off by firewalls and equipped with fire alarms as well as fire extinguishing equipment.
### 5.1.6 Media storage
The CA stores archive, backup and other data and information critical to the performance of the certification services in a vault inside a room with proper access controls, deploying the measures to prevent potential damage and loss.
### 5.1.7 Waste disposal
The CA initializes and/or shreds sensitive paper documents and electronic media containing confidential information before disposal.
### 5.1.8 Off-site backup
The CA implements measures for remote storage and retrieval/procurement of the data, equipment, and any other items required to operate the certification infrastructure systems.
## 5.2 Procedural controls
### 5.2.1 Trusted roles
The CA defines the roles necessary for the operation of its certification infrastructure systems as follows:
1. Person Responsible for Services
- Manages the Digital Certification Infrastructure.
- Approves modifications/revisions of the certification infrastructure systems and operational procedures.
2. Service Operation Manager
- Gives work instructions to person(s) in charge of operation.
- Observes CA Private Key operations on site.
- Manages overall service operations.
3. CA Administrator
- Maintains and manages CA servers, repository servers and other certification infrastructure systems.
- Conducts activation and deactivation of CA Private Keys.
4. Person in Charge of RA
- Controls registration and removal of the information of the customers performing the RA services using the certification infrastructure systems.
- Performs the RA services for CAs operating under the services provided by SECOM Trust Systems through the certification infrastructure systems.
### 5.2.2 Number of Individuals Required per Task
The CA Private Key SHALL be backed up, stored, and recovered only by personnel in Trusted Roles using, at least, dual control in a physically secured environment.
With the exception of Service Operation Manager, SECOM Trust Systems deploys at least two persons performing the roles listed in [Section 5.2.1](#521-trusted-roles) hereof to avoid disruptions in the provision of services.
Critical operations, such as those related to the CA Private Key, are jointly performed by at least two persons.
### 5.2.3 Identification and authentication for each role
With regard to any access to the certification infrastructure systems, SECOM Trust Systems shall conduct identification and authentication of the access-permitted individuals as well as the validity of the access to be an authorized action, through physical or logical means.
### 5.2.4 Roles requiring separation of duties
As a general rule, individual roles listed in [Section 5.2.1](#521-trusted-roles) hereof are performed by independent personnel.
A Service Operation Manager may concurrently serve as a Log Examiner.
**[EV TLS Server Certificates]**
1. The CA MUST enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the issuance of an EV Certificate. The Final Cross-Correlation and Due Diligence steps, as outlined in [Section 3.2.2.2.12](#322212-final-cross-correlation-and-due-diligence-ev-tls-server-certificates), MAY be performed by one of the persons. For example, one Validation Specialist MAY review and verify all the Applicant information and a second Validation Specialist MAY approve issuance of the EV Certificate.
2. Such controls MUST be auditable.
## 5.3 Personnel controls
### 5.3.1 Qualifications, experience, and clearance requirements
Prior to the engagement of any person in the Certificate Management Process, whether as an employee, agent, or an independent contractor of the CA, the CA SHALL verify the identity and trustworthiness of such person.
### 5.3.2 Background check procedures
SECOM Trust Systems assesses the reliability and suitability of the individuals responsible for the roles listed in [Section 5.2.1](#521-trusted-roles) hereof at the time of appointment and on a regular basis thereafter.
**[EV TLS Server Certificates]**
Prior to the commencement of employment of any person by the CA for engagement in the EV Processes, whether as an employee, agent, or an independent contractor of the CA, the CA MUST:
1. **Verify the Identity of Such Person**: Verification of identity MUST be performed through:
A. The personal (physical) presence of such person before trusted persons who perform human resource or security functions, and
B. The verification of well-recognized forms of government-issued photo identification (e.g., passports and/or drivers licenses);
and
2. **Verify the Trustworthiness of Such Person**: Verification of trustworthiness SHALL include background checks, which address at least the following, or their equivalent:
A. Confirmation of previous employment,
B. Check of professional references;
C. Confirmation of the highest or most-relevant educational qualification obtained;
and
3. In the case of employees already in the employ of the CA at the time of adoption of EV Guidelines whose identity and background has not previously been verified as set forth above, the CA SHALL conduct such verification within three months of the date of adoption of EV Guidelines.
### 5.3.3 Training Requirements and Procedures
The CA SHALL provide all personnel performing information verification duties with skills-training that covers basic Public Key Infrastructure knowledge, authentication and vetting policies and procedures (including the CA's CP/CPS), common threats to the information verification process (including phishing and other social engineering tactics), and Baseline Requirements.
The CA SHALL maintain records of such training and ensure that personnel entrusted with Validation Specialist duties maintain a skill level that enables them to perform such duties satisfactorily.
The CA SHALL document that each Validation Specialist possesses the skills required by a task before allowing the Validation Specialist to perform that task.
The CA SHALL require all Validation Specialists to pass an examination provided by the CA on the information verification requirements outlined in Baseline Requirements.
### 5.3.4 Retraining frequency and requirements
All personnel in Trusted roles SHALL maintain skill levels consistent with the CA's training and performance programs.
The CA provides the individuals responsible for the roles listed in [Section 5.2.1](#521-trusted-roles) hereof with refresher training as needed.
### 5.3.5 Job rotation frequency and sequence
The CA conducts job rotations of the personnel for the purpose of securing service quality consistency and improvement as well as prevention of misconducts.
### 5.3.6 Sanctions for unauthorized actions
The provisions concerning penalties set forth in SECOM Trust Systems Rules of Employment apply.
### 5.3.7 Independent Contractor Controls
The CA SHALL verify that the Delegated Third Party's personnel involved in the issuance of a Certificate meet the training and skills requirements of [Section 5.3.3](#533-training-requirements-and-procedures) and the document retention and event logging requirements of [Section 5.4.1](#541-types-of-events-recorded).
When the CA may employ independent contractors for operations of the certification infrastructure systems in whole or in part, the company ensures through the agreements therewith that the operational duties are duly performed by the contractors.
### 5.3.8 Documentation supplied to personnel
The CA permits the personnel's access only to the documents necessary for the performance of relevant duties.
## 5.4 Audit logging procedures
### 5.4.1 Types of events recorded
The CA and each Delegated Third Party SHALL record events related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems. The CA and each Delegated Third Party SHALL record events related to their actions taken to process a certificate request and to issue a Certificate, including all information generated and documentation received in connection with the certificate request; the time and date; and the personnel involved. The CA SHALL make these records available to its Qualified Auditor as proof of the CA’s compliance with Baseline Requirements.
The CA SHALL record at least the following events:
1. CA certificate and key lifecycle events, including:
1. Key generation, backup, storage, recovery, archival, and destruction;
2. Certificate requests, renewal, and re-key requests, and revocation;
3. Approval and rejection of certificate requests;
4. Cryptographic device lifecycle management events;
5. Generation of Certificate Revocation Lists;
6. Signing of OCSP Responses (as described in [Section 4.9](#49-certificate-revocation-and-suspension) and [Section 4.10](#410-certificate-status-services)); and
7. Introduction of new Certificate Profiles and retirement of existing Certificate Profiles.
2. Subscriber Certificate lifecycle management events, including:
1. Certificate requests, renewal, and re-key requests, and revocation;
2. All verification activities stipulated in Baseline Requirements and the CA's Certification Practice Statement;
3. Approval and rejection of certificate requests;
4. Issuance of Certificates;
5. Generation of Certificate Revocation Lists; and
6. Signing of OCSP Responses (as described in [Section 4.9](#49-certificate-revocation-and-suspension) and [Section 4.10](#410-certificate-status-services)).
7. Multi-Perspective Issuance Corroboration attempts from each Network Perspective, minimally recording the following information:
- a. an identifier that uniquely identifies the Network Perspective used;
- b. the attempted domain name and/or IP address; and
- c. the result of the attempt (e.g., "domain validation pass/fail", "CAA permission/prohibition").
8. Multi-Perspective Issuance Corroboration quorum results for each attempted domain name or IP address represented in a Certificate request (i.e., "3/4" which should be interpreted as "Three (3) out of four (4) attempted Network Perspectives corroborated the determinations made by the Primary Network Perspective).
3. Security events, including:
1. Successful and unsuccessful PKI system access attempts;
2. PKI and security system actions performed;
3. Security profile changes;
4. Installation, update and removal of software on a Certificate System;
5. System crashes, hardware failures, and other anomalies;
6. Relevant router and firewall activities (as described in [Section 5.4.1.1](#5411-router-and-firewall-activities-logs)); and
7. Entries to and exits from the CA facility.
Log records MUST include at least the following elements:
1. Date and time of event;
2. Identity of the person making the journal record (when applicable); and
3. Description of the event.
#### 5.4.1.1 Router and firewall activities logs
Logging of router and firewall activities necessary to meet the requirements of [Section 5.4.1](#541-types-of-events-recorded), Subsection 3.6 MUST at a minimum include:
1. Successful and unsuccessful login attempts to routers and firewalls; and
2. Logging of all administrative actions performed on routers and firewalls, including configuration changes, firmware updates, and access control modifications; and
3. Logging of all changes made to firewall rules, including additions, modifications, and deletions; and
4. Logging of all system events and errors, including hardware failures, software crashes, and system restarts.
#### 5.4.1.2 Types of events recorded for Timestamp Authorities
**[Code Signing Certificates]**
The Timestamp Authority MUST log the following information and make these records available to its Qualified Auditor as proof of the Timestamp Authority’s compliance with Baseline Requirements for Code Signing Certificates:
1. Physical or remote access to a timestamp server, including the time of the access and the identity of the individual accessing the server,
2. History of the timestamp server configuration,
3. Any attempt to delete or modify timestamp logs,
4. Security events, including:
- a. Successful and unsuccessful Timestamp Authority access attempts;
- b. Timestamp Authority server actions performed;
- c. Security profile changes;
- d. System crashes, and other anomalies; and
- e. Firewall and router activities.
5. Revocation of a timestamp certificate,
6. Major changes to the timestamp server’s time, and
7. System startup and shutdown.
### 5.4.2 Frequency of processing audit log
The CA reviews Audit logs periodically.
The review of current and archived audit logs include a validation of the audit logs’ integrity, and the timely identification and follow up of unauthorised or suspicious activity.
### 5.4.3 Retention period for audit log
The CA and each Delegated Third Party SHALL retain, for at least two (2) years:
1. CA certificate and key lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (1)) after the later occurrence of:
1. the destruction of the CA Private Key; or
2. the revocation or expiration of the final CA Certificate in that set of Certificates that have an X.509v3 `basicConstraints` extension with the `cA` field set to true and which share a common Public Key corresponding to the CA Private Key;
2. Subscriber Certificate lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (2)) after the expiration of the Subscriber Certificate;
3. Any security event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (3)) after the event occurred.
4. For **Code Signing Certificates**, Timestamp Authority data record after the revocation or renewal of the Timestamp Certificate private key (as set forth in [Section 5.4.1.2](#5412-types-of-events-recorded-for-timestamp-authorities)); and the security event record after the event occurred (as specified in [Section 5.4.1.2](#5412-types-of-events-recorded-for-timestamp-authorities)).
### 5.4.4 Protection of audit log
The CA implements appropriate controls on Audit Log access to secure sole access by the authorized personnel and to keep the log from the eyes of those unauthorized.
### 5.4.5 Audit log backup procedures
Audit Logs are backed up and stored in a secure off-site environment that is separate from the equipment that generates the Audit Logs.
### 5.4.6 Audit collection System (internal vs. external)
The Audit Log collection system is included as a function of the certification infrastructure systems.
### 5.4.7 Notification to event-causing subject
The CA collects Audit Log without notifying the person, system or application that has caused the corresponding event.
### 5.4.8 Vulnerability assessments
Additionally, the CA's security program MUST include an annual Risk Assessment that:
1. Identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes;
2. Assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and
3. Assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.
## 5.5 Records archival
### 5.5.1 Types of records archived
The CA and each Delegated Third Party SHALL archive all audit logs (as set forth in [Section 5.4.1](#541-types-of-events-recorded)).
Additionally, the CA and each Delegated Third Party SHALL archive:
1. Documentation related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems; and
2. Documentation related to their verification, issuance, and revocation of certificate requests and Certificates.
### 5.5.2 Retention period for archive
Archived audit logs (as set forth in [Section 5.5.1](#551-types-of-records-archived) SHALL be retained for a period of at least two (2) years from their record creation timestamp, or as long as they are required to be retained per [Section 5.4.3](#543-retention-period-for-audit-log), whichever is longer.
Additionally, the CA and each Delegated Third Party SHALL retain, for at least two (2) years:
1. All archived documentation related to the security of Certificate Systems, Certificate Management Systems, Root CA Systems and Delegated Third Party Systems (as set forth in [Section 5.5.1](#551-types-of-records-archived)); and
2. All archived documentation relating to the verification, issuance, and revocation of certificate requests and Certificates (as set forth in [Section 5.5.1](#551-types-of-records-archived)) after the later occurrence of:
1. such records and documentation were last relied upon in the verification, issuance, or revocation of certificate requests and Certificates; or
2. the expiration of the Subscriber Certificates relying upon such records and documentation.
### 5.5.3 Protection of archive
Archives are retained in a facility, access to which is restricted to the authorized personnel.
### 5.5.4 Archive backup procedures
The Archive is backed up whenever a change is made in such critical data pertaining to certification infrastructure system functions as Certificate issuance/revocation or CRL issuance.
### 5.5.5 Requirements for time-stamping of records
SECOM Trust Systems uses the NTP (Network Time Protocol) to time-synchronize the certification infrastructure systems and Time-Stamps the critical data recorded therein.
### 5.5.6 Archive collection system (internal or external)
The Archive collection system is included as a function of the certification infrastructure systems.
### 5.5.7 Procedures to obtain and verify archive information
The Archive shall be retrieved from the secure storage by designated personnel with the appropriate access permission for periodic checks of the storage conditions of the media. Further, the Archive is copied to new media as appropriate to maintain their integrity and confidentiality.
## 5.6 Key changeover
Renewal of Key-Pairs or Certificates of the CA, as a general rule, shall be made before their remaining validity periods become shorter than the maximum validity periods of the Certificates issued to Subscribers. After the new key pair is generated, the certificate and CRL are issued using the new key pair.
## 5.7 Compromise and disaster recovery
### 5.7.1 Incident and compromise handling procedures
CA organizations shall have an Incident Response Plan and a Disaster Recovery Plan.
The CA SHALL document a business continuity and disaster recovery procedures designed to notify and reasonably protect Application Software Suppliers, Subscribers, and Relying Parties in the event of a disaster, security compromise, or business failure. The CA is not required to publicly disclose its business continuity plans but SHALL make its business continuity plan and security plans available to the CA's auditors upon request. The CA SHALL annually test, review, and update these procedures.
The business continuity plan MUST include:
1. The conditions for activating the plan,
2. Emergency procedures,
3. Fallback procedures,
4. Resumption procedures,
5. A maintenance schedule for the plan;
6. Awareness and education requirements;
7. The responsibilities of the individuals;
8. Recovery time objective (RTO);
9. Regular testing of contingency plans.
10. The CA's plan to maintain or restore the CA's business operations in a timely manner following interruption to or failure of critical business processes
11. A requirement to store critical cryptographic materials (i.e., secure cryptographic device and activation materials) at an alternate location;
12. What constitutes an acceptable system outage and recovery time
13. How frequently backup copies of essential business information and software are taken;
14. The distance of recovery facilities to the CA's main site; and
15. Procedures for securing its facility to the extent possible during the period of time following a disaster and prior to restoring a secure environment either at the original or a remote site.
Beginning 2025-09-01, the CA shall prepare and maintain comprehensive and actionable plans to address mass revocation events in accordance with the provisions of the Mozilla Root Store Policy.
### 5.7.2 Recovery Procedures if Computing resources, software, and/or data are corrupted
In the event of damage to any hardware, software or data of the certification infrastructure systems, SECOM Trust Systems promptly engages in the certification infrastructure systems recovery efforts using the relevant hardware, software or data retained as backup.
### 5.7.3 Recovery Procedures after Key Compromise
Should a Subscriber determine that a Private Key has or could have been compromised, the Subscriber must promptly make a revocation request to the relevant CA. Following receipt of a revocation request, the relevant CA processes the revocation according to the procedure set forth in Section [Section 4.9](#49-certificate-revocation-and-suspension) of the CAs operated on the Digital Certification Infrastructure.
In the event that the operation of the system related to the CA is interrupted or stopped, the CA shall notify the relevant parties, including the application software supplier, in accordance with the predetermined plans and procedures to safely resume operation.
### 5.7.4 Business continuity capabilities after a disaster
In order to ensure prompt recovery to be implemented in the event of an unforeseen circumstance, SECOM Trust Systems deploys preventive measures for the fastest possible recovery of the certification infrastructure systems, including securing of replacement/backup hardware, continual data backups for recovery, and establishment of the recovery procedures.
## 5.8 CA or RA termination
In the event of termination of the CA, it shall so notify Subscribers and other affected participants, including Application Software Suppliers through the Delegated Third Party, three (3) months prior to the termination.
# 6. TECHNICAL SECURITY CONTROLS
## 6.1 Key pair generation and installation
Per this topic, this CP/CPS provides for the Key controls by the CAs operated on the Digital Certification Infrastructure. The CP/CPS provides for the Key controls by such other participants as Subscribers.
### 6.1.1 Key pair generation
#### 6.1.1.1 CA Key Pair Generation
For CA Key Pairs that are either
i. used as a CA Key Pair for a Root Certificate or
ii. used as a CA Key Pair for a Subordinate CA Certificate, where the Subordinate CA is not the operator of the Root CA or an Affiliate of the Root CA,
the CA SHALL:
1. prepare and follow a Key Generation Script,
2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process, and
3. have a Qualified Auditor issue a report opining that the CA followed its key ceremony during its Key and Certificate generation process and the controls used to ensure the integrity and confidentiality of the Key Pair.
For other CA Key Pairs that are for the operator of the Root CA or an Affiliate of the Root CA, the CA SHOULD:
1. prepare and follow a Key Generation Script and
2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process.
In all cases, the CA SHALL:
1. generate the CA Key Pair in a physically secured environment as described in the CA's CP/CPS;
2. generate the CA Key Pair using personnel in Trusted Roles under the principles of multiple person control and split knowledge;
3. generate the CA Key Pair within cryptographic modules meeting the applicable technical and business requirements as disclosed in the CA's CP/CPS;
4. log its CA Key Pair generation activities; and
5. maintain effective controls to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in its CP/CPS and (if applicable) its Key Generation Script.
#### 6.1.1.2 RA Key Pair Generation
No stipulation.
#### 6.1.1.3 Subscriber Key Pair Generation
The CA SHALL reject a certificate request if one or more of the following conditions are met:
1. The Key Pair does not meet the requirements set forth in [Section 6.1.5](#615-key-sizes) and/or [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking);
2. There is clear evidence that the specific method used to generate the Private Key was flawed;
3. The CA is aware of a demonstrated or proven method that exposes the Applicant's Private Key to compromise;
4. The CA has previously been notified that the Applicant's Private Key has suffered a Key Compromise using the CA's procedure for revocation request as described in [Section 4.9.3](#493-procedure-for-revocation-request) and [Section 4.9.12](#4912-special-requirements-re-key-compromise);
5. The Public Key corresponds to an industry-demonstrated weak Private Key. For requests submitted on or after 2024-11-15, at least the following precautions SHALL be implemented:
1. In the case of Debian weak keys vulnerability (), the CA SHALL reject all keys found at for each key type (e.g. RSA, ECDSA) and size listed in the repository. For all other keys meeting the requirements of [Section 6.1.5](#615-key-sizes), with the exception of RSA key sizes greater than 8192 bits, the CA SHALL reject Debian weak keys.
2. In the case of ROCA vulnerability, the CA SHALL reject keys identified by the tools available at or equivalent.
3. In the case of Close Primes vulnerability (), the CA SHALL reject weak keys which can be factored within 100 rounds using Fermat’s factorization method.
Suggested tools for checking for weak keys can be found here:
If the Subscriber Certificate will contain an `extKeyUsage` extension containing either the values `id-kp-serverAuth` [RFC5280] or `anyExtendedKeyUsage` [RFC5280], the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA.
**[AATL Document Signing Certificates and Code Signing Certificates]**
Subscriber’s key pair shall be directly generated by and stored in such a secure cryptographic hardware device.
### 6.1.2 Private key delivery to subscriber
Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization by the Subscriber.
If the CA or any of its designated RAs become aware that a Subscriber's Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subscriber, then the CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.
**[S/MIME Certificates]**
Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization by the Subscriber.
If the CA or any of its designated RAs become aware that a Subscriber's Private Key has been communicated to a person or organization not authorized by the Subscriber, then the CA SHALL revoke all Certificates that include the Public Key corresponding to the communicated Private Key.
If the CA or a Delegated Third Party generates the Private Key on behalf of the Subscriber where the Private Keys will be transported to the Subscriber, then the entity generating the Private Key SHALL either:
1. Transport the Private Key in hardware with an activation method that is equivalent to 128 bits of encryption, where the material used to activate/protect the Private Key (e.g., a password used to secure a PKCS 12 file) must be delivered to the Subscriber securely and separately from the container holding the Private Key; or
2. Encrypt the Private Key with at least 112 bits of encryption strength.
Illustrative examples include:
- Using a 128-bit AES key to wrap the Private Key.
- Storing the key in a PKCS 12 file encrypted using a password and algorithm whose combination provides at least 112 bits of encryption strength.
- Transporting the Private Key and/or PKCS 12 file and/or activation material via a TLS or other authenticated and encrypted network connection with at least 112 bits of encryption strength.
- Other approaches that meet the requirements are allowed.
**[Code Signing Certificates]**
If the CA or any Delegated Third Party is generating the Private Key on behalf of the Subscriber where the Private Keys will be transported to the Subscriber outside of the Signing Service's secure infrastructure, then the entity generating the Private Key MUST transport the Private Key in hardware with an activation method that is equivalent to 128 bits of encryption.
Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization by the Subscriber.
If the CA or any of its designated RAs become aware that a Subscriber's Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subscriber, then the CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key. If a Signing Service is generating a Private Key on behalf of the Subscriber, that Private Key SHALL NOT be transported to the Subscriber.
### 6.1.3 Public key delivery to certificate issuer
A Subscriber Public Key may be delivered online to the CA, the communication routing of which is encrypted by TLS.
Some of the TLS server subscriber Public Keys are communicated to the CA electronically via the ACME protocol.
### 6.1.4 CA public key delivery to relying parties
Relying Parties may obtain CA Public Keys by accessing the CA Repository.
### 6.1.5 Key sizes
**When issuing a TLS server certificate, S/MIME certificate, AATL document signing certificate and AATL timestamp certificate, the following confirmation need to be done:**
For RSA key pairs the CA SHALL:
- Ensure that the modulus size, when encoded, is at least 2048 bits, and;
- Ensure that the modulus size, in bits, is evenly divisible by 8.
For ECDSA key pairs, the CA SHALL:
- Ensure that the key represents a valid point on the NIST P-256, NIST P-384 or NIST P-521 elliptic curve.
No other algorithms or key sizes are permitted.
**When issuing code signing certificates and timestamp certificates that comply with Baseline Requirements for Code Signing Certificates, the following confirmation need to be done:**
For RSA key pairs the CA SHALL:
- Ensure that the modulus size, when encoded, is at least 3072 bits, and;
- Ensure that the modulus size, in bits, is evenly divisible by 8.
For ECDSA key pairs, the CA SHALL:
- Ensure that the key represents a valid point on the NIST P-256 or NIST P-384 elliptic curve.
No other algorithms or key sizes are permitted.
### 6.1.6 Public key parameters generation and quality checking
RSA: The CA SHALL confirm that the value of the public exponent is an odd number equal to 3 or more. Additionally, the public exponent SHOULD be in the range between 2^16 + 1 and 2^256 - 1. The modulus SHOULD also have the following characteristics: an odd number, not the power of a prime, and have no factors smaller than 752. [Source: Section 5.3.3, NIST SP 800-89]
ECDSA: The CA SHOULD confirm the validity of all keys using either the ECC Full Public Key Validation Routine or the ECC Partial Public Key Validation Routine. [Source: Sections 5.6.2.3.2 and 5.6.2.3.3, respectively, of NIST SP 800-56A: Revision 2]
### 6.1.7 Key usage purposes (as per X.509 v3 key usage field)
Private Keys corresponding to Root Certificates MUST NOT be used to sign Certificates except in the following cases:
1. Self-signed Certificates to represent the Root CA itself;
2. Certificates for Subordinate CAs and Cross-Certified Subordinate CA Certificates;
3. Certificates for infrastructure purposes (administrative role certificates, internal CA operational device certificates); and
4. Certificates for OCSP Response verification.
## 6.2 Private Key Protection and Cryptographic Module Engineering Controls
The CA SHALL implement physical and logical safeguards to prevent unauthorized certificate issuance. Protection of the CA Private Key outside the validated system or device specified in [Section 6.2.7](#627-private-key-storage-on-cryptographic-module) MUST consist of physical security, encryption, or a combination of both, implemented in a manner that prevents disclosure of the Private Key. The CA SHALL encrypt its Private Key with an algorithm and key-length that, according to the state of the art, are capable of withstanding cryptanalytic attacks for the residual life of the encrypted key or key part.
### 6.2.1 Cryptographic module standards and controls
The generation, storage and signing operations of the CA Private Keys are performed using [Section 6.2.7](#627-private-key-storage-on-cryptographic-module).
No stipulation for Subscriber Private Keys.
**[AATL Document Signing Certificates]**
Certificates of the AATL Document Signing Certificate shall have one of the following accreditations:
1. FIPS 140-2 Level 2; or higher
2. Common Criteria (ISO 15408 & ISO 18045) - Protection Profiles CEN prEN 14169 (all parts applicable to the device type) or standards such as CEN EN 419 241 series or equivalent, for remotely managed devices; or
3. by an EU Member State as a Qualified Signature Creation Device (QSCD) after 1 July 2016, or that was recognized as a Secure Signature Creation Device
(SSCD) by an EU Member State designated body before 1 July 2016.
### 6.2.2 Private key (n out of m) multi-person control
Activation, deactivation, backup and other operations relating to CA Private Keys are jointly performed by at least two authorized individuals in a secure environment. Activation, deactivation, backup and other operations relating to Subscriber Private Keys must be performed securely under the control of the relevant Subscribers.
### 6.2.3 Private key escrow
The CA does not Escrow CA Private Keys.
The CA does not Escrow Subscriber Private Keys.
### 6.2.4 Private key backup
See [Section 5.2.2](#522-number-of-individuals-required-per-task).
### 6.2.5 Private key archival
Parties other than the Subordinate CA SHALL NOT archive the Subordinate CA Private Keys without authorization by the Subordinate CA.
### 6.2.6 Private key transfer into or from a cryptographic module
If the Issuing CA generated the Private Key on behalf of the Subordinate CA, then the Issuing CA SHALL encrypt the Private Key for transport to the Subordinate CA. If the Issuing CA becomes aware that a Subordinate CA's Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subordinate CA, then the Issuing CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.
### 6.2.7 Private key storage on cryptographic module
The CA SHALL protect its Private Key in a system or device that has been validated as meeting at least FIPS 140-2 level 3, FIPS 140-3 level 3, or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the Private Key and other assets against known threats.
**[Time stamp certificates for code signing]**
Time stamp certificates for code signing shall no longer be issued after 2025-04-15.
The timestamp subordinate CA certificate for code signing purposes shall be revoked by 2026-06-06.
**[Code Signing Certificates]**
Code signing certificates shall no longer be issued after 2024-05-01.
The Code signing subordinate CA certificates shall be revoked by 2026-06-06.
Effective 2023-06-01, Subscriber Private Keys for Code Signing Certificates SHALL be protected per the following requirements. The CA MUST obtain a contractual representation from the Subscriber that the Subscriber will use one of the following options to generate and protect their Code Signing Certificate Private Keys in a Hardware Crypto Module with a unit design form factor certified as conforming to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+:
1. Subscriber uses a Hardware Crypto Module meeting the specified requirement.
2. Subscriber uses a cloud-base key generation and protection solution with the following requirements:
a Key creation, storage, and usage of Private Key must remain within the security boundaries of the cloud solution’s Hardware Crypto Module that conforms to the specified requirements;
b Subscription at the level that manages the Private Key must be configured to log all access, operations, and configuration changes on the resources securing the Private Key.
3. Subscriber uses a Signing Service which meets the Baseline Requirements for Code Signing Certificates of Section 6.2.7.3.
Effective 2023-06-01, for Code Signing Certificates, one of the following methods MUST be employed to satisfy Baseline Requirements for Code Signing Certificates:
1. The CA ships a suitable Hardware Crypto Module, with one or more pre-generated Key Pairs that the CA has generated using the Hardware Crypto Module;
2. The Subscriber counter-signs certificate requests that can be verified by using a manufacturer’s certificate, commonly known as key attestation, indicating that the Private Key was generated in a non-exportable way using a suitable Hardware Crypto Module;
3. The Subscriber uses a CA prescribed crypto library and a suitable Hardware Crypto Module combination for the Key Pair generation and storage;
4. The Subscriber provides an internal or external IT audit indicating that it is only using a suitable Hardware Crypto Module to generate Key Pairs to be associated with Code Signing Certificates;
5. The Subscriber provides a suitable report from the cloud-based key protection solution subscription and resources configuration protecting the Private Key in a suitable Hardware Crypto Module;
6. The CA relies on a report provided by the Applicant that is signed by an auditor who is approved by the CA and who has IT and security training or is a CISA witnesses the Key Pair creation in a suitable Hardware Crypto Module solution including a cloud-based key generation and protection solution;
7. The Subscriber provides an agreement that they use a Signing Service meeting the Baseline Requirements for Code Signing Certificates of Section 6.2.7.3;
**[AATL Document Signing Certificates]**
If it is confirmed that the CA has generated a private key within the HSM used by the Subscriber, in the certificate application procedure, the CA verify the signature of the certificate issuance request and confirm that it is signed with the private key corresponding to the public key included in the certificate issuance request.
Alternatively, the CA generates a private key on a cryptographic hardware device and securely distributes the private key to the Subscriber, so that the CA proves the Subscriber owns the private key corresponding to the applicable certificate.
### 6.2.8 Activating Private Keys
The CA Private Key is jointly activated by at least two authorized individuals in a secure room. No stipulation for Subscriber Private Keys.
### 6.2.9 Deactivating Private Keys
The CA Private Key is jointly deactivated by at least two authorized individuals in a secure room. No stipulation for Subscriber Private Keys.
### 6.2.10 Destroying Private Keys
Private Keys of the CA are jointly destroyed by at least two authorized individuals by means of complete initialization or physical destruction. The Private Key backups are also destroyed in the same manner. No stipulation for Subscriber Private Keys.
### 6.2.11 Cryptographic Module Rating
The quality standards to be applied to the cryptographic modules used by the CA are as specified in [Section 6.2.1](#621-cryptographic-module-standards-and-controls) hereof. No stipulation for Subscriber Private Keys.
## 6.3 Other aspects of key pair management
### 6.3.1 Public key archival
The provisions for the CA Public Keys are stipulated in [Section 6.2.1](#621-cryptographic-module-standards-and-controls). No stipulation for Subscriber Private Keys.
Archival of Public Keys of the CAs operated on the Digital Certification Infrastructure is covered by [Section 5.5.1](#551-types-of-records-archived) hereof.
### 6.3.2 Certificate operational periods and key pair usage periods
The validity period of the key pair of the subordinate CA is not specified, but the validity period of the subordinate CA certificate shall be 20 years or less.
**[TLS Server Certificates]**
TLS Server subscriber Certificates issued on or after 1 September 2020 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.
**[EV TLS Server Certificates]**
The Validity Period for EV TLS Server Certificates that comply with the EV Guidelines SHALL NOT exceed 398 days.
**[Code Signing Certificates and Timestamp Certificates for Code Signing Certificates]**
Code signing certificates that comply with Baseline Requirements for Code Signing Certificates must not have a Validity Period greater than 39 months. The time stamp authority used for code signing certificates must use a new time stamp certificate with a new private key every 15 months to minimize the impact on the subscriber if the private key of the time stamp certificate is compromised. The validity period of the time stamp certificate must not be greater than 135 months.
The Timestamp Certificate Key Pair that complies with the Baseline Requirements for Code Signing Certificates MUST meet the requirements in [Section 6.1.5](#615-key-sizes). Timestamp Authority SHALL NOT use a Private Key associated with a Timestamp Certificate more than 15 months after the notBefore date of a Timestamp Certificate. Effective 2025-04-15, Private Keys associated with Timestamp Certificates issued for greater than 15 months MUST be removed from the Hardware Crypto Module protecting the Private Key within 18 months after issuance of the Timestamp Certificate. For Timestamp Certificates issued on or after 2024-06-01, the CA SHALL log the removal of the Private Key from the Hardware Crypto Module through means of a key deletion ceremony performed by the CA and witnessed and signed‐off by at least two Trusted Role members. The CA MAY also perform a key destruction ceremony, meaning that all copies of that private key are unequivocally/securely destroyed (i.e. without a way to recover the key), including any instance of the key as part of a backup, to satisfy the Baseline Requirements for Code Signing Certificates. The CA MAY maintain existing backup sets containing the Private Key corresponding to a Timestamp Certificate. The CA SHOULD NOT restore the Private Key corresponding to a Timestamp Certificate contained within the backup if the Timestamp Certificate was issued more than 15 months prior to restoration of the backup. If the CA does restore such a Private Key, the CA SHALL only restore the Private Key in a suitable HSM while it’s maintained in a High Security Zone and in an offline state or air‐gapped from all other networks and perform a new key destruction ceremony prior to the HSM being brought to an online state.
**[AATL Timestamp Certificates]**
The validity period of the time stamp certificate must not be greater than 135 months.
**[S/MIME Certificates]**
S/MIME certificates issued after 2022-04-01 must not have a Validity Period greater than 825 days.
**[Document Signing Certificates and Client Authentication Certificates]**
Subscriber certificates must not have a Validity Period greater than 1827 days.
For the purpose of calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, shall represent an additional day. For this reason, Subscriber Certificates SHOULD NOT be issued for the maximum permissible time by default, in order to account for such adjustments.
## 6.4 Activation data
### 6.4.1 Activation data generation and installation
The activation data required to use Private Keys of the CAs operated on the Digital Certification Infrastructure are jointly generated by at least two authorized individuals and are stored on a digital medium.
### 6.4.2 Activation data protection
The digital media storing the data required for activation of Private Keys of the CAs operated on the Digital Certification Infrastructure are stored under control in a secure room.
### 6.4.3 Other aspects of activation data
Management of the generation and setting of the activation data of the private key of the CA operated on the Digital Certification Infrastructure is performed by the persons described in [Section 5.2.1](#521-trusted-roles).
## 6.5 Computer security controls
### 6.5.1 Specific computer security technical requirements
The CA SHALL enforce multi-factor authentication for all accounts capable of directly causing certificate issuance.
### 6.5.2 Computer security rating
The CA conducts the preproduction system tests of all software and hardware to be employed by the certification infrastructure systems in an effort to secure the system reliability. In addition, SECOM Trust Systems constantly collects information on the security vulnerabilities of the certification infrastructure systems and performs assessments to be able to promptly take proper actions should any vulnerability be detected.
## 6.6 Life cycle technical controls
### 6.6.1 System development controls
**[TLS Server Certificates]**
If a CA uses Linting software developed by third parties, it SHOULD monitor for updated versions of that software and plan for updates no later than three (3) months from the release of the update.
The CA MAY perform Linting on the corpus of its unexpired, un-revoked Subscriber Certificates whenever it updates the Linting software.
### 6.6.2 Security management controls
The CA ensures security by conducting operational administration, such as management of the information asset, personnel and permissions, as well as timely updates of the security software such as anti-hacking and anti-virus applications.
### 6.6.3 Life cycle security controls
The CA performs assessments as appropriate to ensure that the certification infrastructure systems are developed, operated and maintained properly, and to make improvements as needed.
## 6.7 Network security controls
The CA implements firewalls, IDS and other measures as protection against unauthorized access through the network to the certification infrastructure systems.
## 6.8 Time-stamping
Requirements concerning Time-Stamping shall be as stipulated in [Section 5.5.5](#555-requirements-for-time-stamping-of-records) hereof.
# 7. CERTIFICATE, CRL, AND OCSP PROFILES
## 7.1 Certificate profile
The CA SHALL meet the technical requirements set forth in [Section 6.1.5 - Key Sizes](#615-key-sizes), and [Section 6.1.6 - Public Key Parameters Generation and Quality Checking](#616-public-key-parameters-generation-and-quality-checking).
**[TLS Server Certificates]**
Prior to 2023-09-15, the CA SHALL issue Certificates in accordance with the profile specified in Baseline Requirements or the profile specified in version 1.8.6 of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Effective 2023-09-15, the CA SHALL issue Certificates in accordance with the profile specified in Baseline Requirements.
See [APPENDIX B – Certificate profile](#appendix-b--certificate-profile).
### 7.1.1 Version number(s)
Certificates MUST be of type X.509 v3.
### 7.1.2 Certificate Content and Extensions
If the CA asserts compliance with these Baseline Requirements, all certificates that it issues MUST comply with one of the following certificate profiles, which incorporate, and are derived from [RFC 5280](https://tools.ietf.org/html/rfc5280). Except as explicitly noted, all normative requirements imposed by RFC 5280 shall apply, in addition to the normative requirements imposed by this document.
- CA Certificates
- [Section 7.1.2.1 - Root CA Certificate Profile](#7121-root-ca-certificate-profile)
- Subordinate CA Certificates
- Cross Certificates
- [Section 7.1.2.2 - Cross-Certified Subordinate CA Certificate Profile](#7122-cross-certified-subordinate-ca-certificate-profile)
- Technically Constrained CA Certificates
- [Section 7.1.2.3 - Technically-Constrained Non-TLS Subordinate CA Certificate Profile](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile)
- [Section 7.1.2.4 - Technically-Constrained Precertificate Signing CA Certificate Profile](#7124-technically-constrained-precertificate-signing-ca-certificate-profile)
- [Section 7.1.2.5 - Technically-Constrained TLS Subordinate CA Certificate Profile](#7125-technically-constrained-tls-subordinate-ca-certificate-profile)
- [Section 7.1.2.6 - TLS Subordinate CA Certificate Profile](#7126-tls-subordinate-ca-certificate-profile)
- [Section 7.1.2.7 - Subscriber (End-Entity) Certificate Profile](#7127-subscriber-server-certificate-profile)
- [Section 7.1.2.8 - OCSP Responder Certificate Profile](#7128-ocsp-responder-certificate-profile)
- [Section 7.1.2.9 - Precertificate Profile](#7129-precertificate-profile)
#### 7.1.2.1 Root CA Certificate Profile
| **Field** | **Description** |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| `tbsCertificate` | |
| - `version` | MUST be v3(2) |
| - `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. |
| - `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) |
| - `issuer` | Encoded value MUST be byte-for-byte identical to the encoded `subject` |
| - `validity` | See [Section 7.1.2.1.1](#71211-root-ca-validity) |
| - `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) |
| - `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) |
| - `issuerUniqueID` | MUST NOT be present |
| - `subjectUniqueID` | MUST NOT be present |
| - `extensions` | See [Section 7.1.2.1.2](#71212-root-ca-extensions) |
| - `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. |
| `signature` | - |
##### 7.1.2.1.1 Root CA Validity
| **Field** | **Minimum** | **Maximum** |
| ----------- | ------------------------------------ | ---------------------------- |
| `notBefore` | One day prior to the time of signing | The time of signing |
| `notAfter` | 2922 days (approx. 8 years) | 9132 days (approx. 25 years) |
**Note**: This restriction applies even in the event of generating a new Root CA Certificate for an existing `subject` and `subjectPublicKeyInfo` (e.g. reissuance). The new CA Certificate MUST conform to these rules.
##### 7.1.2.1.2 Root CA Extensions
| **Extension** | **Presence** | **Critical** | **Description** |
| --------------------------------- | --------------- | ------------ | --------------------------------------------------------------------- |
| `authorityKeyIdentifier` | RECOMMENDED | N | See [Section 7.1.2.1.3](#71213-root-ca-authority-key-identifier) |
| `basicConstraints` | MUST | Y | See [Section 7.1.2.1.4](#71214-root-ca-basic-constraints) |
| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) |
| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) |
| `extKeyUsage` | MUST NOT | - | - |
| `certificatePolicies` | NOT RECOMMENDED | N | See [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) |
| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) |
| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) |
##### 7.1.2.1.3 Root CA Authority Key Identifier
| **Field** | **Description** |
| --------------------------- | ----------------------------------------------------------------------- |
| `keyIdentifier` | MUST be present. MUST be identical to the `subjectKeyIdentifier` field. |
| `authorityCertIssuer` | MUST NOT be present |
| `authorityCertSerialNumber` | MUST NOT be present |
##### 7.1.2.1.4 Root CA Basic Constraints
| **Field** | **Description** |
| ------------------- | ---------------- |
| `cA` | MUST be set TRUE |
| `pathLenConstraint` | MUST NOT |
#### 7.1.2.2 Cross-Certified Subordinate CA Certificate Profile
This Certificate Profile MAY be used when issuing a CA Certificate using the same Subject Name and Subject Public Key Information as one or more existing CA Certificate(s), whether a Root CA Certificate or Subordinate CA Certificate.
Before issuing a Cross-Certified Subordinate CA, the Issuing CA MUST confirm that the existing CA Certificate(s) are subject to these Baseline Requirements and were issued in compliance with the then-current version of the Baseline Requirements at time of issuance.
| **Field** | **Description** |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| `tbsCertificate` | |
| - `version` | MUST be v3(2) |
| - `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. |
| - `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) |
| - `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) |
| - `validity` | See [Section 7.1.2.2.1](#71221-cross-certified-subordinate-ca-validity) |
| - `subject` | See [Section 7.1.2.2.2](#71222-cross-certified-subordinate-ca-naming) |
| - `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) |
| - `issuerUniqueID` | MUST NOT be present |
| - `subjectUniqueID` | MUST NOT be present |
| - `extensions` | See [Section 7.1.2.2.3](#71223-cross-certified-subordinate-ca-extensions) |
| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. |
| `signature` | - |
##### 7.1.2.2.1 Cross-Certified Subordinate CA Validity
| **Field** | **Minimum** | **Maximum** |
| ----------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------- |
| `notBefore` | The earlier of one day prior to the time of signing or the earliest `notBefore` date of the existing CA Certificate(s) | The time of signing |
| `notAfter` | The time of signing | Unspecified |
##### 7.1.2.2.2 Cross-Certified Subordinate CA Naming
The `subject` MUST comply with the requirements of [Section 7.1.4](#714-name-forms), or, if the existing CA Certificate was issued in compliance with the then-current version of the Baseline Requirements, the encoded `subject` name MUST be byte-for-byte identical to the encoded `subject` name of the existing CA Certificate.
**Note**: The above exception allows the CAs to issue Cross-Certified Subordinate CA Certificates, provided that the existing CA Certificate complied with the Baseline Requirements in force at time of issuance. This allows the requirements of [Section 7.1.4](#714-name-forms) to be improved over time, while still permitting Cross-Certification. If the existing CA Certificate did not comply, issuing a Cross-Certificate is not permitted.
##### 7.1.2.2.3 Cross-Certified Subordinate CA Extensions
| **Extension** | **Presence** | **Critical** | **Description** |
| --------------------------------- | --------------- | --------------------- | ----------------------------------------------------------------------------------------------- |
| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) |
| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) |
| `certificatePolicies` | MUST | N | See [Section 7.1.2.2.6](#71226-cross-certified-subordinate-ca-certificate-certificate-policies) |
| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) |
| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) |
| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) |
| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) |
| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) |
| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) |
| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) |
In addition to the above, extKeyUsage extension requirements vary based on the relationship between the Issuer and Subject organizations represented in the Cross-Certificate.
The extKeyUsage extension MAY be "unrestricted" as described in the following table if:
- the organizationName represented in the Issuer and Subject names of the corresponding certificate are either:
- the same, or
- the organizationName represented in the Subject name is an affiliate of the organizationName represented in the Issuer name
- the corresponding CA represented by the Subject of the Cross-Certificate is operated by the same organization as the Issuing CA or an Affiliate of the Issuing CA organization.
Table: Cross-Certified Subordinate CA with Unrestricted EKU
| **Extension** | **Presence** | **Critical** | **Description** |
| ------------- | --------------- | ------------ | ------------------------------------------------------------------------------------------------ |
| `extKeyUsage` | SHOULD[^eku_ca] | N | See [Section 7.1.2.2.4](#71224-cross-certified-subordinate-ca-extended-key-usage---unrestricted) |
In all other cases, the extKeyUsage extension MUST be "restricted" as described in the following table:
Table: Cross-Certified Subordinate CA with Restricted EKU
| **Extension** | **Presence** | **Critical** | **Description** |
| ------------- | ------------- | ------------ | ---------------------------------------------------------------------------------------------- |
| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.2.5](#71225-cross-certified-subordinate-ca-extended-key-usage---restricted) |
[^eku_ca]: While [RFC 5280, Section 4.2.1.12](https://tools.ietf.org/html/rfc5280#section-4.2.1.12) notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers.
[^name_constraints]: See [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) for further requirements, including regarding criticality of this extension.
##### 7.1.2.2.4 Cross-Certified Subordinate CA Extended Key Usage - Unrestricted
Table: Unrestricted Extended Key Usage Purposes (Affiliated Cross-Certified CA)
| **Key Purpose** | **Description** |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| `anyExtendedKeyUsage` | The special extended key usage to indicate there are no restrictions applied. If present, this MUST be the only key usage present. |
| Any other value | CAs MUST NOT include any other key usage with the `anyExtendedKeyUsage` key usage present. |
Alternatively, if the Issuing CA does not use this form, then the Extended Key Usage extension, if present, MUST be encoded as specified in [Section 7.1.2.2.5](#71225-cross-certified-subordinate-ca-extended-key-usage---restricted).
##### 7.1.2.2.5 Cross-Certified Subordinate CA Extended Key Usage - Restricted
Table: Restricted TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs issuing TLS certificates directly or transitively)
| **Key Purpose** | **Description** |
| ----------------------- | -------------------- |
| `id-kp-serverAuth` | MUST be present. |
| `id-kp-clientAuth` | MAY be present. |
| `id-kp-emailProtection` | MUST NOT be present. |
| `id-kp-codeSigning` | MUST NOT be present. |
| `id-kp-timeStamping` | MUST NOT be present. |
| `anyExtendedKeyUsage` | MUST NOT be present. |
| Any other value | NOT RECOMMENDED. |
Table: Restricted Non-TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs not issuing TLS certificates directly or transitively)
| **Key Purpose** | **Description** |
| --------------------- | -------------------- |
| `id-kp-serverAuth` | MUST NOT be present. |
| `anyExtendedKeyUsage` | MUST NOT be present. |
| Any other value | MAY be present. |
Each included Extended Key Usage key usage purpose:
1. MUST apply in the context of the public Internet (e.g. MUST NOT be for a service that is only valid in a privately managed network), unless:
a. the key usage purpose falls within an OID arc for which the Applicant demonstrates ownership; or,
b. the Applicant can otherwise demonstrate the right to assert the key usage purpose in a public context.
2. MUST NOT include semantics that will mislead the Relying Party about the certificate information verified by the CA, such as including a key usage purpose asserting storage on a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance.
3. MUST be verified by the Issuing CA (i.e. the Issuing CA MUST verify the Cross-Certified Subordinate CA is authorized to assert the key usage purpose).
CAs MUST NOT include additional key usage purposes unless the CA is aware of a reason for including the key usage purpose in the Certificate.
##### 7.1.2.2.6 Cross-Certified Subordinate CA Certificate Certificate Policies
The Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile:
Table: No Policy Restrictions (Affiliated CA)
| **Field** | **Presence** | **Contents** |
| ------------------ | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, and if the Subordinate CA is an Affiliate of the Issuing CA, then the Issuing CA MAY use the `anyPolicy` Policy Identifier, which MUST be the only `PolicyInformation` value. |
| - `anyPolicy` | MUST | |
| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. |
Table: Policy Restricted
| **Field** | **Presence** | **Contents** |
| ------------------------------------------------------------------------------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `policyIdentifier` | MUST | One of the following policy identifiers: |
| - A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The CA MUST include at least one Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)) transitively issued by this Certificate. |
| - `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. |
| - Any other identifier | MAY | If present, MUST be defined by the CA and documented by the CA in its CP/CPS. |
| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. |
This Profile RECOMMENDS that the first `PolicyInformation` value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST include at least one Reserved Certificate Policy Identifier. If any Subscriber Certificates will chain up directly to the Certificate issued under this Certificate Profile, this Cross-Certified Subordinate CA Certificate MUST contain exactly one Reserved Certificate Policy Identifier.
**Note**: policyQualifiers is NOT RECOMMENDED to be present in any Certificate issued under this Certificate Profile because this information increases the size of the Certificate without providing any value to a typical Relying Party, and the information may be obtained by other means when necessary.
If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows:
Table: Permitted `policyQualifiers`
| **Qualifier ID** | **Presence** | **Field Type** | **Contents** |
| ------------------------------------ | ------------ | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. |
| Any other qualifier | MUST NOT | - | - |
#### 7.1.2.3 Technically Constrained Non-TLS Subordinate CA Certificate Profile
This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will not be used to issue TLS certificates directly or transitively.
| **Field** | **Description** |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| `tbsCertificate` | |
| - `version` | MUST be v3(2) |
| - `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. |
| - `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) |
| - `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) |
| - `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) |
| - `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) |
| - `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) |
| - `issuerUniqueID` | MUST NOT be present |
| - `subjectUniqueID` | MUST NOT be present |
| - `extensions` | See [Section 7.1.2.3.1](#71231-technically-constrained-non-tls-subordinate-ca-extensions) |
| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. |
| `signature` | - |
##### 7.1.2.3.1 Technically Constrained Non-TLS Subordinate CA Extensions
| **Extension** | **Presence** | **Critical** | **Description** |
| --------------------------------- | --------------- | --------------------- | --------------------------------------------------------------------------------------------------- |
| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) |
| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) |
| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) |
| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) |
| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) |
| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.3.3](#71233-technically-constrained-non-tls-subordinate-ca-extended-key-usage) |
| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) |
| `certificatePolicies` | MAY | N | See [Section 7.1.2.3.2](#71232-technically-constrained-non-tls-subordinate-ca-certificate-policies) |
| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) |
| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) |
| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) |
##### 7.1.2.3.2 Technically Constrained Non-TLS Subordinate CA Certificate Policies
If present, the Certificate Policies extension MUST be formatted as one of the two tables below:
Table: No Policy Restrictions (Affiliated CA)
| **Field** | **Presence** | **Contents** |
| ------------------ | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, the Subordinate CA MUST be an Affiliate of the Issuing CA. The Certificate Policies extension MUST contain only a single `PolicyInformation` value, which MUST contain the `anyPolicy` Policy Identifier. |
| - `anyPolicy` | MUST | |
| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. |
Table: Policy Restricted
| **Field** | **Presence** | **Contents** |
| ------------------------------------------------------------------------------------------- | --------------- | -------------------------------------------------------------------------------- |
| `policyIdentifier` | MUST | One of the following policy identifiers: |
| - A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST NOT | |
| - `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. |
| - Any other identifier | MAY | If present, MUST be documented by the CA in its CP/CPS. |
| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. |
Table: Permitted `policyQualifiers`
| **Qualifier ID** | **Presence** | **Field Type** | **Contents** |
| ------------------------------------ | ------------ | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. |
| Any other qualifier | MUST NOT | - | - |
##### 7.1.2.3.3 Technically Constrained Non-TLS Subordinate CA Extended Key Usage
The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to issue certificates for each included extended key usage purpose. Multiple, independent key purposes (e.g. `id-kp-timeStamping` and `id-kp-codeSigning`) are NOT RECOMMENDED.
| **Key Purpose** | **OID** | **Presence** |
| ---------------------------------- | ----------------------- | ------------ |
| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST NOT |
| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT |
| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT |
| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT |
| Any other value | - | MAY |
#### 7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile
This Certificate Profile MUST be used when issuing a CA Certificate that will be used as a Precertificate Signing CA, as described in [RFC 6962, Section 3.1](https://tools.ietf.org/html/rfc6962#section-3.1). If a CA Certificate conforms to this profile, it is considered Technically Constrained.
A Precertificate Signing CA MUST only be used to sign Precertificates, as defined in [Section 7.1.2.9](#7129-precertificate-profile). When a Precertificate Signing CA issues a Precertificate, it shall be interpreted as if the Issuing CA of the Precertificate Signing CA has issued a Certificate with a matching `tbsCertificate` of the Precertificate, after applying the modifications specified in [RFC 6962, Section 3.2](https://tools.ietf.org/html/rfc6962#section-3.2).
As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is not altered as part of these modifications. As such, the Precertificate Signing CA MUST use the same signature algorithm as the Issuing CA when issuing Precertificates, and, correspondingly, MUST use a public key of the same public key algorithm as the Issuing CA, although MAY use a different CA Key Pair.
| **Field** | **Description** |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `tbsCertificate` | |
| - `version` | MUST be v3(2) |
| - `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. |
| - `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) |
| - `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) |
| - `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) |
| - `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) |
| - `subjectPublicKeyInfo` | The algorithm identifier MUST be byte-for-byte identical to the algorithm identifier of the `subjectPublicKeyInfo` field of the Issuing CA. See [Section 7.1.3.1](#7131-subjectpublickeyinfo) |
| - `issuerUniqueID` | MUST NOT be present |
| - `subjectUniqueID` | MUST NOT be present |
| - `extensions` | See [Section 7.1.2.4.1](#71241-technically-constrained-precertificate-signing-ca-extensions) |
| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. |
| `signature` | - |
##### 7.1.2.4.1 Technically Constrained Precertificate Signing CA Extensions
| **Extension** | **Presence** | **Critical** | **Description** |
| --------------------------------- | --------------- | --------------------- | ---------------------------------------------------------------------------------------------------- |
| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) |
| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) |
| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) |
| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) |
| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) |
| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) |
| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.4.2](#71242-technically-constrained-precertificate-signing-ca-extended-key-usage) |
| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) |
| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) |
| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) |
| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) |
##### 7.1.2.4.2 Technically Constrained Precertificate Signing CA Extended Key Usage
| **Key Purpose** | **OID** | **Presence** |
| ---------------------------------- | ----------------------- | ------------ |
| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST |
| Any other value | - | MUST NOT |
#### 7.1.2.5 Technically Constrained TLS Subordinate CA Certificate Profile
This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will be used to issue TLS certificates directly or transitively.
| **Field** | **Description** |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| `tbsCertificate` | |
| - `version` | MUST be v3(2) |
| - `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. |
| - `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) |
| - `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) |
| - `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) |
| - `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) |
| - `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) |
| - `issuerUniqueID` | MUST NOT be present |
| - `subjectUniqueID` | MUST NOT be present |
| - `extensions` | See [Section 7.1.2.5.1](#71251-technically-constrained-tls-subordinate-ca-extensions) |
| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. |
| `signature` | - |
##### 7.1.2.5.1 Technically Constrained TLS Subordinate CA Extensions
| **Extension** | **Presence** | **Critical** | **Description** |
| --------------------------------- | --------------- | --------------------- | ------------------------------------------------------------------------------------------- |
| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) |
| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) |
| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) |
| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) |
| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) |
| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) |
| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.6](#712106-ca-certificate-extended-key-usage) |
| `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.5.2](#71252-technically-constrained-tls-subordinate-ca-name-constraints) |
| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) |
| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) |
| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) |
##### 7.1.2.5.2 Technically Constrained TLS Subordinate CA Name Constraints
For a TLS Subordinate CA to be Technically Constrained, Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatibility with certain legacy applications that do not support Name Constraints is necessary.
Table: `nameConstraints` requirements
| **Field** | **Description** |
| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `permittedSubtrees` | The `permittedSubtrees` MUST contain at least one `GeneralSubtree` for both of the `dNSName` and `iPAddress` `GeneralName` name types, UNLESS the specified `GeneralName` name type appears within the `excludedSubtrees` to exclude all names of that name type. Additionally, the `permittedSubtrees` MUST contain at least one `GeneralSubtree` of the `directoryName` `GeneralName` name type. |
| - `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. |
| -- `base` | See following table. |
| -- `minimum` | MUST NOT be present. |
| -- `maximum` | MUST NOT be present. |
| `excludedSubtrees` | The `excludedSubtrees` MUST contain at least one `GeneralSubtree` for each of the `dNSName` and `iPAddress` `GeneralName` name types, unless there is an instance present of that name type in the `permittedSubtrees`. The `directoryName` name type is NOT RECOMMENDED. |
| - `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. |
| -- `base` | See following table. |
| -- `minimum` | MUST NOT be present. |
| -- `maximum` | MUST NOT be present. |
The following table contains the requirements for the `GeneralName` that appears within the `base` of a `GeneralSubtree` in either the `permittedSubtrees` or `excludedSubtrees`.
Table: `GeneralName` requirements for the `base` field
| **Name Type** | **Presence** | **Permitted Subtrees** | **Excluded Subtrees** | **Entire Namespace Exclusion** |
| --------------- | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `dNSName` | MUST | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | If no `dNSName` instance is present in the `permittedSubtrees`, then the CA MUST include a zero-length `dNSName` to indicate no domain names are permitted. |
| `iPAddress` | MUST NOT | SECOM Trust Systems does not issue TLS Server Subscriber (End-Entity) Certificates containing the IPv4 or IPv6 address. | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | If no IPv4 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 8 zero octets, indicating the IPv4 range of 0.0.0.0/0 being excluded. If no IPv6 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 32 zero octets, indicating the IPv6 range of ::0/0 being excluded. |
| `directoryName` | MUST | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | It is NOT RECOMMENDED to include values within `excludedSubtrees`. | The CA MUST include a value within `permittedSubtrees`, and as such, this does not apply. See the Excluded Subtrees requirements for more. |
| `otherName` | NOT RECOMMENDED | See below | See below | See below |
| Any other value | MUST NOT | - | - | - |
Any `otherName`, if present:
1. MUST apply in the context of the public Internet, unless:
a. the `type-id` falls within an OID arc for which the Applicant demonstrates ownership, or,
b. the Applicant can otherwise demonstrate the right to assert the data in a public context.
2. MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA.
3. MUST be DER encoded according to the relevant ASN.1 module defining the `otherName` `type-id` and `value`.
CAs SHALL NOT include additional names unless the CA is aware of a reason for including the data in the Certificate.
#### 7.1.2.6 TLS Subordinate CA Certificate Profile
| **Field** | **Description** |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| `tbsCertificate` | |
| - `version` | MUST be v3(2) |
| - `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. |
| - `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) |
| - `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) |
| - `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) |
| - `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) |
| - `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) |
| - `issuerUniqueID` | MUST NOT be present |
| - `subjectUniqueID` | MUST NOT be present |
| - `extensions` | See [Section 7.1.2.6.1](#71261-tls-subordinate-ca-extensions) |
| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. |
| `signature` | - |
##### 7.1.2.6.1 TLS Subordinate CA Extensions
| **Extension** | **Presence** | **Critical** | **Description** |
| --------------------------------- | --------------- | --------------------- | ----------------------------------------------------------------------------- |
| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) |
| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) |
| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) |
| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) |
| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) |
| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) |
| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.6](#712106-ca-certificate-extended-key-usage) |
| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) |
| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) |
| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) |
| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) |
#### 7.1.2.7 Subscriber (Server) Certificate Profile
| **Field** | **Description** |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| `tbsCertificate` | |
| - `version` | MUST be v3(2) |
| - `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. |
| - `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) |
| - `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) |
| - `validity` | |
| -- `notBefore` | A value within 48 hours of the certificate signing operation. |
| -- `notAfter` | See [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| - `subject` | See [Section 7.1.2.7.1](#71271-subscriber-certificate-types) |
| - `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) |
| - `issuerUniqueID` | MUST NOT be present |
| - `subjectUniqueID` | MUST NOT be present |
| - `extensions` | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) |
| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. |
| `signature` | - |
##### 7.1.2.7.1 Subscriber Certificate Types
There are four types of Subscriber Certificates that may be issued, which vary based on the amount of Subject Information that is included. Each of these certificate types shares a common profile, with three exceptions: the `subject` name fields that may occur, how those fields are validated, and the contents of the `certificatePolicies` extension.
| **Type** | **Description** |
| --------------------------- | ------------------------------------------------------------------------------------- |
| Domain Validated (DV) | See [Section 7.1.2.7.2](#71272-domain-validated) |
| Individual Validated (IV) | SECOM Trust Systems does not issue subscriber certificates for individual validation. |
| Organization Validated (OV) | See [Section 7.1.2.7.4](#71274-organization-validated) |
| Extended Validation (EV) | See [Section 7.1.2.7.5](#71275-extended-validation) |
**Note**: Although each Subscriber Certificate type varies in Subject Information, all Certificates provide the same level of assurance of the device identity (domain name and/or IP address).
##### 7.1.2.7.2 Domain Validated
For a Subscriber Certificate to be Domain Validated, it MUST meet the following profile:
| **Field** | **Requirements** |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `subject` | See following table. |
| `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.1` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). |
| All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) |
All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms).
The following table details the acceptable `AttributeType`s that may appear within the `type` field of an `AttributeTypeAndValue`, as well as the contents permitted within the `value` field.
Table: Domain Validated `subject` Attributes
| **Attribute Name** | **Presence** | **Value** | **Verification** |
| ------------------- | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- |
| `countryName` | MUST NOT | SECOM Trust Systems does not include this attribute. | - |
| `commonName` | NOT RECOMMENDED | If present, MUST contain a value derived from the `subjectAltName` extension according to [Section 7.1.4.3](#7143-subscriber-certificate-common-name-attribute). | |
| Any other attribute | MUST NOT | - | - |
##### 7.1.2.7.3 Individual Validated
SECOM Trust Systems does not issue subscriber certificates for individual validation.
##### 7.1.2.7.4 Organization Validated
For a Subscriber Certificate to be Organization Validated, it MUST meet the following profile:
| **Field** | **Requirements** |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `subject` | See following table. |
| `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.2` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). |
| All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) |
All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms).
The following table details the acceptable `AttributeType`s that may appear within the `type` field of an `AttributeTypeAndValue`, as well as the contents permitted within the `value` field.
Table: Organization Validated `subject` Attributes
| **Attribute Name** | **Presence** | **Value** | **Verification** |
| ------------------------ | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- |
| `domainComponent` | MUST NOT | SECOM Trust Systems does not include this attribute. | - |
| `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.2.1](#3221-identity) |
| `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.2.1](#3221-identity) |
| `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.2.1](#3221-identity) |
| `postalCode` | MUST NOT | SECOM Trust Systems does not include this attribute. | - |
| `streetAddress` | MUST NOT | SECOM Trust Systems does not include this attribute. | - |
| `organizationName` | MUST | The Subject's name and/or DBA/tradename. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". If both are included, the DBA/tradename SHALL appear first, followed by the Subject's name in parentheses. | [Section 3.2.2.2](#3222-dbatradename) |
| `surname` | MUST NOT | - | - |
| `givenName` | MUST NOT | - | - |
| `organizationalUnitName` | MUST NOT | - | - |
| `commonName` | NOT RECOMMENDED | If present, MUST contain a value derived from the `subjectAltName` extension according to [Section 7.1.4.3](#7143-subscriber-certificate-common-name-attribute). | |
| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.4](#7144-other-subject-attributes) |
In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable.
##### 7.1.2.7.5 Extended Validation
For a Subscriber Certificate to be Extended Validation, it MUST comply with the Certificate Profile specified in the then-current version of the EV Guidelines for the Issuance and Management of Extended Validation Certificates.
In addition, it MUST meet the following profile:
| **Field** | **Requirements** |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `subject` | See Guidelines for the Issuance and Management of Extended Validation Certificates, Section 7.1.4.2. |
| `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.1` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). |
| All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) and the EV Guidelines for the Issuance and Management of Extended Validation Certificates. |
In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable.
##### 7.1.2.7.6 Subscriber Certificate Extensions
| **Extension** | **Presence** | **Critical** | **Description** |
| --------------------------------- | --------------- | ------------ | ----------------------------------------------------------------------------------- |
| `authorityInformationAccess` | MUST | N | See [Section 7.1.2.7.7](#71277-subscriber-certificate-authority-information-access) |
| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) |
| `certificatePolicies` | MUST | N | See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies) |
| `extKeyUsage` | MUST | N | See [Section 7.1.2.7.10](#712710-subscriber-certificate-extended-key-usage) |
| `subjectAltName` | MUST | * | See [Section 7.1.2.7.12](#712712-subscriber-certificate-subject-alternative-name) |
| `nameConstraints` | MUST NOT | - | - |
| `keyUsage` | SHOULD | Y | See [Section 7.1.2.7.11](#712711-subscriber-certificate-key-usage) |
| `basicConstraints` | MAY | Y | See [Section 7.1.2.7.8](#71278-subscriber-certificate-basic-constraints) |
| `crlDistributionPoints` | * | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) |
| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) |
| `subjectKeyIdentifier` | NOT RECOMMENDED | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) |
| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) |
**Notes**:
- whether or not the `subjectAltName` extension should be marked Critical depends on the contents of the Certificate's `subject` field, as detailed in [Section 7.1.2.7.12](#712712-subscriber-certificate-subject-alternative-name).
- whether or not the CRL Distribution Points extension must be present depends on 1) whether the Certificate includes an authorityInformationAccess extension with an id-ad-ocsp accessMethod and 2) the Certificate's validity period, as detailed in [Section 7.1.2.11.2](#712112-crl-distribution-points).
##### 7.1.2.7.7 Subscriber Certificate Authority Information Access
The `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `accessLocation` MUST be encoded as the specified `GeneralName` type.
The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied.
| **Access Method** | **OID** | **Access Location** | **Presence** | **Maximum** | **Description** |
| ----------------- | ------------------ | --------------------------- | ------------ | ----------- | ---------------------------------------------- |
| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. |
| `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | SHOULD | \* | A HTTP URL of the Issuing CA's certificate. |
| Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. |
##### 7.1.2.7.8 Subscriber Certificate Basic Constraints
| **Field** | **Description** |
| ------------------- | ------------------- |
| `cA` | MUST be FALSE |
| `pathLenConstraint` | MUST NOT be present |
##### 7.1.2.7.9 Subscriber Certificate Certificate Policies
If present, the Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile:
| **Field** | **Presence** | **Contents** |
| ------------------------------------------------------------------------------------------- | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `policyIdentifier` | MUST | One of the following policy identifiers: |
| - A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)). |
| - `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. |
| - Any other identifier | MAY | If present, MUST be defined and documented in the CA's CP/CPS. |
| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. |
This Profile RECOMMENDS that the first `PolicyInformation` value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier.
Table: Permitted `policyQualifiers`
| **Qualifier ID** | **Presence** | **Field Type** | **Contents** |
| ------------------------------------ | ------------ | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. |
| Any other qualifier | MUST NOT | - | - |
[^first_policy_note]: Although RFC 5280 allows `PolicyInformation`s to appear in any order, several client implementations have implemented logic that considers the `policyIdentifier` that matches a given filter. As such, ensuring the Reserved Certificate Policy Identifier is the first `PolicyInformation` reduces the risk of interoperability challenges.
##### 7.1.2.7.10 Subscriber Certificate Extended Key Usage
| **Key Purpose** | **OID** | **Presence** |
| ---------------------------------- | ----------------------- | --------------- |
| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST |
| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY |
| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT |
| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT |
| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT |
| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT |
| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT |
| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT |
| Any other value | - | NOT RECOMMENDED |
##### 7.1.2.7.11 Subscriber Certificate Key Usage
The acceptable Key Usage values vary based on whether the Certificate's `subjectPublicKeyInfo` identifies an RSA public key or an ECC public key. CAs MUST ensure the Key Usage is appropriate for the Certificate Public Key.
Table: Key Usage for RSA Public Keys
| **Key Usage** | **Permitted** | **Required** |
| ------------------ | ------------- | --------------- |
| `digitalSignature` | Y | SHOULD |
| `nonRepudiation` | N | -- |
| `keyEncipherment` | Y | MAY |
| `dataEncipherment` | Y | NOT RECOMMENDED |
| `keyAgreement` | N | -- |
| `keyCertSign` | N | -- |
| `cRLSign` | N | -- |
| `encipherOnly` | N | -- |
| `decipherOnly` | N | -- |
**Note**: At least one Key Usage MUST be set for RSA Public Keys. The `digitalSignature` bit is REQUIRED for use with modern protocols, such as TLS 1.3, and secure ciphersuites, while the `keyEncipherment` bit MAY be asserted to support older protocols, such as TLS 1.2, when using insecure ciphersuites. Subscribers MAY wish to ensure key separation to limit the risk from such legacy protocols, and thus a CA MAY issue a Subscriber certificate that only asserts the `keyEncipherment` bit. For most Subscribers, the `digitalSignature` bit is sufficient, while Subscribers that want to mix insecure and secure ciphersuites with the same algorithm may choose to assert both `digitalSignature` and `keyEncipherment` within the same certificate, although this is NOT RECOMMENDED. The `dataEncipherment` bit is currently permitted, although setting it is NOT RECOMMENDED, as it is a Pending Prohibition ().
Table: Key Usage for ECC Public Keys
| **Key Usage** | **Permitted** | **Required** |
| ------------------ | ------------- | --------------- |
| `digitalSignature` | Y | MUST |
| `nonRepudiation` | N | -- |
| `keyEncipherment` | N | -- |
| `dataEncipherment` | N | -- |
| `keyAgreement` | Y | NOT RECOMMENDED |
| `keyCertSign` | N | -- |
| `cRLSign` | N | -- |
| `encipherOnly` | N | -- |
| `decipherOnly` | N | -- |
**Note**: The `keyAgreement` bit is currently permitted, although setting it is NOT RECOMMENDED, as it is a Pending Prohibition ().
##### 7.1.2.7.12 Subscriber Certificate Subject Alternative Name
For Subscriber Certificates, the Subject Alternative Name MUST be present and MUST contain at least one `dNSName` or `iPAddress` `GeneralName`. See below for further requirements about the permitted fields and their validation requirements.
If the `subject` field of the certificate is an empty SEQUENCE, this extension MUST be marked critical, as specified in [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6). Otherwise, this extension MUST NOT be marked critical.
Table: `GeneralName` within a `subjectAltName` extension
| **Name Type** | **Permitted** | **Validation** |
| --------------------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `otherName` | N | - |
| `rfc822Name` | N | - |
| `dNSName` | Y | The entry MUST contain either a Fully-Qualified Domain Name or Wildcard Domain Name that the CA has validated in accordance with [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). Wildcard Domain Names MUST be validated for consistency with [Section 3.2.2.6](#3226-wildcard-domain-validation). The entry MUST NOT contain an Internal Name. The Fully-Qualified Domain Name or the FQDN portion of the Wildcard Domain Name contained in the entry MUST be composed entirely of P-Labels or Non-Reserved LDH Labels joined together by a U+002E FULL STOP (".") character. The zero-length Domain Label representing the root zone of the Internet Domain Name System MUST NOT be included (e.g. "example.com" MUST be encoded as "example.com" and MUST NOT be encoded as "example.com."). |
| `x400Address` | N | - |
| `directoryName` | N | - |
| `ediPartyName` | N | - |
| `uniformResourceIdentifier` | N | - |
| `iPAddress` | N | SECOM Trust Systems does not issue TLS Server Subscriber (End-Entity) Certificates containing the IPv4 or IPv6 address. |
| `registeredID` | N | - |
**Note**: As an explicit exception from RFC 5280, P-Labels are permitted to not conform to IDNA 2003. These Requirements allow for the inclusion of P-Labels that do not conform with IDNA 2003 to support newer versions of the Unicode character repertoire, among other improvements to the various IDNA standards.
#### 7.1.2.8 OCSP Responder Certificate Profile
If the Issuing CA does not directly sign OCSP responses, it MAY make use of an OCSP Authorized Responder, as defined by [RFC 6960](https://tools.ietf.org/html/RFC6960#section-4.2.2.2). The Issuing CA of the Responder MUST be the same as the Issuing CA for the Certificates it provides responses for.
| **Field** | **Description** |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| `tbsCertificate` | |
| - `version` | MUST be v3(2) |
| - `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. |
| - `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) |
| - `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) |
| - `validity` | See [Section 7.1.2.8.1](#71281-ocsp-responder-validity) |
| - `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) |
| - `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) |
| - `issuerUniqueID` | MUST NOT be present |
| - `subjectUniqueID` | MUST NOT be present |
| - `extensions` | See [Section 7.1.2.8.2](#71282-ocsp-responder-extensions) |
| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. |
| `signature` | - |
##### 7.1.2.8.1 OCSP Responder Validity
| **Field** | **Minimum** | **Maximum** |
| ----------- | ------------------------------------ | ------------------- |
| `notBefore` | One day prior to the time of signing | The time of signing |
| `notAfter` | The time of signing | Unspecified |
##### 7.1.2.8.2 OCSP Responder Extensions
| **Extension** | **Presence** | **Critical** | **Description** |
| --------------------------------- | --------------- | ------------ | --------------------------------------------------------------------------- |
| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) |
| `extKeyUsage` | MUST | - | See [Section 7.1.2.8.5](#71285-ocsp-responder-extended-key-usage) |
| `id-pkix-ocsp-nocheck` | MUST | N | See [Section 7.1.2.8.6](#71286-ocsp-responder-id-pkix-ocsp-nocheck) |
| `keyUsage` | MUST | Y | See [Section 7.1.2.8.7](#71287-ocsp-responder-key-usage) |
| `basicConstraints` | MAY | Y | See [Section 7.1.2.8.4](#71284-ocsp-responder-basic-constraints) |
| `nameConstraints` | MUST NOT | - | - |
| `subjectAltName` | MUST NOT | - | - |
| `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) |
| `authorityInformationAccess` | NOT RECOMMENDED | N | See [Section 7.1.2.8.3](#71283-ocsp-responder-authority-information-access) |
| `certificatePolicies` | MUST NOT | N | See [Section 7.1.2.8.8](#71288-ocsp-responder-certificate-policies) |
| `crlDistributionPoints` | MUST NOT | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) |
| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) |
| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) |
##### 7.1.2.8.3 OCSP Responder Authority Information Access
For OCSP Responder certificates, this extension is NOT RECOMMENDED, as the Relying Party should already possess the necessary information. In order to validate the given Responder certificate, the Relying Party must have access to the Issuing CA's certificate, eliminating the need to provide `id-ad-caIssuers`. Similarly, because of the requirement for an OCSP Responder certificate to include the `id-pkix-ocsp-nocheck` extension, it is not necessary to provide `id-ad-ocsp`, as such responses will not be checked by Relying Parties.
If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `AuthorityInfoAccessSyntax` MUST contain all required `AccessDescription`s.
| **Access Method** | **OID** | **Access Location** | **Presence** | **Maximum** | **Description** |
| ----------------- | ------------------ | --------------------------- | --------------- | ----------- | ---------------------------------------------- |
| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | NOT RECOMMENDED | \* | A HTTP URL of the Issuing CA's OCSP responder. |
| Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. |
##### 7.1.2.8.4 OCSP Responder Basic Constraints
OCSP Responder certificates MUST NOT be CA certificates. The issuing CA may indicate this one of two ways: by omission of the `basicConstraints` extension, or through the inclusion of a `basicConstraints` extension that sets the `cA` boolean to FALSE.
| **Field** | **Description** |
| ------------------- | ------------------- |
| `cA` | MUST be FALSE |
| `pathLenConstraint` | MUST NOT be present |
**Note**: Due to DER encoding rules regarding the encoding of DEFAULT values within OPTIONAL fields, a `basicConstraints` extension that sets the `cA` boolean to FALSE MUST have an `extnValue` `OCTET STRING` which is exactly the hex-encoded bytes `3000`, the encoded representation of an empty ASN.1 `SEQUENCE` value.
##### 7.1.2.8.5 OCSP Responder Extended Key Usage
| **Key Purpose** | **OID** | **Presence** |
| ------------------- | ----------------- | ------------ |
| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST |
| Any other value | - | MUST NOT |
##### 7.1.2.8.6 OCSP Responder id-pkix-ocsp-nocheck
The CA MUST include the `id-pkix-ocsp-nocheck` extension (OID: 1.3.6.1.5.5.7.48.1.5).
This extension MUST have an `extnValue` `OCTET STRING` which is exactly the hex-encoded bytes `0500`, the encoded representation of the ASN.1 NULL value, as specified in [RFC 6960, Section 4.2.2.2.1](https://tools.ietf.org/html/RFC6960#section-4.2.2.2.1).
##### 7.1.2.8.7 OCSP Responder Key Usage
| **Key Usage** | **Permitted** | **Required** |
| ------------------ | ------------- | ------------ |
| `digitalSignature` | Y | Y |
| `nonRepudiation` | N | -- |
| `keyEncipherment` | N | -- |
| `dataEncipherment` | N | -- |
| `keyAgreement` | N | -- |
| `keyCertSign` | N | -- |
| `cRLSign` | N | -- |
| `encipherOnly` | N | -- |
| `decipherOnly` | N | -- |
##### 7.1.2.8.8 OCSP Responder Certificate Policies
SECOM Trust Systems does not include this extension.
#### 7.1.2.9 Precertificate Profile
A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by [RFC 6962](https://tools.ietf.org/doc/html/rfc6962). A Precertificate appears structurally identical to a Certificate, with the exception of a special critical poison extension in the `extensions` field, with the OID of `1.3.6.1.4.1.11129.2.4.3`. This extension ensures that the Precertificate will not be accepted as a Certificate by clients conforming to [RFC 5280](https://tools.ietf.org/doc/html/rfc5280). The existence of a signed Precertificate can be treated as evidence of a corresponding Certificate also existing, as the signature represents a binding commitment by the CA that it may issue such a Certificate.
A Precertificate is created after a CA has decided to issue a Certificate, but prior to the actual signing of the Certificate. The CA MAY construct and sign a Precertificate corresponding to the Certificate, for purposes of submitting to Certificate Transparency Logs. The CA MAY use the returned Signed Certificate Timestamps to then alter the Certificate's `extensions` field, adding a Signed Certificate Timestamp List, as defined in [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) and as permitted by the relevant profile, prior to signing the Certificate.
Once a Precertificate is signed, relying parties are permitted to treat this as a binding commitment from the CA of the intent to issue a corresponding Certificate, or more commonly, that a corresponding Certificate exists. A Certificate is said to be corresponding to a Precertificate based upon the value of the `tbsCertificate` contents, as transformed by the process defined in [RFC 6962, Section 3.2](https://tools.ietf.org/doc/html/rfc6962#section-3.2).
This profile describes the transformations that are permitted to a Certificate to construct a Precertificate. CAs MUST NOT issue a Precertificate unless they are willing to issue a corresponding Certificate, regardless of whether they have done so. Similarly, a CA MUST NOT issue a Precertificate unless the corresponding Certificate conforms to these Baseline Requirements, regardless of whether the CA signs the corresponding Certificate.
A Precertificate may be issued either directly by the Issuing CA or by a Technically Constrained Precertificate Signing CA, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile). If issued by a Precertificate Signing CA, then in addition to the precertificate poison and signed certificate timestamp list extensions, the Precertificate `issuer` field and, if present, `authorityKeyIdentifier` extension, may differ from the Certificate, as described below.
Table: When the Precertificate is issued directly by the Issuing CA
| **Field** | **Description** |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- |
| `tbsCertificate` | |
| - `version` | Encoded value MUST be byte-for-byte identical to the `version` field of the Certificate |
| - `serialNumber` | Encoded value MUST be byte-for-byte identical to the `serialNumber` field of the Certificate |
| - `signature` | Encoded value MUST be byte-for-byte identical to the `signature` field of the Certificate |
| - `issuer` | Encoded value MUST be byte-for-byte identical to the `issuer` field of the Certificate |
| - `validity` | Encoded value MUST be byte-for-byte identical to the `validity` field of the Certificate |
| - `subject` | Encoded value MUST be byte-for-byte identical to the `subject` field of the Certificate |
| - `subjectPublicKeyInfo` | Encoded value MUST be byte-for-byte identical to the `subjectPublicKeyInfo` field of the Certificate |
| - `issuerUniqueID` | Encoded value MUST be byte-for-byte identical to the `issuerUniqueID` field of the Certificate, or omitted if omitted in the Certificate |
| - `subjectUniqueID` | Encoded value MUST be byte-for-byte identical to the `subjectUniqueID` field of the Certificate, or omitted if omitted in the Certificate |
| - `extensions` | See [Section 7.1.2.9.1](#71291-precertificate-profile-extensions---directly-issued) |
| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. |
| `signature` | - |
Table: When the Precertificate is issued by a Precertificate Signing CA on behalf of an Issuing CA
| **Field** | **Description** |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `tbsCertificate` | |
| `version` | Encoded value MUST be byte-for-byte identical to the `version` field of the Certificate |
| - `serialNumber` | Encoded value MUST be byte-for-byte identical to the `serialNumber` field of the Certificate |
| - `signature` | Encoded value MUST be byte-for-byte identical to the `signature` field of the Certificate |
| - `issuer` | Encoded value MUST be byte-for-byte identical to the `subject` field of the [Precertificate Signing CA Certificate](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) |
| - `validity` | Encoded value MUST be byte-for-byte identical to the `validity` field of the Certificate |
| - `subject` | Encoded value MUST be byte-for-byte identical to the `subject` field of the Certificate |
| - `subjectPublicKeyInfo` | Encoded value MUST be byte-for-byte identical to the `subjectPublicKeyInfo` field of the Certificate |
| - `issuerUniqueID` | Encoded value MUST be byte-for-byte identical to the `issuerUniqueID` field of the Certificate, or omitted if omitted in the Certificate |
| - `subjectUniqueID` | Encoded value MUST be byte-for-byte identical to the `subjectUniqueID` field of the Certificate, or omitted if omitted in the Certificate |
| - `extensions` | See [Section 7.1.2.9.2](#71292-precertificate-profile-extensions---precertificate-ca-issued) |
| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. |
| `signature` | - |
**Note**: This profile requires that the `serialNumber` field of the Precertificate be identical to that of the corresponding Certificate. [RFC 5280, Section 4.1.2.2](https://tools.ietf.org/doc/html/rfc5280#section-4.1.2.2) requires that the `serialNumber` of certificates be unique. For the purposes of this document, a Precertificate shall not be considered a "certificate" subject to that requirement, and thus may have the same `serialNumber` of the corresponding Certificate. However, this does not permit two Precertificates to share the same `serialNumber`, unless they correspond to the same Certificate, as this would otherwise indicate there are two corresponding Certificates that share the same `serialNumber`.
##### 7.1.2.9.1 Precertificate Profile Extensions - Directly Issued
These extensions apply in the context of a Precertificate directly issued from a CA, and not from a Precertificate Signing CA Certificate, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile).
| **Extension** | **Presence** | **Critical** | **Description** |
| ---------------------------------------------------- | ------------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| Precertificate Poison (OID: 1.3.6.1.4.1.11129.2.4.3) | MUST | Y | See [Section 7.1.2.9.3](#71293-precertificate-poison) |
| Signed Certificate Timestamp List | MUST NOT | - | |
| Any other extension | \* | \* | The order, criticality, and encoded values of all other extensions MUST be byte-for-byte identical to the `extensions` field of the Certificate |
**Note**: This requirement is expressing that if the Precertificate Poison extension is removed from the Precertificate, and the Signed Certificate Timestamp List is removed from the certificate, the contents of the `extensions` field MUST be byte-for-byte identical to the Certificate.
##### 7.1.2.9.2 Precertificate Profile Extensions - Precertificate CA Issued
These extensions apply in the context of a Precertificate from a Precertificate Signing CA Certificate, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile). For such Precertificates, the `authorityKeyIdentifier`, if present in the Certificate, is modified in the Precertificate, as described in [RFC 6962, Section 3.2](https://tools.ietf.org/doc/html/rfc6962#section-3.2).
| **Extension** | **Presence** | **Critical** | **Description** |
| ---------------------------------------------------- | ------------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| Precertificate Poison (OID: 1.3.6.1.4.1.11129.2.4.3) | MUST | Y | See [Section 7.1.2.9.3](#71293-precertificate-poison) |
| `authorityKeyIdentifier` | \* | \* | See [Section 7.1.2.9.4](#71294-precertificate-authority-key-identifier) |
| Signed Certificate Timestamp List | MUST NOT | - | |
| Any other extension | \* | \* | The order, criticality, and encoded values of all other extensions MUST be byte-for-byte identical to the `extensions` field of the Certificate |
##### 7.1.2.9.3 Precertificate Poison
The Precertificate MUST contain the Precertificate Poison extension (OID: 1.3.6.1.4.1.11129.2.4.3).
This extension MUST have an `extnValue` `OCTET STRING` which is exactly the hex-encoded bytes `0500`, the encoded representation of the ASN.1 NULL value, as specified in [RFC 6962, Section 3.1](https://tools.ietf.org/doc/html/rfc6962#section-3.1).
##### 7.1.2.9.4 Precertificate Authority Key Identifier
For Precertificates issued by a Precertificate Signing CA, the contents of the `authorityKeyIdentifier` extension MUST be one of the following:
1. SHOULD be as defined in the profile below, or;
2. MAY be byte-for-byte identical with the contents of the `authorityKeyIdentifier` extension of the corresponding Certificate.
| **Field** | **Description** |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `keyIdentifier` | MUST be present. MUST be identical to the `subjectKeyIdentifier` field of the [Precertificate Signing CA Certificate](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) |
| `authorityCertIssuer` | MUST NOT be present |
| `authorityCertSerialNumber` | MUST NOT be present |
**Note**: [RFC 6962](https://datatracker.ietf.org/doc/html/rfc6962) describes how the `authorityKeyIdentifier` present on a Precertificate is transformed to contain the value of the Precertificate Signing CA's `authorityKeyIdentifier` extension (i.e. reflecting the actual issuer certificate's `keyIdentifier`), thus matching the corresponding Certificate when verified by clients. These Baseline Requirements RECOMMEND the use of the Precertificate Signing CA's `keyIdentifier` in Precertificates issued by it in order to ensure consistency between the `subjectKeyIdentifier` and `authorityKeyIdentifier` of all certificates in the chain. Although [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) does not strictly require such consistency, a number of client implementations enforce such consistency for Certificates, and this avoids any risks from Certificate Transparency Logs incorrectly implementing such checks.
#### 7.1.2.10 Common CA Fields
This section contains several fields that are common among multiple CA Certificate profiles. However, these fields may not be common among all CA Certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in [Section 7.1.2](#712-certificate-content-and-extensions).
##### 7.1.2.10.1 CA Certificate Validity
| **Field** | **Minimum** | **Maximum** |
| ----------- | ------------------------------------ | ------------------- |
| `notBefore` | One day prior to the time of signing | The time of signing |
| `notAfter` | The time of signing | Unspecified |
##### 7.1.2.10.2 CA Certificate Naming
All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms).
The following table details the acceptable `AttributeType`s that may appear within the `type` field of an `AttributeTypeAndValue`, as well as the contents permitted within the `value` field.
| **Attribute Name** | **Presence** | **Value** | **Verification** |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- |
| `countryName` | MUST | The two-letter ISO 3166-1 country code for the country in which the CA's place of business is located. | [Section 3.2.2.3](#3223-verification-of-country) |
| `stateOrProvinceName` | MAY | If present, the CA's state or province information. | [Section 3.2.2.1](#3221-identity) |
| `localityName` | MAY | If present, the CA's locality. | [Section 3.2.2.1](#3221-identity) |
| `postalCode` | MUST NOT | SECOM Trust Systems does not certificates issue containing the Attribute Name. | [Section 3.2.2.1](#3221-identity) |
| `streetAddress` | MUST NOT | SECOM Trust Systems does not certificates issue containing the Attribute Name. | [Section 3.2.2.1](#3221-identity) |
| `organizationName` | MUST | The CA's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) |
| `organizationalUnitName` | This attribute MUST NOT be included in Root CA Certificates defined in [Section 7.1.2.1](#7121-root-ca-certificate-profile) or TLS Subordinate CA Certificates defined in [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile) or Technically-Constrained TLS Subordinate CA Certificates defined in [Section 7.1.2.6](#7126-tls-subordinate-ca-certificate-profile). This attribute SHOULD NOT be included in other types of CA Certificates. | - | - |
| `commonName` | MUST | The contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate. | |
| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.4](#7144-other-subject-attributes) |
##### 7.1.2.10.3 CA Certificate Authority Information Access
If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `accessLocation` MUST be encoded as the specified `GeneralName` type.
The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied.
| **Access Method** | **OID** | **Access Location** | **Presence** | **Maximum** | **Description** |
| ----------------- | ------------------ | --------------------------- | ------------ | ----------- | ---------------------------------------------- |
| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. |
| `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's certificate. |
| Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. |
##### 7.1.2.10.4 CA Certificate Basic Constraints
| **Field** | **Description** |
| ------------------- | ---------------- |
| `cA` | MUST be set TRUE |
| `pathLenConstraint` | MAY be present |
##### 7.1.2.10.5 CA Certificate Certificate Policies
If present, the Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile:
Table: No Policy Restrictions (Affiliated CA)
| **Field** | **Presence** | **Contents** |
| ------------------ | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, and if the Subordinate CA is an Affiliate of the Issuing CA, then the Issuing CA MAY use the `anyPolicy` Policy Identifier, which MUST be the only `PolicyInformation` value. |
| - `anyPolicy` | MUST | |
| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. |
Table: Policy Restricted
| **Field** | **Presence** | **Contents** |
| ----------------------------------------------------------------------------------------- | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `policyIdentifier` | MUST | One of the following policy identifiers: |
| A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The CA MUST include exactly one Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)) directly or transitively issued by this Certificate. |
| `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. |
| Any other identifier | MAY | If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement. |
| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. |
The Policy Restricted profile RECOMMENDS that the first `PolicyInformation` value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier.
**Note**: policyQualifiers is NOT RECOMMENDED to be present in any Certificate issued under this Certificate Profile because this information increases the size of the Certificate without providing any value to a typical Relying Party, and the information may be obtained by other means when necessary.
If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows:
Table: Permitted `policyQualifiers`
| **Qualifier ID** | **Presence** | **Field Type** | **Contents** |
| ------------------------------------ | ------------ | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. |
| Any other qualifier | MUST NOT | - | - |
##### 7.1.2.10.6 CA Certificate Extended Key Usage
| **Key Purpose** | **OID** | **Presence** |
| ---------------------------------- | ----------------------- | --------------- |
| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST |
| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY |
| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT |
| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT |
| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT |
| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT |
| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT |
| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT |
| Any other value | - | NOT RECOMMENDED |
##### 7.1.2.10.7 CA Certificate Key Usage
| **Key Usage** | **Permitted** | **Required** |
| ------------------ | ------------- | ---------------- |
| `digitalSignature` | Y | N[^ocsp_signing] |
| `nonRepudiation` | N | -- |
| `keyEncipherment` | N | -- |
| `dataEncipherment` | N | -- |
| `keyAgreement` | N | -- |
| `keyCertSign` | Y | Y |
| `cRLSign` | Y | Y |
| `encipherOnly` | N | -- |
| `decipherOnly` | N | -- |
[^ocsp_signing]: If a CA Certificate does not assert the `digitalSignature` bit, the CA Private Key MUST NOT be used to sign an OCSP Response. See [Section 7.3](#73-ocsp-profile) for more information.
##### 7.1.2.10.8 CA Certificate Name Constraints
If present, the Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatibility with certain legacy applications that do not support Name Constraints is necessary.
Table: `nameConstraints` requirements
| **Field** | **Description** |
| ------------------- | ---------------------------------------------------------------------------------- |
| `permittedSubtrees` | |
| - `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. |
| -- `base` | See following table. |
| -- `minimum` | MUST NOT be present. |
| -- `maximum` | MUST NOT be present. |
| `excludedSubtrees` | |
| - `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. |
| -- `base` | See following table. |
| -- `minimum` | MUST NOT be present. |
| -- `maximum` | MUST NOT be present. |
The following table contains the requirements for the `GeneralName` that appears within the `base` of a `GeneralSubtree` in either the `permittedSubtrees` or `excludedSubtrees`.
Table: `GeneralName` requirements for the `base` field
| **Name Type** | **Presence** | **Permitted Subtrees** | **Excluded Subtrees** |
| --------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `dNSName` | MAY | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. |
| `iPAddress` | MUST NOT | SECOM Trust Systems does not issue TLS Server Subscriber (End-Entity) Certificates containing the IPv4 or IPv6 address. | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. |
| `directoryName` | MAY | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | It is NOT RECOMMENDED to include values within `excludedSubtrees`. |
| `rfc822Name` | NOT RECOMMENDED | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. If no `rfc822Name` instance is present in the `permittedSubtrees`, then the CA MAY include a zero-length `rfc822Name` to indicate no mailboxes are permitted. |
| `otherName` | NOT RECOMMENDED | See below | See below |
| Any other value | NOT RECOMMENDED | - | - |
Any `otherName`, if present:
1. MUST apply in the context of the public Internet, unless:
a. the `type-id` falls within an OID arc for which the Applicant demonstrates ownership, or,
b. the Applicant can otherwise demonstrate the right to assert the data in a public context.
2. MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA.
3. MUST be DER encoded according to the relevant ASN.1 module defining the `otherName` `type-id` and `value`.
CAs SHALL NOT include additional names unless the CA is aware of a reason for including the data in the Certificate.
#### 7.1.2.11 Common Certificate Fields
This section contains several fields that are common among multiple certificate profiles. However, these fields may not be common among all certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in [Section 7.1.2](#712-certificate-content-and-extensions).
##### 7.1.2.11.1 Authority Key Identifier
| **Field** | **Description** |
| --------------------------- | ----------------------------------------------------------------------------------------- |
| `keyIdentifier` | MUST be present. MUST be identical to the `subjectKeyIdentifier` field of the Issuing CA. |
| `authorityCertIssuer` | MUST NOT be present |
| `authorityCertSerialNumber` | MUST NOT be present |
##### 7.1.2.11.2 CRL Distribution Points
The CRL Distribution Points extension MUST be present in:
- Subordinate CA Certificates; and
- Subscriber Certificates that 1) do not qualify as "Short-lived Subscriber Certificates" and 2) do not include an authorityInformationAccess extension with an id-ad-ocsp accessMethod.
The CRL Distribution Points extension SHOULD NOT be present in:
- Root CA Certificates.
The CRL Distribution Points extension is OPTIONAL in:
- Short-lived Subscriber Certificates.
The CRL Distribution Points extension MUST NOT be present in:
- OCSP Responder Certificates.
When present, the CRL Distribution Points extension MUST contain at least one `DistributionPoint`; containing more than one is NOT RECOMMENDED. All `DistributionPoint` items must be formatted as follows:
Table: `DistributionPoint` profile
| **Field** | **Presence** | **Description** |
| ------------------- | ------------ | ------------------------------------------------------------------------------ |
| `distributionPoint` | MUST | The `DistributionPointName` MUST be a `fullName` formatted as described below. |
| `reasons` | MUST NOT | |
| `cRLIssuer` | MUST NOT | |
A `fullName` MUST contain at least one `GeneralName`; it MAY contain more than one. All `GeneralName`s MUST be of type `uniformResourceIdentifier`, and the scheme of each MUST be "http". The first `GeneralName` must contain the HTTP URL of the Issuing CA's CRL service for this certificate.
##### 7.1.2.11.3 Signed Certificate Timestamp List
If present, the Signed Certificate Timestamp List extension contents MUST be an `OCTET STRING` containing the encoded `SignedCertificateTimestampList`, as specified in [RFC 6962, Section 3.3](https://tools.ietf.org/html/rfc6962#section-3.3).
Each `SignedCertificateTimestamp` included within the `SignedCertificateTimestampList` MUST be for a `PreCert` `LogEntryType` that corresponds to the current certificate.
##### 7.1.2.11.4 Subject Key Identifier
If present, the `subjectKeyIdentifier` MUST be set as defined within [RFC 5280, Section 4.2.1.2](https://tools.ietf.org/html/rfc5280#section-4.2.1.2). The CA MUST generate a `subjectKeyIdentifier` that is unique within the scope of all Certificates it has issued for each unique public key (the `subjectPublicKeyInfo` field of the `tbsCertificate`). For example, CAs may generate the subject key identifier using an algorithm derived from the public key, or may generate a sufficiently-large unique number, such as by using a CSPRNG.
##### 7.1.2.11.5 Other Extensions
All extensions and extension values not directly addressed by the applicable certificate profile:
1. MUST apply in the context of the public Internet, unless:
a. the extension OID falls within an OID arc for which the Applicant demonstrates ownership, or,
b. the Applicant can otherwise demonstrate the right to assert the data in a public context.
2. MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA (such as including an extension that indicates a Private Key is stored on a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance).
3. MUST be DER encoded according to the relevant ASN.1 module defining the extension and extension values.
CAs SHALL NOT include additional extensions or values unless the CA is aware of a reason for including the data in the Certificate.
### 7.1.3 Algorithm object identifiers
#### 7.1.3.1 SubjectPublicKeyInfo
The following requirements apply to the `subjectPublicKeyInfo` field within a Certificate or Precertificate. No other encodings are permitted.
##### 7.1.3.1.1 RSA
The CA SHALL indicate an RSA key using the rsaEncryption (OID: 1.2.840.113549.1.1.1) algorithm identifier. The parameters MUST be present, and MUST be an explicit NULL.
The CA SHALL NOT use a different algorithm, such as the id-RSASSA-PSS (OID: 1.2.840.113549.1.1.10) algorithm identifier, to indicate an RSA key.
When encoded, the `AlgorithmIdentifier` for RSA keys MUST be byte-for-byte identical with the following hex-encoded bytes: `300d06092a864886f70d0101010500`
##### 7.1.3.1.2 ECDSA
The CA SHALL indicate an ECDSA key using the id-ecPublicKey (OID: 1.2.840.10045.2.1) algorithm identifier. The parameters MUST use the `namedCurve` encoding.
- For P-256 keys, the `namedCurve` MUST be secp256r1 (OID: 1.2.840.10045.3.1.7).
- For P-384 keys, the `namedCurve` MUST be secp384r1 (OID: 1.3.132.0.34).
- For P-521 keys, the `namedCurve` MUST be secp521r1 (OID: 1.3.132.0.35).
When encoded, the `AlgorithmIdentifier` for ECDSA keys MUST be byte-for-byte identical with the following hex-encoded bytes:
- For P-256 keys, `301306072a8648ce3d020106082a8648ce3d030107`.
- For P-384 keys, `301006072a8648ce3d020106052b81040022`.
- For P-521 keys, `301006072a8648ce3d020106052b81040023`.
#### 7.1.3.2 Signature AlgorithmIdentifier
All objects signed by a CA Private Key MUST conform to Baseline Requirements on the use of the `AlgorithmIdentifier` or `AlgorithmIdentifier`-derived type in the context of signatures.
In particular, it applies to all of the following objects and fields:
- The `signatureAlgorithm` field of a Certificate or Precertificate.
- The `signature` field of a TBSCertificate (for example, as used by either a Certificate or Precertificate).
- The `signatureAlgorithm` field of a CertificateList
- The `signature` field of a TBSCertList
- The `signatureAlgorithm` field of a BasicOCSPResponse.
No other encodings are permitted for these fields.
##### 7.1.3.2.1 RSA
The CA SHALL use one of the following signature algorithms and encodings. When encoded, the `AlgorithmIdentifier` MUST be byte-for-byte identical with the specified hex-encoded bytes.
- RSASSA-PKCS1-v1_5 with SHA-256:
Encoding:
`300d06092a864886f70d01010b0500`.
- RSASSA-PKCS1-v1_5 with SHA-384:
Encoding:
`300d06092a864886f70d01010c0500`.
- RSASSA-PKCS1-v1_5 with SHA-512:
Encoding:
`300d06092a864886f70d01010d0500`.
- RSASSA-PSS with SHA-256, MGF-1 with SHA-256, and a salt length of 32 bytes:
Encoding:
```hexdump
304106092a864886f70d01010a3034a00f300d0609608648016503040201
0500a11c301a06092a864886f70d010108300d0609608648016503040201
0500a203020120
```
- RSASSA-PSS with SHA-384, MGF-1 with SHA-384, and a salt length of 48 bytes:
Encoding:
```hexdump
304106092a864886f70d01010a3034a00f300d0609608648016503040202
0500a11c301a06092a864886f70d010108300d0609608648016503040202
0500a203020130
```
- RSASSA-PSS with SHA-512, MGF-1 with SHA-512, and a salt length of 64 bytes:
Encoding:
```hexdump
304106092a864886f70d01010a3034a00f300d0609608648016503040203
0500a11c301a06092a864886f70d010108300d0609608648016503040203
0500a203020140
```
In addition, the CA MAY use the following signature algorithm and encoding if all of the following conditions are met:
- If used within a Certificate, such as the `signatureAlgorithm` field of a Certificate or the `signature` field of a TBSCertificate:
- The new Certificate is a Root CA Certificate or Subordinate CA Certificate that is a Cross-Certificate; and,
- There is an existing Certificate, issued by the same issuing CA Certificate, using the following encoding for the signature algorithm; and,
- The existing Certificate has a `serialNumber` that is at least 64-bits long; and,
- The only differences between the new Certificate and existing Certificate are one of the following:
- A new `subjectPublicKey` within the `subjectPublicKeyInfo`, using the same algorithm and key size; and/or,
- A new `serialNumber`, of the same encoded length as the existing Certificate; and/or
- The new Certificate's `extKeyUsage` extension is present, has at least one key purpose specified, and none of the key purposes specified are the id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) or the anyExtendedKeyUsage (OID: 2.5.29.37.0) key purposes; and/or
- The new Certificate's `basicConstraints` extension has a pathLenConstraint that is zero.
- If used within an OCSP response, such as the `signatureAlgorithm` of a BasicOCSPResponse:
- The `producedAt` field value of the ResponseData MUST be earlier than 2022-06-01 00:00:00 UTC; and,
- All unexpired, un-revoked Certificates that contain the Public Key of the CA Key Pair and that have the same Subject Name MUST also contain an `extKeyUsage` extension with the only key usage present being the id-kp-ocspSigning (OID: 1.3.6.1.5.5.7.3.9) key usage.
- If used within a CRL, such as the `signatureAlgorithm` field of a CertificateList or the `signature` field of a TBSCertList:
- The CRL is referenced by one or more Root CA or Subordinate CA Certificates; and,
- The Root CA or Subordinate CA Certificate has issued one or more Certificates using the following encoding for the signature algorithm.
**Note**: The above requirements do not permit a CA to sign a Precertificate with this encoding.
- RSASSA-PKCS1-v1_5 with SHA-1:
Encoding:
`300d06092a864886f70d0101050500`
##### 7.1.3.2.2 ECDSA
The CA SHALL use the appropriate signature algorithm and encoding based upon the signing key used.
If the signing key is P-256, the signature MUST use ECDSA with SHA-256. When encoded, the `AlgorithmIdentifier` MUST be byte-for-byte identical with the following hex-encoded bytes: `300a06082a8648ce3d040302`.
If the signing key is P-384, the signature MUST use ECDSA with SHA-384. When encoded, the `AlgorithmIdentifier` MUST be byte-for-byte identical with the following hex-encoded bytes: `300a06082a8648ce3d040303`.
If the signing key is P-521, the signature MUST use ECDSA with SHA-512. When encoded, the `AlgorithmIdentifier` MUST be byte-for-byte identical with the following hex-encoded bytes: `300a06082a8648ce3d040304`.
### 7.1.4 Name Forms
Attribute values SHALL be encoded according to [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280).
This section details encoding rules that apply to all Certificates issued by a CA. Further restrictions may be specified within [Section 7.1.2](#712-certificate-content-and-extensions), but these restrictions do not supersede Baseline Requirements.
#### 7.1.4.1 Name Encoding
The following requirements apply to all Certificates listed in [Section 7.1.2](#712-certificate-content-and-extensions). Specifically, this includes Technically Constrained Non-TLS Subordinate CA Certificates, as defined in [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile), but does not include certificates issued by such CA Certificates, as they are out of scope of these Baseline Requirements.
For every valid Certification Path (as defined by [RFC 5280, Section 6](https://tools.ietf.org/html/rfc5280#section-6)):
- For each Certificate in the Certification Path, the encoded content of the Issuer Distinguished Name field of a Certificate SHALL be byte-for-byte identical with the encoded form of the Subject Distinguished Name field of the Issuing CA certificate.
- For each CA Certificate in the Certification Path, the encoded content of the Subject Distinguished Name field of a Certificate SHALL be byte-for-byte identical among all Certificates whose Subject Distinguished Names can be compared as equal according to [RFC 5280, Section 7.1](https://tools.ietf.org/html/rfc5280#section-7.1), and including expired and revoked Certificates.
When encoding a `Name`, the CA SHALL ensure that:
- Each `Name` MUST contain an `RDNSequence`.
- Each `RelativeDistinguishedName` MUST contain exactly one `AttributeTypeAndValue`.
- Each `RelativeDistinguishedName`, if present, is encoded within the `RDNSequence` in the order that it appears in [Section 7.1.4.2](#7142-subject-attribute-encoding).
- For example, a `RelativeDistinguishedName` that contains a `countryName` `AttributeTypeAndValue` pair MUST be encoded within the `RDNSequence` before a `RelativeDistinguishedName` that contains a `stateOrProvinceName` `AttributeTypeAndValue`.
- Each `Name` MUST NOT contain more than one instance of a given `AttributeTypeAndValue` across all `RelativeDistinguishedName`s unless explicitly allowed in Baseline Requirements.
**Note**: [Section 7.1.2.2.2](#71222-cross-certified-subordinate-ca-naming) provides an exception to the above `Name` encoding requirements when issuing a [Cross-Certified Subordinate CA Certificate](#7122-cross-certified-subordinate-ca-certificate-profile), as described within that section.
#### 7.1.4.2 Subject Attribute Encoding
This document defines requirements for the content and validation of a number of attributes that may appear within the `subject` field of a `tbsCertificate`. CAs SHALL NOT include these attributes unless their content has been validated as specified by, and only if permitted by, the relevant certificate profile specified within [Section 7.1.2](#712-certificate-content-and-extensions).
CAs that include attributes in the Certificate `subject` field that are listed in the table below SHALL encode those attributes in the relative order as they appear in the table and follow the specified encoding requirements for the attribute.
Table: Encoding and Order Requirements for Selected Attributes
| **Attribute** | **OID** | **Specification** | **Encoding Requirements** | **Max Length[^maxlength]** |
| ------------------------ | ---------------------------- | ----------------------------------------------- | ------------------------------------------ | -------------------------- |
| `domainComponent` | `0.9.2342.19200300.100.1.25` | [RFC 4519](https://tools.ietf.org/html/rfc4519) | MUST use `IA5String` | 63 |
| `countryName` | `2.5.4.6` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 2 |
| `stateOrProvinceName` | `2.5.4.8` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 |
| `localityName` | `2.5.4.7` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 |
| `organizationName` | `2.5.4.10` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 |
| `organizationalUnitName` | `2.5.4.11` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 |
| `commonName` | `2.5.4.3` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 |
CAs that include attributes in the Certificate `subject` field that are listed in the table below SHALL follow the specified encoding requirements for the attribute.
Table: Encoding Requirements for Selected Attributes
| **Attribute** | **OID** | **Specification** | **Encoding Requirements** | **Max Length[^maxlength]** |
| ------------------------ | -------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------ | -------------------------- |
| `businessCategory` | `2.5.4.15` | X.520 | MUST use `UTF8String` or `PrintableString` | 128 |
| `jurisdictionCountry` | `1.3.6.1.4.1.311.60.2.1.3` | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `PrintableString` | 2 |
| `serialNumber` | `2.5.4.5` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 64 |
| `organizationIdentifier` | `2.5.4.97` | X.520 | MUST use `UTF8String` or `PrintableString` | None |
[^maxlength]: **Note**: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits.
#### 7.1.4.3 Subscriber Certificate Common Name Attribute
If present, this attribute MUST contain exactly one entry that is one of the values contained in the Certificate's `subjectAltName` extension (see [Section 7.1.2.7.12](#712712-subscriber-certificate-subject-alternative-name)). The value of the field MUST be encoded as follows:
- If the value is a Fully-Qualified Domain Name or Wildcard Domain Name, then the value MUST be encoded as a character-for-character copy of the `dNSName` entry value from the `subjectAltName` extension. Specifically, all Domain Labels of the Fully-Qualified Domain Name or FQDN portion of the Wildcard Domain Name must be encoded as LDH Labels, and P-Labels MUST NOT be converted to their Unicode representation.
#### 7.1.4.4 Other Subject Attributes
When explicitly stated as permitted by the relevant certificate profile specified within [Section 7.1.2](#712-certificate-content-and-extensions), CAs MAY include additional attributes within the `AttributeTypeAndValue` beyond those specified in [Section 7.1.4.2](#7142-subject-attribute-encoding).
### 7.1.5 Name constraints
No stipulation.
### 7.1.6 Certificate policy object identifier
#### 7.1.6.1 Reserved Certificate Policy Identifiers
The following Certificate Policy identifiers are reserved for use by CAs as an optional means of asserting that a Certificate complies with Baseline Requirements, EV Guidelines, Baseline Requirements for Code Signing Certificates and S/MIME Baseline Requirements.
| Reserved Certificate Policy Identifiers |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) domain-validated(1)} (2.23.140.1.2.1)` |
| `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) organization-validated(2)} (2.23.140.1.2.2)` |
| `{joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140) certificate‐policies(1) ev-guidelines(1)} (2.23.140.1.1)` |
| `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) code-signing-requirements(4) code signing(1)} (2.23.140.1.4.1)` |
| `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) mailbox-validated (1) strict (3)} (2.23.140.1.5.1.3)` |
| `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) organization-validated (2) legacy (1)} (2.23.140.1.5.2.1)` |
| `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) organization-validated (2) strict (3)} (2.23.140.1.5.2.3)` |
### 7.1.7 Usage of Policy Constraints extension
Not set.
### 7.1.8 Policy qualifiers syntax and semantics
For the policy qualifier, the URI of the Web page that publishes this CP/CPS MAY be stored.
### 7.1.9 Processing semantics for the critical Certificate Policies extension
Not set.
## 7.2 CRL profile
**[TLS Server Certificates]**
Prior to 2024‐03‐15, the CA SHALL issue CRLs in accordance with the profile specified in Baseline Requirements or the profile specified in Version 1.8.7 of the Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates. Effective 2024‐03‐15, the CA SHALL issue CRLs in accordance with the profile specified in Baseline Requirements.
If the CA asserts compliance with these Baseline Requirements, all CRLs that it issues MUST comply with the following CRL profile, which incorporates, and is derived from [RFC 5280](https://tools.ietf.org/html/rfc5280). Except as explicitly noted, all normative requirements imposed by RFC 5280 shall apply, in addition to the normative requirements imposed by this document. CAs SHOULD examine [RFC 5280, Appendix B](https://tools.ietf.org/html/rfc5280#appendix-B) for further issues to be aware of.
A full and complete CRL is a CRL whose scope includes all Certificates issued by the CA.
A partitioned CRL (sometimes referred to as a "sharded CRL") is a CRL with a constrained scope, such as all Certificates issued by the CA during a certain period of time ("temporal sharding"). Aside from the presence of the Issuing Distribution Point extension (OID 2.5.29.28) in partitioned CRLs, both CRL formats are syntactically the same from the perspective of this profile.
Minimally, CAs MUST issue either a "full and complete" CRL or a set of "partitioned" CRLs which cover the complete set of Certificates issued by the CA within 7 days of such CA issuing its first certificate. In other words, if issuing only partitioned CRLs, the combined scope of those CRLs must be equivalent to that of a full and complete CRL.
CAs MUST NOT issue indirect CRLs (i.e., the issuer of the CRL is not the issuer of all Certificates that are included in the scope of the CRL).
**[Common to all certificates]**
Table: CRL Fields
| **Field** | **Presence** | **Description** |
| ----------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `tbsCertList` | | |
| - `version` | MUST | MUST be v2(1), see [Section 7.2.1](#721-version-numbers) |
| - `signature` | MUST | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) |
| - `issuer` | MUST | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. |
| - `thisUpdate` | MUST | Indicates the issue date of the CRL. |
| - `nextUpdate` | MUST | Indicates the date by which the next CRL will be issued. For CRLs covering Subscriber Certificates, at most 10 days after the `thisUpdate`. For other CRLs, at most 12 months after the `thisUpdate`. |
| - `revokedCertificates` | * | MUST be present if the CA has issued a Certificate that has been revoked and the corresponding entry has yet to appear on at least one regularly scheduled CRL beyond the revoked Certificate's validity period. The CA SHOULD remove an entry for a corresponding Certificate after it has appeared on at least one regularly scheduled CRL beyond the revoked Certificate's validity period. See the "revokedCertificates Component" table for additional requirements. |
| - `extensions` | MUST | See the "CRL Extensions" table for additional requirements. |
| `signatureAlgorithm` | MUST | Encoded value MUST be byte-for-byte identical to the `tbsCertList.signature`. |
| `signature` | MUST | - |
| Any other value | NOT RECOMMENDED | - |
### 7.2.1 Version number(s)
Certificate Revocation Lists MUST be of type X.509 v2.
### 7.2.2 CRL and CRL entry extensions
Table: CRL Extensions
| **Extension** | **Presence** | **Critical** | **Description** |
| -------------------------- | --------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------ |
| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) |
| `CRLNumber` | MUST | N | MUST contain an INTEGER greater than or equal to zero (0) and less than 2¹⁵⁹, and convey a strictly increasing sequence. |
| `IssuingDistributionPoint` | * | Y | See [Section 7.2.2.1 CRL Issuing Distribution Point](#7221-crl-issuing-distribution-point) |
| Any other extension | NOT RECOMMENDED | - | - |
Table: revokedCertificates Component
| **Component** | **Presence** | **Description** |
| -------------------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
| `serialNumber` | MUST | MUST be byte-for-byte identical to the serialNumber contained in the revoked Certificate. |
| `revocationDate` | MUST | Normally, the date and time revocation occurred. See the footnote following this table for circumstances where backdating is permitted. |
| `crlEntryExtensions` | * | See the "crlEntryExtensions Component" table for additional requirements. |
**Note:** **[TLS Server Certificates]** The CA SHOULD update the revocation date in a CRL entry when it is determined that the private key of the Certificate was compromised prior to the revocation date that is indicated in the CRL entry for that Certificate. Backdating the revocationDate field is an exception to best practice described in RFC 5280 (Section 5.3.2); however, Baseline Requirements specify the use of the revocationDate field to support TLS implementations that process the revocationDate field as the date when the Certificate is first considered to be compromised.
Table: crlEntryExtensions Component
| **CRL Entry Extension** | **Presence** | **Description** |
| ----------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `reasonCode` | * | When present (OID 2.5.29.21), MUST NOT be marked critical and MUST indicate the most appropriate reason for revocation of the Certificate.
MUST be present unless the CRL entry is for a Certificate not technically capable of causing issuance and either 1) the CRL entry is for a Subscriber Certificate subject to Baseline Requirements revoked prior to 2023-07-15 or 2) the reason for revocation (i.e., reasonCode) is unspecified (0).
See the "CRLReasons" table for additional requirements. |
| Any other value | NOT RECOMMENDED | - |
Table: CRLReasons
| **RFC 5280 reasonCode** | **RFC 5280 reasonCode value** | **Description** |
| ----------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| unspecified | 0 | Represented by the omission of a reasonCode. MUST be omitted if the CRL entry is for a Certificate not technically capable of causing issuance unless the CRL entry is for a Subscriber Certificate subject to Baseline Requirements revoked prior to 2023-07-15. |
| keyCompromise | 1 | Indicates that it is known or suspected that the Subscriber’s Private Key has been compromised. |
| affiliationChanged | 3 | Indicates that the Subject's name or other Subject Identity Information in the Certificate has changed, but there is no cause to suspect that the Certificate's Private Key has been compromised. |
| superseded | 4 | Indicates that the Certificate is being replaced because: the Subscriber has requested a new Certificate, the CA has reasonable evidence that the validation of domain authorization or control for any fully‐qualified domain name or IP address in the Certificate should not be relied upon, or the CA has revoked the Certificate for compliance reasons such as the Certificate does not comply with these Baseline Requirements or the CA's CP or CPS. |
| cessationOfOperation | 5 | Indicates that the website with the Certificate is shut down prior to the expiration of the Certificate, or if the Subscriber no longer owns or controls the Domain Name in the Certificate prior to the expiration of the Certificate. |
| certificateHold | 6 | MUST NOT be included if the CRL entry is for 1) a Certificate subject to Baseline Requirements, or 2) a Certificate not subject to Baseline Requirements and was either A) issued on-or-after 2020-09-30 or B) has a `notBefore` on-or-after 2020-09-30. |
| privilegeWithdrawn | 9 | Indicates that there has been a subscriber-side infraction that has not resulted in keyCompromise, such as the Certificate Subscriber provided misleading information in their Certificate Request or has not upheld their material obligations under the Subscriber Agreement or Terms of Use. |
The Subscriber Agreement, or an online resource referenced therein, MUST inform Subscribers about the revocation reason options listed above and provide explanation about when to choose each option. Tools that the CA provides to the Subscriber MUST allow for these options to be easily specified when the Subscriber requests revocation of their Certificate, with the default value being that no revocation reason is provided (i.e. the default corresponds to the CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL).
The privilegeWithdrawn reasonCode SHOULD NOT be made available to the Subscriber as a revocation reason option, because the use of this reasonCode is determined by the CA and not the Subscriber.
When a CA obtains verifiable evidence of Key Compromise for a Certificate whose CRL entry does not contain a reasonCode extension or has a reasonCode extension with a non-keyCompromise reason, the CA SHOULD update the CRL entry to enter keyCompromise as the CRLReason in the reasonCode extension.
#### 7.2.2.1 CRL Issuing Distribution Point
Partitioned CRLs MUST contain an Issuing Distribution Point extension. The `distributionPoint` field of the Issuing Distribution Point extension MUST be present. Additionally, the `fullName` field of the DistributionPointName value MUST be present, and its value MUST conform to the following requirements:
1. If a Certificate within the scope of the CRL contains a CRL Distribution Points extension, then at least one of the `uniformResourceIdentifiers` in the CRL Distribution Points's `fullName` field MUST be included in the `fullName` field of the CRL's Issuing Distribution Point extension. The encoding of the `uniformResourceIdentifier` value in the Issuing Distribution Point extension SHALL be byte-for-byte identical to the encoding used in the Certificate's CRL Distribution Points extension.
2. Other GeneralNames of type `uniformResourceIdentifier` MAY be included.
3. Non-`uniformResourceIdentifier` GeneralName types MUST NOT be included.
The `indirectCRL` and `onlyContainsAttributeCerts` fields MUST be set to `FALSE` (i.e., not asserted).
The CA MAY set either of the `onlyContainsUserCerts` and `onlyContainsCACerts` fields to `TRUE`, depending on the scope of the CRL.
The CA MUST NOT assert both of the `onlyContainsUserCerts` and `onlyContainsCACerts` fields.
The `onlySomeReasons` field SHOULD NOT be included; if included, then the CA MUST provide another CRL whose scope encompasses all revocations regardless of reason code.
This extension is NOT RECOMMENDED for full and complete CRLs.
## 7.3 OCSP profile
If an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross-Certified Subordinate CA Certificates, and that certificate has been revoked, then the `revocationReason` field within the `RevokedInfo` of the `CertStatus` MUST be present.
The `CRLReason` indicated MUST contain a value permitted for CRLs, as specified in [Section 7.2.2](#722-crl-and-crl-entry-extensions).
### 7.3.1 Version number(s)
The CA uses OCSP Version 1.
### 7.3.2 OCSP extensions
The `singleExtensions` of an OCSP response MUST NOT contain the `reasonCode` (OID 2.5.29.21) CRL entry extension.
# 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
The CA SHALL at all times:
1. Issue Certificates and operate its PKI in accordance with all law applicable to its business and the Certificates it issues in every jurisdiction in which it operates;
2. Comply with Baseline Requirements;
3. Comply with the audit requirements specified in the CP/CPS; and
4. Be licensed as a CA in each jurisdiction where it operates, if licensing is required by the law of such jurisdiction for the issuance of Certificates.
## 8.1 Frequency or circumstances of assessment
Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile), [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile), or [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), as well as audited in line with [Section 8.7](#87-self-audits) only, or Unconstrained and fully audited in line with all remaining requirements from this section. A Certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 `basicConstraints` extension, with the `cA` boolean set to true and is therefore by definition a Root CA Certificate or a Subordinate CA Certificate.
The period during which the CA issues Certificates SHALL be divided into an unbroken sequence of audit periods. An audit period MUST NOT exceed one year in duration.
If the CA does not have a currently valid Audit Report indicating compliance with one of the audit schemes listed in [Section 8.4](#84-topics-covered-by-assessment), then, before issuing Publicly-Trusted Certificates, the CA SHALL successfully complete a point-in-time readiness assessment performed in accordance with applicable standards under one of the audit schemes listed in [Section 8.4](#84-topics-covered-by-assessment). The point-in-time readiness assessment SHALL be completed no earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates and SHALL be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate.
## 8.2 Identity/qualifications of assessor
The CA's audit SHALL be performed by a Qualified Auditor. A Qualified Auditor means a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively possess the following qualifications and skills:
1. Independence from the subject of the audit;
1. The ability to conduct an audit that addresses the criteria specified in an Eligible Audit Scheme (see [Section 8.4](#84-topics-covered-by-assessment));
1. Employs individuals who have proficiency in examining Public Key Infrastructure technology, information security tools and techniques, information technology and security auditing, and the third-party attestation function;
1. (For audits conducted in accordance with the WebTrust standard) licensed by WebTrust;
1. Bound by law, government regulation, or professional code of ethics; and
1. Except in the case of an Internal Government Auditing Agency, maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage
## 8.3 Assessor's relationship to assessed entity
Auditors shall be operationally and organizationally independent of the assessed entity, except for the audit-related aspects. In conducting the audits, the assessed entity shall provide appropriate support to the effort.
## 8.4 Topics covered by assessment
The CA SHALL undergo an audit in accordance with the following schemes:
1. WebTrust (TLS Server CA):
- "Principles and Criteria for Certification Authorities" Version 2.2 or newer; and either
- "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security" Version 2.7 or newer; or
- "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline" Version 2.8 or newer and "WebTrust Principles and Criteria for Certification Authorities – Network Security" Version 1.0 or newer
2. WebTrust (S/MIME CA):
- For Audit Periods starting before the Effective Date defined in [Section 1.2.1](#121-revisions) of the first version of Baseline Requirements, “WebTrust for CAs v2.2.2 or newer”; or
- For Audit Periods starting after the Effective Date defined in [Section 1.2.1](#121-revisions) of the first version of Baseline Requirements, “WebTrust for CAs v2.2.2 or newer” AND “WebTrust for S/MIME Baseline Requirements v1.0.0 or newer”; or
- For Audit Periods starting after 2025-04-01, “WebTrust for CAs v2.2.2 or newer” AND “WebTrust for S/MIME Baseline Requirements v1.0.0 or newer” AND “WebTrust for Network Security v2.0 or newer”;
3. WebTrust (Code Signing CA):
- “WebTrust for CAs v2.0 or newer” AND “WebTrust for Certification Authorities – Code Signing Baseline Requirements v2.0 or newer” AND “WebTrust for Certification Authorities – Network Security – Version 1.0 or newer”;
It MUST incorporate periodic monitoring and/or accountability procedures to ensure that its audits continue to be conducted in accordance with the requirements of the scheme.
The audit MUST be conducted by a Qualified Auditor, as specified in [Section 8.2](#82-identityqualifications-of-assessor).
For Delegated Third Parties which are not Enterprise RAs, then the CA SHALL obtain an audit report, issued under the auditing standards that underlie the accepted audit schemes found in [Section 8.4](#84-topics-covered-by-assessment), that provides an opinion whether the Delegated Third Party's performance complies with either the Delegated Third Party's practice statement or the CA's CP/CPS. If the opinion is that the Delegated Third Party does not comply, then the CA SHALL not allow the Delegated Third Party to continue performing delegated functions.
The audit period for the Delegated Third Party SHALL NOT exceed one year (ideally aligned with the CA's audit).
## 8.5 Actions taken as a result of deficiency
SECOM Trust Systems promptly implements corrective measures with respect to the deficiencies identified in the audit report.
## 8.6 Communication of results
The Audit Report SHALL state explicitly that it covers the relevant systems and processes used in the issuance of all Certificates that assert one or more of the policy identifiers listed in [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers). The CA SHALL make the Audit Report publicly available.
The CA MUST make its Audit Report publicly available no later than three months after the end of the audit period. In the event of a delay greater than three months, the CA SHALL provide an explanatory letter signed by the Qualified Auditor.
The Audit Report MUST contain at least the following clearly-labelled information:
1. name of the organization being audited;
2. name and address of the organization performing the audit;
3. the SHA-256 fingerprint of all Roots and Subordinate CA Certificates, including Cross-Certified Subordinate CA Certificates, that were in-scope of the audit;
4. audit criteria, with version number(s), that were used to audit each of the certificates (and associated keys);
5. a list of the CA policy documents, with version numbers, referenced during the audit;
6. whether the audit assessed a period of time or a point in time;
7. the start date and end date of the Audit Period, for those that cover a period of time;
8. the point in time date, for those that are for a point in time;and
9. the date the report was issued, which will necessarily be after the end date or point in time date.
An authoritative English language version of the publicly available audit information MUST be provided by the Qualified Auditor and the CA SHALL ensure it is publicly available.
The Audit Report MUST be available as a PDF, and SHALL be text searchable for all information required. Each SHA-256 fingerprint within the Audit Report MUST be uppercase letters and MUST NOT contain colons, spaces, or line feeds.
## 8.7 Self-Audits
- TLS Server CA
During the period in which the CA issues Certificates, the CA SHALL monitor adherence to its Certificate Policy, Certification Practice Statement and Baseline Requirements and strictly control its service quality by performing self audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken.
Effective 2025-03-15, the CA SHOULD use a Linting process to verify the technical accuracy of Certificates within the selected sample set independently of previous linting performed on the same Certificates.
Except for Delegated Third Parties that undergo an annual audit that meets the criteria specified in [Section 8.4](#84-topics-covered-by-assessment), the CA SHALL strictly control the service quality of Certificates issued or containing information verified by a Delegated Third Party by having a Validation Specialist employed by the CA perform ongoing quarterly audits against a randomly selected sample of at least the greater of one certificate or three percent of the Certificates verified by the Delegated Third Party in the period beginning immediately after the last sample was taken. The CA SHALL review each Delegated Third Party's practices and procedures to ensure that the Delegated Third Party is in compliance with Baseline Requirements and the relevant CP/CPS.
The CA SHALL internally audit each Delegated Third Party's compliance with Baseline Requirements on an annual basis.
During the period in which a Technically Constrained Subordinate CA issues Certificates, the CA which signed the Subordinate CA SHALL monitor adherence to the CA's Certificate Policy and the Subordinate CA's Certification Practice Statement. On at least a quarterly basis, against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by the Subordinate CA, during the period commencing immediately after the previous audit sample was taken, the CA shall ensure all applicable CP are met.
- EV TLS Server CA
During the period in which it issues EV Certificates, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least three percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. For all EV Certificates where the Final Cross-Correlation and Due Diligence requirements of [Section 3.2.2.2.12](#322212-final-cross-correlation-and-due-diligence-ev-tls-server-certificates) is performed by an RA, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least six percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken.
- S/MIME CA
During the period in which the CA issues Certificates, the CA SHALL monitor adherence to its CP/CPS and S/MIME Baseline Requirements and control its service quality by performing self audits on at least a quarterly basis against a randomly selected sample including a minimum of the greater of thirty (30) Certificates or three percent (3%) of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken.
Effective 2025-03-15 the CA SHOULD use a Linting process to verify the technical accuracy of Certificates within the selected sample set independently of previous linting performed on the same Certificates.
- Code Signing CA
CAs must abide by the self-audit requirements of Baseline Requirements for Code Signing Certificates. During the period in which it issues Code Signing Certificates, the CA MUST strictly control its service quality by performing ongoing self-audits against a randomly selected sample of at least three percent of the Non-EV Code Signing Certificates and at least three percent of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken. For all Code Signing Certificates where the final cross-correlation and due diligence requirements of Section 8 of Baseline Requirements for Code Signing Certificates is performed by an RA, the CA MUST strictly control its service quality by performing ongoing self-audits against a randomly selected sample of at least six percent of the Non-EV Code Signing Certificates and at least six percent of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken.
## 8.8 Review of delegated parties
Except for Delegated Third Parties, Enterprise RAs, and Technically Constrained Subordinate CAs that undergo an annual audit that meets the criteria specified in [Section 8.4](#84-topics-covered-by-assessment), the CA SHALL ensure the practices and procedures of delegated parties are in compliance with these Requirements and the relevant CP and/or CPS. The CA shall document the obligations of delegated parties and perform monitoring on at least an annual basis of the delegated parties' adherence with those obligations.
# 9. OTHER BUSINESS AND LEGAL MATTERS
## 9.1 Fees
### 9.1.1 Certificate issuance or renewal fees
Stipulated separately in contracts.
### 9.1.2 Certificate access fees
No stipulation.
### 9.1.3 Revocation or status information access fees
No stipulation.
### 9.1.4 Fees for other services
No stipulation.
### 9.1.5 Refund policy
Stipulated separately in contracts.
## 9.2 Financial responsibility
### 9.2.1 Insurance coverage
**[EV TLS Server Certificates]**
The CA shall maintain a sufficient financial resources for the operation and maintenance.
The CA SHALL maintain the following insurance related to their respective performance and obligations the EV Guidelines:
A. Commercial General Liability insurance (occurrence form) with policy limits of at least two million US dollars in coverage;
B. Professional Liability/Errors and Omissions insurance, with policy limits of at least five million US dollars in coverage, and including coverage for:
- i. claims for damages arising out of an act, error, or omission, unintentional breach of contract, or neglect in issuing or maintaining EV Certificates,
- ii. claims for damages arising out of infringement of the proprietary rights of any third party (excluding copyright, and trademark infringement), and invasion of privacy and advertising injury.
Such insurance must be with a company rated no less than A- as to Policy Holder's Rating in the current edition of Best's Insurance Guide (or with an association of companies each of the members of which are so rated).
The CA MAY self-insure for liabilities that arise from such party's performance and obligations under these Guidelines provided that it has at least five hundred million US dollars in liquid assets based on audited financial statements in the past twelve months, and a quick ratio (ratio of liquid assets to current liabilities) of not less than 1.0.
### 9.2.2 Other assets
No stipulation.
### 9.2.3 Insurance or warranty coverage for end-entities
No stipulation.
## 9.3 Confidentiality of business information
### 9.3.1 Scope of confidential information
Information on individuals and organizations in the possession of SECOM Trusts Systems are subject to confidentiality with the exception of those that were explicitly published as a part of a Certificate, a CRL, this CP/CPS.
SECOM Trust Systems does not disclose such information externally unless it is required by law or there is a prior consent of the relevant Subscriber. SECOM Trust Systems may disclose the information subject to confidentiality to a legal counsel or a financial adviser who provides advice in connection with such legal, judicial, administrative or other procedures required by law. It may also disclose information subject to confidentiality to an attorney, an accountant, a legal institution or any other specialist who provides advice on corporate mergers, acquisitions or restructuring.
Subscriber Private Keys are deemed to be information to be kept confidential by the Subscriber's own responsibility. The Services in no circumstances provide access to these Keys.
Information contained in Audit Log and the Audit Reports themselves are subject to the confidentiality and within the Scope of Confidential Information. SECOM Trust Systems will not disclose such information to any external party in other situation than a case stipulated in [Section 8.6](#86-communication-of-results) or unless it is required by law.
### 9.3.2 Information not within the scope of confidential information
Information populated in Certificates and CRLs is not considered confidential. In addition, the following information shall not be subject to the confidentiality provisions herein:
- Information that is or came to be known through no fault of SECOM Trust Systems;
- Information that was or is made known to SECOM Trust Systems by a party other than SECOM Trust Systems without confidentiality requirements;
- Information independently developed by SECOM Trust Systems; or
- Information approved for disclosure by the relevant Subscriber.
### 9.3.3 Responsibility to protect confidential information
SECOM Trust Systems may disclose confidential information when required by law or there is a prior consent of the relevant Subscriber. In the event of the foregoing, the party having come to acquire the information may not disclose said information to a third party due to contractual or legal constraints.
## 9.4 Privacy of personal information
### 9.4.1 Privacy plan
SECOM Trust Systems will use the personal information collected from the subscribers of our authentication service to the extent necessary for the operation of this CA operated on the Digital Certification Infrastructure, such as confirming the application details, sending necessary documents, etc., and confirming who is authorized. SECOM Trust Systems's privacy policy will be announced on SECOM Trust Systems's website ().
### 9.4.2 Information treated as private
SECOM Trust Systems treats information defined as personal information based on domestic laws and regulations (such as information collected from subscribers of SECOM authentication services) as personal information and manages it appropriately.
### 9.4.3 Information not deemed private
SECOM Trust Systems treats personal information as specified in [Section 9.4.2](#942-information-treated-as-private).
### 9.4.4 Responsibility to protect private information
SECOM Trust Systems shall not disclose any personal information of the other party that it has learned during the execution and termination of the contract to third parties, whether during or after the contract period. The personal information protection manager shall be appointed and ensure employees comply with personal information protection policy.
### 9.4.5 Notice and consent to use private information
SECOM Trust Systems shall not use personal information for any purpose other than the purpose of obtaining the consent of the certificate subscriber, except as provided by law. The personal number and specific personal information will be used for the purpose of use permitted by law and for the purpose of use with the consent of the certificate subscriber.
### 9.4.6 Disclosure pursuant to judicial or administrative process
If disclosure is requested by law, rule, court decision/order, administrative agency order /instruction, etc., the personal information of the certificate subscriber may be disclosed.
### 9.4.7 Other information disclosure circumstances
No stipulation.
## 9.5 Intellectual property rights
Unless otherwise agreed to between SECOM Trust Systems and Subscribers, the following informative materials and data pertaining to the Services shall belong to the parties specified as below:
| Property | Details |
| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Certificate | An asset belonging to SECOM Trust Systems. |
| CRL | An asset belonging to SECOM Trust Systems. |
| Distinguished Name (DN) | An asset belonging to an entity to which the Name is assigned as long as the fee for the Subscriber Certificate is properly paid. |
| Subscriber Private Key | An asset belonging the possessor of the Private Key that completes a Key Pair with the Public Key, regardless of how it is stored or who possesses the storage medium. |
| Subscriber Public Key | An asset belonging the possessor of the Private Key that completes a Key Pair, regardless of how it is stored or who possesses the storage medium. |
| This CP/CPS | An asset (including the copyrights) belonging to SECOM Trust Systems. This CP/CPS may be reproduced provided that the original document is properly referenced. It is published under the Creative Commons license Attribution-NoDerivatives (CC-BY-ND) 4.0. |
## 9.6 Representations and warranties
### 9.6.1 CA representations and warranties
By issuing a Certificate, the CA makes the certificate warranties listed herein to the following Certificate Beneficiaries:
1. The Subscriber that is a party to the Subscriber Agreement or Terms of Use for the Certificate;
2. All Application Software Suppliers with whom the Root CA has entered into a contract for inclusion of its Root Certificate in software distributed by such Application Software Supplier; and
3. All Relying Parties who reasonably rely on a Valid Certificate.
The CA represents and warrants to the Certificate Beneficiaries that, during the period when the Certificate is valid, the CA has complied with Baseline Requirements and its CP/CPS in issuing and managing the Certificate.
The Certificate Warranties specifically include, but are not limited to, the following:
1. **Right to Use Domain Name [TLS Server Certificates]**: That, at the time of issuance, the CA
i. implemented a procedure for verifying that the Applicant either had the right to use, or had control of, the Domain Name(s) listed in the Certificate's `subject` field and `subjectAltName` extension (or, only in the case of Domain Names, was delegated such right or control by someone who had such right to use or control);
ii. followed the procedure when issuing the Certificate; and
iii. accurately described the procedure in the CA's CP/CPS;
1. **Right to Use Mailbox Address [S/MIME Certificates]**: That, at the time of issuance, the CA:
i. implemented a procedure for verifying that the Applicant either had the right to use, or had control of, the Mailbox Addresses listed in the Certificate's subject field and subjectAltName extension (or was delegated such right or control by someone who had such right to use or control); ii. followed the procedure when issuing the Certificate; and iii. accurately described the procedure in the CA's CP/CPS;
1. **Compliance**. The CA has complied with [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) in issuing each certificate and operating its PKI or delegated services.
1. **Authorization for Certificate**: That, at the time of issuance, the CA
i. implemented a procedure for verifying that the Subject authorized the issuance of the Certificate and that the Applicant Representative is authorized to request the Certificate on behalf of the Subject;
ii. followed the procedure when issuing the Certificate; and
iii. accurately described the procedure in the CA's CP/CPS;
1. **Accuracy of Information**: That, at the time of issuance, the CA
i. implemented a procedure for verifying the accuracy of all of the information contained in the Certificate;
ii. followed the procedure when issuing the Certificate; and
iii. accurately described the procedure in the CA's CP/CPS;
1. **Key Protection:** The CA represents that it provided the Subscriber at the time of issuance with documentation on how to securely store and prevent the misuse of Private Keys associated with Code Signing Certificates and AATL Document Signing Certificates.
1. **Identity of Applicant**: That, if the Certificate contains Subject Identity Information, the CA
i. implemented a procedure to verify the identity of the Applicant in accordance with [Section 3.2](#32-initial-identity-validation) and [Section 7.1.2](#712-certificate-content-and-extensions);
ii. followed the procedure when issuing the Certificate; and
iii. accurately described the procedure in the CA's CP/CPS;
1. **Subscriber Agreement**: That, if the CA and Subscriber are not Affiliated, the Subscriber and CA are parties to a legally valid and enforceable Subscriber Agreement that satisfies [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations), or, if the CA and Subscriber are the same entity or are Affiliated, the Applicant Representative acknowledged the Terms of Use;
1. **Status**: That the CA maintains a 24 x 7 publicly-accessible Repository with current information regarding the status (valid or revoked) of all unexpired Certificates; and
1. **Revocation**: That the CA will revoke the Certificate for any of the reasons specified in [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations).
The Root CA SHALL be responsible for the performance and warranties of the Subordinate CA, for the Subordinate CA's compliance with [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations), and for all liabilities and indemnification obligations of the Subordinate CA under [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations), as if the Root CA were the Subordinate CA issuing the Certificates
### 9.6.2 RA representations and warranties
Same as this CP/CPS [Section 9.6.1](#961-ca-representations-and-warranties).
### 9.6.3 Subscriber representations and warranties
The CA SHALL require, as part of the Subscriber Agreement or Terms of Use, that the Applicant make the commitments and warranties in this section for the benefit of the CA and the Certificate Beneficiaries.
Prior to the issuance of a Certificate, the CA SHALL obtain, for the express benefit of the CA and the Certificate Beneficiaries, either:
1. The Applicant's agreement to the Subscriber Agreement with the CA, or
2. The Applicant's acknowledgement of the Terms of Use.
The CA SHALL implement a process to ensure that each Subscriber Agreement or Terms of Use is legally enforceable against the Applicant. In either case, the Agreement MUST apply to the Certificate to be issued pursuant to the certificate request. The CA MAY use an electronic or "click-through" Agreement provided that the CA has determined that such agreements are legally enforceable. A separate Agreement MAY be used for each certificate request, or a single Agreement MAY be used to cover multiple future certificate requests and the resulting Certificates, so long as each Certificate that the CA issues to the Applicant is clearly covered by that Subscriber Agreement or Terms of Use.
The Subscriber Agreement or Terms of Use MUST contain provisions imposing on the Applicant itself (or made by the Applicant on behalf of its principal or agent under a subcontractor or hosting service relationship) the following obligations and warranties:
1. **Accuracy of Information**: An obligation and warranty to provide accurate and complete information at all times to the CA, both in the certificate request and as otherwise requested by the CA in connection with the issuance of the Certificate(s) to be supplied by the CA;
1. **Protection of Private Key**: An obligation and warranty by the Applicant to take all reasonable measures to assure control of, keep confidential, and properly protect at all times the Private Key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device, e.g. password or token);
**[Code Signing Certificates]**
Where the key is available outside a Signing Service, to maintain sole control of, keep confidential, and properly protect, at all times in accordance with [Section 6.2.7](#627-private-key-storage-on-cryptographic-module), the Private Key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device, e.g. password or token). The CA MUST provide the Subscriber with documentation on how to protect a Private Key. The CA MAY provide this documentation as a white paper or as part of the Subscriber Agreement. The Subscriber MUST represent that it will generate and operate any device storing Private Keys in a secure manner, as described in a document of code signing best practices, which the CA MUST provide to the Subscriber during the ordering process. The CA MUST obligate the Subscriber to use passwords that are randomly generated with at least 16 characters containing uppercase letters, lowercase letters, numbers, and symbols to transport Private Keys.
1. **Private Key Reuse [Code Signing Certificates]**: To not apply for a Code Signing Certificate if the Public Key in the Certificate is or will be used with a non-Code Signing Certificate.
1. **Use of Certificate [Code Signing Certificates]**: To use the Certificate and associated Private Key only for authorized and legal purposes, including not using the Certificate to sign Suspect Code and to use the Certificate and Private Key solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement or Terms of Use.
1. **Use of Certificate [TLS Server Certificates]**: An obligation and warranty to install the Certificate only on servers that are accessible at the `subjectAltName`(s) listed in the Certificate, and to use the Certificate solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement or Terms of Use;
1. **Reporting and Revocation**: An obligation and warranty to:
a. promptly request revocation of the Certificate, and cease using it and its associated Private Key, if there is any actual or suspected misuse or compromise of the Subscriber’s Private Key associated with the Public Key included in the Certificate, and
b. promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate;
1. **Compliance with Industry Standards**: An acknowledgment and acceptance that the CA may modify the Subscriber Agreement or Terms of Use when necessary to comply with any changes in [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations).
1. **Prevention of Misuse:** To provide adequate network and other security controls to protect against misuse of the Private Key and that the CA will revoke the Certificate without requiring prior notification if there is unauthorized access to the Private Keys.
1. **Acceptance of Certificate**: An obligation and warranty that the Subscriber will review and verify the Certificate contents for accuracy;
1. **Sharing of Information [Code Signing Certificates]**: An acknowledgment and acceptance that, if: (a) the Certificate or the Applicant is identified as a source of Suspect Code, (b) the authority to request the Certificate cannot be verified, or (c) the Certificate is revoked for reasons other than Subscriber request (e.g. as a result of Private Key compromise, discovery of malware, etc.), then the CA is authorized to share information about the Applicant, signed application, Certificate, and surrounding circumstances with other CAs or industry groups, including the CA/Browser Forum.
1. **Termination of Use of Certificate**: An obligation and warranty to promptly cease all use of the Private Key corresponding to the Public Key included in the Certificate upon revocation of that Certificate for reasons of Key Compromise. To promptly cease using the Private Key corresponding to the Public Key listed in a Certificate upon expiration or revocation of the Certificate.
1. **Responsiveness**: An obligation to respond to the CA's instructions concerning Key Compromise or Certificate misuse within a specified time period.
1. **Acknowledgment and Acceptance**: An acknowledgment and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber Agreement or Terms of Use or if revocation is required by the CP/CPS, or [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations).
### 9.6.4 Relying party representations and warranties
The Relying Party of the services of the CA has the following obligations:
- Trust the certificate issued by the CA and use the certificate only for the purposes specified by this CA in this CP/CPS.
- When trying to trust a certificate, make sure that the certificate has not been revoked by the CRL or OCSP responder in the repository.
- When trying to trust a certificate, check the validity period of the certificate and confirm that it is within the validity period.
- When trying to trust a certificate issued by this CA, make sure that the certificate can be signed and verified by the CA's certificate.
- Agree to be responsible as a Relying Party as specified in this CP/CPS when trying to trust and use the CA's certificate.
### 9.6.5 Representations and warranties of other participants
No stipulation.
## 9.7 Disclaimers of warranties
The CA is not liable for any direct, special, incidental or consequential damages arising in connection with the warranties stipulated in [Section 9.6.1](#961-ca-representations-and-warranties) and [Section 9.6.2](#962-ra-representations-and-warranties) hereof, or for lost earnings, loss of data, or any other indirect or consequential damages.
## 9.8 Limitations of liability
In this CP/CPS, the CA shall not be liable for the provisions of "9.6.1 CA representations and warranties” and "9.6.2 RA representations and warranties" hereof in the following cases.
- any damage arising from unlawful conduct, unauthorized use, negligence or any other cause not attributable to the CA;
- all liability in any case if the confirmed information error is the result of the applicant's fraud or willful misconduct.
- any damage attributable to the failure of a Subscriber to perform its obligations;
- any damage attributable to a Subscriber or Relying Party system;
- damages attributable to the defect or malfunction or any other behavior of the Subscriber environment (hardware or software);
- Any damage during the period that a Subscriber neglected to pay the subscription fee as set forth in the agreement thereof;
- damages caused by information published in a Certificate, a CRL or on the OCSP responder due to the reasons not attributable to the CA;
- any damage incurred in an outage of the normal communication due to reasons not attributable to the CA;
- any damage arising in connection with the use of a Certificate, including transaction debts;
- any damage caused by the Delegated Third Party’s failure to fulfill its service provision obligations, such as the termination of service provision by them;
- any damages attributable to improvement, beyond expectations at this point in time, in hardware or software type of cryptographic algorithm decoding skills;
- any damage attributable to the suspension of the CA's operations due to force majeure, including, but not limited to, natural disasters, earthquakes, volcanic eruptions, fires, tsunami, floods, lightning strikes, wars, civil commotion and terrorism.
## 9.9 Indemnities
Notwithstanding any limitations on its liability to Subscribers and Relying Parties, the CA understands and acknowledges that the Application Software Suppliers who have a Root Certificate distribution agreement in place with the Root CA do not assume any obligation or potential liability of the CA under [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) or that otherwise might exist because of the issuance or maintenance of Certificates or reliance thereon by Relying Parties or others. Thus, the CA SHALL defend, indemnify, and hold harmless each Application Software Supplier for any and all claims, damages, and losses suffered by such Application Software Supplier related to a Certificate issued by the CA, regardless of the cause of action or legal theory involved. This does not apply, however, to any claim, damages, or loss suffered by such Application Software Supplier related to a Certificate issued by the CA where such claim, damage, or loss was directly caused by such Application Software Supplier's software displaying as not trustworthy a Certificate that is still valid, or displaying as trustworthy:
(1) a Certificate that has expired, or
(2) a Certificate that has been revoked (but only in cases where the revocation status is currently available from the CA online, and the application software either failed to check such status or ignored an indication of revoked status).
## 9.10 Term and termination
### 9.10.1 Term
This CP/CPS goes into effect upon approval by Certification Services Improvement Committee.
This CP/CPS will in no way lose effect under any circumstances prior to the termination stipulated in [Section 9.10.2](#9102-termination) hereof.
### 9.10.2 Termination
This CP/CPS loses effect as of the termination hereof by the CA, with the exception of the provisions stipulated in [Section 9.10.3](#9103-effect-of-termination-and-survival) hereof.
### 9.10.3 Effect of termination and survival
Even in the event of termination of the use of a Certificate by a Subscriber or the termination of a service provided by the Delegated Third Party, or the CA closes its business, provisions that should remain in effect, due to the nature thereof, shall survive any such termination, regardless of the reasons therefor, and remain in full force and effect with respect to any Subscriber and the CA.
## 9.11 Individual notices and communications with participants
The CA provides the necessary notices to the Delegated Third Party, then the Delegated Third Party provides the necessary notice to Subscribers and Relying Parties through its website, e-mail or in other written forms.
## 9.12 Amendments
### 9.12.1 Procedure for amendment
1. Critical revisions/amendments
SECOM Trust Systems notifies Subscribers and Relying Parties of amendments of this CP/CPS if the amendments thereof are determined to have an obvious impact on the activities for use of Certificates or CRLs by the Subscribers and Relying Parties, by publishing the post-amendment version of this CP/CPS (including the Version History/Description/Date) in the Repository, while refreshing the Major Version Number.
2. Non-critical revisions/amendments
SECOM Trust Systems notifies Subscribers and Relying Parties of amendments of this CP/CPS if the amendments thereof are determined to have no or less impact on the activities for use of Certificates or CRLs by the Subscribers and Relying Parties, by publishing the post-amendment version of this CP/CPS (including the Version History/Description/Date) in the Repository, while refreshing the Minor Version Number.
This CP/CPS shall be revised by the CA as appropriate and goes into effect upon approval by its Certification Services Committee.
### 9.12.2 Notification mechanism and period
If this CP/CPS is revised/amended, the prompt publication of the post-amendment version of this CP/CPS (including the Version History/Description/Date) in the Repository is deemed to be the notification thereof to Subscribers and Relying Parties. Subscribers may make claims within a week of such notification, while the post-amendment version of this CP/CPS is deemed to be approved by the Subscribers unless any claim is made within the said period.
Whenever this CP/CPS is modified, the prompt publication of the modified the CP/CPS shall be deemed as the notification thereof to the participants.
### 9.12.3 Circumstances under which OID must be changed
OID shall be changed if the Certification Service Improvement Committee determines that it is necessary.
## 9.13 Dispute resolution provisions
A party seeking to file a lawsuit, request arbitration or take any other legal action against the CA for the resolution of a dispute relating to a Certificate issued by the CA, said party shall notify the CA to this effect in advance. As regards the location for arbitration and court proceedings, a dispute settlement institution located within Tokyo shall have exclusive jurisdiction.
## 9.14 Governing law
Regardless of the locations of the CAs, Subscribers, or Relying Parties, the laws of Japan will apply to any dispute concerning the interpretation or validity of this CP/CPS. Regarding the location for arbitration and court proceedings, the parties hereto submit to the exclusive jurisdiction of a dispute settlement institution located within Tokyo.
## 9.15 Compliance with applicable law
The CA shall handle cryptographic hardware and software in compliance with relevant export regulations of Japan.
## 9.16 Miscellaneous provisions
### 9.16.1 Entire agreement
SECOM Trust Systems comprehensively stipulates the obligations of Subscribers and Relying Parties and other relevant matters in this CP/CPS and the Service Terms, for provision of the services. Any agreements otherwise, whether oral or written, shall have no effect.
### 9.16.2 Assignment
When assigning the services to a third party, SECOM Trust Systems may assign its responsibilities and other obligations specified in this CP/CPS and the Service Terms.
### 9.16.3 Severability
Even if any provision of this CP/CPS, the Service Terms is deemed invalid, all other provisions stipulated therein shall remain in full force and effect.
In the event of a conflict between Baseline Requirements and a law, regulation or government order (hereinafter 'Law') of any jurisdiction in which a CA operates or issues certificates, a CA MAY modify any conflicting Baseline Requirement to the minimum extent necessary to make the requirement valid and legal in the jurisdiction. This applies only to operations or certificate issuances that are subject to that Law. In such event, the CA SHALL immediately (and prior to issuing a certificate under the modified requirement) include in [Section 9.16.3](#9163-severability) of the CA’s CP/CPS a detailed reference to the Law requiring a modification of Baseline Requirements under this section, and the specific modification to Baseline Requirements implemented by the CA.
The CA MUST also (prior to issuing a certificate under the modified requirement) notify the CA/Browser Forum of the relevant information newly added to its CP/CPS by sending a message to `questions [at] cabforum [dot] org` and receiving confirmation that it has been posted to the Public Mailing List and is indexed in the Public Mail Archives available at (or such other email addresses and links as the Forum may designate), so that the CA/Browser Forum may consider possible revisions to Baseline Requirements accordingly.
Any modification to CA practice enabled under this section MUST be discontinued if and when the Law no longer applies, or Baseline Requirements are modified to make it possible to comply with both Baseline Requirements and the Law simultaneously. An appropriate change in practice, modification to the CA’s CP/CPS and a notice to the CA/Browser Forum, as outlined above, MUST be made within 90 days.
### 9.16.4 Enforcement (attorneys' fees and waiver of rights)
Disputes regarding this service shall be governed by the Tokyo District Court, and SECOM Trust Systems may request the parties for compensation and attorney’s fees for disputes arising from the contractual provisions of the respective regulatory documents, damages, losses and costs related to the parties' actions.
### 9.16.5 Force Majeure
SECOM Trust Systems shall not be liable for any damages caused by natural disasters, earthquakes, eruptions, fires, tsunamis, floods, lightning strikes, disturbances, terrorism, or any other force majeure, whether or not foreseeable. If it becomes impossible to provide this CA, SECOM Trust Systems may suspend this CA until the situation stops.
## 9.17 Other provisions
No stipulation.
# APPENDIX A – CAA Contact Tag
These methods allow domain owners to publish contact information in DNS for the purpose of validating domain control.
## A.1. CAA Methods
### A.1.1. CAA contactemail Property
SYNTAX: `contactemail `
The CAA contactemail property takes an email address as its parameter. The entire parameter value MUST be a valid email address as defined in RFC 6532, Section 3.2, with no additional padding or structure, or it cannot be used.
The following is an example where the holder of the domain specified the contact property using an email address.
```DNS Zone
$ORIGIN example.com.
CAA 0 contactemail "domainowner@example.com"
```
The contactemail property MAY be critical, if the domain owner does not want CAs who do not understand it to issue certificates for the domain.
### A.1.2. CAA contactphone Property
SYNTAX: `contactphone `
The CAA contactphone property takes a phone number as its parameter. The entire parameter value MUST be a valid Global Number as defined in RFC 3966, Section 5.1.4, or it cannot be used. Global Numbers MUST have a preceding + and a country code and MAY contain visual separators.
The following is an example where the holder of the domain specified the contact property using a phone number.
```DNS Zone
$ORIGIN example.com.
CAA 0 contactphone "+81 (3) 1234-5678"
```
The contactphone property MAY be critical if the domain owner does not want CAs who do not understand it to issue certificates for the domain.
## A.2. DNS TXT Methods
### A.2.1. DNS TXT Record Email Contact
The DNS TXT record MUST be placed on the "`_validation-contactemail`" subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid email address as defined in RFC 6532, Section 3.2, with no additional padding or structure, or it cannot be used.
### A.2.2. DNS TXT Record Phone Contact
The DNS TXT record MUST be placed on the "`_validation-contactphone`" subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid Global Number as defined in RFC 3966, Section 5.1.4, or it cannot be used.
# APPENDIX B – Certificate profile
## Table : "Security Communication RootCA2" and Subordinate CAs
Root CA Certificate SHA256 Fingerprint:
513B2CECB810D4CDE5DD85391ADFC6C2DD60D87BB736D2B521484AA47A0EBEF6
| Basic Field | Description |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| version | 3 (0x2) |
| serialNumber | For Root CA
0
For Subordinate CA
Unique value within CA |
| signature | sha256WithRSAEncryption |
| issuer | C = JP
O = SECOM Trust Systems CO.,LTD.
OU = Security Communication RootCA2 |
| validity | For Root CA
From: May 29 05:00:39 2009 GMT
To: May 29 05:00:39 2029 GMT
For Subordinate CA
From: Certificate issued date
To: Set as stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | For Root CA
C = JP
O = SECOM Trust Systems CO.,LTD.
OU = Security Communication RootCA2
For Subordinate CA
Set the Subordinate CA Subscriber information |
| subjectPublicKeyInfo | For Root CA
Public Key Algorithm: rsaEncryption
Public-Key: 2048 bit
For Subordinate CA
The Public Key algorithm identifier and the Public Key data of the Subordinate CA Subscriber |
| Extension Field | Description | critical |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | 160bit value obtained by hashing the CA public key using SHA-1 | N |
| subjectKeyIdentifier | 160bit value obtained by hashing the Subscriber public key using SHA-1 | N |
| keyUsage | keyCertSign, cRLSign（Purpose of use of the Subscriber public key） | Y |
| extendedKeyUsage | Be sure to set this after 2019-01-01, but do not set anyExtendedKeyUsage.
Do not set id-kp-serverAuth and id-kp-emailProtection at the same time.
Set id-kp-codeSigning independently.
For Cross Certificates, set as necessary. | N |
| certificatePolicies | policyIdentifier
- certPolicyId=1.2.392.200091.100.901.4, CA/Browser Forum Reserved Certificate Policy Identifier (If this is included and issued after 2023-09-15, it is recommended to set it first),1.2.392.200091.100.721.1 or any Policy \*1
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS=`http(s)://repository.secomtrust.net/SC-Root2/`
\* () is operational
policyQualifier is not recommended for TLS DV/OV CAs | N |
| basicConstraints | Subject Type=CA
pathLenConstraints（Set as necessary with the CA） | Y |
| nameConstraints | If present, it should be set to Critical. | Y |
| cRLDistributionPoints | URI: `http://repository.secomtrust.net/SC-Root2/SCRoot2CRL.crl` | N |
| authorityInformationAccess | accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI :`http://scrootca2.ocsp.secomtrust.net`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repository.secomtrust.net/SC-Root2/SCRoot2ca.cer`
\* Set OCSP, CA Issuers as necessary | N |
\*1 If issuing an EV certificate, OID (1.2.392.200091.100.721.1) or any policy for EV certificate may be set. If issuing after September 15, 2023, "CA/Browser Forum reserved certificate policy identifier and EV certificate OID (1.2.392.200091.100.721.1)" or "any Policy" (when the CA manages CA keys of subordinate CAs) may be set.
---
## Table : "Security Communication RootCA3" and Subordinate CAs
Root CA Certificate SHA256 Fingerprint:
24A55C2AB051442D0617766541239A4AD032D7C55175AA34FFDE2FBC4F5C5294
| Basic Field | Description |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| version | 3 (0x2) |
| serialNumber | For Root CA
E17C3740FD1BFE67
For Subordinate CA
Unique value within CA |
| signature | sha384WithRSAEncryption |
| issuer | C = JP
O = SECOM Trust Systems CO.,LTD.
CN = Security Communication RootCA3 |
| validity | For Root CA
From: Jun 16 06:17:16 2016 GMT
To: Jan 18 06:17:16 2038 GMT
For Subordinate CA
From: Certificate issued date
To: Set as stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | For Root CA
C = JP
O = SECOM Trust Systems CO.,LTD.
CN = Security Communication RootCA3
For Subordinate CA
Set the Subordinate CA Subscriber information |
| subjectPublicKeyInfo | For Root CA
Public Key Algorithm: rsaEncryption
Public-Key: 4096 bit
For Subordinate CA
The Public Key algorithm identifier and the Public Key data of the Subordinate CA Subscriber |
| Extension Field | Description | critical |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | 160bit value obtained by hashing the CA public key using SHA-1 | N |
| subjectKeyIdentifier | 160bit value obtained by hashing the Subscriber public key using SHA-1 | N |
| keyUsage | keyCertSign, cRLSign（Purpose of use of the Subscriber public key） | Y |
| extendedKeyUsage | Be sure to set this after 2019-01-01, but do not set anyExtendedKeyUsage.
Set one of the following:
(1) id-kp-serverAuth
(2) id-kp-serverAuth and id-kp-clientAuth
(3)Adobe Authentic Documents Trust (1.2.840.113583.1.1.5)
(4) Microsoft Signer of documents (1.3.6.1.4.1.311.10.3.12）
(5) id-kp-codeSigning
(6) id-kp-timeStamping
For Cross Certificates, set as necessary.
(3) and (4) can be set at the same time. | N |
| certificatePolicies | policyIdentifier
- certPolicyId=1.2.392.200091.100.901.6,
CA/Browser Forum Reserved Certificate Policy Identifier (If this is included and issued after 2023-09-15, it is recommended to set it first)
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS=`http(s)://repository.secomtrust.net/SC-Root3/`
\* () is optional
policyQualifier is not recommended for TLS DV/OV CAs | N |
| basicConstraints | Subject Type=CA
pathLenConstraints（Set as necessary with the CA） | Y |
| nameConstraints | If present, it should be set to Critical. | Y |
| cRLDistributionPoints | URI: `http://repository.secomtrust.net/SC-Root3/SCRoot3CRL.crl` | N |
| authorityInformationAccess | accessmethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://scrootca3.ocsp.secomtrust.net`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repository.secomtrust.net/SC-Root3/SCRoot3ca.cer`
\* Set OCSP, CA Issuers as necessary | N |
---
## Table : "Security Communication ECC RootCA1" and Subordinate CAs
Root CA Certificate SHA256 Fingerprint:
E74FBDA55BD564C473A36B441AA799C8A68E077440E8288B9FA1E50E4BBACA11
| Basic Field | Description |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | For Root CA
D65D9BB378812EEB
For Subordinate CA
Unique value within CA |
| signature | ecdsa-with-SHA384 |
| issuer | C = JP
O = SECOM Trust Systems CO.,LTD.
CN = Security Communication ECC Root CA1 |
| validity | For Root CA
From: Jun 16 05:15:28 2016 GMT
To: Jan 18 05:15:28 2038 GMT
For Subordinate CA
From: Certificate issued date
To: Set as stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | For Root CA
C = JP
O = SECOM Trust Systems CO.,LTD.
CN = Security Communication ECC Root CA1
For Subordinate CA
Set the Subordinate CA Subscriber information |
| subjectPublicKeyInfo | For Root CA
Public Key Algorithm: id-ecPublicKey
Public-Key: 384 bit
For Subordinate CA
The Public Key algorithm identifier and the Public Key data of the Subordinate CA Subscriber |
| Extension Field | Description | critical |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | 160bit value obtained by hashing the CA public key using SHA-1 | N |
| subjectKeyIdentifier | 160bit value obtained by hashing the Subscriber public key using SHA-1 | N |
| keyUsage | keyCertSign, cRLSign（Purpose of use of the Subscriber public key） | Y |
| extendedKeyUsage | Set one of the following:
(1) id-kp-serverAuth
(2) id-kp-serverAuth and id-kp-clientAuth
For Cross Certificates, set as necessary. | N |
| certificatePolicies | policyIdentifier
- CA/Browser Forum Reserved Certificate Policy Identifier (If this is included and issued after 2023-09-15, it is recommended to set it first), certPolicyId=1.2.392.200091.100.902.1
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS=`http(s)://repository.secomtrust.net/SC-ECC-Root1`/
\* () is optional
policyQualifier is not recommended for TLS DV/OV CAs | N |
| basicConstraints | Subject Type=CA
pathLenConstraints（Set as necessary） | Y |
| nameConstraints | If present, it should be set to Critical. | Y |
| cRLDistributionPoints | URI: `http://repository.secomtrust.net/SC-ECC-Root1/SCECCRoot1CRL.crl` | N |
| authorityInformationAccess | accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://sceccrootca1.ocsp.secomtrust.net`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repository.secomtrust.net/SC-ECC-Root1/SCECCRoot1ca.cer`
\* Set OCSP, CA Issuers as necessary | N |
---
## Table : "SECOM RSA Root CA 2023" and Subordinate CAs
Root CA Certificate SHA256 Fingerprint:
2C154235528D701790B675AFF6E1970827B10ED665E913835BF46E3460FD5C84
| Basic Field | Description |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| version | 3 (0x2) |
| serialNumber | For Root CA
99B8098D4418DDDB
For Subordinate CA
Unique value within CA |
| signature | sha384WithRSAEncryption |
| issuer | C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM RSA Root CA 2023 |
| validity | For Root CA
From: Jan 25 08:03:37 2023 GMT
To: Jan 1 08:03:37 2048 GMT
For Subordinate CA
From: Certificate issued date
To: Set as stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | For Root CA
C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM RSA Root CA 2023
For Subordinate CA
Set the Subordinate CA Subscriber information |
| subjectPublicKeyInfo | For Root CA
Public Key Algorithm: rsaEncryption
Public-Key: 4096 bit
For Subordinate CA
The Public Key algorithm identifier and the Public Key data of the Subordinate CA Subscriber |
| Extension Field | Description | critical |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | 160bit value obtained by hashing the CA public key using SHA-1 | N |
| subjectKeyIdentifier | 160bit value obtained by hashing the Subscriber public key using SHA-1 | N |
| keyUsage | keyCertSign, cRLSign（Purpose of use of the Subscriber public key） | Y |
| extendedKeyUsage | Set one of the following:
(1) Microsoft Signer of documents (1.3.6.1.4.1.311.10.3.12)
(2) id-kp-documentSigning (1.3.6.1.5.5.7.3.36)
(1) and (2) can be set at the same time.
For Cross Certificates, set as necessary. | N |
| certificatePolicies | policyIdentifier
- certPolicyId=1.2.392.200091.100.901.9
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS= `http://repo1.secomtrust.net/root/rsa/` | N |
| basicConstraints | Subject Type=CA
pathLenConstraints（Set as necessary） | Y |
| nameConstraints | Not present | - |
| cRLDistributionPoints | URI: `http://repo1.secomtrust.net/root/rsa/rsarootca2023.crl` | N |
| authorityInformationAccess | accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://rsarootca2023.ocsp.secom-cert.jp`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repo2.secomtrust.net/root/rsa/rsarootca2023.cer`
\* Set OCSP, CA Issuers as necessary | N |
---
## Table : "SECOM Document Signing RSA Root CA 2023" and Subordinate CAs
Root CA Certificate SHA256 Fingerprint:
46219BBF9148F00E8B7A4C619B57CF7602701FF81348400718870FABD31FC5BE
| Basic Field | Description |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| version | 3 (0x2) |
| serialNumber | For Root CA
E3A2A1C4FE81A10D
For Subordinate CA
Unique value within CA |
| signature | sha384WithRSAEncryption |
| issuer | C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM Document Signing RSA Root CA 2023
OrganizationIdentifier (2.5.4.97) = NTRJP-4011001040781 |
| validity | For Root CA
From: Jan 25 08:33:59 2023 GMT
To: Jan 1 08:33:59 2048 GMT
For Subordinate CA
From: Certificate issued date
To: Set as stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | For Root CA
C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM Document Signing RSA Root CA 2023
OrganizationIdentifier (2.5.4.97) = NTRJP-4011001040781
For Subordinate CA
Set the Subordinate CA Subscriber information |
| subjectPublicKeyInfo | For Root CA
Public Key Algorithm: rsaEncryption
Public-Key: 4096 bit
For Subordinate CA
The Public Key algorithm identifier and the Public Key data of the Subordinate CA Subscriber |
| Extension Field | Description | critical |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | 160bit value obtained by hashing the CA public key using SHA-1 | N |
| subjectKeyIdentifier | 160bit value obtained by hashing the Subscriber public key using SHA-1 | N |
| keyUsage | keyCertSign, cRLSign（Purpose of use of the Subscriber public key） | Y |
| extendedKeyUsage | Set one of the following:
(1) Adobe Authentic Documents Trust (1.2.840.113583.1.1.5)
(2) id-kp-timeStamping
For Cross Certificates, set as necessary. | N |
| certificatePolicies | policyIdentifier
- certPolicyId=1.2.392.200091.100.901.10
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS= `http://repo1.secomtrust.net/root/docrsa/` | N |
| basicConstraints | Subject Type=CA
pathLenConstraints（Set as necessary） | Y |
| nameConstraints | Not present | - |
| cRLDistributionPoints | URI: `http://repo1.secomtrust.net/root/docrsa/docrsarootca2023.crl`
| N |
| authorityInformationAccess | accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://docrsarootca2023.ocsp.secom-cert.jp`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repo2.secomtrust.net/root/docrsa/docrsarootca2023.cer`
\* Set OCSP, CA Issuers as necessary | N |
---
## Table : "SECOM TLS RSA Root CA 2024" and Subordinate CA
Root CA Certificate SHA256 Fingerprint:
1435F225C5D252D7A21948CC3CE62AECFA88001E3DD72D1CC3555100EB372F93
| Basic Field | Description |
| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | For Root CA
EE8934D0CB80E0B2
For Subordinate CA
Unique value within CA |
| signature | sha384WithRSAEncryption |
| issuer | C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM TLS RSA Root CA 2024 |
| validity | For Root CA
Start Date：Jan 31 05:11:55 2024 GMT
End Date：Jan 14 05:11:55 2049 GMT
For Subordinate CA
Start Date：Certificate Issued Date
End Date:：Set as specified in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | For Root CA
C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM TLS RSA Root CA 2024
For Subordinate CA
Set Subscriber information for Subordinate CA |
| subjectPublicKeyInfo | For Root CA
Public Key Algorithm: rsaEncryption
Public-Key: 4096 bit
For Subordinate CA
Public key algorithm identifier and public key data of Subordinate CA Subscribers |
| Extension Field | Description | critical |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | 160bit value obtained by hashing the CA public key using SHA-1 | N |
| subjectKeyIdentifier | 160bit value obtained by hashing the Subscriber public key using SHA-1 | N |
| keyUsage | keyCertSign, cRLSign（Purpose of use of the Subscriber public key） | Y |
| extendedKeyUsage | Set one of the following:
(1) id-kp-serverAuth
(2) id-kp-serverAuth and id-kp-clientAuth
For Cross Certificates, set as necessary. | N |
| certificatePolicies | policyIdentifier
- CA/Browser Forum Reserved Certificate Policy Identifier (it is recommended to set it first), certPolicyId=1.2.392.200091.100.901.11, 1.2.392.200091.100.721.1 or any Policy \*1
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS= `http://repo1.secomtrust.net/root/tlsrsa/`
policyQualifier is not recommended for TLS DV/OV CAs | N |
| basicConstraints | Subject Type=CA
pathLenConstraints（Set as necessary） | Y |
| nameConstraints | If present, it should be set to Critical. | Y |
| cRLDistributionPoints | URI: `http://repo1.secomtrust.net/root/tlsrsa/tlsrsarootca2024.crl` | N |
| authorityInformationAccess | accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://tlsrsarootca2024.ocsp.secom-cert.jp`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repo2.secomtrust.net/root/tlsrsa/tlsrsarootca2024.cer`
\* Set OCSP, CA Issuers as necessary | N |
\*1 If issuing an EV certificate, "CA/Browser Forum reserved certificate policy identifier and EV certificate OID (1.2.392.200091.100.721.1)" or "any Policy" (when the CA manages CA keys of subordinate CAs) may be set.
---
## Table : "SECOM TLS ECC Root CA 2024" and Subordinate CA
Root CA Certificate SHA256 Fingerprint:
6AB2AB75F51CB4F4F0156203FBF6F646232F514BE059F62833308B82B4D72DB1
| Basic Field | Description |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | For Root CA
817A2CEF8F237A44
For Subordinate CA
Unique value within CA |
| signature | ecdsa-with-SHA384 |
| issuer | C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM TLS ECC Root CA 2024 |
| validity | For Root CA
Start Date：Jan 31 05:52:34 2024 GMT
End Date:：Jan 14 05:52:34 2049 GMT
For Subordinate CA
Start Date：Certificate Issued Date
End Date:Set as specified in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | For Root CA
C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM TLS ECC Root CA 2024
For Subordinate CA
Set Subscriber information for Subordinate CA |
| subjectPublicKeyInfo | For Root CA
Public Key Algorithm: id-ecPublicKey
Public-Key: 384bit
For Subordinate CA
Public key algorithm identifier and public key data of Subordinate CA Subscribers |
| Extension Field | Description | critical |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | 160bit value obtained by hashing the CA public key using SHA-1 | N |
| subjectKeyIdentifier | 160bit value obtained by hashing the Subscriber public key using SHA-1 | N |
| keyUsage | keyCertSign, cRLSign（Purpose of use of the Subscriber public key） | Y |
| extendedKeyUsage | Set one of the following:
(1) id-kp-serverAuth
(2) id-kp-serverAuth and id-kp-clientAuth
For Cross Certificates, set as necessary. | N |
| certificatePolicies | policyIdentifier
- CA/Browser Forum Reserved Certificate Policy Identifier (it is recommended to set it first), certPolicyId= 1.2.392.200091.100.902.3, 1.2.392.200091.100.721.1 or any Policy \*1
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS= `http://repo1.secomtrust.net/root/tlsecc/`
policyQualifier is not recommended for TLS DV/OV CAs | N |
| basicConstraints | Subject Type=CA
pathLenConstraints（Set as necessary） | Y |
| nameConstraints | If present, it should be set to Critical. | Y |
| cRLDistributionPoints | URI: `http://repo1.secomtrust.net/root/tlsecc/tlseccrootca2024.crl` | N |
| authorityInformationAccess | accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://tlseccrootca2024.ocsp.secom-cert.jp`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repo2.secomtrust.net/root/tlsecc/tlseccrootca2024.cer`
\* Set OCSP, CA Issuers as necessary | N |
\*1 If issuing an EV certificate, "CA/Browser Forum reserved certificate policy identifier and EV certificate OID (1.2.392.200091.100.721.1)" or "any Policy" (when the CA manages CA keys of Subordinate CAs) may be set.
## Table : "SECOM SMIME RSA Root CA 2024" and Subordinate CA
Root CA Certificate SHA256 Fingerprint:
3629E7188E00A7CB3232C4426BC84912F1218B1A9AE676C0B0ABE1DBFE2182B5
| Basic Field | Description |
| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | For Root CA
DDA9DB9E7EBCD46D
For Subordinate CA
Unique value within CA |
| signature | sha384WithRSAEncryption |
| issuer | C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM SMIME RSA Root CA 2024 |
| validity | For Root CA
Start Date：Jan 31 06:23:06 2024 GMT
End Date:：Jan 14 06:23:06 2049 GMT
For Subordinate CA
Start Date：Certificate Issued Date
End Date:：Set as specified in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | For Root CA
C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM SMIME RSA Root CA 2024
For Subordinate CA
Set Subscriber information for Subordinate CA |
| subjectPublicKeyInfo | For Root CA
Public Key Algorithm: rsaEncryption
Public-Key: 4096 bit
For Subordinate CA
Public key algorithm identifier and public key data of Subordinate CA Subscribers |
| Extension Field | Description | critical |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------- |
| authorityKeyIdentifier | 160bit value obtained by hashing the CA public key using SHA-1 | N |
| subjectKeyIdentifier | 160bit value obtained by hashing the Subscriber public key using SHA-1 | N |
| keyUsage | keyCertSign, cRLSign（Purpose of use of the Subscriber public key） | Y |
| extendedKeyUsage | Set the following:
id-kp-emailProtection
For Cross Certificates, set as necessary. | N |
| certificatePolicies | policyIdentifier
- CA/Browser Forum Reserved Certificate Policy Identifier (it is recommended to set it first), certPolicyId= 1.2.392.200091.100.901.12
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS=`http://repo1.secomtrust.net/root/smimersa/` | N |
| basicConstraints | Subject Type=CA
pathLenConstraints（Set as necessary） | Y |
| nameConstraints | If present, it should be set to Critical. | Y |
| cRLDistributionPoints | URI: `http://repo1.secomtrust.net/root/smimersa/smimersarootca2024.crl` | N |
| authorityInformationAccess | accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://smimersarootca2024.ocsp.secom-cert.jp`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repo2.secomtrust.net/root/smimersa/smimersarootca2024.cer`
\* Set OCSP, CA Issuers as necessary | N |
---
## Table : Subscriber Certificates (Client Authentication Certificate and Document Signing Certificates)
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | sha256WithRSAEncryption |
| issuer | countryName = JP
organizationName = Set the CA’s Organization
organizationalUnitName = The CA's Organizational Unit can be set
commonName = Set the CA’s Common Name |
| validity | notBefore = A value within 48 hours before the certificate signing
notAfter=Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | countryName = JP
stateOrProvinceName = State or Province Name (Optional)
localityName = Locality Name (Optional)
organizationName = Organization Name
organizationalUnitName = Organizational Unit (Optional)
commonName = Subscriber Name
serialNumber = Serial Number (Optional) |
| subjectPublicKeyInfo | Subject's Public Key Data |
| Extension Fields | Settings | critical |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | Authority Public Key Identifier
160bit value obtained by hashing the CA public key using SHA-1 | N |
| subjectKeyIdentifier | Subject Public Key Identifier
160bit value obtained by hashing the Subscriber public key using SHA-1 | N |
| keyUsage | The following can be set:
digitalSignature
Non Repudiation
keyEncipherment
dataEncipherment | Y |
| certificatePolicies | The following can be set:
Policy: 1.2.392.200091.100.381.4 (Client Authentication Certificates)
Policy: 1.2.392.200091.100.381.5 (Document Signing Certificates)
CPS: Repository URL | N |
| subjectAltName | The following can be set:
OtherName: UPN="User Principal Name"
OtherName: "OID"=" Any character string "
Rfc822Name: " Mail address" (Can be set up to 2023-08-31) | N |
| extendedKeyUsage | The following can be set:
id-kp-clientAuth
id-kp-emailProtection (Can be set up to 2023-08-31)
SmartCard Logon
Adobe Authentic Documents Trust = 1.2.840.113583.1.1.5
Microsoft Signer of documents = 1.3.6.1.4.1.311.10.3.12
＊When SmartCard Logon is selected, also select id-kp-clientAuth | N |
| cRLDistributionPoints | HTTP URL of the CA's CRL service
ldap://repo1.secomtrust.net/"IssuerDN"?certificateRevocationList
＊ldap is set as required | N |
| authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
OCSP Responder URL
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
URL of the Subordinate CA Certificate
\* Set OCSP, CA Issuers as necessary | N |
| Netscape Certificate Type | The following can be set:
SSL Client
S/MIME Client (Can be set up to 2023-08-31) | N |
---
## Table : Subscriber Certificates (Code Signing Certificates, Not be issued after 2024-05-01)
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | sha256WithRSAEncryption |
| issuer | countryName = JP
organizationName = Set the CA’s Organization
commonName = Set the CA’s Common Name |
| validity | notBefore = A value within 48 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | countryName = JP
stateOrProvinceName = State Or ProvinceName
localityName = Locality Name
organizationName = Organization Name
organizationalUnitName = Organizational Unit (Optional)
commonName = Subscriber Name |
| subjectPublicKeyInfo | Subject's RSA Public Key Data（3072bit or 4096bit） |
| Extension Fields | Settings | critical |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | Authority Public Key Identifier
160-bit SHA-1 hash value of Authority Public key | N |
| subjectKeyIdentifier | Subject Public Key Identifier
160-bit SHA-1 hash value of the Subject Public key | N |
| keyUsage | digitalSignature | Y |
| certificatePolicies | Policy: 1.2.392.200091.100.381.8
CPS: Repository URL
Policy: 2.23.140.1.4.1（Certificate Policy for Code Signing） | N |
| subjectAltName | - | - |
| extKeyUsage | id-kp-codeSigning | N |
| crlDistributionPoints | HTTP URL of the CA's CRL service | N |
| authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
OCSP Responder URL
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
URL of the Subordinate CA Certificate | N |
---
## Table: Subscriber Certificates (AATL Document Signing Certificates)
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | Set one of the following：
sha256WithRSAEncryption
sha384WithRSAEncryption |
| issuer | countryName = JP
organizationName = SECOM Trust Systems Co., Ltd.
commonName = Set the CA’s Common Name
organizationIdentifier(2.5.4.97) = NTRJP-4011001040781
(NTRJP-Corporation Number of the CA) |
| validity | notBefore = A value within 48 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | countryName = JP
stateOrProvinceName = state Or Province Name (Optional)
localityName = locality Name (Optional)
organizationName = Organization Name (Do not set for individual use)
organizationalUnitName = Organizational Unit (Optional)
commonName = Subscriber Name
serialNumber = Serial number (Optional)
organizationIdentifier(2.5.4.97) = NTRJP-Organization Corporate Number (Optional) |
| subjectPublicKeyInfo | Subject's Public Key Data |
| Extension Fields | Settings | critical |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | Authority Public Key Identifier
160-bit SHA-1 hash value of Authority Public key | N |
| subjectKeyIdentifier | Subject Public Key Identifier
160-bit SHA-1 hash value of the Subject Public key | N |
| keyUsage | digitalSignature
Non Repudiation | Y |
| certificatePolicies | Policy: 1.2.392.200091.100.382.1
CPS: Repository URL | N |
| subjectAltName | - | - |
| extKeyUsage | Adobe Authentic Documents Trust = 1.2.840.113583.1.1.5 | N |
| crlDistributionPoints | HTTP URL of the CA's CRL service | N |
| authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
OCSP Responder URL
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
URL of the Subordinate CA Certificate
\* Set OCSP, CA Issuers as necessary | N |
---
## Table: Subscriber Certificates (S/MIME Certificates)
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | Set one of the following：
sha256WithRSAEncryption
sha384WithRSAEncryption |
| issuer | countryName = JP
organizationName = Set the CA’s Organization
commonName = Set the CA’s Common Name |
| validity | notBefore = A value within 48 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | commonName = Mail address |
| subjectPublicKeyInfo | Subject's Public Key Data |
| Extension Fields | Settings | critical |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | Authority Public Key Identifier
160-bit SHA-1 hash value of Authority Public key | N |
| subjectKeyIdentifier | Subject Public Key Identifier
160-bit SHA-1 hash value of the Subject Public key | N |
| keyUsage | digitalSignature
keyEncipherment | Y |
| certificatePolicies | CA/Browser Forum Reserved Certificate Policy Identifier (Recommended to set first)
Policy: 1.2.392.200091.100.383.1 (Optional)
CPS: Repository URL (Optional) | N |
| subjectAltName | Rfc822Name: "Mail address" | N |
| extKeyUsage | id-kp-emailProtection | N |
| crlDistributionPoints | HTTP URL of the CA's CRL service | N |
| authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
URL of the OCSPResponder
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
URL of the Subordinate CA Certificate
\* Set OCSP, CA Issuers as necessary | N |
---
## Table: Security Communication RootCA2 TSA, TA Certificates (Issued before 2018-09-26)
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | sha256WithRSAEncryption |
| issuer | Information about the issuer (specified by the CAs) |
| validity | notBefore = A value within 24 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | Subscriber information |
| subjectPublicKeyInfo | Subject's Public Key Data |
| Extension Fields | Settins | critical |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | A 160-bit SHA-1 hash for CA Public Key | N |
| subjectKeyIdenrifier | A 160-bit SHA-1 hash for Subscriber Public Key | N |
| keyUsage | digitalSignature
\* Other usages than keyCertSign and cRLSign may be specified by the CAs as necessary. | Y |
| certificatePolicies | policyIdentifier
certPolicyId=1.2.392.200091.100.901.5
policyQualifiers
policyQualifierID=id-qt-cps
qualifier=CPS=`https://repository.secomtrust.net/SC-Root2/` | N |
| subjectAltName | - | - |
| extKeyUsage | id-kp-timeStamping | N |
| cRLDistributionPoints | URI:`http://repository.secomtrust.net/SC-Root2/SCRoot2CRL.crl` | N |
| authorityInformationAccess | accessMethod
id-ad-ocsp（1.3.6.1.5.5.7.48.1)
accessLocation
URI:`http://scrootca2.ocsp.secomtrust.net` (Optional if cRLDistributionPoints is present) | N |
---
## Table: Security Communication RootCA3 TSA, TA Certificates (Issued before 2018-09-26)
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | Set one of the following：
sha256WithRSAEncryption
sha384WithRSAEncryption |
| issuer | Information about the issuer (specified by the CAs) |
| validity | notBefore = A value within 24 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | Subscriber information |
| subjectPublicKeyInfo | Subject's RSA Public Key Data (At least 2048 bit) |
| Extension Fields | Settins | critical |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | A 160-bit SHA-1 hash for CA Public Key | N |
| subjectKeyIdenrifier | A 160-bit SHA-1 hash for Subscriber Public Key | N |
| keyUsage | digitalSignature
\* Other usages than keyCertSign and cRLSign may be specified by the CAs as necessary. | Y |
| certificatePolicies | policyIdentifier
certPolicyId=1.2.392.200091.100.901.7
policyQualifiers
policyQualifierID=id-qt-cps
qualifier=CPS=`https://repository.secomtrust.net/SC-Root3/` | N |
| subjectAltName | - | - |
| extKeyUsage | id-kp-timeStamping | N |
| cRLDistributionPoints | URI:`http://repository.secomtrust.net/SC-Root3/SCRoot3CRL.crl`
\* Optional if id-ad-ocsp accessMethod is present in the authorityInformationAccess extension. | N |
| authorityInformationAccess | accessMethod
id-ad-ocsp（1.3.6.1.5.5.7.48.1)
accessLocation
URI:`http://scrootca3.ocsp.secomtrust.net` (Optional if cRLDistributionPoints is present) | N |
---
## Table: Security Communication RootCA3 TimeStamping Subordinate CA Certificates (Issued after 2018-06-07)
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | Set one of the following：
sha256WithRSAEncryption
sha384WithRSAEncryption |
| issuer | Information about the issuer (specified by the CAs) |
| validity | notBefore = A value within 24 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | Subscriber information |
| subjectPublicKeyInfo | Subject's Public Key Data |
| Extension Fields | Settins | critical |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | A 160-bit SHA-1 hash for CA Public Key | N |
| subjectKeyIdenrifier | A 160-bit SHA-1 hash for Subscriber Public Key | N |
| keyUsage | keyCertSign, cRLSign | Y |
| basicConstraints | Subject Type=CA
pathLenConstraints（The CA sets as necessary） | Y |
| certificatePolicies | policyIdentifier
certPolicyId=1.2.392.200091.100.901.7
policyQualifiers
policyQualifierID=id-qt-cps
qualifier=CPS=`http(s)://repository.secomtrust.net/SC-Root3/` (Optional)
\* ( ) is optional | N |
| subjectAltName | - | - |
| extKeyUsage | id-kp-timeStamping | N |
| cRLDistributionPoints | URI:`http://repository.secomtrust.net/SC-Root3/SCRoot3CRL.crl`
\* Optional if id-ad-ocsp accessMethod is present in the authorityInformationAccess extension. | N |
| authorityInformationAccess | accessMethod
id-ad-ocsp（1.3.6.1.5.5.7.48.1)
accessLocation
URI:`http://scrootca3.ocsp.secomtrust.net` (Optional if cRLDistributionPoints is present)
id-ad-caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI:`http://repository.secomtrust.net/SC-Root3/SCRoot3ca.cer`
\* Set OCSP, CA Issuers as necessary | N |
---
## Table: SECOM TimeStamping CA2 TSA, TA Certificates
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | sha256WithRSAEncryption |
| issuer | Information about the issuer (specified by the CAs) |
| validity | notBefore = A value within 24 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | Subscriber information |
| subjectPublicKeyInfo | Subject's Public Key Data |
| Extension Fields | Settings | critical |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | A 160-bit SHA-1 hash for CA Public Key | N |
| subjectKeyIdentifier | A 160-bit SHA-1 hash value of the Subject Public key | N |
| keyUsage | digitalSignature, nonRepudiation
(Other usages than [keyCertSign] and [cRLSign] may be specified by the CAs as necessary.) | Y |
| certificatePolicies | certPolicyId=1.2.392.200091.100.931.1
policyQualifierID=id-qt-cps
qualifier=`https://repo1.secomtrust.net/spcpp/ts/` | N |
| subjectAltName | - | - |
| extKeyUsage | id-kp-timeStamping | N |
| cRLDistributionPoints | URI:`http://repo1.secomtrust.net/spcpp/ts/ca2/fullCRL.crl` | N |
| authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
`http://ts2.ocsp.secomtrust.net` (Optional if cRLDistributionPoints is present)| N |
---
## Table: SECOM TimeStamping CA3 TSA, TA Certificates
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | Set one of the following：
sha256WithRSAEncryption
sha384WithRSAEncryption |
| issuer | Information about the issuer (specified by the CAs) |
| validity | notBefore = A value within 24 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | Subscriber information |
| subjectPublicKeyInfo | Subject's Public Key Data |
| Extension Fields | Settings | critical |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------- |
| authorityKeyIdentifier | A 160-bit SHA-1 hash for CA Public Key | N |
| subjectKeyIdenrifier | A 160-bit SHA-1 hash for Subscriber Public Key | N |
| keyUsage | digitalSignature (Other purposes other than keyCertSign and cRLSign may be set as necessary by this CA.) | Y |
| certificatePolicies | certPolicyId=1.2.392.200091.100.931.3
policyQualifierID=id-qt-cps
qualifier=`https://repo1.secomtrust.net/spcpp/ts/` | N |
| subjectAltName | - | - |
| extKeyUsage | id-kp-timeStamping | N |
| cRLDistributionPoints | URI:`http://repo1.secomtrust.net/spcpp/ts/ca3/fullCRL.crl`
\* Optional if id-ad-ocsp accessMethod is present in the authorityInformationAccess Extension. | N |
| authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
`http://ts3.ocsp.secomtrust.net` (Optional if cRLDistributionPoints is present)
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
HTTP URL of the CA Certificate
\* Set OCSP, CA Issuers as necessary| N |
---
## Table: SECOM TimeStamping CA4 TSA Certificates (Not issued after 2025-04-15)
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | Set one of the following：
sha256WithRSAEncryption
sha384WithRSAEncryption |
| issuer | Information about the issuer (specified by the CAs) |
| validity | notBefore = A value within 24 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | Subscriber information |
| subjectPublicKeyInfo | Subject's RSA Public Key Data (At least 3072 bit) |
| Extension Fields | Settins | critical |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | A 160-bit SHA-1 hash for CA Public Key | N |
| subjectKeyIdenrifier | A 160-bit SHA-1 hash for Subscriber Public Key | N |
| keyUsage | digitalSignature
(Other usages than [keyCertSign] and [cRLSign] may be specified by the CAs as necessary.) | Y |
| certificatePolicies | certPolicyId=1.2.392.200091.100.931.4
policyQualifierID=id-qt-cps
qualifier=`https://repo1.secomtrust.net/spcpp/ts/` | N |
| subjectAltName | - | - |
| extKeyUsage | timeStamping(1.3.6.1.5.5.7.3.8) | N |
| cRLDistributionPoints | URI:`http://repo1.secomtrust.net/spcpp/ts/ca4/fullCRL.crl` | N |
| authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
`http://ts4.ocsp.secom-cert.jp`
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
HTTP URL of the CA Certificate | N |
---
## Table: SECOM TimeStamping Service TSA Certificates
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | Set one of the following：
sha256WithRSAEncryption
sha384WithRSAEncryption |
| issuer | Information about the issuer (specified by the CAs) |
| validity | notBefore = A value within 24 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | Subscriber information |
| subjectPublicKeyInfo | Subject's Public Key Data |
| Extension Fields | Settins | critical |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | A 160-bit SHA-1 hash for CA Public Key | N |
| subjectKeyIdenrifier | A 160-bit SHA-1 hash for Subscriber Public Key | N |
| keyUsage | digitalSignature | Y |
| certificatePolicies | policyIdentifier
certPolicyId=1.2.392.200091.100.931.5
policyQualifiers
policyQualifierID=id-qt-cps
qualifier= HTTP(S) URL of the CA's Repository | N |
| subjectAltName | - | - |
| extKeyUsage | id-kp-timeStamping | N |
| cRLDistributionPoints | The HTTP URL of the CA's CRL Service
\* Optional if id-ad-ocsp accessMethod is present in the authorityInformationAccess extension. | N |
| authorityInformationAccess | accessMethod
id-ad-ocsp（1.3.6.1.5.5.7.48.1)
accessLocation
HTTP URL of the OCSP Responder (Optional if cRLDistributionPoints is present)
id-ad-caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
HTTP URL of the CA Certificate
\* Set OCSP, CA Issuers as necessary | N |
---