(Warning - rather lengthy, and not directly related to PEM.)
This morning, before a blizzard of PEM mail arrived on various and somewhat
related subjects, I started to post a general question regarding how to search
for and find the certificate and e-mail address for a residential person. Since
the thread that was started several days ago is beginning to show some
prospects of actually converging on something like a concensus, perhaps I can
ask it now.
By way of background, we have been looking at the feasibility of providing an
X.500 directory service that would include GTE's white pages telephone
customers, and (maybe) lots of other things as well. Because we are primarily a
telephone/cellular company, as opposed to an e-mail provider, we would be most
interested in providing e-mail addresses and certificate storage, etc., as an
adjunct to our basic telephone business. Other potential directory service
providers might take a different approach.
There are several complicating factors that we are just beginning to address in
this area:
1. Unlike the printed white pages, an X.500 directory listing should provide a
globally unique distinguished name, even if there are two people with exactly
the same name living in the same locality.
2. Telephone company boundaries generally do not coincide neatly with
geopolitical boundaries, even in the case of a monoply local exchange carrier.
As the industry moves to accommodate alternate access providers such as cable
companies, PCS providers, etc., the territories will definitely overlap, and
each carrier will presumably provide the listings for their particular
customers.
3. In order for the directory service to be useful, it must not be necessary to
know what telephone carrier a given user is using in order to find their
listing. (Currently, this is one of the major problems with X.400.) Likewise,
the FCC will probably insist that the customer be free to change carriers
without having to change their listing or telephone number, etc.
4. Some customers may wish to avoid publishing their street address or their
phone number, etc., except to certain classes of people. Some people may not
even wish to have their full common name listed in the directory, at least as
part of the DN. That is, access controls will be applied to individual
attributes within the directory, including street addresses. And by definition,
the DN in the directory is must be accessible to everyone, or it becomes
useless as a search mechanism. So some of the obvious ways of guaranteeing
uniqueness through further qualification, such as including the street address
in the DN, probably cannot be used.
5. It is presumably socially unacceptable to require a customer to change his
name, invent a nickname, add a qualifying attribute, etc., just because he or
she happened to come second in listing that name. In fact, the order in which
names were listed might compromise a bit of a person's privacy, just because it
might indicate how long that person had had that listing, and therefore how
long ago they might have moved there and/or how old they were.
Given these constraints, how can we provide a residential person a DN that will
result in a reasonably rapid retrieval of the relevant information and still
guarantee the uniqueness of the DN?
I am thinking of proposing something like the following example for the primary
DN for residential persons:
country=US, state=Massachusetts, locality=Middlesex (county), {Surname=Jueneman
+ uniqueID=[message digest of commonName and postalAddress]}
The surname and message digest would result be a multivalued RDN which would be
guaranteed to be unique as long as there were not two people with the same
surname living at the same address. Large apartment houses, school dormitories,
prisons, and other large housing complexes would have to include some form of a
room number or other qualifier.
This combination would release the minimum possible information about an
individual (what county he or she lives in, and then only by surname), but
would still permit a reasonably rapid search. It would also not require the
user to remember the full common name of the person being sought in order to
find them efficiently. Further identification could only be made by reviewing
whatever additional attributes the customer chose to make publicly available,
e.g., favoriteDrink=Absinthe (which maketh the heart grow fonder)
Of course the user could also make available his or her full commonName,
postalAddress, JPEG bikini photo, certain other likes and dislikes, and a warm
and inviting "Come up and see me some time" sound bite if she chooses to, in
addition to her telephone number, beeper or cellular number, one or more e-mail
addresses, and PGP key and/or PEM certificate, not to mention her WWW home page
and her holograph. (Maybe that's how we can sell X.500 -- 900 numbers and
virtual reality!)
I'm assuming here that most people who want to contact someone generally have
some idea where they live. We can introduce some additional locality names as
aliases and seeAlsos, so that if someone doesn't know the difference between
Cambridge and Middlesex country, they could just specify the Boston
metropolitan area. Likewise, someone might know that someone lives in Burbank,
but no know whether that is Los Angeles, Orange, or San Bernadino counties. We
could also search all southern California, the entire East Coast, or the whole
country or even the entire world for everyone with a given surname, but that
would take considerably longer and presumably cost more.
In addition to the primary DN, we could also add the user's e-mail address as
an alias, even in the case where the user has multiple e-mail accounts. His
company e-mail name, his university e-mail address if he is also affiliated
with a university, and his CompuServe or AOL address could all be entered if
the user so chooses, and all would point back to the primary DN and the payload
entry containing the rest of the relevant information.
Notice that I haven't said anything at all about what is contained in the X.509
certificate DN (or the extended v3 contents). Depending on the user's
requirements and who he or she wishes to communicate with, that DN could be
just the message digest of the certificate itself, or it could include the full
commonName, postalAddress, organizational person affiliation, etc., etc.
Multiple certificates can be stored, including varieties for RSA/DES,
DSS/Skipjack, etc.
I don't think there are any technical obstacles to doing this, so my question
to the PEM community is whether they think this is a reasonable approach to
searching an X.500 directory to find someone, and if not what other schema they
would suggest.
Part two of this question, for extra credit, is how people would suggest that
Persona certificates be stored, i.e., what sort of a DN should be used to
guarantee uniqueness, still provide some reasonable ability to find that e-mail
address and certificate without having to search the entire global directory,
and without compromising any more of an individual's anonymity than is
absolutely necessary. (Is it acceptable to reveal the Persona user's country
code? Almost certainly. His state? Maybe. His county of residence, or at least
where he chose to be listed (not necessarily the same)? Probably not. The
message digest of his real common name and billing address? Absolutely not, for
you could look up that digest and find his real name. How else can we guarantee
global uniqueness? Maybe the Persona name plus a message digest of his
certificate or PGP key? Prizes will be awarded for the best solutions, and
neatness counts.)
Bob
--------------------------------
Robert R. Jueneman
Mgr., Secure Systems
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 (rolls over to cellular and/or my house
if no answer -- have patience)