rfc1848.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,633 行 · 第 1/5 页

      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



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


      present, which would cause the verification of the signature to
      fail.

      IMPLEMENTORS NOTE: Implementors should be aware that the
      conversion to a 7bit representation is a function that is required
      in a minimally compliant MIME user agent.  Further, the line
      delimiter conversion required here is distinct from the same
      conversion included in that function.  Specifically, the line
      delimiter conversion applied when a body part is converted to a
      7bit representation (transfer encoded) is performed prior to the
      application of the transfer encoding.  The line delimiter
      conversion applied when a body part is signed is performed after
      the body part is converted to 7bit (transfer encoded).  Both line
      delimiter conversions are required.

2.1.2.  Digital Signature Control Information

   The application of the digital signature service generates control
   information which includes the digital signature itself.  The syntax
   of the control information is that of a set of RFC 822 headers,
   except that the folding of header values onto continuation lines is
   explicitly forbidden.  Each header and value pair generated by the
   digital signature service must be output on exactly one line.

   The complete set of headers generated by the digital signature
   service is as follows.

   Version:
      indicates which version of the MOSS protocol the remaining headers
      represent.

   Originator-ID:
      indicates the private key used to create the digital signature and
      the corresponding public key to be used to verify it.

   MIC-Info:
      contains the digital signature value.

   Each invocation of the digital signature service must emit exactly
   one Version: header and at least one pair of Originator-ID: and MIC-
   Info: headers.  The Version: header must always be emitted first.
   The Originator-ID: and MIC-Info: headers are always emitted in pairs
   in the order indicated.  This specification allows an originator to
   generate multiple signatures of the data, presumably with different
   signature algorithms, and to include them all in the control
   information.  The interpretation of the presence of multiple
   signatures is outside the scope of this specification except that a
   MIC-Info: header is always interpreted in the context of the



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


   immediately preceding Originator-ID: header.

2.1.2.1.  Version:

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

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

   Its value is constant and MOSS implementations compliant with this
   specification must recognize only this value and generate an error if
   any other value is found.

2.1.2.2.  Originator-ID:

   The purpose of the originator header is two-fold: to directly
   identify the public key to be used to verify the digital signature
   and to indirectly identify the user who owns both it and its
   corresponding private key.  Typically, a recipient is less interested
   in the actual public key value, although obviously the recipient
   needs the value to verify the signature, and more interested in
   identifying its owner.  Thus, the originator header may convey either
   or both pieces of information:

      the public key to be used to verify the signature

      the name of the owner and which of the owner's public keys to use
      to verify the signature

   The decision as to what information to place in the value rests
   entirely with the originator.  The suggested value is to include
   both.  Recipients with whom the originator has previously
   communicated will have to verify that the information presented is
   consistent with what is already known.  New recipients will want all
   of the information, which they will need to verify prior to storing
   in their local database.

   The originator header is defined by the grammar token <origid> as
   follows.

      <origid>  ::= "Originator-ID:" <id> CRLF

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

2.1.2.3.  MIC-Info:

   The purpose of the Message Integrity Check (MIC) header is to convey
   the digital signature value.  Its value is a comma separated list of



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


   three arguments: the hash (or MIC) algorithm identifier, the
   signature algorithm identifier, and the digital signature.

   The MIC header is defined by the grammar token <micinfo> as follows.

      <micinfo>  ::= "MIC-Info:" <micalgid> "," <ikalgid> ","
                     <asymsignmic> CRLF

   The grammar tokens for the MIC algorithms and identifiers
   (<micalgid>), signature algorithms and identifiers (<ikalgid>), and
   signed MIC formats (<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
      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.1.3.  application/moss-signature Content Type Definition

   (1)  MIME type name: application

   (2)  MIME subtype name: moss-signature

   (3)  Required parameters: none

   (4)  Optional parameters: none

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

   (6)  Security considerations: none

   The "application/moss-signature" content type is used on the second
   body part of an enclosing multipart/signed.  Its content is comprised
   of the digital signature of the data in the first body part of the
   enclosing multipart/signed and other control information required to
   verify that signature, as defined by Section 2.1.2.  The label
   "application/moss-signature" must be used as the value of the
   protocol parameter of the enclosing multipart/signed; the protocol
   parameter must be present.

   Part of the signature verification information will be the Message
   Integrity Check (MIC) algorithm(s) used during the signature creation
   process.  The MIC algorithm(s) identified in this body part must
   match the MIC algorithm(s) identified in the micalg parameter of the
   enclosing multipart/signed.  If it does (they do) not, a user agent



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


   should identify the discrepancy to a user and it may choose to either
   halt or continue processing, giving precedence to the algorithm(s)
   identified in this body part.

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

      Content-Type: application/moss-signature

      <mosssig>

   where the grammar token <mosssig> is defined as follows.

      <mosssig>       ::= <version> ( 1*<origasymflds> )

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

      <origasymflds>  ::= <origid> <micinfo>

      <origid>        ::= "Originator-ID:" <id> CRLF

      <micinfo>       ::= "MIC-Info:" <micalgid> "," <ikalgid> ","
                          <asymsignmic> CRLF

   The token <id> is defined in Section 4.  All other tokens are defined
   in Section 2.1.2.3.

2.1.4.  Use of multipart/signed Content Type

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


   (1)  The body part to be digitally signed 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 the digital signature service
        according to the protocol parameter, in this case according to
        Section 2.1.1.


   (3)  The prepared body part is digitally signed according to the
        protocol parameter, in this case according to Section 2.1.2.


   The multipart/signed content type is constructed as follows.




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


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


   (2)  The signed body part becomes its first body part.


   (3)  Its second body part is labeled "application/moss-signature" and
        is filled with the control information generated by the digital
        signature service.


   (4)  The value of its required parameter "micalg" is set to the same
        value used in the MIC-Info: header in the control information.
        If there is more than one MIC-Info: header present the value is
        set to a comma separated list of values from the MIC-Info
        headers.  The interpretation of the order of the list of values
        is outside the scope of this specification.


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

      Content-Type: multipart/signed;
        protocol="application/moss-signature";
        micalg="rsa-md5"; boundary="Signed Message"

      --Signed Message
      Content-Type: text/plain

      This is some example text.

      --Signed Message
      Content-Type: application/moss-signature

      Version: 5
      Originator-ID: ID-INFORMATION
      MIC-Info: RSA-MD5,RSA,SIGNATURE-INFORMATION
      --Signed Message--

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

2.2.  Encryption Service

   The MOSS encryption service is applied to MIME objects, specifically
   a MIME body part.  The MIME body part is created according to a local
   convention and then made available to the encryption service.



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


   The following sequence of steps comprises the application of the
   encryption service.


   (1)  The body part to be encrypted must be in MIME canonical form.


   (2)  The data encrypting key and other control information must be
        generated.


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


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


   The first step is defined by MIME.  The latter three steps are
   described below.

2.2.1.  Encryption Control Information

   The application of the encryption service generates control
   information which includes the data encrypting key used to encrypt
   the data itself.  The syntax of the control information is that of a
   set of RFC 822 headers, except that the folding of header values onto
   continuation lines is explicitly forbidden.  Each header and value
   pair generated by the encryption service must be output on exactly
   one line.