SubjectKeyIdentifier ::= OCTET STRINGHousley                     Standards Track                    [Page 17]RFC 2630              Cryptographic Message Syntax             June 1999   The fields of type KeyAgreeRecipientInfo have the following meanings:      version is the syntax version number.  It shall always be 3.      originator is a CHOICE with three alternatives specifying the      sender's key agreement public key.  The sender uses the      corresponding private key and the recipient's public key to      generate a pairwise key.  The content-encryption key is encrypted      in the pairwise key.  The issuerAndSerialNumber alternative      identifies the sender's certificate, and thereby the sender's      public key, by the issuer's distinguished name and the certificate      serial number.  The subjectKeyIdentifier alternative identifies      the sender's certificate, and thereby the sender's public key, by      the X.509 subjectKeyIdentifier extension value.  The originatorKey      alternative includes the algorithm identifier and sender's key      agreement public key. Permitting originator anonymity since the      public key is not certified.      ukm is optional.  With some key agreement algorithms, the sender      provides a User Keying Material (UKM) to ensure that a different      key is generated each time the same two parties generate a      pairwise key.      keyEncryptionAlgorithm identifies the key-encryption algorithm,      and any associated parameters, used to encrypt the content-      encryption key in the key-encryption key.  The key-encryption      process is described in Section 6.4.      recipientEncryptedKeys includes a recipient identifier and      encrypted key for one or more recipients.  The      KeyAgreeRecipientIdentifier is a CHOICE with two alternatives      specifying the recipient's certificate, and thereby the      recipient's public key, that was used by the sender to generate a      pairwise key-encryption key.  The recipient's certificate must      contain a key agreement public key.  The content-encryption key is      encrypted in the pairwise key-encryption key.  The      issuerAndSerialNumber alternative identifies the recipient's      certificate by the issuer's distinguished name and the certificate      serial number; the RecipientKeyIdentifier is described below.  The      encryptedKey is the result of encrypting the content-encryption      key in the pairwise key-encryption key generated using the key      agreement algorithm.   The fields of type RecipientKeyIdentifier have the following   meanings:      subjectKeyIdentifier identifies the recipient's certificate by the      X.509 subjectKeyIdentifier extension value.Housley                     Standards Track                    [Page 18]RFC 2630              Cryptographic Message Syntax             June 1999      date is optional.  When present, the date specifies which of the      recipient's previously distributed UKMs was used by the sender.      other is optional.  When present, this field contains additional      information used by the recipient to locate the public keying      material used by the sender.6.2.3  KEKRecipientInfo Type   Recipient information using previously distributed symmetric keys is   represented in the type KEKRecipientInfo.  Each instance of   KEKRecipientInfo will transfer the content-encryption key to one or   more recipients who have the previously distributed key-encryption   key.      KEKRecipientInfo ::= SEQUENCE {        version CMSVersion,  -- always set to 4        kekid KEKIdentifier,        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,        encryptedKey EncryptedKey }      KEKIdentifier ::= SEQUENCE {        keyIdentifier OCTET STRING,        date GeneralizedTime OPTIONAL,        other OtherKeyAttribute OPTIONAL }   The fields of type KEKRecipientInfo have the following meanings:      version is the syntax version number.  It shall always be 4.      kekid specifies a symmetric key-encryption key that was previously      distributed to the sender and one or more recipients.      keyEncryptionAlgorithm identifies the key-encryption algorithm,      and any associated parameters, used to encrypt the content-      encryption key with the key-encryption key.  The key-encryption      process is described in Section 6.4.      encryptedKey is the result of encrypting the content-encryption      key in the key-encryption key.   The fields of type KEKIdentifier have the following meanings:      keyIdentifier identifies the key-encryption key that was      previously distributed to the sender and one or more recipients.      date is optional.  When present, the date specifies a single key-      encryption key from a set that was previously distributed.Housley                     Standards Track                    [Page 19]RFC 2630              Cryptographic Message Syntax             June 1999      other is optional.  When present, this field contains additional      information used by the recipient to determine the key-encryption      key used by the sender.6.3  Content-encryption Process   The content-encryption key for the desired content-encryption   algorithm is randomly generated.  The data to be protected is padded   as described below, then the padded data is encrypted using the   content-encryption key.  The encryption operation maps an arbitrary   string of octets (the data) to another string of octets (the   ciphertext) under control of a content-encryption key.  The encrypted   data is included in the envelopedData encryptedContentInfo   encryptedContent OCTET STRING.   The input to the content-encryption process is the "value" of the   content being enveloped.  Only the value octets of the envelopedData   encryptedContentInfo encryptedContent OCTET STRING are encrypted; the   OCTET STRING tag and length octets are not encrypted.   Some content-encryption algorithms assume the input length is a   multiple of k octets, where k is greater than one.  For such   algorithms, the input shall be padded at the trailing end with   k-(lth mod k) octets all having value k-(lth mod k), where lth 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 lth mod k = k-1                  02 02 -- if lth mod k = k-2                      .                      .                      .            k k ... k k -- if lth mod k = 0   The padding can be removed unambiguously since all input is padded,   including input values that are already a multiple of the block size,   and no padding string is a suffix of another.  This padding method is   well defined if and only if k is less than 256.6.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.   Any of the three key management techniques can be used for each   recipient of the same encrypted content.Housley                     Standards Track                    [Page 20]RFC 2630              Cryptographic Message Syntax             June 19997  Digested-data Content Type   The digested-data content type consists of content of any type and a   message digest of the content.   Typically, the digested-data content type is used to provide content   integrity, and the result generally becomes an input to the   enveloped-data content type.   The following steps construct digested-data:      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 following object identifier identifies the digested-data content   type:      id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }   The digested-data content type shall have ASN.1 type DigestedData:      DigestedData ::= SEQUENCE {        version CMSVersion,        digestAlgorithm DigestAlgorithmIdentifier,        encapContentInfo EncapsulatedContentInfo,        digest Digest }      Digest ::= OCTET STRING   The fields of type DigestedData have the following meanings:      version is the syntax version number.  If the encapsulated content      type is id-data, then the value of version shall be 0; however, if      the encapsulated content type is other than id-data, then the      value of version shall be 2.      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 5.4 in the      case when there are no signed attributes.Housley                     Standards Track                    [Page 21]RFC 2630              Cryptographic Message Syntax             June 1999      encapContentInfo is the content that is digested, as defined in      section 5.2.      digest is the result of the message-digesting process.   The ordering of the digestAlgorithm field, the encapContentInfo   field, and the digest field makes it possible to process a   DigestedData value in a single pass.8  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 must be managed by other means.   The typical application of the encrypted-data content type will be to   encrypt the content of the data content type for local storage,   perhaps where the encryption key is a password.   The following object identifier identifies the encrypted-data content   type:      id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }   The encrypted-data content type shall have ASN.1 type EncryptedData:      EncryptedData ::= SEQUENCE {        version CMSVersion,        encryptedContentInfo EncryptedContentInfo,        unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }   The fields of type EncryptedData have the following meanings:      version is the syntax version number.  If unprotectedAttrs is      present, then version shall be 2.  If unprotectedAttrs is absent,      then version shall be 0.      encryptedContentInfo is the encrypted content information, as      defined in Section 6.1.      unprotectedAttrs is a collection of attributes that are not      encrypted.  The field is optional.  Useful attribute types are      defined in Section 11.Housley                     Standards Track                    [Page 22]RFC 2630              Cryptographic Message Syntax             June 19999  Authenticated-data Content Type   The authenticated-data content type consists of content of any type,   a message authentication code (MAC), and encrypted authentication   keys for one or more recipients.  The combination of the MAC and one   encrypted authentication key for a recipient is necessary for that   recipient to verify the integrity of the content.  Any type of   content can be integrity protected for an arbitrary number of   recipients.   The process by which authenticated-data is constructed involves the   following steps:      1.  A message-authentication key for a particular message-      authentication algorithm is generated at random.      2.  The message-authentication key is encrypted for each      recipient.  The details of this encryption depend on the key      management algorithm used.      3.  For each recipient, the encrypted message-authentication key      and other recipient-specific information are collected into a      RecipientInfo value, defined in Section 6.2.      4.  Using the message-authentication key, the originator computes      a MAC value on the content.  If the originator is authenticating