Organization Validation Certificate Policy Ver.1.23

Organization Validation
Certificate Policy
Version 1.23

August 21, 2024
SECOM Trust Systems Co., Ltd.

© 2018 SECOM Trust Systems Co., Ltd.
IOrganization Validation Certificate Policy Ver.1.23

Version History
VersionNumberDate

Description

1.00

2018/07/24

Publication of the first version

1.10

2018/10/12

Modified the contents of the profile

1.11

2019/05/24

Revision of overall descriptions and style
Deleted IP address for domain authentication

1.12

2020/03/30

Revision of chapters, and added some "No stipulation"
contents

1.13

2020/09/01

Changed Certificate validity period from 825 days to 398
days

1.14

2020/09/29

Modified Reason code in CRL profile

1.15

2020/12/18

Added OID assigned to CP
Added Security Communication ECC Root CA1 issued
CA profile

1.16

2021/05/31

Modified the description for domain authentication
Modified certificate revocation reasons
Added special requirements for key compromise

1.17

2021/06/15

Revision of descriptions and style
Modified certificate revocation reasons

1.18

2021/11/30

Modified the description for domain authentication
Revision of overall descriptions and style

1.19

2022/06/10

Revision of overall descriptions and style

1.20

2023/05/17

Update “1.2 Document Name and Identification”
Update “2.3 Time or Frequency of Publication”
Update “4.9.1 Circumstances for Certificate Revocation”
Update “5.5.1 Types of Records Archived”
Update “5.5.2 Retention Period for Archive”
Update “5.5.3 Protection of Archive”
Update “5.5.4 Archive Backup Procedures”
Update “5.5.5 Requirements for Time-Stamping ofRecords”
Update “5.5.6 Archive Collection System”
Update “5.5.7 Procedures to Obtain and Verify Archive
Information”© 2018 SECOM Trust Systems Co., Ltd.
IIOrganization Validation Certificate Policy Ver.1.23

Update “5.7.1 Incident and Compromise Handling
Procedures”
Update “5.7.2 Computing Resources, Software, and/or
Data are Corrupted”
Update“5.7.3

EntityPrivateKey

Compromise

Procedures”
Update “5.7.4 Business Continuity Capabilities after a
Disaster”
Update “7.1 Certificate Profile”
Update “7.2 CRL Profile”
Update “7.2.2 CRL Entry Extensions”
1.21

2023/08/28

Update “1.6 Definitions and Acronyms”
Update “7.1 Certificate Profile”

1.22

2024/04/01

Update “1.1 Overview ”
Update “1.6 Definitions and Acronyms”
Update “2.2 Publication of Certificate Information”
Update “3.2.2.4 “Domain Authentication”
Update“3.2.3AuthenticationofApplicantandIndividual Identity ”
Update “3.2.5 Validation of Authority”
Update “3.2.6 Criteria for Interoperation”
Update “4.5.1 Subscriber Private Key and Certificate
Usage”
Update “4.9.8 Maximum Latency for CRLs”
Update “6.1.7 Key Usage Purposes
Update “7.1 Certificate Profile”
Update “7.1.3 Algorithm Object Identifier”
Update “7.2 CRL Profile”
Update “8 Compliance Audit and Other Assessments”
Update“8.1

Frequency

andCircumstancesofAssessment”
Update “8.2 Identity/Qualifications of Assessor”
Update “8.3 Assessor’s Relationship to Assessed Entity”
Update “8.4 Topics Covered by Assessment”
Update “8.5 Actions Taken as a Result of Deficiency”
Update “8.6 Communication of Results”© 2018 SECOM Trust Systems Co., Ltd.
III

Organization Validation Certificate Policy Ver.1.23

1.232024/08/21

Update the below:
1.3.1 CA
1.3.2 RA
1.3.3 Subscribers
1.3.4 Relying Party
1.6 Definitions and Acronyms
2.1 Repository
2.2 Publication of Certificate Information
4.1.2 Enrollment Process and Responsibilities
4.2.1 Performing Identification and Authentication
Functions4.9.1 Circumstances for Certificate Revocation
4.9.7 CRL Issuance Frequency
6.1.1 Key Pair Generation
7.1 Certificate Profile
7.2 CRL Profile
7.2.2 CRL Entry Extensions
Delete the below:
4.2.4 CAA Records Processing© 2018 SECOM Trust Systems Co., Ltd.
IV

Organization Validation Certificate Policy Ver.1.23

Table of Contents
1. Introduction ....................................................................................................................... 1
1.1 Overview ...................................................................................................................... 1
1.2 Document Name and Identification ........................................................................... 2
1.3 PKI Participants.......................................................................................................... 3
1.3.1 CA .......................................................................................................................... 3
1.3.2 RA .......................................................................................................................... 3
1.3.3 Subscribers ............................................................................................................ 4
1.3.4 Relying Parties ..................................................................................................... 4
1.3.5 Other Parties ........................................................................................................ 4
1.4 Certificate Usage ......................................................................................................... 4
1.4.1 Appropriate Certificate Uses ............................................................................... 4
1.4.2 Prohibited Certificate Uses .................................................................................. 4
1.5 Policy Administration ................................................................................................. 4
1.5.1 Organization Administering the Document ....................................................... 4
1.5.2 Contact Information ............................................................................................. 4
1.5.3 Person Determining CP Suitability for the Policy ............................................. 5
1.5.4 Approval Procedure .............................................................................................. 5
1.6 Definitions and Acronyms........................................................................................... 5
2. Publication and Repository Responsibilities..................................................................11
2.1 Repository ...................................................................................................................11
2.2 Publication of Certificate Information ......................................................................11
2.3 Time or Frequency of Publication .............................................................................11
2.4 Access Controls on Repository .................................................................................. 12
3. Identification and Authentication.................................................................................. 13
3.1 Naming....................................................................................................................... 13
3.1.1 Types of Names ................................................................................................... 13
3.1.2 Need for Names to Be Meaningful .................................................................... 13
3.1.3 Anonymity or Pseudonymity of Subscribers ..................................................... 13
3.1.4 Rules for Interpreting Various Name Forms .................................................... 13
3.1.5 Uniqueness of Names ......................................................................................... 14
3.1.6 Recognition, Authentication, and Roles of Trademarks .................................. 14
3.2 Initial Identity Validation ......................................................................................... 14
3.2.1 Method to Prove Possession of Private Key ...................................................... 14
3.2.2 Authentication of Organization Identity........................................................... 14© 2018 SECOM Trust Systems Co., Ltd.
V

Organization Validation Certificate Policy Ver.1.23

3.2.2.1 Identity ......................................................................................................... 15
3.2.2.2 DBA/Tradename........................................................................................... 15
3.2.2.3 Verification of Country ................................................................................ 15
3.2.2.4 Domain Authentication ............................................................................... 16
3.2.2.5 Authentication for an IP Address ............................................................... 18
3.2.2.6 Wildcard Domain Validation ....................................................................... 19
3.2.2.7 Data Source Accuracy .................................................................................. 19
3.2.2.8 CAA Records ................................................................................................. 19
3.2.3 Authentication of Individual Identity ............................................................... 20
3.2.4 Non-Verified Subscriber Information ................................................................ 20
3.2.5 Validation of Authority ....................................................................................... 20
3.2.6 Criteria for Interoperation ................................................................................. 20
3.3 Identification and Authentication for Re-Key Requests......................................... 20
3.3.1 Identification and Authentication for Routine Re-Key .................................... 20
3.3.2 Identification and Authentication for Re-Key after Revocation...................... 21
3.4 Identification and Authentication for Revocation Requests .................................. 21
4. Certificate Life-Cycle Operational Requirements ........................................................ 22
4.1 Certificate Application .............................................................................................. 22
4.1.1 Who May Submit a Certificate Application ...................................................... 22
4.1.2 Enrollment Process and Responsibilities.......................................................... 22
4.2 Certificate Application Processing ........................................................................... 22
4.2.1 Performing Identification and Authentication Functions ............................... 23
4.2.2 Approval or Rejection of Certificate Applications ............................................ 24
4.2.3 Time to Process Certificate Applications .......................................................... 24
4.3 Certificate Issuance................................................................................................... 24
4.3.1 CA Actions during Certificate Issuance ............................................................ 25
4.3.2 Notifications to Subscriber of Certificate Issuance .......................................... 25
4.4 Certificate Acceptance ............................................................................................... 25
4.4.1 Conduct Constituting Certificate Acceptance................................................... 25
4.4.2 Publication of the Certificate by the CA ........................................................... 25
4.4.3 Notification of Certificate Issuance by the CA to Other Entities.................... 25
4.5 Key Pair and Certificate Usage................................................................................ 26
4.5.1 Subscriber Private Key and Certificate Usage ................................................. 26
4.5.2 Relying Party Public Key and Certificate Usage ............................................. 26
4.6 Certificate Renewal ................................................................................................... 26
4.6.1 Circumstances for Certificate Renewal ............................................................ 26© 2018 SECOM Trust Systems Co., Ltd.
VI

Organization Validation Certificate Policy Ver.1.23

4.6.2 Who May Request Renewal ............................................................................... 26
4.6.3 Processing Certificate Renewal Requests ......................................................... 26
4.6.4 Notification of New Certificate Issuance to Subscriber ................................... 26
4.6.5 Conduct Constituting Acceptance of a Renewal Certificate ............................ 26
4.6.6 Publication of the Renewal Certificates by the CA .......................................... 27
4.6.7 Notification of Certificate Issuance by the CA to Other Entities.................... 27
4.7 Certificate Re-Key ..................................................................................................... 27
4.7.1 Circumstances for Certificate Re-Key ............................................................... 27
4.7.2 Who May Request Certification of a New Public Key...................................... 27
4.7.3 Processing Certificate Re-Keying Requests ...................................................... 27
4.7.4 Notification of New Certificate Issuance to Subscriber ................................... 27
4.7.5 Conduct Constituting Acceptance of a Re-Keyed Certificate .......................... 27
4.7.6 Publication of the Re-Keyed Certificate by the CA .......................................... 27
4.7.7 Notification of Certificate Issuance by the CA to Other Entities.................... 27
4.8 Certificate Modification ............................................................................................ 28
4.8.1 Circumstances for Certificate Modification ...................................................... 28
4.8.2 Who May Request Certificate Modification ...................................................... 28
4.8.3 Processing Certificate Modification Requests .................................................. 28
4.8.4 Notification of New Certificate Issuance to Subscriber ................................... 28
4.8.5 Conduct Constituting Acceptance of Modified Certificate ............................... 28
4.8.6 Publication of the Modified Certificates by the CA .......................................... 28
4.8.7 Notification of Certificate Issuance by the CA to Other Entities.................... 28
4.9 Certificate Revocation and Suspension ................................................................... 28
4.9.1 Circumstances for Certificate Revocation ........................................................ 29
4.9.2 Who Can Request Revocation ............................................................................ 30
4.9.3 Procedure for Revocation Request..................................................................... 31
4.9.4 Revocation Request Grace Period...................................................................... 31
4.9.5 Time within Which CA Shall Process the Revocation Request ....................... 31
4.9.6 Revocation Checking Requirements for Relying Parties ................................. 32
4.9.7 CRL Issuance Frequency ................................................................................... 32
4.9.8 Maximum Latency for CRLs .............................................................................. 32
4.9.9 On-Line Revocation/Status Checking Availability ........................................... 32
4.9.10 On-Line Revocation/Status Checking Requirements..................................... 32
4.9.11 Other Forms of Revocation Advertisements Available................................... 34
4.9.12 Special Requirements Regarding Key Compromise ...................................... 34
4.9.13 Circumstances for Suspension ......................................................................... 34© 2018 SECOM Trust Systems Co., Ltd.
VII

Organization Validation Certificate Policy Ver.1.23

4.9.14 Who Can Request Suspension ......................................................................... 34
4.9.15 Procedure for Suspension Request .................................................................. 35
4.9.16 Limits on Suspension Period ........................................................................... 35
4.10 Certificate Status Services ..................................................................................... 35
4.10.1 Operational Characteristics............................................................................. 35
4.10.2 Service Availability ........................................................................................... 35
4.10.3 Optional Features ............................................................................................. 35
4.11 End of Subscription (Registry) ............................................................................... 35
4.12 Key Escrow and Recovery ....................................................................................... 35
4.12.1 Key Escrow and Recovery Policy and Practices ............................................. 36
4.12.2 Session Key Encapsulation and Recovery Policy and Practices ................... 36
5. Facility, Management, and Operational Controls ........................................................ 37
5.1 Physical Controls....................................................................................................... 37
5.1.1 Site Location and Construction ......................................................................... 37
5.1.2 Physical Access ................................................................................................... 37
5.1.3 Power and Air Conditioning............................................................................... 37
5.1.4 Water Exposures ................................................................................................. 37
5.1.5 Fire Prevention and Protection ......................................................................... 37
5.1.6 Media Storage ..................................................................................................... 37
5.1.7 Waste Disposal .................................................................................................... 37
5.1.8 Off-Site Backup ................................................................................................... 37
5.2 Procedural Controls .................................................................................................. 37
5.2.1 Trusted Roles ...................................................................................................... 37
5.2.2 Number of Persons Required per Task ............................................................. 37
5.2.3 Identification and Authentication for Each Role.............................................. 38
5.2.4 Roles Requiring Separation of Duties ............................................................... 38
5.3 Personnel Controls .................................................................................................... 38
5.3.1 Qualifications, Experience, and Clearance Requirements .............................. 38
5.3.2 Background Check Procedures .......................................................................... 38
5.3.3 Training Requirements ...................................................................................... 38
5.3.4 Retraining Frequency and Requirements ........................................................ 38
5.3.5 Job Rotation Frequency and Sequence ............................................................. 38
5.3.6 Sanctions for Unauthorized Actions .................................................................. 38
5.3.7 Independent Contractor Requirements ............................................................ 38
5.3.8 Documentation Supplied to Personnel .............................................................. 38
5.4 Audit Logging Procedures......................................................................................... 38© 2018 SECOM Trust Systems Co., Ltd.
VIIIOrganization Validation Certificate Policy Ver.1.23

5.4.1 Types of Events Recorded .................................................................................. 38
5.4.2 Frequency of Processing Audit Log ................................................................... 39
5.4.3 Retention Period for Audit Log .......................................................................... 39
5.4.4 Protection of Audit Log....................................................................................... 39
5.4.5 Audit Log Backup Procedure ............................................................................. 39
5.4.6 Audit Log Collection System .............................................................................. 39
5.4.7 Notification to Event-Causing Subject.............................................................. 39
5.4.8 Vulnerability Assessments ................................................................................. 39
5.5 Records Archival ........................................................................................................ 39
5.5.1 Types of Records Archived ................................................................................. 39
5.5.2 Retention Period for Archive.............................................................................. 39
5.5.3 Protection of Archive .......................................................................................... 39
5.5.4 Archive Backup Procedures ............................................................................... 39
5.5.5 Requirements for Time-Stamping of Records................................................... 40
5.5.6 Archive Collection System ................................................................................. 40
5.5.7 Procedures to Obtain and Verify Archive Information .................................... 40
5.6 Key Changeover ........................................................................................................ 40
5.7 Compromise and Disaster Recovery ........................................................................ 40
5.7.1 Incident and Compromise Handling Procedures ............................................. 40
5.7.2 Computing Resources, Software, and/or Data are Corrupted ......................... 40
5.7.3 Entity Private Key Compromise Procedures .................................................... 40
5.7.4 Business Continuity Capabilities after a Disaster .......................................... 40
5.8 CA or RA Termination ............................................................................................... 40
6. Technical Security Controls ........................................................................................... 41
6.1 Key Pair Generation and Installation ..................................................................... 41
6.1.1 Key Pair Generation ........................................................................................... 41
6.1.2 Private Key Delivery to Subscriber ................................................................... 41
6.1.3 Public Key Delivery to Certificate Issuer ......................................................... 41
6.1.4 CA Public Key Delivery to Relying Parties....................................................... 41
6.1.5 Key Sizes ............................................................................................................. 41
6.1.6 Public Key Parameters Generation and Quality Checking ............................. 41
6.1.7 Key Usage Purposes ........................................................................................... 41
6.2 Private Key Protection and Cryptographic Module Engineering Controls .......... 42
6.2.1 Cryptographic Module Standards and Controls .............................................. 42
6.2.2 Private Key Multi-Person Control..................................................................... 42
6.2.3 Private Key Escrow ............................................................................................ 42© 2018 SECOM Trust Systems Co., Ltd.
IXOrganization Validation Certificate Policy Ver.1.23

6.2.4 Private Key Backup ............................................................................................ 42
6.2.5 Private Key Archival .......................................................................................... 42
6.2.6 Private Key Transfer into or from a Cryptographic ......................................... 42
6.2.7 Private Key Storage on Cryptographic Module................................................ 43
6.2.8 Method of Activating Private Key ..................................................................... 43
6.2.9 Method of Deactivating Private Key ................................................................. 43
6.2.10 Method of Destroying Private Key .................................................................. 43
6.2.11 Cryptographic Module Rating.......................................................................... 43
6.3 Other Aspects of Key Pair Management ................................................................. 43
6.3.1 Public Key Archival ............................................................................................ 43
6.3.2 Certificate Operational Periods and Key Pair Usage Periods ........................ 43
6.4 Activation Data .......................................................................................................... 44
6.4.1 Activation Data Generation and Installation ................................................... 44
6.4.2 Activation Data Protection ................................................................................. 44
6.4.3 Other Aspects of Activation Data ...................................................................... 44
6.5 Computer Security Controls ..................................................................................... 44
6.5.1 Specific Computer Security Technical Requirements ...................................... 44
6.5.2 Computer Security Rating ................................................................................. 44
6.6 Life-Cycle Technical Controls ................................................................................... 44
6.6.1 System Development Controls........................................................................... 44
6.6.2 Security Management Controls ......................................................................... 44
6.6.3 Life-Cycle Security Controls .............................................................................. 44
6.7 Network Security Controls ....................................................................................... 44
6.8 Time-Stamping .......................................................................................................... 44
7. Certificate, CRL, and OCSP Profiles ............................................................................. 46
7.1 Certificate Profile ...................................................................................................... 46
7.1.1 Version Number(s) .............................................................................................. 54
7.1.2 Certificate Extension .......................................................................................... 54
7.1.3 Algorithm Object Identifier ................................................................................ 54
7.1.4 Name Format ...................................................................................................... 54
7.1.5 Name Constraints............................................................................................... 55
7.1.6 Certificate Policy Object Identifier .................................................................... 55
7.1.7 Use of Policy Constraint Extensions ................................................................. 55
7.1.8 Policy Qualifier Syntax and Semantics ............................................................ 55
7.1.9 How to interpret Critical Certificate Policy Extensions .................................. 56
7.2 CRL Profile ................................................................................................................ 56© 2018 SECOM Trust Systems Co., Ltd.
X

Organization Validation Certificate Policy Ver.1.23

7.2.1 Version Number(s) .............................................................................................. 57
7.2.2 CRL Entry Extensions ....................................................................................... 57
7.3 OCSP Profile .............................................................................................................. 61
7.3.1 Version Number(s) .............................................................................................. 61
7.3.2 OCSP Extensions ................................................................................................ 61
8. Compliance Audit and Other Assessments ................................................................... 62
8.1 Frequency and Circumstances of Assessment ........................................................ 62
8.2 Identity/Qualifications of Assessor .......................................................................... 62
8.3 Assessor’s Relationship to Assessed Entity ............................................................. 62
8.4 Topics Covered by Assessment ................................................................................. 62
8.5 Actions Taken as a Result of Deficiency .................................................................. 62
8.6 Communication of Results ........................................................................................ 62
8.7 Self-Audits ................................................................................................................. 62
9. Other Business and Legal Matters................................................................................ 63
9.1 Fees ............................................................................................................................ 63
9.1.1 Fees for Issuing or Renewing Certificates ........................................................ 63
9.1.2 Certificate Access Fee ......................................................................................... 63
9.1.3 Expiration or Access Fee for Status Information ............................................. 63
9.1.4 Fees for Other Services ...................................................................................... 63
9.1.5 Refund Policy ...................................................................................................... 63
9.2 Financial Responsibility ........................................................................................... 63
9.2.1 Insurance Coverage ............................................................................................ 63
9.2.2 Other Assets ........................................................................................................ 63
9.2.3 End entity Insurance or Warranty coverage .................................................... 63
9.3 Confidentiality of Business Information ................................................................. 63
9.3.1 Scope of Confidential Information ..................................................................... 63
9.3.2 Information Not Within the Scope of Confidential Information ..................... 64
9.3.3 Responsibility to Protect Confidential Information ......................................... 64
9.4 Privacy of Personal Information .............................................................................. 64
9.4.1 Personal Information Protection Plan .............................................................. 64
9.4.2 Information Treated as Personal Information.................................................. 64
9.4.3 Information that is not considered Personal Information ............................... 64
9.4.4 Responsibility for protecting Personal Information ......................................... 64
9.4.5 Notice and Consent regarding use of Personal Information ........................... 64
9.4.6 Information Disclosure with Judicial or Administrative Procedures ............. 64
9.4.7 Other Information Disclosure Conditions ........................................................ 64© 2018 SECOM Trust Systems Co., Ltd.
XIOrganization Validation Certificate Policy Ver.1.23

9.5 Intellectual Property Rights ..................................................................................... 64
9.6 Representations and Warranties ............................................................................. 65
9.6.1 CA Representations and Warranties ................................................................. 65
9.6.2 RA Representations and Warranties ................................................................. 67
9.6.3 Subscriber Representations and Warranties .................................................... 67
9.6.4 Relying Party Representations and Warranties .............................................. 68
9.6.5 Representations and Warranties of Other Participants .................................. 69
9.7 Disclaimer of Warranties .......................................................................................... 69
9.8 Limitations of Liability ............................................................................................. 69
9.9 Indemnities ................................................................................................................ 70
9.10 Term and Termination ............................................................................................ 70
9.10.1 Term ................................................................................................................... 70
9.10.2 Termination ....................................................................................................... 70
9.10.3 Effect of Termination and Survival ................................................................. 70
9.11 Individual Notices and Communications with Participants ................................ 70
9.12 Amendments ............................................................................................................ 70
9.12.1 Procedure for Amendment ............................................................................... 70
9.12.2 Notification Method and Timing ..................................................................... 70
9.12.3 Circumstances under Which OID Must Be Changed .................................... 71
9.13 Dispute Resolution Procedures .............................................................................. 71
9.14 Governing Law ........................................................................................................ 71
9.15 Compliance with Applicable Law ........................................................................... 71
9.16 Miscellaneous Provisions ........................................................................................ 71
9.16.1 Entire Agreement ............................................................................................. 71
9.16.2 Assignment ........................................................................................................ 71
9.16.3 Severability ....................................................................................................... 71
9.16.4 Enforcement ...................................................................................................... 72
9.16.5 Irresistible Force............................................................................................... 72
9.17 Other Provisions ...................................................................................................... 72© 2018 SECOM Trust Systems Co., Ltd.
XIIOrganization Validation Certificate Policy Ver.1.23

1. Introduction
1.1 Overview
Organization Validation Certificate Policy (hereinafter, "this CP") defines the policy on
certificates issued by SC Organization Validation CA (hereinafter, "the CA"), which areoperated by SECOM Trust Systems Co., Ltd. (hereinafter, "SECOM Trust Systems "),by specifying the purpose of use, the scope of application and user procedures
concerning the Certificates. Various procedures regarding the operation andmaintenance of the CA are stipulated in the SECOM Digital Certification
Infrastructure Certification Practice Statement (hereinafter, "CPS").
Unilateral cross-certificate by Security Communication RootCA2 or Security
Communication ECC RootCA1 has been issued to the CA.
Certificates issued by the CA are used for server authentication and data encryption
in the communication routing.
A party seeking to obtain Certificates from the CA must examine its usage purposes
against this CP and the CPS, and agree to them prior to getting the Certificates issued.
The CA shall comply with the latest versions of the standard set forth by the
CA/Browser Forum (hereinafter referred to as Baseline Requirements) and Application
Software Supplier standard published at https://www.cabforum.org/.
Table 1.1-1 List of Standards
Types of certificates issued byStandards to comply withsubordinate CAsBaseline Requirements for the Issuance andManagement of Publicly-Trusted TLS Server
Certificates（hereinafter, Baseline

TLS Server Certificate

Requirements）
Apple Root Certificate Program

Chrome Root Program PolicyMicrosoft Trusted Root Program

Mozilla Root Store Policy

The CA may outsource the part of the certification work to an external business© 2018 SECOM Trust Systems Co., Ltd.
P-1

Organization Validation Certificate Policy Ver.1.23

operator that complies with Baseline Requirements (hereinafter referred to as"Delegated Third Party"), and the contract between the two companies shall be
stipulated in the PB-SSL/TLS certificate issuance service terms (hereinafter referred
to as "Service Terms").
In the event of a conflict between this CP, Service Terms and the CPS, the order ofprecedence in shall be Service Terms, this CP and the CPS. In addition, if there is aseparate contract, etc. between SECOM Trust Systems and an organization that has acontractual relationship, the document such as the contract will take precedence overService Terms, this CP, and CPS. In the event of any inconsistency between this CP
and the Baseline Requirements, the Baseline Requirements take precedence over thisCP.
This CP shall be revised as necessary in order to reflect any technical or operational
developments or improvements pertaining to the CA.
This CP conforms to the RFC3647 "Internet X.509 Public Key Infrastructure
Certificate Policy and Certification Practices Framework" advocated by the IETF as a
CA practice framework.
1.2 Document Name and Identification
The official name of this CP is "Organization Validation Certificate Policy".
This CP is identified with the OID given in "Table 1.2-1 OID (This CP)"
Table 1.2-1 OID (This CP)CP

OID

SC Organization Validation CA1

1.2.392.200091.110.214.1(Issued by Security Communication Root CA2)SC Organization Validation CA2(Issued by Security Communication Root CA2)SC Organization Validation CA3(Issued by Security Communication Root CA2)SC Organization Validation CA4(Issued by Security Communication ECC RootCA1)

Use until 2023/05/31
1.2.392.200091.110.214.2
1.2.392.200091.110.214.3
1.2.392.200091.110.214.4

The OID of the CPS associated with this CP is given in Table 1.2-2 OID (CPS)
Table 1.2-2 OID (CPS)
CPS
SECOM

DigitalCertification

OID
Infrastructure

1.2.392.200091.100.401.1© 2018 SECOM Trust Systems Co., Ltd.
P-2

Organization Validation Certificate Policy Ver.1.23

Certification Practice Statement
1.3 PKI Participants
1.3.1 CACA is an organization that is responsible for the creation, issuance, revocation, andmanagement of Certificates.

The term applies equally to both Root CAs andSubordinate CAs.
1.3.2 RAAny Legal Entity that is responsible for identification and authentication of subjectsof Certificates, but is not a CA, and hence does not sign or issue Certificates. An RA
may assist in the certificate application process or revocation process or both. WhenRA is used as an adjective to describe a role or function, it does not necessarily imply
a separate body, but can be part of the CA.
With the exception of this CP “Section 3.2.2.4 Domain Authentication” and this CP“3.2.2.5 Authentication for an IP Address”, the CA MAY delegate the performance ofall, or any part, of this CP “3.2 Initial Identity Validation” requirements to a DelegatedThird Party, provided that the process as a whole fulfills all of the requirements of thisCP “3.2 Initial Identity Validation”.
Before the CA authorizes a Delegated Third Party to perform a delegated function, theCA SHALL contractually require the Delegated Third Party to:
1. Meet the qualification requirements of the CPS “5.3.1 Qualifications, Experience,and Clearance Requirements”, when applicable to the delegated function;
2. Retain documentation in accordance with the CPS “5.5.2 Retention Period forArchive”;
3. Abide by the other provisions of the Baseline Requirements that are applicable tothe delegated function; and4. Comply with:a. the CA’s Certificate Policy/Certification Practice Statement orb. the Delegated Third Party’s practice statement that the CA has verified complies
with the Baseline Requirements.

© 2018 SECOM Trust Systems Co., Ltd.
P-3

Organization Validation Certificate Policy Ver.1.23

1.3.3 Subscribers
Subscribers shall be any natural person or Legal Entity that receive a Certificate
issued by the CA and conforms to the Subscriber Agreement or Term of Use.
1.3.4 Relying Parties
Relying Party is any natural person or Legal Entity that relies on a Valid Certificate.
An Application Software Supplier is not considered a Relying Party when software
distributed by such Supplier merely displays information relating to a Certificate.
1.3.5 Other Parties
Other Parties include auditors, and companies or organizations that have service
contracts with SECOM Trust Systems, and companies that perform system
integration.
1.4 Certificate Usage
1.4.1 Appropriate Certificate Uses
Certificates issued by the CA may be used for server authentication and dataencryption in the communication routing.
1.4.2 Prohibited Certificate Uses
Certificates issued by the CA shall not be used for purposes other than server
authentication and data encryption in the communication routing.
The CA does not permit the issuance of certificates unless it is confirmed from thedomain owner verified in accordance with this CP "3.2.2.4 Domain Authentication"that the domain owner has the right to use the domain.
1.5 Policy Administration
1.5.1 Organization Administering the Document
This CP is maintained and administered by SECOM Trust Systems.
1.5.2 Contact Information
Inquiries concerning this CP should be directed to:
CA Support Center, SECOM Trust Systems Co., Ltd.
Address:

8-10-16 Shimorennjaku, Mitaka-shi, Tokyo 181-8528© 2018 SECOM Trust Systems Co., Ltd.
P-4

Organization Validation Certificate Policy Ver.1.23

E-mail address:

ca-support secom.co.jp

Website:https://www.secomtrust.net/

The Subscribers, Relying Parties, Application Software Suppliers, and other third
parties can report suspected Private Key Compromise, Certificate misuse, or othertypes of fraud, compromise, misuse, inappropriate conduct, or any other matter related
to Certificates. The CA revokes certificates when it is determined that it needs to be
revoked.
1.5.3 Person Determining CP Suitability for the Policy
The Certification Services Improvement Committee (hereinafter, "this Committee")determines the suitability of the contents of this CP. This CP shall be reviewed andrevised at least annually.
1.5.4 Approval Procedure
This CP goes into effect upon approval by this Committee for the CA.
1.6 Definitions and Acronyms
Application Software Supplier
A supplier of Internet browser software or other relying party application softwarethat displays or uses a certificate and incorporates a root CA certificate.
Archive
Information obtained for the purpose of preserving history for legal or other reasons.
ADN（Authorization Domain Name）
Domain name used to obtain authentication for certificate issuance for a particular
FQDN
Attestation Letter
A letter attesting that Subject Information is correct, which is written by anaccountant, lawyer, government official, or other reliable third party customarily
relied upon for such information.

© 2018 SECOM Trust Systems Co., Ltd.
P-5

Organization Validation Certificate Policy Ver.1.23

Audit Log
Behavioral, access and other histories pertaining to the CA systems which are recorded
for inspection of access to and unauthorized operation of the CA systems.
Baseline Requirements
A document issued by the CA/Browser Forum (available at cabforum.org.) that
integrates a set of fundamental requirements for Certificate issuance/administration.
CA (Certification Authority)
An entity that mainly issues, renews and revokes Certificates, generates and protects
CA Private Keys, and registers Subscribers. This CP also includes the Issuing
Authority (IA).
CAA (Certificate Authority Authorization)
A function to prevent false issuance of Certificates by an unintended CA, by including
the CA information for the domain ownership/control rights to grant the Certificate
issuance for the specific domain, in the DNS record.
CA/Browser Forum
An NPO organized by CAs and Internet browser vendors that works to define andstandardize the Certificate issuance requirements.
CP (Certificate Policy)
A document that sets forth provisions pertaining to Certificates issued by a CA,
including Certificate types, usage and application procedure.
CPS (Certification Practices Statement)
A document that sets forth provisions pertaining to the practices of CAs, including
procedures for the CA operations and the security standards.
CRL (Certificate Revocation List)
A list of information on Certificates which were revoked prior to their expiration due
to reasons such as changes to the information provided in the Certificates and loss of
the relevant Private Key.

© 2018 SECOM Trust Systems Co., Ltd.
P-6

Organization Validation Certificate Policy Ver.1.23

CT (Certificate Transparency)
Certificate Transparency, stipulated in RFC 6962, is an open framework formonitoring/auditing the records of the issued Certificates by registering andpublishing them on the log servers.
Digital Certificate
Digital data certifying that a public key is owned by the party specified, validity ofwhich is certified by the digital signature of the relevant CA affixed thereto.
Escrow
Escrow means the placement (entrustment) of an asset in the control of an
independent third party.
FIPS140-2
The security certification standards developed by the U.S. NIST (National Institute ofStandards and Technology) for cryptographic modules, defining four security levels,the lowest 1 through the highest 4.
INAN (Internet Assigned Numbers Authority)
The organization that globally manages information related to the Internet, such as
IP addresses and port numbers.
Key PairA pair of keys comprising a private key and a public key in the public key cryptosystem.
OCSP (Online Certificate Status Protocol)
A protocol for real-time provision of information on Certificate status.
OID (Object Identifier)
A unique numeric identifier registered by the international registration authority, ina framework to maintain and administer the uniqueness of the mutual connectivity,
services and other aspects of the networks.
PKI (Public Key Infrastructure)
An infrastructure for use of the encryption technology known as the public key
cryptosystem to realize such security technologies as digital signature, encryption and© 2018 SECOM Trust Systems Co., Ltd.
P-7

Organization Validation Certificate Policy Ver.1.23

certification.
Precertificate
A Precertificate is a signed data structure that can be submitted to a Certificate
Transparency log, as defined by RFC 6962. A Precertificate is created after a CA has
decided to issue a Certificate, but prior to the actual signing of the Certificate. The CA
MAY construct and sign a Precertificate corresponding to the Certificate, for purposesof submitting to CT Logs. The CA MAY use the returned Signed Certificate
Timestamps to then alter the Certificate’s extensions field, adding a Signed Certificate
Timestamp List, as defined in Section 7.1.2.11.3 of the Baseline Requirements and as
permitted by the relevant profile, prior to signing the Certificate.
Private Key
A key of a Key Pair that is possessed by the holder of the corresponding public key.
Public Key
A key of a Key Pair used in the public key cryptosystem. A Public Key corresponds to
the Private Key and is published to and shared with the recipient.
RA (Registration Authority)
An entity which, of the duties of a CA, mainly performs assessment of application
submissions, registration of necessary information for issuance of the Certificates, andrequests Certificate signing to CAs.
Relying Party
Any natural person or Legal Entity that relies on a Valid Certificate. An Application
Software Supplier is not considered a Relying Party when software distributed by such
Supplier merely displays information relating to a Certificate.
Repository
A (online) database for storing and providing access to CA certificates, CRLs and thelike.
RFC3647 (Request for Comments 3647)
A document defining the framework for CP and CPS published by the IETF (TheInternet Engineering Task Force), an industry group which establishes technical© 2018 SECOM Trust Systems Co., Ltd.
P-8

Organization Validation Certificate Policy Ver.1.23

standards for the Internet.
RSA
One of the most standard encryption technologies widely used in the Public Key
cryptosystem.
SHA-1 (Secure Hash Algorithm 1)
A hash function used in digital signing. A hash function is a computation technique forgenerating a fixed-length string from a given text. The hash length is 160 bits.
The algorithm works to detect any alterations in the original message during thetransmission by comparing the hash values transmitted and received.
SHA-256 (Secure Hash Algorithm 256)
A hash function used in digital signing. The hash length is 256 bits.
The algorithm works to detect any alterations in the original message during thetransmission by comparing the hash values transmitted and received.
Short-lived Subscriber Certificate
For Certificates issued on or after 15 March 2024 and prior to 15 March 2026, a
Subscriber Certificate with a Validity Period less than or equal to 10 days (864,000
seconds). For Certificates issued on or after 15 March 2026, a Subscriber Certificate
with a Validity Period less than or equal to 7 days (604,800 seconds).
Time-Stamp
Data recording such date and time of creating an electronic file or running a systemprocess.
WebTrust for CA
Standards of internal control and a certification framework based thereon maintainedby CPA Canada regarding the reliability of CAs, the security of electronic commercetransactions, and other relevant matters.
WebTrust for CA - SSL Baseline with Network Security
Audit standards maintained by CPA Canada defining the rules for thereviews/authentications by the CAs for issuance of SSL Certificates and on theCertificates themselves.
© 2018 SECOM Trust Systems Co., Ltd.
P-9

Organization Validation Certificate Policy Ver.1.23

WHOIS
Information obtained directly from a domain name registrar or registry operator via a
protocol defined in RFC3912, a registry data access protocol defined in RFC7482, oran HTTPS website.
X.500
A series of computer network standards regarding the decentralized directory service.

© 2018 SECOM Trust Systems Co., Ltd.
P-10

Organization Validation Certificate Policy Ver.1.23

2. Publication and Repository Responsibilities
2.1 Repository
The CA SHALL make revocation information for Subordinate Certificates andSubscriber Certificates available in accordance with this CP.
2.2 Publication of Certificate Information
The CA SHALL publicly disclose its CP and/or CPS through an appropriate and readily
accessible online means that is available on a 24x7 basis. The CA SHALL publicly
disclose its CA business practices to the extent required by the CA's selected audit
scheme (see this CP “8.4 Topics Covered by Assessment “).
The CP and/or CPS MUST be structured in accordance with RFC 3647 and MUST
include all material required by RFC 3647.
The CA's CP “4.2 Certificate Application Processing“ SHALL state the CA's policy orpractice on processing CAA Records for FQDN; that policy shall be consistent with theBaseline Requirements. It shall clearly specify the set of Issuer Domain Names that
the CA recognizes in CAA "issue" or "issuewild" records as permitting it to issue. The
CA SHALL log all actions taken, if any, consistent with its processing practice.
The CA SHALL host test Web pages that allow Application Software Suppliers to test
their software with Subscriber Certificates that chain up to each publicly trusted Root
Certificate.
The CA SHALL host separate Web pages using Subscriber Certificates that are:i. valid,
ii. revoked, andiii. expired.
2.3 Time or Frequency of Publication
The CA shall develop, implement, enforce, and annually update a CP and CPS that
describes in detail how the CA implements the latest version of the Baseline
Requirements. The CA shall indicate conformance with the Baseline Requirements byincrementing the version number and adding a dated changelog entry, even if no otherchanges are made to a CP and CPS.

© 2018 SECOM Trust Systems Co., Ltd.
P-11

Organization Validation Certificate Policy Ver.1.23

2.4 Access Controls on Repository
The CA makes its Repository publicly available in a read-only manner. In the CA,
only the authorized CA administrators can perform operations such as adding,deleting, modifying, and publishing Repositories.

© 2018 SECOM Trust Systems Co., Ltd.
P-12

Organization Validation Certificate Policy Ver.1.23

3. Identification and Authentication
3.1 Naming
3.1.1 Types of Names
The certificate issued by the CA meets the requirements of the X.509 standard,
RFC5280 standard and Baseline Requirements, and the distinguished name assigned
to the certificate holder is set according to the X.500 distinguished name format.
The following information shall be included in a Certificate issued by the CA:
1.

[Country Name (C)] shall be JP.

2. "Organization Name" (O) shall be the name of the relevant organization in theform of a legal person, corporation, or other form of a legal person.
3. [Organizational Unit Name (OU)] shall be an optional field. The OU field isused to distinguish departments (e.g., Human Resources, Marketing, orDevelopment). However, that option shall be prohibited to use for thecertificates to be issued after September 1, 2022.
4. The "Common Name" (CN) is the main domain name and shall be the domainname existing in the Subject Alternative Name. All domain names are added
to Subject Alternative Name.
5. If the dNSName entry value in the Subject Alternative Name extension area
contains international characters other than ASCII strings, puny-code
converted version of the string is used.
3.1.2 Need for Names to Be Meaningful
The Common Name used in a Certificate issued by the CA shall be meaningful when
the hostname used in the web server DNS for which the relevant Subscriber plans to
install the Certificate is assigned.
3.1.3 Anonymity or Pseudonymity of Subscribers
An anonymous or pseudonymous name may not be registered as the Organization
Name or the Common Name in the Certificate issued by the CA.
3.1.4 Rules for Interpreting Various Name Forms
Rules concerning the interpretation of various name forms are governed by the X.500
Series DN rules.

© 2018 SECOM Trust Systems Co., Ltd.
P-13

Organization Validation Certificate Policy Ver.1.23

3.1.5 Uniqueness of Names
In the CA, the issued certificate guarantees that the certificate owner can be uniquely
identified by the information contained in the Distinguished Name of the Subject.
The serial number of the certificate shall be the serial number including random
numbers generated by CSPRNG. Serial numbers assigned in the CA are unique.
3.1.6 Recognition, Authentication, and Roles of Trademarks
The CA does not verify intellectual property rights for the names indicated in
Certificate applications. Subscribers may not submit the CA any registered trademark
or other trademark-related names of a third party. The CA will not arbitrate or engage
itself in the resolution of any dispute between Subscribers and third parties over theregistered trademark or any alike. The CA reserves the right to reject a Subscriber
Certificate Application or revoke an issued Certificate due to the dispute.
3.2 Initial Identity Validation
3.2.1 Method to Prove Possession of Private Key
A Subscriber proves possession of the relevant Private Key in accordance with thefollowing method.
The signature on the relevant Certificate Signing Request (hereinafter, "CSR") isauthenticated to prove that said CSR is signed with the Private Key corresponding to
the Public Key.
3.2.2 Authentication of Organization Identity
If the Applicant requests a Certificate that will contain Subject Identity Information
comprised only of the countryName field, then the CA SHALL verify the country
associated with the Subject using a verification process meeting the requirementsof this CP “3.2.2.3 Verification of Country” and that is described in the CA's CP and
CPS. If the Applicant requests a Certificate that will contain the countryName field
and other Subject Identity Information, then the CA SHALL verify the identity of the
Applicant, and the authenticity of the Applicant Representative's certificate request
using a verification process meeting the requirements of this CP “3.2.2.1 Identity” andthat is described in the CA's CP and CPS. The CA SHALL inspect any document relied
upon under this Section for alteration or falsification.

© 2018 SECOM Trust Systems Co., Ltd.
P-14

Organization Validation Certificate Policy Ver.1.23

3.2.2.1 Identity
If the Subject Identity Information is to include the name or address of an organization,
the CA SHALL verify the identity and address of the organization and that the addressis the Applicant’s address of existence or operation. The CA SHALL verify the identityand address of the Applicant using documentation provided by, or throughcommunication with, at least one of the following:
1. A government agency in the jurisdiction of the Applicant’s legal creation,
existence, or recognition;
2. A third party database that is periodically updated and considered a Reliable
Data Source;
3. A site visit by the CA or a third party who is acting as an agent for the CA; or
4. An Attestation Letter.
The CA MAY use the same documentation or communication described in 1 through 4
above to verify both the Applicant’s identity and address.
3.2.2.2 DBA/Tradename
If the Subject Identity Information is to include a DBA or tradename, the CA SHALL
verify the Applicant’s right to use the DBA/tradename using at least one of thefollowing:
1. Documentation provided by, or communication with, a government agency in thejurisdiction of the Applicant’s legal creation, existence, or recognition;
2. A Reliable Data Source;
3. Communication with a government agency responsible for the management of such
DBAs or tradenames;
4. An Attestation Letter accompanied by documentary support; or
5. A utility bill, bank statement, credit card statement, government-issued tax
document, or other form of identification that the CA determines to be reliable.
3.2.2.3 Verification of Country
If the countryName field is present in the subject Distinguished Name of the certificate,then the CA SHALL verify the country associated with the Subject using one of thefollowing:・information provided by the Domain Name Registrar; or・a method identified in this CP, “Section 3.2.2.1 Identity”.

© 2018 SECOM Trust Systems Co., Ltd.
P-15

Organization Validation Certificate Policy Ver.1.23

3.2.2.4 Domain Authentication
Secom Trust Systems will authenticate the domain using the following Baseline
Requirements-compliant method to verify that the certificate subscriber has the rightto use the domain name.
The random value described in this section shall consist of a random number of 112
bits or more generated by the CA, and shall be valid for the use of response
confirmation for 30 days from the generation.
In the CA, when making a WHOIS inquiry, the IP address of the contacted WHOIS
server is checked by "<Top Level Domain>.whois-servers.net" on the DNS server, andthe inquiry is made to that WHOIS server first. WHOIS responses are not cached andare referenced with each inquiry.
WHOIS obtains the information from domain name registrars or registry operators
via the HTTPS website or the protocol defined in RFC3912.
The CA doesn’t issue certificates if "RFC 7686 - The ".onion" Special-Use Domain
Name" is included in the certificates.
1. Prove the applicant's authority over the FQDN by sending a random value by
email, Fax, SMS or postal mail to a domain contact registered with the WHOIS
Registry Service and receiving an acknowledgment containing the random value.
Random values are sent to an email address, Fax Number, SMS Number or resident
address that is recognized as a domain contact. The management of multiple
authentication domain names can be checked by email, Fax, SMS or postal mail.
(Baseline Requirements Section 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to
Domain Contact).
2.The local part is 'admin',' administrator',' webmaster',' hostmaster', or 'postmaster'and the following "@" demonstrates control of the requested FQDN by sending arandom value to the email address created as the authentication domain name andreceiving an acknowledgment containing the random value. The authentication
domain name under "@" used in the e-mail address should be the domain nameincluded in the FQDN for which the certificate is issued, and if the authentication
domain is the same, multiple FQDNs can be also checked by e-mail.
(Baseline Requirements Section 3.2.2.4.4 Email to Domain Contact)
3. Prove the applicant’s authority over the FQDN by verifying that there is a random
value or application token in either the DNS CNAME, TXT or CAA record of either© 2018 SECOM Trust Systems Co., Ltd.
P-16

Organization Validation Certificate Policy Ver.1.23

the FQDN for which the certificate is issued or the authentication domain name(includes each prefixed with a label that begins with an underscore character).
(Baseline Requirement Section 3.2.2.4.7 DNS Change)
4, Prove the applicant's authority over the FQDN by sending a random value via
email to the Email contact in the DNS CAA record of the authentication domainname and receiving an acknowledgment containing the random value. If the email
contacts are the same, the multiple FQDNs can also be checked by email. Relevant
CAA resource records should be verified using the search algorithm defined in
Section 3 of RFC 8659.
（Baseline Requirement Section 3.2.2.4.13 Email to DNS CAA Contact)
5. Prove the applicant's authority over the FQDN by sending a random value via
email to the Email contact in the DNS TXT record of the authentication domainname and receiving an acknowledgment containing the random value. If the email
contacts are the same, the multiple FQDNs can also be checked by email.
（Baseline Requirement Section 3.2.2.4.14 Email to DNS TXT Contact)
6. Prove the applicant's authority over the FQDN by calling the domain contact
phone number and getting a response to permission to use the authenticated domainname. In addition, when the telephone number of the domain contact is the same ina plurality of authentication domain names, the authority can be proved for aplurality of FQDNs by presenting each authentication domain name and obtaining
a response of permission to use.
（Baseline Requirement Section 3.2.2.4.15 Phone Contact with Domain Contact)
7. Prove the applicant's authority over the FQDN by calling the phone number ofthe phone contact on the DNS TXT record and getting a response to authorize theuse of the authentication domain name. In addition, when the telephone number ofthe domain contact is the same in a plurality of authentication domain names, theauthority can be proved for a plurality of FQDNs by presenting each authentication
domain name and obtaining a response of permission to use.
（Baseline Requirement Section 3.2.2.4.16 Phone Contact with DNS TXT Record)
8. Prove the applicant's authority over the FQDN by calling the phone number ofthe phone contact in the DNSCAA record and getting a response to authorize the© 2018 SECOM Trust Systems Co., Ltd.
P-17

Organization Validation Certificate Policy Ver.1.23

use of the authentication domain name. In addition, when the telephone number of
the telephone contact is the same in a plurality of authentication domain names, theauthority can be proved for the plurality of FQDNs by presenting each FQDN andobtaining a response of permission to use.
（Baseline Requirement Section 3.2.2.4.17 Phone Contact with DNS CAA Record)
9. Confirm the applicant's control over the FQDN by verifying that the request token
or random value is included in the contents of the file. The CA accesses via an
approved port, and confirms that Random value is placed under the "http (or https):// [FQDN to be issued certificate] /.well-known/pki-validation" directory, and that it
receives a normal HTTP or HTTPS response sent from the request.
For Certificates issued on or after 2021-12-01, the CA MUST NOT issue Certificatesfor other FQDNs that end with all the labels of the validated FQDN unless the CA
performs a separate validation for that FQDN using an authorized method. Thismethod is NOT used for validating Wildcard Domain Names.
If the CA follows redirects the following apply:
1.

Redirects MUST be initiated at the HTTP protocol layer. For validations
performed on or after July 1, 2021, redirects MUST be the result of a 3xx301,
302, or 307 HTTP status code response, as defined in RFC 7231, Section 6.4,
or a 308 HTTP status code response, as defined in RFC 7538, Section 3.
Redirects MUST be to the final value of the Location HTTP response header,
as defined in RFC 7231, Section 7.1.2.

2.

Redirects MUST be to resource URLs with either the "http" or "https" scheme.

3.

Redirects MUST be to resource URLs accessed via Authorized Ports.

If a Random Value is used, then:
1. The CA MUST provide a Random Value unique to the certificate request.
2. The Random Value MUST remain valid for use in a confirming response forno more than 30 days from its creation.
(Baseline Requirements Section 3.2.2.4.18 Agreed-Upon Change to Website v2)
3.2.2.5 Authentication for an IP Address
The CA does not issue a certificate by authenticating the IP address.

© 2018 SECOM Trust Systems Co., Ltd.
P-18

Organization Validation Certificate Policy Ver.1.23

3.2.2.6 Wildcard Domain Validation
Before issuing a Wildcard Certificate, the CA MUST establish documented procedurethat determines if the FQDN portion of any Wildcard Domain Name in theCertificate is “registry-controlled” label or is a “public suffix”.
If the FQDN portion of any Wildcard Domain Name is “registry-controlled” or is a“public suffix”, CAs MUST refuse issuance unless the Applicant proves its rightful
control of the entire Domain Namespace.
Determination of what is “registry-controlled” versus the registerable portion of aCountry Code Top-Level Domain Namespace is referred to the Public Suffix List
(PSL), and to retrieve a fresh copy regularly. If using the PSL, the CA SHOULD
consult the “ICANN DOMAINS” section only, not the “PRIVATE DOMAINS” section.
3.2.2.7 Data Source Accuracy
Prior to using any data source as a Reliable Data Source, the CA evaluates the source
for its reliability, accuracy, and resistance to alteration or falsification. The CA should
consider the following during its evaluation:
1.

The age of the information provided,2.

The frequency of updates to the information source,

3.

The data provider and purpose of the data collection,

4.

The public accessibility of the data availability, and5.

The relative difficulty in falsifying or altering the data.

3.2.2.8 CAA Records
As part of the issuance process, the CA must check for CAA records and follow theprocessing instructions found, for each dNSName in the subjectAltName extension of
the certificate to be issued, as specified in RFC 8659. If the CA issues, they MUST do
so within the TTL of the CAA record, or 8 hours, whichever is greater.
When processing CAA records, the CA MUST process the issue, issuewild, and iodef
property tags as specified in RFC 8659, although they are not required to act on thecontents of the iodef property tag.
Additional property tags may be supported, but must not conflict with or supersede
the mandatory property tags set out in Baseline Requirements. The CA must respect
the critical flag and not issue a certificate if they encounter an unrecognized property
tag with this flag set.
The CA is permitted to treat a record lookup failure as permission to issue if:© 2018 SECOM Trust Systems Co., Ltd.
P-19

Organization Validation Certificate Policy Ver.1.23

・the failure is outside the CA's infrastructure; and・the lookup has been retried at least once; and・the domain's zone does not have a DNSSEC validation chain to the ICANN root.
This CA shall log any actions taken as part of its processing practices.
3.2.3 Authentication of Individual Identity
The CA does not issue Individual Validate certificates (IV certificates) that comply
with the following certificate policy identifiers.
{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificatepolicies(1) baseline-requirements(2) individual-validated(3)} (2.23.140.1.2.3)
3.2.4 Non-Verified Subscriber Information
The information about non-verified certificate subscribers will not be included in thecertificates issued by the CA..
3.2.5 Validation of Authority
If the Applicant for a Certificate containing Subject Identity Information is anorganization, the CA SHALL use a Reliable Method of Communication to verify theauthenticity of the Applicant Representative’s certificate request.
The CA MAY use the sources listed in this CP, “Section 3.2.2.1 Identity” to verify the
Reliable Method of Communication. Provided that the CA uses a Reliable Method ofCommunication, the CA MAY establish the authenticity of the certificate request
directly with the Applicant Representative or with an authoritative source within the
Applicant’s organization, such as the Applicant’s main business offices, corporate
offices, human resource offices, information technology offices, or other departmentthat the CA deems appropriate.
3.2.6 Criteria for Interoperation
The CA SHALL disclose all Cross-Certified Subordinate CA Certificates that identify
the CA as the Subject, provided that the CA arranged for or accepted the establishmentof the trust relationship (i.e. the Cross-Certified Subordinate CA Certificate at issue).
3.3 Identification and Authentication for Re-Key Requests
3.3.1 Identification and Authentication for Routine Re-Key
Subscribers shall be identified and authenticated for Re-Keying in the same manner© 2018 SECOM Trust Systems Co., Ltd.
P-20

Organization Validation Certificate Policy Ver.1.23

as set forth in this CP "3.2 Initial Identity Validation" hereof.
3.3.2 Identification and Authentication for Re-Key after Revocation
A routine Re-Key after Revocation is not supported. The (Re-Keying) application for a
Certificate shall be treated as a new submission, and the applicant Subscriber shallbe identified and authenticated in the same manner as set forth in this CP "3.2 Initial
Identity Validation" hereof.
3.4 Identification and Authentication for Revocation Requests
Accepting the revocation request from the Subscriber or the applicant according to theprescribed procedure, the CA identifies and authenticates the Subscriber.

© 2018 SECOM Trust Systems Co., Ltd.
P-21

Organization Validation Certificate Policy Ver.1.23

4. Certificate Life-Cycle Operational Requirements
4.1 Certificate Application
4.1.1 Who May Submit a Certificate Application
A person who may submit a certificate application shall be individuals, corporations,other organizations that use certificates, and agents delegated by certificate
subscribers (hereinafter referred to as "Applicant").
In accordance with the CP, “Section 5.5.2, Retention Period for Archive”, the CA
SHALL maintain an internal database of all previously revoked Certificates andpreviously rejected certificate requests due to suspected phishing or other fraudulent
usage or concerns. The CA SHALL use this information to identify subsequentsuspicious certificate requests.
4.1.2 Enrollment Process and Responsibilities
Prior to the issuance of a Certificate, the CA SHALL obtain the following
documentation from the Applicant:
1. A certificate request, which may be electronic; and2. An executed Subscriber Agreement or Terms of Use, which may be electronic.
The CA SHOULD obtain any additional documentation the CA determines necessary
to meet the Baseline Requirements.
Prior to the issuance of a Certificate, the CA SHALL obtain from the Applicant acertificate request in a form prescribed by the CA and that complies with the Baseline
Requirements. One certificate request MAY suffice for multiple Certificates to beissued to the same Applicant, subject to the aging and updating requirement in thisCP

“4.2.1 Performing Identification and Authentication Functions”, provided thateach Certificate is supported by a valid, current certificate request signed by theappropriate Applicant Representative on behalf of the Applicant.

The certificate

request MAY be made, submitted and/or signed electronically.
The certificate request MUST contain a request from, or on behalf of, the Applicant for
the issuance of a Certificate, and a certification by, or on behalf of, the Applicant that
all of the information contained therein is correct.
4.2 Certificate Application Processing
The Certificate Subscriber or Applicant applies for the certificate using the certificate© 2018 SECOM Trust Systems Co., Ltd.
P-22

Organization Validation Certificate Policy Ver.1.23

issuance service provided by the Delegated Third Party.
4.2.1 Performing Identification and Authentication Functions
Once accepted, the Certificate Application is authenticated by t in accordance with "3.2
Initial Identification and Authentication" hereof.
The certificate request may include all factual information about the Applicant to be
included in the Certificate, and such additional information as is necessary for the CA
to obtain from the Applicant in order to comply with Baseline Requirements and theCA’s Certificate Policy and/or Certification Practice Statement. In cases where thecertificate request does not contain all the necessary information about the Applicant,the CA shall obtain the remaining information from the Applicant or, having obtained
it from a reliable, independent, third-party data source, confirm it with the Applicant.
The CA shall establish and follow a documented procedure for verifying all data
requested for inclusion in the Certificate by the Applicant.
Applicant information include, but not be limited to, at least one Fully-Qualified
Domain Name to be included in the Certificate’s Subject Alternative Name extension.
In this CP "6.3.2 Certificate Operational Periods and Key Pair Usage Periods", theexpiration date of the subscriber certificate is limited.
The CA may use the documents and data provided in Section “3.2 Initial Identity
Validation” to verify certificate information, or may reuse previous validations
themselves, provided that:
The CA obtained the data or document from a source specified under Section “3.2
Initial Identity Validation” or completed the validation itself no more than 825 days
prior to issuing the Certificate.
For validation of Domain Names according to Section “3.2.2.4 Domain Authentication”,
any data, document, or completed validation used MUST be obtained no more than
398 days prior to issuing the Certificate.
In no case may a prior validation be reused if any data or document used in the priorvalidation was obtained more than the maximum time permitted for reuse of the dataor document prior to issuing the Certificate.
After the change to any validation method specified in the Baseline Requirements or
EV Guidelines, a CA may continue to reuse validation data or documents collectedprior to the change, or the validation itself, for the period stated in the Baseline
Requirements Section 4.2.1 unless otherwise specifically provided in a ballot.
The CA checks the CAA record at the time of reviewing the application information.
The Certificate Subscribers who want to grant the authority to issue certificates to© 2018 SECOM Trust Systems Co., Ltd.
P-23

Organization Validation Certificate Policy Ver.1.23

the FQDN must include the value of "secomtrust.net" in the property "issue" or“issuewild” of the CAA record for each DNS zone.
If there is already a CAA entry in each DNS zone of the Certificate Subscriber and acertificate is required to be issued by this CA, the value of "secomtrust.net" must be
included in the property "issue" or “issuewild” of the CAA record.
The CA shall develop, maintain, and implement documented procedures that identify
and require additional verification activity for High Risk Certificate Requests prior to
the Certificate’s approval, as reasonably necessary to ensure that such requests areproperly verified under Baseline Requirements.
If a Delegated Third Party fulfills any of the CA’s obligations under this section, theCA shall verify that the process used by the Delegated Third Party to identify andfurther verify High Risk Certificate Requests provides at least the same level ofassurance as the CA’s own processes.
4.2.2 Approval or Rejection of Certificate Applications
The CA issues a Certificate corresponding to any application that it approves, notifying
the relevant Subscriber of the completion thereof and the issuance of the Certificate.
In addition, it shall be possible to reject the application for a certificate in which theexamination of all items is not completed adequately, and the one including thefollowing reasons shall be rejected.
・Certificate of Applicant or Subscriber who was previously rejected or previously
violated the terms of the contract
・Have an internal server name or reserved IP address in the Subject Alternative
Name extension field or "common name" field
The CA shall notify the Applicant or the Subscriber of the content of the deficiency andthe resubmission of documents, etc., either directly or through Delegated Third Party.
4.2.3 Time to Process Certificate Applications
The CA promptly issues a Certificate corresponding to any approved Certificate
Application.
4.3 Certificate Issuance© 2018 SECOM Trust Systems Co., Ltd.
P-24

Organization Validation Certificate Policy Ver.1.23

4.3.1 CA Actions during Certificate Issuance
Upon completion of the review and authentication of a Certificate Application, the CA
issues the corresponding Certificate and makes it available for download via a website
accessible only by the Subscriber or send the Certificate to the Subscriber.
Certificate issuance by the Root CA SHALL require an individual authorized by the
CA (i.e. the CA system operator, system officer, or PKI administrator) to deliberately
issue a direct command in order for the Root CA to perform a certificate signing
operation.
The CA confirms whether the format conforms to Baseline Requirements for someitems of the certificate to be issued by the pre-certificate linting function, and refuses
to issue if it does not meet the requirements.
The CA enforces multi-factor authentication for all accounts capable of directly causing
certificate issuance.
The backdating of a certificate's notBefore date to avoid a deadline, prohibition or codeenforced restriction is not used by the CA.
4.3.2 Notifications to Subscriber of Certificate Issuance
The CA will notify the Certificate Subscriber of the issuance via the homepage that
only the Certificate Subscriber can access, or by e-mail or postal mail.
4.4 Certificate Acceptance
4.4.1 Conduct Constituting Certificate Acceptance
When the Subscriber downloaded the Certificate, or when the certificate sent by the
Subscriber is introduced to the server by other methods, the acceptance thereof shallbe deemed complete.
4.4.2 Publication of the Certificate by the CA
The CA certificate of the CA will be published in the repository. The CA can publish
the certificate of the certificate subscriber by registering it in the CT (Certificate
Transparency) log.
4.4.3 Notification of Certificate Issuance by the CA to Other Entities
The CA will not send a notice of Certificate issuance to entities other than the person
in charge, who was registered at the time of the Certificate Application submission.

© 2018 SECOM Trust Systems Co., Ltd.
P-25

Organization Validation Certificate Policy Ver.1.23

4.5 Key Pair and Certificate Usage
4.5.1 Subscriber Private Key and Certificate Usage
Certificates shall be used in accordance with this CP, Service Terms and the CPS.
Subscriber shall protect the Private Key from unauthorized use or disclosure by third
parties and shall use the Private Key only for its intended purpose in accordance with
“9.6.3 Subscriber Representations and Warranties”.
4.5.2 Relying Party Public Key and Certificate Usage
Relying Parties shall acknowledge and agree to the provisions of this CP and the CPS
before using the CA Certificates.
Relying Parties may use the CA Certificates for assessment of Subscriber Certificates.
4.6 Certificate Renewal
The CA recommends generating a new Key Pair when Subscribers renew a Certificate.
4.6.1 Circumstances for Certificate Renewal
Certificate renewal without key renewal is performed when the validity period of thecertificate expires.
4.6.2 Who May Request Renewal
The provisions of this CP "4.1.1 Who May Submit a Certificate Application" hereof
shall apply.
4.6.3 Processing Certificate Renewal Requests
The provisions of this CP "4.3.1 CA Actions during Certificate Issuance" hereof shallapply.
4.6.4 Notification of New Certificate Issuance to Subscriber
The provisions of this CP “4.3.2 Notifications to Subscriber of Certificate Issuance"
hereof shall apply.
4.6.5 Conduct Constituting Acceptance of a Renewal Certificate
The provisions of this CP "4.4.1 Conduct Constituting Certificate Acceptance" hereof
shall apply.

© 2018 SECOM Trust Systems Co., Ltd.
P-26

Organization Validation Certificate Policy Ver.1.23

4.6.6 Publication of the Renewal Certificates by the CA
The provisions of this CP "4.4.2 Publication of the Certificate by the CA" hereof shallapply.
4.6.7 Notification of Certificate Issuance by the CA to Other Entities
The provisions of this CP “4.4.3 Notification of Certificate Issuance by the CA to Other
Entities" hereof shall apply.
4.7 Certificate Re-Key
4.7.1 Circumstances for Certificate Re-Key
A Certificate is Re-Keyed when the validity period of the Certificate is about to expire
or when the Certificate is revoked due to the key compromise.
4.7.2 Who May Request Certification of a New Public Key
The provisions of this CP "4.1.1 Who Can Submit a Certificate Application" hereof
shall apply.
4.7.3 Processing Certificate Re-Keying Requests
The provisions of this CP "4.3.1 CA Actions during Certificate Issuance" hereof shallapply.
4.7.4 Notification of New Certificate Issuance to Subscriber
The provisions of this CP "4.3.2 Notifications to Subscriber of Certificate Issuance"
hereof shall apply.
4.7.5 Conduct Constituting Acceptance of a Re-Keyed Certificate
The provisions of this CP "4.4.1 Conduct Constituting Certificate Acceptance" hereof
shall apply.
4.7.6 Publication of the Re-Keyed Certificate by the CA
The provisions of this CP "4.4.2 Publication of the Certificate by the CA" hereof shallapply.
4.7.7 Notification of Certificate Issuance by the CA to Other Entities
The provisions of this CP "4.4.3 Notification of Certificate Issuance by the CA to Other© 2018 SECOM Trust Systems Co., Ltd.
P-27

Organization Validation Certificate Policy Ver.1.23

Entities" hereof shall apply.
4.8 Certificate Modification
Should modification be required in any information registered in a Certificate, the CA
shall revoke the relevant Certificate and issue a new Certificate.
4.8.1 Circumstances for Certificate Modification
No stipulation
4.8.2 Who May Request Certificate Modification
The provisions of this CP "4.1.1 Who May Submit a Certificate Application" hereof
shall apply.
4.8.3 Processing Certificate Modification Requests
The provisions of this CP "4.3.1 CA Actions during Certificate Issuance" hereof shallapply.
4.8.4 Notification of New Certificate Issuance to Subscriber
The provisions of this CP "4.3.2 Notifications to Subscriber of Certificate Issuance"
hereof shall apply.
4.8.5 Conduct Constituting Acceptance of Modified Certificate
The provisions of this CP "4.4.1 Conduct Constituting Certificate Acceptance" hereof
shall apply.
4.8.6 Publication of the Modified Certificates by the CA
The provisions of this CP "4.4.2 Publication of the Certificate by the CA" hereof shallapply.
4.8.7 Notification of Certificate Issuance by the CA to Other Entities
The provisions of this CP "4.4.3 Notification of Certificate Issuance by the CA to Other
Entities" hereof shall apply.
4.9 Certificate Revocation and Suspension© 2018 SECOM Trust Systems Co., Ltd.
P-28

Organization Validation Certificate Policy Ver.1.23

4.9.1 Circumstances for Certificate Revocation
The CA MAY support revocation of Short-lived Subscriber Certificates.
With the exception of Short-lived Subscriber Certificates, the CA shall revoke a
Certificate within 24 hours and use the corresponding CRLReason (revocation reason)in this CP “7.2.2 Certificate Revocation Lists and CRL Entry Extensions” if one ormore of the following occurs:
1. The Subscriber requests in writing, without specifying CRLreason, that the CA
revoke the Certificate (CRLReason “unspecified (0)” which results in noreasonCode extension being provided in the CRL);
2. The Subscriber notifies the CA that the original certificate request was not
authorized and does not retroactively grant authorization (CRL Reason #9,
privilegeWithdrawn);
3. The CA obtains evidence that the Subscriber’s Private Key corresponding to
the Public Key in the Certificate suffered a Key Compromise (CRL Reason #1,
key Compromise);
4. The CA is made aware of a demonstrated or proven method that can easily
compute the Subscriber’s Private Key based on the Public Key in theCertificate, including but not limited to those identified in (the Baseline
Requirements

Section 6.1.1.3(5), CPS 6.1.1 “Key Pair Generation”) (CRL

Reason #1, key Compromise);
5. The CA obtains evidence that the validation of domain authorization or control
for any Fully-Qualified Domain Name or IP address in the Certificate should
not be relied upon (CRLReason #4, superseded);With the exception of Short-lived Subscriber Certificates, the CA should revoke acertificate within 24 hours, must revoke a Certificate within 5 days and use thecorresponding CRLReason if one or more of the following occurs:
6.

The Certificate no longer complies with the requirements of Section “6.1.5
Key Sizes” and Section “6.1.6 Public Key Parameters Generation andQuality Checking” of this CP (CRLReason #4, superseded) ;7. The CA obtains evidence that the Certificate was misused (CRLReason #9,
privilegeWithdrawn);
8.

The CA is made aware that a Subscriber has violated one or more of its
material obligations under the Subscriber Agreement or Terms of Use (CRL
Reason #9, privilegeWithdrawn);© 2018 SECOM Trust Systems Co., Ltd.
P-29

Organization Validation Certificate Policy Ver.1.23

9. The CA is made aware of any circumstance indicating that use of a FullyQualified Domain Name or IP address in the Certificate is no longer legallypermitted (e.g. a court or arbitrator has revoked a Domain Name
Registrant’s right to use the Domain Name, a relevant licensing or services
agreement between the Domain Name Registrant and the Applicant has
terminated, or the Domain Name Registrant has failed to renew the DomainName) (CRLReason #5, cessationOfOperation);
10. The CA is made aware that a Wildcard Certificate has been used toauthenticate a fraudulently misleading subordinate Fully-Qualified Domain
Name (CRLReason #9, privilegeWithdrawn);
11. The CA is made aware of a material change in the information contained in
the Certificate (CRLReason #9, privilegeWithdrawn);
12. The CA is made aware that the Certificate was not issued in accordance withthese Requirements or the CA's Certificate Policy or Certification PracticeStatement (CRLReason #4, superseded);
13. The CA determines or is made aware that any of the information appearing
in the Certificate is inaccurate (CRLReason #9, privilegeWithdrawn);
14. The CA's right to issue Certificates under these Requirements expires or isrevoked or terminated, unless the CA has made arrangements to continue
maintaining the CRL/OCSP Repository (CRLReason “unspecified (0)” which
results in no reasonCode extension being provided in the CRL);
15.

Revocation is required by the CA's Certificate Policy and/or Certification
Practice Statement for a reason that is not otherwise required to be specified
by this section 4.9.1.1 (CRLReason “unspecified (0)” which results in noreasonCode extension being provided in the CRL);

16. The CA is made aware of a demonstrated or proven method that exposes the
Subscriber's Private Key to compromise, or if there is clear evidence that the
specific method used to generate the Private Key was flawed (CRLReason #1,
keyCompromise).
4.9.2 Who Can Request Revocation
A request for revocation of a Certificate shall be made by the Certificate Subscriber or
the Applicant. If the CA determines that the CP/CPS "4.9.1 Circumstances for
Certificate Revocation" applies, the CA may be the Applicant.
The Subscriber, RA, or Issuing CA can initiate revocation. Additionally, Subscribers,
Relying Parties, Application Software Suppliers, and other third parties may submit© 2018 SECOM Trust Systems Co., Ltd.
P-30

Organization Validation Certificate Policy Ver.1.23

Certificate Problem Reports informing the issuing CA of reasonable cause to revoke
the certificate.
4.9.3 Procedure for Revocation Request
A Subscriber or Applicant shall notify the CA by using the application provided by the
CA or the Delegated third Party and performing the prescribed procedures.
The CA confirms the information received by the prescribed procedure and revokes thecertificate.
4.9.4 Revocation Request Grace Period
Should a Subscriber or an Applicant determine that a Private Key has or could havebeen compromised, they must promptly make a revocation request.
4.9.5 Time within Which CA Shall Process the Revocation Request
The CA will promptly process the revocation of the certificate after receiving a valid
revocation application, and reflect the certificate information in the CRL.
Within 24 hours after receiving a Certificate Problem Report, the CA SHALL
investigate the facts and circumstances related to a Certificate Problem Report andprovide a preliminary report on its findings to both the Subscriber and the entity who
filed the Certificate Problem Report.
After reviewing the facts and circumstances, the CA SHALL work with the Subscriber
and any entity reporting the Certificate Problem Report or other revocation-related
notice to establish whether or not the certificate will be revoked, and if so, a date which
the CA will revoke the certificate. The period from receipt of the Certificate Problem
Report or revocation-related notice to published revocation MUST NOT exceed thetime frame set forth in the CP, “Section 4.9.1. Circumstances for Certificate
Revocation”. The date selected by the CA SHOULD consider the following criteria:
1. The nature of the alleged problem (scope, context, severity, magnitude, risk ofharm);
2. The consequences of revocation (direct and collateral impacts to Subscribers andRelying Parties);
3. The number of Certificate Problem Reports received about a particular Certificate
or Subscriber;
4. The entity making the complaint
If the CA receives an application for revocation with a specified date, it shall revokeon the specified date.
© 2018 SECOM Trust Systems Co., Ltd.
P-31

Organization Validation Certificate Policy Ver.1.23

4.9.6 Revocation Checking Requirements for Relying Parties
The URLs of the CRL storage destination and the OCSP responder are indicated on
the Certificates issued by the CA.
CRLs and the OCSP responder may be accessed using a commonly available Web
Interface. CRLs do not contain expired Certificate information.
Relying Parties must authenticate the validity of a Subscriber's Certificate. The
validity of a Certificate may be verified by using the CRL posted on the Repository siteor the OCSP responder.
4.9.7 CRL Issuance Frequency
CRLs must be available via a publicly-accessible HTTP URL (i.e., “published”).
Within twenty-four (24) hours of issuing its first Certificate, the CA MUST generate
and publish either: - a full and complete CRL; OR - partitioned (i.e., “sharded”) CRLs
that, when aggregated, represent the equivalent of a full and complete CRL.
If the CA publishes a CRL, then the CA shall update and reissue CRLs at least once
every seven days, and the value of the nextUpdate field MUST NOT be more than 10days beyond the value of the thisUpdate field.
4.9.8 Maximum Latency for CRLs
The CRLs issued by the CA are reflected onto the Repository within a reasonable time.
4.9.9 On-Line Revocation/Status Checking Availability
OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST
either:1. Be signed by the CA that issued the Certificates whose revocation status is being
checked, or
2. Be signed by an OCSP Responder whose Certificate is signed by the CA that issued
the Certificate whose revocation status is being checked.
In the latter case, the OCSP signing Certificate MUST contain an extension of type idpkix-ocsp-nocheck, as defined by RFC6960.
4.9.10 On-Line Revocation/Status Checking Requirements
Relying Parties must authenticate the validity of Subscriber Certificates. When notusing the CRL posted on the Repository to check for the Revocation registration of a
Certificate, the Relying Parties must confirm the Certificate status available throughthe OCSP responder.
© 2018 SECOM Trust Systems Co., Ltd.
P-32

Organization Validation Certificate Policy Ver.1.23

OCSP responders operated by the CA shall support the HTTP GET method, as
described in RFC 6960 and/or RFC 5019.
The validity interval of an OCSP response is the difference in time between the
thisUpdate and nextUpdate field, inclusive. For purposes of computing differences, adifference of 3,600 seconds shall be equal to one hour, and a difference of 86,400
seconds shall be equal to one day, ignoring leap-seconds.
For the status of Subscriber Certificates:
1. OCSP responses MUST have a validity interval greater than or equal to 8 hours;
2. OCSP responses MUST have a validity interval less than or equal to 10 days;
3. For OCSP responses with validity intervals less than sixteen hours, then the CA
shall update the information provided via an Online Certificate Status Protocol
prior to one-half of the validity period before the nextUpdate.
4. For OCSP responses with validity intervals greater than or equal to 16 hours,
then the CA shall update the information provided via an Online Certificate
Status Protocol at least 8 hours prior to the nextUpdate, and no later than 4days after the thisUpdate.
For the status of Subordinate CA Certificates:
The CA shall update information provided via an Online Certificate Status Protocol
i. at least every 12 months; andii. within 24 hours after revoking a Subordinate CA Certificate.
If the OCSP responder receives a request for the status of a certificate serial numberthat is "unused", then the responder SHOULD NOT respond with a "good" status. If
the OCSP responder is for a CA that is not Technically Constrained in line with thisCP "7.1.5 Name Constraints", the responder MUST NOT respond with a "good" status
for such requests.
The CA SHOULD monitor the OCSP responder for requests for "unused" serial
numbers as part of its security response procedures.
The OCSP responder MAY provide definitive responses about "reserved" certificate
serial numbers, as if there was a corresponding Certificate that matches thePrecertificate [RFC6962].
A certificate serial number within an OCSP request is one of the following 3 options:
1. "assigned" if a Certificate with that serial number has been issued by the IssuingCA, using any current or previous key associated with that CA subject; or
2. "reserved" if a Precertificate [RFC6962] with that serial number has been issuedby© 2018 SECOM Trust Systems Co., Ltd.
P-33

Organization Validation Certificate Policy Ver.1.23

a. the Issuing CA; or
b. a Precertificate Signing Certificate [RFC6962] associated with the Issuing
CA; or
3. "unused" if neither of the previous conditions are met.
4.9.11 Other Forms of Revocation Advertisements Available
The CA can distribute OCSP responses using stapling in accordance with RFC4366
RFC 5246, RFC 8446. In this case, the CA ensures that the subscriber includes the
OCSP response of the certificate in the TLS process. The CA will comply with thisrequirement for the subscriber after the Service Terms or the contract with thesubscriber, or after the technical confirmation by the CA and the approval of the service
manager.
4.9.12 Special Requirements Regarding Key Compromise
The Relying Party shall demonstrate key compromise in the following methods:
・ Submitting the private key itself, or the data containing the private key and how
to extract the private key from the data
・ Submitting the CSR that includes data such as distinguished names that arerecognized as compromised and that can verify the signature
・ Submitting the challenge response specified by the CA that can be verified bypublic key, and the private key signature for public key
・ Providing the vulnerabilities that can be verified for compromise and the sourcesof referenced security incidents
The CA will notify the Certificate Subscriber that the private key may have been
compromised if they learn that the private key of the Certificate Subscriber may havebeen compromised.
If the CA determines that the private key has been compromised or is likely to becompromised, the CP "4.9.1 Circumstances for Certificate Revocation" shall be dealt
with.
4.9.13 Circumstances for Suspension
The CA will not suspend Certificates.
4.9.14 Who Can Request Suspension
Not applicable.
© 2018 SECOM Trust Systems Co., Ltd.
P-34

Organization Validation Certificate Policy Ver.1.23

4.9.15 Procedure for Suspension Request
Not applicable.
4.9.16 Limits on Suspension Period
Not applicable.
4.10 Certificate Status Services
4.10.1 Operational Characteristics
Certificate status is available to Subscribers for confirmation through the OCSP
responder.
The CA MUST NOT remove revocation entries in CRL or OCSP responses until after
the Expiry Date of the revoked Certificate.
4.10.2 Service Availability
The CA SHALL operate and maintain its CRL and OCSP capability with resources
sufficient to provide a response time of 10 seconds or less under normal operating
conditions.
The CA SHALL maintain an online 24x7 Repository that application software can use
to automatically check the current status of all unexpired Certificates issued by theCA.
The CA SHALL maintain a continuous 24x7 ability to respond internally to a highpriority Certificate Problem Report, and where appropriate, forward such a complaint
to law enforcement authorities, and/or revoke a Certificate that is the subject of sucha complaint.
4.10.3 Optional Features
No stipulation
4.11 End of Subscription (Registry)
Subscribers shall submit a Certificate Revocation Request when ending the certificate
use. It will also end if they do not apply for the renewal of the certificate and thevalidity period of the corresponding certificate has expired.
4.12 Key Escrow and Recovery© 2018 SECOM Trust Systems Co., Ltd.
P-35

Organization Validation Certificate Policy Ver.1.23

4.12.1 Key Escrow and Recovery Policy and Practices
The CA does not Escrow Subscriber Private Keys.
4.12.2 Session Key Encapsulation and Recovery Policy and Practices
Not applicable.

© 2018 SECOM Trust Systems Co., Ltd.
P-36

Organization Validation Certificate Policy Ver.1.23

5. Facility, Management, and Operational Controls
5.1 Physical Controls
5.1.1 Site Location and Construction
Relevant provisions are stipulated in the CPS.
5.1.2 Physical Access
Relevant provisions are stipulated in the CPS.
5.1.3 Power and Air Conditioning
Relevant provisions are stipulated in the CPS.
5.1.4 Water Exposures
Relevant provisions are stipulated in the CPS.
5.1.5 Fire Prevention and Protection
Relevant provisions are stipulated in the CPS.
5.1.6 Media Storage
Relevant provisions are stipulated in the CPS.
5.1.7 Waste Disposal
Relevant provisions are stipulated in the CPS.
5.1.8 Off-Site Backup
Relevant provisions are stipulated in the CPS.
5.2 Procedural Controls
5.2.1 Trusted Roles
Relevant provisions are stipulated in the CPS.
5.2.2 Number of Persons Required per Task
Relevant provisions are stipulated in the CPS.

© 2018 SECOM Trust Systems Co., Ltd.
P-37

Organization Validation Certificate Policy Ver.1.23

5.2.3 Identification and Authentication for Each Role
Relevant provisions are stipulated in the CPS.
5.2.4 Roles Requiring Separation of Duties
Relevant provisions are stipulated in the CPS.
5.3 Personnel Controls
5.3.1 Qualifications, Experience, and Clearance Requirements
Relevant provisions are stipulated in the CPS.
5.3.2 Background Check Procedures
Relevant provisions are stipulated in the CPS.
5.3.3 Training Requirements
Relevant provisions are stipulated in the CPS.
5.3.4 Retraining Frequency and Requirements
Relevant provisions are stipulated in the CPS.
5.3.5 Job Rotation Frequency and Sequence
Relevant provisions are stipulated in the CPS.
5.3.6 Sanctions for Unauthorized Actions
Relevant provisions are stipulated in the CPS.
5.3.7 Independent Contractor Requirements
Relevant provisions are stipulated in the CPS.
5.3.8 Documentation Supplied to Personnel
Relevant provisions are stipulated in the CPS.
5.4 Audit Logging Procedures
5.4.1 Types of Events Recorded
Relevant provisions are stipulated in the CPS.
© 2018 SECOM Trust Systems Co., Ltd.
P-38

Organization Validation Certificate Policy Ver.1.23

5.4.2 Frequency of Processing Audit Log
Relevant provisions are stipulated in the CPS.
5.4.3 Retention Period for Audit Log
Relevant provisions are stipulated in the CPS.
5.4.4 Protection of Audit Log
Relevant provisions are stipulated in the CPS.
5.4.5 Audit Log Backup Procedure
Relevant provisions are stipulated in the CPS.
5.4.6 Audit Log Collection System
Relevant provisions are stipulated in the CPS.
5.4.7 Notification to Event-Causing Subject
Relevant provisions are stipulated in the CPS.
5.4.8 Vulnerability Assessments
Relevant provisions are stipulated in the CPS.
5.5 Records Archival
5.5.1 Types of Records Archived
Relevant provisions are stipulated in the CPS.
5.5.2 Retention Period for Archive
Relevant provisions are stipulated in the CPS.
5.5.3 Protection of Archive
Relevant provisions are stipulated in the CPS.
5.5.4 Archive Backup Procedures
Relevant provisions are stipulated in the CPS.

© 2018 SECOM Trust Systems Co., Ltd.
P-39

Organization Validation Certificate Policy Ver.1.23

5.5.5 Requirements for Time-Stamping of Records
Relevant provisions are stipulated in the CPS.
5.5.6 Archive Collection System
Relevant provisions are stipulated in the CPS.
5.5.7 Procedures to Obtain and Verify Archive Information
Relevant provisions are stipulated in the CPS.
5.6 Key Changeover
Renewal of Key-Pairs or Certificates of the CA, as a general rule, shall be made before
their remaining validity periods become shorter than the maximum validity periods of
the Certificates issued to Subscribers. After the new key pair is generated, thecertificate and CRL are issued using the new key pair.
5.7 Compromise and Disaster Recovery
5.7.1 Incident and Compromise Handling Procedures
Relevant provisions are stipulated in the CPS.
5.7.2 Computing Resources, Software, and/or Data are Corrupted
Relevant provisions are stipulated in the CPS.
5.7.3 Entity Private Key Compromise Procedures
Relevant provisions are stipulated in the CPS.
5.7.4 Business Continuity Capabilities after a Disaster
Relevant provisions are stipulated in the CPS.
5.8 CA or RA Termination
In the event of termination of the CA, it shall so notify Subscribers and other affectedparticipants, including Application Software Suppliers through the Delegated Third
Party, three (3) months prior to the termination.

© 2018 SECOM Trust Systems Co., Ltd.
P-40

Organization Validation Certificate Policy Ver.1.23

6. Technical Security Controls
6.1 Key Pair Generation and Installation
6.1.1 Key Pair Generation
Relevant provisions are stipulated in the CPS.
6.1.2 Private Key Delivery to Subscriber
The CA does not deliver Private Keys to Subscribers.
6.1.3 Public Key Delivery to Certificate Issuer
A Subscriber Public Key may be delivered online to the CA, the communication routingof which is encrypted by SSL/TLS.
6.1.4 CA Public Key Delivery to Relying Parties
Relying Parties may obtain CA Public Keys by accessing the CA Repository.
6.1.5 Key Sizes
Relevant provisions are stipulated in the CPS.
6.1.6 Public Key Parameters Generation and Quality Checking
Relevant provisions are stipulated in the CPS.
6.1.7 Key Usage Purposes
Usage Purposes of the CA and the Certificates issued by the CA shall be as follows:
Table 6.1-1 Key Usage Purposes
The CAThe Certificates issued by
the CAdigital Signature-

yes

nonRepudiation--

keyEncipherment-

Yes（Optional if the public keyof the end entity certificate
is RSA, prohibited if it is
ECDSA）

dataEncipherment--© 2018 SECOM Trust Systems Co., Ltd.
P-41

Organization Validation Certificate Policy Ver.1.23

keyAgreement--

keyCertSign

yes-

cRLSignyes-

encipherOnly--

decipherOnly--

6.2 Private Key Protection and Cryptographic Module Engineering Controls
6.2.1 Cryptographic Module Standards and Controls
The generation, storage and signing operations of the CA Private Keys are performed
using an FIPS140-2 Level 3 conformant cryptographic module.
No stipulation for Subscriber Private Keys.
6.2.2 Private Key Multi-Person Control
Activation, deactivation, backup and other operations relating to CA Private Keys arejointly performed by at least two authorized individuals in a secure environment.
Activation, deactivation, backup and other operations relating to Subscriber Private
Keys must be performed securely under the control of the relevant Subscribers.
6.2.3 Private Key Escrow
The CA does not Escrow CA Private Keys.
The CA does not Escrow Subscriber Private Keys.
6.2.4 Private Key Backup
Backup of Private Keys of the CA is jointly performed by at least two authorizedindividuals and is stored in a secure room as encrypted.
The backup of Subscriber Private Keys must be securely stored under the control of
the relevant Subscribers.
6.2.5 Private Key Archival
The CA does not archive CA Private Keys.
No stipulation for Subscriber Private Keys.
6.2.6 Private Key Transfer into or from a Cryptographic
The transfer of Private Keys of the CA into and from a cryptographic module isperformed in a secure room while encrypted.
© 2018 SECOM Trust Systems Co., Ltd.
P-42

Organization Validation Certificate Policy Ver.1.23

No stipulation for Subscriber Private Keys.
6.2.7 Private Key Storage on Cryptographic Module
Private Keys of the CA operated on the Digital Certification Infrastructure are stored
within the cryptographic module.
No stipulation for Subscriber Private Keys.
6.2.8 Method of Activating Private Key
The CA Private Key is jointly activated by at least two authorized individuals in asecure room.
No stipulation for Subscriber Private Keys.
6.2.9 Method of Deactivating Private Key
The CA Private Key is jointly deactivated by at least two authorized individuals in asecure room.
No stipulation for Subscriber Private Keys.
6.2.10 Method of Destroying Private Key
Private Keys of the CA are jointly destroyed by at least two authorized individuals bymeans of complete initialization or physical destruction. The Private Key backups arealso destroyed in the same manner.
No stipulation for Subscriber Private Keys.
6.2.11 Cryptographic Module Rating
The quality standards to be applied to the cryptographic modules used by the CA are
as specified in "6.2.1 Cryptographic Module Standards and Controls" hereof.
No stipulation for Subscriber Private Keys.
6.3 Other Aspects of Key Pair Management
6.3.1 Public Key Archival
The provisions for the CA Public Keys are stipulated in "6.2.1 Cryptographic Module
Standards and Controls" of the CPS.
No stipulation for Subscriber Private Keys.
6.3.2 Certificate Operational Periods and Key Pair Usage Periods© 2018 SECOM Trust Systems Co., Ltd.
P-43

Organization Validation Certificate Policy Ver.1.23

Relevant provisions are stipulated in the CPS.
6.4 Activation Data
6.4.1 Activation Data Generation and Installation
Relevant provisions are stipulated in the CPS.
6.4.2 Activation Data Protection
Relevant provisions are stipulated in the CPS.
6.4.3 Other Aspects of Activation Data
Relevant provisions are stipulated in the CPS.
6.5 Computer Security Controls
6.5.1 Specific Computer Security Technical Requirements
The CA enforce multi-factor authentication for all accounts capable of directly causing
certificate issuance.
6.5.2 Computer Security Rating
Relevant provisions are stipulated in the CPS.
6.6 Life-Cycle Technical Controls
6.6.1 System Development Controls
Relevant provisions are stipulated in the CPS.
6.6.2 Security Management Controls
Relevant provisions are stipulated in the CPS.
6.6.3 Life-Cycle Security Controls
Relevant provisions are stipulated in the CPS.
6.7 Network Security Controls
Relevant provisions are stipulated in the CPS.
6.8 Time-Stamping© 2018 SECOM Trust Systems Co., Ltd.
P-44

Organization Validation Certificate Policy Ver.1.23

Relevant provisions are stipulated in the CPS.

© 2018 SECOM Trust Systems Co., Ltd.
P-45

Organization Validation Certificate Policy Ver.1.23

7. Certificate, CRL, and OCSP Profiles
7.1 Certificate Profile
The CA SHALL meet the technical requirements set forth in the CP, “Section 2.2 –Publication of Information”, “Section 6.1.5– Key Sizes”, and “Section 6.1.6 – Public Key
Parameters Generation and Quality Checking”.
CAs SHALL generate non-sequential Certificate serial numbers greater than zero (0)and less than 2^159 containing at least 64 bits of output from a CSPRNG.
Certificates issued by the CA conform to RFC5280, the profile of which are indicatedin the tables below.
As defined in Section 7.1.2.9 of the Baseline Requirements, for Version, Serial Number,
Signature, Issuer, Validity, Subject, SubjectPublicKeyInfo, and SignatureAlgorithm of
the Precertificate of the TLS server certificate, the encoded values must be byte-forbyte identical to the TLS server certificate. The order, criticality, and encoded valuesof Extension fields other than "Extension for Certificate Transparency" must be bytefor-byte identical to the extensions field of the certificate. The Precertificate MUST
contain the Precertificate Poison extension (OID: 1.3.6.1.4.1.11129.2.4.3). Thisextension MUST have an extnValue OCTET STRING which is exactly the hex‐
encoded bytes 0500, the encoded representation of the ASN.1 NULL value, as specified
in RFC 6962, Section 3.1.
Table 7.1-1 Server Certificate Profile(CA issued by Security Communication Root CA2)
Basic Fields

Settings

CriticalVersionVersion 3-

Serial Number

non ‐ sequential Certificate serial-

numbers greater than zero (0) andless than 2^159 containing at least
64 bits of output from a CSPRNG
Signature Algorithm

sha256WithRSAEncryption-

IssuerCountry

C=JP-

Organization

O=SECOM Trust Systems CO.,LTD.

-

Common Name

CN= Set the common name of each-certificate authority
Validity

NotBefore

A value within 48 hours before the-© 2018 SECOM Trust Systems Co., Ltd.
P-46

Organization Validation Certificate Policy Ver.1.23

certificate signing
NotAfterSpecified

in

the

CPS

“6.3.2-

Certificate Operational Periods and
Key Pair Usage Periods”.
Subject

Country

C=JP (Fixed value)-

State Or Province

Required-

Locality

Required-Organization

Required-Organizational Unit

Prohibited-

Common Name

Required-

Only one entry must be included,
which is one of the values included inthe

Subject

AlternativeNameextension of the certificate. The
value

must

be

encodedasacharacter-for-character copy of thedNSName entry value from the
Subject Alternative Name extension.
Specifically, the FQDN part of alldomain labels in a fully qualified
domain name must be encoded as
LDH labels, and P labels must not be
converted to Unicode representation.
Must not contain a reserved IP
address or internal name.
Subject Public Key Info

One of the following:-

RSA2048 bits,3072 bits, 4096 bits,
ECDSA384 bits（secp384r1）, 256 bits
（secp256r1）
Extension Fields

Settings

keyUsage

digitalSignature,

CriticalY(keyEncipherment)* If subjectPublicKeyInfo is RSA,
keyEncipherment is optional.
For ECDSA, keyEncipherment isprohibited.
© 2018 SECOM Trust Systems Co., Ltd.
P-47

Organization Validation Certificate Policy Ver.1.23

extendedKeyUsage

serverAuth , clientAuth

N* clientAuth shall be optional.
Subject Altanative Name

RequiredN

Includes at least one dNSName.
Includesfully

qualifieddomainnames verified according to this CP"3.2.2.4 Domain Authentication ".
The entry cannot include an internal
name. The FQDN portion of the fully
qualified domain name contained in
the entry must be composed entirelyof LDH Labels joined together by aU+002E FULL STOP (“.”) character.
Thezero-length

DomainLabel

representing the root zone of theInternet Domain Name System mustnot be included.
Effective

2021-10-01,

theFully-

Qualified

DomainName

mustconsist solely of Domain Labels thatare P-Labels or Non-Reserved LDH
Labels.
CertificatePolicies[1]policyIdentifierN

OID= Set [1.2-1 OID] of this CP
policyQualifiers
policyQualifierId=CPS
qualifier= HTTP(S) URL for theRepository of the CA[2]policyIdentifier= 2.23.140.1.2.2* policyQualifier is deprecated.
CRL Distribution Points

HTTP URL for the CRL service of the

N

CA
*

Optional

if

id-ad-ocsp

accessMethod is present in the
Authority

Information

Accessextension.
© 2018 SECOM Trust Systems Co., Ltd.
P-48

Organization Validation Certificate Policy Ver.1.23

Authority Information Access

accessMethodNocsp (1.3.6.1.5.5.7.48.1)
accessLocation
HTTP URL of OCSP responder
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
HTTP URL for the CA certificate
Authority Key Identifier

SHA-1 hash value of Authority

N

Public Key (160 bits)
Subject Key Identifier

OptionalN

SHA-1 hash value of the Subject
Public Key (160 bits)
Certificate Transparency Extension

OptionalN（1.3.6.1.4.1.11129.2.4.2）

SignedCertificateTimestampList
value

Table 7.1-2 Server Certificate Profile(CA issued by Security Communication ECC Root CA1)
Basic Fields

Settings

CriticalVersionVersion 3-

Serial Number

non ‐ sequential Certificate serial-

numbers greater than zero (0) andless than 2^159 containing at least
64 bits of output from a CSPRNG
Signature Algorithm

ecdsa-with-SHA384-

IssuerCountry

C=JP-

Organization

O=SECOM Trust Systems CO.,LTD.

-

Common Name

CN=Set the common name of each-certificate authority
Validity

NotBefore

A value within 48 hours before the-certificate signing
NotAfterSpecified

in

the

CPS

“6.3.2-

Certificate Operational Periods and
Key Pair Usage Periods”.

© 2018 SECOM Trust Systems Co., Ltd.
P-49

Organization Validation Certificate Policy Ver.1.23

Subject

Country

C=JP (Fixed value)

State Or Province

Required

Locality

RequiredOrganization

RequiredOrganizational Unit

Prohibited

Common Name

Optional--

Only one entry must be included,
which is one of the values included inthe

Subject

AlternativeNameextension of the certificate. The
value

must

be

encodedasacharacter-for-character copy of thedNSName entry value from the
Subject Alternative Name extension.
Specifically, the FQDN part of alldomain labels in a fully qualified
domain name must be encoded as
LDH labels, and P labels must not be
converted to Unicode representation.
Must not contain a reserved IP
address or internal name.
Subject Public Key Info

One of the following:-

RSA2048 bits, 3072 bits, 4096 bits,
ECDSA384 bits（secp384r1）, 256 bits
（secp256r1）
Extension Fields

Settings

keyUsage

digitalSignature,

CriticalY(keyEncipherment)* If subjectPublicKeyInfo is RSA,
keyEncipherment is optional.
For ECDSA, keyEncipherment isprohibited.
extendedKeyUsage

serverAuth, clientAuth

N* clientAuth shall be optional
Subject Alt Name

RequiredN

Includes at least one dNSName.
© 2018 SECOM Trust Systems Co., Ltd.
P-50

Organization Validation Certificate Policy Ver.1.23

Includesfully

qualifieddomainnames verified according to this CP"3.2.2.4 Domain Authentication ".
The entry cannot include an internal
name. The FQDN portion of the fully
qualified domain name contained in
the entry must be composed entirelyof LDH Labels joined together by aU+002E FULL STOP (“.”) character.
Thezero-length

DomainLabel

representing the root zone of theInternet Domain Name System mustnot be included.
The FQDN part of a fully FullyQualified

DomainName

mustconsist solely of Domain Labels thatare P-Labels or Non-Reserved LDH
Labels.
CertificatePolicies[1]policyIdentifierN

OID = Set [1.2-1 OID] of this CP
policyQualifiers
policyQualifierId=CPS
qualifier= HTTP(S) URL for theRepository of the CA[2]policyIdentifier=2.23.140.1.2.2* policyQualifier is deprecated.
CRL Distribution Points

HTTP URL for the CRL service of the

N

CA
*

Optional

if

id-ad-ocsp

accessMethod is present in the
Authority

Information

Accessextension.
Authority Information Access

accessMethodNocsp（1.3.6.1.5.5.7.48.1)
accessLocation
HTTP URL for OCSP responder© 2018 SECOM Trust Systems Co., Ltd.
P-51

Organization Validation Certificate Policy Ver.1.23

CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
HTTP URL for the CA certificate
Authority Key Identifier

SHA-1 hash value of the Authority

N

Public Key (160 bits)
Subject Key Identifier

OptionalN

SHA-1 hash value of the Subject
Public Key (160 bits)
Certificate Transparency Extension

OptionalN（1.3.6.1.4.1.11129.2.4.2）

SignedCertificateTimestampList
value

Table 7.1-3 OCSP Responder Certificate Profile(CA issued by Security Communication Root CA2)
Basic Fields

Settings

CriticalVersionVersion 3-

Serial Number

non ‐ sequential Certificate serial-

numbers greater than zero (0) andless than 2^159 containing at least
64 bits of output from a CSPRNG
Signature Algorithm

sha256WithRSAEncryption-

IssuerCountry

C=JP-

Organization

O=SECOM Trust Systems CO.,LTD.

-

Common Name

CN=Set the common name of each-certificate authority
Validity

NotBefore

A value within 1 day before the-certificate signing
NotAfterSpecified

in

the

CPS

“6.3.2-

Certificate Operational Periods and
Key Pair Usage Periods”
Subject

Country

C=JP (Fixed value)-

Organization

SECOM Trust Systems CO.,LTD-(Fixed value)
Common NameOCSP Responder Name-

© 2018 SECOM Trust Systems Co., Ltd.
P-52

Organization Validation Certificate Policy Ver.1.23

Subject Public Key Info

One of the following:
RSA2048 bits, 3072 bits, 4096 bits.

Extension Fields

Settings

CriticalkeyUsage

digitalSignatureYextendedKeyUsageOCSPSigningN

OCSP No Check

null

N

CertificatePolicies

Prohibited

N

Authority Key Identifier

SHA-1 hash value of the Authority

N

Public Key (160 bits)
Subject Key Identifier

SHA-1 hash value of the Subject

N

Public Key (160 bits)
Table 7.1-4 OCSP Server Certificate Profile(CA issued by Security Communication Root CA1)
Basic Fields

Settings

CriticalVersionVersion 3-

Serial Number

non ‐ sequential Certificate serial-

numbers greater than zero (0) andless than 2^159 containing at least
64 bits of output from a CSPRNG
Signature Algorithm

ecdsa-with-SHA384-

IssuerCountry

C=JP-

Organization

O=SECOM Trust Systems CO.,LTD.

-

Common Name

CN= Set the common name of each-certificate authority
Validity

NotBefore

A value within 1 day before the-certificate signing
NotAfterSpecified

in

the

CPS

“6.3.2-

Certificate Operational Periods and
Key Pair Usage Periods”
Subject

Country

C=JP (Fixed value)-

Organization

SECOM Trust Systems CO.,LTD-(Fixed value)
Common NameOCSP Responder Name-

© 2018 SECOM Trust Systems Co., Ltd.
P-53

Organization Validation Certificate Policy Ver.1.23

Subject Public Key Info

One of the following:
ECDSA384 bits（secp384r1）, 256 bits
（secp256r1）

Extension Fields

Settings

CriticalkeyUsage

digitalSignatureYextendedKeyUsageOCSPSigningN

OCSP No Check

null

N

CertificatePolicies

Prohibited

N

Authority Key Identifier

SHA-1 hash value of Authority

N

Public Key (160 bits)
Subject Key Identifier

SHA-1 hash value of the Subject

N

Public Key (160 bits)
7.1.1 Version Number(s)The CA applies version 3.
7.1.2 Certificate Extension
Certificates issued by the CA use certificate extension fields. The certificate profile
described in “7.1 Certificate Profile” includes a certificate extension.
7.1.3 Algorithm Object Identifier
The algorithm OID used in this service is as follows:
Algorithm

Object Identifier

rsaEncryption{iso(1)

member-body(2)us(840)rsadsi(113549)

pkcs(1) pkcs-1(1) 1}
sha256WithRSAEncryption{iso(1) member-body(2) us(840) rsadsi (113549)
pkcs(1) pkcs-1(1) 11}

sha384WithRSAEncryption{iso(1) member-body(2) us(840) rsadsi (113549)
pkcs(1) pkcs-1(1) 12}

id-ecPublicKey{ iso(1) member-body(2) us(840) ansi-X9-62(10045) idpublicKeyType(2) 1 }ecdsa-with-SHA384{ iso(1) member-body(2) us(840) ansi-X9-62 (10045)
signatures(4) ecdsa-with-SHA2(3) 3 }7.1.4 Name Format© 2018 SECOM Trust Systems Co., Ltd.
P-54

Organization Validation Certificate Policy Ver.1.23

The CA uses the Distinguished Name specified in RFC5280.
For every valid Certification Path (as defined by RFC 5280, Section 6):
For each Certificate in the Certification Path, the encoded content of the Issuer
Distinguished Name field of a Certificate SHALL be byte-for-byte identical with theencoded form of the Subject Distinguished Name field of the Issuing CA certificate.
By issuing the Certificate, the CA represents that it followed the procedure set forthin its Certificate Policy and/or Certification Practice Statement to verify that, as of theCertificate’s issuance date, all of the Subject Information was accurate. CAs SHALLNOT include a Domain Name in a Subject attribute except as specified in Baseline
Requirements Section 3.2.2.4.
Distinguished Names MUST NOT contain only metadata such as '.', '-', and ' ' (i.e.
space) characters, and/or any other indication that the value is absent, incomplete, or
not applicable.
The CA will not issue a certificate with a Subject Alternative Name extension or"common name" field that contains a reserved IP address or internal name.
If the "common name" value is a fully qualified domain name or a wildcard domain
name, the "common name" value is encoded as a character-for-character copy of thedNSName entry value in the Subject Alternative Name extension. Specifically, all
Domain Labels in the FQDN part of a fully qualified domain name or wildcard domainname are encoded as LDH Labels, and P-Labels does not convert to Unicode.
7.1.5 Name Constraints
Not set in the CA.
7.1.6 Certificate Policy Object Identifier
The OID of the certificate issued by the CA is as described in this CP "1.2 Document
Name and Identification".
The following Certificate Policy identifiers are reserved for use by CAs as an optional
means of assertaing that a Certificate complies with Baseline Requirements.
{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificatepolicies(1) baseline-requirements(2) organization-validated(2)} (2.23.140.1.2.2)
7.1.7 Use of Policy Constraint Extensions
Not set.
7.1.8 Policy Qualifier Syntax and Semantics© 2018 SECOM Trust Systems Co., Ltd.
P-55

Organization Validation Certificate Policy Ver.1.23

For the policy qualifier, the URI of the Web page that publishes this CP and CPS isstored.
7.1.9 How to interpret Critical Certificate Policy Extensions
Not set.
7.2 CRL Profile
CRLs issued by the CA conform to RFC5280, the profile of which are indicated in thetables below.
Table 7.2-1 CRL Profile (CA issued by Security Communication Root CA2)
Basic Fields

Settings

CriticalVersionVersion 2-

Signature Algorithm

sha256WithRSAEncryption-

IssuerCountry

C=JP-

Organization

O= SECOM Trust Systems CO.,LTD.

-

Common Name

CN= Set the common name of each-

Certificate Authority
This Update

Issued date and time of CRL-

Next Update

Date and time when the next CRL-

will be issued.
Up to 10 days after thisUpdate.
RevokedSerial Number

Certificates

Byte-for-bite identical value to theserialNumber

included

in

-

the

revoked certificate.
Revocation Date

Usually, the date and time the-revocation occurred.
Reason Code

Value specified in "7.2.2 CRL Entry-

Extensions"
Extension Fields

Settings

Critical

CRL Number

CRL Number

N

Authority Key Identifier

SHA-1 hash value of Authority

N

Public Key (160 bits)© 2018 SECOM Trust Systems Co., Ltd.
P-56

Organization Validation Certificate Policy Ver.1.23

Table 7.2-2 CRL Profile(CA issued by Security Communication Root CA1)
Basic Fields

Settings

CriticalVersionVersion 2-

Signature Algorithm

ecdsa-with-SHA384-

IssuerCountry

C=JP-

Organization

O= SECOM Trust Systems CO.,LTD.

-

Common Name

CN= Set the common name of each-

Certificate Authority
This Update

Issued date and time of CRL-

Next Update

Date and time when the next CRL-

will be issued.
Up to 10 days after thisUpdate
RevokedSerial Number

Byte-for-bite identical value to theCertificates

serialNumber

included

in

-

the

revoked certificate.
Revocation Date

Usually, the date and time the-revocation occurred.
Reason Code

Value specified in "7.2.2 CRL Entry-

Extensions"
Extension Fields

Settings

Critical

CRL Number

CRL Number

N

Authority Key Identifier

SHA-1 hash value of Authority

N

Public Key (160 bits)
7.2.1 Version Number(s)The CA applies CRL version 2.
7.2.2 CRL Entry Extensions
Table 7.2-2-1 CRL Extensions
ExtensionauthorityKeyIdentifier

Presence
Required

CriticalN

Description-© 2018 SECOM Trust Systems Co., Ltd.
P-57

Organization Validation Certificate Policy Ver.1.23

Contains an INTEGER (number)
CRLNumber

RequiredN

greater than or equal to 0 and less than2159.
This extension is not recommended for

IssuingDistributionPoint *Yfull and complete CRLs.
Full and complete CRLs are used in theCANot

Any other extension

Recommended--

Table 7.2-2-2 Revoked Certificates Component
Component

Presence

serialNumber

Required

revocationDate

Required

crlEntryExtensions*

Description
Byte-for-byte identical to the serialNumber contained in therevoked certificate.
Nomally the date and time revocation occurred. See below
this table for circumstances where backdating is permitted.
For requirements, see "Table 7.2-2-3 crlEntryExtensions
Component."

The CA SHOULD update the revocation date in a CRL entry when it is determined thatthe private key of the Certificate was compromised prior to the revocation date that isindicated in the CRL entry for that Certificate. Backdating the revocationDate field is
an exception to best practice described in RFC 5280 (Section 5.3.2); however, the Baseline
Requirements specify the use of the revocationDate field to support TLS
implementations that process the revocationDate field as the date when the Certificate
is first considered to be compromised.
Table 7.2-2-3 crlEntryExtensions Component
CRL Entry

Presence

Extension

Description
When present（OID 2.5.29.21）, not be marked criticaland indicate the most appropriate reason for revocation ofreasonCode*

the Certificate. However, be omitted if the CRL entry is
for a Certificate not technically capable of causing
issuance and either 1) the CRL entry is for Subscriber
Certificate subject to the Requirements revoked prior to© 2018 SECOM Trust Systems Co., Ltd.
P-58

Organization Validation Certificate Policy Ver.1.23

July 15, 2023 or 2) the reason for revocation(i.e.,reasonCode) is unspecified.
See the table of “CRLReasons” for the requirements.
Any other value

Not
Recommended-

Table 7.2-2-4 CRLReasons
RFC 5280
RFC 5280 reasonCode

reasonCode

Description

value
Represented by the omission of a reasonCode.
unspecified

0

However, be omitted if the CRL entry is for a
Subscriber Certificate subject to the Baseline
Requirements revoked prior to July 15, 2023.

keyCompromise

1

Indicate that it is known or suspected that the
Subscriber’s Private Key has been compromised.
Indicate that the Subject’s name or other Subject’s

affiliationChanged

3

Identity Information in the Certificate has changed,
but there is no cause to suspect that the Certificate’s
Private Key has been compromised.
Indicate that the Subscriber has requested a new
Certificate, the CA has reasonable evidence that thevalidation of domain authorization or control for any

superseded

4

FDQN or IP address in the Certificate should not be
relied upon, or the CA has revoked the Certificate forcompliance reasons such as the Certificate does notcomply with the Baseline Requirements or the CA's CP
or CPS.
Indicates that the website with the Certificate is shut
down prior to the expiration of the Certificate, or if the

cessationOfOperation

5 Subscriber no longer owns or controls the Domain
Name in the Certificate prior to the expiration of theCertificate.

certificateHold

6 MUST NOT be included if the CRL entry is for:© 2018 SECOM Trust Systems Co., Ltd.
P-59

Organization Validation Certificate Policy Ver.1.23

1) a Certificate subject to the Baseline Requirements,
2) a Certificate not subject to the Baseline
Requirements and was either:A) issued on-or-after 2020-09-30 orB) has a notBefore on-or-after 2020-09-30.
Indicates that there has been a subscriber-side
infraction that has not resulted in keyCompromise,
privilegeWithdrawn

9such as the Certificate Subscriber provided misleading
information in their Certificate Request or has notupheld their material obligations under the Subscriber
Agreement or Terms of Use.

The Subscriber Agreement, or an online resource referenced therein, must inform
Subscribers about the revocation reason options listed above and provide explanation
about when to choose each option. Tools that the CA provides to the Subscriber mustallow for these options to be easily specified when the Subscriber requests revocationof their Certificate, with the default value being that no revocation reason is provided(i.e. the default corresponds to the CRLReason “unspecified (0)” which results in noreasonCode extension being provided in the CRL).
The privilegeWithdrawn reasonCode should not be made available to the Subscriber
as a revocation reason option, because the use of this reasonCode is determined by the
CA and not the Subscriber.
When the CA obtains verifiable evidence of Key Compromise for a Certificate whose
CRL entry does not contain a reasonCode extension or has a reasonCode extension
with a non-keyCompromise reason, the CA should update the CRL entry to enter
keyCompromise as the CRLReason in the reasonCode extension.
In the CA, the following reasonCode shall be used.
keyCompromise (1)affiliationChanged (3)superseded (4)cessationOfOperation (5)privilegeWithdrawn (9)© 2018 SECOM Trust Systems Co., Ltd.
P-60

Organization Validation Certificate Policy Ver.1.23

7.3 OCSP Profile
The CA operates the OCSP responder in compliance with RFC5019 and 6960.
Effective 2020-09-30, if an OCSP response is for a Root CA or Subordinate CA
Certificate, including Cross Certificates, and that certificate has been revoked, thenthe revocationReason field within the RevokedInfo of the CertStatus MUST be present.
Effective 2020-09-30, the CRLReason indicated MUST contain a value permitted for
CRLs, as specified in the CP “Section 7.2.2 CRL Entry Extensions”.
7.3.1 Version Number(s)The CA uses OCSP Version 1.
7.3.2 OCSP Extensions
Refer to this CP “7.1 Certificate Profile”.
The singleExtensions of an OCSP response MUST NOT contain the reasonCode (OID
2.5.29.21) CRL entry extension.

© 2018 SECOM Trust Systems Co., Ltd.
P-61

Organization Validation Certificate Policy Ver.1.23

8. Compliance Audit and Other Assessments
Relevant provisions are stipulated in the CPS.
8.1 Frequency and Circumstances of Assessment
Relevant provisions are stipulated in the CPS.
8.2 Identity/Qualifications of Assessor
Relevant provisions are stipulated in the CPS.
8.3 Assessor’s Relationship to Assessed Entity
Relevant provisions are stipulated in the CPS.
8.4 Topics Covered by Assessment
The CA SHALL undergo an audit as appropriate in accordance with the WebTrust
Standards below:
・WebTrust for CAs
・WebTrust for CAs SSL Baseline with Network Security
・WebTrust Principles and Criteria for Certification Authorities - Network Security
8.5 Actions Taken as a Result of Deficiency
Relevant provisions are stipulated in the CPS.
8.6 Communication of Results
Relevant provisions are stipulated in the CPS.
8.7 Self-Audits
Relevant provisions are stipulated in the CPS.

© 2018 SECOM Trust Systems Co., Ltd.
P-62

Organization Validation Certificate Policy Ver.1.23

9. Other Business and Legal Matters
9.1 Fees
9.1.1 Fees for Issuing or Renewing Certificates
Stipulated separately in contracts.
9.1.2 Certificate Access Fee
No stipulation.
9.1.3 Expiration or Access Fee for Status Information
No stipulation.
9.1.4 Fees for Other Services
No stipulation.
9.1.5 Refund Policy
Stipulated separately in contracts.
9.2 Financial Responsibility
9.2.1 Insurance Coverage
SECOM Trust Systems shall maintain a sufficient financial resources for the operationand maintenance of the CA.
9.2.2 Other Assets
No stipulation.
9.2.3 End entity Insurance or Warranty coverage
No stipulation.
9.3 Confidentiality of Business Information
9.3.1 Scope of Confidential Information
Relevant provisions are stipulated in the CPS.

© 2018 SECOM Trust Systems Co., Ltd.
P-63

Organization Validation Certificate Policy Ver.1.23

9.3.2 Information Not Within the Scope of Confidential Information
Relevant provisions are stipulated in the CPS.
9.3.3 Responsibility to Protect Confidential Information
Relevant provisions are stipulated in the CPS.
9.4 Privacy of Personal Information
9.4.1 Personal Information Protection Plan
Relevant provisions are stipulated in the CPS.
9.4.2 Information Treated as Personal Information
Relevant provisions are stipulated in the CPS.
9.4.3 Information that is not considered Personal Information
Relevant provisions are stipulated in the CPS.
9.4.4 Responsibility for protecting Personal Information
Relevant provisions are stipulated in the CPS.
9.4.5 Notice and Consent regarding use of Personal Information
Relevant provisions are stipulated in the CPS.
9.4.6 Information Disclosure with Judicial or Administrative Procedures
Relevant provisions are stipulated in the CPS.
9.4.7 Other Information Disclosure Conditions
Relevant provisions are stipulated in the CPS.
9.5 Intellectual Property Rights
This CP includes copyright and is the property of SECOM Trust Systems.
This CP may be reproduced provided that the original document is properly referenced.
It is published under the Creative Commons license Attribution-NoDerivatives (CCBY-ND) 4.0.

© 2018 SECOM Trust Systems Co., Ltd.
P-64

Organization Validation Certificate Policy Ver.1.23

https://creativecommons.org/licenses/by-nd/4.0/
9.6 Representations and Warranties
9.6.1 CA Representations and Warranties
Secom Trust Systems provides authentication services including subscriber
examination, certificate registration, issuance, and revocation in compliance with thecontents stipulated in this CP and CPS, and ensure the reliability of authentication
work, including the reliability of CA private keys.
Except for the warranties set forth in this CP and CPS, SECOM Trust Systems makes
no warranties, explicitly or implied, or in any other way.
By issuing a Certificate, the CA makes the certificate warranties listed herein to thefollowing Certificate Beneficiaries:
1. The Subscriber that is a party to the Subscriber Agreement or Terms of Use for
the Certificate;
2. All Application Software Suppliers with whom the Root CA has entered into acontract for inclusion of its Root Certificate in software distributed by such
Application Software Supplier; and3. All Relying Parties who reasonably rely on a Valid Certificate. The CA represents
and warrants to the Certificate Beneficiaries that, during the period when theCertificate is valid, the CA has complied with Baseline Requirements and its
Certificate Policy and/or Certification Practice Statement in issuing andmanaging the Certificate.
The Certificate Warranties specifically include, but are not limited to, the following:
1. Right to Use Domain Name or IP Address: That, at the time of issuance, the CA
i. implemented a procedure for verifying that the Applicant either had the right touse, or had control of, the Domain Name(s) and IP address(es) listed in theCertificate’s subject field and subjectAltName extension (or, only in the case of
Domain Names, was delegated such right or control by someone who had suchright to use or control);ii. followed the procedure when issuing the Certificate; andiii. accurately described the procedure in the CA’s Certificate Policy and/or
Certification Practice Statement;
2. Authorization for Certificate: That, at the time of issuance, the CA
i. implemented a procedure for verifying that the Subject authorized the issuance© 2018 SECOM Trust Systems Co., Ltd.
P-65

Organization Validation Certificate Policy Ver.1.23of the Certificate and that the Applicant Representative is authorized to request
the Certificate on behalf of the Subject;ii. followed the procedure when issuing the Certificate; andiii. accurately described the procedure in the CA’s Certificate Policy and/or
Certification Practice Statement;
3. Accuracy of Information: That, at the time of issuance, the CA
i. implemented a procedure for verifying the accuracy of all of the information
contained

intheCertificate

(with

the

exceptionofthesubject:organizationalUnitName attribute);
ii. followed the procedure when issuing the Certificate; andiii. accurately described the procedure in the CA’s Certificate Policy and/or
Certification Practice Statement;
4. No Misleading Information: That, at the time of issuance, the CA
i. implemented a procedure for reducing the likelihood that the information
contained in the Certificate’s subject:organizationalUnitName attribute would be
misleading;ii. followed the procedure when issuing the Certificate; andiii. accurately described the procedure in the CA’s Certificate Policy and/or
Certification Practice Statement;
5. Identity of Applicant: That, if the Certificate contains Subject Identity
Information, the CA
i. implemented a procedure to verify the identity of the Applicant in accordancewith Baseline Requirements Section 3.2 and Section 7.1.4.2.2;
ii. followed the procedure when issuing the Certificate; andiii. accurately described the procedure in the CA’s Certificate Policy and/or
Certification Practice Statement;
6. Subscriber Agreement: That, if the CA and Subscriber are not Affiliated, theSubscriber and the CA are parties to a legally valid and enforceable Subscriber
Agreement that satisfies Baseline Requirements, or, if the CA and Subscriber are
the same entity or are Affiliated, the Applicant Representative acknowledged theTerms of Use;
7. Status: That the CA maintains a 24 x 7 publicly-accessible Repository with current
information regarding the status (valid or revoked) of all unexpired Certificates;
and
8. Revocation: That the CA will revoke the Certificate for any of the reasons specified
in Baseline Requirements.
© 2018 SECOM Trust Systems Co., Ltd.
P-66

Organization Validation Certificate Policy Ver.1.23

The Root CA SHALL be responsible for the performance and warranties of theSubordinate CA, for the Subordinate CA’s compliance with Baseline Requirements,and for all liabilities and indemnification obligations of the Subordinate CA under
Baseline Requirements, as if the Root CA were the Subordinate CA issuing theCertificates9.6.2 RA Representations and Warranties
Same as this CP "9.6.1 CA Representation and Warranties".
9.6.3 Subscriber Representations and Warranties
The CA SHALL require, as part of the Subscriber Agreement or Terms of Use, that the
Applicant make the commitments and warranties in this section for the benefit of the
CA and the Certificate Beneficiaries.
Prior to the issuance of a Certificate, the CA SHALL obtain, for the express benefit of
the CA and the Certificate Beneficiaries, either:
1. The Applicant’s agreement to the Subscriber Agreement with the CA, or
2. The Applicant’s acknowledgement of the Terms of Use.
The CA SHALL implement a process to ensure that each Subscriber Agreement or
Terms of Use is legally enforceable against the Applicant. In either case, theAgreement MUST apply to the Certificate to be issued pursuant to the certificate
request. The CA MAY use an electronic or "click-through" Agreement provided that
the CA has determined that such agreements are legally enforceable. A separate
Agreement MAY be used for each certificate request, or a single Agreement MAY be
used to cover multiple future certificate requests and the resulting Certificates, so longas each Certificate that the CA issues to the Applicant is clearly covered by that
Subscriber Agreement or Terms of Use.
The Subscriber Agreement or Terms of Use MUST contain provisions imposing on the
Applicant itself (or made by the Applicant on behalf of its principal or agent under asubcontractor or hosting service relationship) the following obligations andwarranties:
1. Accuracy of Information: An obligation and warranty to provide accurate andcomplete information at all times to the CA, both in the certificate request andas otherwise requested by the CA in connection with the issuance of theCertificate(s) to be supplied by the CA;
2. Protection of Private Key: An obligation and warranty by the Applicant to take all© 2018 SECOM Trust Systems Co., Ltd.
P-67

Organization Validation Certificate Policy Ver.1.23

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: For TLS server certificate, an obligation and warranty to install
the Certificate only on servers that are accessible at the subjectAltName(s) listed
in the Certificate, and to use the Certificate solely in compliance with all applicablelaws and solely in accordance with the Subscriber Agreement or Terms of Use;
5. Reporting and Revocation: An obligation and warranty to:a. promptly request revocation of the Certificate, and cease using it and its
associated Private Key, if there is any actual or suspected misuse or compromiseof the Subscriber’s Private Key associated with the Public Key included in theCertificate, andb. 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 alluse of the Private Key corresponding to the Public Key included in the Certificate
upon revocation of that Certificate for reasons of Key Compromise.
7. Responsiveness: An obligation to respond to the CA’s instructions concerning Key
Compromise or Certificate misuse within a specified time period.
8. Acknowledgment and Acceptance: An acknowledgment and acceptance that the CA
is entitled to revoke the certificate immediately if the Applicant were to violate theterms of the Subscriber Agreement or Terms of Use or if revocation is required by
the CA’s CP, CPS, or Baseline Requirements.
9.6.4 Relying Party Representations and Warranties
The Relying Party of the services of the CA has the following obligations:.・ Trust the certificate issued by the CA and use the certificate only for the purposes
specified by this CA in this CP and CPS.
・ When trying to trust a certificate, make sure that the certificate has not been
revoked by the CRL or OCSP responder in the repository.
・ When trying to trust a certificate, check the validity period of the certificate andconfirm that it is within the validity period.
・ When trying to trust a certificate issued by this CA, make sure that the certificate© 2018 SECOM Trust Systems Co., Ltd.
P-68

Organization Validation Certificate Policy Ver.1.23

can be signed and verified by the CA's certificate.
・ Agree to be responsible as a Relying Party as specified in this CP and CPS whentrying to trust and use the CA's certificate.
9.6.5 Representations and Warranties of Other Participants
No stipulation.
9.7 Disclaimer of Warranties
The CA is not liable for any direct, special, incidental or consequential damages arisingin connection with the warranties stipulated in "9.6.1 CA Representations andWarranties" and "9.6.2 RA Representations and Warranties" hereof, or for lostearnings, loss of data, or any other indirect or consequential damages.
9.8 Limitations of Liability
In this CP, the CA shall not be liable for in the following cases.
・ any damage arising from unlawful conduct, unauthorized use, negligence or any
other cause not attributable to the CA;・ all liability in any case if the confirmed information error is the result of theapplicant's fraud or willful misconduct.
・ any damage attributable to the failure of a Subscriber to perform its obligations;・ any damage attributable to a Subscriber system;
・ damages attributable to the defect or malfunction or any other behavior of the
Subscriber environment (hardware or software);・ damages caused by information published in a Certificate, a CRL or on the OCSP
responder due to the reasons not attributable to SECOM Trust Systems;
・ any damage incurred in an outage of the normal communication due to reasons not
attributable to SECOM Trust Systems;
・ any damage arising in connection with the use of a Certificate, includingtransaction debts;
・ any damage caused by the Delegated Third Party’s failure to fulfill its service
provision obligations, such as the termination of service provision by them;・ any damages attributable to improvement, beyond expectations at this point in
time, in hardware or software type of cryptographic algorithm decoding skills; and・ any damage attributable to the suspension of the CA's operations due to force
majeure, including, but not limited to, natural disasters, earthquakes, volcanic
eruptions, fires, tsunami, floods, lightning strikes, wars, civil commotion and© 2018 SECOM Trust Systems Co., Ltd.
P-69

Organization Validation Certificate Policy Ver.1.23

terrorism.
9.9 Indemnities
Compensation for the certificate issued by the CA shall be stipulated separately.
9.10 Term and Termination
9.10.1 Term
This CP goes into effect upon approval by this Committee.
9.10.2 Termination
This CP loses effect as of the termination hereof by the CA.
9.10.3 Effect of Termination and Survival
Even in the event of termination of the use of a Certificate by a Subscriber or thetermination of a service provided by the Delegated Third Party, or the CA closes its
business, provisions that should remain in effect, due to the nature thereof, shallsurvive any such termination, regardless of the reasons therefor, and remain in fullforce and effect with respect to any Subscriber and the CA.
9.11 Individual Notices and Communications with Participants
The CA provides the necessary notices to the Delegated Third Party, then the
Delegated Third Party provides the necessary notice to Subscribers and Relying
Parties through its website, e-mail or in other written forms.
9.12 Amendments
9.12.1 Procedure for Amendment
This CP shall be revised by the CA as appropriate and goes into effect upon approvalby this Committee.
9.12.2 Notification Method and Timing
Whenever this CP is modified, the prompt publication of the modified CP shall bedeemed as the notification thereof to the participants.

© 2018 SECOM Trust Systems Co., Ltd.
P-70

Organization Validation Certificate Policy Ver.1.23

9.12.3 Circumstances under Which OID Must Be Changed
OID shall be changed if the Certification Service Improvement Committee determinesthat it is necessary.
9.13 Dispute Resolution Procedures
A party seeking to file a lawsuit, request arbitration or take any other legal action
against the CA for the resolution of a dispute relating to a Certificate issued by the CA,
said party shall notify the CA to this effect in advance. As regards the location for
arbitration and court proceedings, a dispute settlement institution located within
Tokyo shall have exclusive jurisdiction.
9.14 Governing Law
The laws of Japan will apply to any dispute concerning the interpretation or validityof this CP and the CPS, as well as the use of the Certificates.
9.15 Compliance with Applicable Law
The CA shall handle cryptographic hardware and software in compliance with relevant
export regulations of Japan.
9.16 Miscellaneous Provisions
9.16.1 Entire Agreement
SECOM Trust Systems comprehensively stipulates the obligations of Subscribers andRelying Parties and other relevant matters in this CP, the Service Terms and CPS, forprovision of the services. Any agreement otherwise, whether oral or written, shall haveno effect.
9.16.2 Assignment
When assigning the services to a third party, SECOM Trust Systems may assign its
responsibilities and other obligations specified in this CP, the Service Terms and CPS.
9.16.3 Severability
Even if any provision of this CP, the Service Terms and CPS is deemed invalid, allother provisions stipulated therein shall remain in full force and effect.
In the event of a conflict between Baseline Requirements and a law, regulation or
government order (hereinafter 'Law') of any jurisdiction in which a CA operates or© 2018 SECOM Trust Systems Co., Ltd.
P-71

Organization Validation Certificate Policy Ver.1.23

issues certificates, a CA MAY modify any conflicting Baseline Requirement to theminimum extent necessary to make the requirement valid and legal in the jurisdiction.
This applies only to operations or certificate issuances that are subject to that Law. In
such event, the CA SHALL immediately (and prior to issuing a certificate under themodified requirement) include in Section 9.16.3 of the CA’s CPS a detailed reference
to the Law requiring a modification of Baseline Requirements under this section, andthe specific modification to Baseline Requirements implemented by the CA.
The CA MUST also (prior to issuing a certificate under the modified requirement)
notify the CA/Browser Forum of the relevant information newly added to its CPS bysending a message to questions@cabforum.org and receiving confirmation that it has
been posted to the Public Mailing List and is indexed in the Public Mail Archives
available at https://cabforum.org/pipermail/public/ (or such other email addresses andlinks as the Forum may designate), so that the CA/Browser Forum may consider
possible revisions to Baseline Requirements accordingly.
Any modification to CA practice enabled under this section MUST be discontinued if
and when the Law no longer applies, or Baseline Requirements are modified to makeit possible to comply with both Baseline Requirements and the Law simultaneously.
An appropriate change in practice, modification to the CA’s CPS and a notice to the
CA/Browser Forum, as outlined above, MUST be made within 90 days.
9.16.4 Enforcement
Disputes regarding this service shall be governed by the Tokyo District Court, andSECOM Trust Systems may request the parties for compensation and attorney’s feesfor disputes arising from the contractual provisions of the respective regulatory
documents, damages, losses and costs related to the parties' actions.
9.16.5 Irresistible ForceSECOM Trust Systems shall not be liable for any damages caused by natural disasters,
earthquakes, eruptions, fires, tsunamis, floods, lightning strikes, disturbances,terrorism, or any other force majeure, whether or not foreseeable. If it becomes
impossible to provide this CA, SECOM Trust Systems may suspend this CA until thesituation stops.
9.17 Other Provisions
No stipulation© 2018 SECOM Trust Systems Co., Ltd.
P-72