Subject: Re: How ambiguous are names in actuality?

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 18 Jul 2005 10:13:10 +0100

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

>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.
>
>

Regards,

Denis Pinkas

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 18 Jul 2005 09:58:58 -0400

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.

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.

-----Original Message-----
From: [email-masked] [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.

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.

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.

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 ".

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

>-----------------------------------------------------------------------
>---------------------------------------------------------
>
>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

>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 
>CRL.  Ditto for Bob.
>
>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 

>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 

>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

>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 
>often NOT the case.
>
>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.
>

>"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 
>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

>C2, and C3 issue end user certificates in the DITs N1, N2, and N3
respectively.

>respect to T.  (Names that could have collided are excluded from C3's DIT.)
>
>Conclusion/Proposal
>

Regards,

Denis Pinkas

---

From: Stephen Kent <[email-masked]>
Date: Mon, 18 Jul 2005 17:13:08 -0400

Denis,

I appreciate your comments on subtle issues associated with name 
collisions, and how these issues differ for ACL or end entity 
authentication use vs. non-repudiation use.

I don't think 3280 or its successor should be providing detailed 
guidance for application developers re use of certs. But but another 
document, maybe a BCP, would be a good lace to do this. One could 
discuss in more detail the question of what constitutes a safe ACL 
entry or a suitable name to display for a received e-mail message, 
etc. Similar example could be provided for NR application contexts. 
One can even include a discussion of how the X.509 folks added issuer 
and subject UIDs to version 2 of the spec to address problems of name 
collisions in directory access controls, where the collisions arose 
due to name reuse over time, another source of name ambiguity.

Steve

---

From: Tim Polk <[email-masked]>
Date: Fri, 22 Jul 2005 16:56:50 -0400

Denis,

When I started in this field, I was taught that security should always be 
*commensurate with risk*.  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.  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?

In my opinion, the current mechanisms provide sufficient security to 
address the risk.  You have proposed rather major changes to the CRL 
validation algorithm.  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.)  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.

(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.)

Thanks,

Tim Polk

At 10:13 AM 7/18/2005 +0100, Denis Pinkas wrote:
> >------------------------------------------------------------------------- 
> -------------------------------------------------------
> >
> >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.
> >