From: Trans <[email protected]> on behalf of Ben Laurie <[email protected]> Subject: Re: [Trans] text to address DKG's conspiring CAs attack
> > > On 30 March 2016 at 17:02, David A. Cooper <[email protected]> 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) You could express name constraints on a trust anchor to prevent re-use of the same CA subject name. Of course, there are very few implementations of this and none (that I know of) in the web PKI and the expression could get long for overpopulated TA stores. Details are in 5914 and 5937, as noted in 6818. Using this you would just need to make sure there are no overlaps in your TA store. > > The vulnerability is also mitigated by requiring AIA in the EE certificate, > which the BRs do. Arguably, 5280 should also. How does an AIA help? AIAs could be suppressed or mis-populated and path building may use artifacts previously download from a different AIA. > > BTW, in case it is not clear, I do agree with Steve that 5280 does not require > global uniqueness. >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
