On 17/11/16 13:05, Doug Beattie wrote: > 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.
Yes, fair. > * The certificate is not within the scope of the Baseline > Requirements; [DB] - the EE or the CA? EE. > * 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. I would be open to suggestions for permitted pairs, but the more EKUs an intermediate has, the greater the usefulness of a SHA-1 collision under it. So I want to keep that to a minimum. > * The certificate has at least 64 bits of entropy from a CSPRNG in > the serial number. [DB] CA and End Entity? No, EE. My current view is that CAs can be trusted not to issue SHA-1 intermediates which are designed for a collision. > 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? I mean a Certificate Authority, the organization. Note the sentence goes on to say "using certs which". > * 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. Presumably you are counting the nonce as data not defined by the CA? Given that a nonce is a fixed short-ish length, do you think it could be used to engineer a collision? > compatibility testing with EKUs in intermediates. [DB] Is this going > to be a retroactive requirement such that existing CAs need to be > re-created? If existing intermediate keys which are part of certificates which don't fit the profile want to continue to sign EE certs with SHA-1, the keys will need re-inserting into new compliant certificates. That should be clear from the way it's worded - if you want to continue to issue SHA-1, your intermediates have to be X, Y and Z. Gerv _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
