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.
Von
------- start of forwarded message -------
From: Tim Polk <tim.polk(a)nist.gov>
To: ietf-pkix(a)imc.org
Subject: How ambiguous are names in actuality?
Date: Thu, 14 Jul 2005 14:24:00 -0400
Ambiguity has recently become a hot topic on this list. This is a really
complicated issue, and I have personally had a great deal of trouble
sorting out the real level of risk. Some of the proposed changes would
greatly impact current software, and these changes should only be
contemplated if the risk is merits such change.
So, I have spent a lot of time, off and on, thinking about ambiguity. I
can't claim to have sorted it all out, but I have convinced myself that one
minor change is absolutely required, and that the current suite of
mechanisms can virtually eliminate ambiguity in real PKIs.
My thinking is appended to this message; I apologize for its length, but
to paraphrase Mark Twain, I simply don't have time to make this short and
concise. I have attempted to define ambiguity, characterize the ways
ambiguity can enter into a PKI, and describe the set of mechanisms that
mitigate this risk.
Thanks,
Tim Polk
--------------------------------------------------------------------------------------------------------------------------------
How ambiguous are names in actuality, and how important is it?
I believe that X.509 expected assignment of unambiguous names based on a
hierarchical system of naming authorities. Whether you agree with that
premise, it is safe to say that the global X.500 directory and its
corresponding system of naming authorities do not exist. So, it may not be
safe to assume that there are no name collisions whatsoever in all the DNs
that appear in certificates and CRLs! I am sure such collisions exist
somewhere (although I haven�t encountered any examples). The real question
here is �What security risk does this situation present, and are the
current mechanisms adequate to address this risk?�
Let�s recognize that the goal for PKIX is not to have globally unambiguous
names, but to be able to obtain a trustworthy public key to establish a
security service. Ambiguity in names is a problem when it causes the
relying party to trust the wrong public key.
There are two ways ambiguous names could cause problems. First, I could
accept public keys from two certificates as representing the same person
based on the same subject name. If these two certificates are bound to
different individuals I may provide a service to the wrong party (or
disclose confidential data, etc., etc.) Second, I could accept a CRL to
validate a particular certificate, based on the same issuer name in the
certificate and CRL. If the certificate and CRL were not actually issued
by the same CA, then the relying party may obtain incorrect certificate status.
Note that both of these problems are in the context of path validation. If
a name collision exists, but only one of the objects (e.g., certificate or
CRL) validates for a given relying party, then there is no actual ambiguity
from that relying party�s point of view.
That is, assume two certificates exist with the same subject name but are
bound to different people. If Alice can only validate one of those
certificates, there is no ambiguity in Alice�s world. Similarly, if Bob
can only validate one of those certificates, there is no ambiguity in Bob�s
world. (It does not matter if Bob and Alice are validating the same
certificate, or different ones!) Similarly, if two CAs have the same
issuer name, but Alice can only validate one, she can�t accept the wrong
CRL. Ditto for Bob.
So, ambiguity is a concern only in the context of path validation for a
given relying party. This means that the mechanisms that are employed in
path validation are relevant to when names are, and are not, ambiguous. I�d
also like to point out that path validation is always performed in the
context of a particular trust anchor. (A relying party may accept paths
that begin with multiple trust anchors, but each specific path has a single
trust anchor.) Seems irrelevant at the moment, but I will get back to it!
Definition 1: a Name N is unambiguous for a trust anchor T if and only if
all certificates that validate for T and have the subject N refer to the
same entity.
Now, let�s think about where name collisions can occur in the first place.
There seems to be consensus that a single CA will not issue two
certificates to two different entities with the same subject name. So, if
a single CA issues two certificates to �O=Microsoft, cn=John Wilson� they
better relate to the same guy. Similarly if a particular CA issues two
certificates to �c=US, O=U.S. Government, OU=NIST, CN=CA1� then the subject
of both certificates must be the same CA.
So, we are only worried about the case where two different CAs are trusted
with respect to a trust anchor T and issue certificates to different
subjects but use the same name. So, when can name collisions occur between
CAs? Or, better yet, under what conditions can we be sure name collisions
won�t occur? Let�s start with user certificates.
In general, each CA that issues user certificates does so for a particular
name space. That is, all names assigned to users will be in a particular
Directory Information Tree (DIT). The CA will either work with a naming
authority that it considers authoritative or may assume that function
itself. For example, the NIST CA only issues user certificates in the
�C=US, O=U.S. Government, OU=NIST� DIT. The NIST CA has been designated
as our naming authority as well, so it keeps track of the names it
assigns. Similarly, the CA that supports NASA only issues certificates for
the name space �C=US, O=U.S. Government, OU=NASA� DIT.
These name spaces are disjoint, so name collisions cannot occur involving
user certificates generated by the NASA and NIST CAs. In fact, consider a
PKI with trust anchor T and CAs C(1), C(2), �, C(n) issuing for name spaces
P(1), P(2), �, P(n). If spaces P(1), P(2), �, P(n) are pairwise disjoint,
name collisions cannot occur involving user certificates generated by C(1),
C(2), �, C(n).
Case 1: Consider a PKI with trust anchor T, and CAs C1, C2, and C3. C1,
C2, and C3 issue end user certificates in the DITs N1, N2, and N3
respectively. If N1, N2, and N3 are pairwise disjoint, then the user names
are unambiguous with respect to T.
In more complex PKIs, we may encounter situations where CAs issue user
certificates for name spaces that overlap. For example, in the U.S DoD�s
hierarchical PKI, CAs all issue certificates in the DIT �C=US, O=U.S.
Government, OU=DOD�. Users routinely receive three certificates from two
different CAs, so all the DoD CAs rely on a common naming authority to
ensure that certificates with the same DNs are issued to the same person.
Case 2: Consider a PKI with trust anchor T, and CAs C1, C2, and C3. C1,
C2, and C3 issue end user certificates in the DITs N1, N2, and N3
respectively. N1 and N2 overlap, but N3 is disjoint from N1 and N2. If
CA1 and CA2 recognize the same naming authority, then the user names in the
PKI are unambiguous with respect to T.
That is, if all the CAs either: (1) issue certificates in disjoint name
spaces, or (2) issue certificates in shared name spaces based on a common
naming authority, names will be unambiguous!
Of course, CAs may issue CA certificates as well. In this case, the CA
does not assign the names, but rather uses the established name. This is
trickier, since the name spaces for CA certificates overlaps but no naming
authority exists. It is still the responsibility of each CA to ensure that
there are no name collisions in CA certificates it issues! This is not
generally a problem, since we require names to be meaningful. A CA should
never issue a certificate to a CA with the DN �C=US, O=Coca Cola� unless
the subject CA is associated with that company. Similarly, if a CA issues
certificates in the DIT �C=US, O=Coca Cola� then it must be associated with
the company!
Of course, a rogue CA may masquerade under the wrong name, or issue
certificates in a DIT it clearly has no right to use, but no decent CA will
cross certify with it. Since we are interested in ambiguity with respect
to a trust anchor, the behavior of a rogue CA is irrelevant. Without cross
certification, no paths involving the rogue CA can be constructed. (Note
that users installing the rogue as a trust anchor is out of scope here!)
However, authority for a name space is not always crystal clear. Without a
central naming authority, there is no clear title for a particular DIT. We
rely on heuristics that work nicely for large entities like Coca-Cola but
may fail for smaller organizations. For example, there may be a number of
companies with variants on a particular name. If the name space assumed by
an organization asserts �Orion� rather than �Orion Security� or �Orion
Space Sciences�, the name may be ambiguous without being blatantly
false. Each entity could reasonably assign user names in the �C=US,
O=Orion� DIT. If each organization established their CA with the name
�C=US, O=Orion, CN=CA1� things could get really ugly.
A trust anchor T may cross certify with two different CAs � say the ones
from NIST and NASA. Each of those CAs may have a relationship with an
�Orion�. If each of them cross certifies with the Orion they know and
love, we have an immediate name collision for a CA named �C=US, O=Orion,
CN=CA1�, and potentially name collisions for �C=US, O=Orion, CN=John
Wilson�, etc., etc. Each CA has played by the rules, but names have just
become ambiguous with respect to T. This might be avoided if T is involved
in the policy decisions leading up to cross certification � but that is
often NOT the case.
Fortunately, we need not depend on policy alone. Beyond the
procedural/policy issues, there are some important mechanisms that help us
with name space control. Most significant are path length constraints and
name constraints. When trust anchor T issued those CA certificates, it
probably wasn�t expecting to accept transitive trust from those CAs, and it
certainly didn�t expect to accept the NIST or NASA CA as authoritative for
the �C=US, O=Orion� DIT.
I listed path length constraints first because this mechanism provides the
simplest and most widely available of our technical controls. Both NASA and
NIST use a single CA, rather than a mesh or hierarchy. If the trust anchor
does not wish to leverage other cross certifications performed by NASA or
NIST, it simply asserts a path length constraint of zero! If T asserted
this constraint for at least one of the NIST or NASA CAs, then the name
�C=US, O=Orion, CN=John Wilson� is unambiguous. While this control was not
designed exclusively for name space control, it does have the effect of
prevenmting subsequent CAs from introducing unexpected name spaces.
Unfortunately, this does not solve our problem for �C=US, O=Orion,
CN=CA1�. This name remains ambiguous. Even with a path length
constraints of zero, a relying party can validate a CRL from either Orion CA.
Name constraints is a more appealing technical mechanism, if less
consistently available. T can explicitly designate the name spaces it
wishes to recognize in the cross certificate issued to NIST (or NASA). By
asserting a permitted subtree of �C=US, O=U.S. Government, OU=NIST� with a
SkipCerts of zero, certificates in the Orion name space are immediately
eliminated. This includes the offending CA certificate, so the �wrong� CRL
no longer validates.
Case 3: Consider a PKI with trust anchor T, and CAs C1, C2, and C3. C1,
C2, and C3 issue end user certificates in the DITs N1, N2, and N3 respectively.
N1 and N2 are disjoint, but N3 overlaps with N1 or N2. C3 does not
recognize the same naming authority as C1 or C2. If name constraints
permitted subtrees P3 is imposed in all cross certificates issued to C3,
where N1, N2, and P3 are pairwise disjoint, then names are unambiguous with
respect to T. (Names that could have collided are excluded from C3�s DIT.)
Conclusion/Proposal
Ambiguity in names is a relatively minor risk with respect to a given trust
anchor. Ambiguity does not occur because of the actions of a single CA;
rather it requires a combination of actions by different CAs within the
infrastructure. If all CA certificates accurately reflect the trust
relationships between the CAs by incorporating appropriate path length and
name constraints, these risks are greatly reduced if not eliminated.
The risk of ambiguous names can be mitigated with a relatively simple
modification in 3280bis, and the addition of some security
considerations. Most importantly, 32890bis should be modified to ensure
that certificate and CRL validation are always performed with respect to
the same trust anchor. Security considerations should be added to
highlight the risk of issuing CA certificates without appropriate
constraints, and to caution application developers that trust anchor
information should be considered when accepting certificates.
The changes that I believe should be implemented are as follows:
(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.
------- end of forwarded message -------
