Carl:
We all hope that cme(_at_)sw(_dot_)stratus(_dot_)com is unique! Likewise, DNs
should be
unique.
Russ
______________________________ Reply Separator _________________________________
Subject: a different cut on the perpetual DN debate
Author: Carl Ellison <cme(_at_)sw(_dot_)stratus(_dot_)com> at internet
Date: 3/8/94 10:31 AM
I've been reading pem-dev for a while now (years?) and have seen the
continuing argument over Distinguished Names (DNs) and the X.500 hierarchy.
I have even participated in that argument. However, I believe we've been
missing the point. I believe we have been trying to do some things which
vary between unwise and impossible.
--------
DNs are supposed to be unique. I always thought that was silly. The name
"Carl Ellison" is not unique and probably never will be. So, you have to
qualify that name with other information -- but all the other information
we've considered (address, company, job title, ...) is subject to change.
For that matter, the name "Carl Ellison" is subject to change.
Meanwhile, public keys are unique, so my suggestion has been to use public
keys. That suggestion is always met with the objection that a public key
might have to be revoked -- and as one person mentioned to me last week,
there's something unsettling about an "Identity Revocation List" (assuming
that we define an individual as a public key rather than a name).
There are some people in this discussion who want a DN to constitute a path
for law enforcement or the courts to use to get to a physical person in
order to enforce a contract. In order to do that, it needs to be trusted,
needs to identify a person uniquely and needs to carry information for the
court to use in finding the specified person.
However, any mechanism which permits people to be identified and traced
uniquely will be a tool for Big Brother. I would consider such a facility
unwise and wouldn't be surprised to find much resistance to such proposals.
---------
At the same time, we want the DN to tell me all I need to know about the
identified person so that I can know if I can trust that person (sight
unseen) in an envisioned transaction. At the very least, then, the DN
needs to contain enough information so that I know when I read that signed
record that the person doing the signing and I both have the same third
person in mind.
That's an interesting task. How can I prove to you that my friend Bill is
actually the same person as your friend Bill? Does the information in a DN
accomplish that? Does it accomplish that for all possible levels of
skepticism on your part?
Meanwhile, even if we can establish that we have the same friend, Bill, how
can I prove to you that Bill can be trusted for whatever activity you need
to trust him? Does a given DN include all possible descriptions of Bill's
trustworthiness in different areas? If it did, wouldn't that information
be considered private and therefore not something to be shown to all people
who can reference the DN hierarchy?
---------
Let me suggest that we need to split this discussion into what we really
need.
1. Can we establish an unrevocable, totally trustworthy,
unique description of an individual? Can we do that with just
text descriptions (as opposed to fingerprints, retnal scans, ...)?
2. Normal human names and physical appearances which we use in the
human-contact society (as opposed to the electronic-contact society)
are subject to both change and non-uniqueness and yet life
proceeds normally in spite of that. Do we need unrevocable,
unique identifications of individuals in order for the
electronic-contact society to function? If not, why not use
public keys as the primary identification index?
3. How can I establish trust of a person? If someone certifies that
"Carl Ellison <cme(_at_)sw(_dot_)stratus(_dot_)com>" has a RIPEM MD5 of
39D9860686A9F075A9A83D49589C677A -- what does that tell you
about Carl's trustworthiness (a) to spend Stratus cash up to $500
per transaction; (b) to hear a confession in the Roman Cathoic Church;
(c) to pay his credit card bills; (d) to pay his phone bill;
(e) to rent an apartment without trashing it; (f) to be single
but interested in marriage (for a personal ad); (g) to be
HIV negative (or positive); ...?
Each of these requires its own syntax, has its own set of trusted
certifiers, etc. Neither the PEM Certification structure nor the
PGP web of trust (via key certification) addresses this issue: PEM
because the goal is for a single DN format; PGP because nothing is
certified but the mapping between key and Internet address -- no
mention is made of marital status or ordination to the priesthood.
No work has gone into protecting the actual certified information
from global disclosure (e.g., point (g)).
4. Once we have established mechanisms for communicating trust
certification (and for controlling the dissemination of that
information itself), do we need any certification hierarchy? What
does it do (aside from what the RIPEM key server does)?
--
Carl M. Ellison
cme(_at_)sw(_dot_)stratus(_dot_)com
RIPEM MD5OfPublicKey: 39D9860686A9F075A9A83D49589C677A
Stratus Computer Inc. TEL: (508)460-2783
55 Fairbanks Boulevard ; Marlborough MA 01752-1298 FAX: (508)624-7488