---
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](#table-of-contents)
- [1. INTRODUCTION](#1-introduction)
- [1.1 Overview](#11-overview)
- [1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations)
- [1.2 Document name and identification](#12-document-name-and-identification)
- [1.2.1 Revisions](#121-revisions)
- [1.3 PKI Participants](#13-pki-participants)
- [1.3.1 Certification Authorities](#131-certification-authorities)
- [1.3.2 Registration Authorities](#132-registration-authorities)
- [1.3.2.1 Enterprise registration authorities (S/MIME Certificates)](#1321-enterprise-registration-authorities-smime-certificates)
- [1.3.3 Subscribers](#133-subscribers)
- [1.3.4 Relying Parties](#134-relying-parties)
- [1.3.5 Other Participants](#135-other-participants)
- [1.4 Certificate Usage](#14-certificate-usage)
- [1.4.1 Appropriate Certificate Uses](#141-appropriate-certificate-uses)
- [1.4.2 Prohibited Certificate Uses](#142-prohibited-certificate-uses)
- [1.5 Policy administration](#15-policy-administration)
- [1.5.1 Organization Administering the Document](#151-organization-administering-the-document)
- [1.5.2 Contact Person](#152-contact-person)
- [1.5.3 Person Determining CPS suitability for the policy](#153-person-determining-cps-suitability-for-the-policy)
- [1.5.4 CPS approval procedures](#154-cps-approval-procedures)
- [1.6 Definitions and Acronyms](#16-definitions-and-acronyms)
- [1.6.1 Definitions](#161-definitions)
- [1.6.2 Acronyms](#162-acronyms)
- [1.6.3 References](#163-references)
- [1.6.4 Conventions](#164-conventions)
- [2. PUBLICATION AND REPOSITORY RESPONSIBILITIES](#2-publication-and-repository-responsibilities)
- [2.1 Repositories](#21-repositories)
- [2.2 Publication of information](#22-publication-of-information)
- [2.3 Time or frequency of publication](#23-time-or-frequency-of-publication)
- [2.4 Access controls on repositories](#24-access-controls-on-repositories)
- [3. IDENTIFICATION AND AUTHENTICATION](#3-identification-and-authentication)
- [3.1 Naming](#31-naming)
- [3.1.1 Types of names](#311-types-of-names)
- [3.1.2 Need for names to be meaningful](#312-need-for-names-to-be-meaningful)
- [3.1.3 Anonymity or pseudonymity of subscribers](#313-anonymity-or-pseudonymity-of-subscribers)
- [3.1.4 Rules for interpreting various name forms](#314-rules-for-interpreting-various-name-forms)
- [3.1.5 Uniqueness of names](#315-uniqueness-of-names)
- [3.1.6 Recognition, authentication, and role of trademarks](#316-recognition-authentication-and-role-of-trademarks)
- [3.2 Initial identity validation](#32-initial-identity-validation)
- [3.2.1 Method to prove possession of private key](#321-method-to-prove-possession-of-private-key)
- [3.2.2 Authentication of Organization and Domain Identity](#322-authentication-of-organization-and-domain-identity)
- [3.2.2.1 Identity](#3221-identity)
- [3.2.2.1.1 Validating authority over mailbox via domain (S/MIME Certificates)](#32211-validating-authority-over-mailbox-via-domain-smime-certificates)
- [3.2.2.1.2 Validating control over mailbox via email (S/MIME Certificates)](#32212-validating-control-over-mailbox-via-email-smime-certificates)
- [3.2.2.1.3 Validating applicant as operator of associated mail server(s) (S/MIME Certificates)](#32213-validating-applicant-as-operator-of-associated-mail-servers-smime-certificates)
- [3.2.2.2 DBA/Tradename](#3222-dbatradename)
- [3.2.2.3 Verification of Country](#3223-verification-of-country)
- [3.2.3 Authentication of individual identity](#323-authentication-of-individual-identity)
- [3.2.3.1 Attribute collection of organization identity (S/MIME Certificates)](#3231-attribute-collection-of-organization-identity-smime-certificates)
- [3.2.4 Non-verified subscriber information](#324-non-verified-subscriber-information)
- [3.2.5 Validation of authority](#325-validation-of-authority)
- [3.2.6 Criteria for Interoperation or Certification](#326-criteria-for-interoperation-or-certification)
- [3.3 Identification and authentication for re-key requests](#33-identification-and-authentication-for-re-key-requests)
- [3.3.1 Identification and authentication for routine re-key](#331-identification-and-authentication-for-routine-re-key)
- [3.3.2 Identification and authentication for re-key after revocation](#332-identification-and-authentication-for-re-key-after-revocation)
- [3.4 Identification and authentication for revocation request](#34-identification-and-authentication-for-revocation-request)
- [4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS](#4-certificate-life-cycle-operational-requirements)
- [4.1 Certificate Application](#41-certificate-application)
- [4.1.1 Who can submit a certificate application](#411-who-can-submit-a-certificate-application)
- [4.1.2 Enrollment process and responsibilities](#412-enrollment-process-and-responsibilities)
- [4.2 Certificate application processing](#42-certificate-application-processing)
- [4.2.1 Performing identification and authentication functions](#421-performing-identification-and-authentication-functions)
- [4.2.2 Approval or rejection of certificate applications](#422-approval-or-rejection-of-certificate-applications)
- [4.2.2.1 Certification authority authorization (CAA) (S/MIME Certificates)](#4221-certification-authority-authorization-caa-smime-certificates)
- [4.2.2.1.1 DNSSEC validation of CAA records](#42211-dnssec-validation-of-caa-records)
- [4.2.2.2 Multi-perspective issuance corroboration (S/MIME Certificates)](#4222-multi-perspective-issuance-corroboration-smime-certificates)
- [4.2.3 Time to process certificate applications](#423-time-to-process-certificate-applications)
- [4.3 Certificate issuance](#43-certificate-issuance)
- [4.3.1 CA actions during certificate issuance](#431-ca-actions-during-certificate-issuance)
- [4.3.1.1 Manual authorization of certificate issuance for Root CAs](#4311-manual-authorization-of-certificate-issuance-for-root-cas)
- [4.3.1.2 Linting of to-be-signed Certificate content](#4312-linting-of-to-be-signed-certificate-content)
- [4.3.1.3 Linting of issued Certificates](#4313-linting-of-issued-certificates)
- [4.3.2 Notification to subscriber by the CA of issuance of certificate](#432-notification-to-subscriber-by-the-ca-of-issuance-of-certificate)
- [4.4 Certificate acceptance](#44-certificate-acceptance)
- [4.4.1 Conduct constituting certificate acceptance](#441-conduct-constituting-certificate-acceptance)
- [4.4.2 Publication of the certificate by the CA](#442-publication-of-the-certificate-by-the-ca)
- [4.4.3 Notification of certificate issuance by the CA to other entities](#443-notification-of-certificate-issuance-by-the-ca-to-other-entities)
- [4.5 Key pair and certificate usage](#45-key-pair-and-certificate-usage)
- [4.5.1 Subscriber private key and certificate usage](#451-subscriber-private-key-and-certificate-usage)
- [4.5.2 Relying party public key and certificate usage](#452-relying-party-public-key-and-certificate-usage)
- [4.6 Certificate renewal](#46-certificate-renewal)
- [4.6.1 Circumstance for certificate renewal](#461-circumstance-for-certificate-renewal)
- [4.6.2 Who may request renewal](#462-who-may-request-renewal)
- [4.6.3 Processing certificate renewal requests](#463-processing-certificate-renewal-requests)
- [4.6.4 Notification of new certificate issuance to subscriber](#464-notification-of-new-certificate-issuance-to-subscriber)
- [4.6.5 Conduct constituting acceptance of a renewal certificate](#465-conduct-constituting-acceptance-of-a-renewal-certificate)
- [4.6.6 Publication of the renewal certificate by the CA](#466-publication-of-the-renewal-certificate-by-the-ca)
- [4.6.7 Notification of certificate issuance by the CA to other entities](#467-notification-of-certificate-issuance-by-the-ca-to-other-entities)
- [4.7 Certificate re-key](#47-certificate-re-key)
- [4.7.1 Circumstance for certificate re-key](#471-circumstance-for-certificate-re-key)
- [4.7.2 Who may request certification of a new public key](#472-who-may-request-certification-of-a-new-public-key)
- [4.7.3 Processing certificate re-keying requests](#473-processing-certificate-re-keying-requests)
- [4.7.4 Notification of new certificate issuance to subscriber](#474-notification-of-new-certificate-issuance-to-subscriber)
- [4.7.5 Conduct constituting acceptance of a re-keyed certificate](#475-conduct-constituting-acceptance-of-a-re-keyed-certificate)
- [4.7.6 Publication of the re-keyed certificate by the CA](#476-publication-of-the-re-keyed-certificate-by-the-ca)
- [4.7.7 Notification of certificate issuance by the CA to other entities](#477-notification-of-certificate-issuance-by-the-ca-to-other-entities)
- [4.8 Certificate modification](#48-certificate-modification)
- [4.8.1 Circumstance for certificate modification](#481-circumstance-for-certificate-modification)
- [4.8.2 Who may request certificate modification](#482-who-may-request-certificate-modification)
- [4.8.3 Processing certificate modification requests](#483-processing-certificate-modification-requests)
- [4.8.4 Notification of new certificate issuance to subscriber](#484-notification-of-new-certificate-issuance-to-subscriber)
- [4.8.5 Conduct constituting acceptance of modified certificate](#485-conduct-constituting-acceptance-of-modified-certificate)
- [4.8.6 Publication of the modified certificate by the CA](#486-publication-of-the-modified-certificate-by-the-ca)
- [4.8.7 Notification of certificate issuance by the CA to other entities](#487-notification-of-certificate-issuance-by-the-ca-to-other-entities)
- [4.9 Certificate revocation and suspension](#49-certificate-revocation-and-suspension)
- [4.9.1 Circumstances for revocation](#491-circumstances-for-revocation)
- [4.9.1.1 Reasons for Revoking a Subscriber Certificate](#4911-reasons-for-revoking-a-subscriber-certificate)
- [4.9.1.2 Reasons for Revoking a Subordinate CA Certificate](#4912-reasons-for-revoking-a-subordinate-ca-certificate)
- [4.9.2 Who can request revocation](#492-who-can-request-revocation)
- [4.9.3 Procedure for revocation request](#493-procedure-for-revocation-request)
- [4.9.4 Revocation request grace period](#494-revocation-request-grace-period)
- [4.9.5 Time within which CA must process the revocation request](#495-time-within-which-ca-must-process-the-revocation-request)
- [4.9.6 Revocation checking requirement for relying parties](#496-revocation-checking-requirement-for-relying-parties)
- [4.9.7 CRL issuance frequency](#497-crl-issuance-frequency)
- [4.9.8 Maximum latency for CRLs (if applicable)](#498-maximum-latency-for-crls-if-applicable)
- [4.9.9 On-line revocation/status checking availability](#499-on-line-revocationstatus-checking-availability)
- [4.9.10 On-line revocation checking requirements](#4910-on-line-revocation-checking-requirements)
- [4.9.11 Other forms of revocation advertisements available](#4911-other-forms-of-revocation-advertisements-available)
- [4.9.12 Special requirements re key compromise](#4912-special-requirements-re-key-compromise)
- [4.9.13 Circumstances for suspension](#4913-circumstances-for-suspension)
- [4.9.14 Who can request suspension](#4914-who-can-request-suspension)
- [4.9.15 Procedure for suspension request](#4915-procedure-for-suspension-request)
- [4.9.16 Limits on suspension period](#4916-limits-on-suspension-period)
- [4.10 Certificate status services](#410-certificate-status-services)
- [4.10.1 Operational characteristics](#4101-operational-characteristics)
- [4.10.2 Service availability](#4102-service-availability)
- [4.10.3 Optional features](#4103-optional-features)
- [4.11 End of subscription](#411-end-of-subscription)
- [4.12 Key escrow and recovery](#412-key-escrow-and-recovery)
- [4.12.1 Key escrow and recovery policy and practices](#4121-key-escrow-and-recovery-policy-and-practices)
- [4.12.2 Session key encapsulation and recovery policy and practices](#4122-session-key-encapsulation-and-recovery-policy-and-practices)
- [5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS](#5-management-operational-and-physical-controls)
- [5.1 Physical Security Controls](#51-physical-security-controls)
- [5.1.1 Site location and construction](#511-site-location-and-construction)
- [5.1.2 Physical access](#512-physical-access)
- [5.1.3 Power and air conditioning](#513-power-and-air-conditioning)
- [5.1.4 Water exposures](#514-water-exposures)
- [5.1.5 Fire prevention and protection](#515-fire-prevention-and-protection)
- [5.1.6 Media storage](#516-media-storage)
- [5.1.7 Waste disposal](#517-waste-disposal)
- [5.1.8 Off-site backup](#518-off-site-backup)
- [5.2 Procedural controls](#52-procedural-controls)
- [5.2.1 Trusted roles](#521-trusted-roles)
- [5.2.2 Number of Individuals Required per Task](#522-number-of-individuals-required-per-task)
- [5.2.3 Identification and authentication for each role](#523-identification-and-authentication-for-each-role)
- [5.2.4 Roles requiring separation of duties](#524-roles-requiring-separation-of-duties)
- [5.3 Personnel controls](#53-personnel-controls)
- [5.3.1 Qualifications, experience, and clearance requirements](#531-qualifications-experience-and-clearance-requirements)
- [5.3.2 Background check procedures](#532-background-check-procedures)
- [5.3.3 Training Requirements and Procedures](#533-training-requirements-and-procedures)
- [5.3.4 Retraining frequency and requirements](#534-retraining-frequency-and-requirements)
- [5.3.5 Job rotation frequency and sequence](#535-job-rotation-frequency-and-sequence)
- [5.3.6 Sanctions for unauthorized actions](#536-sanctions-for-unauthorized-actions)
- [5.3.7 Independent Contractor Controls](#537-independent-contractor-controls)
- [5.3.8 Documentation supplied to personnel](#538-documentation-supplied-to-personnel)
- [5.4 Audit logging procedures](#54-audit-logging-procedures)
- [5.4.1 Types of events recorded](#541-types-of-events-recorded)
- [5.4.1.1 Router and firewall activities logs](#5411-router-and-firewall-activities-logs)
- [5.4.1.2 Types of events recorded for Timestamp Authorities](#5412-types-of-events-recorded-for-timestamp-authorities)
- [5.4.2 Frequency of processing audit log](#542-frequency-of-processing-audit-log)
- [5.4.3 Retention period for audit log](#543-retention-period-for-audit-log)
- [5.4.4 Protection of audit log](#544-protection-of-audit-log)
- [5.4.5 Audit log backup procedures](#545-audit-log-backup-procedures)
- [5.4.6 Audit collection System (internal vs. external)](#546-audit-collection-system-internal-vs-external)
- [5.4.7 Notification to event-causing subject](#547-notification-to-event-causing-subject)
- [5.4.8 Vulnerability assessments](#548-vulnerability-assessments)
- [5.5 Records archival](#55-records-archival)
- [5.5.1 Types of records archived](#551-types-of-records-archived)
- [5.5.2 Retention period for archive](#552-retention-period-for-archive)
- [5.5.3 Protection of archive](#553-protection-of-archive)
- [5.5.4 Archive backup procedures](#554-archive-backup-procedures)
- [5.5.5 Requirements for time-stamping of records](#555-requirements-for-time-stamping-of-records)
- [5.5.6 Archive collection system (internal or external)](#556-archive-collection-system-internal-or-external)
- [5.5.7 Procedures to obtain and verify archive information](#557-procedures-to-obtain-and-verify-archive-information)
- [5.6 Key changeover](#56-key-changeover)
- [5.7 Compromise and disaster recovery](#57-compromise-and-disaster-recovery)
- [5.7.1 Incident and compromise handling procedures](#571-incident-and-compromise-handling-procedures)
- [5.7.1.1 Incident Response and Disaster Recovery Plans](#5711-incident-response-and-disaster-recovery-plans)
- [5.7.2 Recovery Procedures if Computing resources, software, and/or data are corrupted](#572-recovery-procedures-if-computing-resources-software-andor-data-are-corrupted)
- [5.7.3 Recovery Procedures after Key Compromise](#573-recovery-procedures-after-key-compromise)
- [5.7.4 Business continuity capabilities after a disaster](#574-business-continuity-capabilities-after-a-disaster)
- [5.8 CA or RA termination](#58-ca-or-ra-termination)
- [6. TECHNICAL SECURITY CONTROLS](#6-technical-security-controls)
- [6.1 Key pair generation and installation](#61-key-pair-generation-and-installation)
- [6.1.1 Key pair generation](#611-key-pair-generation)
- [6.1.1.1 CA Key Pair Generation](#6111-ca-key-pair-generation)
- [6.1.1.2 RA Key Pair Generation](#6112-ra-key-pair-generation)
- [6.1.1.3 Subscriber Key Pair Generation](#6113-subscriber-key-pair-generation)
- [6.1.2 Private key delivery to subscriber](#612-private-key-delivery-to-subscriber)
- [6.1.3 Public key delivery to certificate issuer](#613-public-key-delivery-to-certificate-issuer)
- [6.1.4 CA public key delivery to relying parties](#614-ca-public-key-delivery-to-relying-parties)
- [6.1.5 Key sizes](#615-key-sizes)
- [6.1.6 Public key parameters generation and quality checking](#616-public-key-parameters-generation-and-quality-checking)
- [6.1.7 Key usage purposes (as per X.509 v3 key usage field)](#617-key-usage-purposes-as-per-x509-v3-key-usage-field)
- [6.2 Private Key Protection and Cryptographic Module Engineering Controls](#62-private-key-protection-and-cryptographic-module-engineering-controls)
- [6.2.1 Cryptographic module standards and controls](#621-cryptographic-module-standards-and-controls)
- [6.2.2 Private key (n out of m) multi-person control](#622-private-key-n-out-of-m-multi-person-control)
- [6.2.3 Private key escrow](#623-private-key-escrow)
- [6.2.4 Private key backup](#624-private-key-backup)
- [6.2.5 Private key archival](#625-private-key-archival)
- [6.2.6 Private key transfer into or from a cryptographic module](#626-private-key-transfer-into-or-from-a-cryptographic-module)
- [6.2.7 Private key storage on cryptographic module](#627-private-key-storage-on-cryptographic-module)
- [6.2.8 Activating Private Keys](#628-activating-private-keys)
- [6.2.9 Deactivating Private Keys](#629-deactivating-private-keys)
- [6.2.10 Destroying Private Keys](#6210-destroying-private-keys)
- [6.2.11 Cryptographic Module Rating](#6211-cryptographic-module-rating)
- [6.3 Other aspects of key pair management](#63-other-aspects-of-key-pair-management)
- [6.3.1 Public key archival](#631-public-key-archival)
- [6.3.2 Certificate operational periods and key pair usage periods](#632-certificate-operational-periods-and-key-pair-usage-periods)
- [6.4 Activation data](#64-activation-data)
- [6.4.1 Activation data generation and installation](#641-activation-data-generation-and-installation)
- [6.4.2 Activation data protection](#642-activation-data-protection)
- [6.4.3 Other aspects of activation data](#643-other-aspects-of-activation-data)
- [6.5 Computer security controls](#65-computer-security-controls)
- [6.5.1 Specific computer security technical requirements](#651-specific-computer-security-technical-requirements)
- [6.5.2 Computer security rating](#652-computer-security-rating)
- [6.6 Life cycle technical controls](#66-life-cycle-technical-controls)
- [6.6.1 System development controls](#661-system-development-controls)
- [6.6.2 Security management controls](#662-security-management-controls)
- [6.6.3 Life cycle security controls](#663-life-cycle-security-controls)
- [6.7 Network security controls](#67-network-security-controls)
- [6.8 Time-stamping](#68-time-stamping)
- [7. CERTIFICATE, CRL, AND OCSP PROFILES](#7-certificate-crl-and-ocsp-profiles)
- [7.1 Certificate profile](#71-certificate-profile)
- [7.1.1 Version number(s)](#711-version-numbers)
- [7.1.2 Certificate Content and Extensions](#712-certificate-content-and-extensions)
- [7.1.2.1 Root CA Certificate Profile](#7121-root-ca-certificate-profile)
- [7.1.2.2 Cross-Certified Subordinate CA Certificate Profile](#7122-cross-certified-subordinate-ca-certificate-profile)
- [7.1.2.3 Subordinate CA Certificate Profile](#7123-subordinate-ca-certificate-profile)
- [7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile](#7124-technically-constrained-precertificate-signing-ca-certificate-profile)
- [7.1.2.5 Technically Constrained TLS Subordinate CA Certificate Profile](#7125-technically-constrained-tls-subordinate-ca-certificate-profile)
- [7.1.2.6 TLS Subordinate CA Certificate Profile](#7126-tls-subordinate-ca-certificate-profile)
- [7.1.2.7 Subscriber Certificate Profile](#7127-subscriber-certificate-profile)
- [7.1.2.8 OCSP Responder Certificate Profile](#7128-ocsp-responder-certificate-profile)
- [7.1.2.8.1 OCSP Responder Validity](#71281-ocsp-responder-validity)
- [7.1.2.8.2 OCSP Responder Extensions](#71282-ocsp-responder-extensions)
- [7.1.2.8.3 OCSP Responder Authority Information Access](#71283-ocsp-responder-authority-information-access)
- [7.1.2.8.4 OCSP Responder Basic Constraints](#71284-ocsp-responder-basic-constraints)
- [7.1.2.8.5 OCSP Responder Extended Key Usage](#71285-ocsp-responder-extended-key-usage)
- [7.1.2.8.6 OCSP Responder id-pkix-ocsp-nocheck](#71286-ocsp-responder-id-pkix-ocsp-nocheck)
- [7.1.2.8.7 OCSP Responder Key Usage](#71287-ocsp-responder-key-usage)
- [7.1.2.8.8 OCSP Responder Certificate Policies](#71288-ocsp-responder-certificate-policies)
- [7.1.2.9 Precertificate Profile](#7129-precertificate-profile)
- [7.1.2.10 Common CA Fields](#71210-common-ca-fields)
- [7.1.2.10.1 CA Certificate Validity](#712101-ca-certificate-validity)
- [7.1.2.10.2 CA Certificate Naming](#712102-ca-certificate-naming)
- [7.1.2.10.3 CA Certificate Authority Information Access](#712103-ca-certificate-authority-information-access)
- [7.1.2.10.4 CA Certificate Basic Constraints](#712104-ca-certificate-basic-constraints)
- [7.1.2.10.5 CA Certificate Certificate Policies](#712105-ca-certificate-certificate-policies)
- [7.1.2.10.6 CA Certificate Extended Key Usage](#712106-ca-certificate-extended-key-usage)
- [7.1.2.10.7 CA Certificate Key Usage](#712107-ca-certificate-key-usage)
- [7.1.2.11 Common Certificate Fields](#71211-common-certificate-fields)
- [7.1.2.11.1 Authority Key Identifier](#712111-authority-key-identifier)
- [7.1.2.11.2 CRL Distribution Points](#712112-crl-distribution-points)
- [7.1.2.11.3 Signed Certificate Timestamp List](#712113-signed-certificate-timestamp-list)
- [7.1.2.11.4 Subject Key Identifier](#712114-subject-key-identifier)
- [7.1.2.11.5 Other Extensions](#712115-other-extensions)
- [7.1.3 Algorithm object identifiers](#713-algorithm-object-identifiers)
- [7.1.3.1 SubjectPublicKeyInfo](#7131-subjectpublickeyinfo)
- [7.1.3.1.1 RSA](#71311-rsa)
- [7.1.3.1.2 ECDSA](#71312-ecdsa)
- [7.1.3.2 Signature AlgorithmIdentifier](#7132-signature-algorithmidentifier)
- [7.1.3.2.1 RSA](#71321-rsa)
- [7.1.3.2.2 ECDSA](#71322-ecdsa)
- [7.1.4 Name Forms](#714-name-forms)
- [7.1.4.1 Name Encoding](#7141-name-encoding)
- [7.1.4.2 Subject Attribute Encoding](#7142-subject-attribute-encoding)
- [7.1.4.3 Subscriber Certificate Common Name Attribute](#7143-subscriber-certificate-common-name-attribute)
- [7.1.4.4 Other Subject Attributes](#7144-other-subject-attributes)
- [7.1.5 Name constraints](#715-name-constraints)
- [7.1.6 Certificate policy object identifier](#716-certificate-policy-object-identifier)
- [7.1.6.1 Reserved Certificate Policy Identifiers](#7161-reserved-certificate-policy-identifiers)
- [7.1.7 Usage of Policy Constraints extension](#717-usage-of-policy-constraints-extension)
- [7.1.8 Policy qualifiers syntax and semantics](#718-policy-qualifiers-syntax-and-semantics)
- [7.1.9 Processing semantics for the critical Certificate Policies extension](#719-processing-semantics-for-the-critical-certificate-policies-extension)
- [7.2 CRL profile](#72-crl-profile)
- [7.2.1 Version number(s)](#721-version-numbers)
- [7.2.2 CRL and CRL entry extensions](#722-crl-and-crl-entry-extensions)
- [7.2.2.1 CRL Issuing Distribution Point](#7221-crl-issuing-distribution-point)
- [7.3 OCSP profile](#73-ocsp-profile)
- [7.3.1 Version number(s)](#731-version-numbers)
- [7.3.2 OCSP extensions](#732-ocsp-extensions)
- [8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS](#8-compliance-audit-and-other-assessments)
- [8.1 Frequency or circumstances of assessment](#81-frequency-or-circumstances-of-assessment)
- [8.2 Identity/qualifications of assessor](#82-identityqualifications-of-assessor)
- [8.3 Assessor's relationship to assessed entity](#83-assessors-relationship-to-assessed-entity)
- [8.4 Topics covered by assessment](#84-topics-covered-by-assessment)
- [8.5 Actions taken as a result of deficiency](#85-actions-taken-as-a-result-of-deficiency)
- [8.6 Communication of results](#86-communication-of-results)
- [8.7 Self-Audits](#87-self-audits)
- [8.8 Review of delegated parties](#88-review-of-delegated-parties)
- [9. OTHER BUSINESS AND LEGAL MATTERS](#9-other-business-and-legal-matters)
- [9.1 Fees](#91-fees)
- [9.1.1 Certificate issuance or renewal fees](#911-certificate-issuance-or-renewal-fees)
- [9.1.2 Certificate access fees](#912-certificate-access-fees)
- [9.1.3 Revocation or status information access fees](#913-revocation-or-status-information-access-fees)
- [9.1.4 Fees for other services](#914-fees-for-other-services)
- [9.1.5 Refund policy](#915-refund-policy)
- [9.2 Financial responsibility](#92-financial-responsibility)
- [9.2.1 Insurance coverage](#921-insurance-coverage)
- [9.2.2 Other assets](#922-other-assets)
- [9.2.3 Insurance or warranty coverage for end-entities](#923-insurance-or-warranty-coverage-for-end-entities)
- [9.3 Confidentiality of business information](#93-confidentiality-of-business-information)
- [9.3.1 Scope of confidential information](#931-scope-of-confidential-information)
- [9.3.2 Information not within the scope of confidential information](#932-information-not-within-the-scope-of-confidential-information)
- [9.3.3 Responsibility to protect confidential information](#933-responsibility-to-protect-confidential-information)
- [9.4 Privacy of personal information](#94-privacy-of-personal-information)
- [9.4.1 Privacy plan](#941-privacy-plan)
- [9.4.2 Information treated as private](#942-information-treated-as-private)
- [9.4.3 Information not deemed private](#943-information-not-deemed-private)
- [9.4.4 Responsibility to protect private information](#944-responsibility-to-protect-private-information)
- [9.4.5 Notice and consent to use private information](#945-notice-and-consent-to-use-private-information)
- [9.4.6 Disclosure pursuant to judicial or administrative process](#946-disclosure-pursuant-to-judicial-or-administrative-process)
- [9.4.7 Other information disclosure circumstances](#947-other-information-disclosure-circumstances)
- [9.5 Intellectual property rights](#95-intellectual-property-rights)
- [9.6 Representations and warranties](#96-representations-and-warranties)
- [9.6.1 CA representations and warranties](#961-ca-representations-and-warranties)
- [9.6.2 RA representations and warranties](#962-ra-representations-and-warranties)
- [9.6.3 Subscriber representations and warranties](#963-subscriber-representations-and-warranties)
- [9.6.4 Relying party representations and warranties](#964-relying-party-representations-and-warranties)
- [9.6.5 Representations and warranties of other participants](#965-representations-and-warranties-of-other-participants)
- [9.7 Disclaimers of warranties](#97-disclaimers-of-warranties)
- [9.8 Limitations of liability](#98-limitations-of-liability)
- [9.9 Indemnities](#99-indemnities)
- [9.10 Term and termination](#910-term-and-termination)
- [9.10.1 Term](#9101-term)
- [9.10.2 Termination](#9102-termination)
- [9.10.3 Effect of termination and survival](#9103-effect-of-termination-and-survival)
- [9.11 Individual notices and communications with participants](#911-individual-notices-and-communications-with-participants)
- [9.12 Amendments](#912-amendments)
- [9.12.1 Procedure for amendment](#9121-procedure-for-amendment)
- [9.12.2 Notification mechanism and period](#9122-notification-mechanism-and-period)
- [9.12.3 Circumstances under which OID must be changed](#9123-circumstances-under-which-oid-must-be-changed)
- [9.13 Dispute resolution provisions](#913-dispute-resolution-provisions)
- [9.14 Governing law](#914-governing-law)
- [9.15 Compliance with applicable law](#915-compliance-with-applicable-law)
- [9.16 Miscellaneous provisions](#916-miscellaneous-provisions)
- [9.16.1 Entire agreement](#9161-entire-agreement)
- [9.16.2 Assignment](#9162-assignment)
- [9.16.3 Severability](#9163-severability)
- [9.16.4 Enforcement (attorneys' fees and waiver of rights)](#9164-enforcement-attorneys-fees-and-waiver-of-rights)
- [9.16.5 Force Majeure](#9165-force-majeure)
- [9.17 Other provisions](#917-other-provisions)
- [APPENDIX A – CAA Contact Tag](#appendix-a--caa-contact-tag)
- [A.1. CAA Methods](#a1-caa-methods)
- [A.1.1. CAA contactemail Property](#a11-caa-contactemail-property)
- [A.2. DNS TXT Methods](#a2-dns-txt-methods)
- [A.2.1. DNS TXT Record Email Contact](#a21-dns-txt-record-email-contact)
- [APPENDIX B – Certificate profile](#appendix-b--certificate-profile)
- [Table : "Security Communication RootCA2" and Subordinate CAs](#table--security-communication-rootca2-and-subordinate-cas)
- [Table : "Security Communication RootCA3" and Subordinate CAs](#table--security-communication-rootca3-and-subordinate-cas)
- [Table : "SECOM RSA Root CA 2023" and Subordinate CAs](#table--secom-rsa-root-ca-2023-and-subordinate-cas)
- [Table : "SECOM Document Signing RSA Root CA 2023" and Subordinate CAs](#table--secom-document-signing-rsa-root-ca-2023-and-subordinate-cas)
- [Table : "SECOM SMIME RSA Root CA 2024" and Subordinate CA](#table--secom-smime-rsa-root-ca-2024-and-subordinate-ca)
- [Table : Subscriber Certificates (Client Authentication Certificate and Document Signing Certificates)](#table--subscriber-certificates-client-authentication-certificate-and-document-signing-certificates)
- [Table : Subscriber Certificates (Code Signing Certificates, Not be issued after 2024-05-01)](#table--subscriber-certificates-code-signing-certificates-not-be-issued-after-2024-05-01)
- [Table: Subscriber Certificates (AATL Document Signing Certificates)](#table-subscriber-certificates-aatl-document-signing-certificates)
- [Table: Subscriber Certificates (S/MIME Certificates)](#table-subscriber-certificates-smime-certificates)
- [Table: Security Communication RootCA2 TSA, TA Certificates (Issued before 2018-09-26)](#table-security-communication-rootca2-tsa-ta-certificates-issued-before-2018-09-26)
- [Table: Security Communication RootCA3 TSA, TA Certificates (Issued before 2018-09-26)](#table-security-communication-rootca3-tsa-ta-certificates-issued-before-2018-09-26)
- [Table: Security Communication RootCA3 TimeStamping Subordinate CA Certificates (Issued after 2018-06-07)](#table-security-communication-rootca3-timestamping-subordinate-ca-certificates-issued-after-2018-06-07)
- [Table: SECOM TimeStamping CA2 TSA, TA Certificates](#table-secom-timestamping-ca2-tsa-ta-certificates)
- [Table: SECOM TimeStamping CA3 TSA, TA Certificates](#table-secom-timestamping-ca3-tsa-ta-certificates)
- [Table: SECOM TimeStamping CA4 TSA Certificates (Not issued after 2025-04-15)](#table-secom-timestamping-ca4-tsa-certificates-not-issued-after-2025-04-15)
- [Table: SECOM TimeStamping Service TSA Certificates](#table-secom-timestamping-service-tsa-certificates)
# 1. INTRODUCTION
## 1.1 Overview
This Certificate Policy/Certification Practice Statement (hereinafter, "CP/CPS") shall indicate the purpose of use, scope of application, and user procedures for certificates operated by SECOM Trust Systems CO., LTD. (hereinafter, "SECOM Trust Systems"), and stipulate policies concerning the certificates.
SECOM Trust Systems provides the certification services as the CAs, including the CA key administration as well as issuance/revocation of Certificates (hereinafter, "the Services").
This CP/CPS shall be revised as necessary in order to reflect any technical or operational developments or improvements pertaining to the CA.
This CP/CPS conforms to the RFC3647 "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework" advocated by the IETF as a CA practice framework”.
This CP/CPS complies with [CCADB Policy](https://www.ccadb.org/policy), the CA MUST provide at least an authoritative English version of CP/CPS which are not originally in English, with version numbers matching the document they are a translation of. The Japanese version of the CP/CPS should be written with the Japanese section name under the English section name.
### 1.1.1 Standards, Criteria and Regulations
The CA shall comply with the latest versions of the Standards, Criteria, and Regulations established by the CA/Browser Forum, as well as the Application Software Supplier.
See [Section 8.4](#84-topics-covered-by-assessment) for the audit scheme that CAs must follow.
Table: Standards, Criteria and Regulations List
| Types of certificates issued by subordinate CAs | Standards, Criteria and Regulations to comply with |
| ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| S/MIME Certificates | [Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates](https://cabforum.org/smime-br/) (hereinafter, "S/MIME Baseline Requirements")
[Apple Root Certificate Program](https://www.apple.com/certificateauthority/ca_program.html)
[Microsoft Trusted Root Program](https://aka.ms/RootCert)
[Mozilla Root Store Policy](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/) |
| Code Signing Certificates, Timestamp Certificates for Code Signing Certificates | [Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates](https://cabforum.org/working-groups/code-signing/requirements/) (hereinafter, "Baseline Requirements for Code Signing Certificates")
[Microsoft Trusted Root Program](https://aka.ms/RootCert) |
| AATL Document Signing Certificates, AATL Timestamp Certificates | [Adobe Approved Trust List Technical Requirements](https://helpx.adobe.com/acrobat/kb/approved-trust-list2.html) (hereinafter, "AATL Technical Requirements") |
| Microsoft Document Signing Certificates | [Microsoft Trusted Root Program](https://aka.ms/RootCert) |
\* AATL Document Signing Certificates and Microsoft Document Signing Certificates are collectively referred to as "Document Signing Certificates".
\* Timestamp Certificates for Code Signing Certificates and AATL Timestamp Certificates are collectively referred to as "Timestamp Certificates".
The CA may outsource the part of the certification work to an external business operator that complies with 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)
| Name of organization | OID |
| -------------------- | -------------- |
| SECOM Trust Systems | 1.2.392.200091 |
---
OID used when issuing a subordinate CA certificate from the Root CA
Table: OID (Root CA CP)
| CP | OID |
| --------------------------------------------------------- | ------------------------- |
| Security Communication RootCA2 Subordinate CA CP | 1.2.392.200091.100.901.4 |
| Security Communication RootCA2 Time-Stamp Service CP | 1.2.392.200091.100.901.5 |
| Security Communication RootCA3 Subordinate CA CP | 1.2.392.200091.100.901.6 |
| Security Communication RootCA3 Time-Stamp Service CP | 1.2.392.200091.100.901.7 |
| SECOM RSA Root CA 2023 Subordinate CA CP | 1.2.392.200091.100.901.9 |
| SECOM Document Signing RSA Root CA 2023 Subordinate CA CP | 1.2.392.200091.100.901.10 |
| SECOM SMIME RSA Root CA 2024 Subordinate CA CP | 1.2.392.200091.100.901.12 |
---
OID used when issuing EE certificates from a subordinate CA
Table: OID（Subordinate CA CP）
| CP | OID |
| ----------------------------------------------------------------------------- | ------------------------ |
| Client Certificate Policy (SHA1)
(Client Authentication Certificates) | 1.2.392.200091.100.381.1 |
| Certificate Policy for Data Signing (SHA1)
(Document Signing Certificates) | 1.2.392.200091.100.381.2 |
| Client Certificate Policy
(Client Authentication Certificates) | 1.2.392.200091.100.381.4 |
| Certificate Policy for Data Signing
(Document Signing Certificates) | 1.2.392.200091.100.381.5 |
| Certificate Policy for Code Signing (SHA256) | 1.2.392.200091.100.381.8 |
| Certificate Policy for AATL Document Signing | 1.2.392.200091.100.382.1 |
| Certificate Policy for S/MIME | 1.2.392.200091.100.383.1 |
| SECOM TimeStamping CA2 | 1.2.392.200091.100.931.1 |
| SECOM TimeStamping CA3 | 1.2.392.200091.100.931.3 |
| SECOM TimeStamping CA4 | 1.2.392.200091.100.931.4 |
| SECOM TimeStamping Service | 1.2.392.200091.100.931.5 |
---
See [Section 7.1.6.1 Reserved Certificate Policy Identifiers](#7161-reserved-certificate-policy-identifiers).
### 1.2.1 Revisions
| **Ver.** | **Date** | **Description** |
| -------- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1.00 | 2025-05-26 | Publication of the first version. |
| 1.01 | 2025-06-17 | Updated notation and sections below.
[Section 4.2.1](#421-performing-identification-and-authentication-functions)
[Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods)
[APPENDIX B – Certificate profile](#appendix-b--certificate-profile) |
| 1.02 | 2025-10-22 | Removed all TLS server certificate content from this CP/CPS and moved it to the ["SECOM Publicly Trusted TLS Server Authentication Certificate Policy/Certification Practice Statement."](https://repo1.secomtrust.net/spcpp/publicly-trusted-cpcps/) |
## 1.3 PKI Participants
### 1.3.1 Certification Authorities
Certification Authority (CA) is an organization that is responsible for the creation, issuance, revocation, and management of Certificates. CA publishes CRLs (Certificate Revocation Lists) and stores and provides information on Certificate status using the OCSP responder.
Certification Authority (CA) is defined in [Section 1.6](#16-definitions-and-acronyms).
### 1.3.2 Registration Authorities
**[S/MIME Certificates]**
With the exception of [Section 3.2.2](#322-authentication-of-organization-and-domain-identity), the CA MAY delegate the performance of all, or any part, of [Section 3.2](#32-initial-identity-validation) requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of [Section 3.2](#32-initial-identity-validation).
Before the CA authorizes a Delegated Third Party to perform a delegated function, the CA SHALL contractually require the Delegated Third Party to:
1. Meet the qualification requirements of [Section 5.3.1](#531-qualifications-experience-and-clearance-requirements), when applicable to the delegated function;
2. Retain documentation in accordance with [Section 5.5.2](#552-retention-period-for-archive);
3. Abide by the other provisions of 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](#32211-validating-authority-over-mailbox-via-domain-smime-certificates) or [Section 3.2.2.1.3](#32213-validating-applicant-as-operator-of-associated-mail-servers-smime-certificates).
The CA SHALL impose these limitations as a contractual requirement on the Enterprise RA and monitor compliance by the Enterprise RA in accordance with [Section 8.8](#88-review-of-delegated-parties).
An Enterprise RA MAY also submit Certificate Requests using the `Mailbox-validated` profile for users whose email domain(s) are not under the delegated organization’s authorization or control. In this case, the CA SHALL confirm that the mailbox holder has control of the requested Mailbox Address(es) in accordance with [Section 3.2.2.1.2](#32212-validating-control-over-mailbox-via-email-smime-certificates).
### 1.3.3 Subscribers
Subscribers shall be any natural person or Legal Entity that receive a Certificate issued by the CA and conforms to the Subscriber Agreement or Term of Use.
Subscribers generate Key Pairs in their own rights, to which Certificates are issued by the CAs. They are qualified as Subscribers upon accepting the issued Certificates after submitting the Certificate applications to the CAs. Subscribers must assess Section in light of their usage purposes, and agree thereto.
### 1.3.4 Relying Parties
Relying Party is any natural person or Legal Entity that relies on a Valid Certificate. An Application Software Supplier is not considered a Relying Party when software distributed by such Supplier merely displays information relating to a Certificate.
Relying Parties are the entities that authenticate the validity of Certificates issued by the CAs. Relying Parts are assumed to be performing the authentication and placing trust upon confirming and agreeing to the contents of Section in light of the Relying Parties' own purposes of use.
"Relying Party" and "Application Software Supplier" are defined in [Section 1.6.1](#161-definitions). Current Members of the CA/Browser Forum who are Application Software Suppliers are listed here:
.
### 1.3.5 Other Participants
Other groups include auditors, and companies or organizations that have service contracts with SECOM Trust Systems, and companies that perform system integration.
## 1.4 Certificate Usage
### 1.4.1 Appropriate Certificate Uses
The CAs are the Certification Authorities functioning as top of the Subordinate CAs and issue Subordinate CA Certificates as Subscriber Certificates. Relying Parties that trust and use the Certificates may authenticate the reliability of such Certificates using the CA public key Certificates.
### 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:
| Contact Information | CA Support Center, SECOM Trust Systems |
| ------------------- | ------------------------------------------------ |
| Address | 8-10-16 Shimorenjaku, Mitaka-shi, Tokyo 181-8528 |
| Inquiry details | Inquiries for this CP/CPS / Except for Certificate Problem Report |
| --------------- | ------------------------------------------------------------------------------------------------ |
| Email | ca-support [at] secom [dot] co [dot] jp |
| Business hours | 9:00-18:00, except on Saturdays, Sundays, national holidays, and year-end and New Year holidays. |
The Subscribers, Relying Parties, Application Software Suppliers, and other third parties can report suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA revokes certificates when it is determined that it needs to be revoked.
| Inquiry details | Certificate Problem Report |
| --------------- | ------------------------------------------------------- |
| URL | |
| Business hours | 24x7 |
### 1.5.3 Person Determining CPS suitability for the policy
The Certification Services Improvement Committee (hereinafter, "this Committee") determines the suitability of the contents of this CP/CPS. This CP/CPS shall be reviewed and revised at least annually.
### 1.5.4 CPS approval procedures
This CP/CPS shall be published in the repository as developed and revised under approval of 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](#81-frequency-or-circumstances-of-assessment).
**Audit Report**: A report from a Qualified Auditor stating the Qualified Auditor's opinion on whether an entity's processes and controls comply with the mandatory provisions of Baseline Requirements.
**Authorization Domain Name**: The FQDN used to obtain authorization for a given FQDN to be included in a Certificate. The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. If a Wildcard Domain Name is to be included in a Certificate, then the CA MUST remove "`*.`" from the left-most portion of the Wildcard Domain Name to yield the corresponding FQDN. The CA may prune zero or more Domain Labels of the FQDN from left to right until encountering a Base Domain Name and may use any one of the values that were yielded by pruning (including the Base Domain Name itself) for the purpose of domain validation.
**Authorized Ports**: One of the following ports: 80 (http), 443 (https), 25 (smtp), 22 (ssh).
**Baseline Requirements**: A document issued by the CA/Browser Forum (available at cabforum.org.) that integrates a set of fundamental requirements for Certificate issuance/administration.
**Business Entity**: Any entity that is not a Private Organization, Government Entity, or Non-Commercial Entity as defined herein. Examples include, but are not limited to, general partnerships, unincorporated associations, sole proprietorships, etc.
**CAA**: From RFC 8659 (): "The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue."
**CA/Browser Forum**: An NPO organized by CAs and Internet browser vendors that works to define and standardize the Certificate issuance requirements.
**CA Key Pair**: A Key Pair where the Public Key appears as the Subject Public Key Info in one or more Root CA Certificate(s) and/or Subordinate CA Certificate(s).
**Certificate**: An electronic document that uses a digital signature to bind a public key and an identity.
**Certificate Data**: Certificate requests and data related thereto (whether obtained from the Applicant or otherwise) in the CA's possession or control or to which the CA has access.
**Certificate Management Process**: Processes, practices, and procedures associated with the use of keys, software, and hardware, by which the CA verifies Certificate Data, issues Certificates, maintains a Repository, and revokes Certificates.
**Certificate Policy (CP)**: A set of rules that indicates the applicability of a named Certificate to a particular community and/or PKI implementation with common security requirements.
**Certificate Problem Report**: Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.
**Certificate Profile**: A set of documents or files that defines requirements for Certificate content and Certificate extensions in accordance with [Section 7](#7-certificate-crl-and-ocsp-profiles), e.g. a Section in a CA’s CPS or a certificate template file used by CA software.
**Certificate Requester**: A natural person who is either the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or a third party (such as an ISP or hosting company) that completes and submits an EV Certificate Request on behalf of the Applicant.
**Certificate Revocation List (CRL)**: A regularly updated time-stamped list of revoked Certificates that is created and digitally signed by the CA that issued the Certificates.
**Certificate Signing Request (CSR)**: CSR stands for Certificate Signing Request, a data file on which the digital certificate issuance is based. A CSR contains the public key of the entity requesting the Certificate signing, to which the issuer's digital signature is affixed upon the issuance thereof.
**Certificate Transparency (CT)**: Certificate Transparency, stipulated in RFC 6962, is an open framework for monitoring/auditing the records of the issued Certificates by registering and publishing them on the log servers.
**Certification Authority (CA)**: An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Root CAs and Subordinate CAs.
**Certification Practice Statement**: One of several documents forming the governance framework in which Certificates are created, issued, managed, and used.
**Certification Services Improvement Committee**: The decision-making body for the operational policy of the Services, including administration of this CP/CPS and modification reviews.
**Code**: A contiguous set of bits that has been or can be digitally signed with a Private Key that corresponds to a Code Signing Certificate.
**Code Signature:** A Signature logically associated with a signed Code.
**Code Signing Certificate:** A digital certificate issued by a CA that contains a Code Signing EKU.
**Confirmation Request**: An appropriate out-of-band communication requesting verification or confirmation of the particular fact at issue.
**Confirming Person**: A position within an Applicant's organization that confirms the particular fact at issue.
**Contract Signer**: A natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements.
**Control**: "Control" (and its correlative meanings, "controlled by" and "under common control with") means possession, directly or indirectly, of the power to: (1) direct the management, personnel, finances, or plans of such entity; (2) control the election of a majority of the directors ; or (3) vote that portion of voting shares required for "control" under the law of the entity's Jurisdiction of Incorporation or Registration but in no case less than 10%.
**Country**: Either a member of the United Nations OR a geographic region recognized as a Sovereign State by at least two UN member nations.
**Cross-Certified Subordinate CA Certificate**: A certificate that is used to establish a trust relationship between two CAs.
**CSPRNG**: A random number generator intended for use in a cryptographic system.
**Delegated Third Party**: A natural person or Legal Entity that is not the CA but is authorized by the CA, and whose activities are not within the scope of the appropriate CA audits, to assist in the Certificate Management Process by performing or fulfilling one or more of the CA requirements found herein.
**Digital Certification Infrastructure**: A platform for operating the CA of SECOM Trust Systems and of the users of the Private CA users.
**DNS CAA Email Contact**: The email address defined in [Appendix A.1.1](#a11-caa-contactemail-property).
**DNS TXT Record Email Contact**: The email address defined in [Appendix A.2.1](#a21-dns-txt-record-email-contact).
**Domain Contact**: The Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record, or as obtained through direct contact with the Domain Name Registrar.
**Domain Label**: From RFC 8499 (): "An ordered list of zero or more octets that makes up a portion of a domain name. Using graph theory, a label identifies one node in a portion of the graph of all possible domain names."
**Domain Name**: An ordered list of one or more Domain Labels assigned to a node in the Domain Name System.
**Domain Namespace**: The set of all possible Domain Names that are subordinate to a single node in the Domain Name System.
**Domain Name Registrant**: Sometimes referred to as the "owner" of a Domain Name, but more properly the person(s) or entity(ies) registered with a Domain Name Registrar as having the right to control how a Domain Name is used, such as the natural person or Legal Entity that is listed as the "Registrant" by WHOIS or the Domain Name Registrar.
**Domain Name Registrar**: A person or entity that registers Domain Names under the auspices of or by agreement with:
i. the Internet Corporation for Assigned Names and Numbers (ICANN),
ii. a national Domain Name authority/registry, or
iii. a Network Information Center (including their affiliates, contractors, delegates, successors, or assignees).
**Enterprise RA**: An employee or agent of an organization unaffiliated with the CA who authorizes issuance of Certificates to that organization.
**Escrow**: Escrow means the placement (entrustment) of an asset in the control of an independent third party.
**Expiry Date**: The "Not After" date in a Certificate that defines the end of a Certificate's validity period.
**FIPS140**: The security certification standards developed by the U.S. NIST (National Institute of Standards and Technology) for cryptographic modules.
**HSM (Hardware Security Module)**: The hardware that works as a protecting safe to store private keys used for encryption and digital signing. An HSM computes encryption and digital signing as well as generates private keys and random digits.
**Fully-Qualified Domain Name**: A Domain Name that includes the Domain Labels of all superior nodes in the Internet Domain Name System.
**Government Agency**: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of Private Organizations is established (e.g., the government agency that issued the Certificate of Incorporation). In the context of Business Entities, the government agency in the jurisdiction of operation that registers business entities. In the case of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities.
**Government Entity**: A government-operated legal entity, agency, department, ministry, branch, or similar element of the government of a country, or political subdivision within such country (such as a state, province, city, county, etc.).
**High Risk Certificate Request**: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that the CA identifies using its own risk-mitigation criteria.
**Incorporating Agency**: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of the entity is registered (e.g., the government agency that issues certificates of formation or incorporation). In the context of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities.
**Independent Confirmation From Applicant**: Confirmation of a particular fact received by the CA pursuant to the provisions of the EV Guidelines or binding upon the Applicant.
**Internal Name**: A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA's Root Zone Database.
**Individual**: A natural person.
**INAN (Internet Assigned Numbers Authority)**: The organization that globally manages information related to the Internet, such as IP addresses and port numbers.
**International Organization**: An organization founded by a constituent document, e.g., a charter, treaty, convention or similar document, signed by, or on behalf of, a minimum of two Sovereign State governments.
**Issuing Authority (IA)**: An entity which, of the duties of a CA, mainly handles the issuance/ renewal/ revocation of Certificates, generation and protection of CA private keys, and the maintenance and management of repositories.
**IP Address**: A 32-bit or 128-bit number assigned to a device that uses the Internet Protocol for communication.
**IP Address Contact**: The person(s) or entity(ies) registered with an IP Address Registration Authority as having the right to control how one or more IP Addresses are used.
**IP Address Registration Authority**: The Internet Assigned Numbers Authority (IANA) or a Regional Internet Registry (RIPE, APNIC, ARIN, AfriNIC, LACNIC).
**Issuing CA**: In relation to a particular Certificate, the CA that issued the Certificate. This could be either a Root CA or a Subordinate CA.
**Key Compromise**: A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it.
**Key Generation Script**: A documented plan of procedures for the generation of a CA Key Pair.
**Key Pair**: The Private Key and its associated Public Key.
**LDH Label**: From RFC 5890 (): "A string consisting of ASCII letters, digits, and the hyphen with the further restriction that the hyphen cannot appear at the beginning or end of the string. Like all DNS labels, its total length must not exceed 63 octets."
**Legal Entity**: An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a country's legal system.
**Legal Existence**: A Private Organization, Government Entity, or Business Entity has Legal Existence if it has been validly formed and not otherwise terminated, dissolved, or abandoned.
**Legal Practitioner**: A person who is either a lawyer or a Latin Notary as described in these Guidelines and competent to render an opinion on factual claims of the Applicant.
**Linting**: A process in which the content of digitally signed data such as a Precertificate [RFC 6962], Certificate, Certificate Revocation List, or OCSP response, or data-to-be-signed object such as a `tbsCertificate` (as described in [RFC 5280, Section 4.1.1.1](https://tools.ietf.org/doc/html/rfc5280##section-4.1.1.1)) is checked for conformance with the profiles and requirements defined in 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 (): "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](#82-identityqualifications-of-assessor).
**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 ): "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 (): "The class of labels that begin with the prefix `"xn--"` (case independent), but otherwise conform to the rules for LDH labels."
**X.500**: A series of computer network standards regarding the decentralized directory service.
**X.509**: X.509 ITU-T certificate and CRL format. In X.509 v3 (Version 3), an extension area for holding arbitrary information has been added.
### 1.6.2 Acronyms
| **Acronym** | **Meaning** |
| ----------- | -------------------------------------------------------------- |
| AICPA | American Institute of Certified Public Accountants |
| ADN | Authorization Domain Name |
| CA | Certification Authority |
| CAA | Certification Authority Authorization |
| ccTLD | Country Code Top-Level Domain |
| CICA | Canadian Institute of Chartered Accountants |
| CP | Certificate Policy |
| CPS | Certification Practice Statement |
| CRL | Certificate Revocation List |
| DBA | Doing Business As |
| DNS | Domain Name System |
| FIPS | (US Government) Federal Information Processing Standard |
| FQDN | Fully-Qualified Domain Name |
| IM | Instant Messaging |
| IANA | Internet Assigned Numbers Authority |
| ICANN | Internet Corporation for Assigned Names and Numbers |
| ISO | International Organization for Standardization |
| NIST | (US Government) National Institute of Standards and Technology |
| OCSP | Online Certificate Status Protocol |
| OID | Object Identifier |
| PKI | Public Key Infrastructure |
| RA | Registration Authority |
| S/MIME | Secure MIME (Multipurpose Internet Mail Extensions) |
| SSL | Secure Sockets Layer |
| TLS | Transport Layer Security |
| VoIP | Voice Over Internet Protocol |
### 1.6.3 References
See [Section 1.1](#11-overview)
### 1.6.4 Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 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](#111-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 . 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](#111-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](#311-types-of-names) and [Section 3.1.2](#312-need-for-names-to-be-meaningful) hereof.
Rules concerning the interpretation of various name forms are governed by the X.500 Series DN rules.
### 3.1.5 Uniqueness of names
The CA guarantees that the issued certificate can uniquely identify the owner of the certificate by the information contained in the identification name of the Subject. The serial number of the certificate shall be the serial number including the random number generated by CSPRNG. The serial number assigned in the CA is unique.
### 3.1.6 Recognition, authentication, and role of trademarks
The CA does not verify intellectual property rights for the names indicated in Certificate applications. Subscribers may not submit any registered trademark or other trademark-related names of a third party. The CA will not arbitrate or engage itself in the resolution of any dispute between Subscribers and third parties over the registered trademark or any alike. The CA reserves the right to reject a Subscriber Certificate Application or revoke an issued Certificate due to the dispute.
## 3.2 Initial identity validation
### 3.2.1 Method to prove possession of private key
A Subscriber proves possession of the relevant Private Key in accordance with the following method.
The signature on the relevant Certificate Signing Request (hereinafter, "CSR") is authenticated to prove that said CSR is signed with the Private Key corresponding to the Public Key.
### 3.2.2 Authentication of Organization and Domain Identity
If the Applicant requests a Certificate that will contain Subject Identity Information comprised only of the `countryName` field, then the CA SHALL verify the country associated with the Subject using a verification process meeting the requirements of [Section 3.2.2.3](#3223-verification-of-country). If the Applicant requests a Certificate that will contain the countryName field and other Subject Identity Information, then the CA SHALL verify the identity of the Applicant, and the authenticity of the Applicant Representative's certificate request using a verification process meeting the requirements of this [Section 3.2.2.1](#3221-identity). The CA SHALL inspect any document relied upon under this Section for alteration or falsification.
**[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](#421-performing-identification-and-authentication-functions)) 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](https://github.com/cabforum/servercert/blob/main/docs/BR.md#3224-validation-of-domain-authorization-or-control) to perform this verification.
For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate.
##### 3.2.2.1.2 Validating control over mailbox via email (S/MIME Certificates)
The CA MAY confirm the Applicant's control over each Mailbox Field to be included in a Certificate by sending a Random Value via email and then receiving a confirming response utilizing the Random Value.
Control over each Mailbox Address SHALL be confirmed using a unique Random Value. The Random Value SHALL be sent only to the email address being validated and SHALL not be shared in any other way.
The Random Value SHALL be unique in each email. The Random Value SHALL remain valid for use in a confirming response for no more than 24 hours from its creation. The CA MAY specify a shorter validity period for Random Values in its CP and/or CPS.
The Random Value SHALL be reset upon each instance of the email sent by the CA to a Mailbox Address, however all relevant Random Values sent to that Mailbox Address MAY remain valid for use in a confirming response within the validity period described in this Section. In addition, the Random Value SHALL be reset upon first use by the user if intended for additional use as an authentication factor following the Mailbox Address verification.
##### 3.2.2.1.3 Validating applicant as operator of associated mail server(s) (S/MIME Certificates)
The CA MAY confirm the Applicant's control over each Mailbox Field to be included in the Certificate by confirming control of the SMTP FQDN to which a message delivered to the Mailbox Address should be directed. The SMTP FQDN SHALL be identified using the address resolution algorithm defined in [RFC 5321 Section 5.1](https://datatracker.ietf.org/doc/html/rfc5321#section-5.1) which determines which SMTP FQDNs are authoritative for a given Mailbox Address. If more than one SMTP FQDN has been discovered, the CA SHALL verify control of an SMTP FQDN following the selection process at [RFC 5321 Section 5.1](https://datatracker.ietf.org/doc/html/rfc5321#section-5.1). Aliases in MX record RDATA SHALL NOT be used for this validation method.
To confirm the Applicant's control of the SMTP FQDN, the CA SHALL use only the currently-approved methods in [Section 3.2.2.4 of the TLS Baseline Requirements](https://github.com/cabforum/servercert/blob/main/docs/BR.md#3224-validation-of-domain-authorization-or-control).
#### 3.2.2.2 DBA/Tradename
If the Subject Identity Information is to include a DBA or tradename, the CA SHALL verify the Applicant's right to use the DBA/tradename using at least one of the following:
1. Documentation provided by, or communication with, a government agency in the jurisdiction of the Applicant's legal creation, existence, or recognition;
2. A Reliable Data Source;
3. Communication with a government agency responsible for the management of such DBAs or trade names;
4. An Attestation Letter accompanied by documentary support; or
5. A utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.
#### 3.2.2.3 Verification of Country
If the `subject:countryName` field is present, then the CA SHALL verify the country associated with the Subject using one of the following:
a. the ccTLD of the requested Domain Name;
b. information provided by the Domain Name Registrar; or
c. a method identified in [Section 3.2.2.1](#3221-identity).
### 3.2.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;
1. An address of the Legal Entity (if included in the Subject);
1. Jurisdiction of Incorporation or Registration of the Legal Entity; and
### 3.2.4 Non-verified subscriber information
The information about non-verified certificate subscribers will not be included in the certificates issued by the CA.
### 3.2.5 Validation of authority
If the Applicant for a Certificate containing Subject Identity Information is an organization, the CA SHALL use a Reliable Method of Communication to verify the authenticity of the Applicant Representative's certificate request.
The CA MAY use the sources listed in [Section 3.2.2.1](#3221-identity) to verify the Reliable Method of Communication. Provided that the CA uses a Reliable Method of Communication, the CA MAY establish the authenticity of the certificate request directly with the Applicant Representative or with an authoritative source within the Applicant's organization, such as the Applicant's main business offices, corporate offices, human resource offices, information technology offices, or other department that the CA deems appropriate.
In addition, the CA SHALL establish a process that allows an Applicant to specify the individuals who may request Certificates. If an Applicant specifies, in writing, the individuals who may request a Certificate, then the CA SHALL NOT accept any certificate requests that are outside this specification. The CA SHALL provide an Applicant with a list of its authorized certificate requesters upon the Applicant's verified written request.
**[S/MIME Certificates]**
The CA or RA SHALL use a Reliable Method of Communication to verify the authority and approval of an Applicant Representative to perform one or more of the following:
- to act as an Enterprise RA;
- to request issuance or revocation of Certificates; or
- to assign responsibilities to others to act in these roles.
The CA or RA MAY establish a process that allows an Applicant to specify the individuals who may act as Applicant Representatives on an ongoing basis. The CA SHALL provide an Applicant with a list of its authorized Applicant Representatives upon the Applicant's verified written request.
The CA or RA MAY use the sources listed in [Section 3.2.3.1](#3231-attribute-collection-of-organization-identity-smime-certificates) to verify the Reliable Method of Communication. Provided that the CA or RA uses a Reliable Method of Communication, the CA or RA MAY establish the authenticity of the Certificate Request directly with the Applicant Representative or with an authoritative source within the Applicant's organization, such as the Applicant's main business offices, corporate offices, human resource offices, information technology offices, or other department that the CA or RA deems appropriate.
### 3.2.6 Criteria for Interoperation or Certification
The CA SHALL disclose all Cross-Certified Subordinate CA Certificates that identify the CA as the Subject, provided that the CA arranged for or accepted the establishment of the trust relationship (i.e. the Cross-Certified Subordinate CA Certificate at issue).
## 3.3 Identification and authentication for re-key requests
### 3.3.1 Identification and authentication for routine re-key
Subscribers shall be identified and authenticated for Re-Keying in the same manner as set forth in [Section 3.2](#32-initial-identity-validation) hereof.
### 3.3.2 Identification and authentication for re-key after revocation
A routine Re-Key after Revocation is not supported. The (Re-Keying) application for a Certificate shall be treated as a new submission, and the applicant Subscriber shall be identified and authenticated in the same manner as set forth in [Section 3.2](#32-initial-identity-validation) hereof.
## 3.4 Identification and authentication for revocation request
Accepting the revocation request from the Subscriber or the applicant according to the prescribed procedure, the CA identifies and authenticates the Subscriber.
# 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
## 4.1 Certificate Application
### 4.1.1 Who can submit a certificate application
A person who may submit a certificate application shall be individuals, corporations, other organizations that use certificates, and agents delegated by certificate subscribers (hereinafter referred to as "Applicant").
In accordance with [Section 5.5.2](#552-retention-period-for-archive), the CA SHALL maintain an internal database of all previously revoked Certificates and previously rejected certificate requests due to suspected phishing or other fraudulent usage or concerns. The CA SHALL use this information to identify subsequent suspicious certificate requests.
**[S/MIME Certificates, Document Signing Certificates and Client Authentication Certificates]**
An application for the CA can be made by an LRA and organization that has been certified by SECOM Trust Systems based on
[Section 3.2.2](#322-authentication-of-organization-and-domain-identity).
Applications for LRA can be made by persons specified by LRA based on the LRA operational standards.
### 4.1.2 Enrollment process and responsibilities
Prior to the issuance of a Certificate, the CA SHALL obtain the following documentation from the Applicant:
1. A certificate request, which may be electronic; and
2. An executed Subscriber Agreement or Terms of Use, which may be electronic.
The CA SHOULD obtain any additional documentation the CA determines necessary to meet [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations).
Prior to the issuance of a Certificate, the CA SHALL obtain from the Applicant a certificate request in a form prescribed by the CA and that complies with [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations). One certificate request MAY suffice for multiple Certificates to be issued to the same Applicant, subject to the aging and updating requirement in [Section 4.2.1](#421-performing-identification-and-authentication-functions), provided that each Certificate is supported by a valid, current certificate request signed by the appropriate Applicant Representative on behalf of the Applicant. The certificate request MAY be made, submitted and/or signed electronically.
The certificate request MUST contain a request from, or on behalf of, the Applicant for the issuance of a Certificate, and a certification by, or on behalf of, the Applicant that all of the information contained therein is correct.
**[S/MIME Certificates]**
Prior to the issuance of a Certificate, the CA SHALL obtain the following documentation from the Applicant:
1. A Certificate Request; and
2. An executed Subscriber Agreement and/or Terms of Use.
The Certificate Request and Subscriber Agreement or Terms of Use SHALL be in a form prescribed by the CA and SHALL comply with these Requirements including [Section 9.6.3](#963-subscriber-representations-and-warranties). The CA SHOULD obtain any additional documentation the CA determines necessary to fulfill these Requirements.
The Certificate Request SHALL contain a request from, or on behalf of, the Applicant for the issuance of a Certificate, and a certification by, or on behalf of, the Applicant that all of the information contained therein is correct.
One Certificate Request MAY suffice for multiple Certificates to be issued to the same Applicant, subject to the validation reuse periods described in [Section 4.2.1](#421-performing-identification-and-authentication-functions), provided that each Certificate is supported by a valid, current Certificate Request signed by the appropriate Applicant Representative on behalf of the Applicant.
A CA may rely on a previously verified Certificate Request to issue a replacement Certificate if:
1. The previous Certificate being referenced was not revoked;
2. The expiration date of the replacement Certificate is the same as the previous Certificate being referenced; and
3. The Subject Information of the Certificate is the same as the previous Certificate being referenced.
## 4.2 Certificate application processing
### 4.2.1 Performing identification and authentication functions
SECOM Trust Systems performs identity verification and authentication of the LRA or the organization in accordance with [Section 3.2](#32-initial-identity-validation). In applying for a certificate accepted from the LRA, the certificate presented by the LRA is verified and authenticated for the identity of the LRA.
The LRA performs identity verification and authentication based on the LRA operational standards in the manner determined by the LRA.
**[S/MIME Certificates]**
Applicant information SHALL include, but not be limited to, at least one Mailbox Field to be included in the Certificate's `subjectAltName` extension.
[Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) limits the validity period of Subscriber Certificates.
The CA MAY reuse completed validations and/or supporting evidence performed in accordance with [Section 3.2](#32-initial-identity-validation) within the following limits:
1. **Validation of mailbox authorization or control**: Completed validation of the control of a mail server in accordance with [Section 3.2.2.1.1](#32211-validating-authority-over-mailbox-via-domain-smime-certificates) or [Section 3.2.2.1.3](#32213-validating-applicant-as-operator-of-associated-mail-servers-smime-certificates) SHALL be obtained no more than 398 days prior to issuing the Certificate.
In the event of changes to the TLS Baseline Requirements methods specified in [Section 3.2.2.1.1](#32211-validating-authority-over-mailbox-via-domain-smime-certificates), a CA MAY continue to reuse completed validations and/or supporting evidence for the period stated in this section.
Completed validation of control of a mailbox in accordance with [Section 3.2.2.1.2](#32212-validating-control-over-mailbox-via-email-smime-certificates) SHALL be obtained no more than 30 days prior to issuing the Certificate.
A prior validation SHALL NOT be reused if any data or document used in the prior validation was obtained more than the maximum time permitted for reuse of the data or document prior to issuing the Certificate.
**[Document Signing Certificate and Timestamp Certificates]**
The CA MAY reuse completed validations and/or supporting evidence performed in accordance with [Section 3.2](#32-initial-identity-validation) within the following limits:
The validation SHALL be obtained no more than 398 days prior to issuing the Certificate.
**[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](https://www.rfc-editor.org/rfc/rfc9495.html).
Starting on March 15, 2025 prior to issuing a Certificate that includes a Mailbox Address, the CA SHALL retrieve and process CAA records in accordance with Section 4 of [RFC 9495: Certification Authority Authorization (CAA) Processing for Email Addresses](https://www.rfc-editor.org/rfc/rfc9495.html).
Some methods relied upon for validating the Applicant's control over the domain portion of the Mailbox Address to be used in the Certificate (see [Section 3.2.2.1.1](#32211-validating-authority-over-mailbox-via-domain-smime-certificates) and [Section 3.2.2.1.3](#32213-validating-applicant-as-operator-of-associated-mail-servers-smime-certificates)) require CAA records to be retrieved and processed from additional remote Network Perspectives before Certificate issuance (see [Section 4.2.2.2](#4222-multi-perspective-issuance-corroboration-smime-certificates)). To corroborate the Primary Network Perspective, a remote Network Perspective's CAA check response MUST be interpreted as permission to issue, regardless of whether the responses from both Perspectives are byte-for-byte identical. Additionally, a CA MAY consider the response from a remote Network Perspective as corroborating if one or both of the Perspectives experience an acceptable CAA record lookup failure, as defined in this section.
When processing CAA records, CAs SHALL process the `issuemail` property tag as specified in RFC 9495. Additional property tags MAY be supported, but SHALL NOT conflict with or supersede the authorizations to issue S/MIME Certificates as specified in the `issuemail` property tag.
If the CA issues a Certificate following a CAA check, they SHALL do so within the TTL of the CAA record, or 8 hours, whichever is greater. This stipulation does not prevent the CA from checking CAA records at any other time.
If the Certificate includes more than one Mailbox Address, then the CA SHALL perform the above procedure for each Mailbox Address.
CAA checking is optional for Certificates issued by a Technically Constrained Subordinate CA Certificate as set out in [Section 7.1.5](#715-name-constraints), where the lack of CAA checking is an explicit contractual provision in the contract with the Technically Constrained Subordinate CA Applicant.
The CA SHALL NOT issue a Certificate unless the CA determines that Certificate Request is consistent with the applicable CAA RRset. The CA SHALL log all actions taken, if any, consistent with its CAA processing practice.
CAs are permitted to treat a record lookup failure as permission to issue if:
- the failure is outside the CA's infrastructure; and
- the lookup has been retried at least once; and
- the CA has confirmed that the domain is "Insecure" as defined in [RFC 4035 Section 4.3](https://datatracker.ietf.org/doc/html/rfc4035#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](https://datatracker.ietf.org/doc/html/rfc4035#section-5); and
- support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and
- support SHA-2 as defined in [RFC 4509](https://datatracker.ietf.org/doc/html/rfc4509) and [RFC 5702](https://datatracker.ietf.org/doc/html/rfc5702); and
- properly handle the security concerns enumerated in [RFC 6840 Section 4](https://datatracker.ietf.org/doc/html/rfc6840#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](#87-self-audits).
#### 4.2.2.2 Multi-perspective issuance corroboration (S/MIME Certificates)
**[S/MIME Certificates]**
CAs SHOULD implement [Section 3.2.2.9](https://github.com/cabforum/servercert/blob/main/docs/BR.md#3229-multi-perspective-issuance-corroboration) of the TLS Baseline Requirements before March 15, 2025. Effective May 15, 2025 CAs SHALL implement [Section 3.2.2.9](https://github.com/cabforum/servercert/blob/main/docs/BR.md#3229-multi-perspective-issuance-corroboration) of the TLS Baseline Requirements.
### 4.2.3 Time to process certificate applications
No stipulation.
## 4.3 Certificate issuance
### 4.3.1 CA actions during certificate issuance
#### 4.3.1.1 Manual authorization of certificate issuance for Root CAs
Certificate issuance by the Root CA SHALL require an individual authorized by the CA (i.e. the CA system operator, system officer, or PKI administrator) to deliberately issue a direct command in order for the Root CA to perform a certificate signing operation.
#### 4.3.1.2 Linting of to-be-signed Certificate content
**[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 ).
#### 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](#963-subscriber-representations-and-warranties), provisions 2. and 4.
### 4.5.2 Relying party public key and certificate usage
Relying Parties shall acknowledge and agree to the provisions of this CP/CPS before using the CA Certificates.
Relying Parties may use the CA Certificates for assessment of Subscriber Certificates.
## 4.6 Certificate renewal
### 4.6.1 Circumstance for certificate renewal
Certificate renewal may be performed upon the request of the Subscriber or by the CA at its discretion.
### 4.6.2 Who may request renewal
The provisions of [Section 4.1.1 - Who can submit a certificate application](#411-who-can-submit-a-certificate-application) hereof shall apply.
### 4.6.3 Processing certificate renewal requests
The provisions of [Section 4.3.1 - CA actions during certificate issuance](#431-ca-actions-during-certificate-issuance) hereof shall apply.
### 4.6.4 Notification of new certificate issuance to subscriber
The provisions of [Section 4.3.2 - Notification to subscriber by the CA of issuance of certificate](#432-notification-to-subscriber-by-the-ca-of-issuance-of-certificate) hereof shall apply.
### 4.6.5 Conduct constituting acceptance of a renewal certificate
The provisions of [Section 4.4.1 - Conduct constituting certificate acceptance](#441-conduct-constituting-certificate-acceptance) hereof shall apply.
### 4.6.6 Publication of the renewal certificate by the CA
The provisions of [Section 4.4.2 - Publication of the certificate by the CA](#442-publication-of-the-certificate-by-the-ca) hereof shall apply.
### 4.6.7 Notification of certificate issuance by the CA to other entities
The provisions of [Section 4.4.3 - Notification of certificate issuance by the CA to other entities](#443-notification-of-certificate-issuance-by-the-ca-to-other-entities) hereof shall apply.
## 4.7 Certificate re-key
### 4.7.1 Circumstance for certificate re-key
A Certificate is Re-Keyed when the validity period of the Certificate is about to expire or when the Certificate is revoked due to the key compromise.
### 4.7.2 Who may request certification of a new public key
The provisions of [Section 4.1.1 - Who can submit a certificate application](#411-who-can-submit-a-certificate-application) hereof shall apply.
### 4.7.3 Processing certificate re-keying requests
The provisions of [Section 4.3.1 - CA actions during certificate issuance](#431-ca-actions-during-certificate-issuance) hereof shall apply.
### 4.7.4 Notification of new certificate issuance to subscriber
The provisions of [Section 4.3.2 - Notification to subscriber by the CA of issuance of certificate](#432-notification-to-subscriber-by-the-ca-of-issuance-of-certificate) hereof shall apply.
### 4.7.5 Conduct constituting acceptance of a re-keyed certificate
The provisions of [Section 4.4.1 - Conduct constituting certificate acceptance](#441-conduct-constituting-certificate-acceptance) hereof shall apply.
### 4.7.6 Publication of the re-keyed certificate by the CA
The provisions of [Section 4.4.2 - Publication of the certificate by the CA](#442-publication-of-the-certificate-by-the-ca) hereof shall apply.
### 4.7.7 Notification of certificate issuance by the CA to other entities
The provisions of [Section 4.4.3 - Notification of certificate issuance by the CA to other entities](#443-notification-of-certificate-issuance-by-the-ca-to-other-entities) hereof shall apply.
## 4.8 Certificate modification
### 4.8.1 Circumstance for certificate modification
Certificate modification may be performed upon the request of the Subscriber or by CA at its discretion.
### 4.8.2 Who may request certificate modification
The provisions of [Section 4.9.2](#492-who-can-request-revocation) and [Section 4.1.1](#411-who-can-submit-a-certificate-application) hereof shall apply.
### 4.8.3 Processing certificate modification requests
The provisions of [Section 4.3.1 - CA actions during certificate issuance](#431-ca-actions-during-certificate-issuance) hereof shall apply.
### 4.8.4 Notification of new certificate issuance to subscriber
The provisions of [Section 4.3.2 - Notification to subscriber by the CA of issuance of certificate](#432-notification-to-subscriber-by-the-ca-of-issuance-of-certificate) hereof shall apply.
### 4.8.5 Conduct constituting acceptance of modified certificate
The provisions of [Section 4.4.1 - Conduct constituting certificate acceptance](#441-conduct-constituting-certificate-acceptance) hereof shall apply.
### 4.8.6 Publication of the modified certificate by the CA
The provisions of [Section 4.4.2 - Publication of the certificate by the CA](#442-publication-of-the-certificate-by-the-ca) hereof shall apply.
### 4.8.7 Notification of certificate issuance by the CA to other entities
The provisions of [Section 4.4.3 - Notification of certificate issuance by the CA to other entities](#443-notification-of-certificate-issuance-by-the-ca-to-other-entities) hereof shall apply.
## 4.9 Certificate revocation and suspension
### 4.9.1 Circumstances for revocation
#### 4.9.1.1 Reasons for Revoking a Subscriber Certificate
**[S/MIME Certificates]**
The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:
1. The Subscriber requests in writing that the CA revoke the Certificate;
2. The Subscriber notifies the CA that the original Certificate Request was not authorized and does not retroactively grant authorization;
3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise;
4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate (such as a Debian weak key, see );
5. The CA obtains evidence that the validation of domain authorization or mailbox control for any Mailbox Address in the Certificate should not be relied upon.
The CA SHOULD revoke a Certificate within 24 hours and SHALL revoke a Certificate within 5 days if one or more of the following occurs:
6. The Certificate no longer complies with the requirements of [Section 6.1.5](#615-key-sizes) and [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking);
7. The CA obtains evidence that the Certificate was misused;
8. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use;
9. The CA is made aware of any circumstance indicating that use of an email address or Fully-Qualified Domain Name in the Certificate is no longer legally permitted (e.g., a court or arbitrator has revoked the right to use an email address or Domain Name, a relevant licensing or services agreement between the Subscriber has terminated, or the account holder has failed to maintain the active status of the email address or Domain Name);
10. The CA is made aware of a material change in the information contained in the Certificate;
11. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA's CP and/or CPS;
12. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate;
13. The CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository;
14. Revocation is required by the CA's CP and/or CPS; or
15. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed.
**[Code Signing Certificates]**
The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:
1. The Subscriber requests in writing that the CA revoke the Certificate;
2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization;
3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise;
4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate;
5. The CA is made aware of a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed; or
6. The CA has reasonable assurance that a Certificate was used to sign Suspect Code.
The CA SHOULD revoke a certificate within 24 hours and SHALL revoke a Certificate within 5 days if one or more of the following occurs:
7. The Certificate no longer complies with the requirements of Section 6.1.5 and Section 6.1.6;
8. The CA obtains evidence that the Certificate was misused.
9. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use.
10. The CA is made aware of a material change in the information contained in the Certificate.
11. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA's Certificate Policy or Certification Practice Statement.
12. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate.
13. The CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository.
14. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement.
The CA MAY delay revocation based on a request from Application Software Suppliers where immediate revocation has a potentially large negative impact to the ecosystem.
**[Client Authentication Certificates, Document Signing Certificates and Timestamp Certificates]**
The CA SHALL revoke a Certificate if one or more of the following occurs:
1. The Subscriber requests in writing that the CA revoke the Certificate;
2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization;
3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise;
4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate;
5. The CA is made aware of a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed; or
6. The Certificate no longer complies with the requirements of Section 6.1.5 and Section 6.1.6;
7. The CA obtains evidence that the Certificate was misused.
8. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use.
9. The CA is made aware of a material change in the information contained in the Certificate.
10. The CA is made aware that the Certificate was not issued in accordance with [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) or the CA's Certificate Policy or Certification Practice Statement.
11. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate.
12. The CA's right to issue Certificates under [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository.
13. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement.
#### 4.9.1.2 Reasons for Revoking a Subordinate CA Certificate
The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs:
1. The Subordinate CA requests revocation in writing;
2. The Subordinate CA notifies the Issuing CA that the original certificate request was not authorized and does not retroactively grant authorization;
3. The Issuing CA obtains evidence that the Subordinate CA's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of [Section 6.1.5](#615-key-sizes) and [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking);
4. The Issuing CA obtains evidence that the Certificate was misused;
5. The Issuing CA is made aware that the Certificate was not issued in accordance with or that Subordinate CA has not complied with this document or the applicable Certificate Policy or Certification Practice Statement;
6. The Issuing CA determines that any of the information appearing in the Certificate is inaccurate or misleading;
7. The Issuing CA or Subordinate CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate;
8. The Issuing CA's or Subordinate CA's right to issue Certificates under [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) expires or is revoked or terminated, unless the Issuing CA has made arrangements to continue maintaining the CRL/OCSP Repository; or
9. Revocation is required by the Issuing CA's CP/CPS.
### 4.9.2 Who can request revocation
The Subscriber, RA, or Issuing CA can initiate revocation. Additionally, Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate.
### 4.9.3 Procedure for revocation request
The CA SHALL provide a process for Subscribers to request revocation of their own Certificates.
The Subscriber submits a revocation request for the Subscriber certificate to the CA according to the prescribed procedure. For the certificates requested and issued by the LRA, a revocation request for a Subscriber certificate shall be made by the method determined by the LRA based on the LRA operational standards. LRA accesses the site provided by SECOM Trust Systems using the LRA certificate, and applies for revocation of the Subscriber certificate to the CA.
The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports.
The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in [Section 1.5.2](#152-contact-person) of their CPS.
### 4.9.4 Revocation request grace period
Actual revocation timelines depend on the reasons for revocation as described in this [section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate) and [section 4.9.1.2](#4912-reasons-for-revoking-a-subordinate-ca-certificate).
### 4.9.5 Time within which CA must process the revocation request
Within 24 hours after receiving a Certificate Problem Report, the CA SHALL investigate the facts and circumstances related to a Certificate Problem Report and provide a preliminary report on its findings to both the Subscriber and the entity who filed the Certificate Problem Report.
After reviewing the facts and circumstances, the CA SHALL work with the Subscriber and any entity reporting the Certificate Problem Report or other revocation-related notice to establish whether or not the certificate will be revoked, and if so, a date which the CA will revoke the certificate. The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation MUST NOT exceed the time frame set forth in [Section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate). The date selected by the CA SHOULD consider the following criteria:
1. The nature of the alleged problem (scope, context, severity, magnitude, risk of harm);
2. The consequences of revocation (direct and collateral impacts to Subscribers and Relying Parties);
3. The number of Certificate Problem Reports received about a particular Certificate or Subscriber;
4. The entity making the complaint (for example, a complaint from a law enforcement official that a Web site is engaged in illegal activities should carry more weight than a complaint from a consumer alleging that they didn't receive the goods they ordered); and
5. Relevant legislation.
### 4.9.6 Revocation checking requirement for relying parties
Relying parties should check the revocation status of all certificates that contain a CRL Distribution Point or OCSP pointer.
### 4.9.7 CRL issuance frequency
CRLs MUST be available via a publicly-accessible HTTP URL (i.e., "published").
**[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](https://datatracker.ietf.org/doc/html/rfc6960) and/or [RFC 5019](https://datatracker.ietf.org/doc/html/rfc5019). 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](https://datatracker.ietf.org/doc/html/rfc6960).
### 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](https://datatracker.ietf.org/doc/html/rfc6960) and/or [RFC 5019](https://datatracker.ietf.org/doc/html/rfc5019).
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](#715-name-constraints), 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](#491-circumstances-for-revocation).
### 4.9.13 Circumstances for suspension
The Repository MUST NOT include entries that indicate that a Certificate is suspended.
See [Section 7.2.2](#722-crl-and-crl-entry-extensions) for restrictions on use of suspension.
### 4.9.14 Who can request suspension
Not applicable.
### 4.9.15 Procedure for suspension request
Not applicable.
### 4.9.16 Limits on suspension period
Not applicable.
## 4.10 Certificate status services
### 4.10.1 Operational characteristics
Revocation entries on a CRL or OCSP Response MUST NOT be removed until after the Expiry Date of the revoked Certificate.
**[Code Signing Certificates]**
Revocation information shall be confirmed for at least 10 years after the expiration date.
### 4.10.2 Service availability
The CA SHALL operate and maintain its CRL and optional OCSP capability with resources sufficient to provide a response time of ten seconds or less under normal operating conditions.
The CA SHALL maintain an online 24x7 Repository that application software can use to automatically check the current status of all unexpired Certificates issued by the CA.
The CA SHALL maintain a continuous 24x7 ability to respond internally to a high-priority Certificate Problem Report, and where appropriate, forward such a complaint to law enforcement authorities, and/or revoke a Certificate that is the subject of such a complaint.
### 4.10.3 Optional features
No stipulation.
## 4.11 End of subscription
In terminating subscription of the Services, Subscribers are required to proceed with the service subscription termination procedure set forth in the relevant agreement therefor or the like.
Subscribers shall submit a Certificate Revocation Request when ending the certificate use. It will also end if they do not apply for the renewal of the certificate and the validity period of the corresponding certificate has expired.
## 4.12 Key escrow and recovery
### 4.12.1 Key escrow and recovery policy and practices
The CA does not Escrow Subscriber Private Keys.
### 4.12.2 Session key encapsulation and recovery policy and practices
Not applicable.
# 5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS
The CA SHALL develop, implement, and maintain a comprehensive security program designed to:
1. Protect the confidentiality, integrity, and availability of Certificate Data and Certificate Management Processes;
2. Protect against anticipated threats or hazards to the confidentiality, integrity, and availability of the Certificate Data and Certificate Management Processes;
3. Protect against unauthorized or unlawful access, use, disclosure, alteration, or destruction of any Certificate Data or Certificate Management Processes;
4. Protect against accidental loss or destruction of, or damage to, any Certificate Data or Certificate Management Processes; and
5. Comply with all other security requirements applicable to the CA by law.
The Certificate Management Process MUST include:
1. physical security and environmental controls;
2. system integrity controls, including configuration management, integrity maintenance of trusted code, and malware detection/prevention;
3. network security and firewall management, including port restrictions and IP address filtering;
4. user management, separate trusted-role assignments, education, awareness, and training; and
5. logical access controls, activity logging, and inactivity time-outs to provide individual accountability.
The CA's security program MUST include an annual Risk Assessment that:
1. Identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes;
2. Assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and
3. Assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.
Based on the Risk Assessment, the CA SHALL develop, implement, and maintain a security plan consisting of security procedures, measures, and products designed to achieve the objectives set forth above and to manage and control the risks identified during the Risk Assessment, commensurate with the sensitivity of the Certificate Data and Certificate Management Processes. The security plan MUST include administrative, organizational, technical, and physical safeguards appropriate to the sensitivity of the Certificate Data and Certificate Management Processes. The security plan MUST also take into account then-available technology and the cost of implementing the specific measures, and SHALL implement a reasonable level of security appropriate to the harm that might result from a breach of security and the nature of the data to be protected.
## 5.1 Physical Security Controls
### 5.1.1 Site location and construction
The CA has its certification infrastructure system installed within a 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](#521-trusted-roles) hereof to avoid disruptions in the provision of services.
Critical operations, such as those related to the CA Private Key, are jointly performed by at least two persons.
### 5.2.3 Identification and authentication for each role
With regard to any access to the certification infrastructure systems, SECOM Trust Systems shall conduct identification and authentication of the access-permitted individuals as well as the validity of the access to be an authorized action, through physical or logical means.
### 5.2.4 Roles requiring separation of duties
As a general rule, individual roles listed in [Section 5.2.1](#521-trusted-roles) hereof are performed by independent personnel.
A Service Operation Manager may concurrently serve as a Log Examiner.
## 5.3 Personnel controls
### 5.3.1 Qualifications, experience, and clearance requirements
Prior to the engagement of any person in the Certificate Management Process, whether as an employee, agent, or an independent contractor of the CA, the CA SHALL verify the identity and trustworthiness of such person.
### 5.3.2 Background check procedures
SECOM Trust Systems assesses the reliability and suitability of the individuals responsible for the roles listed in [Section 5.2.1](#521-trusted-roles) hereof at the time of appointment and on a regular basis thereafter.
### 5.3.3 Training Requirements and Procedures
The CA SHALL provide all personnel performing information verification duties with skills-training that covers basic Public Key Infrastructure knowledge, authentication and vetting policies and procedures (including the CA's CP/CPS), common threats to the information verification process (including phishing and other social engineering tactics), and Baseline Requirements.
The CA SHALL maintain records of such training and ensure that personnel entrusted with Validation Specialist duties maintain a skill level that enables them to perform such duties satisfactorily.
The CA SHALL document that each Validation Specialist possesses the skills required by a task before allowing the Validation Specialist to perform that task.
The CA SHALL require all Validation Specialists to pass an examination provided by the CA on the information verification requirements outlined in Baseline Requirements.
### 5.3.4 Retraining frequency and requirements
All personnel in Trusted roles SHALL maintain skill levels consistent with the CA's training and performance programs.
The CA provides the individuals responsible for the roles listed in [Section 5.2.1](#521-trusted-roles) hereof with refresher training as needed.
### 5.3.5 Job rotation frequency and sequence
The CA conducts job rotations of the personnel for the purpose of securing service quality consistency and improvement as well as prevention of misconducts.
### 5.3.6 Sanctions for unauthorized actions
The provisions concerning penalties set forth in SECOM Trust Systems Rules of Employment apply.
### 5.3.7 Independent Contractor Controls
The CA SHALL verify that the Delegated Third Party's personnel involved in the issuance of a Certificate meet the training and skills requirements of [Section 5.3.3](#533-training-requirements-and-procedures) and the document retention and event logging requirements of [Section 5.4.1](#541-types-of-events-recorded).
When the CA may employ independent contractors for operations of the certification infrastructure systems in whole or in part, the company ensures through the agreements therewith that the operational duties are duly performed by the contractors.
### 5.3.8 Documentation supplied to personnel
The CA permits the personnel's access only to the documents necessary for the performance of relevant duties.
## 5.4 Audit logging procedures
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](#49-certificate-revocation-and-suspension) and [Section 4.10](#410-certificate-status-services)); and
7. Introduction of new Certificate Profiles and retirement of existing Certificate Profiles.
2. Subscriber Certificate lifecycle management events, including:
1. Certificate requests, renewal, and re-key requests, and revocation;
2. All verification activities stipulated in Baseline Requirements and the CA's Certification Practice Statement;
3. Approval and rejection of certificate requests;
4. Issuance of Certificates;
5. Generation of Certificate Revocation Lists; and
6. Signing of OCSP Responses (as described in [Section 4.9](#49-certificate-revocation-and-suspension) and [Section 4.10](#410-certificate-status-services)).
7. Multi-Perspective Issuance Corroboration attempts from each Network Perspective, minimally recording the following information:
- a. an identifier that uniquely identifies the Network Perspective used;
- b. the attempted domain name and/or IP address; and
- c. the result of the attempt (e.g., "domain validation pass/fail", "CAA permission/prohibition").
8. Multi-Perspective Issuance Corroboration quorum results for each attempted domain name or IP address represented in a Certificate request (i.e., "3/4" which should be interpreted as "Three (3) out of four (4) attempted Network Perspectives corroborated the determinations made by the Primary Network Perspective).
3. Security events, including:
1. Successful and unsuccessful PKI system access attempts;
2. PKI and security system actions performed;
3. Security profile changes;
4. Installation, update and removal of software on a Certificate System;
5. System crashes, hardware failures, and other anomalies;
6. Relevant router and firewall activities (as described in [Section 5.4.1.1](#5411-router-and-firewall-activities-logs)); and
7. Entries to and exits from the CA facility.
Log records MUST include at least the following elements:
1. Date and time of event;
2. Identity of the person making the journal record (when applicable); and
3. Description of the event.
#### 5.4.1.1 Router and firewall activities logs
Logging of router and firewall activities necessary to meet the requirements of [Section 5.4.1](#541-types-of-events-recorded), Subsection 3.6 MUST at a minimum include:
1. Successful and unsuccessful login attempts to routers and firewalls; and
2. Logging of all administrative actions performed on routers and firewalls, including configuration changes, firmware updates, and access control modifications; and
3. Logging of all changes made to firewall rules, including additions, modifications, and deletions; and
4. Logging of all system events and errors, including hardware failures, software crashes, and system restarts.
#### 5.4.1.2 Types of events recorded for Timestamp Authorities
**[Code Signing Certificates]**
The Timestamp Authority MUST log the following information and make these records available to its Qualified Auditor as proof of the Timestamp Authority’s compliance with Baseline Requirements for Code Signing Certificates:
1. Physical or remote access to a timestamp server, including the time of the access and the identity of the individual accessing the server,
2. History of the timestamp server configuration,
3. Any attempt to delete or modify timestamp logs,
4. Security events, including:
- a. Successful and unsuccessful Timestamp Authority access attempts;
- b. Timestamp Authority server actions performed;
- c. Security profile changes;
- d. System crashes, and other anomalies; and
- e. Firewall and router activities.
5. Revocation of a timestamp certificate,
6. Major changes to the timestamp server’s time, and
7. System startup and shutdown.
### 5.4.2 Frequency of processing audit log
The CA reviews Audit logs periodically.
The review of current and archived audit logs include a validation of the audit logs’ integrity, and the timely identification and follow up of unauthorised or suspicious activity.
### 5.4.3 Retention period for audit log
The CA and each Delegated Third Party SHALL retain, for at least two (2) years:
1. CA certificate and key lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (1)) after the later occurrence of:
1. the destruction of the CA Private Key; or
2. the revocation or expiration of the final CA Certificate in that set of Certificates that have an X.509v3 `basicConstraints` extension with the `cA` field set to true and which share a common Public Key corresponding to the CA Private Key;
2. Subscriber Certificate lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (2)) after the expiration of the Subscriber Certificate;
3. Any security event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (3)) after the event occurred.
4. For **Code Signing Certificates**, Timestamp Authority data record after the revocation or renewal of the Timestamp Certificate private key (as set forth in [Section 5.4.1.2](#5412-types-of-events-recorded-for-timestamp-authorities)); and the security event record after the event occurred (as specified in [Section 5.4.1.2](#5412-types-of-events-recorded-for-timestamp-authorities)).
### 5.4.4 Protection of audit log
The CA implements appropriate controls on Audit Log access to secure sole access by the authorized personnel and to keep the log from the eyes of those unauthorized.
### 5.4.5 Audit log backup procedures
Audit Logs are backed up and stored in a secure off-site environment that is separate from the equipment that generates the Audit Logs.
### 5.4.6 Audit collection System (internal vs. external)
The Audit Log collection system is included as a function of the certification infrastructure systems.
### 5.4.7 Notification to event-causing subject
The CA collects Audit Log without notifying the person, system or application that has caused the corresponding event.
### 5.4.8 Vulnerability assessments
Additionally, the CA's security program MUST include an annual Risk Assessment that:
1. Identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes;
2. Assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and
3. Assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.
## 5.5 Records archival
### 5.5.1 Types of records archived
The CA and each Delegated Third Party SHALL archive all audit logs (as set forth in [Section 5.4.1](#541-types-of-events-recorded)).
Additionally, the CA and each Delegated Third Party SHALL archive:
1. Documentation related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems; and
2. Documentation related to their verification, issuance, and revocation of certificate requests and Certificates.
### 5.5.2 Retention period for archive
Archived audit logs (as set forth in [Section 5.5.1](#551-types-of-records-archived) SHALL be retained for a period of at least two (2) years from their record creation timestamp, or as long as they are required to be retained per [Section 5.4.3](#543-retention-period-for-audit-log), whichever is longer.
Additionally, the CA and each Delegated Third Party SHALL retain, for at least two (2) years:
1. All archived documentation related to the security of Certificate Systems, Certificate Management Systems, Root CA Systems and Delegated Third Party Systems (as set forth in [Section 5.5.1](#551-types-of-records-archived)); and
2. All archived documentation relating to the verification, issuance, and revocation of certificate requests and Certificates (as set forth in [Section 5.5.1](#551-types-of-records-archived)) after the later occurrence of:
1. such records and documentation were last relied upon in the verification, issuance, or revocation of certificate requests and Certificates; or
2. the expiration of the Subscriber Certificates relying upon such records and documentation.
### 5.5.3 Protection of archive
Archives are retained in a facility, access to which is restricted to the authorized personnel.
### 5.5.4 Archive backup procedures
The Archive is backed up whenever a change is made in such critical data pertaining to certification infrastructure system functions as Certificate issuance/revocation or CRL issuance.
### 5.5.5 Requirements for time-stamping of records
SECOM Trust Systems uses the NTP (Network Time Protocol) to time-synchronize the certification infrastructure systems and Time-Stamps the critical data recorded therein.
### 5.5.6 Archive collection system (internal or external)
The Archive collection system is included as a function of the certification infrastructure systems.
### 5.5.7 Procedures to obtain and verify archive information
The Archive shall be retrieved from the secure storage by designated personnel with the appropriate access permission for periodic checks of the storage conditions of the media. Further, the Archive is copied to new media as appropriate to maintain their integrity and confidentiality.
## 5.6 Key changeover
Renewal of Key-Pairs or Certificates of the CA, as a general rule, shall be made before their remaining validity periods become shorter than the maximum validity periods of the Certificates issued to Subscribers. After the new key pair is generated, the certificate and CRL are issued using the new key pair.
## 5.7 Compromise and disaster recovery
### 5.7.1 Incident and compromise handling procedures
#### 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](#49-certificate-revocation-and-suspension) of the CAs operated on the Digital Certification Infrastructure.
In the event that the operation of the system related to the CA is interrupted or stopped, the CA shall notify the relevant parties, including the application software supplier, in accordance with the predetermined plans and procedures to safely resume operation.
### 5.7.4 Business continuity capabilities after a disaster
In order to ensure prompt recovery to be implemented in the event of an unforeseen circumstance, SECOM Trust Systems deploys preventive measures for the fastest possible recovery of the certification infrastructure systems, including securing of replacement/backup hardware, continual data backups for recovery, and establishment of the recovery procedures.
## 5.8 CA or RA termination
In the event of termination of the CA, it shall so notify Subscribers and other affected participants, including Application Software Suppliers through the Delegated Third Party, three (3) months prior to the termination.
# 6. TECHNICAL SECURITY CONTROLS
## 6.1 Key pair generation and installation
Per this topic, this CP/CPS provides for the Key controls by the CAs operated on the Digital Certification Infrastructure. The CP/CPS provides for the Key controls by such other participants as Subscribers.
### 6.1.1 Key pair generation
#### 6.1.1.1 CA Key Pair Generation
For CA Key Pairs that are either
i. used as a CA Key Pair for a Root Certificate or
ii. used as a CA Key Pair for a Subordinate CA Certificate, where the Subordinate CA is not the operator of the Root CA or an Affiliate of the Root CA,
the CA SHALL:
1. prepare and follow a Key Generation Script,
2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process, and
3. have a Qualified Auditor issue a report opining that the CA followed its key ceremony during its Key and Certificate generation process and the controls used to ensure the integrity and confidentiality of the Key Pair.
For other CA Key Pairs that are for the operator of the Root CA or an Affiliate of the Root CA, the CA SHOULD:
1. prepare and follow a Key Generation Script and
2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process.
In all cases, the CA SHALL:
1. generate the CA Key Pair in a physically secured environment as described in the CA's CP/CPS;
2. generate the CA Key Pair using personnel in Trusted Roles under the principles of multiple person control and split knowledge;
3. generate the CA Key Pair within cryptographic modules meeting the applicable technical and business requirements as disclosed in the CA's CP/CPS;
4. log its CA Key Pair generation activities; and
5. maintain effective controls to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in its CP/CPS and (if applicable) its Key Generation Script.
#### 6.1.1.2 RA Key Pair Generation
No stipulation.
#### 6.1.1.3 Subscriber Key Pair Generation
The CA SHALL reject a certificate request if one or more of the following conditions are met:
1. The Key Pair does not meet the requirements set forth in [Section 6.1.5](#615-key-sizes) and/or [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking);
2. There is clear evidence that the specific method used to generate the Private Key was flawed;
3. The CA is aware of a demonstrated or proven method that exposes the Applicant's Private Key to compromise;
4. The CA has previously been notified that the Applicant's Private Key has suffered a Key Compromise using the CA's procedure for revocation request as described in [Section 4.9.3](#493-procedure-for-revocation-request) and [Section 4.9.12](#4912-special-requirements-re-key-compromise);
5. The Public Key corresponds to an industry-demonstrated weak Private Key. For requests submitted on or after 2024-11-15, at least the following precautions SHALL be implemented:
1. In the case of Debian weak keys vulnerability (), the CA SHALL reject all keys found at for each key type (e.g. RSA, ECDSA) and size listed in the repository. For all other keys meeting the requirements of [Section 6.1.5](#615-key-sizes), with the exception of RSA key sizes greater than 8192 bits, the CA SHALL reject Debian weak keys.
2. In the case of ROCA vulnerability, the CA SHALL reject keys identified by the tools available at or equivalent.
3. In the case of Close Primes vulnerability (), the CA SHALL reject weak keys which can be factored within 100 rounds using Fermat’s factorization method.
Suggested tools for checking for weak keys can be found here:
If the Subscriber Certificate will contain an `extKeyUsage` extension containing either the values `id-kp-serverAuth` [RFC5280] or `anyExtendedKeyUsage` [RFC5280], the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA.
**[AATL Document Signing Certificates and Code Signing Certificates]**
Subscriber’s key pair shall be directly generated by and stored in such a secure cryptographic hardware device.
### 6.1.2 Private key delivery to subscriber
Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization by the Subscriber.
If the CA or any of its designated RAs become aware that a Subscriber's Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subscriber, then the CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.
**[S/MIME Certificates]**
Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization by the Subscriber.
If the CA or any of its designated RAs become aware that a Subscriber's Private Key has been communicated to a person or organization not authorized by the Subscriber, then the CA SHALL revoke all Certificates that include the Public Key corresponding to the communicated Private Key.
If the CA or a Delegated Third Party generates the Private Key on behalf of the Subscriber where the Private Keys will be transported to the Subscriber, then the entity generating the Private Key SHALL either:
1. Transport the Private Key in hardware with an activation method that is equivalent to 128 bits of encryption, where the material used to activate/protect the Private Key (e.g., a password used to secure a PKCS 12 file) must be delivered to the Subscriber securely and separately from the container holding the Private Key; or
2. Encrypt the Private Key with at least 112 bits of encryption strength.
Illustrative examples include:
- Using a 128-bit AES key to wrap the Private Key.
- Storing the key in a PKCS 12 file encrypted using a password and algorithm whose combination provides at least 112 bits of encryption strength.
- Transporting the Private Key and/or PKCS 12 file and/or activation material via a TLS or other authenticated and encrypted network connection with at least 112 bits of encryption strength.
- Other approaches that meet the requirements are allowed.
**[Code Signing Certificates]**
If the CA or any Delegated Third Party is generating the Private Key on behalf of the Subscriber where the Private Keys will be transported to the Subscriber outside of the Signing Service's secure infrastructure, then the entity generating the Private Key MUST transport the Private Key in hardware with an activation method that is equivalent to 128 bits of encryption.
Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization by the Subscriber.
If the CA or any of its designated RAs become aware that a Subscriber's Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subscriber, then the CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key. If a Signing Service is generating a Private Key on behalf of the Subscriber, that Private Key SHALL NOT be transported to the Subscriber.
### 6.1.3 Public key delivery to certificate issuer
A Subscriber Public Key may be delivered online to the CA, the communication routing of which is encrypted by TLS.
### 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](#627-private-key-storage-on-cryptographic-module) MUST consist of physical security, encryption, or a combination of both, implemented in a manner that prevents disclosure of the Private Key. The CA SHALL encrypt its Private Key with an algorithm and key-length that, according to the state of the art, are capable of withstanding cryptanalytic attacks for the residual life of the encrypted key or key part.
### 6.2.1 Cryptographic module standards and controls
The generation, storage and signing operations of the CA Private Keys are performed using [Section 6.2.7](#627-private-key-storage-on-cryptographic-module).
No stipulation for Subscriber Private Keys.
**[AATL Document Signing Certificates]**
Certificates of the AATL Document Signing Certificate shall have one of the following accreditations:
1. FIPS 140-2 Level 2; or higher
2. Common Criteria (ISO 15408 & ISO 18045) - Protection Profiles CEN prEN 14169 (all parts applicable to the device type) or standards such as CEN EN 419 241 series or equivalent, for remotely managed devices; or
3. by an EU Member State as a Qualified Signature Creation Device (QSCD) after 1 July 2016, or that was recognized as a Secure Signature Creation Device
(SSCD) by an EU Member State designated body before 1 July 2016.
### 6.2.2 Private key (n out of m) multi-person control
Activation, deactivation, backup and other operations relating to CA Private Keys are jointly performed by at least two authorized individuals in a secure environment. Activation, deactivation, backup and other operations relating to Subscriber Private Keys must be performed securely under the control of the relevant Subscribers.
### 6.2.3 Private key escrow
The CA does not Escrow CA Private Keys.
The CA does not Escrow Subscriber Private Keys.
### 6.2.4 Private key backup
See [Section 5.2.2](#522-number-of-individuals-required-per-task).
### 6.2.5 Private key archival
Parties other than the Subordinate CA SHALL NOT archive the Subordinate CA Private Keys without authorization by the Subordinate CA.
### 6.2.6 Private key transfer into or from a cryptographic module
If the Issuing CA generated the Private Key on behalf of the Subordinate CA, then the Issuing CA SHALL encrypt the Private Key for transport to the Subordinate CA. If the Issuing CA becomes aware that a Subordinate CA's Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subordinate CA, then the Issuing CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.
### 6.2.7 Private key storage on cryptographic module
The CA SHALL protect its Private Key in a system or device that has been validated as meeting at least FIPS 140-2 level 3, FIPS 140-3 level 3, or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the Private Key and other assets against known threats.
**[Time stamp certificates for code signing]**
Time stamp certificates for code signing shall no longer be issued after 2025-04-15.
The timestamp subordinate CA certificate for code signing purposes shall be revoked by 2026-06-06.
**[Code Signing Certificates]**
Code signing certificates shall no longer be issued after 2024-05-01.
The Code signing subordinate CA certificates shall be revoked by 2026-06-06.
Effective 2023-06-01, Subscriber Private Keys for Code Signing Certificates SHALL be protected per the following requirements. The CA MUST obtain a contractual representation from the Subscriber that the Subscriber will use one of the following options to generate and protect their Code Signing Certificate Private Keys in a Hardware Crypto Module with a unit design form factor certified as conforming to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+:
1. Subscriber uses a Hardware Crypto Module meeting the specified requirement.
2. Subscriber uses a cloud-base key generation and protection solution with the following requirements:
a Key creation, storage, and usage of Private Key must remain within the security boundaries of the cloud solution’s Hardware Crypto Module that conforms to the specified requirements;
b Subscription at the level that manages the Private Key must be configured to log all access, operations, and configuration changes on the resources securing the Private Key.
3. Subscriber uses a Signing Service which meets the Baseline Requirements for Code Signing Certificates of Section 6.2.7.3.
Effective 2023-06-01, for Code Signing Certificates, one of the following methods MUST be employed to satisfy Baseline Requirements for Code Signing Certificates:
1. The CA ships a suitable Hardware Crypto Module, with one or more pre-generated Key Pairs that the CA has generated using the Hardware Crypto Module;
2. The Subscriber counter-signs certificate requests that can be verified by using a manufacturer’s certificate, commonly known as key attestation, indicating that the Private Key was generated in a non-exportable way using a suitable Hardware Crypto Module;
3. The Subscriber uses a CA prescribed crypto library and a suitable Hardware Crypto Module combination for the Key Pair generation and storage;
4. The Subscriber provides an internal or external IT audit indicating that it is only using a suitable Hardware Crypto Module to generate Key Pairs to be associated with Code Signing Certificates;
5. The Subscriber provides a suitable report from the cloud-based key protection solution subscription and resources configuration protecting the Private Key in a suitable Hardware Crypto Module;
6. The CA relies on a report provided by the Applicant that is signed by an auditor who is approved by the CA and who has IT and security training or is a CISA witnesses the Key Pair creation in a suitable Hardware Crypto Module solution including a cloud-based key generation and protection solution;
7. The Subscriber provides an agreement that they use a Signing Service meeting the Baseline Requirements for Code Signing Certificates of Section 6.2.7.3;
**[AATL Document Signing Certificates]**
If it is confirmed that the CA has generated a private key within the HSM used by the Subscriber, in the certificate application procedure, the CA verify the signature of the certificate issuance request and confirm that it is signed with the private key corresponding to the public key included in the certificate issuance request.
Alternatively, the CA generates a private key on a cryptographic hardware device and securely distributes the private key to the Subscriber, so that the CA proves the Subscriber owns the private key corresponding to the applicable certificate.
### 6.2.8 Activating Private Keys
The CA Private Key is jointly activated by at least two authorized individuals in a secure room. No stipulation for Subscriber Private Keys.
### 6.2.9 Deactivating Private Keys
The CA Private Key is jointly deactivated by at least two authorized individuals in a secure room. No stipulation for Subscriber Private Keys.
### 6.2.10 Destroying Private Keys
Private Keys of the CA are jointly destroyed by at least two authorized individuals by means of complete initialization or physical destruction. The Private Key backups are also destroyed in the same manner. No stipulation for Subscriber Private Keys.
### 6.2.11 Cryptographic Module Rating
The quality standards to be applied to the cryptographic modules used by the CA are as specified in [Section 6.2.1](#621-cryptographic-module-standards-and-controls) hereof. No stipulation for Subscriber Private Keys.
## 6.3 Other aspects of key pair management
### 6.3.1 Public key archival
The provisions for the CA Public Keys are stipulated in [Section 6.2.1](#621-cryptographic-module-standards-and-controls). No stipulation for Subscriber Private Keys.
Archival of Public Keys of the CAs operated on the Digital Certification Infrastructure is covered by [Section 5.5.1](#551-types-of-records-archived) hereof.
### 6.3.2 Certificate operational periods and key pair usage periods
The validity period of the key pair of the subordinate CA is not specified, but the validity period of the subordinate CA certificate shall be 20 years or less.
**[Code Signing Certificates and Timestamp Certificates for Code Signing Certificates]**
Code signing certificates that comply with Baseline Requirements for Code Signing Certificates must not have a Validity Period greater than 39 months. The time stamp authority used for code signing certificates must use a new time stamp certificate with a new private key every 15 months to minimize the impact on the subscriber if the private key of the time stamp certificate is compromised. The validity period of the time stamp certificate must not be greater than 135 months.
The Timestamp Certificate Key Pair that complies with the Baseline Requirements for Code Signing Certificates MUST meet the requirements in [Section 6.1.5](#615-key-sizes). Timestamp Authority SHALL NOT use a Private Key associated with a Timestamp Certificate more than 15 months after the notBefore date of a Timestamp Certificate. Effective 2025-04-15, Private Keys associated with Timestamp Certificates issued for greater than 15 months MUST be removed from the Hardware Crypto Module protecting the Private Key within 18 months after issuance of the Timestamp Certificate. For Timestamp Certificates issued on or after 2024-06-01, the CA SHALL log the removal of the Private Key from the Hardware Crypto Module through means of a key deletion ceremony performed by the CA and witnessed and signed‐off by at least two Trusted Role members. The CA MAY also perform a key destruction ceremony, meaning that all copies of that private key are unequivocally/securely destroyed (i.e. without a way to recover the key), including any instance of the key as part of a backup, to satisfy the Baseline Requirements for Code Signing Certificates. The CA MAY maintain existing backup sets containing the Private Key corresponding to a Timestamp Certificate. The CA SHOULD NOT restore the Private Key corresponding to a Timestamp Certificate contained within the backup if the Timestamp Certificate was issued more than 15 months prior to restoration of the backup. If the CA does restore such a Private Key, the CA SHALL only restore the Private Key in a suitable HSM while it’s maintained in a High Security Zone and in an offline state or air‐gapped from all other networks and perform a new key destruction ceremony prior to the HSM being brought to an online state.
**[AATL Timestamp Certificates]**
The validity period of the time stamp certificate must not be greater than 135 months.
**[S/MIME Certificates]**
S/MIME certificates issued after 2022-04-01 must not have a Validity Period greater than 825 days.
**[Document Signing Certificates and Client Authentication Certificates]**
Subscriber certificates must not have a Validity Period greater than 1827 days.
For the purpose of calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, shall represent an additional day. For this reason, Subscriber Certificates SHOULD NOT be issued for the maximum permissible time by default, in order to account for such adjustments.
## 6.4 Activation data
### 6.4.1 Activation data generation and installation
The activation data required to use Private Keys of the CAs operated on the Digital Certification Infrastructure are jointly generated by at least two authorized individuals and are stored on a digital medium.
### 6.4.2 Activation data protection
The digital media storing the data required for activation of Private Keys of the CAs operated on the Digital Certification Infrastructure are stored under control in a secure room.
### 6.4.3 Other aspects of activation data
Management of the generation and setting of the activation data of the private key of the CA operated on the Digital Certification Infrastructure is performed by the persons described in [Section 5.2.1](#521-trusted-roles).
## 6.5 Computer security controls
### 6.5.1 Specific computer security technical requirements
The CA SHALL enforce multi-factor authentication for all accounts capable of directly causing certificate issuance.
### 6.5.2 Computer security rating
The CA conducts the preproduction system tests of all software and hardware to be employed by the certification infrastructure systems in an effort to secure the system reliability. In addition, SECOM Trust Systems constantly collects information on the security vulnerabilities of the certification infrastructure systems and performs assessments to be able to promptly take proper actions should any vulnerability be detected.
## 6.6 Life cycle technical controls
### 6.6.1 System development controls
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](https://cabforum.org/working-groups/netsec/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](#555-requirements-for-time-stamping-of-records) hereof.
# 7. CERTIFICATE, CRL, AND OCSP PROFILES
## 7.1 Certificate profile
The CA SHALL meet the technical requirements set forth in [Section 6.1.5 - Key Sizes](#615-key-sizes), and [Section 6.1.6 - Public Key Parameters Generation and Quality Checking](#616-public-key-parameters-generation-and-quality-checking).
### 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](#appendix-b--certificate-profile).
#### 7.1.2.2 Cross-Certified Subordinate CA Certificate Profile
See [APPENDIX B – Certificate profile](#appendix-b--certificate-profile).
#### 7.1.2.3 Subordinate CA Certificate Profile
See [APPENDIX B – Certificate profile](#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](#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](https://tools.ietf.org/html/RFC6960#section-4.2.2.2). The Issuing CA of the Responder MUST be the same as the Issuing CA for the Certificates it provides responses for.
| **Field** | **Description** |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| `tbsCertificate` | |
| - `version` | MUST be v3(2) |
| - `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. |
| - `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) |
| - `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) |
| - `validity` | See [Section 7.1.2.8.1](#71281-ocsp-responder-validity) |
| - `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) |
| - `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) |
| - `issuerUniqueID` | MUST NOT be present |
| - `subjectUniqueID` | MUST NOT be present |
| - `extensions` | See [Section 7.1.2.8.2](#71282-ocsp-responder-extensions) |
| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. |
| `signature` | - |
##### 7.1.2.8.1 OCSP Responder Validity
| **Field** | **Minimum** | **Maximum** |
| ----------- | ------------------------------------ | ------------------- |
| `notBefore` | One day prior to the time of signing | The time of signing |
| `notAfter` | The time of signing | Unspecified |
##### 7.1.2.8.2 OCSP Responder Extensions
| **Extension** | **Presence** | **Critical** | **Description** |
| --------------------------------- | --------------- | ------------ | --------------------------------------------------------------------------- |
| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) |
| `extKeyUsage` | MUST | - | See [Section 7.1.2.8.5](#71285-ocsp-responder-extended-key-usage) |
| `id-pkix-ocsp-nocheck` | MUST | N | See [Section 7.1.2.8.6](#71286-ocsp-responder-id-pkix-ocsp-nocheck) |
| `keyUsage` | MUST | Y | See [Section 7.1.2.8.7](#71287-ocsp-responder-key-usage) |
| `basicConstraints` | MAY | Y | See [Section 7.1.2.8.4](#71284-ocsp-responder-basic-constraints) |
| `nameConstraints` | MUST NOT | - | - |
| `subjectAltName` | MUST NOT | - | - |
| `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) |
| `authorityInformationAccess` | NOT RECOMMENDED | N | See [Section 7.1.2.8.3](#71283-ocsp-responder-authority-information-access) |
| `certificatePolicies` | MUST NOT | N | See [Section 7.1.2.8.8](#71288-ocsp-responder-certificate-policies) |
| `crlDistributionPoints` | MUST NOT | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) |
| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) |
| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) |
##### 7.1.2.8.3 OCSP Responder Authority Information Access
For OCSP Responder certificates, this extension is NOT RECOMMENDED, as the Relying Party should already possess the necessary information. In order to validate the given Responder certificate, the Relying Party must have access to the Issuing CA's certificate, eliminating the need to provide `id-ad-caIssuers`. Similarly, because of the requirement for an OCSP Responder certificate to include the `id-pkix-ocsp-nocheck` extension, it is not necessary to provide `id-ad-ocsp`, as such responses will not be checked by Relying Parties.
If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `AuthorityInfoAccessSyntax` MUST contain all required `AccessDescription`s.
| **Access Method** | **OID** | **Access Location** | **Presence** | **Maximum** | **Description** |
| ----------------- | ------------------ | --------------------------- | --------------- | ----------- | ---------------------------------------------- |
| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | NOT RECOMMENDED | \* | A HTTP URL of the Issuing CA's OCSP responder. |
| Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. |
##### 7.1.2.8.4 OCSP Responder Basic Constraints
OCSP Responder certificates MUST NOT be CA certificates. The issuing CA may indicate this one of two ways: by omission of the `basicConstraints` extension, or through the inclusion of a `basicConstraints` extension that sets the `cA` boolean to FALSE.
| **Field** | **Description** |
| ------------------- | ------------------- |
| `cA` | MUST be FALSE |
| `pathLenConstraint` | MUST NOT be present |
**Note**: Due to DER encoding rules regarding the encoding of DEFAULT values within OPTIONAL fields, a `basicConstraints` extension that sets the `cA` boolean to FALSE MUST have an `extnValue` `OCTET STRING` which is exactly the hex-encoded bytes `3000`, the encoded representation of an empty ASN.1 `SEQUENCE` value.
##### 7.1.2.8.5 OCSP Responder Extended Key Usage
| **Key Purpose** | **OID** | **Presence** |
| ------------------- | ----------------- | ------------ |
| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST |
| Any other value | - | MUST NOT |
##### 7.1.2.8.6 OCSP Responder id-pkix-ocsp-nocheck
The CA MUST include the `id-pkix-ocsp-nocheck` extension (OID: 1.3.6.1.5.5.7.48.1.5).
This extension MUST have an `extnValue` `OCTET STRING` which is exactly the hex-encoded bytes `0500`, the encoded representation of the ASN.1 NULL value, as specified in [RFC 6960, Section 4.2.2.2.1](https://tools.ietf.org/html/RFC6960#section-4.2.2.2.1).
##### 7.1.2.8.7 OCSP Responder Key Usage
| **Key Usage** | **Permitted** | **Required** |
| ------------------ | ------------- | ------------ |
| `digitalSignature` | Y | Y |
| `nonRepudiation` | N | -- |
| `keyEncipherment` | N | -- |
| `dataEncipherment` | N | -- |
| `keyAgreement` | N | -- |
| `keyCertSign` | N | -- |
| `cRLSign` | N | -- |
| `encipherOnly` | N | -- |
| `decipherOnly` | N | -- |
##### 7.1.2.8.8 OCSP Responder Certificate Policies
SECOM Trust Systems does not include this extension.
#### 7.1.2.9 Precertificate Profile
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](#712-certificate-content-and-extensions).
##### 7.1.2.10.1 CA Certificate Validity
| **Field** | **Minimum** | **Maximum** |
| ----------- | ------------------------------------ | ------------------- |
| `notBefore` | One day prior to the time of signing | The time of signing |
| `notAfter` | The time of signing | Unspecified |
##### 7.1.2.10.2 CA Certificate Naming
All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms).
The following table details the acceptable `AttributeType`s that may appear within the `type` field of an `AttributeTypeAndValue`, as well as the contents permitted within the `value` field.
| **Attribute Name** | **Presence** | **Value** | **Verification** |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- |
| `countryName` | MUST | The two-letter ISO 3166-1 country code for the country in which the CA's place of business is located. | [Section 3.2.2.3](#3223-verification-of-country) |
| `stateOrProvinceName` | MAY | If present, the CA's state or province information. | [Section 3.2.2.1](#3221-identity) |
| `localityName` | MAY | If present, the CA's locality. | [Section 3.2.2.1](#3221-identity) |
| `postalCode` | MUST NOT | SECOM Trust Systems does not certificates issue containing the Attribute Name. | [Section 3.2.2.1](#3221-identity) |
| `streetAddress` | MUST NOT | SECOM Trust Systems does not certificates issue containing the Attribute Name. | [Section 3.2.2.1](#3221-identity) |
| `organizationName` | MUST | The CA's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) |
| `organizationalUnitName` | This attribute MUST NOT be included in Root CA Certificates defined in [Section 7.1.2.1](#7121-root-ca-certificate-profile). This attribute SHOULD NOT be included in other types of CA Certificates. | - | - |
| `commonName` | MUST | The contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate. | |
| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.4](#7144-other-subject-attributes) |
##### 7.1.2.10.3 CA Certificate Authority Information Access
If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `accessLocation` MUST be encoded as the specified `GeneralName` type.
The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied.
| **Access Method** | **OID** | **Access Location** | **Presence** | **Maximum** | **Description** |
| ----------------- | ------------------ | --------------------------- | ------------ | ----------- | ---------------------------------------------- |
| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. |
| `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's certificate. |
| Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. |
##### 7.1.2.10.4 CA Certificate Basic Constraints
| **Field** | **Description** |
| ------------------- | ---------------- |
| `cA` | MUST be set TRUE |
| `pathLenConstraint` | MAY be present |
##### 7.1.2.10.5 CA Certificate Certificate Policies
**[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)
| **Field** | **Presence** | **Contents** |
| ------------------ | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, and if the Subordinate CA is an Affiliate of the Issuing CA, then the Issuing CA MAY use the `anyPolicy` Policy Identifier, which MUST be the only `PolicyInformation` value. |
| - `anyPolicy` | MUST | |
| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. |
Table: Policy Restricted
| **Field** | **Presence** | **Contents** |
| ----------------------------------------------------------------------------------------- | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `policyIdentifier` | MUST | One of the following policy identifiers: |
| A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The CA MUST include exactly one Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type directly or transitively issued by this Certificate. |
| `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. |
| Any other identifier | MAY | If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement. |
| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. |
The Policy Restricted profile RECOMMENDS that the first `PolicyInformation` value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier.
**Note**: policyQualifiers is NOT RECOMMENDED to be present in any Certificate issued under this Certificate Profile because this information increases the size of the Certificate without providing any value to a typical Relying Party, and the information may be obtained by other means when necessary.
If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows:
Table: Permitted `policyQualifiers`
| **Qualifier ID** | **Presence** | **Field Type** | **Contents** |
| ------------------------------------ | ------------ | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. |
| Any other qualifier | MUST NOT | - | - |
##### 7.1.2.10.6 CA Certificate Extended Key Usage
| **Key Purpose** | **OID** | **Presence** |
| ------------------------------------ | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | Not covered by this CP/CPS. See [SECOM Publicly Trusted TLS Server Authentication Certificate Policy/Certification Practice Statement](https://repo1.secomtrust.net/spcpp/publicly-trusted-cpcps/). |
| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY |
| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MAY (This Key Purpose MUST NOT be combined with any other Key Purpose) |
| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MAY (Before 2023-09-01, This Key Purpose can be set in combination with `id-kp-clientAuth`) |
| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MAY (This Key Purpose MUST NOT be combined with any other Key Purpose) |
| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT |
| `id-kp-documentSigning` | 1.3.6.1.5.5.7.3.36 | MAY |
| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT (On or after 2023-09-01) |
| `Precertificate Signing Certificate` | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT |
| `Microsoft Signer of documents` | 1.3.6.1.4.1.311.10.3.12 | MAY |
| `Adobe Authentic Documents Trust` | 1.2.840.113583.1.1.5 | MAY |
| `Any other value` | - | MAY |
##### 7.1.2.10.7 CA Certificate Key Usage
| **Key Usage** | **Permitted** | **Required** |
| ------------------ | ------------- | ---------------- |
| `digitalSignature` | Y | N[^ocsp_signing] |
| `nonRepudiation` | N | -- |
| `keyEncipherment` | N | -- |
| `dataEncipherment` | N | -- |
| `keyAgreement` | N | -- |
| `keyCertSign` | Y | Y |
| `cRLSign` | Y | Y |
| `encipherOnly` | N | -- |
| `decipherOnly` | N | -- |
[^ocsp_signing]: If a CA Certificate does not assert the `digitalSignature` bit, the CA Private Key MUST NOT be used to sign an OCSP Response. See [Section 7.3](#73-ocsp-profile) for more information.
#### 7.1.2.11 Common Certificate Fields
This section contains several fields that are common among multiple certificate profiles. However, these fields may not be common among all certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in [Section 7.1.2](#712-certificate-content-and-extensions).
##### 7.1.2.11.1 Authority Key Identifier
| **Field** | **Description** |
| --------------------------- | ----------------------------------------------------------------------------------------- |
| `keyIdentifier` | MUST be present. MUST be identical to the `subjectKeyIdentifier` field of the Issuing CA. |
| `authorityCertIssuer` | MUST NOT be present |
| `authorityCertSerialNumber` | MUST NOT be present |
##### 7.1.2.11.2 CRL Distribution Points
The CRL Distribution Points extension MUST be present in:
- Subordinate CA Certificates;
- 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
| **Field** | **Presence** | **Description** |
| ------------------- | ------------ | ------------------------------------------------------------------------------ |
| `distributionPoint` | MUST | The `DistributionPointName` MUST be a `fullName` formatted as described below. |
| `reasons` | MUST NOT | |
| `cRLIssuer` | MUST NOT | |
A `fullName` MUST contain at least one `GeneralName`; it MAY contain more than one. All `GeneralName`s MUST be of type `uniformResourceIdentifier`, and the scheme of each MUST be "http". The first `GeneralName` must contain the HTTP URL of the Issuing CA's CRL service for this certificate.
##### 7.1.2.11.3 Signed Certificate Timestamp List
If present, the Signed Certificate Timestamp List extension contents MUST be an `OCTET STRING` containing the encoded `SignedCertificateTimestampList`, as specified in [RFC 6962, Section 3.3](https://tools.ietf.org/html/rfc6962#section-3.3).
Each `SignedCertificateTimestamp` included within the `SignedCertificateTimestampList` MUST be for a `PreCert` `LogEntryType` that corresponds to the current certificate.
##### 7.1.2.11.4 Subject Key Identifier
If present, the `subjectKeyIdentifier` MUST be set as defined within [RFC 5280, Section 4.2.1.2](https://tools.ietf.org/html/rfc5280#section-4.2.1.2). The CA MUST generate a `subjectKeyIdentifier` that is unique within the scope of all Certificates it has issued for each unique public key (the `subjectPublicKeyInfo` field of the `tbsCertificate`). For example, CAs may generate the subject key identifier using an algorithm derived from the public key, or may generate a sufficiently-large unique number, such as by using a CSPRNG.
##### 7.1.2.11.5 Other Extensions
All extensions and extension values not directly addressed by the applicable certificate profile:
1. MUST apply in the context of the public Internet, unless:
a. the extension OID falls within an OID arc for which the Applicant demonstrates ownership, or,
b. the Applicant can otherwise demonstrate the right to assert the data in a public context.
2. MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA (such as including an extension that indicates a Private Key is stored on a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance).
3. MUST be DER encoded according to the relevant ASN.1 module defining the extension and extension values.
CAs SHALL NOT include additional extensions or values unless the CA is aware of a reason for including the data in the Certificate.
### 7.1.3 Algorithm object identifiers
#### 7.1.3.1 SubjectPublicKeyInfo
The following requirements apply to the `subjectPublicKeyInfo` field within a Certificate or Precertificate. No other encodings are permitted.
##### 7.1.3.1.1 RSA
The CA SHALL indicate an RSA key using the rsaEncryption (OID: 1.2.840.113549.1.1.1) algorithm identifier. The parameters MUST be present, and MUST be an explicit NULL.
The CA SHALL NOT use a different algorithm, such as the id-RSASSA-PSS (OID: 1.2.840.113549.1.1.10) algorithm identifier, to indicate an RSA key.
When encoded, the `AlgorithmIdentifier` for RSA keys MUST be byte-for-byte identical with the following hex-encoded bytes: `300d06092a864886f70d0101010500`
##### 7.1.3.1.2 ECDSA
The CA SHALL indicate an ECDSA key using the id-ecPublicKey (OID: 1.2.840.10045.2.1) algorithm identifier. The parameters MUST use the `namedCurve` encoding.
- For P-256 keys, the `namedCurve` MUST be secp256r1 (OID: 1.2.840.10045.3.1.7).
- For P-384 keys, the `namedCurve` MUST be secp384r1 (OID: 1.3.132.0.34).
- For P-521 keys, the `namedCurve` MUST be secp521r1 (OID: 1.3.132.0.35).
When encoded, the `AlgorithmIdentifier` for ECDSA keys MUST be byte-for-byte identical with the following hex-encoded bytes:
- For P-256 keys, `301306072a8648ce3d020106082a8648ce3d030107`.
- For P-384 keys, `301006072a8648ce3d020106052b81040022`.
- For P-521 keys, `301006072a8648ce3d020106052b81040023`.
#### 7.1.3.2 Signature AlgorithmIdentifier
All objects signed by a CA Private Key MUST conform to [Section 1.1.1 Standards, Criteria and Regulations](#111-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:
```hexdump
304106092a864886f70d01010a3034a00f300d0609608648016503040201
0500a11c301a06092a864886f70d010108300d0609608648016503040201
0500a203020120
```
- RSASSA-PSS with SHA-384, MGF-1 with SHA-384, and a salt length of 48 bytes:
Encoding:
```hexdump
304106092a864886f70d01010a3034a00f300d0609608648016503040202
0500a11c301a06092a864886f70d010108300d0609608648016503040202
0500a203020130
```
- RSASSA-PSS with SHA-512, MGF-1 with SHA-512, and a salt length of 64 bytes:
Encoding:
```hexdump
304106092a864886f70d01010a3034a00f300d0609608648016503040203
0500a11c301a06092a864886f70d010108300d0609608648016503040203
0500a203020140
```
In addition, the CA MAY use the following signature algorithm and encoding if all of the following conditions are met:
- If used within a Certificate, such as the `signatureAlgorithm` field of a Certificate or the `signature` field of a TBSCertificate:
- The new Certificate is a Root CA Certificate or Subordinate CA Certificate that is a Cross-Certificate; and,
- There is an existing Certificate, issued by the same issuing CA Certificate, using the following encoding for the signature algorithm; and,
- The existing Certificate has a `serialNumber` that is at least 64-bits long; and,
- The only differences between the new Certificate and existing Certificate are one of the following:
- A new `subjectPublicKey` within the `subjectPublicKeyInfo`, using the same algorithm and key size; and/or,
- A new `serialNumber`, of the same encoded length as the existing Certificate; and/or
- The new Certificate's `extKeyUsage` extension is present, has at least one key purpose specified, and none of the key purposes specified are the id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) or the anyExtendedKeyUsage (OID: 2.5.29.37.0) key purposes; and/or
- The new Certificate's `basicConstraints` extension has a pathLenConstraint that is zero.
- If used within an OCSP response, such as the `signatureAlgorithm` of a BasicOCSPResponse:
- The `producedAt` field value of the ResponseData MUST be earlier than 2022-06-01 00:00:00 UTC; and,
- All unexpired, un-revoked Certificates that contain the Public Key of the CA Key Pair and that have the same Subject Name MUST also contain an `extKeyUsage` extension with the only key usage present being the id-kp-ocspSigning (OID: 1.3.6.1.5.5.7.3.9) key usage.
- If used within a CRL, such as the `signatureAlgorithm` field of a CertificateList or the `signature` field of a TBSCertList:
- The CRL is referenced by one or more Root CA or Subordinate CA Certificates; and,
- The Root CA or Subordinate CA Certificate has issued one or more Certificates using the following encoding for the signature algorithm.
**Note**: The above requirements do not permit a CA to sign a Precertificate with this encoding.
- RSASSA-PKCS1-v1_5 with SHA-1:
Encoding:
`300d06092a864886f70d0101050500`
##### 7.1.3.2.2 ECDSA
The CA SHALL use the appropriate signature algorithm and encoding based upon the signing key used.
If the signing key is P-256, the signature MUST use ECDSA with SHA-256. When encoded, the `AlgorithmIdentifier` MUST be byte-for-byte identical with the following hex-encoded bytes: `300a06082a8648ce3d040302`.
If the signing key is P-384, the signature MUST use ECDSA with SHA-384. When encoded, the `AlgorithmIdentifier` MUST be byte-for-byte identical with the following hex-encoded bytes: `300a06082a8648ce3d040303`.
If the signing key is P-521, the signature MUST use ECDSA with SHA-512. When encoded, the `AlgorithmIdentifier` MUST be byte-for-byte identical with the following hex-encoded bytes: `300a06082a8648ce3d040304`.
### 7.1.4 Name Forms
Attribute values SHALL be encoded according to [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280).
This section details encoding rules that apply to all Certificates issued by a CA. Further restrictions may be specified within [Section 7.1.2](#712-certificate-content-and-extensions), but these restrictions do not supersede [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations).
#### 7.1.4.1 Name Encoding
The following requirements apply to all Certificates listed in [Section 7.1.2](#712-certificate-content-and-extensions).
For every valid Certification Path (as defined by [RFC 5280, Section 6](https://tools.ietf.org/html/rfc5280#section-6)):
- For each Certificate in the Certification Path, the encoded content of the Issuer Distinguished Name field of a Certificate SHALL be byte-for-byte identical with the encoded form of the Subject Distinguished Name field of the Issuing CA certificate.
- For each CA Certificate in the Certification Path, the encoded content of the Subject Distinguished Name field of a Certificate SHALL be byte-for-byte identical among all Certificates whose Subject Distinguished Names can be compared as equal according to [RFC 5280, Section 7.1](https://tools.ietf.org/html/rfc5280#section-7.1), and including expired and revoked Certificates.
When encoding a `Name`, the CA SHALL ensure that:
- Each `Name` MUST contain an `RDNSequence`.
- Each `RelativeDistinguishedName` MUST contain exactly one `AttributeTypeAndValue`.
- Each `RelativeDistinguishedName`, if present, is encoded within the `RDNSequence` in the order that it appears in [Section 7.1.4.2](#7142-subject-attribute-encoding).
- For example, a `RelativeDistinguishedName` that contains a `countryName` `AttributeTypeAndValue` pair MUST be encoded within the `RDNSequence` before a `RelativeDistinguishedName` that contains a `stateOrProvinceName` `AttributeTypeAndValue`.
- Each `Name` MUST NOT contain more than one instance of a given `AttributeTypeAndValue` across all `RelativeDistinguishedName`s unless explicitly allowed in [Section 1.1.1 Standards, Criteria and Regulations](#111-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](#712-certificate-content-and-extensions).
CAs that include attributes in the Certificate `subject` field that are listed in the table below SHALL encode those attributes in the relative order as they appear in the table and follow the specified encoding requirements for the attribute.
Table: Encoding and Order Requirements for Selected Attributes
| **Attribute** | **OID** | **Specification** | **Encoding Requirements** | **Max Length[^maxlength]** |
| ------------------------ | ---------------------------- | ----------------------------------------------- | ------------------------------------------ | -------------------------- |
| `domainComponent` | `0.9.2342.19200300.100.1.25` | [RFC 4519](https://tools.ietf.org/html/rfc4519) | MUST use `IA5String` | 63 |
| `countryName` | `2.5.4.6` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 2 |
| `stateOrProvinceName` | `2.5.4.8` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 |
| `localityName` | `2.5.4.7` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 |
| `organizationName` | `2.5.4.10` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 |
| `organizationalUnitName` | `2.5.4.11` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 |
| `commonName` | `2.5.4.3` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 |
CAs that include attributes in the Certificate `subject` field that are listed in the table below SHALL follow the specified encoding requirements for the attribute.
Table: Encoding Requirements for Selected Attributes
| **Attribute** | **OID** | **Specification** | **Encoding Requirements** | **Max Length[^maxlength]** |
| ------------------------ | ---------- | ----------------------------------------------- | ------------------------------------------ | -------------------------- |
| `businessCategory` | `2.5.4.15` | X.520 | MUST use `UTF8String` or `PrintableString` | 128 |
| `serialNumber` | `2.5.4.5` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 64 |
| `organizationIdentifier` | `2.5.4.97` | X.520 | MUST use `UTF8String` or `PrintableString` | None |
[^maxlength]: **Note**: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits.
#### 7.1.4.3 Subscriber Certificate Common Name Attribute
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](#712-certificate-content-and-extensions), CAs MAY include additional attributes within the `AttributeTypeAndValue` beyond those specified in [Section 7.1.4.2](#7142-subject-attribute-encoding).
### 7.1.5 Name constraints
No stipulation.
### 7.1.6 Certificate policy object identifier
#### 7.1.6.1 Reserved Certificate Policy Identifiers
The following Certificate Policy identifiers are reserved for use by CAs as an optional means of asserting that a Certificate complies with [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) .
| Reserved Certificate Policy Identifiers |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) code-signing-requirements(4) code signing(1)} (2.23.140.1.4.1)` |
| `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) mailbox-validated (1) strict (3)} (2.23.140.1.5.1.3)` |
| `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) organization-validated (2) legacy (1)} (2.23.140.1.5.2.1)` |
| `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) organization-validated (2) strict (3)} (2.23.140.1.5.2.3)` |
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
| **Field** | **Presence** | **Description** |
| ----------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `tbsCertList` | | |
| - `version` | MUST | MUST be v2(1), see [Section 7.2.1](#721-version-numbers) |
| - `signature` | MUST | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) |
| - `issuer` | MUST | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. |
| - `thisUpdate` | MUST | Indicates the issue date of the CRL. |
| - `nextUpdate` | MUST | Indicates the date by which the next CRL will be issued. For CRLs covering Subscriber Certificates, at most 10 days after the `thisUpdate`. For other CRLs, at most 12 months after the `thisUpdate`. |
| - `revokedCertificates` | * | MUST be present if the CA has issued a Certificate that has been revoked and the corresponding entry has yet to appear on at least one regularly scheduled CRL beyond the revoked Certificate's validity period. The CA SHOULD remove an entry for a corresponding Certificate after it has appeared on at least one regularly scheduled CRL beyond the revoked Certificate's validity period. See the "revokedCertificates Component" table for additional requirements. |
| - `extensions` | MUST | See the "CRL Extensions" table for additional requirements. |
| `signatureAlgorithm` | MUST | Encoded value MUST be byte-for-byte identical to the `tbsCertList.signature`. |
| `signature` | MUST | - |
| Any other value | NOT RECOMMENDED | - |
### 7.2.1 Version number(s)
Certificate Revocation Lists MUST be of type X.509 v2.
### 7.2.2 CRL and CRL entry extensions
Table: CRL Extensions
| **Extension** | **Presence** | **Critical** | **Description** |
| -------------------------- | --------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------ |
| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) |
| `CRLNumber` | MUST | N | MUST contain an INTEGER greater than or equal to zero (0) and less than 2¹⁵⁹, and convey a strictly increasing sequence. |
| `IssuingDistributionPoint` | * | Y | See [Section 7.2.2.1 CRL Issuing Distribution Point](#7221-crl-issuing-distribution-point) |
| Any other extension | NOT RECOMMENDED | - | - |
Table: revokedCertificates Component
| **Component** | **Presence** | **Description** |
| -------------------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
| `serialNumber` | MUST | MUST be byte-for-byte identical to the serialNumber contained in the revoked Certificate. |
| `revocationDate` | MUST | Normally, the date and time revocation occurred. See the footnote following this table for circumstances where backdating is permitted. |
| `crlEntryExtensions` | * | See the "crlEntryExtensions Component" table for additional requirements. |
Table: crlEntryExtensions Component
| **CRL Entry Extension** | **Presence** | **Description** |
| ----------------------- | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `reasonCode` | * | When present (OID 2.5.29.21), MUST NOT be marked critical and MUST indicate the most appropriate reason for revocation of the Certificate.
MUST be present unless the CRL entry is for a Certificate not technically capable of causing issuance and either 1) the CRL entry is for a Subscriber Certificate subject to revoked prior to 2023-07-15 or 2) the reason for revocation (i.e., reasonCode) is unspecified (0).
See the "CRLReasons" table for additional requirements. |
| Any other value | NOT RECOMMENDED | - |
Table: CRLReasons
| **RFC 5280 reasonCode** | **RFC 5280 reasonCode value** | **Description** |
| ----------------------- | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| unspecified | 0 | Represented by the omission of a reasonCode. MUST be omitted if the CRL entry is for a Certificate not technically capable of causing issuance unless the CRL entry is for a Subscriber Certificate subject to Baseline Requirements revoked prior to 2023-07-15. |
| keyCompromise | 1 | Indicates that it is known or suspected that the Subscriber’s Private Key has been compromised. |
| affiliationChanged | 3 | Indicates that the Subject's name or other Subject Identity Information in the Certificate has changed, but there is no cause to suspect that the Certificate's Private Key has been compromised. |
| superseded | 4 | Indicates that the Certificate is being replaced because: the Subscriber has requested a new Certificate, the CA has reasonable evidence that the validation of domain authorization in the Certificate should not be relied upon, or the CA has revoked the Certificate for compliance reasons such as the Certificate does not comply with [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) or the CA's CP or CPS. |
| cessationOfOperation | 5 | Indicates that the website with the Certificate is shut down prior to the expiration of the Certificate, or if the Subscriber no longer owns or controls the Domain Name in the Certificate prior to the expiration of the Certificate. |
| certificateHold | 6 | MUST NOT be included if the CRL entry is for 1) a Certificate subject to [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations), or 2) a Certificate not subject to [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) and was either A) issued on-or-after 2020-09-30 or B) has a `notBefore` on-or-after 2020-09-30. |
| privilegeWithdrawn | 9 | Indicates that there has been a subscriber-side infraction that has not resulted in keyCompromise, such as the Certificate Subscriber provided misleading information in their Certificate Request or has not upheld their material obligations under the Subscriber Agreement or Terms of Use. |
The Subscriber Agreement, or an online resource referenced therein, MUST inform Subscribers about the revocation reason options listed above and provide explanation about when to choose each option. Tools that the CA provides to the Subscriber MUST allow for these options to be easily specified when the Subscriber requests revocation of their Certificate, with the default value being that no revocation reason is provided (i.e. the default corresponds to the CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL).
The privilegeWithdrawn reasonCode SHOULD NOT be made available to the Subscriber as a revocation reason option, because the use of this reasonCode is determined by the CA and not the Subscriber.
When a CA obtains verifiable evidence of Key Compromise for a Certificate whose CRL entry does not contain a reasonCode extension or has a reasonCode extension with a non-keyCompromise reason, the CA SHOULD update the CRL entry to enter keyCompromise as the CRLReason in the reasonCode extension.
#### 7.2.2.1 CRL Issuing Distribution Point
Partitioned CRLs MUST contain an Issuing Distribution Point extension. The `distributionPoint` field of the Issuing Distribution Point extension MUST be present. Additionally, the `fullName` field of the DistributionPointName value MUST be present, and its value MUST conform to the following requirements:
1. If a Certificate within the scope of the CRL contains a CRL Distribution Points extension, then at least one of the `uniformResourceIdentifiers` in the CRL Distribution Points's `fullName` field MUST be included in the `fullName` field of the CRL's Issuing Distribution Point extension. The encoding of the `uniformResourceIdentifier` value in the Issuing Distribution Point extension SHALL be byte-for-byte identical to the encoding used in the Certificate's CRL Distribution Points extension.
2. Other GeneralNames of type `uniformResourceIdentifier` MAY be included.
3. Non-`uniformResourceIdentifier` GeneralName types MUST NOT be included.
The `indirectCRL` and `onlyContainsAttributeCerts` fields MUST be set to `FALSE` (i.e., not asserted).
The CA MAY set either of the `onlyContainsUserCerts` and `onlyContainsCACerts` fields to `TRUE`, depending on the scope of the CRL.
The CA MUST NOT assert both of the `onlyContainsUserCerts` and `onlyContainsCACerts` fields.
The `onlySomeReasons` field SHOULD NOT be included; if included, then the CA MUST provide another CRL whose scope encompasses all revocations regardless of reason code.
This extension is NOT RECOMMENDED for full and complete CRLs.
## 7.3 OCSP profile
If an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross-Certified Subordinate CA Certificates, and that certificate has been revoked, then the `revocationReason` field within the `RevokedInfo` of the `CertStatus` MUST be present.
The `CRLReason` indicated MUST contain a value permitted for CRLs, as specified in [Section 7.2.2](#722-crl-and-crl-entry-extensions).
### 7.3.1 Version number(s)
The CA uses OCSP Version 1.
### 7.3.2 OCSP extensions
The `singleExtensions` of an OCSP response MUST NOT contain the `reasonCode` (OID 2.5.29.21) CRL entry extension.
# 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
The CA SHALL at all times:
1. Issue Certificates and operate its PKI in accordance with all law applicable to its business and the Certificates it issues in every jurisdiction in which it operates;
2. Comply with Baseline Requirements;
3. Comply with the audit requirements specified in the CP/CPS; and
4. Be licensed as a CA in each jurisdiction where it operates, if licensing is required by the law of such jurisdiction for the issuance of Certificates.
## 8.1 Frequency or circumstances of assessment
Certificates that are capable of being used to issue new certificates MUST 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](#84-topics-covered-by-assessment), then, before issuing Publicly-Trusted Certificates, the CA SHALL successfully complete a point-in-time readiness assessment performed in accordance with applicable standards under one of the audit schemes listed in [Section 8.4](#84-topics-covered-by-assessment). The point-in-time readiness assessment SHALL be completed no earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates and SHALL be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate.
## 8.2 Identity/qualifications of assessor
The CA's audit SHALL be performed by a Qualified Auditor. A Qualified Auditor means a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively possess the following qualifications and skills:
1. Independence from the subject of the audit;
1. The ability to conduct an audit that addresses the criteria specified in an Eligible Audit Scheme (see [Section 8.4](#84-topics-covered-by-assessment));
1. Employs individuals who have proficiency in examining Public Key Infrastructure technology, information security tools and techniques, information technology and security auditing, and the third-party attestation function;
1. (For audits conducted in accordance with the WebTrust standard) licensed by WebTrust;
1. Bound by law, government regulation, or professional code of ethics; and
1. Except in the case of an Internal Government Auditing Agency, maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage
## 8.3 Assessor's relationship to assessed entity
Auditors shall be operationally and organizationally independent of the assessed entity, except for the audit-related aspects. In conducting the audits, the assessed entity shall provide appropriate support to the effort.
## 8.4 Topics covered by assessment
The CA SHALL undergo an audit in accordance with the following schemes:
1. WebTrust (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](#82-identityqualifications-of-assessor).
For Delegated Third Parties which are not Enterprise RAs, then the CA SHALL obtain an audit report, issued under the auditing standards that underlie the accepted audit schemes found in [Section 8.4](#84-topics-covered-by-assessment), that provides an opinion whether the Delegated Third Party's performance complies with either the Delegated Third Party's practice statement or the CA's CP/CPS. If the opinion is that the Delegated Third Party does not comply, then the CA SHALL not allow the Delegated Third Party to continue performing delegated functions.
The audit period for the Delegated Third Party SHALL NOT exceed one year (ideally aligned with the CA's audit).
## 8.5 Actions taken as a result of deficiency
SECOM Trust Systems promptly implements corrective measures with respect to the deficiencies identified in the audit report.
## 8.6 Communication of results
The Audit Report SHALL state explicitly that it covers the relevant systems and processes used in the issuance of all Certificates that assert one or more of the policy identifiers listed in [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers). The CA SHALL make the Audit Report publicly available.
The CA MUST make its Audit Report publicly available no later than three months after the end of the audit period. In the event of a delay greater than three months, the CA SHALL provide an explanatory letter signed by the Qualified Auditor.
The Audit Report MUST contain at least the following clearly-labelled information:
1. name of the organization being audited;
2. name and address of the organization performing the audit;
3. the SHA-256 fingerprint of all Roots and Subordinate CA Certificates, including Cross-Certified Subordinate CA Certificates, that were in-scope of the audit;
4. audit criteria, with version number(s), that were used to audit each of the certificates (and associated keys);
5. a list of the CA policy documents, with version numbers, referenced during the audit;
6. whether the audit assessed a period of time or a point in time;
7. the start date and end date of the Audit Period, for those that cover a period of time;
8. the point in time date, for those that are for a point in time;and
9. the date the report was issued, which will necessarily be after the end date or point in time date.
An authoritative English language version of the publicly available audit information MUST be provided by the Qualified Auditor and the CA SHALL ensure it is publicly available.
The Audit Report MUST be available as a PDF, and SHALL be text searchable for all information required. Each SHA-256 fingerprint within the Audit Report MUST be uppercase letters and MUST NOT contain colons, spaces, or line feeds.
## 8.7 Self-Audits
- S/MIME CA
During the period in which the CA issues Certificates, the CA SHALL monitor adherence to its CP/CPS and S/MIME Baseline Requirements and control its service quality by performing self audits on at least a quarterly basis against a randomly selected sample including a minimum of the greater of thirty (30) Certificates or three percent (3%) of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken.
Effective 2025-03-15 the CA SHOULD use a Linting process to verify the technical accuracy of Certificates within the selected sample set independently of previous linting performed on the same Certificates.
- Code Signing CA
CAs must abide by the self-audit requirements of Baseline Requirements for Code Signing Certificates. During the period in which it issues Code Signing Certificates, the CA MUST strictly control its service quality by performing ongoing self-audits against a randomly selected sample of at least three percent of the Non-EV Code Signing Certificates and at least three percent of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken. For all Code Signing Certificates where the final cross-correlation and due diligence requirements of Section 8 of Baseline Requirements for Code Signing Certificates is performed by an RA, the CA MUST strictly control its service quality by performing ongoing self-audits against a randomly selected sample of at least six percent of the Non-EV Code Signing Certificates and at least six percent of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken.
## 8.8 Review of delegated parties
Except for Delegated Third Parties, Enterprise RAs, and Technically Constrained Subordinate CAs that undergo an annual audit that meets the criteria specified in [Section 8.4](#84-topics-covered-by-assessment), the CA SHALL ensure the practices and procedures of delegated parties are in compliance with these Requirements and the relevant CP and/or CPS. The CA shall document the obligations of delegated parties and perform monitoring on at least an annual basis of the delegated parties' adherence with those obligations.
# 9. OTHER BUSINESS AND LEGAL MATTERS
## 9.1 Fees
### 9.1.1 Certificate issuance or renewal fees
Stipulated separately in contracts.
### 9.1.2 Certificate access fees
No stipulation.
### 9.1.3 Revocation or status information access fees
No stipulation.
### 9.1.4 Fees for other services
No stipulation.
### 9.1.5 Refund policy
Stipulated separately in contracts.
## 9.2 Financial responsibility
### 9.2.1 Insurance coverage
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](#86-communication-of-results) or unless it is required by law.
### 9.3.2 Information not within the scope of confidential information
Information populated in Certificates and CRLs is not considered confidential. In addition, the following information shall not be subject to the confidentiality provisions herein:
- Information that is or came to be known through no fault of SECOM Trust Systems;
- Information that was or is made known to SECOM Trust Systems by a party other than SECOM Trust Systems without confidentiality requirements;
- Information independently developed by SECOM Trust Systems; or
- Information approved for disclosure by the relevant Subscriber.
### 9.3.3 Responsibility to protect confidential information
SECOM Trust Systems may disclose confidential information when required by law or there is a prior consent of the relevant Subscriber. In the event of the foregoing, the party having come to acquire the information may not disclose said information to a third party due to contractual or legal constraints.
## 9.4 Privacy of personal information
### 9.4.1 Privacy plan
SECOM Trust Systems will use the personal information collected from the subscribers of our authentication service to the extent necessary for the operation of this CA operated on the Digital Certification Infrastructure, such as confirming the application details, sending necessary documents, etc., and confirming who is authorized. SECOM Trust Systems's privacy policy will be announced on SECOM Trust Systems's website ().
### 9.4.2 Information treated as private
SECOM Trust Systems treats information defined as personal information based on domestic laws and regulations (such as information collected from subscribers of SECOM authentication services) as personal information and manages it appropriately.
### 9.4.3 Information not deemed private
SECOM Trust Systems treats personal information as specified in [Section 9.4.2](#942-information-treated-as-private).
### 9.4.4 Responsibility to protect private information
SECOM Trust Systems shall not disclose any personal information of the other party that it has learned during the execution and termination of the contract to third parties, whether during or after the contract period. The personal information protection manager shall be appointed and ensure employees comply with personal information protection policy.
### 9.4.5 Notice and consent to use private information
SECOM Trust Systems shall not use personal information for any purpose other than the purpose of obtaining the consent of the certificate subscriber, except as provided by law. The personal number and specific personal information will be used for the purpose of use permitted by law and for the purpose of use with the consent of the certificate subscriber.
### 9.4.6 Disclosure pursuant to judicial or administrative process
If disclosure is requested by law, rule, court decision/order, administrative agency order /instruction, etc., the personal information of the certificate subscriber may be disclosed.
### 9.4.7 Other information disclosure circumstances
No stipulation.
## 9.5 Intellectual property rights
Unless otherwise agreed to between SECOM Trust Systems and Subscribers, the following informative materials and data pertaining to the Services shall belong to the parties specified as below:
| Property | Details |
| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Certificate | An asset belonging to SECOM Trust Systems. |
| CRL | An asset belonging to SECOM Trust Systems. |
| Distinguished Name (DN) | An asset belonging to an entity to which the Name is assigned as long as the fee for the Subscriber Certificate is properly paid. |
| Subscriber Private Key | An asset belonging the possessor of the Private Key that completes a Key Pair with the Public Key, regardless of how it is stored or who possesses the storage medium. |
| Subscriber Public Key | An asset belonging the possessor of the Private Key that completes a Key Pair, regardless of how it is stored or who possesses the storage medium. |
| This CP/CPS | An asset (including the copyrights) belonging to SECOM Trust Systems. This CP/CPS may be reproduced provided that the original document is properly referenced. It is published under the Creative Commons license Attribution-NoDerivatives (CC-BY-ND) 4.0. |
## 9.6 Representations and warranties
### 9.6.1 CA representations and warranties
By issuing a Certificate, the CA makes the certificate warranties listed herein to the following Certificate Beneficiaries:
1. The Subscriber that is a party to the Subscriber Agreement or Terms of Use for the Certificate;
2. All Application Software Suppliers with whom the Root CA has entered into a contract for inclusion of its Root Certificate in software distributed by such Application Software Supplier; and
3. All Relying Parties who reasonably rely on a Valid Certificate.
The CA represents and warrants to the Certificate Beneficiaries that, during the period when the Certificate is valid, the CA has complied with [Section 1.1.1 Standards, Criteria and Regulations](#111-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;
1. **Compliance**. The CA has complied with [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) in issuing each certificate and operating its PKI or delegated services.
1. **Authorization for Certificate**: That, at the time of issuance, the CA
i. implemented a procedure for verifying that the Subject authorized the issuance of the Certificate and that the Applicant Representative is authorized to request the Certificate on behalf of the Subject;
ii. followed the procedure when issuing the Certificate; and
iii. accurately described the procedure in the CA's CP/CPS;
1. **Accuracy of Information**: That, at the time of issuance, the CA
i. implemented a procedure for verifying the accuracy of all of the information contained in the Certificate;
ii. followed the procedure when issuing the Certificate; and
iii. accurately described the procedure in the CA's CP/CPS;
1. **Key Protection:** The CA represents that it provided the Subscriber at the time of issuance with documentation on how to securely store and prevent the misuse of Private Keys associated with Code Signing Certificates and AATL Document Signing Certificates.
1. **Identity of Applicant**: That, if the Certificate contains Subject Identity Information, the CA
i. implemented a procedure to verify the identity of the Applicant in accordance with [Section 3.2](#32-initial-identity-validation) and [Section 7.1.2](#712-certificate-content-and-extensions);
ii. followed the procedure when issuing the Certificate; and
iii. accurately described the procedure in the CA's CP/CPS;
1. **Subscriber Agreement**: That, if the CA and Subscriber are not Affiliated, the Subscriber and CA are parties to a legally valid and enforceable Subscriber Agreement that satisfies [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations), or, if the CA and Subscriber are the same entity or are Affiliated, the Applicant Representative acknowledged the Terms of Use;
1. **Status**: That the CA maintains a 24 x 7 publicly-accessible Repository with current information regarding the status (valid or revoked) of all unexpired Certificates; and
1. **Revocation**: That the CA will revoke the Certificate for any of the reasons specified in [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations).
The Root CA SHALL be responsible for the performance and warranties of the Subordinate CA, for the Subordinate CA's compliance with [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations), and for all liabilities and indemnification obligations of the Subordinate CA under [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations), as if the Root CA were the Subordinate CA issuing the Certificates
### 9.6.2 RA representations and warranties
Same as this CP/CPS [Section 9.6.1](#961-ca-representations-and-warranties).
### 9.6.3 Subscriber representations and warranties
The CA SHALL require, as part of the Subscriber Agreement or Terms of Use, that the Applicant make the commitments and warranties in this section for the benefit of the CA and the Certificate Beneficiaries.
**[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](#111-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](#627-private-key-storage-on-cryptographic-module), the Private Key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device, e.g. password or token). The CA MUST provide the Subscriber with documentation on how to protect a Private Key. The CA MAY provide this documentation as a white paper or as part of the Subscriber Agreement. The Subscriber MUST represent that it will generate and operate any device storing Private Keys in a secure manner, as described in a document of code signing best practices, which the CA MUST provide to the Subscriber during the ordering process. The CA MUST obligate the Subscriber to use passwords that are randomly generated with at least 16 characters containing uppercase letters, lowercase letters, numbers, and symbols to transport Private Keys.
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](#111-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](#627-private-key-storage-on-cryptographic-module), the Private Key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device, e.g. password or token). The CA MUST provide the Subscriber with documentation on how to protect a Private Key. The CA MAY provide this documentation as a white paper or as part of the Subscriber Agreement.
The Subscriber 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](#111-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](#961-ca-representations-and-warranties) and [Section 9.6.2](#962-ra-representations-and-warranties) hereof, or for lost earnings, loss of data, or any other indirect or consequential damages.
## 9.8 Limitations of liability
In this CP/CPS, the CA shall not be liable for the provisions of "9.6.1 CA representations and warranties” and "9.6.2 RA representations and warranties" hereof in the following cases.
- any damage arising from unlawful conduct, unauthorized use, negligence or any other cause not attributable to the CA;
- all liability in any case if the confirmed information error is the result of the applicant's fraud or willful misconduct.
- any damage attributable to the failure of a Subscriber to perform its obligations;
- any damage attributable to a Subscriber or Relying Party system;
- damages attributable to the defect or malfunction or any other behavior of the Subscriber environment (hardware or software);
- Any damage during the period that a Subscriber neglected to pay the subscription fee as set forth in the agreement thereof;
- damages caused by information published in a Certificate, a CRL or on the OCSP responder due to the reasons not attributable to the CA;
- any damage incurred in an outage of the normal communication due to reasons not attributable to the CA;
- any damage arising in connection with the use of a Certificate, including transaction debts;
- any damage caused by the Delegated Third Party’s failure to fulfill its service provision obligations, such as the termination of service provision by them;
- any damages attributable to improvement, beyond expectations at this point in time, in hardware or software type of cryptographic algorithm decoding skills;
- any damage attributable to the suspension of the CA's operations due to force majeure, including, but not limited to, natural disasters, earthquakes, volcanic eruptions, fires, tsunami, floods, lightning strikes, wars, civil commotion and terrorism.
## 9.9 Indemnities
Notwithstanding any limitations on its liability to Subscribers and Relying Parties, the CA understands and acknowledges that the Application Software Suppliers who have a Root Certificate distribution agreement in place with the Root CA do not assume any obligation or potential liability of the CA under [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) or that otherwise might exist because of the issuance or maintenance of Certificates or reliance thereon by Relying Parties or others. Thus, the CA SHALL defend, indemnify, and hold harmless each Application Software Supplier for any and all claims, damages, and losses suffered by such Application Software Supplier related to a Certificate issued by the CA, regardless of the cause of action or legal theory involved. This does not apply, however, to any claim, damages, or loss suffered by such Application Software Supplier related to a Certificate issued by the CA where such claim, damage, or loss was directly caused by such Application Software Supplier's software displaying as not trustworthy a Certificate that is still valid, or displaying as trustworthy:
(1) a Certificate that has expired, or
(2) a Certificate that has been revoked (but only in cases where the revocation status is currently available from the CA online, and the application software either failed to check such status or ignored an indication of revoked status).
## 9.10 Term and termination
### 9.10.1 Term
This CP/CPS goes into effect upon approval by this Committee.
This CP/CPS will in no way lose effect under any circumstances prior to the termination stipulated in [Section 9.10.2](#9102-termination) hereof.
### 9.10.2 Termination
This CP/CPS loses effect as of the termination hereof by the CA, with the exception of the provisions stipulated in [Section 9.10.3](#9103-effect-of-termination-and-survival) hereof.
### 9.10.3 Effect of termination and survival
Even in the event of termination of the use of a Certificate by a Subscriber or the termination of a service provided by the Delegated Third Party, or the CA closes its business, provisions that should remain in effect, due to the nature thereof, shall survive any such termination, regardless of the reasons therefor, and remain in full force and effect with respect to any Subscriber and the CA.
## 9.11 Individual notices and communications with participants
The CA provides the necessary notices to the Delegated Third Party, then the Delegated Third Party provides the necessary notice to Subscribers and Relying Parties through its website, e-mail or in other written forms.
## 9.12 Amendments
### 9.12.1 Procedure for amendment
1. Critical revisions/amendments
SECOM Trust Systems notifies Subscribers and Relying Parties of amendments of this CP/CPS if the amendments thereof are determined to have an obvious impact on the activities for use of Certificates or CRLs by the Subscribers and Relying Parties, by publishing the post-amendment version of this CP/CPS (including the Version History/Description/Date) in the Repository, while refreshing the Major Version Number.
2. Non-critical revisions/amendments
SECOM Trust Systems notifies Subscribers and Relying Parties of amendments of this CP/CPS if the amendments thereof are determined to have no or less impact on the activities for use of Certificates or CRLs by the Subscribers and Relying Parties, by publishing the post-amendment version of this CP/CPS (including the Version History/Description/Date) in the Repository, while refreshing the Minor Version Number.
This CP/CPS shall be revised by the CA as appropriate and goes into effect upon approval by 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](#111-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](#111-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](#9163-severability) 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 (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 `
The CAA contactemail property takes an email address as its parameter. The entire parameter value MUST be a valid email address as defined in RFC 6532, Section 3.2, with no additional padding or structure, or it cannot be used.
The following is an example where the holder of the domain specified the contact property using an email address.
```DNS Zone
$ORIGIN example.com.
CAA 0 contactemail "domainowner@example.com"
```
The contactemail property MAY be critical, if the domain owner does not want CAs who do not understand it to issue certificates for the domain.
## A.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
| Basic Field | Description |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| version | 3 (0x2) |
| serialNumber | For Root CA
0
For Subordinate CA
Unique value within CA |
| signature | sha256WithRSAEncryption |
| issuer | C = JP
O = SECOM Trust Systems CO.,LTD.
OU = Security Communication RootCA2 |
| validity | For Root CA
From: May 29 05:00:39 2009 GMT
To: May 29 05:00:39 2029 GMT
For Subordinate CA
From: Certificate issued date
To: Set as stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | For Root CA
C = JP
O = SECOM Trust Systems CO.,LTD.
OU = Security Communication RootCA2
For Subordinate CA
Set the Subordinate CA Subscriber information |
| subjectPublicKeyInfo | For Root CA
Public Key Algorithm: rsaEncryption
Public-Key: 2048 bit
For Subordinate CA
The Public Key algorithm identifier and the Public Key data of the Subordinate CA Subscriber |
| Extension Field | Description | critical |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | For Root CA
Not present
For Subordinate CA
160bit value obtained by hashing the CA public key using SHA-1 | N |
| subjectKeyIdentifier | 160bit value obtained by hashing the Subscriber public key using SHA-1 | N |
| keyUsage | keyCertSign, cRLSign（Purpose of use of the Subscriber public key） | Y |
| extendedKeyUsage | For Root CA
Not present
For Subordinate CA
Be sure to set this after 2019-01-01, but do not set anyExtendedKeyUsage.
Do not set id-kp-serverAuth and id-kp-emailProtection at the same time.
Set id-kp-codeSigning independently.
For Cross Certificates, set as necessary. | N |
| certificatePolicies | For Root CA
Not present
For Subordinate CA
policyIdentifier
- certPolicyId=1.2.392.200091.100.901.4, CA/Browser Forum Reserved Certificate Policy Identifier (If this is included and issued after 2023-09-15, it is recommended to set it first),1.2.392.200091.100.721.1 or any Policy \*1
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS=`http(s)://repository.secomtrust.net/SC-Root2/`
\* () is operational
policyQualifier is not recommended for TLS DV/OV CAs | N |
| basicConstraints | Subject Type=CA
pathLenConstraints（Set as necessary with the CA） | Y |
| nameConstraints | For Root CA
Not present
For Subordinate CA
If present, it should be set to Critical. | Y |
| cRLDistributionPoints | For Root CA
Not present
For Subordinate CA
URI: `http://repository.secomtrust.net/SC-Root2/SCRoot2CRL.crl` | N |
| authorityInformationAccess | For Root CA
Not present
For Subordinate CA
accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI :`http://scrootca2.ocsp.secomtrust.net`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repository.secomtrust.net/SC-Root2/SCRoot2ca.cer`
\* Set OCSP, CA Issuers as necessary | N |
---
## Table : "Security Communication RootCA3" and Subordinate CAs
Root CA Certificate SHA256 Fingerprint:
24A55C2AB051442D0617766541239A4AD032D7C55175AA34FFDE2FBC4F5C5294
| Basic Field | Description |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| version | 3 (0x2) |
| serialNumber | For Root CA
E17C3740FD1BFE67
For Subordinate CA
Unique value within CA |
| signature | sha384WithRSAEncryption |
| issuer | C = JP
O = SECOM Trust Systems CO.,LTD.
CN = Security Communication RootCA3 |
| validity | For Root CA
From: Jun 16 06:17:16 2016 GMT
To: Jan 18 06:17:16 2038 GMT
For Subordinate CA
From: Certificate issued date
To: Set as stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | For Root CA
C = JP
O = SECOM Trust Systems CO.,LTD.
CN = Security Communication RootCA3
For Subordinate CA
Set the Subordinate CA Subscriber information |
| subjectPublicKeyInfo | For Root CA
Public Key Algorithm: rsaEncryption
Public-Key: 4096 bit
For Subordinate CA
The Public Key algorithm identifier and the Public Key data of the Subordinate CA Subscriber |
| Extension Field | Description | critical |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | For Root CA
Not present
For Subordinate CA
160bit value obtained by hashing the CA public key using SHA-1 | N |
| subjectKeyIdentifier | 160bit value obtained by hashing the Subscriber public key using SHA-1 | N |
| keyUsage | keyCertSign, cRLSign（Purpose of use of the Subscriber public key） | Y |
| extendedKeyUsage | For Root CA
Not present
For Subordinate CA
Be sure to set this after 2019-01-01, but do not set anyExtendedKeyUsage.
Set one of the following:
(1) id-kp-serverAuth
(2) id-kp-serverAuth and id-kp-clientAuth
(3)Adobe Authentic Documents Trust (1.2.840.113583.1.1.5)
(4) Microsoft Signer of documents (1.3.6.1.4.1.311.10.3.12）
(5) id-kp-codeSigning
(6) id-kp-timeStamping
For Cross Certificates, set as necessary.
(3) and (4) can be set at the same time. | N |
| certificatePolicies | For Root CA
Not present
For Subordinate CA
policyIdentifier
- certPolicyId=1.2.392.200091.100.901.6,
CA/Browser Forum Reserved Certificate Policy Identifier (If this is included and issued after 2023-09-15, it is recommended to set it first)
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS=`http(s)://repository.secomtrust.net/SC-Root3/`
\* () is optional
policyQualifier is not recommended for TLS DV/OV CAs | N |
| basicConstraints | Subject Type=CA
pathLenConstraints（Set as necessary with the CA） | Y |
| nameConstraints | For Root CA
Not present
For Subordinate CA
If present, it should be set to Critical. | Y |
| cRLDistributionPoints | For Root CA
Not present
For Subordinate CA
URI: `http://repository.secomtrust.net/SC-Root3/SCRoot3CRL.crl` | N |
| authorityInformationAccess | For Root CA
Not present
For Subordinate CA
accessmethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://scrootca3.ocsp.secomtrust.net`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repository.secomtrust.net/SC-Root3/SCRoot3ca.cer`
\* Set OCSP, CA Issuers as necessary | N |
---
## Table : "SECOM RSA Root CA 2023" and Subordinate CAs
Root CA Certificate SHA256 Fingerprint:
2C154235528D701790B675AFF6E1970827B10ED665E913835BF46E3460FD5C84
| Basic Field | Description |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| version | 3 (0x2) |
| serialNumber | For Root CA
99B8098D4418DDDB
For Subordinate CA
Unique value within CA |
| signature | sha384WithRSAEncryption |
| issuer | C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM RSA Root CA 2023 |
| validity | For Root CA
From: Jan 25 08:03:37 2023 GMT
To: Jan 1 08:03:37 2048 GMT
For Subordinate CA
From: Certificate issued date
To: Set as stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | For Root CA
C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM RSA Root CA 2023
For Subordinate CA
Set the Subordinate CA Subscriber information |
| subjectPublicKeyInfo | For Root CA
Public Key Algorithm: rsaEncryption
Public-Key: 4096 bit
For Subordinate CA
The Public Key algorithm identifier and the Public Key data of the Subordinate CA Subscriber |
| Extension Field | Description | critical |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | For Root CA
Not present
For Subordinate CA
160bit value obtained by hashing the CA public key using SHA-1 | N |
| subjectKeyIdentifier | 160bit value obtained by hashing the Subscriber public key using SHA-1 | N |
| keyUsage | keyCertSign, cRLSign（Purpose of use of the Subscriber public key） | Y |
| extendedKeyUsage | For Root CA
Not present
For Subordinate CA
Set one of the following:
(1) Microsoft Signer of documents (1.3.6.1.4.1.311.10.3.12)
(2) id-kp-documentSigning (1.3.6.1.5.5.7.3.36)
(1) and (2) can be set at the same time.
For Cross Certificates, set as necessary. | N |
| certificatePolicies | For Root CA
Not present
For Subordinate CA
policyIdentifier
- certPolicyId=1.2.392.200091.100.901.9
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS= `http://repo1.secomtrust.net/root/rsa/` | N |
| basicConstraints | Subject Type=CA
pathLenConstraints（Set as necessary） | Y |
| nameConstraints | Not present | - |
| cRLDistributionPoints | For Root CA
Not present
For Subordinate CA
URI: `http://repo1.secomtrust.net/root/rsa/rsarootca2023.crl` | N |
| authorityInformationAccess | For Root CA
Not present
For Subordinate CA
accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://rsarootca2023.ocsp.secom-cert.jp`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repo2.secomtrust.net/root/rsa/rsarootca2023.cer`
\* Set OCSP, CA Issuers as necessary | N |
---
## Table : "SECOM Document Signing RSA Root CA 2023" and Subordinate CAs
Root CA Certificate SHA256 Fingerprint:
46219BBF9148F00E8B7A4C619B57CF7602701FF81348400718870FABD31FC5BE
| Basic Field | Description |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| version | 3 (0x2) |
| serialNumber | For Root CA
E3A2A1C4FE81A10D
For Subordinate CA
Unique value within CA |
| signature | sha384WithRSAEncryption |
| issuer | C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM Document Signing RSA Root CA 2023
OrganizationIdentifier (2.5.4.97) = NTRJP-4011001040781 |
| validity | For Root CA
From: Jan 25 08:33:59 2023 GMT
To: Jan 1 08:33:59 2048 GMT
For Subordinate CA
From: Certificate issued date
To: Set as stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | For Root CA
C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM Document Signing RSA Root CA 2023
OrganizationIdentifier (2.5.4.97) = NTRJP-4011001040781
For Subordinate CA
Set the Subordinate CA Subscriber information |
| subjectPublicKeyInfo | For Root CA
Public Key Algorithm: rsaEncryption
Public-Key: 4096 bit
For Subordinate CA
The Public Key algorithm identifier and the Public Key data of the Subordinate CA Subscriber |
| Extension Field | Description | critical |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | For Root CA
Not present
For Subordinate CA
160bit value obtained by hashing the CA public key using SHA-1 | N |
| subjectKeyIdentifier | 160bit value obtained by hashing the Subscriber public key using SHA-1 | N |
| keyUsage | keyCertSign, cRLSign（Purpose of use of the Subscriber public key） | Y |
| extendedKeyUsage | For Root CA
Not present
For Subordinate CA
Set one of the following:
(1) Adobe Authentic Documents Trust (1.2.840.113583.1.1.5)
(2) id-kp-timeStamping
For Cross Certificates, set as necessary. | N |
| certificatePolicies | For Root CA
Not present
For Subordinate CA
policyIdentifier
- certPolicyId=1.2.392.200091.100.901.10
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS= `http://repo1.secomtrust.net/root/docrsa/` | N |
| basicConstraints | Subject Type=CA
pathLenConstraints（Set as necessary） | Y |
| nameConstraints | Not present | - |
| cRLDistributionPoints | For Root CA
Not present
For Subordinate CA
URI: `http://repo1.secomtrust.net/root/docrsa/docrsarootca2023.crl`
| N |
| authorityInformationAccess | For Root CA
Not present
For Subordinate CA
accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://docrsarootca2023.ocsp.secom-cert.jp`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repo2.secomtrust.net/root/docrsa/docrsarootca2023.cer`
\* Set OCSP, CA Issuers as necessary | N |
---
## Table : "SECOM SMIME RSA Root CA 2024" and Subordinate CA
Root CA Certificate SHA256 Fingerprint:
3629E7188E00A7CB3232C4426BC84912F1218B1A9AE676C0B0ABE1DBFE2182B5
| Basic Field | Description |
| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | For Root CA
DDA9DB9E7EBCD46D
For Subordinate CA
Unique value within CA |
| signature | sha384WithRSAEncryption |
| issuer | C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM SMIME RSA Root CA 2024 |
| validity | For Root CA
Start Date：Jan 31 06:23:06 2024 GMT
End Date:：Jan 14 06:23:06 2049 GMT
For Subordinate CA
Start Date：Certificate Issued Date
End Date:：Set as specified in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | For Root CA
C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM SMIME RSA Root CA 2024
For Subordinate CA
Set Subscriber information for Subordinate CA |
| subjectPublicKeyInfo | For Root CA
Public Key Algorithm: rsaEncryption
Public-Key: 4096 bit
For Subordinate CA
Public key algorithm identifier and public key data of Subordinate CA Subscribers |
| Extension Field | Description | critical |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | 160bit value obtained by hashing the CA public key using SHA-1 | N |
| subjectKeyIdentifier | 160bit value obtained by hashing the Subscriber public key using SHA-1 | N |
| keyUsage | keyCertSign, cRLSign（Purpose of use of the Subscriber public key） | Y |
| extendedKeyUsage | For Root CA
Not present
For Subordinate CA
Set the following:
id-kp-emailProtection
For Cross Certificates, set as necessary. | N |
| certificatePolicies | For Root CA
Not present
For Subordinate CA
policyIdentifier
- CA/Browser Forum Reserved Certificate Policy Identifier (it is recommended to set it first), certPolicyId= 1.2.392.200091.100.901.12
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS=`http://repo1.secomtrust.net/root/smimersa/` | N |
| basicConstraints | Subject Type=CA
pathLenConstraints（Set as necessary） | Y |
| nameConstraints | For Root CA
Not present
For Subordinate CA
If present, it should be set to Critical. | Y |
| cRLDistributionPoints | For Root CA
Not present
For Subordinate CA
URI: `http://repo1.secomtrust.net/root/smimersa/smimersarootca2024.crl` | N |
| authorityInformationAccess | For Root CA
Not present
For Subordinate CA
accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://smimersarootca2024.ocsp.secom-cert.jp`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repo2.secomtrust.net/root/smimersa/smimersarootca2024.cer`
\* Set OCSP, CA Issuers as necessary | N |
---
## Table : Subscriber Certificates (Client Authentication Certificate and Document Signing Certificates)
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | sha256WithRSAEncryption |
| issuer | countryName = JP
organizationName = Set the CA’s Organization
organizationalUnitName = The CA's Organizational Unit can be set
commonName = Set the CA’s Common Name |
| validity | notBefore = A value within 48 hours before the certificate signing
notAfter=Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | countryName = JP
stateOrProvinceName = State or Province Name (Optional)
localityName = Locality Name (Optional)
organizationName = Organization Name
organizationalUnitName = Organizational Unit (Optional)
commonName = Subscriber Name
serialNumber = Serial Number (Optional) |
| subjectPublicKeyInfo | Subject's Public Key Data |
| Extension Fields | Settings | critical |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | Authority Public Key Identifier
160bit value obtained by hashing the CA public key using SHA-1 | N |
| subjectKeyIdentifier | Subject Public Key Identifier
160bit value obtained by hashing the Subscriber public key using SHA-1 | N |
| keyUsage | The following can be set:
digitalSignature
Non Repudiation
keyEncipherment
dataEncipherment | Y |
| certificatePolicies | The following can be set:
Policy: 1.2.392.200091.100.381.4 (Client Authentication Certificates)
Policy: 1.2.392.200091.100.381.5 (Document Signing Certificates)
CPS: Repository URL | N |
| subjectAltName | The following can be set:
OtherName: UPN="User Principal Name"
OtherName: "OID"=" Any character string "
Rfc822Name: " Mail address" (Can be set up to 2023-08-31) | N |
| extendedKeyUsage | The following can be set:
id-kp-clientAuth
id-kp-emailProtection (Can be set up to 2023-08-31)
SmartCard Logon
Adobe Authentic Documents Trust = 1.2.840.113583.1.1.5
Microsoft Signer of documents = 1.3.6.1.4.1.311.10.3.12
＊When SmartCard Logon is selected, also select id-kp-clientAuth | N |
| cRLDistributionPoints | HTTP URL of the CA's CRL service
ldap://repo1.secomtrust.net/"IssuerDN"?certificateRevocationList
＊ldap is set as required | N |
| authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
OCSP Responder URL
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
URL of the Subordinate CA Certificate
\* Set OCSP, CA Issuers as necessary | N |
| Netscape Certificate Type | The following can be set:
SSL Client
S/MIME Client (Can be set up to 2023-08-31) | N |
---
## Table : Subscriber Certificates (Code Signing Certificates, Not be issued after 2024-05-01)
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | sha256WithRSAEncryption |
| issuer | countryName = JP
organizationName = Set the CA’s Organization
commonName = Set the CA’s Common Name |
| validity | notBefore = A value within 48 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | countryName = JP
stateOrProvinceName = State Or ProvinceName
localityName = Locality Name
organizationName = Organization Name
organizationalUnitName = Organizational Unit (Optional)
commonName = Subscriber Name |
| subjectPublicKeyInfo | Subject's RSA Public Key Data（3072bit or 4096bit） |
| Extension Fields | Settings | critical |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | Authority Public Key Identifier
160-bit SHA-1 hash value of Authority Public key | N |
| subjectKeyIdentifier | Subject Public Key Identifier
160-bit SHA-1 hash value of the Subject Public key | N |
| keyUsage | digitalSignature | Y |
| certificatePolicies | Policy: 1.2.392.200091.100.381.8
CPS: Repository URL
Policy: 2.23.140.1.4.1（Certificate Policy for Code Signing） | N |
| subjectAltName | - | - |
| extKeyUsage | id-kp-codeSigning | N |
| crlDistributionPoints | HTTP URL of the CA's CRL service | N |
| authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
OCSP Responder URL
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
URL of the Subordinate CA Certificate | N |
---
## Table: Subscriber Certificates (AATL Document Signing Certificates)
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | Set one of the following：
sha256WithRSAEncryption
sha384WithRSAEncryption |
| issuer | countryName = JP
organizationName = SECOM Trust Systems Co., Ltd.
commonName = Set the CA’s Common Name
organizationIdentifier(2.5.4.97) = NTRJP-4011001040781
(NTRJP-Corporation Number of the CA) |
| validity | notBefore = A value within 48 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | countryName = JP
stateOrProvinceName = state Or Province Name (Optional)
localityName = locality Name (Optional)
organizationName = Organization Name (Do not set for individual use)
organizationalUnitName = Organizational Unit (Optional)
commonName = Subscriber Name
serialNumber = Serial number (Optional)
organizationIdentifier(2.5.4.97) = NTRJP-Organization Corporate Number (Optional) |
| subjectPublicKeyInfo | Subject's Public Key Data |
| Extension Fields | Settings | critical |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | Authority Public Key Identifier
160-bit SHA-1 hash value of Authority Public key | N |
| subjectKeyIdentifier | Subject Public Key Identifier
160-bit SHA-1 hash value of the Subject Public key | N |
| keyUsage | digitalSignature
Non Repudiation | Y |
| certificatePolicies | Policy: 1.2.392.200091.100.382.1
CPS: Repository URL | N |
| subjectAltName | - | - |
| extKeyUsage | Adobe Authentic Documents Trust = 1.2.840.113583.1.1.5 | N |
| crlDistributionPoints | HTTP URL of the CA's CRL service | N |
| authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
OCSP Responder URL
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
URL of the Subordinate CA Certificate
\* Set OCSP, CA Issuers as necessary | N |
---
## Table: Subscriber Certificates (S/MIME Certificates)
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).
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | Set one of the following：
sha256WithRSAEncryption
sha384WithRSAEncryption |
| issuer | countryName = JP
organizationName = Set the CA’s Organization
commonName = Set the CA’s Common Name |
| validity | notBefore = A value within 48 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | commonName = Mail address |
| subjectPublicKeyInfo | Subject's Public Key Data |
| Extension Fields | Settings | critical |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | Authority Public Key Identifier
160-bit SHA-1 hash value of Authority Public key | N |
| subjectKeyIdentifier | Subject Public Key Identifier
160-bit SHA-1 hash value of the Subject Public key | N |
| keyUsage | digitalSignature
keyEncipherment | Y |
| certificatePolicies | CA/Browser Forum Reserved Certificate Policy Identifier (Recommended to set first)
Policy: 1.2.392.200091.100.383.1 (Optional)
CPS: Repository URL (Optional) | N |
| subjectAltName | Rfc822Name: "Mail address" | N |
| extKeyUsage | id-kp-emailProtection | N |
| crlDistributionPoints | HTTP URL of the CA's CRL service | N |
| authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
URL of the OCSPResponder
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
URL of the Subordinate CA Certificate
\* Set OCSP, CA Issuers as necessary | N |
---
## Table: Security Communication RootCA2 TSA, TA Certificates (Issued before 2018-09-26)
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | sha256WithRSAEncryption |
| issuer | Information about the issuer (specified by the CAs) |
| validity | notBefore = A value within 24 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | Subscriber information |
| subjectPublicKeyInfo | Subject's Public Key Data |
| Extension Fields | Settins | critical |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | A 160-bit SHA-1 hash for CA Public Key | N |
| subjectKeyIdenrifier | A 160-bit SHA-1 hash for Subscriber Public Key | N |
| keyUsage | digitalSignature
\* Other usages than keyCertSign and cRLSign may be specified by the CAs as necessary. | Y/N |
| certificatePolicies | policyIdentifier
certPolicyId=1.2.392.200091.100.901.5
policyQualifiers
policyQualifierID=id-qt-cps
qualifier=CPS=`https://repository.secomtrust.net/SC-Root2/` | N |
| subjectAltName | - | - |
| extKeyUsage | id-kp-timeStamping | Y/N |
| cRLDistributionPoints | URI:`http://repository.secomtrust.net/SC-Root2/SCRoot2CRL.crl` | N |
| authorityInformationAccess | accessMethod
id-ad-ocsp（1.3.6.1.5.5.7.48.1)
accessLocation
URI:`http://scrootca2.ocsp.secomtrust.net` (Optional if cRLDistributionPoints is present) | N |
---
## Table: Security Communication RootCA3 TSA, TA Certificates (Issued before 2018-09-26)
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | Set one of the following：
sha256WithRSAEncryption
sha384WithRSAEncryption |
| issuer | Information about the issuer (specified by the CAs) |
| validity | notBefore = A value within 24 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | Subscriber information |
| subjectPublicKeyInfo | Subject's RSA Public Key Data (At least 2048 bit) |
| Extension Fields | Settins | critical |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | A 160-bit SHA-1 hash for CA Public Key | N |
| subjectKeyIdenrifier | A 160-bit SHA-1 hash for Subscriber Public Key | N |
| keyUsage | digitalSignature
\* Other usages than keyCertSign and cRLSign may be specified by the CAs as necessary. | Y/N |
| certificatePolicies | policyIdentifier
certPolicyId=1.2.392.200091.100.901.7
policyQualifiers
policyQualifierID=id-qt-cps
qualifier=CPS=`https://repository.secomtrust.net/SC-Root3/` | N |
| subjectAltName | - | - |
| extKeyUsage | id-kp-timeStamping | Y/N |
| cRLDistributionPoints | URI:`http://repository.secomtrust.net/SC-Root3/SCRoot3CRL.crl`
\* Optional if id-ad-ocsp accessMethod is present in the authorityInformationAccess extension. | N |
| authorityInformationAccess | accessMethod
id-ad-ocsp（1.3.6.1.5.5.7.48.1)
accessLocation
URI:`http://scrootca3.ocsp.secomtrust.net` (Optional if cRLDistributionPoints is present) | N |
---
## Table: Security Communication RootCA3 TimeStamping Subordinate CA Certificates (Issued after 2018-06-07)
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | Set one of the following：
sha256WithRSAEncryption
sha384WithRSAEncryption |
| issuer | Information about the issuer (specified by the CAs) |
| validity | notBefore = A value within 24 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | Subscriber information |
| subjectPublicKeyInfo | Subject's Public Key Data |
| Extension Fields | Settins | critical |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | A 160-bit SHA-1 hash for CA Public Key | N |
| subjectKeyIdenrifier | A 160-bit SHA-1 hash for Subscriber Public Key | N |
| keyUsage | keyCertSign, cRLSign | Y |
| basicConstraints | Subject Type=CA
pathLenConstraints（The CA sets as necessary） | Y |
| certificatePolicies | policyIdentifier
certPolicyId=1.2.392.200091.100.901.7
policyQualifiers
policyQualifierID=id-qt-cps
qualifier=CPS=`http(s)://repository.secomtrust.net/SC-Root3/` (Optional)
\* ( ) is optional | N |
| subjectAltName | - | - |
| extKeyUsage | Be sure to set this after 2019-01-01, but do not set anyExtendedKeyUsage.
id-kp-timeStamping | N |
| cRLDistributionPoints | URI:`http://repository.secomtrust.net/SC-Root3/SCRoot3CRL.crl`
\* Optional if id-ad-ocsp accessMethod is present in the authorityInformationAccess extension. | N |
| authorityInformationAccess | accessMethod
id-ad-ocsp（1.3.6.1.5.5.7.48.1)
accessLocation
URI:`http://scrootca3.ocsp.secomtrust.net` (Optional if cRLDistributionPoints is present)
id-ad-caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI:`http://repository.secomtrust.net/SC-Root3/SCRoot3ca.cer`
\* Set OCSP, CA Issuers as necessary | N |
---
## Table: SECOM TimeStamping CA2 TSA, TA Certificates
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | sha256WithRSAEncryption |
| issuer | Information about the issuer (specified by the CAs) |
| validity | notBefore = A value within 24 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | Subscriber information |
| subjectPublicKeyInfo | Subject's Public Key Data |
| Extension Fields | Settings | critical |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | A 160-bit SHA-1 hash for CA Public Key | N |
| subjectKeyIdentifier | A 160-bit SHA-1 hash value of the Subject Public key | N |
| keyUsage | digitalSignature, nonRepudiation
(Other usages than [keyCertSign] and [cRLSign] may be specified by the CAs as necessary.) | Y/N |
| certificatePolicies | certPolicyId=1.2.392.200091.100.931.1
policyQualifierID=id-qt-cps
qualifier=`https://repo1.secomtrust.net/spcpp/ts/` | N |
| subjectAltName | - | - |
| extKeyUsage | id-kp-timeStamping | Y/N |
| cRLDistributionPoints | URI:`http://repo1.secomtrust.net/spcpp/ts/ca2/fullCRL.crl` | N |
| authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
`http://ts2.ocsp.secomtrust.net` (Optional if cRLDistributionPoints is present) | N |
---
## Table: SECOM TimeStamping CA3 TSA, TA Certificates
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | Set one of the following：
sha256WithRSAEncryption
sha384WithRSAEncryption |
| issuer | Information about the issuer (specified by the CAs) |
| validity | notBefore = A value within 24 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | Subscriber information |
| subjectPublicKeyInfo | Subject's Public Key Data |
| Extension Fields | Settings | critical |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | A 160-bit SHA-1 hash for CA Public Key | N |
| subjectKeyIdenrifier | A 160-bit SHA-1 hash for Subscriber Public Key | N |
| keyUsage | digitalSignature (Other purposes other than keyCertSign and cRLSign may be set as necessary by this CA.) | Y/N |
| certificatePolicies | certPolicyId=1.2.392.200091.100.931.3
policyQualifierID=id-qt-cps
qualifier=`https://repo1.secomtrust.net/spcpp/ts/` | N |
| subjectAltName | - | - |
| extKeyUsage | id-kp-timeStamping | Y/N |
| cRLDistributionPoints | URI:`http://repo1.secomtrust.net/spcpp/ts/ca3/fullCRL.crl`
\* Optional if id-ad-ocsp accessMethod is present in the authorityInformationAccess Extension. | N |
| authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
`http://ts3.ocsp.secomtrust.net` (Optional if cRLDistributionPoints is present)
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
HTTP URL of the CA Certificate
\* Set OCSP, CA Issuers as necessary | N |
---
## Table: SECOM TimeStamping CA4 TSA Certificates (Not issued after 2025-04-15)
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | Set one of the following：
sha256WithRSAEncryption
sha384WithRSAEncryption |
| issuer | Information about the issuer (specified by the CAs) |
| validity | notBefore = A value within 24 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | Subscriber information |
| subjectPublicKeyInfo | Subject's RSA Public Key Data (At least 3072 bit) |
| Extension Fields | Settins | critical |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | A 160-bit SHA-1 hash for CA Public Key | N |
| subjectKeyIdenrifier | A 160-bit SHA-1 hash for Subscriber Public Key | N |
| keyUsage | digitalSignature
(Other usages than [keyCertSign] and [cRLSign] may be specified by the CAs as necessary.) | Y |
| certificatePolicies | certPolicyId=1.2.392.200091.100.931.4
policyQualifierID=id-qt-cps
qualifier=`https://repo1.secomtrust.net/spcpp/ts/` | N |
| subjectAltName | - | - |
| extKeyUsage | timeStamping(1.3.6.1.5.5.7.3.8) | Y |
| cRLDistributionPoints | URI:`http://repo1.secomtrust.net/spcpp/ts/ca4/fullCRL.crl` | N |
| authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
`http://ts4.ocsp.secom-cert.jp`
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
HTTP URL of the CA Certificate | N |
---
## Table: SECOM TimeStamping Service TSA Certificates
| Basic Fields | Settings |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| version | 3 (0x2) |
| serialNumber | Unique value within CA |
| signature | Set one of the following：
sha256WithRSAEncryption
sha384WithRSAEncryption |
| issuer | Information about the issuer (specified by the CAs) |
| validity | notBefore = A value within 24 hours before the certificate signing
notAfter = Stipulated in [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) |
| subject | Subscriber information |
| subjectPublicKeyInfo | Subject's Public Key Data |
| Extension Fields | Settins | critical |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| authorityKeyIdentifier | A 160-bit SHA-1 hash for CA Public Key | N |
| subjectKeyIdenrifier | A 160-bit SHA-1 hash for Subscriber Public Key | N |
| keyUsage | digitalSignature | Y/N |
| certificatePolicies | policyIdentifier
certPolicyId=1.2.392.200091.100.931.5
policyQualifiers
policyQualifierID=id-qt-cps
qualifier= HTTP(S) URL of the CA's Repository | N |
| subjectAltName | - | - |
| extKeyUsage | id-kp-timeStamping | Y/N |
| cRLDistributionPoints | The HTTP URL of the CA's CRL Service
\* Optional if id-ad-ocsp accessMethod is present in the authorityInformationAccess extension. | N |
| authorityInformationAccess | accessMethod
id-ad-ocsp（1.3.6.1.5.5.7.48.1)
accessLocation
HTTP URL of the OCSP Responder (Optional if cRLDistributionPoints is present)
id-ad-caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
HTTP URL of the CA Certificate
\* Set OCSP, CA Issuers as necessary | N |
---