ietf-822
[Top] [All Lists]

MIME-PEM Interaction Specification

1993-10-21 13:58:26
We now have a moderately stable proposal for integration of MIME and
PEM.  It is included below and will also be submitted to the Internet
Drafts directory.

The main features of this spec are:

- use of MIME's boundary and content transfer encoding mechanisms,

- separation of encryption and signature processes

- introduction of application/quoted-mime-entity to protect signed
  bodies (and use of the recently introduced multipart/headerset)

- separation of enhancement from all transactions involving requests
  and replies for certificates and CRLs.

It has taken a fair amount of time to work through the detailed
interactions between the MIME and PEM cultures, but we think we've
reached a very nice result.

We believe it is premature to attempt to move this spec to Proposed
Standard.  It will take a while for the PEM and MIME communities to
absorb and debate the details.  Since quite a bit of the required
mechanisms already exist in various implementations of PEM and MIME, we
think it makes a lot of sense to whip up some experimental
implementations to see how well these ideas work.  We will do this, and
we should have something ready for use by year's end.

We'd like to include this on the PEM working group agenda for the
Houston IETF meeting.  Do folks wish to spend time on this?  Steve Kent,
is there time available?

Thanks,

Jim Galvin
Sandy Murphy
Steve Crocker








          Network Working Group                            Steve Crocker
          Internet Draft                                       Ned Freed
                                                              Jim Galvin
                                                            Sandy Murphy
                                                           Marshall Rose

                               MIME-PEM Interaction

                                  Oct 15, 1993




          1.  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 valid for a maximum of six months and may
          be updated, replaced, or obsoleted by other documents at any
          time.  It is inappropriate to use Internet Drafts as reference
          material or to cite them other than as a "work in progress".


          2.  Abstract

          This memo defines a framework for interaction between MIME and
          PEM services.  MIME, an acronym for "Multipurpose Internet
          Mail Extensions", defines the format of the contents of
          Internet mail messages and provides for multi-part textual and
          non-textual message bodies.  PEM, an acronym for "Privacy
          Enhanced Mail", provides message encryption and message
          authentication/integrity services for Internet mail messages.



















          draft                MIME-PEM Interaction             Oct 1993


          3.  Introduction


          An Internet electronic mail message consists of two parts: the
          headers and the body.  The headers form a collection of
          field/value pairs structured according to RFC 822 [1], whilst
          the body, if structured, is defined according to MIME [2].
          MIME does not provide encryption or authentication/integrity
          services.


          PEM [3-6] allows encryption and authentication/integrity
          enhancements to be applied to the contents of electronic mail
          messages but does not provide message structuring or type
          labelling facilities.


          This memo defines a framework whereby the services provided by
          MIME and PEM are used in a complementary fashion.  The 
          resulting combined service provides encryption and 
          authentication/integrity services for single-part and multi-
          part textual and non-textual messages.  We refer to the 
          authentication/integrity service as a signature.


          The services of encryption and signature are separated. This 
          differs from the service provided by [3], in that the 
          encryption privacy enhancement in [3] also computes a 
          signature of the message.  To take full advantage of the 
          functionality provided by MIME, canonicalization and transfer 
          encoding operations are removed from the privacy enhancement 
          and left to the MIME agent.  The content domain header, 
          defined in [3], is not included, as its functionality is 
          subsumed by MIME. Transmission of certificate and certificate 
          revocation lists is separated from the privacy enhancement.  
          The message types no longer need be mentioned in the headers, 
          as the information they impart is contained in the content 
          types.  The requests and responses of [6] are provided for in 
          new content types.

          This represents a departure in mechanism, although not in 
          effect, from the procedures identified in [3].







          Expires Jun, 1994                                     [Page 2]





          draft                MIME-PEM Interaction             Oct 1993


          MIME-PEM interaction is provided for by defining six new MIME   
          content types: application/pem-keys, application/pem-
          signature, application/pem-encrypted, application/quoted-mime-
          entity, application/pem-request and application/certdata. The
          MIME-PEM interaction also uses another new MIME type,
          multipart/headerset, proposed by David Crocker.  The 
          relationship between MIME and PEM is described in terms of two 
          functions, message composition and message delivery.


          The new content types have two different purposes.  The first
          four types (application/pem-keys, application/pem-signature,
          application/pem-encrypted and application/quoted-mime-entity)
          are used to transmit and receive privacy enhanced messages and
          are always encapsulated in a multipart/headerset body part.   
          The last two types (application/pem-request and application/
          certdata) are used to transmit requests for certificate
          operations (retrieval, certification, revocation lists
          retrieval, etc.) and the responses to those requests.  These
          two content types are independent body parts, not required to
          be encapsulated in any other body part.  The two groups of
          content types are discussed in the two sections following.
                                              

          4.  Definition of new enhancement Content Types


          4.1.  Multipart/headerset Content Type Definition


          (1)  MIME type name: multipart

          (2)  MIME subtype name: headerset

          (3)  Required parameters: boundary

          (4)  Optional parameters: none

          (5)  Encoding considerations: Either 7bit, 8bit, or binary
               encoding may be used, depending on the nested part
               encodings and transport limitations.

          (6)  Security Considerations: see [3]







          Expires Jun, 1994                                     [Page 3]





          draft                MIME-PEM Interaction             Oct 1993


          The headerset subtype of multipart always contains at least      
          two body parts, where the first body part gives instructions     
          in some way for the processing of all the body parts.  In this   
          use of the headerset subtype, there are always two body parts.   
          The first part describes the privacy enhancement which was       
          applied to the second body part. The first part's content type   
          is application/pem-signature or application/pem-keys.            


          The second body part contains a body part which contains the     
          privacy-enhanced content.  The second part's content type is     
          either application/pem-encrypted, if the requested privacy       
          enhancement is encryption, or application/quoted-mime-entity,
          if the requested privacy enhancement is signature.   


          The syntax and semantics of the boundary parameter is defined
          in [2].


          4.2.  Application/pem-keys Content Type Definition               

          (1)  MIME type name: application

          (2)  MIME subtype name: pem-keys                                 

          (3)  Required parameters: none

          (4)  Optional parameters: none

          (5)  Encoding considerations: 7bit is always sufficient.

          (6)  Security Considerations: see [3]


          The canonical form of this content type corresponds to the       
          following production for <pemkeys>, which differs from the       
          <pemhdr> in [3] in that neither the <crlhdr> nor the fields      
          conveying certificates or related exclusively to signature are   
          a part of the production.  (The certificate fields appear in
          the application/certdata content type, see Section 5.2).  The
          <contentdomain> field is also eliminated.  The <proctype>
          field is replaced by the <version> field, as the message types
          included in <proctype> are imparted by the content type name
          of the body part.  The productions <dekinfo>, <origid-asymm>,





          Expires Jun, 1994                                     [Page 4]





          draft                MIME-PEM Interaction             Oct 1993


          <origid-symm>, <recipflds> and <keyinfo> are as defined in
          section 9 of [3].                 


          <pemkeys> ::= <version>                                         
                   <dekinfo>                                               
                   (1*(<origkeyflds> *<recipflds>)) ; symmetric case       
                   /((1*<origkeyflds>) *(<recipflds>)) ; asymmetric case 

          <version> ::= "Version" ":" "5" CRLF
     
          <origkeyflds> ::= <origid-asymm> [<keyinfo>]       ;asymmetric   
                         / <origid-symm> [<keyinfo>]         ;symmetric    


          This content type must be used as the first part of a            
          multipart/headerset content type. It may not be used in any      
          other context.                                                   


          4.3.  Application/pem-signature Content Type Definition          

          (1)  MIME type name: application

          (2)  MIME subtype name: pem-signature                            

          (3)  Required parameters: none

          (4)  Optional parameters: none

          (5)  Encoding considerations: 7bit is always sufficient.

          (6)  Security Considerations: see [3]


          The canonical form of this content type corresponds to the       
          following production for <pemsig>, which differs from the        
          <pemhdr> in [3] in that neither the <crlhdr> nor the fields      
          conveying certificates or related exclusively to encryption      
          are a part of the production.  (The certificate fields appear
          in the application/certdata content type, see Section 5.2).
          The <contentdomain> field is also eliminated.  The <proctype>
          field is replaced by the <version> field, as the message types
          included in <proctype> are imparted by the content type name
          of the body part.  The productions <keyinfo>, <micinfo>,





          Expires Jun, 1994                                     [Page 5]





          draft                MIME-PEM Interaction             Oct 1993


          <recipflds>, <origid-asymm> and <origid-symm> are as defined
          in section 9 of [3].         

          <pemsig> ::= <version>                                          
                   (1*(<origsigflds> *<recipflds>)) ; symmetric case       
                   /((1*<origsigflds>) *(<recipflds>)) ; asymmetric case   

          <version> ::= "Version" ":" "5" CRLF

          <origsigflds> ::= <origid-asymm> [<keyinfo>]                     
                         <micinfo>                           ;asymmetric   
                         / <origid-symm> [<keyinfo>]         ;symmetric    


          This content type must be used as the first part of a            
          multipart/headerset content type. It may not be used in any      
          other context.                                                   


          4.4.  Application/pem-encrypted Content Type Definition


          (1)  MIME type name: application

          (2)  MIME subtype name: pem-encrypted

          (3)  Required parameters: none

          (4)  Optional parameters: none

          (5)  Encoding considerations: The encryption will produce
               binary data and may need to be encoded for transport.
               Any transport-compatible encoding capable of  
               accommodating binary data may be used.  A base64
               encoding will be sufficient for all transport systems.
               

          (6)  Security Considerations: see [3]


          The content of the application/pem-encrypted is an encrypted     
          valid MIME object.  Because it is encrypted, the canonical       
          form of this content type is any arbitrary data.                 
          This content type must be used as the second part of a           
          multipart/headerset content type. It may not be used in any      





          Expires Jan, 1994                                     [Page 6]





          draft                MIME-PEM Interaction             Jul 1993


          other context.


          4.5.  Application/quoted-mime-entity Content Type Definition


          (1)  MIME type name: application

          (2)  MIME subtype name: quoted-mime-entity

          (3)  Required parameters: none

          (4)  Optional parameters: none

          (5)  Encoding considerations: If the quoted 
               mime body part has a quoted printable, 7bit, or base64
               transfer encoding indicated, the transfer encoding
               of this body part should be 7bit to avoid nested
               encodings.  Otherwise, any transport-compatible
               encoding capable of accommodating the content type of
               the quoted mime body part may be used.

          (6)  Security Considerations: see [3]


          The application/quoted-mime-entity content is constrained to 
          be a valid MIME object.  The content of that body part must be 
          in the canonical form for its content type. 


          This content type must be used as the second part of a           
          multipart/headerset content type. It may be used in any          
          other context, as well.                                          


          The application/quoted-mime-entity content type may on first 
          inspection appear to be superfluous since the content it 
          contains is itself constrained to be a valid MIME object.  
          However, the use of application/quoted-mime-entity serves a 
          vital function: it protects the inner MIME object from any 
          changes that might be performed by messaging gateways. Such 
          changes frequently disrupt header and boundary information,  
          which in turn would lead to integrity check failures.







          Expires Jun, 1994                                     [Page 7]





          draft                MIME-PEM Interaction             Oct 1993


          The use of application/quoted-mime-entity ensures that if a 
          gateway is compelled to make encoding changes it will do so on
          the application/quoted-mime-entity object as a whole. Such 
          encoding changes, if done properly, will leave the
          application/quoted-mime-entity content entirely intact.


          The application/quoted-mime-entity type may be generally  
          useful outside PEM, as well.  We intend for this to be a type 
          that could be used anywhere in a MIME object and not  
          restricted to PEM. 
                                               

          5.  Definition of new certificate Content Types


          5.1.  Application/pem-request Content Type Definition

          (1)  MIME type name: application

          (2)  MIME subtype name: pem-request

          (3)  Required parameters: none

          (4)  Optional parameters: none

          (5)  Encoding considerations: 7bit is always sufficient.

          (6)  Security Considerations: see [3]


          The canonical form of this content type corresponds to the
          following production.

          <request> ::= <version>
          <version> ::= "Version" ":" "5" CRLF
                        (<subject> / <issuer> / <certification>)
          <subject> ::= "Subject" ":" <asymmid> CRLF
          <issuer> ::= "Issuer" ":" <asymmid> CRLF
          <certification> ::= "Certification" ":" <encbin> CRLF


          The purpose of this body part is to transmit a request.  The
          request can be "Certification", which requests certification
          of a self-signed certificate, or "Subject", which requests the





          Expires Jun, 1994                                     [Page 8]





          draft                MIME-PEM Interaction             Oct 1993


          certificate chain corresponding to a subject identified by a 
          distinguished name, or "Issuer", which requests the revocation 
          list chain issued by an issuer identified by a distinguished
          name. The "Subject" and "Issuer" fields each contain a value
          of type Name, encoded according to the Basic Encoding Rules,
          then in ASCII, as for the "Originator-ID-Asymmetric" field of
          [3].


          In each case, the response can be transmitted in an
          application/certdata content type.


          This type is intended to provide for the requests described
          in [6].  The key certification request and CRL-retrieval
          request are provided for directly.  The CRL-storage request
          is provided for by transmitting the CRL's to be stored in an
          application/certdata content type. 


          5.2.  Application/certdata Content Type Definition

          (1)  MIME type name: application

          (2)  MIME subtype name: certdata

          (3)  Required parameters: none

          (4)  Optional parameters: none

          (5)  Encoding considerations: 7bit is always sufficient.

          (6)  Security Considerations: see [3]


          The canonical form of this content type corresponds to the
          following production built on top of the definitions in
          section 9 of [3].                                                

          <certdata> ::= <certchain> / <crlchain>                          
          <certchain> ::= <version> (<cert> *([<crl>]<cert>))
          <crlchain> ::= <version> 1*(<crl>[<cert])                 
          <cert> ::= "Certificate" ":" <encbin> CRLF                  
          <version> ::= "Version" ":" "5" CRLF






          Expires Jun, 1994                                     [Page 9]





          draft                MIME-PEM Interaction             Oct 1993



          This content type is used to transfer certificate or             
          certificate revocation list information.  This information is    
          entirely independent of any particular enhanced message. (Note
          that the converse is not true: the validity of an enhanced
          message cannot be determined without the proper certificates     
          or current CRL information.)  As such, the application/pem-      
          certdata content type is an independent body part.  It is not     
          used in a multipart/headerset context containing PEM enhanced    
          messages.                                                        


          The <certchain> production contains one certificate chain.   
          Each certificate chain starts with a certificate and continues 
          with the certificates of subsequent issuers.  Each issuer  
          listed is presumed to have issued the preceding certificate.   
          For each issuer, a CRL may be supplied.  A CRL in the chain  
          belongs to the immediately following issuer. Therefore, it  
          potentially contains the immediately preceding certificate.



          The <crlchain> production contains one certificate revocation    
          list chain.  The CRLs in the chain begin with a requested CRL    
          and continue with the CRLs of subsequent issuers.  The issuer    
          of each CRL is presumed to have issued a certificate for the     
          issuer of the preceding CRL.  For each CRL, the issuer's         
          certificate may be supplied.  A certificate in the chain must      
          belong to the issuer of the immediately preceding CRL.


          The relationship between a certificate and an immediately        
          preceding CRL is the same in both cases.  In a <certchain>       
          the crl's are optional.  In a <crlchain>, the certificates       
          are optional.                                                       


          6.  Message Composition


          When a user composes a message, it is the responsibility of
          the user agent to construct a valid MIME message.  In
          particular, Content-Type: and Content-Transfer-Encoding:
          headers should be used wherever they are appropriate.  This
          allows the receiving user agent to unambiguously interpret the





          Expires Jun, 1994                                    [Page 10]





          draft                MIME-PEM Interaction             Oct 1993


          message body and process it accordingly.


          Each block of content headers associated with either an RFC822
          <message> or with a MIME <body-part> represents a logical
          place where privacy enhancement can be requested.  A privacy
          enhancement request associated with a particular <message> or
          <body-part> content is taken to apply to the entire content;
          it is not possible to privacy-enhance only a portion of a body
          part.


          The mechanism used to communicate privacy enhancement requests
          to the pre-submission processor described below is strictly a
          local implementation issue. However, the interface between the
          message composer and pre-submission processing MUST be
          trustworthy, since the message composer relies on pre-
          submission processing to either perform the requested privacy
          enhancement operation or return an error.  Regardless of the
          mechanism chosen, great care should be taken to safeguard
          against both the release of information that has not received
          the requested type of privacy enhancement as well as tampering
          with the enhancement request itself.


          6.1.  Pre-Submission Algorithm


          The user agent first composes a MIME-compliant message and
          then applies this algorithm:


          (1)  If the content at this (initially top) level has NOT been
               selected for privacy enhancement, the user agent sees if
               the content is either multipart or message.  If so, it
               then recursively applies this algorithm to the
               encapsulated body parts; if not, it terminates processing
               for this content.

          (2)  If the content at this level has been selected for  
               privacy enhancement, then the content, including its
               headers, constitutes the object that receives privacy
               enhancement.  The headers at a minimum will include a
               Content-Type header, either explicit or implicit.  The
               object will eventually be replaced with the multipart/





          Expires Jun, 1994                                    [Page 11]





          draft                MIME-PEM Interaction             Oct 1993


               headerset content that is produced by the privacy
               enhancement operation.              

          (3)  The content of the object must be transformed from local
               form to its MIME binary canonical form.  Also, if the 
               requested privacy enhancement is signature, and if
               Content-Transfer-Encoding: headers were present in the
               headers of the object, the content encoding is reversed,
               leaving only 7BIT, 8BIT, and BINARY as possible encodings
               for all body parts.  This is done so that any artifacts
               introduced by encoding are removed and consistent
               integrity checks will be generated.

          (4)  Once an object in binary canonical form has been produced
               the selected privacy enhancement is performed.  The 
               privacy enhancement produces two data streams: the 
               privacy enhanced object and a control stream comprised
               of a set of headers as defined in the <pemsig> or
               <pemkeys> productions.

          (5)  A new body part is then constructed, of content type
               multipart/headerset.  The body part contains two
               body parts, whose content depends on the privacy
               enhancement requested.

               (a) If the requested privacy enhancement is encryption,
                   then the first body part within the multipart/
                   headerset is labelled with a content type of
                   application/pem-keys and contains the <pemkeys> 
                   control stream produced by the privacy enhancement.
                   The second body part within the multipart/headerset 
                   is labelled with a content type application/pem-
                   encrypted, and contains the privacy enhanced object 
                   produced by the privacy enhancement.  An appropriate 
                   transfer encoding is also applied to the content and 
                   a corresponding Content-Transfer-Encoding: header is 
                   added to the application/pem-encrypted body part.
                   Base64 encoding is recommended in the case of
                   encryption privacy enhancement in order to be
                   backwards-compatible with the original PEM
                   conventions.

               (b) If the requested privacy enhancement is signature, 
                   then the first body part within the multipart/
                   headerset is labelled with a content type of 





          Expires Jun, 1994                                    [Page 12]





          draft                MIME-PEM Interaction             Oct 1993


                   application/pem-signature and contains the <pemsig> 
                   control stream produced by the privacy enhancement.  
                   The second body part within the multipart/headerset 
                   is labelled with a content type application/quoted-
                   mime-entity, and contains the privacy enhanced object 
                   produced by the privacy enhancement.  An appropriate 
                   transfer encoding is also applied to the content and 
                   a corresponding Content-Transfer-Encoding: header is 
                   added to the application/quoted-mime-entity bodypart.
        
               This multipart/headerset content replaces the original
               object.


          7.  Post-Delivery Algorithm

          When a user receives a message containing a multipart/
          headerset content, the user agent may transform the content
          back into its original form prior to privacy-enhancement.
          This operation, the post-delivery algorithm, is performed by
          reversing the steps performed during the pre-submission
          algorithm.

          When the original content is reconstituted into its MIME
          binary canonical form, it may use octet values outside of the
          US-ASCII repertoire and may contain body parts without line
          breaks.  If the user agent replaces the multipart/headerset
          content with the original content, then it must select
          appropriate Content-Transfer-Encodings for each body part and
          add corresponding Content-Transfer-Encoding: headers.

          Upon successful completion of the post-delivery algorithm for
          each content, the type of privacy enhancement that was in
          effect for that content must be communicated to the user.  The
          mechanism used to do this is a local implementation issue. As
          with requests for privacy enhancement to the pre-submission
          algorithm, the path between post-delivery processing and
          actual display of the message must be a trusted one, lest a
          message be presented that purports to have undergone some form
          of privacy enhancement it did not in fact receive.


          8.  Examples

          For example, suppose the following body part was selected for





          Expires Jun, 1994                                    [Page 13]





          draft                MIME-PEM Interaction             Oct 1993


          privacy enhancement:


               Content-Type: message/rfc822

               To: ned(_at_)innosoft(_dot_)com
               Subject: example #1
               MIME-Version: 1.0
               Content-Type: text/plain; charset=us-ascii

               Hi Ned.  See how much nicer this works!


          After applying pre-submission algorithm with a request that
          signature privacy enhancement be applied to the body part, the 
          body part submitted for delivery would appear as:


               Content-Type: multipart/headerset;
                             boundary="Privacy Boundary"

               --Privacy Boundary
               Content-Type: application/pem-signature

               Version: 5
               Originator-ID-Asymmetric: ...,09
               MIC-Info: RSA-MD5,RSA,...

               --Privacy Boundary
               Content-Type: application/quoted-mime-entity

               Content-Type: message/rfc822

               To: ned(_at_)innosoft(_dot_)com
               Subject: example #1
               MIME-Version: 1.0
               Content-Type: text/plain; charset=us-ascii

               Hi Ned.  See how much nicer this works!

               --Privacy Boundary--


          After applying the post-delivery algorithm, the resulting
          body part would once again appear as:





          Expires Jun, 1994                                    [Page 14]





          draft                MIME-PEM Interaction             Oct 1993



               Content-Type: message/rfc822

               To: ned(_at_)innosoft(_dot_)com
               Subject: example #1
               MIME-Version: 1.0
               Content-Type: text/plain; charset=us-ascii

               Hi Ned.  See how much nicer this works!


          The body part need not be ascii text.  For example, the
          following audio body part could be privacy enhanced:

               Content-Type: audio
               Content-Transfer-Encoding: base64

               JFJFGJGJJjfjgjgjghjJFGJGJKSKFJFG739475fgfhelkJHDJJGH
               GJKjfdjjJHUjfjd27485jjJDGHj3j4jjHDJjfh5566kfjhJFDHDD
               kwpritufnLKDJWYRIk6n47382oJDHFK4ie3y49JCBCMBVUei3hj

          producing the following body part:

 
               Content-Type: multipart/headerset;
                             boundary="Privacy Boundary"

               --Privacy Boundary
               Content-Type: application/pem-signature

               Version: 5
               Originator-ID-Asymmetric: ...,09
               MIC-Info: RSA-MD5,RSA,...

               --Privacy Boundary
               Content-Type: application/quoted-mime-entity
               Content-Transfer-Encoding: 7bit

               Content-Type: audio
               Content-Transfer-Encoding: base64

               JFJFGJGJJjfjgjgjghjJFGJGJKSKFJFG739475fgfhelkJHDJJGH
               GJKjfdjjJHUjfjd27485jjJDGHj3j4jjHDJjfh5566kfjhJFDHDD
               kwpritufnLKDJWYRIk6n47382oJDHFK4ie3y49JCBCMBVUei3hj






          Expires Jun, 1994                                    [Page 15]





          draft                MIME-PEM Interaction             Jul 1993


               --Privacy Boundary--




          The following privacy-enhanced message illustrates how an
          enhanced body part can itself receive enhancement.

               Date:    Mon, 29 Mar 93 13:57:08 -0500
               From:    Greg Vaudreuil 
<gvaudre(_at_)CNRI(_dot_)Reston(_dot_)VA(_dot_)US>
               To:      Marshall Rose 
<mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us>
               Subject: Forwarded integrity Message
               MIME-Version: 1.0
               Content-Type: multipart/headerset;
                             boundary="Privacy Boundary"

               --Privacy Boundary
               Content-Type: application/pem-signature

               Version: 5
               Originator-ID-Asymmetric: ...,09
               MIC-Info: RSA-MD5,RSA,...

               --Privacy Boundary
               Content-Type: application/quoted-mime-entity

               Content-Type: multipart/mixed;
                             boundary="Middle Boundary"

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

               The enclosed message was integrity enhanced.

               Greg V.

               --Middle Boundary
               Content-Type: multipart/headerset;
                             boundary="Forwarded Message"

               --Forwarded Message
               Content-Type: application/pem-signature

               Version: 5
               Originator-ID-Asymmetric: ...,09





          Expires Jun, 1994                                    [Page 16]





          draft                MIME-PEM Interaction             Jul 1993


               MIC-Info: RSA-MD5,RSA,...

               --Forwarded Message
               Content-Type: application/quoted-mime-entity

               Content-Type: message/RFC822

               Date:    Mon, 29 Mar 93 13:53:02 -0500
               From:    Ned Freed <ned(_at_)innosoft(_dot_)com>
               To:      Greg Vaudreuil 
<gvaudre(_at_)IETF(_dot_)CNRI(_dot_)Reston(_dot_)VA(_dot_)US>
               Subject: Minimal PEM Message

               This is a signed message using MIME-PEM.

               Greg V.

               --Forwarded Message--

               --Middle Boundary--

               --Privacy Boundary--


          The following privacy-enhanced body part illustrates the use
          of encryption and the application/pem-encrypted content type.

               Content-Type: multipart/headerset;
                             boundary="PEM Boundary"

               --PEM Boundary
               Content-Type: application/pem-keys

               Version: 5
               DEK-Info: DES-CBC,4C776432D61A9829
               Originator-ID-Asymmetric: ...,09
               Key-Info: RSA,...

               --PEM Boundary
               Content-Type: application/pem-encrypted
               Content-Transfer-Encoding: base64

               8R/EVhZy7OU= 

               --PEM Boundary--






          Expires Jun, 1994                                    [Page 17]





          draft                MIME-PEM Interaction             Jul 1993




          If it was desired to produce a signed and encrypted body part,     
          the signature would be done first, producing:                    

 
               Content-Type: multipart/headerset;
                             boundary="Sign Boundary" 

               --Sign Boundary                                             
               Content-Type: application/pem-signature                     

               Version: 5                                       
               Originator-ID-Asymmetric: ...,09                            
               MIC-Info: RSA-MD5,RSA,...                                   

               --Sign Boundary                                             
               Content-Type: application/quoted-mime-entity

               Content-Type: message/RFC822                                

               To:    Ned Freed <ned(_at_)innosoft(_dot_)com>                   
      
               Subject: Strongly Protected Message                         

               This will be signed and encrypted.  Let the bad guys        
               do their worst!                                             

               Jim                                                         

               --Sign Boundary--                                           

          and then it would be encrypted, producing:                       

               Content-Type: multipart/headerset;
                             boundary="Enc Boundary"  

               --Enc Boundary
               Content-Type: application/pem-keys                          

               Version: 5                                      
               DEK-Info: DES-CBC,4C776432D61A9829                          
               Originator-ID-Asymmetric: ...,09                            
               Key-Info: RSA,...                                           

               --Enc Boundary                                              





          Expires Jun, 1994                                    [Page 18]





          draft                MIME-PEM Interaction             Jul 1993


               Content-Type: application/pem-encrypted                     
               Content-Transfer-Encoding: base64                           

               9S/FWjAz8P=V                                                

               --Enc Boundary--                                            


          where the encrypted contents, 9S/FWjAz8P=V, are the encryption   
          of the first multipart/headerset.                                


          9.  Observations

          The use of the pre-submission and post-delivery algorithms to
          combine PEM and MIME capabilities exhibit several properties:

          (1)  It allows privacy-enhancement of an arbitrary content,
               not just an entire RFC 822 message.

          (2)  For a multipart or message content, it allows the user to
               decide whether the structure of the content should
               receive what sort of privacy-enhancement.

          (3)  It provides for messages containing several privacy
               enhanced contents, thereby removing the requirement for
               PEM software to be able to generate or interpret a single
               content which intermixes both unenhanced and enhanced
               components.


          The use of a MIME-capable user agent makes complex nesting of    
          enhanced message body parts much easier.  For example, the     
          user can separately sign and encrypt a message.  This     
          motivates a complete separation of the confidentiality     
          security service from the authentication/message integrity     
          security service.  That is, different keys could be used for     
          the different services and protected separately.  In the     
          asymmetric case, this means an employee's company could be     
          given access to the (private) decryption key, granting the     
          company the ability to decrypt messages addressed to the     
          employee in emergencies, without also granting the company     
          the ability to sign messages as the employee.                        







          Expires Jun, 1994                                    [Page 19]





          draft                MIME-PEM Interaction             Jul 1993


          The use of two private keys requires the ability to maintain     
          multiple certificates for each user.                             


          10.  Acknowledgements

          David H. Crocker suggested the use of a multipart structure
          for MIME-PEM interaction.


          11.  References

          [1]  D.H. Crocker, Standard for the Format of ARPA Internet
               Text Messages, RFC 822, August, 1982.

          [2]  N. Borenstein, N. Freed, Multipurpose Internet Mail
               Extensions, RFC 1341, June 1992.

          [3]  J. Linn, Privacy Enhancement for Internet Electronic
               Mail -- Part I: Message Encryption and Authentication
               Procedures, RFC 1421, DEC, February 1993.

          [4]  S. Kent, Privacy Enhancement for Internet Electronic
               Mail -- Part II: Certificate-Based Key Management, RFC
               1422, BBN, February 1993.

          [5]  D. Balenson, Privacy Enhancement for Internet Electronic
               Mail -- Part III: Algorithms, Modes, and Identifiers, RFC
               1423, TIS, February 1993.
 
          [6]  B. Kaliski, Privacy Enhancement for Internet Electronic
               Mail -- Part IV: Key Certification and Related Services,
               RFC 1424, RSA Laboratories, February 1993.

          [7]  R. Braden, Editor, Requirements for Internet Hosts --
                Application and Support, RFC 1123, October 1989.


          12.  Author Addresses

          Steve Crocker
          Trusted Information Systems
          3060 Washington Road
          Glenwood, MD  21738
          email:  crocker(_at_)tis(_dot_)com





          Expires Jun, 1994                                    [Page 20]





          draft                MIME-PEM Interaction             Jul 1993



          Ned Freed
          Innosoft International, Inc.
          250 West First Street, Suite 240
          Claremont, CA 91711
          USA
          Tel:    +1 909 624 7907
          Fax:    +1 909 621 5319
          email:  ned(_at_)innosoft(_dot_)com


          Jim Galvin
          Trusted Information Systems
          3060 Washington Road
          Glenwood, MD  21738
          email:  galvin(_at_)tis(_dot_)com

          Sandra Murphy
          Trusted Information Systems
          3060 Washington Road
          Glenwood, MD  21738
          email:  murphy(_at_)tis(_dot_)com

          Marshall T. Rose
          Dover Beach Consulting, Inc.
          420 Whisman Court
          Mountain View, CA  94043-2186
          Tel:    +1 415 968 1052
          Fax:    +1 415 968 2510
          email:  mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us




















          Expires Jun, 1994                                    [Page 21]


<Prev in Thread] Current Thread [Next in Thread>
  • MIME-PEM Interaction Specification, James M Galvin <=