It has been noted that currently, Mozilla's SHA-1 ban is implemented via the ban in the BRs, which we require all CAs to adhere to. However, implementing the ban via the BRs is problematic for a number of reasons:
* It allows the issuance of SHA-1 certs in publicly-trusted hierarchies in those cases where the cert is not within scope of the BRs (e.g. email certs). * The scope of the BRs is a matter of debate, and so there are grey areas, as well as areas clearly outside scope, where SHA-1 issuance could happen. * Even when the latest version of Firefox stops trusting SHA-1 certs very soon, a) that block is overrideable, and b) that doesn't address risks to older versions. Therefore, we would like to update Mozilla's CA policy to implement a "proper" SHA-1 ban. At the moment, it seems difficult to define a SHA-1 ban for email, so the current text leaves that for a future update. Here is some draft text, which would be added to the Maintenance section of the policy, bullet 6. It has been discussed here, and discussed on the CABF public list as well, so it's been pretty carefully analyzed. <quote> CAs may only sign SHA-1 hashes over end-entity certificates which chain up to roots in Mozilla's program if all the following are true: 1) The end-entity certificate: * is not within the scope of the Baseline Requirements; * contains an EKU extension which does not contain either of the id-kp- serverAuth or anyExtendedKeyUsage key purposes; * has at least 64 bits of entropy from a CSPRNG in the serial number. 2) The issuing intermediate: * contains an EKU extension which does not contain either of the id-kp- serverAuth or anyExtendedKeyUsage key purposes; * has a pathlen:0 constraint. Point 2 does not apply if the certificate is an OCSP signing certificate manually issued directly from a root. CAs may only sign SHA-1 hashes over intermediate certificates which chain up to roots in Mozilla's program if the certificate to be signed is a duplicate of an existing SHA-1 intermediate certificate with the only changes being all of: * a new key (of the same size); * a new serial number (of the same length); * the addition of an EKU and/or a pathlen constraint to meet the requirements outlined above. CAs may only sign SHA-1 hashes over OCSP responses if the signing certificate contains an EKU extension which contains only the id-kp-ocspSigning EKU. CAs may only sign SHA-1 hashes over CRLs for roots and intermediates which have issued SHA-1 certificates. CAs may not sign SHA-1 hashes over other data, including CT pre-certificates. </quote> This is: https://github.com/mozilla/pkipolicy/issues/25 ------- This is a proposed update to Mozilla's root store policy for version 2.4. Please keep discussion in this group rather than on Github. Silence is consent. Policy 2.3 (current version): https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md Update process: https://wiki.mozilla.org/CA:CertPolicyUpdates _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
