"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