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 supported key
   management techniques for each recipient.

   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 four 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;

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

         passwords: the content-encryption key is encrypted in a key-
         encryption key that is derived from a password or other shared
         secret value.

   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.

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 RevocationInfoChoices OPTIONAL }

      RecipientInfos ::= SET SIZE (1..MAX) 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.  The appropriate value
      depends on originatorInfo, RecipientInfo, and unprotectedAttrs.
      The version MUST be assigned as follows:

         IF (originatorInfo is present) AND
            ((any certificates with a type of other are present) OR
            (any crls with a type of other are present))
         THEN version is 4
         ELSE
            IF ((originatorInfo is present) AND
               (any version 2 attribute certificates are present)) OR
               (any RecipientInfo structures include pwri) OR
               (any RecipientInfo structures include ori)
            THEN version is 3
            ELSE
               IF (originatorInfo is absent) AND
                  (unprotectedAttrs is absent) AND
                  (all RecipientInfo structures are version 0)
               THEN version is 0
               ELSE version is 2

      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
         management algorithms.  certs may also contain attribute
         certificates associated with the originator.  The certificates
         contained in certs are intended to be sufficient for all
         recipients to build certification paths from a recognized
         "root" or "top-level certification authority".  However, certs
         may contain more certificates than necessary, and there may be
         certificates sufficient to make certification paths 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 are 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 each of the supported key
   management techniques.  Any of the key management techniques can be
   used for each recipient of the same encrypted content.  In all cases,
   the encrypted content-encryption key is transferred to one or more
   recipients.

   Since all implementations will not support every possible key
   management algorithm, all implementations MUST gracefully handle
   unimplemented algorithms when they are encountered.  For example, if
   a recipient receives a content-encryption key encrypted in their RSA
   public key using RSA-OAEP (Optimal Asymmetric Encryption Padding) and
   the implementation only supports RSA PKCS #1 v1.5, then a graceful
   failure must be implemented.

   Implementations MUST support key transport, key agreement, and
   previously distributed symmetric key-encryption keys, as represented
   by ktri, kari, and kekri, respectively.  Implementations MAY support
   the password-based key management as represented by pwri.
   Implementations MAY support any other key management technique as
   represented by ori.  Since each recipient can employ a different key
   management technique and future specifications could define
   additional key management techniques, all implementations MUST
   gracefully handle unimplemented alternatives within the RecipientInfo
   CHOICE, all implementations MUST gracefully handle unimplemented
   versions of otherwise supported alternatives within the RecipientInfo
   CHOICE, and all implementations MUST gracefully handle unimplemented
   or unknown ori alternatives.

      RecipientInfo ::= CHOICE {
        ktri KeyTransRecipientInfo,
        kari [1] KeyAgreeRecipientInfo,
        kekri [2] KEKRecipientInfo,
        pwri [3] PasswordRecipientinfo,
        ori [4] OtherRecipientInfo }

      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 MUST be 0.
      If the RecipientIdentifier is subjectKeyIdentifier, then the
      version MUST be 2.

      rid specifies the recipient's certificate or key that was used by
      the sender to protect the content-encryption key.  The content-
      encryption key is encrypted with the recipient's public 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.  Therefore, a recipient X.509 version 3 certificate that
      contains a key usage extension MUST assert the keyEncipherment
      bit.  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 a key identifier.  When an X.509
      certificate is referenced, the key identifier matches the X.509
      subjectKeyIdentifier extension value.  When other certificate
      formats are referenced, the documents that specify the certificate
      format and their use with the CMS must include details on matching
      the key identifier to the appropriate certificate field.  For
      recipient processing, implementations MUST support both of these
      alternatives for specifying the recipient's certificate.  For
      sender processing, implementations MUST support at least one of
      these alternatives.

      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 recipients that
   use 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 }

      SubjectKeyIdentifier ::= OCTET STRING

   The fields of type KeyAgreeRecipientInfo have the following meanings:

      version is the syntax version number.  It MUST 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
      a key identifier.  When an X.509 certificate is referenced, the
      key identifier matches the X.509 subjectKeyIdentifier extension
      value.  When other certificate formats are referenced, the
      documents that specify the certificate format and their use with
      the CMS must include details on matching the key identifier to the
      appropriate certificate field.  The originatorKey alternative
      includes the algorithm identifier and sender's key agreement
      public key.  This alternative permits originator anonymity since
      the public key is not certified.  Implementations MUST support all
      three alternatives for specifying the sender's public key.

      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.  Implementations MUST accept a KeyAgreeRecipientInfo
      SEQUENCE that includes a ukm field.  Implementations that do not
      support key agreement algorithms that make use of UKMs MUST
      gracefully handle the presence of UKMs.

      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.

      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.  Therefore, a recipient X.509
      version 3 certificate that contains a key usage extension MUST
      assert the keyAgreement bit.  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.  Implementations MUST support both
      alternatives for specifying the recipient's certificate.

   The fields of type RecipientKeyIdentifier have the following
   meanings:

      subjectKeyIdentifier identifies the recipient's certificate by a
      key identifier.  When an X.509 certificate is referenced, the key
      identifier matches the X.509 subjectKeyIdentifier extension value.
      When other certificate formats are referenced, the documents that
      specify the certificate format and their use with the CMS must
      include details on matching the key identifier to the appropriate
      certificate field.

      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 MUST 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.

      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.2.4.  PasswordRecipientInfo Type

   Recipient information using a password or shared secret value is
   represented in the type PasswordRecipientInfo.  Each instance of
   PasswordRecipientInfo will transfer the content-encryption key to one
   or more recipients who possess the password or shared secret value.

   The PasswordRecipientInfo Type is specified in RFC 3211 [PWRI].  The
   PasswordRecipientInfo structure is repeated here for completeness.

      PasswordRecipientInfo ::= SEQUENCE {
        version CMSVersion,   -- Always set to 0
        keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier
                                     OPTIONAL,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        encryptedKey EncryptedKey }

   The fields of type PasswordRecipientInfo have the following meanings:

      version is the syntax version number.  It MUST always be 0.

      keyDerivationAlgorithm identifies the key-derivation algorithm,
      and any associated parameters, used to derive the key-encryption
      key from the password or shared secret value.  If this field is
      absent, the key-encryption key is supplied from an external
      source, for example a hardware crypto token such as a smart card.

      keyEncryptionAlgorithm identifies the encryption algorithm, and
      any associated parameters, used to encrypt the content-encryption
      key with the key-encryption key.

      encryptedKey is the result of encrypting the content-encryption
      key with the key-encryption key.

6.2.5.  OtherRecipientInfo Type

   Recipient information for additional key management techniques are
   represented in the type OtherRecipientInfo.  The OtherRecipientInfo
   type allows key management techniques beyond key transport, key
   agreement, previously distributed symmetric key-encryption keys, and
   password-based key management to be specified in future documents.
   An object identifier uniquely identifies such key management
   techniques.

      OtherRecipientInfo ::= SEQUENCE {
        oriType OBJECT IDENTIFIER,
        oriValue ANY DEFINED BY oriType }

   The fields of type OtherRecipientInfo have the following meanings:

      oriType identifies the key management technique.

      oriValue contains the protocol data elements needed by a recipient
      using the identified key management technique.

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.

   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 aforementioned key management techniques can be used for
   each recipient of the same encrypted content.

7.  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 MUST be 0; however, if
      the encapsulated content type is other than id-data, then the
      value of version MUST 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.

      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 derived from 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 the version MUST be 2.  If unprotectedAttrs is
      absent, then version MUST 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.

9.  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
       any information in addition to the content (see Section 9.2), a
       message digest is calculated on the content, the message digest
       of the content and the other information are authenticated using
       the message-authentication key, and the result becomes the "MAC
       value".

9.1.  AuthenticatedData Type

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

      id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
         ct(1) 2 }

   The authenticated-data content type shall have ASN.1 type
   AuthenticatedData:

      AuthenticatedData ::= SEQUENCE {
        version CMSVersion,
        originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
        recipientInfos RecipientInfos,
        macAlgorithm MessageAuthenticationCodeAlgorithm,
        digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
        encapContentInfo EncapsulatedContentInfo,
        authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
        mac MessageAuthenticationCode,
        unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }

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

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

      MessageAuthenticationCode ::= OCTET STRING

   The fields of type AuthenticatedData have the following meanings:

      version is the syntax version number.  The version MUST be
      assigned as follows:

         IF (originatorInfo is present) AND
            ((any certificates with a type of other are present) OR
            (any crls with a type of other are present))
         THEN version is 3
         ELSE
            IF ((originatorInfo is present) AND
               (any version 2 attribute certificates are present))
            THEN version is 1
            ELSE version is 0

      originatorInfo optionally provides information about the
      originator.  It is present only if required by the key management
      algorithm.  It MAY contain certificates, attribute certificates,
      and CRLs, as defined in Section 6.1.

      recipientInfos is a collection of per-recipient information, as
      defined in Section 6.1.  There MUST be at least one element in the
      collection.

      macAlgorithm is a message authentication code (MAC) algorithm
      identifier.  It identifies the MAC algorithm, along with any
      associated parameters, used by the originator.  Placement of the
      macAlgorithm field facilitates one-pass processing by the
      recipient.

      digestAlgorithm identifies the message digest algorithm, and any
      associated parameters, used to compute a message digest on the
      encapsulated content if authenticated attributes are present.  The
      message digesting process is described in Section 9.2.  Placement
      of the digestAlgorithm field facilitates one-pass processing by
      the recipient.  If the digestAlgorithm field is present, then the
      authAttrs field MUST also be present.

      encapContentInfo is the content that is authenticated, as defined
      in Section 5.2.

      authAttrs is a collection of authenticated attributes.  The
      authAttrs structure is optional, but it MUST be present if the
      content type of the EncapsulatedContentInfo value being
      authenticated is not id-data.  If the authAttrs field is present,
      then the digestAlgorithm field MUST also be present.  The
      AuthAttributes structure MUST be DER encoded, even if the rest of
      the structure is BER encoded.  Useful attribute types are defined
      in Section 11.  If the authAttrs field is present, it MUST
      contain, at a minimum, the following two attributes:

         A content-type attribute having as its value the content type
         of the EncapsulatedContentInfo value being authenticated.
         Section 11.1 defines the content-type attribute.

         A message-digest attribute, having as its value the message
         digest of the content.  Section 11.2 defines the message-digest
         attribute.

      mac is the message authentication code.

      unauthAttrs is a collection of attributes that are not
      authenticated.  The field is optional.  To date, no attributes
      have been defined for use as unauthenticated attributes, but other
      useful attribute types are defined in Section 11.

9.2.  MAC Generation

   The MAC calculation process computes a message authentication code
   (MAC) on either the content being authenticated or a message digest
   of content being authenticated together with the originator's
   authenticated attributes.

   If the authAttrs field is absent, the input to the MAC calculation
   process is the value of the encapContentInfo eContent OCTET STRING.
   Only the octets comprising the value of the eContent OCTET STRING are
   input to the MAC algorithm; the tag and the length octets are
   omitted.  This has the advantage that the length of the content being
   authenticated need not be known in advance of the MAC generation
   process.

   If the authAttrs field is present, the content-type attribute (as
   described in Section 11.1) and the message-digest attribute (as
   described in Section 11.2) MUST be included, and the input to the MAC
   calculation process is the DER encoding of authAttrs.  A separate
   encoding of the authAttrs field is performed for message digest
   calculation.  The IMPLICIT [2] tag in the authAttrs field is not used
   for the DER encoding, rather an EXPLICIT SET OF tag is used.  That
   is, the DER encoding of the SET OF tag, rather than of the IMPLICIT
   [2] tag, is to be included in the message digest calculation along
   with the length and content octets of the authAttrs value.

   The message digest calculation process computes a message digest on
   the content being authenticated.  The initial input to the message
   digest calculation process is the "value" of the encapsulated content
   being authenticated.  Specifically, the input is the encapContentInfo
   eContent OCTET STRING to which the authentication process is applied.
   Only the octets comprising the value of the encapContentInfo eContent
   OCTET STRING are input to the message digest algorithm, not the tag

   or the length octets.  This has the advantage that the length of the
   content being authenticated need not be known in advance.  Although
   the encapContentInfo eContent OCTET STRING tag and length octets are
   not included in the message digest calculation, they are still
   protected by other means.  The length octets are protected by the
   nature of the message digest algorithm since it is computationally
   infeasible to find any two distinct contents of any length that have
   the same message digest.

   The input to the MAC calculation process includes the MAC input data,
   defined above, and an authentication key conveyed in a recipientInfo
   structure.  The details of MAC calculation depend on the MAC
   algorithm employed (e.g., Hashed Message Authentication Code (HMAC)).
   The object identifier, along with any parameters, that specifies the
   MAC algorithm employed by the originator is carried in the
   macAlgorithm field.  The MAC value generated by the originator is
   encoded as an OCTET STRING and carried in the mac field.

9.3.  MAC Verification

   The input to the MAC verification process includes the input data
   (determined based on the presence or absence of the authAttrs field,
   as defined in 9.2), and the authentication key conveyed in
   recipientInfo.  The details of the MAC verification process depend on
   the MAC algorithm employed.

   The recipient MUST NOT rely on any MAC values or message digest
   values computed by the originator.  The content is authenticated as
   described in Section 9.2.  If the originator includes authenticated
   attributes, then the content of the authAttrs is authenticated as
   described in Section 9.2.  For authentication to succeed, the MAC
   value calculated by the recipient MUST be the same as the value of
   the mac field.  Similarly, for authentication to succeed when the
   authAttrs field is present, the content message digest value
   calculated by the recipient MUST be the same as the message digest
   value included in the authAttrs message-digest attribute.

   If the AuthenticatedData includes authAttrs, then the content-type
   attribute value MUST match the AuthenticatedData encapContentInfo
   eContentType value.