If PEM is a MIME sub-type, and is carried through a series of
MIME-conscious MTAs, will the arrival of the message at a PEM-
capable User Agent allow the encrypted part to be handled properly?
Yes. This is an extra advantage that I didn't mention in my original note,
mostly because it is not my primary area of concern. But it is definitely true
that the addition of the header information makes it much easier for a MIME
UA to handle PEM messages.
Most MIME UAs use Content-Type information to decide how to display messages.
The most general of them use a table that specifies an appropriate filter
to invoke. In the case of message/pem, the filter would be some kind of
PEM facility that reads the PEM information.
In other words, the presence of this headers makes it trivial to integrate
PEM facilties into MIME UAs.
Will anyone be confused by the addressee information which is
contained in PEM in plaintext (but authenticable) form?
The Content-Type of message/pem explicitly tells MIME-aware agents that there's
something here that requires appropriate handling (this is generally true of
all MIME types; there's nothing special about this type). The use of
plaintext or encoded text isn't part of this decision.
Most reasonable MIME UAs, when faced with a type they don't grok, will say
something like "this isn't something I know, want to just look at it as text".
The user can then display the message, and if its in plaintext form that's all
to the good. If it isn't then the user gets a facefull of encoded jabber, which
is harmless. But in either case the user is aware that this is something
special that requires some type of appropriate handling.
Finally, for my own edification - feel free to respond only to
me - is there any architectural value in actually trying to
make it possible to encapsulate MIME in PEM and vice versa,
rather than picking one of the two as the normal mode?
There are definite advantages of having PEM facilities available at the MIME
per-part level (PEM in MIME). You get some of this already with my proposal,
but the integration isn't as tight and clean as it can or should be.
Carrying an entire MIME message in PEM (MIME in PEM) is also essential,
however. For one thing, there's a big problem with PEM-izing each MIME part
separately -- you aren't protected against certain kinds of tampering like
deletion of a entire part of a message. This is an interesting point
philosophically, since when you combine it with the nonrepudiation of origin
facilities PEM provides you end up with what amounts to an irrefutable quote
out of context!
The structure of the entire message is also visible when you use per-part-PEM,
which may represent an unacceptable exposure in some cases. (Traffic analysis,
while not a topic directly addressed by PEM, is nevertheless made simpler by
this structural exposure to a perhaps intolerable degree.)
However, in its simplest form MIME in PEM brings back the interoperability
problems that started me on this topic. This can be fixed by using MIME in PEM
in MIME nesting, thus keeping the outermost label MIME-compliant. This could be
done with an Content-Type such as message/pem-mime or whatever, which would
indicates that the entity that has attended to by PEM is itself a MIME object
internally and has a (possibly encrypted and always checksummed) internal MIME
Content-Type header of its own.
In summary, I think both PEM-in-MIME and MIME-in-PEM are needed in some
form. We can get by with PEM-in-MIME for now as a stopgap measure as long
as we plan from the outset to supplant this with a more comprehensive solution
in the future.
Ned