Re: [Trans] text to address DKG's conspiring CAs attack

[David A. Cooper]

I have never believed that "the X.500 directory tree is the basis for all names in certs.," and you know that! Nor does that have anything to do with what I said in my previous email. There's no reason for you to rebut my analysis. What is needed is for someone to write a description of the attack scenario that accurately describes the attack scenario DKG presented, and the text you proposed doesn't do that. If my description of the scenario is so wrong, then please explain (in detail) how a relying party would be able to determine that there are two distinct intermediate CAs in this scenario and not a single CA that has been issued cross-certificates by two different roots (as depicted in my diagrams) and how that fits in with your response to Ben Laurie that: A relying party validates a cert by walking down a cert pat from a trust anchor to a target cert. In DKG's example, the two CAs with the same name have different trust anchor parents, thus there are two distinct paths. A CRL (or OCSP response) issued by a CA on one path is totally independent from A CRL (or OSCSP response) issued by a CA on a distinct path. What information (specifically) would appear in a CRL or OCSP response issued by a CA on one path that would make it distinguishable to a relying party from a CRL or OCSP response issued by a CA on the other path in the scenario DKG described? On 03/16/2016 01:47 PM, Stephen Kent wrote: David, As others have pointed out, the description below is fundamentally flawed, and as a result the conclusion is flawed as well. See comments in-line below. Others are wrong :-). ... In fact, an attack of the sort Gilmor envisioned can be mounted by any two CAs that are not name-constrained; the attack need not be initiated by trust anchors per se. (Also note that X.509 and RFC 5280 do not preclude creation of doppelganger CAs; the requirement for Subject name uniqueness applies individually to each CA but not across CA boundaries, and there is no requirement for public key uniqueness across CAs.) This is incorrect! X.509 requires name uniqueness, including across CA boundaries. [Since this issue isn't relevant to the "conspiring CAs attack," information about this inaccuracy is at the end of the email. David still believes that the X.500 directory tree is the basis for all names in certs. of course this is not even remotely true, and 5280 is quite clear about this. But I am happy to avoid this argument by omitting the reference to X.509, since we're discussing Internet standards and thus RFC 5280 is relevant reference. The attack requires that both of the doppelganger CAs issue a certificate for a targeted Subject (e.g., web site). These two (EE) certificates are identical; they contain the same name, public key, serial number, etc. Only one of the malicious CAs logs a bogus certificate and acquires an SCT for it. Because the bogus certificates are identical, the SCT will match both. As noted by others, if the two (EE) certificates are identical, then there is only one EE certificate. So, in the scenario described above, there aren't two intermediate CAs and two (identical) EE certificates. There are two trust anchors, each issuing a certificate to a single subordinate CA, which in turn has issued a single EE certificate identifying the target Subject: wrong, again. In the scenaior there are two distinct, intermediate CAs, with distinct parents. The CA certs for the malicious CAs are different, e.g., at a minimum they have different Issuer names. The question of whether there are one or two bogus certs strikes me as an existential distinction. I'm not going spend my time rebuting the rest of your analysis, as it is based on a faulty interpretation of what I wrote, and is illustrated with diagrams that don't match the scenario that DKG and I are describe. Steve _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans