rfc1847.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 620 行 · 第 1/2 页

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