[cabfpub] Mozilla SHA-1 further restrictions (v5)

Gervase Markham gerv at mozilla.org
Tue Jan 24 08:19:18 MST 2017


Here's v5. Thanks for all the thoughtful input so far. Last call, as I
want to move this back to m.d.s.policy and incorporate it into v2.4 of
our root store policy.

This is the same as v4 except I allow manually issued OCSP certs
directly off roots, and I've properly listed the changes permitted for
reissuing a new issuing intermediate.

<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.

Point 2 does not apply if the certificate is an OCSP signing certificate
manually issued directly from a root.

CAs may only sign SHA-1 hashes over intermediate certificates 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 changes being all of:
* a new key (of the same size);
* a new serial number (of the same length);
* the addition of an EKU and/or a pathlen constraint 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


More information about the Public mailing list