[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
>>user.
>
>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
>certificate
>list.
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
>all.
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 |
+--------------------------------------------------------------------------+