From: Jueneman(_at_)gte(_dot_)com
Date: Tue, 12 Jul 94 19:09:29 +5
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.
So your thesis is that you can't really deploy a system using DN's
unless there is X.500 directory support available. Is this correct?
- Te
No, certainly not. But let's differentiate between the two possible uses. of
DNs.
I might tend to agree that X.400, and particularly the X.400 style OR names, is
particularly user unfriendly, and without a directory would be a real pain to
use.
(But since I have never seen any particular utility to X.400 in general, and
since
the X.400 security concepts in particular seem totally useless and
unimplementable,
that doesn't strike me as too great a loss.)
What we were talking about (I think) was the use of DNs in a X.509 certificate.
And
clearly, there are alternative means available for distributing such
certificates,
just as there are for distributing the e-mail routing information.
Perhaps some of the confusion in general (not necessarily on your part) has been
caused by the apparent similarity of the DN that is used for X.400 addressing
and
the DN that is part of the X.509 certificate. In fact, they have relatively
little
to do with each other. It is certainly possible, and I would say highly likely,
that
SMTP e-mail names (or CC:mail names, or Lotus Notes names, etc.) will continue
to be
used for e-mail addressing, for despite the international cooperation of a
number of
monoply PTTs is putting together X.400, it really fails to adequately address
real
world needs, and therefore has failed to take off.
So it is perfectly acceptable to use conventional Internet names or whatever
else is
necessary for mail ROUTING, and to use some different form of globally
unambiguous
name structure for the purpose of providing whatever information about a person
is
considered socially redeeming, within the X.509 certificate.
It would certainly be convenient to have access to an X.500 directory, complete
with
at least drag-and-drop integration with a mail UA and PEM UA, in order to
retrieve
both cetificates and whatever form of e-mail address is used, but this isn't
_necessary_. My point is that no one will ever be required to type in an entire
certificate, and that therefore the format of the DN within the certificate
should
not be of any great concern. If nothing better exists, then file each
certificate
under your own favorite UNIX, Mac, or DOS file format name, and just INCLUDE it
when
it comes time to create a message. Crude and ugly, but workable.
Again, the problem seems to be that we associated encryption and signatures all
too
closely with mail, and that context brings in all sorts of unnecessary baggage.
To
use your example, suppose I had a PEM encrypted and signed FAX capability (ASCII
text oly for the moment -- I don't want to deal with signing graphic images for
now). All that I need to send that FAX is the recipient's telephone number, and
assuming the country code is included that number will be globally unambiguous.
But
I would still need to somehow identity the person I want to have read it, and
if I
sign it he needs to know who I claim to be, so that he can validate that
identity to
whatever degree he feels necessary.
Bob
Bob
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
617/466-2820
Jueneman(_at_)GTE(_dot_)COM