Rhy, you've made some interesting points, and if I were in the product
development business I might have more answers for you. However, even if I
were, I'm not sure that you would like them, because I would certainly not be
handing out those solutions for free.
I understand the grand tradition of a "free" Internet -- free in the sense that
someone else pays for the connectivity, taxpayers and students pay for the
University grants to write a lot of the software, many people donate software
as freeware, etc. But the Internet is very rapidly evolving beyond that, and
now includes millions of PCs and Macintoshes sitting behind corporate LANs, and
those people expect professional quality software AND ARE WILLING TO PAY FOR
IT.
This will of course reveal a significant difference in opinion and approach
between the two of us, but I don't give a two hoots in hell if there is free
source code available for any of the functions that you have mentioned,
although I understand that you may have completely different needs. I think it
is sufficient to point to existing commercial products that will do what you
want, with or without a little tweaking. I'll name some that I think come
close, but I don't mean to denigrate any others. In other words, this is an
existance proof, and admittedly some of the finer details may not be filled in
yet.
I don't react well to theoretical arguments of a system's capability. To
convince me of X.500's worth in storing certificates, Bob or Warwick or
someone will have to produce the following:
(a) Example C source code for linking into my application which will
search for and retrieve a certificate based on at least the e-mail
address. Other search criteria are a bonus. LDAP is probably the
best protocol to use for this, but anything else that is simple
and works over TCP/IP will be fine. Don't worry about users without
TCP/IP just yet: we'll worry about gateways afterwards.
There are a number of DAP and LDAP clients available, some of which are public
domain. We are using DEC's InfoBroker product, which can support retrieval from
a private e-mail database and/or be intergrated with X.500. The version 1
product included a pretty good Windows client, but their next release will
abandon that in favor of using a generic WWW interface to their DUA server. The
folks at the Univ. of Michigan have gone the same way, as has the Univ. of
Texas (both of which have on the order of 80 to 100K users). Most of these
products also include an API, so you can add your hooks to your application.
(b) Source code for a TCP/IP based X.500 server that I can install right
now and have my name and certificate set up in under one day and have
it made available to the rest of the world in under a week. Note:
I don't want to put my key on GTE's server Bob. I want to put it
on _my_ server, under my own local administration policies.
The ISODE QUIPU program is suitable for small to medium-sized installations,
and is available public domain. The ISODE consortium is also developing a more
bullet-proof commercial version. Mark Wahl could undoubtedly provide you with
further references. We brought up a version using X-windows on a PC and had a
pretty slick demo running in relatively short time -- maybe not a week, but
less than a month.
(c) Source code for a CA user interface for the X.500 server. That is,
a program which would allow the person running a CA to perform
general housekeeping tasks, sign keys, issue CRL's, etc.
There are several issues here, and presumably three steps:
1. Generate the user's certificate. Most PEM implementations provide some kind
of a mechanism for this function, some more awkward than others.
2. Get the certificate signed by a CA. Depending on the application, this may
have to take place in person, in from of the CA, so that the binding of the
identity to the key can be assured. RSA sells their Certificate Issuing
System, but it is probably too expensive for your application. I assume that
TIS and Jeff SChiller at MIT have similar software-based systems, and
presumably Sead Muftic at the COST consortium as well. You may have some
export-control issues to deal with, so this may be a slightly more difficult
problem for you than it would be here in the US or Canada. I can't help you
much there.
3. Deposit the certificate in an X.500 system. Bell Northern Research has a
system called Entrust which is supposed to to this and more. I'm in the process
or ordiering one, and I'm sure that Warwick would be happy to send you some
literature!
(d) Source code for the act of a user sending their key to a CA to have
it signed. Note: I want a TCP/IP protocol for this. Not some
grungy e-mail interface.
This assumes a particular policy that may not be sufficiently universal,
although it may meet your needs. Grunginess is in the eye of the beholder, but
given all the wonderful capabilities of PEM/MIME, I would certainly have lots
better things to do that to develop a new TCP/IP protocol, write up an RFC, get
it approved and standardized, go through all this wrangling, etc. Masochism is
greatly overrated!
Maybe this stuff exists. URL's please. But don't expect me to write it
without someone else's code to look at to see if I'm doing it right. The
day I can get a program from you, type in an e-mail address, and it returns
me a certificiate is the day I'll be dancing in the streets about X.500.
Put it this way Bob: "Put your money where your mouth is and show us that
it can work. Stop theorising." Sure, there are some tough problems as to
what search criteria to use, but if you focus too hard on them, you won't
get anywhere. Do something simple first, write the code for it, and then
start adding extra bits and pieces later.
Sorry, but I'm not a product developer, and have no intention of becoming one.
There are a sufficient number of people who ARE in the product development
pubiness, and as soon as a product in this area become available, I buy it and
evaluate it. What I _am_ trying to do is to develop those nasty search criteria
that you mentioned, drum up some support from other potential X.500 service
providers and users, including PRDMD operators, and achieve a concensus as to
how to operate such a system on a multiple-provider international basis. I once
offered to bring up an X.500 server for this purpose on a no-cost trial basis
that you would have been free to use, but I got no takers. If you insist on
getting _everything_ for free, and/or writing it all yourself, then I'm afraid
I can't help you.
In any case, I stand by my assertion that using X.500 or whois or whatever
to do certificate management is not the best option. It has nothing to do
with search criteria or e-mail addresses or hatred of X.500 or whatever.
It has to do with security. The CA management tasks alluded to in (c)
and (d) require quite a lot of thought of how to do them right to prevent
spoofing. Instead of bolting this onto an already complex directory system,
I suggest using a simpler protocol which is easier to verify secure and is
not dependent on a single view of the "find a user" problem.
I'l agree that with version 1 certificates, the issues of directory DNs and
certificates DNs are badly entangled and confused, and therefore the CA
administration and directory administration people might have to work together
more than might otherwise be desirable. I believe that v3 will completely solve
that problem. But if the security of the system depends in any way of the
certificate distribution mechanism, whether X.500 or something else, then we
have failed completely. We _certainly_ should not be depending on a secure
protocol.
Rather than "bolting" the CA managment problem onto a complex directory system,
I view the two problems as completely separate issues. CA administration and
CRL creation is something that has to be done regardless of how the
certificates are distributed, even if they are distributed by including them in
all outgoing messages to be cached by the recipient. Its even possible that
neither the originator nor the CA have an X.500 facility available to them, but
the recipient does. In that case the recipient mqy choose to deposit the
certificate in an X.500 system himself, making them available at least locally
if not globally.
Maybe what I should do is design a protocol and post it here as a draft.
Then Bob, you are free to point out whether X.500 is capable of what I
think we need to make CA's truly viable within a finite timeframe.
Even if you conclude that the existing systems are all fatally flawed, would
cost too much for all your users to buy, or you could do a much better job
yourself, I think that you owe it to yourself to try some of these already
existing products and systems and discover their strengths and weaknesses
before you conclude that something else is required.
Regards,
Bob
P.S. Thanks for the delicious kangaroo meat. All I had to do was to code up a
MIME viewer that understood the ASN.1 for kangaroo DNA, reconstitute it a la
Jurassic Park, add water, and stir. Fortunately I had the assistance of one of
those 14 year old geeks from the movies that can write whole new operating
systems in only dozen keystrokes, and it ran perfectly the first time. There
was one side effect, however -- what I can do to get rid of these damned
rabbits that are now all over the place?
Q. What do you call a boomerang that doesn't return?
A. A stick.
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820