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 19996.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 keyHousley                     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 managementHousley                     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 STRING6.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 }