Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5652

Cryptographic Message Syntax (CMS)

Pages: 56
Internet Standard: 70
Errata
Obsoletes:  3852
Updated by:  8933
Part 2 of 3 – Pages 17 to 34
First   Prev   Next

Top   ToC   RFC5652 - Page 17   prevText

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.
Top   ToC   RFC5652 - Page 18
   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 }
Top   ToC   RFC5652 - Page 19
   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
Top   ToC   RFC5652 - Page 20
      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.
Top   ToC   RFC5652 - Page 21
   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
Top   ToC   RFC5652 - Page 22

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.
Top   ToC   RFC5652 - Page 23
      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
Top   ToC   RFC5652 - Page 24
   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
Top   ToC   RFC5652 - Page 25
      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 }
Top   ToC   RFC5652 - Page 26
   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 }
Top   ToC   RFC5652 - Page 27
   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.
Top   ToC   RFC5652 - Page 28
   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.
Top   ToC   RFC5652 - Page 29
   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.
Top   ToC   RFC5652 - Page 30
   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.
Top   ToC   RFC5652 - Page 31
   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:
Top   ToC   RFC5652 - Page 32
         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:
Top   ToC   RFC5652 - Page 33
         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
Top   ToC   RFC5652 - Page 34
   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.


(page 34 continued on part 3)

Next Section