rfc2315.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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,
   signedAndEnvelopedData, digestedData, and encryptedData, identify,
   respectively, the data, signed-data, enveloped-data, signed-and-
   enveloped-data, digested-data, and encrypted-data content types
   defined in Sections 8-13.

   data OBJECT IDENTIFIER ::= { pkcs-7 1 }
   signedData OBJECT IDENTIFIER ::= { pkcs-7 2 }
   envelopedData OBJECT IDENTIFIER ::= { pkcs-7 3 }
   signedAndEnvelopedData OBJECT IDENTIFIER ::=
      { pkcs-7 4 }
   digestedData OBJECT IDENTIFIER ::= { pkcs-7 5 }
   encryptedData OBJECT IDENTIFIER ::= { pkcs-7 6 }

   These object identifiers are intended to be used in the contentType
   field of a value of type ContentInfo (see Section 5). The content
   field of that type, which has the content-type-specific syntax ANY
   DEFINED BY contentType, would have ASN.1 type Data, SignedData,
   EnvelopedData, SignedAndEnvelopedData, DigestedData, and
   EncryptedData, respectively. These object identifiers are also
   intended to be used in a PKCS #9 content-type attribute.

Security Considerations

   Security issues are discussed throughout this memo.

Revision history


   Versions 1.0-1.3

   Versions 1.0-1.3 were distributed to participants in RSA Data
   Security, Inc.'s Public-Key Cryptography Standards meetings in
   February and March 1991.


   Version 1.4

   Version 1.4 is part of the June 3, 1991 initial public release of
   PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop
   document SEC-SIG-91-22.




Kaliski                      Informational                     [Page 29]

RFC 2315          PKCS