[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: specification language?
>At 10:36 3/8/96, Jueneman@gte.com wrote:
>
>>2. Sometimes it is necessary to use multivalued RDNs in a name, in order to
>>disambiguate them. For example, if there are two people of the same name in
an
>>organization, it may be necessary to use commonName plus serialNumber
>>(employee
>>ID) to define which one is which.
>
>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.
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 identiy is
confused with someone else's (just ask anyone who has had their credit rating
screwed up because os such a mistake.)
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.
>
>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.
>
>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. I claim that the same is true of DNS names, especially if you are a
CompuServe user.
Bob