rfc2630.txt

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

   the message digest calculation process and the signer's private key.
   The details of the signature generation depend on the signature
   algorithm employed.  The object identifier, along with any
   parameters, that specifies the signature algorithm employed by the
   signer is carried in the signatureAlgorithm field.  The signature
   value generated by the signer is encoded as an OCTET STRING and
   carried in the signature field.

5.6  Message Signature Verification Process

   The input to the signature verification process includes the result
   of the message digest calculation process and the signer's public
   key.  The recipient may obtain the correct public key for the signer
   by any means, but the preferred method is from a certificate obtained
   from the SignedData certificates field.  The selection and validation
   of the signer's public key may be based on certification path
   validation (see [PROFILE]) as well as other external context, but is
   beyond the scope of this document.  The details of the signature
   verification depend on the signature algorithm employed.

   The recipient may not rely on any message digest values computed by
   the originator.  If the signedData signerInfo includes
   signedAttributes, then the content message digest must be calculated
   as described in section 5.4.  For the signature to be valid, the
   message digest value calculated by the recipient must be the same as
   the value of the messageDigest attribute included in the
   signedAttributes of the signedData signerInfo.

6  Enveloped-data Content Type

   The enveloped-data content type consists of an encrypted content of
   any type and encrypted content-encryption keys for one or more
   recipients.  The combination of the encrypted content and one
   encrypted content-encryption key for a recipient is a "digital
   envelope" for that recipient.  Any type of content can be enveloped
   for an arbitrary number of recipients using any of the three key
   management techniques for each recipient.




Housley                     Standards Track                    [Page 12]

RFC 2630              Cryptographic Message Syntax             June 1999


   The typical application of the enveloped-data content type will
   represent one or more recipients' digital envelopes on content of the
   data or signed-data content types.

   Enveloped-data is constructed by the following steps:

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

      2.  The content-encryption key is encrypted for each recipient.
      The details of this encryption depend on the key management
      algorithm used, but three general techniques are supported:

         key transport:  the content-encryption key is encrypted in the
         recipient's public key;

         key agreement:  the recipient's public key and the sender's
         private key are used to generate a pairwise symmetric key, then
         the content-encryption key is encrypted in the pairwise
         symmetric key; and

         symmetric key-encryption keys:  the content-encryption key is
         encrypted in a previously distributed symmetric key-encryption
         key.

      3.  For each recipient, the encrypted content-encryption key and
      other recipient-specific information are collected into a
      RecipientInfo value, defined in Section 6.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 6.3.

      5.  The RecipientInfo values for all the recipients are collected
      together with the encrypted content to form an EnvelopedData value
      as defined in Section 6.1.

   A recipient opens the digital envelope by decrypting one of the
   encrypted content-encryption keys and then decrypting the encrypted
   content with the recovered content-encryption 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.






Housley                     Standards Track                    [Page 13]

RFC 2630              Cryptographic Message Syntax             June 1999


6.1  EnvelopedData Type

   The following object identifier identifies the enveloped-data content
   type:

      id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

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

      EnvelopedData ::= SEQUENCE {
        version CMSVersion,
        originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
        recipientInfos RecipientInfos,
        encryptedContentInfo EncryptedContentInfo,
        unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

      OriginatorInfo ::= SEQUENCE {
        certs [0] IMPLICIT CertificateSet OPTIONAL,
        crls [1] IMPLICIT CertificateRevocationLists OPTIONAL }

      RecipientInfos ::= SET OF RecipientInfo

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

      EncryptedContent ::= OCTET STRING

      UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute

   The fields of type EnvelopedData have the following meanings:

      version is the syntax version number.  If originatorInfo is
      present, then version shall be 2.  If any of the RecipientInfo
      structures included have a version other than 0, then the version
      shall be 2.  If unprotectedAttrs is present, then version shall be
      2.  If originatorInfo is absent, all of the RecipientInfo
      structures are version 0, and unprotectedAttrs is absent, then
      version shall be 0.

      originatorInfo optionally provides information about the
      originator.  It is present only if required by the key management
      algorithm.  It may contain certificates and CRLs:

         certs is a collection of certificates.  certs may contain
         originator certificates associated with several different key



Housley                     Standards Track                    [Page 14]

RFC 2630              Cryptographic Message Syntax             June 1999


         management algorithms.  certs may also contain attribute
         certificates associated with the originator.  The certificates
         contained in certs are intended to be sufficient to make chains
         from a recognized "root" or "top-level certification authority"
         to all recipients.  However, certs may contain more
         certificates than necessary, and there may be certificates
         sufficient to make chains from two or more independent top-
         level certification authorities.  Alternatively, certs may
         contain fewer certificates than necessary, if it is expected
         that recipients have an alternate means of obtaining necessary
         certificates (e.g., from a previous set of certificates).

         crls is a collection of CRLs.  It is intended that the set
         contain information sufficient to determine whether or not the
         certificates in the certs field are valid, but such
         correspondence is not necessary.  There may be more CRLs than
         necessary, and there may also be fewer CRLs than necessary.

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

      encryptedContentInfo is the encrypted content information.

      unprotectedAttrs is a collection of attributes that are not
      encrypted.  The field is optional.  Useful attribute types are
      defined in Section 11.

   The fields of type EncryptedContentInfo have the following meanings:

      contentType indicates the type of content.

      contentEncryptionAlgorithm identifies the content-encryption
      algorithm, and any associated parameters, used to encrypt the
      content.  The content-encryption process is described in Section
      6.3.  The same content-encryption algorithm and content-encryption
      key is used for all recipients.

      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.

   The recipientInfos field comes before the encryptedContentInfo field
   so that an EnvelopedData value may be processed in a single pass.

6.2  RecipientInfo Type

   Per-recipient information is represented in the type RecipientInfo.
   RecipientInfo has a different format for the three key management



Housley                     Standards Track                    [Page 15]

RFC 2630              Cryptographic Message Syntax             June 1999


   techniques that are supported: key transport, key agreement, and
   previously distributed symmetric key-encryption keys.  Any of the
   three key management techniques can be used for each recipient of the
   same encrypted content.  In all cases, the content-encryption key is
   transferred to one or more recipient in encrypted form.

      RecipientInfo ::= CHOICE {
        ktri KeyTransRecipientInfo,
        kari [1] KeyAgreeRecipientInfo,
        kekri [2] KEKRecipientInfo }

      EncryptedKey ::= OCTET STRING

6.2.1  KeyTransRecipientInfo Type

   Per-recipient information using key transport is represented in the
   type KeyTransRecipientInfo.  Each instance of KeyTransRecipientInfo
   transfers the content-encryption key to one recipient.

      KeyTransRecipientInfo ::= SEQUENCE {
        version CMSVersion,  -- always set to 0 or 2
        rid RecipientIdentifier,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        encryptedKey EncryptedKey }

      RecipientIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier }

   The fields of type KeyTransRecipientInfo have the following meanings:

      version is the syntax version number.  If the RecipientIdentifier
      is the CHOICE issuerAndSerialNumber, then the version shall be 0.
      If the RecipientIdentifier is subjectKeyIdentifier, then the
      version shall be 2.

      rid specifies the recipient's certificate or key that was used by
      the sender to protect the content-encryption key.  The
      RecipientIdentifier provides two alternatives for specifying the
      recipient's certificate, and thereby the recipient's public key.
      The recipient's certificate must contain a key transport public
      key.  The content-encryption key is encrypted with the recipient's
      public key.  The issuerAndSerialNumber alternative identifies the
      recipient's certificate by the issuer's distinguished name and the
      certificate serial number; the subjectKeyIdentifier identifies the
      recipient's certificate by the X.509 subjectKeyIdentifier
      extension value.




Housley                     Standards Track                    [Page 16]

RFC 2630              Cryptographic Message Syntax             June 1999


      keyEncryptionAlgorithm identifies the key-encryption algorithm,
      and any associated parameters, used to encrypt the content-
      encryption key for the recipient.  The key-encryption process is
      described in Section 6.4.

      encryptedKey is the result of encrypting the content-encryption
      key for the recipient.

6.2.2  KeyAgreeRecipientInfo Type

   Recipient information using key agreement is represented in the type
   KeyAgreeRecipientInfo.  Each instance of KeyAgreeRecipientInfo will
   transfer the content-encryption key to one or more recipient that
   uses the same key agreement algorithm and domain parameters for that
   algorithm.

      KeyAgreeRecipientInfo ::= SEQUENCE {
        version CMSVersion,  -- always set to 3
        originator [0] EXPLICIT OriginatorIdentifierOrKey,
        ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        recipientEncryptedKeys RecipientEncryptedKeys }

      OriginatorIdentifierOrKey ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier,
        originatorKey [1] OriginatorPublicKey }

      OriginatorPublicKey ::= SEQUENCE {
        algorithm AlgorithmIdentifier,
        publicKey BIT STRING }

      RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey

      RecipientEncryptedKey ::= SEQUENCE {
        rid KeyAgreeRecipientIdentifier,
        encryptedKey EncryptedKey }

      KeyAgreeRecipientIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        rKeyId [0] IMPLICIT RecipientKeyIdentifier }

      RecipientKeyIdentifier ::= SEQUENCE {
        subjectKeyIdentifier SubjectKeyIdentifier,
        date GeneralizedTime OPTIONAL,
        other OtherKeyAttribute OPTIONAL }