Subject: How ambiguous are names in actuality?

From: Tim Polk <[email-masked]>
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.

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 15 Jul 2005 23:54:10 +0100

Tim,
Thanks for the good analysis.

I do however feel that a point is slightly missing and thus my
conclusion differ a bit from yours.

I agree that subject naming ambiguity is not a real problem. Every CA is
well motivated to name its subjects in a way that makes sense within the
context of the intended use of the certificates and the naming structure
used in X.509 definitely allows this to be done sufficiently.

My concern is only with CRL Issuer naming and the reliance of this name
for security. In parallel I'm also concerned about path validation
complexity.

While validating a certificate path is a primary task for path
validation, the CRL validation is more of a background process that is
more or less invisible to relying parties and their applications. As
such, the consequences and threats concerning ambiguous naming of CRL
issuers might not be as clear to deployers of PKI as subject naming is.
I would suspect that someone deploying PKI will just assume that the
system will make sure that only the correct CRL will match the
certificates anyway since they will never understand this issue fully.

I do not believe that name constraints is a sufficient mechanism since a
valid path to a colliding CRL will have a valid path, or it would not
exist. So if such CRL exist, then we can't fix the problem with name
constraints.

Finally I do not worry too much about deployed products concerning
indirect CRLs since this is an almost non used feature as far as I know.

Thus I think a more restrictive path relationship between the target
certificate path and its CRL issuer path is still motivated here.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Tim Polk
> Sent: den 14 juli 2005 20:24
> To: [email-masked]
> Subject: How ambiguous are names in actuality?
> 
> 
> 
> can't claim to have sorted it all out, but I have convinced myself
that
> one
------------------------------------------------------------------------
--
> ------------------------------------------------------
> 
>               How ambiguous are names in actuality, and how important
is
> it?
> 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
> 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
> from that relying party's point of view.
> 
> 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
> issuer name, but Alice can only validate one, she can't accept the
wrong
> path validation are relevant to when names are, and are not,
ambiguous.
> I'd
> Now, let's think about where name collisions can occur in the first
place.
> a single CA issues two certificates to "O=Microsoft, cn=John Wilson"
they
> certificates to "c=US, O=U.S. Government, OU=NIST, CN=CA1" then the
> subject
> won't occur?  Let's start with user certificates.
> 
> "C=US, O=U.S. Government, OU=NIST" DIT.   The NIST CA has been
designated
> assigns.  Similarly, the CA that supports NASA only issues
certificates
> for
> the name space "C=US,  O=U.S. Government, OU=NASA" DIT.
> 
> 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,
> C(2), ..., C(n).
> 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
> CA1 and CA2 recognize the same naming authority, then the user names
in
> the
> never issue a certificate to a CA with the DN "C=US, O=Coca Cola"
unless
> certificates in the DIT "C=US, O=Coca Cola" then it must be associated
> with
> the company!
> 
> 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
> 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
> "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
> in the policy decisions leading up to cross certification - but that
is
> 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.
> simplest and most widely available of our technical controls. Both
NASA
> and
> "C=US, O=Orion, CN=John Wilson" is unambiguous. While this control was
not
> 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.
> asserting a permitted subtree of "C=US, O=U.S. Government, OU=NIST"
with a
> eliminated.  This includes the offending CA certificate, so the
"wrong"
> CRL
> respectively.
> respect to T.  (Names that could have collided are excluded from C3's
> DIT.)
> 
> Conclusion/Proposal
>

---

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 26 Jul 2005 16:04:05 +0100

>Denis,

>Santosh's presentation was at the Washington IETF in November 2004.  Due to 
>time constraints, he had to abbreviate his presentation, but the complete 
>set of slides were included in the meeting proceedings.  The slides can be 
>found at:

>http://www1.ietf.org/proceedings_new/04nov/slides/pkix-4/sld1.htm

I have read these slides. However there is a major difference betwen slides 
and text in an I-D. There has been a request for text for both approches 
to be placed in an I-D. I made the effort to write it.

Should I understand that you do not support the promulgation of 
Santosh's approach ?

Denis

>Tim
>
>At 12:01 PM 7/18/2005 -0400, Santosh Chokhani wrote:
>
>>Denis,
>>
>>Solution was presented at the IETF.  I do not intend to draft an I-D unless
>>the WG chairs and AD intend to support its promulgation.
>>
>>From: Denis Pinkas [mailto:[email-masked]]
>>Sent: Monday, July 18, 2005 12:56 PM
>>To: Santosh Chokhani; [email-masked]
>>Subject: Re: How ambiguous are names in actuality?
>>
>>
>>Santosh,
>>
>> >To me the basic problem with Tim's posting is that it is a band aid
>> >solution to a problem that has a very simple solution.
>>
>>The problem raised is much wider that the CRL problem where the solution
>>fits in two lines of text:
>>
>>"The full certification path that has been used to validate the target
>>   certificate MUST also be used to validate the CRL issuer certificate".
>>
>>As far as I remember I have not seen a description of your solution posted
>>in:
>>http://www.ietf.org/internet-drafts/draft-santosh-pkix-...-00.txt
>>
>>Denis
>>
>> >When we look at the issue as an abstract graph theory problem and want
>> >a clean and simple solution to make sure that the correct CRL is
>> >fetched, the solution I have proposed solves the problem.
>> >
>> >Any thing else we do, is simply rationalization to support one or more
>> >unarticulated motives.
>> >
>> >[mailto:[email-masked]] On Behalf Of Denis Pinkas
>> >Sent: Monday, July 18, 2005 5:13 AM
>> >To: Tim Polk; [email-masked]
>> >Subject: Re: How ambiguous are names in actuality?
>> >
>> >
>> >
>> >Tim,
>> >
>> >My views are quite different. You are looking for a solution to
>> >MITIGATE the risk, whereas there exists a solution to SUPPRESS the
>> >risk, as it is explained below.
>> >The changes you propose, like "same trust anchor", do not suppress the
>>risk.
>> >
>> >
>> >You mention that the problem of name collisions exists both for two
>> >leaf certificates and for CRL certificates. This is correct. While the
>> >problem for CRL certificates arises
>> >only *during* the path verification algorithm, this is not the case for
>>leaf
>> >certificates.
>> >
>> >For a leaf certificate that has been verified to be valid, the output
>> >of the algorithm is a sequence of certificates up to a given trust
>> >anchor. The major issue is what
>> >to do with it, and this is NOT mentioned within RFC 3280.
>> >
>> >Leaf certificates may be used in two contexts:
>> >
>> >   a) access control or end-entity authentication,
>> >   b) non repudiation.
>> >
>> >These two cases are different and are explored below.
>> >
>> >ACCESS CONTROL OR END-ENTITY AUTHENTICATION
>> >
>> >There are two phases when a public key certificate is used for an
>> >access control service :
>> >
>> >- Phase 1 : the owner of the protected object must fill-in the ACL
>> >correctly,
>> >- Phase 2 : during an access, the sequence of certificates that has
>> >been validated
>> >                must be checked against the content of the ACL.
>> >
>> >The real issue is that nowhere in RFC 3280 it is said what the content
>> >of the ACL should be. Because of this lack of information, some
>> >implementations of "relying party software"
>> >may be subject to problems related to name collisions, while some others
>> >will not.
>> >
>> >There is no clear indication in RFC 3280 to tell how the owner of the
>> >protected object will make sure that it is pointing to the right
>> >certificate BEFORE using that certificate
>> >for access control purposes.
>> >
>> >The point is that the owner of the protected object SHALL enter the
>> >full certification path in the ACL. If it does not have the full path,
>> >then it SHALL construct it according to
>> >the validation policy that is appropriate for his application and SHOULD
>> >make sure
>> >that it is not revoked. It will thus use the full certification path and
>>may
>> >check either
>> >automatically using some local rules or may check using his brain that the
>> >full certification
>> >path is correct.
>> >
>> >Note that if the ACL would only contain the DN of the leaf certificate,
>> >then the access control mechanism would be subject to name collisions,
>> >
>> >When the ACL contains both the DN of the leaf certificate and all the
>> >DNs from the upper CA up to a trust anchor identified by its DN (i.e.
>> >the DN of the trust anchor is also taken,
>> >since there may be more than one trust anchor in a given validation
>>policy),
>> >then the
>> >access control mechanism can never be subject to name collisions.
>> >
>> >Since a validation policy may include more than one trust anchor, it
>> >means that it SHALL not be allowed to define a validation policy that
>> >uses two trust anchors with the same DN.
>> >
>> >This means that during phase 1, the owner of the protected object must
>> >fill-in the ACL with all the DNs from the certification path, including
>> >the DN from the trust anchor
>> >(of course a hash of it may be used instead) and that during phase 2, the
>> >whole certification path
>> >must be used and compared with the content of the ACL.
>> >
>> >This solution fully *suppresses* the risk in any case.
>> >
>> >Of course, in some contexts, some shortcuts may be taken (e.g. when
>> >there exists a single trust anchor in the validation policy) or when it
>> >may be known that name collisions
>> >may never happen (e.g. because all the CAs apply a given naming policy) but
>> >this is not
>> >the general case.
>> >
>> >The solution explained above is also much simpler than adding name
>> >constrains that could be anyway defeated.
>> >
>> >NON REPUDIATION
>> >
>> >With non repudiation, only the whole sequence of DN extracted from the
>> >certification path is meaningful. A DN like CN= "John William" does not
>> >make sense unless at the same time
>> >all the upper DNs from the CAs are used or displayed. So if someone wants
>>to
>> >know
>> >without any ambiguity who a signer is, it SHALL use of the sequence of DN
>>up
>> >to
>> >a trust anchor of the signature policy.
>> >
>> >Since a signature policy may include more than one trust anchor, it
>> >means that it SHALL NOT be allowed to define a signature policy that
>> >uses two trust anchors with the same DN.
>> >
>> >COLLISIONS BETWEEN CRL ISSUER NAMES
>> >
>> >For CRLs, I have already mentioned the additional sentence that shall
>> >be added to RFC 3280. It is copied again below  :
>> >
>> >"The full certification path that has been used to validate the target
>> >certificate MUST also be used to validate the CRL issuer certificate ".
>> >
>> >
>> >REPLY TO YOUR CONCLUSIONS
>> >
>> >As a reply to your conclusions: using path length constrains does not
>> >solve the issue. Adding other constrains does not solve the issue
>> >either. Using name constraints would
>> >introduce an order of magnitude of complexity and would not be effective in
>> >the general case.
>> >Using certification policies and path length constrains might help, but
>> >still do not solve
>> >the problem in the general case.
>> >
>> >
>> >Denis
>> >
>> >
>> >>----------------------------------------------------------------------
>> >>-
>> >>---------------------------------------------------------
>> >>
>> >> is it?
>> >>certificates, there is no ambiguity in Alice's world.   Similarly, if 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
>> >
>> >>Definition 1:  a Name N is unambiguous for a trust anchor T if and
>> >>only
>> >>if
>> >>a single CA issues two certificates to "O=Microsoft, cn=John Wilson" they
>> >>"C=US, O=U.S. Government, OU=NIST" DIT.   The NIST CA has been designated
>> >>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,
>> >>C(2), ., C(n).
>> >>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.
>> >>
>> >>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
>> >
>> >>never issue a certificate to a CA with the DN "C=US, O=Coca Cola" unless
>> >>Without a
>> >>O=Orion" DIT.   If each organization established their CA with the name
>> >>love, we have an immediate name collision for a CA named "C=US, O=Orion,
>> >>Wilson", etc., etc.  Each CA has played by the rules, but names have just
>> >>procedural/policy issues, there are some important mechanisms that
>> >>help
>> >>us
>> >>probably wasn't expecting to accept transitive trust from those CAs, and
>>it
>> >
>> >>"C=US, O=Orion, CN=John Wilson" is unambiguous. While this control was not
>>
>> >>Orion CA.
>> >>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.
>> >>
>> >>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.
>> >>
>> >>multiple trust anchors should consider the trust anchor in access
>> >>control decisions to ensure that names are unambiguous.
>> >>
>> >Regards,
>> >Denis Pinkas

---

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 26 Jul 2005 15:59:24 +0100

>When I started in this field, I was taught that security should always be 
>*commensurate with risk*.  

When I started this field, I was told that 100 % security does not exist, 
but this was not a rational for purposely building insecure algorithms or designs.

:-)

> It is always possible to add new controls, but 
>it is not always appropriate.  That is why I started with a lot of thinking 
>about the problem, and the actual level of risk faced by PKI users.

>I did not see anything in your message below that indicates that my 
>analysis of the risk is incorrect.  

We do agree that there is a risk of name collisions, but whereas you are looking 
for solutions to MITIGATE the risk, I have presented solutions to SUPPRESS the risk.

> I explained in detail why I believe 
>name ambiguity would only occur in rather unlikely niche cases.  Do you 
>disagree with my analysis, and if so why?

The risk is similar as having two (different) files on an hard disk that bear purposely 
or by accident the same name. The hard disk is equivalent to a trust anchor, 
while every file is equivalent to the name of a certificate owner.

Checks between cannot be limited to simple DN comparisons unless it is known 
which CA is trusted to issue that name. My response goes in details about this.

>In my opinion, the current mechanisms provide sufficient security to 
>address the risk.  You have proposed rather major changes to the CRL 
>validation algorithm.  

The topic of "name ambuiguity" or of "name collisions" is not strictly related 
to the CRL validation algorithm. On one aspect only it relates to it.

> I have proposed changes as well, but mainly advocate 
>using existing mechanisms as designed.  My change can also be implemented 
>through configuration (i.e., by accepting only a single trust 
>anchor.)  

The "single trust anchor" is insecure in the general case, and does not even had anything.

> Your proposal would have a significant impact on all our running 
>code; IMHO this is inappropriate unless the changes significantly reduce 
>the risks faced by PKI relying parties.

It does not simply REDUCE the risk: it SUPRESSES the risk.

>(BTW, I also agree with Steve's observation that the discussion of ACLs 
>below significantly expands the scope of 3280bis.  A separate BCP on the 
>topic would certainly be of value, but for the purposes of 3280bis we 
>should restrict this discussion to path validation.)

Well, it could also be placed in an informative annex. 
At this time, I wonder it is really a BCP (Best Current Practice).
It would rather be a BCR (Best Current Recommendation).

:-)

Denis 

>Thanks,
>
>Tim Polk
>
>At 10:13 AM 7/18/2005 +0100, Denis Pinkas wrote:
>>Tim,
>>
>>My views are quite different. You are looking for a solution to MITIGATE 
>>the risk,
>>whereas there exists a solution to SUPPRESS the risk, as it is explained 
>>below.
>>The changes you propose, like “same trust anchor”, do not suppress the risk.
>>
>>You mention that the problem of name collisions exists both for two leaf 
>>certificates
>>and for CRL certificates. This is correct. While the problem for CRL 
>>certificates arises
>>leaf certificates.
>>For a leaf certificate that has been verified to be valid, the output of 
>>the algorithm
>>is a sequence of certificates up to a given trust anchor. The major issue 
>>is what
>>There are two phases when a public key certificate is used for an access 
>>control service :
>>
>>- Phase 1 : the owner of the protected object must fill-in the ACL correctly,
>>- Phase 2 : during an access, the sequence of certificates that has been 
>>validated
>>The real issue is that nowhere in RFC 3280 it is said what the content of 
>>the ACL should be.
>>Because of this lack of information, some implementations of “relying 
>>party software”
>>protected object
>>will make sure that it is pointing to the right certificate BEFORE using 
>>that certificate
>>The point is that the owner of the protected object SHALL enter the full 
>>certification path
>>in the ACL. If it does not have the full path, then it SHALL construct it 
>>according to
>>may check either
>>then the access control
>>mechanism would be subject to name collisions,
>>
>>When the ACL contains both the DN of the leaf certificate and all the DNs 
>>from the upper CA
>>up to a trust anchor identified by its DN (i.e. the DN of the trust anchor 
>>is also taken,
>>policy), then the
>>Since a validation policy may include more than one trust anchor, it means 
>>that it
>>SHALL not be allowed to define a validation policy that uses two trust 
>>anchors with the same DN.
>>
>>fill-in the ACL
>>with all the DNs from the certification path, including the DN from the 
>>trust anchor
>>Of course, in some contexts, some shortcuts may be taken (e.g. when there 
>>exists a single
>>trust anchor in the validation policy) or when it may be known that name 
>>collisions
>>may never happen (e.g. because all the CAs apply a given naming policy) 
>>but this is not
>>the general case.
>>
>>The solution explained above is also much simpler than adding name constrains
>>that could be anyway defeated.
>>
>>NON REPUDIATION
>>
>>certification path
>>is meaningful. A DN like CN= “John William” does not make sense unless at 
>>the same time
>>to know
>>up to
>>Since a signature policy may include more than one trust anchor, it means 
>>that it SHALL NOT
>>be allowed to define a signature policy that uses two trust anchors with 
>>the same DN.
>>
>>For CRLs, I have already mentioned the additional sentence that shall be 
>>added to RFC 3280.
>>It is copied again below  :
>>
>>“The full certification path that has been used to validate the target 
>>certificate MUST also be
>>used to validate the CRL issuer certificate ”.
>>
>>
>>solve the issue.
>>Adding other constrains does not solve the issue either. Using name 
>>constraints would
>>introduce an order of magnitude of complexity and would not be effective 
>>in the general case.
>> >------------------------------------------------------------------------- 
>> -------------------------------------------------------
>> >
>> >A trust anchor T may cross certify with two different CAs  say the ones
>> >in the policy decisions leading up to cross certification  but that is
>> >often NOT the case.
>> >