[cabfpub] Mozilla SHA-1 further restrictions

[Gervase Markham]

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

Do others have comments here? The entropy requirement is a hack, but it
it effective enough that we don't need braces in addition to this belt?

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

Gerv