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

[Gervase Markham]

Here's v.3 for continued discussion. I feel we do need EKU restrictions
in the intermediate given what Erwann says about leveraging a SHA-1
collision into a clone of the intermediate.

I still haven't figured out exactly what to do about EKUs and email, and
would appreciate further input. Firstly, I guess CAs who want to
continue to issue email certs using SHA-1 need to make the case as to
why that's necesssary. If it turns out to be necessary now, when will it
not be necessary?

Then, if we continue to allow it for a time, I would like to restrict
certs which have the email EKU to a minimum set of additional EKUs,
definitely not including code signing. I guess client auth has to be one
of them. What else?

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