Bob posts a long reply on my draft. I'll go into it in more detail
later, but maybe it would be good to talk tech for a while, so that I can
point out where Steve and I are coming from and why we feel that this
proposal is necessary.
Let's first ask: "What is the ideal PEM-compliant UA?", or more
specifically, "What does Bob dream about when he thinks of PEM?". :-)
The ideal user agent (IMHO) would work thusly: when a user wishes to send
an e-mail message, they fire up their directory searching tools to look
for the e-mail address and certificate. They would present some
criteria, usually the name, and get back the required information.
Whether this directory is a full X.500 distributed one, or (more likely
in the short term) a name/certificate cache kept by the user locally,
that doesn't concern us here. Once they have the required information,
they will compose the message, add the required enhancements, and send it
off. Beautiful, elegant, just the thing, etc.
Let's now ask: "What does a current UA look like, and how can I add PEM
to it?". Current user agents ask for e-mail addresses, or in some cases
aliases which are looked up in an address book or .mailrc file. The
message is then composed and sent off. The easiest way to add PEM to
something like this is to put a couple of lines of code in the final
message submission routine to pass it to a third-party PEM program to
apply enhancements. At the message submission stage, all that the
third-party program has to work with is e-mail addresses. No friendly
names, no directory, zip.
To bring current UA's up to the "ideal" level would require a redesign of
the entire message composition and reply process. First of all, the
current address book facility would need to be replaced with a much
smarter directory or cache facility. Then, the entire post-processing
phase that occurs after message editing would need a complete re-write to
perform PEM enhancements.
This is one reason why having a correspondence between e-mail addresses
and DN's is very handy: PEM support can be bolted onto existing UA's very
quickly. Then, over time the rest of the program can be redesigned.
As an example of this "bolt on" philosophy, look at MIME. Originally,
there were two main MIME systems: Andrew (a full GUI environment with all
the ideal MIME features) and metamail (a bolt-on MIME processor that is
probably the worst ever in terms of user interface design). Andrew was
the ideal to which we all aspired in the MIME working group, but metamail
is still the more popular. Nathaniel Borenstein distributed patches for
all of the major existing UA's (usually just a couple of lines of code
were added to each) which made them call metamail for MIME messages.
Instantly, MIME usage mushroomed. Now, we are starting to see UA authors
(Pine, Elm, etc) modifying their products to support MIME in a more ideal
fashion. But, they would never had bothered if metamail had not made
MIME popular in the first place. We'd all still be doing hacks with
uuencode and MIME would be "Nifty, but if only it didn't require full GUI
operation for compliance I might support it".
A similar thing has happened with PGP and RIPEM. They can be bolted onto
existing UA's at the final message submission level and hey presto, instant
PEM support. Both PGP and RIPEM are popular, and both use e-mail addresses
to identify keys. Care to guess why?
Although eventually we will have UA's that support "ideal PEM", they will
be a long time coming. Until that time, e-mail addresses will be the
fundamental identifying string for users that PEM implementations will see.
It's ugly, but it works.
This now leaves us with "How do we associate an e-mail address with a key?".
The easiest way is to cache incoming certificates with the associated
e-mail address. This does have two drawbacks: (a) by the time the PEM
program reads the incoming message, the From and Reply-To headers have
probably been stripped (especially if the UA supports MIME), and (b) without
a signing method to bind an e-mail address strongly to a key, spoofing
could occur.
This is the current state of the game, Bob. Unless you want to volunteer
to redesign and rewrite all existing UA's, we are going to have to find a
way to cope with it.
Putting aside bootstrapping issues for now, we still have my major
concern that PEM is still fundamentally a top-down system that requires
the powers that be to get off their butts before the serfs can
effectively use the system. MIME, PGP, and RIPEM have shown that the
serfs can force the powers that be to get off their butts because those
systems work from the bottom up. The serfs are not generally in a
position to choose the DN that the organisation will use once the powers
that be get off their butts, so they need something else in the
meantime. E-mail addresses are it. Call me radical if you will, but
that's my position.
Cheers,
Rhys.