rfc1848.txt

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


RFC 1848             MIME Object Security Services          October 1995


   Recipient-ID:
      indicates the public key used to encrypt the data encrypting key
      that was used to encrypt the data.

   Key-Info:
      contains data encrypting key encrypted with the recipient's public
      key.

   Each invocation of the encryption service must emit exactly one
   Version: header, exactly one DEK-Info: header, and at least one pair
   of Recipient-ID: and Key-Info: headers.  Headers are always emitted
   in the order indicated.  The Recipient-ID: and Key-Info: headers are
   always emitted in pairs in the order indicated, one pair for each
   recipient of the encrypted data.  A Key-Info: header is always
   interpreted in the context of the immediately preceding Recipient-ID:
   header.

      IMPLEMENTORS NOTE: Implementors should always generate a
      Recipient-ID: and Key-Info header pair representing the originator
      of the encrypted data.  By doing so, if an originator sends a
      message to a recipient that is returned undelivered, the
      originator will be able to decrypt the message and determine an
      appropriate course of action based on its content.  If not, an
      originator will not be able to review the message that was sent.

2.2.1.1.  DEK-Info:

   The purpose of the data encrypting key information header is to
   indicate the algorithm and mode used to encrypt the data, along with
   any cryptographic parameters that may be required, e.g.,
   initialization vectors.  Its value is either a single argument
   indicating the algorithm and mode or a comma separated pair of
   arguments where the second argument carries any cryptographic
   parameters required by the algorithm and mode indicated in the first
   argument.

   The data encrypting key information header is defined by the grammar
   token <dekinfo> as follows.

      <dekinfo>  ::= "DEK-Info" ":" <dekalgid>
                     [ "," <dekparameters> ] CRLF

   The grammar tokens for the encryption algorithm and mode identifier
   (<dekalgid>) and the optional cryptographic parameters
   (<dekparameters>) are defined by RFC 1423.  They are also reprinted
   in Appendix B.





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


2.2.1.2.  Recipient-ID:

   The purpose of the recipient header is to identify the private key
   that must be used to decrypt the data encrypting key that will be
   used to decrypt the data.  Presumably the recipient owns the private
   key and thus is less interested in identifying the owner of the key
   and more interested in the private key value itself.  Nonetheless,
   the recipient header may convey either or both pieces of information:

      the public key corresponding to the private key to be used to
      decrypt the data encrypting key

      the name of the owner and which of the owner's private keys to use
      to decrypt the data encrypting key

   The decision as to what information to place in the value rests
   entirely with the originator.  The suggested choice is to include
   just the public key.  However, some recipients may prefer that
   originators not include their public key.  How this preference is
   conveyed to and managed by the originator is outside the scope of
   this specification.

   The recipient header is defined by the grammar token <recipid> as
   follows.

      <recipid>  ::= "Recipient-ID:" <id> CRLF

   The grammar token <id> is defined in Section 4.

2.2.1.3.  Key-Info:

   The purpose of the key information header is to convey the encrypted
   data encrypting key.  Its value is a comma separated list of two
   arguments: the algorithm and mode identifier in which the data
   encrypting key is encrypted and the encrypted data encrypting key.

   The key information header is defined by the grammar token
   <asymkeyinfo> as follows.

      <asymkeyinfo>  ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF

   The grammar tokens for the encryption algorithm and mode identifier
   (<ikalgid>) and the encrypted data encrypting key format
   (<asymsignmic>) are defined by RFC 1423.  They are also reprinted in
   Appendix B.

      IMPLEMENTORS NOTE: RFC 1423 is referenced by the PEM protocol,
      which includes support for symmetric signatures and key



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


      management.  As a result, some of the grammar tokens defined
      there, for example, <ikalgid>, will include options that are not
      legal for this protocol.  These options must be ignored and have
      not been included in the appendix.

2.2.2.  application/moss-keys Content Type Definition

   (1)  MIME type name: application

   (2)  MIME subtype name: moss-keys

   (3)  Required parameters: none

   (4)  Optional parameters: none

   (5)  Encoding considerations: quoted-printable is always sufficient

   (6)  Security considerations: none

   The "application/moss-keys" content type is used on the first body
   part of an enclosing multipart/encrypted.  Its content is comprised
   of the data encryption key used to encrypt the data in the second
   body part and other control information required to decrypt the data,
   as defined by Section 2.2.1.  The label "application/moss-keys" must
   be used as the value of the protocol parameter of the enclosing
   multipart/encrypted; the protocol parameter must be present.

   An application/moss-keys body part is constructed as follows:

      Content-Type: application/moss-keys

      <mosskeys>

   where the <mosskeys> token is defined as follows.

      <mosskeys>      ::= <version> <dekinfo> 1*<recipasymflds>

      <version>       ::= "Version:" "5" CRLF

      <dekinfo>       ::= "DEK-Info" ":" <dekalgid>
                          [ "," <dekparameters> ] CRLF

      <recipasymflds> ::= <recipid> <asymkeyinfo>

      <recipid>       ::= "Recipient-ID:" <id> CRLF

      <asymkeyinfo>   ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF




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


   The token <id> is defined in Section 4.  The token <version> is
   defined in Section 2.1.2.1.  All other tokens are defined in Section
   2.2.1.3.

2.2.3.  Use of multipart/encrypted Content Type

   The definition of the multipart/encrypted body part in [7] specifies
   three steps for creating the body part.


   (1)  The body part to be encrypted is created according to a local
        convention, for example, with a text editor or a mail user
        agent.


   (2)  The body part is prepared for encryption according to the
        protocol parameter, in this case the body part must be in MIME
        canonical form.


   (3)  The prepared body part is encrypted according to the protocol
        parameter, in this case according to Section 2.2.1.


   The multipart/encrypted content type is constructed as follows.


   (1)  The value of its required parameter "protocol" is set to
        "application/moss-keys".


   (2)  The first body part is labeled "application/moss-keys" and is
        filled with the control information generated by the encryption
        service.


   (3)  The encrypted body part becomes the content of its second body
        part, which is labeled "application/octet-stream".


   A multipart/encrypted content type with the MOSS protocol might look
   as follows:









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


      Content-Type: multipart/encrypted;
        protocol="application/moss-keys";
        boundary="Encrypted Message"

      --Encrypted Message
      Content-Type: application/moss-keys

      Version: 5
      DEK-Info: DES-CBC,DEK-INFORMATION
      Recipient-ID: ID-INFORMATION
      Key-Info: RSA,KEY-INFORMATION

      --Encrypted Message
      Content-Type: application/octet-stream

      ENCRYPTED-DATA
      --Encrypted Message--

   where DEK-INFORMATION, ID-INFORMATION, and KEY-INFORMATION are
   descriptive of the content that would appear in a real body part.

3.  Removing MIME Object Security Services

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


   (1)  A recipient to verify the digital signature.


   (2)  A multipart/signed body part with two body parts: the signed
        data and the control information.


   (3)  The public key of the originator.


   The signed data and control information of the enclosing
   multipart/signed are prepared according to the description below.
   The digital signature is verified by re-computing the hash of the
   data, decrypting the hash value in the control information with the
   originator's public key, and comparing the two hash values.  If the
   two hash values are equal, the signature is valid.

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





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


   (1)  A recipient to decrypt the data.


   (2)  A multipart/encrypted body part with two body parts: the
        encrypted data and the control information.


   (3)  The private key of the recipient.


   The encrypted data and control information of the enclosing
   multipart/encrypted are prepared according to the description below.
   The data encrypting key is decrypted with the recipient's private key
   and used to decrypt the data.

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

3.1.  Digital Signature Service

   This section describes the processing steps necessary to verify the
   MOSS digital signature service.  The definition of the
   multipart/signed body part in [7] specifies three steps for receiving
   it.


   (1)  The digitally signed body part and the control information body
        part are prepared for processing.


   (2)  The prepared body parts are made available to the digital
        signature verification process.


   (3)  The results of the digital signature verification process are
        made available to the user and processing continues with the
        digitally signed body part, as returned by the digital signature
        verification process.


   Each of these steps is described below.

3.1.1.  Preparation

   The digitally signed body part (the data) and the control information
   body part are separated from the enclosing multipart/signed body
   part.




Crocker, et al              Standards Track                    [Page 18]