rfc2315.txt

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

                  o    the digestAlgorithms and signerInfos
                       fields may contain zero elements in version 1,
                       but not in version 0

                  o    the crls field is allowed in version 1,
                       but not in version 0

             Except for the difference in version number, version 0
             SignedData values are acceptable as version 1 values. An
             implementation can therefore process SignedData values of
             either version as though they were version 1 values. It is
             suggested that PKCS implementations generate only version 1
             SignedData values, but be prepared to process SignedData
             values of either version.







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


        3.   In the degenerate case where there are no signers
             on the content, the ContentInfo value being "signed" is
             irrelevant. It is recommended in that case that the content
             type of the ContentInfo value being "signed" be data, and
             the content field of the ContentInfo value be omitted.

9.2 SignerInfo type

   Per-signer information is represented in the type SignerInfo:

   SignerInfo ::= SEQUENCE {
     version Version,
     issuerAndSerialNumber IssuerAndSerialNumber,
     digestAlgorithm DigestAlgorithmIdentifier,
     authenticatedAttributes
       [0] IMPLICIT Attributes OPTIONAL,
     digestEncryptionAlgorithm
       DigestEncryptionAlgorithmIdentifier,
     encryptedDigest EncryptedDigest,
     unauthenticatedAttributes
       [1] IMPLICIT Attributes OPTIONAL }

   EncryptedDigest ::= OCTET STRING

   The fields of type SignerInfo have the following meanings:

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

        o    issuerAndSerialNumber specifies the signer's
             certificate (and thereby the signer's distinguished name
             and public key) by issuer distinguished name and issuer-
             specific serial number.

        o    digestAlgorithm identifies the message-digest
             algorithm (and any associated parameters) under which the
             content and authenticated attributes (if present) are
             digested. It should be among those in the digestAlgorithms
             field of the superior SignerInfo value. The message-
             digesting process is described in Section 9.3.

        o    authenticatedAttributes is a set of attributes
             that are signed (i.e., authenticated) by the signer. The
             field is optional, but it must be present if the content
             type of the ContentInfo value being signed is not data. If
             the field is present, it must contain, at a minimum, two
             attributes:




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


                  1.   A PKCS #9 content-type attribute having
                       as its value the content type of the
                       ContentInfo value being signed.

                  2.   A PKCS #9 message-digest attribute,
                       having as its value the message digest
                       of the content (see below).

             Other attribute types that might be useful here, such as
             signing time, are also defined in PKCS #9.

        o    digestEncryptionAlgorithm identifies the digest-
             encryption algorithm (and any associated parameters) under
             which the message digest and associated information are
             encrypted with the signer's private key. The digest-
             encryption process is described in Section 9.4.

        o    encryptedDigest is the result of encrypting the
             message digest and associated information with the signer's
             private key.

        o    unauthenticatedAttributes is a set of attributes
             that are not signed (i.e., authenticated) by the signer.
             The field is optional. Attribute types that might be useful
             here, such as countersignatures, are defined in PKCS #9.

   Notes.

        1.   It is recommended in the interest of PEM
             compatibility that the authenticatedAttributes field be
             omitted whenever the content type of the ContentInfo value
             being signed is data and there are no other authenticated
             attributes.

        2.   The difference between version 1 SignerInfo and
             version 0 SignerInfo (defined in PKCS #7, Version 1.4) is
             in the message-digest encryption process (see Section 9.4).
             Only the PEM-compatible processes are different, reflecting
             changes in Privacy-Enhanced Mail signature methods. There
             is no difference in the non-PEM-compatible message-digest
             encryption process.

             It is suggested that PKCS implementations generate only
             version 1 SignedData values. Since the PEM signature method
             with which version 0 is compatible is obsolescent, it is
             suggested that PKCS implementations be prepared to receive
             only version 1 SignedData values.




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


9.3 Message-digesting process

   The message-digesting process computes a message digest on either the
   content being signed or the content together with the signer's
   authenticated attributes. In either case, the initial input to the
   message-digesting process is the "value" of the content being signed.
   Specifically, the initial input is the contents octets of the DER
   encoding of the content field of the ContentInfo value to which the
   signing process is applied. Only the contents octets of the DER
   encoding of that field are digested, not the identifier octets or the
   length octets.

   The result of the message-digesting process (which is called,
   informally, the "message digest") depends on whether the
   authenticatedAttributes field is present. When the field is absent,
   the result is just the message digest of the content. When the field
   is present, however, the result is the message digest of the complete
   DER encoding of the Attributes value containted in the
   authenticatedAttributes field. (For clarity: The IMPLICIT [0] tag in
   the authenticatedAttributes field is not part of the Attributes
   value. The Attributes value's tag is SET OF, and the DER encoding of
   the SET OF tag, rather than of the IMPLICIT [0] tag, is to be
   digested along with the length and contents octets of the Attributes
   value.) Since the Attributes value, when the field is present, must
   contain as attributes the content type and the message digest of the
   content, those values are indirectly included in the result.

   When the content being signed has content type data and the
   authenticatedAttributes field is absent, then just the value of the
   data (e.g., the contents of a file) is digested. This has the
   advantage that the length of the content being signed need not be
   known in advance of the encryption process. This method is compatible
   with Privacy-Enhanced Mail.

   Although the identifier octets and the length octets are not
   digested, they are still protected by other means. The length octets
   are protected by the nature of the message-digest algorithm since it
   is by assumption computationally infeasible to find any two distinct
   messages of any length that have the same message digest.
   Furthermore, assuming that the content type uniquely determines the
   identifier octets, the identifier octets are protected implicitly in
   one of two ways: either by the inclusion of the content type in the
   authenticated attributes, or by the use of the PEM-compatible
   alternative in Section 9.4 which implies that the content type is
   data.






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


   Note. The fact that the message digest is computed on part of a DER
   encoding does not mean that DER is the required method of
   representing that part for data transfer. Indeed, it is expected that
   some implementations of this document may store objects in other than
   their DER encodings, but such practices do not affect message-digest
   computation.

9.4 Digest-encryption process

   The input to the digest-encryption process--the value supplied to the
   signer's digest-encryption algorithm--includes the result of the
   message-digesting process (informally, the "message digest") and the
   digest algorithm identifier (or object identifier). The result of the
   digest-encryption process is the encryption with the signer's private
   key of the BER encoding of a value of type DigestInfo:

   DigestInfo ::= SEQUENCE {
     digestAlgorithm DigestAlgorithmIdentifier,
     digest Digest }

   Digest ::= OCTET STRING

   The fields of type DigestInfo have the following meanings:

        o    digestAlgorithm identifies the message-digest
             algorithm (and any associated parameters) under which the
             content and authenticated attributes are digested. It
             should be the same as the digestAlgorithm field of the
             superior SignerInfo value.

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

   Notes.

        1.   The only difference between the signature process
             defined here and the signature algorithms defined in PKCS
             #1 is that signatures there are represented as bit strings,
             for consistency with the X.509 SIGNED macro. Here,
             encrypted message digests are octet strings.

        2.   The input to the encryption process typically will
             have 30 or fewer octets. If digestEncryptionAlgorithm is
             PKCS #1's rsaEncryption, then this means that the input can
             be encrypted in a single block as long as the length of the
             RSA modulus is at least 328 bits, which is reasonable and
             consistent with security recommendations.




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


        3.   A message-digest algorithm identifier is included
             in the DigestInfo value to limit the damage resulting from
             the compromise of one message-digest algorithm. For
             instance, suppose an adversary were able to find messages
             with a given MD2 message digest.  That adversary could then
             forge a signature by finding a message with the same MD2
             message digest as one that a signer previously signed, and
             presenting the previous signature as the signature on the
             new message.  This attack would succeed only if the signer
             previously used MD2, since the DigestInfo value contains
             the message-digest algorithm.  If a signer never trusted
             the MD2 algorithm and always used MD5, then the compromise
             of MD2 would not affect the signer. If the DigestInfo value
             contained only the message digest, however, the compromise
             of MD2 would affect signers that use any message-digest
             algorithm.

        4.   There is potential for ambiguity due to the fact
             that the DigestInfo value does not indicate whether the
             digest field contains just the message digest of the
             content or the message digest of the complete DER encoding
             of the authenticatedAttributes field. In other words, it is
             possible for an adversary to transform a signature on
             authenticated attributes to one that appears to be just on
             content by changing the content to be the DER encoding of
             the authenticatedAttributes field, and then removing the
             authenticatedAttributes field. (The reverse transformation
             is possible, but requires that the content be the DER
             encoding of an authenticated attributes value, which is
             unlikely.) This ambiguity is not a new problem, nor is it a
             significant one, as context will generally prevent misuse.
             Indeed, it is also possible for an adversary to transform a
             signature on a certificate or certificate-revocation list
             to one that appears to be just on signed-data content.

9.5 Compatibility with Privacy-Enhanced Mail

   Compatibility with the MIC-ONLY and MIC-CLEAR process types in PEM
   occurs when the content type of the ContentInfo value being signed is
   data, there are no authenticated attributes, the message-digest
   algorithm is md2 or md5, and the digest-encryption algorithm is PKCS
   #1's rsaEncryption. Under all those conditions, the encrypted message
   digest produced here matches the one produced in PEM because:

        1.   The value input to the message-digest algorithm in
             PEM is the same as in this document when there are no
             authenticated attributes. MD2 and MD5 in PEM are the same
             as md2 and md5.



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


        2.   The value encrypted with the signer's private key
             in PEM (as specified in RFC 1423) is the same as in this
             document when there are no authenticated attributes. RSA
             private-key encryption in PEM is the same as PKCS #1's
             rsaEncryption.

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

10. Enveloped-data content type

   The enveloped-data content type consists of encrypted content of any
   type and encrypted content-encryption keys for one or more
   recipients. The combination of encrypted content and encrypted
   content-encryption key for a recipient is a "digital envelope" for
   that recipient. Any type of content can be enveloped for any number
   of recipients in parallel.

   It is expected that the typical application of the enveloped-data