Here's v4. I've decided to leave the email situation unchanged for now, in the name of getting the SSL situation put to bed. We can address it in a different discussion.
This is the same as v3 except it allows the issuance of SHA-1 intermediates to add EKUs so that they can be used in chains meeting the other requirements (a fix for a problem Bruce pointed out). <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. CAs may only sign SHA-1 hashes over issuing intermediates 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 change being the addition of an EKU 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> Gerv _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
