[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Network Working Group                    Internet Engineering Task Force
Internet Draft                       Privacy Enhanced Mail Working Group
<draft-ietf-pem-mime-alternative-00.txt>                  J. I. Schiller
                                                                     MIT
                                                            October 1993

                  An Alternative PEM MIME Integration

Status of this Memo

   This  document  is an   Internet Draft.  Internet Drafts  are working
   documents  of the Internet Engineering  Task Force (IETF), its Areas,
   and its  Working Groups. Note  that other groups may  also distribute
   working documents as Internet Drafts.

   Internet Drafts  are draft  documents valid  for   a maximum  of  six
   months. Internet   Drafts may be updated,  replaced,  or obsoleted by
   other documents at any  time. It is not  appropriate to  use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   Please check  the  I-D abstract listing  contained  in  each Internet
   Draft  directory to learn  the  current status of   this or any other
   Internet Draft.

   Distribution of  this memo is  unlimited. Please send comments to the
   <pem-dev@tis.com> mailing list.

   This is the second document  to describe a  mechanism to enclose MIME
   messages  within PEM and vica versa.  This document is an independent
   effort to be  considered as an  alternative to the previous document.
   This  is *not* a revision  of that document and the  authors of it do
   not necessarily endorse the approach described here.

Introduction

   This document  describes a mechanism  for providing  Privacy Enhanced
   Mail (PEM) functionality within the context of MIME messages.

Background

   MIME (RFC1341-1342)   and PEM    (RFC1421-1424) have  taken  separate
   evolution paths. Specifically    PEM was designed  and specified   to
   handle RFC822  (non-MIME) messages. The goal of  this document  is to
   describe a  method  for using PEM  to  protect MIME messages,  and to
   define a way to enclose PEM processed messages within MIME messages.

   To accomplish these goals requires an  additional profile for RFC1421
   (Content-Domain: MIME) and the definition of a new MIME "application"
   (application/pem-1421).

   There are  four possibilities for interaction  between PEM  and MIME.
   They are:

   * A MIME   message transporting an  RFC1421 PEM  message which itself
   contains an RFC822 message (Content-Domain: RFC822).

   * A MIME  message  transporting an  RFC1421 PEM  message which itself
   contains a MIME object (Content-Domain: MIME).



Expires: April 28, 1994                                         [Page 1]


Network Working Group                    Internet Engineering Task Force
Internet Draft                       Privacy Enhanced Mail Working Group
                                                          J. I. Schiller
                                                                     MIT
                                                            October 1993

   * A PEM  message  which contains a  RFC822  message (as  specified by
   RFC1421).

   *  A PEM message  which contains  a MIME message  or object (Content-
   Domain: MIME).

Definition of "Content-Domain: MIME" within an RFC1421 PEM message

   When  a PEM message  contains a MIME object, as  opposed  to a simple
   text message,   the value  of  the  Content-Domain  field of the  PEM
   headers shall be the string "MIME".

   An RFC1421 PEM message of  Content-Domain "MIME" shall contain a MIME
   "object" that begins with a "Content-Type" MIME header. The PEM body,
   upon completion of  successful PEM  processing is  handed to a   MIME
   interpreter for  further  processing. Content-Domain "MIME"  messages
   may be protected with   either ENCRYPTED, MIC-ONLY or  MIC-CLEAR  PEM
   services. However if MIC-CLEAR is chosen, the  MIME content should be
   in a canonical 7bit form.

   In  other  words, if the  enclosed  MIME object   is encoded  in such
   fashion as  to be  7bit   transportable, then MIC-CLEAR  may  be (and
   perhaps   should  be) used. Other   non-encrypted  messages should be
   encoded via the MIC-ONLY mechanism.

Enclosing a PEM message within a MIME object

   An RFC1421 PEM message may be enclosed  in a MIME message by defining
   it to be of Content Type "application/pem-1421"  by preceding the PEM
   processed body with:

               Content-Type: application/pem-1421

   Note that the   application subtype is  defined to  be "pem-1421" and
   that the  representation *must* be text/plain; charset=us-ascii. This
   is because these are  correct  characterizations  of what a   RFC1421
   message appears as.

The behavior of a MIME mail reader with PEM capability

   A MIME mail reader with PEM capability will  be able to fully process
   a MIME message which includes a PEM portion (which  may either be the
   entire message or only part of a multi-part message).

   The MIME reader  will process a message which  contains a PEM portion
   as  it  would    any   other  MIME  message.   Upon    encountering a
   "application/pem-1421"  body part, it  will  invoke PEM processing on
   the  enclosed  PEM message. If  the  PEM message contains  a Content-
   Domain "MIME"    body,   it will   invoke  MIME  recursively   on the
   successfully processed PEM body. If the Content-Domain is RFC822, the
   PEM software will  either display the enclosed  text,  or prepend the
   necessary headers such that it can be fed to a MIME reader which will
   treat it as an RFC822 mail message.



Expires: April 28, 1994                                         [Page 2]


Network Working Group                    Internet Engineering Task Force
Internet Draft                       Privacy Enhanced Mail Working Group
                                                          J. I. Schiller
                                                                     MIT
                                                            October 1993

The behavior of a MIME mail reader without PEM capability

   A MIME mail reader will  process a MIME  message with PEM contents as
   any other MIME message. If  an  application/pem-1421 object is  found
   and the MIME  reader does not support  PEM, then the MIME  reader may
   handle the enclosed PEM message in the  same or similar fashion as it
   handles any  other application subtype  for which  it  has no support
   software.

The behavior of a non-MIME but PEM capable mail reader

   A   PEM mail reader  that  does not understand   MIME will be able to
   process a MIME/PEM message provided that the  message itself is a PEM
   message. In other words, if the whole message is PEM processed as the
   last step prior  to  transmission, then  a PEM capable,  but non-MIME
   capable mail reader will be able to process the  PEM message and then
   display the enclosed MIME object in the same  fashion that a non-MIME
   mail reader handles a MIME (but non-PEM) message today.

   It is likely that a non-MIME compliant mail  reading agent may not be
   able  to parse  a  MIME  message  in order  to  discover an  enclosed
   "application/pem-1421" component containing a PEM message. However an
   end-user may be able to manually  reformat the incoming message so as
   to make it amenable to PEM processing.

Discussion

   Prior  approaches   to integrating  PEM  and  MIME  have  suggested a
   significant  departure from the  RFC1421 PEM encapsulation mechanism.
   Specifically it has been recommended that PEM messages be represented
   as MIME multi-part messages. One part of the multi-part would contain
   what in RFC1421 is described as the PEM headers,  and the other would
   contain  the  PEM body   that  is protected  by the    PEM mechanisms
   specified in the PEM header part.

   This document intentionally does not recommend such an approach. This
   is because it is important for MIME interpreters  to *not* reach down
   into the  structure  of a  PEM body   until PEM  processing  has been
   performed. The  reason  for  this  requirement has  to   do  with the
   requirement   that PEM  body   parts  be  immutable  so that  digital
   signatures computed  on them can  be verified. If  a PEM body part is
   decomposeable by MIME readers,  then it is  quite possible  that MIME
   gateways  could reassemble PEM body  parts  in a fashion semantically
   equivalent to the original message, but sufficiently different (i.e.,
   different in  one bit is sufficient)  to cause signature verification
   to later fail.

   It is important   to   understand that  the  signature   verification
   requirement mandates that  PEM  messages be  carried within  MIME  as
   "application" objects and   not  as "message",  "multipart"  or other
   types  of body parts. Once this  is recognized,  it no longer matters
   whether or not the object within  the "application" enclosure appears
   to be a MIME object upon visual inspection, for it is now outside the
   realm of what a MIME interpreter may attempt to parse without the aid
   of the application processor (PEM in this case).

Expires: April 28, 1994                                         [Page 3]

Network Working Group                    Internet Engineering Task Force
Internet Draft                       Privacy Enhanced Mail Working Group
                                                          J. I. Schiller
                                                                     MIT
                                                            October 1993

   By  using the RFC1421 based encapsulation  technology we benefit from
   the experience gained  in  debugging existing PEM implementations  as
   well as ease backward compatibility with non-MIME based PEM agents.

Examples

   Date: Sun, 30 May 93 23:59:39 EST
   From: jis@MIT.EDU (Jeffrey I. Schiller)
   To: pem-dev@tis.com
   Subject: Example PEM MIME Interaction
   MIME-Version: 1.0
   Content-Type: application/pem-1421

   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,MIC-CLEAR
   Content-Domain: MIME
   Originator-Certificate: MIIB+jCCAWMCAQIwDQYJKoZIhvcNAQECBQAwSj...
   Issuer-Certificate: MIIB+jCCAWMCAQQwDQYJKoZIhvcNAQECBQAwRDELMA...
   MIC-Info: RSA-MD5,RSA,dlSRMLFiwcK7FDvFef8gJfLWwMM4uxMSNtKGlLz9xxw
    fAyvaFuzp85davcwX4q7EImDs4K46Uwh0oL2GueLnv6b4s1gg25mMg/Y5Bd7/HaE
    cvkV77tKWGXZrDGEgGSDA

   Content-Type: text/plain; charset=us-ascii

   This is a test message.
   -----END PRIVACY-ENHANCED MESSAGE-----

Author's Address

   Jeffrey I. Schiller
   Massachusetts Institute of Technology
   MIT Room E40-311
   1 Amherst Street
   Cambridge, MA 02139
   U.S.A.
   Tel:    +1 (617) 253-0161
   Fax:    +1 (617) 258-8736
   Email:  jis@mit.edu