View source for CA/CertificatePolicyV2.1

= About Mozilla's CA Certificate Policy Version 2.1 =

== Purpose of this update ==

Mozilla is working towards stronger controls and visibility of publicly-trusted issuing certificates in order to make better trust decisions, detect security incidents faster, and limit the impact of each security incident. [http://www.mozilla.org/projects/security/certs/policy/ Version 2.1 of Mozilla's CA Certificate Policy] encourages CAs to technically constrain subordinate CA certificates using RFC 5280 extensions that are specified directly in the intermediate certificate and controlled by crypto code (e.g. NSS). We recognize that technically constraining subordinate CA certificates may not be practical in some cases, so the subordinate CA certificates that are not technically constrained will have to be audited in accordance with [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Mozilla's CA Certificate Policy] and publicly disclosed.

Additionally, Version 2.1 of Mozilla's CA Certificate Policy requires CAs to update their operations and SSL certificate issuance to comply with [https://www.cabforum.org/Baseline_Requirements_V1_1.pdf version 1.1 of the CA/Browser Forum Baseline Requirements.] The CA/Browser Forum Baseline Requirements (BRs) provide a foundation for best practices across the industry by defining a single, consolidated set of essential standards for all SSL/TLS certificates.

== Time Frames for included CAs to comply with the new policy ==

Version 2.1 of [http://www.mozilla.org/projects/security/certs/policy Mozilla's CA Certificate Policy] was published on February 14, 2013. 

Certificates issued before February 15, 2013, must at least meet the requirements of [[CA:CertificatePolicyV2.0 | Version 2.0 of Mozilla's CA Certificate Policy.]]

Any Certificate Authority being considered for root inclusion after February 15, 2013 must comply with [http://www.mozilla.org/projects/security/certs/policy Version 2.1 of Mozilla's CA Certificate Policy.]

CAs that were already included in Mozilla's program as of February 15, 2013 will have transition time frames (see below) for them to make the necessary changes in order to comply with the new requirements in [http://www.mozilla.org/projects/security/certs/policy Version 2.1 of Mozilla's CA Certificate Policy.]

=== Audit Criteria ===
[http://www.mozilla.org/projects/security/certs/policy/ Version 2.1 of Mozilla's CA Certificate Policy] adds the requirement that SSL certificate issuance also be audited according to the [https://www.cabforum.org/Baseline_Requirements_V1_1.pdf CA/Browser Forum's Baseline Requirements.] CAs with a root certificate that has the websites (SSL/TLS) trust bit enabled in Mozilla's CA Certificate Program shall have their SSL certificate issuance and operations audited according to the Baseline Requirements between February 15, 2013, and February 15, 2014. 

Audits performed for audit periods commencing before February 15, 2013, must be performed at least according to the criteria listed in [[CA:CertificatePolicyV2.0 | Version 2.0 of Mozilla's CA Certificate Policy.]] 

Additionally, if SSL certificates are issued, audits performed for audit periods commencing before February 15, 2013, must also be performed according to the Baseline Requirements audit criteria ([http://www.webtrust.org/homepage-documents/item72056.pdf WebTrust SSL Baseline Requirements Audit Criteria V.1.1,] or [http://pda.etsi.org/pda/home.asp?wki_id=LJfRMZJQbbbekfdgITkht ETSI TS 102 042 V2.3.1 DVCP and OVCP]) as to CA operations occurring on or after February 15, 2013. If the Baseline Requirements audit would only apply to 120 days or less, then a Point in Time audit may be performed. At the CA's option, the Baseline Requirements audit may cover the entire audit period. 

Audits performed for audit periods commencing on or after February 15, 2013, must be performed according to the criteria listed in [http://www.mozilla.org/projects/security/certs/policy/ Version 2.1 of Mozilla's CA Certificate Policy] as to all CA operations during the audit period.

An "audit period" is the time frame covered by an audit.

=== Multi-Factor Authentication and CA Hierarchy ===

In item #6 of the [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Inclusion Policy] a requirement was added for CAs to enforce multi-factor authentication for all accounts capable of directly causing certificate issuance. This requirement was [[CA:Communications#September_8.2C_2011 | previously communicated,]] so all CAs are expected to already be in compliance with this requirement. 

In item #6 of the [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Inclusion Policy] a requirement was added for CAs to maintain a certificate hierarchy such that the included certificate does not directly issue end-entity certificates to customers (e.g., the included certificate signs intermediate issuing certificates), as described in CA/Browser Forum Baseline Requirement (BR) #12.
* This requirement and the exceptions listed in BR #12 apply to SSL/TLS, S/MIME, and Code Signing certificates. 
* Root certificates and trust anchors that are already included in NSS will be granted the time necessary to transition their existing customers to a new hierarchy. If needed, the CA shall create a new root certificate within the next year (before February 2014) and actively work to include the new root certificate in Mozilla's program and transition their customers to the new hierarchy.
* Mozilla grants an exception to the trust anchors in Mozilla's program that are signed by national policy root certificates whose corresponding national policy does not allow the subordinate CA to issue other subordinate CA certificates. 

=== Technical Constraints or Auditing/Disclosure of Intermediate Certificates ===

Items #8, 9, and 10 of the [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Inclusion Policy] describe how intermediate certificates must either be technically constrained '''or''' be audited and publicly disclosed.

* All subordinate CA certificates that are issued after May 15, 2013 must comply with version 2.1 of the [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Inclusion Policy]
* All pre-existing subordinate CA certificates must be updated to comply with version 2.1 of the [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Inclusion Policy] for new certificate issuance by May 15, 2014.
* All certificates that are capable of being used to issue new certificates must comply with version 2.1 of the [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Inclusion Policy] for new certificate issuance by May 15, 2014.

=== Baseline Requirements ===

Item #12 of the [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Inclusion Policy] adds the requirement for CA operations and issuance of certificates to be used for SSL-enabled servers to also conform to version 1.1 of the [http://www.cabforum.org/documents.html CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates.]

* As of February 2013, SSL certificate issuance must also be audited according to the Baseline Requirements (BRs), as described above. The first BR audit for each CA and subCA may include a reasonable list of BRs that the CA (or subCA) is not yet in compliance with. The second BR audit (the following year) is expected to confirm that the issues that were listed in the previous BR audit have been resolved.
* All other dates are as specified by the CA/Browser Forum.

== Frequently Asked Questions ==

# RFC 5280 reads "In general, this extension will appear only in end entity certificates". Is it non-standard to have EKU in intermediate certificates, and will client software break when receiving such a certificate chain? 
#* Inclusion of EKU in CA certificates is generally allowed. NSS and CryptoAPI both treat the EKU extension in intermediate certificates as a constraint on the permitted EKU OIDs in end-entity certificates. Browsers and certificate client software have been using EKU in intermediate certificates, and it has been common for enterprise subordinate CAs in Windows environments to use EKU in their intermediate certificates to constrain certificate issuance. Therefore, it is unlikely that using EKU in intermediate certificates would break other client software.
#* The use of the EKU extension in intermediate certificates was discussed at length in the [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/0jnELviAxxo mozilla.dev.security.policy forum.] We considered other options, such as standardizing a set of Policy OIDs or un-deprecating NetscapeCertType. The discussion included the concern that one interpretation of RFC 5280 is that this use of EKU is non-standard, but it was decided that the RFCs are not clear, and perhaps conflicting, in regards to EKUs in CA certificates. In the discussion it was pointed out that other major browsers and client software already support this use of EKU but do not recognize NetscapeCertType; and we also recognized the difficulties involved in standardizing a set of Policy OIDs. The conclusion of the discussion was that EKU is the best tool for technically constraining the types of certificates that an intermediate certificate may sign.
# RFC 5280 requires that Name Constraints MUST be marked critical. However, some internet browsers and other relying-party applications do not yet support Name Constraints, so they will reject any certificate that has critical Name Constraints. Mozilla's new policy requires Name Constraints in technically-constrained intermediate certificates that may sign SSL certificates. Do the Name Constraints have to be marked critical?
#* As stated in the CA/Browser Forum's Baseline Requirements document: Non-critical Name Constraints are an exception to RFC 5280 that 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.
#* The question about Name Constraints being marked critical was discussed in the [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/UgqTBOdGH6s mozilla.dev.security.policy forum.] The critical bit does not mean 'important'. It means 'Break backwards compatibility'; i.e. if your software doesn't handle Name Constraints, but they are marked as critical, then reject the certificate. This means that certificates that are created with critical Name Constraints will not work in some widely-used browsers and application software. Therefore, we determined that in order to make forward progress in our policy, we would need to allow non-critical Name Constraints until Name Constraints are more broadly supported. We also decided to let this exception be handled in the CA/Browser Forum's Baseline Requirements document, and not specifically call it out in Mozilla's policy.