Network Working Group Steve Crocker Internet Draft Ned Freed Marshall Rose MIME-PEM Interaction Mon Jan 11 02:20: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. 3. Introduction In the Internet community, an electronic mail message has 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 Multipurpose Internet Mail Extensions (MIME) [2]. Privacy Enhanced Mail (PEM) [3-6] allows encryption and authentication services to be applied to an electronic mail message. This memo defines a framework whereby the services provided by MIME and PEM are used in a complementary fashion. draft MIME-PEM Interaction Jan 93 In order to provide for MIME-PEM interaction, two content types, "multipart/pem" and "application/pem", are defined. 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. Definition of the multipart/pem Content Type (1) MIME type name: multipart (2) MIME subtype name: pem (3) Required parameters: boundary, privacy (4) Optional parameters: none (5) Encoding considerations: always 7bit (6) Security Considerations: see [3] This subtype of multipart always contains two body parts: the first is an arbitrary content and the second is an application/pem content which describes the privacy- enhancements which resulted in the first body part. The value of the first body part corresponds to as defined in [3]. Note that if is represented using the base64 encoding, then a Content-Transfer-Encoding: header is present which indicates use of the base64 content encoding. This Content-Transfer-Encoding must be used for encrypted . Any Content-Transfer-Encoding may be used when is not encrypted, although some form of encoding is recommended to protect the contents from damage that may subsequently cause message integrity check (MIC) failure. The syntax and semantics of the boundary parameter is defined in [2]. Expires May 16, 1993 [Page 2] draft MIME-PEM Interaction Jan 93 The syntax of the privacy parameter, using the ABNF notation of [1], is: privacy-value ::= "ENCRYPTED" / "MIC-ONLY" with each value conveying the intent as specified in [3]. 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. Definition of the application/pem Content Type (1) MIME type name: application (2) MIME subtype name: pem (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: always 7bit (6) Security Considerations: see [3] The syntax of this content type corresponds to the production defined in [3]. 5. Message Composition When a user composes a message, it is the responsibility of the user agent to use Content-Type: headers. This allows the receiving user agent to unambiguously interpret the 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 particular or content is taken to apply to the entire content; it is not possible to privacy-enhance only a piece of a body part. Expires May 16, 1993 [Page 3] draft MIME-PEM Interaction Jan 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 required, 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 This Content-Privacy header is only a suggested mechanism -- the interface between the message composer and pre- submission processing is entirely a local matter, and in general any mechanism with comparable semantics 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 the release of information that has not received the requested sort of privacy enhancement. 5.1. Pre-Submission Algorithm Prior to submission, the user agent applies this algorithm: (1) If the content has not been selected for privacy enhancement, then 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 binary canonical form. Note that 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. (3) Otherwise, the selected privacy-enhancement is performed, constructing a new content. The Content- headers, other Expires May 16, 1993 [Page 4] draft MIME-PEM Interaction Jan 93 than Content-Transfer-Encoding: and Content-Privacy: (if this header is used), are taken from the original content, if any. (4) If the selected privacy-enhancement is ENCRYPTED, then the base64 Content-Transfer-Encoding is applied and a Content-Transfer-Encoding: header is added to the new content. If the selected privacy-enhancement is MIC-ONLY, a Content-Transfer-Encoding other than 7bit must be used only if the content data requires it. However, at a mimimum the use of the quoted-printable Content- Transfer-Encoding is strongly recommended to insure that the message is not damaged in transit, causing the MIC to fail. (5) Finally, a multipart/pem content is constructed, which contains the new content and a corresponding application/pem content. The multipart/pem content replaces the original content. 6. Message Delivery When a user receives a message containing an multipart/pem content, the user agent may transform the content back into its original content type. 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/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 the header approach is chosen, 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: Expires May 16, 1993 [Page 5] draft MIME-PEM Interaction Jan 93 content-annotation ::= "Content-Annotation" ":" annotation-value annotation-value ::= ";" with corresponding to the privacy-enhancement that was in effect during submission, and , defined in [1], 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. An Example For example, suppose the following message was being readied for submission: 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: 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: Expires May 16, 1993 [Page 6] draft MIME-PEM Interaction Jan 93 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: text/plain; charset=us-ascii Hi Ned. See how much nicer this works! --next-part Content-Type: application/pem Proc-Type: 4,MIC-ONLY Content-Domain: RFC822 Originator-ID-Asymmetric: ... 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 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! Of course, as the message being submitted was only plain US- ASCII text, the Content-Type: header could be ommitted. In that case, after applying the pre-submission algorithm, the message submitted for delivery would appear as: Expires May 16, 1993 [Page 7] draft MIME-PEM Interaction Jan 93 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 Hi Ned. See how much nicer this works! --next-part Content-Type: application/pem Proc-Type: 4,MIC-ONLY Content-Domain: RFC822 Originator-ID-Asymmetric: ... MIC-Info: RSA-MD5,RSA, ... --next-part-- 8. Observations The use of the pre-submission and post-delivery algorithms 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 privacy-enhancement. (3) It allows a message to contain 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. Expires May 16, 1993 [Page 8] draft MIME-PEM Interaction Jan 93 (5) It minimizes confusing 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. Request for Comments 822, (August, 1982). [2] N. Borenstein, N. Freed, Multipurpose Internet Mail Extensions. Request for Comments 1341, (June, 1992). [3] J. Linn, Privacy Enhancement for Internet Electronic Mail -- Part I: Message Encryption and Authentication Procedures. Internet-Draft, (July 23, 1992). [4] S. Kent, Privacy Enhancement for Internet Electronic Mail -- Part II: Certificate-Based Key Management. Internet-Draft, (August 6, 1992). [5] D. Balenson, Privacy Enhancement for Internet Electronic Mail -- Part III: Algorithms, Modes, and Identifiers. Internet-Draft, (September 3, 1992). [6] B. Kaliski, Privacy Enhancement for Internet Electronic Mail -- Part IV: Key Certification and Related Services Internet-Draft, (September 1, 1992). Expires May 16, 1993 [Page 9] draft MIME-PEM Interaction Jan 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 May 16, 1993 [Page 10]