summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1847.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1847.txt')
-rw-r--r--doc/rfc/rfc1847.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc1847.txt b/doc/rfc/rfc1847.txt
new file mode 100644
index 0000000..4c5a9e8
--- /dev/null
+++ b/doc/rfc/rfc1847.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group J. Galvin
+Request For Comments: 1847 S. Murphy
+Category: Standards Track Trusted Information Systems
+ S. Crocker
+ CyberCash, Inc.
+ N. Freed
+ Innosoft International, Inc.
+ October 1995
+
+
+ Security Multiparts for MIME:
+ Multipart/Signed and Multipart/Encrypted
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ This document defines a framework within which security services may
+ be applied to MIME 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 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. 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.
+
+Table 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]
+
+RFC 1847 Security Multiparts October 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 to STD 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. 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.
+ 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 to
+ recognize a security multipart body part and to identify its
+ protected data and control information body parts. If the value of
+ the protocol parameter is unrecognized the MIME agent will not be
+ able to process the 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.
+
+ A 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]
+
+RFC 1847 Security Multiparts October 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) 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 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, labeled accordingly. The second body part is labeled 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 are
+ defined by the specification for the value of the protocol parameter.
+ The value may be a comma (",") separated list of tokens, indicating
+ the use 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/signed container 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 body 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 (headers and 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 MIME
+ labeling 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 label according to the value of the protocol
+ parameter, 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 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.
+
+ The 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) 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 labeled according to
+ the value of the protocol parameter. The second body part contains
+ the data which was encrypted and is always 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 body part in canonical MIME format, including an appropriate
+ set of MIME headers.
+
+ (2) The body part (headers and 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 MIME labeling 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 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 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 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 document defines a framework within which security services may
+ be applied to MIME body parts. A minimal MIME implementation will be
+ able to recognize multipart/signed and multipart/encrypted body parts
+ and be able to identify the protected data and control information
+ body parts within them.
+
+ Complete support for security services requires the MIME agent to
+ recognize the value of the protocol parameter and to continue
+ processing based on its value. The value of the protocol parameter
+ is the same value used to label the content type of the control
+ information.
+
+ The value of the protocol parameter and the resulting processing
+ required must be specified in the document defining the security
+ protocol used. That document must also precisely specify the
+ contents of the control information body part.
+
+4. Definition of Key Management Content Types
+
+ This specification recognizes that the complete specification of a
+ MIME-based security protocol must include a mechanism for
+ distributing the cryptographic material used in support of the
+ security services. For example, a digital 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
+ cryptographic information and one for the purpose of returning the
+ cryptographic 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 for the
+ MIME and PEM interaction.
+
+7. References
+
+ [1] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+ [2] Borenstein, N., and N. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galvin, et al Standards Track [Page 10]
+
+RFC 1847 Security Multiparts October 1995
+
+
+8. Authors' Addresses
+
+ Jim Galvin
+ Trusted Information Systems
+ 3060 Washington Road
+ Glenwood, MD 21738
+
+ Phone: +1 301 854 6889
+ Fax: +1 301 854 5363
+ EMail: galvin@tis.com
+
+
+ Sandy Murphy
+ Trusted Information Systems
+ 3060 Washington Road
+ Glenwood, MD 21738
+
+ Phone: +1 301 854 6889
+ 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 91790
+
+ Phone: +1 818 919 3600
+ Fax: +1 818 919 3614
+ EMail: ned@innosoft.com
+
+
+
+
+
+
+
+
+
+
+
+Galvin, et al Standards Track [Page 11]
+