Re: PEM/mailer integration via MIME

[John Linn 10-Nov-1992 1555 <[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>

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).  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.  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.  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:

MIME-Version:
Content-Type: application/pem
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
<PEM encapsulated header>
<blank line>
<PEM encapsulated text>
-----END PRIVACY-ENHANCED MESSAGE-----

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

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 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
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. 

--jl