Page 1
Page 1 of 83
Internet Security Research Group
(ISRG)
Certificate Policy
DRAFT Version 1.0 DRAFT
Updated May 5, 2015
Approved by ISRG Policy Management Authority
ISRG
Web Site: https://letsencrypt.org
Page 2
Page 2 of 83
Copyright Notice
Copyright © 2014 ISRG and/or its licensors. All rights reserved.
This document is provided for the intended recipient’s review only. Do not redistribute this document, in
part or in whole, without first obtaining prior written consent from ISRG.
To request consent, contact ISRG at or write:
Internet Security Research Group
331 E. Evelyn Ave.
Mountain View, CA 94041
Page 3
Page 3 of 83
Table of Contents
1
INTRODUCTION .............................................................................................................................................10
OVERVIEW ......................................................................................................................................................10
DOCUMENT NAME AND IDENTIFICATION ........................................................................................................10
Alphanumeric Identifier ........................................................................................................................10
Object Identifier ....................................................................................................................................10
PKI PARTICIPANTS..........................................................................................................................................11
Certification Authority (CA) .................................................................................................................11
Policy Management Authority ..............................................................................................................12
Registration Authorities (RAs) ..............................................................................................................12
Applicants/Subscribers .........................................................................................................................12
Relying Parties ......................................................................................................................................13
Other Participants ................................................................................................................................14
1.3.6.1 Certificate Manufacturing Authority ................................................................................................................ 14
1.3.6.2 Repository ......................................................................................................................................................... 14
CERTIFICATE USAGE .......................................................................................................................................14
Allowed Certificate Uses .......................................................................................................................14
Prohibited Certificate Uses ...................................................................................................................14
Cross-Certification ...............................................................................................................................15
POLICY ADMINISTRATION ...............................................................................................................................15
Organization Administering this Document .........................................................................................15
Contact Person ......................................................................................................................................15
Person Determining CPS Suitability for the Policy ..............................................................................15
CPS Approval Procedures ....................................................................................................................15
DEFINITIONS AND ACRONYMS ........................................................................................................................15
Definitions .............................................................................................................................................15
Acronyms ...............................................................................................................................................21
2
PUBLICATION AND REPOSITORY RESPONSIBILITIES .....................................................................23
REPOSITORIES .................................................................................................................................................23
PUBLICATION OF CERTIFICATION INFORMATION ............................................................................................23
Publication of CA Information ..............................................................................................................23
Interoperability .....................................................................................................................................23
TIME OR FREQUENCY OF PUBLICATION...........................................................................................................23
ACCESS CONTROLS ON REPOSITORIES ............................................................................................................23
3
IDENTIFICATION AND AUTHENTICATION ...........................................................................................24
NAMING ..........................................................................................................................................................24
Types of Names .....................................................................................................................................24
Need for Names To Be Meaningful .......................................................................................................25
Anonymity or Pseudonymity of Subscribers .........................................................................................25
Rules for Interpreting Various Name Forms ........................................................................................25
Uniqueness of Names ............................................................................................................................25
Recognition, Authentication, and Role of Trademarks .........................................................................25
3.1.6.1 Name Claim Dispute Resolution Procedure ..................................................................................................... 25
INITIAL IDENTITY VALIDATION.......................................................................................................................26
Method to Prove Possession of Private Key .........................................................................................26
Authentication of Domains and Administrative Certificates ................................................................26
3.2.2.1 Acceptable Forms of Identification Documents for Applicants ....................................................................... 26
3.2.2.2 Performance of Electronic Identification .......................................................................................................... 26
3.2.2.3 gTLD Domain Validation ................................................................................................................................. 27
3.2.2.4 Country Name Field Validation ........................................................................................................................ 27
3.2.2.5 IP Address Validation ....................................................................................................................................... 27
Non-Verified Subscriber Information ...................................................................................................27
Validation of Authority .........................................................................................................................28
Page 4
Page 4 of 83
3.2.4.1 Verification against the Denied List ................................................................................................................. 28
3.2.4.2 Verification against High Risk Certificate Requests ........................................................................................ 28
3.2.4.3 Data Source Accuracy ....................................................................................................................................... 28
Criteria for Interoperation ....................................................................................................................28
Authentication of Device Identity ..........................................................................................................28
Authentication of Other Certificates .....................................................................................................29
IDENTIFICATION AND AUTHENTICATION (I&A) FOR REKEY AND RENEWAL ..................................................29
Identification and Authentication for Rekey Requests ..........................................................................29
Identification and Authentication for Rekey after Revocation ..............................................................29
Certificate Renewal ...............................................................................................................................29
Certificate Update .................................................................................................................................29
Renewal or Update of Affiliated Individual’s Certificate .....................................................................29
I&A FOR REVOCATION AND SUSPENSION REQUESTS......................................................................................29
4
CERTIFICATE LIFE CYCLE OPERATIONAL REQUIREMENTS .......................................................31
CERTIFICATE APPLICATION.............................................................................................................................31
Who Can Submit a Certificate Application ...........................................................................................31
Enrollment Process and Responsibilities ..............................................................................................31
CERTIFICATE APPLICATION PROCESSING ........................................................................................................31
Performing Identification and Authentication Functions .....................................................................31
Approval or Rejection of Certificate Applications ................................................................................32
Time to Process Certificate Application ...............................................................................................32
CERTIFICATE ISSUANCE ..................................................................................................................................32
CA Actions during Certificate Issuance ................................................................................................32
Notification to Subscriber by the CA of Issuance of the Certificate .....................................................33
CERTIFICATE ACCEPTANCE.............................................................................................................................33
Conduct Constituting Certificate Acceptance .......................................................................................33
Publication of the Certificate by the CA ...............................................................................................33
Notification of Certificate Issuance by the Authorized CA to Other Entities .......................................33
KEY PAIR AND CERTIFICATE USAGE...............................................................................................................33
Subscriber Private Key and Certificate Usage .....................................................................................33
Relying Party Public Key and Certificate Usage .................................................................................33
CERTIFICATE RENEWAL ..................................................................................................................................34
Circumstance for Certificate Renewal ..................................................................................................34
Who May Request Renewal ...................................................................................................................34
Processing Certificate Renewal Requests .............................................................................................34
Conduct Constituting Acceptance of a Renewal Certificate .................................................................34
Publication of the Renewal Certificate by the CA ................................................................................34
Notification of Certificate Issuance by the Authorized CA to Other Entities .......................................34
CERTIFICATE REKEY .......................................................................................................................................34
Circumstances for Certificate Rekey ....................................................................................................34
Who May Request a Rekey ....................................................................................................................34
Processing Certificate Rekeying Requests ............................................................................................35
Notification of New Certificate Issuance to Subscriber ........................................................................35
Conduct Constituting Acceptance of a Rekeyed Certificate .................................................................35
Notification of Certificate Issuance by the Authorized CA to Other Entities .......................................35
MODIFICATION................................................................................................................................................35
Circumstances for Certificate Modification .........................................................................................35
Who May Request Certificate Modification ..........................................................................................35
Processing Certificate Modification Requests ......................................................................................35
Notification of New Certificate Issuance to Subscriber ........................................................................35
Conduct Constituting Acceptance of Modified Certificate ...................................................................35
Publication of the Modified Certificate by the CA ................................................................................35
Notification of Certificate Issuance by the CA to other Entities ...........................................................35
CERTIFICATE REVOCATION AND SUSPENSION.................................................................................................35
Circumstances for Revocation ..............................................................................................................36
4.9.1.1 Permissive Revocation ...................................................................................................................................... 36
Page 5
Page 5 of 83
4.9.1.2 Required Revocation ......................................................................................................................................... 36
Who Can Request Revocation ...............................................................................................................37
Procedure for Revocation Request .......................................................................................................37
4.9.3.1 Procedure for Investigating Certificate Problem Reports ................................................................................. 37
Revocation Request Grace Period ........................................................................................................37
Time within which CA must Process a Revocation Request .................................................................37
Revocation Checking Requirements for Relying Parties ......................................................................38
CRL Issuance Frequency ......................................................................................................................38
Maximum Latency of CRLs ...................................................................................................................38
Online Revocation/Status Checking Availability ..................................................................................38
Online Revocation Checking Requirements ..........................................................................................38
Other Forms of Revocation Advertisements Available .........................................................................38
Special Requirements Rekey Compromise ............................................................................................38
Circumstances for Suspension ..............................................................................................................38
Who can Request a Suspension .............................................................................................................38
Procedure for Suspension Request .......................................................................................................39
Limits on Suspension Period .................................................................................................................39
CERTIFICATE STATUS SERVICES.................................................................................................................39
Operational Characteristics .................................................................................................................39
Service Availability ...............................................................................................................................39
Optional Features .................................................................................................................................39
END OF SUBSCRIPTION ...............................................................................................................................39
KEY ESCROW AND RECOVERY ...................................................................................................................40
Key Escrow and Recovery Policy and Practices ..................................................................................40
Session Key Encapsulation and Recovery Policy and Practices ..........................................................40
5
FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS ........................................................41
PHYSICAL CONTROLS......................................................................................................................................41
Site Location and Construction ............................................................................................................41
Physical Access .....................................................................................................................................41
Power and Air Conditioning .................................................................................................................42
Water Exposures ...................................................................................................................................42
Fire Prevention and Protection ............................................................................................................42
Media Storage .......................................................................................................................................42
Waste Disposal......................................................................................................................................42
Off-site Backup ......................................................................................................................................43
PROCEDURAL CONTROLS ................................................................................................................................43
Trusted Roles ........................................................................................................................................43
Number of Persons Required per Task .................................................................................................43
Identification and Authentication for Each Role ..................................................................................43
Roles Requiring Separation of Duties ...................................................................................................44
5.2.4.1 Activities Requiring Multiple Individuals ........................................................................................................ 44
PERSONNEL CONTROLS...................................................................................................................................44
Background, Qualifications, Experience, and Security Clearance Requirements ...............................44
Background Check Procedures .............................................................................................................44
Training Requirements ..........................................................................................................................45
Retraining Frequency and Requirements .............................................................................................45
Job Rotation Frequency and Sequence .................................................................................................45
Sanctions for Unauthorized Actions .....................................................................................................45
Independent Contractor Requirements .................................................................................................45
Documentation Supplied to Personnel ..................................................................................................45
AUDIT LOGGING PROCEDURES........................................................................................................................45
Types of Events Recorded .....................................................................................................................45
Frequency of Log Review and Processing ............................................................................................45
Retention Period for Audit Logs ...........................................................................................................46
Protection of Audit Logs .......................................................................................................................46
Audit Log Backup Procedures ..............................................................................................................46
Page 6
Page 6 of 83
Audit Collection System (Internal vs. External) ...................................................................................46
Notification to Event-Causing Subject ..................................................................................................46
Vulnerability Assessments .....................................................................................................................46
5.4.8.1 Risk Assessment ............................................................................................................................................... 47
RECORDS ARCHIVE .........................................................................................................................................47
Types of Events Archived ......................................................................................................................47
5.5.1.1 Certificate Issuance ........................................................................................................................................... 47
5.5.1.2 Certificate Validation ........................................................................................................................................ 48
5.5.1.3 Certificate Revocation ...................................................................................................................................... 48
5.5.1.4 Certificate Renewal ........................................................................................................................................... 48
5.5.1.5 Security events .................................................................................................................................................. 48
Retention Period for Archive ................................................................................................................48
Protection of Archive ............................................................................................................................48
Archive Backup Procedures ..................................................................................................................49
Requirements for Time-Stamping of Records .......................................................................................49
Archive Collection System ....................................................................................................................49
Procedures to Obtain and Verify Archive Information .........................................................................49
Long Term Information Preservation ...................................................................................................49
KEY CHANGEOVER..........................................................................................................................................49
COMPROMISE AND DISASTER RECOVERY .......................................................................................................49
Incident and Compromise Handling Procedures .................................................................................49
Computing Resources, Software, and/or Data are Corrupted .............................................................49
CA Private Key Compromise Procedures .............................................................................................50
Business Continuity Capabilities After a Disaster................................................................................50
Customer Service Center ......................................................................................................................50
5.7.5.1 User Agent Verification .................................................................................................................................... 50
CA OR RA TERMINATION ...............................................................................................................................51
6
TECHNICAL SECURITY CONTROLS ........................................................................................................52
KEY PAIR GENERATION AND INSTALLATION ..................................................................................................52
Key Pair Generation .............................................................................................................................52
6.1.1.1 Key Generation Ceremony ............................................................................................................................... 52
Private Key Delivery to Subscriber ......................................................................................................52
Public Key Delivery to CA ...................................................................................................................52
Key Sizes ...............................................................................................................................................52
Public Key Parameters Generation and Quality Checking ..................................................................53
Key Usage Purposes (as per X509 v3 Key Usage Field) ......................................................................53
PRIVATE KEY PROTECTION AND CRYPTOMODULE ENGINEERING CONTROLS ................................................53
Cryptomodule Standards and Controls ................................................................................................53
Private Key (n out of m) Multi-Person Control ....................................................................................54
Private Key Escrow ...............................................................................................................................54
Private Key Backup ...............................................................................................................................54
Private Key Archival .............................................................................................................................54
Private Key Transfer into or from a Cryptomodule ..............................................................................54
Private Key Storage on a Cryptomodule ..............................................................................................54
Method of Activating Private Keys .......................................................................................................54
Method of Deactivating Private Keys ...................................................................................................54
Method of Destroying Private Keys ......................................................................................................54
OTHER ASPECTS OF KEY MANAGEMENT ........................................................................................................55
Public Key Archival ..............................................................................................................................55
Certificate Operational Periods and Key Usage Periods .....................................................................55
Restrictions on Authorized CA’s Private Key Use ................................................................................55
ACTIVATION DATA..........................................................................................................................................55
Activation Data Generation and Installation .......................................................................................55
Activation Data Protection ...................................................................................................................56
Other Aspects of Activation Data .........................................................................................................56
COMPUTER SECURITY CONTROLS ...................................................................................................................56
Specific Computer Security Technical Requirements ...........................................................................56
Page 7
Page 7 of 83
Computer Security Rating .....................................................................................................................56
LIFE CYCLE TECHNICAL CONTROLS ...............................................................................................................56
System Development Controls ..............................................................................................................57
Security Management Controls .............................................................................................................57
Life Cycle Security Controls .................................................................................................................57
NETWORK SECURITY CONTROLS ....................................................................................................................57
TIME STAMPING ..............................................................................................................................................58
7
CERTIFICATE, CRL, AND OCSP PROFILES ...........................................................................................59
CERTIFICATE PROFILES ...................................................................................................................................59
Version Number(s) ................................................................................................................................59
Certificate Extensions ...........................................................................................................................59
Algorithm Object Identifiers .................................................................................................................61
Name Forms ..........................................................................................................................................62
Name Constraints .................................................................................................................................62
Certificate Policy Object Identifier .......................................................................................................62
Usage of Policy Constraints Extension .................................................................................................63
Policy Qualifiers, Syntax, and Semantics .............................................................................................63
Processing Semantics for the Critical Certificate Policies Extension ..................................................63
CRL PROFILE ..................................................................................................................................................63
Version Number(s) ................................................................................................................................63
CRL and CRL Entry Extensions ............................................................................................................63
OCSP PROFILE................................................................................................................................................63
Version Number(s) ................................................................................................................................63
OCSP Extensions ..................................................................................................................................63
8
COMPLIANCE AUDITS AND OTHER ASSESSMENTS ..........................................................................64
FREQUENCY OF AUDIT OR ASSESSMENTS .......................................................................................................64
Internal Self-Assessment Audits ............................................................................................................64
IDENTITY AND QUALIFICATIONS OF ASSESSOR ...............................................................................................64
ASSESSOR’S RELATIONSHIP TO ASSESSED ENTITY .........................................................................................65
TOPICS COVERED BY ASSESSMENT .................................................................................................................65
ACTIONS TAKEN AS A RESULT OF DEFICIENCY...............................................................................................65
COMMUNICATION OF RESULTS........................................................................................................................65
9
OTHER BUSINESS AND LEGAL MATTERS .............................................................................................66
FEES ................................................................................................................................................................66
Certificate Issuance, Renewal and Revocation Fees ............................................................................66
Certificate Access Fees .........................................................................................................................66
Revocation or Status Information Access Fee (Certificate Validation Services) .................................66
Fees for Other Services such as Policy Information ............................................................................66
Refund Policy ........................................................................................................................................66
FINANCIAL RESPONSIBILITY ...........................................................................................................................66
Insurance Coverage ..............................................................................................................................66
Other Assets ..........................................................................................................................................66
Insurance or Warranty Coverage for End-entities ...............................................................................66
CONFIDENTIALITY OF BUSINESS INFORMATION ..............................................................................................66
Scope of Confidential Information ........................................................................................................66
Information Not Within the Scope of Confidential Information ...........................................................66
Responsibility to Protect Confidential Information ..............................................................................66
PRIVACY OF PERSONAL INFORMATION ...........................................................................................................67
Privacy Plan ..........................................................................................................................................67
Information Treated as Private .............................................................................................................67
Information not Deemed Private ..........................................................................................................67
Responsibility to Protect Private Information ......................................................................................67
Notice and Consent to use Private Information ....................................................................................68
Disclosure Pursuant to Judicial or Administrative Process .................................................................68
Page 8
Page 8 of 83
Other Information Disclosure Circumstances ......................................................................................68
Sensitivity of Information ......................................................................................................................68
Opportunity to Correct Private Information. ........................................................................................68
INTELLECTUAL PROPERTY RIGHTS..................................................................................................................68
REPRESENTATIONS AND WARRANTIES............................................................................................................69
CA Representations and Warranties .....................................................................................................69
9.6.1.1 Warranties from CA to Subscriber ................................................................................................................... 69
9.6.1.2 Warranties from CA to Relying Party .............................................................................................................. 69
9.6.1.3 CA to Certificate Beneficiaries ......................................................................................................................... 70
9.6.1.4 General Representations and Warranties of CA ............................................................................................... 71
RA Representations and Warranties .....................................................................................................71
Applicant/Subscriber Representations and Warranties ........................................................................71
Relying Party Obligations, Representations and Liability ...................................................................71
Representations and Warranties of Other PKI Participants ................................................................71
DISCLAIMER OF WARRANTIES.........................................................................................................................71
LIMITATIONS OF LIABILITY .............................................................................................................................72
INDEMNITIES ...................................................................................................................................................73
TERM AND TERMINATION...........................................................................................................................73
Term ......................................................................................................................................................73
Termination ...........................................................................................................................................73
Effect of Termination and Survival .......................................................................................................74
INDIVIDUAL NOTICES AND COMMUNICATIONS WITH PARTICIPANTS .........................................................74
AMENDMENTS ............................................................................................................................................74
Procedure for Amendment ....................................................................................................................74
Notification Mechanism and Period .....................................................................................................74
Circumstances under Which OID Must Be Changed ...........................................................................74
DISPUTE RESOLUTION PROVISIONS ............................................................................................................74
GOVERNING LAW .......................................................................................................................................75
COMPLIANCE WITH APPLICABLE LAW .......................................................................................................75
MISCELLANEOUS PROVISIONS....................................................................................................................75
Entire Agreement ..................................................................................................................................75
Assignment ............................................................................................................................................75
Severability ...........................................................................................................................................75
Enforcement (Attorney Fees and Waiver of Rights) .............................................................................75
OTHER PROVISIONS....................................................................................................................................76
Relationship. .........................................................................................................................................76
Force Majeure ......................................................................................................................................76
10 CERTIFICATE PROFILES ............................................................................................................................77
ROOT CA CERTIFICATE..............................................................................................................................77
SUBORDINATE CA CERTIFICATE ................................................................................................................77
DV-SSL CERTIFICATE................................................................................................................................78
HUMAN ADMINISTRATIVE CERTIFICATE ....................................................................................................80
OCSP RESPONDER CERTIFICATE(S) ...........................................................................................................80
ROOT CRL .................................................................................................................................................81
SUBORDINATE CRL (OPTIONAL) ................................................................................................................82
OCSP REQUEST FORMAT ...........................................................................................................................82
OCSP RESPONSE FORMAT .........................................................................................................................82
Page 9
Page 9 of 83
Change History
Date
Changes / Authors
Version
01 December 2014
Original
Authors: Shelley Johnson, Warren Brunson
1.0
Page 10
Page 10 of 83
1 Introduction
Overview
This ISRG Certificate Policy (CP) contains the business, technical, and legal requirements for governing
the life cycle events of Domain Validated SSL Certificates (DV-SSL) and CA Administrative Certificates,
including approval, issuance, usage, validation, revocation, and renewal.
This CP applies to the Certification Authority (CA), Policy Management Authority (PMA), Certificate
Manufacturing Authority (CMA), Certificate Status Authority (CSA), Registration Authority (RA),
Repository, Applicants, Subscribers, and Relying Parties1.
This document also contains the policies ISRG uses to meet the requirements of the CA/Browser Forum
(CA/B Forum), including the CA/B Forum Baseline Requirements for the Issuance and Management of
Publicly Trusted Certificates (CA/B Forum Baseline Requirements) version 1.1.9, as published on August
4, 2014, at https://cabforum.org and the CAB Forum Network Requirements published on January 1, 2013,
at https://cabforum.org/network-security/.
Should any inconsistency arise between the provisions of this CP and the CA/B Forum Baseline
Requirements, the CA/B Forum Baseline Requirements take precedence.
This CP is used along with other documents – most notably, the Certification Practice Statement (CPS) – to
govern the operation of the ISRG PKI.
This Certificate Policy and its corresponding Certification Practice Statement are structured in accordance
with RFC 3647 format and shall be publicly disclosed and available online on a 24x7 basis.
Document Name and Identification
Alphanumeric Identifier
The alphanumeric identifier (i.e., the title) for this CPS is the "ISRG Certificate Practices Statement,
MONTH DAY YEAR" or “isrg-cps-vYEAR DATE MONTH”.
Object Identifier
The following certificate types and OIDs will be recognized for use within the PKI established by this
Policy. The certificate types listed below vary depending upon the identity of the Subscriber (electronic
device or individual). Certificates issued under this Policy will contain in the Certificate Policies field of
the Certificate the applicable OID(s) listed below.
DV SSL Certificate ([insert-isrg owned policy oid]) and (2.23.140.1.2.1) – issued to Subscribers that
demonstrate control of a domain in accordance with Section 3.2.2.
Administrative CA Certificates ([insert-isrg owned policy oid]) – used solely for the management and
operation of the PKI, including device Certificates, individual certificates for Administrators, and others as
needed.
1 One legal entity may perform two or more of these functions.
Page 11
Page 11 of 83
Subordinate CA Certificate (2.23.140.1.2.1) – issued by the Root CA Certificate in accordance with
Section 7 of this CP.
Other Types – as allowed by this Policy and upon approval of the PMA.
The Certificate profiles for these Certificates may be found in appendices and in Section 7, which are
subject to modification from time to time.
PKI Participants
Certification Authority (CA)
The CA is responsible for the creation, maintenance, and enforcement of this CP.
The CA is responsible for all aspects of the creation, issuance, validation, revocation, and management of
Certificates including: (i) the application and enrollment process; (ii) the identification and authentication
process; (iii) the actual Certificate manufacturing process; (iv) publication of the Certificate; (v) revocation
of the Certificate; (vi) renewal of the Certificate; and (vii) ensuring that all aspects of the CA services and
CA operations and infrastructure related to Certificates issued under this Policy are performed in
accordance with the requirements, representations, and warranties of this Policy.
The CA operates a Policy Management Authority (PMA) that reviews and approves this Policy, any
applicable CPS, and revisions to this Policy and each such CPS.
The CA may delegate some or all of these duties to other organizations.
CAs (CAs who have cross-certified or are otherwise authorized to issue Certificates by the PMA) may
enter into arrangements to provide notification of certificate issuance and revocation to each other and to
share other information relevant to the operation of the PKI established by this Policy. The CA must make
an OCSP Responder available to end entities in accordance with Section 4.10. The CA must notify a
Subscriber when a Certificate bearing that Subscriber’s DN is issued or revoked.
The CA will revoke the Certificate for any of the reasons specified in the CA/B Forum Baseline
Requirements.
The CA issues Certificates to Applicants, who may be individuals or organizations.
The CA will issue DV-SSL Certificates to Applicants who control a Fully Qualified Domain Name
(FQDN). A DV-SSL Certificate issued to a Subscriber must contain one or more policy identifier(s),
defined by the CA, in the Certificate’s certificatePolicies extension that indicates adherence to and
compliance with the CAB/F Baseline Requirements. The issuing CA shall document in its Certification
Practice Statement that the DV-SSL Certificates it issues containing the specified policy identifier(s) are
managed in accordance with these CAB/F Baseline Requirements. The CA shall not include a Domain
Name in a Subject attribute except as specified in Sections 9.2.1 and 9.2.2 of the CAB/F Baseline
Requirements.
The CA will issue Administrative Certificates to itself including self-signed subordinate CA Certificates,
and other device Certificates such as OCSP responder Certificates.
In addition, the CA will issue Administrative Certificates to individuals who are employed by or otherwise
affiliated with the CA for the purpose of administering the CA infrastructure.
The CA will require, as part of the Subscriber Agreement or Terms of Use Agreement, that the Applicant
make the commitments and warranties set forth among Section 1.3.4 and Section 9.6.3 of this Policy, for
the benefit of the CA and the Certificate Beneficiaries.
Page 12
Page 12 of 83
The CA will enter a Relying Party Agreement with each Relying Party. The CA will ensure that all Relying
Party Agreements incorporate by reference the provisions of this Policy regarding the CA’s and the Relying
Party’s rights and obligations.
The CA will ensure that is agreements with other PKI Participants incorporate by reference the provisions
of this Policy, or provide the respective contracting parties the protections established by this policy.
Policy Management Authority
The management of ISRG has established a Policy Management Authority (PMA). The purpose of the
PMA is to establish, monitor, and maintain the integrity of this policy and associated public key
infrastructures (PKIs).
The PMA shall develop, implement, enforce, and annually update a Certificate Policy and/or Certification
Practice Statement that describe in detail how the CA implements the CA/B Forum Baseline Requirements,
version 1.1.9.
Registration Authorities (RAs)
The CA shall be ultimately responsible for all Certificates it issues. However, under this Policy, the CA
may subcontract registration and Identification and Authentication (I&A) functions to an organization that
agrees to fulfill the functions of an RA in accordance with the terms of this Policy, and that will accept DV-
SSL Certificate applications and collect and verify Applicant identity information to be entered into a
Certificate. RA functions may also be carried out by a combination of human and/or intelligent
computational automated processes. An RA operating under this Policy is responsible only for those duties
assigned to it by the CA pursuant to an agreement with the CA or as specified in this Policy.
Applicants/Subscribers
In addition to other responsibilities of Applicant/Subscriber set forth in this Policy, Applicant/Subscriber
has the responsibilities set forth below.
1. Provide complete and accurate responses to all requests for information made by the CA (or an RA)
during Applicant registration, Certificate application, and I&A processes; and upon issuance of a
Certificate naming the Applicant as the Subscriber, review the Certificate to ensure that all Subscriber
information included in it is accurate, and to Accept or reject the Certificate in accordance with Section
4.4.
2. If the CA and Subscriber are not Affiliated, the Subscriber and the CA are parties to a legally valid and
enforceable Certificate Agreement that satisfies these Requirements, or, if the CA and Subscriber are
Affiliated, the Applicant Representative acknowledged and accepted the Terms of Use.
3. Generate a Key Pair using a Trustworthy System, and take reasonable precautions to prevent any
compromise, modification, loss, disclosure, or unauthorized use of the Private Key.
4. Use the Certificate and the corresponding Private Key exclusively for purposes authorized by this
Policy and only in a manner consistent with this Policy.
5. Instruct the CA (or an RA) to revoke the Certificate promptly upon any actual or suspected loss,
disclosure, or other compromise of the Private Key.
A Subscriber who is found to have acted in a manner counter to these obligations will have his, her, or its
Certificate revoked, and will forfeit all claims he, she, or it may have against PKI Service Providers.
Except to the extent otherwise specified in this Policy, a Subscriber’s obligations will be governed by the
Terms of Use or the Certificate Agreement between the Subscriber and the CA.
Page 13
Page 13 of 83
The Subscriber Agreement or Terms of Use Agreement must contain provisions imposing on the Applicant
itself (or made by the Applicant on behalf of its principal or agent under a subcontractor or hosting service
relationship) the obligations and warranties set forth below.
1. Accuracy of Information. An obligation and warranty to provide accurate and complete information at
all times to the CA, both in the certificate request and as otherwise requested by the CA in connection
with the issuance of the Certificate(s) to be supplied by the CA.
2. Protection of Private Key. An obligation and warranty by the Applicant to take all reasonable measures
to maintain sole control of, keep confidential, and properly protect at all times the Private Key that
corresponds to the Public Key to be included in the requested Certificate(s) (and any associated
activation data or device, e.g. password or token).
3. Acceptance of Certificate. An obligation and warranty that the Subscriber will review and verify the
Certificate contents for accuracy.
4. Use of Certificate. An obligation and warranty to 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 applicable laws and solely in accordance with the Subscriber or Terms of Use
Agreement.
5. Reporting and Revocation. An obligation and warranty to promptly cease using a Certificate and its
associated Private Key, and promptly request the CA to revoke the Certificate, in the event that: (a)
any information in the Certificate is, or becomes, incorrect or inaccurate, or (b) there is any actual or
suspected misuse or compromise of the Subscriber’s Private Key associated with the Public Key
included in the Certificate.
6. Termination of Use of Certificate. An obligation and warranty to promptly cease all use of the Private
Key corresponding to the Public Key included in the Certificate upon revocation of that Certificate for
reasons of Key Compromise.
7. Responsiveness. An obligation to respond to the CA’s instructions concerning Key Compromise or
Certificate misuse within a specified time period.
8. Acknowledgment and Acceptance. An acknowledgment and acceptance that the CA is entitled to
revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber or Terms
of Use Agreement or if the CA discovers that the Certificate is being used to enable criminal activities
such as phishing attacks, fraud, or the distribution of malware.
Relying Parties
Relying Parties are entities (individuals or organizations) that act in reliance upon a Certificate issued by
the CA. In order to receive benefit from this Policy, Relying Parties must comply with applicable terms and
conditions of this Policy and associated Certification Practices Statement including, but not limited to,
checking the validity of the Certificate through an appropriate OCSP or other reliable response mechanism.
Prior to relying on or using a Certificate issued under this Policy, a Relying Party is obligated to:
1. Ensure that the Certificate and intended use are appropriate under the provisions of this Policy;
2. Use the Certificate only in accordance with the certification path validation procedure specified in
X.509 and PKIX; and
3. Check the status of the Certificate by the OSCP Responder, as applicable, in accordance with the
requirements stated in Section 4.10.
4. For digital signatures created during the Operational Period of a Certificate, a Relying Party has a right
to rely on the Certificate only under circumstances constituting Reasonable Reliance as defined in
Section 1.6 of this Policy.
5. If a Relying Party relies on a Certificate that was expired or that the Relying Party knew or should
have known was revoked at the time of reliance (e.g., a decision to rely on a revoked Certificate based
on the reasons for revocation, information from other sources, or specific business considerations
pertaining to the Relying Party), the Relying Party does so at its own risk and, in so relying, waives
any warranties that any PKI Service Provider may have provided.
In no event shall a Relying Party Agreement waive or otherwise lessen the obligations of a Relying Party
set forth in this Policy. Except to the extent otherwise specified in this Policy, a Relying Party’s obligations
will be governed by the Relying Party Agreement between the Relying Party and the CA.
Page 14
Page 14 of 83
Other Participants
1.3.6.1 Certificate Manufacturing Authority
The CA will remain ultimately responsible for the manufacture of DV-SSL Certificates. However, the CA
may subcontract manufacturing and administrative functions to third party Certificate Manufacturing
Authorities (CMAs) who agree to be bound by this Policy.
1.3.6.2 Repository
The CA will perform the role and functions that require the use of a Repository. The CA may subcontract
performance of the Repository functions to a third party organization, which will be bound by this Policy,
but the CA remains responsible for the performance of those services in accordance with this Policy.
A Repository is responsible for maintaining a secure system for storing and retrieving Certificates, a
current copy, or a link to a current copy, of this Policy, and other information relevant to Certificates, and
for providing information regarding the status of Certificates as valid or invalid that can be determined by a
Relying Party.
The CA maintains a 24 x 7 publicly-accessible Repository with current information regarding the status
(valid or revoked) of all unexpired Certificates.
Certificate Usage
Allowed Certificate Uses
• DV-SSL certificates issued in compliance with this Policy can be used only to establish secure online
communication hosts (as identified by the FQDN provided in the certificate) and clients using
SSL/TLS protocols.
Applications for which Administrative Certificates are suitable include, but are not limited to, applications
that:
• Generation of other Certificates such as DV-SSL, Intermediate CA and device; and
• Administration of software and hardware components within the CA
Prohibited Certificate Uses
DV-SSL Certificates shall not be used for any function or purposes described below in this Section.
1. Any application requiring fail-safe performance such as:
a. The operation of nuclear power facilities;
b. Air traffic control systems;
c. Aircraft navigation systems;
d. Weapons control systems; and
e. Any other system whose failure could lead to injury, death, or environmental damage.
2. Transactions in which applicable law prohibits the use of digital signatures for such transactions.
3. Transactions that are otherwise prohibited by law.
4. Software or hardware architectures that provide facilities for interference with encrypted
communications, including but not limited to:
a. Active eavesdropping (e.g., Man-in-the-Middle [MitM] attacks); and
b. Traffic management of domain names or internet protocol (IP) addresses that the organization
does not own or control
(Note: these restrictions shall apply regardless of whether a relying party communicating
through the software or hardware architecture has knowledge of its providing facilities for
interference with encrypted communications.)
5. Any use other than those explicitly allowed under Section 1.4.1.
Administrative Certificates may not be used for any purpose other than administering the operation of the
CA, RA, CMA, CSA, and Repository infrastructures and related activities.
Page 15
Page 15 of 83
Cross-­Certification
The PMA may approve cross-certification to other Certificate Policies. The CA must inform Subscribers of
the uses allowed within the cross-certified PKI. Any cross-certification to external CPs will only be done
after approval by the PMA or its designee.
If the CA is cross-certifying with another external party, it cannot issue that entity a Subordinate Certificate
unless it is compliant with the CA/B Forum Baseline Requirements and conforms to the CP of the cross-
certifying entity and the requirements therein.
Policy Administration
Organization Administering this Document
This Policy is owned by ISRG and is administered by the PMA.
Contact Person
Questions regarding the implementation and administration of this Policy should be directed to:
Joshua Aas, Executive Director
Internet Security Research Group
331 E. Evelyn Ave.
Mountain View, CA 94041
Person Determining CPS Suitability for the Policy
The PMA will determine the suitability of any CPS to this Policy.
CPS Approval Procedures
The PMA will examine a proposed CPS for compliance with this Policy, and may, at its discretion, consult
with subject matter experts in relation to the suitability of CPS provisions. The PMA will approve or reject
a CPS using procedures outlined in its charter.
Definitions and Acronyms
Capitalized terms used in this Policy have the following meanings:
Definitions
Accept or Acceptance: An act that triggers rights and obligations of an Applicant with respect to its
Certificate under the applicable Certificate Agreement or Relying Party Agreement. Indications of
Acceptance may include: (i) using the Certificate (after issuance); (ii) failing to notify the CA of any
problems with the Certificate within a reasonable time after receiving it, or (iii) other manifestations of
assent. “Accepted” shall have a corollary meaning.
Affiliate: A corporation, partnership, joint venture or other entity controlling, controlled by, or under
common control with another entity, or an agency, department, political subdivision, or any entity
operating under the direct control of a Government Entity. “Affiliated” shall have a corollary meaning.
Applicant: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the
Certificate issues and is Accepted by the Applicant, the Applicant is referred to as the Subscriber. For
Certificates issued to devices, the Applicant is the entity that controls or operates the device named in the
Certificate, even if the device is sending the actual certificate request.
Page 16
Page 16 of 83
Applicant Representative: A natural person or human sponsor who is either the Applicant, employed by
the Applicant, or an authorized agent who has express authority to represent the Applicant who: (i) who
signs and submits, or approves a certificate request on behalf of the Applicant; (ii) signs and submits a
Certificate Agreement on behalf of the Applicant; and/or (iii) acknowledges and agrees to the Terms of Use
applicable to the Certificate on behalf of the Applicant when the Applicant is an Affiliate of the CA.
Application Software Supplier: A supplier of Internet browser software or other relying-party application
software that displays or uses Certificates and incorporates Root Certificates.
CA Certificate: A Certificate at the beginning of a certification chain within the CA’s PKI hierarchy of the
CA. The CA Certificate contains the Public Key that corresponds to the CA Private Signing Key that the
CA uses to create or manage Certificates. CA Certificates and their corresponding Public Keys may be
embedded in software or obtained or downloaded by the affirmative act of a Relying Party in order to
establish a certification chain. Based upon the Certificate’s use, a CA Certificate may be a Root CA
Certificate or a Subordinate CA Certificate.
CA Private Signing Key: The Private Key that corresponds to the CA’s Public Key listed in its CA
Certificate and used to sign other Certificates such as subordinate CA certificates. The CA Private Signing
Key is not used to sign Subscriber Certificates.
CA Private Root Key: The Private Key used to sign CA Certificates.
Certificate: An electronic document that uses a digital signature to bind a Public Key to an identity.
Certificate Agreement: The contract between a Subscriber and the CA and/or RA that details the
procedures, rights, responsibilities, and obligations of each party with respect to a Certificate issued to the
Subscriber.
Certificate Beneficiaries: Each of the following:
o Subscribers;
o All Application Software Suppliers with which a Root CA to which the CA is a
Subordinate CA has entered into a contract for the inclusion of such Root CA’s Root
Certificate in software distributed by such Application Software Supplier; and
o All Relying Parties who have formed Reasonable Reliance with respect to a Valid
Certificate.
Certificate Data: Certificate requests and data related thereto (whether obtained from the Applicant or
otherwise) in the CA’s possession or control or to which the CA has access.
Certificate Management Process: Processes, practices, and procedures associated with the use of keys,
software, and hardware, by which the CA verifies Certificate Data, issues Certificates, maintains a
Repository, and revokes Certificates.
Certificate Manufacturing Authority (CMA): An organization that manufactures or creates Certificates
based on this Policy.
Certificate Policy (CP): A named set of rules that indicates the applicability of Certificates to particular
communities and classes of applications and specifies the Identification and Authentication processes
performed prior to Certificate issuance, the Certificate Profile and other allowed uses of Certificates. This
document is a Certificate Policy.
Certificate Problem Report: Complaint of suspected Key Compromise, Certificate misuse, or other types
of fraud, compromise, misuse, or inappropriate conduct related to Certificates.
Certificate Profile: The protocol used in Section 7 of this Policy to establish the allowed format and
contents of data fields within DV-SSL and Administrative Certificates issued under this Certificate Policy,
Page 17
Page 17 of 83
which identify the CA, the Subscriber, the Validity Period of the Certificate, and other information that
identifies the Subscriber.
Certificate Revocation List: A regularly updated time-stamped list of revoked Certificates that is created
and digitally signed by the CA that issued the Certificates.
Certificate Status Authority (CSA): An organization that uses data in a Repository to provide certificate
revocation status and/or complete certificate path validation (including revocation checking) to the Relying
Parties through Online Certificate Status Protocol or Certificate Revocation List capabilities.
Certification Authority (CA): An organization that is responsible for the creation, issuance, revocation,
and management of Certificates. The term applies equally to both Root CAs and Subordinate CAs. Also
known as a Certificate Authority.
Certification Practice Statement: One of several documents forming the governance framework in which
Certificates are created, issued, managed, and used.
Country: Either a member of the United Nations OR a geographic region recognized as a sovereign nation
by at least two UN member nations.
Cross Certificate: A certificate that is used to establish a trust relationship between two CAs.
Cryptomodule: Secure software, device, or utility that: (i) generates Key Pairs; (ii) stores cryptographic
information; and/or (iii) performs cryptographic functions.
Delegated Third Party: A natural person or Legal Entity that is not the CA but is authorized by the CA to
assist in the Certificate Management Process by performing or fulfilling one or more of the CA
requirements found herein.
Distinguished Name (DN): The unique identifier for a Subscriber so that he, she or it can be located in a
directory (e.g., the DN might contain the following attributes: (i) common name (cn); (ii) e-mail address
(mail); (iii) organization name (o); (iv) organizational unit (ou); (v) locality (l); (vi) state (st); and (vii)
country (c)).
Domain Authorization Document: Documentation provided by, or a CA’s documentation of a
communication with, a Domain Name Registrar, the Domain Name Registrant, or the person or entity listed
in WHOIS as the Domain Name Registrant (including any private, anonymous, or proxy registration
service) attesting to the authority of an Applicant to request a Certificate for a specific Domain Namespace.
Domain Name: The label assigned to a node in the Domain Name System.
Domain Namespace: The set of all possible Domain Names that are subordinate to a single node in the
Domain Name System.
Domain Name Registrant: Sometimes referred to as the “owner” of a Domain Name, but more properly
the person(s) or entity(ies) registered with a Domain Name Registrar as having the right to control how a
Domain Name is used, such as the natural person or Legal Entity that is listed as the “Registrant” by
WHOIS or the Domain Name Registrar.
Domain Name Registrar: A person or entity that registers Domain Names under the auspices of or by
agreement with (i) the Internet Corporation for Assigned Names and Numbers (ICANN), (ii) a national
Domain Name authority/registry, or (iii) a Network Information Center (including their affiliates,
contractors, delegates, successors, or assigns).
Domain Validation: The process of demonstrating control over a Domain by the Applicant or Subscriber.
Page 18
Page 18 of 83
Expiry Date / Expiration Date: The “Not After” date in a Certificate that defines the end of a Certificate’s
validity period.
Fully-Qualified Domain Name (FQDN): A Domain Name that includes the labels of all superior nodes in
the Internet Domain Name System.
High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to
internal criteria and databases maintained by the CA, which may include names at higher risk for phishing
or other fraudulent usage, names contained in previously rejected certificate requests or revoked
Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that
the CA identifies using its own risk-mitigation criteria.
High-Security Zone: An area to which access is controlled through an entry point and limited to
authorized, appropriately screened personnel and properly escorted visitors; which is accessible only from
Security Zones; and which is separated from Security Zones and Operations Zones by a perimeter. High-
Security Zones are monitored 24 hours a day, 7 days a week (24x7) by security staff, other personnel,
and/or electronic means.
Identification and Authentication: The process of validating the identity of an Applicant and confirming
the Applicant’s control over a domain (for DV-SSL Certificates), or confirming the Applicant’s position
within an organization (for Administrative Certificates).
Internal Name: A string of characters (not an IP address) in a Common Name or Subject Alternative
Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of
certificate issuance because it does not end with a Top Level Domain registered in the Root Zone Database
of the Internet Assigned Numbers Authority (IANA).
ISRG Certificate: A Certificate issued pursuant to this Policy.
Issue Certificates/Issuance: The act performed by a CA in creating a Certificate, listing itself as “Issuer”
of that Certificate, and notifying the Applicant of the contents of the Certificate and that the Certificate is
ready and available for Acceptance.
Issuer: The CA that creates a Certificate and makes it available for Acceptance by the Applicant.
Key Compromise: A Private Key is said to be compromised if its value has been disclosed to an
unauthorized person, an unauthorized person has had access to it, or there exists a practical technique by
which an unauthorized person may discover its value. A Private Key is also considered compromised if
methods have been developed that can easily calculate it based on the Public Key (for example, a Debian
weak key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence that the specific method used to
generate the Private Key was flawed.
Key Generation: The process of creating a Key Pair.
Key Pair: The Private Key and its associated Public Key.
Legal Entity: An association, corporation, partnership, proprietorship, trust, government entity or other
entity with legal standing in a country’s legal system.
Man-in-the-Middle Attack (MitM): An attack on an authentication protocol in which the attacker
positions himself or herself in between the claimant and verifier so that he or she can intercept and alter
data traveling between them.
Object Identifier (OID): A unique alphanumeric or numeric identifier registered under the International
Organization for Standardization’s applicable standard for a specific object or object class.
Page 19
Page 19 of 83
OCSP Responder: An online server operated under the authority of the CA and connected to its
Repository for processing Certificate status requests. See also Online Certificate Status Protocol.
Online Certificate Status Protocol (OCSP): An online Certificate-checking protocol that enables relying-
party application software to determine the status of an identified Certificate. See also OCSP Responder.
Operational Period: A Certificate’s actual term of validity, beginning with the start of the Validity Period
and ending on the earlier of (i) the end of the Validity Period disclosed in the Certificate, or (ii) the
revocation of the Certificate.
Operations Zone: An area where access is limited to personnel who work there and to properly escorted
visitors. Operations Zones should be monitored at least periodically and should preferably be accessible
only from a Reception Zone.
PKI Service Providers: The PMA, RAs, CMAs, CSAs, and Repositories participating in the PKI defined
by this Policy.
Policy: This Certificate Policy.
Policy Management Authority (PMA): A group within a CA that is responsible for setting,
implementing, and administering policy decisions regarding the CA, including but not limited to those
related to its Certificate Policy and Certification Practices Statement.
Private Key: The key of a Key Pair that is kept secret by the holder of the Key Pair, and that is used to
create digital signatures and/or to decrypt electronic records or files that were encrypted with the
corresponding Public Key.
Public Key: The key of a Key Pair publicly disclosed by the holder of the corresponding Private Key and
used by the recipient to validate digital signatures created with the corresponding Private Key and/or to
encrypt messages or files to be decrypted with the corresponding Private Key.
Public Key Infrastructure (PKI): A set of hardware, software, people, procedures, rules, policies, and
obligations used to facilitate the trustworthy creation, issuance, management, and use of Certificates and
keys based on Public Key cryptography.
Publicly Trusted Certificate: A Certificate that is trusted by virtue of the fact that its corresponding Root
Certificate is distributed as a trust anchor in widely-available application software such as browsers.
Qualified Auditor: A natural person or Legal Entity that meets the requirements of Section 8 (Auditor
Qualifications).
Reception Zone: A zone that is accessible by the public and from which access may be gained to higher
security zones with appropriate security controls.
Reasonable Reliance: For purposes of this Policy, a Relying Party’s decision to rely on an ISRG
Certificate will be considered “Reasonable Reliance” if he, she, or it:
• Has entered into a Relying Party Agreement and agreed to be bound by the terms and conditions
of this Policy;
• Verified that the digital signature in question (if any) was created by the Private Key
corresponding to the Public Key in the Certificate during the time that the Certificate was valid,
and that the communication signed with the digital signature had not been altered;
• Verified that the Certificate in question was valid at the time of the Relying Party’s reliance, by
conducting a status check of the Certificate’s then-current validity as required by the CA; and
• Used the Certificate for purposes appropriate under this Policy and under circumstances where
reliance would be reasonable and in good faith in light of all the circumstances that were known or
should have been known to the Relying Party prior to reliance. (A Relying Party bears all risk of
Page 20
Page 20 of 83
relying on the Certificate while knowing or having reason to know of any facts that would cause a
person of ordinary business prudence to refrain from relying on the Certificate).
Registered Domain Name: A Domain Name that has been registered with a Domain Name Registrar.
Registration Authority (RA): Any Legal Entity that is responsible for identification and authentication of
subjects of Certificates, but is not a CA, and hence does not sign or issue Certificates. An RA may assist in
the certificate application process or revocation process or both. When “RA” is used as an adjective to
describe a role or function, it does not necessarily imply a separate body, but can be part of the CA.
Reliable Data Source: An identification document or source of data used to verify Subject Identity
Information that is generally recognized among commercial enterprises and governments as reliable, and
which was created by a third party for a purpose other than the Applicant obtaining a Certificate.
Reliable Method of Communication: A method of communication, such as a postal/courier delivery
address, telephone number, or email address, that was verified using a source other than the Applicant
Representative.
Relying Party: Any natural person or Legal Entity that relies on a Valid Certificate. An Application
Software Supplier is not considered a Relying Party when software distributed by such Supplier merely
displays information relating to a Certificate.
Relying Party Agreement: An agreement between CA and a Relying Party setting forth the terms and
conditions governing reliance or other permitted use by the Relying Party on an ISRG Certificate, which
such agreement details the procedures, rights, responsibilities, and obligations of each of CA and Relying
Party.
Repository: An online database containing publicly-disclosed PKI governance documents (such as
Certificate Policies and Certification Practice Statements) and Certificate status information, either in the
form of a CRL or an OCSP response.
Reserved IP Address: An IPv4 or IPv6 address that the IANA has marked as reserved, as shown in the
following references:
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml
Restricted Zones: Any one of (i) an Operations Zone; (ii) a Security Zone; and (iii) a High Security Zone.
Revocation: The act of making a Certificate permanently ineffective from a specified time forward.
Revocation is effected by notation or inclusion in a set of revoked Certificates or other directory or
database of revoked Certificates.
Root Certificate Authority: The top level Certification Authority whose Root Certificate is distributed by
Application Software Suppliers and that issues Subordinate CA Certificates. The Root CA also protects the
CA Private Signing Key.2
Root Certificate: The self-signed Certificate issued by the Root CA to identify itself and to facilitate
verification of Certificates issued to its Subordinate CAs.
Security Zone: An area to which access is limited to authorized personnel and to authorized and properly
escorted visitors. Security Zones should preferably be accessible from an Operations Zone, and through a
specific entry point. A Security Zone need not be separated from an Operations Zone by a secure perimeter.
2 The CA/B Forum Baseline Requirements define a Root CA as a “top level Certification Authority whose Root
Certificate is distributed by Application Software Providers and that issues Subordinate CA Certificates.” The
definition used for this Policy does not include the requirement for distribution by Application Software Providers,
which include browser makers.
Page 21
Page 21 of 83
A Security Zone should be monitored 24 hours a day and 7 days a week by security staff or other
personnel, or electronic means.
Split-Knowledge Technique: A security procedure where no single individual possesses the equipment,
knowledge or expertise to view, alter or otherwise have access to sensitive or confidential information in a
particular PKI.
Subject: The natural person, device, system, unit, or Legal Entity identified in a Certificate as the Subject.
The Subject is either the Subscriber or a device under the control and operation of the Subscriber.
Subject Identity Information: Information that identifies the Certificate Subject. Subject Identity
Information does not include a domain name listed in the subjectAltName extension or the Subject
commonName field.
Subordinate CA Certificate: A Certificate that is signed by a Root CA and subsequently listed in the
Certificate chain. Subordinate CA Certificates and their corresponding Public Keys may be embedded in
software or obtained or downloaded by the affirmative act of a Relying Party in order to establish a
certification chain within the ISRG PKI hierarchy.
Subordinate CA: A Certification Authority whose Certificate is signed by the Root CA, or another
Subordinate CA.
Subscriber: A natural person or Legal Entity to whom a Certificate is issued and who is legally bound by a
Certificate Agreement or Terms of Use Agreement.
Technically Constrained Subordinate CA Certificate: A Subordinate CA certificate that uses a
combination of Extended Key Usage settings and Name Constraint settings contained within the Certificate
to limit the scope within which the Subordinate CA Certificate may issue Subscriber or additional
Subordinate CA Certificates.
Terms of Use: Provisions regarding the safekeeping and acceptable uses of a Certificate issued in
accordance with these Requirements.
Trusted Role: A role involving functions that may introduce security problems if not carried out properly,
whether accidentally or maliciously. The functions of Trusted Roles form the basis of trust for the entire
PKI.
Trustworthy System: Computer hardware, software, and procedures that are (i) reasonably secure from
intrusion and misuse; (ii) provide a reasonable level of availability, reliability, and correct operation; (iii)
are reasonably suited to performing their intended functions; and (iv) enforce the applicable security policy.
Unregistered Domain Name: A Domain Name that is not a Registered Domain Name.
Valid Certificate: A Certificate that passes the validation procedure specified in RFC 5280.
Validity Period: The period of time measured from the date when the Certificate is issued until the Expiry
Date.
Wildcard Certificate: A Certificate containing an asterisk (*) in the left-most position of any of the
Subject Fully-Qualified Domain Names contained in the Certificate.
Acronyms
CA
Certification Authority
CMA
Certificate Manufacturing Authority
CPS
Certification Practice Statement
CRL
Certificate Revocation List
Page 22
Page 22 of 83
CSA
Certificate Status Authority
DN
Distinguished Name
DSA
Digital Signature Algorithm
DV
Domain Validated
FQDN
Fully Qualified Domain Name
I&A
Identification and Authentication
ISO
International Standards Organization
OID
Object Identifier
PKI
Public Key Infrastructure
PMA
Policy Management Authority
RA
Registration Authority
SSL
Secure Sockets Layer
X.500
The ITU-T (International Telecommunication Union-T) standard that establishes a
distributed, hierarchical directory protocol organized by country, region, organization,
etc.
X.501
The ITU-T (International Telecommunication Union-T) standard for use of Distinguished
Names in an X.500 directory.
X.509 The ITU-T (International Telecommunication Union-T) standard for Certificates. X.509, version 3, refers
to Certificates containing or capable of containing extensions.
Page 23
Page 23 of 83
2 Publication and Repository Responsibilities
Repositories
The CA and CSA shall be responsible for maintaining an online 24x7 Repository that application software
can use to automatically check the current status of all unexpired Certificates issued by the CA. The CA
and CSA shall support an OCSP capability using the GET method for each Certificate issued.
The Repository shall not include entries that indicate that a Certificate is suspended. Suspension is not
permitted under this Certificate Policy.
Publication of Certification Information
Publication of CA Information
Each CA and CSA will operate or cause the operation of one or more secure online Repositories that are
available to Relying Parties and that contain (i) issued Certificates; (ii) an online Certificate status database
(or both); (iii) the CA’s CA Certificate for its CA Private Signing Key; (iv) past and current versions of the
CA’s CPS; (v) a copy of this Policy; and (vi) other relevant information relating to Certificates.
Interoperability
The CA shall disclose all Cross Certificates that identify the CA as the Subject, provided that the CA
arranged for or accepted the establishment of the trust relationship (i.e. the Cross Certificate at issue).
Time or Frequency of Publication
The Certificates in this Policy shall be published following Acceptance by the Applicant (who is thereafter
a Subscriber) in accordance with the procedure specified in Section 4.3. If the CA elects to publish CRLs,
the CRLs will be published as specified in Section 4.10.
Access Controls on Repositories
The CA will not impose any access controls on
• This Policy;
• The CA’s CA Certificate; or
• Past and current versions of the CA’s CPS.
The CA and CSA may impose access controls on Certificates and Certificate status information, in
accordance with provisions of this Policy.
Page 24
Page 24 of 83
3 Identification and Authentication
Naming
Types of Names
By issuing the Certificate, the CA represents that it followed the requirements set forth in the following
Sections to verify that, as of the Certificate’s issuance date, all of the Subject information was accurate. For
Certificates other than DV-SSL, The CA shall generate and sign Certificates that contain non-null
Distinguished Names (DNs). CAs shall not include a Domain Name in a Subject attribute except as
specified below. Certificates may also include alternative name forms.
For CA (Root and Subordinate)
All CAs shall include non-null Subject or Issuer DNs.
For the Root CA Certificate, the Issuer DN shall include the name of the organization and country that
operates the CA at the time of issuance. The issuer DN may include the common name of the CA that
clearly identifies it. This common name can be expressed as a sequence of words, or as all the components
of the CA’s Registered Domain Name.
The Issuer and Subject DN for a Root CA Certificate will be the same. The Issuer DN of a subordinate CA
shall be its Issuer’s subject DN.
For DV-SSL
The Issuer DN of a DV-SSL Certificate shall be its Issuer’s subject DN.
CAs shall include FQDNs or IP Addresses of the Device in the subject Alternative Name extension. The
Subject Alternative Name extension may contain more than one instance of the name form. CAs may
include a FQDN or IP Address in the subject DN for backwards compatibility, but this name shall be also
included in the Subject Alternative Name extension.
Wildcard names are not permitted.
CA shall not issue a Certificate with a subjectAlternativeName extension or Subject commonName field
containing a Reserved IP Address or Internal Name.
If the subject Domain Component field is populated, this field must contain a label from a Domain Name.
The domainComponent fields for each Domain Name must be in a single ordered sequence containing all
labels from the Domain name. The labels must be encoded in the reverse order to the on-wire
representation of domain names in the DNS protocol, so that the label closest to the root is encoded first.
The CA must ensure that the certificate is issued with the consent of, and according to procedures
established by, the owner of each Domain Name.
CAs shall not include the address, locality, province/state, or postal code fields if the verified name of
organization is not present.
CAs may include the two-letter ISO 3166-1 country code associated with the location of the Subject, as
long as it is verified in accordance Section 3.2.2.4.
Any additional attribute in the subject DN may be populated as long as the information has been verified by
the CA. Optional attributes shall not contain metadata indicating that the value is absent, incomplete or not
applicable.
Page 25
Page 25 of 83
For human Administrative Certificates
The issuer DN of an administrative Certificate shall be its issuer’s subject DN.
The subject DN shall include the Applicant’s full name, the CA organization’s name, sub-organization, and
the two-letter ISO 3166-1 country code associated with the location of the Applicant, and the words
“Administrative Certificate.” The Subject Alternative Name extension will include the Applicant’s verified
email.
For device Administrative Certificates (e.g. OCSP Signers)
The Issuer DN of an administrative Certificate shall be its issuer’s Subject DN.
The Subject DN may include the common name of the Device. This common name can be expressed as a
sequence of words, or as all the components of the CA’s Registered Domain Name. In addition, the CA
organization’s name, and the two-letter ISO 3166-1 country code associated with the location of the
Device.
The Subject Alternative Extension shall include the Device’s FQDN.
Need for Names To Be Meaningful
The contents of each Certificate Subject Alternative Name extension must have an association with the
authenticated name of the Subscriber. A Certificate issued for an electronic device must include the
authenticated name of the electronic device.
An Administrative Certificate issued to an individual must contain the authenticated common name – a
combination of first name, surname, and optionally initials.
Anonymity or Pseudonymity of Subscribers
The subject name used for DV-SSL Certificates shall be the Subscriber’s authenticated domain name. Each
Subscriber must have a clearly distinguishable and unique X.501 Distinguished Name (“DN”) in the
Certificate subject name field and in accordance with RFC 5280. The DN must be in the form of an X.501
printable string and must not be blank.
Rules for Interpreting Various Name Forms
The CA may defer to a naming authority for guidance on name interpretation and subordination.
Uniqueness of Names
The Subject Name listed in a Certificate shall be unambiguous and unique for all Certificates issued by the
CA and shall conform to X.500 standards for name uniqueness.
If necessary, additional numbers or letters may be appended to the real name to ensure the name’s
uniqueness within the domain of Certificates issued by the CA for Administrative Certificates. No wildcard
name forms shall be allowed. Each name shall be unique and for a single unique entity.
Recognition, Authentication, and Role of Trademarks
3.1.6.1 Name Claim Dispute Resolution Procedure
The CA should reserve the right to make all decisions regarding Subscriber names in Certificates. A party
requesting a Certificate may be required to demonstrate its right to use a particular name. The CA will
investigate and correct if necessary any name collisions brought to its attention. If appropriate, the CA will
coordinate with and defer to the appropriate naming authority.
Page 26
Page 26 of 83
Initial Identity Validation
Method to Prove Possession of Private Key
Applicants are required to prove possession of the Private Key corresponding to the Public Key in a
Certificate request, which may be done by signing the request with the Private Key. The CA shall establish
that the Applicant is in possession of the Private Key corresponding to the Public Key submitted with the
application in accordance with an appropriate secure protocol.
Authentication of Domains and Administrative Certificates
The issuance of a DV-SSL or Administrative Certificate will be based on I&A performed by the CA or RA
using procedures that shall be documented in the CPS. The number and types of identification documents
(IDs), the process documentation and the authentication requirements for issuance of a DV-SSL Certificate
are listed below.
3.2.2.1 Acceptable Forms of Identification Documents for Applicants
For DV-SSL Certificates and for administrative Certificates issued for devices, the CA shall provide a
secure means of validating the Applicant’s control over the device and domain name for which a Certificate
is requested. The means of validating such control shall be consistent with the relevant CA/B Forum
Baseline Requirements. For domain ownership, the validation shall consist of comparison of the
Applicant’s submitted information with a domain registration database; for example, through a WHOIS
inquiry.
For Administrative Certificates issued to individuals, the CA shall provide a secure means of validating the
identity of the Applicant; such means shall include satisfactory proof of organizational affiliation with the
Human Resources department of the CA.
The requirements for renewal of Certificates shall be the same as those above.
3.2.2.2 Performance of Electronic Identification
For each Name listed in a DV-SSL Certificate, the CA shall confirm that, as of the date the Certificate was
issued, the Applicant (or the Applicant’s Parent Company, Subsidiary Company, or Affiliate, collectively
referred to as “Applicant” for the purposes of this Section) either is the Domain Name Registrant or has
control over the FQDN by:
1. Confirming the Applicant as the Domain Name Registrant directly with the Domain Name Registrar;
2. Communicating directly with the Domain Name Registrant using an address, email, or telephone
number provided by the Domain Name Registrar;
3. Communicating directly with the Domain Name Registrant using the contact information listed in the
WHOIS record’s “registrant,” “technical,” or “administrative” field;
4. Communicating with the Domain’s administrator using an email address created by pre-pending
“admin,” “administrator,” “webmaster,” “hostmaster,” or “postmaster” in the local part, followed by
the at-sign (“@”), followed by the Domain Name, which may be formed by pruning zero or more
components from the requested FQDN;
5. Relying upon a Domain Authorization Document;
6. Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change
to information found on an online Web page identified by a uniform resource identifier containing the
FQDN; or
7. Using any other method of confirmation, provided that the CA maintains documented evidence that the
method of confirmation establishes that the Applicant is the Domain Name Registrant or has control
over the FQDN to at least the same level of assurance as those methods previously described.
Page 27
Page 27 of 83
Note: For purposes of determining the appropriate domain name level or Domain Namespace, the
registerable Domain Name is the second-level domain for generic top-level domains (gTLD) such as .com,
.net, or .org, or, if the Fully Qualified Domain Name contains a 2 letter Country Code Top-Level Domain
(ccTLD), then the domain level is whatever is allowed for registration according to the rules of that ccTLD.
If the CA relies upon a Domain Authorization Document to confirm the Applicant’s control over a FQDN,
then the Domain Authorization Document must substantiate that the communication came from either the
Domain Name Registrant (including any private, anonymous, or proxy registration service) or the Domain
Name Registrar listed in the WHOIS. The CA must verify that the Domain Authorization Document was
either (i) dated on or after the certificate request date or (ii) used by the CA to verify a previously issued
certificate and that the Domain Name’s WHOIS record has not been modified since the previous
certificate’s issuance.
3.2.2.3 gTLD Domain Validation
The CA will not issue Certificates containing a new gTLD under consideration by ICANN. Prior to issuing
a Certificate containing an Internal Name with a gTLD that ICANN has announced as under consideration
to make operational, the CA will provide a warning to the applicant that the gTLD may soon become
resolvable and that, at that time, the CA will revoke the Certificate unless the applicant promptly registers
the domain name.
Within 30 days after ICANN has approved a new gTLD for operation, as evidenced by publication of a
contract with the gTLD operator on [www.ICANN.org] each CA must (1) compare the new gTLD against
the CA’s records of valid certificates and (2) cease issuing Certificates containing a Domain Name that
includes the new gTLD until after the CA has first verified the Subscriber's control over or exclusive right
to use the Domain Name in accordance with the CA/B Forum Baseline Requirements.
Within 120 days after the publication of a contract for a new gTLD is published on [www.icann.org], the
CA must revoke each Certificate containing a Domain Name that includes the new gTLD unless the
Subscriber is either the Domain Name Registrant or can demonstrate control over the Domain Name.
3.2.2.4 Country Name Field Validation
If the subject:countryName field is present, then the CA will verify the country associated with the Subject
using one of the following: (a) the IP Address range assignment by country for either (i) the web site’s IP
address, as indicated by the DNS record for the web site or (ii) the Applicant’s IP address; (b) the ccTLD of
the requested Domain Name; (c) information provided by the Domain Name Registrar; or (d) a method
identified in the CA/B Forum Baseline Requirements. The CA will implement a process to screen proxy
servers in order to prevent reliance upon IP addresses assigned in countries other than where the Applicant
is actually located.
3.2.2.5 IP Address Validation
The CA will not issue certificates for IP Addresses.
Non-­Verified Subscriber Information
Information that is not verified in accordance with the appropriate I&A outlined in Section 3 of this CP and
the corresponding CPS, shall not be placed in a Certificate.
Page 28
Page 28 of 83
Validation of Authority
For DV-SSL Certificates, demonstration of control over the device and domain may be conducted
electronically and if used shall consist of validation of the information presented as described above. If the
Applicant cannot demonstrate control, validation of authority will be verified through a check to an
alternative source as listed in Section 3.2.2.
For Administrative Certificates issued to individuals, the information submitted by the Applicant shall
consist of at least the following items:
1. Full name; and
2. Validation from the Human Resources department of the CA that confirms affiliation to the CA.
3.2.4.1 Verification against the Denied List
In accordance with the CA/B Forum Baseline Requirements, the CA shall maintain an internal database of
all previously revoked Certificates and previously rejected certificate requests due to suspected phishing or
other fraudulent usage or concerns. The CA shall use this information to identify subsequent suspicious
certificate requests.
3.2.4.2 Verification against High Risk Certificate Requests
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 are properly verified.
3.2.4.3 Data Source Accuracy
Prior to using any data source as a Reliable Data Source, the CA shall evaluate the source for its reliability,
accuracy, and resistance to alteration or falsification. The CA shall 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; and
5. The relative difficulty in falsifying or altering the data.
Databases maintained by the CA, its owner, or its affiliated companies do not qualify as a Reliable Data
Source if the primary purpose of the database is to collect information for the purpose of fulfilling the
validation requirements under the CA/B Forum Baseline Requirements.
Criteria for Interoperation
This Policy allows for cross-certification with other PKIs. Criteria for cross-certification includes review
and approval of this Policy and its associated CPS by the PMA of the PKI for which cross-certification is
desired, and review and of the cross-certifying PKI’s CP and CPS by the CA’s PMA. Upon approval by
both PMAs, cross-certification may be accomplished.
Authentication of Device Identity
A DV-SSL Certificate request identifying an electronic device as the subject of a Certificate may only be
made by a human sponsor demonstrating control of the device and affiliation with the domain, as described
in Section 3.2.2 above.
When issuing this type of Certificate, the CA shall conform to the following standards:
Page 29
Page 29 of 83
1. The “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates,”
version 1.1.9, published at http://www.cabforum.org. In the event of any inconsistency between this
CP and those requirements, the requirements will take precedence over this document. This type of
Certificate can only be issued by an CA that can ensure accomplishment of the I&A required by this
Section; and
2. The CA/B Forum Network requirements.
Throughout this CP and the corresponding CPS, references from either document will be specified to
indicate which requirements were satisfied with the content.
Authentication of Other Certificates
This policy has no stipulation for other Certificates.
Identification and Authentication (I&A) for Rekey and Renewal
Identification and Authentication for Rekey Requests
Rekey is not supported by this policy.
Identification and Authentication for Rekey after Revocation
Rekey is not supported by this policy.
Certificate Renewal
Renewing a Certificate means creating a new Certificate with the same name, Public Key, and
authorizations as the old one, but a new Validity Period and a new serial number. A Certificate may be
renewed without performing I&A if:
• It has not been revoked;
• The Key Pair has not reached the end of its validity;
• The Private Key has not been compromised;
• The data used for the renewal has not reached more than 39 months in age; and
• The Subscriber name and attributes are correct.
Certificate Update
Certificate update is not permitted under this Policy.
Renewal or Update of Affiliated Individual’s Certificate
Renewal or update of the Administrative Certificate of an affiliated individual will require that the
affiliation between the affiliated individual and his or her sponsoring organization still exists.
I&A for Revocation and Suspension Requests
A Subscriber may request revocation of his, her, or its Certificate at any time for any reason. The CA, when
faced with such a request, must adopt authentication mechanisms that balance the need to prevent
unauthorized requests against the need to quickly revoke Certificates When a revocation request is
electronically submitted, the identity of the requestor may be authenticated on the basis of the digital
signature used to submit the message. If the request is signed using the Private Key corresponding to the
requestor’s Public Key, such a request shall be accepted as valid.
Page 30
Page 30 of 83
Revocation requests submitted by other than digitally signed request shall require verification of the
requestor’s identity if the Revocation is meant for an Administrative Certificate or control of the device or
domain for a DV-SSL Certificate. This can be done through completing a verification of the same
information provided during initial registration, or other alternative information that was used during that
process.
Suspension of an SSL Certificate shall not be permitted as per the requirements listed in the CA/B Forum
Baseline Requirements Section 13.2.7.
Page 31
Page 31 of 83
4 Certificate Life Cycle Operational Requirements
Certificate Application
This Policy endorses the following procedures for satisfying the security requirements of this PKI. The
following steps are required when applying for a Certificate: (i) establish identity of subject (per Section 3);
(ii) obtain a Key Pair for each Certificate required; (iii) prove to the CA that the Public Key forms a
functioning Key Pair with the Private Key held by the Subscriber; and (iv) provide a point of contact for
verification of any roles or authorizations requested.
Prior to the issuance of a Certificate, the CA shall obtain the following documentation from the Applicant:
1. A certificate request, which may be electronic; and
2. An executed Subscriber or Terms of Use Agreement, which may be electronic.
The CA obtains any additional documentation that it determines necessary to meet the requirements.
Prior to the issuance of a Certificate, the CA shall obtain from the Applicant a certificate request in a form
prescribed by the CA and that complies with this policy and the CA/B Forum Baseline Requirements. One
certificate request may suffice for multiple Certificates to be issued to the same Applicant, subject to the
aging and updating requirement in the CA/B Forum Baseline Requirements, provided that each Certificate
is supported by a valid, current certificate request signed by the appropriate Applicant Representative on
behalf of the Applicant. The certificate request may be made, submitted, and/or signed electronically.
The certificate request must contain a request from, or on behalf of, the Applicant for the issuance of a
Certificate, and a certification by, or on behalf of, the Applicant that all of the information contained
therein is correct.
Who Can Submit a Certificate Application
An application for a DV-SSL Certificate may be made by an individual acting on behalf of himself or
herself, or by an individual acting on behalf of an organization. Applications may also be generated by
machines acting on behalf or individuals or organizations.
An application for an individual’s Administrative Certificate may be made by the individual acting on
behalf of himself or herself; or by an individual acting on behalf of another, as long as that individual can
demonstrate organizational affiliation and authority to do so.
Enrollment Process and Responsibilities
Applicants will complete a Certificate application and provide requested information in a form prescribed
by the CA in accordance with this Policy. An Applicant must also enter into a Certificate Agreement with
the CA. All applications are subject to review, approval, and acceptance by the CA.
Certificate Application Processing
Performing Identification and Authentication Functions
For domain-validated device Certificates, the CA shall validate the Applicant’s ownership of, or control
over, the device and domain name for which a Certificate is requested, using processes that are consistent
with the relevant CA/B Forum Baseline Requirements. For domain ownership, the validation shall be
conform to the requirements as listed in Section 3.2.2.2, “Electronic Identification.”
Page 32
Page 32 of 83
For Administrative Certificates issued to individuals, the CA shall provide a secure means of validating the
identity of the Applicant; such means shall include satisfactory proof of identity from the Human Resources
Department of the CA and proof of organizational affiliation with the CA.
The requirements for renewal of Certificates shall be the same as those above.
The certificate request may include all factual information about the Applicant to be included in the
Certificate, and such additional information required from the Applicant as is necessary for the CA to
comply with this Policy, the corresponding CPS, and the CA/B Forum Baseline Requirements. In cases
where the certificate 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.
Approval or Rejection of Certificate Applications
Certificate applications shall be approved or rejected within 30 days of application receipt by the CA, or
such other period that is compliant with the CA/B Forum Baseline Requirements.
Time to Process Certificate Application
The time required to process a Certificate application shall be consistent with the time requirement for
acceptance or rejection.
Certificate Issuance
After all application and approval processes identified in this Policy are completed, the CA will: (i) issue
the requested Certificate; (ii) notify the Applicant of the Certificate’s issuance; and (iii) make the
Certificate available to the Applicant for Acceptance. The procedures for notifying the Applicant of the
Certificate’s issuance, and the procedure used to deliver or make the Certificate available to the Applicant
must be secure and confidential, and must comply with the applicable portions of the CA/B Forum Baseline
Requirements.
CA Actions during Certificate Issuance
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 Certificate Agreement; or
2. The Applicant’s agreement to the Terms of Use agreement.
The CA shall implement a process to ensure that each Certificate Agreement or Terms of Use Agreement is
legally enforceable against the Applicant. In either case, the Agreement must apply to the Certificate to be
issued pursuant to the certificate request. The CA may use an electronic or “click-through” agreement,
provided that the CA has determined that such agreements are legally enforceable. A separate agreement
may be used for each certificate request, or a single agreement may be used to cover multiple future
certificate requests and the resulting Certificates, so long as each Certificate that the CA issues to the
Applicant is clearly covered by that Certificate Agreement or Terms of Use Agreement.
Nothing in the Certificate Agreements may waive or otherwise lessen the obligations of the Subscriber as
set forth in this Policy.
Page 33
Page 33 of 83
Notification to Subscriber by the CA of Issuance of the Certificate
Notification of Certificate issuance to others may be effected by publication of the Certificate in a
recognized Repository.
Certificate Acceptance
An Applicant’s Acceptance of its Certificate will be a precondition to its use of such Certificate. The CA
will define in its agreements with Applicants and Subscribers (or in its CPS, if incorporated by reference in
its agreements with Applicants and Subscribers) the procedure(s) that constitute(s) Acceptance by an
Applicant. By Accepting a Certificate, the Applicant / Subscriber warrants that all of the information
provided by it (and by its sponsoring organization, where applicable) and included in the Certificate, and all
representations made by the Applicant (and by its sponsoring organization, where applicable) as part of the
application and I&A process, are true and not misleading.
Conduct Constituting Certificate Acceptance
The following conduct constitutes certificate acceptance:
• Downloading a Certificate or installing a Certificate from a message attaching it; or
• Failure of the Subscriber to object to the Certificate or its content.
Publication of the Certificate by the CA
The CA and CSA shall publish the Certificates issued as described in Section 4.3 in a publicly accessible
Repository.
Notification of Certificate Issuance by the Authorized CA to Other Entities
Notification of Certificate issuance to others may be done by publication of the Certificate in a recognized
Repository.
Key Pair and Certificate Usage
Certificates may not be used for purposes counter to the principles and applications outlined in this Policy.
Subscriber Private Key and Certificate Usage
Use of the Private Key corresponding to the Public Key in the Certificate shall only be permitted after
Subscriber has agreed to the Certificate Agreement and accepted the Certificate. The Certificate shall be
used lawfully in accordance with the Certificate Agreement, the terms of this CP, and the relevant CPS.
Certificate use must be consistent with the KeyUsage field extensions included in the Certificate.
Subscribers shall protect their private keys from unauthorized use and shall discontinue use of the Private
Key following expiration or revocation of the Certificate. Parties other than the Subscriber shall not archive
the Subscriber Private Key except as set forth in Section 4.12.
Relying Party Public Key and Certificate Usage
Relying Parties shall rely a Certificate only for those uses specified in the KeyUsage field of the Certificate.
Relying Parties shall not rely on a Certificate that has been revoked or that has expired.
If any of the Certificates in the Certificate Chain have been revoked, the Relying Party is solely responsible
to investigate whether prior reliance on the Certificate is reasonable. If circumstances indicate that
additional assurance is required, the Relying party must obtain such assurances before using the Certificate.
Any such reliance is made solely at the risk of the Relying Party.
Page 34
Page 34 of 83
Assuming that the use of the Certificate is appropriate, Relying Parties shall use software that is compliant
with X.509 and applicable IET PKIX standards. Such operations include identifying a Certificate Chain
and verifying the digital signatures on all Certificates in the Certificate Chain. The CA and CSA shall
specify the mechanism(s) used to determine the validity of a Certificate (e.g., OCSP), and shall acquire,
process, and use this information in accordance with their obligations as Relying Parties.
Certificate Renewal
Circumstance for Certificate Renewal
A certificate may be renewed if:
1. It has not been revoked for reasons of key compromise; and
2. It has not yet reached its expiry date; and
3. The renewal period is in force; and
4. No information contained within the certificate, including the Public Key, has changed.
Who May Request Renewal
Only the Subscriber may request a Certificate Renewal. For DV-SSL Certificates, this may be done
electronically or by other means in which the Subscriber’s identity, ownership or control over the domain,
and ownership or control over the device may be verified. For Administrative Certificates, this may be
done electronically or by other means in which the Subscriber’s identity and affiliation with the CA may be
verified.
Processing Certificate Renewal Requests
All Renewal requests shall be validated by the CA to ensure that the circumstances for Renewal are met.
Such validation shall be in compliance with the CA/B Forum Baseline Requirements.
Conduct Constituting Acceptance of a Renewal Certificate
As with Acceptance of any other Certificate the following conduct constitutes acceptance of a Renewal
Certificate:
• Downloading a Certificate or installing a Certificate from a message attaching it; or
• Failure of the Subscriber to object to the certificate or its content.
Publication of the Renewal Certificate by the CA
The CA and CSA shall publish the Certificates issued in a publicly accessible Repository.
Notification of Certificate Issuance by the Authorized CA to Other Entities
The notification procedures used by the CA shall be the same as with a new Certificate.
Certificate Rekey
Circumstances for Certificate Rekey
Rekey is not supported by this policy.
Who May Request a Rekey
Rekey is not supported by this policy.
Page 35
Page 35 of 83
Processing Certificate Rekeying Requests
Rekey is not supported by this policy.
Notification of New Certificate Issuance to Subscriber
Rekey is not supported by this policy.
Conduct Constituting Acceptance of a Rekeyed Certificate
Rekey is not supported by this policy.
Notification of Certificate Issuance by the Authorized CA to Other Entities
Rekey is not supported by this policy.
Modification
Updating a Certificate means creating a new Certificate that has the same or a different key, a different
serial number, and differs in one or more fields, from the old Certificate.
The CA shall authenticate the request for the Certificate modification using the same means for the initial
I&A in Section 3.2.
If the CA needs to modify the Root CA Certificate to update its Private Signature Key and generates a new
Public Key, the new trust anchor shall be provided to all CAs, RAs, and Subscribers.
Circumstances for Certificate Modification
A Certificate may be modified at the request of a Subscriber that can fulfill the I&A requirements of
Section 3.2 at any time during the life of the Certificate.
Who May Request Certificate Modification
The Subscriber may request the modification of their Certificate. The CA or RA shall verify any requested
changes for the modification of the Subscriber Certificate.
Processing Certificate Modification Requests
The Certificate modification process shall be in accordance with Certificate Issuance and I&A as specified
in Section 3.2. The CA or RA shall validate any changes in the Subscriber authorizations in the Certificate
most specifically the FQDN as listed in DV-SSL Certificates.
Notification of New Certificate Issuance to Subscriber
See Section 4.3.2.
Conduct Constituting Acceptance of Modified Certificate
See Section 4.4.1.
Publication of the Modified Certificate by the CA
See Section 4.4.2.
Notification of Certificate Issuance by the CA to other Entities
See Section 4.4.3.
Certificate Revocation and Suspension
Page 36
Page 36 of 83
Circumstances for Revocation
4.9.1.1 Permissive Revocation
A Subscriber may request revocation of his, her, or its Certificate at any time for any reason (i.e., the
Subscriber requests in writing that the CA revoke the Certificate). The CA may request revocation of an
Administrative Certificate for an individual at any time for any reason. The CA may revoke a Certificate
for any reason, including without limitation the failure of the Subscriber (or any sponsoring organization,
where applicable) to meet its obligations under this Policy, the applicable CPS, or any other agreement,
regulation, or law applicable to the Certificate that may be in force, including violating the provisions of the
CA/B Forum Baseline Requirements. This includes revoking a Certificate when the CA suspects that a
compromise of the corresponding Private Key has occurred.
The CA shall maintain a continuous 24x7 ability to accept and respond to revocation requests and related
inquiries.
4.9.1.2 Required Revocation
A Subscriber or Subordinate CA will promptly request revocation of a Certificate whenever:
1. Any of the information in the Certificate changes or becomes obsolete;
2. The Subscriber or Subordinate CA notifies the CA that the original certificate request was not
authorized and does not retroactively grant authorization;
3. The Private Key, or the media holding the Private Key, associated with the Certificate is known or
suspected of being compromised.
The CA may revoke a Certificate whenever:
1. The Subscriber or Subordinate CA has failed to meet its material obligations under this Policy, any
applicable CPS, or any other agreement, regulation, or law that may be in force that is applicable to the
Certificate, including applicable provisions of the CA/B Forum Baseline Requirements;
2. Knowledge or reasonable suspicion of compromise is obtained;
3. The CA obtains evidence that the Subscriber’s or Subordinate CA’s Private Key corresponding to the
Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements
of Appendix A in the CA/B Forum Baseline Requirements;
4. The CA is made aware that a Subscriber or Subordinate CA has violated one or more of its material
obligations under the Subscriber or Terms of Use Agreement;
5. The CA is made aware of any circumstance indicating that use of a FQDN or IP address in the
Certificate is no longer legally permitted (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 Domain Name);
6. The CA is made aware of a material change in the information contained in the Certificate;
7. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading;
8. The CA ceases operations for any reason and has not made arrangements for another CA to provide
revocation support for the Certificate;
9. The CA’s right to issue Certificates under the CA/B Forum Baseline Requirements expires or is
revoked or terminated, unless the CA has made arrangements to continue maintaining the OCSP
Repository;
10. The CA is made aware of a possible compromise of the Private Key of the Subordinate CA used for
issuing the Certificate;
11. Revocation is required by this Certificate Policy and/or the corresponding Certification Practice
Statement;
12. The technical content or format of the Certificate presents an unacceptable risk to Application
Software Suppliers or Relying Parties as determined by the CA or the CA/B Forum;
13. The CA determines that the Certificate was not properly issued in accordance with this Policy and/or
any applicable CPS; or
14. Knowledge or reasonable suspicion of misuse is obtained.
Page 37
Page 37 of 83
Who Can Request Revocation
As described in Section 4.9.1 above, either the Subscriber or the CA may request revocation. The CA may
summarily revoke Certificates within its domain.
In addition, an individual who is not the Subscriber may request revocation of a DV-SSL Certificate if the
individual can demonstrate ownership or control over the device, and ownership or control over the
domain. Likewise, an individual who is not the Subscriber may request revocation of an Administrative
Certificate if the individual can demonstrate affiliation with the CA in a position of authority or
responsibility for either the individual or the use of the Administrative Certificate.
The CA shall provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties
with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types
of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA
shall publicly disclose the instructions through a readily accessible online means.
Procedure for Revocation Request
As described in this Policy, a Certificate revocation request should be promptly communicated to the CA.
A Certificate revocation request may be communicated electronically if it is digitally signed with the
Private Key of the Subscriber. Alternatively, the Subscriber may request revocation by contacting the CA
and providing adequate proof of identification in accordance with this Policy or an equivalent method.
Individuals who are not Subscribers shall request revocation by contacting the CA and providing adequate
proof of the items listed in Section 4.9.2.
4.9.3.1 Procedure for Investigating Certificate Problem Reports
The CA shall begin the investigation of a Certificate Problem Report within twenty-four hours of receipt,
and decide whether revocation or other appropriate action is warranted based on at least the following
criteria:
1. The nature of the alleged problem;
2. The number of Certificate Problem Reports received about a particular Certificate or
Subscriber;
3. The entity making the complaint (for example a security professional with good evidence of
private key compromise should carry more weight than a complaint from a consumer alleging
that she didn’t receive the goods she ordered); and
4. Relevant legislation.
The CA shall maintain a continuous 24x7 ability to respond internally to a high-priority Certificate Problem
Report, and where appropriate, forward such a complaint to law enforcement authorities, and/or revoke a
Certificate that is the subject of such a complaint.
Revocation Request Grace Period
This Policy makes no stipulation regarding a Revocation request grace period.
Time within which CA must Process a Revocation Request
The CA shall revoke a Certificate as quickly as practical after receipt of a proper revocation request and
confirmation of the authority of the person requesting revocation. The CA shall not suspend a Certificate in
accordance with applicable CA/B Forum Baseline Requirements. Promptly following revocation of a
Page 38
Page 38 of 83
Certificate, the CA and CSA shall update the online Certificate database Repository and reporting
mechanisms (e.g., OCSP). All revocation requests and the resulting actions taken by the CA will be
archived.
Revocation Checking Requirements for Relying Parties
Use of revoked Certificates could have damaging or catastrophic consequences in certain applications.
Therefore, before relying on a Certificate, a Relying Party must conduct a validation request in accordance
with the method and procedures established by the CA (see Section 4.10). If it is temporarily infeasible to
obtain revocation information, then the Relying Party must either reject use of the Certificate, or make an
informed decision to accept the risk, responsibility, and consequences of using a Certificate whose
authenticity cannot be guaranteed to the standards of this Policy.
CRL Issuance Frequency
The CA, or CSA shall maintain CRL and OCSP Certificate status reporting mechanisms in accordance with
the provisions of CAB/F Baseline Requirement 13.2.2. CRL reporting mechanisms will be used only for
status reporting on Subordinate CA certificates. For all Subscriber Certificates, including DV-SSL and
individual Administrative Certificates, OCSP or similar reporting mechanisms will be used.
CRL updating shall occur at intervals of no more than 12 months, or within 24 hours of a Subordinate CA
Certificate revocation.
Maximum Latency of CRLs
CRLs issued in accordance with this Policy shall have resources sufficient to provide a response time of 10
seconds or less under normal operating conditions.
Online Revocation/Status Checking Availability
If OCSP validation is employed, the CA and CSA will validate online, near-real-time the status of the
Certificate indicated in a properly formatted Certificate validation request message.
Online Revocation Checking Requirements
Relying Parties who rely on an online Certificate status database must (i) validate a Certificate with such
database before relying on the Certificate, and (ii) log the validation request. Failure to do so negates the
ability of the Relying Party to claim that it acted on the Certificate with reasonable reliance.
Other Forms of Revocation Advertisements Available
A CA may also use other methods to publicize revoked Certificates.
Special Requirements Rekey Compromise
This Policy makes no special requirements regarding Rekey compromise.
Circumstances for Suspension
This Policy does not allow for Certificate Suspension.
Who can Request a Suspension
See Section 4.9.2.
Page 39
Page 39 of 83
Procedure for Suspension Request
This Policy does not allow for Certificate Suspension.
Limits on Suspension Period
No stipulation.
Certificate Status Services
Operational Characteristics
The CA and the CSA shall make revocation information for Subordinate Certificates and Subscriber
Certificates available in accordance with the CA/B Forum Baseline Requirements Appendix B.
If the Subscriber Certificate is for a high-traffic FQDN, the CA may rely on stapling, in accordance with
[RFC4366], to distribute its OCSP responses. In this case, the CA shall ensure that the Subscriber “staples”
the OCSP response for the Certificate in its TLS handshake. The CA shall enforce this requirement on the
Subscriber either contractually, through the Subscriber or Terms of Use Agreement, or by technical review
measures implement by the CA.
OCSP responses conform to RFC2560 and/or RFC5019. OCSP responses shall either:
1. Be signed by the CA that issued the Certificates whose revocation status is being checked, or
2. Be signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate
whose revocation status is being checked.
In the latter case, the OCSP signing Certificate MUST contain an extension of type id-pkix-ocsp-nocheck,
as defined by RFC2560.
Service Availability
The CA and CSA shall update information provided via an Online Certificate Status Protocol at least every
4 days. OCSP responses from this service must have a maximum expiration time of 10 days.
The Issued CA and CSA shall operate and maintain its OCSP capability with resources sufficient to
provide a response time of 10 seconds or less under normal operating conditions.
Revocation entries on an OCSP Response will not be removed until after the Expiry Date of the revoked
Certificate.
If the OCSP responder receives a request for status of a certificate that has not been issued, then the
responder shall not respond with a “good” status. The CA and CSA will monitor the responder for such
requests as part of its security response procedures.
The Repository must not include entries that indicate that a Certificate is suspended.
Optional Features
End of Subscription
No stipulation.
Page 40
Page 40 of 83
Key Escrow and Recovery
If an Administrative Key Pair is used for both signature and confidentiality purposes, recovery of the
Private Key is prohibited unless the CA provides mechanisms (hardware, software, or procedural) that
permit recovery of the Private Key while protecting it from being used to impersonate the Subscriber.
This Policy does not permit the escrow of Private Keys.
Key Escrow and Recovery Policy and Practices
This Policy does not permit the escrow of Subscriber Private Keys,
Session Key Encapsulation and Recovery Policy and Practices
No stipulation.
Page 41
Page 41 of 83
5 Facility, Management, and Operational Controls
Physical Controls
The CA, and all RAs, CMAs, CSAs and Repositories, will implement appropriate physical security
controls to restrict access to the hardware and software (including the server, workstations, and any external
cryptographic hardware modules or tokens) used in connection with providing CA services. Access to such
hardware and software will be limited to those personnel performing in Trusted Roles as described in
Section 5.2.1. Access will be controlled through the use of electronic access controls, mechanical
combination locksets, deadbolts, or other physical protections of equivalent or greater strength. Such access
controls must be manually or electronically monitored for unauthorized intrusion at all times.
Site Location and Construction
The site(s) for the CA’s server(s) must be located and constructed to satisfy the requirements for a High-
Security Zone, as described in Section 1.6. These requirements include:
1. Location in a geographic area that is relatively free from multiple natural hazards;
2. Building construction that protects against or mitigates physical security and environmental hazards;
3. Multiple levels of security for the facility, with security increasing in areas closer to the CA key
materials and associated equipment;
4. The ability to store sensitive information and materials in secured containers within a High-Security
Zone as described in Section 1.6;
5. The ability to physically restrict access to CA key materials and associated equipment to personnel
previously identified on an approved access list, and electronically or manually logged;
6. The ability to protect Hardware Cryptomodules physically, through site protection;
7. The ability to physically enforce dual- or multiple-person requirements for access to CA key materials,
servers, and associated equipment;
8. The requirement that Trusted Role Employees of the CA and the RA must not leave their workstations
unattended when the cryptography is in an unlocked state (i.e., when the PIN or password has been
entered);
9. The protection of workstations that contain Private Keys on hard drives through physical security or
protection with an appropriate access control product; and
10. The ability to enforce constant escort and supervision of all persons entering the restricted area(s) who
are not on the approved access list.
The site(s) for RA activities must satisfy the requirements for an Operations Zone as described in Section
1.6. These requirements include:
1. Location within a site that meets the requirements for an Operations Zone or more secure zone as
described in Section 1.6;
2. The ability to physically restrict access to RA workstations to personnel previously identified on an
approved access list;
3. The ability to physically restrict access to Cryptomodules to personnel previously identified on an
approved access list; and
4. The ability to store Cryptomodules and other sensitive information (including personally identifiable
information, or PII) in a physically secured container within an area meeting Operations Zone or
Security Zone requirements.
Physical Access
The physical access controls for the CA’s servers and related equipment must accomplish the following:
1. Protect CA equipment at all times from unauthorized access;
Page 42
Page 42 of 83
2. Restrict access from one area of the facility to another, or from one security zone to another, using
physical or electronic constraints (e.g., physically locked doors, programmable electronic badge
systems, biometrics systems);
3. Restrict access to CA key materials, servers, and related equipment to those personnel on a
preapproved access list;
4. Provide for constant monitoring of the site by electronic means (e.g., recorded video surveillance,
motion detectors with logs and alarms), and by personnel with defined security duties;
5. Provide for physical security checks of the facility containing the CA’s servers and related equipment
at regular intervals to ensure that the area is protected against unauthorized access, with records
maintained of each such check showing when it was performed, who performed it, and the results of
the check;
6. Provide for physical security checks of the High-Security Zones, including areas where CA
Cryptomodules and other key materials are stored, at regular intervals, with records maintained of each
such check showing when it was performed, who performed it, and the results of the check;
7. Provide for electronic or manual logs of persons accessing the CA’s Cryptomodules, servers, and
related equipment.
The physical controls for RA equipment and working areas must accomplish the following:
1. Protect RA equipment such as workstations from unauthorized access, use, or removal, including
placing the workstations and work areas in Operations or Security Zones as described in Section 1.6;
2. Protect associated Cryptomodules from unauthorized access use, or removal, including providing
locked containers in secure areas for storing Cryptomodules that are not in use.
Power and Air Conditioning
Facilities that house the CA equipment must be supplied with power and air conditioning sufficient to
create a reliable operating environment. In addition, personnel areas within the facility must be supplied
with sufficient utilities to satisfy operational, health, and safety needs. The CA equipment will have power
and air conditioning backup capabilities sufficient to automatically lock out input, finish any pending
actions, and record the state of the equipment in the event a failure of one of these systems results in an
equipment shutdown. The revocation systems will be supported by uninterruptible power supplies and
sufficient backup power generation, or by automatic failover to a secondary processing site.
Water Exposures
CA equipment must be installed such that it is not in danger of exposure to water; e.g., on elevated floors.
Moisture detectors must be installed in areas susceptible to flooding. CA operators who have sprinklers for
fire control will have a contingency plan for recovery should the sprinklers malfunction or cause water
damage outside of the fire area.
Fire Prevention and Protection
Facilities that house the CA equipment must be supplied with automatic fire extinguishing system(s) that
will be installed in accordance with local code. The CA will have a contingency plan that accounts for
damage by fire.
Media Storage
Media must be stored so as to protect it from accidental damage (e.g., by water, fire, or electromagnetic
fields). Media that contains audit, archive, or backup information must be stored in a location separate from
the CA equipment.
Waste Disposal
Normal office waste must be removed or destroyed in accordance with best business practices. Media used
to collect or transmit information must be destroyed, such that the information is unrecoverable, prior to
disposal.
Page 43
Page 43 of 83
Off-­site Backup
System backups sufficient to recover from system failure will be made on a periodic schedule, as described
in the CPS. At least one backup copy will be stored at an offsite location separate from the CA equipment.
The backup will be stored at a site with physical and procedural controls commensurate to that of the
operational CA system.
Procedural Controls
Trusted Roles
A Trusted Role is one whose incumbent performs functions that could introduce security problems if
carried out improperly, whether by accident or malice. The people selected to fill Trusted Roles must be
careful and above reproach as described in the next Section. The functions performed in Trusted Roles
form the basis of trust in the entire PKI.
Number of Persons Required per Task
The CA must utilize commercially reasonable practices to ensure that one person acting alone cannot
circumvent safeguards.
The CA must ensure that no single individual may gain access to Subscriber Private Keys stored by the CA.
At a minimum, procedural or operational mechanisms must be in place for key recovery, such as a Split-
Knowledge Technique, to prevent the disclosure of the Encryption Key to an unauthorized individual.
Multi-user control is also required for CA Key generation, as outlined in Section 6.2.2. All other duties
associated with CA roles may be performed by an individual operating alone. The CA must ensure that any
verification process it employs provides for oversight of all activities performed by privileged CA role
holders.
To best ensure the integrity of the CA equipment and operation, it is recommended that wherever possible a
separate individual be identified for each Trusted Role. The separation provides a set of checks and
balances over the CA operation. The CA requires that employees of the CA and RA and contractors to
observe the principle of “least privilege” when accessing Certificate systems, or when configuring access
privileges on them. Furthermore, the CA must implement a process that disables all privileged access by an
individual to Certificate systems within 24 hours following termination of the individual’s employment or
contracting relationship with the CA or Delegated Third Party.
Under no circumstances will the incumbent of a CA Trusted Role perform his or her own auditor function.
Identification and Authentication for Each Role
Each person performing a CA role must have his or her identity and authorization verified before being (i)
included in the access list for the CA site; (ii) included in the access list for physical access to the CA
system; (iii) given a Certificate for the performance of a CA Trusted Role; or (iv) given an account on the
PKI system. Each of these Certificates and accounts (with the exception of CA signing Certificates) must
(i) be directly attributable to an individual; (ii) not be shared; and (iii) be restricted to actions authorized for
that role through the use of CA software, operating system and procedural controls. When accessed across
shared networks, CA operations must be secured, using mechanisms such as token-based strong
authentication and encryption.
Page 44
Page 44 of 83
Roles Requiring Separation of Duties
Policy and control procedures are implemented by the CA to ensure segregation of duties based upon job
responsibilities. The most sensitive tasks must require multiple Trusted Role personnel to be present; such
tasks include access to and management of CA private key material, as well as cryptographic hardware and
software. The requirement for multiple Trusted Role personnel must be enforced throughout the lifecycles
of CA materials from initial receipt and inspection through final logical or physical destruction.
In addition, the CA must segregate roles performing the following duties:
• Identification and validation of information in Certificate Applications;
• Acceptance, rejection, or other processing of Certificate Applications, revocation requests, and key
recovery or renewal requests;
• Issuance and revocation of Subscriber Certificates;
• Loading of a CA into a production environment;
• Generation, issuance, or destruction of CA certificates;
• Handling of Subscriber information;
• Duties generally required of a Security Officer; and
• Audits of CA systems.
5.2.4.1 Activities Requiring Multiple Individuals
The following activities require two or more individuals to be present:
• Physical access to the CA computing environment including associated network equipment;
• Physical access to the Cryptomodules containing CA Keys;
• Physical access to the activation material associated with the Cryptomodules containing CA Keys;
• Physical access to the equipment containing CA root and Subordinate Certificates used to issue
Subscriber Certificates;
• Activities involving the creation or backup of Root Certificates or Subordinate Certificates, or the
signing of OCSP materials;
• Activities involving the receiving of new Cryptomodules; and
• Activities involving the decommissioning or destruction of Cryptomodules.
Personnel Controls
Background, Qualifications, Experience, and Security Clearance
Requirements
CAs, RAs, CSAs, and CMAs will formulate and follow personnel and management policies sufficient to
provide reasonable assurance of the trustworthiness and competence of their employees and of the
satisfactory performance of their duties in manner consistent with this Policy.
Background Check Procedures
CAs will conduct an appropriate investigation of all personnel who serve in Trusted Roles prior to their
employment and thereafter as necessary or as stipulated in organization policy, to verify their
trustworthiness and competence in accordance with the requirements of this Policy and the CA’s personnel
practices or equivalent. Personnel who fail an initial or subsequent investigation will not serve or continue
to serve in a Trusted Role.
Page 45
Page 45 of 83
Training Requirements
The CA must ensure that all personnel performing managerial duties with respect to the operation of the
CA and RAs receive suitable training in (i) CA/RA security principles and mechanisms; (ii) security
awareness; (iii) all PKI software versions in use on the CA system; (iv) duties they are expected to perform;
and (v) disaster recovery and business continuity procedures.
Retraining Frequency and Requirements
The requirements of Section 5.3.3 must be kept current to accommodate changes in the CA system.
Refresher training must be conducted as required.
Job Rotation Frequency and Sequence
This Policy makes no stipulation regarding frequency or sequence of job rotation.
Sanctions for Unauthorized Actions
In the event of actual or suspected unauthorized action by a person performing duties with respect to the
operation of the CA or RA, the CA should suspend his or her access to the CA system.
Independent Contractor Requirements
The CA must ensure that contractor access to the CA site is in accordance with Section 5.1.1.
Documentation Supplied to Personnel
Documentation sufficient to define duties and procedures for each role will be provided to the personnel
filling that role.
Audit Logging Procedures
Types of Events Recorded
The CA and each Delegated Third Party shall record details of the actions taken to process a certificate
request and to issue a Certificate, including all information generated and documentation received in
connection with the certificate request, the time and date, and the personnel involved. The CA shall make
these records available to its Qualified Auditor as proof of the CA’s compliance with the CP, CPS, and the
CA/B Forum Baseline Requirements.
The CA will record events related to CA servers and related equipment and applications, at a minimum
including events that relate to the proper and secure function of the CA system, and the certificate life cycle
items listed in Section 5.5.1. Events may be attributable to human action (in any role) or may be
automatically invoked by the equipment. At a minimum, the information recorded will include the type of
event, and the date and time the event occurred, the source of the event, and the success or failure of a
requested action.
Where possible, the audit data will be collected by automated means; when this is not possible, a logbook,
paper form, or other physical mechanism will be used. Audit processes will be invoked at system startup,
and will cease only at system shutdown. Should it become apparent that an automated audit system has
failed and that redundant audit systems are not sufficient to provide needed audit logs, the affected
component(s) will cease CA-related operations until the audit capability can be restored. If it is
unacceptable to cease CA operation, other means will be employed to maintain audit capability.
Frequency of Log Review and Processing
The CA must ensure that its audit logs are reviewed by Trusted Role CA personnel at least weekly and all
significant events are explained in an audit log summary. Such reviews may include both electronic and
Page 46
Page 46 of 83
manual means, and may involve verifying that the log has not been tampered with, and then briefly
inspecting all log entries, with a more thorough investigation of any alerts or irregularities in the logs.
The Trusted Role employee will validate the integrity of logging processes and ensure that monitoring,
logging, alerting, and log-integrity-verification functions are operating properly (an in-house or third-party
audit log reduction and analysis tool may be used). Supporting manual and electronic logs from the CA and
RA should be compared where any action is deemed suspicious. Actions taken following these reviews
must be documented.
Retention Period for Audit Logs
The information generated on the CA equipment will be kept on the CA equipment until the information is
moved to an appropriate archive facility. Deletion of the audit log from the CA equipment will be
performed by a person performing a Trust Role other than CA Operator. This Trusted Role will be
identified in the CA’s CPS. Audit logs shall be retained as archive records in accordance with Section
5.5.2.
Protection of Audit Logs
The audit log, to the extent possible, will not be open for reading or modification by any human, or by any
automated process other than those that perform audit processing. Audit logs that have not been archived
must not be deleted. Any entity that does not have modification access to the audit log may archive it (note
that deletion requires modification access). Audit data to be archived shall be moved to a safe, secure
storage location separate from the CA equipment.
Audit Log Backup Procedures
Audit logs and audit summaries shall be backed up or copied if in manual form.
Audit Collection System (Internal vs. External)
This Policy makes no requirement for the audit log collection system to be external to the CA equipment.
The audit process shall run independently of the CA Operator and will not in any way be under the control
of the CA Operator.
The CA shall identify those Certificate Systems under the control of the CA or Delegated Third Party
Trusted Roles capable of monitoring and logging system activity and enable those systems to continuously
monitor and log system activity.
Notification to Event-­Causing Subject
Where an event is logged by the audit collection system no notice need be given to the individual,
organization, device or application that caused the event.
Vulnerability Assessments
Events recorded by the audit process will be logged, in part, to monitor system vulnerabilities. The CA
must ensure that a vulnerability assessment is performed, and reviewed, with remediation or mitigations
performed in a timely manner, at least once yearly, or following examination of log events that show
attempts or suspected attempts to breach the system.
The CA must undergo or perform a vulnerability scan for the following additional reasons:
1. Within one week of receiving a request from the CA/Browser Forum;
2. After any system or network changes that the CA determines are significant; and
Page 47
Page 47 of 83
3. At least once per quarter, on public and private IP addresses identified by the CA or Delegated Third
Party as the CA’s or Delegated Third Party’s Certificate systems.
The CA must also undergo a penetration test on itself and each Delegated Third Party’s Certificate Systems
on at least an annual basis and after infrastructure or application upgrades or modifications that the CA
determines are significant. The CA will also record evidence that each vulnerability scan and penetration
test was performed by a person or entity (or collective group thereof) with the skills, tools, proficiency,
code of ethics, and independence necessary to provide a reliable vulnerability scan or penetration test.
Should the CA or the CA discover a critical vulnerability during a penetration test not previously addressed
by the CA’s vulnerability correction process, the following must be completed within 96 hours:
1. The CA must remediate the critical vulnerability;
2. If remediation of the critical vulnerability within 96 hours is not possible, create and implement a plan
to mitigate the Critical Vulnerability, giving priority to:
a. Vulnerabilities with high CVSS scores, starting with the vulnerabilities the CA determines are
the most critical (such as those with a CVSS score of 10.0) and
b. Systems that lack sufficient compensating controls that, if the vulnerability were left
unmitigated, would allow external system control, code execution, privilege escalation, or
system compromise; or
3. Document the factual basis for the CA’s determination that the vulnerability does not require
remediation because:
a. The CA disagrees with the NVD rating,
b. The identification is a false positive,
c. The exploit of the vulnerability is prevented by compensating controls or an absence of
threats; or
d. Other similar reasons.
5.4.8.1 Risk Assessment
The CA’s security program must include an annual Risk Assessment that:
1. Identifies foreseeable internal and external threats that could result in unauthorized access, disclosure,
misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes;
2. Assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity
of the Certificate Data and Certificate Management Processes; and
3. Assesses the sufficiency of the policies, procedures, information systems, technology, and other
arrangements that the CA has in place to counter such threats.
Records Archive
Types of Events Archived
CA archive records must be detailed enough to establish the validity of a signature and of the proper
operation of the PKI. At a minimum, the following data will be recorded and archived:
5.5.1.1 Certificate Issuance
• Applicant’s name as it appears in the Certificate’s “Common Name” field
• Method of application (i.e., online, in-person, etc.)\
• For each data element accepted for proofing, including electronic forms:
o Name of document presented for identity proofing
o Issuing authority
o Date of issuance
o Date of expiration
o All fields verified
Page 48
Page 48 of 83
o Source of verification (i.e., which databases used)
o Method of verification (i.e., online, in-person)
o Date/time of verification
o Name of the RA
o All associated error messages and codes
o Date/time of process completion
o Date/time of Certificate download/Acceptance
5.5.1.2 Certificate Validation
• Certificate serial number
• Certificate status with reason code
• All associated error messages and codes
• Date/time of all Certificate validation requests
• Date/time of transmission of Certificate status request responses
5.5.1.3 Certificate Revocation
• Date/time
• Name of the RA
• Subscriber’s common name
• Reason code for revocation request
• Certificate serial number
• All associated verification request and revocation data
5.5.1.4 Certificate Renewal
• Certificate serial number
• Certificate common name
• New Validity Period dates
• Date/time of completion of renewal process
• All associated renewal data
5.5.1.5 Security events
• Successful and unsuccessful PKI system access attempts;
• PKI and security system actions performed;
• Security profile changes;
• System crashes, hardware failures, and other anomalies;
• Firewall and router activities; and
• Entries to and exits from the CA facility.
Retention Period for Archive
Archive records will be kept for a period of at least seven years and six months without any loss of data. If
the original media cannot retain the data for the required period, a mechanism to periodically transfer the
archived data to new media will be defined by the archive site. Software applications required to make the
archive data readable by humans will also be maintained for as long as necessary. The CA shall retain all
documentation relating to Certificate requests and the verification thereof, and all Certificates and
revocation thereof, for aforementioned period of seven years and six months after any Certificate based on
that documentation ceases to be valid. The CA shall make these audit logs available to its Qualified Auditor
upon request.
Protection of Archive
Archived logs will be written to media that cannot be modified afterwards. Only authorized Trusted Role
individuals, as defined in Section 5.2.4, may retrieve archived logs from storage. No unauthorized
Page 49
Page 49 of 83
individual will be able to write to, modify, or delete the archive. However, archived records may be moved
to another medium. The contents of the archive will not be released as a whole, except as required by law
or by lawful order of a judicial body with appropriate jurisdiction. Records of individual transactions may
be released upon request of any entities involved in the transaction or their legally recognized agents.
Archive media will be stored in a separate, safe, secure storage facility under conditions equivalent to or
stronger than the security of the CA system and the information it contains.
Archive Backup Procedures
Adequate backup procedures must be in place so that in the event of the loss or destruction of the primary
records, a complete set of backup copies will be available in a timely manner.
Requirements for Time-­Stamping of Records
Certificate validations will be time-stamped using time from a trusted source such as an NTP server.
Archive Collection System
No stipulation.
Procedures to Obtain and Verify Archive Information
Procedures to obtain and verify archive information and procedures detailing how to create, package, and
send the archive information will be published in the CA procedures handbook or CPS. Only authorized
users will be allowed to access the archive. During any inspections required by this Policy, the inspector
will verify the integrity of the archives.
Long Term Information Preservation
No stipulation.
Key Changeover
A Subscriber may only apply to renew his, her, or its Certificate within three months prior to the expiration
of one of the Keys, provided the previous Certificate has not been revoked. A Subscriber, the CA, or the
RA may initiate this renewal process. Automated key renewal is permitted. The CA must ensure that the
details of this process are indicated in its CPS or other publicly available document. Subscribers without
valid keys must be re-authenticated by the CA in the same manner as the initial registration. Where a
Subscriber’s Certificate has been revoked as a result of non-compliance, the CA must verify that any
reasons for non-compliance have been addressed to its satisfaction prior to issuing a new Certificate. Keys
may not be renewed using an expired key.
Compromise and Disaster Recovery
Incident and Compromise Handling Procedures
Computing Resources, Software, and/or Data are Corrupted
The CA must have in place an appropriate disaster recovery and business resumption plan. The plan must
set up and render operational a facility located in a geographically diverse area that is capable of providing
CA Services in accordance with this Policy within 72 hours of an emergency. The plan will include a
complete and periodic test of readiness for the recovery facility. The plan will be referenced within the CPS
or other appropriate documentation that is publicly available as described previously.
Page 50
Page 50 of 83
CA Private Key Compromise Procedures
In the event of the compromise or suspected compromise of the CA’s Private Signing Key, the CA must
immediately notify all CAs with whom it has cross-certified. In the event of the compromise or suspected
compromise of any other Participant’s Signing Key, the Participant must notify the CA immediately. The
CA must ensure that its CPS or other publicly available document and appropriate agreements contain
provisions outlining the means it will use to provide notice of compromise or suspected compromise.
In the event of the compromise of a CA’s CA Private Signing Key, the CA must revoke all Certificates
issued using that key and provide appropriate notice. After addressing the factors that led to Key
Compromise, the CA may (i) generate a new CA Signing Key Pair; and (ii) reissue Certificates to all
Subscribers and ensure all OCSP responders are signed using the new key.
Business Continuity Capabilities After a Disaster
In the event that the CA declares a disaster (generally defined as the unplanned cessation of services), the
CA will maintain continuity of validation services sufficient to maintain a service level of 99.5 percent
uptime except for scheduled maintenance windows. The CA will re-establish continuity of certificate life
cycle services within 72 hours of the disaster declaration.
The CA shall document business continuity and disaster recovery procedures designed to notify and
reasonably protect Application Software Suppliers, Subscribers, and Relying Parties in the event of a
disaster, security compromise, or business failure. The CA shall make the business continuity plan and
security plan available to the CA’s auditors upon request. The CA shall annually test, review, and update
these procedures.
The business continuity plan will include:
1. The conditions for activating the plan;
2. Emergency procedures;
3. Fallback procedures;
4. Resumption procedures;
5. A maintenance schedule for the plan;
6. Awareness and education requirements;
7. The responsibilities of the individuals;
8. Recovery time objective (RTO);
9. Regular testing of contingency plans.
10. The CA’s plan to maintain or restore the CA’s business operations in a timely manner following
interruption to or failure of critical business processes;
11. A requirement to store critical cryptographic materials (i.e., secure cryptographic device and activation
materials) at an alternate location;
12. Designation of acceptable system outage and recovery times;
13. Designation of the frequency of backup procedures for essential business information and software;
14. The distance of recovery facilities to the CA’s main site; and
15. Procedures for securing CA facilities to the extent possible during the period of time following a
disaster and prior to restoring a secure environment either at the original or a remote site.
Customer Service Center
This Policy makes no stipulation as to the existence and function of a human-staffed Customer Service
Center.
5.7.5.1 User Agent Verification
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. At a minimum, the CA shall
host separate web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired.
Page 51
Page 51 of 83
CA or RA Termination
In the event that the CA ceases operation, all Subscribers, CMAs, CSAs, Relying Parties will be promptly
notified of the termination. In addition, all CAs with which cross-certification agreements are current at the
time of cessation will be promptly informed of the termination. All Certificates issued by the CA that
reference this Policy must be revoked no later than the time of termination. All current and archived CA
identity proofing, Certificate, validation, revocation, renewal, policy and practices, billing, and audit data
will be transferred to the PMA (or designate) within seven days of CA cessation and in accordance with
this Policy. Transferred data will not include any data unrelated to this Policy. No key recovery enabled
repository data will be co-mingled with this data.
Page 52
Page 52 of 83
6 Technical Security Controls
Key Pair Generation and Installation
Key Pair Generation
Key Pairs for all Subscribers must be generated in such a way that the Private Key is not known by any
person other than the Key holder.
6.1.1.1 Key Generation Ceremony
For CA Root Keys that are for the operator of the Root CA or an Affiliate of the Root CA, the CA shall:
1. Prepare and follow a Key generation script; and
2. Have a Qualified Auditor witness the Root CA Key Pair generation process or record a video of the
entire Root CA Key Pair generation process.
In all cases the CA shall:
1. Generate the keys in a physically secured environment described in Section 5.1;
2. Generate the CA keys using personnel in trusted roles under the principles of multiple person control
and Split Knowledge;
3. Generate the CA keys within Cryptomodules meeting the applicable technical and business
requirements as described in Section 6.1;
4. Log its CA key generation activities as described in Section 5.5.1; and
5. Maintain effective controls to provide reasonable assurance that the Private Key was generated and
protected in conformance with the procedures described in Section 6.2.
.
Private Key Delivery to Subscriber
In most cases, a Private Key will be generated by and remain within the Cryptomodule for which it is
intended. If this does not occur, then the CA must securely deliver the Private Key to the Subscriber.
Accountability for the location and state of the Cryptomodule must be maintained until delivery and
possession occurs and the Subscriber acknowledges receipt of the Key to the CA or the RA. If the Key is
generated by the system for which it is intended as described above, the key will be stored by and used by
that system and no further action is required. If the key must be extracted for use by other applications or in
other locations, a protected data structure (such as defined in [PKCS#12]) will be used. The resulting file
may be kept on a magnetic medium or transported electronically. See Section 6.4.1.
Public Key Delivery to CA
Public Keys shall be delivered to the CA in a secure and trustworthy manner, such as a Certificate request
message. Delivery may also be accomplished via non-electronic means, such as CD or other storage
medium sent via registered mail or courier. Any other methods used for Public Key delivery will be
stipulated in a CPS.
The Public Key corresponding to the CA’s CA Private Signing Key may be delivered to Subscribers and
Relying Parties in an online transaction in accordance with IETF PKIX Part 3, or other appropriate
mechanism.
Key Sizes
All valid certificates shall contain Public Keys of at least 2048 bits for RSA or at least 224 bits for ECDSA
and a digest algorithm of SHA-256.
Page 53
Page 53 of 83
CA Root Certificates shall contain Public Keys of at least 3072 bits for RSA or at least 256 bits for ECDSA
and a digest algorithm of SHA-256.
Public Key Parameters Generation and Quality Checking
The CA shall generate Digital Signature Algorithm (DSA) parameters in accordance with FIPS 186-3.
RSA: The CA shall confirm that the value of the public exponent is an odd number equal to 3 or more.
Additionally, the public exponent should be in the range between 216+1 and 2256-1. The modulus should
also have the following characteristics: an odd number, not the power of a prime, and have no factors
smaller than 752.
DSA: Although FIPS 800-57 says that domain parameters may be made available at some accessible site,
compliant DSA certificates must include all domain parameters. This is to insure maximum interoperability
among relying party software. The CA must confirm that the value of the Public Key has the unique correct
representation and range in the field, and that the key has the correct order in the subgroup.
ECC: The CA should confirm the validity of all keys using either the ECC full Public Key validation
routine or the ECC partial Public Key validation routine.
Key Usage Purposes (as per X509 v3 Key Usage Field)
Keys contained in a DV-SSL Certificate may be used for SSL activities, including digital signature, key
encipherment, and client and server authentication. Keys contained in an Administrative Certificate may be
used for digital signature, and nonrepudiation.
CA Private Signing Keys are the only Keys permitted to be used for signing Certificates, CRLs, and OCSP
responders. The Certificate Key Usage field must be used in accordance with PKIX-1 Certificate, CRL and
OCSP Profiles. At least one of the following Key Usage values must be present in all Certificates: (i)
digital signature, or (ii) Non-Repudiation. One of the following additional values must be present in CA
Certificate-signing Certificates: (i) Key Cert Sign, (ii) CRL Sign, or (iii) digital signature. The use of a
specific Key is determined by the Key usage extension in the X.509 Certificate. This restriction is not
intended to prohibit use of protocols like the Secure Sockets Layer that provide authenticated connections
using Key management Certificates.
Private Key Protection and Cryptomodule Engineering Controls
Each Subscriber and PKI Service Provider must protect its Private Key(s) in accordance with the provisions
of this Policy.
Cryptomodule Standards and Controls
The standard for Cryptomodules for Subscribers and CA Administrative Certificates is FIPS140-2.
Cryptomodules for Subscribers and Administrative Certificates must be validated to FIPS140-2 Level 2 or
better. Cryptomodules for OCSP and other administrative devices must be validated to FIPS140-2 Level 2
or better.
The CA shall protect its Private Key in a system or device that has been validated as meeting at least FIPS-
140-2 Level 3 or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 or higher.
The CA shall encrypt its Private Key with an algorithm and key-length that, according to the state of the
art, are capable of withstanding cryptanalytic attacks for the residual life of the encrypted key or key part.
Page 54
Page 54 of 83
Private Key (n out of m) Multi-­Person Control
The CA Private Key shall be backed up, stored, and recovered only by personnel in trusted roles using at
least two-person control in a physically secured environment. The CA Private Keys shall be under a
minimum of two-person control for all activities described in Section 5.2.4. In addition, the CA shall
change authentication keys and passwords for any privileged account or service account on a Certificate
System whenever a person’s authorization to administratively access that account on the Certificate System
is changed or revoked; and lock out account access to Certificate Systems after no more than five failed
access attempts, provided that this security measure is supported by the Certificate System and does not
weaken the security of this authentication control.
Private Key Escrow
Private Key escrow is not allowed under this Policy.
Private Key Backup
A Subscriber may optionally back up his, her, or its own Private Key for DV-SSL and Administrative
Certificates. If this is done, the key must be copied and stored in encrypted form and protected at a level no
lower than stipulated for the primary version of the key.
The CA Private Key shall be backed up, stored, and recovered only by personnel in Trusted Roles using at
least two-person control in a physically secured environment.
Private Key Archival
Private Keys shall not be archived.
Private Key Transfer into or from a Cryptomodule
CA and Issuer CA Private Keys must be generated by and kept within a Cryptomodule. In the event that a
Private Key is to be transported from one Cryptomodule to another, the Private Key must be encrypted
during transport. CA and Issuer CA Private Keys must never exist in plain text form outside the
Cryptomodule boundary.
Private Key Storage on a Cryptomodule
No stipulation beyond that specified in FIPS-140-2.
Method of Activating Private Keys
A Subscriber must be authenticated to its Cryptomodule before the activation of the Private Key. For CA
and Subordinate CA Certificates, it shall be through the use of an electronic device. For Subscribers and
Administrative CA Certificate users, this authentication may be in the form of a password. When
deactivated, Private Keys must be kept in encrypted form only.
Method of Deactivating Private Keys
Cryptomodules that have been activated must not be left unattended or otherwise open to unauthorized
access. After use, they must be deactivated, using, for example, a manual logout procedure or a passive
timeout. When not in use, hardware Cryptomodules should be removed and stored, unless they are within
the Subscriber’s sole control.
Method of Destroying Private Keys
Private Keys should be destroyed when they are no longer needed, or when the Certificates to which they
correspond expire or are revoked. For software Cryptomodules, this can be done by overwriting the data.
For tokens, this will likely be accomplished by executing a “zeroize” command. Physical destruction of
hardware is not required.
Page 55
Page 55 of 83
Other Aspects of Key Management
Public Key Archival
This Policy makes no stipulation regarding the archiving of Subscriber Public Keys.
Certificate Operational Periods and Key Usage Periods
All Certificates and corresponding keys shall have maximum Validity Periods not to exceed the following:
Key Type
Certificate Lifetime Key Usage Period
Root CA
25 years
25 years
Root OCSP
30 days
3 years
Intermediate CA
8 years
8 years
Intermediate OCSP
30 days
3 years
DV-SSL Certificates
Up to 39 months
Up to 39 months
CA Administrative Certificates
3 years
3 years
Certificates and keys must not be used after the expiration of the Validity Periods indicated in this Section.
Restrictions on Authorized CA’s Private Key Use
The Private Key used by the CA for issuing Certificates will be used only for signing such Certificates and,
optionally, CRLs or other validation services responses (i.e. OCSP).
Certificate issuance by the Root CA shall require an individual authorized by the CA (i.e. The CA or the
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.
Root CA Private Keys shall not be used to sign Certificates except in the following cases:
1. Self-signed Certificates to represent the Root CA itself;
2. Certificates for Subordinate CAs and Cross Certificates;
3. Certificates for infrastructure purposes (e.g. administrative role certificates, internal CA operational
device certificates, and OCSP Response verification Certificates); and
4. Certificates issued solely for the purpose of testing products with Certificates issued by a Root CA.
Activation Data
Activation Data Generation and Installation
A passphrase, PIN or other activation data shall be used to protect access to the Private Key of the CA Root
Certificates, Subscribers, and CA Administrative Certificates.
For CA Root, Subordinate CA, and CSA Certificates, activation data shall be generated automatically. For
DV-SSL and CA Administrative Certificates, the activation data may be user-selected.
For CA Administrative Certificates, if the activation data must be transmitted to the Subscriber, it shall be
via a channel of appropriate protection, and distinct in time and place from the associated Cryptomodule. If
this is not done by hand, the Subscriber should be advised of the date sent, method of sending, and
expected delivery date of any activation data. As part of the delivery method, end entities should
acknowledge receipt of the Cryptomodule and activation data. In addition, end entities should also receive
Page 56
Page 56 of 83
(and acknowledge receipt of) information regarding the use and control of the Cryptomodule. See Section
6.1.2
Activation Data Protection
If written down, activation data must be secured at the level of the data that the associated Cryptomodule is
used to protect, and must not be stored with the Cryptomodule. Activation data must never be shared.
Other Aspects of Activation Data
This Policy makes no stipulation on the life of activation data; however, it should be changed periodically
to decrease the likelihood that it has been discovered. CAs may define activation data requirements in their
CPSs or Certificate Agreements.
Computer Security Controls
Specific Computer Security Technical Requirements
All CA servers must include the following functionality either provided by the operating system or through
a combination of operating system, PKI application, and physical safeguards:
1. Control of access to CA services and PKI roles;
2. Enforced separation of duties for PKI roles;
3. Identification and authentication of PKI roles and associated identities;
4. Object re-use or separation for CA random access memory;
5. Use of cryptography for session communication and database security;
6. Archival of CA and End-Entity history and audit data;
7. Audit of security related events;
8. Self-test of security related CA services;
9. Trusted path for identification of PKI roles and associated identities;
10. Recovery mechanisms for Keys and the CA system; and
11. Enforcement of domain integrity boundaries for security critical processes.
Computer Security Rating
The CA’s equipment will meet and be operated to a Common Criteria EAL 4 rating or higher, or equivalent
security as measured by another generally recognized standard. The CA’s equipment operating at this
rating will, as a minimum, implement:
1. Self-protection;
2. Process isolation;
3. Discretionary access control;
4. Object reuse controls;
5. Individual I&A; and
6. Protected audit records.
Life Cycle Technical Controls
CA equipment (hardware and software) procured to operate a PKI (including equipment for any RA, CMA,
or CSA) will be purchased in a fashion to reduce the likelihood that any particular copy was tampered with;
for instance, by random selection.
CA equipment will be protectively packaged and delivered via an accountable method. Tamper-evident
packaging will be used or equipment will be hand-carried from a controlled procurement environment to
the installation site. Equipment procured prior to registration as the CA will be deemed to satisfy this
requirement. The CA equipment will be dedicated to administering a key management infrastructure. It will
Page 57
Page 57 of 83
not have installed applications or component software that is not part of the CA configuration. Where
possible, equipment such as servers will be wiped clean of any factory-installed software, and then
reimaged to hardened standards using trusted software repositories. Cryptomodules will be zeroized before
first use. Equipment updates will be purchased or developed in the same manner as original equipment, and
will be installed by trusted and trained personnel in a defined manner.
System Development Controls
The CA must use software that has been designed and developed with the following standards: .
• For commercial off-the-shelf software, the software shall be designed and developed under a
formal, documented development methodology;
• Where open source software has been utilized, the applicant shall demonstrate that security
requirements were achieved through software verification & validation and structured
development/lifecycle management.
The design and development process must provide sufficient documentation to support third party security
evaluation of the CA components and be supported by third party verification of process compliance and
on-going assessments to influence security safeguard design and minimize residual risk.
Security Management Controls
A formal configuration management methodology must be used for installation and ongoing maintenance
of the CA system. The CA software, when first loaded, must provide a method for the CA to verify that the
software on the system (i) originated from the software developer; (ii) has not been modified prior to
installation; and (iii) is the version intended for use. The CA must provide a mechanism to periodically
verify the integrity of the software, and to control and monitor the configuration of the CA system.
The CA must also apply recommended security patches to Certificate Systems within six months of the
security patch’s availability, unless the CA documents that the security patch would introduce additional
vulnerabilities or instabilities that outweigh the benefits of applying the security patch. The CA will also
review all system accounts at least every 90 days and deactivate any accounts that are no longer necessary
for operations.
Life Cycle Security Controls
The CA must restrict remote administration or access to an issuing system, Certificate Management
System, or security support system except when (i) the remote connection originates from a device owned
or controlled by the CA or Delegated Third Party and from a pre-approved external IP address, (ii) the
remote connection is through a temporary, non-persistent encrypted channel that is supported by multi-
factor authentication, and (iii) the remote connection is made to a designated intermediary device (a)
located within the CA’s network, (b) secured in accordance with Section 6.5 and the CA/B Forum Baseline
Requirements, and (c) that mediates the remote connection to the Issuing system.
Network Security Controls
CA equipment should be connected to no more than two network domains at a time. CA equipment
intended to connect to more than one network classification domain will have procedures defined in a CPS,
or other document made available to its auditors, that prevent information from one domain from reaching
another (e.g., equipment shutdown, removable hard drives, switching the network connection). CA
equipment may operate through a network guard insofar as it does not circumvent the function of the guard.
Protection of CA equipment will be provided against known network attacks. Use of appropriate boundary
controls will be employed. All unused network ports and services will be turned off. Any network software
Page 58
Page 58 of 83
present on the CA equipment will be necessary to the functioning of the CA application. Root CA
equipment will be stand-alone (off-line) configurations.
The CA must maintain a network environment that protects the Private Keys, Root Certificates, and
Subordinate CA Certificates from compromise or misuse.
1. Networks will be segmented in order to provide multiple levels of protection to the CA Certificates;
2. Networks will use firewalls and/or other inbound traffic protections to reject or restrict unauthorized
traffic;
3. Networks will use intrusion detection and/or other monitoring systems to notify administrators and
security personnel of attempts at unauthorized access;
4. Access to CA servers and CA Keys must be through approved applications;
5. Access to Applicant and Subscriber data must be monitored and logged, and must be traceable back to
an individual; and
6. Networks will have an implemented detection and prevention controls under the control of the CA or
Delegated Third Party Trusted Roles to protect Certificate Systems against viruses and malicious
software
Time Stamping
All audit events will be time-stamped using NTP-validated time, which corresponds to the times on all
network components being logged.
Page 59
Page 59 of 83
7 Certificate, CRL, and OCSP Profiles
Certificate Profiles
The CA shall populate the issuer field of each Certificate issued after the adoption of the CA/B Forum
Baseline Requirements in accordance with the specifications within this Section. All other optional
attributes, when present within the subject field, must contain information that has been verified by the CA.
Optional attributes must not contain metadata such as ‘.’, ‘-‘, and ‘ ‘ (space) characters, and/or any other
indication that the value is absent, incomplete, or not applicable. By issuing the Certificates as per the
guidelines in this Section, the CA verifies that the subject information was accurate.
Version Number(s)
The CA must issue X.509 Version 3 Certificates.
Certificate Extensions
Rules for the inclusion, assignment of value, and processing of extensions are summarized in the profiles
Appendix A of the CA/B Forum Baseline Requirements. Use of Certificate extension shall comply with
RFC 5280 and the requirements below provided for compliance with the CA/B Forum Baseline
Requirements.
The CA shall generate non-sequential Certificate serial numbers that exhibit at least 20 bits of entropy.
The CA shall not issue a Certificate that contains a keyUsage flag, extendedKeyUsage value, Certificate
extension, or other data not specified in below or in the profiles unless the CA is aware of a reason for
including the data in the Certificate, in such case, this modification must be noted in the CPS.
CAs shall not issue a Certificate with:
• Extensions that do not apply in the context of the public Internet (such as an extendedKeyUsage value
for a service that is only valid in the context of a privately manage d network), unless:
o Such value falls within an OID arc for which the Applicant demonstrates ownership, or
o The Applicant can otherwise demonstrate the right to assert the data in a public context; or
o Semantics that, if included, will mislead a Relying Party about the certificate information verified
by the CA (such as including extendedKeyUsage value for a smart card, where the CA is not able
to verify that the corresponding Private Key is confined to such hardware due to remote issuance).
Root CA Certificate:
• basicConstraints. This extension must appear as a critical extension. The cA field must be set true.
The pathLenConstraint field should not be present.
• keyUsage. This extension must be present and must be marked critical. Bit positions for keyCertSign
and cRLSign must be set. If the Root CA Private Key is used for signing OCSP responses, then the
digitalSignature bit must be set.
• certificatePolicies. This extension should not be present.
• extendedKeyUsage. This extension must not be present.
Subordinate CA Certificates:
Page 60
Page 60 of 83
• certificatePolicies. This extension must be present and should not be marked critical.
certificatePolicies:policyIdentifier (Required)
The following fields may be present if the Subordinate CA is not an Affiliate of the entity that controls
the Root CA.
certificatePolicies:policyQualifiers:policyQualifierId (Optional)
o id-qt 1 [RFC 5280].
certificatePolicies:policyQualifiers:qualifier:cPSuri (Optional)
o HTTP URL for the Root CA's Certificate Policies, Certification Practice Statement, Relying Party
Agreement, or other pointer to online policy information provided by the CA.
• cRLDistributionPoints. This extension must be present and must not be marked critical. It must
contain the HTTP URL of the CA’s CRL service.
• authorityInformationAccess. With the exception of stapling, which is noted below, this extension
must be present. It must not be marked critical, and it must contain the HTTP URL of the CA’s OCSP
responder (accessMethod = 1.3.6.1.5.5.7.48.1). It should also contain the HTTP URL of the CA’s
certificate (accessMethod = 1.3.6.1.5.5.7.48.2). See Section 13.2.1 of the CA/B Forum Baseline
Requirements for details. The HTTP URL of the CA’s OCSP responder may be omitted, provided that
the Subscriber “staples” the OCSP response for the Certificate in its TLS handshakes [RFC4366].
• basicConstraints. This extension must be present and must be marked critical. The cA field must be
set true. The pathLenConstraint field may be present.
• keyUsage. This extension must be present and must be marked critical. Bit positions for keyCertSign
and cRLSign must be set. If the Subordinate CA Private Key is used for signing OCSP responses, then
the digitalSignature bit must be set.
• nameConstraints (optional). If present, this extension should be marked critical. Non-critical Name
Constraints are an exception to RFC 5280 (4.2.1.10), however, they may be used until the Name
Constraints extension is supported by Application Software Suppliers whose software is used by a
substantial portion of Relying Parties worldwide.
• extkeyUsage (optional). For Subordinate CA Certificates to be technically constrained in line with
Section 9.8, then either the value id-kp-serverAuth or id-kp-clientAuth, or both values, must be
present. Other values may be present. If present, this extension should be marked non-critical.
Generally Extended Key Usage will only appear within Subscriber certificates (as highlighted in RFC
5280 (4.2.1.12)), however, Subordinate CAs may include the extension to further protect relying
parties until the use of the extension is consistent between Application Software Suppliers whose
software is used by a substantial portion of Relying Parties worldwide.
DV-SSL Certificates:
• certificatePolicies. This extension must be present and should not be marked critical.
certificatePolicies:policyIdentifier (Required)
o A Policy Identifier, defined by the issuing CA, that indicates a Certificate Policy asserting the
issuing CA's adherence to and compliance with these Requirements.
The following extensions may be present:
o certificatePolicies:policyQualifiers:policyQualifierId (Recommended)
▪ id-qt 1 [RFC 5280].
o certificatePolicies:policyQualifiers:qualifier:cPSuri (Optional)
▪ HTTP URL for the Subordinate CA's Certification Practice Statement, Relying Party
Agreement or other pointer to online information provided by the CA.
Page 61
Page 61 of 83
• cRLDistributionPoints. This extension may be present. If present, it must not be marked critical, and
it must contain the HTTP URL of the CA’s CRL service.
• authorityInformationAccess. With the exception of stapling, which is noted below, this extension
must be present. It must not be marked critical, and it must contain the HTTP URL of the issuing CA’s
OCSP responder (accessMethod= 1.3.6.1.5.5.7.48.1). It should also contain the HTTP URL of the
issuing CA’s certificate (accessMethod = 1.3.6.1.5.5.7.48.2).
The HTTP URL of the issuing CA’s OCSP responder may be omitted provided that the Subscriber
“staples” OCSP responses for the Certificate in its TLS handshakes [RFC4366].
• basicConstraints (optional). If present, the cA field must be set false.
• keyUsage (optional) If present, bit positions for keyCertSign and cRLSign must not be set.
• extKeyUsage (required). Either the value id-kp-serverAuth [RFC5280] or id-kp-
clientAuth[RFC5280] or both values must be present. id-kp-emailProtection [RFC5280] may be
present. Other values should not be present.
Algorithm Object Identifiers
Certificates under this Policy will use the following OIDs for signatures:
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)
sha384WithRSAEncryption(12)}
sha512WithRSAEncryption
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
sha512WithRSAEncryption(13)}
ecdsa-with-SHA256
{iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2 (3) 2}
ecdsa-with-SHA384
{iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 3}
ecdsa-with-SHA512
{iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 4}
Certificates under this Policy shall use the following OIDs for identifying the algorithm for which the
subject key was generated:
id-dsa
{ iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }
rsaEncryption
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1}
id-ecPublicKey
{iso(1) member-body(2) us(840) ansi-x9-62(10045) public key-type (2)
1}
id-ecDH
{iso(1) identified-organization(3) certicom(132) schemes(1) ecdh(12)}
For certificates that contain an elliptic curve public key, the parameters shall be specified as one of the
following named curves.
Curve P-256
ansip256r1 ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045)
curves(3) prime(1) 7 }
Curve P-384
ansip384r1 ::= { iso(1) identified-organization(3) certicom(132) curve(0)
34 }
Curve P-521
ansip384r1 ::= { iso(1) identified-organization(3) certicom(132) curve(0)
35 }
Page 62
Page 62 of 83
Name Forms
Every DN must be in the form of an X.501 printable string.
Where required as set forth in Section 3.1.1, the subject and issuer fields of the Certificate shall be
populated with an X.500 Distinguished Name. Distinguished Names shall be composed of standard
attribute types, such as those identified in RFC 5280.
For attribute values, All CA Distinguished Names (in various fields, e.g., Issuer, Subject, Subject
Alternative Name, Name constraints) shall be encoded as printable strings. All subscriber DN portions that
name constraints apply to shall be encoded as printable string. Other portions of the subscriber DN shall be
encoded as printable strings, if possible. If a portion cannot be encoded as a printable string, then and only
then shall it be encoded using a different format and that format shall be UTF8.
For domain component attribute values: All domain component attribute values shall be encoded as an IA
string.
Name Constraints
For a Subordinate CA Certificate to be considered Technically Constrained, the certificate must include an
Extended Key Usage (EKU) extension specifying all extended key usages for certificates that the
Subordinate CA Certificate is authorized to issue.
If the Subordinate CA Certificate includes the id-kp-serverAuth extended key usage, then the Subordinate
CA Certificate must include the Name Constraints X.509v3 extension with constraints on dNSName,
iPAddress and DirectoryName as follows:
• For each dNSName in permittedSubtrees, the CA must confirm that the Applicant has registered
the dNSName or has been authorized by the domain registrant to act on the registrant's behalf in
line with the verification practices of Section 3.2.2.
• For each iPAddress range in permittedSubtrees, the CA must confirm that the Applicant has been
assigned the iPAddress range or has been authorized by the assigner to act on the assignee's
behalf.
• For each DirectoryName in permittedSubtrees the CA must confirm the Applicants and/or
Subsidiary’s Organizational name and location such that Subscriber certificates issued from the
subordinate CA Certificate will be in compliancy with 3.1.1.
If the Subordinate CA Certificate is not allowed to issue certificates with an iPAddress, then the
Subordinate CA Certificate must specify the entire IPv4 and IPv6 address ranges in excludedSubtrees. The
Subordinate CA Certificate must include within excludedSubtrees an iPAddress GeneralName of 8 zero
octets (covering the IPv4 address range of 0.0.0.0/0). The Subordinate CA Certificate must also include
within excludedSubtrees an iPAddress GeneralName of 32 zero octets (covering the IPv6 address range of
:0:0:0:0:0:0:0:0/0). Otherwise, the Subordinate CA Certificate MUST include at least one iPAddress in
permittedSubtrees.
If the Subordinate CA is not allowed to issue certificates with dNSNames, then the Subordinate CA
Certificate MUST include a zero-length dNSName in excludedSubtrees. Otherwise, the Subordinate CA
Certificate must include at least one dNSName in permittedSubtrees.
Certificate Policy Object Identifier
Certificates issued under this policy shall assert the appropriate OID with which it was issued, as defined in
Section 1.2.2.
Page 63
Page 63 of 83
Usage of Policy Constraints Extension
No stipulation.
Policy Qualifiers, Syntax, and Semantics
The issuing CA shall populate the policyQualifiers user notice field of Subordinate CA Certificates if it is
not an Affiliate of the entity that controls the Root CA. The issuing CA may populate the policyQualifier
CPSuri field with the URI of the CA’s CPS.
The issuing CA should populate the policyQualifiers user notice field of DV-SSL and administrative
Certificates. The issuing CA may populate the policyQualifier CPSuri field with the URI of the CA’s CPS.
When populated, the userNotice field should contain text substantially similar to the following:
This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate
Policy found at [policy location URL]
Processing Semantics for the Critical Certificate Policies Extension
Not applicable, the Certificate Policies extension is not marked critical when present.
CRL Profile
If utilized, CRLs will be issued in the X.509 version 2 format. The CPS or other publicly available
document will identify the CRL extensions supported and the level of support for these extensions.
Version Number(s)
The issuing CA must issue X.509 version two (2) CRLs in accordance with the PKIX Certificate and CRL
Profile.
CRL and CRL Entry Extensions
All Subscriber PKI software must correctly process all CRL extensions identified in the Certificate and
CRL profile in Section 10. The CPS or other publicly available document will identify must define the use
of any extensions supported by the issuing CA, its RAs and end entities.
OCSP Profile
OCSP Signers shall sign responses using algorithms designated for CRL signing. Section 10 contains the
profile for an OCSP certificate signer, OCSP request, and responses.
Version Number(s)
See OCSP request and responses in Section 10.
OCSP Extensions
See OCSP request and responses in Section 10.
Page 64
Page 64 of 83
8 Compliance Audits and Other Assessments
Frequency of Audit or Assessments
A CA will undergo a review and approval process by the PMA to demonstrate compliance with this Policy.
This Policy makes no stipulation as to the exact frequency of compliance inspections, but inspections for
re-certification will be required any time a significant change in CA operations is made.
In any event, the CA, RAs, CSAs, and CMAs must certify annually that they have at all times during the
period in question complied with the requirements of this Policy. The CA, RAs, and CMAs must also state
any periods of non-compliance with this Policy and provide reasons for non-compliance. The period during
which the CA issues Certificates shall be divided into an unbroken sequence of audit periods. An audit
period must not exceed one year in duration. Whichever scheme is chosen, it must incorporate periodic
monitoring and/or accountability procedures to ensure that its audits continue to be conducted in
accordance with the requirements of the scheme.
Internal Self-­Assessment Audits
During the period in which the CA issues Certificates, it shall monitor adherence to its Certificate Policy,
Certification Practice Statement and the CA/B Forum Baseline Requirements and strictly control its service
quality by performing self-audits on at least a quarterly basis against a randomly selected sample of the
greater of one certificate or at least 3 percent of the Certificates issued by it during the period commencing
immediately after the previous self-audit sample was taken.
Identity and Qualifications of Assessor
Subject to further qualifications identified in Section 9, Compliance Inspectors must (i) have qualifications
in accord with best commercial practice; (ii) perform CA or Information System Security inspections as
their primary responsibility; and (iii) be familiar with the CA’s practices.
The CA’s audit shall be performed by a Qualified Auditor. A Qualified Auditor means a natural person,
legal entity, or group of natural persons or legal entities that collectively possess the following
qualifications and skills:
1. Independence from the subject of the audit;
2. The ability to conduct an audit that addresses the criteria specified in an eligible audit scheme as
specified in the CA/B Forum Baseline Requirements;
3. Individuals who have proficiency in examining Public Key Infrastructure technology, information
security tools and techniques, information technology and security auditing, and the third-party
attestation function;
4. Accreditation in accordance with ETSI TS 119 403, or accredited to conduct such audits under an
equivalent national scheme, or accredited by a national accreditation body in line with ISO 27006 to
carry out ISO 27001 audits or licensed by WebTrust;
5. Bound by law, government regulation, or professional code of ethics; and
6. Except in the case of an internal government auditing agency, maintains professional liability/errors &
omissions insurance with policy limits of at least one million US dollars in coverage.
Page 65
Page 65 of 83
Assessor’s Relationship to Assessed Entity
The Compliance Inspector(s) and CA must have a contractual relationship for the performance of the
inspection, or be sufficiently separated organizationally from the CA to provide an unbiased, independent
evaluation.
Topics Covered by Assessment
Inspections will be substantially similar to (i) the American Institute of Certified Public Accountants’
(“AICPA’s”) Service Organization Control 2 Report; (ii) AICPA/CICA WebTrust for Certification
Authorities (CA WebTrust); and/or (iii) any other appropriate standards as determined by the PMA.
SOC 2 and CA WebTrust are performed by an accredited public accountant or nationally-recognized
accounting firm. Inspections must follow any guidelines adopted by the PMA, including whether the CA’s
practices comply with the technical, procedural and personnel policies and practices outlined in this Policy.
Actions Taken as a Result of Deficiency
CA inspection results must be submitted to the CA’s regulator or licensing body where applicable, and the
PMA. If irregularities are found, the CA must submit a report to its regulator or licensing body and the
PMA as to any action the CA will take in response to the inspection report. Where the CA fails to take
appropriate action in response to the inspection report, the CA’s regulator, licensing body or the PMA may
(i) indicate the irregularities, but allow the CA to continue operations until the next programmed
inspection; (ii) allow the CA to continue operations for a maximum of thirty (30) days pending correction
of any problems prior to revocation; (iii) downgrade the assurance level of any Certificates issued by the
CA (including Cross Certificates); or (iv) revoke the CA’s Certificate. Any decision regarding which of
these actions to take will be based on the severity of the irregularities.
Any remedy may include permanent or temporary CA cessation, but all relevant factors must be considered
prior to making a decision. A special audit may be required to confirm the implementation and
effectiveness of the remedy. The CA will post any appropriate results of an inspection, in whole or in part,
so that it is accessible for review by Subscribers and relying parties. The manner and extent of the
publication will be defined by the CA.
Communication of Results
The audit report shall state explicitly that it covers the relevant systems and processes used in the issuance
of all Certificates that assert one or more of the policy identifiers listed in the CA/B Forum Baseline
Requirements in Section 9.3.1. The CA shall make the audit report publicly available. The CA is not
required to make publicly available any general audit findings that do not impact the overall audit opinion.
The CA shall make its Audit Report publicly available no later than three months after the end of the audit
period. In the event of a delay greater than three months, and if so requested by an Application Software
Supplier, the CA shall provide an explanatory letter signed by the Qualified Auditor.
Page 66
Page 66 of 83
9 Other Business and Legal Matters
Fees
Notice of any fee charged to a Subscriber or Relying Party must be brought to the attention of that entity.
Certificate Issuance, Renewal and Revocation Fees
CAs and RAs may establish and charge a reasonable Certificate issuance fee for providing I&A,
registration and Certificate issuance services to potential end entities.
Certificate Access Fees
The CA may establish and charge a reasonable fee for providing Certificate status information services.
Revocation or Status Information Access Fee (Certificate Validation
Services)
The CA may establish and charge a reasonable fee for providing Certificate revocation information
services.
Fees for Other Services such as Policy Information
The CA and RAs may establish and charge other reasonable fees. However, no fee may be charged for
access to review the provisions of this Policy.
Refund Policy
Any fees collected for Certificate applications that are not approved will be refunded.
Financial Responsibility
Insurance Coverage
No stipulation.
Other Assets
CAs shall maintain reasonable and sufficient financial resources to maintain operations, fulfill duties, and
address liability obligations to entities described in Section 1.3 of this Policy.
Insurance or Warranty Coverage for End-­entities
CAs shall maintain reasonable levels of insurance coverage or demonstrate sufficient balance sheet to
address all foreseeable liability obligations to entities described in Section 1.3 of this Policy.
Confidentiality of Business Information
Scope of Confidential Information
[subject to the provisions of Section 9.4, ISRG to determine]
Information Not Within the Scope of Confidential Information
[subject to the provisions of Section 9.4, ISRG to determine]
Responsibility to Protect Confidential Information
[subject to the provisions of Section 9.4, ISRG to determine]
Page 67
Page 67 of 83
Privacy of Personal Information
Privacy Plan
See the ISRG privacy policy located at [insert location of ISRG privacy policy – e.g., web address of the
Repository]
Notwithstanding the foregoing provisions of this Section 9.4.1, the provisions below in such Section shall
apply with respect to information under this Policy.
1. The CA or RA should collect only such personal information about an Applicant, a Subscriber, or a
sponsoring organization that is necessary for the issuance of a Certificate to the Applicant or
Subscriber. For the purpose of proper administration of Certificates, the CA or RA may request non-
Certificate information to be used in issuing and managing Certificates (e.g., identifying numbers,
business or home addresses and telephone numbers). But such information will only be used for
purposes of Certificate management and issuance. Collection of personal information may be subject
to collection, maintenance, retention and protection requirements of state and federal law.
2. Applicants and Subscribers must be given access and the ability to correct or modify their personal or
organization information. The CA or RA must provide this information on appropriate request, but
only after taking proper steps to authenticate the identity of the requesting party.
3. The CA may choose to define or restrict its disclosure of Certificate-related information to a greater
degree than is provided for under this Policy.
Information Treated as Private
See the ISRG privacy policy located at [insert location of ISRG privacy policy – e.g., web address of the
Repository].
Notwithstanding the foregoing provisions of this Section 9.4.2, the provisions below in such Section shall
apply with respect to information under this Policy.
1. Private Keys are sensitive and confidential information and, therefore, Private Keys shall be held in
strictest confidence. Under no circumstances will any Private Key appear unencrypted outside the
Cryptomodule storing such Private Key.
2. All non-public information stored locally on CA and/or RA equipment (not in the Repository) is
considered confidential for purposes of this Policy. Access to this information will be restricted to
those with an official need-to-know in order to perform their official duties. Any information
pertaining to CA management of Certificates, such as compilations of Certificate information, shall be
treated as confidential.
Information not Deemed Private
Information contained in any Certificate issued by a CA under this Policy is neither confidential nor
private. Information relevant to the validation of the certificate, such as the IP Address of any requests
made by the Subscriber or any IP Addresses associated with FQDNs in the certificate, are not deemed
private. Information required to be provided by Repository as provided under the other provisions of this
Policy is neither confidential nor private. Information required to be provided by OCSP Responder as
provided under the other provisions of this Policy is neither confidential nor private.
Responsibility to Protect Private Information
See the ISRG privacy policy located at [insert location of ISRG privacy policy – e.g., web address of the
Repository]
Notwithstanding the foregoing provisions of this Section 9.4.4, the provisions below in such Section shall
apply with respect to information under this Policy.
Page 68
Page 68 of 83
1. Access to information that is held by a PKI Participant and that is identified as private or confidential
under this Policy shall be restricted to those employees or agents of the PKI Participant with an official
need to know in order to perform their official duties, and to that access needed to accommodate
disclosures of such information that are provided for under the other provisions of this Policy.
2. PKI Service Providers will not disclose any information identified as private or confidential under this
Policy to any third party other than as provided under Section 9.4.
Notice and Consent to use Private Information
See the ISRG privacy policy located at [insert location of ISRG privacy policy – e.g., web address of the
Repository]
Disclosure Pursuant to Judicial or Administrative Process
See the ISRG privacy policy located at [insert location of ISRG privacy policy – e.g., web address of the
Repository]
Notwithstanding the foregoing provisions of this Section 9.4.6, the provisions below in such Section shall
apply with respect to information under this Policy.
1. A PKI Service Provider may release information identified as confidential or private under this Policy
in the event such disclosure is required by law, governmental rule or regulation, or court order.
2. Unless prohibited by law, a PKI Service Provider will give all interested persons or parties reasonable
prior written notice before disclosing any information considered confidential under this Section 9.4.6.
Protection of information as provide for under this Section 9.4 will remain an obligation
notwithstanding the status of a Certificate (current or revoked) or the status of the CA.
Other Information Disclosure Circumstances
See the ISRG privacy policy located at [insert location of ISRG privacy policy – e.g., web address of the
Repository]
Notwithstanding the foregoing provisions of this Section 9.4.7, the provisions below in such Section shall
apply with respect to information under this Policy.
1. A PKI Service Provider may release information identified as confidential or private under this Policy
in the event such disclosure is: (i) authorized by this Policy; or (ii) necessary to effect an appropriate
use of a Certificate. All requests for disclosure of information considered confidential under this
Section 9.4.7 must be made in writing.
2. Unless prohibited by law, a PKI Service Provider will give all interested persons or parties reasonable
prior written notice before disclosing any information considered confidential under this Section 9.4.7.
Protection of information as provide for under this Section 9.4 will remain an obligation
notwithstanding the status of a Certificate (current or revoked) or the status of the CA.
Sensitivity of Information
See the ISRG privacy policy located at [insert location of ISRG privacy policy – e.g., web address of the
Repository if it will be kept there]
Opportunity to Correct Private Information
Subscribers and Relying Parties must be given access and the ability to correct or modify their personal or
Organization information. The CA must provide this information on appropriate request, but only after
taking proper steps to authenticate the identity of the requesting party.
Intellectual Property Rights
A Private Key will be treated as the sole property of the legitimate holder of the ISRG Certificate
containing the corresponding Public Key.
Page 69
Page 69 of 83
“ISRG” is registered in the U.S. Patent and Trademark Office as a mark of ISRG.
This Policy, its OID, and the [include other properties to which ownership is to be asserted, e.g. the ISRG
mark] are the intellectual property of ISRG and/or its licensors, protected by trademark, copyright and other
laws regarding intellectual property, and may be used only pursuant to a license or other express permission
from ISRG, and then only in accordance with the provisions of such express permission and this Policy.
Any other use of this Policy, its OID, or [decide whether to include here other properties as entered above
in this paragraph] without the express written permission of the owner is expressly prohibited.
Representations and Warranties
CA Representations and Warranties
The warranties required of a CA to Subscribers and Authorized Relying Parties under Section 9.6.1.1,
9.6.1.2, 9.6.1.3, and 9.6.1.4 will be subject to the limitations and disclaimers set forth elsewhere in this
Policy. A CA may provide further limitations and exclusions on these warranties as the CA deems
appropriate, relating to:
(i) the Subscriber’s (a) improper use of Certificates or key pairs, (b) failure to safeguard Private Keys, (c)
failure to comply with the provisions of this Policy or of any agreement with the CA or RA, and/or (d)
other actions giving rise to any loss;
(ii) Events beyond the reasonable control of the CA and the RAs; and
(iii) Time limitations for the filing of claims.
However, such limitations and exclusions may not, in any event, be less than those otherwise provided for
in Section 9.
9.6.1.1 Warranties from CA to Subscriber
CAs must provide the following warranties, in a separate writing or in contract, to all Subscribers of
Certificates they issue:
• The CA has issued and managed the Certificate in accordance with the applicable Certificate
Agreement (and in accordance with this Policy and any applicable CPS, if this Policy has been
incorporated by reference in the Certificate Agreement (see Section 1.3.1)); and
• The Certificate meets all requirements of the applicable Certificate Agreement (and this Policy and any
applicable CPS, if this Policy has been incorporated by reference in the Certificate Agreement (see
Section 1.3.1)).
Such warranties shall be made as of (i) the time of the Subscriber’s Acceptance of the Certificate; and (ii)
the time that the Subscriber’s Certificate is used during its Operational Period.
9.6.1.2 Warranties from CA to Relying Party
A CA may provide a validation warranty to a Relying Party for a per transaction amount for transactions in
which the Relying Party exercises Reasonable Reliance on a Certificate. In such instances, the CA warrants
that:
• The CA has issued and managed the Certificate in accordance with this Policy;
• The CA complied with the requirements of this Policy and any applicable CPS when verifying the
identity of the Subscriber;
• There are no material misrepresentations of fact in the Certificate known to the CA, and the CA has
taken steps as required under this Policy to verify the information contained in the Certificate;
• The CA has taken all steps required by this Policy to ensure that the Subscriber’s submitted
information has been accurately transcribed to the Certificate;
• Information provided by the CA concerning the current validity of the Certificate is accurate and that
validity has not been diminished by the CA’s failure to promptly revoke the Certificate in accordance
with Section 4.9; and
Page 70
Page 70 of 83
• The Certificate meets all material requirements of this Policy and any applicable CPS.
These warranties apply to any Relying Party who (i) relies on a Certificate in an electronic transaction in
which the Certificate played a material role in verifying the identity of one or more persons or devices; (ii)
exercises Reasonable Reliance on that Certificate; and (ii) follows all procedures required by this Policy
and by the applicable Relying Party Agreement for verifying the status of the Certificate. These warranties
are made to the Relying Party as of the time the Repository is referenced to determine Certificate validity,
and only if the Certificate is valid and not revoked at that time.
9.6.1.3 CA to Certificate Beneficiaries
The representations and warranties of the CA set forth in this Section 9.6.1.3 are made to the Certificate
Beneficiaries by CA when it issues a Certificate.
The CA represents and warrants to the Certificate Beneficiaries that, during the period when the Certificate
is valid, the CA has complied with these Requirements and its Certificate Policy and/or Certification
Practice Statement in issuing and managing the Certificate.
The warranties that a CA provides to the Certificate Beneficiaries specifically include, but are not limited
to, those set forth below.
1. Right to Use Domain Name. That, at the time of issuance, the CA: (i) implemented a procedure for
verifying that the Applicant either had the right to use, or had control of, the Domain Name(s) and IP
address(es) listed in the Certificate’s subject field and subjectAltName extension (or, only in the case
of Domain Names, was delegated such right or control by someone who had such right to use or
control); (ii) followed the procedure when issuing the Certificate; and (iii) accurately described the
procedure in this Certificate Policy and/or the corresponding 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 of the Certificate and that the Applicant
Representative is authorized to request the Certificate on behalf of the Subject; (ii) followed the
procedure when issuing the Certificate; and (iii) accurately described the procedure in this Certificate
Policy and/or the corresponding 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 in the Certificate (with the exception of the
subject:organizationalUnitName attribute); (ii) followed the procedure when issuing the Certificate;
and (iii) accurately described the procedure in this Certificate Policy and/or the corresponding
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; and (iii) accurately described the procedure in this Certificate Policy and/or the
corresponding 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 accordance with Sections 9.2.4 and
11.2 in the CA/B Forum Baseline Requirements; (ii) followed the procedure when issuing the
Certificate; and (iii) accurately described the procedure in this Certificate Policy and/or the
corresponding Certification Practice Statement.
6. Subscriber Agreement. That, if the CA and Subscriber are not Affiliated, the Subscriber and CA are
parties to a legally valid and enforceable Subscriber Agreement that satisfies these Requirements, or, if
the CA and Subscriber are Affiliated, the Applicant Representative acknowledged and accepted the
Terms of Use.
Page 71
Page 71 of 83
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 these
Requirements.
9.6.1.4 General Representations and Warranties of CA
By issuing a Certificate, the CA represents that it followed the procedure set forth this Policy and its
Certification Practice Statement to verify that, as of the Certificate’s issuance date, all of the Subject
Information was accurate.
By issuing a Subordinate CA Certificate, the CA represents that it followed the procedure set forth in this
Policy and its Certification Practice Statement to verify that, as of the Subordinate CA Certificate’s
issuance date, all of the Subject Information was accurate.
The CA represents that all Certificates containing a policy identifier indicating compliance with the CAB/F
Baseline Requirements are issued and managed in accordance with the CAB/F Baseline Requirements.
Every Subordinate CA shall represent, in its Certificate Policy and/or Certification Practice Statement, that
all Certificates containing a policy identifier indicating compliance with the CAB/F Baseline Requirements
are issued and managed in accordance with the CAB/F Baseline Requirements.
RA Representations and Warranties
When an RA submits to the CA information relating to or of an Applicant, Subscriber or sponsoring
organization, the RA represents that the RA has authenticated the identity of the Applicant, Subscriber, or
sponsoring organization, as applicable, in accordance with the authentication requirements of this Policy.
The RA shall provide all the warranties and representations provided hereunder for those obligations of a
CA which the RA is delegated by the CA.
Applicant/Subscriber Representations and Warranties
Each Applicant/Subscriber represents and warrants that it has and will, as applicable, fulfil all obligations
of Applicant/Subscriber set forth in this Policy.
Relying Party Obligations, Representations and Liability
Each Relying Party represents and warrants that it has and will, as applicable, fulfil all obligations of
Relying Party set forth in this Policy.
Representations and Warranties of Other PKI Participants
Each Relying Party represents and warrants that it has and will, as applicable, fulfil all obligations of
Relying Party set forth in this Policy.
Each Certificate Manufacturing Authority represents and warrants that it has and will, as applicable, fulfil
all obligations of Certificate Manufacturing Authority set forth in this Policy.
Disclaimer of Warranties
If a Relying Party relies on a Certificate that was expired or that the Relying Party knew or should have
known was revoked at the time of reliance (e.g., a decision to rely on a revoked Certificate based on the
reasons for revocation, information from other sources, or specific business considerations pertaining to the
Relying Party), the Relying Party does so at its own risk and, in so relying, waives any warranties that any
PKI Service Provider may have provided.
Page 72
Page 72 of 83
Limitations of Liability
PKI Service Providers assume no liability whatsoever in relation to the use of Certificates or associated key
pairs for any use other than in accordance with this Policy or related agreements.
The PKI Service Providers, and their employees, servants or agents, make no representations or warranties,
express or implied, other than as expressly stated in this Policy or in an agreement between the PKI Service
Provider and a Subscriber or Relying Party.
Except as expressly prohibited in this Policy, PKI Service Providers may disclaim all warranties and
obligations of any type, including without limitation (i) any warranty of merchantability; (ii) any warranty
of fitness for a particular purpose; (iii) any warranty of accuracy of information provided; and (iv) any
warranty of non-infringement.
The PKI Service Providers are neither intermediaries nor guarantors of the underlying transactions between
Subscribers and Relying Parties. Recourse, liability, and dispute resolution for claims solely between
Subscribers and Relying Parties (e.g., claims of non-performance not related to Subscriber identity) shall be
under applicable law.
Claims against PKI Service Providers are limited to showing that the PKI Service Providers operated in a
manner inconsistent with this Policy, the applicable CPS, or a related agreement or warranty.
PKI Service Providers are responsible to a Relying Party only if the Relying Party has complied with all
obligations, terms, and conditions of this Policy and of the applicable Relying Party Agreement, and only to
the extent otherwise allowed by this Policy. In addition, PKI Service Providers are responsible to a Relying
Party only for direct damages suffered by such Relying Party that are (a) caused by the failure of the PKI
Service Provider to comply with the terms of this Policy, the CPS, or a related agreement or warranty, and
(b) sustained by such Relying Party as a result of Reasonable Reliance on a Certificate in accordance with
this Policy.
PKI Service Providers may enter into indemnification agreements with other PKI Service Providers to
appropriately allocate the risk and financial responsibility arising from the parties’ respective duties and
obligations. Notwithstanding the immediately preceding sentence, for tasks delegated by a CA to any
Delegated Third Party, the CA and Delegated Third Party may allocate liability between themselves
contractually as they determine, but the CA shall remain fully responsible for the performance of all parties
in accordance with the CA/B Forum Baseline Requirements, as if the tasks had not been delegated and
regardless of whether CA and the Delegated Third Party entered an indemnification agreement in
accordance with the immediately preceding sentence.
Except to the extent such liability is specified by the other provisions of this Policy, a CA’s liability to a
Subscriber or Relying Party will be determined in accordance with any agreement between the CA and the
Subscriber or Relying Party.
Except to the extent liability is limited by the other provisions of this Policy, an RA’s liability to a
Subscriber will be determined in accordance with any agreement between the RA and the Subscriber.
A Relying Party found to have acted in a manner counter to the obligations of a Relying Party under this
Policy forfeits all claims he, she, or it may have against any PKI Service Providers.
This Policy establishes an open-but-bounded PKI. PKI Service Providers will not be liable to any person
who relies upon a Certificate unless such liability is clearly established by contract, special warranty or law.
Unless otherwise provided in separate writing or in contract, the total, maximum, aggregate liability of a
CA or RA for all Certificates issued under this Policy and for all transactions relying on Certificates is
$10,000,000.
Page 73
Page 73 of 83
Unless otherwise provided in separate writing or in contract, the maximum potential liability for a CA or
RA to any Relying Party with respect to any one Certificate upon which the Relying Party relies will be
limited to (a) $100,000 per transaction; and (b) $250,000 for all transactions in which the Relying Party
relies on the Certificate. The CA and RAs may limit their liability to a Subscriber with respect to the
Subscriber’s Certificate to the amount received by the CA and/or RA from the Subscriber with respect to
such Certificate.
If the CA has issued and managed the Certificate in compliance with the CA/B Forum Baseline
Requirements and this Policy and/or corresponding Certification Practice Statement, the CA may disclaim
liability to the Certificate Beneficiaries or any other third parties for any losses suffered as a result of use or
reliance on such Certificate beyond those specified in this Certificate Policy and/or the corresponding
Certification Practice Statement. If the CA has not issued or managed the Certificate in compliance with the
CA/B Forum Baseline Requirements and this Certificate Policy and/or the corresponding Certification
Practice Statement, the CA may seek to limit its liability to the Subscriber and to Relying Parties,
regardless of the cause of action or legal theory involved, for any and all claims, losses or damages suffered
as a result of the use or reliance on such Certificate by any appropriate means that the CA desires. If the CA
chooses to limit its liability for Certificates that are not issued or managed in compliance with these
Requirements or its Certificate Policy and/or Certification Practice Statement, then the CA shall include the
limitations on liability in this Certificate Policy and/or corresponding Certification Practice Statement.
Indemnities
Each Subscriber and Relying Party will indemnify and hold the PKI Service Providers and their respective
directors, officers, employees, agents and affiliates harmless from any and all liability arising out of the
Subscriber’s use of a Certificate for other than its intended use.
The Root CA shall be responsible for the performance and warranties of the Subordinate CA, for the
Subordinate CA’s compliance with this Policy, and for all liabilities and indemnification obligations of the
Subordinate CA under this Policy, as if the Root CA were the Subordinate CA issuing the Certificates.
Notwithstanding any limitations on its liability to Subscribers and Relying Parties, the CA understands and
acknowledges that the Application Software Suppliers who have a Root Certificate distribution agreement
in place with a Root CA to which the CA is a Subordinate CA do not assume any obligation or potential
liability of the CA under these Requirements or that otherwise might exist because of the issuance or
maintenance of Certificates or reliance thereon by Relying Parties or others. Thus, except in the case where
the CA is a government entity, the CA shall defend, indemnify, and hold harmless each Application
Software Supplier for any and all claims, damages, and losses suffered by such Application Software
Supplier related to a Certificate issued by the CA, regardless of the cause of action or legal theory involved.
This does not apply, however, to any claim, damages, or loss suffered by such Application Software
Supplier related to a Certificate issued by the CA where such claim, damage, or loss was directly caused by
such Application Software Supplier’s software displaying as not trustworthy a Certificate that is still valid,
or displaying as trustworthy (a) a Certificate that has expired or (b) a Certificate that has been revoked (but
only in cases where the revocation status is currently available from the CA online, and the application
software either failed to check such status or ignored an indication of revoked status).
Term and Termination
Term
This Policy, as amended from time to time, shall remain in force until it is replaced by a new version or
terminated.
Termination
Termination of this CP is at the discretion of the PMA. A CA’s termination of their CPS is at the discretion
of the CA.
Page 74
Page 74 of 83
Effect of Termination and Survival
The following sections of this CP shall survive termination or expiration of this CP: [ISRG to determine
and insert set].
Individual Notices and Communications with Participants
All communication among Participants shall be in writing or via digitally signed communication. If in
writing, the communication shall be signed on the appropriate Organization letterhead. If electronic, a
Digital Signature shall be made using a Private Key whose companion Public Key is certified using a
Certificate meeting the requirements set in this Policy or other Certification Policy as determined the PMA.
Amendments
Procedure for Amendment
All changes to this Policy that may materially affect Subscribers or Relying Parties are subject to a 15-day
notification requirement. Affected PKI Participants may file comments with the PMA within 15 days of
original notice. Written and signed comments on proposed changes must be directed to the PMA. Decisions
with respect to the proposed changes are at the sole discretion of the PMA.
Notification Mechanism and Period
Editorial and typographical corrections, changes to contact details and other minor changes that do not
materially impact PKI Participants may be changed without notice and are not subject to the notification
requirements herein.
The PMA will notify all interested persons of proposed changes, the final date for receipt of comments, and
the proposed effective date of change. A copy of this Policy is available in electronic form on the Internet
at [insert Repository address], and via e-mail from [insert email address]. In the event that the PMA
considers making changes to this Policy that are subject to notification requirements, the PMA will post the
proposed changes on its Web site along with the final date for receipt of comments and the proposed
effective date of change. The resulting changes, if any, to this Policy shall become effective after the a
revised version of this Policy incorporating such changes is posted to the Repository on or after date so
posted as the proposed effective date of change.
Circumstances under Which OID Must Be Changed
If a change in this Policy is determined by the ISRG PMA to change the level of assurance associated with
a then-current OID for a particular type of Certificate, then a revised version of this Policy shall be made
available by the ISRG PMA in conformity with the amendment process applicable to and described within
this Policy, which revised version will contain a revised OID for such type of Certificate.
Dispute Resolution Provisions
In the event of any dispute or disagreement between two or more PKI Participants (“Disputing Parties”)
arising out of or related to this Policy (including but not limited to in connection with any Certificate issued
by a CA under this Policy), the Disputing Parties will use their best efforts to settle the dispute or
disagreement through mediation or good faith negotiations following notice from one Disputing Party to
the other(s). If the Disputing Parties cannot reach a mutually agreeable resolution of the dispute or
disagreement within sixty (60) days following the date of such notice, then the Disputing Parties will
submit the dispute to binding arbitration. The American Arbitration Association’s Rules for Commercial
Arbitration and Optional Rules for Emergency Measures of Protection will apply to the proceedings.
This provision will not limit the right of party to obtain other recourse and relief under any applicable law
for disputes or disagreements that do not arise out of or which are not related to this Policy or an ISRG
Certificate.
Page 75
Page 75 of 83
Governing Law
Subject to any limits appearing in applicable law, the laws of the state of [insert state and country], shall
govern the enforceability, construction, interpretation, and validity of this Policy, irrespective of contract or
other choice of law provisions and without the requirement to establish a commercial nexus in [insert state
and country]. This choice of law is made to ensure uniform procedures and interpretation for all PKI
Participants, no matter where they are located.
This governing law provision applies only to this Policy. Agreements incorporating this Policy by reference
may have their own governing law provisions, provided that this Section 9.14 governs the enforceability,
construction, interpretation, and validity of the terms of this Policy separate and apart from the remaining
provisions of any such agreements, subject to any limitations appearing in applicable law.
Compliance with Applicable Law
The CA shall at all times:
1. Issue Certificates and operate its PKI in accordance with all law applicable to its business and the
2. Certificates it issues in every jurisdiction in which it operates;
3. Comply with the CA/B Forum Baseline Requirements;
4. Comply with the audit requirements set forth in Section 17 in the CA/B Forum Baseline Requirements;
and
5. Be licensed as a CA in each jurisdiction where it operates, if licensing is required by the law of such
jurisdiction for the issuance of Certificates.
Notwithstanding the provisions of Section 9.16.3, if a court or government body with jurisdiction over the
activities covered by these Requirements determines that the performance of any mandatory requirement is
illegal, then such requirement is considered reformed to the minimum extent necessary to make the
requirement valid and legal. This applies only to operations or certificate issuances that are subject to the
laws of that jurisdiction. The parties involved shall notify the CA/B Forum of the facts, circumstances, and
law(s) involved, so that the CA/Browser Forum may revise the Baseline Requirements accordingly.
Miscellaneous Provisions
Entire Agreement
Except where specified by other contracts, this Policy and any applicable CPS shall constitute the entire
understanding and agreement between the parties with respect to the transactions contemplated, and
supersedes any and all prior or contemporaneous oral or written representation, understanding, agreement
or communication concerning the subject matter hereof. No party is relying upon any warranty,
representation, assurance or inducement not expressly set forth herein.
Assignment
Without the written consent of the CA, PKI Participants may not assign any of their rights or obligations
under this Policy or any applicable CPS or agreements entered into in accordance with the terms of this
Policy or such CPS.
Severability
In the event that a clause or provision of this Policy is held to be unenforceable by a court of law or other
tribunal having authority, the remainder of the Policy shall remain valid.
Enforcement (Attorney Fees and Waiver of Rights)
No waiver of any breach or default or any failure to exercise any right hereunder shall be construed as a
waiver of any subsequent breach or default or relinquishment of any future right to exercise such right. The
headings in this CP are for convenience only and cannot be used in interpreting this CP.
Page 76
Page 76 of 83
Other Provisions
Relationship
No joint venture, partnership, trust, agency or fiduciary relationship is established or deemed to be
established among any of the parties using this Policy or the PKI established pursuant hereto. Issuance of
Certificates in accordance with this Policy does not make the CA, or any RA, an agent, fiduciary, trustee, or
other representative of Subscribers or Authorized Relying Parties.
Force Majeure
No PKI Service Provider shall incur liability if it is prevented, forbidden, or delayed from performing, or
omits to perform, any act or requirement by reason of: (i) any provision of any applicable law, regulation or
order; civil, governmental or military authority; (ii) the failure of any electrical, communication, or other
system operated by any other party over which the PKI Service Provider has no control; (iii) fire, flood, or
other emergency condition; (iv) strike, acts of terrorism, war or act of god; or (v) other similar causes
beyond its reasonable control and without the fault or negligence of the PKI Service Provider.
Page 77
Page 77 of 83
10 Certificate Profiles
Root CA Certificate
Field
Value
Version
V3 (2)
Serial Number
Must be unique
Issuer Signature Algorithm
As stipulated in Section 7.1.3
Issuer Distinguished Name
cn= ISRG Root X [n], o= Internet Security Research Group, C=US
where [n] in an integer starting in 1 and represents the instance of the Root
CA. For example, ISRG Root X1, ISRG Root X2, etc.
Validity Period
Up to 25 years. Dates expressed in UTC format. See Section 6.3.2.
Subject Distinguished Name
Same as issuer DN
Subject Public Key Information
As stipulated in Section 6.1.4
Issuer’s Signature
As stipulated in Section 7.1.3
Extensions
Subject Key Identifier
Not Critical. Required.
Octet String (20 byte SHA-1 hash of the binary DER encoding of the Root
CA public key information)
Key Usage
Critical. Required.
keyCertSign, cRLSign
Extended Key Usage
Not Present
Private Key Usage Period
Not Present
Private Key Usage Period
Not Present
Certificate Policies
Not Present
Subject Information Access
Not Present
Policy Mapping
Not Present
Subject Alternative Name
Not Present
Issuer Alternative Name
Not Present
Subject Directory Attributes
Not Present
Basic Constraints
Critical. Required.
cA=True, pathLength constraint absent
Policy Constraints
Not Present
CRL Distribution Points
Not Present
Subordinate CA Certificate
Field
Value
Version
V3 (2)
Serial Number
Must be unique
Issuer Signature Algorithm
As stipulated in Section 7.1.3
Issuer Distinguished Name
Derived from the Issuer subject DN
Validity Period
Up to 8 years. Dates expressed in UTC format. See Section 6.3.2.
Subject Distinguished Name
cn= Let’s Encrypt Authority X[m], o=Let’s Encrypt, C=US
where m in an integer starting in 1 and represents the instance of the
subordinate CA. For example the initial instances of the subordinate CA for
DV-SSL would be Let’s Encrypt Authority X1, Let’s Encrypt Authority X12,
etc.
Subject Public Key Information
As stipulated in Section 6.1.4
Issuer’s Signature
As stipulated in Section 7.1.3
Extensions
Page 78
Page 78 of 83
Authority Key Identifier
Not Critical. Required.
Octet String (20 byte SHA-1 hash of the binary DER encoding of the Root
CA public key information)
Subject Key Identifier
Not Critical. Required.
Octet String (20 byte SHA-1 hash of the binary DER encoding of the
Subordinate CA public key information)
Key Usage
Critical. Required.
digitalSignature, keyCertSign, cRLSign
Extended Key Usage
Not Critical. Optional
id-kp-serverAuth, id-kp-clientAuth
Private Key Usage Period
Not Present
Certificate Policies
Not Critical. Required.
One or more policy OIDS from Section 1.2.2 as appropriate.
Required, a user notice qualifier
Optional, a CPS’s HTTP URI
Subject Information Access
Not Present
Policy Mapping
Not Present
Subject Alternative Name
Not Present
Issuer Alternative Name
Not Present
Subject Directory Attributes
Not Present
Basic Constraints
Critical. Optional.
cA=True, pathLength=0
Policy Constraints
Not Present
Name Constraints
Not Critical3. Optional.
As stipulated in Section 7.1.5
Authority Information Access
Not Critical. Required.
The HTTP URL of the Issuing CA’s OCSP responder MAY be omitted,
provided that the Subscriber “staples” the OCSP response for the Certificate
in its TLS handshakes. If present, contains the HTTP URI of the CA’s OCSP
responder, and the HTTP URI of the CA’s Certificate
CRL Distribution Points
Not Critical. Required.
Contains HTTP URI to CRL
DV-­SSL Certificate
Field
Value
Version
V3 (2)
Serial Number
Must be unique
Issuer Signature Algorithm
As stipulated in Section 7.1.3
Issuer Distinguished Name
Derived from the Issuer subject DN
Validity Period
Up to 39 months. Dates expressed in UTC format. See Section 6.3.2.
Subject Distinguished Name
Optional, cn= Server’s FQDN or IP Address,
Optional, C=two letter ISO code
Subject Public Key Information
As stipulated in Section 6.1.4
Issuer’s Signature
As stipulated in Section 7.1.3
Extensions
Authority Key Identifier
Not Critical. Required.
Octet String (20 byte SHA-1 hash of the binary DER encoding of the
Subordinate CA public key information)
3 Non-critical Name Constraints are an exception to RFC 5280 (4.2.1.10), however, they may be used until the
Name Constraints extension is supported by Application Software Suppliers whose software is used by a substantial
portion of Relying Parties worldwide. This is compliant with Baseline Requirements Appendix B (2).
Page 79
Page 79 of 83
Subject Key Identifier
Not Critical. Required.
Octet String (20 byte SHA-1 hash of the binary DER encoding of the public
key information)
Key Usage
Critical. Optional.
digitalSignature, keyEncipherment
Extended Key Usage
Not Critical. Required.
id-kp-serverAuth, id-kp-clientAuth
Private Key Usage Period
Not Present
Certificate Policies
Not Critical. Required.
Contains one or more policy OIDS from Section 1.2.2 as appropriate.
Recommended, a user notice qualifier
Optional, a CPS’s HTTP URI
Subject Information Access
Not Present
Policy Mapping
Not Present
Subject Alternative Name
Not Critical. Required.
At least one dNSName=FQDN;
Issuer Alternative Name
Not Present
Subject Directory Attributes
Not Present
Basic Constraints
Not Present
Policy Constraints
Not Present
Name Constraints
Not Present
Authority Information Access
Not Critical. Required.
The HTTP URL of the Issuing CA’s OCSP responder MAY be omitted,
provided that the Subscriber “staples” the OCSP response for the Certificate
in its TLS handshakes.If present, contains the HTTP URI of the CA’s OCSP
responder, and the HTTP URI of the CA’s Certificate
CRL Distribution Points
Not Critical, Optional.
Contains HTTP URI to CRL
Page 80
Page 80 of 83
Human Administrative Certificate
Field
Value
Version
V3 (2)
Serial Number
Must be unique
Issuer Signature Algorithm
As stipulated in Section 7.1.3
Issuer Distinguished Name
Derived from the Issuer subject DN
Validity Period
Up to 3 years. Dates expressed in UTC format. See Section 6.3.2.
Subject Distinguished Name
cn= [Applicant’s Full name], O=[CA’s organization Name], OU=
Administrative Certificate, C=two letter ISO code
Subject Public Key Information
As stipulated in Section 6.1.4
Issuer’s Signature
As stipulated in Section 7.1.3
Extensions
Authority Key Identifier
Not Critical. Required.
Octet String (20 byte SHA-1 hash of the binary DER encoding of the
Subordinate CA public key information)
Subject Key Identifier
Not Critical. Required.
Octet String (20 byte SHA-1 hash of the binary DER encoding of the public
key information)
Key Usage
Critical. Optional.
digitalSignature, nonRepudiation
Extended Key Usage
Not Present
Private Key Usage Period
Not Present
Certificate Policies
Not Critical. Required.
Contains administrative policy OID from Section 1.2.2 as appropriate.
Recommended, a user notice qualifier
Optional, a CPS’s HTTP URI
Subject Information Access
Not Present
Policy Mapping
Not Present
Subject Alternative Name
Not Critical. Required.
RFC822= Applicant’s email address
Issuer Alternative Name
Not Present
Subject Directory Attributes
Not Present
Basic Constraints
Not Present
Policy Constraints
Not Present
Name Constraints
Not Present
Authority Information Access
Not Critical. Required.
Not present if the OCSP responses are stapled.
If present, contains the HTTP URI of the CA’s OCSP responder, and the
HTTP URI of the CA’s Certificate
CRL Distribution Points
Not Critical, Optional.
Contains HTTP URI to CRL
OCSP Responder Certificate(s)
Field
Value
Version
V3 (2)
Serial Number
Must be unique
Issuer Signature Algorithm
As stipulated in Section 7.1.3
Issuer Distinguished Name
Derived from the Issuer subject DN
Validity Period
Up to 5 years. Dates expressed in UTC format. See Section 6.3.2.
Subject Distinguished Name
cn= [OCSP Server Name], O= [Organization Managing OCSP], C=two letter
ISO code
Page 81
Page 81 of 83
Subject Public Key Information
As stipulated in Section 6.1.4
Issuer’s Signature
As stipulated in Section 7.1.3
Extensions
Authority Key Identifier
Not Critical. Required.
Octet String (20 byte SHA-1 hash of the binary DER encoding of the CA
(either the Root CA or Subordinate CA) public key information)
Subject Key Identifier
Not Critical. Required.
Octet String (20 byte SHA-1 hash of the binary DER encoding of the public
key information)
Key Usage
Critical. Optional.
digitalSignature,
Extended Key Usage
Not Critical. Required.
id-kp-OCSPSigning
Certificate Policies
Not Critical. Optional.
All the certificate policies, from Section 1.2.2, under which the CA issues
Certificates.
Subject Alternative Name
Not Critical. Required.
OCSP responder’ URL
No Check
Not Critical. Required.
id-pkix-ocsp-nocheck
Authority Information Access
Not Critical. Optional.
Pointer to the CA Certificate
Basic Constraints
Critical. Optional.
cA=False
Root CRL
Field
CRL Value
Version
V2 (1)
Issuer Signature Algorithm
As stipulated in Section 7.1.3
Issuer Distinguished Name
Derived from the Issuer subject DN
cn= ISRG Root CA [n], o= ISRG, C=US
where [n] in an integer starting in 1 and represents the instance of the Root
CA. For example, ISRG Root CA 1, ISRG Root CA 2, etc.
thisUpdate
Time and date expressed in UTC format.
nextUpdate
Time and date expressed in UTC format.
ThisUpdate + (up to) 12 months
Revoked Certificates List
0 or more 2-tuple of certificate serial number and revocation date (UTC
Format)
Issuer’s Signature
As stipulated in Section 7.1.3
CRL Extensions
CRL Number
Integer
Authority Key Identifier
Not Critical. Required.
Octet String (20 byte SHA-1 hash of the binary DER encoding of the CA
public key information)
CRL Extensions
Invalidity Date
Optional
Reason Code
Must be present if one of the following: Key Compromise, CA Compromised,
Affiliation Changed, Superseded, and Cessation of Operations. Absent
Otherwise.
Page 82
Page 82 of 83
Subordinate CRL (Optional)
Field
CRL Value
Version
V2 (1)
Issuer Signature Algorithm
As stipulated in Section 7.1.3
Issuer Distinguished Name
cn= ISRG [Type] CA [m], o= ISRG, o=TBD, C=US
where Type represents the type of certificate issued from the CA.
where m in an integer starting in 1 and represents the instance of the
subordinate CA. For example the initial instances of the subordinate CA for
DV-SSL would be ISRG DV-SSL CA 1, ISRG DV-SSL CA 2, etc.
thisUpdate
Time and date expressed in UTC format.
nextUpdate
Time and date expressed in UTC format.
ThisUpdate + (up to) 7 days
Revoked Certificates List
0 or more 2-tuple of certificate serial number and revocation date (UTC
Format)
Issuer’s Signature
As stipulated in Section 7.1.3
CRL Extensions
CRL Number
Integer
Authority Key Identifier
Not Critical. Required.
Octet String (20 byte SHA-1 hash of the binary DER encoding of the CA
public key information)
CRL Extensions
Invalidity Date
Optional
Reason Code
Must be present if one of the following: Key Compromise, Affiliation
Changed, Superseded, and Cessation of Operations. Absent Otherwise.
OCSP Request Format
Field
Expected Value
Version
V1 (0)
Requester Name
Not Required
Request List
List of Certificates
Signature
Not Required
Extensions
Not Required
OCSP Response Format
Field
Expected Value
Response Status
Successful | Malformed Request | Internal Error | Try Later
Response Type
id-pkix-ocsp-basic
Version
V1 (0)
Responder ID
Hash of Responder Public Key
Produced At
Generalized Time
List of Responses
Each response will contain Certificate identifier, Certificate status4,
thisUpdate, nextUpdate
Signature Algorithm
As stipulated in Section 7.1.3
4 Certificate Status. If the Certificate is revoked, the OCSP Responder will provide revocation time and revocation
reason
Page 83
Page 83 of 83
Signature
Present
Certificates
Applicable Certificates issued to the OCSP Responder
Extensions
Not Required
Nonce
Will be present if nonce extension is present in the request.