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

[David A. Cooper]

I provided rather detailed evidence that RFC 5280 does require global name uniqueness. Can you explain why my evidence is wrong? How does the text in Section 6.3 of RFC 5280 ensure that a CRL issued by one CA isn't used to determine the status of certificates issued by an unrelated CA issuing certificates under the same name if both can be validated from the same trust anchor? I have been explaining what RFC 5280 says (and what X.509 says). I have not been trying to justify that it was a correct design decision, so there's no need for me to answer the question about how one would ensure names are unambiguous. You are free to agree with Steve that RFC 5280 shouldn't have required names to be globally unambiguous, but that doesn't change the fact that (as I have shown) RFC 5280 and other PKIX documents were written in a way that things don't work unless names are globally unambiguous. If RFC 5280 didn't require names to be unambiguous, why didn't the text in Section 6.3.3 address the problem I mentioned above by requiring that the certification path for a CRL be the same as for the certificate whose status is being checked (or at least require that the list of CA names in the paths be the same)? Again, you can agree with Steve that something like that should have been done, but where's the evidence that it was done? Dave P.S. It would really be helpful if this discussion thread could end. It's not relevant to TRANS, and there would be no reason to discuss it at all in this group if there wasn't an attempt to include text about it in one of the TRANS documents. On 03/30/2016 01:15 PM, Ben Laurie wrote: On 30 March 2016 at 17:02, David A. Cooper <david.coo...@nist.gov> wrote: So, your contention is that PKIX diverged from X.509 by removing the requirement for names to be unambiguous, and did nothing to address the vulnerability created by this divergence other than noting the vulnerability in the Security Considerations sections of its documents? The working group then went on to develop protocols and profiles that relied on names being unambiguous, and then just noted in the Security Considerations that an unnecessary vulnerability had been created? I have even looked for evidence that the PKIX WG discussed the idea of deviating from X.509 and allowing names to be ambiguous (i.e., unrelated entities operating under the same name) and have been unable to find any evidence of that on the mail list. I have, however, heard an explanation for why the text in Section 4.1.2.6 says what it does, and it was not about a deliberate decision to deviate from X.509. In practice, how would you ensure names were unambiguous? (actually, a CT-like mechanism could be used, but CT does rather post-date 5280) The vulnerability is also mitigated by requiring AIA in the EE certificate, which the BRs do. Arguably, 5280 should also. BTW, in case it is not clear, I do agree with Steve that 5280 does not require global uniqueness.

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