Howdy,
I've been talking privately to a number of people on this list about
these sort of problems for several months now and this looks like as good
a time as any to hop in.
X.500 semantics, functionality, whatever looks pretty good, but the problem
alot of us have is that it really doesn't exist for us to use yet. It doesn't
do me any good to argue about this field or that or how the directory is going
to work. In practicality it's of no use to me. I'm not in any position to
drag it down or condemn the syntax of addressing (I admit to an internet-centric
bias because of years of use) and I hold to the belief that there are
alot of competent people working on bringing X.500 services to me some day.
In the interim, I need another solution. Preferable one that will not
prevent me from switching over to X.500 (whenever). The PEM rfc's are a good
point for me to start. There is nothing in them to force me to have to
rely on directory servers, even though the words exist in the documents.
I need reliable public keys and the PEM certificates (or even the PKCS extended
certificates) give me that. There will be applications that might need
a little more information some need a little less, but there's enough pertinent
information contained in the distinguished name to get started (assuming
I have the proper idea of what a DN is). I need a CA hierarchy, maybe
not with an all powerful top level, but even adaptations like Michael Roe's
PASSWORD project will probable work. Multiple PCA's even within the
government will probable work, and maybe tuneable clients, like what was
discussed earlier will make it easy to not have a top level. But I need
to have alot of code running on the net (ie. use) before I can start seeing
what needs tuning or not. (Call it a learning disability)
I need to move certificates around. Store and forward services like mail
give me a variety of methods to do this that are not dependent on X.500
directory services. But I'd like to have reliable public keys (certificates
actually) for other services. I think I can still use much of the PEM
rfc's to help me along the way here. The problem has been this X.500 names
stuff. I believe keeping the X.509 information in the certificates is
still important.
Internet email addresses are the most prevalent form of identity used
by the Internet community. Stepping a little away from pem-dev the Internet
host identification is the basic form of identification for machines on the
internet. When I send mail to jueneman%wotan(_at_)gte(_dot_)com or
crocker(_at_)tis(_dot_)com
I believe that Bob or Steve are going to get that mail. Similarly when
I point my Web viewer at http://www.ncsa.uiuc.edu/ I'm believe that I'm
connecting to the http daemon at NCSA. Modulo some spoofing and such
there's an agreed upon set of rules to preserve uniqueness of hosts
and on the hosts we have rules to insure uniqueness of users and services.
There's good code out there to help my applications find hosts, and a
collection of rfc's that address this. These rfc's also leave room for
embedding certificates into the domain name space. If I have
everything in place that the PEM rfc's talk about (certificates, CA hierarchy,
and other good stuff) I can take certificates from my CA and tennis shoe
them to a domain server and place them in the TXT fields and use the HS class
instead of the IN class to find these servers (thanks athena!) I've got
a collection of certificates sitting on a machine and this works as fast as
looking up the names of hosts. After all if I'm sending mail to tis.com
or gte.com I still have to find the host.