On Wednesday, 4 October 2017 20:19:22 UTC+1, Gervase Markham wrote: > Would it be an acceptable solution to add these intermediates to OneCRL?
I can't think of any reason this isn't a good idea, the intermediate claims never to issue anything Firefox (the consumer of OneCRL) would want to trust. However if I understand the situation correctly, this situation is already very low risk anyway with no reasonable expectation that it could be exploited against a competent SSL/TLS client which for some reason still accepts SHA1 and of course no risk for e.g. modern Firefox which doesn't accepts SHA1 anyway. If I haven't understood (please anyone jump in) then my assessment may be utterly wrong. In this part of Doug's hierarchy actual OCSP responses are from a dedicated OCSP signer using SHA1. It might prove possible for attackers to force a collision here by manipulating the details they present, but since it's dedicated to this purpose they can't use the signature in the response to make something else like an X.509 certificate, it won't be trusted in that context. So this is useless practically speaking. The certificates Doug wants permission to issue - for that dedicated signer itself - are also signed with SHA1 and that signature is trusted on an X.509 certificate, so that could be a target. BUT they're signing something that's directly under Doug's control, not an attacker, so there's no avenue here for collision. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
