[cabfpub] Mozilla SHA-1 further restrictions

[Doug Beattie]

> * The issuing CA and the certificate itself both have a critical EKU 
> extension with a single key purpose, which is not id-kp-serverAuth or 
> anyExtendedKeyUsage; [DB] I think we should allow multiple EKUs so we 
> can support SMIME & Client auth (for example) in one CA.

I would be open to suggestions for permitted pairs, but the more EKUs an intermediate has, the greater the usefulness of a SHA-1 collision under it. So I want to keep that to a minimum.

[DB] Given the entropy requirement is a collision attack feasible?  I still think there should be no limit on the number of EKUs.  Excluding id-kp-serverAuth and anyExtendedKeyUsage is fine


> CAs may only sign SHA-1 hashes over non-certificate data (e.g. OCSP 
> responses, CRLs) using certs which chain up to roots in Mozilla's 
> program if all of the following are true: [DB] What do you mean by 
> "CA"?  Do you mean a CA certificate, one that has Basic constraints 
> set to CA?

I mean a Certificate Authority, the organization. Note the sentence goes on to say "using certs which".

[DB] I'm still confused on this and think there is a difference between what a CA cert can sign and what a Certification Authority can sign.  We should try to place requirements on Certificates (and identify the type clearly) and not Certification Authorities.  For example, CAs might set up a signing service where they sign customer provided hashes of "things" with EE certificates, certainly we should be allowed to do that, but we should not be able to do that with a CA certificate.  Timestamping services fall into this category also - CAs can't run a SHA-1 timestamping service?


> compatibility testing with EKUs in intermediates. [DB] Is this going 
> to be a retroactive requirement such that existing CAs need to be 
> re-created?

If existing intermediate keys which are part of certificates which don't fit the profile want to continue to sign EE certs with SHA-1, the keys will need re-inserting into new compliant certificates. That should be clear from the way it's worded - if you want to continue to issue SHA-1, your intermediates have to be X, Y and Z.

[DB] This is problematic.  All legacy SHA-1 CAs need to be re-cut? That is a major impact  The CA certificate is already out there so I don’t think a new cert with the same key helps anything. Then we need to revoke the old CA? That will be a serious impact to existing customers.

Gerv