[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

uniqueness of X.500 names

At 17:49 3/24/96, Jueneman@gte.com wrote:

>>Sorry, Bob, but I can't resist this :).
>>This is one of the problems with DNs.  Uniqueness of DNs is advertized as
>>necessary so that I, the remote user looking up my old friend Bob at IBM,
>>know which of the many Bobs is my friend.  However, the uniqueness of DNs
>>is solved in some manner the CA chooses -- e.g., appending employee number
>>or mail stop -- and that could be totally irrelevant to me, the external
>Sorry, Carl. The problem is not with DNs, but life in general. Since as a
>society we don't require people to assign unique names to our children when
>they are born, we end up with potential confusion. so when you want to look up
>someone's name in the telephone book, your organizational directory, you often
>have to use some other information to determine which person is which.

I agree completely.  This is an attribute of human beings, and no
technological construct is going to solve it.  All we can do is make secure
paths to the other information -- especially to the person himself.

>The basic assumption that was made in X.500 (not specifically in X.509) was
>that it would be very useful to have an globally unambiguous way of ensuring
>that entries about two different people would be kept separate, so as to avoid
>the serious consequences that sometimes occur when someone's identity is
>confused with someone else's (just ask anyone who has had their credit rating
>screwed up because os such a mistake.)

This is a necessary design goal IMHO -- not just something "useful".

>However, the DNs themselves were NEVER intended to be the user friendly way of
>actually resolving those possible ambiguities -- they were only provided as a
>means of having a unique index assoicated with an entry. They way that you
>disambiguate them is to _browse_, looking at other attributes you already
>know.  Of course, if you have received someone's certificate directly -- the
>business card approach -- that's cool too.

Ah -- but that's the rub.  There are X.509 defenders out there who claim to
me, face to face, that I the user need their unique X.500 names so that I
can tell my friend Bob at IBM from all the other Bobs at IBM.  Those X.509
defenders are misspeaking.

>>This came up for me in reviewing an article on certificates, recently.
>>Namely, the step-by-step process of using a certificate ignored the
>>important step of finding out which of many possible ID strings is the one
>>of interest to you.  It's interesting to me to note that whatever effort
>>you have to go through to discover that ID-string:human mapping is probably
>>identical to the process you'd have to go through to get a public key
>>directly from your old friend.
>Yes, it might well be.  But what you might want to do before you send off a
>encrypted scathing message regarding your boss, etc., to your old friend,
>is to
>revalidate the friends name and other attributes maybe even cheecking his
>picture in the X.500 data base. Otherwise, some very embarrassing errors can
>occur if you use the same "nickname" list of e-mail address as your

As long as I assign the nicknames in my list and generate all the
certificates in my (nickname,key) database, then there is no problem short
of the occasional brain fart.

>>I offer this note not to start a flame exchange but to note for the record
>>that the frequent argument in favor of X.500 style unique names is
>>seriously flawed>for me, the user.
>It isn't the X500 that is flawed, it is the perceived need for unique names at

It's when we start relying on names to mean something for security purposes
that the scheme falls apart.  If X.509 hadn't come along and taken on a
life of its own, then X.500's uniqueness would probably have been quite
adequate -- for its own purposes.

For security, uniqueness isn't sufficient.  Both I and the CA maintain
mappings of (identity,name).  However, we don't have mappings between
name_CA and name_me.  If I'm going to use the CA's product, then I need to
know its mapping.  identity_CA and identity_me are not expressible
digitally, so we can't have a mapping there.  To form the mapping between
name_CA and name_me, I have to make contact with identity_me and let
him/her/it provide the mapping.  I have to make that contact securely, with
no man-in-the-middle.  If I've done that, then identity_me can hand me a
key directly -- and the need for the CA goes away.  I can form my own
(key,name) certificate directly and know I can trust it.

>I claim that the same is true of DNS names, especially if you are a
>CompuServe user.

Not being a compuserve user, I don't understand this reference.  Their
login names are cryptic -- as bad as public keys or hashes [but shorter].
If that's what you mean, I could for the sake of argument claim that it's
better that way.  At least with a compuserve name, you don't think you know
who it refers to until you've checked.

 - Carl

|Carl M. Ellison          cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc., Suite 430                   http://www.cybercash.com/    |
|2100 Reston Parkway           PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Reston, VA 22091      Tel: (703) 620-4200                                 |