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) 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. > > The proposed text for Section 3.3 seems to be written with the goal of > advancing your personal belief about what RFC 5280 does or does not require > rather than trying to explain a potential attack in the clearest way > possible. Removing the parenthetical about RFC 5280 and simply referring to > the intermediate CA and EE as the single entities that they are would go a > long way towards improving the text. > > > On 03/30/2016 10:25 AM, Stephen Kent wrote: > > David, > > I appreciate your persistence, but we will just have to agree to disagree > on the > topic of whether 5280 requires global name uniqueness. > > First, I cited text from Secyion 4.1.2.6, which is the one place in 5280 > where global > name uniqueness should be mandated if it were a requirement. That section > establishes a > requirement for local (per-CA) name uniqueness, not for global name > uniqueness. IMHO > that is the definitive statement on this topic. > > RFC 5280, like its predecessors, has deviated from X.509 where we felt > necessary. Your > argument that PKIX docs will maintain compatibility with X.509 is just an > indication > of overall intent, not a promise to never deviate. You acknowledge this > later when you > discuss CRL issuer paths and say ".. a requirement imposed by RFC 5280, > but not X.509." > > Yes, the Security Considerations section of 5280 notes that problems that > can arise if > names are not globally unique. However, that is not the same as saying > that 5280 requires > them to be so. Rather it is a warning of the bad things that may happen if > name collisions > occur. A warning in the Security Considerations section the way we usually > note a residual > vulnerability in a standard. It is NOT a backdoor way to add a requirement > to a standard. > > Your other comments cite text that, in your opinion, suggests the need for > global name > uniqueness, rather than citing text that establishes this requirement. > Hence I'm not going > to spend time addressing those comments. > > Aside from the gratuitous parenthetical in your text falsely stating that > RFC 5280 "doe not preclude the creation of two CAs with the same name, so > long as the parent CAs are distinct," you still write about two CAs issuing > two EE certificates that are identical. If it walks like a duck and it > quacks like a duck, then chances are its a duck. In the scenario you are > trying to describe, there is one CA that issues one EE certificate. > > One might argue that two entities acting as CAs that have the same name > and same public > key are the same CA. But if the entities happen to be different > organizations, perhaps > in different geopolitical regions, others might argue that they are > different CAs. > > Can you name even one RP that maintains a cache of revocation status info > organized by cert path? > > BBN has implemented RP code for at least 4 products over the past 20 > years. Some were part > of PKI systems developed for clients in the financial services area. The > most recent is > the RPSTIR code for the RPKI. All of them operate as I described. > > I'll discuss whether my attack scenarios are accurate and match the spirit > of DKGs original > message with him, not you. > > Steve > > > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
