rfc2315.txt

RFC 的详细文档！

             padded to a multiple of some block size; see
             Section 10.3 for discussion.)

        6.   For each signer, the doubly encrypted message
             digest and other signer-specific information are
             collected into a SignerInfo value, defined in
             Section 9.2.

        7.   The content is encrypted with the content-
             encryption key. (See Section 10.3 for discussion.)

        8.   The message-digest algorithms for all the signers,
             the SignerInfo values for all the signers and the
             RecipientInfo values for all the recipients are
             collected together with the encrypted content into
             a SignedAndEnvelopedData value, defined in Section
             11.1.




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


   A recipient opens the envelope and verifies the signatures in two
   steps. First, the one of the encrypted content-encryption keys is
   decrypted with the recipient's private key, and the encrypted content
   is decrypted with the recovered content-encryption key. Second, the
   doubly encrypted message digest for each signer is decrypted with the
   recovered content-encryption key, the result is decrypted with the
   signer's public key, and the recovered message digest is compared to
   an independently computed message digest.

   Recipient private keys and signer public keys are contained or
   referenced as discussed in Sections 9 and 10.

   This section is divided into three parts. The first part describes
   the top-level type SignedAndEnvelopedData and the second part
   describes the digest-encryption process. Other types and processes
   are the same as in Sections 9 and 10.  The third part summarizes
   compatibility with Privacy-Enhanced Mail.

   Note. The signed-and-enveloped-data content type provides
   cryptographic enhancements similar to those resulting from the
   sequential combination of signed-data and enveloped-data content
   types. However, since the signed-and-enveloped-data content type does
   not have authenticated or unauthenticated attributes, nor does it
   provide enveloping of signer information other than the signature,
   the sequential combination of signed-data and enveloped-data content
   types is generally preferable to the SignedAndEnvelopedData content
   type, except when compatibility with the ENCRYPTED process type in
   Privacy-Enhanced Mail in intended.

11.1 SignedAndEnvelopedData type

   The signed-and-enveloped-data content type shall have ASN.1 type
   SignedAndEnvelopedData:

   SignedAndEnvelopedData ::= SEQUENCE {
     version Version,
     recipientInfos RecipientInfos,
     digestAlgorithms DigestAlgorithmIdentifiers,
     encryptedContentInfo EncryptedContentInfo,
     certificates
        [0] IMPLICIT ExtendedCertificatesAndCertificates
          OPTIONAL,
     crls
       [1] IMPLICIT CertificateRevocationLists OPTIONAL,
     signerInfos SignerInfos }






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


   The fields of type SignedAndEnvelopedData have the following
   meanings:

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

        o    recipientInfos is a collection of per-recipient
             information, as in Section 10. There must be at
             least one element in the collection.

        o    digestAlgorithms is a collection of message-digest
             algorithm identifiers, as in Section 9. The
             message-digesting process is the same as in
             Section 9 in the case when there are no
             authenticated attributes.

        o    encryptedContentInfo is the encrypted content, as
             in Section 10. It can have any of the defined
             content types.

        o    certificates is a set of PKCS #6 extended
             certificates and X.509 certificates, as in Section
             9.

        o    crls is a set of certificate-revocation lists, as
             in Section 9.

        o    signerInfos is a collection of per-signer
             information. There must be at least one element in
             the collection. SignerInfo values have the same
             meaning as in Section 9 with the exception of the
             encryptedDigest field (see below).

   Notes.

        1.   The fact that the recipientInfos and
             digestAlgorithms fields come before the contentInfo field
             and the signerInfos field comes after it makes it possible
             to process a SignedAndEnvelopedData value in a single pass.
             (Single-pass processing is described in Section 5.)

        2.   The difference between version 1
             SignedAndEnvelopedData and version 0 SignedAndEnvelopedData
             (defined in PKCS #7, Version 1.4) is that the crls field is
             allowed in version 1, but not in version 0. Except for the
             difference in version number, version 0
             SignedAndEnvelopedData values are acceptable as version 1
             values. An implementation can therefore process



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


             SignedAndEnvelopedData values of either version as though
             they were version 1 values. It is suggested that PKCS
             implementations generate only version 1
             SignedAndEnvelopedData values, but be prepared to process
             SignedAndEnvelopedData values of either version.

11.2 Digest-encryption process

   The input to the digest-encryption process is the same as in Section
   9, but the process itself is different.  Specifically, the process
   involves two steps. First, the input to the process is supplied to
   the signer's digest-encryption algorithm, as in Section 9. Second,
   the result of the first step is encrypted with the content-encryption
   key.  There is no DER encoding between the two steps; the "value"
   output by the first step is input directly to the second step. (See
   Section 10.3 for discussion.)

   This process is compatible with the ENCRYPTED process type in
   Privacy-Enhanced Mail.

   Note. The purpose of the second step is to prevent an adversary from
   recovering the message digest of the content.  Otherwise, an
   adversary would be able to determine which of a list of candidate
   contents (e.g., "Yes" or "No") is the actual content by comparing the
   their message digests to the actual message digest.

11.3 Compatibility with Privacy-Enhanced Mail

   Compatibility with the ENCRYPTED process type of PEM occurs when the
   content type of the ContentInfo value being signed and enveloped is
   data, the message-digest algorithm is md2 or md5, the content-
   encryption algorithm is DES in CBC mode, the digest-encryption
   algorithm is PKCS #1's rsaEncryption, and the key-encryption
   algorithm is PKCS #1's rsaEncryption.  Under all those conditions,
   the doubly encrypted message digest and the encrypted content
   encryption key match the ones produced in PEM because of reasons
   similar to those given in Section 9.5, as well as the following:

        1.   The value input to the content-encryption
             algorithm in PEM is the same as in this document.
             DES in CBC mode is the same as desCBC.

        2.   The value input to the key-encryption algorithm in
             PEM is the same as in this document (see Section
             10.4). RSA public-key encryption in PEM is the
             same as PKCS #1's rsaEncryption.





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


        3.   The double-encryption process applied to the
             message digest in this document and in PEM are the
             same.

   The other parts of the signed-and-enveloped-data content type
   (certificates, CRLs, algorithm identifiers, etc.) are easily
   translated to and from their corresponding PEM components. (CRLs are
   carried in a separate PEM message.)

12. Digested-data content type

   The digested-data content type consists of content of any type and a
   message digest of the content.

   It is expected that the typical application of the digested-data
   content type will be to add integrity to content of the data content
   type, and that the result would become the content input to the
   enveloped-data content type.

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

        1.   A message digest is computed on the content with a
             message-digest algorithm.

        2.   The message-digest algorithm and the message
             digest are collected together with the content
             into a DigestedData value.

   A recipient verifies the message digest by comparing the message
   digest to an independently computed message digest.

   The digested-data content type shall have ASN.1 type DigestedData:

   DigestedData ::= SEQUENCE {
     version Version,
     digestAlgorithm DigestAlgorithmIdentifier,
     contentInfo ContentInfo,
     digest Digest }

   Digest ::= OCTET STRING

   The fields of type DigestedData have the following meanings:

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





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


        o    digestAlgorithm identifies the message-digest
             algorithm (and any associated parameters) under which the
             content is digested. (The message-digesting process is the
             same as in Section 9 in the case when there are no
             authenticated attributes.)

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

        o    digest is the result of the message-digesting process.

   Note. The fact that the digestAlgorithm field comes before the
   contentInfo field and the digest field comes after it makes it
   possible to process a DigestedData value in a single pass.  (Single-
   pass processing is described in Section 5.)

13. Encrypted-data content type

   The encrypted-data content type consists of encrypted content of any
   type. Unlike the enveloped-data content type, the encrypted-data
   content type has neither recipients nor encrypted content-encryption
   keys. Keys are assumed to be managed by other means.

   It is expected that the typical application of the encrypted-data
   content type will be to encrypt content of the data content type for
   local storage, perhaps where the encryption key is a password.

   The encrypted-data content type shall have ASN.1 type EncryptedData:

   EncryptedData ::= SEQUENCE {
     version Version,
     encryptedContentInfo EncryptedContentInfo }

   The fields of type EncryptedData have the following meanings:

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

        o    encryptedContentInfo is the encrypted content
             information, as in Section 10.

14. Object identifiers

   This document defines seven object identifiers: pkcs-7, data,
   signedData, envelopedData, signedAndEnvelopedData, digestedData, and
   encryptedData.





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


   The object identifier pkcs-7 identifies this document.

   pkcs-7 OBJECT IDENTIFIER ::=
     { iso(1) member-body(2) US(840) rsadsi(113549)
         pkcs(1) 7 }

   The object identifiers data, signedData, envelopedData,