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
Coming soon... When version 2.1 is published, I will fill in this section based on https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1
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.