On Monday, 7 November 2016 09:53:37 UTC, Gervase Markham wrote: > One option would be to say that there should be no signing of SHA-1 > hashes in any circumstances within the hierarchies which chain up to > Mozilla-trusted roots. However, it's possible that such a total ban > would have disproportionate impact, and there are some circumstances > where SHA-1-hash-signing can safely continue (e.g. if all data is > CA-controlled). Or it may be that there isn't. Comments welcome.
In the ideal world we'd just distrust all CAs which are still signing with SHA-1. This is not the ideal world. Where we don't have another way forward, I think one option is for CAs to replace an existing unconstrained intermediate with a newer one that is suitably constrained, and revoke the old one. This is subject to all the usual caveats about revocation and of course the constraints chosen must be practical for that particular CA in the chosen timeframe. Constraints don't eliminate the collision threat, but they reduce the value of certificates produced by an attacker, which in turn can make the attack uneconomic and have the effect of preventing it. Being able to produce a working CA:TRUE certificate under your control is worth a lot more than being able to spoof a single chosen email address in S/MIME. Another economic tactic would be to require CAs to use long random serial numbers even in non-BR certificates. M-D style chosen prefix attacks need to correctly predict this part of the tbsCertificate to work, or to do the work N times where N is the number of certificates they must make on average to get a matching serial number. Thus in theory at least a CA which does this properly is a very unattractive target for the attack. This can also be rationalised as protection for subscribers who aren't even interested in the Web PKI and won't be phasing out SHA-1 until 2018 or beyond when SHA-1 may be very creaky indeed, which makes it a good investment for the sort of CA which has such customers. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
