rfc2315.txt

RFC 的详细文档！

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
   content type will be to represent one or more recipients' digital
   envelopes on content of the data, digested-data, or signed-data
   content types.

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

        1.   A content-encryption key for a particular content-
             encryption algorithm is generated at random.

        2.   For each recipient, the content-encryption key is
             encrypted with the recipient's public key.

        3.   For each recipient, the encrypted content-
             encryption key and other recipient-specific information are
             collected into a RecipientInfo value, defined in Section
             10.2.

        4.   The content is encrypted with the content-
             encryption key. (Content encryption may require that the
             content be padded to a multiple of some block size; see
             Section 10.3 for discussion.)

        5.   The RecipientInfo values for all the recipients
             are collected together with the encrypted content into a
             EnvelopedData value, defined in Section 10.1.





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


   A recipient opens the envelope by decrypting the one of the encrypted
   content-encryption keys with the recipient's private key and
   decrypting the encrypted content with the recovered content-
   encryption key. The recipient's private key is referenced by an
   issuer distinguished name and an issuer-specific serial number that
   uniquely identify the certificate for the corresponding public key.

   This section is divided into four parts. The first part describes the
   top-level type EnvelopedData, the second part describes the per-
   recipient information type RecipientInfo, and the third and fourth
   parts describe the content-encryption and key-encryption processes.

   This content type is not compatible with Privacy-Enhanced Mail
   (although some processes it defines are compatible with their PEM
   counterparts), since Privacy-Enhanced Mail always involves digital
   signatures, never digital envelopes alone.

10.1 EnvelopedData type

   The enveloped-data content type shall have ASN.1 type EnvelopedData:

   EnvelopedData ::= SEQUENCE {
     version Version,
     recipientInfos RecipientInfos,
     encryptedContentInfo EncryptedContentInfo }

   RecipientInfos ::= SET OF RecipientInfo

   EncryptedContentInfo ::= SEQUENCE {
     contentType ContentType,
     contentEncryptionAlgorithm
       ContentEncryptionAlgorithmIdentifier,
     encryptedContent
       [0] IMPLICIT EncryptedContent OPTIONAL }

   EncryptedContent ::= OCTET STRING

   The fields of type EnvelopedData have the following meanings:

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

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

        o    encryptedContentInfo is the encrypted content
             information.



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


   The fields of type EncryptedContentInfo have the following meanings:

        o    contentType indicates the type of content.

        o    contentEncryptionAlgorithm identifies the content-
             encryption algorithm (and any associated
             parameters) under which the content is encrypted.
             The content-encryption process is described in
             Section 10.3. This algorithm is the same for all
             recipients.

        o    encryptedContent is the result of encrypting the
             content. The field is optional, and if the field
             is not present, its intended value must be
             supplied by other means.

   Note. The fact that the recipientInfos field comes before the
   encryptedContentInfo field makes it possible to process an
   EnvelopedData value in a single pass. (Single-pass processing is
   described in Section 5.)

10.2 RecipientInfo type

   Per-recipient information is represented in the type RecipientInfo:

   RecipientInfo ::= SEQUENCE {
     version Version,
     issuerAndSerialNumber IssuerAndSerialNumber,
     keyEncryptionAlgorithm

       KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey }

   EncryptedKey ::= OCTET STRING

   The fields of type RecipientInfo have the following meanings:

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

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






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


        o    keyEncryptionAlgorithm identifies the key-
             encryption algorithm (and any associated
             parameters) under which the content-encryption key
             is encrypted with the recipient's public key. The
             key-encryption process is described in Section
             10.4.

        o    encryptedKey is the result of encrypting the
             content-encryption key with the recipient's public
             key (see below).

10.3 Content-encryption process

   The input to the content-encryption process is the "value" of the
   content being enveloped. Specifically, the input is the contents
   octets of a definite-length BER encoding of the content field of the
   ContentInfo value to which the enveloping process is applied. Only
   the contents octets of the BER encoding are encrypted, not the
   identifier octets or length octets; those other octets are not
   represented at all.

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

   The identifier octets and the length octets are not encrypted. The
   length octets may be protected implicitly by the encryption process,
   depending on the encryption algorithm. The identifier octets are not
   protected at all, although they can be recovered from the content
   type, assuming that the content type uniquely determines the
   identifier octets. Explicit protection of the identifier and length
   octets requires that the signed-and-enveloped-data content type be
   employed, or that the digested-data and enveloped-data content types
   be applied in succession.

   Notes.

        1.   The reason that a definite-length BER encoding is
             required is that the bit indicating whether the length is
             definite or indefinite is not recorded anywhere in the
             enveloped-data content type.  Definite-length encoding is
             more appropriate for simple types such as octet strings, so
             definite-length encoding is chosen.






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


        2.   Some content-encryption algorithms assume the
             input length is a multiple of k octets, where k > 1, and
             let the application define a method for handling inputs
             whose lengths are not a multiple of k octets. For such
             algorithms, the method shall be to pad the input at the
             trailing end with k - (l mod k) octets all having value k -
             (l mod k), where l is the length of the input. In other
             words, the input is padded at the trailing end with one of
             the following strings:

                      01 -- if l mod k = k-1
                     02 02 -- if l mod k = k-2
                                 .
                                 .
                                 .
                   k k ... k k -- if l mod k = 0

             The padding can be removed unambiguously since all input is
             padded and no padding string is a suffix of another. This
             padding method is well-defined if and only if k < 256;
             methods for larger k are an open issue for further study.

10.4 Key-encryption process

   The input to the key-encryption process--the value supplied to the
   recipient's key-encryption algorithm--is just the "value" of the
   content-encryption key.

11. Signed-and-enveloped-data content type

   This section defines the signed-and-enveloped-data content type. For
   brevity, much of this section is expressed in terms of material in
   Sections 9 and 10.

   The signed-and-enveloped-data content type consists of encrypted
   content of any type, encrypted content-encryption keys for one or
   more recipients, and doubly encrypted message digests for one or more
   signers. The "double encryption" consists of an encryption with a
   signer's private key followed by an encryption with the content-
   encryption key.

   The combination of encrypted content and encrypted content-encryption
   key for a recipient is a "digital envelope" for that recipient. The
   recovered singly encrypted message digest for a signer is a "digital
   signature" on the recovered content for that signer.  Any type of
   content can be enveloped for any number of recipients and signed by
   any number of signers in parallel.




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


   It is expected that the typical application of the signed-and-
   enveloped-data content type will be to represent one signer's digital
   signature and one or more recipients' digital envelopes on content of
   the data content type.

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

        1.   A content-encryption key for a particular content-
             encryption algorithm is generated at random.

        2.   For each recipient, the content-encryption key is
             encrypted with the recipient's public key.

        3.   For each recipient, the encrypted content-
             encryption key and other recipient-specific
             information are collected into a RecipientInfo
             value, defined in Section 10.2.

        4.   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.)

        5.   For each signer, the message digest and associated
             information are encrypted with the signer's
             private key, and the result is encrypted with the
             content-encryption key. (The second encryption may
             require that the result of the first encryption be