After reading the recent MIME-PEM draft, I have two questions. I am not
in any way a PEM expert, so please bear with me if these are dumb questions.
Also I'm not on the pem-dev list, so please leave the Cc: above!
1) What is the reason to encapsulate clear-text PEM body parts in an
entity of type message/pem-clear, instead of including the body part
unencapsulated (e.g. as text/plain, but potentially any MIME type)?
The latter would provide better interoperation with MIME-capable UAs
that are not PEM-capable (MIME does not mandate any particular
treatment for unrecognized subtypes of message).
There are two reasons for the addition of this layer:
(1) It makes the structure of mic-clear and encrypted messages match up. While
this is not a real requirement, it is nice thing to have.
(2) It limits the amount of "automatic interoperation" that occurs with
MIME-aware MTAs and gateways.
The important point here is why (2) is a Good Thing and not a Bad Thing.
Unfortunately, the reasoning here requires a fair amount of technical MIME
knowledge, so please bear with me.
When MIME was designed a great deal of work was done on the notion of canonical
forms. (Historical note: Part of this concern comes from the PEM-related
origins of the base64 encoding. A fairly elaborate model for canonicalization
of various formats was initially proposed. This model was too complex and was
eventually replaced by the much simpler model we have now.) I don't want to get
into the specifics here, but associated with each MIME type/subtype is a
canonical form that must be used when an object of the given type is placed in
a MIME body part. The original object data is of course arbitrary, but MIME
specifies one and only one way to canonicalize into what you put into a MIME
body part. I will say that in most cases the canonicalization is trivial. The
fact that it is trivial is nice, but it tends to make canonicalization itself
look trivial. It isn't.
However, the work on canonical forms only went so far -- it only provides
canonical formats for the data inside of atomic MIME bodyparts. The structure
of the MIME information used to encapsulate one or more atomic bodyparts is
tightly specified, but a single canonical form for the encapsulation is not
given. In particular, given the fact that the encapsulation mechanism is
derived from RFC822 headers, the number of ways of expressing the same
information is very large. (No larger than ASN.1's BER allows, perhaps, but we
don't have an equivalent of DER in the RFC822 world and I shudder to think of
how difficult it would be to create an equivalent.)
This is a big problem as far as PEM is concerned. MIME software was and is
designed to make use (and more important, play games with) all that nice MIME
structuring information. This includes not only UAs but also gateways. For
example, consider the case of a multipart MIC-CLEAR message where one or more
parts contain 8-bit data and no encoding was used. Let's further suppose that
this message encounters an non-PEM-aware MTA that needs to downgrade the
message to 7-bit. According to the current specifications, doing this involves
getting inside of the MIC-CLEAR content and changing the
Content-Transfer-Encoding headers. This transformation is NOT invertible down
to the character-by-character level. (E.g when the encoding is removed what
case is the "8BIT" atom supposed to be in? And so on.) And so the MIC will fail
once the message reaches its destination.
You may say that the 8bit stuff had no business going out unencoded to begin
with. But this is only an example -- the point is that MTAs and more
importantly gateways can and do have occasion to get inside of multipart
objects. The data is always kept safe (the MTA or gateway is broken if it
butchers the data) but the additional requirement of keeping all the headers
and encapsulation intact isn't met. (Take a look at what the MIME-MHS
specification does with multipart/whatever -- entire headers and of course
specific boundary markers are abandoned, the contents of certain types of parts
are translated in an uninvertible way, and so forth. I don't think expecting
MIME-PEM to survive a transfer across X.400 is at all unreasonable.)
A non-PEM-aware MTA has no way of knowing that the first part of a
multipart/pem has to be handled specially. MIME is quite specific on this
point: it says that all multipart/foo things you don't recognize are to be
treated as multipart/mixed. This in turn means that when MTAs have to get
inside the encapsulation and do something they will do just that. And the
results will be disasterous as far as PEM is concerned.
Now, let's be clear that we're not asking for much -- what we're asking for is
that all agents treat the contents of the first subpart of multipart/foo as an
atomic part with no visible structure. It has to be transfer-encoded,
transfer-decoded, split into pieces and reconstructed, or whatever as an
untransformable unit. The ONLY exception is when the part is viewed.
I know of only two ways we can associate this information with the first part:
(1) We can add special semantics to multipart/pem or (2) We can add an extra
level of encapsulation.
I had hopes that the new version of MIME would change the semantics of
multipart/foo; in particular, the multipart/header-set proposal has some real
appeal and would solve this problem for us. But none of these changes made it
into the draft standard revision (mostly for procedural reasons), and moreover
I came to realize that there's a significant MIME deployment out there that
works according to RFC1341 already. This means that we cannot attach
additional semantics to multipart/pem. So we're left with using an additional
level of encapsulation. And thus was message/pem-clear born. MIME says nothing
about any sort of default handling for message/foo parts; moreover there's
enough variability among the initially defined message subtypes that it is
clear that only message/rfc822 can be treated as having visible internal
structure.
I therefore added the message/pem-clear layer to solve this set of problems. I
agree that it does have the disadvantage of making MIME-PEM a little more
opaque to MIME readers as well. But is this that big of a deal? MIME is
modular; most MIME readers are modular too. Adding a facility that makes
message/pem-clear equivalent to message/rfc822 is easy in all the readers I'm
familiar with.
Incidentally, I've been worrying about all this ever since the MIME-PEM
document was first written. I have wanted to discuss this issue at the last two
PEM WG meetings, but I have been prevented from doing so because of other
discussions taking up all the time. I don't mean to say that the discussion
that did take place was useless, but if the PEM WG wants to deal with the
substantive technical issues in the MIME-PEM document some time is going to
have to be allocated to do it.
2) What is the reason for the "privacy" parameter to multipart/pem?
Doesn't it follow from the type of the first subpart and/or the
application/pem subpart?
Yes it does. If we retain message/pem-clear encapsulation I'll remove the
privacy parameter from multpart/pem. Sorry I missed this; I don't like
duplication of information that can only lead to silly states.
3) Would a non-MIME PEM-capable user agent be able to recognize MIME-encoded
PEM messages? Is it at all possible to achieve this?
Making a non-MIME PEM-aware reader handle the PEM aspects of MIME-PEM is fairly
easy. Greg has been arguing this point for quite a while; thus far I have
heard nobody stand up and contradict him. It isn't automatic by any
means, but it is easy. (Lots of code is available to assist in this area.)
However, such a reader can then only deal with PEM-izing and unPEM-izing MIME
messages; the actual MIME content may or may not make much sense. You clearly
cannot handle the full range of MIME without having some significant MIME
smarts.
For this reason, and also because MIME is deploying a lot quicker than PEM is,
I think the more important question is how hard is fitting PEM capabilities
into a MIME reader. This turns out to be pretty easy given the fact that MIME
is so modular and therefore most MIME readers can be extended in a modular
fashion.
Ned