Hello Gerv, The BRs are clear on the use of SHA-1, but I have a question about the Mozilla policy and how it relates to the use of SHA-1 OCSP signing certificates.
In December 2016 the Mozilla policy 2.3 was published and it didn't address the use of SHA-1 on OCSP signing certificates (see anyone that needs it, this page for links to the Mozilla CA policies: https://wiki.mozilla.org/CA:CertPolicy ) In February 2017, Mozilla Policy 2.4 was published which added stipulations for use of SHA-1 and that has been subsequently updated a few times this year to evolve to this: 5.1.1 SHA-1 CAs MAY sign SHA-1 hashes over end-entity certificates which chain up to roots in Mozilla's program only if all the following are true: 1. The end-entity certificate: o is not within the scope of the Baseline Requirements; o contains an EKU extension which does not contain either of the id-kp-serverAuth or anyExtendedKeyUsage key purposes; o has at least 64 bits of entropy from a CSPRNG in the serial number. 2. The issuing certificate: o contains an EKU extension which does not contain either of the id-kp-serverAuth or anyExtendedKeyUsage key purposes; o has a pathlen:0 constraint. Point 2 does not apply if the certificate is an OCSP signing certificate manually issued directly from a root. In late 2016 we pre-generated a number of OCSP signing certificates for use in signing OCSP messages under our SSL CAs, but since we didn't know this same rule would be applied to non-BR certificates, we didn't pre-generate any OCSP signing certificates for those CAs. The specific issue is that these client certificate CAs don't have the EKU extension even though we have no intent of issuing SSL certificates (they are WT audited and verified to not issue any SSL certificates per the BRs). Is it permissible to continue issuing SHA-1 OCSP signing certificates for these existing legacy non-SSL CAs so we may continue providing revocation services using algorithms they support until all certificates under the CAs expire? This would be no later than the end of 2020. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
