Network Working Group Steve Crocker Internet Draft Ned Freed Marshall Rose MIME-PEM Interaction Thu Apr 18 14:00:00 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 [3], 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 [4-7], an acronym for "Privacy Enhanced Mail", provides message encryption and authentication services for Internet mail messages. draft MIME-PEM Interaction Apr 93 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. MIME does not provide encryption or authentication services. PEM allows encryption and authentication services 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 services for multi-part text and non-text messages. MIME-PEM interaction is provided for by defining four new MIME content types: multipart/pem, application/pem, message/pem- clear, and application/pem-encrypted. Then the relationship between MIME and PEM is described in terms of two functions: message composition and message delivery. 4. Definiton of new Content Types 4.1. Multipart/pem Content Type Definition (1) MIME type name: multipart (2) MIME subtype name: pem (3) Required parameters: boundary, privacy (4) Optional parameters: none Expires Oct 18, 1993 [Page 2] draft MIME-PEM Interaction Apr 93 (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 [4] This subtype of multipart always contains two body parts. The contents of the first body part contains the privacy-enhanced content and corresponds to the production as defined in section 9 of [4]. The first part's content type is either message/pem-clear or application/pem-encrypted. The second part describes the privacy enhancement which was applied to the first body part. The second part's content type is always application/pem. The syntax and semantics of the boundary parameter is defined in [3]. The syntax of the privacy parameter, using the ABNF notation of [1], is: privacy-value ::= "ENCRYPTED" / "MIC-ONLY" with each value conveying the intent of the PEM Proc-Type: field as specified in section 4.6.1.1 of [4]. Note that MIC- CLEAR is not provided directly; it is subsumed by the combination of MIC-ONLY and the MIME Content-Transfer-Encoding mechanism that is available to any body part. 4.2. Message/pem-clear Content Type Definition (1) MIME type name: message (2) MIME subtype name: pem-clear (3) Required parameters: none Expires Oct 18, 1993 [Page 3] draft MIME-PEM Interaction Apr 93 (4) Optional parameters: none (5) Encoding considerations: Any transport-compatible encoding capable of accomodating the range of data present in a particular message may be used. Use of quoted-printable is strongly recommended in order to guard against inadvertent corruption that would otherwise lead to validation failures. (6) Security Considerations: see [4] The canonical form of this content type corresponds to the after integrity checks have been computed. This content type occurs only inside of a multipart/pem content type. 4.3. 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: Any transport-compatible encoding capable of accomodating binary data may be used. However, base64 is recommended in order to be backwards- compatible with the original PEM encoding conventions. (6) Security Considerations: see [4] The canonical form of this content type corresponds to the after encryption processing. This content type occurs only inside of a multipart/pem content type. Expires Oct 18, 1993 [Page 4] draft MIME-PEM Interaction Apr 93 4.4. Application/pem Content Type Definition (1) MIME type name: application (2) MIME subtype name: pem (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: 7bit is always sufficient. (6) Security Considerations: see [4] The canonical form of this content type corresponds to the production defined in section 9 of [4]. This content type may be used both as a subpart of the multipart/pem content type and as an independent bodypart to represent certificates and certificate revocation lists (CRLs). Certificates and CRLs are not always associated with any . 5. 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 message body and process it accordingly. Each block of content headers associated with either an RFC822 or with a MIME represents a logical place where privacy enhancement can be requested. A privacy enhancement request associated with a particular or content is taken to apply to the entire content; it is not possible to privacy-enhance only a portion of a body part. Expires Oct 18, 1993 [Page 5] draft MIME-PEM Interaction Apr 93 Since the semantics of privacy enhancment requests closely parallel those of an additional Content- header, the use of an additional Content- header for this purpose is a reasonable, but not mandatory, approach. If a Content- header is used for this purpose, this memo suggests that a new header field, "Content-Privacy", be used for this purpose. The syntax of this header field corresponds to the production defined above. NOTE The Content-Privacy header is defined here for illustrative purposes only; this RFC does not recommend any one specific mechanism. The interface between the message composer and pre-submission processing is entirely a local matter, and in general any mechanism with semantics comparable to a Content-Privacy header can be used. More to the point, 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 sort of privacy enhancement as well as tampering with the enhancement request itself. 5.1. Pre-Submission Algorithm Prior to submission, 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 has been selected for privacy enhancement, the content is transformed from local form to its MIME Expires Oct 18, 1993 [Page 6] draft MIME-PEM Interaction Apr 93 binary canonical form. If Content-Transfer-Encoding: headers are present the content encoding is reversed as a part of this process, 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. (3) Once binary canonical form has been produced the selected privacy-enhancement is performed. If encryption processing is performed an entirely new content is generated which replaces the original content. information is also produced by this process. (4) A new part is then constructed with the privacy-enhanced material as its content. This part is labelled with a content type of either message/pem-clear (if the privacy-enhancement is MIC-ONLY) or application/encrypted (if the privacy-enhancement is ENCRYPTED). An appropriate transfer encoding is also applied to the content and a corresponding Content-Transfer-Encoding: header is added to the new part. Base64 encoding is recommended in the case of ENCRYPTED privacy-enhancement in order to be backwards-compatible with the original PEM conventions. When MIC-ONLY privacy-enhancement is used a transfer encoding other than 7bit must be used only if the content data requires it. However, at a minimum the use of the quoted-printable encoding is strongly recommended to insure that the message is not damaged in transit, which would in turn lead to validation check failures and decryption errors. (5) Finally, a multipart/pem content is constructed, which contains the new part and a corresponding application/pem part containing the . The multipart/pem content replaces the original content. 6. Message Delivery When a user receives a message containing a multipart/pem 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 Expires Oct 18, 1993 [Page 7] draft MIME-PEM Interaction Apr 93 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/pem 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. Once again, the semantics of these indicators closely parallel those of a Content- header. If a header is actually used to communicate or store this information, it is suggested that a new header field, "Content-Annotation," be used for this purpose. The syntax of this suggested header field, using the ABNF notation of [1], is: content-annotation ::= "Content-Annotation" ":" annotation-value annotation-value ::= ";" with corresponding to the privacy-enhancement that was in effect during submission, and , defined in [1] and [2], indicates the date and time when the privacy- enhancement was verified by the receiving user agent. NOTE As with requests for privacy enhancement to the pre- submission algorithm, the path between post-delivery and actual display of the message must be a trusted one, lest a message be presented that purports to have had a it did not in fact possess. 7. Examples For example, suppose the following message was being readied for submission: Date: Thu, 12 Nov 1992 21:43:40 -0800 From: scrocker@tis.com Expires Oct 18, 1993 [Page 8] draft MIME-PEM Interaction Apr 93 To: ned@innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Privacy: mic-only Hi Ned. See how much nicer this works! After applying pre-submission algorithm, the message submitted for delivery would appear as: Date: Thu, 12 Nov 1992 21:43:40 -0800 From: scrocker@tis.com To: ned@innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: multipart/pem; boundary="next-part"; privacy=mic-only --next-part Content-Type: message/pem-clear Content-Type: text/plain; charset=us-ascii Hi Ned. See how much nicer this works! --next-part Content-Type: application/pem Proc-Type: 4,MIC-ONLY Originator-ID-Asymmetric: ...,09 MIC-Info: RSA-MD5,RSA,... --next-part-- After applying the post-delivery algorithm, the resulting message would appear as: Date: Thu, 12 Nov 1992 21:43:40 -0800 From: scrocker@tis.com To: ned@innosoft.com Subject: example #1 MIME-Version: 1.0 Expires Oct 18, 1993 [Page 9] draft MIME-PEM Interaction Apr 93 Content-Type: text/plain; charset=us-ascii Content-Annotation: mic-only; Thu, 12 Nov 1992 22:13:40 -0800 (integrity verified) Hi Ned. See how much nicer this works! The following privacy-enhanced message illustrates how an entire message can receive enhancement. Date: Mon, 29 Mar 93 13:57:08 -0500 From: Greg Vaudreuil To: Marshall Rose Subject: Forwarded integrity Message MIME-Version: 1.0 Content-Type: multipart/pem; boundary="Privacy Boundary"; privacy=mic-only --Privacy Boundary Content-Type: message/pem-clear 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/pem; boundary="Forwarded Message" privacy=mic-only --Forwarded Message Content-Type: message/pem-clear Content-Type: message/RFC822 Date: Mon, 29 Mar 93 13:53:02 -0500 Expires Oct 18, 1993 [Page 10] draft MIME-PEM Interaction Apr 93 From: Ned Freed To: Greg Vaudreuil Subject: Minimal PEM Message This is a mic-clear message using 822 pem. Greg V. --Forwarded Message Content-Type: application/pem Proc-Type: 4,MIC-ONLY Originator-ID-Asymmetric: ...,09 MIC-Info: RSA-MD5,RSA,... --Forwarded Message-- --Middle Boundary-- --Privacy Boundary Content-Type: application/pem Proc-Type: 4,MIC-ONLY Originator-ID-Asymmetric: ...,09 MIC-Info: RSA-MD5,RSA,... --Privacy Boundary-- Expires Oct 18, 1993 [Page 11] draft MIME-PEM Interaction Apr 93 The following privacy-enhanced message illustrates the use of encryption and the application/encrypted content type. Date: Mon, 29 Mar 93 14:36:40 -0500 From: Greg Vaudreuil To: Jim Galvin Subject: Example Encrypted Message MIME-Version: 1.0 Content-Type: multipart/pem; boundary="PEM Boundary"; privacy=encrypted --PEM Boundary Content-Type: application/encrypted Content-Transfer-Encoding: base64 8R/EVhZy7OU= --PEM Boundary Content-Type: application/pem Proc-Type: 4,ENCRYPTED DEK-Info: DES-CBC,4C776432D61A9829 Originator-ID-Asymmetric: ...,09 Key-Info: RSA,... MIC-Info: RSA-MD5,RSA,... --PEM Boundary-- 8. 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. Expires Oct 18, 1993 [Page 12] draft MIME-PEM Interaction Apr 93 (3) It provides for a 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. (4) It minimizes confusion when viewing a MIC-ONLY content without a PEM-capable user agent. (5) It minimizes confusion when viewing a MIC-ONLY content with a MIME-capable user agent that is not PEM-capable. 9. Acknowledgements David H. Crocker suggested the use of a multipart structure for MIME-PEM interaction. 10. References [1] D.H. Crocker, Standard for the Format of ARPA Internet Text Messages, RFC 822, August, 1982. [2] R. Braden, Editor, Requirements for Internet Hosts -- Application and Support, RFC 1123, October 1989. [3] N. Borenstein, N. Freed, Multipurpose Internet Mail Extensions, RFC 1341, June 1992. [4] J. Linn, Privacy Enhancement for Internet Electronic Mail -- Part I: Message Encryption and Authentication Procedures, RFC 1421, DEC, February 1993. [5] S. Kent, Privacy Enhancement for Internet Electronic Mail -- Part II: Certificate-Based Key Management, RFC 1422, BBN, February 1993. [6] D. Balenson, Privacy Enhancement for Internet Electronic Mail -- Part III: Algorithms, Modes, and Identifiers, RFC 1423, TIS, February 1993. [7] B. Kaliski, Privacy Enhancement for Internet Electronic Mail -- Part IV: Key Certification and Related Services, RFC 1424, RSA Laboratories, February 1993. Expires Oct 18, 1993 [Page 13] draft MIME-PEM Interaction Apr 93 11. Author Addresses Steve Crocker Trusted Information Systems email: crocker@tis.com 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@innosoft.com Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Moutain View, CA 94043-2186 Tel: +1 415 968 1052 Fax: +1 415 968 2510 email: mrose@dbc.mtview.ca.us Expires Oct 18, 1993 [Page 14]