[security-area] Fwd: How ambiguous are names in actuality?

[Von Welch]

Mike,

 I missed Tim's second point. I agree that looks like the promising
path.

Von

Mike Helm writes (15:57 July 14, 2005):
 > "Von Welch" writes:
 > > An interesting note from Tim Polk on ambiguous names in
 > > PKIs. Unfortunately it doesn't apply to the types of PKIs we use in
 > > Grids since it assume a single trust anchor that cross certifies all
 > > peers.
 > 
 > On the contrary, at least 2 of 3 of these are very good recommendations
 > and definitely apply to Grids.
 > 
 > #1 is one that seems commonsensical (probably not very important, tho).
 > Software should do this  - what would openssl do?  (Do I need to ask :^)
 > 
 > #2 is something I have been campaigning for, for years.  Not alone either.
 > 
 > #3 name constraints - interesting, but name constraints are dead as a doornail
 > because of how PKIX managed this attribute; and besides, for Grid work, the 
 > access control is provided in the wrong direction (the relying party 
 > is supposed to apply this rule, in the Grid ideology), and so it is at
 > worst irrelevant and at best a minor, and hard to maintain, benefit.
 > This issue was solved, perhaps imperfectly, with the signing_policy file.
 > 
 > #2 is the key - is it enough?  I've seen some MS certs with an AIA extension
 > that point back to a trust anchor, so you can tell directly in what hierarchy 
 > this cert belongs - is that useful?  Is that needed in a full network
 > architecture?
 > 
 > >   (1) Modify section 6.3.3 to state that CRL validation MUST use the same
 > > trust anchor T specified in the corresponding certification path.
 > >
 > > (2) Add security considerations that indicate applications that accept
 > > multiple trust anchors should consider the trust anchor in access control
 > > decisions to ensure that names are unambiguous.
 > >
 > > (3) Add security considerations that explain the importance of consistent
 > > use of path length and name constraints in preventing name ambiguity
 >