---- Included message:
human factors lesson here - if a computer professional is having
trouble specifying his X.400 address in a replyable form, we probably need
to look carefully at the choice of X.500 names (which are similar and
related in a not-quite-obvious way) in certificates. This could be
a Help Desk nightmare - if people don't know their own addresses, how
are they going to be sure they signed things with the right certificate? ;)
As I said in my recent message to Peter, it is important to distinguish between
the
DN used in an X.509 certificate that is used to bind the user's public key to
his
name-plus-other-useful-information (TBD), with the DN that is actually used to
look
up a person. In a real directory, the X.509 certificate is carried as just part
of
the payload, along with the user's picture, favorite drink, etc. The DN that is
used
to _directly_ access this information may or may not be particularly
user-friendly
-- it is the job of the DUA to present this information in a more "natural
style,"
and by that I certainly do NOT mean Kille's string notation! More to the point,
in a
real directory, searching and browsing operations are likely to be used more
often
than direct read operations, so the DN is not particularly important.
In any decent e-mail implementation that includes DUA and PEM support, there
would
be several layers of indirection and caching that would typically be used. For a
user's most frequent correspondent's, a local alias file would store both his
name,
e-mail address, and the most ocmmonly used certificate. Depenidng on the user's
preference, the expansion of this information might or might not be presented
for
his approval before taking action on it.
If the correspondent isn't in the local alias file, then several user-friendly
search criteria could reasonably be defined. In addition, your own DUA could
keep
some of its own information cached, e.g., the last 500 unique entries that were
examined, and could make some intelligent guesses. Next, your Directory Service
Provider (either your own Private Directory Managment Domain, in the case of a
corporate directory, or your Administrative Directory Management provider in the
case of a public directory) would presumably have considerately provided a
number of
aliases for RDNs within the DN. For example, our intellectual property lawyers
may
insist on having O=GTE Laboratories Incorporated spelled out in full, with no
periods or commas. But (hopefully) they would have no particular problem with
aliases such as GTE Laboratories, Inc., GTE Labs, or even GTEL, assuming that
such
uses wouldn't infringe on someone else's name. Likewise, the common name that is
listed as part of my full distinguished name might be Robert Reade Jueneman, but
Robert R. Jueneman, Robert Jueneman, and Bob Jueneman would all be listed as
undistinguished common names as well, along with surname=Jueneman,
givenName=Robert,
and perhaps nickName=Bob. (But _not_ nickName="Dammit, Bob!" -- the string
syntax is
too complicated. :-) And don't ask me what the semantics of givenName and
initials
are, because I think that whoever defined these really botched it. Take J.
Robert
Oppenheimer and Harry S Truman, for example. I don't know whether my initials
are R,
or R.R. or RRJ, or what. But I digress.)
The important point is that the DN in a certificate is supposed to be READ, not
WRITTEN. People see really ugly X.400 OR names (Peter does have a way of rubbing
people's noses in this problem, although he is right), and they conclude that
they
don't want to have anything to do with such monstrosities. But "Joseph F.
Wackerman"
<74071(_dot_)1564(_at_)CompuServe(_dot_)COM>, to name another of my
correspondents, isn't much
better. That's why he is just "Joe" in my personal address directory -- my
computer
is pretty good at looking up things by now.
Bob
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
617/466-2820
Jueneman(_at_)GTE(_dot_)COM