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

Bruce Morton Bruce.Morton at entrustdatacard.com
Mon Jan 30 12:16:10 MST 2017


Hi Gerv,

Can you provide some clarification on how this will be implemented/imposed? What would be good to know is if the CA does not comply to the new Mozilla SHA-1 restrictions is this a policy compliance issue or will this mean the certificate issued will not be trusted by Firefox?

Thanks, Bruce.

-----Original Message-----
From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham via Public
Sent: Tuesday, January 24, 2017 10:19 AM
To: CABFPub <public at cabforum.org>
Cc: Gervase Markham <gerv at mozilla.org>
Subject: Re: [cabfpub] Mozilla SHA-1 further restrictions (v5)

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
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public


More information about the Public mailing list