view Side-By-Side changes
Date: Tue, 09 Apr 2002 06:10:27 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 22 Nov 1994 23:00:00 GMT ETag: "304ba6-47bb-2ed277f0" Accept-Ranges: bytes Content-Length: 18363 Connection: close Content-Type: text/plain Network Working GroupJimJ. GalvinINTERNET DRAFT SandyRequest For Comments: 1847 S. Murphydraft-ietf-pem-sigenc-02.txt SteveCategory: Standards Track Trusted Information Systems S. CrockerNedCyberCash, Inc. N. FreedNovember 1994Innosoft International, Inc. October 1995 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted Status of this Memo This documentisspecifies an InternetDraft. Internet Drafts are working documents ofstandards track protocol for the InternetEngineering Task Force (IETF), its Areas,community, andits Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six monthsrequests discussion andmay be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material orsuggestions for improvements. Please refer tocite them other than as ``work in progress''. To learnthe current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status ofany Internet Draft, please check the 1id-abstracts.txt listing contained in onethis protocol. Distribution ofthe 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).this memo is unlimited. Abstract This document definestwo new content types for specifying the application ofa framework within which security services may be applied to MIMEmessage bodies.body parts. MIME, an acronym for "Multipurpose Internet Mail Extensions", defines the format of the contents of Internet mail messages and provides for multi-part textual andnon-textualnon- 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. The type and contents of the control information body parts are determined by the value of the protocol parameter of the enclosing multipart/signed or multipart/encrypted content type, which is required to be present.Galvin/Murphy/Crocker/Freed Expires: May 1995Table of Contents 1. Introduction .............................................. 2 2. Definition of Security Subtypes of Multipart .............. 2 2.1 Definition of Multipart/Signed .......................... 3 2.2 Definition of Multipart/Encrypted ....................... 6 3. Definition of Control Information Content Types ........... 9 4. Definition of Key Management Content Types ................ 9 5. Security Considerations ................................... 10 6. Acknowledgements .......................................... 10 7. References ................................................ 10 8. Authors' Addresses ........................................ 11 Galvin, et al Standards Track [Page 1]INTERNET DRAFTRFC 1847 Security MultipartsNovember 1994October 1995 1. 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 toRFC822STD 11, RFC 822 [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. By itself, it does not specify security protection. A MIME agent must include support for both the framework defined here and a mechanism to interact with a security protocol defined in a separate document. 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 allowThe type and contents of theframework to be usedcontrol information body parts are determined byall protocols providing signature and encryption services. A three-step process is specified fortheorigination and receptionvalue of themultipart contents. The detailsprotocol parameter of theprocessing performed during each stepenclosing multipart/signed or multipart/encrypted content type, which isspecified by the protocol being used.required to be present. By registering new values for the required protocol parameter, the framework is easily extended to accommodate a variety of protocols. A MIME agent that includes support for this framework will be able toparserecognize a security multipart body part and to identify its protected data and control information bodyparts, even whenparts. If the value of the protocol parameter is unrecognizedandthebody part canMIME agent will not bedisplayedable to process theuser.security multipart. However, a MIME agent may continue to process any other body parts that may be present. 2. 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 the second of the two required body parts. The multipart/encrypted content type specifies how to support confidentiality via encryption. The control information is carried in the first of the two required body parts.Galvin/Murphy/Crocker/Freed Expires: May 1995A three-step process is described for the origination and reception of the multipart/signed and multipart/encrypted contents. The details of the processing performed during each step is left to be specified by the security protocol being used. Galvin, et al Standards Track [Page 2]INTERNET DRAFTRFC 1847 Security MultipartsNovember 1994October 1995 2.1. Definition of Multipart/Signed (1) MIME type name: multipart (2) MIME subtype name: signed (3) Required parameters: boundary, protocol, and micalg (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 itscontent type label.MIME headers. The second body part contains the control information necessary to verify the digital signature. The first body part may contain any valid MIME content type,labelledlabeled accordingly. The second body part islabelledlabeled according to the value of the protocol parameter. The attribute token for the protocol parameter is "protocol", i.e., parameter := "protocol" "=" value The value token is comprised of the type and sub-type tokens of the Content-Type: header of the second body part, i.e., value := <"> type "/" subtype <"> where the type and subtype tokens are defined by the MIME [2] specification. The semantics of the protocol parameter are defined according to its value. The attribute token for the micalg parameter is "micalg", i.e., parameter := "micalg" "=" value The Message Integrity Check (MIC) is the name given to the quantity computed over the body part with a message digest or hash function, in support of the digital signature service. Valid value tokens areGalvin/Murphy/Crocker/Freed Expires: May 1995 [Page 3] INTERNET DRAFT Security Multiparts November 1994defined by the specification for the value of the protocol parameter. The value may be a comma (",") separated list of tokens, indicating thepresenceuse of multiple MIC algorithms. 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 micalg parameter. If multiple MIC algorithms are specified, the purpose and use of the multiple algorithms is defined by the protocol. If the MIC algorithm Galvin, et al Standards Track [Page 3] RFC 1847 Security Multiparts October 1995 is also specified in the control information and the value there does not agree with the value in this parameter, it must be treated as an error. NOTE: The presence of the micalg 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 MIC values until the boundary identifying the second body part is found. The entire contents of the multipart/signedbody partcontainer 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 of the body part or any of its encapsulated body parts. The signature in a multipart/signed only applies to the material that is actually within the multipart/signed object. In particular, it does not apply to any enclosing message material, nor does it apply to entities that are referenced (e.g. via a MIME message/external- body) by rather than included in the signed content. 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 content of the body part to be protected is prepared according to a local convention. The content is then transformed into a MIME bodypart,part in canonical MIME format, including an appropriate set of MIME headers. In addition, if the multipart/signed object is EVER to be transferred over the standard Internet SMTP infrastructure, the resulting MIME body is constrained to 7 bits -- that is, the use of material requiring either 8bit or binary content-transfer-encoding is NOT allowed. Such 8bit or binary material MUST be encoded using either the quoted-printable or base64 encodings. This requirement exists because it is not generally possible, given the current characteristics of Internet SMTP, for a message originator to guarantee that a message will travel only along paths capable of carrying 8bit or binary material. Galvin, et al Standards Track [Page 4] RFC 1847 Security Multiparts October 1995 SMTP clients normally have the option of either converting the message to eliminate the use of 8bit or binary encoding or returning a nondelivery notification to the originator. However, conversion is not viable in the case of signed objects since conversion would necessarily invalidate the signature. This leaves a nondelivery notification as the only available option, which is not acceptable. (2) The body part(content(headers andheaders)content) to be digitally signed is prepared for signature according to the value of the protocol parameter. The MIME headers of the signed body part are included in the signature to protect the integrity of the MIMElabellinglabeling 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 bodypart,part and label according to the value of the protocol parameter, and the digitally signed body part, which the MIME implementationGalvin/Murphy/Crocker/Freed Expires: May 1995 [Page 4] INTERNET DRAFT Security Multiparts November 1994will use as the first body part. When receiving a multipart/signed body part, the following sequence of steps describes the processingnecessary.necessary to verify the signature or signatures. 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 the signature verification process according to the 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. Galvin, et al Standards Track [Page 5] RFC 1847 Security Multiparts October 1995 (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.2.2. DefinitionThe following example is an illustration of a multipart/signed body part. It is necessarily incomplete since the control information is defined by the security protocol, which must be specified in a separate document. Content-Type: multipart/signed; protocol="TYPE/STYPE"; micalg="MICALG"; boundary="Signed Boundary" --Signed Boundary Content-Type: text/plain; charset="us-ascii" This is some text to be signed although it could be any type of data, labeled accordingly, of course. --Signed Boundary Content-Type: TYPE/STYPE CONTROL INFORMATION for protocol "TYPE/STYPE" would be here --Signed Boundary-- 2.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 Galvin/Murphy/Crocker/Freed Expires: May 1995 [Page 5] INTERNET DRAFT Security Multiparts November 1994 (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 islabelledlabeled according to the value of the protocol parameter. The second body part contains the data which was encrypted and is alwayslabelled application/octet- stream.labeled application/octet-stream. The attribute token for the protocol parameter is "protocol", i.e., parameter := "protocol" "=" value Galvin, et al Standards Track [Page 6] RFC 1847 Security Multiparts October 1995 The value token is comprised of the type and sub-type tokens of the Content-Type: header of the first body part, i.e., value := <"> type "/" subtype <"> where the type and subtype tokens are defined by the MIME [2] specification. 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 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 bodypart,part in canonical MIME format, including an appropriate set of MIME headers. (2) The body part(content(headers andheaders)content) to be encrypted is prepared for encryption according to the value of the protocol parameter. The MIME headers of the encrypted body part are included in the encryption to protect from disclosure the MIMElabellinglabeling 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 bodypart,part and label according to the value of the protocol parameter, 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 aGalvin/Murphy/Crocker/Freed Expires: May 1995 [Page 6] INTERNET DRAFT Security Multiparts November 1994multipart/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 processingnecessary.necessary to decrypt the enclosed data. 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 the decryption process according to the value of the protocol parameter. Galvin, et al Standards Track [Page 7] RFC 1847 Security Multiparts October 1995 (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. Implementors should note that the data, if any, of a failed decryption process is pretty much guaranteed to be garbage. (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. The following example is an illustration of a multipart/encrypted body part. It is necessarily incomplete since the control information is defined by the security protocol, which must be specified in a separate document. Content-Type: multipart/encrypted; protocol="TYPE/STYPE"; boundary="Encrypted Boundary" --Encrypted Boundary Content-Type: TYPE/STYPE CONTROL INFORMATION for protocol "TYPE/STYPE" would be here --Encrypted Boundary Content-Type: application/octet-stream Content-Type: text/plain; charset="us-ascii" Galvin, et al Standards Track [Page 8] RFC 1847 Security Multiparts October 1995 All of this indented text, including the indented headers, would be unreadable since it would have been encrypted by the protocol "TYPE/STYPE". Also, this encrypted data could be any type of data, labeled accordingly, of course. --Encrypted Boundary-- 3. Definition of Control Information Content Types This documentrequires the definition of two additional content types, one each for whendefines adigital signature isframework within which security services may be applied toaMIME bodypartparts. A minimal MIME implementation will be able to recognize multipart/signed andfor when encryption is appliedmultipart/encrypted body parts and be able toaidentify the protected data and control information bodypart. These content types areparts within them. Complete support for security services requires the MIME agent toberecognize the value of the protocol parameter and to continue processing based on its value. The value of the protocol parameter is the same value usedin multipart/signedto label the content type of the control information. The value of the protocol parameter andmultipart/encrypted body parts, Galvin/Murphy/Crocker/Freed Expires: May 1995 [Page 7] INTERNET DRAFT Security Multiparts November 1994 respectively, as indicated above. Their definitionthe resulting processing required must beincludedspecified in thespecificationdocument defining theuse of thesecurity protocolindicated inused. That document must also precisely specify theprotocol parameter.contents of the control information body part. 4. Definition of Key Management Content TypesIt is recognizedThis specification recognizes thatmany cryptographic techniques requirethe complete specification of a MIME-based security protocol must include a mechanism for distributing the cryptographickeysmaterial used in support oftheirthe security services.AsFor example, aresult, many security protocols willdigital signature service implemented with asymmetric cryptography requires that a signer's public key be available to the signee. One possible mechanism for distributing cryptographic material is to define two additional body parts: one for the purpose of requesting cryptographickeysinformation and one for the purpose ofdistributingreturning the cryptographickeys.information requested. The specification of a security protocol may include a definition of two such body parts or it may specify an alternate mechanism for the distribution of cryptographic material. Galvin, et al Standards Track [Page 9] RFC 1847 Security Multiparts October 1995 5. 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. 6. Acknowledgements David H. Crocker suggested the use of a multipart structure forMIME-PEMthe MIME and PEM interaction. 7. References [1]David H. Crocker. StandardCrocker, D., "Standard for the Format of ARPA Internet TextMessages.Messages", STD 11, RFC 822, University of Delaware, August 1982. [2]Nathaniel BorensteinBorenstein, N., andNed Freed. MIMEN. Freed, "MIME (Multipurpose Internet Mail Extension) Part One: Mechanisms for Specifying and Describing the Format of Internet MessageBodies.Bodies", RFC 1521, Bellcore and Innosoft, September 1993.ObsoletesGalvin, et al Standards Track [Page 10] RFC1341.1847 Security Multiparts October 1995 8. Authors' Addresses Jim Galvinemail:Trusted Information Systems 3060 Washington Road Glenwood, MD 21738 Phone: +1 301 854 6889 Fax: +1 301 854 5363 EMail: galvin@tis.com Sandy Murphyemail: sandy@tis.com Steve Crocker email: crocker@tis.comTrusted Information SystemsGalvin/Murphy/Crocker/Freed Expires: May 1995 [Page 8] INTERNET DRAFT Security Multiparts November 19943060 Washington Road Glenwood, MD 21738Tel:Phone: +1 301 854 6889FAX:Fax: +1 301 854 5363 EMail: sandy@tis.com Steve Crocker CyberCash, Inc. 2086 Hunters Crest Way Vienna, VA 22181 Phone:: +1 703 620 1222 Fax: +1 703 391 2651 EMail: crocker@cybercash.com Ned Freed Innosoft International, Inc. 1050 East Garvey Avenue South West Covina, CA 91790Tel:Phone: +1 818 919 3600FAX:Fax: +1 818 919 3614email:EMail: ned@innosoft.comGalvin/Murphy/Crocker/Freed Expires: May 1995Galvin, et al Standards Track [Page9] INTERNET DRAFT Security Multiparts November 1994 Table of Contents Status of this Memo ............................................. 1 Abstract ........................................................ 1 1 Introduction ................................................... 2 2 Definition of Security Subtypes of Multipart ................... 2 2.1 Definition of Multipart/Signed ............................... 3 2.2 Definition of Multipart/Encrypted ............................ 5 3 Definition of Control Information Content Types ................ 7 4 Definition of Key Management Content Types ..................... 8 5 Security Considerations ........................................ 8 6 Acknowledgements ............................................... 8 7 References ..................................................... 8 8 Authors' Addresses ............................................. 8 Galvin/Murphy/Crocker/Freed Expires: May 1995 [Page 10]11] ----