title: SECOM Publicly Trusted TLS Server Authentication Certificate Policy/Certification Practice Statement

subtitle: Version 1.00

author: SECOM Trust Systems CO., LTD.

date: 2025-10-22

copyright: © 2025 SECOM Trust Systems CO., LTD. This CP/CPS is licensed under the Creative Commons Attribution-NoDerivatives (CC-BY-ND) 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.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.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.4.21 DNS Labeled with Account ID ‑ ACME
      • 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.8.1 DNSSEC Validation of CAA Records
      • 3.2.2.9 Multi-Perspective Issuance Corroboration
    • 3.2.3 Authentication of individual identity
    • 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.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.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.1.1 Incident Response and Disaster Recovery Plans
      • 5.7.1.2 Mass Revocation Plans
    • 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 (Out of scope for this CP/CPS)
      • 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 TLS RSA Root CA 2024" and Subordinate CA
  • Table : "SECOM TLS ECC Root CA 2024" and Subordinate CA

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

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 TLS Server Authentication Certificate Policy/Certification Practice Statement".

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）

See Section 7.1.6.1 Reserved Certificate Policy Identifiers.

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.

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 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 this Committee. This CP/CPS goes into effect upon approval by this Committee for the CA.

1.6 Definitions and Acronyms

1.6.1 Definitions

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.

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.

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

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.

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

For subordinate CAs under SECOM TLS RSA Root CA 2024 and SECOM TLS ECC Root CA 2024, for each Baseline Requirements certificate policy OID that the corresponding hierarchy issues, the Applicant MUST use its automated solution to issue valid test TLS server authentication certificates (i.e., "Automation Test Certificates") intended to demonstrate its automation capabilities to the Chrome Root Program. Valid Automation Test Certificates MUST be renewed at least once every 30 calendar days.

Within 24 hours of issuance, CA SHOULD log final certificates to at least one CT log usable in Chrome at the time of issuance.

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.

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

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

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.

Effective 2026-03-15: DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective MUST:

• perform DNSSEC validation using the algorithm defined in RFC 4035 Section 5; and
• support NSEC3 as defined in RFC 5155; and
• support SHA-2 as defined in RFC 4509 and RFC 5702; and
• properly handle the security concerns enumerated in RFC 6840 Section 4.

Effective 2026-03-15: CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control.

DNSSEC validation back to the IANA DNSSEC root trust anchor MAY be performed on all DNS queries associated with the validation of domain authorization or control by Remote Network Perspectives used for Multi-Perspective Issuance Corroboration.

DNSSEC validation back to the IANA DNSSEC root trust anchor is considered outside the scope of self-audits performed to fulfill the requirements in 8.7 Self-Audits. 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 2025-01-15:

• 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 2025-07-15:

• 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

SECOM Trust Systems does not use this method on or after 2025-10-22.

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

• 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.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. 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 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.4.21 DNS Labeled with Account ID ‑ ACME

SECOM Trust Systems does not use this method.

3.2.2.5 Authentication for an IP Address

SECOM Trust Systems does not issue a certificate by authenticating the IP address.

3.2.2.6 Wildcard Domain Validation

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

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.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;
• the CA has confirmed that the domain is "Insecure" as defined in RFC 4035 Section 4.3.

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.8.1 DNSSEC Validation of CAA Records

Effective 2026-03-15: DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with CAA record lookups performed by the Primary Network Perspective MUST:

• perform DNSSEC validation using the algorithm defined in RFC 4035 Section 5; and
• support NSEC3 as defined in RFC 5155; and
• support SHA-2 as defined in RFC 4509 and RFC 5702; and
• properly handle the security concerns enumerated in RFC 6840 Section 4.

Effective 2026-03-15: CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups.

Effective 2026-03-15: DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue.

DNSSEC validation back to the IANA DNSSEC root trust anchor MAY be performed on all DNS queries associated with CAA record lookups performed by Remote Network Perspectives as part of Multi-Perspective Issuance Corroboration.

DNSSEC validation back to the IANA DNSSEC root trust anchor is considered outside the scope of self-audits performed to fulfill the requirements in Section 8.7.

3.2.2.9 Multi-Perspective Issuance Corroboration

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)

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.

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.

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.

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.

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 within the maximum number of days prior to issuing the Certificate, as defined in the following table:

Table: Subject Identity Information validation data reuse periods

For validation of Domain Names and IP Addresses according to Section 3.2.2.4 and Section 3.2.2.5, any data, document, or completed validation used MUST be obtained within the maximum number of days prior to issuing the Certificate, as defined in the following table:

Table: Domain Name and IP Address validation data reuse periods

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.

After the change to any validation method specified in the Baseline Requirements or EV Guidelines, a CA may continue to reuse validation data or documents collected prior to the change, or the validation itself, for the period stated in Section 4.2.1 unless otherwise specifically provided in a ballot.

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.

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

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

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.

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

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.

4.4.2 Publication of the certificate by the CA

The CA certificate of the CA will be published in the repository.

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

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

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

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.

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

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/Browser Forum's Network and Certificate System Security Requirements are incorporated by reference as if fully set forth herein.

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 physically secure data center. The data center is constructed at a location with low vulnerability to water exposures, earthquakes, fires, or other disasters, and structural measures have 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.

24/7 monitoring, access control with multi-factor authentication and multi-person control, and other physical security measures are enforced to prevent unauthorized entry, ensuring that the CA Infrastructure is always operated in a physically secure environment in accordance with the CA/Browser Forum's Network and Certificate System Security Requirements.

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

The CA SHALL maintain a documented change management process for Trusted Roles, Network Boundary Controls, and CA Infrastructure.
This process SHALL include:

• Annual review and update as needed;
• Risk assessment for changes to Trusted Roles, Network Boundary Controls, or CA Infrastructure;
• Procedures for managing exceptions and emergency changes;
• Procedures for change reversal where applicable.

All changes to Trusted Role definitions, appointments, Network Boundary Controls, and CA Infrastructure MUST be completed in accordance with this change management process.

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.

Each Trusted Role SHALL have its responsibilities, privileges, and access documented, and SHALL be assigned in accordance with the Principle of Least Privilege and the Principle of Separation of Duties.

Group accounts or shared credentials SHOULD NOT be used to access CA Infrastructure or Network Boundary Controls.
If group accounts or shared credentials are used, each use MUST be attributable to an approved activity and an individual user or service account.

Authentication credentials MUST be changed or revoked when associated authorizations are changed or revoked.
Access to CA Infrastructure and Network Boundary Controls MUST be disabled for personnel within twenty-four (24) hours of termination of employment or contracting relationship.

All accounts capable of authenticating to or accessing CA Infrastructure or Network Boundary Controls SHALL be reviewed at least every three (3) months, and any unnecessary accounts SHALL be deactivated or removed.

Security measures SHALL be implemented to minimize susceptibility to unauthorized access through repeated authentication attempts (e.g., brute-force attacks), based on a documented risk assessment.

Workstations SHALL be configured to prevent continued access after a set period of inactivity (e.g., automatic logoff), with the duration selected based on risk assessment.

Physical access to any Root CA System SHALL require Multi-Party Control.

Passwords used as authentication credentials SHOULD be generated and managed in accordance with NIST 800-63B Revision 3 Appendix A.

Any remote connection enabling Privileged Access to CA Infrastructure MUST:

• originate from a workstation owned and/or controlled by the CA;
• be made through a temporary, non-persistent, and encrypted channel;
• be authenticated using Multi-Factor Authentication;
• be made to a Network Boundary Control asset located within the CA’s network, secured in accordance with these Requirements, and mediating the remote connection.

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

The CA SHALL identify and document the monitoring and logging capabilities of CA Infrastructure and Network Boundary Controls.
Policies and procedures for monitoring and logging SHALL be reviewed at least annually and updated as needed.

The integrity of logging processes SHALL be monitored through continuous automated monitoring or review by Trusted Roles at least once every 31 days.

Audit logs SHALL be retained and/or archived for the time necessary to meet these Requirements and applicable obligations, and managed to prevent unauthorized alteration or access.

Audit logs SHALL be processed through automated mechanisms under the control of Trusted Roles, to identify possible Critical Security Events and unauthorized changes.

Personnel assigned to Trusted Roles SHALL be alerted via multiple mechanisms and/or communication channels of identified possible audit log compromise, Critical Security Events, and unauthorized changes.

Personnel assigned to Trusted Roles SHALL commence an initial response to such alerts within twenty-four (24) hours of the alert being generated.

Incident response plans SHOULD include identification of the potential impact, scope, and severity of the incident; containment to minimize further impact; and identification and mitigation or eradication of the root cause(s).

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

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

5.7.1.1 Incident Response and Disaster Recovery Plans

Upon detection of an incident, personnel assigned to applicable Trusted Roles shall commence an initial response within 24 hours of the alert being generated, and all actions shall be recorded. In the case of major incidents, prompt notification to relevant parties and authorities shall be performed.

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.

5.7.1.2 Mass Revocation Plans

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.

CA organizations MUST have a mass revocation plan, and as of December 1, 2025, they SHALL assert in section 5.7.1 of their CPS or combined CP/CPS that they maintain a comprehensive and actionable plan for mass revocation events, that they perform annual testing of the mass revocation plan, and that they incorporate lessons learned into such plan in order to continually improve their preparedness for mass revocation events over time.

The CA's mass revocation plan MUST include clearly defined, actionable, and comprehensive procedures designed to ensure rapid, consistent, and reliable response to large-scale certificate revocation scenarios. The CA is not required to publicly disclose its mass revocation plan or procedures but MUST make them available to its auditors upon request. The CA SHALL annually test, review, and update its plan and such procedures. The CA's mass revocation plan MAY be integrated into the CA's incident response, business continuity, disaster recovery, or other similar plans or procedures, provided that provisions governing mass revocation events remain clearly identifiable and satisfy these requirements.

Mass revocation provisions MUST include:

1. Activation criteria – specific, objective, and measurable thresholds at which the mass revocation plan is triggered based on the CA’s risk profile, issuance volumes, and operational capabilities;
2. Customer contact information – how subscriber and customer contact details are stored, maintained, and kept up to date;
3. Automation points – processes that are automated or could be automated, and those processes that require manual intervention;
4. Targets and timelines – for incident triage, revocation initiation, certificate replacement, and post-event review;
5. Subscriber notification methods – mechanisms for notifying impacted Subscribers;
6. Role assignments – roles and responsibilities of personnel responsible for initiating, coordinating, and executing the plan;
7. Training and education – training, awareness, and readiness activities for personnel responsible for, or supporting, the plan;
8. Plan testing – annual operational testing to assess readiness and demonstrate implementation feasibility, using one or more of tabletop exercises, simulations, parallel testing, or controlled test environments that DO NOT involve the revocation of active Subscriber Certificates; and
9. Post-test analysis and update schedule – how lessons learned from testing or live incidents are incorporated into the plan, and how often it is reviewed and updated.

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.

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.

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

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.

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.

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.

Subscriber Certificates issued before 2026-03-15 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.

Subscriber Certificates issued on or after 2026-03-15 and before 2027-03-15 SHOULD NOT have a Validity Period greater than 199 days and MUST NOT have a Validity Period greater than 200 days.

Subscriber Certificates issued on or after 2027-03-15 and before 2029-03-15 SHOULD NOT have a Validity Period greater than 99 days and MUST NOT have a Validity Period greater than 100 days.

Subscriber Certificates issued on or after 2029-03-15 SHOULD NOT have a Validity Period greater than 46 days and MUST NOT have a Validity Period greater than 47 days.

Table: Reference for maximum Validity Periods of Subscriber Certificates

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

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 shall define, document, and maintain an inventory of its CA Infrastructure, including certificate management systems, CA servers, HSMs, network devices, and supporting systems. The inventory shall be reviewed annually and updated upon any changes in accordance with the CA/Browser Forum's Network and Certificate System Security Requirements separate networks based on functional and logical relationships. Network segmentation SHALL be designed and implemented to:

• minimize attack surfaces;
• limit lateral movement within networks;
• restrict traffic flow between different network segments; and
• protect all CA Infrastructure components from unauthorized access.

Network segmentation SHALL be implemented using Network Boundary Controls such as firewalls, network switches, physically separate networks, or software-defined networking. Software-based segmentation methods, such as VLANs, VLAN access control lists, and VPNs, MAY also be leveraged as appropriate.

All systems located on the same network as any CA Infrastructure component MUST implement equivalent security controls as required for CA Infrastructure.

Root CA Systems SHALL be physically separated from all other CA Infrastructure.

Connections to CA Infrastructure SHALL be authenticated and encrypted, except where a formal specification prohibits or limits the use of authentication and/or encryption.

The CA SHALL implement intrusion detection and prevention systems (IDS/IPS), disable unused network ports and services, and enforce multi-factor authentication for administrative access.

The policies and procedures in this section apply to all Certificate Systems, Security Support Systems, and Network Boundary Controls.

The CA MUST document and follow a vulnerability correction process that includes:

identification; review; response; and remediation.

Vulnerability management requirements:

• Penetration tests SHALL be performed at least annually, and after significant infrastructure or application changes, by qualified and independent personnel using appropriate tools and methods.
• The vulnerability identification process SHALL include continuous monitoring for relevant security advisories.
• For any vulnerability assessed as Critical or High, a response plan SHALL be determined within 72 hours of discovery.
• For High or Medium risk vulnerabilities, remediation SHALL be completed within a timeframe defined by the CA based on risk assessment, which SHALL normally not exceed 60 days.
• A vulnerability SHALL be considered remediated when it has been fixed such that it is no longer present, or the impact has been confirmed and documented as not affecting the CA's security posture.
• All actions and results SHALL be documented and subject to audit.

In case of an active intrusion or compromise, certificate issuance SHALL be suspended until the incident is mitigated.

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.

This Section describes the profiles applicable from 2023-09-15 onward.
For CA profiles for TLS server certificates issued before 2023-09-15, and for profiles other than TLS server certificates, refer to 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 (Out of scope for this CP/CPS)
      • 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 (Out of scope for this CP/CPS)

No stipulation.

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

*1

• For subordinate CAs under SECOM TLS RSA Root CA 2024 and SECOM TLS ECC Root CA 2024, id-kp-clientAuth MUST NOT be included on or after 2025-06-15.
• For subordinate CAs under other root CAs, id-kp-clientAuth MUST NOT be included on or after 2026-06-15.

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.

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 and EV Guidelines.

7.1.7 Usage of Policy Constraints extension

Not set.

7.1.8 Policy qualifiers syntax and semantics

For the policy qualifier, the URI of the Web page that publishes this CP/CPS MAY be stored.

7.1.9 Processing semantics for the critical Certificate Policies extension

Not set.

7.2 CRL profile

Prior to 2024‐03‐15, the CA SHALL issue CRLs in accordance with the profile specified in Baseline Requirements or the profile specified in Version 1.8.7 of the Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates. Effective 2024‐03‐15, the CA SHALL issue CRLs in accordance with the profile specified in Baseline Requirements.

If the CA asserts compliance with these Baseline Requirements, all CRLs that it issues MUST comply with the following CRL profile, which incorporates, and is derived from RFC 5280. Except as explicitly noted, all normative requirements imposed by RFC 5280 shall apply, in addition to the normative requirements imposed by this document. CAs SHOULD examine RFC 5280, Appendix B for further issues to be aware of.

A full and complete CRL is a CRL whose scope includes all Certificates issued by the CA.

A partitioned CRL (sometimes referred to as a "sharded CRL") is a CRL with a constrained scope, such as all Certificates issued by the CA during a certain period of time ("temporal sharding"). Aside from the presence of the Issuing Distribution Point extension (OID 2.5.29.28) in partitioned CRLs, both CRL formats are syntactically the same from the perspective of this profile.

Minimally, CAs MUST issue either a "full and complete" CRL or a set of "partitioned" CRLs which cover the complete set of Certificates issued by the CA within 7 days of such CA issuing its first certificate. In other words, if issuing only partitioned CRLs, the combined scope of those CRLs must be equivalent to that of a full and complete CRL.

CAs MUST NOT issue indirect CRLs (i.e., the issuer of the CRL is not the issuer of all Certificates that are included in the scope of the CRL).

Table: CRL Fields

7.2.1 Version number(s)

Certificate Revocation Lists MUST be of type X.509 v2.

7.2.2 CRL and CRL entry extensions

Table: CRL Extensions

Table: revokedCertificates Component

Note: [TLS Server Certificates] The CA SHOULD update the revocation date in a CRL entry when it is determined that the private key of the Certificate was compromised prior to the revocation date that is indicated in the CRL entry for that Certificate. Backdating the revocationDate field is an exception to best practice described in RFC 5280 (Section 5.3.2); however, Baseline Requirements specify the use of the revocationDate field to support TLS implementations that process the revocationDate field as the date when the Certificate is first considered to be compromised.

Table: crlEntryExtensions Component

Table: CRLReasons

The Subscriber Agreement, or an online resource referenced therein, MUST inform Subscribers about the revocation reason options listed above and provide explanation about when to choose each option. Tools that the CA provides to the Subscriber MUST allow for these options to be easily specified when the Subscriber requests revocation of their Certificate, with the default value being that no revocation reason is provided (i.e. the default corresponds to the CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL).

The privilegeWithdrawn reasonCode SHOULD NOT be made available to the Subscriber as a revocation reason option, because the use of this reasonCode is determined by the CA and not the Subscriber.

When a CA obtains verifiable evidence of Key Compromise for a Certificate whose CRL entry does not contain a reasonCode extension or has a reasonCode extension with a non-keyCompromise reason, the CA SHOULD update the CRL entry to enter keyCompromise as the CRLReason in the reasonCode extension.

7.2.2.1 CRL Issuing Distribution Point

Partitioned CRLs MUST contain an Issuing Distribution Point extension. The distributionPoint field of the Issuing Distribution Point extension MUST be present. Additionally, the fullName field of the DistributionPointName value MUST be present, and its value MUST conform to the following requirements:

1. If a Certificate within the scope of the CRL contains a CRL Distribution Points extension, then at least one of the uniformResourceIdentifiers in the CRL Distribution Points's fullName field MUST be included in the fullName field of the CRL's Issuing Distribution Point extension. The encoding of the uniformResourceIdentifier value in the Issuing Distribution Point extension SHALL be byte-for-byte identical to the encoding used in the Certificate's CRL Distribution Points extension.
2. Other GeneralNames of type uniformResourceIdentifier MAY be included.
3. Non-uniformResourceIdentifier GeneralName types MUST NOT be included.

The indirectCRL and onlyContainsAttributeCerts fields MUST be set to FALSE (i.e., not asserted).

The CA MAY set either of the onlyContainsUserCerts and onlyContainsCACerts fields to TRUE, depending on the scope of the CRL.

The CA MUST NOT assert both of the onlyContainsUserCerts and onlyContainsCACerts fields.

The onlySomeReasons field SHOULD NOT be included; if included, then the CA MUST provide another CRL whose scope encompasses all revocations regardless of reason code.

This extension is NOT RECOMMENDED for full and complete CRLs.

7.3 OCSP profile

If an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross-Certified Subordinate CA Certificates, and that certificate has been revoked, then the revocationReason field within the RevokedInfo of the CertStatus MUST be present.

The CRLReason indicated MUST contain a value permitted for CRLs, as specified in Section 7.2.2.

7.3.1 Version number(s)

The CA uses OCSP Version 1.

7.3.2 OCSP extensions

The singleExtensions of an OCSP response MUST NOT contain the reasonCode (OID 2.5.29.21) CRL entry extension.

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

The CA SHALL at all times:

1. Issue Certificates and operate its PKI in accordance with all law applicable to its business and the Certificates it issues in every jurisdiction in which it operates;
2. Comply with Baseline Requirements;
3. Comply with the audit requirements specified in the CP/CPS; and
4. Be licensed as a CA in each jurisdiction where it operates, if licensing is required by the law of such jurisdiction for the issuance of Certificates.

8.1 Frequency or circumstances of assessment

Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with Section 7.1.2.4, or Section 7.1.2.5, as well as audited in line with Section 8.7 only, or Unconstrained and fully audited in line with all remaining requirements from this section. A Certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 basicConstraints extension, with the cA boolean set to true and is therefore by definition a Root CA Certificate or a Subordinate CA Certificate.

The period during which the CA issues Certificates SHALL be divided into an unbroken sequence of audit periods. An audit period MUST NOT exceed one year in duration.

If the CA does not have a currently valid Audit Report indicating compliance with one of the audit schemes listed in Section 8.4, then, before issuing Publicly-Trusted Certificates, the CA SHALL successfully complete a point-in-time readiness assessment performed in accordance with applicable standards under one of the audit schemes listed in Section 8.4. The point-in-time readiness assessment SHALL be completed no earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates and SHALL be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate.

8.2 Identity/qualifications of assessor

The CA's audit SHALL be performed by a Qualified Auditor. A Qualified Auditor means a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively possess the following qualifications and skills:

1. Independence from the subject of the audit;
2. The ability to conduct an audit that addresses the criteria specified in an Eligible Audit Scheme (see Section 8.4);
3. Employs individuals who have proficiency in examining Public Key Infrastructure technology, information security tools and techniques, information technology and security auditing, and the third-party attestation function;
4. (For audits conducted in accordance with the WebTrust standard) licensed by WebTrust;
5. Bound by law, government regulation, or professional code of ethics; and
6. Except in the case of an Internal Government Auditing Agency, maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage

8.3 Assessor's relationship to assessed entity

Auditors shall be operationally and organizationally independent of the assessed entity, except for the audit-related aspects. In conducting the audits, the assessed entity shall provide appropriate support to the effort.

8.4 Topics covered by assessment

The CA SHALL undergo an audit in accordance with the following schemes:

1. WebTrust (TLS Server CA):

   • "Principles and Criteria for Certification Authorities" Version 2.2 or newer; and either
     • "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security" Version 2.7 or newer; or
     • "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline" Version 2.8 or newer and "WebTrust Principles and Criteria for Certification Authorities – Network Security" Version 1.0 or newer

It MUST incorporate periodic monitoring and/or accountability procedures to ensure that its audits continue to be conducted in accordance with the requirements of the scheme.

The audit MUST be conducted by a Qualified Auditor, as specified in Section 8.2.

For Delegated Third Parties which are not Enterprise RAs, then the CA SHALL obtain an audit report, issued under the auditing standards that underlie the accepted audit schemes found in Section 8.4, that provides an opinion whether the Delegated Third Party's performance complies with either the Delegated Third Party's practice statement or the CA's CP/CPS. If the opinion is that the Delegated Third Party does not comply, then the CA SHALL not allow the Delegated Third Party to continue performing delegated functions.

The audit period for the Delegated Third Party SHALL NOT exceed one year (ideally aligned with the CA's audit).

8.5 Actions taken as a result of deficiency

SECOM Trust Systems promptly implements corrective measures with respect to the deficiencies identified in the audit report.

8.6 Communication of results

The Audit Report SHALL state explicitly that it covers the relevant systems and processes used in the issuance of all Certificates that assert one or more of the policy identifiers listed in Section 7.1.6.1. The CA SHALL make the Audit Report publicly available.

The CA MUST make its Audit Report publicly available no later than three months after the end of the audit period. In the event of a delay greater than three months, the CA SHALL provide an explanatory letter signed by the Qualified Auditor.

The Audit Report MUST contain at least the following clearly-labelled information:

1. name of the organization being audited;
2. name and address of the organization performing the audit;
3. the SHA-256 fingerprint of all Roots and Subordinate CA Certificates, including Cross-Certified Subordinate CA Certificates, that were in-scope of the audit;
4. audit criteria, with version number(s), that were used to audit each of the certificates (and associated keys);
5. a list of the CA policy documents, with version numbers, referenced during the audit;
6. whether the audit assessed a period of time or a point in time;
7. the start date and end date of the Audit Period, for those that cover a period of time;
8. the point in time date, for those that are for a point in time;and
9. the date the report was issued, which will necessarily be after the end date or point in time date.

An authoritative English language version of the publicly available audit information MUST be provided by the Qualified Auditor and the CA SHALL ensure it is publicly available.

The Audit Report MUST be available as a PDF, and SHALL be text searchable for all information required. Each SHA-256 fingerprint within the Audit Report MUST be uppercase letters and MUST NOT contain colons, spaces, or line feeds.

8.7 Self-Audits

• TLS Server CA

  During the period in which the CA issues Certificates, the CA SHALL monitor adherence to its Certificate Policy, Certification Practice Statement and Baseline Requirements and strictly control its service quality by performing self audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken.

  Effective 2025-03-15, the CA SHOULD use a Linting process to verify the technical accuracy of Certificates within the selected sample set independently of previous linting performed on the same Certificates.

  Except for Delegated Third Parties that undergo an annual audit that meets the criteria specified in Section 8.4, the CA SHALL strictly control the service quality of Certificates issued or containing information verified by a Delegated Third Party by having a Validation Specialist employed by the CA perform ongoing quarterly audits against a randomly selected sample of at least the greater of one certificate or three percent of the Certificates verified by the Delegated Third Party in the period beginning immediately after the last sample was taken. The CA SHALL review each Delegated Third Party's practices and procedures to ensure that the Delegated Third Party is in compliance with Baseline Requirements and the relevant CP/CPS.

  The CA SHALL internally audit each Delegated Third Party's compliance with Baseline Requirements on an annual basis.

  During the period in which a Technically Constrained Subordinate CA issues Certificates, the CA which signed the Subordinate CA SHALL monitor adherence to the CA's Certificate Policy and the Subordinate CA's Certification Practice Statement. On at least a quarterly basis, against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by the Subordinate CA, during the period commencing immediately after the previous audit sample was taken, the CA shall ensure all applicable CP are met.

• EV TLS Server CA

  During the period in which it issues EV Certificates, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least three percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. For all EV Certificates where the Final Cross-Correlation and Due Diligence requirements of Section 3.2.2.2.12 is performed by an RA, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least six percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken.

8.8 Review of delegated parties

Except for Delegated Third Parties, Enterprise RAs, and Technically Constrained Subordinate CAs that undergo an annual audit that meets the criteria specified in Section 8.4, the CA SHALL ensure the practices and procedures of delegated parties are in compliance with these Requirements and the relevant CP and/or CPS. The CA shall document the obligations of delegated parties and perform monitoring on at least an annual basis of the delegated parties' adherence with those obligations.

9. OTHER BUSINESS AND LEGAL MATTERS

9.1 Fees

9.1.1 Certificate issuance or renewal fees

Stipulated separately in contracts.

9.1.2 Certificate access fees

No stipulation.

9.1.3 Revocation or status information access fees

No stipulation.

9.1.4 Fees for other services

No stipulation.

9.1.5 Refund policy

Stipulated separately in contracts.

9.2 Financial responsibility

9.2.1 Insurance coverage

[EV TLS Server Certificates]

The CA shall maintain a sufficient financial resources for the operation and maintenance. The CA SHALL maintain the following insurance related to their respective performance and obligations the EV Guidelines:

A. Commercial General Liability insurance (occurrence form) with policy limits of at least two million US dollars in coverage;

B. Professional Liability/Errors and Omissions insurance, with policy limits of at least five million US dollars in coverage, and including coverage for:

• i. claims for damages arising out of an act, error, or omission, unintentional breach of contract, or neglect in issuing or maintaining EV Certificates,

• ii. claims for damages arising out of infringement of the proprietary rights of any third party (excluding copyright, and trademark infringement), and invasion of privacy and advertising injury.

Such insurance must be with a company rated no less than A- as to Policy Holder's Rating in the current edition of Best's Insurance Guide (or with an association of companies each of the members of which are so rated). The CA MAY self-insure for liabilities that arise from such party's performance and obligations under these Guidelines provided that it has at least five hundred million US dollars in liquid assets based on audited financial statements in the past twelve months, and a quick ratio (ratio of liquid assets to current liabilities) of not less than 1.0.

9.2.2 Other assets

No stipulation.

9.2.3 Insurance or warranty coverage for end-entities

No stipulation.

9.3 Confidentiality of business information

9.3.1 Scope of confidential information

Information on individuals and organizations in the possession of SECOM Trusts Systems are subject to confidentiality with the exception of those that were explicitly published as a part of a Certificate, a CRL, this CP/CPS.

SECOM Trust Systems does not disclose such information externally unless it is required by law or there is a prior consent of the relevant Subscriber. SECOM Trust Systems may disclose the information subject to confidentiality to a legal counsel or a financial adviser who provides advice in connection with such legal, judicial, administrative or other procedures required by law. It may also disclose information subject to confidentiality to an attorney, an accountant, a legal institution or any other specialist who provides advice on corporate mergers, acquisitions or restructuring.

Subscriber Private Keys are deemed to be information to be kept confidential by the Subscriber's own responsibility. The Services in no circumstances provide access to these Keys. Information contained in Audit Log and the Audit Reports themselves are subject to the confidentiality and within the Scope of Confidential Information. SECOM Trust Systems will not disclose such information to any external party in other situation than a case stipulated in Section 8.6 or unless it is required by law.

9.3.2 Information not within the scope of confidential information

Information populated in Certificates and CRLs is not considered confidential. In addition, the following information shall not be subject to the confidentiality provisions herein:

• Information that is or came to be known through no fault of SECOM Trust Systems;
• Information that was or is made known to SECOM Trust Systems by a party other than SECOM Trust Systems without confidentiality requirements;
• Information independently developed by SECOM Trust Systems; or
• Information approved for disclosure by the relevant Subscriber.

9.3.3 Responsibility to protect confidential information

SECOM Trust Systems may disclose confidential information when required by law or there is a prior consent of the relevant Subscriber. In the event of the foregoing, the party having come to acquire the information may not disclose said information to a third party due to contractual or legal constraints.

9.4 Privacy of personal information

9.4.1 Privacy plan

SECOM Trust Systems will use the personal information collected from the subscribers of our authentication service to the extent necessary for the operation of this CA operated on the Digital Certification Infrastructure, such as confirming the application details, sending necessary documents, etc., and confirming who is authorized. SECOM Trust Systems's privacy policy will be announced on SECOM Trust Systems's website (http://www.secomtrust.net).

9.4.2 Information treated as private

SECOM Trust Systems treats information defined as personal information based on domestic laws and regulations (such as information collected from subscribers of SECOM authentication services) as personal information and manages it appropriately.

9.4.3 Information not deemed private

SECOM Trust Systems treats personal information as specified in Section 9.4.2.

9.4.4 Responsibility to protect private information

SECOM Trust Systems shall not disclose any personal information of the other party that it has learned during the execution and termination of the contract to third parties, whether during or after the contract period. The personal information protection manager shall be appointed and ensure employees comply with personal information protection policy.

9.4.5 Notice and consent to use private information

SECOM Trust Systems shall not use personal information for any purpose other than the purpose of obtaining the consent of the certificate subscriber, except as provided by law. The personal number and specific personal information will be used for the purpose of use permitted by law and for the purpose of use with the consent of the certificate subscriber.

9.4.6 Disclosure pursuant to judicial or administrative process

If disclosure is requested by law, rule, court decision/order, administrative agency order /instruction, etc., the personal information of the certificate subscriber may be disclosed.

9.4.7 Other information disclosure circumstances

No stipulation.

9.5 Intellectual property rights

Unless otherwise agreed to between SECOM Trust Systems and Subscribers, the following informative materials and data pertaining to the Services shall belong to the parties specified as below:

9.6 Representations and warranties

9.6.1 CA representations and warranties

By issuing a Certificate, the CA makes the certificate warranties listed herein to the following Certificate Beneficiaries:

1. The Subscriber that is a party to the Subscriber Agreement or Terms of Use for the Certificate;
2. All Application Software Suppliers with whom the Root CA has entered into a contract for inclusion of its Root Certificate in software distributed by such Application Software Supplier; and
3. All Relying Parties who reasonably rely on a Valid Certificate. The CA represents and warrants to the Certificate Beneficiaries that, during the period when the Certificate is valid, the CA has complied with Baseline Requirements and its CP/CPS in issuing and managing the Certificate.

The Certificate Warranties specifically include, but are not limited to, the following:

1. Right to Use Domain Name [TLS Server Certificates]: That, at the time of issuance, the CA

   i. implemented a procedure for verifying that the Applicant either had the right to use, or had control of, the Domain Name(s) listed in the Certificate's subject field and subjectAltName extension (or, only in the case of Domain Names, was delegated such right or control by someone who had such right to use or control); ii. followed the procedure when issuing the Certificate; and iii. accurately described the procedure in the CA's CP/CPS;

2. Compliance. The CA has complied with Section 1.1.1 Standards, Criteria and Regulations in issuing each certificate and operating its PKI or delegated services.

3. Authorization for Certificate: That, at the time of issuance, the CA

   i. implemented a procedure for verifying that the Subject authorized the issuance of the Certificate and that the Applicant Representative is authorized to request the Certificate on behalf of the Subject; ii. followed the procedure when issuing the Certificate; and iii. accurately described the procedure in the CA's CP/CPS;

4. Accuracy of Information: That, at the time of issuance, the CA

   i. implemented a procedure for verifying the accuracy of all of the information contained in the Certificate; ii. followed the procedure when issuing the Certificate; and iii. accurately described the procedure in the CA's CP/CPS;

5. Key Protection: The CA requires Subscribers to protect their Private Keys associated with TLS Subscriber Certificates in accordance with best practices, as stipulated in the Subscriber Agreement or Terms of Use.

6. Identity of Applicant: That, if the Certificate contains Subject Identity Information, the CA

   i. implemented a procedure to verify the identity of the Applicant in accordance with Section 3.2 and Section 7.1.2; ii. followed the procedure when issuing the Certificate; and iii. accurately described the procedure in the CA's CP/CPS;

7. Subscriber Agreement: That, if the CA and Subscriber are not Affiliated, the Subscriber and CA are parties to a legally valid and enforceable Subscriber Agreement that satisfies Section 1.1.1 Standards, Criteria and Regulations, or, if the CA and Subscriber are the same entity or are Affiliated, the Applicant Representative acknowledged the Terms of Use;

8. Status: That the CA maintains a 24 x 7 publicly-accessible Repository with current information regarding the status (valid or revoked) of all unexpired Certificates; and

9. Revocation: That the CA will revoke the Certificate for any of the reasons specified in Section 1.1.1 Standards, Criteria and Regulations.

The Root CA SHALL be responsible for the performance and warranties of the Subordinate CA, for the Subordinate CA's compliance with Section 1.1.1 Standards, Criteria and Regulations, and for all liabilities and indemnification obligations of the Subordinate CA under Section 1.1.1 Standards, Criteria and Regulations, as if the Root CA were the Subordinate CA issuing the Certificates

9.6.2 RA representations and warranties

Same as this CP/CPS Section 9.6.1.

9.6.3 Subscriber representations and warranties

The CA SHALL require, as part of the Subscriber Agreement or Terms of Use, that the Applicant make the commitments and warranties in this section for the benefit of the CA and the Certificate Beneficiaries.

Prior to the issuance of a Certificate, the CA SHALL obtain, for the express benefit of the CA and the Certificate Beneficiaries, either:

1. The Applicant's agreement to the Subscriber Agreement with the CA, or
2. The Applicant's acknowledgement of the Terms of Use.

The CA SHALL implement a process to ensure that each Subscriber Agreement or Terms of Use is legally enforceable against the Applicant. In either case, the Agreement MUST apply to the Certificate to be issued pursuant to the certificate request. The CA MAY use an electronic or "click-through" Agreement provided that the CA has determined that such agreements are legally enforceable. A separate Agreement MAY be used for each certificate request, or a single Agreement MAY be used to cover multiple future certificate requests and the resulting Certificates, so long as each Certificate that the CA issues to the Applicant is clearly covered by that Subscriber Agreement or Terms of Use.

The Subscriber Agreement or Terms of Use MUST contain provisions imposing on the Applicant itself (or made by the Applicant on behalf of its principal or agent under a subcontractor or hosting service relationship) the following obligations and warranties:

1. Accuracy of Information: An obligation and warranty to provide accurate and complete information at all times to the CA, both in the certificate request and as otherwise requested by the CA in connection with the issuance of the Certificate(s) to be supplied by the CA;
2. Protection of Private Key: An obligation and warranty by the Applicant to take all reasonable measures to assure control of, keep confidential, and properly protect at all times the Private Key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device, e.g. password or token);
3. Acceptance of Certificate: An obligation and warranty that the Subscriber will review and verify the Certificate contents for accuracy;
4. Use of Certificate: An obligation and warranty to install the Certificate only on servers that are accessible at the subjectAltName(s) listed in the Certificate, and to use the Certificate solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement or Terms of Use;
5. Reporting and Revocation: An obligation and warranty to: a. promptly request revocation of the Certificate, and cease using it and its associated Private Key, if there is any actual or suspected misuse or compromise of the Subscriber’s Private Key associated with the Public Key included in the Certificate, and b. promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate;
6. Termination of Use of Certificate: An obligation and warranty to promptly cease all use of the Private Key corresponding to the Public Key included in the Certificate upon revocation of that Certificate for reasons of Key Compromise.
7. Responsiveness: An obligation to respond to the CA's instructions concerning Key Compromise or Certificate misuse within a specified time period.
8. Acknowledgment and Acceptance: An acknowledgment and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber Agreement or Terms of Use or if revocation is required by the CA's CP/CPS, or Section 1.1.1 Standards, Criteria and Regulations.
9. Timely Revocation Cooperation:
   The Subscriber shall cooperate with the CA to ensure timely revocation of certificates in accordance with Section 1.1.1 Standards, Criteria and Regulations. The Subscriber acknowledges that the CA is obligated to comply with Section 1.1.1 Standards, Criteria and Regulations, and agrees to provide timely cooperation and information as required to meet revocation timelines, including in the event of mass revocation. The Subscriber shall not use publicly-trusted TLS server certificates on systems that cannot tolerate timely revocation.

9.6.4 Relying party representations and warranties

The Relying Party of the services of the CA has the following obligations:

• Trust the certificate issued by the CA and use the certificate only for the purposes specified by this CA in this CP/CPS.
• When trying to trust a certificate, make sure that the certificate has not been revoked by the CRL or OCSP responder in the repository.
• When trying to trust a certificate, check the validity period of the certificate and confirm that it is within the validity period.
• When trying to trust a certificate issued by this CA, make sure that the certificate can be signed and verified by the CA's certificate.
• Agree to be responsible as a Relying Party as specified in this CP/CPS when trying to trust and use the CA's certificate.

9.6.5 Representations and warranties of other participants

No stipulation.

9.7 Disclaimers of warranties

The CA is not liable for any direct, special, incidental or consequential damages arising in connection with the warranties stipulated in Section 9.6.1 and Section 9.6.2 hereof, or for lost earnings, loss of data, or any other indirect or consequential damages.

9.8 Limitations of liability

In this CP/CPS, the CA shall not be liable for the provisions of "9.6.1 CA representations and warranties” and "9.6.2 RA representations and warranties" hereof in the following cases.

• any damage arising from unlawful conduct, unauthorized use, negligence or any other cause not attributable to the CA;
• all liability in any case if the confirmed information error is the result of the applicant's fraud or willful misconduct.
• any damage attributable to the failure of a Subscriber to perform its obligations;
• any damage attributable to a Subscriber or Relying Party system;
• damages attributable to the defect or malfunction or any other behavior of the Subscriber environment (hardware or software);
• Any damage during the period that a Subscriber neglected to pay the subscription fee as set forth in the agreement thereof;
• damages caused by information published in a Certificate, a CRL or on the OCSP responder due to the reasons not attributable to the CA;
• any damage incurred in an outage of the normal communication due to reasons not attributable to the CA;
• any damage arising in connection with the use of a Certificate, including transaction debts;
• any damage caused by the Delegated Third Party’s failure to fulfill its service provision obligations, such as the termination of service provision by them;
• any damages attributable to improvement, beyond expectations at this point in time, in hardware or software type of cryptographic algorithm decoding skills;
• any damage attributable to the suspension of the CA's operations due to force majeure, including, but not limited to, natural disasters, earthquakes, volcanic eruptions, fires, tsunami, floods, lightning strikes, wars, civil commotion and terrorism.

9.9 Indemnities

Notwithstanding any limitations on its liability to Subscribers and Relying Parties, the CA understands and acknowledges that the Application Software Suppliers who have a Root Certificate distribution agreement in place with the Root CA do not assume any obligation or potential liability of the CA under Section 1.1.1 Standards, Criteria and Regulations or that otherwise might exist because of the issuance or maintenance of Certificates or reliance thereon by Relying Parties or others. Thus, the CA SHALL defend, indemnify, and hold harmless each Application Software Supplier for any and all claims, damages, and losses suffered by such Application Software Supplier related to a Certificate issued by the CA, regardless of the cause of action or legal theory involved. This does not apply, however, to any claim, damages, or loss suffered by such Application Software Supplier related to a Certificate issued by the CA where such claim, damage, or loss was directly caused by such Application Software Supplier's software displaying as not trustworthy a Certificate that is still valid, or displaying as trustworthy:

(1) a Certificate that has expired, or

(2) a Certificate that has been revoked (but only in cases where the revocation status is currently available from the CA online, and the application software either failed to check such status or ignored an indication of revoked status).

9.10 Term and termination

9.10.1 Term

This CP/CPS goes into effect upon approval by this Committee.

This CP/CPS will in no way lose effect under any circumstances prior to the termination stipulated in Section 9.10.2 hereof.

9.10.2 Termination

This CP/CPS loses effect as of the termination hereof by the CA, with the exception of the provisions stipulated in Section 9.10.3 hereof.

9.10.3 Effect of termination and survival

Even in the event of termination of the use of a Certificate by a Subscriber or the termination of a service provided by the Delegated Third Party, or the CA closes its business, provisions that should remain in effect, due to the nature thereof, shall survive any such termination, regardless of the reasons therefor, and remain in full force and effect with respect to any Subscriber and the CA.

9.11 Individual notices and communications with participants

The CA provides the necessary notices to the Delegated Third Party, then the Delegated Third Party provides the necessary notice to Subscribers and Relying Parties through its website, e-mail or in other written forms.

9.12 Amendments

9.12.1 Procedure for amendment

1. Critical revisions/amendments SECOM Trust Systems notifies Subscribers and Relying Parties of amendments of this CP/CPS if the amendments thereof are determined to have an obvious impact on the activities for use of Certificates or CRLs by the Subscribers and Relying Parties, by publishing the post-amendment version of this CP/CPS (including the Version History/Description/Date) in the Repository, while refreshing the Major Version Number.

2. Non-critical revisions/amendments SECOM Trust Systems notifies Subscribers and Relying Parties of amendments of this CP/CPS if the amendments thereof are determined to have no or less impact on the activities for use of Certificates or CRLs by the Subscribers and Relying Parties, by publishing the post-amendment version of this CP/CPS (including the Version History/Description/Date) in the Repository, while refreshing the Minor Version Number.

This CP/CPS shall be revised by the CA as appropriate and goes into effect upon approval by this Committee.

9.12.2 Notification mechanism and period

If this CP/CPS is revised/amended, the prompt publication of the post-amendment version of this CP/CPS (including the Version History/Description/Date) in the Repository is deemed to be the notification thereof to Subscribers and Relying Parties. Subscribers may make claims within a week of such notification, while the post-amendment version of this CP/CPS is deemed to be approved by the Subscribers unless any claim is made within the said period. Whenever this CP/CPS is modified, the prompt publication of the modified the CP/CPS shall be deemed as the notification thereof to the participants.

9.12.3 Circumstances under which OID must be changed

OID shall be changed if this Committee determines that it is necessary.

9.13 Dispute resolution provisions

A party seeking to file a lawsuit, request arbitration or take any other legal action against the CA for the resolution of a dispute relating to a Certificate issued by the CA, said party shall notify the CA to this effect in advance. As regards the location for arbitration and court proceedings, a dispute settlement institution located within Tokyo shall have exclusive jurisdiction.

9.14 Governing law

Regardless of the locations of the CAs, Subscribers, or Relying Parties, the laws of Japan will apply to any dispute concerning the interpretation or validity of this CP/CPS. Regarding the location for arbitration and court proceedings, the parties hereto submit to the exclusive jurisdiction of a dispute settlement institution located within Tokyo.

9.15 Compliance with applicable law

The CA shall handle cryptographic hardware and software in compliance with relevant export regulations of Japan.

9.16 Miscellaneous provisions

9.16.1 Entire agreement

SECOM Trust Systems comprehensively stipulates the obligations of Subscribers and Relying Parties and other relevant matters in this CP/CPS and the Service Terms, for provision of the services. Any agreements otherwise, whether oral or written, shall have no effect.

9.16.2 Assignment

When assigning the services to a third party, SECOM Trust Systems may assign its responsibilities and other obligations specified in this CP/CPS and the Service Terms.

9.16.3 Severability

Even if any provision of this CP/CPS, the Service Terms is deemed invalid, all other provisions stipulated therein shall remain in full force and effect.

In the event of a conflict between Baseline Requirements and a law, regulation or government order (hereinafter 'Law') of any jurisdiction in which a CA operates or issues certificates, a CA MAY modify any conflicting Baseline Requirement to the minimum extent necessary to make the requirement valid and legal in the jurisdiction. This applies only to operations or certificate issuances that are subject to that Law. In such event, the CA SHALL immediately (and prior to issuing a certificate under the modified requirement) include in Section 9.16.3 of the CA’s CP/CPS a detailed reference to the Law requiring a modification of Baseline Requirements under this section, and the specific modification to Baseline Requirements implemented by the CA.

The CA MUST also (prior to issuing a certificate under the modified requirement) notify the CA/Browser Forum of the relevant information newly added to its CP/CPS by sending a message to questions [at] cabforum [dot] org and receiving confirmation that it has been posted to the Public Mailing List and is indexed in the Public Mail Archives available at https://cabforum.org/pipermail/public/ (or such other email addresses and links as the Forum may designate), so that the CA/Browser Forum may consider possible revisions to Baseline Requirements accordingly.

Any modification to CA practice enabled under this section MUST be discontinued if and when the Law no longer applies, or Baseline Requirements are modified to make it possible to comply with both Baseline Requirements and the Law simultaneously. An appropriate change in practice, modification to the CA’s CP/CPS and a notice to the CA/Browser Forum, as outlined above, MUST be made within 90 days.

9.16.4 Enforcement (attorneys' fees and waiver of rights)

Disputes regarding this service shall be governed by the Tokyo District Court, and SECOM Trust Systems may request the parties for compensation and attorney’s fees for disputes arising from the contractual provisions of the respective regulatory documents, damages, losses and costs related to the parties' actions.

9.16.5 Force Majeure

SECOM Trust Systems shall not be liable for any damages caused by natural disasters, earthquakes, eruptions, fires, tsunamis, floods, lightning strikes, disturbances, terrorism, or any other force majeure, whether or not foreseeable. If it becomes impossible to provide this CA, SECOM Trust Systems may suspend this CA until the situation stops.

9.17 Other provisions

No stipulation.

APPENDIX A – CAA Contact Tag

These methods allow domain owners to publish contact information in DNS for the purpose of validating domain control.

A.1. CAA Methods

A.1.1. CAA contactemail Property

SYNTAX: contactemail <rfc6532emailaddress>

The CAA contactemail property takes an email address as its parameter. The entire parameter value MUST be a valid email address as defined in RFC 6532, Section 3.2, with no additional padding or structure, or it cannot be used.

The following is an example where the holder of the domain specified the contact property using an email address.

$ORIGIN example.com.
               CAA 0 contactemail "domainowner@example.com"

The contactemail property MAY be critical, if the domain owner does not want CAs who do not understand it to issue certificates for the domain.

A.1.2. CAA contactphone Property

SYNTAX: contactphone <rfc3966 Global Number>

The CAA contactphone property takes a phone number as its parameter. The entire parameter value MUST be a valid Global Number as defined in RFC 3966, Section 5.1.4, or it cannot be used. Global Numbers MUST have a preceding + and a country code and MAY contain visual separators.

The following is an example where the holder of the domain specified the contact property using a phone number.

$ORIGIN example.com.
               CAA 0 contactphone "+81 (3) 1234-5678"