I took this discussion to the CAB Forum public list, where a couple of significant things happened.
Firstly, Erwann pointed out that (in clients other than Firefox, which doesn't implement the necessary exceptions to the normal rules), you can use a "self-issued" cert to leverage a SHA-1 collision into a clone of the issuing intermediate for which you hold the private key :-| Secondly, there was significant pushback on Nick Lamb's proposal of requiring SHA-1-issuing intermediates to have a single EKU, because EKUs often need to come in groups - e.g. id-kp-emailProtection and id-kp-clientAuth. I can certainly see the use case for that. The first of these makes EKU constraints on intermediates even more of a good idea, and the second of these makes them rather difficult :-| At the moment, the new draft just says "no id-kp-serverAuth", but leaves email out in the cold somewhat. It seems like it might be tricky to write a sane set of EKU rules which both provided meaningful protection and didn't get in the way of sensible use cases. Of course, it could be that perhaps the email ecosystem also needs a SHA-1 ban :-). I've asked CAs to tell me why I shouldn't just do that, so we'll see what they say. Gerv _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
