Hi everyone,
I don't contribute much to this list but I thought I'd throw in my
$0.02 worth.
From: Jueneman(_at_)gte(_dot_)com
X-Mailer: SuperTCP/NFS for Windows Version 4.00 (Mailer Version 1.02)
To: Mr Rhys Weatherley <rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au>
Cc: Christian Huitema <huitema(_at_)sophia(_dot_)inria(_dot_)fr>,
pem-dev(_at_)tis(_dot_)com
...
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.
email addresses map directly into DNS names. DNS security will permit
the storage of keys under any DNS name. Such entries will be signed
if the DNS zone is secure. Such a signed binding between a domain
name and a key *is*, in effect, a certificate. Such simple DNS
certifications (consisting of a KEY RR and a SIG RR) are trivially
findable on-line but could also be easily detached...
(They also can form a nice hierarchy if you want to use it, with the
key for each zone certified by the next higher zone up to root.)
If someone wants to, they could define a DNS RR that claimed to have
in its data portion the DN equivalent of its DNS owner name.
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?
(1) Why on earth do you assume that DN'w will be unique for people? Seems
like they have exactly the same "problem" as email address.
(2) Of course you can set up aliases for a zillion email names if you
need to. To be of general use, the aliases should, in effect, be
many-to-many. So what? Your constant attempts to chain people in a
prison of identity in ridiculous. In the Internet world, the email
mailbox address *is* the identity. Its only for special limited
purposes that a binding between an email address and an individual
humane being is needed and for each such special purpose there is
normally a special authority that needs to keep authoritative track of
this. This authority can always issues certificates of some sort, if
its wants, and whoever cares to can believe the certificates if they
want to. Note that many such entities, such as governments, will
deliberately create "false" entries due to witness protection
programs, secret agents, etc.
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?
Any key stored under the name can obviously be used to encrypt stuff
to that email address and something signed by the private equivalent
of any key stored under the domain name is authentically from that
name. If multiple people/organizations/whatevers choose to use the
same name (ie, email address), they have choosen to merge their
identities for communications using that name and you *should*not* be
able to securely distinguish them unless they sign their messages with
different names.
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.
It's always the case that you occasionally need to look something up
by something different than the primary key, which for Internet
identities, is the email address. You are one hell of a lot more
likely to remember the email address or to have gotten mail from the
entity from which you can extract this than you are to have remembered
the DN or gotten it in some fashion.
The presumption that there will ever be a total directory that is
searchable is ridiculous. Look at the fraction of people who have
unlisted phone numbers. Almost no company makes their employee
directory public. You are *never* going to have a total directory to
look people up in and if you concentrate on that you are dooming
yourself to permanent failure.
There will always be somewhat of a mess of assorted methods, some
quite ad hoc (like asking someone you know who you think might know
the address for the person you are after). That's just the way it
is. No technical solution exists to the problem that there will
NEVER be a complete directory because the difficulty is that so many
people and organizations have data they want very much to be kept out
of such a directory.
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".
These problems have been around for thousands of years. When you have
a lot of entities in a directory, many of them will be close together
and hard to distinguish. i.e., it's a hard problem with no perfect
solution.
It seems too 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.
You need everything. You need the search mechanism to know all about
common nicknames. You need people to be able to list their own AKAs.
You need to be able to do SOUNDEX searches. And you need everything
else you can think of. And you will still fail a lot due to people
actually missing from the directory and due to close hits from
multiple entries that are very similar in the indicies you are using
and due to cases where the correct entry is missing and the indicies
you are using are a close hit for a wrong entry that is there. And
while this is an interesting discussion, I don't see that it has much
of anything to do with the MIME structure of secure mail or how to fit
PEM into that. Seems more like a discussion in the unsolved problmes
of library science arena.
...
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.
Exactly. the existing, globally deployed Domain Name System, with
some security additions, is such a protocol. See
draft-ietf-dnssec-secext-*.txt. Just, for example, retrieve any user
account KEY RRs stored under jueneman.gte.com.
...
Bob
--------------------------------
Robert R. Jueneman
Donald