rfc1848.txt

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

   leading spaces present only to improve readability).  When encoded,
   it would appear as follows (line breaks present only to improve
   readability):

      MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3RlZCBJ
      bmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1UEAxMP
      SmFtZXMgTS4gR2Fsdmlu

4.2.  Identifiers

   There are 5 types of identifiers specified by this document:

      email address identifiers

      arbitrary string identifiers

      distinguished name identifiers

      the public keys themselves

      issuer name serial number pairs from a certificate

   All of these have approximately the same structure (except issuer
   name and serial number which has 'TYPE, STRING, KEYSEL' for
   historical reasons):

      TYPE, KEYSEL, STRING

   The TYPE field is a literal string chosen from the set "EN", "STR",
   "DN", "PK", and "IS", one for each of the possible identifiers.

   The KEYSEL field is used to distinguish between the multiple public
   keys that may be associated with the name form in the STRING field.
   Its value must be unique with respect to all other key selectors used



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


   with the same name form.  An example would be to use a portion (low-
   order 16 or 32 bits) or all of the actual public key used.

   The STRING field is the name form and has a different syntax
   according to the value of the TYPE field.

   The identifier used in each of the originator and recipient fields is
   described by the following grammar.  The definition of the key
   selector token is included here since it used by several of the
   identifiers below.

      <id>            ::=   <id-email> / <id-string>    / <id-dname>
                          / <id-publickey> / <id-issuer>

      <keysel>        ::= 1*<hexchar>
                          ; hex dump of a non-null sequence of octets

   Each of the identifier name forms is described below.

4.2.1.  Email Address

   The email address identifier has the following syntax.

      <id-email>      ::= "EN"  "," <keysel> "," <emailstr> CRLF

   The syntax of the token <emailstr> is defined in Section 4.1.1.

   For example:

      EN,1,[e-mail]

   is an email address identifier.

4.2.2.  Arbitrary String

   The arbitrary string identifier has the following syntax.

      <id-string>     ::= "STR" "," <keysel> "," <string> CRLF

   The syntax of the token <string> is defined in Section 4.1.2.

   For example:

      STR,1,The SAAG mailing list maintainer

   is an arbitrary string identifier.





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


4.2.3.  Distinguished Name

   The distinguished name identifier has the following syntax.

      <id-dname>      ::= "DN"  "," <keysel> "," <dnamestr> CRLF

   The syntax of the token <dnamestr> is defined in Section 4.1.3.

   For example (line breaks present only to improve readability):

      DN,1,MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3R
      lZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1U
      EAxMPSmFtZXMgTS4gR2Fsdmlu

   is a distinguished name identifier.

4.2.4.  Public Key

   The public key identifier has the following syntax.

      <id-publickey>  ::= "PK"  "," <publickey> [ "," <id-subset> ] CRLF

      <publickey>     ::= <encbin>
                          ; a printably encoded, ASN.1 encoded public
                          ; key (as defined by the
                          ; 'SubjectPublicKeyInfo' production specified
                          ; in X.509 [9])

      <id-subset>     ::= <id-email> / <id-string> / <id-dname>

   The production SubjectPublicKeyInfo is imported from the X.500
   Directory from the certificate object.  It is currently the best
   choice for a general purpose public key encoding.

   For example, (line breaks present only to improve readability):

      PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6BekJmG
      4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn
      0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB

   is a public key identifier without the optional <id-subset>.

   In normal usage, the token <id-subset> is expected to be present.  It
   represents a mechanism by which an identifier (name form and key
   selector) can be associated with a public key.  Recipients of a
   public key identifier must take care to verify the accuracy of the
   purported association.  If they do not, it may be possible for a
   malicious originator to assert an identifier that accords the



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


   originator unauthorized privileges.  See Section 5.2 for more
   details.

   For example, (line breaks present only to improve readability):

      PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6BekJmG
      4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn
      0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,[e-mail]

   is a public key identifier with the optional <id-subset>.

4.2.5.  Issuer Name and Serial Number

   The issuer name and serial number identifier has the following
   syntax.

      <id-issuer>     ::= "IS"  "," <dnamestr>  "," <serial> CRLF

      <serial>        ::= 1*<hexchar>
                          ; hex dump of a certificate serial number

   The <id-issuer> identifier is included for compatibility with the
   ID-ASymmetric fields defined in [3] (and compatibility with X.500
   Directory certificates should they become ubiquitously available).
   Its syntax was chosen such that the older fields are easily converted
   to this new form by prefixing the old value with "IS" (and replacing
   the field name of [3] with an appropriate new ID field name).  For
   example, (line breaks present only to improve readability):

      IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3
      RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02

   is an issuer name and serial number identifier according to MOSS,
   while

      MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3
      RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02

   is an issuer name and serial number identifier according to PEM.

5.  Key Management Content Types

   This document defines two key management content types: one for
   requesting cryptographic key material and one for sending
   cryptographic key material.  Since MOSS depends only on the existence
   of public/private key pairs, these content types provide a means for
   conveying public keys and an assertion as to the identity of the
   owner.  In addition, in order to be compatible with the certificate-



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


   base key management system proposed by RFC 1422, the content types
   may also be used to convey certificate and certificate revocation
   list material.

   The functions defined here are based on the exchange of body parts.
   In particular, a user would send a message containing at least one
   application/mosskey-request content, as defined below.  In response,
   a user would expect to receive a message containing at least one
   application/mosskey-data content, as defined below.  MIME provides a
   convenient framework for a user to send several request body parts
   and to receive several data (response) body parts in one message.

5.1.  application/mosskey-request Content Type Definition

   (1)  MIME type name: application

   (2)  MIME subtype name: mosskey-request

   (3)  Required parameters: none

   (4)  Optional parameters: none

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

   (6)  Security Considerations: none

   The content of this body part corresponds to the following
   production.

      <request>       ::= <version>
                          ( <subject> / <issuer> / <certification> )

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

      <subject>       ::= "Subject:" <id> CRLF

      <issuer>        ::= "Issuer:" <id> CRLF

      <certification> ::= "Certification:" <encbin> CRLF

   A user would use this content type to specify needed cryptographic
   key information.  The message containing this content type might be
   directed towards an automatic or manual responder, which may be
   mail-based, depending on the local implementation and environment.
   The application/mosskey-request content type is an independent body
   part because it is entirely independent of any other body part.





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


   If the application/mosskey-request content contains a Certification:
   field it requests certification of the self-signed certificate in the
   field value.  If the content contains an Issuer: field it requests
   the Certificate Revocation List (CRL) chain beginning with the CRL of
   the issuer identified in the field value.  If the content contains a
   Subject: field it requests either the public key of the subject or a
   certificate chain beginning with the subject identified in the field
   value, or both if both exist.

   The Subject: and Issuer: fields each contain a value of type <id>,
   which is defined in Section 4.

   One possible response to receiving an application/mosskey-request
   body part is to construct and return an application/mosskey-data body
   part.  When returning public keys, certificate chains, and
   certificate revocation list chains, if there exists more than one,
   several application/mosskey-data body parts are to be returned in the
   reply message, one for each.

5.2.  application/mosskey-data Content Type Definition

   The principal objective of this content type is to convey
   cryptographic keying material from a source to a destination.  This
   might be in response to the receipt of an application/mosskey-request
   content type or it might be in anticipation of receiving an
   application/mosskey-request if it is not sent, e.g., it may be
   combined with a multipart/signed object by an originator to ensure
   that a recipient has the cryptographic keying material necessary to
   verify the signature.  When combined with other content types, the
   processing by a recipient is enhanced if the application/mosskey-data
   content type is positioned in its enclosing content type prior to the
   content types that will make use of its cryptographic keying
   material.

   However, no explicit provision is made in this document for
   determining the authenticity or accuracy of the data being conveyed.
   In particular, when a public key and its identifier is conveyed,
   there is nothing to prevent the source or an interloper along the
   path from the source to the destination from substituting alternate
   values for either the public key or the identifier.

   It is incumbent upon a recipient to verify the authenticity and
   accuracy of the data received in this way prior to its use.  This
   problem can be addressed by the use of certificates, since a
   certification hierarchy is a well-defined mechanism that conveniently
   supports the automatic verification of the data.  Alternatively, the
   source of the application/mosskey-data body part could digitally sign
   it.  In this way, if the destination believes that a correct source's



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


   public key is available locally and if the destination believes the
   source would convey accurate data, then the contents of the
   application/mosskey-data from the source coul