On Tuesday, 25 October 2016 21:16:36 UTC+1, Ryan Sleevi wrote: > The linked bug is a concrete example, where an unconstrained sub-CA was > revoked, due to non-compliance with the BRs, but has now been cross-certified > as a constrained sub-CA. All of these non-BR compliant certificates are now > valid, by utilizing the technically constrained path. From a Mozilla policy, > what are the implications of this new cross-certified constrained sub-CA?
Is it possible for someone to write up the details of the non-compliant issuances and so on ? I would find it much easier to comment on the particulars of 1311200 if they were more specific. > A very concrete example of the implications of this relate to SHA-1 > certificates. If, prior to Dec 31, 2015, CAs had issued some N-million TCSCs, > signed with SHA-1, to all parties that wished to keep issuing SHA-1, could > these TCSCs have continued issuing SHA-1 certificates without violating the > Mozilla requirements? One interpretation is that yes, they could have, at > least from Mozilla policy. However, from the BRs, the answer is that no, they > couldn't have. Unless I'm missing something, these constrained certificates pose a much smaller risk under our expected threat model for SHA-1. We suppose a bad guy can (or will soon be able to) pull off a chosen prefix attack on SHA-1 enabling them to trick a CA into signing document A and then use its signature on document B successfully. Back when this happened for MD5, many CAs were issuing from roots, or at best from completely unconstrained intermediates, just because. The attack was used to produce a working unconstrained CA:TRUE certificate. One successful attack translated into unlimited issuing power across all of the Web PKI. It seem eminently reasonable to believe this one certificate might be extremely valuable to criminals with an effective plan to exploit it before any effective remedy is deployed, and everybody in the Web PKI (which is now basically everyone) is put at risk. In contrast for the TCSCs a successful attack would produce /at best/ another constrained intermediate, and in most cases I've seen not even a working CA:TRUE certificate but just some arbitrary wildcard end entity certificate for a subset of the constrained names. The attack must also be launched against infrastructure controlled by the very organisation the certificates will be used to impersonate, not some unrelated third party as with the MD5 attacks. Finally, as I understand it the hypothetical SHA-1 TSCSs would be revoked along with any other still extant SHA-1 certificates by the issuing CA, before the planned Firefox 51 public release. So I don't think this would imperil the planned action in Firefox 51. Am I wrong about that ? _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
