«Forum Guideline CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.1.9 (Current through ...»
Issuance and Management
Publicly-Trusted Certificates, v.1.1.9
(Current through adoption of Ballot 129 on 4 August 2014)
Copyright © 2011-2014, The CA / Browser Forum, all rights reserved.
Verbatim copying and distribution of this entire document is permitted in any medium without royalty, provided this
notice is preserved.
Upon request, the CA / Browser Forum may grant permission to make a translation of this document into a language other than English. In such circumstance, copyright in the translation remains with the CA / Browser Forum. In the event that a discrepancy arises between interpretations of a translated version and the original English version, the original English version shall govern. A translated version of the document must prominently display the following statement in the language of the translation:Copyright © 2011-2014 The CA / Browser Forum, all rights reserved.
This document is a translation of the original English version. In the event that a discrepancy arises between interpretations of this version and the original English version, the original English version shall govern.' A request to make a translated version of this document should be submitted to email@example.com.
i Forum Guideline Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v. 1.1.9 This version 1.1.9 represents the Baseline Requirements, as adopted by the CA/Browser Forum as of Ballot 129, passed by the Forum on 4 August 2014.
These Baseline Requirements describe an integrated set of technologies, protocols, identity-proofing, lifecycle management, and auditing requirements that are necessary (but not sufficient) for the issuance and management of Publicly-Trusted Certificates; Certificates that are trusted by virtue of the fact that their corresponding Root Certificate is distributed in widely-available application software. The Requirements are not mandatory for Certification Authorities unless and until they become adopted and enforced by relying–party Application Software Suppliers.
Notice to Readers This version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates present criteria established by the CA/Browser Forum for use by Certification Authorities when issuing, maintaining, and revoking publicly-trusted
Relevant Compliance Dates Compliance Summary Description (See Full Text for Details) 2013-01-01 For RSA public keys, CAs SHALL confirm that the value of the public exponent is an odd number equal to 3 or more. (Appendix A – (4) General Requirements for Public Keys) 2013-01-01 CAs SHALL support an OCSP capability using the GET method.
2013-01-01 CAs SHALL comply with the Network and Certificate System Security Requirements.
2013-08-01 OCSP Responders SHALL NOT respond “Good” for Unissued Certificates.
2013-09-01 CAs SHALL revoke any certificate where wildcard character occurs in the first label position immediately to the left of a “registry-controlled” label or “public suffix”.
2013-12-31 CAs SHALL confirm that the RSA Public Key is at least 2048 bits or that one of the following ECC curves is used: P-256, P-384, or P-521. A Root CA Certificate issued prior to 31 Dec. 2010 with an RSA key size less than 2048 bits MAY still serve as a trust anchor.
2015-04-01 CAs SHALL NOT issue certificates with validity periods longer than 39 months.
2015-11-01 Issuance of Certificates with Reserved IP Address or Internal Name prohibited.
2016-10-01 All Certificates with Reserved IP Address or Internal Name must be revoked.
ii Forum Guideline
TABLE OF CONTENTS
5. Abbreviations and Acronyms
7. Certificate Warranties and Representations
7.1 By the CA
7.1.1 Certificate Beneficiaries
7.1.2 Certificate Warranties
7.2 By the Applicant
8. Community and Applicability
8.2 Certificate Policies
8.3 Commitment to Comply
8.4 Trust model
9. Certificate Content and Profile
9.1 Issuer Information
9.1.1 Issuer Common Name Field
9.1.2 Issuer Domain Component Field
9.1.3 Issuer Organization Name Field
9.1.4 Issuer Country Name Field
9.2 Subject Information
9.2.1 Subject Alternative Name Extension
9.2.2 Subject Common Name Field
9.2.3 Subject Domain Component Field
9.2.4 Subject Distinguished Name Fields
9.2.5 Subject Country Name Field
9.2.6 Subject Organizational Unit Field
9.2.7 Subject Information – Subordinate CA Certificates
9.2.8 Other Subject Attributes
9.3 Certificate Policy Identification
9.3.1 Reserved Certificate Policy Identifiers
9.3.2 Root CA Certificates
9.3.3 Subordinate CA Certificates
9.3.4 Subscriber Certificates
9.4 Validity Period
9.4.1 Subscriber Certificates
9.5 Public Key
9.6 Certificate Serial Number
9.7 Technical Constraints in Subordinate CA Certificates via Name Constraints and EKU
9.8 Additional Technical Requirements
10. Certificate Application
10.1 Documentation Requirements
10.2 Certificate Request
10.2.2 Request and Certification
10.2.3 Information Requirements
10.2.4 Subscriber Private Key
10.2.5 Subordinate CA Private Key
iii Forum Guideline 10.3.2 Agreement Requirements
11. Verification Practices
11.1.1 Authorization by Domain Name Registrant
11.1.2 Authorization for an IP Address
11.1.3 Wildcard Domain Validation
11.1.4 New gTLD Domains
11.2 Verification of Subject Identity Information
11.2.3 Authenticity of Certificate Request
11.2.4 Verification of Individual Applicant
11.2.5 Verification of Country
11.3 Age of Certificate Data
11.4 Denied List
11.5 High Risk Requests
11.6 Data Source Accuracy
12. Certificate Issuance by a Root CA
13. Certificate Revocation and Status Checking
13.1.1 Revocation Request
13.1.2 Certificate Problem Reporting
13.1.5 Reasons for Revoking a Subscriber Certificate
13.1.6 Reasons for Revoking a Subordinate CA Certificate
13.2 Certificate Status Checking
13.2.3 Response Time
13.2.4 Deletion of Entries
13.2.5 OCSP Signing
13.2.6 Response for non-issued certificates
13.2.7 Certificate Suspension
14. Employees and Third Parties
14.1 Trustworthiness and Competence
14.1.1 Identity and Background Verification
14.1.2 Training and Skill Level
14.2 Delegation of Functions
14.2.2 Compliance Obligation
14.2.3 Allocation of Liability
14.2.4 Enterprise RAs
15. Data Records
15.1 Documentation and Event Logging
15.2 Events and Actions
15.3.1 Audit Log Retention
15.3.2 Documentation Retention
16. Data Security
16.2 Risk Assessment
16.3 Security Plan
16.4 Business Continuity
16.5 System Security
iv Forum Guideline
16.6 Private Key Protection
17.1 Eligible Audit Schemes
17.2 Audit Period
17.3 Audit Report
17.4 Pre-Issuance Readiness Audit
17.5 Audit of Delegated Functions
17.6 Auditor Qualifications
17.7 Key Generation Ceremony
17.8 Regular Quality Assessment Self Audits
17.9 Regular Quality Assessment of Technically Constrained Subordinate CAs
18. Liability and Indemnification
18.1 Liability to Subscribers and Relying Parties
18.2 Indemnification of Application Software Suppliers
18.3 Root CA Obligations
Appendix A - Cryptographic Algorithm and Key Requirements (Normative)
Appendix B – Certificate Extensions (Normative)
Appendix C - User Agent Verification (Normative)
v Forum Guideline
1. Scope The Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates describe a subset of the requirements that a Certification Authority must meet in order to issue Publicly Trusted Certificates. Except where explicitly stated otherwise, these requirements apply only to relevant events that occur on or after the Effective Date.
These Requirements do not address all of the issues relevant to the issuance and management of Publicly-Trusted Certificates. The CA/Browser Forum may update the Requirements from time to time, in order to address both existing and emerging threats to online security. In particular, it is expected that a future version will contain more formal and comprehensive audit requirements for delegated functions.
This version of the Requirements only addresses Certificates intended to be used for authenticating servers accessible through the Internet. Similar requirements for code signing, S/MIME, time-stamping, VoIP, IM, Web services, etc. may be covered in future versions.
These Requirements do not address the issuance, or management of Certificates by enterprises that operate their own Public Key Infrastructure for internal purposes only, and for which the Root Certificate is not distributed by any Application Software Supplier.
These Requirements are applicable to all Certification Authorities within a chain of trust. They are to be flowed down from the Root Certification Authority through successive Subordinate Certification Authorities.
2. Purpose The primary goal of these Requirements is to enable efficient and secure electronic communication, while addressing user concerns about the trustworthiness of Certificates. The Requirements also serve to inform users and help them to make informed decisions when relying on Certificates.
3. References ETSI TS 119 403, Electronic Signatures and Infrastructures (ESI); Trust Service Provider Conformity Assessment General Requirements and Guidance.
ETSI TS 102 042, Electronic Signatures and Infrastructures (ESI); Policy requirements for certification authorities issuing public key certificates.
FIPS 140-2, Federal Information Processing Standards Publication - Security Requirements For Cryptographic Modules, Information Technology Laboratory, National Institute of Standards and Technology, May 25, 2001.
ISO 21188:2006, Public key infrastructure for financial services -- Practices and policy framework.
NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications, http://csrc.nist.gov/publications/nistpubs/800-89/SP-800-89_November2006.pdf.
RFC2119, Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement Levels, Bradner, March 1997.
RFC2527, Request for Comments: 2527, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework, Chokhani, et al, March 1999.
RFC2560, Request for Comments: 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol
- OCSP M. Myers, et al, June 1999.
RFC3647, Request for Comments: 3647, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework, Chokhani, et al, November 2003.
RFC4366, Request for Comments: 4366, Transport Layer Security (TLS) Extensions, Blake-Wilson, et al, April 2006.
RFC5019, Request for Comments: 5019, The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments, A. Deacon, et al, September 2007.
RFC5280, Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile, Cooper et al, May 2008.
WebTrust for Certification Authorities Version 2.0, available at http://www.webtrust.org/homepagedocuments/item27839.aspx.
X.509v3, ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks.
4. Definitions Affiliate: A corporation, partnership, joint venture or other entity controlling, controlled by, or under common control with another entity, or an agency, department, political subdivision, or any entity operating under the direct control of a Government Entity.
Applicant: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate issues, 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.