title: SECOM Publicly Trusted Certificate Policy/Certification Practice Statement

subtitle: Version 1.02

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.2.1 Enterprise registration authorities (S/MIME Certificates)
    • 1.3.3 Subscribers
    • 1.3.4 Relying Parties
    • 1.3.5 Other Participants
  • 1.4 Certificate Usage
    • 1.4.1 Appropriate Certificate Uses
    • 1.4.2 Prohibited Certificate Uses
  • 1.5 Policy administration
    • 1.5.1 Organization Administering the Document
    • 1.5.2 Contact Person
    • 1.5.3 Person Determining CPS suitability for the policy
    • 1.5.4 CPS approval procedures
  • 1.6 Definitions and Acronyms
    • 1.6.1 Definitions
    • 1.6.2 Acronyms
    • 1.6.3 References
    • 1.6.4 Conventions
• 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
  • 2.1 Repositories
  • 2.2 Publication of information
  • 2.3 Time or frequency of publication
  • 2.4 Access controls on repositories
• 3. IDENTIFICATION AND AUTHENTICATION
  • 3.1 Naming
    • 3.1.1 Types of names
    • 3.1.2 Need for names to be meaningful
    • 3.1.3 Anonymity or pseudonymity of subscribers
    • 3.1.4 Rules for interpreting various name forms
    • 3.1.5 Uniqueness of names
    • 3.1.6 Recognition, authentication, and role of trademarks
  • 3.2 Initial identity validation
    • 3.2.1 Method to prove possession of private key
    • 3.2.2 Authentication of Organization and Domain Identity
      • 3.2.2.1 Identity
        • 3.2.2.1.1 Validating authority over mailbox via domain (S/MIME Certificates)
        • 3.2.2.1.2 Validating control over mailbox via email (S/MIME Certificates)
        • 3.2.2.1.3 Validating applicant as operator of associated mail server(s) (S/MIME Certificates)
      • 3.2.2.2 DBA/Tradename
      • 3.2.2.3 Verification of Country
    • 3.2.3 Authentication of individual identity
      • 3.2.3.1 Attribute collection of organization identity (S/MIME Certificates)
    • 3.2.4 Non-verified subscriber information
    • 3.2.5 Validation of authority
    • 3.2.6 Criteria for Interoperation or Certification
  • 3.3 Identification and authentication for re-key requests
    • 3.3.1 Identification and authentication for routine re-key
    • 3.3.2 Identification and authentication for re-key after revocation
  • 3.4 Identification and authentication for revocation request
• 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
  • 4.1 Certificate Application
    • 4.1.1 Who can submit a certificate application
    • 4.1.2 Enrollment process and responsibilities
  • 4.2 Certificate application processing
    • 4.2.1 Performing identification and authentication functions
    • 4.2.2 Approval or rejection of certificate applications
      • 4.2.2.1 Certification authority authorization (CAA) (S/MIME Certificates)
        • 4.2.2.1.1 DNSSEC validation of CAA records
      • 4.2.2.2 Multi-perspective issuance corroboration (S/MIME Certificates)
    • 4.2.3 Time to process certificate applications
  • 4.3 Certificate issuance
    • 4.3.1 CA actions during certificate issuance
      • 4.3.1.1 Manual authorization of certificate issuance for Root CAs
      • 4.3.1.2 Linting of to-be-signed Certificate content
      • 4.3.1.3 Linting of issued Certificates
    • 4.3.2 Notification to subscriber by the CA of issuance of certificate
  • 4.4 Certificate acceptance
    • 4.4.1 Conduct constituting certificate acceptance
    • 4.4.2 Publication of the certificate by the CA
    • 4.4.3 Notification of certificate issuance by the CA to other entities
  • 4.5 Key pair and certificate usage
    • 4.5.1 Subscriber private key and certificate usage
    • 4.5.2 Relying party public key and certificate usage
  • 4.6 Certificate renewal
    • 4.6.1 Circumstance for certificate renewal
    • 4.6.2 Who may request renewal
    • 4.6.3 Processing certificate renewal requests
    • 4.6.4 Notification of new certificate issuance to subscriber
    • 4.6.5 Conduct constituting acceptance of a renewal certificate
    • 4.6.6 Publication of the renewal certificate by the CA
    • 4.6.7 Notification of certificate issuance by the CA to other entities
  • 4.7 Certificate re-key
    • 4.7.1 Circumstance for certificate re-key
    • 4.7.2 Who may request certification of a new public key
    • 4.7.3 Processing certificate re-keying requests
    • 4.7.4 Notification of new certificate issuance to subscriber
    • 4.7.5 Conduct constituting acceptance of a re-keyed certificate
    • 4.7.6 Publication of the re-keyed certificate by the CA
    • 4.7.7 Notification of certificate issuance by the CA to other entities
  • 4.8 Certificate modification
    • 4.8.1 Circumstance for certificate modification
    • 4.8.2 Who may request certificate modification
    • 4.8.3 Processing certificate modification requests
    • 4.8.4 Notification of new certificate issuance to subscriber
    • 4.8.5 Conduct constituting acceptance of modified certificate
    • 4.8.6 Publication of the modified certificate by the CA
    • 4.8.7 Notification of certificate issuance by the CA to other entities
  • 4.9 Certificate revocation and suspension
    • 4.9.1 Circumstances for revocation
      • 4.9.1.1 Reasons for Revoking a Subscriber Certificate
      • 4.9.1.2 Reasons for Revoking a Subordinate CA Certificate
    • 4.9.2 Who can request revocation
    • 4.9.3 Procedure for revocation request
    • 4.9.4 Revocation request grace period
    • 4.9.5 Time within which CA must process the revocation request
    • 4.9.6 Revocation checking requirement for relying parties
    • 4.9.7 CRL issuance frequency
    • 4.9.8 Maximum latency for CRLs (if applicable)
    • 4.9.9 On-line revocation/status checking availability
    • 4.9.10 On-line revocation checking requirements
    • 4.9.11 Other forms of revocation advertisements available
    • 4.9.12 Special requirements re key compromise
    • 4.9.13 Circumstances for suspension
    • 4.9.14 Who can request suspension
    • 4.9.15 Procedure for suspension request
    • 4.9.16 Limits on suspension period
  • 4.10 Certificate status services
    • 4.10.1 Operational characteristics
    • 4.10.2 Service availability
    • 4.10.3 Optional features
  • 4.11 End of subscription
  • 4.12 Key escrow and recovery
    • 4.12.1 Key escrow and recovery policy and practices
    • 4.12.2 Session key encapsulation and recovery policy and practices
• 5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS
  • 5.1 Physical Security Controls
    • 5.1.1 Site location and construction
    • 5.1.2 Physical access
    • 5.1.3 Power and air conditioning
    • 5.1.4 Water exposures
    • 5.1.5 Fire prevention and protection
    • 5.1.6 Media storage
    • 5.1.7 Waste disposal
    • 5.1.8 Off-site backup
  • 5.2 Procedural controls
    • 5.2.1 Trusted roles
    • 5.2.2 Number of Individuals Required per Task
    • 5.2.3 Identification and authentication for each role
    • 5.2.4 Roles requiring separation of duties
  • 5.3 Personnel controls
    • 5.3.1 Qualifications, experience, and clearance requirements
    • 5.3.2 Background check procedures
    • 5.3.3 Training Requirements and Procedures
    • 5.3.4 Retraining frequency and requirements
    • 5.3.5 Job rotation frequency and sequence
    • 5.3.6 Sanctions for unauthorized actions
    • 5.3.7 Independent Contractor Controls
    • 5.3.8 Documentation supplied to personnel
  • 5.4 Audit logging procedures
    • 5.4.1 Types of events recorded
      • 5.4.1.1 Router and firewall activities logs
      • 5.4.1.2 Types of events recorded for Timestamp Authorities
    • 5.4.2 Frequency of processing audit log
    • 5.4.3 Retention period for audit log
    • 5.4.4 Protection of audit log
    • 5.4.5 Audit log backup procedures
    • 5.4.6 Audit collection System (internal vs. external)
    • 5.4.7 Notification to event-causing subject
    • 5.4.8 Vulnerability assessments
  • 5.5 Records archival
    • 5.5.1 Types of records archived
    • 5.5.2 Retention period for archive
    • 5.5.3 Protection of archive
    • 5.5.4 Archive backup procedures
    • 5.5.5 Requirements for time-stamping of records
    • 5.5.6 Archive collection system (internal or external)
    • 5.5.7 Procedures to obtain and verify archive information
  • 5.6 Key changeover
  • 5.7 Compromise and disaster recovery
    • 5.7.1 Incident and compromise handling procedures
      • 5.7.1.1 Incident Response and Disaster Recovery 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.2 Cross-Certified Subordinate CA Certificate Profile
      • 7.1.2.3 Subordinate CA Certificate Profile
      • 7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile
      • 7.1.2.5 Technically Constrained TLS Subordinate CA Certificate Profile
      • 7.1.2.6 TLS Subordinate CA Certificate Profile
      • 7.1.2.7 Subscriber Certificate Profile
      • 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.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.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.2. DNS TXT Methods
    • A.2.1. DNS TXT Record Email Contact
• APPENDIX B – Certificate profile
  • Table : "Security Communication RootCA2" and Subordinate CAs
  • Table : "Security Communication RootCA3" and Subordinate CAs
  • Table : "SECOM RSA Root CA 2023" and Subordinate CAs
  • Table : "SECOM Document Signing RSA Root CA 2023" and Subordinate CAs
  • Table : "SECOM SMIME RSA Root CA 2024" and Subordinate CA
  • Table : Subscriber Certificates (Client Authentication Certificate and Document Signing Certificates)
  • Table : Subscriber Certificates (Code Signing Certificates, Not be issued after 2024-05-01)
  • Table: Subscriber Certificates (AATL Document Signing Certificates)
  • Table: Subscriber Certificates (S/MIME Certificates)
  • Table: Security Communication RootCA2 TSA, TA Certificates (Issued before 2018-09-26)
  • Table: Security Communication RootCA3 TSA, TA Certificates (Issued before 2018-09-26)
  • Table: Security Communication RootCA3 TimeStamping Subordinate CA Certificates (Issued after 2018-06-07)
  • Table: SECOM TimeStamping CA2 TSA, TA Certificates
  • Table: SECOM TimeStamping CA3 TSA, TA Certificates
  • Table: SECOM TimeStamping CA4 TSA Certificates (Not issued after 2025-04-15)
  • Table: SECOM TimeStamping Service TSA Certificates

1. INTRODUCTION

1.1 Overview

This Certificate Policy/Certification Practice Statement (hereinafter, "CP/CPS") shall indicate the purpose of use, scope of application, and user procedures for certificates operated by SECOM Trust Systems CO., LTD. (hereinafter, "SECOM Trust Systems"), and stipulate policies concerning the certificates.

SECOM Trust Systems provides the certification services as the CAs, including the CA key administration as well as issuance/revocation of Certificates (hereinafter, "the Services").

This CP/CPS shall be revised as necessary in order to reflect any technical or operational developments or improvements pertaining to the CA.

This CP/CPS conforms to the RFC3647 "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework" advocated by the IETF as a CA practice framework”.

This CP/CPS complies with CCADB Policy, the CA MUST provide at least an authoritative English version of CP/CPS which are not originally in English, with version numbers matching the document they are a translation of. The Japanese version of the CP/CPS should be written with the Japanese section name under the English section name.

1.1.1 Standards, Criteria and Regulations

The CA shall comply with the latest versions of the Standards, Criteria, and Regulations established by the CA/Browser Forum, as well as the Application Software Supplier.

See Section 8.4 for the audit scheme that CAs must follow.

Table: Standards, Criteria and Regulations List

* AATL Document Signing Certificates and Microsoft Document Signing Certificates are collectively referred to as "Document Signing Certificates".

* Timestamp Certificates for Code Signing Certificates and AATL Timestamp Certificates are collectively referred to as "Timestamp Certificates".

The CA may outsource the part of the certification work to an external business operator that complies with S/MIME 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 "Table: Standards, Criteria and Regulations List", the "Table: Standards, Criteria and Regulations List" shall take precedence over this CP/CPS.

1.2 Document name and identification

The official name of this CP/CPS is "SECOM Publicly Trusted 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

[S/MIME Certificates]

With the exception of Section 3.2.2, 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 S/MIME 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 S/MIME Baseline Requirements.

The CA SHALL impose these limitations as a contractual requirement on the Enterprise RA and monitor compliance by the Enterprise RA.

[Document Signing Certificates and Client Authentication Certificates]

The LRA is the entity that performs, on behalf of the RA, verification of the existence of the certificate subscriber and verification of the identity, registration of the certificate for issuing and revoking the certificate, and the like. A special organization or entity that has been reviewed by the RA in advance and confirmed by the RA can play that role. The LRA, like the RA, shall comply with the matters stipulated in this CP/CPS. Note that the LRA may perform a task only when a client certificate policy or a data signature certificate policy is applied.

1.3.2.1 Enterprise registration authorities (S/MIME Certificates)

The CA MAY delegate to an Enterprise Registration Authority (RA) to verify Certificate Requests for Subjects within the Enterprise RA's own organization. The CA SHALL NOT accept Certificate Requests authorized by an Enterprise RA unless the following requirements are satisfied:

1. If the Certificate Request is for a Mailbox-validated profile, the CA SHALL confirm that the Enterprise RA has authorization or control of the requested email domain(s) in accordance with Section 3.2.2.1.1 or Section 3.2.2.1.3.

The CA SHALL impose these limitations as a contractual requirement on the Enterprise RA and monitor compliance by the Enterprise RA in accordance with Section 8.8.

An Enterprise RA MAY also submit Certificate Requests using the Mailbox-validated profile for users whose email domain(s) are not under the delegated organization’s authorization or control. In this case, the CA SHALL confirm that the mailbox holder has control of the requested Mailbox Address(es) in accordance with Section 3.2.2.1.2.

1.3.3 Subscribers

Subscribers shall be any natural person or Legal Entity that receive a Certificate issued by the CA and conforms to the Subscriber Agreement or Term of Use. Subscribers generate Key Pairs in their own rights, to which Certificates are issued by the CAs. They are qualified as Subscribers upon accepting the issued Certificates after submitting the Certificate applications to the CAs. Subscribers must assess Section in light of their usage purposes, and agree thereto.

1.3.4 Relying Parties

Relying Party is any natural person or Legal Entity that relies on a Valid Certificate. An Application Software Supplier is not considered a Relying Party when software distributed by such Supplier merely displays information relating to a Certificate. Relying Parties are the entities that authenticate the validity of Certificates issued by the CAs. Relying Parts are assumed to be performing the authentication and placing trust upon confirming and agreeing to the contents of Section in light of the Relying Parties' own purposes of use.

"Relying Party" and "Application Software Supplier" are defined in Section 1.6.1. Current Members of the CA/Browser Forum who are Application Software Suppliers are listed here:
https://cabforum.org/members.

1.3.5 Other Participants

Other groups include auditors, and companies or organizations that have service contracts with SECOM Trust Systems, and companies that perform system integration.

1.4 Certificate Usage

1.4.1 Appropriate Certificate Uses

The CAs are the Certification Authorities functioning as top of the Subordinate CAs and issue Subordinate CA Certificates as Subscriber Certificates. Relying Parties that trust and use the Certificates may authenticate the reliability of such Certificates using the CA public key Certificates.

1.4.2 Prohibited Certificate Uses

No stipulation.

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

AATL (Adobe Approved Trust List): A program that allows to create digital signatures that are trusted whenever the signed document is opened in Adobe® Acrobat® or Acrobat® Reader® software.

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

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 Data: Certificate requests and data related thereto (whether obtained from the Applicant or otherwise) in the CA's possession or control or to which the CA has access.

Certificate Management Process: Processes, practices, and procedures associated with the use of keys, software, and hardware, by which the CA verifies Certificate Data, issues Certificates, maintains a Repository, and revokes Certificates.

Certificate Policy (CP): A set of rules that indicates the applicability of a named Certificate to a particular community and/or PKI implementation with common security requirements.

Certificate Problem Report: Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.

Certificate Profile: A set of documents or files that defines requirements for Certificate content and Certificate extensions in accordance with Section 7, e.g. a Section in a CA’s CPS or a certificate template file used by CA software.

Certificate Requester: A natural person who is either the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or a third party (such as an ISP or hosting company) that completes and submits an EV Certificate Request on behalf of the Applicant.

Certificate Revocation List (CRL): A regularly updated time-stamped list of revoked Certificates that is created and digitally signed by the CA that issued the Certificates.

Certificate Signing Request (CSR): CSR stands for Certificate Signing Request, a data file on which the digital certificate issuance is based. A CSR contains the public key of the entity requesting the Certificate signing, to which the issuer's digital signature is affixed upon the issuance thereof.

Certificate Transparency (CT): Certificate Transparency, stipulated in RFC 6962, is an open framework for monitoring/auditing the records of the issued Certificates by registering and publishing them on the log servers.

Certification Authority (CA): An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Root CAs and Subordinate CAs.

Certification Practice Statement: One of several documents forming the governance framework in which Certificates are created, issued, managed, and used.

Certification Services Improvement Committee: The decision-making body for the operational policy of the Services, including administration of this CP/CPS and modification reviews.

Code: A contiguous set of bits that has been or can be digitally signed with a Private Key that corresponds to a Code Signing Certificate.

Code Signature: A Signature logically associated with a signed Code.

Code Signing Certificate: A digital certificate issued by a CA that contains a Code Signing EKU.

Confirmation Request: An appropriate out-of-band communication requesting verification or confirmation of the particular fact at issue.

Confirming Person: A position within an Applicant's organization that confirms the particular fact at issue.

Contract Signer: A natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements.

Control: "Control" (and its correlative meanings, "controlled by" and "under common control with") means possession, directly or indirectly, of the power to: (1) direct the management, personnel, finances, or plans of such entity; (2) control the election of a majority of the directors ; or (3) vote that portion of voting shares required for "control" under the law of the entity's Jurisdiction of Incorporation or Registration but in no case less than 10%.

Country: Either a member of the United Nations OR a geographic region recognized as a Sovereign State by at least two UN member nations.

Cross-Certified Subordinate CA Certificate: A certificate that is used to establish a trust relationship between two CAs.

CSPRNG: A random number generator intended for use in a cryptographic system.

Delegated Third Party: A natural person or Legal Entity that is not the CA but is authorized by the CA, and whose activities are not within the scope of the appropriate CA audits, to assist in the Certificate Management Process by performing or fulfilling one or more of the CA requirements found herein.

Digital Certification Infrastructure: A platform for operating the CA of SECOM Trust Systems and of the users of the Private CA users.

DNS CAA Email Contact: The email address defined in Appendix A.1.1.

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

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.

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 S/MIME 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.

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.

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.

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

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.

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.

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" 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 Section 1.1.1 Standards, Criteria and Regulations.

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 S/MIME Certificates published at https://www.cabforum.org. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document.

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 review and update its CP/CPS at least every 365 days, incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.

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.

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.

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.

[S/MIME Certificate issued on or before 2023-08-31]

When issuing an S/MIME on or before 2023-08-31, the CA authenticates that it controls the email account associated with the email address registered in the certificate, or that it is authorized by the email account owner to apply on behalf of, by using the methods described below. The random value described in this section shall consist of a random number of 112 bits or more generated by the CA, and shall be effective for the use of response confirmation for 30 days from the generation.

1. The CA will refer to the registration person（Registrant）information registered in the WHOIS Registry Service in the domain under @ included in the e-mail address, and confirm that the applicant owns the domain (the applicant and the domain owner are the same organization). If the CA confirms that the domain is owned by a third-party organization, it makes sure the account is approved for use, for that the owner of the domain will submit a "domain name use consent form" stamped by the owner organization.

2. The CA confirms that the owner of the e-mail account approves the use of the account by sending a random value by e-mail to the domain contact registered in the WHOIS Registry Service and receiving an acknowledgment containing the random value.

3. Local parts should be 'admin', 'administrator', 'webmaster', 'hostmaster', or ‘postmaster', and by sending a random value to the email address created in the domain below @ included in the email address and receiving the acknowledgment containing the random value, so that CA makes sure that the owner of the email account approves the use of the account.

4. The CA confirms the control of the email account by verifying that the request token or random value is included in the contents of the file. By accessing via the approved port, the CA confirms that a random value is displayed under the "http (or https): // [domains under @ included in the email address] /.well-known/pki-validation" directory, and it receives a successful HTTP or HTTPS response from the request.

5. The CA confirms the control of the email account by verifying that there is a random value or application token in either the DNS CNAME, TXT or CAA record of any of the domains under @ contained in the email address (including the one having a prefix of label with an underscore character at the beginning).

[S/MIME Certificate issued on or after 2023-09-01]

This section defines the permitted processes and procedures for confirming the Applicant's control of Mailbox Addresses to be included in issued Certificates.

The CA SHALL verify that Applicant controls the email accounts associated with all Mailbox Fields referenced in the Certificate or has been authorized by the email account holder to act on the account holder’s behalf.

The CA SHALL NOT delegate the verification of mailbox authorization or control.

The CA's CP/CPS SHALL specify the procedures that the CA employs to perform this verification. CAs SHALL maintain a record of which validation method, including the relevant version number from the TLS Baseline Requirements or S/MIME Baseline Requirements, was used to validate every domain or email address in issued Certificates.

Completed validations of Applicant authority MAY be valid for the issuance of multiple Certificates over time. In all cases, the validation SHALL have been initiated within the time period specified in the relevant requirement (such as Section 4.2.1) prior to Certificate issuance.

Note: Mailbox Fields MAY be listed in Subscriber Certificates using rfc822Name or otherNames of type id-on-SmtpUTF8Mailbox in the subjectAltName extension. Mailbox Fields MAY be listed in Subordinate CA Certificates via rfc822Name in permittedSubtrees within the nameConstraints extension.

3.2.2.1 Identity

If the Subject Identity Information is to include the name or address of an organization, the CA SHALL verify the identity and address of the organization and that the address is the Applicant's address of existence or operation. The CA SHALL verify the identity and address of the Applicant using documentation provided by, or through communication with, at least one of the following:

1. A government agency in the jurisdiction of the Applicant's legal creation, existence, or recognition;
2. A third party database that is periodically updated and considered a Reliable Data Source;
3. A site visit by the CA or a third party who is acting as an agent for the CA; or
4. An Attestation Letter.

The CA MAY use the same documentation or communication described in 1 through 4 above to verify both the Applicant's identity and address.

Alternatively, the CA MAY verify the address of the Applicant (but not the identity of the Applicant) using a utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.

As a result of the examination, If SECOM Trust Systems determines that it is non-conforming, the submitted official documents will be returned or destroyed. If SECOM Trust Systems has received the application form, SECOM Trust Systems shall destroy it.

3.2.2.1.1 Validating authority over mailbox via domain (S/MIME Certificates)

The CA MAY confirm the Applicant, such as an Enterprise RA, has been authorized by the email account holder to act on the account holder’s behalf by verifying the entity's control over the domain portion of the Mailbox Address to be used in the Certificate.

The CA SHALL use only the approved methods in Section 3.2.2.4 of the TLS Baseline Requirements to perform this verification.

For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate.

3.2.2.1.2 Validating control over mailbox via email (S/MIME Certificates)

The CA MAY confirm the Applicant's control over each Mailbox Field to be included in a Certificate by sending a Random Value via email and then receiving a confirming response utilizing the Random Value.

Control over each Mailbox Address SHALL be confirmed using a unique Random Value. The Random Value SHALL be sent only to the email address being validated and SHALL not be shared in any other way.

The Random Value SHALL be unique in each email. The Random Value SHALL remain valid for use in a confirming response for no more than 24 hours from its creation. The CA MAY specify a shorter validity period for Random Values in its CP and/or CPS.

The Random Value SHALL be reset upon each instance of the email sent by the CA to a Mailbox Address, however all relevant Random Values sent to that Mailbox Address MAY remain valid for use in a confirming response within the validity period described in this Section. In addition, the Random Value SHALL be reset upon first use by the user if intended for additional use as an authentication factor following the Mailbox Address verification.

3.2.2.1.3 Validating applicant as operator of associated mail server(s) (S/MIME Certificates)

The CA MAY confirm the Applicant's control over each Mailbox Field to be included in the Certificate by confirming control of the SMTP FQDN to which a message delivered to the Mailbox Address should be directed. The SMTP FQDN SHALL be identified using the address resolution algorithm defined in RFC 5321 Section 5.1 which determines which SMTP FQDNs are authoritative for a given Mailbox Address. If more than one SMTP FQDN has been discovered, the CA SHALL verify control of an SMTP FQDN following the selection process at RFC 5321 Section 5.1. Aliases in MX record RDATA SHALL NOT be used for this validation method.

To confirm the Applicant's control of the SMTP FQDN, the CA SHALL use only the currently-approved methods in Section 3.2.2.4 of the TLS Baseline Requirements.

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.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.3 Authentication of individual identity

[Document Signing Certificates and Client Authentication Certificates]

SECOM Trust Systems authenticates the identity of applicants or individuals based on official documents issued by national or local governments, investigations conducted, or databases owned by third parties that SECOM Trust Systems trusts, or through other means deemed equally trustworthy by this Committee. An examination of an applicant and a subscriber may be performed by terms and conditions separately stipulated by SECOM Trust Systems, or a method determined by the LRA based on the SECOM Passport for PublicID LRA Operational Standards (hereinafter, ”LRA Operational Standards”)

[AATL Document Signing Certificates]

The following methods shall be used to issue certificates for the AATL Document Signing Certificate. To authenticate an individual belonging to an organization, the CA shall confirm the existence of the representative or a person delegated by the representative. To authenticate official positions in the civil service, the CA shall confirm the existence of the representative or a person delegated by the representative. The representative or a person authorized by the representative shall be the one who verified the identity of the individual face-to-face and confirmed a match. The individual identity shall be authenticated through one of the following methods:

1. Confirm the Applicant’s seal impression included with any application received in writing;
2. Verify the Applicant’s identity using official documents;
3. Performing a postal challenge/response to the Applicant using an address obtained from a reliable third party;
4. Performing a telephone challenge/response to the Applicant using a telephone number from a reliable third party;
5. Performing an email challenge/response to the Applicant using an email address from a reliable third party. Information used for examination can be reused within the period prescribed by the CA.

3.2.3.1 Attribute collection of organization identity (S/MIME Certificates)

The CA or RA SHALL collect and retain evidence supporting the following identity attributes for the Organization:

1. Formal name of the Legal Entity;
2. An address of the Legal Entity (if included in the Subject);
3. Jurisdiction of Incorporation or Registration of the Legal Entity; and

3.2.4 Non-verified subscriber information

The information about non-verified certificate subscribers will not be included in the certificates issued by the CA.

3.2.5 Validation of authority

If the Applicant for a Certificate containing Subject Identity Information is an organization, the CA SHALL use a Reliable Method of Communication to verify the authenticity of the Applicant Representative's certificate request.

The CA MAY use the sources listed in Section 3.2.2.1 to verify the Reliable Method of Communication. Provided that the CA uses a Reliable Method of Communication, the CA MAY establish the authenticity of the certificate request directly with the Applicant Representative or with an authoritative source within the Applicant's organization, such as the Applicant's main business offices, corporate offices, human resource offices, information technology offices, or other department that the CA deems appropriate.

In addition, the CA SHALL establish a process that allows an Applicant to specify the individuals who may request Certificates. If an Applicant specifies, in writing, the individuals who may request a Certificate, then the CA SHALL NOT accept any certificate requests that are outside this specification. The CA SHALL provide an Applicant with a list of its authorized certificate requesters upon the Applicant's verified written request.

[S/MIME Certificates]

The CA or RA SHALL use a Reliable Method of Communication to verify the authority and approval of an Applicant Representative to perform one or more of the following:

• to act as an Enterprise RA;
• to request issuance or revocation of Certificates; or
• to assign responsibilities to others to act in these roles.

The CA or RA MAY establish a process that allows an Applicant to specify the individuals who may act as Applicant Representatives on an ongoing basis. The CA SHALL provide an Applicant with a list of its authorized Applicant Representatives upon the Applicant's verified written request.

The CA or RA MAY use the sources listed in Section 3.2.3.1 to verify the Reliable Method of Communication. Provided that the CA or RA uses a Reliable Method of Communication, the CA or RA MAY establish the authenticity of the Certificate Request directly with the Applicant Representative or with an authoritative source within the Applicant's organization, such as the Applicant's main business offices, corporate offices, human resource offices, information technology offices, or other department that the CA or RA deems appropriate.

3.2.6 Criteria for Interoperation or Certification

The CA SHALL disclose all Cross-Certified Subordinate CA Certificates that identify the CA as the Subject, provided that the CA arranged for or accepted the establishment of the trust relationship (i.e. the Cross-Certified Subordinate CA Certificate at issue).

3.3 Identification and authentication for re-key requests

3.3.1 Identification and authentication for routine re-key

Subscribers shall be identified and authenticated for Re-Keying in the same manner as set forth in Section 3.2 hereof.

3.3.2 Identification and authentication for re-key after revocation

A routine Re-Key after Revocation is not supported. The (Re-Keying) application for a Certificate shall be treated as a new submission, and the applicant Subscriber shall be identified and authenticated in the same manner as set forth in Section 3.2 hereof.

3.4 Identification and authentication for revocation request

Accepting the revocation request from the Subscriber or the applicant according to the prescribed procedure, the CA identifies and authenticates the Subscriber.

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1 Certificate Application

4.1.1 Who can submit a certificate application

A person who may submit a certificate application shall be individuals, corporations, other organizations that use certificates, and agents delegated by certificate subscribers (hereinafter referred to as "Applicant").

In accordance with Section 5.5.2, the CA SHALL maintain an internal database of all previously revoked Certificates and previously rejected certificate requests due to suspected phishing or other fraudulent usage or concerns. The CA SHALL use this information to identify subsequent suspicious certificate requests.

[S/MIME Certificates, Document Signing Certificates and Client Authentication Certificates]

An application for the CA can be made by an LRA and organization that has been certified by SECOM Trust Systems based on Section 3.2.2. Applications for LRA can be made by persons specified by LRA based on the LRA operational standards.

4.1.2 Enrollment process and responsibilities

Prior to the issuance of a Certificate, the CA SHALL obtain the following documentation from the Applicant:

1. A certificate request, which may be electronic; and
2. An executed Subscriber Agreement or Terms of Use, which may be electronic.

The CA SHOULD obtain any additional documentation the CA determines necessary to meet Section 1.1.1 Standards, Criteria and Regulations.

Prior to the issuance of a Certificate, the CA SHALL obtain from the Applicant a certificate request in a form prescribed by the CA and that complies with Section 1.1.1 Standards, Criteria and Regulations. One certificate request MAY suffice for multiple Certificates to be issued to the same Applicant, subject to the aging and updating requirement in Section 4.2.1, provided that each Certificate is supported by a valid, current certificate request signed by the appropriate Applicant Representative on behalf of the Applicant. The certificate request MAY be made, submitted and/or signed electronically.

The certificate request MUST contain a request from, or on behalf of, the Applicant for the issuance of a Certificate, and a certification by, or on behalf of, the Applicant that all of the information contained therein is correct.

[S/MIME Certificates]

Prior to the issuance of a Certificate, the CA SHALL obtain the following documentation from the Applicant:

1. A Certificate Request; and
2. An executed Subscriber Agreement and/or Terms of Use.

The Certificate Request and Subscriber Agreement or Terms of Use SHALL be in a form prescribed by the CA and SHALL comply with these Requirements including Section 9.6.3. The CA SHOULD obtain any additional documentation the CA determines necessary to fulfill these Requirements.

The Certificate Request SHALL contain a request from, or on behalf of, the Applicant for the issuance of a Certificate, and a certification by, or on behalf of, the Applicant that all of the information contained therein is correct.

One Certificate Request MAY suffice for multiple Certificates to be issued to the same Applicant, subject to the validation reuse periods described in Section 4.2.1, provided that each Certificate is supported by a valid, current Certificate Request signed by the appropriate Applicant Representative on behalf of the Applicant.

A CA may rely on a previously verified Certificate Request to issue a replacement Certificate if:

1. The previous Certificate being referenced was not revoked;
2. The expiration date of the replacement Certificate is the same as the previous Certificate being referenced; and
3. The Subject Information of the Certificate is the same as the previous Certificate being referenced.

4.2 Certificate application processing

4.2.1 Performing identification and authentication functions

SECOM Trust Systems performs identity verification and authentication of the LRA or the organization in accordance with Section 3.2. In applying for a certificate accepted from the LRA, the certificate presented by the LRA is verified and authenticated for the identity of the LRA. The LRA performs identity verification and authentication based on the LRA operational standards in the manner determined by the LRA.

[S/MIME Certificates]

Applicant information SHALL include, but not be limited to, at least one Mailbox Field to be included in the Certificate's subjectAltName extension.

Section 6.3.2 limits the validity period of Subscriber Certificates.

The CA MAY reuse completed validations and/or supporting evidence performed in accordance with Section 3.2 within the following limits:

1. Validation of mailbox authorization or control: Completed validation of the control of a mail server in accordance with Section 3.2.2.1.1 or Section 3.2.2.1.3 SHALL be obtained no more than 398 days prior to issuing the Certificate.

   In the event of changes to the TLS Baseline Requirements methods specified in Section 3.2.2.1.1, a CA MAY continue to reuse completed validations and/or supporting evidence for the period stated in this section.

   Completed validation of control of a mailbox in accordance with Section 3.2.2.1.2 SHALL be obtained no more than 30 days prior to issuing the Certificate.

A prior validation SHALL NOT be reused if any data or document used in the prior validation was obtained more than the maximum time permitted for reuse of the data or document prior to issuing the Certificate.

[Document Signing Certificate and Timestamp Certificates]

The CA MAY reuse completed validations and/or supporting evidence performed in accordance with Section 3.2 within the following limits: The validation SHALL be obtained no more than 398 days prior to issuing the Certificate.

[Code Signing Certificates]

Code Signing Certificates SHALL NOT be issued on or after 2024-05-01.

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

4.2.2.1 Certification authority authorization (CAA) (S/MIME Certificates)

[S/MIME Certificates]

Starting on September 15, 2024 the CA SHALL state its policy or practice on processing CAA Records for Mailbox Addresses in Section 4.2 of its CP and/or CPS. That policy SHALL be consistent with these Requirements and SHALL clearly specify the set of Issuer Domain Names that the CA recognizes in CAA issuemail records as permitting it to issue.Starting on September 15, 2024 prior to issuing a Certificate that includes a Mailbox Address, the CA SHOULD retrieve and process CAA records in accordance with Section 4 of RFC 9495: Certification Authority Authorization (CAA) Processing for Email Addresses.

Starting on March 15, 2025 prior to issuing a Certificate that includes a Mailbox Address, the CA SHALL retrieve and process CAA records in accordance with Section 4 of RFC 9495: Certification Authority Authorization (CAA) Processing for Email Addresses.

Some methods relied upon for validating the Applicant's control over the domain portion of the Mailbox Address to be used in the Certificate (see Section 3.2.2.1.1 and Section 3.2.2.1.3) require CAA records to be retrieved and processed from additional remote Network Perspectives before Certificate issuance (see Section 4.2.2.2). To corroborate the Primary Network Perspective, a remote Network Perspective's CAA check response MUST be interpreted as permission to issue, regardless of whether the responses from both Perspectives are byte-for-byte identical. Additionally, a CA MAY consider the response from a remote Network Perspective as corroborating if one or both of the Perspectives experience an acceptable CAA record lookup failure, as defined in this section.

When processing CAA records, CAs SHALL process the issuemail property tag as specified in RFC 9495. Additional property tags MAY be supported, but SHALL NOT conflict with or supersede the authorizations to issue S/MIME Certificates as specified in the issuemail property tag.

If the CA issues a Certificate following a CAA check, they SHALL do so within the TTL of the CAA record, or 8 hours, whichever is greater. This stipulation does not prevent the CA from checking CAA records at any other time.

If the Certificate includes more than one Mailbox Address, then the CA SHALL perform the above procedure for each Mailbox Address.

CAA checking is optional for Certificates issued by a Technically Constrained Subordinate CA Certificate as set out in Section 7.1.5, where the lack of CAA checking is an explicit contractual provision in the contract with the Technically Constrained Subordinate CA Applicant.

The CA SHALL NOT issue a Certificate unless the CA determines that Certificate Request is consistent with the applicable CAA RRset. The CA SHALL log all actions taken, if any, consistent with its CAA processing practice.

CAs are permitted to treat a record lookup failure as permission to issue if:

• the failure is outside the CA's infrastructure; and
• the lookup has been retried at least once; and
• the CA has confirmed that the domain is "Insecure" as defined in RFC 4035 Section 4.3.

Subscribers who wish to be granted permission to issue S/MIME certificates must include the value "secomtrust.net" in the DNS issuemail property tag. If the S/MIME subscribers already has a CAA entry in their DNS zone and requires certificate issuance from the CA, the issuemail property tag MUST contain the value "secomtrust.net".

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

4.2.2.2 Multi-perspective issuance corroboration (S/MIME Certificates)

[S/MIME Certificates]

CAs SHOULD implement Section 3.2.2.9 of the TLS Baseline Requirements before March 15, 2025. Effective May 15, 2025 CAs SHALL implement Section 3.2.2.9 of the TLS Baseline Requirements.

4.2.3 Time to process certificate applications

No stipulation.

4.3 Certificate issuance

4.3.1 CA actions during certificate issuance

4.3.1.1 Manual authorization of certificate issuance for Root CAs

Certificate issuance by the Root CA SHALL require an individual authorized by the CA (i.e. the CA system operator, system officer, or PKI administrator) to deliberately issue a direct command in order for the Root CA to perform a certificate signing operation.

4.3.1.2 Linting of to-be-signed Certificate content

[S/MIME Certificates]

It is considered best practice for the CA to implement a Linting process to test the technical conformity of each to-be-signed artifact prior to signing it.

• Effective 2025-03-15 the CA SHOULD implement a Linting process testing compliance with S/MIME Baseline Requirements.
• Effective 2025-09-15 the CA SHALL implement a Linting process testing compliance with S/MIME Baseline Requirements.

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.

4.4 Certificate acceptance

4.4.1 Conduct constituting certificate acceptance

[S/MIME Certificates]

When the Subscriber downloaded the Certificate, or when the certificate sent by the Subscriber is introduced to the server by other methods, the acceptance thereof shall be deemed complete.

[Client Authentication Certificates, Document Signing Certificates and Timestamp Certificates]

If the CA receives a report for receipt from the LRA or the Subscriber, or if no objection is made within 14 days of the CA's distribution of the Certificate, consider that the LRA or Subscriber has received the certificate.

4.4.2 Publication of the certificate by the CA

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

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

[S/MIME Certificates]

The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:

1. The Subscriber requests in writing that the CA revoke the Certificate;
2. The Subscriber notifies the CA that the original Certificate Request was not authorized and does not retroactively grant authorization;
3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise;
4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys);
5. The CA obtains evidence that the validation of domain authorization or mailbox control for any Mailbox Address in the Certificate should not be relied upon.

The CA SHOULD revoke a Certificate within 24 hours and SHALL revoke a Certificate within 5 days if one or more of the following occurs:

6. The Certificate no longer complies with the requirements of Section 6.1.5 and Section 6.1.6;
7. The CA obtains evidence that the Certificate was misused;
8. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use;
9. The CA is made aware of any circumstance indicating that use of an email address or Fully-Qualified Domain Name in the Certificate is no longer legally permitted (e.g., a court or arbitrator has revoked the right to use an email address or Domain Name, a relevant licensing or services agreement between the Subscriber has terminated, or the account holder has failed to maintain the active status of the email address or Domain Name);
10. The CA is made aware of a material change in the information contained in the Certificate;
11. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA's CP and/or CPS;
12. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate;
13. The CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository;
14. Revocation is required by the CA's CP and/or CPS; or
15. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed.

[Code Signing Certificates]

The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:

1. The Subscriber requests in writing that the CA revoke the Certificate;
2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization;
3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise;
4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate;
5. The CA is made aware of a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed; or
6. The CA has reasonable assurance that a Certificate was used to sign Suspect Code.

The CA SHOULD revoke a certificate within 24 hours and SHALL revoke a Certificate within 5 days if one or more of the following occurs:

7. The Certificate no longer complies with the requirements of Section 6.1.5 and Section 6.1.6;
8. The CA obtains evidence that the Certificate was misused.
9. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use.
10. The CA is made aware of a material change in the information contained in the Certificate.
11. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA's Certificate Policy or Certification Practice Statement.
12. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate.
13. The CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository.
14. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement.

The CA MAY delay revocation based on a request from Application Software Suppliers where immediate revocation has a potentially large negative impact to the ecosystem.

[Client Authentication Certificates, Document Signing Certificates and Timestamp Certificates]

The CA SHALL revoke a Certificate if one or more of the following occurs:

1. The Subscriber requests in writing that the CA revoke the Certificate;
2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization;
3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise;
4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate;
5. The CA is made aware of a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed; or
6. The Certificate no longer complies with the requirements of Section 6.1.5 and Section 6.1.6;
7. The CA obtains evidence that the Certificate was misused.
8. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use.
9. The CA is made aware of a material change in the information contained in the Certificate.
10. The CA is made aware that the Certificate was not issued in accordance with Section 1.1.1 Standards, Criteria and Regulations or the CA's Certificate Policy or Certification Practice Statement.
11. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate.
12. The CA's right to issue Certificates under Section 1.1.1 Standards, Criteria and Regulations expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository.
13. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement.

4.9.1.2 Reasons for Revoking a Subordinate CA Certificate

The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs:

1. The Subordinate CA requests revocation in writing;
2. The Subordinate CA notifies the Issuing CA that the original certificate request was not authorized and does not retroactively grant authorization;
3. The Issuing CA obtains evidence that the Subordinate CA's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of Section 6.1.5 and Section 6.1.6;
4. The Issuing CA obtains evidence that the Certificate was misused;
5. The Issuing CA is made aware that the Certificate was not issued in accordance with or that Subordinate CA has not complied with this document or the applicable Certificate Policy or Certification Practice Statement;
6. The Issuing CA determines that any of the information appearing in the Certificate is inaccurate or misleading;
7. The Issuing CA or Subordinate CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate;
8. The Issuing CA's or Subordinate CA's right to issue Certificates under Section 1.1.1 Standards, Criteria and Regulations expires or is revoked or terminated, unless the Issuing CA has made arrangements to continue maintaining the CRL/OCSP Repository; or
9. Revocation is required by the Issuing CA's CP/CPS.

4.9.2 Who can request revocation

The Subscriber, RA, or Issuing CA can initiate revocation. Additionally, Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate.

4.9.3 Procedure for revocation request

The CA SHALL provide a process for Subscribers to request revocation of their own Certificates.

The Subscriber submits a revocation request for the Subscriber certificate to the CA according to the prescribed procedure. For the certificates requested and issued by the LRA, a revocation request for a Subscriber certificate shall be made by the method determined by the LRA based on the LRA operational standards. LRA accesses the site provided by SECOM Trust Systems using the LRA certificate, and applies for revocation of the Subscriber certificate to the CA.

The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports.

The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in Section 1.5.2 of their CPS.

4.9.4 Revocation request grace period

Actual revocation timelines depend on the reasons for revocation as described in this section 4.9.1.1 and section 4.9.1.2.

4.9.5 Time within which CA must process the revocation request

Within 24 hours after receiving a Certificate Problem Report, the CA SHALL investigate the facts and circumstances related to a Certificate Problem Report and provide a preliminary report on its findings to both the Subscriber and the entity who filed the Certificate Problem Report. After reviewing the facts and circumstances, the CA SHALL work with the Subscriber and any entity reporting the Certificate Problem Report or other revocation-related notice to establish whether or not the certificate will be revoked, and if so, a date which the CA will revoke the certificate. The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation MUST NOT exceed the time frame set forth in Section 4.9.1.1. The date selected by the CA SHOULD consider the following criteria:

1. The nature of the alleged problem (scope, context, severity, magnitude, risk of harm);
2. The consequences of revocation (direct and collateral impacts to Subscribers and Relying Parties);
3. The number of Certificate Problem Reports received about a particular Certificate or Subscriber;
4. The entity making the complaint (for example, a complaint from a law enforcement official that a Web site is engaged in illegal activities should carry more weight than a complaint from a consumer alleging that they didn't receive the goods they ordered); and
5. Relevant legislation.

4.9.6 Revocation checking requirement for relying parties

Relying parties should check the revocation status of all certificates that contain a CRL Distribution Point or OCSP pointer.

4.9.7 CRL issuance frequency

CRLs MUST be available via a publicly-accessible HTTP URL (i.e., "published").

[Client Authentication Certificates, S/MIME Certificates, Code Signing Certificates, Document Signing Certificates and Timestamp Certificates]

For the status of Subscriber Certificates: the CA SHALL update and reissue CRLs at least once every seven (7) days, and the value of the nextUpdate field SHALL NOT be more than ten (10) days beyond the value of the thisUpdate field.

[Common to all certificates]

CAs issuing CA Certificates:

1. MUST update and publish a new CRL at least every twelve (12) months;
2. MUST update and publish a new CRL within twenty-four (24) hours after recording a Certificate as revoked.

CAs MUST continue issuing CRLs until one of the following is true:

• all Subordinate CA Certificates containing the same Subject Public Key are expired or revoked; OR
• the corresponding Subordinate CA Private Key is destroyed.

4.9.8 Maximum latency for CRLs (if applicable)

For the Root CA, a new CRL is issued and published in the Repository within 24 hours after issuance. The CRLs issued by the CA will be reflected onto the repository within a reasonable time.

4.9.9 On-line revocation/status checking availability

When provided, OCSP responses SHALL conform to RFC 6960 and/or RFC 5019. OCSP responses SHALL 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 whose Certificate is signed by the CA that issued the Certificate whose revocation status is being checked.

In the latter case, the OCSP signing Certificate SHALL contain the ocspSigning EKU (1.3.6.1.5.5.7.3.9) and an extension of type id-pkix-ocsp-nocheck, as defined by RFC 6960.

4.9.10 On-line revocation checking requirements

OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019.

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.

For the status of Subscriber Certificates:

1. OCSP responses SHALL have a validity interval greater than or equal to eight hours;
2. OCSP responses SHALL have a validity interval less than or equal to ten days;
3. For OCSP responses with validity intervals less than sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol prior to one-half of the validity period before the nextUpdate; and
4. For OCSP responses with validity intervals greater than or equal to sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate.

For the status of Subordinate CA Certificates, the CA SHALL update information provided via OCSP:

1. at least every twelve months; and
2. within 24 hours after revoking a Subordinate CA Certificate.

If the OCSP responder receives a request for the status of a Certificate serial number that is "unused", 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.5, the responder SHALL NOT respond with a "good" status for such requests.

A Certificate serial number within an OCSP request is "assigned" if a Certificate with that serial number has been issued by the Issuing CA, using any current or previous key associated with that CA subject, or "unused" if otherwise.

4.9.11 Other forms of revocation advertisements available

No stipulation.

4.9.12 Special requirements re key compromise

See Section 4.9.1.

4.9.13 Circumstances for suspension

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

See Section 7.2.2 for restrictions on use of suspension.

4.9.14 Who can request suspension

Not applicable.

4.9.15 Procedure for suspension request

Not applicable.

4.9.16 Limits on suspension period

Not applicable.

4.10 Certificate status services

4.10.1 Operational characteristics

Revocation entries on a CRL or OCSP Response MUST NOT be removed until after the Expiry Date of the revoked Certificate.

[Code Signing Certificates]

Revocation information shall be confirmed for at least 10 years after the expiration date.

4.10.2 Service availability

The CA SHALL operate and maintain its CRL and optional OCSP capability with resources sufficient to provide a response time of ten seconds or less under normal operating conditions.

The CA SHALL maintain an online 24x7 Repository that application software can use to automatically check the current status of all unexpired Certificates issued by the CA.

The CA SHALL maintain a continuous 24x7 ability to respond internally to a high-priority Certificate Problem Report, and where appropriate, forward such a complaint to law enforcement authorities, and/or revoke a Certificate that is the subject of such a complaint.

4.10.3 Optional features

No stipulation.

4.11 End of subscription

In terminating subscription of the Services, Subscribers are required to proceed with the service subscription termination procedure set forth in the relevant agreement therefor or the like. Subscribers shall submit a Certificate Revocation Request when ending the certificate use. It will also end if they do not apply for the renewal of the certificate and the validity period of the corresponding certificate has expired.

4.12 Key escrow and recovery

4.12.1 Key escrow and recovery policy and practices

The CA does not Escrow Subscriber Private Keys.

4.12.2 Session key encapsulation and recovery policy and practices

Not applicable.

5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS

The CA SHALL develop, implement, and maintain a comprehensive security program designed to:

1. Protect the confidentiality, integrity, and availability of Certificate Data and Certificate Management Processes;
2. Protect against anticipated threats or hazards to the confidentiality, integrity, and availability of the Certificate Data and Certificate Management Processes;
3. Protect against unauthorized or unlawful access, use, disclosure, alteration, or destruction of any Certificate Data or Certificate Management Processes;
4. Protect against accidental loss or destruction of, or damage to, any Certificate Data or Certificate Management Processes; and
5. Comply with all other security requirements applicable to the CA by law.

The Certificate Management Process MUST include:

1. physical security and environmental controls;
2. system integrity controls, including configuration management, integrity maintenance of trusted code, and malware detection/prevention;
3. network security and firewall management, including port restrictions and IP address filtering;
4. user management, separate trusted-role assignments, education, awareness, and training; and
5. logical access controls, activity logging, and inactivity time-outs to provide individual accountability.

The CA's security program MUST include an annual Risk Assessment that:

1. Identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes;
2. Assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and
3. Assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.

Based on the Risk Assessment, the CA SHALL develop, implement, and maintain a security plan consisting of security procedures, measures, and products designed to achieve the objectives set forth above and to manage and control the risks identified during the Risk Assessment, commensurate with the sensitivity of the Certificate Data and Certificate Management Processes. The security plan MUST include administrative, organizational, technical, and physical safeguards appropriate to the sensitivity of the Certificate Data and Certificate Management Processes. The security plan MUST also take into account then-available technology and the cost of implementing the specific measures, and SHALL implement a reasonable level of security appropriate to the harm that might result from a breach of security and the nature of the data to be protected.

5.1 Physical Security Controls

5.1.1 Site location and construction

The CA has its certification infrastructure system installed within a 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.

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.

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.1.2 Types of events recorded for Timestamp Authorities

[Code Signing Certificates]

The Timestamp Authority MUST log the following information and make these records available to its Qualified Auditor as proof of the Timestamp Authority’s compliance with Baseline Requirements for Code Signing Certificates:

1. Physical or remote access to a timestamp server, including the time of the access and the identity of the individual accessing the server,
2. History of the timestamp server configuration,
3. Any attempt to delete or modify timestamp logs,
4. Security events, including:
   • a. Successful and unsuccessful Timestamp Authority access attempts;
   • b. Timestamp Authority server actions performed;
   • c. Security profile changes;
   • d. System crashes, and other anomalies; and
   • e. Firewall and router activities.
5. Revocation of a timestamp certificate,
6. Major changes to the timestamp server’s time, and
7. System startup and shutdown.

5.4.2 Frequency of processing audit log

The CA reviews Audit logs periodically. The review of current and archived audit logs include a validation of the audit logs’ integrity, and the timely identification and follow up of unauthorised or suspicious activity.

5.4.3 Retention period for audit log

The CA and each Delegated Third Party SHALL retain, for at least two (2) years:

1. CA certificate and key lifecycle management event records (as set forth in Section 5.4.1 (1)) after the later occurrence of:
   1. the destruction of the CA Private Key; or
   2. the revocation or expiration of the final CA Certificate in that set of Certificates that have an X.509v3 basicConstraints extension with the cA field set to true and which share a common Public Key corresponding to the CA Private Key;
2. Subscriber Certificate lifecycle management event records (as set forth in Section 5.4.1 (2)) after the expiration of the Subscriber Certificate;
3. Any security event records (as set forth in Section 5.4.1 (3)) after the event occurred.
4. For Code Signing Certificates, Timestamp Authority data record after the revocation or renewal of the Timestamp Certificate private key (as set forth in Section 5.4.1.2); and the security event record after the event occurred (as specified in Section 5.4.1.2).

5.4.4 Protection of audit log

The CA implements appropriate controls on Audit Log access to secure sole access by the authorized personnel and to keep the log from the eyes of those unauthorized.

5.4.5 Audit log backup procedures

Audit Logs are backed up and stored in a secure off-site environment that is separate from the equipment that generates the Audit Logs.

5.4.6 Audit collection System (internal vs. external)

The Audit Log collection system is included as a function of the certification infrastructure systems.

5.4.7 Notification to event-causing subject

The CA collects Audit Log without notifying the person, system or application that has caused the corresponding event.

5.4.8 Vulnerability assessments

Additionally, the CA's security program MUST include an annual Risk Assessment that:

1. Identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes;
2. Assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and
3. Assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.

5.5 Records archival

5.5.1 Types of records archived

The CA and each Delegated Third Party SHALL archive all audit logs (as set forth in Section 5.4.1).

Additionally, the CA and each Delegated Third Party SHALL archive:

1. Documentation related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems; and
2. Documentation related to their verification, issuance, and revocation of certificate requests and Certificates.

5.5.2 Retention period for archive

Archived audit logs (as set forth in Section 5.5.1 SHALL be retained for a period of at least two (2) years from their record creation timestamp, or as long as they are required to be retained per Section 5.4.3, whichever is longer.

Additionally, the CA and each Delegated Third Party SHALL retain, for at least two (2) years:

1. All archived documentation related to the security of Certificate Systems, Certificate Management Systems, Root CA Systems and Delegated Third Party Systems (as set forth in Section 5.5.1); and
2. All archived documentation relating to the verification, issuance, and revocation of certificate requests and Certificates (as set forth in Section 5.5.1) after the later occurrence of:
   1. such records and documentation were last relied upon in the verification, issuance, or revocation of certificate requests and Certificates; or
   2. the expiration of the Subscriber Certificates relying upon such records and documentation.

5.5.3 Protection of archive

Archives are retained in a facility, access to which is restricted to the authorized personnel.

5.5.4 Archive backup procedures

The Archive is backed up whenever a change is made in such critical data pertaining to certification infrastructure system functions as Certificate issuance/revocation or CRL issuance.

5.5.5 Requirements for time-stamping of records

SECOM Trust Systems uses the NTP (Network Time Protocol) to time-synchronize the certification infrastructure systems and Time-Stamps the critical data recorded therein.

5.5.6 Archive collection system (internal or external)

The Archive collection system is included as a function of the certification infrastructure systems.

5.5.7 Procedures to obtain and verify archive information

The Archive shall be retrieved from the secure storage by designated personnel with the appropriate access permission for periodic checks of the storage conditions of the media. Further, the Archive is copied to new media as appropriate to maintain their integrity and confidentiality.

5.6 Key changeover

Renewal of Key-Pairs or Certificates of the CA, as a general rule, shall be made before their remaining validity periods become shorter than the maximum validity periods of the Certificates issued to Subscribers. After the new key pair is generated, the certificate and CRL are issued using the new key pair.

5.7 Compromise and disaster recovery

5.7.1 Incident and compromise handling procedures

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.2 Recovery Procedures if Computing resources, software, and/or data are corrupted

In the event of damage to any hardware, software or data of the certification infrastructure systems, SECOM Trust Systems promptly engages in the certification infrastructure systems recovery efforts using the relevant hardware, software or data retained as backup.

5.7.3 Recovery Procedures after Key Compromise

Should a Subscriber determine that a Private Key has or could have been compromised, the Subscriber must promptly make a revocation request to the relevant CA. Following receipt of a revocation request, the relevant CA processes the revocation according to the procedure set forth in Section Section 4.9 of the CAs operated on the Digital Certification Infrastructure.

In the event that the operation of the system related to the CA is interrupted or stopped, the CA shall notify the relevant parties, including the application software supplier, in accordance with the predetermined plans and procedures to safely resume operation.

5.7.4 Business continuity capabilities after a disaster

In order to ensure prompt recovery to be implemented in the event of an unforeseen circumstance, SECOM Trust Systems deploys preventive measures for the fastest possible recovery of the certification infrastructure systems, including securing of replacement/backup hardware, continual data backups for recovery, and establishment of the recovery procedures.

5.8 CA or RA termination

In the event of termination of the CA, it shall so notify Subscribers and other affected participants, including Application Software Suppliers through the Delegated Third Party, three (3) months prior to the termination.

6. TECHNICAL SECURITY CONTROLS

6.1 Key pair generation and installation

Per this topic, this CP/CPS provides for the Key controls by the CAs operated on the Digital Certification Infrastructure. The CP/CPS provides for the Key controls by such other participants as Subscribers.

6.1.1 Key pair generation

6.1.1.1 CA Key Pair Generation

For CA Key Pairs that are either

i. used as a CA Key Pair for a Root Certificate or ii. used as a CA Key Pair for a Subordinate CA Certificate, where the Subordinate CA is not the operator of the Root CA or an Affiliate of the Root CA,

the CA SHALL:

1. prepare and follow a Key Generation Script,
2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process, and
3. have a Qualified Auditor issue a report opining that the CA followed its key ceremony during its Key and Certificate generation process and the controls used to ensure the integrity and confidentiality of the Key Pair.

For other CA Key Pairs that are for the operator of the Root CA or an Affiliate of the Root CA, the CA SHOULD:

1. prepare and follow a Key Generation Script and
2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process.

In all cases, the CA SHALL:

1. generate the CA Key Pair in a physically secured environment as described in the CA's CP/CPS;
2. generate the CA Key Pair using personnel in Trusted Roles under the principles of multiple person control and split knowledge;
3. generate the CA Key Pair within cryptographic modules meeting the applicable technical and business requirements as disclosed in the CA's CP/CPS;
4. log its CA Key Pair generation activities; and
5. maintain effective controls to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in its CP/CPS and (if applicable) its Key Generation Script.

6.1.1.2 RA Key Pair Generation

No stipulation.

6.1.1.3 Subscriber Key Pair Generation

The CA SHALL reject a certificate request if one or more of the following conditions are met:

1. The Key Pair does not meet the requirements set forth in Section 6.1.5 and/or Section 6.1.6;

2. There is clear evidence that the specific method used to generate the Private Key was flawed;

3. The CA is aware of a demonstrated or proven method that exposes the Applicant's Private Key to compromise;

4. The CA has previously been notified that the Applicant's Private Key has suffered a Key Compromise using the CA's procedure for revocation request as described in Section 4.9.3 and Section 4.9.12;

5. The Public Key corresponds to an industry-demonstrated weak Private Key. For requests submitted on or after 2024-11-15, at least the following precautions SHALL be implemented:

   1. In the case of Debian weak keys vulnerability (https://wiki.debian.org/SSLkeys), the CA SHALL reject all keys found at https://github.com/cabforum/Debian-weak-keys/ for each key type (e.g. RSA, ECDSA) and size listed in the repository. For all other keys meeting the requirements of Section 6.1.5, with the exception of RSA key sizes greater than 8192 bits, the CA SHALL reject Debian weak keys.
   2. In the case of ROCA vulnerability, the CA SHALL reject keys identified by the tools available at https://github.com/crocs-muni/roca or equivalent.
   3. In the case of Close Primes vulnerability (https://fermatattack.secvuln.info/), the CA SHALL reject weak keys which can be factored within 100 rounds using Fermat’s factorization method.

   Suggested tools for checking for weak keys can be found here: https://cabforum.org/resources/tools/

If the Subscriber Certificate will contain an extKeyUsage extension containing either the values id-kp-serverAuth [RFC5280] or anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA.

[AATL Document Signing Certificates and Code Signing Certificates]

Subscriber’s key pair shall be directly generated by and stored in such a secure cryptographic hardware device.

6.1.2 Private key delivery to subscriber

Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization by the Subscriber.

If the CA or any of its designated RAs become aware that a Subscriber's Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subscriber, then the CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.

[S/MIME Certificates]

Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization by the Subscriber.

If the CA or any of its designated RAs become aware that a Subscriber's Private Key has been communicated to a person or organization not authorized by the Subscriber, then the CA SHALL revoke all Certificates that include the Public Key corresponding to the communicated Private Key.

If the CA or a Delegated Third Party generates the Private Key on behalf of the Subscriber where the Private Keys will be transported to the Subscriber, then the entity generating the Private Key SHALL either:

1. Transport the Private Key in hardware with an activation method that is equivalent to 128 bits of encryption, where the material used to activate/protect the Private Key (e.g., a password used to secure a PKCS 12 file) must be delivered to the Subscriber securely and separately from the container holding the Private Key; or
2. Encrypt the Private Key with at least 112 bits of encryption strength.

Illustrative examples include:

• Using a 128-bit AES key to wrap the Private Key.
• Storing the key in a PKCS 12 file encrypted using a password and algorithm whose combination provides at least 112 bits of encryption strength.
• Transporting the Private Key and/or PKCS 12 file and/or activation material via a TLS or other authenticated and encrypted network connection with at least 112 bits of encryption strength.
• Other approaches that meet the requirements are allowed.

[Code Signing Certificates]

If the CA or any Delegated Third Party is generating the Private Key on behalf of the Subscriber where the Private Keys will be transported to the Subscriber outside of the Signing Service's secure infrastructure, then the entity generating the Private Key MUST transport the Private Key in hardware with an activation method that is equivalent to 128 bits of encryption.

Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization by the Subscriber.

If the CA or any of its designated RAs become aware that a Subscriber's Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subscriber, then the CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key. If a Signing Service is generating a Private Key on behalf of the Subscriber, that Private Key SHALL NOT be transported to the Subscriber.

6.1.3 Public key delivery to certificate issuer

A Subscriber Public Key may be delivered online to the CA, the communication routing of which is encrypted by TLS.

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 S/MIME certificate, AATL document signing certificate and AATL timestamp certificate, the following confirmation need to be done:

For RSA key pairs the CA SHALL:

• Ensure that the modulus size, when encoded, is at least 2048 bits, and;
• Ensure that the modulus size, in bits, is evenly divisible by 8.

For ECDSA key pairs, the CA SHALL:

• Ensure that the key represents a valid point on the NIST P-256, NIST P-384 or NIST P-521 elliptic curve.

No other algorithms or key sizes are permitted.

When issuing code signing certificates and timestamp certificates that comply with Baseline Requirements for Code Signing Certificates, the following confirmation need to be done:

For RSA key pairs the CA SHALL:

• Ensure that the modulus size, when encoded, is at least 3072 bits, and;
• Ensure that the modulus size, in bits, is evenly divisible by 8.

For ECDSA key pairs, the CA SHALL:

• Ensure that the key represents a valid point on the NIST P-256 or NIST P-384 elliptic curve.

No other algorithms or key sizes are permitted.

6.1.6 Public key parameters generation and quality checking

RSA: The CA SHALL confirm that the value of the public exponent is an odd number equal to 3 or more. Additionally, the public exponent SHOULD be in the range between 2^16 + 1 and 2^256 - 1. The modulus SHOULD also have the following characteristics: an odd number, not the power of a prime, and have no factors smaller than 752. [Source: Section 5.3.3, NIST SP 800-89]

ECDSA: The CA SHOULD confirm the validity of all keys using either the ECC Full Public Key Validation Routine or the ECC Partial Public Key Validation Routine. [Source: Sections 5.6.2.3.2 and 5.6.2.3.3, respectively, of NIST SP 800-56A: Revision 2]

6.1.7 Key usage purposes (as per X.509 v3 key usage field)

Private Keys corresponding to Root Certificates MUST NOT be used to sign Certificates except in the following cases:

1. Self-signed Certificates to represent the Root CA itself;
2. Certificates for Subordinate CAs and Cross-Certified Subordinate CA Certificates;
3. Certificates for infrastructure purposes (administrative role certificates, internal CA operational device certificates); and
4. Certificates for OCSP Response verification.

6.2 Private Key Protection and Cryptographic Module Engineering Controls

The CA SHALL implement physical and logical safeguards to prevent unauthorized certificate issuance. Protection of the CA Private Key outside the validated system or device specified in Section 6.2.7 MUST consist of physical security, encryption, or a combination of both, implemented in a manner that prevents disclosure of the Private Key. The CA SHALL encrypt its Private Key with an algorithm and key-length that, according to the state of the art, are capable of withstanding cryptanalytic attacks for the residual life of the encrypted key or key part.

6.2.1 Cryptographic module standards and controls

The generation, storage and signing operations of the CA Private Keys are performed using Section 6.2.7.
No stipulation for Subscriber Private Keys.

[AATL Document Signing Certificates]

Certificates of the AATL Document Signing Certificate shall have one of the following accreditations:

1. FIPS 140-2 Level 2; or higher
2. Common Criteria (ISO 15408 & ISO 18045) - Protection Profiles CEN prEN 14169 (all parts applicable to the device type) or standards such as CEN EN 419 241 series or equivalent, for remotely managed devices; or
3. by an EU Member State as a Qualified Signature Creation Device (QSCD) after 1 July 2016, or that was recognized as a Secure Signature Creation Device
   (SSCD) by an EU Member State designated body before 1 July 2016.

6.2.2 Private key (n out of m) multi-person control

Activation, deactivation, backup and other operations relating to CA Private Keys are jointly performed by at least two authorized individuals in a secure environment. Activation, deactivation, backup and other operations relating to Subscriber Private Keys must be performed securely under the control of the relevant Subscribers.

6.2.3 Private key escrow

The CA does not Escrow CA Private Keys. The CA does not Escrow Subscriber Private Keys.

6.2.4 Private key backup

See Section 5.2.2.

6.2.5 Private key archival

Parties other than the Subordinate CA SHALL NOT archive the Subordinate CA Private Keys without authorization by the Subordinate CA.

6.2.6 Private key transfer into or from a cryptographic module

If the Issuing CA generated the Private Key on behalf of the Subordinate CA, then the Issuing CA SHALL encrypt the Private Key for transport to the Subordinate CA. If the Issuing CA becomes aware that a Subordinate CA's Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subordinate CA, then the Issuing CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.

6.2.7 Private key storage on cryptographic module

The CA SHALL protect its Private Key in a system or device that has been validated as meeting at least FIPS 140-2 level 3, FIPS 140-3 level 3, or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the Private Key and other assets against known threats.

[Time stamp certificates for code signing]

Time stamp certificates for code signing shall no longer be issued after 2025-04-15. The timestamp subordinate CA certificate for code signing purposes shall be revoked by 2026-06-06.

[Code Signing Certificates]

Code signing certificates shall no longer be issued after 2024-05-01. The Code signing subordinate CA certificates shall be revoked by 2026-06-06.

Effective 2023-06-01, Subscriber Private Keys for Code Signing Certificates SHALL be protected per the following requirements. The CA MUST obtain a contractual representation from the Subscriber that the Subscriber will use one of the following options to generate and protect their Code Signing Certificate Private Keys in a Hardware Crypto Module with a unit design form factor certified as conforming to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+:

1. Subscriber uses a Hardware Crypto Module meeting the specified requirement.
2. Subscriber uses a cloud-base key generation and protection solution with the following requirements: a Key creation, storage, and usage of Private Key must remain within the security boundaries of the cloud solution’s Hardware Crypto Module that conforms to the specified requirements; b Subscription at the level that manages the Private Key must be configured to log all access, operations, and configuration changes on the resources securing the Private Key.
3. Subscriber uses a Signing Service which meets the Baseline Requirements for Code Signing Certificates of Section 6.2.7.3.

Effective 2023-06-01, for Code Signing Certificates, one of the following methods MUST be employed to satisfy Baseline Requirements for Code Signing Certificates:

1. The CA ships a suitable Hardware Crypto Module, with one or more pre-generated Key Pairs that the CA has generated using the Hardware Crypto Module;
2. The Subscriber counter-signs certificate requests that can be verified by using a manufacturer’s certificate, commonly known as key attestation, indicating that the Private Key was generated in a non-exportable way using a suitable Hardware Crypto Module;
3. The Subscriber uses a CA prescribed crypto library and a suitable Hardware Crypto Module combination for the Key Pair generation and storage;
4. The Subscriber provides an internal or external IT audit indicating that it is only using a suitable Hardware Crypto Module to generate Key Pairs to be associated with Code Signing Certificates;
5. The Subscriber provides a suitable report from the cloud-based key protection solution subscription and resources configuration protecting the Private Key in a suitable Hardware Crypto Module;
6. The CA relies on a report provided by the Applicant that is signed by an auditor who is approved by the CA and who has IT and security training or is a CISA witnesses the Key Pair creation in a suitable Hardware Crypto Module solution including a cloud-based key generation and protection solution;
7. The Subscriber provides an agreement that they use a Signing Service meeting the Baseline Requirements for Code Signing Certificates of Section 6.2.7.3;

[AATL Document Signing Certificates]

If it is confirmed that the CA has generated a private key within the HSM used by the Subscriber, in the certificate application procedure, the CA verify the signature of the certificate issuance request and confirm that it is signed with the private key corresponding to the public key included in the certificate issuance request.

Alternatively, the CA generates a private key on a cryptographic hardware device and securely distributes the private key to the Subscriber, so that the CA proves the Subscriber owns the private key corresponding to the applicable certificate.

6.2.8 Activating Private Keys

The CA Private Key is jointly activated by at least two authorized individuals in a secure room. No stipulation for Subscriber Private Keys.

6.2.9 Deactivating Private Keys

The CA Private Key is jointly deactivated by at least two authorized individuals in a secure room. No stipulation for Subscriber Private Keys.

6.2.10 Destroying Private Keys

Private Keys of the CA are jointly destroyed by at least two authorized individuals by means of complete initialization or physical destruction. The Private Key backups are also destroyed in the same manner. No stipulation for Subscriber Private Keys.

6.2.11 Cryptographic Module Rating

The quality standards to be applied to the cryptographic modules used by the CA are as specified in Section 6.2.1 hereof. No stipulation for Subscriber Private Keys.

6.3 Other aspects of key pair management

6.3.1 Public key archival

The provisions for the CA Public Keys are stipulated in Section 6.2.1. No stipulation for Subscriber Private Keys.

Archival of Public Keys of the CAs operated on the Digital Certification Infrastructure is covered by Section 5.5.1 hereof.

6.3.2 Certificate operational periods and key pair usage periods

The validity period of the key pair of the subordinate CA is not specified, but the validity period of the subordinate CA certificate shall be 20 years or less.

[Code Signing Certificates and Timestamp Certificates for Code Signing Certificates]

Code signing certificates that comply with Baseline Requirements for Code Signing Certificates must not have a Validity Period greater than 39 months. The time stamp authority used for code signing certificates must use a new time stamp certificate with a new private key every 15 months to minimize the impact on the subscriber if the private key of the time stamp certificate is compromised. The validity period of the time stamp certificate must not be greater than 135 months.

The Timestamp Certificate Key Pair that complies with the Baseline Requirements for Code Signing Certificates MUST meet the requirements in Section 6.1.5. Timestamp Authority SHALL NOT use a Private Key associated with a Timestamp Certificate more than 15 months after the notBefore date of a Timestamp Certificate. Effective 2025-04-15, Private Keys associated with Timestamp Certificates issued for greater than 15 months MUST be removed from the Hardware Crypto Module protecting the Private Key within 18 months after issuance of the Timestamp Certificate. For Timestamp Certificates issued on or after 2024-06-01, the CA SHALL log the removal of the Private Key from the Hardware Crypto Module through means of a key deletion ceremony performed by the CA and witnessed and signed‐off by at least two Trusted Role members. The CA MAY also perform a key destruction ceremony, meaning that all copies of that private key are unequivocally/securely destroyed (i.e. without a way to recover the key), including any instance of the key as part of a backup, to satisfy the Baseline Requirements for Code Signing Certificates. The CA MAY maintain existing backup sets containing the Private Key corresponding to a Timestamp Certificate. The CA SHOULD NOT restore the Private Key corresponding to a Timestamp Certificate contained within the backup if the Timestamp Certificate was issued more than 15 months prior to restoration of the backup. If the CA does restore such a Private Key, the CA SHALL only restore the Private Key in a suitable HSM while it’s maintained in a High Security Zone and in an offline state or air‐gapped from all other networks and perform a new key destruction ceremony prior to the HSM being brought to an online state.

[AATL Timestamp Certificates]

The validity period of the time stamp certificate must not be greater than 135 months.

[S/MIME Certificates]

S/MIME certificates issued after 2022-04-01 must not have a Validity Period greater than 825 days.

[Document Signing Certificates and Client Authentication Certificates]

Subscriber certificates must not have a Validity Period greater than 1827 days.

For the purpose of calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, shall represent an additional day. For this reason, Subscriber Certificates SHOULD NOT be issued for the maximum permissible time by default, in order to account for such adjustments.

6.4 Activation data

6.4.1 Activation data generation and installation

The activation data required to use Private Keys of the CAs operated on the Digital Certification Infrastructure are jointly generated by at least two authorized individuals and are stored on a digital medium.

6.4.2 Activation data protection

The digital media storing the data required for activation of Private Keys of the CAs operated on the Digital Certification Infrastructure are stored under control in a secure room.

6.4.3 Other aspects of activation data

Management of the generation and setting of the activation data of the private key of the CA operated on the Digital Certification Infrastructure is performed by the persons described in Section 5.2.1.

6.5 Computer security controls

6.5.1 Specific computer security technical requirements

The CA SHALL enforce multi-factor authentication for all accounts capable of directly causing certificate issuance.

6.5.2 Computer security rating

The CA conducts the preproduction system tests of all software and hardware to be employed by the certification infrastructure systems in an effort to secure the system reliability. In addition, SECOM Trust Systems constantly collects information on the security vulnerabilities of the certification infrastructure systems and performs assessments to be able to promptly take proper actions should any vulnerability be detected.

6.6 Life cycle technical controls

6.6.1 System development controls

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.

7.1.1 Version number(s)

Certificates MUST be of type X.509 v3.

7.1.2 Certificate Content and Extensions

This section specifies the additional requirements for Certificate content and extensions for Certificates.

7.1.2.1 Root CA Certificate Profile

See APPENDIX B – Certificate profile.

7.1.2.2 Cross-Certified Subordinate CA Certificate Profile

See APPENDIX B – Certificate profile.

7.1.2.3 Subordinate CA Certificate Profile

See APPENDIX B – Certificate profile.

7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile

No stipulation.

7.1.2.5 Technically Constrained TLS Subordinate CA Certificate Profile

No stipulation.

7.1.2.6 TLS Subordinate CA Certificate Profile

No stipulation.

7.1.2.7 Subscriber Certificate Profile

See APPENDIX B – Certificate profile.

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

No stipulation.

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

[S/MIME Certificates and Code Signing Certificates]

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.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;
• Subscriber Certificates that do not include an authorityInformationAccess extension with an id-ad-ocsp accessMethod; and
• Code Signing Certificates;

The CRL Distribution Points extension SHOULD NOT be present in:

• Root CA 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 Section 1.1.1 Standards, Criteria and Regulations 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 Section 1.1.1 Standards, Criteria and Regulations.

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 Section 1.1.1 Standards, Criteria and Regulations.

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

No stipulation.

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 Section 1.1.1 Standards, Criteria and Regulations .

The OIDs 2.23.140.1.5.2.1 and 2.23.140.1.5.2.3 are used by SECOM Trust Systems when issuing S/MIME subordinate CA certificates to externally-operated subordinate CAs. Therefore, this CP/CPS does not address the validation procedures or certificate profiles for S/MIME end-entity certificates corresponding to these OIDs.

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

[Code Signing certificates]

The serial number of a revoked Certificate MUST remain on the CRL for at least 10 years after the expiration of the Certificate. Application Software Suppliers MAY require the CA to support a longer life-time in its contract with the CA. If a Code Signing Certificate contains the Lifetime Signing OID, the Code Signature becomes invalid when the Code Signing Certificate expires, even if the Code Signature is timestamped. Because the Lifetime Signing OID is intended to be used with test purposes only, a CA MAY cease maintaining revocation information for a Code Signing Certificate with the Lifetime Signing OID after the Code Signing Certificate expires.

If a Code Signing Certificate previously has been revoked, and the CA later becomes aware of a more appropriate revocation date, then the CA MAY use that revocation date in subsequent CRL entries for that Code Signing Certificate.

[Common to all certificates]

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

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 be 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 (S/MIME CA):

   • For Audit Periods starting before the Effective Date defined in Section 1.2.1 of the first version of S/MIME Baseline Requirements, “WebTrust for CAs v2.2.2 or newer”; or
   • For Audit Periods starting after the Effective Date defined in Section 1.2.1 of the first version of S/MIME Baseline Requirements, “WebTrust for CAs v2.2.2 or newer” AND “WebTrust for S/MIME Baseline Requirements v1.0.0 or newer”; or
   • For Audit Periods starting after 2025-04-01, “WebTrust for CAs v2.2.2 or newer” AND “WebTrust for S/MIME Baseline Requirements v1.0.0 or newer” AND “WebTrust for Network Security v2.0 or newer”;

2. WebTrust (Code Signing CA):

   • “WebTrust for CAs v2.0 or newer” AND “WebTrust for Certification Authorities – Code Signing Baseline Requirements v2.0 or newer” AND “WebTrust for Certification Authorities – Network Security – Version 1.0 or newer”;

1. WebTrust (AATL Document Signing CA and AATL Timestamp CA):

   • “WebTrust for CA v.2.0 or later”;

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

• S/MIME CA

  During the period in which the CA issues Certificates, the CA SHALL monitor adherence to its CP/CPS and S/MIME Baseline Requirements and control its service quality by performing self audits on at least a quarterly basis against a randomly selected sample including a minimum of the greater of thirty (30) Certificates or three percent (3%) of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken.

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

• Code Signing CA

  CAs must abide by the self-audit requirements of Baseline Requirements for Code Signing Certificates. During the period in which it issues Code Signing Certificates, the CA MUST strictly control its service quality by performing ongoing self-audits against a randomly selected sample of at least three percent of the Non-EV Code Signing Certificates and at least three percent of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken. For all Code Signing Certificates where the final cross-correlation and due diligence requirements of Section 8 of Baseline Requirements for Code Signing Certificates is performed by an RA, the CA MUST strictly control its service quality by performing ongoing self-audits against a randomly selected sample of at least six percent of the Non-EV Code Signing Certificates and at least six percent of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken.

8.8 Review of delegated parties

Except for Delegated Third Parties, Enterprise RAs, and Technically Constrained Subordinate CAs that undergo an annual audit that meets the criteria specified in Section 8.4, 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

No stipulation.

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 Section 1.1.1 Standards, Criteria and Regulations 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 Mailbox Address [S/MIME Certificates]: That, at the time of issuance, the CA:

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

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 represents that it provided the Subscriber at the time of issuance with documentation on how to securely store and prevent the misuse of Private Keys associated with Code Signing Certificates and AATL Document Signing Certificates.

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.

[S/MIME Certificates]

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 use the Certificate only on MailBox Addresses 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.

[Code Signing Certificates]

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: To provide accurate and complete information at all times in connection with the issuance of a Certificate, including in the Certificate Request and as otherwise requested by the CA.
2. Protection of Private Key: Where the key is available outside a Signing Service, to maintain sole control of, keep confidential, and properly protect, at all times in accordance with Section 6.2.7, the Private Key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device, e.g. password or token). The CA MUST provide the Subscriber with documentation on how to protect a Private Key. The CA MAY provide this documentation as a white paper or as part of the Subscriber Agreement. The Subscriber MUST represent that it will generate and operate any device storing Private Keys in a secure manner, as described in a document of code signing best practices, which the CA MUST provide to the Subscriber during the ordering process. The CA MUST obligate the Subscriber to use passwords that are randomly generated with at least 16 characters containing uppercase letters, lowercase letters, numbers, and symbols to transport Private Keys.
3. Private Key Reuse: To not apply for a Code Signing Certificate if the Public Key in the Certificate is or will be used with a non-Code Signing Certificate.
4. Use: To use the Certificate and associated Private Key only for authorized and legal purposes, including not using the Certificate to sign Suspect Code and to use the Certificate and Private Key solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement or Terms of Use.
5. Compliance with Industry Standards: An acknowledgment and acceptance that the CA may modify the Subscriber Agreement or Terms of Use when necessary to comply with any changes in Section 1.1.1 Standards, Criteria and Regulations.
6. Prevention of Misuse: To provide adequate network and other security controls to protect against misuse of the Private Key and that the CA will revoke the Certificate without requiring prior notification if there is unauthorized access to the Private Keys.
7. Acceptance of Certificate: Not to use the Certificate until after the Applicant, or an agent of Applicant, has reviewed and verified the Certificate contents for accuracy.
8. Reporting and Revocation: To promptly cease using a Certificate and its associated Private Key and promptly request that the CA revoke the Certificate if the Subscriber believes that (a) any information in the Certificate is, or becomes, incorrect or inaccurate, (b) the Private Key associated with the Public Key contained in the Certificate was misused or compromised, or (c) there is evidence that the Certificate was used to sign Suspect Code.
9. Sharing of Information: An acknowledgment and acceptance that, if: (a) the Certificate or the Applicant is identified as a source of Suspect Code, (b) the authority to request the Certificate cannot be verified, or (c) the Certificate is revoked for reasons other than Subscriber request (e.g. as a result of Private Key compromise, discovery of malware, etc.), then the CA is authorized to share information about the Applicant, signed application, Certificate, and surrounding circumstances with other CAs or industry groups, including the CA/Browser Forum.
10. Termination of Use of Certificate: To promptly cease using the Private Key corresponding to the Public Key listed in a Certificate upon expiration or revocation of the Certificate.
11. Responsiveness: An obligation to respond to the CA's instructions concerning Key Compromise or Certificate misuse within a specified time period.
12. Acknowledgment and Acceptance: An acknowledgement and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the Terms of Use or the Subscriber Agreement.

[Certificates other than those listed above]

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: To provide accurate and complete information at all times in connection with the issuance of a Certificate, including in the Certificate Request and as otherwise requested by the CA.
2. Protection of Private Key: Where the key is available outside a Signing Service, to maintain sole control of, keep confidential, and properly protect, at all times in accordance with Section 6.2.7, the Private Key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device, e.g. password or token). The CA MUST provide the Subscriber with documentation on how to protect a Private Key. The CA MAY provide this documentation as a white paper or as part of the Subscriber Agreement. The Subscriber SHALL also comply with all key management requirements set forth in this CP/CPS.
3. Use: To use the Certificate and associated Private Key only for authorized and legal purposes and to use the Certificate and Private Key solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement or Terms of Use.
4. Compliance with Industry Standards: An acknowledgment and acceptance that the CA may modify the Subscriber Agreement or Terms of Use when necessary to comply with any changes in Section 1.1.1 Standards, Criteria and Regulations.
5. Prevention of Misuse: To provide adequate network and other security controls to protect against misuse of the Private Key and that the CA will revoke the Certificate without requiring prior notification if there is unauthorized access to the Private Keys.
6. Acceptance of Certificate: Not to use the Certificate until after the Applicant, or an agent of Applicant, has reviewed and verified the Certificate contents for accuracy.
7. Reporting and Revocation: To promptly cease using a Certificate and its associated Private Key and promptly request that the CA revoke the Certificate if the Subscriber believes that (a) any information in the Certificate is, or becomes, incorrect or inaccurate, or (b) the Private Key associated with the Public Key contained in the Certificate was misused or compromised.
8. Sharing of Information: An acknowledgment and acceptance that, if the authority to request the Certificate cannot be verified, then the CA is authorized to share information about the Applicant, signed application, Certificate, and surrounding circumstances with other CAs or industry groups.
9. Termination of Use of Certificate: To promptly cease using the Private Key corresponding to the Public Key listed in a Certificate upon expiration or revocation of the Certificate.
10. Responsiveness: An obligation to respond to the CA's instructions concerning Key Compromise or Certificate misuse within a specified time period.
11. Acknowledgment and Acceptance: An acknowledgement and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the Terms of Use or the Subscriber Agreement.

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 Section 1.1.1 Standards, Criteria and Regulations 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 Section 1.1.1 Standards, Criteria and Regulations 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 S/MIME Baseline Requirements under this section, and the specific modification to S/MIME 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 S/MIME Baseline Requirements accordingly.

Any modification to CA practice enabled under this section MUST be discontinued if and when the Law no longer applies, or S/MIME Baseline Requirements are modified to make it possible to comply with both S/MIME 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.2. DNS TXT Methods

A.2.1. DNS TXT Record Email Contact

The DNS TXT record MUST be placed on the "_validation-contactemail" subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid email address as defined in RFC 6532, Section 3.2, with no additional padding or structure, or it cannot be used.

APPENDIX B – Certificate profile

Table : "Security Communication RootCA2" and Subordinate CAs

Root CA Certificate SHA256 Fingerprint: 513B2CECB810D4CDE5DD85391ADFC6C2DD60D87BB736D2B521484AA47A0EBEF6

Table : "Security Communication RootCA3" and Subordinate CAs

Root CA Certificate SHA256 Fingerprint: 24A55C2AB051442D0617766541239A4AD032D7C55175AA34FFDE2FBC4F5C5294

Table : "SECOM RSA Root CA 2023" and Subordinate CAs

Root CA Certificate SHA256 Fingerprint: 2C154235528D701790B675AFF6E1970827B10ED665E913835BF46E3460FD5C84

Table : "SECOM Document Signing RSA Root CA 2023" and Subordinate CAs

Root CA Certificate SHA256 Fingerprint: 46219BBF9148F00E8B7A4C619B57CF7602701FF81348400718870FABD31FC5BE

Table : "SECOM SMIME RSA Root CA 2024" and Subordinate CA

Root CA Certificate SHA256 Fingerprint: 3629E7188E00A7CB3232C4426BC84912F1218B1A9AE676C0B0ABE1DBFE2182B5

Table : Subscriber Certificates (Client Authentication Certificate and Document Signing Certificates)

Table : Subscriber Certificates (Code Signing Certificates, Not be issued after 2024-05-01)

Table: Subscriber Certificates (AATL Document Signing Certificates)

Table: Subscriber Certificates (S/MIME Certificates)

This profile is compliant with the S/MIME Baseline Requirements strict mailbox-validated profile {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) mailbox-validated (1) strict (3)} (2.23.140.1.5.1.3).

Table: Security Communication RootCA2 TSA, TA Certificates (Issued before 2018-09-26)

Table: Security Communication RootCA3 TSA, TA Certificates (Issued before 2018-09-26)

Table: Security Communication RootCA3 TimeStamping Subordinate CA Certificates (Issued after 2018-06-07)

Table: SECOM TimeStamping CA2 TSA, TA Certificates

Table: SECOM TimeStamping CA3 TSA, TA Certificates

Table: SECOM TimeStamping CA4 TSA Certificates (Not issued after 2025-04-15)

Table: SECOM TimeStamping Service TSA Certificates