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
• 1. INTRODUCTION
  • 1.1 Overview
    • 1.1.1 Standards, Criteria and Regulations
  • 1.2 Document name and identification
    • 1.2.1 Revisions
  • 1.3 PKI Participants
    • 1.3.1 Certification Authorities
    • 1.3.2 Registration Authorities
      • 1.3.2.1 Enterprise registration authorities (S/MIME Certificates)
    • 1.3.3 Subscribers
    • 1.3.4 Relying Parties
    • 1.3.5 Other Participants
  • 1.4 Certificate Usage
    • 1.4.1 Appropriate Certificate Uses
    • 1.4.2 Prohibited Certificate Uses
  • 1.5 Policy administration
    • 1.5.1 Organization Administering the Document
    • 1.5.2 Contact Person
    • 1.5.3 Person Determining CPS suitability for the policy
    • 1.5.4 CPS approval procedures
  • 1.6 Definitions and Acronyms
    • 1.6.1 Definitions
    • 1.6.2 Acronyms
    • 1.6.3 References
    • 1.6.4 Conventions
• 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
  • 2.1 Repositories
  • 2.2 Publication of information
  • 2.3 Time or frequency of publication
  • 2.4 Access controls on repositories
• 3. IDENTIFICATION AND AUTHENTICATION
  • 3.1 Naming
    • 3.1.1 Types of names
    • 3.1.2 Need for names to be meaningful
    • 3.1.3 Anonymity or pseudonymity of subscribers
    • 3.1.4 Rules for interpreting various name forms
    • 3.1.5 Uniqueness of names
    • 3.1.6 Recognition, authentication, and role of trademarks
  • 3.2 Initial identity validation
    • 3.2.1 Method to prove possession of private key
    • 3.2.2 Authentication of Organization and Domain Identity
      • 3.2.2.1 Identity
        • 3.2.2.1.1 Validating authority over mailbox via domain (S/MIME Certificates)
        • 3.2.2.1.2 Validating control over mailbox via email (S/MIME Certificates)
        • 3.2.2.1.3 Validating applicant as operator of associated mail server(s) (S/MIME Certificates)
      • 3.2.2.2 DBA/Tradename
        • 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
          • 3.2.2.2.1.2 Acceptable Method of Verification
        • 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
          • 3.2.2.2.2.2 Acceptable Method of Verification
        • 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
        • 3.2.2.2.4 Verified Method of Communication (EV TLS Server Certificates)
          • 3.2.2.2.4.1 Verification Requirements
          • 3.2.2.2.4.2 Acceptable Methods of Verification
        • 3.2.2.2.5 Verification of Applicant's Operational Existence (EV TLS Server Certificates)
          • 3.2.2.2.5.1 Verification Requirements
          • 3.2.2.2.5.2 Acceptable Methods of Verification
        • 3.2.2.2.6 Verification of Applicant's Domain Name (EV TLS Server Certificates)
          • 3.2.2.2.6.1 Verification Requirements
        • 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
          • 3.2.2.2.7.2 Acceptable Methods of Verification – Name, Title and Agency
          • 3.2.2.2.7.3 Acceptable Methods of Verification – Authority
          • 3.2.2.2.7.4 Pre-Authorized Certificate Approver
        • 3.2.2.2.8 Verification of Signature on Subscriber Agreement and EV Certificate Requests (EV TLS Server Certificates)
          • 3.2.2.2.8.1 Verification Requirements
          • 3.2.2.2.8.2 Acceptable Methods of Signature Verification
        • 3.2.2.2.9 Verification of Approval of EV Certificate Request (EV TLS Server Certificates)
          • 3.2.2.2.9.1 Verification Requirements
          • 3.2.2.2.9.2 Acceptable Methods of Verification
        • 3.2.2.2.10 Verification of Certain Information Sources (EV TLS Server Certificates)
          • 3.2.2.2.10.1 Verified Legal Opinion
          • 3.2.2.2.10.2 Verified Accountant Letter
          • 3.2.2.2.10.3 Face-to-Face Validation
          • 3.2.2.2.10.4 Independent Confirmation From Applicant
          • 3.2.2.2.10.5 Qualified Independent Information Source
          • 3.2.2.2.10.6 Qualified Government Information Source
          • 3.2.2.2.10.7 Qualified Government Tax Information Source
        • 3.2.2.2.11 Other Verification Requirements (EV TLS Server Certificates)
          • 3.2.2.2.11.1 High Risk Status
          • 3.2.2.2.11.2 Denied Lists and Other Legal Block Lists
          • 3.2.2.2.11.3 Parent/Subsidiary/Affiliate Relationship
        • 3.2.2.2.12 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)
          • 3.2.2.2.13.1 Validation For Existing Subscribers
          • 3.2.2.2.13.2 Re-issuance Requests
          • 3.2.2.2.13.3 Age of Validated Data
      • 3.2.2.3 Verification of Country
      • 3.2.2.4 Validation of Domain Authorization or Control
        • 3.2.2.4.1 Validating the Applicant as a Domain Contact
        • 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact
        • 3.2.2.4.3 Phone Contact with Domain Contact
        • 3.2.2.4.4 Constructed Email to Domain Contact
        • 3.2.2.4.5 Domain Authorization Document
        • 3.2.2.4.6 Agreed-Upon Change to Website
        • 3.2.2.4.7 DNS Change
        • 3.2.2.4.8 IP Address
        • 3.2.2.4.9 Test Certificate
        • 3.2.2.4.10 TLS Using a Random Value
        • 3.2.2.4.11 Any Other Method
        • 3.2.2.4.12 Validating Applicant as a Domain Contact
        • 3.2.2.4.13 Email to DNS CAA Contact
        • 3.2.2.4.14 Email to DNS TXT Contact
        • 3.2.2.4.15 Phone Contact with Domain Contact
        • 3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact
        • 3.2.2.4.17 Phone Contact with DNS CAA Phone Contact
        • 3.2.2.4.18 Agreed-Upon Change to Website v2
        • 3.2.2.4.19 Agreed-Upon Change to Website - ACME
        • 3.2.2.4.20 TLS Using ALPN
      • 3.2.2.5 Authentication for an IP Address
      • 3.2.2.6 Wildcard Domain Validation
      • 3.2.2.7 Data Source Accuracy
      • 3.2.2.8 CAA Records
      • 3.2.2.9 Multi-Perspective Issuance Corroboration
    • 3.2.3 Authentication of individual identity
      • 3.2.3.1 Attribute collection of organization identity (S/MIME Certificates)
    • 3.2.4 Non-verified subscriber information
    • 3.2.5 Validation of authority
    • 3.2.6 Criteria for Interoperation or Certification
  • 3.3 Identification and authentication for re-key requests
    • 3.3.1 Identification and authentication for routine re-key
    • 3.3.2 Identification and authentication for re-key after revocation
  • 3.4 Identification and authentication for revocation request
• 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
  • 4.1 Certificate Application
    • 4.1.1 Who can submit a certificate application
    • 4.1.2 Enrollment process and responsibilities
  • 4.2 Certificate application processing
    • 4.2.1 Performing identification and authentication functions
    • 4.2.2 Approval or rejection of certificate applications
      • 4.2.2.1 Certification authority authorization (CAA) (S/MIME Certificates)
      • 4.2.2.2 Multi-perspective issuance corroboration (S/MIME Certificates)
    • 4.2.3 Time to process certificate applications
  • 4.3 Certificate issuance
    • 4.3.1 CA actions during certificate issuance
      • 4.3.1.1 Manual authorization of certificate issuance for Root CAs
      • 4.3.1.2 Linting of to-be-signed Certificate content
      • 4.3.1.3 Linting of issued Certificates
    • 4.3.2 Notification to subscriber by the CA of issuance of certificate
  • 4.4 Certificate acceptance
    • 4.4.1 Conduct constituting certificate acceptance
    • 4.4.2 Publication of the certificate by the CA
    • 4.4.3 Notification of certificate issuance by the CA to other entities
  • 4.5 Key pair and certificate usage
    • 4.5.1 Subscriber private key and certificate usage
    • 4.5.2 Relying party public key and certificate usage
  • 4.6 Certificate renewal
    • 4.6.1 Circumstance for certificate renewal
    • 4.6.2 Who may request renewal
    • 4.6.3 Processing certificate renewal requests
    • 4.6.4 Notification of new certificate issuance to subscriber
    • 4.6.5 Conduct constituting acceptance of a renewal certificate
    • 4.6.6 Publication of the renewal certificate by the CA
    • 4.6.7 Notification of certificate issuance by the CA to other entities
  • 4.7 Certificate re-key
    • 4.7.1 Circumstance for certificate re-key
    • 4.7.2 Who may request certification of a new public key
    • 4.7.3 Processing certificate re-keying requests
    • 4.7.4 Notification of new certificate issuance to subscriber
    • 4.7.5 Conduct constituting acceptance of a re-keyed certificate
    • 4.7.6 Publication of the re-keyed certificate by the CA
    • 4.7.7 Notification of certificate issuance by the CA to other entities
  • 4.8 Certificate modification
    • 4.8.1 Circumstance for certificate modification
    • 4.8.2 Who may request certificate modification
    • 4.8.3 Processing certificate modification requests
    • 4.8.4 Notification of new certificate issuance to subscriber
    • 4.8.5 Conduct constituting acceptance of modified certificate
    • 4.8.6 Publication of the modified certificate by the CA
    • 4.8.7 Notification of certificate issuance by the CA to other entities
  • 4.9 Certificate revocation and suspension
    • 4.9.1 Circumstances for revocation
      • 4.9.1.1 Reasons for Revoking a Subscriber Certificate
      • 4.9.1.2 Reasons for Revoking a Subordinate CA Certificate
    • 4.9.2 Who can request revocation
    • 4.9.3 Procedure for revocation request
    • 4.9.4 Revocation request grace period
    • 4.9.5 Time within which CA must process the revocation request
    • 4.9.6 Revocation checking requirement for relying parties
    • 4.9.7 CRL issuance frequency
    • 4.9.8 Maximum latency for CRLs (if applicable)
    • 4.9.9 On-line revocation/status checking availability
    • 4.9.10 On-line revocation checking requirements
    • 4.9.11 Other forms of revocation advertisements available
    • 4.9.12 Special requirements re key compromise
    • 4.9.13 Circumstances for suspension
    • 4.9.14 Who can request suspension
    • 4.9.15 Procedure for suspension request
    • 4.9.16 Limits on suspension period
  • 4.10 Certificate status services
    • 4.10.1 Operational characteristics
    • 4.10.2 Service availability
    • 4.10.3 Optional features
  • 4.11 End of subscription
  • 4.12 Key escrow and recovery
    • 4.12.1 Key escrow and recovery policy and practices
    • 4.12.2 Session key encapsulation and recovery policy and practices
• 5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS
  • 5.1 Physical Security Controls
    • 5.1.1 Site location and construction
    • 5.1.2 Physical access
    • 5.1.3 Power and air conditioning
    • 5.1.4 Water exposures
    • 5.1.5 Fire prevention and protection
    • 5.1.6 Media storage
    • 5.1.7 Waste disposal
    • 5.1.8 Off-site backup
  • 5.2 Procedural controls
    • 5.2.1 Trusted roles
    • 5.2.2 Number of Individuals Required per Task
    • 5.2.3 Identification and authentication for each role
    • 5.2.4 Roles requiring separation of duties
  • 5.3 Personnel controls
    • 5.3.1 Qualifications, experience, and clearance requirements
    • 5.3.2 Background check procedures
    • 5.3.3 Training Requirements and Procedures
    • 5.3.4 Retraining frequency and requirements
    • 5.3.5 Job rotation frequency and sequence
    • 5.3.6 Sanctions for unauthorized actions
    • 5.3.7 Independent Contractor Controls
    • 5.3.8 Documentation supplied to personnel
  • 5.4 Audit logging procedures
    • 5.4.1 Types of events recorded
      • 5.4.1.1 Router and firewall activities logs
      • 5.4.1.2 Types of events recorded for Timestamp Authorities
    • 5.4.2 Frequency of processing audit log
    • 5.4.3 Retention period for audit log
    • 5.4.4 Protection of audit log
    • 5.4.5 Audit log backup procedures
    • 5.4.6 Audit collection System (internal vs. external)
    • 5.4.7 Notification to event-causing subject
    • 5.4.8 Vulnerability assessments
  • 5.5 Records archival
    • 5.5.1 Types of records archived
    • 5.5.2 Retention period for archive
    • 5.5.3 Protection of archive
    • 5.5.4 Archive backup procedures
    • 5.5.5 Requirements for time-stamping of records
    • 5.5.6 Archive collection system (internal or external)
    • 5.5.7 Procedures to obtain and verify archive information
  • 5.6 Key changeover
  • 5.7 Compromise and disaster recovery
    • 5.7.1 Incident and compromise handling procedures
    • 5.7.2 Recovery Procedures if Computing resources, software, and/or data are corrupted
    • 5.7.3 Recovery Procedures after Key Compromise
    • 5.7.4 Business continuity capabilities after a disaster
  • 5.8 CA or RA termination
• 6. TECHNICAL SECURITY CONTROLS
  • 6.1 Key pair generation and installation
    • 6.1.1 Key pair generation
      • 6.1.1.1 CA Key Pair Generation
      • 6.1.1.2 RA Key Pair Generation
      • 6.1.1.3 Subscriber Key Pair Generation
    • 6.1.2 Private key delivery to subscriber
    • 6.1.3 Public key delivery to certificate issuer
    • 6.1.4 CA public key delivery to relying parties
    • 6.1.5 Key sizes
    • 6.1.6 Public key parameters generation and quality checking
    • 6.1.7 Key usage purposes (as per X.509 v3 key usage field)
  • 6.2 Private Key Protection and Cryptographic Module Engineering Controls
    • 6.2.1 Cryptographic module standards and controls
    • 6.2.2 Private key (n out of m) multi-person control
    • 6.2.3 Private key escrow
    • 6.2.4 Private key backup
    • 6.2.5 Private key archival
    • 6.2.6 Private key transfer into or from a cryptographic module
    • 6.2.7 Private key storage on cryptographic module
    • 6.2.8 Activating Private Keys
    • 6.2.9 Deactivating Private Keys
    • 6.2.10 Destroying Private Keys
    • 6.2.11 Cryptographic Module Rating
  • 6.3 Other aspects of key pair management
    • 6.3.1 Public key archival
    • 6.3.2 Certificate operational periods and key pair usage periods
  • 6.4 Activation data
    • 6.4.1 Activation data generation and installation
    • 6.4.2 Activation data protection
    • 6.4.3 Other aspects of activation data
  • 6.5 Computer security controls
    • 6.5.1 Specific computer security technical requirements
    • 6.5.2 Computer security rating
  • 6.6 Life cycle technical controls
    • 6.6.1 System development controls
    • 6.6.2 Security management controls
    • 6.6.3 Life cycle security controls
  • 6.7 Network security controls
  • 6.8 Time-stamping
• 7. CERTIFICATE, CRL, AND OCSP PROFILES
  • 7.1 Certificate profile
    • 7.1.1 Version number(s)
    • 7.1.2 Certificate Content and Extensions
      • 7.1.2.1 Root CA Certificate Profile
        • 7.1.2.1.1 Root CA Validity
        • 7.1.2.1.2 Root CA Extensions
        • 7.1.2.1.3 Root CA Authority Key Identifier
        • 7.1.2.1.4 Root CA Basic Constraints
      • 7.1.2.2 Cross-Certified Subordinate CA Certificate Profile
        • 7.1.2.2.1 Cross-Certified Subordinate CA Validity
        • 7.1.2.2.2 Cross-Certified Subordinate CA Naming
        • 7.1.2.2.3 Cross-Certified Subordinate CA Extensions
        • 7.1.2.2.4 Cross-Certified Subordinate CA Extended Key Usage - Unrestricted
        • 7.1.2.2.5 Cross-Certified Subordinate CA Extended Key Usage - Restricted
        • 7.1.2.2.6 Cross-Certified Subordinate CA Certificate Certificate Policies
      • 7.1.2.3 Technically Constrained Non-TLS Subordinate CA Certificate Profile
        • 7.1.2.3.1 Technically Constrained Non-TLS Subordinate CA Extensions
        • 7.1.2.3.2 Technically Constrained Non-TLS Subordinate CA Certificate Policies
        • 7.1.2.3.3 Technically Constrained Non-TLS Subordinate CA Extended Key Usage
      • 7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile
        • 7.1.2.4.1 Technically Constrained Precertificate Signing CA Extensions
        • 7.1.2.4.2 Technically Constrained Precertificate Signing CA Extended Key Usage
      • 7.1.2.5 Technically Constrained TLS Subordinate CA Certificate Profile
        • 7.1.2.5.1 Technically Constrained TLS Subordinate CA Extensions
        • 7.1.2.5.2 Technically Constrained TLS Subordinate CA Name Constraints
      • 7.1.2.6 TLS Subordinate CA Certificate Profile
        • 7.1.2.6.1 TLS Subordinate CA Extensions
      • 7.1.2.7 Subscriber (Server) Certificate Profile
        • 7.1.2.7.1 Subscriber Certificate Types
        • 7.1.2.7.2 Domain Validated
        • 7.1.2.7.3 Individual Validated
        • 7.1.2.7.4 Organization Validated
        • 7.1.2.7.5 Extended Validation
        • 7.1.2.7.6 Subscriber Certificate Extensions
        • 7.1.2.7.7 Subscriber Certificate Authority Information Access
        • 7.1.2.7.8 Subscriber Certificate Basic Constraints
        • 7.1.2.7.9 Subscriber Certificate Certificate Policies
        • 7.1.2.7.10 Subscriber Certificate Extended Key Usage
        • 7.1.2.7.11 Subscriber Certificate Key Usage
        • 7.1.2.7.12 Subscriber Certificate Subject Alternative Name
      • 7.1.2.8 OCSP Responder Certificate Profile
        • 7.1.2.8.1 OCSP Responder Validity
        • 7.1.2.8.2 OCSP Responder Extensions
        • 7.1.2.8.3 OCSP Responder Authority Information Access
        • 7.1.2.8.4 OCSP Responder Basic Constraints
        • 7.1.2.8.5 OCSP Responder Extended Key Usage
        • 7.1.2.8.6 OCSP Responder id-pkix-ocsp-nocheck
        • 7.1.2.8.7 OCSP Responder Key Usage
        • 7.1.2.8.8 OCSP Responder Certificate Policies
      • 7.1.2.9 Precertificate Profile
        • 7.1.2.9.1 Precertificate Profile Extensions - Directly Issued
        • 7.1.2.9.2 Precertificate Profile Extensions - Precertificate CA Issued
        • 7.1.2.9.3 Precertificate Poison
        • 7.1.2.9.4 Precertificate Authority Key Identifier
      • 7.1.2.10 Common CA Fields
        • 7.1.2.10.1 CA Certificate Validity
        • 7.1.2.10.2 CA Certificate Naming
        • 7.1.2.10.3 CA Certificate Authority Information Access
        • 7.1.2.10.4 CA Certificate Basic Constraints
        • 7.1.2.10.5 CA Certificate Certificate Policies
        • 7.1.2.10.6 CA Certificate Extended Key Usage
        • 7.1.2.10.7 CA Certificate Key Usage
        • 7.1.2.10.8 CA Certificate Name Constraints
      • 7.1.2.11 Common Certificate Fields
        • 7.1.2.11.1 Authority Key Identifier
        • 7.1.2.11.2 CRL Distribution Points
        • 7.1.2.11.3 Signed Certificate Timestamp List
        • 7.1.2.11.4 Subject Key Identifier
        • 7.1.2.11.5 Other Extensions
    • 7.1.3 Algorithm object identifiers
      • 7.1.3.1 SubjectPublicKeyInfo
        • 7.1.3.1.1 RSA
        • 7.1.3.1.2 ECDSA
      • 7.1.3.2 Signature AlgorithmIdentifier
        • 7.1.3.2.1 RSA
        • 7.1.3.2.2 ECDSA
    • 7.1.4 Name Forms
      • 7.1.4.1 Name Encoding
      • 7.1.4.2 Subject Attribute Encoding
      • 7.1.4.3 Subscriber Certificate Common Name Attribute
      • 7.1.4.4 Other Subject Attributes
    • 7.1.5 Name constraints
    • 7.1.6 Certificate policy object identifier
      • 7.1.6.1 Reserved Certificate Policy Identifiers
    • 7.1.7 Usage of Policy Constraints extension
    • 7.1.8 Policy qualifiers syntax and semantics
    • 7.1.9 Processing semantics for the critical Certificate Policies extension
  • 7.2 CRL profile
    • 7.2.1 Version number(s)
    • 7.2.2 CRL and CRL entry extensions
      • 7.2.2.1 CRL Issuing Distribution Point
  • 7.3 OCSP profile
    • 7.3.1 Version number(s)
    • 7.3.2 OCSP extensions
• 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
  • 8.1 Frequency or circumstances of assessment
  • 8.2 Identity/qualifications of assessor
  • 8.3 Assessor's relationship to assessed entity
  • 8.4 Topics covered by assessment
  • 8.5 Actions taken as a result of deficiency
  • 8.6 Communication of results
  • 8.7 Self-Audits
  • 8.8 Review of delegated parties
• 9. OTHER BUSINESS AND LEGAL MATTERS
  • 9.1 Fees
    • 9.1.1 Certificate issuance or renewal fees
    • 9.1.2 Certificate access fees
    • 9.1.3 Revocation or status information access fees
    • 9.1.4 Fees for other services
    • 9.1.5 Refund policy
  • 9.2 Financial responsibility
    • 9.2.1 Insurance coverage
    • 9.2.2 Other assets
    • 9.2.3 Insurance or warranty coverage for end-entities
  • 9.3 Confidentiality of business information
    • 9.3.1 Scope of confidential information
    • 9.3.2 Information not within the scope of confidential information
    • 9.3.3 Responsibility to protect confidential information
  • 9.4 Privacy of personal information
    • 9.4.1 Privacy plan
    • 9.4.2 Information treated as private
    • 9.4.3 Information not deemed private
    • 9.4.4 Responsibility to protect private information
    • 9.4.5 Notice and consent to use private information
    • 9.4.6 Disclosure pursuant to judicial or administrative process
    • 9.4.7 Other information disclosure circumstances
  • 9.5 Intellectual property rights
  • 9.6 Representations and warranties
    • 9.6.1 CA representations and warranties
    • 9.6.2 RA representations and warranties
    • 9.6.3 Subscriber representations and warranties
    • 9.6.4 Relying party representations and warranties
    • 9.6.5 Representations and warranties of other participants
  • 9.7 Disclaimers of warranties
  • 9.8 Limitations of liability
  • 9.9 Indemnities
  • 9.10 Term and termination
    • 9.10.1 Term
    • 9.10.2 Termination
    • 9.10.3 Effect of termination and survival
  • 9.11 Individual notices and communications with participants
  • 9.12 Amendments
    • 9.12.1 Procedure for amendment
    • 9.12.2 Notification mechanism and period
    • 9.12.3 Circumstances under which OID must be changed
  • 9.13 Dispute resolution provisions
  • 9.14 Governing law
  • 9.15 Compliance with applicable law
  • 9.16 Miscellaneous provisions
    • 9.16.1 Entire agreement
    • 9.16.2 Assignment
    • 9.16.3 Severability
    • 9.16.4 Enforcement (attorneys' fees and waiver of rights)
    • 9.16.5 Force Majeure
  • 9.17 Other provisions
• APPENDIX A – CAA Contact Tag
  • A.1. CAA Methods
    • A.1.1. CAA contactemail Property
    • A.1.2. CAA contactphone Property
  • A.2. DNS TXT Methods
    • A.2.1. DNS TXT Record Email Contact
    • A.2.2. DNS TXT Record Phone Contact
• APPENDIX B – Certificate profile
  • Table : "Security Communication RootCA2" and Subordinate CAs
  • Table : "Security Communication RootCA3" and Subordinate CAs
  • Table : "Security Communication ECC RootCA1" 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 TLS RSA 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 : 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 (AATL Document Signing Certificates)
  • Table: Subscriber Certificates (S/MIME Certificates)
  • 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 TimeStamping Subordinate CA Certificates (Issued after 2018-06-07)
  • Table: SECOM TimeStamping CA2 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 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, 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 for the audit scheme that CAs must follow.

Table: Standards, Criteria and Regulations List

* 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)

OID used when issuing a subordinate CA certificate from the Root CA

Table: OID (Root CA CP)

OID used when issuing EE certificates from a subordinate CA

Table: OID（Subordinate CA CP）

1.2.1 Revisions

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.

1.3.2 Registration Authorities

With the exception of Section 3.2.2.4 and Section 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.

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, when applicable to the delegated function;
2. Retain documentation in accordance with Section 5.5.2;
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) 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 or Section 3.2.2.1.3.

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.

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.

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. Current Members of the CA/Browser Forum who are Application Software Suppliers are listed here:
https://cabforum.org/members.

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 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:

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.

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.

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 (https://tools.ietf.org/html/rfc8659): "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, 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.

DNS CAA Phone Contact: The phone number defined in Appendix A.1.2.

DNS TXT Record Email Contact: The email address defined in Appendix A.2.1.

DNS TXT Record Phone Contact: The phone number defined in Appendix A.2.2.

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 (https://tools.ietf.org/html/rfc8499): "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 (https://tools.ietf.org/html/rfc5890): "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) 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 (https://tools.ietf.org/html/rfc5890): "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 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.

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.

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 <r2.csr` \| sed "s/[ -]//g" The script outputs: 201602251811c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f

Required Website Content: Either a Random Value or a Request Token, together with additional information that uniquely identifies the Subscriber, as specified by the CA.

Requirements: The Baseline Requirements found in this document.

Reserved IP Address: An IPv4 or IPv6 address that is contained in the address block of any entry in either of the following IANA registries:

https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

Root CA: The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.

Root Certificate: The self-signed Certificate issued by the Root CA to identify itself and to facilitate verification of Certificates issued to its Subordinate CAs.

Root Key Generation Script: A documented plan of procedures to be performed for the generation of the Root CA Key Pair.

RSA: One of the most standard encryption technologies widely used in the Public Key cryptosystem.

SHA-1 (Secure Hash Algorithm 1): A hash function used in digital signing. A hash function is a computation technique for generating a fixed-length string from a given text. The hash length is 160 bits. The algorithm works to detect any alterations in the original message during the transmission by comparing the hash values transmitted and received.

SHA-2 (Secure Hash Algorithm 2): A hash function of the Secure Hash Algorithm series used for digital signatures, which is an improved version of SHA-1. The bit length of SHA-256 is 256 bits, and the bit length of SHA-384 is 384 bits. By comparing the hash values on the transmitting side and the receiving side of the data, which works to detect whether the original text has been tampered or not during communication.

Short-lived Subscriber Certificate: For Certificates issued on or after 15 March 2024 and prior to 15 March 2026, a Subscriber Certificate with a Validity Period less than or equal to 10 days (864,000 seconds). For Certificates issued on or after 15 March 2026, a Subscriber Certificate with a Validity Period less than or equal to 7 days (604,800 seconds).

Sovereign State: A state or country that administers its own government, and is not dependent upon, or subject to, another power.

Subject: The natural person, device, system, unit, or Legal Entity identified in a Certificate as the Subject. The Subject is either the Subscriber or a device under the control and operation of the Subscriber.

Subject Identity Information: Information that identifies the Certificate Subject. Subject Identity Information does not include a Domain Name or an IP Address listed in the subjectAltName extension or the Subject commonName field.

Subordinate CA: A Certification Authority whose Certificate is signed by the Root CA, or another Subordinate CA.

Subscriber: A natural person or Legal Entity to whom a Certificate is issued and who is legally bound by a Subscriber Agreement or Terms of Use.

Subscriber Agreement: An agreement between the CA and the Applicant/Subscriber that specifies the rights and responsibilities of the parties.

Subsidiary Company: A company that is controlled by a Parent Company.

Technically Constrained Subordinate CA Certificate: A Subordinate CA certificate which uses a combination of Extended Key Usage and/or Name Constraint extensions, as defined within the relevant Certificate Profiles of this document, to limit the scope within which the Subordinate CA Certificate may issue Subscriber or additional Subordinate CA Certificates.

Terms of Use: Provisions regarding the safekeeping and acceptable uses of a Certificate issued in accordance with Baseline Requirements when the Applicant/Subscriber is an Affiliate of the CA or is the CA.

Test Certificate: This term is no longer used in these Baseline Requirements.

Trustworthy System: Computer hardware, software, and procedures that are: reasonably secure from intrusion and misuse; provide a reasonable level of availability, reliability, and correct operation; are reasonably suited to performing their intended functions; and enforce the applicable security policy.

Unregistered Domain Name: A Domain Name that is not a Registered Domain Name.

Valid Certificate: A Certificate that passes the validation procedure specified in RFC 5280.

Validation Specialist: Someone who performs the information verification duties specified by Baseline Requirements.

Validity Period: From RFC 5280 (https://tools.ietf.org/html/rfc5280): "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 (https://tools.ietf.org/html/rfc5890): "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

1.6.3 References

See Section 1.1

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 http://www.cabforum.org. 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. The CA shall indicate conformance with Section 1.1.1 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 and Section 3.1.2 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. 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. 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.

https://www.secomtrust.net/service/pfw/apply/ev/list.html

[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 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 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. 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.

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:

If the corporate number and establishment date cannot be confirmed by the CA, enter the following text in serialNumber.

If the subscriber is as follows, the CA will set the businessCategory as follows.

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 (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 (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.

   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 (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 (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 https://www.cabforum.org. 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 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 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 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), 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);

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.

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. 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 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.

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 (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 (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 (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, Section 3.2.2.2.4, Section 3.2.2.2.5.1, or Section 3.2.2.2.6.1, 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);

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. 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, 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 and Section 8.2.

In the case of EV Certificates to be issued in compliance with the requirements of Section 1.3.2, 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 (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;
3. The Applicant's Verified Method of Communication required by Section 3.2.2.2.4 but still MUST perform the verification required by Section 3.2.2.2.4.2 (B);
4. The Applicant's Operational Existence under Section 3.2.2.2.5;
5. The Name, Title, Agency and Authority of the Contract Signer, and Certificate Approver, under Section 3.2.2.2.7; and
6. The Applicant's right to use the specified Domain Name under Section 3.2.2.2.6, 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 and except when permitted otherwise in Section 3.2.2.2.13.1, 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 and Section 3.2.2.2.9.

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.

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.

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 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 dNSNames in the subjectAltName extension or in Subordinate CA Certificates via dNSNames 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 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. 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. 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. 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, or a 308 HTTP status code response, as defined in RFC 7538, Section 3. Redirects MUST be to the final value of the Location HTTP response header, as defined in RFC 7231, 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. 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. 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, or a 308 HTTP status code response, as defined in RFC 7538, Section 3. Redirects MUST be to the final value of the Location HTTP response header, as defined in RFC 7231, 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. 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. 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.

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) or IP address(es) (see Section 3.2.2.5) 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). 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) 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 or Section 7.1.2.5, 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 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

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;
2. An address of the Legal Entity (if included in the Subject);
3. 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 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 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 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 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, 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.

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. 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, 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. 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, 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. 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 limits the validity period of Subscriber Certificates. The CA MAY use the documents and data provided in Section 3.2 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 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 limits the validity period of Subscriber Certificates.

The CA MAY reuse completed validations and/or supporting evidence performed in accordance with Section 3.2 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 or Section 3.2.2.1.3 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, 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 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 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 or Section 3.2.2.5.

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.

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.

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 and Section 3.2.2.1.3) require CAA records to be retrieved and processed from additional remote Network Perspectives before Certificate issuance (see Section 4.2.2.2). 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, 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 of the TLS Baseline Requirements before March 15, 2025. Effective May 15, 2025 CAs SHALL implement Section 3.2.2.9 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 https://cabforum.org/resources/tools/).

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, 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 hereof shall apply.

4.6.3 Processing certificate renewal requests

The provisions of Section 4.3.1 - 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 hereof shall apply.

4.6.5 Conduct constituting acceptance of a renewal certificate

The provisions of Section 4.4.1 - 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 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 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 hereof shall apply.

4.7.3 Processing certificate re-keying requests

The provisions of Section 4.3.1 - 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 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 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 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 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 and Section 4.1.1 hereof shall apply.

4.8.3 Processing certificate modification requests

The provisions of Section 4.3.1 - 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 hereof shall apply.

4.8.5 Conduct constituting acceptance of modified certificate

The provisions of Section 4.4.1 - 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 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 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) 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) (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) if one or more of the following occurs:

6. The Certificate no longer complies with the requirements of Section 6.1.5 and Section 6.1.6 (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 https://wiki.debian.org/SSLkeys);
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 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 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 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 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 and Section 6.1.6;
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 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 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 and section 4.9.1.2.

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. 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, 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.

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 or Section 7.1.2.5, 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.

4.9.13 Circumstances for suspension

The Repository MUST NOT include entries that indicate that a Certificate is suspended.

See Section 7.2.2 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 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 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, 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 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 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 and the document retention and event logging requirements of Section 5.4.1.

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 and Section 4.10); 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 and Section 4.10).
   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); 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, 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 (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 (2)) after the expiration of the Subscriber Certificate;
3. Any security event records (as set forth in Section 5.4.1 (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); and the security event record after the event occurred (as specified in Section 5.4.1.2).

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).

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 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, 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); 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) 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 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 and/or Section 6.1.6;

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 and Section 4.9.12;

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 (https://wiki.debian.org/SSLkeys), the CA SHALL reject all keys found at https://github.com/cabforum/Debian-weak-keys/ 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, 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 https://github.com/crocs-muni/roca or equivalent.
   3. In the case of Close Primes vulnerability (https://fermatattack.secvuln.info/), 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: https://cabforum.org/resources/tools/

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 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.
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.

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 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. 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 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. 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.

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 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, and Section 6.1.6 - 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.

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. 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
  • Subordinate CA Certificates
    • Cross Certificates
      • Section 7.1.2.2 - Cross-Certified Subordinate CA Certificate Profile
    • Technically Constrained CA Certificates
      • Section 7.1.2.3 - Technically-Constrained Non-TLS Subordinate CA Certificate Profile
      • Section 7.1.2.4 - Technically-Constrained Precertificate Signing CA Certificate Profile
      • Section 7.1.2.5 - Technically-Constrained TLS Subordinate CA Certificate Profile
    • Section 7.1.2.6 - TLS Subordinate CA Certificate Profile
• Section 7.1.2.7 - Subscriber (End-Entity) Certificate Profile
• Section 7.1.2.8 - OCSP Responder Certificate Profile
• Section 7.1.2.9 - Precertificate Profile

7.1.2.1 Root CA Certificate Profile

7.1.2.1.1 Root CA Validity

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

7.1.2.1.3 Root CA Authority Key Identifier

7.1.2.1.4 Root CA Basic Constraints

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.

7.1.2.2.1 Cross-Certified Subordinate CA Validity

7.1.2.2.2 Cross-Certified Subordinate CA Naming

The subject MUST comply with the requirements of Section 7.1.4, 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 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

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

In all other cases, the extKeyUsage extension MUST be "restricted" as described in the following table:

Table: Cross-Certified Subordinate CA with Restricted EKU

[^eku_ca]: While RFC 5280, 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 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)

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.

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)

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)

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)

Table: Policy Restricted

This Profile RECOMMENDS that the first PolicyInformation value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see 7.1.6.1)[^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

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.

7.1.2.3.1 Technically Constrained Non-TLS Subordinate CA 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)

Table: Policy Restricted

Table: Permitted policyQualifiers

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.

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. 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. 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.

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.

7.1.2.4.1 Technically Constrained Precertificate Signing CA Extensions

7.1.2.4.2 Technically Constrained Precertificate Signing CA Extended Key Usage

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.

7.1.2.5.1 Technically Constrained TLS Subordinate CA 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

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

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

7.1.2.6.1 TLS Subordinate CA Extensions

7.1.2.7 Subscriber (Server) Certificate Profile

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.

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:

All subject names MUST be encoded as specified in Section 7.1.4.

The following table details the acceptable AttributeTypes 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

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:

All subject names MUST be encoded as specified in Section 7.1.4.

The following table details the acceptable AttributeTypes 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

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:

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

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.
• 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.

7.1.2.7.7 Subscriber Certificate Authority Information Access

The AuthorityInfoAccessSyntax MUST contain one or more AccessDescriptions. 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 AccessDescriptions with the same accessMethod, if permitted for that accessMethod. When multiple AccessDescriptions 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 AccessDescriptions that contain different accessMethods, provided that previous requirement is satisfied.

7.1.2.7.8 Subscriber Certificate Basic Constraints

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:

This Profile RECOMMENDS that the first PolicyInformation value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see 7.1.6.1)[^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

[^first_policy_note]: Although RFC 5280 allows PolicyInformations 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

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

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 (https://github.com/cabforum/servercert/issues/384).

Table: Key Usage for ECC Public Keys

Note: The keyAgreement bit is currently permitted, although setting it is NOT RECOMMENDED, as it is a Pending Prohibition (https://github.com/cabforum/servercert/issues/384).

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. Otherwise, this extension MUST NOT be marked critical.

Table: GeneralName within a subjectAltName extension

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. The Issuing CA of the Responder MUST be the same as the Issuing CA for the Certificates it provides responses for.

7.1.2.8.1 OCSP Responder Validity

7.1.2.8.2 OCSP Responder 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 AccessDescriptions. Each AccessDescription MUST only contain a permitted accessMethod, as detailed below, and each AuthorityInfoAccessSyntax MUST contain all required AccessDescriptions.

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.

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

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.

7.1.2.8.7 OCSP Responder Key Usage

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. 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. 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 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.

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. 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

Table: When the Precertificate is issued by a Precertificate Signing CA on behalf of an Issuing CA

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 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.

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. For such Precertificates, the authorityKeyIdentifier, if present in the Certificate, is modified in the Precertificate, as described in RFC 6962, Section 3.2.

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.

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.

Note: RFC 6962 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 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.

7.1.2.10.1 CA Certificate Validity

7.1.2.10.2 CA Certificate Naming

All subject names MUST be encoded as specified in Section 7.1.4.

The following table details the acceptable AttributeTypes that may appear within the type field of an AttributeTypeAndValue, as well as the contents permitted within the value field.

7.1.2.10.3 CA Certificate Authority Information Access

If present, the AuthorityInfoAccessSyntax MUST contain one or more AccessDescriptions. 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 AccessDescriptions with the same accessMethod, if permitted for that accessMethod. When multiple AccessDescriptions 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 AccessDescriptions that contain different accessMethods, provided that previous requirement is satisfied.

7.1.2.10.4 CA Certificate Basic Constraints

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)

Table: Policy Restricted

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)[^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

7.1.2.10.6 CA Certificate Extended Key Usage

7.1.2.10.7 CA Certificate Key Usage

[^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 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

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

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.

7.1.2.11.1 Authority Key Identifier

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

A fullName MUST contain at least one GeneralName; it MAY contain more than one. All GeneralNames 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.

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. 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:

  304106092a864886f70d01010a3034a00f300d0609608648016503040201
  0500a11c301a06092a864886f70d010108300d0609608648016503040201
  0500a203020120
  

• RSASSA-PSS with SHA-384, MGF-1 with SHA-384, and a salt length of 48 bytes:

  Encoding:

  304106092a864886f70d01010a3034a00f300d0609608648016503040202
  0500a11c301a06092a864886f70d010108300d0609608648016503040202
  0500a203020130
  

• RSASSA-PSS with SHA-512, MGF-1 with SHA-512, and a salt length of 64 bytes:

  Encoding:

  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.

This section details encoding rules that apply to all Certificates issued by a CA. Further restrictions may be specified within Section 7.1.2, 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. Specifically, this includes Technically Constrained Non-TLS Subordinate CA Certificates, as defined in Section 7.1.2.3, 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):

• 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, 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.
  • 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 RelativeDistinguishedNames unless explicitly allowed in Baseline Requirements.

Note: Section 7.1.2.2.2 provides an exception to the above Name encoding requirements when issuing a Cross-Certified Subordinate CA Certificate, 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.

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

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

[^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). 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, CAs MAY include additional attributes within the AttributeTypeAndValue beyond those specified in Section 7.1.4.2.

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.

7.1.7 Usage of Policy Constraints extension

Not set.