Cybertrust Japan

Certificate Policy/Certification Practice Statement

for Public S/MIME Certificate

OID: 1.2.392.200081.1.32

Version 2.04

Cybertrust Japan Co., Ltd.

February 16, 2026

**■ Copyright and distribution conditions of this document**

This document is available under Attribution-NoDerivs (CC-BY-ND) 4.0 (or later version) of the Creative Commons license.

© 2020 Cybertrust Japan Co., Ltd.

Version 2.04

Creation/revision date: February 16, 2026

This document can be copied and distributed in whole or in part free of charge if the following conditions are satisfied.

- Display the copyright notice, Version, and revision date on the top of pages of a whole or a part of this copies.

- Set forth that full text can be obtained at https://www.cybertrust.ne.jp/ssl/repository_rt/ if only a part of this document is distributed.

- Specify the citation source appropriately when using part of this document as excerpts and citations in other documents.

- Cybertrust Japan shall not be liable for any dispute or damage related to copying and distribution of this document.

- In addition, Cybertrust Japan prohibits alteration and modification in any case.

For inquiries about the copyright and distribution conditions of this document, please contact us as described in 1.5.2 “Contact person” of this document.

-------------------
# Revision History

<table>
<colgroup>
<col style="width: 12%" />
<col style="width: 25%" />
<col style="width: 61%" />
</colgroup>
<tbody>
<tr>
<th style="text-align: center;">Version</th>
<th style="text-align: center;">Date</th>
<th style="text-align: center;">Reason for Revision</th>
</tr>
<tr>
<td style="text-align: left;">1.00</td>
<td style="text-align: left;">October 14, 2021</td>
<td style="text-align: left;"><ul>
<li><p>Merged two existing CPSes(JCSI Root Certification Practice Statement and Cybertrust Root Certification Practice Statement) and established “Cybertrust Japan Certification Practice Statement” as version 1.00.</p></li>
</ul></td>
</tr>
<tr>
<td style="text-align: left;">1.01</td>
<td style="text-align: left;">November 25, 2021</td>
<td style="text-align: left;"><ul>
<li><p>Modified "5.4.1 Types of Events Recorded"</p></li>
</ul></td>
</tr>
<tr>
<td style="text-align: left;">1.02</td>
<td style="text-align: left;">August 25, 2022</td>
<td style="text-align: left;"><ul>
<li><p>Modified the description listed in "5.4.1 Types of events recorded" for the clarification.</p></li>
<li><p>Added descriptions in Section "9.16.3 Severability"</p></li>
<li><p>Minor modifications on phraseology.</p></li>
</ul></td>
</tr>
<tr>
<td style="text-align: left;">1.03</td>
<td style="text-align: left;">September 21, 2022</td>
<td style="text-align: left;"><ul>
<li><p>Revised "1.1 Overview" and "Appendix B: List of Revoked CAs" due to the revocation of CA certificates.</p></li>
</ul></td>
</tr>
<tr>
<td style="text-align: left;">1.04</td>
<td style="text-align: left;">November 11, 2022</td>
<td style="text-align: left;"><ul>
<li><p>Modified names of the documents referenced in "1.1 Overview"</p></li>
</ul></td>
</tr>
<tr>
<td style="text-align: left;">1.05</td>
<td style="text-align: left;">April 21, 2023</td>
<td style="text-align: left;"><ul>
<li><p>Added about the Validation Specialist internal examination in section “5.3.3 Training Requirements”</p></li>
<li><p>Added about notification to root program in "5.7.1 Incident and Compromise Handling Procedures"</p></li>
<li><p>Added about requirements to comply in "6.7 Network Security Controls"</p></li>
</ul></td>
</tr>
<tr>
<td style="text-align: left;">1.06</td>
<td style="text-align: left;">April 28, 2023</td>
<td style="text-align: left;"><ul>
<li><p>Revised "1.1 Overview", "2.2 Publication of Certification Information", and "Appendix B: List of Revoked CAs" due to the revocation of CA certificates.</p></li>
</ul></td>
</tr>
<tr>
<td style="text-align: left;">1.07</td>
<td style="text-align: left;">August 24,2023</td>
<td style="text-align: left;"><ul>
<li><p>Modified descriptions in "1.1 Overview" due to the issuance of CA certificate.</p></li>
<li><p>Revised "1.1 Overview" and "Appendix B: List of Revoked CAs" due to the revocation of CA certificate.</p></li>
<li><p>Added descriptions in "1.5.2 Contact Person" for clarification.</p></li>
<li><p>Modified descriptions in "9.12.1 Procedure for Amendment".</p></li>
<li><p>Added definitions in "Appendix A List of Definitions".</p></li>
<li><p>Minor modifications on phraseology.</p></li>
</ul></td>
</tr>
<tr>
<td style="text-align: left;">1.08</td>
<td style="text-align: left;">March 15, 2024</td>
<td style="text-align: left;"><ul>
<li><p>Modified descriptions in "6.8 Time-stamping"</p></li>
<li><p>Minor modifications on phraseology.</p></li>
</ul></td>
</tr>
<tr>
<td style="text-align: left;">1.09</td>
<td style="text-align: left;">April 15, 2024</td>
<td style="text-align: left;"><ul>
<li><p>Added descriptions on Timestamp Authority in “1.1 Overview”</p></li>
<li><p>Modified ”1.3.3 Issuing Authorities” to “1.3.1.1 Issuing Authorities”</p></li>
<li><p>Added “1.3.2.1 Enterprise registration authorities”</p></li>
<li><p>Added descriptions on Timestamp Authority in “1.3.5 Other Participants”</p></li>
<li><p>Modified descriptions in “2.4 Access Controls on Repositories”</p></li>
<li><p>Modified descriptions in “5.7.1 Incident and Compromise Handling Procedures”</p></li>
</ul></td>
</tr>
<tr>
<td style="text-align: left;">1.10</td>
<td style="text-align: left;">July 30, 2024</td>
<td style="text-align: left;"><ul>
<li><p>Added newly created CAs' information in "1.1 Overview" and “2.2 Publication of certification information”</p></li>
<li><p>Modified descriptions in "1.3.3 Subscribers“</p></li>
<li><p>Clarified “1.3.5 Other Participants”</p></li>
<li><p>Added “5.4.1.1 Router and firewall activities logs”</p></li>
<li><p>Modified the description in “6.4.1 Activation data generation and installation” due to new equipment procurement of HSM</p></li>
<li><p>Added subsection to “7.1 Certificate profile”, “7.2 CRL profile”,”7.3 OCSP profile”,”9.1 Fees” and “9.2 Financial responsibility”</p></li>
<li><p>Minor modifications on phraseology</p></li>
</ul></td>
</tr>
<tr>
<td style="text-align: left;">1.11</td>
<td style="text-align: left;">August 20, 2024</td>
<td style="text-align: left;"><ul>
<li><p>Deleted revoked Subordinate Certification Authorities information in “1.1 Overview” and “2.2 Publication of certification information”.</p></li>
<li><p>Deleted or modified descriptions related to “Organization-validated Legacy Generation of S/MIME Certificate”, “EV Code Signing Certificate”, “Non EV Code Signing Certificate”, and “Timestamp Certificate”, which had been no longer issued due to revocation of Subordinate Certification Authorities.</p></li>
<li><p>Added revoked Subordinate Certification Authorities information in “Appendix D: List of Revoked CAs”.</p></li>
</ul></td>
</tr>
<tr>
<td style="text-align: left;">1.12</td>
<td style="text-align: left;">September 13, 2024</td>
<td style="text-align: left;"><ul>
<li><p>Add descriptions in “5.4.1 Types of events recorded”</p></li>
<li><p>Add definitions in "Appendix A List of Definitions"</p></li>
<li><p>Minor modifications on phraseology</p></li>
</ul></td>
</tr>
<tr>
<td style="text-align: left;">2.00</td>
<td style="text-align: left;">February 14, 2025</td>
<td style="text-align: left;"><ul>
<li><p>Integrated CP(Cybertrust Japan Certificate Policy) and CPS(Cybertrust Japan Certification Practice Statement), removed descriptions related to TLS server certificate, and established a dedicated CP/CPS for S/MIME certificate(Cybertrust Japan Certificate Policy/Certification Practice Statement for Public S/MIME Certificate)</p></li>
</ul></td>
</tr>
<tr>
<td style="text-align: left;">2.01</td>
<td style="text-align: left;">March 14, 2025</td>
<td style="text-align: left;"><ul>
<li><p>Add “4.2.2.2 Multi-Perspective Issuance Corroboration”</p></li>
<li><p>Add description about linting to “4.3.1 CA actions during</p></li>
</ul>
<p>certificate issuance” and “8.7 Self audit”</p>
<ul>
<li><p>Minor changes throughout the document.</p></li>
</ul></td>
</tr>
<tr>
<td style="text-align: left;">2.02</td>
<td style="text-align: left;">July 15, 2025</td>
<td style="text-align: left;"><ul>
<li><p>Moved the content of 3.2.2.6 CAA Record Procedures to 4.2.2.1 Certification Authority Authorization.</p></li>
<li><p>Updated the verification methods under "Appendix A: Verification Requirements for Subscriber Certificate" for email mailbox approval/control: methods based on BR 3.2.2.4.2 and 3.2.2.4.15 are now marked as "Not Used".</p></li>
<li><p>Minor additional edits.</p></li>
</ul></td>
</tr>
<tr>
<td style="text-align: left;">2.03</td>
<td style="text-align: left;">November 12, 2025</td>
<td style="text-align: left;"><ul>
<li><p>Add a statement in "1.1 Overview" that the English version of this CP/CPS takes precedence</p></li>
<li><p>Revised "4.2.2.1 Certification authority authorization" for clarification</p></li>
<li><p>Revised  "5.7.1 Incident and compromise handling procedures" for clarification</p></li>
<li><p>Add a vulnerability response timeline to "6.7 Network security controls"</p></li>
<li><p>Other minor revisions</p></li>
</ul></td>
</tr>
<tr>
<td style="text-align: left;">2.04</td>
<td style="text-align: left;">February 16, 2026</td>
<td style="text-align: left;"><ul>
<li><p>Added statements regarding DNSSEC validation to “4.2.2.1 Certification authority authorization”</p></li>
<li><p>Other minor revisions</p></li>
</ul></td>
</tr>
</tbody>
</table>

-----------
# Contents

- [Revision History](#revision-history)
- [Contents](#contents)
- [1. INTRODUCTION](#1-introduction)
  - [1.1 Overview](#11-overview)
  - [1.2 Document name and identification](#12-document-name-and-identification)
  - [1.3 PKI participants](#13-pki-participants)
    - [1.3.1 Certification authorities](#131-certification-authorities)
      - [1.3.1.1 Issuing Authorities](#1311-issuing-authorities)
    - [1.3.2 Registration authorities](#132-registration-authorities)
      - [1.3.2.1 Enterprise registration authorities](#1321-enterprise-registration-authorities)
    - [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 CP/CPS suitability for the policy](#153-person-determining-cpcps-suitability-for-the-policy)
    - [1.5.4 CP/CPS approval procedures](#154-cpcps-approval-procedures)
  - [1.6 Definitions and acronyms](#16-definitions-and-acronyms)
- [2. PUBLICATION AND REPOSITORY RESPONSIBILITIES](#2-publication-and-repository-responsibilities)
  - [2.1 Repositories](#21-repositories)
  - [2.2 Publication of certification information](#22-publication-of-certification-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 identity](#322-authentication-of-organization-identity)
    - [3.2.2.1 Identity](#3221-identity)
    - [3.2.2.2 DBA/Tradename](#3222-dbatradename)
    - [3.2.2.3 Verification of Country](#3223-verification-of-country)
    - [3.2.2.4 Validation of Mailbox Authorization or Control](#3224-validation-of-mailbox-authorization-or-control)
        - [3.2.2.4.1 Validating authority over mailbox via domain （SMBR3.2.2.1）](#32241-validating-authority-over-mailbox-via-domain-smbr3221)
        - [3.2.2.4.2 Validating control over mailbox via email (SMBR3.2.2.2)](#32242-validating-control-over-mailbox-via-email-smbr3222)
        - [3.2.2.4.3 Validating applicant as operator of associated mail server(s) (SMBR3.2.2.3)](#32243-validating-applicant-as-operator-of-associated-mail-servers-smbr3223)
        - [3.2.2.4.4 Validating control over mailbox using ACME extensions (SMBR3.2.2.4)](#32244-validating-control-over-mailbox-using-acme-extensions-smbr3224)
    - [3.2.2.5 Data Source Accuracy](#3225-data-source-accuracy)
    - [3.2.3 Authentication of individual identity](#323-authentication-of-individual-identity)
    - [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](#326-criteria-for-interoperation)
  - [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](#4221-certification-authority-authorization)
      - [4.2.2.2 Multi-perspective issuance corroboration](#4222-multi-perspective-issuance-corroboration)
    - [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.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.1.3 Reason of Revoking Other Certificates](#4913-reason-of-revoking-other-certificates)
        - [4.9.1.3.1 Root CA Certificate](#49131-root-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 (if applicable)](#497-crl-issuance-frequency-if-applicable)
    - [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. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS](#5-facility-management-and-operational-controls)
  - [5.1 Physical controls](#51-physical-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.1.9 Anti-Earthquake Measures](#519-anti-earthquake-measures)
  - [5.2 Procedural controls](#52-procedural-controls)
    - [5.2.1 Trusted roles](#521-trusted-roles)
      - [5.2.1.1 Certification Authority Supervisor](#5211-certification-authority-supervisor)
      - [5.2.1.2 Issuing Authority Manager](#5212-issuing-authority-manager)
      - [5.2.1.3 Issuing Authority System Administrator](#5213-issuing-authority-system-administrator)
      - [5.2.1.4 Issuing Authority Operator](#5214-issuing-authority-operator)
      - [5.2.1.5 Registration Authority Manager](#5215-registration-authority-manager)
      - [5.2.1.6 Registration Authority Operator Manager](#5216-registration-authority-operator-manager)
      - [5.2.1.7 Registration Authority Operator](#5217-registration-authority-operator)
    - [5.2.2 Number of persons required per task](#522-number-of-persons-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](#533-training-requirements)
    - [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 requirements](#537-independent-contractor-requirements)
    - [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.2 Frequency of processing log](#542-frequency-of-processing-log)
    - [5.4.3 Retention period for audit log](#543-retention-period-for-audit-log)
    - [5.4.4 Protection of audit log](#544-protection-of-audit-log)
    - [5.4.5 Audit log backup procedures](#545-audit-log-backup-procedures)
    - [5.4.6 Audit collection system (internal vs. external)](#546-audit-collection-system-internal-vs-external)
    - [5.4.7 Notification to event-causing subject](#547-notification-to-event-causing-subject)
    - [5.4.8 Vulnerability assessments](#548-vulnerability-assessments)
  - [5.5 Records archival](#55-records-archival)
    - [5.5.1 Types of records archived](#551-types-of-records-archived)
    - [5.5.2 Retention period for archive](#552-retention-period-for-archive)
    - [5.5.3 Protection of archive](#553-protection-of-archive)
    - [5.5.4 Archive backup procedures](#554-archive-backup-procedures)
    - [5.5.5 Requirements for time-stamping of records](#555-requirements-for-time-stamping-of-records)
    - [5.5.6 Archive collection system (internal or external)](#556-archive-collection-system-internal-or-external)
    - [5.5.7 Procedures to obtain and verify archive information](#557-procedures-to-obtain-and-verify-archive-information)
  - [5.6 Key changeover](#56-key-changeover)
  - [5.7 Compromise and disaster recovery](#57-compromise-and-disaster-recovery)
    - [5.7.1 Incident and compromise handling procedures](#571-incident-and-compromise-handling-procedures)
    - [5.7.2 Computing resources, software, and/or data are corrupted](#572-computing-resources-software-andor-data-are-corrupted)
    - [5.7.3 Entity private key compromise procedures](#573-entity-private-key-compromise-procedures)
    - [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.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 Method of activating private key](#628-method-of-activating-private-key)
    - [6.2.9 Method of deactivating private key](#629-method-of-deactivating-private-key)
    - [6.2.10 Method of destroying private key](#6210-method-of-destroying-private-key)
    - [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 extensions](#712-certificate-extensions)
    - [7.1.3 Algorithm object identifiers](#713-algorithm-object-identifiers)
      - [7.1.3.1 SubjectPublicKeyInfo](#7131-subjectpublickeyinfo)
      - [7.1.3.2 signatureAlgorithm](#7132-signaturealgorithm)
    - [7.1.4 Name forms](#714-name-forms)
    - [7.1.5 Name constraints](#715-name-constraints)
    - [7.1.6 Certificate policy object identifier](#716-certificate-policy-object-identifier)
    - [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.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)
- [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.9.1 Indemnification by Subscribers and Relying Parties](#991-indemnification-by-subscribers-and-relying-parties)
    - [9.9.2 Indemnification by Cybertrust](#992-indemnification-by-cybertrust)
  - [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: List of Definitions](#appendix-a-list-of-definitions)
- [Appendix B: Profile of Certificate](#appendix-b-profile-of-certificate)
- [Appendix C: List of Revoked CAs](#appendix-c-list-of-revoked-cas)

-------------------
# 1\. INTRODUCTION

## 1.1 Overview

Cybertrust Japan Co., Ltd. ("Cybertrust") operates Root Certification Authorities (the "Root CAs") and Subordinate Certification Authorities (the "Subordinate CAs") underneath to issue publicly trusted digital certificates. The Root CAs and the Subordinate CAs are collectively referred to as the "CAs" hereinafter unless separately described in this document.

The "S/MIME Certificate" (hereinafter collectively referred to as "Certificate" unless separately stipulated) are issued from the Subordinate CA to its subscribers.

All types of subscriber certificates issued by the Subordinate CAs are collectively referred to as "certificates" unless the certificate type is separately mentioned, and service operated by Cybertrust issuing publicly trusted certificates is referred to as "this service" hereinafter.

Each Root CA is identified with the information in following tables, and the certificates for each Subordinate CA are issued by either one of the Root CAs operated by Cybertrust.

Note that revoked CAs are listed in Appendix C.

Root CA

| Name of CA | SecureSign Root CA16 |
|:---|:---|
| Serial Number of CA Certificate | 547B8DAB53110077A81803AEA12B1129AB42E045 |
| Validity Period of CA Certificate | July 30, 2024 to July 29, 2044 |
| Signature Algorithm | SHA384 with RSA |
| Key Size of CA | 4096 bit |
| Hash value (SHA-1) | D17917EC45E2A0CAD774513010A4C65CAAB33C49 |
| Hash value (SHA-256) | 4C1CCD24F17E950FC18536B33CAFE32293CFC33E8467B41E1C693055D7F513BF |

Subordinate CA

| Name of CA | Cybertrust Japan SureMail CA G9 |
|:---|:---|
| Serial Number of CA Certificate | 143D38AEE7BEA7D577D96AA346B5581E0A651915 |
| Validity Period of CA Certificate | July 30, 2024 to July 29, 2034 |
| Signature Algorithm | SHA256 with RSA |
| Key Size of CA | 4096 bit |
| Hash value (SHA-1) | D3FA22289481BA615E9A688CEE92A2F103D8114E |
| Hash value (SHA-256) | DF722167C475B964E39C2536D87E694A160F65C43F62DAC8764EA051D5783AAA |
| Certificates to be Issued | S/MIME Certificate (Organization-validated Strict Generation) |
| Root CA | SecureSign Root CA16 |

The CAs are compliant with the following requirements and laws and ordinances:

1. Cybertrust Japan Certificate Policy/Certification Practice Statement for Public S/MIME Certificate (This document and hereafter called "this CP/CPS.")

2. The requirements imposed on the CAs by the CA/Browser Forum, such as followings:

   - Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates" provided by CA/Browser Forum (“BR”)
   - Network and Certificate System Security Requirements" provided by CA/Browser Forum 
   - Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates provided by the CA/Browser Forum  (“BR”)


3. The requirements imposed on the CAs by the Application Software Supplier who includes the CA's root CA certificate(s) in its application software is registered, such as followings:

   - Program Requirements - Microsoft Trusted Root Program
   - Mozilla Root Store Policy
   - Apple Root Certificate Program
   - CCADB Policy


4. Laws of Japan that are applicable to the operations performed by the certification authority established in Japan.

Cybertrust complies with the latest versions of the above requirements published by CA/Browser Forum at https://www.cabforum.org and the above requirements imposed on the CAs by the Application Software Supplier who includes the CA's root CA certificate(s) in its application software is registered. If there is any discrepancy between this CP/CPS and the requirements, the requirements shall prevail.

The latest version of this CP/CPS, and relevant documents may be found in the Cybertrust repository page. This CP/CPS will be published in both English and Japanese, but if there is any discrepancy between the English and Japanese versions of the same version, the English version will take precedence.

This CP/CPS prescribes the requirements for operating the CAs as well as the various requirements thereto issuing certificates. The requirements include obligations of the CAs, of subscribers, and of Relying Parties.

Cybertrust shall adopt the RFC 3647 "Certificate Policy and Certification Practices Framework" set forth by the IETF PKIX Working Group upon specifying the various requirements in this CP/CPS. RFC 3647 is an international guideline that sets forth the framework for CP/CPS. In each provision of this CP/CPS, which is established based on the framework of RFC3647, matters that the CA does not perform are described as "Not applicable" while "No Stipulation" is used when there is no requirement for related provision.

## 1.2 Document name and identification

The formal name of this CP/CPS shall be “Certificate Policy/Certification Practice Statement for Public S/MIME Certificate”.

An object ID (OID) specific to this CP/CPS is assigned as following.

| Document Name | OID |
|:--:|:--:|
| Cybertrust Japan Certificate Policy/Certification Practice Statement for Public S/MIME Certificate | 1.2.392.200081.1.32 |

## 1.3 PKI participants

Cybertrust Japan Policy Authority (“CTJ PA”) determines policies such as this CP/CPS and appoints CA Supervisors set forth in “5.2.1 Trusted roles” of this CP/CPS.

The following describes the parties related to the certificates issued by the CAs. Each party shall observe the obligations set forth in this CP/CPS.

### 1.3.1 Certification authorities

The CAs set forth in the “1.1 Overview" of this CP/CPS. Each CAs consists of a Registration Authority and an Issuing Authority. Each CA is supervised by the CA Supervisor.

#### 1.3.1.1 Issuing Authorities

Each Issuing Authority of the Root CA is operated by Cybertrust, issues or revokes Subordinate CA certificates based on instructions from the RA of the Root CA. The Issuing Authorities also control the Private Key of the Root CAs based on this CP/CPS.

Each Issuing Authority of the Subordinate CAs are also operated by Cybertrust, issues or revokes subscriber certificates based on instructions from the RA. The Issuing Authority also controls the Private Key of the Subordinate CAs based on this CP/CPS.

### 1.3.2 Registration authorities

Each Registration Authority (“RA”) is operated by Cybertrust and accepts applications for subscriber certificates, and verifies the applications based on this CP/CPS. Based on the validation results, the RAs instruct corresponding Issuing Authorities to issue/revoke the subscriber certificates, or to dismisses the applications. The CAs do not delegate any of its RA operations including domain or email address control validation to any third parties.

#### 1.3.2.1 Enterprise registration authorities

Not applicable.

### 1.3.3 Subscribers

Subscribers are organizations that apply for a certificate with either Subordinate CAs and use issued subscriber certificate based on this CP/CPS, and the Subscriber Agreement.

A person who is responsible for applying for a subscriber's certificate is referred to as an “application supervisor”. A subscriber must appoint an application supervisor among persons affiliated with the subscriber.

Persons affiliated with the subscriber who may submit a certificate request to the Subordinate CAs shall be limited to the application supervisor, or a procedural manager who is authorized by the application supervisor to submit a certificate request. The procedural manager may be appointed among persons inside or outside of the subscriber.

When the procedural manager is to be appointed from the outside, the procedural manager may be an individual or an organization. The procedural manager appointed among persons outside the subscriber may be defined as the "Applicant's Agent" in the Subscriber Agreement, etc.

When the CA applies for and use the certificate for its own use, the CA also acts as a subscriber.

### 1.3.4 Relying parties

Relying Parties are organizations or individuals verify the validity of the certificates of the CAs and subscribers and rely on the certificates based on own judgment.

### 1.3.5 Other participants

Other parties include Application Software Suppliers, and auditors.

## 1.4 Certificate usage

### 1.4.1 Appropriate certificate uses

Uses of certificate shall be as set forth in the table below. Matters in detail regarding each certificate of the CAs and subscribers are set forth in Appendix B.

| Certificate Type           | Use     |
|----------------------------|-------------------------------------------------------------|
| S/MIME Certificate         | Certificate of E-mail protection (certification of the organization that uses the certificate and certification that the organization has the right to use the email address (Mailbox Address)) issued in accordance with “SMBR”. Issuing the certificate of Organization-validated Strict Generation defined in SMBR.                                |
| Root CA Certificate        |Certificate of Root CA that issues a Subordinate CA certificate.                                  |
| Subordinate CA certificate | Certificate of Subordinate CA that issues a subscriber certificate to subscriber.                     |

The Root CAs do not issue the Subordinate CA certificates to any third party.

### 1.4.2 Prohibited certificate uses

The CAs prohibit the use of certificates for any purpose other than as set forth in "1.4.1 Appropriate certificate uses" of this CP/CPS. Also, certificates may not be used for the purpose of intercepting encrypted network traffic (e.g., "man-in-the-middle attacks").

The certificates issued by Cybertrust do not guarantee that the Subject is trustworthy, reputable in its business, safe to do business with, compliant with any law nor that the equipment into which the certificate has been installed is free from defect, malware, or virus. The CAs merely certify that the reasonable means of verification for submitted information has been executed prior to certificate issuance.

## 1.5 Policy administration

### 1.5.1 Organization administering the document

This CP/CPS, and the Subscriber Agreement are administered by Cybertrust, which operates every CA described in this document.

### 1.5.2 Contact person

Cybertrust accepts inquiries related to its services and this CP/CPS at the following contact information.

<table>
<colgroup>
<col style="width: 100%" />
</colgroup>
<tbody>
<tr>
<td style="text-align: center;">Contact Information</td>
</tr>
<tr>
<td style="text-align: left;"><p>General contact in Cybertrust Japan Co., Ltd.</p>
<p>Address: 13F SE Sapporo Bldg., 1-1-2 Kita 7-jo Nishi, Kita-ku, Sapporo-shi 060-0807</p>
<p>Tel: 0120-957-975 or +81-11-708-5283</p>
<p>Business Days: Monday to Friday (excluding National Holidays, and the designated days addressed on Cybertrust’s website including Year-End and New Year)</p>
<p>Business Hours: 9:00 to 18:00 JST</p>
<p>Inquiries and complaints: As indicated below</p>
<table>
<colgroup>
<col style="width: 64%" />
<col style="width: 35%" />
</colgroup>
<thead>
<tr>
<th style="text-align: center;">Description</th>
<th style="text-align: center;">Address</th>
</tr>
</thead>
<tbody>
<tr>
<td><ul>
<li><p>Inquiries regarding the application process for issuance and technical inquiries</p></li>
<li><p>Inquiries regarding this CP/CPS, etc.</p></li>
<li><p>Capable of response from 9:00 to 18:00 JST on business days.</p></li>
</ul></td>
<td style="text-align: center;">servicedesk@cybertrust.ne.jp</td>
</tr>
<tr>
<td><ul>
<li><p>Inquiries regarding request and application processes for certificate revocation.</p></li>
<li><p>Inquiries regarding certificate problems or upon discovery of fraudulent certificates.</p></li>
<li><p>Communication of other complaints.</p></li>
<li><p>An emergency contact and capable of response for 24 hours a day, 7 days a week</p></li>
</ul></td>
<td style="text-align: center;">evc-report@cybertrust.ne.jp</td>
</tr>
</tbody>
</table></td>
</tr>
</tbody>
</table>

### 1.5.3 Person determining CP/CPS suitability for the policy

The suitability of this CP/CPS is evaluated and determined by CTJ PA.

### 1.5.4 CP/CPS approval procedures

The suitability described in "1.5.3 Person determining CP/CPS suitability for the policy" of this CP/CPS shall go through an external audit, and then be approved by CTJ PA.

## 1.6 Definitions and acronyms

As prescribed in Appendix A of t this CP/CPS.

--------------------------------------------------
# 2\. PUBLICATION AND REPOSITORY RESPONSIBILITIES

## 2.1 Repositories

Repositories of the CAs are controlled by Cybertrust.

Publish the following information at <https://www.cybertrust.ne.jp/ssl/repository_rt/index.html> for 24 hours a day, 7 days a week.

1.  this CP/CPS

2. Subscriber Agreement

3. other terms and conditions regarding the services of the CAs (the "Related Rules")

## 2.2 Publication of certification information

Cybertrust publishes the following information in repositories accessible for 24 hours a day, 7 days a week.

1. Publish each CA Certificate information on following each URL.

| The Root CA | URL |
|----|----|
| SecureSign Root CA16 | http://rtcrl.cybertrust.ne.jp/SecureSign/rtca16/rtca16.crt |

| The Subordinate CA | URL |
|----|----|
| Cybertrust Japan SureMail CA G9 | http://smcrl.cybertrust.ne.jp/SureMail/smcag9/smcag9.crt |

2. Publish each CRL on following each URL.

| The Root CA | URL |
|----|----|
| SecureSign Root CA16 | http://rtcrl.cybertrust.ne.jp/SecureSign/rtca16/cdp.crl |

| The Subordinate CA | URL |
|----|----|
| Cybertrust Japan SureMail CA G9 | http://smcrl.cybertrust.ne.jp/SureMail/smcag9/cdp.crl |

## 2.3 Time or frequency of publication

The timing and frequency of publication regarding the information to be published by CAs shall be as follows. These does not apply for the cases where repository maintenance or the like is required, but CRL shall be available 24 hours.

1. This CP/CPS, the Subscriber Agreement for each certificate, and the Related Rules shall be published each time they are amended.

2. The CRL shall be renewed based on the cycle prescribed in "4.9.7 CRL issuance frequency (if applicable)" of this CP/CPS for each certificate and then published.

3. The certificates of the Subordinate CAs shall be published at least during the effective period.

4. The Root CA Certificates shall be published at least during the operation period of each Root CA.

## 2.4 Access controls on repositories

The CAs shall publish the repository in a read-only manner.

----------------------------------------
# 3\. IDENTIFICATION AND AUTHENTICATION

## 3.1 Naming

### 3.1.1 Types of names

Certificate Distinguished Names and Subject Alternative Names comply with the requirements addressed in section "1.1 Overview" of this CP/CPS.

Subscribers are identified based on the X.500 Distinguished Name ("DN") in the certificate.

### 3.1.2 Need for names to be meaningful

The name included in the DN of the subscriber’s certificates shall have the meaning of the subsequent paragraph.

S/MIME Certificate

<table>
<colgroup>
<col style="width: 35%" />
<col style="width: 64%" />
</colgroup>
<tbody>
<tr>
<th style="text-align:left;">DN Item</th>
<th style="text-align:left;">Meaning</th>
</tr>
<tr>
<td>Common Name</td>
<td>Name of an entity of the subscriber</td>
</tr>
<tr>
<td><p>e-mailAddress</p>
<p>* (optional item)</p></td>
<td>An email address for which the certificate is used.</td>
</tr>
<tr>
<td>Organization</td>
<td>Name of an entity of the subscriber</td>
</tr>
<tr>
<td>OrganizationIdentifier</td>
<td><p>3 character Registration Scheme identifier*¹ followed by 2 character ISO 3166-1 country code for the nation in which the Registration Scheme is operated followed by a hyphen‐minus “‐” (0x2D (ASCII), U+002D (UTF‐8)) and Registration Reference allocated in accordance with the identified Registration Scheme as stipulated in SMBR Section 7.1.4.2.2.</p>
<p>For a Government Entity Subject which does not have a identifier described above*², the Registration Scheme identifier ‘GOV’ is available in which the Registration Scheme identifier ‘GOV’ followed by 2 character ISO 3166-1 country code the Government Entity is located, a plus "+" (0x2B (ASCII), U+002B (UTF‐8)), then followed by 2 characters from ISO 3166‐2 identifier for subdivision only if the Applicant Government Entity is verified at a subdivision level.</p></td>
</tr>
<tr>
<td>Locality</td>
<td>Address of business location (locality)</td>
</tr>
<tr>
<td>State or Province</td>
<td>Address of business location (state or province)</td>
</tr>
<tr>
<td>Country</td>
<td>Address of business location (country) (JP)</td>
</tr>
</tbody>
</table>

\*1 The Subordinate CA issues certificates for legal entities having VAT scheme Registration Scheme identifier stipulated in SMBR.

\*2 Whether \*1 is applicable or not, the Subordinate CA issues certificate, based on Appendix A in SMBR, for Government Entities with GOV Registration Scheme identifier, only if the Government Entity is verifiable in accordance with "3.2.3 Authentication of organization identity" and has no applicable Corporate Number, Corporate identification number, or LEI. The PSD stipulated in Appendix A in SMBR is not applicable to the entity in Japan.

rfc822Name included in Subject Alternative Name extension of S/MIME Certificates shall have a meaning below.

| Subject Alternative Name | Meaning                              |
|:--------------------------|:--------------------------------------|
| rfc822Name               | Email address to use the certificate |

### 3.1.3 Anonymity or pseudonymity of subscribers

The Subordinate CAs do not accept any certificate request by anonymity or pseudonymity of subscribers.

### 3.1.4 Rules for interpreting various name forms

Rules for interpreting the DN form of certificates issued by the CAs shall be pursuant to X.500.

### 3.1.5 Uniqueness of names

A common name of each Subordinate CA issued by corresponding Root CA shall be unique value per each Root CA.

The certificates issued by the Subordinate CAs can uniquely identify a subscriber based on the DN.

### 3.1.6 Recognition, authentication, and role of trademarks

The Subordinate CAs do not authenticate the copyrights, trade secrets, trademark rights, utility model rights, patent rights and other intellectual property rights (including, but not limited to, rights for obtaining patents and other intellectual properties; simply "Intellectual Property Rights") upon issuing a subscriber's certificate.

## 3.2 Initial identity validation

The Subordinate CA shall verify the information of applicant’s establishment/registration jurisdiction before issuing Certificate.

The list of corporate establishment/registration agency databases used by the Subordinate CAs to confirm the establishment of jurisdiction/registration jurisdiction will be published at https://www.cybertrust.ne.jp/ssl/repository/Jurisdiction.pdf.

### 3.2.1 Method to prove possession of private key

For Certificate, the Subordinate CAs generates a subscriber's Private Key on behalf of the subscriber. As stipulated in “6.1.2Private key delivery to subscriber" of this CP/CPS, the Subordinate CAs shall deliver a Private Key to their subscriber. When the subscriber receives the Private Key, the ownership of the Private Key shall be transferred from those Subordinate CAs to the subscriber.

### 3.2.2 Authentication of organization identity

All DNS queries conducted to satisfy the requirements of "3.2.2.4 Validation of Mailbox Authorization or Control" and "4.2.2.1 Certification Authority Authorization" MUST be performed by querying authoritative nameservers directly, without using recursive resolvers operated outside the CA’s audit scope.

All contact information for Domain Contacts MUST come from the WHOIS record, a DNS SOA record, or direct contact with the Domain Name Registrar of the Base Domain Name, and MUST be obtained directly by the CA, i.e. without the use of third-party services operated outside the CA's audit scope. All contact information for IP Address Contacts MUST be obtained through direct contact with the IP Address Registration Authority, i.e. without the use of any other third-party services operated outside the CA's audit scope.

### 3.2.2.1 Identity

The Subordinate CAs SHALL collect and retain evidence supporting the following identity attributes for the Organization:

1. Formal name of the Legal Entity;
2. An address of the Legal Entity;
3. Jurisdiction of Incorporation or Registration of the Legal Entity; and
4. Unique identifier and type of identifier for the Legal Entity.

In accordance with Section 3.2.3 of the SMBR, the Subordinate CAs shall verify the full legal name,  an address, and identifier of the Legal Entity Applicant using documentation provided by, or through communication with, at least one of the following:

1. A government agency in the jurisdiction of the Legal Entity’s creation, existence, or recognition;
2. A Legal Entity Identifier (LEI) data reference;
3. A site visit by the CA or a third party who is acting as an agent for the CA;
4. An Attestation which includes a copy of supporting documentation used to establish the Applicant’s legal existence (such as a certificate of registration, articles of incorporation, operating agreement, statute, or regulatory act) and its current status.

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

In cases 1 and 4 above, the Subordinate CAs SHALL verify that the status of the Applicant is not designated by labels such as “ceased,” “inactive,” “invalid,” “not current,” or the equivalent.

When LEI data reference is used, the Subordinate CAs SHALL verify that the RegistrationStatus is ISSUED and the EntityStatus is ACTIVE. The Subordinate CAs SHALL only allow use of an LEI if the ValidationSources entry is FULLY_CORROBORATED. An LEI SHALL NOT be used if ValidationSources entry is PARTIALLY_CORROBORATED, PENDING, or ENTITY_SUPPLIED_ONLY. The Subscriber’s unique identifier shall be verified for appropriateness and added in accordance with Section 7.1.4.2.2 of the SMBR.

### 3.2.2.2 DBA/Tradename

The Subordinate CAs do not allow DBA/Tradename to be included in the subscriber's certificate.

### 3.2.2.3 Verification of Country

The Subordinate CAs validate Country which to be included in a certificate as per the applicable verification process for the certificate before issuing a requested certificate. In addition, the Subordinate CAs shall verify the Country in accordance with Section 3.2.3 of the SMBR, and the same verification methods as those specified in this CP/CPS ,Section “3.2.2.1 Identity Verification”, shall be applied.

### 3.2.2.4 Validation of Mailbox Authorization or Control

Prior to the issuance of a Certificate, the Subordinate CAs shall verify one of the following:

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

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

The Subordinate CAs SHALL maintain a record of which validation method, including the relevant version number from the BR or SMBR, was used to validate every domain or email address in issued Certificates.

The Subordinate CAs validate the Domain Name or the email address (Mailbox Address) to be listed in Certificate by using at least one of following procedure. The Subordinate CAs, however, SHALL not issue any certificate to the email address (Mailbox Address) of which ends with ".onion" for the right most label.

##### 3.2.2.4.1 Validating authority over mailbox via domain （SMBR3.2.2.1）

The Subordinate CAs MAY confirm the Applicant which includes the Applicant’s Parent Company, Subsidiary Company, or Affiliate, has been authorized by the email account holder to act on the account holder’s behalf by verifying the Applicant's control over the domain portion of the Mailbox Address to be used in the Certificate.

The CAs SHALL use only the approved methods in Section 3.2.2.4 of the BR to perform this verification.

##### 3.2.2.4.2 Validating control over mailbox via email (SMBR3.2.2.2)

The Subordinate CAs MAY confirm the Applicant’s control over each Mailbox Field to be included in a Certificate by sending a Random Value(as defined in the SMBR) via email and then receiving a confirming response utilizing the 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.

When a Random Value is used as an additional verification method for the review of the subject mailbox address, the Random Value shall not be reused, and a new unique Random Value shall be generated.

##### 3.2.2.4.3 Validating applicant as operator of associated mail server(s) (SMBR3.2.2.3)

The Subordinate CAs do not use this method.

##### 3.2.2.4.4 Validating control over mailbox using ACME extensions (SMBR3.2.2.4)

The Subordinate CAs do not use this method.

### 3.2.2.5 Data Source Accuracy

Before using a data source as a reliable data source, the Subordinate CAs evaluate the source for its reliability in accordance with Section 3.2.8 of the SMBR.

The Subordinate CAs MAY rely upon a letter attesting that Subject Information or other fact is correct. The CA or RA SHALL verify that the letter was written by an accountant, lawyer, government official, or other reliable third party in the Applicant’s jurisdiction customarily relied upon for such information.

An Attestation SHALL include a copy of documentation supporting the fact to be attested. The Subordinate CAs SHALL use a Reliable Method of Communication to contact the sender and to confirm the Attestation is authentic.

### 3.2.3 Authentication of individual identity

The Subordinate CAs do not issue a certificate to a natural person who are specified in SMBR 3.2.4.

### 3.2.4 Non-verified subscriber information

The Subordinate CAs do not include non-verifying subscriber information in certificates as specified in SMBR 3.2.5.

### 3.2.5 Validation of authority

The Subordinate CAs shall verify in accordance with SMBR 3.2.6 that the application supervisor works for the subscriber and has the authority to submit a certificate request on behalf of the subscriber. The Subordinate CAs shall additionally verify that the application supervisor has accepted the Subscriber Agreement and approved the filing of an application by the procedural manager by a Reliable Method of Communication. The Subordinate CAs use the sources verified in Section 3.2.2.1 "Identity" of this CP/CPS to verify the Reliable Method of Communication.

The Subordinate CAs allow an Applicant to specify the individuals who may request Certificates. If an Applicant specifies, in writing, the individuals who may request a Certificate, then the CA SHALL NOT accept any certificate requests that are outside this specification. The CA SHALL provide an Applicant with a list of its authorized Certificate Requesters upon the Applicant’s verified written request.

### 3.2.6 Criteria for interoperation

The CAs do not operate interoperation.

## 3.3 Identification and authentication for re-key requests

### 3.3.1 Identification and authentication for routine re-key

The provisions of “3.2Initial identity validation” of this CP/CPS shall apply correspondingly.

### 3.3.2 Identification and authentication for re-key after revocation

The provisions of “3.2Initial identity validation" of this CP/CPS shall apply correspondingly.

However, when it is verified that the certification information and expiration date with the reissuance application coincide with the certificate of the re-issuer, verification based on "3.2 Initial identity validation" of this CP/CPS is not performed, and a certificate shall be issued based on the verification of the foregoing coincidence.

## 3.4 Identification and authentication for revocation request

When the Subordinate CAs receive a revocation request from a subscriber via email or in the method indicated on Cybertrust’s website, the Subordinate CAs shall verify the identity of the person who submitted the revocation, that such person is authorized to submit a revocation request, and the reason for the revocation. As the verification method, each Subordinate CA shall compare the information notified upon application for issuance of a certificate and the information only known between the Subordinate CA and the subscriber which are presented for verification. If verified, the Subordinate CAs revoke the certificate. The revocation request submitted from the application-account-site by the person in charge of application is regarded as an authorized request in a same manner. However, the Subordinate CAs process the additional verification if necessary.

Upon receiving a revocation request for a certificate of a specific subscriber from other than the subscriber of that certificate, the Subordinate CAs shall survey the reason of revocation and verify with the subscriber of the certificate if necessary. Each Subordinate CA verifies the result of survey and revoke the certificate if the revocation reason is found corresponding any of events set forth in the Subscriber Agreement.

The email address to be used for the revocation request is indicated in "1.5.2 Contact person" of this CP/CPS and on Cybertrust's website.

------------------------------------------------------
# 4\. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

## 4.1 Certificate Application

### 4.1.1 Who can submit a certificate application

Persons who may apply for a certificate with the Subordinate CAs shall only be the application supervisor, or a person in charge of application who was authorized by the application supervisor submit a certificate request.

Appointment of the application supervisor or the person in charge of application shall be pursuant to the provisions of “1.3.3 Subscribers" of this CP/CPS.”

Verification by the Subordinate CAs against their subscriber's intention for submitting a certificate request shall be responded by the application supervisor or by a person inside the subscriber who is with the authorization by the application supervisor.

In accordance with Section 5.5.2, the Subordinate 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 these concerns. The Subordinate CA SHALL use this information to identify subsequent suspicious certificate requests.

### 4.1.2 Enrollment process and responsibilities

A subscriber shall apply for a certificate upon accepting this CP/CPS, the Subscriber Agreement, Upon filing an application, a subscriber is responsible for providing correct and accurate information to the Subordinate CAs.

The methods of applying for certificates are posted on Cybertrust's website or informed to subscriber, correspondingly to the requested certificate type.

## 4.2 Certificate application processing

### 4.2.1 Performing identification and authentication functions

The provisions of “3.2Initial identity validation” of this CP/CPS shall apply correspondingly. The RAs of each Subordinate CA shall perform the procedure.

The Subordinate CA may reuse completed validation, information, or documents obtained by processing "3.2 Initial identity validation". The Subordinate CAs MAY reuse documents, data, and previous validation results for less than 398 days from the day the initial validation completes to issue multiple Certificates.

However, when using this CP/CPS “3.2.2.4.2 Validating control over mailbox via email (SMBR3.2.2.2)”, the completed validation of control of a mailbox SHALL have been obtained no more than 30 days prior to the issuance of the Certificate and MAY be reused for multiple Certificate issuances.

In cases where the certificate request does not contain all the necessary information about the Applicant, the Subordinate CAs SHALL obtain the remaining information from the Applicant or, obtain it from a reliable, independent, third-party data source, then confirm it with the Applicant.

If the issuemail contains any of the following values, the Subordinate CAs recognize that it is designated as a certification authority that permits issuance of the subscriber certificates.

cybertrust.ne.jp

cybertrust.co.jp

### 4.2.2 Approval or rejection of certificate applications

#### 4.2.2.1 Certification authority authorization

When all requirements prescribed in “3.2Initial identity validation" of this CP/CPS are confirmed, the RAs of the Subordinate CAs shall approve the application and instruct the Issuing Authority to issue a certificate. The Subordinate CAs do not notify the subscriber of such issuance in advance.

When the requirements prescribed in “3.2Initial identity validation" of this CP/CPS are not satisfied, the Subordinate CAs shall dismiss the application for issuing a certificate and reject issuance. In the foregoing case, the Subordinate CAs shall notify the reason of such rejection to the application supervisor or the person in charge of application who submitted the application. The Subordinate CAs do not return the information and data obtained from the application supervisor or the person in charge of application during the application process.

When the application supervisor or the person in charge of application withdraws the submitted application, the Subordinate CAs shall dismiss such application. The Subordinate CAs do not return the information and data obtained from the application supervisor or the person in charge of application during the application process.

The Subordinate CAs that issue certificates should retrieve and process CAA records in accordance with Section 4 of RFC 9495. When processing CAA records, the Subordinate CAs shall process the issuemail property tag as specified in RFC 9495.

For certificates issuance, the Subordinate CAs shall confirm the CAA within the TTL of the CAA record, or 8 hours, whichever is greater.

If the Certificate includes more than one email address, then the Subordinate CAs shall perform to retrieve and process CAA records for each email address.

The Subordinate CAs shall not issue a Certificate unless the Subordinate CAs determine that the values contained in the issuemail property tag is consistent with the values listed in ”4.2.1 Performing identification and authentication functions" of this CP/CPS. The Subordinate CAs shall log all actions taken, if consistent with its CAA processing practice.

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

- the cause of the failure is outside the Subordinate CAs' infrastructure; and

- the lookup has been retried at least once; and

- confirmed that the domain is “Insecure” as defined in RFC 4035 Section 4.3.

The Subordinate CAs document potential issuance that were prevented by a CAA record in sufficient detail to provide feedback to the CA/Browser Forum, and if a CAA iodef record contains a contact ( mailto: or https: ), the Certification Authority SHOULD send a report regarding the issuance request to that contact.

On or after March 15, 2026, the Subordinate CAs MUST perform DNSSEC validation back to the IANA DNSSEC root trust anchor on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective in accordance with Section 4.2.2.1.1 of the SMBR, and MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with CAA record lookups. Additionally, the Subordinate CAs MUST NOT treat the issuance as permitted if the Primary Network Perspective observes DNSSEC validation errors (e.g., SERVFAIL).

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.

#### 4.2.2.2 Multi-perspective issuance corroboration

The Subordinate CAs that issue certificates implement Multi Perspective Issuance Corroboration based on Section 3.2.2.9 of the BR. The Subordinate CAs will confirm the followings using at least two (2) remote Network Perspectives before Certificate issuance in accordance with based on Quorum Requirements set forth in Section 3.2.2.9 of the BR.

- Random Value, IP Address, or Contact Address (Email address or phone number), as used by the relied upon validation method specified in Section "3.2.2.4 Validation of Domain Authorization or Control" of the BR; and

- The Subordinate CA's authority to issue certificates for the requested mailbox addresses based on CAA record, as specified in “4.2.2.1 Certification authority authorization” of this CP/CPS.

The Subordinate CAs MAY reuse corroborating evidence for CAA record quorum compliance for a maximum of 398 days. After issuing a Certificate to a domain, remote Network Perspectives MAY omit retrieving and processing CAA records for the same domain or its subdomains in subsequent Certificate requests from the same Applicant for up to a maximum of 398 days.

### 4.2.3 Time to process certificate applications

After each RAs of the Subordinate CAs processes the application based on the provisions of “4.2Certificate application processing" of this CP/CPS, the Issuing Authority shall promptly issue a certificate.

## 4.3 Certificate issuance

### 4.3.1 CA actions during certificate issuance

The CA certificates issuance shall require an individual authorized by the Root CAs (i.e. the Issuing Authority System Administrator and/or Issuing Authority Manager) to deliberately issue a direct command in order for the Root CAs perform a certificate signing operation.

For the subscriber's certificate, each RA of the Subordinate CAs shall instruct corresponding Issuing Authority to issue the subscriber's certificate after completing the validation procedures based on “3.2 Initial identity validation" of this CP/CPS. The Issuing Authorities shall send to the subscriber the notice set forth in "4.3.2 Notification to subscriber by the CA of issuance of certificate" of this CP/CPS simultaneously with issuing the certificate.

The CAs do not delegate any of its RA operations to any third parties. Also, CAs shall enforce multi-factor authentication for all accounts capable of directly causing certificate issuance or performing Registration Authority.

CAs shall not issue subscriber certificates directly from its root CAs.

On-or-after March15, 2025, the subordinate CAs sign the tbsCertificate with a dummy private key and then runs linting. The Subordinate CAs use the Linting tools that have been widely adopted by the industry.

Note that the Subscriber Agreement of the certificate between Cybertrust and the subscriber shall come into force from the time that the subscriber applies for the issuance of a certificate.

### 4.3.2 Notification to subscriber by the CA of issuance of certificate

The Subordinate CAs shall notify the subscriber of the certificate issuance and the procedures required for the subscriber to accept the certificate, based on the information submitted during the enrolment process.

## 4.4 Certificate acceptance

### 4.4.1 Conduct constituting certificate acceptance

A subscriber shall accept issued certificate according to the notified contents in the email from the Subordinate CAs based on the provisions of "4.3.2 Notification to subscriber by the CA of issuance of certificate" of this CP/CPS. The Subordinate CAs shall deem that a subscriber has accepted their certificate when a subscriber receives the notice of issuance.

### 4.4.2 Publication of the certificate by the CA

The certificates of this Certification Authority are published in the repository as accordance to "2.2 Publication of certification information" of this CP/CPS. Additionally, this Certification Authority will not publish subscriber certificates.

### 4.4.3 Notification of certificate issuance by the CA to other entities

The Subordinate CAs may notify other entities designated by the subscriber of the issuance of the certificate.

## 4.5 Key pair and certificate usage

### 4.5.1 Subscriber private key and certificate usage

A subscriber shall use its Private Key and certificate only for the usage set forth in “1.4.1Appropriate certificate uses" of this CP/CPS and any other usage is not allowed. Moreover, a subscriber's Private Key and certificate may only be used by the subscriber, and the subscriber must not license the use thereof to a third party. Other obligations of a subscriber regarding the use of its Private Key and certificate are set forth in "9.6.3 Subscriber representations and warranties" of this CP/CPS.

### 4.5.2 Relying party public key and certificate usage

A Relying Party shall confirm, under its own responsibility, the validity of the certificate that is used by a subscriber for the usage set forth in "1.4.1 Appropriate certificate uses" of this CP/CPS.

Other obligations of Relying Parties regarding the use of a subscriber's public key and certificate are set forth in "9.6.4 Relying party representations and warranties” of this CP/CPS.

## 4.6 Certificate renewal

### 4.6.1 Circumstance for certificate renewal

The Subordinate CAs shall accept a renewal request pursuant to the expiration of the validity period of the certificate used by a subscriber.

### 4.6.2 Who may request renewal

The provisions of “4.1.1Who can submit a certificate application" of this CP/CPS shall apply correspondingly.

### 4.6.3 Processing certificate renewal requests

The provisions of "4.2 Certificate application processing" of this CP/CPS shall apply correspondingly.

### 4.6.4 Notification of new certificate issuance to subscriber

The provisions of “4.3.2Notification to subscriber by the CA of issuance of certificate" of this CP/CPS shall apply correspondingly.

### 4.6.5 Conduct constituting acceptance of a renewal certificate

The provisions of “4.4.1Conduct constituting certificate acceptance" of this CP/CPS shall apply correspondingly.

### 4.6.6 Publication of the renewal certificate by the CA

The provisions of “4.4.2Publication of the certificate by the CA" of this CP/CPS shall apply correspondingly.

### 4.6.7 Notification of certificate issuance by the CA to other entities

The provisions of “4.4.3Notification of certificate issuance by the CA to other entities" of this CP/CPS shall apply correspondingly.

## 4.7 Certificate re-key

### 4.7.1 Circumstance for certificate re-key

The Subordinate CAs shall accept a renewal request pursuant to the expiration of the validity period of the certificate used by a subscriber.

### 4.7.2 Who may request certification of a new public key

The provisions of “4.1.1Who can submit a certificate application" of this CP/CPS shall apply correspondingly.

### 4.7.3 Processing certificate re-keying requests

The provisions of "4.2 Certificate application processing" of this CP/CPS shall apply correspondingly.

### 4.7.4 Notification of new certificate issuance to subscriber

The provisions of “4.3.2Notification to subscriber by the CA of issuance of certificate" of this CP/CPS shall apply correspondingly.

### 4.7.5 Conduct constituting acceptance of a re-keyed certificate

The provisions of “4.4.1Conduct constituting certificate acceptance" of this CP/CPS shall apply correspondingly.

### 4.7.6 Publication of the re-keyed certificate by the CA

The provisions of “4.4.2Publication of the certificate by the CA" of this CP/CPS shall apply correspondingly.

### 4.7.7 Notification of certificate issuance by the CA to other entities

The provisions of “4.4.3Notification of certificate issuance by the CA to other entities" of this CP/CPS shall apply correspondingly.

## 4.8 Certificate modification

### 4.8.1 Circumstance for certificate modification

The Subordinate CAs shall not accept a request for modifying a previously issued certificate.

If there is any modification to the certificate information, a subscriber must promptly request the revocation of the corresponding certificate to the issuer Subordinate CA for revoking the corresponding certificate.

### 4.8.2 Who may request certificate modification

Not applicable.

### 4.8.3 Processing certificate modification requests

Not applicable.

### 4.8.4 Notification of new certificate issuance to subscriber

Not applicable.

### 4.8.5 Conduct constituting acceptance of modified certificate

Not applicable.

### 4.8.6 Publication of the modified certificate by the CA

Not applicable.

### 4.8.7 Notification of certificate issuance by the CA to other entities

Not applicable.

## 4.9 Certificate revocation and suspension

### 4.9.1 Circumstances for revocation

The CA shall revoke the applicable certificate due to the following events.

#### 4.9.1.1 Reasons for Revoking a Subscriber Certificate

Subscribers shall request revocation of an applicable certificate upon the occurrence of a revocation event as specified in the Subscriber Agreement.

The Subordinate CAs shall revoke a certificate within 24 hours if a Subordinate CAs are aware of one or more of the followings.

Prior to revoking a Certificate, this Certification Authority may verify the identity and authority of the entity requesting revocation.

1. a Subscriber requests in writing that the Subordinate CA revokes its certificate without specifying the CRL Reason (CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL);

2. a Subscriber notifies Cybertrust that the original certificate request had not been authorized and does not retroactively grant authorization (CRLReason \#9, privilegeWithdrawn);

3. the Subordinate CAs obtain evidence that the Subscriber’s Private Key corresponding to the Public Key in the certificate suffered a Key Compromise (CRLReason \#1, keyCompromise);

4. the Subordinate CAs are made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys) (CRLReason \#1, keyCompromise);

5. the Subordinate CAs obtain evidence that the Domain Name or email address registrant’s right to use the Domain Name or email address registrant should not be relied upon (CRLReason \#4, superseded);

The Subordinate CAs may revoke a certificate within 24 hours and must revoke a certificate within 5 days if a Subordinate CA is aware of one or more of the followings:

6. the subscriber certificate no longer complies with applicable requirements such as Sections 6.1.5 and 6.1.6 of the BR (section 6.1.5 and section 6.1.6 of the SMBR for S/MIME Certificate) (CRLReason \#4, superseded);

7. the Subordinate CAs obtains evidence that the subscriber certificate was misused (CRLReason \#9, privilegeWithdrawn);

8. the Subordinate CAs are made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement (CRLReason \#9, privilegeWithdrawn);

9. the Subordinate CAs confirm any circumstance indicating that use of email address in the S/MIME certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name or email address registrant’s right to use the Domain Name or email address, a relevant licensing or services agreement between the Domain Name or email address registrant and the Applicant has terminated, or the Domain Name or email address registrant has failed to renew the Domain Name or email address) (CRLReason \#5, cessationOfOperation);

10. the Subordinate CAs confirm a material change in the information contained in the subscriber certificate (CRLReason \#9, privilegeWithdrawn);

11. the Subordinate CAs confirm that the subscriber certificate was issued without complying with the applicable requirements set forth by CA/Browser Forum, this CP/CPS, the Subscriber Agreement provided, or requirements imposed by Application Software Suppliers for which Root CA certificates are registered that this Subordinate CA may issue the qualified certificate with the same expiry date of the original certificate without charge (CRLReason \#4, superseded);

12. the Subordinate CAs determine or is made aware that any of the information appearing in the Certificate is inaccurate (CRLReason \#9, privilegeWithdrawn);

13. The Subordinate CAs’ right to issue subscriber certificates under CA/Browser Forum requirements expire or are revoked or terminated, unless the Subordinate CAs have made arrangements to continue maintaining the CRLRepository (CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL);

14. Revocation is required by relevant requirements set forth by CA/Browser Forum, this CP/CPS for a reason that is not otherwise required to be specified by this section 4.9.1.1 (CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL); or

15. the Subordinate CAs are made aware of a demonstrated or proven method that exposes the subscriber’s Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed (CRLReason \#1, keyCompromise).

The Subordinate CAs may revoke any subscriber certificate in its sole discretion when deemed appropriate.

#### 4.9.1.2 Reasons for Revoking a Subordinate CA Certificate

In the occurrence of the following event, the Root CAs shall revoke the corresponding Subordinate CA certificate within seven (7) days at the time that such event is discovered:

1.  the Subordinate CAs request revocation in writing;

2.  The Subordinate CAs notify the Root CAs that the original application to this service was not authorized and does not retroactively grant authorization;

3.  The Root CAs obtain an evidence that the Subordinate CAs’ Private Key corresponding to the Public Key in the Subordinate CA certificate suffered a Key Compromise or no longer complies with the requirements of SMBR 6.1.5 and SMBR 6.1.6;

4.  The Root CAs obtain evidence that the Subordinate CA certificate was misused;

5.  The Root CAs are made aware that the Certificate was not issued in accordance with or that Subordinate CAs have not complied with the BR or this CP/CPS;

6.  The Root CAs determine that any of the information appearing in the Subordinate CA certificate is inaccurate or misleading;

7.  The Root CAs or the Subordinate CAs cease operations for any reason and has not made arrangements for another CA to provide revocation support for the subscriber certificate;

8.  The Root CAs’ or Subordinate CAs’ right to issue Certificates under CA/Browser Forum requirements expire or are revoked or terminated, unless the CAs have made arrangements to continue maintaining the CRL Repository;

9.  Revocation of the Subordinate CA certificate is required by the Root CAs’ CP/CPS;

10. The Root CAs determine that the technical content or format of the certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties; or

11. Cybertrust terminates this service.

#### 4.9.1.3 Reason of Revoking Other Certificates

##### 4.9.1.3.1 Root CA Certificate

In the occurrence of any one of the following events, the Root CAs revoke their Root CA certificate at the time that such event is discovered; provided, however, that, with regard to (ii) below, the Root CAs may revoke its certificate on a day that is separately notified by the Root CAs before termination of operations:

1. when it is learned that the Private Key of either one of Root CAs has been compromised; or

2. when the Root CAs are to terminate their certification operations and have not made arrangements for another Root CA to provide revocation support for the Subordinate CA certificates.

3. The Root CAs' rights to issue Certificates under the Related Rules expire or are revoked or terminated, unless the Root CAs have made arrangements to continue maintaining the CRL Repository;

4. The Root CAs determine that the technical content or format of the certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties.

### 4.9.2 Who can request revocation

Persons who may request revocation shall be the application supervisor, the person in charge of application, or an agent who is duly authorized by the subscriber and who knows information that was notified by the Subordinate CAs when the issuance application of the certificate was submitted, which is shared only between the Subordinate CA and the subscriber.

Other third parties may submit Certificate Problem Reports informing the CAs of reasonable cause, if exists, to revoke the certificate.

### 4.9.3 Procedure for revocation request

A subscriber shall submit a revocation request via document, email, or in the method indicated by Cybertrust on its website. The revocation request must include information that is known only to the Subordinate CA and the subscriber, reason of revocation, contact information and so on in accordance with instructions of the Subordinate CAs’.

The Subordinate CAs shall verify the reason of revocation as prescribed in “3.4 Identification and authentication for revocation request" of this CP. In the case revocation of certain Subscriber's certificates is requested by third parties; the CA shall verify the revocation reasons and revoke reported certificates if the CA found the revocation is deemed appropriate. 

The CAs do not notify the Subscriber after the certificate revocation. However, the CA may contact the Subscribers to notify on the revocation if the revocation is requested along with the free reissue stipulated in "9.1 Fees" of this CP.

### 4.9.4 Revocation request grace period

In the occurrence of an event corresponding to "4.9.1.1 Reasons for Revoking a subscriber certificate" of this CP/CPS, a subscriber shall promptly submit a revocation request.

### 4.9.5 Time within which CA must process the revocation request

The Subordinate CAs accept the revocation request 24 hours a day, 7 days a week.

Within 24 hours after receiving a Certificate Problem Report, the Subordinate CAs 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 Subordinate CAs shall work with its 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 Subordinate CAs 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 Reasons for Revoking a Subscriber Certificate" of this CP/CPS. The date selected by the Subordinate CAs should consider the following:

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

5. Relevant legislation.

### 4.9.6 Revocation checking requirement for relying parties

The Relying Parties shall verify the certificate revocation with the CRL issued by the CAs.

### 4.9.7 CRL issuance frequency (if applicable)

The Subordinate CAs issue the CRL in a cycle of at least 7 days. However, the Subordinate CAs update and disclose the CRL in 24 hours after revocation if there is any revoked subscriber certificate. The Root CAs SHALL update CRLs at least (i) once every twelve months and (ii) within 24 hours after revoking a Subordinate CA Certificate, and the value of the nextUpdate field MUST NOT be more than twelve months beyond the value of the thisUpdate field.

### 4.9.8 Maximum latency for CRLs (if applicable)

The CAs shall publish the CRL within reasonable time after the issuance of CRL For the cycle of the CRL update, "4.9.7 CRL issuance frequency (if applicable)" of this CP/CPS shall be applied.

### 4.9.9 On-line revocation/status checking availability

OCSP does not provide revocation information based on OCSP to the Subordinate CA Certificate issued from SecureSign Root CA16 and S/MIME Certificate.

### 4.9.10 On-line revocation checking requirements

Not applicable.

### 4.9.11 Other forms of revocation advertisements available

Not applicable.

### 4.9.12 Special requirements re key compromise

When the Subordinate CAs learn that the subscriber’s Private Key has been compromised or there is a possibility thereof, the Subordinate CAs shall initiate the revocation procedures of the certificate based on "4.9.3 Procedure for revocation request" of this CP/CPS. The subordinate CAs accept a report for the Private Key Compromise from the third party at the problem report contact listed in "1.5.2 Contact person" of this CP/CPS.

Reports or subsequent responses to the Subordinate CAs on key compromise shall include;

1. the demonstration on the Private Key Compromise:

   - Private Key itself and/or

   - a CSR signed by the compromised Private Key with the Common Name of which value specified by the Subordinate CAs; and

2. name and reachable contact information such as email address and/or phone number of a person who reports the problem.

### 4.9.13 Circumstances for suspension

The CAs do not accept applications for suspending the certificates.

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

The CAs shall not provide services that enable the verification of the certificate status other than by way of CRL.

### 4.10.1 Operational characteristics

Revocation entries on a CRL Responses shall not be removed until after the Expiry Date of the revoked Certificates.

### 4.10.2 Service availability

The CAs shall operate and maintain its CRL capability with resources sufficient to provide a response time of ten seconds or less under normal operating conditions. CRLs are updated and reissued at least every seven days, and the value of the nextUpdate field MUST NOT be more than ten days beyond the value of the thisUpdate field.

The CAs shall maintain an online 24 hours a day, 7 days a week Repository that application software can use to automatically check the current status of all unexpired certificates issued by the CAs.

The CAs shall maintain a continuous 24 hours a day,7days a week ability to respond internally to a high-priority Certificate Problem Report, and where appropriate, forward such a notification to law enforcement authorities or to CTJ PA, and/or revoke a certificate that is the subject of such a notification.

### 4.10.3 Optional features

No Stipulation.

## 4.11 End of subscription

The reasons for ending the use of a subscriber's certificate shall be set forth in the Subscriber Agreement. Moreover, if a subscriber wishes to terminate the Subscriber Agreement midway during the validity period of the certificate, the subscriber must submit a certificate revocation request with the CAs based on "4.9.3 Procedure for revocation request" of this CP/CPS.

## 4.12 Key escrow and recovery

### 4.12.1 Key escrow and recovery policy and practices

The CA does not escrow and recovery subscriber private keys.

### 4.12.2 Session key encapsulation and recovery policy and practices

Not applicable.

-----------------------------------------------------
# 5\. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS

## 5.1 Physical controls

### 5.1.1 Site location and construction

The CA systems shall be installed in a facility that is not easily affected by earthquakes, fires, floods, and other disasters (the "Facility"; unless separately prescribed herein, they shall include the main site and the backup site set forth in "5.1.8 Off-site backup" of this CP/CPS). The Facility shall undergo architectural measures for preventing the damage of earthquakes, fires, floods and other disasters as well as preventing unauthorized invasion. Information regarding the location of the CAs shall not be indicated outside or inside the building where the Facility is located.

### 5.1.2 Physical access

The Facility and the respective rooms inside the Facility where certification operations are performed shall be set with a security level according to the importance of the operation, and suitable entrance/exit control shall be performed. For authentication upon entering/existing the room, an entrance/exit card or biometric identification or other implementable technological means shall be used in accordance with the security level. A measure must be implemented where the doors cannot be opened unless multiple persons with authority are present for entry into particularly important rooms, for access to other important assets in the same room, and for opening one or both two doors of the safe of the CAs' system.

The Facility and the respective rooms inside the Facility where certification operations are performed shall be monitored with a monitoring system for 24 hours a day, 7 days for a week.

### 5.1.3 Power and air conditioning

A power sources with necessary and sufficient capacity for operating CA systems and related equipment shall be secured in the Facility. An uninterruptible power supply and a private power generator shall be installed as measures against instantaneous interruption and blackouts. Air-conditioning equipment shall be installed in the respective rooms where certification operations are performed, and this shall be duplicated in particularly important rooms.

### 5.1.4 Water exposures

A water leakage detector shall be installed in the particularly important rooms in the Facility where certification operations are performed, and waterproofing measures shall be taken.

### 5.1.5 Fire prevention and protection

The Facility is of a fire-proof construction. The particularly important rooms shall be located within the fire retarding division, and fire alarms and automatic gas fire extinguishers shall be installed.

### 5.1.6 Media storage

Media containing the backup data of the CA systems and documents and the like used in the validation shall be archived in a room in which only authorized personnel can enter.

### 5.1.7 Waste disposal

Documents containing Confidential Information shall be disposed of after being shredded with a shredder. Electronic mediums shall be physically destroyed, initialized, demagnetized, or subject to other similar measures to completely erase the recorded data before being discarded.

### 5.1.8 Off-site backup

The original or copy of the Private Keys of the CAs and important assets for system recovery shall be archived on the main site and in a remote backup site. The locking of the safe in the backup site shall be controlled by multiple persons, and the opening/closing of the safe shall be recorded.

### 5.1.9 Anti-Earthquake Measures

The Facility is of an earthquake-resistant construction, and the equipment and fixtures of CA systems have undergone tip-prevention measures and anti-drop measures.

## 5.2 Procedural controls

### 5.2.1 Trusted roles

Cybertrust shall set forth the personnel required for operating the CAs (the "CA staffs") and their roles as follows.

#### 5.2.1.1 Certification Authority Supervisor

The Certification Authority Supervisor of each CA shall govern their CA. The Certification Authority Supervisor is collectively referred to as the “CA Supervisor” in this document and this CP/CPS.

#### 5.2.1.2 Issuing Authority Manager

The Issuing Authority Manager shall control the operations of the Issuing Authority of the CA.

#### 5.2.1.3 Issuing Authority System Administrator

The Issuing Authority System Administrator shall maintain and control the CA systems under the control of the Issuing Authority Manager.

#### 5.2.1.4 Issuing Authority Operator

The Issuing Authority Operator shall assist the operations of the Issuing Authority Manager and the Issuing Authority System Administrator; provided, however, that the Issuing Authority Operator is not authorized to operate the CA systems.

#### 5.2.1.5 Registration Authority Manager

The Registration Authority Manager (the “RA Manager”) shall control the RA operations for the CAs.

#### 5.2.1.6 Registration Authority Operator Manager

The Registration Authority Operator Manager (the “RA Operator Manager”) shall control the Registration Authority Operators.

#### 5.2.1.7 Registration Authority Operator

The Registration Authority Operator (the “RA Operator”) shall process the applications from the subscribers under the control of the RA Manager and request the issuance or revocation of certificates to the Issuing Authority.

### 5.2.2 Number of persons required per task

Cybertrust shall appoint two or more Issuing Authority System Administrators and RA Operators, respectively.

### 5.2.3 Identification and authentication for each role

Cybertrust shall establish the entrance authority of the respective rooms where certification operations are performed and the operation authority of the CA systems in accordance with the respective roles. An entrance/exit card, a biometric identification, a digital certificate, and an ID/password are used independently or in combination to authenticate the identification and entrance/operation authority when entry into the respective rooms and upon operation of the system.

### 5.2.4 Roles requiring separation of duties

Cybertrust does not allow the concurrent serving of the Issuing Authority and the RA, and it does not allow the CA Supervisor to concurrently serve another role.

## 5.3 Personnel controls

### 5.3.1 Qualifications, experience, and clearance requirements

The CA staffs shall be hired and assigned based on the recruitment standards to be separately set forth by Cybertrust.

### 5.3.2 Background check procedures

The background check of employees to be assigned as the CA staffs shall be conducted based on Cybertrust's internal rules and regulations and the requirements set forth in SMBR.

### 5.3.3 Training requirements

Cybertrust shall implement training requirements and procedures to all employees being assigned as the CA staffs. The training requirements and procedures shall include, in addition to the education of this CP/CPS, and the Related Rules, the required training requirements and procedures in accordance with the role of the CA staffs.

All validation specialists must take a required internal examination.

The effectiveness of the training requirements and procedures shall be evaluated by the Issuing Authority Manager or the RA Manager, and retraining shall be implemented as needed.

### 5.3.4 Retraining frequency and requirements

Cybertrust shall implement retraining requirements and procedures to the CA staffs as needed. The CAs shall implement training in the occurrence of at least the following events:

1. When this CP/CPS, the Subscriber Agreement, and the Related Rules are amended, and when CTJ PA, the CA Supervisor, the Issuing Authority Manager, or the RA Manager for each CA thinks it necessary;

2. When the systems of the CAs where the CA staffs are assigned are changed, and when CTJ PA, each CA Supervisor, the Issuing Authority Manager or the RA Manager thinks it necessary; and

3. When CTJ PA, the CA Supervisor, the Issuing Authority Manager, or the Registration Authority Manager otherwise thinks it necessary.

### 5.3.5 Job rotation frequency and sequence

Cybertrust shall rotate jobs of the CA staffs as needed.

### 5.3.6 Sanctions for unauthorized actions

Cybertrust shall promptly investigate the cause and scope of influence and impose a penalty on that CA staff in accordance with Cybertrust's work rules when a CA staffs conduct an act that is in breach of this CP/CPS, Cybertrust's internal rules/regulations, and the Related Rules.

### 5.3.7 Independent contractor requirements

When Cybertrust is to assign employees of outsourcees, contract employees or dispatched employees (collectively, the "Contract Employees") as a CA staffs, Cybertrust shall conclude a contract that clearly sets forth the details of the outsourced work, confidentiality obligation to be imposed on the Contract Employees, and penal regulations, and demand the Contract Employees to observe this CP/CPS, Cybertrust's internal rules/regulations, and the Related Rules.

When the Contract Employees conduct an act that is in breach of this CP/CPS, Cybertrust's internal rules and regulations, and the Related Rules, penalties shall be imposed based on the foregoing contract.

### 5.3.8 Documentation supplied to personnel

Cybertrust shall implement measures so that the respective CA staffs can only refer to documents that are required according to their respective roles.

## 5.4 Audit logging procedures

### 5.4.1 Types of events recorded

Cybertrust shall collect the following records as audit logs in order to evaluate the compliance of this CP/CPS and/or adequacy of the security. The records shall include the date and time, identity of the person making the journal record, and description of the record.

1.  The CA certificate and key lifecycle events, including:

    - Key generation, backup, storage, recovery, archival, and destruction;

    - Certificate requests, renewal, and re-key requests, and revocation;

    - Approval and rejection of certificate requests;

    - Cryptographic device lifecycle management events;

    - Generation of Certificate Revocation Lists;

    - Introduction of new Certificate Profiles and retirement of existing Certificate Profiles.

2.  Subscriber Certificate lifecycle management events, including:

    - Certificate requests, renewal, and re-key requests, and revocation;

    - All verification activities stipulated in the relevant requirements and the CA’s Certification Practice Statement;

    - Approval and rejection of certificate requests;

    - Issuance of Certificates;

    - Generation of Certificate Revocation Lists; and

    - Multi-Perspective Issuance Corroboration attempts from each Network Perspective, minimally recording the following information:

      - an identifier that uniquely identifies the Network Perspective used;

      - the attempted domain name and/or IP address; and

      - the result of the attempt (e.g., "domain validation pass/fail", "CAA permission/prohibition").

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

    - Successful and unsuccessful PKI system access attempts;

    - PKI and security system actions performed;

    - Security profile changes;

    - Installation, update and removal of software on a Certificate System;

    - System crashes, hardware failures, and other anomalies;

    - Router and Firewall activities; and

    - Entries to and exits from the CA facility.

4.  Log records MUST include the following elements:

    - Date and time of event;

    - Identity of the person making the journal record (when applicable); and

    - Description of the event.

#### 5.4.1.1 Router and firewall activities logs

Among the audit logs stipulated in this CP/CPS "5.4.1 Types of events recorded", "Router and Firewall activities logs" of Security events shall be included the following.

- Successful and unsuccessful login attempts to routers and firewalls; and

- Logging of all administrative actions performed on routers and firewalls, including configuration changes, firmware updates, and access control modifications; and

- Logging of all changes made to firewall rules, including additions, modifications, and deletions; and

- Logging of all system events and errors, including hardware failures, software crashes, and system restarts.

### 5.4.2 Frequency of processing log

Cybertrust shall inspect the audit logs prescribed in "5.4.1 Types of events recorded" of this CP/CPS on a regular basis and as necessary.

### 5.4.3 Retention period for audit log

The CAs SHALL retain audit logs stipulated in “5.4.1Types of events recorded” of the CP/CPS, for at least two years:

1. CA certificate and key lifecycle management event records after the later occurrence of:

   - the destruction of the CA Private Key; or

   - 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 record for at least two (2) years after certificates are expired;

3. Any security event records after the event occurred.

When the audit logs are no longer required, the CA shall dispose of such audit logs based on the provisions of "5.1.7 Waste disposal" of this CP/CP.

### 5.4.4 Protection of audit log

Cybertrust shall implement access control to the audit logs so that only authorized personnel can view the audit logs. The CAs shall implement physical access control to the safe, and logical access control to folders and the like in cases of electronic mediums.

### 5.4.5 Audit log backup procedures

Cybertrust shall acquire the backup of the logs in the systems of the RAs and the Issuing Authorities. For paper mediums, only the original copies thereof need to be archived.

### 5.4.6 Audit collection system (internal vs. external)

Systems of the RAs and the Issuing Authorities shall automatically collect the audit logs by using the function installed in the system.

### 5.4.7 Notification to event-causing subject

Cybertrust shall collect and inspect the audit logs without notifying the party that caused the event.

### 5.4.8 Vulnerability assessments

Cybertrust conducts the following annual Risk Assessment:

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

Cybertrust also performs regular vulnerability assessment and implement the necessary measures for correcting the vulnerability. It shall also take necessary measures when risks or threats are discovered by regularly inspecting audit logs.

## 5.5 Records archival

### 5.5.1 Types of records archived

Cybertrust shall archive the following information in addition to the audit logs prescribed in "5.4.1 Types of events recorded" of this CP/CPS:

1. certificates of the CAs;

2. subscriber's certificates;

3. CRLs;

4. internal audit reports;

5. external audit reports;

6. documents received from the subscribers at the time of applications; and

7. this CP/CPS, and the Related Rules.

### 5.5.2 Retention period for archive

The CA shall retain archived audit logs set forth in "5.5.1 Types of records archived" of this CP/CPS and records listed below for a period of at least two years from their record creation timestamp or as long as required per "5.4.3 Retention period for audit log", whichever is longer.

1. All archived documentation related to the Certificate Systems, Certificate Management Systems and Root CA Systems.

2. All archived documentation relating to the verification, issuance, and revocation of certificate requests and Certificates after the later occurrence of:

   - such records and documentation were last relied upon in the verification, issuance, or revocation of certificate requests and Certificates; or

   - the expiration of the Subscriber Certificates relying upon such records and documentation.

The CA MAY choose a greater value as more appropriate in order to be able to investigate possible security or other types of incidents that will require retrospection and examination of past records archived.

When records are no longer required, the CA shall dispose of such records based on the provisions of "5.1.7 Waste disposal" of this CP/CPS.

### 5.5.3 Protection of archive

Records shall be protected based on the same procedures as "5.4.4 Protection of audit log" of this CP/CPS.

### 5.5.4 Archive backup procedures

Records shall be backed up based on the same procedures as "5.4.5 Audit log backup procedures" of this CP/CPS.

### 5.5.5 Requirements for time-stamping of records

Cybertrust shall record the date of creation or process on documentations and the like. If the date alone lacks authenticity as a record, the time should also be recorded. The issued date and time shall be recorded for certificates of the CAs and the subscribers. The CA systems shall undergo necessary measures for recording the accurate date and time of the issued certificate and audit logs.

### 5.5.6 Archive collection system (internal or external)

Certificates shall automatically be collected by using on the function of the CA systems. Other paper mediums shall be collected by the CA staffs.

### 5.5.7 Procedures to obtain and verify archive information

Cybertrust shall limit persons authorized to acquire and view records to the CA staffs, the auditor, and the persons authorized by CTJ PA. Validation regarding the legibility of records shall be implemented as needed.

## 5.6 Key changeover

Cybertrust renews the key pairs of the CAs so that the validity of the certificates of the CAs do not expire while a subscriber's certificate is valid.

The certificate that contains the CAs’ renewed public key is posted on Cybertrust's website.

## 5.7 Compromise and disaster recovery

### 5.7.1 Incident and compromise handling procedures

Cybertrust SHALL document a business continuity and disaster recovery procedures designed to notify and reasonably protect Application Software Suppliers with whom the Root CA is registered, Subscribers, and Relying Parties in the event of a disaster, security compromise, or business failure. Cybertrust SHALL annually test, review, and update these procedures.

When the Private Key (s) of CAs are compromised, Cybertrust shall execute the following:

1. discontinuation of certification operations using the compromised Private Key;

2. revocation of all the certificates that were issued from the Subordinate CAs that used the compromised Private Key;

3. investigation of the cause of compromise;

4. formulation of proposed remedial measures and evaluation/approval thereof by CTJ PA;

5. execution of remedial measures;

6. assessment on appropriateness of resuming business operations;

7. generation of new key pairs and issuance of certificates;

8. resumption of certification operations (including notification to subscribers and Relying Parties); and

9. reissuance of certificates

When the CAs suffer from a disaster, the Subordinate CAs shall perform recovery operations using backup hardware, software and data based on the business continuation plan prescribed in "5.7.4 Business continuity capabilities after a disaster" of this CP/CPS, exert efforts to resume the certification operations, and publish the fact of such resumption to the subscribers and Relying Parties when the certification operations are resumed.

In addition, if an event that is defined as an incident occurs under the requirements of each Application Software Suppliers that registers the Root CA Certificates, Cybertrust reports promptly all incidents to applicable Application Software Suppliers in the incident report format required by the Application Software Suppliers that registers provider and update the incident report regularly until the corresponding bug is resolved.

### 5.7.2 Computing resources, software, and/or data are corrupted

When hardware, software, or data is destroyed, Cybertrust shall continue performing the certification operations by using the backup hardware, software, or data.

### 5.7.3 Entity private key compromise procedures

In the event the Private Key that is being managed under the subscriber's own responsibility is compromised, or suspected of being compromised, the subscriber must take the certificate revocation procedures based on the procedures prescribed in "4.9 Certificate revocation and suspension" of this CP/CPS.

The Subordinate CAs revoke a subscriber's certificate based on the provision of "4.9.3 Procedure for revocation request" of this CP/CPS.

### 5.7.4 Business continuity capabilities after a disaster

Cybertrust shall separately set forth a business continuation plan regarding the recovery measures for recovering from disasters and business continuity. The business continuation plan defines the operating procedures of recovery and resumption of all or a part (revocation processing) of the operations of the CAs by using data and the like archived in the Facility.

With regard to the recovery time from disasters, the step-by-step recovery target is set forth in the business continuation plan based on investigations of the disaster situation.

## 5.8 CA or RA termination

When Cybertrust is to terminate the operations of one or more the CAs, it shall notify the subscribers in advance, as well as publish information to such effect on Cybertrust's website.

The information of subscribers held by Cybertrust shall be disposed of or provided to the transferee of business operations, and this shall be announced on Cybertrust's website after the termination of operations.

----------------------------------
# 6\. TECHNICAL SECURITY CONTROLS

## 6.1 Key pair generation and installation

### 6.1.1 Key pair generation

The key pairs of the CAs shall be generated in accordance with the procedure set force in the section 6.1.1.1 of the SMBR, in the presence of or by submitting the video recorded process to the auditor specified in "8.2 Identity/qualifications of assessor" and "8.3 Assessor's relationship to assessed entity" of this CP/CPS to ensure the key generation of those Root CAs and the Subordinate CAs are performed accordingly to predetermined procedures based on Key Generation Script.

In generating the key pair of the CA, the HSM that satisfies the standards of at least FIPS 140-2 Level 3 shall be used.

The Subordinate CAs reject a certificate request if one or more of the following conditions on generation of subscriber’s key pair are met;

1. The Key Pair does not meet the requirements set forth in section 6.1.5 and section 6.1.6 of the SMBR;

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

3. The Subordinate CAs are aware of a demonstrated or proven method that exposes the Applicant’s Private to compromise;

4. This Subordinate CA have previously been notified that the Applicant’s Private Key has suffered a Key Compromise, such as described in “4.9.3 Procedure for revocation request” and “4.9.12 Special requirements re key compromise” of this CP/CPS; or

5. the Subordinate CAs are aware of a demonstrated or proven method to easily compute the Applicant’s Private Key based on the Public Key (such as a Debian weak key, see https://wiki.debian.org/SSLkeys).

### 6.1.2 Private key delivery to subscriber

The Subordinate CAs do not archive the subscriber's private key.

The Subordinate CAs shall be generated a subscriber 's Private Key. The Subordinate CAs shall deliver a Private Key to a subscriber in a PKCS 12 file encrypted using a password and algorithm whose combination provides at least 112 bits of encryption strength based on SMBR Section 6.1.2. The Subordinate CAs delete the Subscriber Private Key after it’s delivered to its subscriber.

The Subordinate CAs have an authority to revoke Subscriber's certificate when the CA becomes aware that a Subscriber’s Private Key has been communicated to someone other than followings, or that there is any possibility of.

1. A person or organization not authorized by the Subscriber.

2. Personnel at this CA who is assigned to generate or provide Subscriber Private Keys.

### 6.1.3 Public key delivery to certificate issuer

A subscriber’s public key shall be generated by the Subordinate CA.

### 6.1.4 CA public key delivery to relying parties

The certificates of the Root CAs including the public key of the Root CAs is published in the repositories. The certificates of the Subordinate CA including the public key of the Subordinate CAs are published on Cybertrust's website.

The CA does not deliver the public key of the CA to Relying Parties.

### 6.1.5 Key sizes

The Algorithm Type and Key Size of the certificates of the Root CA shall be as follows.

| Name of CA           | Algorithm Type  | Key Size |
|----------------------|-----------------|----------|
| SecureSign Root CA16 | SHA384 with RSA | 4096 bit |

The Algorithm Type and Key Size of the Subordinate CA Certificates shall be as follows.

| Name of CA                      | Algorithm Type  | Key Size |
|---------------------------------|-----------------|----------|
| Cybertrust Japan SureMail CA G9 | SHA256 with RSA | 4096 bit |

The Algorithm Type system and Key Size of the subscriber's certificate shall be as follows.

| Subscriber's certificate; | Algorithm Type | Key Size |
|----|----|----|
| Certificate issued by Cybertrust Japan SureMail CA G9 | SHA256 with RSA | At least 2048 bit (with a modulus size in bits divisible by 8) |

### 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<sup>16</sup>+1 and 2<sup>256</sup>-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].

In generating the key pair of the CAs, the hardware that satisfies the standards of FIPS 140-2 shall be used.

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

The key usage of the Root CA Certificate shall be Certificate Signing, CRL Signing.

The key usage of Certificates shall be Digital Signature, Non-Repudiation, and Key Encipherment.

The Private Keys of the Root CA Certificates must not be used except for signing in the following cases:

1. Self-signed Certificates to represent the Root CA itself;

2. Certificates for Subordinate CAs and Cross Certificates;

3. Certificates for infrastructure purposes of the CA;

4. CRL published by the Root CA

## 6.2 Private Key Protection and Cryptographic Module Engineering Controls

### 6.2.1 Cryptographic module standards and controls

The cryptographic module for controlling the key pair of CAs shall be the HSM that satisfies the at least FIPS 140-2 Level 3 standard. The HSM shall be controlled by the Issuing Authority.

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

The Private Key used by the CA shall at all times be controlled by multiple Issuing Authority System Administrators.

### 6.2.3 Private key escrow

The CA does not escrow the Private Key of the CA and of subscribers.

### 6.2.4 Private key backup

The Issuing Authority System Administrator shall back up the Private Key of the CA. The Private Key backed up from the HSM shall be encrypted and then divided into multiple pieces, and each of them shall be safely archived in a lockable safe.

### 6.2.5 Private key archival

Cybertrust shall not archive the Private Key used by the CA.

### 6.2.6 Private key transfer into or from a cryptographic module

Cybertrust shall transfer a copy of the Private Key used by the CA to the backup site based on a safe method. When it is necessary to restore the Private Key of the CA due to a failure of the HSM or other reasons, the Issuing Authority System Administrator shall restore the Private Key using the backup archived in the main site or the backup site.

### 6.2.7 Private key storage on cryptographic module

The Private Keys used by the CAs shall be stored in the HSM that satisfies the standards of at least FIPS 140-2 Level 3.

### 6.2.8 Method of activating private key

The Private Key used by the CA shall be activated by multiple Issuing Authority System Administrators based on the procedures to be separately prescribed with the approval of the Issuing Authority Manager. The activation operation shall be recorded.

### 6.2.9 Method of deactivating private key

The Private Key used by the CA shall be non-activated by multiple Issuing Authority System Administrators based on the procedures to be separately prescribed with the approval of the Issuing Authority Manager. The non-activation operation shall be recorded.

### 6.2.10 Method of destroying private key

The Private Key used by the CA shall be destroyed by multiple Issuing Authority System Administrators based on the procedures to be separately prescribed under the control of the Issuing Authority Manager and according to instructions of the CA Supervisor. Simultaneously, the Private Key that was backed up pursuant to "6.2.4 Private key backup" of this CP/CPS shall also be destroyed based on the same procedures. The destruction operation shall be recorded.

### 6.2.11 Cryptographic Module Rating

The CA shall use the HSM that satisfies the standards set forth in "6.2.1 Cryptographic module standards and controls" of this CP/CPS.

## 6.3 Other aspects of key pair management

### 6.3.1 Public key archival

Storage of the public key shall be carried out by storing the certificate containing that public key.

### 6.3.2 Certificate operational periods and key pair usage periods

The maximum validity periods of each certificate shall be as per the following table.

| Type | Private Key | Maximum Validity Period of Certificate |
|:----|:----|:----|
| Certificates of Root CA | Not specified | 25 years 1month |
| Certificates of Subordinate CA | Not specified | 16 years 1month |
| S/MIME Certificates | Not specified | 824 days |

## 6.4 Activation data

### 6.4.1 Activation data generation and installation

The activation data used by the CA shall be generated and set upon giving consideration so that it cannot be easily speculated.

Cybertrust activates the cryptographic module containing its CA Private Keys according to the specifications of the hardware manufacturer. This method has been evaluated as meeting the requirements of at least FIPS 140-2 Level 3. The cryptographic hardware is held under two-person control as explained in Section 5.2.2. Cybertrust will only transmit activation data via an appropriately protected channel and at a time and place that is distinct from the delivery of the associated cryptographic module.

All Cybertrust personnel are instructed to use strong passwords and to protect PINs and passwords that meet the requirements specified by the CAB Forums Network Security Requirements.

### 6.4.2 Activation data protection

The activation data used in the CA shall be stored in a lockable safe in a room that is subject to entrance/exit control based on the provisions of "5.1.2 Physical access" of this CP/CPS.

### 6.4.3 Other aspects of activation data

No stipulation.

## 6.5 Computer security controls

### 6.5.1 Specific computer security technical requirements

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

In addition to the above, the CA system shall perform the following as security measures:

1. authentication of authority of the operator; 

2. identification and authentication of the operator;

3. acquisition of operation logs for important system operations;

4. setup of appropriate passwords and periodical modification thereof; and

5. backup and recovery.

### 6.5.2 Computer security rating

Cybertrust shall implement, in advance, installation assessment of hardware and software to be installed by the CA. Cybertrust shall also continuously collect information and perform evaluations regarding the security vulnerability in the system to be used and take necessary measures if a critical vulnerability is discovered.

## 6.6 Life cycle technical controls

### 6.6.1 System development controls

The establishment and modification of the CA system shall be performed based on the provisions to be separately set forth under the control of the development supervisor appointed internally by Cybertrust. When the development supervisor deems it necessary, verification which is indispensable and competent shall be carried out in a testing environment to verify that there are no security-related problems.

### 6.6.2 Security management controls

The CA system shall undergo necessary settings in order to ensure competent security. In addition to implementing entrance/exit control, access authorization control according to the security level, and antivirus measures of the said system, Cybertrust shall continuously collect information and perform evaluations regarding the security vulnerability, and promptly take necessary measures if a critical vulnerability is discovered.

### 6.6.3 Life cycle security controls

Cybertrust shall appoint a supervisor in the respective processes of development, operation, change, and disposal of the CA system, formulate and evaluate the work plan or procedures, and conduct testing as needed. The respective operations shall be recorded.

## 6.7 Network security controls

The CA manages network security in compliance with the Network and Certificate System Security Requirements set forth by the CA/Browser Forum.

The CA's system and external systems, such as the Internet, shall be connected via a firewall or the like and be monitored by an intrusion detection system. Provided that, the Root CA system shall not be connected to a network and shall be operated offline.

This Certification Authority conducts vulnerability assessments (Section 5.4.8 Vulnerability Assessments). If a discovered vulnerability is assessed as critical, remediation or mitigation measures must be completed within 96 hours. For vulnerabilities assessed at other levels, a decision on the response will be made within 30 days following a risk assessment and the results shall be documented in a report.

## 6.8 Time-stamping

All logs contain synchronized timestamp according to "5.5.5 Requirements for time-stamping of records" of this CP/CPS.

------------------------------------------
# 7\. CERTIFICATE, CRL, AND OCSP PROFILES

## 7.1 Certificate profile

Cybertrust uses the ITU X.509 version 3 standard to construct digital Certificates.

### 7.1.1 Version number(s)

Cybertrust issues X.509 version 3 Certificates.

### 7.1.2 Certificate extensions

The CAs use certificate extensions in accordance with applicable industry standards, including RFC 5280. The CAs do not issue Certificates with a critical private extension.

Certificates must contain the ExtendedKeyUsage extension, aligning to Application Software Supplier granted trust bits and private PKI use cases. Certificates may not contain the anyExtendedKeyUsage value. Subordinate CA Certificates for publicly trusted certificates, with the exception of cross-certificates that share a Private Key with a corresponding root CA certificate: must contain an ExtendedKeyUsage extension; must not include the anyExtendedKeyUsage; and must not include both the id-kp-serverAuth and id-kp-emailProtection in KeyPurposeId in the same certificate at the same time.

The subscriber certificates must also contain an ExtendedKeyUsage extension; must not include the anyExtendedKeyUsage; and must not include both the id-kp-serverAuth and id-kp-emailProtection in KeyPurposeId in the same certificate at the same time. For Certificates, the subjectAltName extension is populated in accordance with RFC 5280 as well. The authorized email address is included in subjectAltName extension.

Cybertrust generates non-sequential Certificate serial numbers (positive numbers greater than zero) that contain at least 64 bits of output from a CSPRNG.

Matters regarding the CA Certificate, and the Subscriber Certificate, are set forth in Appendix B.

### 7.1.3 Algorithm object identifiers

#### 7.1.3.1 SubjectPublicKeyInfo

| Type    | algorithm identifier | OID                  |
|:---------|:----------------------|:----------------------|
| RSA key | rsaEncryption        | 1.2.840.113549.1.1.1 |

#### 7.1.3.2 signatureAlgorithm

| Type            | algorithm identifier    | OID                   |
|:-----------------|:-------------------------|:-----------------------|
| SHA256 with RSA | sha256WithRSAEncryption | 1.2.840.113549.1.1.11 |
| SHA384 with RSA | sha384WithRSAEncryption | 1.2.840.113549.1.1.12 |

Matters regarding the certificates of the CA and subscribers are set forth in Appendix B.

Note that the Root CA shall not issue any Subordinate CA certificates using the SHA-1 hash algorithm, and neither Subordinate CAs issue any subscriber certificates using the SHA-1 hash algorithm.

### 7.1.4 Name forms

The CAs use distinguished names that are composed of standard attribute types, such as those identified in RFC 5280. The content of the Certificate Issuer Distinguished Name field must match the Subject DN of the Issuer CA to support name chaining as specified in section 4.1.2.4 of RFC 5280. Certificates are populated with the Issuer Name and Subject Distinguished Name required under Section 3.1.1.

The Root CAs shall not allow including organization unit (OU) attribute in the Subordinate CA certificates.

For S/MIME certificates, the subjectAltName extension must be present and contain an email address.

The CAs do not allow containing only metadata such as '.', '‐', and ’ ’ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable as a value in certificates.

Matters regarding the certificates of the CA and subscribers are set forth in Appendix B.  
  
Note that the Root CA shall not issue any Subordinate CA certificates using the SHA-1 hash algorithm and Subordinate CAs shall not issue any Subscriber certificates using the SHA-1 hash algorithm.

### 7.1.5 Name constraints

Not applicable.

### 7.1.6 Certificate policy object identifier

When the CAs issue a Certificate containing one of the policy identifiers, it asserts that the Certificate is managed in accordance with the policy that is identified herein.

| Name of Policy | Object Identifier |
|----|----|
| SureMail Certificate Policy (S/MIME Certificate Organization-validated Strict Generation) | 1.2.392.200081.1.32.3 |
| CABF S/MIME Certificate Policy (Organization-validated Strict Generation) | 2.23.140.1.5.2.3 |

Details regarding the certificates of each CA and subscribers are set forth in Appendix B.

### 7.1.7 Usage of Policy Constraints extension

Not applicable.

### 7.1.8 Policy qualifiers syntax and semantics

The CA may include Policy Qualifier field in the Certificate Policy extension, and may include brief statements in that Policy Qualifier field. This Policy Qualifier field may contain the URI that points to the CP and CPS applied to the certificate.

Matters regarding the certificates of the CA and subscribers are set forth in Appendix B.

### 7.1.9 Processing semantics for the critical Certificate Policies extension

Not applicable.

## 7.2 CRL profile

For revoked Subscriber Certificates, the CRLReason indicated MUST NOT be unspecified (0) or certificateHold(6). If the reason for revocation is unspecified, CAs MUST omit reasonCode entry extension.

The CRLReason for subscriber certificates must indicate one of following reason codes which is the most appropriate reason for revocation of the certificate listed in RFC5280, section 5.3.1 unless a CRLReason is unspecified. If the certificate is revoked for none of the reasons listed below, the CA does not provide the reason Code CRL entry extension.

1. keyCompromise (1),

2. privilegeWithdrawn (9),

3. affiliationChanged (3),

4. superseded (4),

5. cessationOfOperation (5),

Additionally, the CA may specify following revocation reason in the case of CA certificates revocation with the reasonCode CRL entry extension existed.

1. cACompromise (2)

### 7.2.1 Version number(s)

The CAs issue version 2 CRLs that conform to RFC 5280. Matters regarding the CRL issued by this CA are set forth in Appendix B of this CP.

### 7.2.2 CRL and CRL entry extensions

Matters regarding the CRL issued by this CA are set forth in Appendix B of this CP.

## 7.3 OCSP profile

This CA does not provide revocation information via OCSP.

### 7.3.1 Version number(s)

Not applicable.

### 7.3.2 OCSP extensions

Not applicable.

---------------------------------------------
# 8\. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

## 8.1 Frequency or circumstances of assessment

The CA is annually audited by the qualified outside auditor with the appropriate WebTrust Principles and Criteria formulated by CPA Canada, accordingly to the certificate. A visiting audit may additionally be performed on the CA by qualified outside auditor at the times CTJPA deemed necessary.

## 8.2 Identity/qualifications of assessor

The qualified auditor performing the external audit on the CA shall be independent from the CA.

## 8.3 Assessor's relationship to assessed entity

The auditor shall be, as a rule, a party that is independent from the operations of the CA and capable of maintaining neutrality.

## 8.4 Topics covered by assessment

The topics covered by the audit shall be the scope set forth in the programs of the WebTrust Principles and Criteria. The CA shall be audited with the appropriate criteria correspondingly to the certificate type.

## 8.5 Actions taken as a result of deficiency

Identified matters that are discovered in the verification are reported to CTJ PA, the CA Supervisor, the Issuing Authority Manager, and the RA Manager. When the auditor, CTJ PA, or the CA Supervisor determines that corrective action is required, corrective action shall be taken under the control of CTJ PA.

## 8.6 Communication of results

Validation results of the WebTrust Principles and Criteria are published according to the provisions of the respective requirements.

The results of each audit are reported to the CTJPA and to any third party entities which are entitled by law, regulation, or agreement to receive the audit results. Cybertrust’s WebTrust for CAs audit reports can be found at: https://www.cybertrust.ne.jp/ssl/repository_rt/index.html. On an annual basis and within three months of completion, Cybertrust submits relevant audit compliance reports to the Application Software Supplier who includes the CA's root CA certificate(s) in its application software.

## 8.7 Self-Audits

The Subordinate CAs that issue certificates performs regular internal audits against a randomly selected sample of at least thirty certificates or three percent of certificates whichever greater, issued during the audit period on at least a quarterly basis.

In addition, on-or-after March 15, 2025, the Subordinate CAs that issue the Certificates 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.

---------------------------------------
# 9\. OTHER BUSINESS AND LEGAL MATTERS

## 9.1 Fees

### 9.1.1 Certificate issuance or renewal fees

The fees and payment method concerning the certificates issued by the Subordinate CAs are notified so that a subscriber can properly verify the same such as by posting on Cybertrust's website or submitting a quotation. If there is any discrepancy between the description on Cybertrust's website and the description in the quotation separately submitted by Cybertrust, the descriptions of the quotation shall prevail.

Moreover, if the Subordinate CAs are requested by a subscriber to reissue a certificate based on the following reasons, the Subordinate CAs shall reissue a certificate that is valid for the remaining period, free of charge so as long as such request is made within thirty (30) days after the issuance of the original certificate in principle. The original certificate shall basically be revoked.:

1. the generated key pair was unintentionally erased or damaged during the application;

2. the Subordinate CAs otherwise deem it appropriate.

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

Cybertrust shall separately stipulate refund policy in the Subscriber Agreement.

## 9.2 Financial responsibility

### 9.2.1 Insurance coverage

Cybertrust shall maintain a sufficient financial foundation that is required for observing the subject matter set forth in this CP/CPS and for operating the CA. Cybertrust shall also take out appropriate insurance for covering its indemnity liability.

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

Cybertrust shall handle the following information as confidential information (the "Confidential Information"):

1. application information from a subscriber;

2. information set forth in "9.4.2 Information treated as private" of this CP/CPS;

3. inquiry information received from a subscriber, a Relying Party, or other third parties; and

4. information relating to the security of the CA.

### 9.3.2 Information not within the scope of confidential information

Of the information held by Cybertrust, the following information shall be excluded from the scope of Confidential Information:

1. information set forth in “2.2 Publication of certification information" of this CP/CPS as information to be published;

2. subscriber's certificate, the Subordinate CA Certificate, and the Root CA Certificate;

3. information that became public knowledge for reasons other than the negligence on the part of Cybertrust;

4. information that became public knowledge without any restriction of confidentiality from a party other than Cybertrust; and

5. information for which a subscriber agreed in advance to the effect of being disclosed or provided.

### 9.3.3 Responsibility to protect confidential information

Cybertrust shall implement measures for preventing the divulgence of the Confidential Information. Cybertrust shall not use the Confidential Information except when it is necessary for performing its operations; provided, however, that, when disclosure of the Confidential Information is demanded during the course of judicial, administrative or other legal proceedings; or when the Confidential Information is to be disclosed to a party such as a financial advisor or a potential acquirer/acquiree that executed a confidentiality agreement with Cybertrust in relation to an acquisition/merger and/or a party such as an attorney, certified public accountant, tax attorney or the like that legally bears the confidentiality obligation, or when Cybertrust obtains the prior approval of the subscriber disclosing the Confidential Information, Cybertrust may disclose the Confidential Information to the party requesting disclosure of such Confidential Information. In the foregoing case, the party receiving the disclosure of the requested Confidential Information must not disclose or divulge such information to any third party regardless of the method thereof.

The handling of protection of personal information shall be set forth in “9.4 Privacy of personal information" of this CP/CPS.

## 9.4 Privacy of personal information

### 9.4.1 Privacy plan

Handling of personal information held by Cybertrust shall be set forth in the Privacy Policy that is published on Cybertrust' website (https://www.cybertrust.co.jp/corporate/privacy-policy.html).

### 9.4.2 Information treated as private

Cybertrust shall handle, as personal information, any personally identifiable information that is included in the issuance of certificates and revocation requests, inquiries, or the like.

### 9.4.3 Information not deemed private

Cybertrust shall not deem, as personal information, any information other than the information set forth in "9.4.2 Information treated as private" of this CP/CPS.

### 9.4.4 Responsibility to protect private information

The responsibility of protecting the personal information held by Cybertrust shall be as set forth in "9.4.1 Privacy plan" of this CP/CPS.

### 9.4.5 Notice and consent to use private information

Based on a subscriber's issuance application or revocation request, it shall be deemed that Cybertrust has obtained the consent of the subscriber with regard to the CA using the personal information of that subscriber for performing its certificate issuance/revocation operations that are scheduled in this CP/CPS and the CA conducting an audit. Moreover, Cybertrust shall not use the personal information acquired from a subscriber for any purpose other than performing the certification operations; save for the cases set forth in "9.4.6 Disclosure pursuant to judicial or administrative process" of this CP/CPS.

### 9.4.6 Disclosure pursuant to judicial or administrative process

When disclosure of personal information handled by Cybertrust is demanded during the course of judicial, administrative, or other legal proceedings, Cybertrust may disclose such personal information.

### 9.4.7 Other information disclosure circumstances

When Cybertrust is to outsource a part of its operations, there may be cases where Cybertrust needs to disclose the Confidential Information and personal information to the outsourcee. In the foregoing case, Cybertrust shall include a provision in the service contract which imposes a confidentiality obligation on the outsourcee for maintaining the confidentiality of the Confidential Information and personal information.

## 9.5 Intellectual property rights

Unless separately agreed herein, all Intellectual Property Rights pertaining to the following information shall belong to Cybertrust or Cybertrust's supplier or licensor related to the CA service:

1. certificates issued by the CA and certificate revocation information;

2. this CP/CPS, and related documents;

3. public key and Private Key of the CA; and

4. hardware and software leased by the CA.

## 9.6 Representations and warranties

The representations and warranties of the Issuing Authority, the Registration Authority, subscribers and relying parties are prescribed below. Excluding the representations and warranties of the Issuing Authority, the Registration Authority, subscribers and relying parties that are expressly prescribed in “9.6 Representations and warranties" of this CP/CPS, the respective parties mutually verify that they shall not make any express or implied representations or warranties.

### 9.6.1 CA representations and warranties

Cybertrust represents and warrants that it bears the following obligations upon performing its operations.

- to comply with Relevant Requirements, this CP/CPS.

- to safely control the CA Private Key.

- to monitor and operate the system.

Cybertrust represents and warrants following obligations at the time of issuance.

1. Right to Use email address
The CAs implemented and followed a procedure for verifying that the Applicant either had the right to use, or had control of, email address for certificates listed in the Certificate’s subject field and subjectAltName extension, and accurately describe the procedure in this CP/CPS.

2. Authorization for Certificate
The CAs implemented and followed 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, and accurately describe the procedure in this CP/CPS.

3. Accuracy of Information
The CAs implemented and followed a procedure for verifying the accuracy of all of the information contained in the Certificate, and accurately describe the procedure in this CP/CPS.

4. Identity of Applicant
The CAs implemented and followed a procedure to verify the identity of the Applicant in accordance or with Section 3.2 and Section 7.1.4.2.2 of the SMBR for certificates, and accurately describe the procedure in this CP/CPS.

5. Subscriber Agreement
That the Subscriber has been provided with the most current version of the Subscriber Agreement, the applicable Subscriber Agreement is the Subscriber Agreement that was accepted when the Certificate was issued, and the Subscriber and the CAs are parties to a legally valid and enforceable Subscriber Agreement that satisfies these requirements, and both parties agree upon Subscriber Agreement.

6. Status
That the CAs maintain for 24 hours a day, 7 days a week publicly‐accessible Repository with current information regarding the status (valid or revoked) of all unexpired certificates.

7. Revocation
That the CAs revoke the certificate for any of the reasons specified in this CP/CPS, Subscriber Agreement, or relevant requirements.

### 9.6.2 RA representations and warranties

Cybertrust represents and warrants that it bears the following obligations upon performing operations as the RA:

1. Perform validation of subscribers based on this CP/CPS;

2. properly handle certificate issuance applications and revocation requests to the Issuing Authority; and

3. accept inquiries ("1.5.2 Contact person" of this CP/CPS).

### 9.6.3 Subscriber representations and warranties

A subscriber represents and warrants that it bears the following obligations upon using the service provided by the CA.

A subscriber represents and warrants following obligations.

1. Accuracy of Information
An obligation and warranty to provide correct and accurate 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 email address listed in the Certificate, and to use the Certificate solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement.

5. Reporting and Revocation
An obligation and warranty to 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 an obligation and warranty to 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 using the Private Key corresponding to the Public Key listed in a Certificate upon expiration or revocation of the Certificate.

7. Responsiveness
An obligation and warranty to respond to the CA's instruction within a specified period upon the occurrence of a revocation reason such as Private Key compromise or certificate misuse set forth in the Subscriber Agreement.

8. Acknowledgment and Acceptance
An obligation and warranty to acknowledge and accept that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber Agreement or if revocation is required by this CP/CPS, or relevant requirements set forth by CA/Browser Forum.

A subscriber also represents and warrants followings;

- to comply with appropriate usage of certificates and Private Keys,

- to refrain from using the certificate in email that are contrary to public order and morals,

- to refrain from using any certificate containing only metadata such as '.', '‐', and ' ' (i.e. space) characters, and/or any other value indicates that the value is absent, incomplete, or not applicable,

- to immediately request revocation of the certificate to the CA upon the occurrence of an event set forth in the Subscriber Agreement,

- to refrain from using an expired certificate or a revoked certificate,

- to observe applicable laws and regulations, and

- to respond to all the inquiries on information of their Certificate requests or the status of Certificate use which the CA asks to the Subscribers.

- to notify the CA when the Subscriber terminate using certain services.

### 9.6.4 Relying party representations and warranties

A Relying Party represents and warrants that it bears the following obligations:

1. to confirm that the certificates are being used for the usage set forth in "1.4.1 Appropriate certificate uses" of this CP/CPS;

2. to confirm the effective period and entries of certificates issued by the Subordinate CA;

3. to verify the digital signature and verify the issuer of the certificate;

4. to confirm whether the certificate has been revoked based on CRL; and

5. to bear legal liability for situations arising from the default of obligations prescribed in this paragraph.

### 9.6.5 Representations and warranties of other participants

No Stipulation.

## 9.7 Disclaimers of warranties

The CA shall not be liable for any damages excluding direct damages arising in relation to the warranties set forth in "9.6.1 CA representations and warranties" and "9.6.2 RA representations and warranties" of this CP/CPS.

The CA shall not be liable in any way for the consequences resulting from a Relying Party trusting the certificates of the CA and subscribers based on its own judgment.

## 9.8 Limitations of liability

Cybertrust shall not be liable in any way in the following cases in relation to the subject matter of "9.6.1 CA representations and warranties" and "9.6.2 RA representations and warranties" of this CP/CPS:

1. any damage that arises regardless of the CAs observing this CP/CPS, the Requirements specified in “1.1 Overview" of this CP/CPS, and legal regulations;

2. any damage that arises due to fraud, unauthorized use or negligence that is not attributable to Cybertrust;

3. damage that arises as a result of subscribers or Relying Parties neglecting to perform their respective obligations prescribed in “9.6Representations and warranties" of this CP/CPS;

4. damage that arises as a result of the key pair of the certificate issued by the Subordinate CA being divulged due to acts of a third party other than Cybertrust;

5. damage that arises as a result of the certificate infringing upon the copyright, trade secret or any other intellectual property right of the subscriber, a Relying Party or a third party; or

6. damage caused by improvement in the encryption algorithm decoding technology, based on hardware or software, exceeding current expectations.

The total amount of damages to be borne by Cybertrust against subscribers and Relying Parties or other third parties with regard to any and all damages arising in relation to the application, approval, trust or any other use of the certificates of the CA shall not exceed 10,000,000 yen under no circumstances whatsoever.

This upper cap shall be applied to each certificate regardless of the number of digital signatures, number of transactions, or number of damages pertaining to the respective certificates, and shall be allocated in order from the claim that is made first.

Among the damages arising from any default or breach of this CP/CPS, the Subscriber Agreement, or the Related Rules, the CA shall not be liable for any data loss, indirect damages including lost profits, consequential damages and punitive damages to the extent permitted under the governing law set forth in "9.14 Governing law" of the CP/CPS.

## 9.9 Indemnities

### 9.9.1 Indemnification by Subscribers and Relying Parties 

At the time that a subscriber or a Relying Party receives or uses a certificate issued by the Subordinate CAs, that subscriber or Relying Party shall become liable to compensate for any damage suffered by Cybertrust due to claims made by a third party against Cybertrust or lawsuits or other legal measures initiated or implemented by a third party against Cybertrust resulting from any of the following acts conducted by the Relying Party, as well as become responsible for implementing measures so that Cybertrust does not suffer any more damage:

1. unauthorized use, falsification, or misrepresentation during the use of a certificate;

2. breach of this CP/CPS, or the Subscriber Agreement; or

3. neglect by a subscriber to preserve the Private Key.

The Subordinate CAs are not the subscriber's or Relying Party's agent, trustee or any other representative.

### 9.9.2 Indemnification by Cybertrust

Cybertrust SHALL defend, indemnify, and hold harmless each Application Software Supplier for any 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 where such claim, damage, or loss was directly caused by such Application Software Supplier’s software as followings:

1. such Application Software Supplier’s software displays a certificate as not trustworthy while the certificate remains valid; or

2. such Application Software Supplier’s software fails verifying and displays a certificate as trustworthy, despite the certificate is expired or a revoked and the revocation status is provided and available online by the CAs.

## 9.10 Term and termination

### 9.10.1 Term

This CP/CPS shall come into effect when approved by CTJ PA. This CP/CPS is not invalidated before the time set forth in “9.10.2 Termination" of this CP/CPS.

### 9.10.2 Termination

This CP/CPS shall become invalid at the time that the CA terminates its operations, excluding the cases prescribed in “9.10.3 Effect of termination and survival" of this CP/CPS.

### 9.10.3 Effect of termination and survival

The provisions of 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 9.9, 9.10.2, 9.10.3, 9.13, 9.14, 9.15, and 9.16 of this CP/CPS shall continue to remain in force even after the termination of this CP/CPS.

## 9.11 Individual notices and communications with participants

When Cybertrust is to notify subscribers individually, such notice shall be deemed to have been made when a written notice is hand-delivered, delivered via postal mail with verification of receipt, or sent via email. Moreover, notices from subscribers to Cybertrust shall all be made in writing, and such notices shall be deemed to have arrived when such notices are sent and received by Cybertrust.

Cybertrust will notify the Application Software Suppliers in advance that requires notification of each matter, if any of the matters listed below occur:

1. Ownership or control of the CA certificates changes;

2. The Subordinate CA certificates which are not technically constrained and are directly or transitively chaining up to any Cybertrust Certificates, included in root store (e.g., stipulated in section 5.3 of Mozilla Root Store Policy) are controlled by an organization other than the CA;

3. Ownership or control of Cybertrust's operations changes; or

4. There is a material change in Cybertrust’s operations (e.g., when the cryptographic hardware related to a certificate in Mozilla's root store is consequently moved from one secure location to another).

5. Termination of CA operations

## 9.12 Amendments

### 9.12.1 Procedure for amendment

The CA shall review and update this CP/CPS at least once in 365 days, incrementing the version number and adding a dated changelog entry. This CP/CPS may be amended if needed based on CTJ PA’s instruction. CTJ PA shall approve the amendment after obtaining the evaluation of the CA staff or the evaluation of outside professionals such as attorneys or other experts.

### 9.12.2 Notification mechanism and period

After CTJ PA approves the amendment of this CP/CPS, Cybertrust shall implement measures to post the CP/CPS before amendment and the CP/CPS after amendment on the website so that the subscribers and Relying Parties can verify the amended contents. The amended CP/CPS shall come into force at the time that is separately set forth by CTJ PA unless the withdrawal of the amended CP/CPS is publicly announced by Cybertrust. If a subscriber does not request the revocation of its digital certificate within fifteen (15) days after the effectuation thereof, it shall be deemed that the subscriber has accepted the amended CP/CPS.

### 9.12.3 Circumstances under which OID must be changed

CTJ PA is responsible to decide if the OID updates are required correspondingly to this CP/CPS change.

## 9.13 Dispute resolution provisions

All disputes arising in relation to this CP/CPS, or the certificates issued by the CAs to which this CP/CPS for each certificate applies shall be submitted to the Tokyo District Court as the competent court of agreed jurisdiction in the first instance. With regard to matters that are not set forth in this CP/CPS or when doubts arise with regard to this CP/CPS, the parties shall consult in good faith to resolve such matters.

## 9.14 Governing law

This CP/CPS is construed in accordance with the laws of Japan, and the laws of Japan shall apply to any dispute pertaining to the certification operations based on this CP/CPS.

## 9.15 Compliance with applicable law

This CP/CPS is subject to all applicable laws and regulations.

## 9.16 Miscellaneous provisions

### 9.16.1 Entire agreement

Unless separately specified herein, the matters agreed in this CP/CPS supersede all other agreements unless this CP/CPS is amended or terminated.

### 9.16.2 Assignment

When Cybertrust is to assign this service to a third party, this CP/CPS, and the liabilities and other obligations set forth in them may be assigned to such third party.

### 9.16.3 Severability

Even if any provision of this CP/CPS is found to be invalid for one reason or another, the remaining provisions shall continue to remain in force.

In the event of a conflict between applicable requirements of CA/Browser Forum and a law, regulation or government order of any jurisdiction in which Cybertrust operates or issues certificates, Cybertrust MAY modify any conflicting requirement of CA/Browser Forum 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, regulation or government order. In such event, Cybertrust SHALL immediately (and prior to issuing a certificate under the modified requirement) include in this section of the CP/CPS a detailed reference to the law, regulation or government order requiring a modification of requirements of CA/Browser Forum and the specific modification to requirements of CA/Browser Forum implemented by Cybertrust.

Cybertrust 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 in accordance with the procedures specified in section 9.16.3 of applicable requirements.

### 9.16.4 Enforcement (attorneys’ fees and waiver of rights)

The CAs may seek indemnification and attorneys' fees from a party for damages, losses, and expenses related to that party's conduct. Cybertrust’s failure to enforce a provision of this CP/CPS does not waive Cybertrust’s right to enforce the same provision later or right to enforce any other provision of this CP/CPS. To be effective, waivers must be in writing and signed by Cybertrust.

### 9.16.5 Force Majeure

In the event the performance of a part or all of the obligations under this CP/CPS is delayed because of calamities, court orders, labor disputes, or other reasons that are not attributable to the CAs, Cybertrust shall be exempted from the performance of its obligations under this CP/CPS during the delay period and shall not be liable in any way against a subscriber or a third party that trusted or used a certificate.

## 9.17 Other provisions

No stipulation.

----------------------------------
# Appendix A: List of Definitions

<table>
<colgroup>
<col style="width: 36%" />
<col style="width: 63%" />
</colgroup>
<tbody>
<tr>
<th style="text-align: center;">Term</th>
<th style="text-align: center;">Definition</th>
</tr>
<tr>
<td style="text-align: left;">Archive</td>
<td style="text-align: left;">As used herein, the term "archive" refers to the process of storing expired certificates for a predetermined period.</td>
</tr>
<tr>
<td style="text-align: left;">Application Software Supplier</td>
<td style="text-align: left;">A supplier of software or other relying-party application software that displays or uses the Certificates, incorporates Root CA Certificates, and adopts the CA/Browser Forum’s Requirements as all or part of its requirements for participation in a root store program.</td>
</tr>
<tr>
<td style="text-align: left;">Cryptographic Module</td>
<td style="text-align: left;">Software, hardware, or a device configured from the combination of such software and hardware that is used for ensuring security in the generation, storage and use of Private Keys.</td>
</tr>
<tr>
<td style="text-align: left;">Suspension</td>
<td style="text-align: left;">Measure for temporarily invalidating a certificate during the effective period of that certificate.</td>
</tr>
<tr>
<td style="text-align: left;">Corporate identification number</td>
<td style="text-align: left;">12 digits number for identification assigned to corporates and organizations in accordance with regulation of "Commercial Registration Act" (https://www.japaneselawtranslation.go.jp/ja/laws/view/4186), which number is available at https://www1.touki.or.jp/gateway.html.</td>
</tr>
<tr>
<td style="text-align: left;">Key Size</td>
<td style="text-align: left;">A bit number that represents the key size (number of digits), which is also a factor in deciding the cryptographic strength.</td>
</tr>
<tr>
<td style="text-align: left;">Key Pair</td>
<td style="text-align: left;">A public key and a Private Key in public key cryptography. The two keys are unique in that one key cannot be derived from the other key.</td>
</tr>
<tr>
<td style="text-align: left;">Activation</td>
<td style="text-align: left;">To cause a system or device to be usable. Activation requires activation data, and specifically includes a PIN and pass phrase.</td>
</tr>
<tr>
<td style="text-align: left;">Subscriber Agreement</td>
<td style="text-align: left;">An agreement to be accepted by a subscriber to apply for and use a certificate. This CP/CPS constitutes a part of the Subscriber Agreement.</td>
</tr>
<tr>
<td style="text-align: left;">Compromise</td>
<td style="text-align: left;">A state where the confidentiality or integrity of information that is incidental to the Private Key and the Private Key is lost.</td>
</tr>
<tr>
<td style="text-align: left;">Public Key</td>
<td style="text-align: left;">One key of the key pair in public key cryptography that is notified to and used by the other party (communication partner, etc.).</td>
</tr>
<tr>
<td style="text-align: left;">Subject</td>
<td style="text-align: left;">The Legal Entity identified in a Certificate as the Subject. The Subject is the Subscriber.</td>
</tr>
<tr>
<td style="text-align: left;">Revocation</td>
<td style="text-align: left;">Measure for invalidating a certificate even during the effective period of that certificate.</td>
</tr>
<tr>
<td style="text-align: left;">Certificate Management System</td>
<td style="text-align: left;">A system used by a CA or Delegated Third Party to process, approve issuance of, or store certificates or certificate status information, including the database, database server, and storage.</td>
</tr>
<tr>
<td style="text-align: left;">Certificate Revocation List</td>
<td style="text-align: left;">Abbreviated as "CRL" in this CP/CPS. CRL is a list of revoked certificates. The CA publishes CRL so that the Relying Parties can verify the validity of certificates.</td>
</tr>
<tr>
<td style="text-align: left;">Certificate Systems</td>
<td style="text-align: left;">The system used by a CA or Delegated Third Party in providing identity verification, registration and enrollment, certificate approval, issuance, validity status, support, and other PKI‐related services.</td>
</tr>
<tr>
<td style="text-align: left;">Certificate Requester</td>
<td style="text-align: left;">A natural person who is the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or the employee or agent of a third party (such as software publisher) who completes and submits a Certificate Request on behalf of the Applicant.</td>
</tr>
<tr>
<td style="text-align: left;">Registration Identifier</td>
<td style="text-align: left;">The unique code assigned to an Applicant by the Incorporating or Registration Agency in such entity’s Jurisdiction of Incorporation or Registration.</td>
</tr>
<tr>
<td style="text-align: left;">Certification Operations</td>
<td style="text-align: left;">Series of operations that are performed during the life cycle controls of certificates. Including, but not limited to, operations of accepting issuance/revocation requests, validation operations, issuance/revocation/discarding operations, operations of responding to inquiries, billing operations, and system maintenance and management operations of the CA.</td>
</tr>
<tr>
<td style="text-align: left;">Backup Site</td>
<td style="text-align: left;">A facility that is separate from the main site for storing important assets of the CA required for certificate issuance and revocation to ensure business continuity during disasters, etc.</td>
</tr>
<tr>
<td style="text-align: left;">Private Key</td>
<td style="text-align: left;">One key of the key pair in public key cryptography that is kept private from third parties other than a subscriber.</td>
</tr>
<tr>
<td style="text-align: left;">Corporate Number</td>
<td style="text-align: left;">13 digits number for identification assigned, by National Tax Agency, to corporates and other entities which number is available at https://www.houjin-bangou.nta.go.jp/ for reference.</td>
</tr>
<tr>
<td style="text-align: left;">Main Site</td>
<td style="text-align: left;">A facility equipped with assets of the CA required for certificate issuance and revocation.</td>
</tr>
<tr>
<td style="text-align: left;">Escrow</td>
<td style="text-align: left;">As used herein, the term "deposit" refers to the processing of registering and storing a Private Key or a public key at a third party.</td>
</tr>
<tr>
<td style="text-align: left;">Repository</td>
<td style="text-align: left;">A website or system for posting public information such as this CP/CPS and CRL.</td>
</tr>
<tr>
<td style="text-align: left;">Linting</td>
<td style="text-align: left;">A process in which the content of digitally signed data such as a Certificates, CRL, or OCSP Response, or data-to-be-signed object such as a `tbsCertificate` (as described in RFC 5280, Section 4.1.1.1) is checked for conformance with the profiles and requirements defined in the BR.</td>
</tr>
<tr>
<td style="text-align: left;">Apple Root Certificate Program</td>
<td style="text-align: left;">The requirements which Apple imposes Root CAs to have their certificates trusted and included as the Root CA Certificate in Apple products.</td>
</tr>
<tr>
<td style="text-align: left;">Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates</td>
<td style="text-align: left;">Requirements for issuing publicly trusted S/MIME certificates which were formulated by the CA/Browser Forum.</td>
</tr>
<tr>
<td style="text-align: left;">Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (BR)</td>
<td style="text-align: left;">Requirements for issuing publicly trusted TLS Server certificates which were formulated by the CA/Browser Forum.</td>
</tr>
<tr>
<td style="text-align: left;">CA/Browser Forum</td>
<td style="text-align: left;">Organization that consists of the CA that issue publicly-trusted certificates for SSL/TLS communications and the companies that develop applications such as browsers. It creates standards about certificates. The website of the organization is https://cabforum.org/.</td>
</tr>
<tr>
<td style="text-align: left;">DBA/Tradename</td>
<td style="text-align: left;">Indicates a common name, trade name, shop name, etc. other than the legal name of an organization.</td>
</tr>
<tr>
<td style="text-align: left;">Distinguished Name</td>
<td style="text-align: left;">An identifier set forth in the X.500 recommendation formulated by ITU-T. Configured from attribute information such as a common name, organization name, and country name.</td>
</tr>
<tr>
<td style="text-align: left;">DNS CAA Email Contact</td>
<td style="text-align: left;">The email address defined in section A.1.1 of BR.</td>
</tr>
<tr>
<td style="text-align: left;">DNS CAA Phone Contact</td>
<td style="text-align: left;">The phone number defined in section A.1.2 of BR.</td>
</tr>
<tr>
<td style="text-align: left;">DNS CA Authorization Resource Record (CAA Record)</td>
<td style="text-align: left;">One of the DNS records defined in RFC8659 and RFC9495 which aims to clarify the certification authority to issue the certificate to a domain name and prevent the issuance of unintended certificates.</td>
</tr>
<tr>
<td style="text-align: left;">DNS TXT Record Email Contact</td>
<td style="text-align: left;">The email address defined in section A.2.1 of BR.</td>
</tr>
<tr>
<td style="text-align: left;">DNS TXT Record Phone Contact</td>
<td style="text-align: left;">The phone number defined in section A.2.2 of BR.</td>
</tr>
<tr>
<td style="text-align: left;">FIPS 140-2</td>
<td style="text-align: left;">FIPS (Federal Information Processing Standards Publication 140) is a U.S. federal standard that prescribes the specifications of security requirements in a cryptographic module. With this standard, the security requirements are classified as the levels of 1 (lowest) to 4 (highest).</td>
</tr>
<tr>
<td style="text-align: left;">IETF PKIX Working Group</td>
<td style="text-align: left;">Internet Engineering Task Force (IETF) is an organization that standardizes technologies used for the Internet, and the PKIX Working Group of IETF set forth RFC3647.</td>
</tr>
<tr>
<td style="text-align: left;">IP Address</td>
<td style="text-align: left;">32-bit or 128-bit label that is assigned to a device that uses the Internet Protocol for communications.</td>
</tr>
<tr>
<td style="text-align: left;">ITU-T</td>
<td style="text-align: left;">Telecommunications Standardization Sector of the International Telecommunication Union.</td>
</tr>
<tr>
<td style="text-align: left;">LEI (Legal Entity Identifier)</td>
<td style="text-align: left;">An international identifier assigned by the International Organization for Standardization (ISO) which enables clear and unique identification of legal entities participating in financial transactions.</td>
</tr>
<tr>
<td style="text-align: left;">Program Requirements - Microsoft Trusted Root Program</td>
<td style="text-align: left;">The requirements which Microsoft imposes Root CAs to have their certificates trusted and included as the Root CA Certificate in Microsoft products.</td>
</tr>
<tr>
<td style="text-align: left;">Mozilla Root Store Policy</td>
<td style="text-align: left;">The requirements which Mozilla imposes Root CAs to have their certificates trusted and included as the Root CA Certificate in Mozilla products.</td>
</tr>
<tr>
<td style="text-align: left;">Multi-Perspective Issuance Corroboration</td>
<td style="text-align: left;"><p>Refers to the process of obtaining same validation results as a domain validation and/or CAA check, confirmed using multiple Network Perspectives before Certificate issuance. This process can protect against Border Gateway Protocol (BGP) attacks or hijacks and improve the reliability of the validation results.</p>
<p>Network Perspective refers to a system that operates on a network to obtain the information necessary for some validations. The Network Perspective used as the primary system is called the Primary Network Perspective, while the Network Perspective operating from a remote location is referred to as the remote Network Perspective.</p></td>
</tr>
<tr>
<td style="text-align: left;">Network and Certificate System Security Requirements</td>
<td style="text-align: left;">The requirements developed by CA/Browser Forum for the security on network of publicly trusted certificate and the security of CA systems.</td>
</tr>
<tr>
<td style="text-align: left;">Name Constraints</td>
<td style="text-align: left;">Registration of the Key Usage and Name Constraint extensions in a certificate of a certification authority to restrict the issue of a subscriber certificate.</td>
</tr>
<tr>
<td style="text-align: left;">Organization-validated Strict Generation</td>
<td style="text-align: left;">Certificates of Strict generational Organization-validated type among the S/MIME Certificates issued based on "Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates" as set forth by the CA/Browser Forum and used for S/MIME signing.</td>
</tr>
<tr>
<td style="text-align: left;">RFC7231</td>
<td style="text-align: left;">The document named "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content" defining semantics of HTTP/1.1 message which is set forth by the IETF PKIX Working Group.</td>
</tr>
<tr>
<td style="text-align: left;">RFC7538</td>
<td style="text-align: left;">The document named "The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)" defining the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect) which is set forth by the IETF PKIX Working Group.</td>
</tr>
<tr>
<td style="text-align: left;">RSA</td>
<td style="text-align: left;">Public key cryptography developed by Rivest, Shamir, and Adelman.</td>
</tr>
<tr>
<td style="text-align: left;">SHA1/SHA256</td>
<td style="text-align: left;">A hash function used in digital signatures, etc. A hash function is used for reducing data into a given length based on mathematical operations and makes it infeasible to calculate the same output value from two different input values. It is also infeasible to inverse the input value from the output value.</td>
</tr>
<tr>
<td style="text-align: left;">WebTrust Principles and Criteria</td>
<td style="text-align: left;">Audit standards established by CPA Canada to evaluate the appropriateness and effectiveness of certification authority operations.</td>
</tr>
<tr>
<td style="text-align: left;">X.500</td>
<td style="text-align: left;">International standard of distribution directory services to be provided on a network standardized by ITU-T.</td>
</tr>
<tr>
<td style="text-align: left;">X.509</td>
<td style="text-align: left;">International standard of digital certificates standardized by ITU-T.</td>
</tr>
</tbody>
</table>

-------------------------------------
# Appendix B: Profile of Certificate

1)　Root CA Certificates

1-1) SecureSign Root CA16 (RCA16)

(Basic Certificate Fields)

<table>
<colgroup>
<col style="width: 26%" />
<col style="width: 35%" />
<col style="width: 37%" />
</colgroup>
<thead>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>version</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left;">Version</td>
<td style="text-align: left;">Version of the encoded certificate</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: INTEGER</p>
</td>
<td style="text-align: left;">2 (Ver.3)</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>serialNumber</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">CertificateSerialNumber</td>
<td style="text-align: left;">Serial number of certificate</td>
<td style="text-align: left;">* the following values:</td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: INTEGER</p>
</td>
<td style="text-align: left;"><p>RCA16</p>
<p>482310557539637110534164367265714055315282124869</p>
<p>(0x547B8DAB53110077A81803AEA12B1129AB42E045)</p></td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>signature</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">AlgorithmIdentifier</td>
<td style="text-align: left;">The identifier for the signature algorithm used by the CA to sign this certificate</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>algorithm</p>
</td>
<td style="text-align: left;">Object ID for the signature algorithm</td>
<td style="text-align: left;">* the following values:</td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;"><p>RCA16:</p>
<p>1.2.840.113549.1.1.12 (sha384WithRSAEncryption)</p></td>
</tr>
<tr>
<td style="text-align: left;">
<p>parameters</p>
</td>
<td style="text-align: left;">Parameters of signature algorithm</td>
<td style="text-align: left;">*RCA16</td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: NULL</p>
</td>
<td style="text-align: left;">NULL</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>issuer</strong></td>
<td style="text-align: left;"><strong>Value</strong></td>
</tr>
<tr>
<td style="text-align: left;">countryName</td>
<td style="text-align: left;">Country name attribute of certificate issuer</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for the country name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.6</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of country name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;">JP</td>
</tr>
<tr>
<td style="text-align: left;">organizationName</td>
<td style="text-align: left;">Organization name attribute of certificate issuer</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for organization name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.10</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of organization name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;">Cybertrust Japan Co., Ltd.</td>
</tr>
<tr>
<td style="text-align: left;">commonName</td>
<td style="text-align: left;">Common name attribute of certificate issuer</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for common name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.3</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of common name</td>
<td style="text-align: left;">* the following values:</td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;"><p>RCA16:</p>
<p>SecureSign Root CA16</p></td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>validity</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">Validity</td>
<td style="text-align: left;">Validity period of the certificate</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>notBefore</p>
</td>
<td style="text-align: left;">The date on which the certificate validity period begins</td>
<td style="text-align: left;">* the following values:</td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: UTCTime</p>
</td>
<td style="text-align: left;"><p>RCA16:</p>
<p>240730070811Z</p>
<p>(July 30, 2024 16:08:11 JST)</p></td>
</tr>
<tr>
<td style="text-align: left;">
<p>notAfter</p>
</td>
<td style="text-align: left;">The date on which the certificate validity period ends</td>
<td style="text-align: left;">* the following values:</td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: UTCTime</p>
</td>
<td style="text-align: left;"><p>RCA16:</p>
<p>440729065540Z</p>
<p>(July 29, 2044 15:55:40 JST)</p></td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>subject</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">countryName</td>
<td style="text-align: left;">Country name attribute of certificate subject</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for the country name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.6</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of country name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;">JP</td>
</tr>
<tr>
<td style="text-align: left;">organizationName</td>
<td style="text-align: left;">Organization name attribute of certificate subject</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for organization name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.10</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of organization name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;">Cybertrust Japan Co., Ltd.</td>
</tr>
<tr>
<td style="text-align: left;">commonName</td>
<td style="text-align: left;">Common name attribute of certificate subject</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for common name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.3</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of common name</td>
<td style="text-align: left;">* the following values:</td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;"><p>RCA16:</p>
<p>SecureSign Root CA16</p></td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>subjectPublicKeyInfo</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">SubjectPublicKeyInfo</td>
<td style="text-align: left;">Subject’s public key information</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>AlgorithmIdentifier</p>
</td>
<td style="text-align: left;">The identifier for cryptographic algorithm</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>algorithm</p>
</td>
<td style="text-align: left;">Object ID for the cryptographic algorithm</td>
<td style="text-align: left;">* the following values:</td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;"><p>RCA16:</p>
<p>1.2.840.113549.1.1.1 (rsaEncryption)</p></td>
</tr>
<tr>
<td style="text-align: left;">
<p>parameters</p>
</td>
<td style="text-align: left;">Parameters of cryptographic algorithm</td>
<td style="text-align: left;">* the following values:</td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;"><p>RCA16:</p>
<p>NULL</p></td>
</tr>
<tr>
<td style="text-align: left;">
<p>subjectPublicKey</p>
</td>
<td style="text-align: left;">Value of public key</td>
<td style="text-align: left;">* the following values:</td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: BIT STRING</p>
</td>
<td style="text-align: left;"><p>RCA16:</p>
<p>*Public key of 4096 bit size</p></td>
</tr>
</tbody>
</table>

(Certificate Extensions)

<table>
<colgroup>
<col style="width: 26%" />
<col style="width: 35%" />
<col style="width: 37%" />
</colgroup>
<thead>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>basicConstraints (extnId :== 2.5.29.19, critical :== TRUE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left;">BasicConstraints</td>
<td style="text-align: left;">Basic Constraints</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>cA</p>
</td>
<td style="text-align: left;">The flag to determine whether the supplied certificate is associated with a CA or an end entity</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: BOOLEAN</p>
</td>
<td style="text-align: left;">TRUE</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>keyUsage (extnId :== 2.5.29.15, critical :== TRUE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">KeyUsage</td>
<td style="text-align: left;">Key Usage</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: BIT STRING</p>
</td>
<td style="text-align: left;"><p>00000110 (0x06)</p>
<p>(keyCertSign, cRLSign)</p></td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>subjectKeyIdentifier (extnId :== 2.5.29.14, critical :== FALSE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">SubjectKeyIdentifier</td>
<td style="text-align: left;">Information of Subject Key Identifier</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>KeyIdentifier</p>
</td>
<td style="text-align: left;">The identifier for public key</td>
<td style="text-align: left;">* the following values:</td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">type: OCTET STRING</td>
<td style="text-align: left;"><p>RCA16:</p>
<p>186E34B6DB99556448A58649B89E4B93F70E2B0F</p></td>
</tr>
</tbody>
</table>

2)　Subordinate CA Certificates

2-1) Cybertrust Japan SureMail CA G9 (SMCA9)

(Basic Certificate Fields)

<table>
<colgroup>
<col style="width: 26%" />
<col style="width: 35%" />
<col style="width: 37%" />
</colgroup>
<thead>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>version</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left;">Version</td>
<td style="text-align: left;">Version of the encoded certificate</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: INTEGER</p>
</td>
<td style="text-align: left;">2 (Ver.3)</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>serialNumber</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">CertificateSerialNumber</td>
<td style="text-align: left;">Serial number of certificate</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: INTEGER</p>
</td>
<td style="text-align: left;"><p>115545098678772788817932575847967909108066359573</p>
<p>(0x143D38AEE7BEA7D577D96AA346B5581E0A651915)</p></td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>signature</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">AlgorithmIdentifier</td>
<td style="text-align: left;">The identifier for the signature algorithm used by the CA to sign this certificate</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>algorithm</p>
</td>
<td style="text-align: left;">Object ID for the signature algorithm</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">1.2.840.113549.1.1.11 (sha256WithRSAEncryption)</td>
</tr>
<tr>
<td style="text-align: left;">
<p>parameters</p>
</td>
<td style="text-align: left;">Parameters of signature algorithm</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: NULL</p>
</td>
<td style="text-align: left;">NULL</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>issuer</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">countryName</td>
<td style="text-align: left;">Country name attribute of certificate issuer</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for the country name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.6</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of country name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;">JP</td>
</tr>
<tr>
<td style="text-align: left;">organizationName</td>
<td style="text-align: left;">Organization name attribute of certificate issuer</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for organization name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.10</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of organization name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;">Cybertrust Japan Co., Ltd.</td>
</tr>
<tr>
<td style="text-align: left;">commonName</td>
<td style="text-align: left;">Common name attribute of certificate issuer</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for common name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.3</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of common name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;">SecureSign Root CA16</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>validity</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">Validity</td>
<td style="text-align: left;">Validity period of the certificate</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>notBefore</p>
</td>
<td style="text-align: left;">The date on which the certificate validity period begins</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: UTCTime</p>
</td>
<td style="text-align: left;"><p>240730081133Z</p>
<p>(July 30, 2024 17:11:33 JST)</p></td>
</tr>
<tr>
<td style="text-align: left;">
<p>notAfter</p>
</td>
<td style="text-align: left;">The date on which the certificate validity period ends</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: UTCTime</p>
</td>
<td style="text-align: left;"><p>340729081015Z</p>
<p>(July 29, 2034 17:10:15 JST)</p></td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>Subject</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">countryName</td>
<td style="text-align: left;">Country name attribute of certificate subject</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for the country name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.6</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of country name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;">JP</td>
</tr>
<tr>
<td style="text-align: left;">organizationName</td>
<td style="text-align: left;">Organization name attribute of certificate subject</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for organization name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.10</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of organization name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;">Cybertrust Japan Co., Ltd.</td>
</tr>
<tr>
<td style="text-align: left;">commonName</td>
<td style="text-align: left;">Common name attribute of certificate subject</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for common name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.3</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of common name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;">Cybertrust Japan SureMail CA G9</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>subjectPublicKeyInfo</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">SubjectPublicKeyInfo</td>
<td style="text-align: left;">Subject’s public key information</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>AlgorithmIdentifier</p>
</td>
<td style="text-align: left;">The identifier for cryptographic algorithm</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>algorithm</p>
</td>
<td style="text-align: left;">Object ID for the cryptographic algorithm</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">1.2.840.113549.1.1.1 (rsaEncryption)</td>
</tr>
<tr>
<td style="text-align: left;">
<p>parameters</p>
</td>
<td style="text-align: left;">Parameters of cryptographic algorithm</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">NULL</td>
</tr>
<tr>
<td style="text-align: left;">
<p>subjectPublicKey</p>
</td>
<td style="text-align: left;">Value of public key</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: BIT STRING</p>
</td>
<td style="text-align: left;">*Public key of 4096 bit size</td>
</tr>
</tbody>
</table>

(Certificate Extensions)

<table>
<colgroup>
<col style="width: 26%" />
<col style="width: 35%" />
<col style="width: 37%" />
</colgroup>
<thead>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>basicConstraints (extnId :== 2.5.29.19, critical :== TRUE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left;">BasicConstraints</td>
<td style="text-align: left;">Basic Constraints</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>cA</p>
</td>
<td style="text-align: left;">The flag to determine whether the supplied certificate is associated with a CA or an end entity</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: BOOLEAN</p>
</td>
<td style="text-align: left;">TRUE</td>
</tr>
<tr>
<td style="text-align: left;">pathLenConstraint</td>
<td style="text-align: left;">
<p>Path length constraint</p>
</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: INTEGER</p>
</td>
<td style="text-align: left;">0</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>certificatePolicies (extnId :== 2.5.29.32, critical :== FALSE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">PolicyInformation</td>
<td style="text-align: left;">Information of the Policy</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>policyIdentifier</p>
</td>
<td style="text-align: left;">Object ID for the Policy</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;"><p>2.23.140.1.5.2.3</p>
<p>(CABF S/MIME Organization-validated Strict Generation)</p></td>
</tr>
<tr>
<td style="text-align: left;">PolicyInformation</td>
<td style="text-align: left;">Information of the Policy</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>policyIdentifier</p>
</td>
<td style="text-align: left;">Object ID for the Policy</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">1.2.392.200081.1.32.3</td>
</tr>
<tr>
<td style="text-align: left;">
<p>policyQualifiers</p>
</td>
<td style="text-align: left;">
<p>Information of the policy qualifiers</p>
</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>PolicyQualifierID</p>
</td>
<td style="text-align: left;">
<p>Classification of the policy qualifiers</p>
</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">1.3.6.1.5.5.7.2.1 (CPSuri)</td>
</tr>
<tr>
<td style="text-align: left;">
<p>Qualifier</p>
</td>
<td style="text-align: left;">
<p>URI of CP/CPS is published</p>
</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type:IA5String</p>
</td>
<td style="text-align: left;">https://www.cybertrust.ne.jp/ssl/repository_rt/index.html</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>authorityInfoAccess (extnId :== 1.3.6.1.5.5.7.1.1, critical :== FALSE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">
<p>AccessDescription</p>
</td>
<td style="text-align: left;">Issuer of the Authority</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>accessMethod</p>
</td>
<td style="text-align: left;">Access method</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">1.3.6.1.5.5.7.48.2 (caIssuers)</td>
</tr>
<tr>
<td style="text-align: left;">
<p>accessLocation</p>
</td>
<td style="text-align: left;">Access location</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: IA5String</p>
</td>
<td style="text-align: left;">http://rtcrl.cybertrust.ne.jp/SecureSign/rtca16/rtca16.crt</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>keyUsage (extnId :== 2.5.29.15, critical :== TRUE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">KeyUsage</td>
<td style="text-align: left;">Key Usage</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: BIT STRING</p>
</td>
<td style="text-align: left;"><p>00000110 (0x06)</p>
<p>(keyCertSign, cRLSign)</p></td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>extKeyUsage (extnId :==  2.5.29.37, critical :== FALSE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">ExtKeyUsage</td>
<td style="text-align: left;">Extended Key Usage</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>KeyPurposeId</p>
</td>
<td style="text-align: left;">The purpose of the key contained in the certificate</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">1.3.6.1.5.5.7.3.4 (emailProtection)</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>authorityKeyIdentifier (extnId :== 2.5.29.35, critical :== FALSE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">AuthorityKeyIdentifier</td>
<td style="text-align: left;">Information of Authority Key Identifier</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>KeyIdentifier</p>
</td>
<td style="text-align: left;">The identifier for public key</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OCTET STRING</p>
</td>
<td style="text-align: left;">186E34B6DB99556448A58649B89E4B93F70E2B0F</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>cRLDistributionPoints (extnId :== 2.5.29.31, critical :== FALSE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">CRLDistributionPoints</td>
<td style="text-align: left;">CRL Distribution Point</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>DistributionPoint</p>
</td>
<td style="text-align: left;">CRL Distribution Point</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>uniformResourceIdentifier</p>
</td>
<td style="text-align: left;">URI of CRL Distribution Point</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: IA5String</p>
</td>
<td style="text-align: left;">http://rtcrl.cybertrust.ne.jp/SecureSign/rtca16/cdp.crl</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>subjectKeyIdentifier (extnId :== 2.5.29.14, critical :== FALSE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">SubjectKeyIdentifier</td>
<td style="text-align: left;">Information of Subject Key Identifier</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>KeyIdentifier</p>
</td>
<td style="text-align: left;">The identifier for public key</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OCTET STRING</p>
</td>
<td style="text-align: left;">83486A284E149A7D1AC5F2EA05D43E72BE600EA7</td>
</tr>
</tbody>
</table>

3)　S/MIME Certificates

3-1) Cybertrust Japan SureMail CA G9 (SMCA9)

(Basic Certificate Fields)

<table>
<colgroup>
<col style="width: 26%" />
<col style="width: 35%" />
<col style="width: 37%" />
</colgroup>
<thead>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>version</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left;">Version</td>
<td style="text-align: left;">Version of the encoded certificate</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: INTEGER</p>
</td>
<td style="text-align: left;">2 (Ver.3)</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>serialNumber</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">CertificateSerialNumber</td>
<td style="text-align: left;">Serial number of certificate</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: INTEGER</p>
</td>
<td style="text-align: left;">*Serial number of certificate (unique positive integer)</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>signature</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">AlgorithmIdentifier</td>
<td style="text-align: left;">The identifier for the signature algorithm used by the CA to sign this certificate</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>algorithm</p>
</td>
<td style="text-align: left;">Object ID for signature algorithm</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">1.2.840.113549.1.1.11 (sha256WithRSAEncryption)</td>
</tr>
<tr>
<td style="text-align: left;">
<p>parameters</p>
</td>
<td style="text-align: left;">Parameters of signature algorithm</td>
<td style="text-align: left;">NULL</td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: NULL</p>
</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>issuer</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">countryName</td>
<td style="text-align: left;">Country name attribute of certificate issuer</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for the country name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.6</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of country name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;">JP</td>
</tr>
<tr>
<td style="text-align: left;">organizationName</td>
<td style="text-align: left;">Organization name attribute of certificate issuer</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for the organization name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.10</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of organization name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;">Cybertrust Japan Co., Ltd.</td>
</tr>
<tr>
<td style="text-align: left;">commonName</td>
<td style="text-align: left;">Common name attribute of certificate issuer</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for the common name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.3</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of common name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;">Cybertrust Japan SureMail CA G9</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>validity</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">Validity</td>
<td style="text-align: left;">Validity period of certificate</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>notBefore</p>
</td>
<td style="text-align: left;">The date on which the certificate validity period begins</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: UTCTime</p>
</td>
<td style="text-align: left;">*The date on which the certificate validity period begins</td>
</tr>
<tr>
<td style="text-align: left;">
<p>notAfter</p>
</td>
<td style="text-align: left;">The date on which the certificate validity period ends</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: UTCTime</p>
</td>
<td style="text-align: left;">*The date on which the certificate validity period ends</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>subject</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">countryName</td>
<td style="text-align: left;">Validated country name attribute of certificate subject</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for the country name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.6</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of country name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;">*Country name attribute of certificate subject</td>
</tr>
<tr>
<td style="text-align: left;">stateOrProvinceName</td>
<td style="text-align: left;">Validated state or Province name attribute of certificate subject</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for the state or province name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.8</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of state or province name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString / UTF8String</p>
</td>
<td style="text-align: left;">*State or province name attribute of certificate subject</td>
</tr>
<tr>
<td style="text-align: left;">localityName</td>
<td style="text-align: left;">Validated locality name attribute of certificate subject</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for the locality name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.7</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of locality name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString / UTF8String</p>
</td>
<td style="text-align: left;">*Locality name attribute of certificate subject</td>
</tr>
<tr>
<td style="text-align: left;">organizationName</td>
<td style="text-align: left;">Formal organization name attribute of certificate subject</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for the organization name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.10</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of organization name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString / UTF8String</p>
</td>
<td style="text-align: left;">* Formal organization name attribute of certificate subject</td>
</tr>
<tr>
<td style="text-align: left;">organizationIdentifier</td>
<td style="text-align: left;">Organization identifier attribute of certificate subject</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for the organizational identifier</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type:OID</p>
</td>
<td style="text-align: left;">2.5.4.97</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of organization identifier</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString / UTF8String</p>
</td>
<td style="text-align: left;">*Organization identifier attribute of certificate subject</td>
</tr>
<tr>
<td style="text-align: left;">commonName</td>
<td style="text-align: left;">Common name attribute of certificate subject</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for common name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.3</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of common name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString / UTF8String</p>
</td>
<td style="text-align: left;">*Organization name</td>
</tr>
<tr>
<td style="text-align: left;">e-mailAddress</td>
<td style="text-align: left;">emailAddress of certificate subject</td>
<td style="text-align: left;">*When necessary</td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for emailAddress</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">1.2.840.113549.1.9.1</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of emailAddress</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: IA5String</p>
</td>
<td style="text-align: left;">*emailAddress of certificate subject</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>subjectPublicKeyInfo</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">SubjectPublicKeyInfo</td>
<td style="text-align: left;">Subject’s public key information</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>AlgorithmIdentifier</p>
</td>
<td style="text-align: left;">The identifier for the cryptographic algorithm</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>algorithm</p>
</td>
<td style="text-align: left;">Object ID for the cryptographic algorithm</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">1.2.840.113549.1.1.1 (rsaEncryption)</td>
</tr>
<tr>
<td style="text-align: left;">
<p>parameters</p>
</td>
<td style="text-align: left;">Parameters of cryptographic algorithm</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">NULL</td>
</tr>
<tr>
<td style="text-align: left;">
<p>subjectPublicKey</p>
</td>
<td style="text-align: left;">Value of public key</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: BIT STRING</p>
</td>
<td style="text-align: left;"><p>*The key size depends on application</p>
<p>*The key size must be at least 2048 bit</p></td>
</tr>
</tbody>
</table>

(Certificate Extensions)

<table>
<colgroup>
<col style="width: 26%" />
<col style="width: 35%" />
<col style="width: 37%" />
</colgroup>
<thead>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>basicConstraints (extnId :== 2.5.29.19, critical :== TRUE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left;">BasicConstraints</td>
<td style="text-align: left;">Basic Constraints</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>cA</p>
</td>
<td style="text-align: left;">The flag to determine whether the supplied certificate is associated with a ca or an end entity</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: BOOLEAN</p>
</td>
<td style="text-align: left;">FALSE</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>certificatePolicies (extnId :== 2.5.29.32, critical :== FALSE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">PolicyInformation</td>
<td style="text-align: left;">Information of the Policy</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>policyIdentifier</p>
</td>
<td style="text-align: left;">Object ID for the Policy</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;"><p>2.23.140.1.5.2.3</p>
<p>(CABF S/MIME Organization-validated Strict Generation)</p></td>
</tr>
<tr>
<td style="text-align: left;">
<p>PolicyInformation</p>
</td>
<td style="text-align: left;">Information of the Policy</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>policyIdentifier</p>
</td>
<td style="text-align: left;">Object ID for the Policy</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">1.2.392.200081.1.32.3</td>
</tr>
<tr>
<td style="text-align: left;">
<p>policyQualifiers</p>
</td>
<td style="text-align: left;">Information of the policy qualifiers</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>PolicyQualifierID</p>
</td>
<td style="text-align: left;">Classification of the policy qualifiers</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">1.3.6.1.5.5.7.2.1 (CPSuri)</td>
</tr>
<tr>
<td style="text-align: left;">
<p>Qualifier</p>
</td>
<td style="text-align: left;">URI of CP/CPS is published</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: IA5String</p>
</td>
<td style="text-align: left;">https://www.cybertrust.ne.jp/ssl/repository_rt/index.html</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>subjectAltName (extnId :== 2.5.29.17, critical :== FALSE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">SubjectAltName</td>
<td style="text-align: left;">Subject Alternative Name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>rfc822Name</p>
</td>
<td style="text-align: left;">rfc822Name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: IA5String</p>
</td>
<td style="text-align: left;">*emailAddress of certificate subject</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>authorityInfoAccess (extnId :== 1.3.6.1.5.5.7.1.1, critical :== FALSE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">AuthorityInfoAccess</td>
<td style="text-align: left;">Authority Information Access</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>AccessDescription</p>
</td>
<td style="text-align: left;">(Issuer of the Authority)</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>accessMethod</p>
</td>
<td style="text-align: left;">Access method</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">1.3.6.1.5.5.7.48.2 (caIssuers)</td>
</tr>
<tr>
<td style="text-align: left;">
<p>accessLocation</p>
</td>
<td style="text-align: left;">Access location</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: IA5String</p>
</td>
<td style="text-align: left;">http://smcrl.cybertrust.ne.jp/SureMail/smcag9/smcag9.crt</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>keyUsage (extnId :== 2.5.29.15, critical :==TRUE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">KeyUsage</td>
<td style="text-align: left;">Key Usage</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">type: BIT STRING</td>
<td style="text-align: left;"><p>11100000 (0xE0)</p>
<p>(digitalSignature, nonRepudiation, keyEncipherment)</p></td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>extKeyUsage (extnId :==  2.5.29.37, critical :== FALSE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">ExtKeyUsage</td>
<td style="text-align: left;">Extended Key Usage</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>KeyPurposeId</p>
</td>
<td style="text-align: left;">The purpose of the key contained in the certificate</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">1.3.6.1.5.5.7.3.4 (emailProtection)</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>authorityKeyIdentifier (extnId :== 2.5.29.35, critical :== FALSE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">AuthorityKeyIdentifier</td>
<td style="text-align: left;">Authority Key Identifier</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>KeyIdentifier</p>
</td>
<td style="text-align: left;">The identifier for the public key</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OCTET STRING</p>
</td>
<td style="text-align: left;">83486A284E149A7D1AC5F2EA05D43E72BE600EA7</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>cRLDistributionPoints (extnId :== 2.5.29.31, critical :== FALSE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">CRLDistributionPoints</td>
<td style="text-align: left;">CRL Distribution Point</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>DistributionPoint</p>
</td>
<td style="text-align: left;">CRL Distribution Point</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>uniformResourceIdentifier</p>
</td>
<td style="text-align: left;">URI of CRL Distribution Point</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: IA5String</p>
</td>
<td style="text-align: left;">http://smcrl.cybertrust.ne.jp/SureMail/smcag9/cdp.crl</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>subjectKeyIdentifier (extnId :== 2.5.29.14, critical :== FALSE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">SubjectKeyIdentifier</td>
<td style="text-align: left;">Subject Key Identifier</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>KeyIdentifier</p>
</td>
<td style="text-align: left;">The identifier for the public key</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OCTET STRING</p>
</td>
<td style="text-align: left;">*Hash value of the BIT STRING subjectPublicKey</td>
</tr>
</tbody>
</table>

4)　CRLs

4-1) SecureSign Root CA16 (RCA16)
4-2) Cybertrust Japan SureMail CA G9 (SMCA9)

(CRL Fields)

<table>
<colgroup>
<col style="width: 26%" />
<col style="width: 35%" />
<col style="width: 37%" />
</colgroup>
<thead>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>version</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left;">Version</td>
<td style="text-align: left;">Version of the CRL (Revocation list)</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: INTEGER</p>
</td>
<td style="text-align: left;">1 (Ver.2)</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>signature</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">AlgorithmIdentifier</td>
<td style="text-align: left;">The identifier for the signature algorithm used by the CRL issuer to sign the CertificateList</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>algorithm</p>
</td>
<td style="text-align: left;">Object ID for the signature algorithm</td>
<td style="text-align: left;">*One of the following values:</td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;"><p>SMCA9:</p>
<p>1.2.840.113549.1.1.11 (sha256WithRSAEncryption)</p></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;"></td>
<td style="text-align: left;"><p>RCA16,</p>
<p>1.2.840.113549.1.1.12 (sha384WithRSAEncryption)</p></td>
</tr>
<tr>
<td style="text-align: left;">
<p>parameters</p>
</td>
<td style="text-align: left;">Parameters of signature algorithm</td>
<td style="text-align: left;">RCA16 and SMCA9</td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: NULL</p>
</td>
<td style="text-align: left;">NULL</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>issuer</strong></td>
<td style="text-align: left;"><strong>Value</strong></td>
</tr>
<tr>
<td style="text-align: left;">countryName</td>
<td style="text-align: left;">Country name attribute of CRL issuer</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for the country name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.6</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of country name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;">JP</td>
</tr>
<tr>
<td style="text-align: left;">organizationName</td>
<td style="text-align: left;">Organization name attribute of CRL issuer</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for organization name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.10</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of organization name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;">Cybertrust Japan Co., Ltd.</td>
</tr>
<tr>
<td style="text-align: left;">commonName</td>
<td style="text-align: left;">Common name attribute of CRL issuer</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>type</p>
</td>
<td style="text-align: left;">Object ID for common name</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OID</p>
</td>
<td style="text-align: left;">2.5.4.3</td>
</tr>
<tr>
<td style="text-align: left;">
<p>value</p>
</td>
<td style="text-align: left;">Value of common name</td>
<td style="text-align: left;">*One of the following values:</td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: PrintableString</p>
</td>
<td style="text-align: left;"><p>RCA16:</p>
<p>SecureSign Root CA16</p></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;"></td>
<td style="text-align: left;"><p>SMCA9:</p>
<p>Cybertrust Japan SureMail CA G9</p></td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>thisUpdate</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">thisUpdate</td>
<td style="text-align: left;">The issue date of this CRL</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: UTCTime</p>
</td>
<td style="text-align: left;">*The date on which the certificate validity period begins</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>nextUpdate</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">nextUpdate</td>
<td style="text-align: left;">The date by which the next CRL is issued</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: UTCTime</p>
</td>
<td style="text-align: left;">*The date by which the next CRL is issued</td>
</tr>
</tbody>
</table>

(CRL Extensions)

<table>
<colgroup>
<col style="width: 26%" />
<col style="width: 35%" />
<col style="width: 37%" />
</colgroup>
<thead>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>cRLNumber (extnId :== 2.5.29.20, critical :== FALSE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left;">cRLNumber</td>
<td style="text-align: left;">CRL Number</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: INTEGER</p>
</td>
<td style="text-align: left;">*Serial number of CRL</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>authorityKeyIdentifier (extnId :== 2.5.29.35, critical :== FALSE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">AuthorityKeyIdentifier</td>
<td style="text-align: left;">Authority Key Identifier</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>KeyIdentifier</p>
</td>
<td style="text-align: left;">The identifier for public key</td>
<td style="text-align: left;">*One of the following values:</td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: OCTET STRING</p>
</td>
<td style="text-align: left;"><p>RCA16:</p>
<p>186E34B6DB99556448A58649B89E4B93F70E2B0F</p></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;"></td>
<td style="text-align: left;"><p>SMCA9:</p>
<p>83486A284E149A7D1AC5F2EA05D43E72BE600EA7</p></td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>issuingDistributionPoint (extnId :== 2.5.29.28, critical :== TRUE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">issuingDistributionPoint</td>
<td style="text-align: left;">CRL issuing distribution point</td>
<td style="text-align: left;">*Excluding RCA16</td>
</tr>
<tr>
<td style="text-align: left;">
<p>distributionPoint</p>
</td>
<td style="text-align: left;">CRL Distribution Point</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;">
<p>uniformResourceIdentifier</p>
</td>
<td style="text-align: left;">URI of CRL is published</td>
<td style="text-align: left;">* the following values:</td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: IA5String</p>
</td>
<td style="text-align: left;"><p>SMCA9:</p>
<p>http://smcrl.cybertrust.ne.jp/SureMail/smcag9/cdp.crl</p></td>
</tr>
<tr>
<td style="text-align: left;">
<p>onlyContainsUserCerts</p>
</td>
<td style="text-align: left;">The flag to indicate that CRL contains only for user certs.</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: BOOLEAN</p>
</td>
<td style="text-align: left;">TRUE</td>
</tr>
<tr>
<td style="text-align: left;">
<p>onlyContainsCACerts</p>
</td>
<td style="text-align: left;">The flag to indicate that CRL contains only for CA certs.</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: BOOLEAN</p>
</td>
<td style="text-align: left;">FALSE</td>
</tr>
<tr>
<td style="text-align: left;">
<p>indirectCRL</p>
</td>
<td style="text-align: left;">The flag to indicate that CRL is indirect CRL.</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: BOOLEAN</p>
</td>
<td style="text-align: left;">FALSE</td>
</tr>
</tbody>
</table>

(CRL Entry)

<table>
<colgroup>
<col style="width: 26%" />
<col style="width: 35%" />
<col style="width: 37%" />
</colgroup>
<thead>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>revokedCertificates</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left;">CertificateSerialNumber</td>
<td style="text-align: left;">Serial number of revoked certificate</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: INTEGER</p>
</td>
<td style="text-align: left;">*Serial number of revoked certificate</td>
</tr>
<tr>
<td style="text-align: left;">revocationDate</td>
<td style="text-align: left;">The date on which the revocation occurred</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: UTCTime</p>
</td>
<td style="text-align: left;">*The date on which the revocation occurred</td>
</tr>
</tbody>
</table>

(CRL Entry Extensions)

<table>
<colgroup>
<col style="width: 26%" />
<col style="width: 35%" />
<col style="width: 37%" />
</colgroup>
<thead>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>invalidityDate (extnId :== 2.5.29.24, critical :== FALSE)</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left;">invalidityDate</td>
<td style="text-align: left;">The date on which it is known or suspected That the certificate became invalid</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: GeneralizedTime</p>
</td>
<td style="text-align: left;">*The date on which the revocation of the certificate occurred.</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;background-color:gainsboro;"><strong>cRLReason (extnId :== 2.5.29.21, critical :== FALSE）</strong></td>
<td style="text-align: left;"><strong>value</strong></td>
</tr>
<tr>
<td style="text-align: left;">CRLReason</td>
<td style="text-align: left;">The reason code for the certificate revocation</td>
<td style="text-align: left;"></td>
</tr>
<tr>
<td style="text-align: left;"></td>
<td style="text-align: left;">
<p>type: ENUMERATED</p>
</td>
<td style="text-align: left;">*Value of reason code for the revocation</td>
</tr>
</tbody>
</table>

----------------------------------
# Appendix C: List of Revoked CAs

Root CAs

None.

Subordinate CAs

| Name of CA | Cybertrust Japan SureServer EV CA G4 |
|:---|:---|
| Serial Number of CA Certificate | 2637AA218390223237789A9BAD8A7076E622B634 |
| Validity Period of CA Certificate | April 9, 2020 to April 9, 2030 |
| Hash value (SHA-1) | 5570C3D33BB080E7D35B5AAB3B70EA52011B1688 |
| Hash value (SHA-256) | 399B950244EA52E374D2E4DE70A1CB872875F97E35516895B07E8CC5EB5A6B29 |
| Revocation Date | June 21, 2020 17:11:38 (JST) |
| Revocation Reason | Cessation of operation |
| Root CA | SecureSign Root CA12 |

| Name of CA | Cybertrust Japan SureServer EV CA G5 |
|:---|:---|
| Serial Number of CA Certificate | 3AD8B1A1D7334C9F62463939CBBB2C2CF4A9A438 |
| Validity Period of CA Certificate | April 9, 2020 to April 9, 2030 |
| Hash value (SHA-1) | 3BC8815266264418A0E7CFD44319DC4812753040 |
| Hash value (SHA-256) | 5ED4D96D978FAB1760216B6D7C6C4F636BFAD0CA25AC85BA7AFC459AFE7DA9F2 |
| Revocation Date | June 21, 2020 17:32:11 (JST) |
| Revocation Reason | Cessation of operation |
| Root CA | SecureSign Root CA15 |

| Name of CA | Cybertrust Japan SureServer EV CA G6 |
|:---|:---|
| Serial Number of CA Certificate | 0498C56281A1A3819A30ADA18BBB4906E24CDE66 |
| Validity Period of CA Certificate | June 3, 2020 to June 3, 2030 |
| Hash value (SHA-1) | 799D8151CE5D2A951A29CCA646A7B6509BC44143 |
| Hash value (SHA-256) | E8DC1CB6EAEC23B16BDF7E1BD57D25AB91975829953B3873483D54A6A465AA34 |
| Revocation Date | June 21, 2020 17:22:42 (JST) |
| Revocation Reason | Cessation of operation |
| Root CA | SecureSign Root CA14 |

| Name of CA | Cybertrust Japan SureServer CA G5 |
|----|----|
| Serial Number of CA Certificate | 79629546ABCD0B6293910AAE16D5594FDE8C3ABB |
| Validity Period of CA Certificate | April 9, 2020 to April 9, 2030 |
| Hash value (SHA-1) | 29924AB435117BD34627D640B8C6892733E0ED38 |
| Hash value (SHA-256) | AAA47419211F74D5C719B8F023E450BC610E0BE9D65A7FDEBD3C9B0642C78B43 |
| Revocation Date | June 21, 2020 17:13:23 (JST) |
| Revocation Reason | Cessation of operation |
| Root CA | SecureSign Root CA12 |

| Name of CA | Cybertrust Japan SureServer CA G6 |
|:---|:---|
| Serial Number of CA Certificate | 15B79EA71C7B8CB19506AAFF5EF5017E8CD31AAA |
| Validity Period of CA Certificate | April 9, 2020 to April 9, 2030 |
| Hash value (SHA-1) | 804FCCF74C78FD39CB165EBD95F8384D9F9C8232 |
| Hash value (SHA-256) | 7D494CE0DCF09312874C0296D4F8F9E2A7DA21CEE272201E56E905464FA6B3D6 |
| Revocation Date | June 21, 2020 17:33:09 (JST) |
| Revocation Reason | Cessation of operation |
| Root CA | SecureSign Root CA15 |

| Name of CA | Cybertrust Japan SureMail CA G5 |
|:---|:---|
| Serial Number of CA Certificate | 59562F1F81E6952E9AD89F430028201555B4A266 |
| Validity Period of CA Certificate | April 9, 2020 to April 9, 2030 |
| Hash value (SHA-1) | 7E1930F1329C8F895BDE50E6B0AD6B691ABD8E6E |
| Hash value (SHA-256) | 5285CFADE33A396D22C8FF2368A9143821B3F1B0FF527F8883B36BB8A9E95A47 |
| Revocation Date | June 21, 2020 17:15:03 (JST) |
| Revocation Reason | Cessation of operation |
| Root CA | SecureSign Root CA12 |

| Name of CA | Cybertrust Japan SureMail CA G6 |
|:---|:---|
| Serial Number of CA Certificate | 40BF947ECB33AB9CDB43DEBCBE9A7A079F1EEFC2 |
| Validity Period of CA Certificate | April 9, 2020 to April 9, 2030 |
| Hash value (SHA-1) | CD0961FD4B900771F740F697932A21A56DA149B6 |
| Hash value (SHA-256) | ED7685BBFCCB13134C04C4ED07F33D7361DC518B381916C402C0EE37B4B21CC0 |
| Revocation Date | June 21, 2020 17:34:11 (JST) |
| Revocation Reason | Cessation of operation |
| Root CA | SecureSign Root CA15 |

| Name of CA | Cybertrust Japan SureCode EV CA G1 |
|:---|:---|
| Serial Number of CA Certificate | 7AFCFB111FF70F66853C53910CF23FD51722743D |
| Validity Period of CA Certificate | April 9, 2020 to April 9, 2036 |
| Hash value (SHA-1) | 1A9F73CED9337336FA4F5A6B1B4764AAE3E4A953 |
| Hash value (SHA-256) | 0C6F6C6F6AC9508DBE69D4BDDC0C6C4CB52E3A0B54975B3BE483449799E0F3D6 |
| Revocation Date | June 21, 2020 17:24:02 (JST) |
| Revocation Reason | Cessation of operation |
| Root CA | SecureSign Root CA14 |

| Name of CA | Cybertrust Japan SureCode EV CA G2 |
|:---|:---|
| Serial Number of CA Certificate | 2E0725B935D866072AA61B4BE5DAC81059145ED7 |
| Validity Period of CA Certificate | April 9, 2020 to April 9, 2036 |
| Hash value (SHA-1) | 5B685C7BB809DBD9A046F18D995977F85546B983 |
| Hash value (SHA-256) | B040BDB929A9C292DFD76134E589538045C9D61EBBD139186422F56FAA4FB8E1 |
| Revocation Date | June 21, 2020 17:35:06 (JST) |
| Revocation Reason | Cessation of operation |
| Root CA | SecureSign Root CA15 |

| Name of CA                        | Cybertrust Japan SureCode CA G1          |
|-----------------------------------|----------------------------------|
| Serial Number of CA Certificate   | 1253A495AA2D9155A2FB649FB19C445512E172A4                         |
| Validity Period of CA Certificate | April 9, 2020 to April 9, 2036       |
| Hash value (SHA-1)                | DB4F530FE971742D128253BDACAD707AFD3A22AC                         |
| Hash value (SHA-256)              | C0BE67133B36BBEE3A05DC34FCFB866C0EE8EBC3D862B248A7EEC7E035B4A57A |
| Revocation Date                   | June 21, 2020 17:25:14 (JST)          |
| Revocation Reason                 | Cessation of operation     |
| Root CA                           | SecureSign Root CA14         |

| Name of CA                        | Cybertrust Japan SureCode CA G2      |
|-----------------------------------|----------------------------------|
| Serial Number of CA Certificate   | 02357E2E4380F68B22CE957CCF484EC34621E47F                         |
| Validity Period of CA Certificate | April 9, 2020 to April 9, 2036        |
| Hash value (SHA-1)    | CCF09D79D8D571103405CE2425298F887A78C793 |
| Hash value (SHA-256)              | 6AA7415D875D7B8945AE8B61E2AF2E2E78C98E058B8C2D072D41B2D48483FAA1 |
| Revocation Date                   | June 21, 2020 17:36:01 (JST)             |
| Revocation Reason                 | Cessation of operation              |
| Root CA                           | SecureSign Root CA15          |

| Name of CA                        | Cybertrust Japan SureTime CA G1                                  |
|-----------------------------------|------------------------------------------------------------------|
| Serial Number of CA Certificate   | 193A4704EF2D1D26D0D11D28FE44088473FD73EC                         |
| Validity Period of CA Certificate | April 9, 2020 to April 9, 2036                                   |
| Hash value (SHA-1)                | 4D4F47A322CAFED27EF8E7FCD908B24A2B7EABFD                         |
| Hash value (SHA-256)              | AE5ECCCAD770233E9AC5A2CE773CE752EB8DF51D7EA6FFC70BFF687613BD84CE |
| Revocation Date                   | June 21, 2020 17:26:16 (JST)                                     |
| Revocation Reason                 | Cessation of operation                                           |
| Root CA                           | SecureSign Root CA14                                             |

| Name of CA                        | Cybertrust Japan SureTime CA G2                                  |
|-----------------------------------|------------------------------------------------------------------|
| Serial Number of CA Certificate   | 076495342127D54FF3BFB5E350617FA716125A10                         |
| Validity Period of CA Certificate | April 9, 2020 to April 9, 2036                                   |
| Hash value (SHA-1)                | FA390AB94C7EEA8281F915F7E452CF6FA5B4B738                         |
| Hash value (SHA-256)              | 2B1F4353FAC8EA7269E761C96DDC43AD73334B9717CB5F2426E38DE20E460609 |
| Revocation Date                   | June 21, 2020 17:36:51 (JST)                                     |
| Revocation Reason                 | Cessation of operation                                           |
| Root CA                           | SecureSign Root CA15                                             |

| Name of CA | Cybertrust Japan SureTime CA G3 |
|:---|:---|
| Serial Number of CA Certificate | 610BE2A6DFBED34D816E17F762066D8850DE8C04 |
| Validity Period of CA Certificate | June 22, 2020 to June 22, 2036 |
| Hash value (SHA-1) | EB07FE22E8F17CE7FF797FAF1B854DCED841EDAD |
| Hash value (SHA-256) | CC0A0DF79B94888CB630FE07C43CF43E592813AE26D9141D410BAC0A16D7478C |
| Revocation Date | September 21, 2022 13:33:19 (JST) |
| Revocation Reason | Superseded |
| Root CA | SecureSign Root CA14 |

| Name of CA | Cybertrust Japan SureTime CA G4 |
|:---|:---|
| Serial Number of CA Certificate | 4AF6C82119A300E57F8E9E99C0A24E28D6E8F30D |
| Validity Period of CA Certificate | June 22, 2020 to June 22, 2036 |
| Hash value (SHA-1) | 9E70C71AF24EF3FFE27878D5AA54E2BE5BB619A1 |
| Hash value (SHA-256) | FF2D814C8D66794B383EACF5E1F2F44EB767F5C37C9855DC77A989680C6E8D47 |
| Revocation Date | September 21, 2022 13:38:55 (JST) |
| Revocation Reason | Superseded |
| Root CA | SecureSign Root CA15 |

| Name of CA | Cybertrust Japan SureMail CA G7 |
|:---|:---|
| Serial Number of CA Certificate | 438AD46A876954D1F2AA7E8C8AC28200F24270BE |
| Validity Period of CA Certificate | June 22, 2020 to June 22, 2030 |
| Signature Algorithm | SHA256 with RSA |
| Key Size of CA | 2048 bit |
| Hash value (SHA-1) | E78CBAC46E1C13595B253492FF82C5B53EC4FD22 |
| Hash value (SHA-256) | BE88404D1D6451268E1F90EC93BC2172876B22678E5405EACE95B1CDF35FAD07 |
| Revocation Date | April 28, 2023 16:12:38 (JST) |
| Revocation Reason | Cessation of operation |
| Root CA | SecureSign Root CA12 |

| Name of CA | Cybertrust Japan SureMail CA G8 |
|:---|:---|
| Serial Number of CA Certificate | 1D3F1E58E0DF9F5DCEA86CA9AFC5CAD5ADDB9C89 |
| Validity Period of CA Certificate | June 22, 2020 to June 22, 2030 |
| Signature Algorithm | ECDSA with SHA384 |
| Key Size of CA | 384 bit |
| Hash value (SHA-1) | 15ED815535775C8565E260EFD5827A37087CB15B |
| Hash value (SHA-256) | 195FA1E40EDF0B1BDCB2C4F913DD5FD6CCB58891DF3B73E53C7AEB9AC3F86E28 |
| Revocation Date | August 21, 2023 12:24:48 (JST) |
| Revocation Reason | Superseded |
| Root CA | SecureSign Root CA15 |

| Name of CA | Cybertrust Japan SureMail CA G8 |
|:---|:---|
| Serial Number of CA Certificate | 1FA4C422EADA4D67BE7EC31B75024A2DB55C0015 |
| Validity Period of CA Certificate | August 21, 2023 to June 22, 2030 |
| Signature Algorithm | ECDSA with SHA384 |
| Key Size of CA | 384 bit |
| Hash value (SHA-1) | 113F753E0D47D761623FC92FC561931D335746B4 |
| Hash value (SHA-256) | 8FBD048775F6F4C486CF4960A7BB8B807225E37C74935E5B99CBA9E41383FECA |
| Revocation Date | August 20, 2024 19:25:03 (JST) |
| Revocation Reason | Cessation of operation |
| Root CA | SecureSign Root CA15 |

| Name of CA | Cybertrust Japan SureCode EV CA G3 |
|:---|:---|
| Serial Number of CA Certificate | 401C0824BBCEA63303FB626F7D613BFF01241FF6 |
| Validity Period of CA Certificate | June 22, 2020 to June 22, 2036 |
| Signature Algorithm | SHA384 with RSA |
| Key Size of CA | 4096 bit |
| Hash value (SHA-1) | 6261D96B51BFF7807F38B4A52E4155D89EFEF71E |
| Hash value (SHA-256) | 87CC9D3EDF3F8517D922944AA114A5576AB4FD8DF09E35D10FF314C8EA172619 |
| Revocation Date | August 20, 2024 19:12:54 (JST) |
| Revocation Reason | Cessation of operation |
| Root CA | SecureSign Root CA14 |

| Name of CA | Cybertrust Japan SureCode EV CA G4 |
|:---|:---|
| Serial Number of CA Certificate | 3067E8FBFB2201DE04917E3AE9701115A580F9D1 |
| Validity Period of CA Certificate | June 22, 2020 to June 22, 2036 |
| Signature Algorithm | ECDSA with SHA384 |
| Key Size of CA | 384 bit |
| Hash value (SHA-1) | 542AA69A5F38DFD4CD9C41B03048B7BCE10124A7 |
| Hash value (SHA-256) | AEEDAB7F871504EE07CEB3ED93AF034394548B1E655F7C759B9646AB78F0CEBB |
| Revocation Date | August 20, 2024 19:27:05 (JST) |
| Revocation Reason | Cessation of operation |
| Root CA | SecureSign Root CA15 |

| Name of CA | Cybertrust Japan SureCode CA G3 |
|:---|:---|
| Serial Number of CA Certificate | 605809FFFD7AD23CC7793CFC3181DE152DFE1C19 |
| Validity Period of CA Certificate | June 22, 2020 to June 22, 2036 |
| Signature Algorithm | SHA384 with RSA |
| Key Size of CA | 4096 bit |
| Hash value (SHA-1) | A50C5F28193A2F2971517BE5DD3C2212AAEE5376 |
| Hash value (SHA-256) | A2383AF3FDE129CCFB7865D057D40A1A4BDA70E1E45C53E8BB58681AF62E1B4B |
| Revocation Date | August 20, 2024 19:14:30 (JST) |
| Revocation Reason | Cessation of operation |
| Root CA | SecureSign Root CA14 |

| Name of CA | Cybertrust Japan SureCode CA G4 |
|:---|:---|
| Serial Number of CA Certificate | 2141B3AAF2EFDF0F9FC1CBE2C6A8AB4E966DA06F |
| Validity Period of CA Certificate | June 22, 2020 to June 22, 2036 |
| Signature Algorithm | ECDSA with SHA384 |
| Key Size of CA | 384 bit |
| Hash value (SHA-1) | 7F466C2F01734A4034024DBD9E460515D3B80C76 |
| Hash value (SHA-256) | 42A7E8F7E06F2FC1CE417B26AC6F724E7BCC520A3B64ED506C7AA0B6DA25D63E |
| Revocation Date | August 20, 2024 19:28:31 (JST) |
| Revocation Reason | Cessation of operation |
| Root CA | SecureSign Root CA15 |

| Name of CA | Cybertrust Japan SureTime CA G3 |
|:---|:---|
| Serial Number of CA Certificate | 47C05BCA232CA403ABA01603F0584B6B150ACFFB |
| Validity Period of CA Certificate | September 9, 2021 to September 9, 2037 |
| Signature Algorithm | SHA384 with RSA |
| Key Size of CA | 4096 bit |
| Hash value (SHA-1) | 3C050F28F197CE9BBE16EE6551C9530D838D9AD5 |
| Hash value (SHA-256) | F8D976C1190F85B54EBD88B45986FCF475D1A58F8CFD1D70B0E40A6346BBA4A6 |
| Revocation Date | August 20, 2024 19:15:53 (JST) |
| Revocation Reason | Cessation of operation |
| Root CA | SecureSign Root CA14 |

| Name of CA | Cybertrust Japan SureTime CA G4 |
|:---|:---|
| Serial Number of CA Certificate | 3E745100E3A15C5D0288B4475F408E516A8337B5 |
| Validity Period of CA Certificate | September 9, 2021 to September 9, 2037 |
| Signature Algorithm | ECDSA with SHA384 |
| Key Size of CA | 384 bit |
| Hash value (SHA-1) | F95B7E1CA40A890941A5039DAD81463D92B3A4B7 |
| Hash value (SHA-256) | 5022E703CD525D1D45F8CAB522C00B8D371891C9995D28F36E12906B8D1E9EBE |
| Revocation Date | August 20, 2024 19:29:50 (JST) |
| Revocation Reason | Cessation of operation |
| Root CA | SecureSign Root CA15 |