Gerv, > 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: > > * the cert has a Basic Constraints extension with a value of false in > the cA component;
This makes sense in the context of delegated OCSP signing and aligns with the Microsoft policy. For CRLs, are you suggesting that CAs need to create delegated CRL signing certificates? I believe it is common practice to sign CRLs directly from roots and intermediates. Same goes for OCSP responses for intermediates. > > * Doing so is necessary for a documented compatibility reason; What constitutes a 'documented compatibility reason'? Is the intent to create a very limited scope backed by hard data, or is "Windows XP (pre-SP3)" a 'documented compatibility reason'? I would like to continue to provide SHA-1 signed OCSP responses and CRLs for all certificates in GoDaddy's SHA-1 hierarchies (root - intermediate - and EE certs are all SHA-1), but if the intent is to prevent that with this bullet, then I'd like to make it clear here - perhaps by requiring approval rather than just documenting. > > * The CA takes care the all of the signed data is either static, > defined by the CA, or of a known and expected form. Should we specifically ban nonces in OCSP responses? _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
