See [DB] comments below. -----Original Message----- From: Public [mailto:[email protected]] On Behalf Of Gervase Markham via Public Sent: Thursday, November 17, 2016 6:48 AM To: CABFPub <[email protected]> Cc: Gervase Markham <[email protected]> Subject: [cabfpub] Mozilla SHA-1 further restrictions
<snip> CAs may only sign SHA-1 hashes over end-entity certs which chain up to roots in Mozilla's program if all the following are true: [DB] This section is a bit unclear in scope. Maybe we need 2 sections, one for rules for generating CA certificates and one for End Entity certificates because you go back and forth in scope. * The certificate is not within the scope of the Baseline Requirements; [DB] - the EE or the CA? * The issuing CA and the certificate itself both have a critical EKU extension with a single key purpose, which is not id-kp-serverAuth or anyExtendedKeyUsage; [DB] I think we should allow multiple EKUs so we can support SMIME & Client auth (for example) in one CA. * The issuing CA has a pathlen:0 constraint; * The certificate has at least 64 bits of entropy from a CSPRNG in the serial number. [DB] CA and End Entity? CAs may only sign SHA-1 hashes over non-certificate data (e.g. OCSP responses, CRLs) using certs which chain up to roots in Mozilla's program if all of the following are true: [DB] What do you mean by "CA"? Do you mean a CA certificate, one that has Basic constraints set to CA? * Doing so is necessary for a documented compatibility reason; * All of the signed data is static, or defined by the CA and not another party. [DB] The rules should be different if it's the CA certificate or a technically constrained non-CA cert. For example, OCSP signing certs with EKU constrained to that should be allowed to sign OCSP messages with nonces, but a CA should not. </quote> We intend to impose this requirement with a compliance deadline of 6 months, as it may require cutting new intermediates, and compatibility testing with EKUs in intermediates. [DB] Is this going to be a retroactive requirement such that existing CAs need to be re-created? This is a last call for objections that have not so far been raised. Gerv _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
