rfc1848.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                         S. Crocker
Request For Comments: 1848                               CyberCash, Inc.
Category: Standards Track                                       N. Freed
                                            Innosoft International, Inc.
                                                               J. Galvin
                                                               S. Murphy
                                             Trusted Information Systems
                                                            October 1995


                     MIME Object Security Services

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 MIME Object Security Services (MOSS), a
   protocol that uses the multipart/signed and multipart/encrypted
   framework [7] to apply digital signature and encryption services to
   MIME objects.  The services are offered through the use of end-to-end
   cryptography between an originator and a recipient at the application
   layer.  Asymmetric (public key) cryptography is used in support of
   the digital signature service and encryption key management.
   Symmetric (secret key) cryptography is used in support of the
   encryption service.  The procedures are intended to be compatible
   with a wide range of public key management approaches, including both
   ad hoc and certificate-based schemes.  Mechanisms are provided to
   support many public key management approaches.

Table of Contents

   1.  Introduction .............................................    3
   2.  Applying MIME Object Security Services ...................    4
   2.1  Digital Signature Service ...............................    4
   2.1.1  Canonicalization ......................................    5
   2.1.2  Digital Signature Control Information .................    7
   2.1.2.1  Version: ............................................    8
   2.1.2.2  Originator-ID: ......................................    8
   2.1.2.3  MIC-Info: ...........................................    8
   2.1.3  application/moss-signature Content Type Definition ....    9
   2.1.4  Use of multipart/signed Content Type ..................   10
   2.2  Encryption Service ......................................   11



Crocker, et al              Standards Track                     [Page 1]

RFC 1848             MIME Object Security Services          October 1995


   2.2.1  Encryption Control Information ........................   12
   2.2.1.1  DEK-Info: ...........................................   13
   2.2.1.2  Recipient-ID: .......................................   14
   2.2.1.3  Key-Info: ...........................................   14
   2.2.2  application/moss-keys Content Type Definition .........   15
   2.2.3  Use of multipart/encrypted Content Type ...............   16
   3.  Removing MIME Object Security Services ...................   17
   3.1  Digital Signature Service ...............................   18
   3.1.1  Preparation ...........................................   18
   3.1.2  Verification ..........................................   19
   3.1.3  Results ...............................................   19
   3.2  Encryption Service ......................................   20
   3.2.1  Preparation ...........................................   20
   3.2.2  Decryption ............................................   20
   3.2.3  Results ...............................................   21
   4.  Identifying Originators, Recipients, and Their Keys ......   21
   4.1  Name Forms ..............................................   23
   4.1.1  Email Addresses .......................................   23
   4.1.2  Arbitrary Strings .....................................   23
   4.1.3  Distinguished Names ...................................   23
   4.2  Identifiers .............................................   24
   4.2.1  Email Address .........................................   25
   4.2.2  Arbitrary String ......................................   25
   4.2.3  Distinguished Name ....................................   26
   4.2.4  Public Key ............................................   26
   4.2.5  Issuer Name and Serial Number .........................   27
   5.  Key Management Content Types .............................   27
   5.1  application/mosskey-request Content Type Definition .....   28
   5.2  application/mosskey-data Content Type Definition ........   29
   6.  Examples .................................................   31
   6.1  Original Message Prepared for Protection ................   31
   6.2  Sign Text of Original Message ...........................   32
   6.3  Sign Headers and Text of Original Message ...............   32
   6.4  Encrypt Text of a Message ...............................   33
   6.5  Encrypt the Signed Text of a Message ....................   35
   6.6  Protecting Audio Content ................................   37
   6.6.1  Sign Audio Content ....................................   37
   6.6.2  Encrypt Audio Content .................................   37
   7.  Observations .............................................   38
   8.  Comparison of MOSS and PEM Protocols .....................   39
   9.  Security Considerations ..................................   41
   10.  Acknowledgements ........................................   41
   11.  References ..............................................   41
   12.  Authors' Addresses ......................................   43
     Appendix A: Collected Grammar ..............................   44
     Appendix B: Imported Grammar ...............................   47





Crocker, et al              Standards Track                     [Page 2]

RFC 1848             MIME Object Security Services          October 1995


1.  Introduction

   MIME [2], 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.  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.  MIME does not provide for
   the application of security services.

   PEM [3-6], an acronym for "Privacy Enhanced Mail", defines message
   encryption and message authentication procedures for text-based
   electronic mail messages using a certificate-based key management
   mechanism.  The specifications include several features that are
   easily and more naturally supported by MIME, for example, the
   transfer encoding operation, the Content-Domain header, and the
   support services specified by its Part IV [6].  The specification is
   limited by specifying the application of security services to text
   messages only.

   MOSS is based in large part on the PEM protocol as defined by RFC
   1421.  Many of PEMs features and most of its protocol specification
   are included here.  A comparison of MOSS and PEM may be found in
   Section 8.

   In order to make use of the MOSS services, a user (where user is not
   limited to being a human, e.g., it could be a process or a role) is
   required to have at least one public/private key pair.  The public
   key must be made available to other users with whom secure
   communication is desired.  The private key must not be disclosed to
   any other user.

   An originator's private key is used to digitally sign MIME objects; a
   recipient would use the originator's public key to verify the digital
   signature.  A recipient's public key is used to encrypt the data
   encrypting key that is used to encrypt the MIME object; a recipient
   would use the corresponding private key to decrypt the data
   encrypting key so that the MIME object can be decrypted.

   As long as the private keys are protected from disclosure, i.e., the
   private keys are accessible only to the user to whom they have been
   assigned, the recipient of a digitally signed message will know from
   whom the message was sent and the originator of an encrypted message
   will know that only the intended recipient is able to read it.  For
   assurance, the ownership of the public keys used in verifying digital
   signatures and encrypting messages should be verified.  A stored
   public key should be protected from modification.



Crocker, et al              Standards Track                     [Page 3]

RFC 1848             MIME Object Security Services          October 1995


   The framework defined in [7] provides an embodiment of a MIME object
   and its digital signature or encryption keys.  When used by MOSS the
   framework provides digital signature and encryption services to
   single and multi-part textual and non-textual MIME objects.

2.  Applying MIME Object Security Services

   The application of the MOSS digital signature service requires the
   following components.

   (1)  The data to be signed.

   (2)  The private key of the originator.

   The data to be signed is prepared according to the description below.
   The digital signature is created by generating a hash of the data and
   encrypting the hash value with the private key of the originator.
   The digital signature, some additional ancillary information
   described below, and the data are then embodied in a multipart/signed
   body part.  Finally, the multipart/signed body part may be
   transferred to a recipient or processed further, for example, it may
   be encrypted.

   The application of the MOSS encryption service requires the following
   components.

   (1)  The data to be encrypted.

   (2)  A data encrypting key to encrypt the data.

   (3)  The public key of the recipient.

   The data to be encrypted is prepared according to the description
   below.  The originator creates a data encrypting key and encrypts the
   data.  The recipient's public key is used to encrypt the data
   encrypting key.  The encrypted data, the encrypted data encrypting
   key, and some additional ancillary information described below are
   then embodied in a multipart/encrypted body part, ready to be
   transferred to a recipient or processed further, for example, it may
   be signed.

   The next two sections describe the digital signature and encryption
   services, respectively, in detail.

2.1.  Digital Signature Service

   The MOSS digital signature service is applied to MIME objects,
   specifically a MIME body part.  The MIME body part is created



Crocker, et al              Standards Track                     [Page 4]

RFC 1848             MIME Object Security Services          October 1995


   according to a local convention and then made available to the
   digital signature service.

   The following sequence of steps comprises the application of the
   digital signature service.


   (1)  The body part to be signed must be canonicalized.


   (2)  The digital signature and other control information must be gen-
        erated.


   (3)  The control information must be embodied in an appropriate MIME
        content type.


   (4)  The control information body part and the data body part must be
        embodied in a multipart/signed content type.


   Each of these steps is described below.

2.1.1.  Canonicalization

   The body part must be converted to a canonical form that is uniquely
   and unambiguously representable in at least the environment where the
   digital signature is created and the environment where the digital
   signature will be verified, i.e., the originator and recipient's
   environment, respectively.  This is required in order to ensure that
   both the originator and recipient have the same data with which to
   calculate the digital signature; the originator needs to be able to
   create the digital signature value while the recipient needs to be
   able to compare a re-computed value with the received value.  If the
   canonical form is representable on many different host computers, the
   signed data may be forwarded by recipients to additional recipients,
   who will also be able to verify the original signature.  This service
   is called forwardable authentication.

   The canonicalization transformation is a two step process.  First,
   the body part must be converted to a form that is unambiguously
   representable on as many different host computers as possible.
   Second, the body part must have its line delimiters converted to a
   unique and unambiguous representation.

   The representation chosen to satisfy the first step is 7bit, as
   defined by MIME; the high order bit of each octet of the data to be



Crocker, et al              Standards Track                     [Page 5]

RFC 1848             MIME Object Security Services          October 1995


   signed must be zero.  A MIME body part is comprised of two parts:
   headers and content.  Since the headers of body parts are already
   required to be represented in 7bit, this step does not require
   changes to the headers.  This step requires that if the content is
   not already 7bit then it must be encoded with an appropriate MIME
   content transfer encoding and a Content-Transfer-Encoding: header
   must be added to the headers.  For example, if the content to be
   signed contains 8bit or binary data, the content must be encoded with
   either the quoted-printable or base64 encoding as defined by MIME.

      IMPLEMENTORS NOTE: Since the MIME standard explicitly disallows
      nested content transfer encodings, i.e., the content types
      multipart and message may not themselves be encoded, the 7bit
      transformation requires each nested body part to be individually
      encoded in a 7bit representation.  Any valid MIME encoding, e.g.,
      quoted-printable or base64, may be used and, in fact, a different
      encoding may be used on each of the non-7bit body parts.

   Representing all content types in a 7bit format transforms them into
   text-based content types.  However, text-based content types present
   a unique problem.  In particular, the line delimiter used for a
   text-based content type is specific to a local environment; different
   environments use the single character carriage-return (<CR>), the
   single character line-feed (<LF>), or the two character sequence
   "carriage-return line-feed (<CR><LF>)".

   The application of the digital signature service requires that the
   same line delimiter be used by both the originator and the recipient.
   This document specifies that the two character sequence "<CR><LF>"
   must be used as the line delimiter.  Thus, the second step of the
   canonicalization transformation includes the conversion of the local
   line delimiter to the two character sequence "<CR><LF>".

   The conversion to the canonical line delimiter is only required for
   the purposes of computing the digital signature.  Thus, originators
   must apply the line delimiter conversion before computing the digital
   signature but must transfer the data without the line delimiter
   conversion.  Similarly, recipients must apply the line delimiter
   conversion before computing the digital signature.

      NOTE: An originator can not transfer the content with the line
      delimiter conversion intact because the conversion process is not
      idempotent.  In particular, SMTP servers may themselves convert
      the line delimiter to a local line delimiter, prior to the message
      being delivered to the recipient.  Thus, a recipient has no way of
      knowing if the conversion is present or not.  If the recipient
      applies the conversion to a content in which it is already
      present, the resulting content may have two line delimiters