7Network Working Group J. Galvin
8Request For Comments: 1847 S. Murphy
9Category: Standards Track Trusted Information Systems
13 Innosoft International, Inc.
17 Security Multiparts for MIME:
18 Multipart/Signed and Multipart/Encrypted
22 This document specifies an Internet standards track protocol for the
23 Internet community, and requests discussion and suggestions for
24 improvements. Please refer to the current edition of the "Internet
25 Official Protocol Standards" (STD 1) for the standardization state
26 and status of this protocol. Distribution of this memo is unlimited.
30 This document defines a framework within which security services may
31 be applied to MIME body parts. MIME, an acronym for "Multipurpose
32 Internet Mail Extensions", defines the format of the contents of
33 Internet mail messages and provides for multi-part textual and non-
34 textual message bodies. The new content types are subtypes of
35 multipart: signed and encrypted. Each will contain two body parts:
36 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.
44 1. Introduction .............................................. 2
45 2. Definition of Security Subtypes of Multipart .............. 2
46 2.1 Definition of Multipart/Signed .......................... 3
47 2.2 Definition of Multipart/Encrypted ....................... 6
48 3. Definition of Control Information Content Types ........... 9
49 4. Definition of Key Management Content Types ................ 9
50 5. Security Considerations ................................... 10
51 6. Acknowledgements .......................................... 10
52 7. References ................................................ 10
53 8. Authors' Addresses ........................................ 11
58Galvin, et al Standards Track [Page 1]
60RFC 1847 Security Multiparts October 1995
65 An Internet electronic mail message consists of two parts: the
66 headers and the body. The headers form a collection of field/value
67 pairs structured according to STD 11, RFC 822 [1], whilst the body,
68 if structured, is defined according to MIME [2]. The basic MIME
69 specification does not provide specific security protection.
71 This document defines a framework whereby security protection
72 provided by other protocols may be used with MIME in a complementary
73 fashion. By itself, it does not specify security protection. A MIME
74 agent must include support for both the framework defined here and a
75 mechanism to interact with a security protocol defined in a separate
76 document. The resulting combined service provides security for
77 single-part and multi-part textual and non-textual messages.
79 The framework is provided by defining two new security subtypes of
80 the MIME multipart content type: signed and encrypted. In each of
81 the security subtypes, there are exactly two related body parts: one
82 for the protected data and one for the control information. The type
83 and contents of the control information body parts are determined by
84 the value of the protocol parameter of the enclosing multipart/signed
85 or multipart/encrypted content type, which is required to be present.
86 By registering new values for the required protocol parameter, the
87 framework is easily extended to accommodate a variety of protocols.
89 A MIME agent that includes support for this framework will be able to
90 recognize a security multipart body part and to identify its
91 protected data and control information body parts. If the value of
92 the protocol parameter is unrecognized the MIME agent will not be
93 able to process the security multipart. However, a MIME agent may
94 continue to process any other body parts that may be present.
962. Definition of Security Subtypes of Multipart
98 The multipart/signed content type specifies how to support
99 authentication and integrity services via digital signature. The
100 control information is carried in the second of the two required body
103 The multipart/encrypted content type specifies how to support
104 confidentiality via encryption. The control information is carried
105 in the first of the two required body parts.
107 A three-step process is described for the origination and reception
108 of the multipart/signed and multipart/encrypted contents. The
109 details of the processing performed during each step is left to be
110 specified by the security protocol being used.
114Galvin, et al Standards Track [Page 2]
116RFC 1847 Security Multiparts October 1995
1192.1. Definition of Multipart/Signed
121 (1) MIME type name: multipart
123 (2) MIME subtype name: signed
125 (3) Required parameters: boundary, protocol, and micalg
127 (4) Optional parameters: none
129 (5) Security considerations: Must be treated as opaque while in
132 The multipart/signed content type contains exactly two body parts.
133 The first body part is the body part over which the digital signature
134 was created, including its MIME headers. The second body part
135 contains the control information necessary to verify the digital
136 signature. The first body part may contain any valid MIME content
137 type, labeled accordingly. The second body part is labeled according
138 to the value of the protocol parameter.
140 The attribute token for the protocol parameter is "protocol", i.e.,
142 parameter := "protocol" "=" value
144 The value token is comprised of the type and sub-type tokens of the
145 Content-Type: header of the second body part, i.e.,
147 value := <"> type "/" subtype <">
149 where the type and subtype tokens are defined by the MIME [2]
150 specification. The semantics of the protocol parameter are defined
151 according to its value.
153 The attribute token for the micalg parameter is "micalg", i.e.,
155 parameter := "micalg" "=" value
157 The Message Integrity Check (MIC) is the name given to the quantity
158 computed over the body part with a message digest or hash function,
159 in support of the digital signature service. Valid value tokens are
160 defined by the specification for the value of the protocol parameter.
161 The value may be a comma (",") separated list of tokens, indicating
162 the use of multiple MIC algorithms. As a result, the comma (",")
163 character is explicitly excluded from the list of characters that may
164 be included in a token used as a value of the micalg parameter. If
165 multiple MIC algorithms are specified, the purpose and use of the
166 multiple algorithms is defined by the protocol. If the MIC algorithm
170Galvin, et al Standards Track [Page 3]
172RFC 1847 Security Multiparts October 1995
175 is also specified in the control information and the value there does
176 not agree with the value in this parameter, it must be treated as an
179 NOTE: The presence of the micalg parameter on the
180 multipart/signed content type header is explicitly intended to
181 support one-pass processing. MIME implementations may locate
182 the second body part by inputting the first body part and
183 computing the specified MIC values until the boundary
184 identifying the second body part is found.
186 The entire contents of the multipart/signed container must be treated
187 as opaque while it is in transit from an originator to a recipient.
188 Intermediate message transfer agents must not alter the content of a
189 multipart/signed in any way, including, but not limited to, changing
190 the content transfer encoding of the body part or any of its
191 encapsulated body parts.
193 The signature in a multipart/signed only applies to the material that
194 is actually within the multipart/signed object. In particular, it
195 does not apply to any enclosing message material, nor does it apply
196 to entities that are referenced (e.g. via a MIME message/external-
197 body) by rather than included in the signed content.
199 When creating a multipart/signed body part, the following sequence of
200 steps describes the processing necessary. It must be emphasized that
201 these steps are descriptive, not prescriptive, and in no way impose
202 restrictions or requirements on implementations of this
205 (1) The content of the body part to be protected is prepared
206 according to a local convention. The content is then
207 transformed into a MIME body part in canonical MIME format,
208 including an appropriate set of MIME headers.
210 In addition, if the multipart/signed object is EVER to be
211 transferred over the standard Internet SMTP infrastructure, the
212 resulting MIME body is constrained to 7 bits -- that is, the use
213 of material requiring either 8bit or binary
214 content-transfer-encoding is NOT allowed. Such 8bit or binary
215 material MUST be encoded using either the quoted-printable or
218 This requirement exists because it is not generally possible,
219 given the current characteristics of Internet SMTP, for a
220 message originator to guarantee that a message will travel only
221 along paths capable of carrying 8bit or binary material.
226Galvin, et al Standards Track [Page 4]
228RFC 1847 Security Multiparts October 1995
231 SMTP clients normally have the option of either converting the
232 message to eliminate the use of 8bit or binary encoding or
233 returning a nondelivery notification to the originator.
234 However, conversion is not viable in the case of signed objects
235 since conversion would necessarily invalidate the signature.
236 This leaves a nondelivery notification as the only available
237 option, which is not acceptable.
239 (2) The body part (headers and content) to be digitally signed is
240 prepared for signature according to the value of the protocol
241 parameter. The MIME headers of the signed body part are
242 included in the signature to protect the integrity of the MIME
243 labeling of the data that is signed.
245 (3) The prepared body part is made available to the signature creation
246 process according to a local convention. The signature creation
247 process must make available to a MIME implementation two data
248 streams: the control information necessary to verify the
249 signature, which the MIME implementation will place in the second
250 body part and label according to the value of the protocol
251 parameter, and the digitally signed body part, which the MIME
252 implementation will use as the first body part.
254 When receiving a multipart/signed body part, the following sequence
255 of steps describes the processing necessary to verify the signature
256 or signatures. It must be emphasized that these steps are
257 descriptive, not prescriptive, and in no way impose restrictions or
258 requirements on implementations of this specification.
260 (1) The first body part and the control information in the second body
261 part must be prepared for the signature verification process
262 according to the value of the protocol parameter.
264 (2) The prepared body parts must be made available to the signature
265 verification process according to a local convention. The
266 signature verification process must make available to the MIME
267 implementation the result of the signature verification and the
268 body part that was digitally signed.
270 NOTE: The result of the signature verification is likely to
271 include a testament of the success or failure of the
272 verification. Also, in the usual case, the body part
273 returned after signature verification will be the same as
274 the body part that was received. We do not insist that
275 this be the case to allow for protocols that may modify the
276 body part during the signature processing.
282Galvin, et al Standards Track [Page 5]
284RFC 1847 Security Multiparts October 1995
287 (3) The result of the signature verification process is made available
288 to the user and the MIME implementation continues processing with
289 the verified body part, i.e., the body part returned by the
290 signature verification process.
292 The following example is an illustration of a multipart/signed body
293 part. It is necessarily incomplete since the control information is
294 defined by the security protocol, which must be specified in a
297 Content-Type: multipart/signed; protocol="TYPE/STYPE";
298 micalg="MICALG"; boundary="Signed Boundary"
301 Content-Type: text/plain; charset="us-ascii"
303 This is some text to be signed although it could be
304 any type of data, labeled accordingly, of course.
307 Content-Type: TYPE/STYPE
309 CONTROL INFORMATION for protocol "TYPE/STYPE" would be here
3132.2. Definition of Multipart/Encrypted
315 (1) MIME type name: multipart
317 (2) MIME subtype name: encrypted
319 (3) Required parameters: boundary, protocol
321 (4) Optional parameters: none
323 (5) Security considerations: none
325 The multipart/encrypted content type contains exactly two body parts.
326 The first body part contains the control information necessary to
327 decrypt the data in the second body part and is labeled according to
328 the value of the protocol parameter. The second body part contains
329 the data which was encrypted and is always labeled
330 application/octet-stream.
332 The attribute token for the protocol parameter is "protocol", i.e.,
334 parameter := "protocol" "=" value
338Galvin, et al Standards Track [Page 6]
340RFC 1847 Security Multiparts October 1995
343 The value token is comprised of the type and sub-type tokens of the
344 Content-Type: header of the first body part, i.e.,
346 value := <"> type "/" subtype <">
348 where the type and subtype tokens are defined by the MIME [2]
349 specification. The semantics of the protocol parameter are defined
350 according to its value.
352 When creating a multipart/encrypted body part, the following sequence
353 of steps describes the processing necessary. It must be emphasized
354 that these steps are descriptive, not prescriptive, and in no way
355 impose restrictions or requirements on implementations of this
358 (1) The contents of the body part to be protected is prepared according
359 to a local convention. The contents are then transformed into a
360 MIME body part in canonical MIME format, including an appropriate
363 (2) The body part (headers and content) to be encrypted is prepared for
364 encryption according to the value of the protocol parameter. The
365 MIME headers of the encrypted body part are included in the
366 encryption to protect from disclosure the MIME labeling of the
367 data that is encrypted.
369 (3) The prepared body part is made available to the encryption process
370 according to a local convention. The encryption process must make
371 available to a MIME implementation two data streams: the control
372 information necessary to decrypt the body part, which the MIME
373 implementation will place in the first body part and label
374 according to the value of the protocol parameter, and the
375 encrypted body part, which the MIME implementation will place in
376 the second body part and label application/octet-stream. Thus,
377 when used in a multipart/encrypted, the application/octet-stream
378 data is comprised of a nested MIME body part.
380 When receiving a multipart/encrypted body part, the following
381 sequence of steps describes the processing necessary to decrypt the
382 enclosed data. It must be emphasized that these steps are
383 descriptive, not prescriptive, and in no way impose restrictions or
384 requirements on implementations of this specification.
386 (1) The second body part and the control information in the first body
387 part must be prepared for the decryption process according to the
388 value of the protocol parameter.
394Galvin, et al Standards Track [Page 7]
396RFC 1847 Security Multiparts October 1995
399 (2) The prepared body parts must be made available to the decryption
400 process according to a local convention. The decryption process
401 must make available to the MIME implementation the result of the
402 decryption and the decrypted form of the encrypted body part.
404 NOTE: The result of the decryption process is likely to
405 include a testament of the success or failure of the
406 decryption. Failure may be due to an inability to locate
407 the proper decryption key or the proper recipient field,
408 etc. Implementors should note that the data, if any, of a
409 failed decryption process is pretty much guaranteed to be
412 (3) The result of the decryption process is made available to the user
413 and the MIME implementation continues processing with the decrypted
414 body part, i.e., the body part returned by the decryption process.
416 NOTE: A MIME implementation will not be able to display the
417 received form of the second body part because the
418 application of encryption will transform the body part.
419 This transformation will not be described in the MIME
420 headers (Content-Type: and Content-Transfer-Encoding:) but,
421 rather, will be described in the content of the first body
422 part. Therefore, an implementation should wait until the
423 encryption has been removed before attempting to display
426 The following example is an illustration of a multipart/encrypted
427 body part. It is necessarily incomplete since the control
428 information is defined by the security protocol, which must be
429 specified in a separate document.
431 Content-Type: multipart/encrypted; protocol="TYPE/STYPE";
432 boundary="Encrypted Boundary"
435 Content-Type: TYPE/STYPE
437 CONTROL INFORMATION for protocol "TYPE/STYPE" would be here
440 Content-Type: application/octet-stream
442 Content-Type: text/plain; charset="us-ascii"
450Galvin, et al Standards Track [Page 8]
452RFC 1847 Security Multiparts October 1995
455 All of this indented text, including the indented headers,
456 would be unreadable since it would have been encrypted by
457 the protocol "TYPE/STYPE". Also, this encrypted data could
458 be any type of data, labeled accordingly, of course.
460 --Encrypted Boundary--
4623. Definition of Control Information Content Types
464 This document defines a framework within which security services may
465 be applied to MIME body parts. A minimal MIME implementation will be
466 able to recognize multipart/signed and multipart/encrypted body parts
467 and be able to identify the protected data and control information
468 body parts within them.
470 Complete support for security services requires the MIME agent to
471 recognize the value of the protocol parameter and to continue
472 processing based on its value. The value of the protocol parameter
473 is the same value used to label the content type of the control
476 The value of the protocol parameter and the resulting processing
477 required must be specified in the document defining the security
478 protocol used. That document must also precisely specify the
479 contents of the control information body part.
4814. Definition of Key Management Content Types
483 This specification recognizes that the complete specification of a
484 MIME-based security protocol must include a mechanism for
485 distributing the cryptographic material used in support of the
486 security services. For example, a digital signature service
487 implemented with asymmetric cryptography requires that a signer's
488 public key be available to the signee.
490 One possible mechanism for distributing cryptographic material is to
491 define two additional body parts: one for the purpose of requesting
492 cryptographic information and one for the purpose of returning the
493 cryptographic information requested. The specification of a security
494 protocol may include a definition of two such body parts or it may
495 specify an alternate mechanism for the distribution of cryptographic
506Galvin, et al Standards Track [Page 9]
508RFC 1847 Security Multiparts October 1995
5115. Security Considerations
513 This specification describes an enhancement to MIME to support signed
514 and encrypted body parts. In that context this entire document is
519 David H. Crocker suggested the use of a multipart structure for the
520 MIME and PEM interaction.
524 [1] Crocker, D., "Standard for the Format of ARPA Internet Text
525 Messages", STD 11, RFC 822, University of Delaware, August 1982.
527 [2] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
528 Extension) Part One: Mechanisms for Specifying and Describing the
529 Format of Internet Message Bodies", RFC 1521, Bellcore and
530 Innosoft, September 1993.
562Galvin, et al Standards Track [Page 10]
564RFC 1847 Security Multiparts October 1995
570 Trusted Information Systems
574 Phone: +1 301 854 6889
576 EMail: galvin@tis.com
580 Trusted Information Systems
584 Phone: +1 301 854 6889
591 2086 Hunters Crest Way
594 Phone:: +1 703 620 1222
596 EMail: crocker@cybercash.com
600 Innosoft International, Inc.
601 1050 East Garvey Avenue South
602 West Covina, CA 91790
604 Phone: +1 818 919 3600
606 EMail: ned@innosoft.com
618Galvin, et al Standards Track [Page 11]