John,
I have to disgaree with you absolutley on the the proposal of dropping
X.500 from CAs. Firstly you assertion that X.500 is addressing a niche
market shows that you apparently have little exposure to what folks are
doing with X.500 today and are planning to do with it. You should look
carefully at X.500. At its heart X.500 is a database engine that
supports very high speed searches using a hierarchical naming scheme.
It does not intrinisically have anything to do with email. The fact
that it was developed in the email(X.400) world does not mean that it
has to be used there. I have seen many non-email uses of X.500 ranging
from various directories to inventory to bill of materials and I am
talking about production systems not theoretical systems. It is also a
key candidate for applications such as license management and software
distribution.
Secondly most of the customers(including major banks and telcos) I have
discussed Certificate Authorities with are interested in using X.500 as
the storage mechanism and X.509 for authentication and certifcates. You
seem to not have thought through some of the advantages of using an
existing technology that provides many of the key underlying services
such as the shadowing/replication features and distributed database you
would need in a robust commercial implementation of a Certificate
Authority. Virtually everybody I have had personal contact with on this
subject expects X.509 Certificates to be used as one of the key
standards for Certificates. In fact one of the most common requests we
have for our X.500 product is to add X.509 certificate support.
You also state that trusted directories are needed. Well, if you use
certicates and you have CAs verifying them, then you know that the
certifcate signed document comes from a given user and you do not care
about the directory being trusted. Relying on the directory being
trusted is not a good way to ensure non-rupdiation which is what you
ultimately want.
Your case for dropping X.500/X.509 is not a good one in my opinion. Use
of X.500/X.509 should be discussed more fully than just dropping it
willy nilly. I aslo disagree that X.500 is fundamentally not suitable
for use on the Internet as you imply. I believe many folks are
seriously considering using it a the core directoy for their Internet
usage.
Regards
Chris Crafford
The opions expressed here are mine and do not necessarily reflect the
opinions of Tandem Compputers Inc.
------------ ORIGINAL ATTACHMENT --------
SENT 07-20-95 FROM SMTPGATE (gnu(_at_)toad(_dot_)com)
If we are considering changing the certificate mechanisms, I'd like to
open the question of whether X.509 certificates should even be used in
future key-certification systems.
It's clear that the X.400/X.500 architecture for electronic mail has
only a niche future. There is no inherent reason to use it on the
Internet except that "it was there when we needed certificates". But
its addressing mechanisms are cumbersome for use on the Internet, and
integrate very poorly with current and proposed Internet standards for
electronic mail, communications security, and commerce. Some of the
delay in creation and deployment of badly needed cryptographic
standards such as secure DNS and PEM was caused by trying to integrate
these unwieldy addresses (because of the lack of a developed
alternative more suitable to use on the Internet).
Basically, X.509 certificates, as currently understood and deployed,
require a complete dictionary-based one-to-one mapping between
Internet protocol elements (such a email addresses or host addresses)
and X.500 addresses. This lack of integration makes their use
cumbersome -- not only in the development of applications and
infrastructure, but all the way into the daily interface of end-users.
It requires that end-users maintain trusted directories in order to do
the simplest operation, such as determining whether an email message
is from the person it purports to be from.
There are clearly lessons we can take from the X.509 experience, but I
believe that we should learn those lessons and use the experience to
design a mechanism that works well on the Internet. Now, when we are
considering a revision of the technical certificate structure, and
before widespread deployment of ANY digital signature system, is the
time to do it right. Failure to seize this opportunity will result in
key certification remaining needlessly complex and error-prone
throughout the remaining lifetime of the Internet.
--
John Gilmore gnu(_at_)toad(_dot_)com --
gnu(_at_)eff(_dot_)org