[cabfpub] Mozilla SHA-1 further restrictions

[Doug Beattie]

-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 


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

So how about I change that section to say that if you want to sign non-cert data, you have to do so with a cert that has a Basic Constraints extension with a value of false in the cA component? Then remove the static data requirement. This way, you can't transfer the hash to a colliding cert, because it wouldn't chain properly.

Does this meet the OCSP/CRL/timestamping use case?

[DB] Yes, I think it does.  You might want to define what "cert data" is so we what "non-cert data" is.  I'm assuming Cert data consists of certificates, CRLs and OCSP responses, nothing else.

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

Yes, sorry, I mis-spoke. What I think I mean is that existing intermediates certs that fit the profile can continue to be used, but you have to stop using those which don't, and mint new intermediates with new keys to replace them. In other words, rotate your intermediates. You can't reuse the same keys because, you are right, that doesn't help, as the SHA-1 signatures could still be transferred and used with the old intermediate which has the same key. If we do it this way, you don't have to revoke the old ones, you just have to stop signing SHA-1 things with them. So existing systems continue to work.

[DB] What's driving this change now, especially given that SHA-1 SSL certificates won’t be trusted by the time this requirement is enforced?  This is going to be a lot of work for CAs to re-cut all of the CAs (shared and dedicated ones for customers).  Even if someone could get an SSL certificate from one of these CAs, it would be of minimal use.  Specifying this requirement for new CAs is fine.

Doug