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. 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 Mozilla's CA Certificate Inclusion 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 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 Mozilla's CA Certificate Policy was published on February 14, 2013.

Certificates issued before February 15, 2013, must at least meet the requirements of Version 2.0 of Mozilla's CA Certificate Policy.

Any Certificate Authority being considered for root inclusion after February 15, 2013 must comply with Version 2.1 or later of Mozilla's CA Certificate Policy. This includes having a Baseline Requirements audit performed if the websites trust bit is to be enabled. Note that the CA's first Baseline Requirements audit may be a Point in Time audit.

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 Version 2.1 of Mozilla's CA Certificate Policy.

Audit Criteria

Version 2.1 of Mozilla's CA Certificate Policy adds the requirement that SSL certificate issuance also be audited according to the 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 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 (WebTrust SSL Baseline Requirements Audit Criteria V.1.1, or 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 Version 2.1 or later of Mozilla's CA Certificate Inclulsion 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 Mozilla's CA Certificate 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 previously communicated, so all CAs are expected to already be in compliance with this requirement.

In item #6 of Mozilla's CA Certificate 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. (Note: in version 1.3 and later of the BRs, this is in section 6.1.7)

• This requirement and the exceptions listed in BRs about root CA private keys being used to sign certificates 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.
• Mozilla grants an exception to the trust anchors that are signed by a national CA who is working towards inclusion of the national root certificate, but Mozilla has requested that each subordinate CA be evaluated separately first.

Baseline Requirements

Item #12 of the 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 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.

Technical Constraints or Auditing/Disclosure of Intermediate Certificates

Items #8, 9, and 10 of Mozilla's CA Certificate 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 or later of Mozilla's CA Certificate Inclusion Policy
• All pre-existing subordinate CA certificates must be updated to comply with version 2.1 or later of Mozilla's CA Certificate Inclusion Policy for new certificate issuance by May 15, 2014.
  • A pre-existing externally-operated subordinate CA certificate that expires before May 15, 2014 may be re-issued in order to extend the validity period of the currently-valid intermediate CA certificate until May 15, 2014. That is, the replacement certificate's notAfter date would be May 15, 2014 or earlier.
• All certificates that are capable of being used to issue new certificates must comply with version 2.1 or later of Mozilla's CA Certificate Inclusion Policy for new certificate issuance by May 15, 2014.

Frequently Asked Questions

1. 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 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.
2. 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 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.
3. How do I technically constrain a subordinate CA certificate that will only be used to issue end-user certificates intended for client authentication?
   • For the subCA certificate to be considered technically constrained according to item #9 of Mozilla's CA Certificate Inclusion Policy, the subCA certificate must have the Extended Key Usage (EKU) extension with the id-kp-clientAuth KeyPurposeId (and whatever else they need), and the EKU extension must not include any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection, id-kp-codeSigning.
     • If the EKU extension includes id-kp-serverAuth, then (in order to be considered technically constrained) the subCA certificate must also include the Name Constraints extension as described in item #9 of Mozilla's CA Certificate Inclusion Policy.
     • If the EKU extension includes id-kp-emailProtection, then (in order to be considered technically constrained) technical and/or business controls need to be in place to ensure that the subCA only issues certs for email addresses that the CA has confirmed the subCA is authorized to use, as described in item #9 of Mozilla's CA Certificate Inclusion Policy.
     • If the EKU extension includes id-kp-codeSigning, then (in order to be considered technically constrained) the SubCA certificate must also contain a directoryName permittedSubtrees constraint as described item #9 of Mozilla's CA Certificate Inclusion Policy.
4. If an included trust anchor does not have the websites (SSL/TLS) trust bit enabled, can it be exempt from items #9 and #10 of Mozilla's CA Certificate Inclusion Policy?
   • A subordinate CA certificate that transitively chains to a trust anchor that only has the email trust bit enabled may be considered technically constrained as per item #9 of Mozilla's CA Certificate Inclusion Policy even when it does not include an EKU extension.
   • A subordinate CA certificate that transitively chains to an included trust anchor that has the Code Signing and/or websites (SSL/TLS) trust bit(s) enabled must either include an EKU extension and constraints as per item #9 of Mozilla's CA Certificate Inclusion Policy, or must be audited and publicly disclosed as per item #10 of Mozilla's CA Certificate Inclusion Policy.
5. The transition of some subordinate CAs to Technical Constraints (as per #9 of Mozilla's CA Certificate Inclusion Policy) has been accomplished by creating a new CA hierarchy, so the old subordinate CA certificate remains in 'CRL/OCSP only' mode until all certificates in the old hierarchy have expired. Do we need to disclose the old subordinate CA certificates that are being phased out and are in 'CRL/OCSP only' mode?
   • For each subordinate CA certificate that is being phased out and is in 'CRL/OCSP only' mode, please provide the following information: Name of SubCA (optional), SubCA Cert Hash (SHA1 or SHA256), SubCA Cert Subject Key Identifier, SubCA Cert Serial Number, Date of Last Cert Issuance, Date of Last Cert Expiration.
6. What about Certificate Transparency Precertificate Signing Certificates?
   • A Precertificate Signing Certificate with an Extended Key Usage (EKU) extension with only the Certificate Transparency OID 1.3.6.1.4.1.11129.2.4.4 is considered technically constrained according to section 9 of Mozilla's CA Certificate Policy. The certificate's EKU extension must not include any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection, id-kp-codeSigning.