Warning: This thread is NOT intended to directly address any particular issue
concerning PEM-MIME, but is more focussed on X.500 questions. I apologise for
wasting the pem-dev bandwidth, but this audience is probably more knowledgeable
on some of these issues than any other group I can think of. But if you are
concerned that continuing this discussion might be holding up the release of
the spec in any way, you can quit reading now. :-)
In fact, the style of DN that everyone loves to hate, the
organizationalPerson, DN, would be workable, but may not be very
helpful, NOR IS IT NECESSARILY EXPECTED TO BE. The DN is expected to
provide a globally unique way of identifying an organization, person,
machine, etc., but it is NOT the way that such information should be
searched for.
Let me back off a little from what I said. Within a single X.500 DSA, it is
perfectly possible to build "filters" or reverse search indices that can
facilitate look-ups based on other attributes. "Favorite drink" plus a uniqueID
would not be a very reasonable DN, although technically allowable, but a filter
could be constructed that would search on favorite drink as fast as it would
search on state, locality, and surname.
However, this gets a lot harder once you leave the domain of the DSA that you
are connected to. IF such a filter were defined in all of the DSAs, then any
DSA would be able to perform the search efficiently, but if not it would
require searching that DSA's entire database -- an expensive operation.
So the reason for having an agreed-upon schema for Distinguished Names is so
that all of the directory service providers can search for common information
efficiently. Since there may be many Administrative Directory Managment Domains
(ADDMDs) throughout the world and many more Private Directory Managment Domains
(PRDMDs), some reasonable standard or agreement has to be concocted to
facilitate these searches. In addition, although some redundance is desirable
for the sake of availability, it would be desirable if the the naming scheme
could at least focus or direct the search strategy somewhat, so that not all
DSAs have to be interrogated for every non-local query.
Ah! You've just hit the nail on the head for why e-mail identifiers and
arbitrary strings in PEM-MIME are a good idea. They are very good search
keys, whereas DN's are, by your own admission, hopeless search keys.
No, let's try to be a little more precise. I did NOT say that DNs are hopeless
search keys, since I haven't said what the DN schema was that is in question.
If the schema is in fact an RFC822 e-mail name, then by your argument that
style of DN would be a very _good_ search key.
(And BTW, I've already given up on trying to fight the use of e-mail
identifiers and arbitrary strings in PEM-MIME. If it works and is accepted,
then fine. If not, the implementors will have some useless code. I'm more
concerned about the use of bare keys without certificates and CRLs, but I've
finally convinced myself that the certificate infrastructure is likely to come
along soon enough that this shouldn't be any issue for too long. And I do like
Ned's distinction between Certified and Uncertified, and hope that
implementations will reflect such distinctions.)
All joking about boomerangs aside, I'm deadly serious in asking -- how would
e-mail users like to be listed and found in their ideal directory?
By e-mail address. Simple huh? However, that doesn't rule out other
forms of identification. Searching by name, organisation, position, etc,
are all good search criteria, but are inherently fuzzy. E-mail addresses
are extremely exact and are likely to find the right key first time every
time. If you happen to have it, why not use it?
Clearly. No problem. We can certainly create an alias based on the e-mail
address that would point directly to whatever other DN might be used, even the
awkward, ugly organizationalPerson or residentialPerson style DN. Creating such
an alias would be a reasonable feature for a service provider to offer. And if
your own local database of nicknames includes e-mail names, as it almost
certainly does, then this would be a very logical and fast way to locate the
cryptographic certificates and anything else that might be required.
There are, however, several cases where it wouldn't work. Although the e-mail
address is globally unique, the binding of e-mail address to user name is not
one-to-one. I have four alternative e-mail address name forms -- Jueneman,
rjueneman, rrj0, and rrj1 at gte.com, as do many of my collegues. In addition,
many of them also have mailboxes at one or two universities, and perhaps on
CompuServe or DOCKMASTER or some other provider as well. Should we set up
aliases for each of these?
Some people have the reverse problem -- multiple individuals share a common
mailbox. Admittedly tacky, like sharing your toothbrush, but not uncommon,
particularly for smaller companies just starting up. Now which certificate
should be used in this case?
But brushing these issues aside, what if I don't know or can't remember
someone's e-mail address? Kent(_at_)bbn(_dot_)com is easy -- we should all have
such short
surnames and domain names. But what if I get confused -- was it Clark Kent and
Steve Reeves, or Steve Kent and Clark Reeves? And surely you don't expect me to
remember Peter William's horrible X.400-to-SMTP-gateway e-mail address.
So we cannot necessarily assume that we even know the country of residence
of a
user. That's not a problem for a Internet e-mail address -- naming does not
equate to routing in any (or at least most) cases. So should I go about
looking
up Ted Myer's e-mail address if I can't remember it -- do we put everyone in
the world in the public name space? How else can we qualify the name to make
it
globally unique, AND facilitate searching, at least to some extent?
I think you are trying to solve too many problems here Bob. The PEM
working group doesn't need to solve the problem of finding an e-mail
address for a user. There are many ways, existing and proposed, for doing
that already on all sorts of search criteria (whois, netfind, USENET
addresses WAIS server, UUCP maps, and yes, even X.500). There's a whole
FAQ on this issue, and research is continuing both at the academic and
practical levels. A good UA in the future will need to support these
kinds of things, but they are completely unrelated to PEM's services.
I was raising this issue from the standpoint of a potential X.500 directory
service provider that would like to overcome some of the problems that we are
currently facing, and addressing this group as representative of the larger
community. Reardless of the protocol or implementation that might be used,
whether X.500, whois++, etc., etc., what kind of search keys would the user
community find useful?
For example, although Ned hasn't followed up on his thinking, I agree that
commonName makes a lousy search key. Although presumably commonName should be
presented in conventional order, some people feel that "Jueneman, Robert R."
should be acceptable -- and I won't even get into the issue of Chinese and
Korean names and which comes first. Even if we agree to list first name first,
its tough to remember that it is Bob Jueneman and Rob Shirey, not the other way
around. And heaven help the Elizabeths of the world -- is it Liz, or Beth,
Betty, or Betsy? And what about those people who are known by their middle
name, like our VP for Research and Development, C. David Decker, who goes by
"Dave".
It seems to much to ask for any UA to deal with all of the different nicknames
and short forms, so maybe we have to assume that the user himself will list all
of the common varients, and maybe even some of the more common misspellings,
using a seeAlso.
The point that I was getting at was that the space of all e-mail users common
names is going to grow very rapidly, and without some form of hierarchy being
imposed will become very difficult to search. But other than country, it is
hard to see what other form of qualification could be used -- I was just
looking for some suggestions.
What is missing from PEM's point of view is the final step that maps the
found e-mail address to a public key. I believe it is fruitless to try to
modify whois, netfind, X.500, etc, to do this. I believe a smarter way is
to define a new and simpler protocol that just does key management and can
search on e-mail addresses. It may even be able to search on other things,
which would be a bonus, but going the whole hog to support every search
criteria under the sun is best left to other working groups that have more
expertise in this area than we do. Let's stick to what we know, key
management, and leave the rest to someone else to worry about.
I strongly disagree, at least with respect to X.500. NO, repeat, NO
modification is necessary to X.500 to support the use of e-mail names as a
search argument to find certificates. All we have to do is add the rfc822 name
to a revised organizationalPerson or residentialPerson object class and define
the appropriate schema. That doesn't change the X.500 standard, it shouldn't
change any decent DSA implementations, and it should have a minimal impact on
any DUAs. Directory User Agents that are implemented as client-server models,
where the server is responsible for actually implementing the DUA
functionality, such as DEC's InfoBroker, will have an even easier time.
Since it appears that most of these systems are moving to support a WWW
interface, it should be very easy to integrate a certificate retrieval
mechanism within existing browsers.
I will therefore make the following offer:
-----------------------------------------------------------------------
If this group can arrive at a reasonable concensus that an rfc822 e-mail
address is highly desirable as a search argument for finding PEM or even PGP
certificates, I will raise that as an action item at the next meeting of the
NADF, in late February. I wouldn't anticipate any serious problem in getting it
added to the existing schema.
-----------------------------------------------------------------------
That won't solve the problem for the whole world, but it will at least provide
a reference point for others to use. And since the Internet white pages project
and the NADF pilot are in the process of being integrated, this should begin to
lead to a real solution.
I was planning to raise the issue of a simple key management protocol
after the PEM-MIME spec goes through. I've got some ideas along this
line, but at present it is more critical that we get PEM-MIME out the door
and implemented, even if it isn't as pure as some would like it to be.
There is a precedent for separating the "find e-mail address" and "find
key" issues. Remember those "integrated packages" of days gone by? They
had spreadsheets, wordprocessors, and databases, all in the same package.
They were eventually rejected by the users because they did all those
functions so-so, rather than doing all those functions well. The users
moved to mixing and matching software to get the best in each category and
demanded that the manufacturers provide ways to convert between different
formats and systems.
From a user's point of view, they aren't going to notice (or care) that
the UA software first contacts a whois/netfind/X.500 server to get the
e-mail address and then contacts a separate key server to get the public
key. There's no need to do everything with the one system because a good
UA will hide that from the user.
There is a chicken-and-egg problem here. Some e-mail packages like Eudora, and
perhaps Lotus Notes, are going to be coming out with X.500 interfaces. And some
others will include PGP, and maybe PEM. But no one is likely to use X.500 to
retrieve PEM certificates if there are no certificates to be found there, and
if there are no decent UAs, there won't be any push to make certificates
available via this mechanism.
If there was a simple way to make money by providing an X.500 service this
would be a relatively simple problem to solve. Failing that, we may have to
fund it the same way we do Internet connections, or ask for a volunteer to
provide such a service as a freebie.
Bob
--------------------------------
Robert R. Jueneman
Staff Scientist
Wireless and Secure Systems Laboratory
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820