rfc1848.txt

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

   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]

RFC 1848             MIME Object Security Services          October 1995


   The control information is prepared by removing any content transfer
   encodings that may be present.

   The digitally signed body part is prepared by leaving the content
   transfer encodings intact and canonicalizing the line delimiters
   according to Step 2 of Section 2.1.1.

3.1.2.  Verification

   First, the recipient must obtain the public key of the originator.
   The public key may be contained in the control information or it may
   be necessary for the recipient to retrieve the public key based on
   information present in the control information.  The retrieval may be
   from a local database or from a remote service.  The acquisition of
   the originator's public key is outside the scope of the
   specification, although Section 5 defines one possible mechanism.

   With the public key, the recipient decrypts the hash value contained
   in the control information.  Then, a new hash value is computed over
   the body part purported to have been digitally signed.

   Finally, the two hash values are compared to determine the accuracy
   of the digital signature.

3.1.3.  Results

   There are two required components of the results of the verification
   process.  The first is an indication as to whether a public key could
   be found that allows the hash values in the previous step to compare
   equal.  Such an indication verifies only that the data received is
   the same data that was digitally signed.

   The second indication identifies the owner of the public key who is
   presumably the holder of the private key that created the digital
   signature.  The indication must include a testament as to the
   accuracy of the owner identification.

   At issue is a recipient knowing who created the digital signature.
   In order for the recipient to know with certainty who digitally
   signed the message, the binding between the owner's name and the
   public key must have been verified by the recipient prior to the
   verification of the digital signature.  The verification of the
   binding may have been completed offline and stored in a trusted,
   local database or, if the owner's name and public key are embodied in
   a certificate, it may be possible to complete it in realtime.  See
   Section 5 for more information.





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


3.2.  Encryption Service

   This section describes the processing steps necessary to decrypt the
   MOSS encryption service.  The definition of the multipart/encrypted
   body part in [7] specifies three steps for receiving it.


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


   (2)  The prepared body parts are made available to the decryption
        process.


   (3)  The results of the decryption process are made available to the
        user and processing continues with the decrypted body part, as
        returned by the decryption process.


   Each of these steps is described below.

3.2.1.  Preparation

   The encrypted body part (the data) and the control information body
   part are separated from the enclosing multipart/encrypted body part.
   The body parts are prepared for the decryption process by removing
   any content transfer encodings that may be present.

3.2.2.  Decryption

   First, the recipient must locate the encrypted data encrypting key in
   the control information.  Each Recipient-ID: header is checked in
   order to see if it identifies the recipient or a public key of the
   recipient.

   If it does, the immediately following Key-Info: header will contain
   the data encrypting key encrypted with the public key of the
   recipient.  The recipient must use the corresponding private key to
   decrypt the data encrypting key.

   The data is decrypted with the data encrypting key.  The decrypted
   data will be a MIME object, a body part, ready to be processed by a
   MIME agent.







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


3.2.3.  Results

   If the recipient is able to locate and decrypt a data encrypting key,
   from the point of view of MOSS the decryption should be considered
   successful.  An indication of the owner of the private key used to
   decrypt the data encrypting key must be made available to the user.

   Ultimately, the success of the decryption is dependent on the ability
   of a MIME agent to continue processing with the decrypted body part.

4.  Identifying Originators, Recipients, and Their Keys

   In the PEM specifications, public keys are required to be embodied in
   certificates, an object that binds each public key with a
   distinguished name.  A distinguished name is a name form that
   identifies the owner of the public key.  The embodiment is issued by
   a certification authority, a role that is expected to be trustworthy
   insofar as the certification authority would have procedures to
   verify the identity of the owner prior to issuing the certificate.

   In MOSS, a user is not required to have a certificate.  The MOSS
   services require that the user have at least one public/private key
   pair.  The MOSS protocol requires the digital signature and
   encryption services to emit Originator-ID: and Recipient-ID: headers,
   as appropriate.  In the discussion above the actual value of these
   headers was omitted, having been relegated to this section.  Although
   the value of each of these headers serves a distinct purpose, for
   simplicity the single grammar token <id> represents the value that
   may be assigned to either header.

   One possible value for the Originator-ID: and Recipient-ID: headers
   is the public key values themselves.  However, while it is true that
   the public keys alone could be exchanged and used by users to
   communicate, the values are, in fact, large and cumbersome.  In
   addition, public keys would appear as a random sequence of characters
   and, as a result, would not be immediately consumable by human users.

      NOTE: It should be pointed out that a feature of being able to
      specify the public key explicitly is that it allows users to
      exchange encrypted, anonymous mail.  In particular, receiving
      users will always know a message comes from the same originating
      user even if the real identity of the originating user is unknown.

   Recognizing that the use of public keys is, in general, unsuitable
   for use by humans, MOSS allows other identifiers in Originator-ID:
   and Recipient-ID: headers.  These other identifiers are comprised of
   two parts: a name form and a key selector.




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


   The name form is chosen and asserted by the user who owns the
   public/private key pair.  Three name forms are specified by this
   document.  The use of a distinguished name is retained for
   compatibility with PEM (and compatibility with the X.500 Directory
   should it become a ubiquitous service).  However, the Internet
   community has a great deal of experience with the use of electronic
   mail addresses as a name form.  Also, arbitrary strings are useful to
   identify the owners of public keys when private name forms are used.
   Hence, email addresses and arbitrary strings are included as name
   forms to increase flexibility.

   Since a user may have more than one public key and may wish to use
   the same name form for each public key, a name form is insufficient
   for uniquely identifying a public key.  A unique "key selector" must
   be assigned to each public key.  The combination of a name form and
   the key selector uniquely identifies a public key.  Throughout this
   document, this combination is called an identifier.  There are 5
   identifiers specified by this document.

      NOTE: In the simplest case, key selectors will be assigned by the
      owners of the public/private key pairs.  This works best when
      users generate their own key pairs for personal use, from which
      they distribute their public key to others asserting by
      declaration that the public key belongs to them.  When the
      assertion that the public key belongs to them is made by a third
      party, for example when a certification authority issues a
      certificate to a user according to [4], the key selector may be
      assigned by that third party.

   The value of the key selector must be unique with respect to the name
   form with which it forms an identifier.  Although the same key
   selector value may be used by more than one name form it must not be
   used for two different keys with the same name form.  When considered
   separately, neither a name form nor a key selector is sufficient for
   identifying the public key to be used.  Either could be used to
   determine a set of public keys that may be tried in turn until the
   desired public key is identified.

   With a public/private key pair for one's self and software that is
   MOSS aware, an originating user may digitally sign arbitrary data and
   send it to one or more recipients.  With the public keys of the
   recipients, a user may encrypt the data so that only the intended
   recipients can decrypt and read it.  With the name forms assigned to
   the public keys, originators and recipients can easily recognize
   their peers in a communication.

   In the next section the 3 name forms are described in detail.
   Following that is the specification of the 5 identifiers.



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


4.1.  Name Forms

   There are 3 name forms specified by this document: email addresses,
   distinguished names, and arbitrary strings.

4.1.1.  Email Addresses

   The email address (grammar token <emailstr>) used must be a valid
   RFC822 address, which is defined in terms of one of the two grammar
   tokens <addr-spec> or <route-addr>.  The grammar for these two tokens
   is included in the Appendix as a convenience; the definitive source
   for these tokens is necessarily RFC822 [1].

      <emailstr>      ::= <addr-spec> / <route-addr>
                          ; an electronic mail address as defined by
                          ; one of these two tokens from RFC822

   For example, the strings "[e-mail]", "[e-mail]",
   "[e-mail]", and "[e-mail]" are all email addresses.

4.1.2.  Arbitrary Strings

   The arbitrary string (grammar token <string>) must have a length of
   at least 1.  There are no other restrictions on the value chosen.

      <string>        ::= ; a non-null sequence of characters

   For example, the string

      the SAAG mailing list maintainer

   is an arbitrary string.

4.1.3.  Distinguished Names

   The distinguished name (grammar token <dnamestr>) must be constructed
   according to the guidelines of the X.500 Directory.  The actual
   syntax of the distinguished name is outside the scope of this
   specification.  However, RFC1422, for example, specifies syntactic
   restrictions based on its choice of a certification hierarchy for
   certificates.

   For the purposes of conveying a distinguished name from an originator
   to a recipient, it must be ASN.1 encoded and then printably encoded
   according to the base64 encoding defined by MIME.






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


      <dnamestr>      ::= <encbin>
                          ; a printably encoded, ASN.1 encoded
                          ; distinguished name (as defined by the 'Name'
                          ; production specified in X.501 [8])

   For example,

      /Country Name=US
      /State or Province Name=MD
      /Organization Name=Trusted Information Systems
      /Organizational Unit Name=Glenwood
      /Common Name=James M. Galvin/

   is a distinguished name in a user friendly format (line breaks and