SECOM Passport for Web EV Certification Authority Certificate Policy
Version2.10

April 15, 2015
SECOM Trust Systems Co., Ltd.

Version History
Version Number	Date	Description	
1.00	2007/6/29	Publication of the first version	
1.10	2008/9/19	Compliance with EV Guidelines Ver1.1	
1.20	2008/12/18	Incorporation of provisions on 2048-bit keys	
1.30	2010/11/18	Incorporation of provisions on OCSP	
1.40	2012/11/9	Addition of SubjectAltName to certificate profile 
Deletion of provisions on 1024-bit keys
Overall revision of the language and format	
2.00	2014/8/1	Major version upgrade
Addition of SECOM Passport for Web EV2.0CA	
2.10	2015/4/15	Addition of language on CAA	

1. Introduction
1.1 Overview
1.2 Document Name and Identification
1.3 PKI Participants
1.3.1 Certification Authority
1.3.1.1 IA
1.3.1.2 RA
1.3.2 Subscriber
1.3.3 Relying Party
1.4 Certificate Usage
1.4.1 Appropriate Certificate Uses
1.4.2 Prohibited Certificate Uses
1.5 Policy Administration
1.5.1 Organization Administering Documents
1.5.2 Contact Information
1.5.3 Party Determining Policy Suitability
1.5.4 Approval Procedure
1.6 Definitions and Acronyms
2. Publication and Repository Responsibilities
2.1 Repository
2.2 Publication of Certificate Information
2.3 Timing or Frequency of Publication
2.4 Access Controls on Repository
3. Identification and Authentication
3.1 Naming
3.1.1 Types of Names
3.1.2 Need for Names to Be Meaningful
3.1.3 Anonymity or Pseudonymity of Subscribers
3.1.4 Rules for Interpreting Various Name Formats
3.1.5 Uniqueness of Names
3.1.6 Recognition, Authentication and Roles of Trademarks
3.2 Initial Identity Validation
3.2.1 Method of Proving Possession of Private Key
3.2.2 Authentication of Organization Identity
3.2.3 Authentication of Individual Identity
3.2.4 Unverified Subscriber Information
3.2.5 Verification of Legitimacy of Authority
3.2.6 Criteria for Interoperation
3.3 Identity Verification and Authentication for Re-key Requests
3.3.1 Identity Verification and Authentication for Routine Re-key
3.3.2 Identity Verification and Authentication for Re-key after Revocation of Certificates
4. Certificate Life-Cycle Operational Requirements
4.1 Certificate Applications
4.1.1 Entities Who May Apply for Certificates
4.1.2 Application Procedure and Responsibilities
4.2 Certificate Application Procedure
4.2.1 Identity Verification and Authentication
4.2.2 Approval or Rejection of Certificate Applications
4.2.3 Certificate Application Processing Time
4.3 Certificate Issuance
4.3.1 Certificate Issuance Procedure
4.3.2 Notice to Subscribers of Certificate Issuance
4.4 Confirmation of Certificate Acceptance
4.4.1 Procedure for Confirmation of Certificate Acceptance
4.4.2 Publication of Certificates by Certification Authorities
4.4.3 Notice to Other Entities of Certificate Issuance by Certification Authorities
4.5 Key Pair and Certificate Usage
4.5.1 Subscriber Private Key and Certificate Usage
4.5.2 Relying Party Public Key and Certificate Usage
4.6 Certificate Renewal
4.6.1 Circumstances for Certificate Renewal
4.6.2 Entities Who May Request Certificate Renewal
4.6.3 Processing of Certificate Renewal Requests
4.6.4 Notice to Subscribers of New Certificate Issuance
4.6.5 Procedures for Confirmation of Renewed Certificate Acceptance
4.6.6 Publication of Renewed Certificates by Certification Authorities
4.6.7 Notice to Other Entities of Certificate Issuance by Certification Authorities
4.7 Certificate Renewal Requiring Re-key
4.7.1 Circumstances for Renewal
4.7.2 Entities Who May Request New Certificates
4.7.3 Processing of Renewal Requests
4.7.4 Notice to Subscribers of New Certificate
4.7.5 Procedures for Confirmation of Re-keyed Certificate Acceptance
4.7.6 Publication of Re-keyed Certificates by Certification Authorities
4.7.7 Notice to Other Entities of Certificate Issuance by Certification Authorities
4.8 Certificate Modification
4.8.1 Circumstances for Certificate Modification
4.8.2 Entities Who May Request Certificate Modification
4.8.3 Processing of Modification Requests
4.8.4 Notice to Subscribers of New Certificate Issuance
4.8.5 Procedure for Confirmation of Modified Certificate Acceptance
4.8.6 Publication of Modified Certificates by Certification Authorities
4.8.7 Notice to Other Entities of Certificate Issuance by Certification Authorities
4.9 Certificate Revocation and Suspension
4.9.1 Circumstances for Certificate Revocation
4.9.2 Entities Who May Request Certificate Revocation
4.9.3 Procedure for Revocation Requests
4.9.4 Revocation Request Grace Period
4.9.5 Period within Which Certification Authorities Must Process Revocation Requests
4.9.6 Requirement to Check Revocation Status
4.9.7 Publication Frequency of Certificate Revocation Lists
4.9.8 Maximum Delay in Publication of Certificate Revocation Lists
4.9.9 Online Verification of Revocation & Status Information
4.9.10 Requirements for Online Verification of Revocation & Status Information
4.9.11 Availability of Other Forms of Revocation Information
4.9.12 Special Requirements on Key Compromise
4.9.13 Circumstances for Certificate Suspension
4.9.14 Entities Who May Request Certificate Suspension
4.9.15 Procedure for Suspension Requests
4.9.16 Duration of Suspension
4.10 Certificate Status Verification Services
4.10.1 Operational Features
4.10.2 Service Availability
4.10.3 Optional Specifications
4.11 Termination of Subscription (Registration)
4.12 Key Escrow and Key Recovery
4.12.1 Key Escrow and Key Recovery Policy and Practice
4.12.2 Session Key Encapsulation and Key Recovery Policy and Practice
5. Facility, Management and Operational Controls
5.1 Physical Controls
5.1.1 Site Location and Construction
5.1.2 Physical Access
5.1.3 Power and Air Conditioning
5.1.4 Flood Control
5.1.5 Fire Prevention
5.1.6 Media Storage
5.1.7 Waste Disposal
5.1.8 Off-site Backup
5.2 Procedural Controls
5.2.1 Trusted Roles
5.2.2 Number of Persons Required per Task
5.2.3 Identity Verification and Authentication for Each Role
5.2.4 Roles Requiring Separation of Duties
5.3 Personnel Controls
5.3.1 Qualifications, Experience, and Clearance Requirements
5.3.2 Background Check
5.3.3 Training Requirements
5.3.4 Retraining Frequency and Requirements
5.3.5 Job Rotation Frequency and Sequence
5.3.6 Sanctions for Unauthorized Actions
5.3.7 Independent Contractor Requirements
5.3.8 Documentation Supplied to Personnel
5.4 Audit Logging Procedures
5.4.1 Types of Events Recorded
5.4.2 Frequency of Processing Audit Logs
5.4.3 Retention Period for Audit Logs
5.4.4 Protection of Audit Logs
5.4.5 Audit Log Backup Procedure
5.4.6 Audit Log Collection System
5.4.7 Notice to Event-causing Entity
5.4.8 Vulnerability Assessments
5.5 Records Archival
5.5.1 Types of Archives
5.5.2 Archive Retention Period
5.5.3 Archive Protection
5.5.4 Archive Backup Procedure
5.5.5 Requirements for Time-stamping Records
5.5.6 Archive Collection System
5.5.7 Archive Verification Procedure
5.6 Key Changeover
5.7 Compromise and Disaster Recovery
5.7.1 Accident, Incident and Compromise Recovery Procedures
5.7.2 Hardware, Software or Data Recovery Procedure
5.7.3 Compromised Private Key Recovery Procedure
5.7.4 Post-Disaster Business Continuity
5.8 Termination of Certification Authority or Registration Authority
6. Technical Security Controls
6.1 Key Pair Generation and Installation
6.1.1 Key Pair Generation
6.1.2 Private Key Delivery to Subscribers
6.1.3 Public Key Delivery to Certification Authorities
6.1.4 CA Public Key Delivery to Relying Parties
6.1.5 Key Sizes
6.1.6 Parameter Generation and Quality Check of Public Keys
6.1.7 Key Usage
6.2 Private Key Protection and Cryptographic Module Engineering Controls
6.2.1 Cryptographic Module Standards and Controls
6.2.2 Private Key Multi-Person Control
6.2.3 Private Key Escrow
6.2.4 Private Key Backup
6.2.5 Private Key Archival
6.2.6 Private Key Transfer to or from a Cryptographic Module
6.2.7 Private Key Storage on Cryptographic Module
6.2.8 Method of Activating Private Key
6.2.9 Method of Deactivating Private Key
6.2.10 Method of Destroying Private Key
6.2.11 Cryptographic Module Rating
6.3 Other Key Pair Controls
6.3.1 Public Key Archival
6.3.2 Validity Period of Private Key and Public Key
6.4 Activation data
6.4.1 Activation Data Generation and Installation
6.4.2 Activation Data Protection
6.4.3 Other Aspects of Activation Data to Be Considered
6.5 Computer Security Controls
6.5.1 Technical Requirements for Computer Security
6.5.2 Computer Security Assessment
6.6 Life Cycle Security Controls
6.6.1 System Development Controls
6.6.2 Security Management Controls
6.6.3 Life Cycle Security Controls
6.7 Network Security Controls
6.8 Time-stamping
7. Certificate, Certificate Revocation List and OCSP Server Certificate Profiles
7.1 Certificate Profiles
7.2 CRL Profiles
7.3 OCSP Profile
7.3.1 Version Number
7.3.2 OCSP Extension
8. Compliance Audit and Other Assessments
8.1 Frequency of Audits
8.2 Auditor Identity and Qualifications
8.3 Relationship between Auditor and Audited Department
8.4 Matters Audited
8.5 Measures Taken for Inadequacies
8.6 Disclosure of Audit Results
9. Other Business and Legal Matters
9.1 Fees
9.2 Financial Responsibility
9.3 Confidentiality of Business Information
9.3.1 Scope of Confidential Information
9.3.2 Information outside the Scope of Confidential Information
9.3.3 Responsibility to Protect Confidential Information
9.4 Protection of Personal Information
9.5 Intellectual Property Rights
9.6 Representations and Warranties
9.6.1 Certification Authority Representations and Warranties
9.6.1.1 IA Representations and Warranties
9.6.1.2 RA Representations and Warranties
9.6.2 Subscriber Representations and Warranties
9.6.3 Relying Party Representations and Warranties
9.6.4 Other Participant Representations and Warranties
9.7 Disclaimer of Warranties
9.8 Limitation of Liability
9.9 Indemnities
9.10 Term and Termination
9.10.1 Term
9.10.2 Termination
9.10.3 Effect of Termination and Survival
9.11 Individual Notices and Communication among Participants
9.12 Revisions
9.12.1 Revision Procedure
9.12.2 Notification Method and Timing
9.12.3 Circumstances Requiring Change of Object Identifier
9.13 Dispute Resolution Procedures
9.14 Governing Law
9.15 Compliance with Applicable Laws
9.16 Miscellaneous Provisions
9.16.1 Entire Agreement
9.16.2 Assignment
9.16.3 Severability
9.16.4 Enforcement
9.17 Other Provisions

1. Introduction
1.1 Overview
Secom Passport for Web EV Certification Authority Certificate Policy (hereinafter "this CP") defines the policy on EV SSL certificates (hereinafter "Certificate(s)") issued by SECOM Passport for Web EV CA and SECOM Passport for Web EV 2.0 CA (hereinafter collectively referred to as "the CA" in the singular form), which are operated 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 and maintenance of the CA are stipulated in the SECOM Passport for Web EV Certification Practice Statement (hereinafter "CPS").
SECOM Passport for Web EV CA has an active-passive mutual authentication certificate issued by Security Communication EV RootCA1, and SECOM Passport for Web EV 2.0 CA has an active-passive mutual authentication certificate issued by Security Communication RootCA2.
Certificates issued by the CA shall be valid for one (1) year or two (2) years, as the case may be.
Certificates issued by the CA are used for server authentication and encryption of information in the communication pathway. The parties regarding whom Certificates may be issued are set forth in the SECOM Passport for Web EV Service Terms (hereinafter "Service Terms").
A party seeking to have the CA issue a Certificate must review and check its intended use against this CP, the Service Terms and the CPS, and agree to all three prior to the issuance of a Certificate.

The CA is in compliance with the EVSSL Certificate Guidelines and the Baseline Requirements of the CA/ Browser Forum disclosed at https://www.cabforum.org/. Further, the CA incorporates the applicable requirements of the EVSSL Certificate Guidelines and the Baseline Requirements (either through direct incorporation or by reference) in all of its contracts with subordinate CAs, RAs and subcontracting RAs regarding EV SSL certificates and the issuance and/or maintenance thereof.

In the event of a conflict between this CP and the Service Terms or the CPS, the order of precedence in the application thereof shall be the Service Terms, this CP and the CPS. Should there be a separate contract or the like between SECOM Trust Systems and an organization, a group or any other party with which it has a contractual relationship, said contract or the like takes precedence over the Service Terms, this CP and the CPS.

This CP shall be revised as necessary in order to reflect any technical or operational development or improvement pertaining to the CA.

This CP is in compliance with RFC3647 "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework" advocated by the IETF as a certification practices framework.

1.2 Document Name and Identification
The official name of this CP is "SECOM Passport for Web EV Certification Authority Certificate Policy". A registered and unique object identifier (hereinafter "OID") is assigned to this CP. The OID of this CP and that of the CPS, which is referenced herein, are as follows:

CP/CPS	OID	
SECOM Passport for Web EV Certification Authority Certificate Policy	1.2.392.200091.100.721.1	
SECOM Passport for Web EV Certification Practice Statement	1.2.392.200091.100.731.1	

1.3 PKI Participants
1.3.1 Certification Authority
A CA (Certification Authority) comprises an IA and a RA. SECOM Trust Systems is the operator of a CA that is operated on a digital certification infrastructure.

1.3.1.1 IA
An IA mainly issues or revokes Certificates, publishes CRLs (Certificate Revocation Lists), provides information on Certificate status using the OCSP server, and maintains and manages the repository. SECOM Trust Systems operates the IA of a CA that is operated on a digital certification infrastructure.

1.3.1.2 RA
An RA mainly verifies the existence of subscribers requesting the issuance or revocation of Certificates, conducts assessment to verify subscriber identity, and performs registration work for the issuance or revocation of Certificates.

1.3.2 Subscriber
A subscriber shall be a corporation or any other organization requesting a Certificate from SECOM Trust Systems.

1.3.3 Relying Party
A relying party signifies an individual, a corporation or any other organization that verifies the identity of a subscriber and the validity of a public key. It also signifies an individual, corporation or any other organization that trusts and uses a CP and a CPS for the purpose of conducting encrypted communication with a Web server owned by a subscriber using said public key.

1.4 Certificate Usage
1.4.1 Appropriate Certificate Uses
Certificates issued by the CA may be used for server authentication and encryption of information in the communication pathway.

1.4.2 Prohibited Certificate Uses
Certificates issued by the CA may not be used for purposes other than server authentication and encryption of information in the communication pathway.

1.5 Policy Administration
1.5.1 Organization Administering Documents
SECOM Trust Systems maintains and manages this CP.

1.5.2 Contact Information
Inquiries concerning this CP and requests concerning certificates (issuance, renewal, revocation) as well as complaints related thereto (usage and verification problems, phishing by subscribers) should be directed to: 
CA Support Center, SECOM Trust Systems Co., Ltd.
Address: 1-5-1 Jingumae, Shibuya-ku, Tokyo 150-0001
E-mail address:  ra-support@secom.co.jp

Requests for the issuance or revocation of Certificates and the reporting of problems pertaining to Certificates are accepted 24x7. 
Responses to out-of-hours (18:00 to 09:00 of the following day) inquiries may be delayed until the following business day or later with the exception of emergencies.

1.5.3 Party Determining Policy Suitability
The Certification Services Improvement Committee determines the suitability of the contents of this CP.

1.5.4 Approval Procedure
This CP is prepared and revised by SECOM Trust Systems and goes into effect upon approval by the Certification Services Improvement Committee.

1.6 Definitions and Acronyms
Alphabetical order
Archive
Information obtained for the purpose of preserving history for legal or other reasons.

Escrow
To deposit with (entrust to) a third party.

Key Pair
A pair of keys comprising a private key and a public key in public key cryptography.

Audit Logs
Behavioral, access and other history pertaining to a certification authority system which are recorded to check for access to and unauthorized operation of the certification authority system

Public Key
A key comprising a key pair used in public key cryptography, which corresponds to a private key and is disclosed to the communication destination.

Private Key
A key comprising a key pair used in public key cryptography, which corresponds to a public key and is owned only by the relevant subscriber.

Digital Certificate
Electronic data certifying that a public key is owned by the party specified, the validity of which is guaranteed by the digital signature of the relevant CA that is affixed thereto.

Repository
A database for storing and providing access to CA certificates, CRLs and the like.

A ~ Z
CA (Certification Authority) consists of IA and RA.

An entity that mainly issues, renews and revokes Certificates, generates and protects CA’s private keys, and registers subscribers.

CAA (Certificate Authority Authorization)
A function, which is associated with the authority to use a domain, of preventing the erroneous issuance of a Certificate by an unintended certification authority by indicating, in the DNS record, information on the certification authority or authorities that may issue Certificates for a specific domain.

CA/Browser Forum
A non-profit organization comprised of certification authorities and Internet browser vendors, which is working to standardize Certificates by defining the requirements therefor.

CP (Certificate Policy)
A document providing for matters pertaining to Certificates issued by a CA, including Certificate types, usage and application procedure.

CPS (Certification Practices Statement)
A document providing for the operation of a CA, including various procedures and security standards pertaining to the operation of a CA.

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.

EV SSL Certificate
"Extended Validation Certificates (EV Certificates)" being the collective term used to refer to digital certificates issued in accordance with the screening criteria set forth in the new guidelines published by the non-profit organization CA/Browser Forum, "EV SSL Certificates" are those issued in particular for Web servers.

FIPS140-2
A security accreditation standard for cryptographic modules established by the U.S. NIST (National Institute of Standards and Technology), which defines four levels of security with 1 being the lowest and 4 being the highest.

HSM (Hardware Security Module)
A tamper resistant encryption device used to ensure security mainly with regard to the generation, storage and use of private keys.

IA (Issuing Authority)
An entity which, of the duties of a CA, mainly handles the issuance, renewal and revocation of Certificates, generation and protection of a CA’s private keys, and the maintenance and management of repositories.

OID (Object Identifier)
A globally unique number constituting a framework for maintaining and managing the uniqueness of the mutual connectivity, services and other aspects of networks, which number is registered with an international registration authority. 

OCSP (Online Certificate Status Protocol)
A protocol for real-time provision of information on Certificate status.

PKI (Public Key Infrastructure)
An infrastructure, which employs encryption technology known as public key cryptography, for realizing security technologies such as digital signature, encryption and authentication.

RA (Registration Authority)
An entity which, of the duties of a CA, mainly performs the assessment of application information and registration of information necessary for the issuance of Certificates, and additionally makes Certificate requests to a CA on behalf of subscribers.

RFC3647 (Request for Comments 3647)
A document defining the framework for CP and CPS published by the IETF (The Internet Engineering Task Force), a group which establishes technical standards pertaining to the Internet.

RSA
One of the most typical encryption technologies widely used in public key cryptography.

SHA-1 (Secure Hash Algorithm 1)
A hash function used in digital signature. A hash function is a computation technique for generating a fixed-length character string from a given text. The hash length is 160 bits. Comparing the hash value on the transmitting end and that on the receiving end of data renders it possible to detect alterations in the original text during transmission.

SHA-256 (Secure Hash Algorithm 256)
A hash function used in digital signature. A hash function is a computation technique for generating a fixed-length character string from a given text. The hash length is 256 bits. Comparing the hash value on the transmitting end and that on the receiving end of data renders it possible to detect alterations in the original text during transmission.

WebTrust for CA
Criteria on internal controls and a certification framework based thereon established by the American Institute of Certified Public Accountants (AICPA) and the Canadian Institute of Chartered Accountants (CICA) for certification authorities with regard to reliability, security of electronic transactions, and other relevant matters.

WebTrust for EV
Audit criteria established by the American Institute of Certified Public Accountants (AICPA) and the Canadian Institute of Chartered Accountants (CICA) with respect to the rules that certification authorities have in place for the verification work required to issue EV SSL certificates and on the certificates themselves.

WebTrust for Baseline Requirements
Audit criteria established by the American Institute of Certified Public Accountants (AICPA) and the Canadian Institute of Chartered Accountants (CICA) with respect to the rules that certification authorities have in place for the verification work required to issue SSL certificates and on the certificates themselves.

2. Publication and Repository Responsibilities
2.1 Repository
SECOM Trust Systems maintains and manages a repository in order to allow subscribers and relying parties to access CRL information 24x7. Further, it manages an OCSP server to allow subscribers and relying parties to check online the status of Certificates 24x7. However, the repository and the OCSP server may not be available temporarily at times due to maintenance or for any other reason.

2.2 Publication of Certificate Information
SECOM Trust Systems stores the following information in the repository to allow the online access thereof by subscribers and relying parties:
・ CRL
・ The CA Certificates
・ The newest versions of this CP and the CPS
・ Other information pertaining to Certificates issued by the CA
SECOM Trust Systems will make the information on Certificate status available online to subscribers and relying parties via the OCSP server.

2.3 Timing or Frequency of Publication
This CP and the CPS are published in the repository each time a change is made. A CRL, which includes information on revocation processed in accordance with this CP, is published in the repository each time it is issued. Certificates that have expired are deleted from the CRL.

2.4 Access Controls on Repository
Subscribers and relying parties may access the repository at any time. The protocols used to access the repository shall be HTTP (Hyper Text Transfer Protocol) and HTTPS (HTTP with the added function of data encryption using SSL). Information in the repository may be accessed via any commonly used Web interface.

3. Identification and Authentication
3.1 Naming
3.1.1 Types of Names 
The name of the CA, which is indicated in a Certificate as the issuer thereof, and the name of the subscriber, to whom the Certificate pertains, are established in accordance with the X.500 identifier (DN: 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 corporation or organization other than a corporation.
3. "Organizational Unit Name" (OU) shall be an optional field. The OU field is used to differentiate among the various departments (e.g., human resources, marketing and development departments) and other groups within an organization.
4. "Common Name" (CN) shall be the name of the host on the Web server in which the Certificate issued by the CA is to be installed.

3.1.2 Need for Names to Be Meaningful
The usefulness of the Common Name in a Certificate issued by the CA shall be that it is the name of the host used in the DNS of the Web server in which the relevant subscriber plans to install said Certificate.

3.1.3 Anonymity or Pseudonymity of Subscribers
An assumed or a fictitious name may not be registered as the Organization Name or the Common Name for a Certificate issued by the CA.

3.1.4 Rules for Interpreting Various Name Formats
Rules concerning the interpretation of various name forms are governed by the Distinguished Names Rules for the X.500 Series.

3.1.5 Uniqueness of Names 
The distinguished names (DN) indicated in any Certificate issued by the CA shall be uniquely attributable to the Web server for which the Certificate is issued.

3.1.6 Recognition, Authentication and Roles of Trademarks
SECOM Trust Systems does not verify whether there are intellectual property rights pertaining to the names indicated in an application for a Certificate. A subscriber may not use a name related to any registered trademark of a third party in its request to the CA. SECOM Trust Systems will not arbitrate or take part in dispute resolution in the event of a dispute between a subscriber and a third party over a registered trademark or any other intellectual property right. Further, SECOM Trust Systems has the right to reject a subscriber's application for a Certificate or revoke an issued Certificate for reasons of dispute. 

3.2 Initial Identity Validation
3.2.1 Method of Proving Possession of Private Key
A subscriber proves possession of the relevant private key in accordance with the following method.
The signature on the relevant Certificate Signing Request (hereinafter "CSR") is inspected to verify that said CSR is signed with the private key corresponding to the public key.

3.2.2 Authentication of Organization Identity
SECOM Trust Systems authenticates the identity organizations based on official documents issued by national and municipal governments, investigations conducted or databases owned by third parties that SECOM Trust Systems trusts, and other methods determined to be equally trustworthy by the Certification Services Improvement Committee.

3.2.3 Authentication of Individual Identity
SECOM Trust Systems authenticates the identity of individuals based on official documents issued by national and municipal governments, investigations conducted or databases owned by third parties that SECOM Trust Systems trusts, and other methods determined to be equally trustworthy by the Certification Services Improvement Committee.

3.2.4 Unverified Subscriber Information
No stipulation

3.2.5 Verification of Legitimacy of Authority
SECOM Trust Systems verifies that an entity making a Certificate-related request has the legitimate authority to make such request in accordance with "3.2.2 Authentication of Organization" and "3.2.3 Authentication of Individual" hereof. In the event a third party other than a subscriber makes a request and the intent to make said request cannot be confirmed directly with the subscriber, a letter of proxy is required certifying that said third party is an agent of the subscriber.
*As used in this clause, "subscriber" signifies a corporation or any other organization using the host name indicated as the Common Name on the Certificates stipulated in "3.1.1 Types of Names".

3.2.6 Criteria for Interoperation
SECOM Passport for Web EV CA has an active-passive mutual authentication certificate issued by Security Communication EV RootCA1, and SECOM Passport for Web EV 2.0 CA has an active-passive mutual authentication certificate issued by Security Communication RootCA2.

3.3 Identity Verification and Authentication for Re-key Requests
3.3.1 Identity Verification and Authentication for Routine Re-key
The identity of a subscriber shall be verified and authenticated in the same manner as in "3.2 Initial Identity Validation" when re-keying.

3.3.2 Identity Verification and Authentication for Re-key after Revocation of Certificates
Re-keying is not available for revoked Certificates. The application for a Certificate shall be treated as a new application, and the identity of the subscriber shall be verified and authenticated in the same manner as in "3.2 Initial Identity Validation".

3.4 Identity Verification and Authentication for Revocation Requests
Following receipt of a revocation request via a website accessible only by subscribers, SECOM Trust Systems verifies and authenticates the identity of the relevant subscriber.

4. Certificate Life-Cycle Operational Requirements
4.1 Certificate Applications
4.1.1 Entities Who May Apply for Certificates
An application for a Certificate may be filed by a corporation using the Certificate, an Authorized Person (as specified in the Client Organization-Based Document Submission Criteria [SECOM Passport for Web EV]) of a corporation other than the user corporation, or an agent appointed by the Authorized Person.

4.1.2 Application Procedure and Responsibilities
In applying for a Certificate, a subscriber or an agent entrusted by the subscriber to perform the application procedure shall agree to the contents of this CP, the Service Terms and the CPS before proceeding with the application   and must also guarantee that the information provided in the application is accurate.
The method for requesting a Certificate is as follows:
Submit the documents required to SECOM Trust Systems in accordance with the "Application Procedure" on the website.

4.2 Certificate Application Procedure
4.2.1 Identity Verification and Authentication
Following receipt of an application for a Certificate, SECOM Trust Systems performs verification in accordance with "3.2 Initial Identification and Authentication" of this CP. However, there will be no verification based on CAA records.

4.2.2 Approval or Rejection of Certificate Applications
SECOM Trust Systems issues a Certificate corresponding to any application that it approves following assessment, subsequently notifying the relevant subscriber of the completion of the assessment and the issuance of the Certificate. Should an application for a Certificate be inadequate, SECOM Trust Systems will notify the relevant subscriber of the reason for its inadequacy and ask for the re-submission of the documents and any other information required.

4.2.3 Certificate Application Processing Time
SECOM Trust Systems promptly issues a Certificate corresponding to any approved application for Certificate.

4.3 Certificate Issuance
4.3.1 Certificate Issuance Procedure
Upon completion of the assessment of Certificate application, SECOM Trust Systems issues the corresponding Certificate and makes it available for download via a website accessible only by subscribers.

4.3.2 Notice to Subscribers of Certificate Issuance
SECOM Trust Systems notifies the relevant subscriber of the fact that the subscriber's Certificate is ready for download via a website accessible only by subscribers. A subscriber is able to download the Certificate upon receipt of the notice from the CA.

4.4 Confirmation of Certificate Acceptance
4.4.1 Procedure for Confirmation of Certificate Acceptance
A Certificate shall be deemed to have been received upon confirmation that it has been downloaded from the website accessible only by subscribers.

4.4.2 Publication of Certificates by Certification Authorities
The CA does not publish the Certificates of subscribers.

4.4.3 Notice to Other Entities of Certificate Issuance by Certification Authorities
SECOM Trust Systems does not send a notice of certificate issuance to entities other than the person in charge, who was registered at the time of application for a Certificate.

4.5 Key Pair and Certificate Usage
4.5.1 Subscriber Private Key and Certificate Usage
Subscribers use the private key and Certificates for server authentication and encryption of information in the communication pathway. A subscriber shall use the relevant Certificate and corresponding private key only for the purposes approved by the CA   and for no other purpose.

4.5.2 Relying Party Public Key and Certificate Usage
Relying parties may verify the reliability of Certificates issued by the CA using the CA's Certificates. A relying party must understand and agree to this CP and the CPS prior to verifying the reliability of and placing trust in a Certificate issued by the CA.

4.6 Certificate Renewal
The CA recommends generating a new key pair when renewing a Certificate. 4.6.1 
4.6.1 Circumstances for Certificate Renewal
No stipulation
4.6.2 Entities Who May Request Certificate Renewal
No stipulation

4.6.3 Processing of Certificate Renewal Requests
No stipulation
4.6.4 Notice to Subscribers of New Certificate Issuance
No stipulation
4.6.5 Procedures for Confirmation of Renewed Certificate Acceptance
No stipulation
4.6.6 Publication of Renewed Certificates by Certification Authorities
No stipulation
4.6.7 Notice to Other Entities of Certificate Issuance by Certification Authorities
No stipulation
4.7 Certificate Renewal Requiring Re-key
4.7.1 Circumstances for Renewal
A Certificate may be renewed when it is about to expire. A revoked or an expired Certificate cannot be renewed. SECOM Trust Systems begins accepting requests for Certificate renewal sixty (60) days prior to the expiration of the relevant Certificate and begins issuing renewed Certificates thirty (30) days prior to the expiration date.

4.7.2 Entities Who May Request New Certificates
The provisions of "4.1.1 Entities Who May Apply for Certificates" shall apply.

4.7.3 Processing of Renewal Requests
The provisions of "4.3.1 Certificate Issuance Procedure" shall apply.
4.7.4 Notice to Subscribers of New Certificate
The provisions of "4.3.2 Notice to Subscribers of Certificate Issuance" shall apply.
4.7.5 Procedures for Confirmation of Re-keyed Certificate Acceptance
The provisions of "4.4.1 Procedure for Confirmation of Certificate Acceptance" shall apply.
4.7.6 Publication of Re-keyed Certificates by Certification Authorities
Provisions of "4.4.2 Publication of Certificates by Certification Authorities" shall apply.
4.7.7 Notice to Other Entities of Certificate Issuance by Certification Authorities
The provisions of "4.4.3 Notice to Other Entities of Certificate Issuance by Certification Authorities" shall apply.
4.8 Certificate Modification
Should change 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 Entities Who May Request Certificate Modification
No stipulation
4.8.3 Processing of Modification Requests
No stipulation
4.8.4 Notice to Subscribers of New Certificate Issuance
No stipulation
4.8.5 Procedure for Confirmation of Modified Certificate Acceptance
No stipulation
4.8.6 Publication of Modified Certificates by Certification Authorities
No stipulation
4.8.7 Notice to Other Entities of Certificate Issuance by Certification Authorities
No stipulation

4.9 Certificate Revocation and Suspension
4.9.1 Circumstances for Certificate Revocation
A subscriber must promptly request SECOM Trust Systems to revoke a Certificate in the event of any of the following:
・ There has been a change in information indicated in the Certificate.
・ The private key has been or may be compromised for any reason including the theft, loss, unauthorized disclosure or unauthorized use thereof.
・ There is an error in the Certificate, or the Certificate is not being used authorized purposes.
・ The use of the Certificate is being terminated.
SECOM Trust Systems may revoke the Certificate of a subscriber at its discretion in the event of any of the following:
・ The subscriber is not performing the obligations thereof under the Service Terms, this CP, the CPS, relevant agreements or laws.
・ It is determined that the CA's private key has been compromised or there is danger that it will be compromised.
・ SECOM Trust Systems recognizes any other situation deemed to necessitate revocation.

4.9.2 Entities Who May Request Certificate Revocation
A request for revocation of a Certificate may be made by a corporation using the Certificate, an Authorized Person (as specified in the Client Organization-Based Document Submission Criteria [SECOM Passport for Web EV]) of a corporation other than the user corporation, or an agent appointed by the Authorized Person.

4.9.3 Procedure for Revocation Requests
A subscriber makes a revocation request by selecting the relevant Certificate information on a website accessible only by subscribers.

4.9.4 Revocation Request Grace Period
Should a subscriber determine that a private key has been compromised or there is danger that it will be compromised, the subscriber must promptly make a revocation request.

4.9.5 Period within Which Certification Authorities Must Process Revocation Requests
Upon receipt of a valid revocation request, SECOM Trust Systems will promptly process the request and reflect the relevant Certificate information in a CRL.

4.9.6 Requirement to Check Revocation Status
The URL of the CRL storage destination and the URL of the OCSP server are indicated on Certificates issued by the CA.
CRLs and the OCSP server may be accessed using a commonly available Web Interface. CRLs do not contain expired Certificate information.
A relying party must verify the validity of a subscriber's Certificate. The validity of a Certificate may be verified by using the CRL posted on the repository site or the OCSP server.

4.9.7 Publication Frequency of Certificate Revocation Lists
The CRL is updated every twenty four (24) hours regardless of whether there has been a revocation. In the event of a Certificate is revoked, the CRL is updated as of the revocation.

4.9.8 Maximum Delay in Publication of Certificate Revocation Lists
A CRL issued by the CA is immediately reflected in the repository.

4.9.9 Online Verification of Revocation & Status Information
Certificate status information is provided online via the OCSP server.

4.9.10 Requirements for Online Verification of Revocation & Status Information
A relying party must verify the validity of a subscriber's Certificate. When not using the CRL posted on the repository to check for the revocation registration of a Certificate, the relying party must check the Certificate status information provided via the OCSP server.

4.9.11 Availability of Other Forms of Revocation Information
No stipulation

4.9.12 Special Requirements on Key Compromise
No stipulation

4.9.13 Circumstances for Certificate Suspension
The CA does not suspend Certificates.

4.9.14 Entities Who May Request Certificate Suspension
No stipulation

4.9.15 Procedure for Suspension Requests
No stipulation
4.9.16 Duration of Suspension
No stipulation

4.10 Certificate Status Verification Services 
4.10.1 Operational Features
No stipulation
4.10.2 Service Availability
No stipulation
4.10.3 Optional Specifications
No stipulation

4.11 Termination of Subscription (Registration)
A subscriber must make Certificate revocation request when terminating the use of Services.

4.12 Key Escrow and Key Recovery
4.12.1 Key Escrow and Key Recovery Policy and Practice
The CA does not hold subscriber private keys in escrow.

4.12.2 Session Key Encapsulation and Key Recovery Policy and Practice
No stipulation

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 Flood Control
Relevant provisions are stipulated in the CPS.
5.1.5 Fire Prevention
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.

5.2.3 Identity Verification 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
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.
5.4.2 Frequency of Processing Audit Logs
Relevant provisions are stipulated in the CPS.
5.4.3 Retention Period for Audit Logs
Relevant provisions are stipulated in the CPS.
5.4.4 Protection of Audit Logs
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 Notice to Event-causing Entity
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 Archives
SECOM Trust Systems archives and stores the following information in addition to the CA-related system logs specified in "5.4.1 Types of Events Recorded" in the CPS:
・ Certificates and CRLs issued
・ Processing history relating to CRL issuance
・ This CP
・ Documents governing the certificate authorities' business practices, which were prepared  in accordance with this CP
・ Documents pertaining to outsource agreements when outsourcing certification services 
・ Records of audit results and audit reports
・ Application and request forms from subscribers
・ OCSP  server access log

5.5.2 Archive Retention Period
SECOM Trust Systems retains its archives for a minimum of ten (10) years.

5.5.3 Archive Protection
Archives are retained in a facility accessible only to authorized personnel.

5.5.4 Archive Backup Procedure
A backup of the archives is created as necessary in the event of a change in critical data pertaining to a system related to the CA, such as that for Certificate issuance, revocation or CRL issuance.

5.5.5 Requirements for Time-stamping Records
SECOM Trust Systems uses the NTP (Network Time Protocol) to time synchronize systems related to the CA and time stamps critical information recorded therein.

5.5.6 Archive Collection System
The archive collection system is included as a function of the systems related to the CA.

5.5.7 Archive Verification Procedure
Personnel with access authorization obtain archives from a secure storage and regularly check the storage conditions of the media. Further, the archives are copied to new media as needed to maintain their integrity and confidentiality.

5.6 Key Changeover
Before the remaining validity period of the Certificate corresponding to the CA private key becomes shorter than the maximum validity period of a Certificate issued to a subscriber, a new private key is generated in its stead and a new Certificate is issued. Once a new private key is generated, Certificates and CRLs are issued using the new private key.

5.7 Compromise and Disaster Recovery

5.7.1 Accident, Incident and Compromise Recovery Procedures
SECOM Trust Systems establishes measures regarding accidents, incidents and compromises, including the following, to ensure the prompt recovery of systems and operations related to the CA in the event thereof.
・ Compromise of the CA private key 
・ Damages to or malfunction of hardware, software, data or the like
・ Fires, earthquakes and other disasters

5.7.2 Hardware, Software or Data Recovery Procedure
In the event of damage to any hardware, software or data of a system related to the CA, SECOM Trust Systems promptly engages in system recovery efforts using the relevant hardware, software or data that it retains as a backup.

5.7.3 Compromised Private Key Recovery Procedure
Should it be determined that the CA private key has been or may be compromised or should a disaster or any other unexpected happening result in a situation that may lead to the interruption or suspension of the operation of a system related to the CA, SECOM Trust Systems follows predetermined plans and procedures to resume secure system operation.

5.7.4 Post-Disaster Business Continuity
In order to ensure prompt recovery efforts in the event of unforeseen circumstances, SECOM Trust Systems has measures in place for recovering the certification infrastructure system as expeditiously as possible, which include securing the replacement hardware in advance for systems related to the CA, securing backup data in preparation for recovery, and establishing recovery procedures.

5.8 Termination of Certification Authority or Registration Authority
When terminating the CA, SECOM Trust Systems notifies the subscribers and other participants to this effect in advance. All Certificates issued by the CA are revoked prior to the termination of the CA.

6. Technical Security Controls
6.1 Key Pair Generation and Installation
6.1.1 Key Pair Generation
In the certification infrastructure system, the CA key pair is generated on a hardware security module (hereinafter "HSM") that is FIPS140-2 Level 3 compliant.
The key pair generation operation is jointly performed by authorized individuals.
A subscriber key pair is generated on the Web server where the relevant Certificate is to be located.
The method recommended by the CA for key pair generation on a Web server is posted on the SECOM Trust Systems website.

6.1.2 Private Key Delivery to Subscribers
A subscriber private key is generated by the subscriber. The CA does not deliver private keys to subscribers.

6.1.3 Public Key Delivery to Certification Authorities 
A subscriber public key may be delivered online to the CA. The communication pathway is encrypted by SSL for key delivery.

6.1.4 CA Public Key Delivery to Relying Parties
A relying party may obtain the CA public key by accessing the CA repository.

6.1.5 Key Sizes
The length of a CA key pair shall be 2048 bits by the RSA format. The length of a subscriber key pair shall be 2048 bits by the RSA format.

6.1.6 Parameter Generation and Quality Check of Public Keys
Parameter generation and parameter strength verification for the CA public key are performed using an available function of the encryption device used to generate key pairs.  This CP does not provide for the parameter generation and quality check of subscriber public keys.

6.1.7 Key Usage
For KeyUsage of the CA Certificate, set bit positions for CertSign and cRLSign.

For subscriber Certificates issued by the CA, set bit positions for digitalSignature and keyEncipherment.

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 key are performed using an FIPS140-2 Level 3 compliant HSM.
This CP does not provide for the cryptographic module standards and controls of subscriber private keys.

6.2.2 Private Key Multi-Person Control
Activation, deactivation, backup and other operations relating to the CA private key are jointly performed by two or more authorized individuals in a secure environment.
Activation, deactivation, backup and other operations relating to a subscriber private key must be performed securely under the control of the relevant subscriber.

6.2.3 Private Key Escrow
The CA does not hold the CA private key in escrow.
The CA does not hold subscriber private keys in escrow.

6.2.4 Private Key Backup
Backup of the CA private key is jointly performed by authorized individuals in a secure room and is stored in a secure room in the encrypted state. The backup of a subscriber private key must be securely stored under the control of the relevant subscriber.

6.2.5 Private Key Archival
The CA does not archive the CA private key.
This CP does not provide for the archival of subscriber private keys.

6.2.6 Private Key Transfer to or from a Cryptographic Module
The transfer of the CA private key to and from an HSM is performed in a secure room with the private key in an encrypted state.
This CP does not provide for the transfer of subscriber private keys.

6.2.7 Private Key Storage on Cryptographic Module
The private key of the CA, which is operated on a digital certification infrastructure, is stored within the HSM.
This CP does not provide for the storage of subscriber private keys.

6.2.8 Method of Activating Private Key
The CA private key is jointly activated by authorized individuals in a secure room.
This CP does not provide for the activation of subscriber private keys.

6.2.9 Method of Deactivating Private Key
The CA private key is jointly deactivated by authorized individuals in a secure room.
This CP does not provide for the deactivation of subscriber private keys.

6.2.10 Method of Destroying Private Key
The CA private key is jointly destroyed by authorized individuals by means of initialization or physical destruction. The backup key is also destroyed in the same manner.
This CP does not provide for the destruction of subscriber private keys.

6.2.11 Cryptographic Module Rating
The quality standard for an HSM used by the CA is as specified in "6.2.1 Cryptographic Module Standards and Controls" of this CP.
This CP does not provide for the cryptographic modules for subscriber private keys.

6.3 Other Key Pair Controls
6.3.1 Public Key Archival
The provisions for the CA public key are stipulated in "6.2.1 Cryptographic Module Standards and Controls" of the CPS.
This CP does not provide for the archival of subscriber private keys.

6.3.2 Validity Period of Private Key and Public Key
The validity period of the CA private key and public key shall not exceed twenty (20) years.
This CP does not provide for the validity period of subscriber private keys. The validity period of subscriber certificates issued by the CA shall be one (1) year or two (2) years, as the case may be.

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 to Be Considered
No stipulation

6.5 Computer Security Controls
6.5.1 Technical Requirements for Computer Security
Relevant provisions are stipulated in the CPS.
6.5.2 Computer Security Assessment
Relevant provisions are stipulated in the CPS.

6.6 Life Cycle Security 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
Relevant provisions are stipulated in the CPS.

7. Certificate, Certificate Revocation List and OCSP Server Certificate Profiles

7.1 Certificate Profiles
Profiles of the Certificates issued by the CA are indicated in the tables below.
Table 7.1-1 SECOM Passport for Web EV CA Server Certificate Profile
Basic Fields	Settings	criticalVersion Version 3-Serial Number 	e.g.)	-Signature Algorithm SHA1 with RSAEncryption-IssuerCountryC=JP- OrganizationO=SECOM Trust Systems CO.,LTD.-Common NameCN=SECOM Passport for Web EV CA-ValidityNotBefore	e.g.)	- NotAfter	e.g.)	-SubjectCountryC=JP(Fixed value)	- State Or Province	Required	-
	Locality	Required	-
	jurisdictionOfIncorporationCountryNameJP(Fixed value)	-
	Organization	Required	-
	Organizational Unit	Optional	-
	Common Name	Server name (Required)	-
	Serial Number	Required (*1)	-
	businessCategory	Required (*2)	-Subject Public Key Info	Subject public key 2048 bits	-
Extension Fields	Settings	criticalKeyUsagedigitalSignature, keyEnciphermentyExtendedKeyUsageserverAuthnSubject Alt Name	dNSName=Server Name	n	
CertificatePoliciespolicyIdentifier
OID=1.2.392.200091.100.721.1 
policyQualifiers
policyQualifierId=CPS
qualifiier=https://repo1.secomtrust.net/spcpp/pfw/pfwevca/nCRL Distribution Points
http://repo1.secomtrust.net/spcpp/pfw/pfwevca/fullcrl.crlnAuthority Information Access
accessMethod
ocsp（1 3 6 1 5 5 7 48 1)
accessLocation
http://ev.ocsp.secomtrust.net 
nAuthority Key Identifier	SHA-1 hash value of authority public key (160 bits)	nSubject Key Identifier	SHA-1 hash value of subject public key (160 bits)	n	

Table 7.1-2 SECOM Passport for Web EV CA OCSP Server Certificate Profile
Basic Fields	Settings	critical	
Version Version 3-Serial Number 	e.g.)	-Signature Algorithm SHA1 with RSAEncryption-IssuerCountryC=JP- OrganizationO=SECOM Trust Systems CO.,LTD.-Common NameCN=SECOM Passport for Web EV CA-ValidityNotBefore	e.g.)	- NotAfter	e.g.)	-SubjectCountryC=JP(Fixed value)	- Organization	Required	-Common Name	Server name (Required)	-Subject Public Key Info	Subject public key 2048 bits	-
Extension Fields	Settings	criticalKeyUsagedigitalSignatureyExtendedKeyUsageOCSPSigningnOCSP No Checknulln CertificatePoliciespolicyIdentifier 
OID=1.2.392.200091.100.721.1
policyQualifiers
policyQualifierId=CPS
qualifiier=https://repo1.secomtrust.net/spcpp/pfw/pfwevca/nAuthority Key Identifier	SHA-1 hash value of authority public key (160 bits)	nSubject Key Identifier	SHA-1 hash value of subject public key (160 bits)	n	

Table 7.1-3 SECOM Passport for Web EV 2.0 CA Server Certificate Profile
Basic Fields	Settings	criticalVersion Version 3-Serial Number 	e.g.)	-Signature Algorithm SHA256 with RSAEncryption-IssuerCountryC=JP- OrganizationO=SECOM Trust Systems CO.,LTD.-Common NameCN=SECOM Passport for Web EV 2.0 CA-ValidityNotBefore	e.g.)	- NotAfter	e.g.)	-SubjectCountryC=JP(Fixed value)	- State Or Province	Required	-Locality	Required	-
	jurisdictionOfIncorporationCountryNameJP(Fixed value)	-
	Organization	Required	-
	Organizational Unit	Optional	-
	Common Name	Server name (Required)	-
	Serial Number	Required (*1)	-
	businessCategory	Required (*2)	-Subject Public Key Info	Subject public key 2048 bits	-
Extension Fields	Settings	criticalKeyUsagedigitalSignature, keyEnciphermentyExtendedKeyUsageserverAuthnSubject Alt NamedNSName=Server Name	nCertificatePoliciespolicyIdentifier
OID=1.2.392.200091.100.721.1 
policyQualifiers
policyQualifierId=CPS
qualifiier=https://repo1.secomtrust.n et/spcpp/pfw/pfwev2ca/nCRL Distribution Points
http://repo1.secomtrust.net/spcpp/pf w/pfwev2ca/fullcrl.crlnAuthority Information Access
accessMethod
ocsp（1 3 6 1 5 5 7 48 1)
accessLocation
http://ev2.ocsp.secomtrust.netnAuthority Key Identifier	SHA-1 hash value of authority public key (160 bits)	nSubject Key Identifier	SHA-1 hash value of subject public key (160 bits)	n	

Table 7.1-4 SECOM Passport for Web EV 2.0 CA OCSP Server Certificate Profile
Basic Fields	Settings	criticalVersion Version 3-Serial Number 	e.g.)	-Signature Algorithm SHA256 with RSAEncryption-IssuerCountryC=JP- OrganizationO=SECOM Trust Systems CO.,LTD.-Common NameCN=SECOM Passport for Web EV CA-ValidityNotBefore	e.g.)	- NotAfter	e.g.)	-SubjectCountryC=JP(Fixed value)	- 
	Organization(Fixed value)	-
	Common Name	OCSP server name (Required)	-Subject Public Key Info	Subject public key 2048 bits	-
Extension Fields	Settings	criticalKeyUsagedigitalSignatureyExtendedKeyUsageOCSPSigningnOCSP No Checknulln CertificatePoliciespolicyIdentifier
OID=1.2.392.200091.100.721.1
policyQualifiers
policyQualifierId=CPS
qualifiier=https://repo1.secomtrust.net/spcpp/pfw/pfwev2ca/nAuthority Key Identifier	SHA-1 hash value of authority public key (160 bits)	nSubject Key Identifier	SHA-1 hash value of subject public key (160 bits)	n	

(*1) For the following subscribers, the CA sets the Serial Number as indicated below: 
Registered corporations: Corporate registration number or a comparable number
Central government ministries and agencies and state organs: Date of establishment
Local governments and their organs: Date of establishment
National and public universities and high schools: Date of establishment

Should SECOM Trust Systems be unable to verify the date of establishment, the following word or words are entered as the Serial Number:
Central government ministries and agencies and state organs: Government
Local governments and their organs: Local Government
National and public universities and high schools: Public School

(*2) For the following subscribers, the CA set the businessCategory as indicated below:
Registered corporations: Private Organization
Central government ministries and agencies and state organs: Government Entity

Local governments and their organs: Government Entity
National and public universities and high schools: Government Entity

7.2 CRL Profiles
Profiles of the CRLs issued by the CA are indicated in the tables below.

Table 7.2-1	SECOM Passport for Web EV CA CRL Profile
Basic Fields	Settings	criticalVersion Version 3-Signature Algorithm SHA1 with RSAEncryption-IssuerCountryC=JP- OrganizationO=SECOM Trust Systems CO.,LTD.-Common NameCN=SECOM Passport for Web EV CA-This Update	e.g.)	- Next Update	e.g.) 2006/2/5 00:00:00 GMT Set as Update interval =24H, Validity period =96H 	-Revoked CertificatesSerial Number	e.g.)	- Revocation Date 	e.g.)	-Reason Code	Circumstances of revocation (unspecifiled, etc.)	-
Extension Fields	Settings	criticalCRL NumberCRL number	criticalAuthority Key Identifier	SHA-1 hash value of authority public key (160 bits)	n	

Table 7.2-2SECOM Passport for Web EV 2.0 CA CRL Profile
Basic Fields	Settings	criticalVersion Version 3-Signature Algorithm SHA256 with RSAEncryption-IssuerCountryC=JP- OrganizationO=SECOM Trust Systems CO.,LTD.-Common NameCN=SECOM Passport for Web EV 2.0 CA-This Update	e.g.)	- Next Update	e.g.) 2006/2/5 00:00:00 GMT Set as Update interval =24H, Validity period =96H 	-Revoked CertificatesSerial Number	e.g.)	- Revocation Date 	e.g.)	-Reason Code	Circumstances of revocation (unspecified, etc.)	-
Extension Fields	Settings	criticalCRL NumberCRL number	criticalAuthority Key Identifier	SHA-1 hash value of authority public key (160 bits)	n	

7.3 OCSP Profile
The CA provides an OCSP to RFC2560, 5019 or 6960 compliant Certificates.

7.3.1 Version Number
The CA uses OCSP Version 1.

7.3.2 OCSP Extension
No stipulation

8. Compliance Audit and Other Assessments
The CA performs audits from time to time to verify that the operation thereof is in compliance with this CP and the CPS.
The details of the compliance audits performed by the CA are stipulated in the CPS.

8.1 Frequency of Audits
Relevant provisions are stipulated in the CPS.
8.2 Auditor Identity and Qualifications
Relevant provisions are stipulated in the CPS.
8.3 Relationship between Auditor and Audited Department
Relevant provisions are stipulated in the CPS.
8.4 Matters Audited
Relevant provisions are stipulated in the CPS.
8.5 Measures Taken for Inadequacies
Relevant provisions are stipulated in the CPS.
8.6 Disclosure of Audit Results
Relevant provisions are stipulated in the CPS.

9. Other Business and Legal Matters
9.1 Fees
Fees for the Certificates issued by the CA are stipulated separately.

9.2 Financial Responsibility
SECOM Trust Systems shall maintain adequate financial resources for the operation and maintenance of the CA.

9.3 Confidentiality of Business Information
9.3.1 Scope of Confidential Information
Relevant provisions are stipulated in the CPS.
9.3.2 Information outside 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 Protection of Personal Information
Relevant provisions are stipulated in the CPS.
9.5 Intellectual Property Rights
The following copyrighted materials are the property of SECOM Trust Systems.
・ This CP
・ SECOM stickers and sticker verification page

9.6 Representations and Warranties
9.6.1 Certification Authority Representations and Warranties
9.6.1.1 IA Representations and Warranties
SECOM Trust Systems has the obligation to perform the following in the execution of its duties as an IA:
・ Secure generation and management of CA private keys
・ Precise issuance, revocation and management of Certificates based on requests from the RA
・ Operation and operation monitoring of IA systems
・ Issuance and publication of CRLs
・ Provision of access to the OCSP server
・ Maintenance and management of the repository

9.6.1.2 RA Representations and Warranties
SECOM Trust Systems has the obligation to perform the following in the execution of its duties as an RA:
・ Installation and operation of registration terminals in a secure environment
・ Precise assessment of application, including verification of identity, in connection with Certificate issuance
・ Provision of prompt and accurate instructions to the IA on issuance, revocation and other Certificate-related actions

9.6.2 Subscriber Representations and Warranties
A subscriber shall have the following obligations:
・ Provide accurate and complete information when applying for a Certificate. In the event of change in the information provided, promptly notify SECOM Trust Systems to this effect.
・ Protect its private key from being compromised.
・ Use the Certificate in accordance with the provisions of the Service Terms and this CP.
・ Promptly request SECOM Trust Systems to revoke Subscriber Certificate in the event subscriber determines that the private key corresponding to the public key indicated in its Certificate has been or may be compromised or there has been a change in registered information.

9.6.3 Relying Party Representations and Warranties
A relying party shall have the following obligations:
・ Verify the validity of the CA Certificate.
・ Verify the validity of the subscriber Certificate by checking the validity period to ensure it has not expired and checking the CRL or the OCSP server to see if it is registered as a revoked Certificate.
・ Determine whether to trust the subscriber information on its own responsibility.

9.6.4 Other Participant Representations and Warranties
No stipulation

9.7 Disclaimer of Warranties
SECOM Trust Systems is not liable for any direct, special, incidental or consequential damages arising in connection with the warranties stipulated in "9.6.1 Certification Authority Representations and Warranties" of this CP, or for lost earnings, loss of data, or any other indirect or consequential damages. 

9.8 Limitation of Liability
SECOM Trust Systems is not liable for the provisions of "9.6.1 Certification Authority Representations and Warranties" of this CP in any of the following cases:
・ Any damage arising from unlawful conduct, unauthorized use, negligence or any other cause not attributable to SECOM Trust Systems
・ Any damage attributable to the failure of a subscriber to perform its obligations
・ Any damage attributable to a subscriber system
・ Damages attributable to a hardware or software defect or malfunction or any other behavior of  a SECOM Trust Systems or a subscriber system
・ Damages caused by information released in a Certificate, a CRL or the OCSP server due to reasons beyond the control of SECOM Trust Systems
・ Any damage incurred in a situation where normal communication is not possible due to reasons beyond the control of SECOM Trust Systems
・ Any damage arising in connection with the use of a Certificate, including transaction debts
・ Damages attributable to improvement, beyond expectations at this point in time, in hardware or software encryption algorithm decoding skills
・ Any damage attributable to the suspension of the CA's operations due to force majeure, including natural disasters, earthquakes, volcanic eruptions, fires, tsunami, floods, lightning strikes, wars, civil commotion and terrorism

9.9 Indemnities
SECOM Trust Systems shall compensate a subscriber for the damages incurred thereby for reasons attributable to a Certificate in an amount not to exceed the contract fees received and equal to the fees for the remaining months of the contract period (period of less than one month is rounded off) and shall not be liable in any other way.

9.10 Term and Termination
9.10.1 Term
This CP goes into effect upon approval by the Certification Services Improvement Committee.
This CP will not be invalidated under any circumstances prior to the termination hereof as stipulated in "9.10.2 Termination" hereof.

9.10.2 Termination
This CP loses effect as of the termination hereof by SECOM Trust Systems with the exception of the provisions stipulated in "9.10.3 Effect of Termination and Survival".

9.10.3 Effect of Termination and Survival
Even in the event of termination of the use of a Certificate by a subscriber, termination of a contract between SECOM Trust Systems and the other party thereto, or the termination of a service provided by SECOM Trust Systems, provisions that should remain in effect, due to the nature thereof, shall survive any such termination, regardless of the reasons therefor, and remain in full force and effect with respect to any subscriber, relying party, entity in a contractual relationship with SECOM Trust Systems, and SECOM Trust Systems.

9.11 Individual Notices and Communication among Participants
SECOM Trust Systems provides the necessary notices to subscribers and relying parties through means such as its website, e-mail and written documents.

9.12 Revisions
9.12.1 Revision Procedure
SECOM Trust Systems checks this CP on a regular basis. Further, SECOM Trust Systems revises this CP as needed at its discretion, and the revised version goes into effect upon approval by the Certification Services Improvement Committee.

9.12.2 Notification Method and Timing
In the event this CP is modified, participants will be notified through the prompt publication of the modified version of this CP.

9.12.3 Circumstances Requiring Change of Object Identifier
No stipulation

9.13 Dispute Resolution Procedures
A party seeking to file a lawsuit, request arbitration or take any other legal action against SECOM Trust Systems for the resolution of a dispute relating to a Certificate issued by the CA, said party shall notify SECOM Trust Systems 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 CA and this CP are governed by the laws of Japan. The laws of Japan will apply to any dispute concerning the interpretation or validity of this CP and the CPS, as well as the use of Certificates.

9.15 Compliance with Applicable Laws
The CA shall handle cryptographic hardware and software in compliance with the various Japanese export regulations.

9.16 Miscellaneous Provisions
9.16.1 Entire Agreement
SECOM Trust Systems comprehensively stipulates subscriber and relying party obligations and other relevant matters in this CP in providing the services and any other agreement, whether oral or written, shall have no effect.

9.16.2 Assignment
When assigning the service to a third party, SECOM Trust Services may also assign its responsibilities and other obligations specified in this CP, the Service Terms, and the CP. 

9.16.3 Severability
Even if any provision of this CP, the Service Terms or the CPS is deemed invalid, all other provisions stipulated said documents shall remain in full force and effect.

9.16.4 Enforcement
No stipulation

9.17 Other Provisions
No stipulation