Re: PEM/mailer integration via MIME

[Ned Freed <[e-mail]>]

> If the question is "how to transport PEM, unambiguously and with minimal
> perturbation to existing protocols, within a MIME-oriented mail system",
> then I believe the title of the answer should be "Procedures for use of
> PEM within a MIME environment", or some such, likely in the form of a
> small standalone document analogous to other recently announced
> Internet-Drafts concerning mapping and downgrading procedures applicable
> at different interfaces between mail system components. Per Ned Freed's
> message, such an answer's content probably includes two headers:

> MIME-Version:
> Content-Type: <application/pem> or <message/pem>

This is essentially what I'm proposing, with one significant difference -- I
feel this should be done by default as part of the initial PEM rollout and not
as an option. As far as I can tell the overhead is minescule, the changes
necessary are trivial, and the benefits are extremely real and tangible.

> As far as I understand MIME, this approach would be workable if what
> followed were a PEM message with structure as defined in
> draft-ietf-pem-msgproc-02.  I recall resistance to this approach in
> earlier discussion, since this could result in data which was already
> encoded for PEM being re-encoded in the course of MIME processing, a
> result perceived as not only inefficient (which would  be the case, but
> would be manifested only in certain environments) but also Intolerably
> Evil (which seems an overstatement).

Use of encoding on any message type part regardless of subtype is explicitly
forbidden in the MIME specification. I also don't think there's much danger of
this happening by accident either, so I believe this is a complete nonissue.

As for the notion that it is Intolerably Evil, there is a definite faction of
MIME supporters that do feel this way. They lobbied for and got the restriction
on not being able to encode the multipart and message types as a whole.
Personally, I'm a moderate in all this (and my MIME implementation fully
supports but never produces nested encodings) but I certainly don't want to
antagonize this very vocal subgroup.

> There was also discussion of the
> idea that PEM should consume MIME's message framing mechanism rather
> than continuing to employ its own framing convention; unfortunately, PEM
> requires a closing message delimiter in order to compute a message
> integrity check, and MIME doesn't provide one except as a side effect of
> enclosure within a multipart message.

True. This is an issue that has to be dealt in order to really integrate
the two. However, this is irrelevant to the simple encapsulation approach.

> There was also debate about
> whether <application/pem> or <message/pem> would be the best answer, 
> with (as I recall) returns from some precincts suggesting different
> answers for the cases of encrypted vs. signed-only messages.

The implicit encoding restriction that message/pem gives you is a real
advantage. Aside from this they are just names, really. And once again, I feel
we're in need of a quick fix now rather than waiting for a comprehensive
solution to come out later, so I'd opt for the one that gives the right results
right now and worry about cleaning it all up later when we've agreed on a Grand
Unified Message Format.

> I think that converging these divergent opinions into a agreed means for
> representing PEM within MIME would certainly be a Good Thing, and one that
> should certainly be simpler than defining the reverse encapsulation; could
> anyone not live with something as simple and crude as the two MIME headers
> being followed by a PEM message as defined, yielding:

> ...

> to follow all of the message's enclosing RFC-822 headers?  

I can definitely live with this!

> Ned states that "Practically every mail user agent in widespread use
> either already supports MIME or work is underway to make it support MIME
> in a future release.  This is also true of many gateway packages." 
> These are exciting statements, suggesting that MIME capabilities will
> become available to large prospective user communities in the
> not-too-distant future.  Even so, I won't personally postpone
> respiration pending the flag day which eradicates the last non-MIME mail
> component from the super-Internet presently enjoying RFC-822 mail
> connectivity.

I don't think non-MIME RFC822 will ever disappear entirely from the Internet.
However, this was not at all the point I was trying to make. My point was that
MIME usage is becoming widespread more rapidly than anticipated, that you can
no longer be sure that any given path through the Internet won't involve
MIME-ization of your messages, and therefore if there are interoperability
problems between MIME and PEM they are quite likely to hit us square in the
fact in fairly short order.

I'll even go so far as to say that I think the reason we haven't seen these
problems already is largely due to the lack of a significant PEM installed
base. Once this changes I think we'll be in for it.

> I suspect that 822-level gateways (even more likely than
> UAs to be one-offs, locally built or tweaked for requirements of
> particular administrations, and perhaps supported only in a sketchy
> fashion) will be especially persistent.  Clearly, the messages this
> installed base emits won't bear MIME-Version: headers, and the new
> MIME-sentient components as introduced must continue to be able to
> transport the old-style messages without difficulty (unless the
> introduction of MIME-sentient intermediaries intrinsically breaks
> existing connectivity, which I hope and presume isn't the case).

I guess I wasn't clear as to where I think the problems are going to come from.
As a result of the fundamental nature of the installed RFC822 base (some of
which indulges in practices that are in violation of RFC822) newly created
MIME-aware MTAs, gateways, and UAs are inevitably going to find themselves in a
position where conversion to MIME formats is inevitable. This is going to
result in conversion of non-MIME messages to MIME messages in some cases. And
you will not be able to predict when this will happen in advance.

This will then cause PEM messages, which contain absolutely no labelling in the
message header indicating their PEM nature (the labelling is, as far as I'm
aware, always part of the message body), to get stamped as plain text messages.
And there are a bunch of things that can then be done to a plain text message
that you don't want to do to a PEM message. (In effect we're revisiting the
encoding of encodings issue, not to mention other nastier sorts of conversions
and transformations).

None of this breaks existing connectivity in any way. On the contrary, it
significantly enhances existing connectivity, but the price paid for this
enhancement is that things that aren't properly labelled don't get the handling
that is their due.

Let me provide another example which, while it does not involve catastrophic
behavior, is something that should be avoided. Let's suppose I operate an
e-mail to FAX gateway. This uses MIME labelling to distinguish between text,
PostScript, the TIFF, and so forth. To such a gateway an encrypted PEM part is
just plain text. You then end up with FAX pages full of base64 encoded stuff.
The simple addition of the appropriate MIME-Version: and Content-Type: headers
fixes this -- it makes the FAX gateway aware of the type of data it is dealing
with so it can handle it intelligently. (The proper thing would probably be to
drop the part and inform the sender of the problem. The sender can then beat on
the FAX gateway developers to add full PEM support to their product ;-)

> I don't understand, therefore, why
> it's critical that all PEM messages must bear MIME-Version: headers, even if
> the environment in which a PEM UA operates doesn't otherwise support MIME. 

This isn't really a UA issue. It is an MTA/gateway issue. Since the present
incarnation of PEM is effectively invisible as far as MIME goes PEM ends up
looking like normal text. And the handling of normal text in general isn't
right for PEM material. All I'm proposing is that we make PEM visible to 
MIME so that MTAs and gateway will keep their hands to themselves.

				Ned