Subject: Name collisions

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 17 Jun 2005 12:26:33 +0100

David,

>Oh dear. The same old problem of namespaces again. X.500 makes it very 
>clear that there is only one namespace for all Distinguished names, so 
>CAs cannot invent their own DNs in isolation to the rest of the world. 

You make the same mistake as many (but not all) in the OSI Directory WG 
by still confusing X.500 and X.509.

You cannot not mandate every CA on the earth to know all the other CAs  
(not yet CAs on the moon, as far as I know).

>If they do, then their domain is the entire universe of distinguished 
>names and they cannot expect to interwork with any other CA without 
>experiencing name collisions.

It is perfectly possible to securely internetwork with other CAs, whether or not 
there are name collisions.   

It is not possible to build a secure system making the (false) assumption 
that name collisions will never happen. Otherwise wrongdoers will penetrate 
systems constructed on that false assumption.

>Twenty years ago we had the same problem with people inventing their own 
>domain names and IP addresses on their LANs. Then they wondered why 
>things did not work correctly when they tried to connect to the rest of 
>the world via the Internet. Surprise, surprise, they had to get globally 
>unique domain names and IP addresses in order to interwork properly.

>It is the same today with CAs and X.500 distinguished names. Fullstop. 

It is certainly not the same.

>End of discussion

No problem: you can leave the discussion, but the threat will not vanish by magic.

Denis

PS. Are you coming to IETF meeting in Paris, so that we can have a dinner 
together .. and speak about good food  ?

>regards
>
>David
>
>
>
>Manger, James H wrote:
>> Denis Pinkas wants to distinguish: * An indirect CRL that covers
>> certificates from only one CA; from * An indirect CRL that covers
>> certificates from more than one CA. David Cooper and Santosh Chokhani
>> don't see this as a useful distinction.
>> 
>> 
>> Perhaps I can have a stab at why Denis might want the distinction.
>> It comes down to names and the namespace in which they are
>> unambiguous.  The minimal assumption is that names are only
>> unambiguous in the context of the CA that certified them.  That is, a
>> CA defines its own namespace.
>> 
>> With an indirect CRL covering certificates from only one CA, we can
>> chose that CA as the single namespace.  As long as all the names
>> being matched come from that namespace we have a CRL validation
>> solution with unambiguous names and no extra assumptions.  We can
>> achieve this if the CRL issuer's own certificate comes from that CA
>> (and the CA includes its own name in its own namespace).
>> 
>> With an indirect CRL covering certificates from more than one CA
>> there is no longer a single CA to provide the namespace for all names
>> being matched.  Consequently, the minimal assumption that names are
>> only unambiguous in the context of one CA is no longer sufficient.
>> 
>> James
>> 
>> 
>
>-- 
>
>*****************************************************************
>David W. Chadwick, BSc PhD
>Professor of Information Systems Security
>The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
>Tel: +44 1227 82 3221
>Fax +44 1227 762 811
>Mobile: +44 77 96 44 7184
>Email: [email-masked]
>Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
>Research Web site: http://sec.cs.kent.ac.uk
>Entrust key validation string: MLJ9-DU5T-HV8J
>PGP Key ID is 0xBC238DE5
>
>*****************************************************************
>

Regards,

Denis Pinkas

---

From: David Chadwick <[email-masked]>
Date: Tue, 21 Jun 2005 00:13:50 +0100

Denis

I think not. X.509 references X.501, which defines distinguished names. 
So I dont think it was me who was confused, but rather a large number of 
PKI people who read X.509 but never bothered to read X.501 (or even the 
bits of X.501 that were referenced by X.509).

David Cooper's message of 20 June tells you were the reference is made.

> (not yet CAs on the moon, as far as I know).

We dont need to. We never have needed to. Do you know all the email 
addresses in the world?? No, and you dont need to.

All  you need to know is that your name/CA name/email address 
etc....(add your other favourite global name here) is bound to be 
different from all other ones. That is sufficient.

> there are name collisions.   

No I dont believe it is (always). If 2 CAs have the same name, and 
re-key, or use indirect CRL issuers (which might also have name clashes) 
then we have a hard problem on our hands in practice.

> 
> It is not possible to build a secure system 

Its not possible to build a 100% secure system anyway, ever.

> making the (false) assumption 

Wrongdoers will penetrate all systems given enough time and money. So 
this is not an argument against using globally unambiguous names.

regards

David

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 21 Jun 2005 12:02:30 +0200

David Chadwick wrote:

> Denis Pinkas wrote:
>
>> You cannot not mandate every CA on the earth to know all the other 
>> CAs  (not yet CAs on the moon, as far as I know).
>

Transport of email is dependent on the unicity of DNS addresses, which 
has a centralized registration system to guarantee it.
And if they are not unique, the transport is broken.

>> It is perfectly possible to securely internetwork with other CAs, 
>> whether or not there are name collisions.   
>
> re-key, or use indirect CRL issuers (which might also have name 
> clashes) then we have a hard problem on our hands in practice.

If we need to enforce the unicity of the names, it must be in a way 
that's so secure it can be compared to a cryptographically secure 
method, or that will be the weak link of real life PKIs.

That's the strong reason to consider the problem, even if x500 is 
clearly built on the assumption distinguished names just are 
*distinguished* but does not care about how to actually enforce it 
(except by the way that bad data shouldn't be entered in the directory, 
but the annoying part is that x509 quite clearly has the promise it does 
not rely on the security of the directory, only of it's trust anchors).

>> It is not possible to build a secure system [...] 
>

But it's the very least to expect the system we construct is not broken 
from start, and that's very different from stating perfection can't be 
reached !

But the problem here is more in the line of "aren't we starting to have 
mutually incompatible requirements ?"
How can we both trust a CA and be protected if it does by accident or 
deliberately something bad ?
How can we both consider different two identically named certificates if 
they are under separate hierarchy and make cross-certification work ?
Trying to stop requiring that the naming is unique is very disruptive 
for the x509 architecture, and should be very carefully thought.

So I think that the format of the mailing list discussion is inadequate 
to make progress on this, and the suggestion of Stephen Farrell to first 
get drafts from the people who think they can solve the problem is the 
best solution.