[cabfpub] Mozilla SHA-1 further restrictions

Gervase Markham gerv at mozilla.org
Thu Nov 17 15:24:32 UTC 2016


On 17/11/16 14:54, Doug Beattie wrote:
> [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.

My definition was that cert data is, er, certs, and non-cert data is
everything else, including CRLs and OCSP. Does that make the following
problematic?

"If you want to sign something that's not a certificate, you have to do
the signing with a cert that has a Basic Constraints extension with a
value of false in the cA component."

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

Firstly, it's not just about SSL - Mozilla's policy also covers S/MIME.

Let's say someone signs an email cert from an intermediate without
pathlen:0. If there's a collision, that signature can be passed to an
intermediate cert which can sign email certs for any email address. But
if it has a pathlen, they can only create an EE cert.

Or if someone signs an email cert from an intermediate without an EKU,
if there's a collision that sig can be transferred to any other type of
cert or signed object. But if there's an EKU, it can only be transferred
to the type of object the original signed thing was, thereby reducing
the value of the attack.

Gerv




More information about the Public mailing list