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
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Reply via email to