rfc2315.txt

RFC 的详细文档！

   The DigestAlgorithmIdentifier type identifies a message-digest
   algorithm. Examples include MD2 and MD5. A message-digest algorithm
   maps an octet string (the message) to another octet string (the
   message digest).

   DigestAlgorithmIdentifier ::= AlgorithmIdentifier

6.4 DigestEncryptionAlgorithmIdentifier

   The DigestEncryptionAlgorithmIdentifier type identifies a digest-
   encryption algorithm under which a message digest can be encrypted.
   One example is PKCS #1's rsaEncryption. A digest-encryption algorithm
   supports encryption and decryption operations. The encryption
   operation maps an octet string (the message digest) to another octet
   .bp string (the encrypted message digest) under control of a digest-
   encryption key. The decryption operation is the inverse of the



Kaliski                      Informational                      [Page 6]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   encryption operation. Context determines which operation is intended.

   DigestEncryptionAlgorithmIdentifier ::=
     AlgorithmIdentifier

6.5 ExtendedCertificateOrCertificate

   The ExtendedCertificateOrCertificate type gives either a PKCS #6
   extended certificate or an X.509 certificate.  This type follows the
   syntax recommended in Section 6 of PKCS #6:

   ExtendedCertificateOrCertificate ::= CHOICE {
     certificate Certificate, -- X.509

     extendedCertificate [0] IMPLICIT ExtendedCertificate }

6.6 ExtendedCertificatesAndCertificates

   The ExtendedCertificatesAndCertificates type gives a set of extended
   certificates and X.509 certificates. It is intended that the set be
   sufficient to contain chains from a recognized "root" or "top-level
   certification authority" to all of the signers with which the set is
   associated, but there may be more certificates than necessary, or
   there may be fewer than necessary.

   ExtendedCertificatesAndCertificates ::=
     SET OF ExtendedCertificateOrCertificate

   Note. The precise meaning of a "chain" is outside the scope of this
   document. Some applications of this document may impose upper limits
   on the length of a chain; others may enforce certain relationships
   between the subjects and issuers of certificates in a chain. An
   example of such relationships has been proposed for Privacy-Enhanced
   Mail in RFC 1422.

6.7 IssuerAndSerialNumber

   The IssuerAndSerialNumber type identifies a certificate (and thereby
   an entity and a public key) by the distinguished name of the
   certificate issuer and an issuer-specific certificate serial number.

   IssuerAndSerialNumber ::= SEQUENCE {
     issuer Name,
     serialNumber CertificateSerialNumber }







Kaliski                      Informational                      [Page 7]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


6.8 KeyEncryptionAlgorithmIdentifier

   The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption
   algorithm under which a content-encryption key can be encrypted. One
   example is PKCS #1's rsaEncryption. A key-encryption algorithm
   supports encryption and decryption operations. The encryption
   operation maps an octet string (the key) to another octet string (the
   encrypted key) under control of a key-encryption key. The decryption
   operation is the inverse of the encryption operation.  Context
   determines which operation is intended.

   KeyEncryptionAlgorithmIdentifier ::=
     AlgorithmIdentifier

6.9 Version

   The Version type gives a syntax version number, for compatibility
   with future revisions of this document.

   Version ::= INTEGER

7. General syntax

   The general syntax for content exchanged between entities according
   to this document associates a content type with content. The syntax
   shall have ASN.1 type ContentInfo:

   ContentInfo ::= SEQUENCE {
     contentType ContentType,
     content
       [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }

   ContentType ::= OBJECT IDENTIFIER

   The fields of type ContentInfo have the following meanings:

        o    contentType indicates the type of content. It is
             an object identifier, which means it is a unique string of
             integers assigned by the authority that defines the content
             type. This document defines six content types (see Section
             14): data, signedData, envelopedData,
             signedAndEnvelopedData, digestedData, and encryptedData.

        o    content is the content. The field is optional, and
             if the field is not present, its intended value must be
             supplied by other means. Its type is defined along with the
             object identifier for contentType.




Kaliski                      Informational                      [Page 8]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   Notes.

        1.   The methods below assume that the type of content
             can be determined uniquely by contentType, so the type
             defined along with the object identifier should not be a
             CHOICE type.

        2.   When a ContentInfo value is the inner content of
             signed-data, signed-and-enveloped-data, or digested-data
             content, a message-digest algorithm is applied to the
             contents octets of the DER encoding of the content field.
             When a ContentInfo value is the inner content of
             enveloped-data or signed-and-enveloped-data content, a
             content-encryption algorithm is applied to the contents
             octets of a definite-length BER encoding of the content
             field.

        3.   The optional omission of the content field makes
             it possible to construct "external signatures," for
             example, without modification to or replication of the
             content to which the signatures apply. In the case of
             external signatures, the content being signed would be
             omitted from the "inner" encapsulated ContentInfo value
             included in the signed-data content type.

8. Data content type

   The data content type is just an octet string. It shall have ASN.1
   type Data:

   Data ::= OCTET STRING

   The data content type is intended to refer to arbitrary octet
   strings, such as ASCII text files; the interpretation is left to the
   application. Such strings need not have any internal structure
   (although they may; they could even be DER encodings).

9. Signed-data content type

   The signed-data content type consists of content of any type and
   encrypted message digests of the content for zero or more signers.
   The encrypted digest for a signer is a "digital signature" on the
   content for that signer. Any type of content can be signed by any
   number of signers in parallel. Furthermore, the syntax has a
   degenerate case in which there are no signers on the content. The
   degenerate case provides a means for disseminating certificates and
   certificate-revocation lists.




Kaliski                      Informational                      [Page 9]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   It is expected that the typical application of the signed-data
   content type will be to represent one signer's digital signature on
   content of the data content type. Another typical application will be
   to disseminate certificates and certificate-revocation lists.

   The process by which signed data is constructed involves the
   following steps:

        1.   For each signer, a message digest is computed on
             the content with a signer-specific message-digest
             algorithm. (If two signers employ the same message-digest
             algorithm, then the message digest need be computed for
             only one of them.) If the signer is authenticating any
             information other than the content (see Section 9.2), the
             message digest of the content and the other information are
             digested with the signer's message digest algorithm, and
             the result becomes the "message digest."

        2.   For each signer, the message digest and associated
             information are encrypted with the signer's private key.

        3.   For each signer, the encrypted message digest and
             other signer-specific information are collected into a
             SignerInfo value, defined in Section 9.2.  Certificates and
             certificate-revocation lists for each signer, and those not
             corresponding to any signer, are collected in this step.

        4.   The message-digest algorithms for all the signers
             and the SignerInfo values for all the signers are collected
             together with the content into a SignedData value, defined
             in Section 9.1.

   A recipient verifies the signatures by decrypting the encrypted
   message digest for each signer with the signer's public key, then
   comparing the recovered message digest to an independently computed
   message digest. The signer's public key is either contained in a
   certificate included in the signer information, or is referenced by
   an issuer distinguished name and an issuer-specific serial number
   that uniquely identify the certificate for the public key.

   This section is divided into five parts. The first part describes the
   top-level type SignedData, the second part describes the per-signer
   information type SignerInfo, and the third and fourth parts describe
   the message-digesting and digest-encryption processes. The fifth part
   summarizes compatibility with Privacy-Enhanced Mail.






Kaliski                      Informational                     [Page 10]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


9.1 SignedData type

   The signed-data content type shall have ASN.1 type SignedData:

   SignedData ::= SEQUENCE {
     version Version,
     digestAlgorithms DigestAlgorithmIdentifiers,
     contentInfo ContentInfo,
     certificates
        [0] IMPLICIT ExtendedCertificatesAndCertificates
          OPTIONAL,
     crls
       [1] IMPLICIT CertificateRevocationLists OPTIONAL,
     signerInfos SignerInfos }

   DigestAlgorithmIdentifiers ::=

     SET OF DigestAlgorithmIdentifier

   SignerInfos ::= SET OF SignerInfo

   The fields of type SignedData have the following meanings:

        o    version is the syntax version number. It shall be
             1 for this version of the document.

        o    digestAlgorithms is a collection of message-digest
             algorithm identifiers. There may be any number of
             elements in the collection, including zero. Each
             element identifies the message-digest algorithm
             (and any associated parameters) under which the
             content is digested for a some signer. The
             collection is intended to list the message-digest
             algorithms employed by all of the signers, in any
             order, to facilitate one-pass signature
             verification. The message-digesting process is
             described in Section 9.3.

        o    contentInfo is the content that is signed. It can
             have any of the defined content types.

        o    certificates is a set of PKCS #6 extended
             certificates and X.509 certificates. It is intended that
             the set be sufficient to contain chains from a recognized
             "root" or "top-level certification authority" to all of the
             signers in the signerInfos field. There may be more
             certificates than necessary, and there may be certificates
             sufficient to contain chains from two or more independent



Kaliski                      Informational                     [Page 11]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


             top-level certification authorities. There may also be
             fewer certificates than necessary, if it is expected that
             those verifying the signatures have an alternate means of
             obtaining necessary certificates (e.g., from a previous set
             of certificates).

        o    crls is a set of certificate-revocation lists. It
             is intended that the set contain information sufficient to
             determine whether or not the certificates in the
             certificates field are "hot listed," but such
             correspondence is not necessary.  There may be more
             certificate-revocation lists than necessary, and there may