Rhys and Steve,
Well, as the diplomats say, we have had a "frank and candid"
exchange of views. Actually, despite the length of the discussion,
I think we may be getting somewhere. Lets see if we can find
some points in common.
I liked Rhys' summary of "What does Bob dream about when he
thinks of PEM?" He reasonably accurately captured my notion of
how the system ought to work.
I also liked and accept his summary of how "real-world," aka Unix
UA's, does work.
(I have to confess that I have a very strong aversion to Unix, hate to
use it and don't need to in my work, and would move to a Mac before
I would even consider a Unix implementation without a good GUI.
As a result, I have limited experience with products such as MH
that may be lingua franca for the rest of the community. That is
also why I am not yet using TIS-PEM -- for me, it is on an
unacceptable software platform. In fact, the primary reason that PEM
has not yet caught on significantly MAY be that the users who have the
requirements for digital signatures and encryption are not likely to
be Unix users. What the world is waiting for, IMHO, is a decent
shrink-wrapped product that will run under Windows or on the Mac.
I'd even accept a Windows NT version, if NT just supported Adobe
Type Manager and PostScript. I'm looking forward to what Sead Muftic
is developing at COST, and I hear interesting rumors about Lotus Notes
and MicroSoft Mail.)
(As far as I'm concerned, the integration of TIS-PEM with MH made it
worse, not better. If it were just a simple compute-only filter, maybe I
could get it to run under DOS at first, and later integrate it with
a drag-and-drop Windows interface to a mailer. I may do exactly that
with RIPEM, which is still a relatively ugly character-line interface, but
seems to be simpler to use. And there are DOS, Windows NT, and Mac
versions available.)
So back to the "real" world. Rhys' point, which is well taken, is that
to bootstrap our way into using PEM, we need "bolt-on" postprocessors
(for outgoing mail, preprocessors for incoming mail) that will work with
a minimum of human intervention. Presumably the message would just
be piped back and forth, with little if any real integration.
I had thought that the PEM implementations would automatically cache
incoming certificates, as they are required to do for incoming CRLs. And
because my mind-set is somewhat more focussed on validating signatures
rather than on encrypting outgoing messages, I was assuming that such
an automatic cache would solve the problem transparently. I didn't
really care what kind of a cache was used -- just stick it somewhere, and
retrieve it when you need it. For example, hash the subject name any way
you like, and use the hash as an index to a conventional table lookup.
Now, finally, the light dawns. Sorry it has taken so long. The question is,
how does the dumb-as-a-rock post-processor find the appropriate
certificate to be used for encrypting the outbound message, given
only the outbound message itself?
Well, the obvious thing to do would be to use the e-mail name in the
To: or Cc: field to look up the certificate, I suppose, and then present
it to the user for his approval.
If this is a really dumb process, it means that I have to be pretty
careful in my choice of e-mail names, so that I refer to users consistently.
So I would have to say "Mr Rhys Weatherley
<rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au>"
consistently, and I couldn't use a local alias, or "Weatherley, Rhys"
<rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au>, and if his administrator were to
allow him to
create an alias of Weatherly(_at_)qut(_dot_)edu(_dot_)au, I couldn't use that
either.
With a little more intelligence, I suppose the postprocessor could browse
around a little until it found an approximate match, and then present that.
Evan a simple soundex search search could be implemented, so that if
I said To: Rhesus Weatherley, it would still have a chance of finding
an approximate match, even it thought I was referring to a monkey. :-)
So the issues seems to be (1) how to extract something about the user
from an incoming message, (2) how to be reasonably sure that the
"something" really represented that user, and (3) how to refer to that
"something" within outbound messages.
I see the point that since my unmodified mailer is going to have to
include the user's e-mail address anyway, why not extract "something",
i.e., part or all of the e-mail address from the incoming message, file
the certificate under that "something" (or perhaps a hashed equivalent),
and then extract that "something" from the outgoing message again on the
way out.
What should that "something" be? If we extract it from the From:
address, we might get awkwardness like Jueneman%wotan(_at_)gte(_dot_)com,
since the to and from portions may be modified en route. Perhaps
the Reply-To: portion is less likely to be modified, but that can't
be guaranteed either. If I send mail to the NADF exploder, both the
From: and Reply-To: addresses are replaced with the address of the
exploder, and the only place my name appears is in parentheses
after the From: portion.
The fact that such things can occur is an excellent reason why the
"something" that is extracted should come from the certificate itself,
of course, which addresses my points 1 and 2 above. And I'll agree
that we would rather not have to add (and type) hacks such as
X-PEM-DN:c=US,o="GTE Laboratories Incorporated",CN="Robert R. Jueneman"
(or the reverse, in little endian format) in order to be able to find the
correct information in the outgoing message.
But do I really have to include the entire e-mail address? And in particular,
do I have to break it down into its constitutent parts using
domainComponent's in order to make this work? This seems so
awkward that I am searching for a way to avoid it.
Thinking out loud now, couldn't we adopt the convention that users
include the common name of the addressee within quotes proceding the
complete e-mail name, and that that common name be used as the index
to find the certificate?
For example, Sead Muftic recently sent three messages to me in
a row. Two had an address of muftic(_at_)guest(_dot_)surfnet(_dot_)nl and one
was
"Sead Muftic" <sead(_at_)dsv(_dot_)su(_dot_)se>. Although there might be two
Sead
Muftics in the world, wouldn't it be sufficient to merely extract the
common name "Sead Muftic" from the certificate, and include
"Sead Muftic" (or perhaps for search purposes, "Muftic, Sead")
on the way out? If we are really paranoid about collisions, the
postprocessor could check to see if there were multiple common
names with the different certificates. With this technique, it wouldn't
matter which e-mail address the reply was to be sent to - the same
certificate would be used in either case.
Surely even Unix UAs can support an address book where the user's
name can be listed, and a format like
"Jueneman, Robert R." <Jueneman(_at_)gte(_dot_)com> can be supported.
This would make it easy to strip off the name within quotes,
turn around the name presentation order, and match it with the CN in the
certificate. for that matter, enter the CN in reverse order in the certificate
and the solution is even easier.
This message is long enough, and I want to make sure my own mailer
will support this style, so I'll respond to some of the other points
subsequently.
Bob