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. Version 2.1 of Mozilla's CA Certificate Policy encourages CAs to technically constrain all subordinate CA certificates by including an Extended Key Usage (EKU) extension specifying all extended key usages that the subordinate CA is authorized to issue certificates for. Technically constraining subordinate CAs that can issue SSL certificates also requires the subordinate CA certificate to include the Name Constraints X.509v3 extension, and the CA must have confirmed that the subordinate CA is authorized to issue certificates for the domains that are included in the Name Constraints extension. Version 2.1 of Mozilla's CA Certificate Policy requires auditing and public disclosure of subordinate CA certificates that are not technically constrained with EKU and Name Constraints.
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 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 requesting root inclusion after February 15, 2013 must comply with Version 2.1 of Mozilla's CA Certificate Policy.
CAs that were already included in Mozilla's program as of February 15, 2013 shall comply with version 2.1 of the Inclusion Policy as follows. Audits performed after the dates listed below should confirm the CA's compliance with the new 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 of Mozilla's CA Certificate Policy as to all CA operations during the audit period.
Multi-Factor Authentication and CA Hierarchy
Item #6, third bullet: The multi-factor authentication requirement was previously communicated to all CAs, so all CAs are expected to already be in compliance with this requirement.
Item #6, fourth bullet: "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 #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 Inclusion Policy describe how intermediate certificates must either be technically constrained or audited and disclosed.
- All subordinate CA certificates that are issued after May 15, 2013 must comply with version 2.1 of the Inclusion Policy
- All pre-existing subordinate CA certificates must be updated to comply with version 2.1 of the 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 Inclusion Policy for new certificate issuance by May 15, 2014.
Baseline Requirements
Item #12 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 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 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.