Network Working Group Jim Galvin INTERNET DRAFT Sandy Murphy draft-ietf-pem-sigenc-01.txt Steve Crocker Ned Freed July 1994 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted 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 ``work in progress''. To learn the current status of any Internet Draft, please check the 1id-abstracts.txt listing contained in one of the Internet Drafts Shadow Directories on ds.internic.net (US East Coast), venera.isi.edu (US West Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe). 2. Abstract This document defines two new content types for specifying the application of security services to MIME message bodies. 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. The new content types are subtypes of multipart: signed and encrypted. Each will contain two body parts: one for the protected data and one for the control information necessary to remove the protection. Two control information content types are defined, application/signature and application/keys, one for each of the multiparts. The first is to be used when a body part is digitally signed; the second is to be used when a body part is encrypted. The contents of each of the multipart body parts is determined by the value of the protocol parameter, which is required to be present. Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 1] INTERNET DRAFT Security Multiparts July 1994 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 RFC822 [1], whilst the body, if structured, is defined according to MIME [2]. The basic MIME specification does not provide specific security protection. This document defines a framework whereby security protection provided by other protocols may be used with MIME in a complementary fashion. The resulting combined service provides security for single-part and multi-part textual and non-textual messages. The framework is provided by defining two new security subtypes of the MIME multipart content type: signed and encrypted. In each of the security subtypes, there are exactly two related body parts: one for the protected data and one for the control information. This should allow the framework to be used by all protocols providing signature and encryption services. A three-step process is specified for the origination and reception of the multipart contents. The details of the processing performed during each step is specified by the protocol being used. By registering new values for the required protocol parameter, the framework is easily extended to accommodate a variety of protocols. If necessary, additional content types may be defined for the control information carried in each of the multiparts defined in this specification. 4. Definition of Security Subtypes of Multipart The multipart/signed content type specifies how to support authentication and integrity services via digital signature. The control information is carried in a new content type: application/signature. The multipart/encrypted content type specifies how to support confidentiality via encryption. The control information is carried in a new content type: application/keys. 4.1. Definition of Multipart/Signed (1) MIME type name: multipart Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 2] INTERNET DRAFT Security Multiparts July 1994 (2) MIME subtype name: signed (3) Required parameters: boundary, protocol, and hashalg (4) Optional parameters: none (5) Encoding considerations: 7bit, 8bit, or binary depending on transport requirements and encoding of the digitally signed data (6) Security considerations: Must be treated as opaque while in transit The multipart/signed content type contains exactly two body parts. The first body part is the body part over which the digital signature was created, including its content type label. The second body part contains the control information necessary to verify the digital signature and is labelled accordingly. Its content is defined according to the value of the protocol parameter. This document includes the specification of one content type for the control information, which is intended to be suitable for most protocols: application/signature. When using the protocol parameter the attribute token is "protocol", i.e., parameter := "protocol" "=" value Valid value tokens will be maintained by the Internet Assigned Numbers Authority (IANA). The semantics of the protocol parameter are defined according to its value. When using the hashalg parameter the attribute token is "hashalg", i.e., parameter := "hashalg" "=" value Valid value tokens will be maintained by the IANA. The value may be a comma (",") separated list of tokens, indicating the presence of multiple signatures. As a result, the comma (",") character is explicitly excluded from the list of characters that may be included in a token used as a value of the hashalg parameter. If multiple hash algorithms are specified, the purpose and use of the multiple algorithms is defined by the protocol. If the hash algorithm is also specified in the control information and the value there does not agree with the value in this parameter, the control information value must be given precedence. Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 3] INTERNET DRAFT Security Multiparts July 1994 NOTE: The presence of the hashalg parameter on the multipart/signed content type header is explicitly intended to support one-pass processing. MIME implementations may locate the second body part by inputting the first body part and computing the specified hash values until the boundary identifying the second body part is found. The entire multipart/signed body part must be treated as opaque while it is in transit from an originator to a recipient. Intermediate message transfer agents must not alter the content of a multipart/signed in any way, including, but not limited to, changing the content transfer encoding on the body part or any of its encapsulated body parts. When creating a multipart/signed body part, the following sequence of steps describes the processing necessary. It must be emphasized that these steps are descriptive, not prescriptive, and in no way impose restrictions or requirements on implementations of this specification. (1) The contents of the body part to be protected is prepared according to a local convention. The contents are then transformed into a MIME body part, including an appropriate set of headers. The result of this transformation must be a MIME body part that could be submitted for delivery. (2) The body part (content and headers) to be digitally signed is prepared for signature according to the value of the protocol parameter. The MIME headers are included in the signature to protect the integrity of the type of the data that is signed. (3) The prepared body part is made available to the signature creation process according to a local convention. The signature creation process must make available to a MIME implementation two data streams: the control information necessary to verify the signature, which the MIME implementation will place in the second body part, and the digitally signed body part, which the MIME implementation will use as the first body part. When receiving a multipart/signed body part, the following sequence of steps describes the processing necessary. It must be emphasized that these steps are descriptive, not prescriptive, and in no way impose restrictions or requirements on implementations of this specification. (1) The first body part and the control information in the second body part must be prepared for signature verification according to the Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 4] INTERNET DRAFT Security Multiparts July 1994 value of the protocol parameter. (2) The prepared body parts must be made available to the signature verification process according to a local convention. The signature verification process must make available to the MIME implementation the result of the signature verification and the body part that was digitally signed. NOTE: The result of the signature verification is likely to include a testament of the success or failure of the verification. Also, in the usual case, the body part returned after signature verification will be the same as the body part that was received. We do not insist that this be the case to allow for protocols that may modify the body part during the signature processing. (3) The result of the signature verification process is made available to the user and the MIME implementation continues processing with the verified body part, i.e., the body part returned by the signature verification process. 4.2. Definition of Multipart/Encrypted (1) MIME type name: multipart (2) MIME subtype name: encrypted (3) Required parameters: boundary, protocol (4) Optional parameters: none (5) Encoding considerations: 7bit, 8bit, or binary depending on transport requirements and encoding of the encrypted data (6) Security considerations: none The multipart/encrypted content type contains exactly two body parts. The first body part contains the control information necessary to decrypt the data in the second body part and is labelled accordingly. Its content is defined according to the value of the protocol parameter. The second body part contains the data which was encrypted and is always labelled application/octet-stream. This document includes the specification of one content type for the control information: application/keys. Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 5] INTERNET DRAFT Security Multiparts July 1994 When using the protocol parameter the attribute token is "protocol", i.e., parameter := "protocol" "=" value Valid value tokens will be maintained by the Internet Assigned Numbers Authority (IANA). The semantics of the protocol parameter are defined according to its value. When creating a multipart/encrypted body part, the following sequence of steps describes the processing necessary. It must be emphasized that these steps are descriptive, not prescriptive, and in no way impose restrictions or requirments on implementations of this specification. (1) The contents of the body part to be protected is prepared according to a local convention. The contents are then transformed into a MIME body part, including an appropriate set of headers. The result of this transformation must be a MIME body part that could be submitted for delivery. (2) The body part (content and headers) to be encrypted is prepared for encryption according to the value of the protocol parameter. The MIME headers are included in the encryption to protect from disclosure the type of the data that is encrypted. (3) The prepared body part is made available to the encryption process according to a local convention. The encryption process must make available to a MIME implementation two data streams: the control information necessary to decrypt the body part, which the MIME implementation will place in the first body part, and the encrypted body part, which the MIME implementation will place in the second body part and label application/octet-stream. Thus, when used in a multipart/encrypted, the application/octet-stream data is comprised of a nested MIME body part. When receiving a multipart/encrypted body part, the following sequence of steps describes the processing necessary. It must be emphasized that these steps are descriptive, not prescriptive, and in no way impose restrictions or requirements on implementations of this specification. (1) The second body part and the control information in the first body part must be prepared for decryption according to the value of the protocol parameter. Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 6] INTERNET DRAFT Security Multiparts July 1994 (2) The prepared body parts must be made available to the decryption process according to a local convention. The decryption process must make available to the MIME implementation the result of the decryption and the decrypted form of the encrypted body part. NOTE: The result of the decryption process is likely to include a testament of the success or failure of the decryption. Failure may be due to an inability to locate the proper decryption key or the proper recipient field, etc. (3) The result of the decryption process is made available to the user and the MIME implementation continues processing with the decrypted body part, i.e., the body part returned by the decryption process. NOTE: A MIME implementation will not be able to display the received form of the second body part because the application of encryption will transform the body part. This transformation will not be described in the MIME headers (Content-Type: and Content-Transfer-Encoding:) but, rather, will be described in the content of the first body part. Therefore, an implementation should wait until the encryption has been removed before attempting to display the content. 5. Definition of Security Subtypes of Application This document defines two additional content types, one each for when a digital signature is applied to a body part and for when encryption is applied to a body part. These content types are to be used in multipart/signed and multipart/encrypted body parts, respectively. This document defines the use of these content types inside their multipart content types. Their use outside a multipart content is not defined by this document. 5.1. Application/Signature Content Type (1) MIME type name: application (2) MIME subtype name: signature Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 7] INTERNET DRAFT Security Multiparts July 1994 (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: any valid encoding may be used (6) Security considerations: none This content type is used on the second body part of an enclosing multipart/signed. It is comprised of the digital signature of the data, which is the first body part of the enclosing multipart/signed, and the information required to verify that signature. In order to process this body part an implementation must recognize and proceed according to the protocol parameter of the enclosing multipart/signed. It is an error for the protocol parameter to be missing in the enclosing multipart/signed body part. Included in the signature verification information will be the hash algorithm used during the signature creation process. The hash algorithm identified in this body part must match the algorithm identified in the hashalg parameter of the enclosing multipart/signed. If it does not, a user agent should identify the discrepancy to a user and may choose to either halt or continue processing, giving precedence to the algorithm identified in this body part. 5.2. Application/Keys Content Type (1) MIME type name: application (2) MIME subtype name: keys (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: any valid encoding may be used (6) Security considerations: none This content type is used on the first body part of an enclosing multipart/encrypted. It is comprised of the data encryption key used to encrypt the data, located in the second body part of the enclosing multipart/encrypted, and the information required to perform the decryption. In order to process this body part, an implementation must recognize and proceed according to the protocol parameter of the Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 8] INTERNET DRAFT Security Multiparts July 1994 enclosing multipart/encrypted. It is an error for the protocol parameter to be missing in the enclosing multipart/encrypted body part. 6. Security Considerations This specification describes an enhancement to MIME to support signed and encrypted body parts. In that context this entire document is about security. 7. Acknowledgements David H. Crocker suggested the use of a multipart structure for MIME-PEM interaction. 8. References [1] David H. Crocker. Standard for the Format of ARPA Internet Text Messages. RFC 822, University of Delaware, August 1982. [2] Nathaniel Borenstein and Ned Freed. MIME (Multipurpose Internet Mail Extension) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. RFC 1521, Bellcore and Innosoft, September 1993. Obsoletes RFC 1341. 9. Authors' Addresses Jim Galvin email: galvin@tis.com Sandy Murphy email: sandy@tis.com Steve Crocker email: crocker@tis.com Trusted Information Systems 3060 Washington Road Glenwood, MD 21738 Tel: +1 301 854 6889 FAX: +1 301 854 5363 Ned Freed Innosoft International, Inc. 250 West First Street, Suite 240 Claremont, CA 91711 Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 9] INTERNET DRAFT Security Multiparts July 1994 Tel: +1 909 624 7907 FAX: +1 909 621 5319 email: ned@innosoft.com Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 10] INTERNET DRAFT Security Multiparts July 1994 Table of Contents 1 Status of this Memo ............................................. 1 2 Abstract ........................................................ 1 3 Introduction .................................................... 2 4 Definition of Security Subtypes of Multipart .................... 2 4.1 Definition of Multipart/Signed ................................ 2 4.2 Definition of Multipart/Encrypted ............................. 5 5 Definition of Security Subtypes of Application .................. 7 5.1 Application/Signature Content Type ............................ 7 5.2 Application/Keys Content Type ................................. 8 6 Security Considerations ......................................... 9 7 Acknowledgements ................................................ 9 8 References ...................................................... 9 9 Authors' Addresses .............................................. 9 Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 11]