Mark,
Let me chime in here. You and I have had at least a portion of this
discussion. I found the discussion useful before. I believe it
had the right effect, although perhaps not everything you would wish.
Let me respond to some of the points you make.
Yes, I send plain ASCII messages, but I am also committed to MIME
and *all* my outgoing messages are in MIME format. The great
majority of them are, of course, single-segment messages of type
TEXT/PLAIN (not all are in US-ASCII charset though).
So, interaction with MIME is a requirement for me. I can't have
two parallel efforts, one supporting PEM, the other MIME. One or
the other has to give way. For a number of reasons, MIME won.
Also, there seems to be some indifference on the part of PEM to
distributed processing of mail. The suggestions I've heard for
MIMEifying PEM tend to be of the form of putting a PEM wrapper over
a MIME message. This, to me, seems to be backwards. I see a
message as a collection of objects, each of which may have its own
authentication/privacy status, bundled together under the auspices
of MIME. If any message-wide authentication/privacy is done, it
should be of the MIME bundle and not of the data within the
bundles.
As you're probably aware, Ned Freed, Marshall Rose and I have a draft
specification for the integration of PEM with MIME. Let me call this
MIME-with-PEM for purposes of discussion. MIME-with-PEM permits
authentication and/or encryption at all levels of a message. This is
a necessary capability. In the case of a compound message, i.e. a
message with multiple parts, it will be the *sender* who chooses
whether to apply authentication and/or encryption to some or all of
the parts and/or to the entire message. In some cases, this will mean
that the user will receive a message in which authentication and/or
encryption is applied to the entire message.
There really isn't any easy way around this effect. There is a
legitimate and useful interpretation for every possible combination.
For particular scenarios, it may be desirable to steer the users
toward signing individual body parts instead of an overall message,
but that cannot be a rule that's imposed on the entire design.
Having said all that, there is one important design goal that we have
adopted within the MIME-with-PEM specification. In the case of
authentication, we want the interior structure of the message to be
visible and parseable even if the authenticity and integrity are not
checked. That is, if someone sends you a compound message which is
signed on the outside, you will be able to read the components without
checking the signature of the entire message. Of course, this means
there's a security vulnerability, but transparency seems worth the
risk. The same idea does not -- and should not -- apply to encrypted
messages. If I send you an encrypted message, you'll have to decrypt
it before you can see any portion of the interior.
Let me explain the reason why. Suppose you are using a remote
server e-mail architecture; I'm thinking especially of IMAP but
these arguments are equally valid for DMSP, NNTP, and to a lesser
extent POP. In the brave new world of MIME you can have relatively
large messages with many attachments; additionally, some of the
attachments may be external to the message.
MIME is a lot of great things, but one thing it isn't is easy to
parse on machines with limited resources such as PC's. I have
written MIME parsing code for a PC, but it is quite slow compared
to the parsing code that can run on a Unix machine with adequate
memory.
Here's what ties these two strings together: suppose the remote
server took on part of the overhead. Specifically, suppose it
parsed the MIME structure so that the client already had a parse
tree of the message, without actually having received any part of
the message itself. Now, add to this supposition a capability
retrieve specific MIME segments of the message, using the parse
tree as guidance, without necessarily having to retrieve any other
part of the message.
The attractiveness of this for small machines such as PC's or Mac's
is obvious. Less obvious, but still important, is the
attractiveness of this for machines which sit behind relatively low
bandwidth links (e.g. V.32b/V42b SLIP links). This isn't just
pie-in-the-sky dreaming. It's existing, deployed technology.
The indifference of the present form of PEM to MIME takes a serious
toll here. If a MIMEgram must be encapsulated within PEM in its
entirety, a distributed system engineer is faced with the choice of
doing the de-PEM step in the server -- thus subjecting the
plaintext to interception or alteration -- or of downloading the
whole thing to the client and forcing it to do both the de-PEM and
de-MIME steps. Note that we've established that de-MIMEing may be
unacceptably expensive for a small machine; yet now we're adding an
extra burden.
As noted above, nothing forces the sender to encapsulate the entire
message, but nothing prevents the sender from doing so. If the sender
does encapsulate the entire message -- and particularly if the sender
encrypts the entire message -- then the entire message has to be
processed to undo the enchancements. In your model, one possibility
is to have the server be trusted with the user's private key. It can
then handle any verification or encryption. If you don't want to
trust the server with the private key -- which is probably the safest
idea -- then you really don't have much choice. This is not a
question of hostility toward the client-server model; this is a
fundamental limitation in the client-server model with the assumption
that the server is untrusted.
I'm afraid that until there is some better attention on the part of
PEM to MIME -- and to the needs of distributed architecture -- PEM
isn't going to be useful in my community. PEM would have been
great back in 1989. The problem is, PEM has been delayed for a
long time and the e-mail community has moved beyond the
infrastructure that PEM covers.
I understand and sympathize greatly with the desire to get any
version of PEM out rather than have it drag on forever. PEM has
suffered enough with charges of being vapor (albeit from sources we
can ignore). However, I don't see how this version helps.
As an implementor, I see this version of PEM as being offered in
direct competition to MIME, to the detriment of both. Yet I'm
sympathetic to both. If I contrive to acquire this viewpoint, it
does not take a PhD in psychology to envision what other, less
sympathetic, implementors will think. If a ``MIME vs PEM'' fight
develops, I would have to lobby on behalf of MIME and against PEM
as a matter of self-preservation.
There really isn't a MIME vs PEM fight in progress. Integration of
PEM with MIME is an extremely high priority activity. It's the
central effort within the PEM WG, and it's high on our implementation
agenda.
Please consider the strong negative impact that a non-MIME version
of PEM may have on the e-mail community in general, and on the
large and growing MIME community in particular. MIME has become a
fundamental part of e-mail for this community; it is not ``just'' a
multi-media mail format.
I think you're proposing that anything, PEM or anything else, that
isn't embedded in MIME is harmful. I think that goes too far. MIME
is a very good thing, and I believe it is succeeding nicely. It
doesn't need to be aided by holding back other efforts. In order for
MIME to completely dominate the e-mail ecology, it just has to be
better than everything else and occupy its niche for the right length
of time.
What I would like to see is a fully integrated PEM as a layer on
top of MIME. Although ``MESSAGE/PEM'' as a content type is an
attractive kludge, it does not deal with the distributed processing
problem I've outlined above. I would like to continue to
distribute processing as before, but without compromising any PEM
integrity or putting a burdensome processing load on clients that
are inadequate to the task. That is, I would like to see PEM
encoding of a MIME structure tree. This requires quite a bit more
intelligence in PEM than merely treating a message as plain ASCII.
Hmm... I'm not sure I understand this proposal. I suspect I disagree,
but I'm certainly willing to listen. How about fleshing this out in
the style of the current I-D so we can see the specific alternative
you have in mind?
These are not new viewpoints; I've stated them before. The more
time passes, the more alarmed I'm becoming at the prospect that
we're seeing PEM become a solution for the previous decade's
problems. Please consider these points. I hope it wasn't too
inflammatory.
Actually, you're assuming PEM solves problems in a neat and clean way.
Spend some time looking at the export issues and at the U.S.
Government's insistence on alternate algorithms and you may find the
MIME integration issue is small potatoes.
Steve