On Fri, 27 Jan 1995 Jueneman(_at_)gte(_dot_)com wrote:
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.
I certainly acknowledge this. What I'm looking for at the moment is not
"free" in terms of cost, but free in terms of "can I pull it apart to see
what makes it tick?". X.500 is to me a complete mystery. Why? Because
the damn standards are not available freely on the Internet in a usable
form and I'd rather not pay the highway robbery prices that Standards
Australia is asking for them. Even if I did have them, I'd still want to
see inside at least one other product to make sure I'm doing things right.
Thanks for the suggestions. I do admit that I have a big aversion to
using other people's code, especially commercial code. Regardless, I'm
still unconvinced that we should be wiring ourselves into X.500 and only
X.500. Other directory systems exist and an X.500-only PEM strategy will
limit people's ability to choose what directory system they want to use.
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!
What if I not only wrote up the RFC, but also produced a freeware
implementation of it at the same time? What if it could be installed in
under a day by even the dumbest of system administrators? What if
(horrors) it solved the problems now rather than later? What if it didn't
rely upon any particular user-discovery protocol by sat on top of all of
them?
You'd hate it, I know, because "it ain't X.500". But since you aren't
writing PEM implementations, your opinion doesn't count. Sorry, but
them's the breaks. I haven't heard from any other PEM implementors yet
as to what they think of my proposal.
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.
I didn't take up your offer because (a) I believe using an X.500 server
to be overkill, and (b) I want to set up my own server, not use yours. I
can't speak for the others.
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.
While you are right that the security of certificates should not depend on
the security of the protocol, there are other issues. When a user
contacts a CA, how do they know it is the right one and not a pseudo-CA
that they've been pointed at by a cracker? What provides the mapping
between "CA with DN x" and "contact host h and port p"? If a CA provides
a referral to another CA (i.e. "I don't have it, but you can get it over
there"), how does the user trust this referral?
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.
I probably will try out a few systems, but I'm not hopeful in the least.
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?
You got the rabbits because the kangaroo meat was not encoded in ASN.1.
It was a flat ASCII file with easy to understand labels that didn't
require buying 600 standards documents to find the right object identifier
for kangaroo meat. It still worked because kangaroo meat is pretty tough
stuff and will get through any broken software and mistaken assumption. :-)
Q. What do you call a boomerang that doesn't return?
A. A stick.
Ha ha. I must have heard that one a million times. :-)
Cheers,
Rhys.
--
Rhys Weatherley, Queensland University of Technology, Brisbane, Australia.
E-mail: rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au "net.maturity is knowing
when NOT to followup"