idnits 2.17.00 (12 Aug 2021) /tmp/idnits40338/draft-ietf-pem-sigenc-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-14) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1994) is 10042 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 822 (ref. '1') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1341 (ref. '2') (Obsoleted by RFC 1521) Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jim Galvin 3 INTERNET DRAFT Sandy Murphy 4 draft-ietf-pem-sigenc-02.txt Steve Crocker 5 Ned Freed 6 November 1994 8 Security Multiparts for MIME: 9 Multipart/Signed and Multipart/Encrypted 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, and 15 its Working Groups. Note that other groups may also distribute working 16 documents as Internet Drafts. 18 Internet Drafts are valid for a maximum of six months and may be 19 updated, replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet Drafts as reference material or to cite 21 them other than as ``work in progress''. 23 To learn the current status of any Internet Draft, please check the 24 1id-abstracts.txt listing contained in one of the Internet Drafts Shadow 25 Directories on ds.internic.net (US East Coast), venera.isi.edu (US West 26 Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe). 28 Abstract 30 This document defines two new content types for specifying the 31 application of security services to MIME message bodies. MIME, an 32 acronym for "Multipurpose Internet Mail Extensions", defines the format 33 of the contents of Internet mail messages and provides for multi-part 34 textual and non-textual message bodies. The new content types are 35 subtypes of multipart: signed and encrypted. Each will contain two body 36 parts: one for the protected data and one for the control information 37 necessary to remove the protection. The type and contents of the 38 control information body parts are determined by the value of the 39 protocol parameter of the enclosing multipart/signed or 40 multipart/encrypted content type, which is required to be present. 42 1. Introduction 44 An Internet electronic mail message consists of two parts: the headers 45 and the body. The headers form a collection of field/value pairs 46 structured according to RFC822 [1], whilst the body, if structured, is 47 defined according to MIME [2]. The basic MIME specification does not 48 provide specific security protection. 50 This document defines a framework whereby security protection provided 51 by other protocols may be used with MIME in a complementary fashion. 52 The resulting combined service provides security for single-part and 53 multi-part textual and non-textual messages. 55 The framework is provided by defining two new security subtypes of the 56 MIME multipart content type: signed and encrypted. In each of the 57 security subtypes, there are exactly two related body parts: one for the 58 protected data and one for the control information. This should allow 59 the framework to be used by all protocols providing signature and 60 encryption services. 62 A three-step process is specified for the origination and reception of 63 the multipart contents. The details of the processing performed during 64 each step is specified by the protocol being used. 66 By registering new values for the required protocol parameter, the 67 framework is easily extended to accommodate a variety of protocols. 69 A MIME agent that includes support for this framework will be able to 70 parse protected body parts, even when the value of the protocol 71 parameter is unrecognized and the body part can not be displayed to the 72 user. 74 2. Definition of Security Subtypes of Multipart 76 The multipart/signed content type specifies how to support 77 authentication and integrity services via digital signature. The 78 control information is carried in the second of the two required body 79 parts. 81 The multipart/encrypted content type specifies how to support 82 confidentiality via encryption. The control information is carried in 83 the first of the two required body parts. 85 2.1. Definition of Multipart/Signed 87 (1) MIME type name: multipart 89 (2) MIME subtype name: signed 91 (3) Required parameters: boundary, protocol, and micalg 93 (4) Optional parameters: none 95 (5) Encoding considerations: 7bit, 8bit, or binary depending on 96 transport requirements and encoding of the digitally signed data 98 (6) Security considerations: Must be treated as opaque while in transit 100 The multipart/signed content type contains exactly two body parts. The 101 first body part is the body part over which the digital signature was 102 created, including its content type label. The second body part 103 contains the control information necessary to verify the digital 104 signature. The first body part may contain any valid MIME content type, 105 labelled accordingly. The second body part is labelled according to the 106 value of the protocol parameter. 108 The attribute token for the protocol parameter is "protocol", i.e., 110 parameter := "protocol" "=" value 112 The value token is comprised of the type and sub-type tokens of the 113 Content-Type: header of the second body part, i.e., 115 value := type "/" subtype 117 where the type and subtype tokens are defined by the MIME [2] 118 specification. The semantics of the protocol parameter are defined 119 according to its value. 121 The attribute token for the micalg parameter is "micalg", i.e., 123 parameter := "micalg" "=" value 125 The Message Integrity Check (MIC) is the name given to the quantity 126 computed over the body part with a message digest or hash function, in 127 support of the digital signature service. Valid value tokens are 128 defined by the specification for the value of the protocol parameter. 129 The value may be a comma (",") separated list of tokens, indicating the 130 presence of multiple MIC algorithms. As a result, the comma (",") 131 character is explicitly excluded from the list of characters that may be 132 included in a token used as a value of the micalg parameter. If 133 multiple MIC algorithms are specified, the purpose and use of the 134 multiple algorithms is defined by the protocol. If the MIC algorithm is 135 also specified in the control information and the value there does not 136 agree with the value in this parameter, it must be treated as an error. 138 NOTE: The presence of the micalg parameter on the 139 multipart/signed content type header is explicitly intended to 140 support one-pass processing. MIME implementations may locate 141 the second body part by inputting the first body part and 142 computing the specified MIC values until the boundary 143 identifying the second body part is found. 145 The entire multipart/signed body part must be treated as opaque while it 146 is in transit from an originator to a recipient. Intermediate message 147 transfer agents must not alter the content of a multipart/signed in any 148 way, including, but not limited to, changing the content transfer 149 encoding of the body part or any of its encapsulated body parts. 151 When creating a multipart/signed body part, the following sequence of 152 steps describes the processing necessary. It must be emphasized that 153 these steps are descriptive, not prescriptive, and in no way impose 154 restrictions or requirements on implementations of this specification. 156 (1) The content of the body part to be protected is prepared according 157 to a local convention. The content is then transformed into a MIME 158 body part, including an appropriate set of headers. 160 (2) The body part (content and headers) to be digitally signed is 161 prepared for signature according to the value of the protocol 162 parameter. The MIME headers of the signed body part are included 163 in the signature to protect the integrity of the MIME labelling of 164 the data that is signed. 166 (3) The prepared body part is made available to the signature creation 167 process according to a local convention. The signature creation 168 process must make available to a MIME implementation two data 169 streams: the control information necessary to verify the signature, 170 which the MIME implementation will place in the second body part, 171 and the digitally signed body part, which the MIME implementation 172 will use as the first body part. 174 When receiving a multipart/signed body part, the following sequence of 175 steps describes the processing necessary. It must be emphasized that 176 these steps are descriptive, not prescriptive, and in no way impose 177 restrictions or requirements on implementations of this specification. 179 (1) The first body part and the control information in the second body 180 part must be prepared for the signature verification process 181 according to the value of the protocol parameter. 183 (2) The prepared body parts must be made available to the signature 184 verification process according to a local convention. The 185 signature verification process must make available to the MIME 186 implementation the result of the signature verification and the 187 body part that was digitally signed. 189 NOTE: The result of the signature verification is likely to 190 include a testament of the success or failure of the 191 verification. Also, in the usual case, the body part 192 returned after signature verification will be the same as 193 the body part that was received. We do not insist that 194 this be the case to allow for protocols that may modify the 195 body part during the signature processing. 197 (3) The result of the signature verification process is made available 198 to the user and the MIME implementation continues processing with 199 the verified body part, i.e., the body part returned by the 200 signature verification process. 202 2.2. Definition of Multipart/Encrypted 204 (1) MIME type name: multipart 206 (2) MIME subtype name: encrypted 208 (3) Required parameters: boundary, protocol 210 (4) Optional parameters: none 212 (5) Encoding considerations: 7bit, 8bit, or binary depending on 213 transport requirements and encoding of the encrypted data 215 (6) Security considerations: none 217 The multipart/encrypted content type contains exactly two body parts. 218 The first body part contains the control information necessary to 219 decrypt the data in the second body part and is labelled according to 220 the value of the protocol parameter. The second body part contains the 221 data which was encrypted and is always labelled application/octet- 222 stream. 224 The attribute token for the protocol parameter is "protocol", i.e., 226 parameter := "protocol" "=" value 228 The value token is comprised of the type and sub-type tokens of the 229 Content-Type: header of the first body part, i.e., 231 value := type "/" subtype 233 where the type and subtype tokens are defined by the MIME [2] 234 specification. The semantics of the protocol parameter are defined 235 according to its value. 237 When creating a multipart/encrypted body part, the following sequence of 238 steps describes the processing necessary. It must be emphasized that 239 these steps are descriptive, not prescriptive, and in no way impose 240 restrictions or requirements on implementations of this specification. 242 (1) The contents of the body part to be protected is prepared according 243 to a local convention. The contents are then transformed into a 244 MIME body part, including an appropriate set of headers. 246 (2) The body part (content and headers) to be encrypted is prepared for 247 encryption according to the value of the protocol parameter. The 248 MIME headers of the encrypted body part are included in the 249 encryption to protect from disclosure the MIME labelling of the 250 data that is encrypted. 252 (3) The prepared body part is made available to the encryption process 253 according to a local convention. The encryption process must make 254 available to a MIME implementation two data streams: the control 255 information necessary to decrypt the body part, which the MIME 256 implementation will place in the first body part, and the encrypted 257 body part, which the MIME implementation will place in the second 258 body part and label application/octet-stream. Thus, when used in a 259 multipart/encrypted, the application/octet-stream data is comprised 260 of a nested MIME body part. 262 When receiving a multipart/encrypted body part, the following sequence 263 of steps describes the processing necessary. It must be emphasized that 264 these steps are descriptive, not prescriptive, and in no way impose 265 restrictions or requirements on implementations of this specification. 267 (1) The second body part and the control information in the first body 268 part must be prepared for the decryption process according to the 269 value of the protocol parameter. 271 (2) The prepared body parts must be made available to the decryption 272 process according to a local convention. The decryption process 273 must make available to the MIME implementation the result of the 274 decryption and the decrypted form of the encrypted body part. 276 NOTE: The result of the decryption process is likely to 277 include a testament of the success or failure of the 278 decryption. Failure may be due to an inability to locate 279 the proper decryption key or the proper recipient field, 280 etc. 282 (3) The result of the decryption process is made available to the user 283 and the MIME implementation continues processing with the decrypted 284 body part, i.e., the body part returned by the decryption process. 286 NOTE: A MIME implementation will not be able to display the 287 received form of the second body part because the 288 application of encryption will transform the body part. 289 This transformation will not be described in the MIME 290 headers (Content-Type: and Content-Transfer-Encoding:) but, 291 rather, will be described in the content of the first body 292 part. Therefore, an implementation should wait until the 293 encryption has been removed before attempting to display 294 the content. 296 3. Definition of Control Information Content Types 298 This document requires the definition of two additional content types, 299 one each for when a digital signature is applied to a body part and for 300 when encryption is applied to a body part. These content types are to 301 be used in multipart/signed and multipart/encrypted body parts, 302 respectively, as indicated above. Their definition must be included in 303 the specification defining the use of the security protocol indicated in 304 the protocol parameter. 306 4. Definition of Key Management Content Types 308 It is recognized that many cryptographic techniques require a mechanism 309 for distributing the cryptographic keys used in support of their 310 services. As a result, many security protocols will define two 311 additional body parts: one for the purpose of requesting cryptographic 312 keys and one for the purpose of distributing cryptographic keys. 314 5. Security Considerations 316 This specification describes an enhancement to MIME to support signed 317 and encrypted body parts. In that context this entire document is about 318 security. 320 6. Acknowledgements 322 David H. Crocker suggested the use of a multipart structure for MIME-PEM 323 interaction. 325 7. References 327 [1] David H. Crocker. Standard for the Format of ARPA Internet Text 328 Messages. RFC 822, University of Delaware, August 1982. 330 [2] Nathaniel Borenstein and Ned Freed. MIME (Multipurpose Internet 331 Mail Extension) Part One: Mechanisms for Specifying and Describing 332 the Format of Internet Message Bodies. RFC 1521, Bellcore and 333 Innosoft, September 1993. Obsoletes RFC 1341. 335 8. Authors' Addresses 337 Jim Galvin 338 email: galvin@tis.com 340 Sandy Murphy 341 email: sandy@tis.com 343 Steve Crocker 344 email: crocker@tis.com 346 Trusted Information Systems 347 3060 Washington Road 348 Glenwood, MD 21738 349 Tel: +1 301 854 6889 350 FAX: +1 301 854 5363 352 Ned Freed 353 Innosoft International, Inc. 354 1050 East Garvey Avenue South 355 West Covina, CA 91790 356 Tel: +1 818 919 3600 357 FAX: +1 818 919 3614 358 email: ned@innosoft.com 359 Table of Contents 361 Status of this Memo ............................................. 1 362 Abstract ........................................................ 1 363 1 Introduction ................................................... 2 364 2 Definition of Security Subtypes of Multipart ................... 2 365 2.1 Definition of Multipart/Signed ............................... 3 366 2.2 Definition of Multipart/Encrypted ............................ 5 367 3 Definition of Control Information Content Types ................ 7 368 4 Definition of Key Management Content Types ..................... 8 369 5 Security Considerations ........................................ 8 370 6 Acknowledgements ............................................... 8 371 7 References ..................................................... 8 372 8 Authors' Addresses ............................................. 8