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

[Mike Helm]

"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