The With-MAC key-wrapping algorithm for Cryptographic Message Syntax
draft-herzog-withmac-keywrap-02

Abstract

This document describes a new key-wrapping algorithm to be used in the EnvelopedData, AuthenticatedData and AuthEnvelopedData structures of the Cryptographic Message Syntax. Because these structures do not provide data-origin authentication, a recipient cannot cryptographically verify that the plaintext received was the plaintext encapsulated by the message's original sender. The With-MAC key-wrapping algorithm allows an EncryptedKey value to hold both a wrapped symmetric key and a MAC value on the data to be authenticated. When used in EnvelopedData, AuthenticatedData and AuthEnvelopedData structures, therefore, these structures can achieve data-origin authentication (in some circumstances) using only symmetric-key algorithms. This is useful in cases where the structures must be generated by entities without certified digital-signature keys.

Disclaimer

This work is sponsored by the United States Air Force under Air Force Contract FA8721-05-C-0002. Opinions, interpretations, conclusions and recommendations are those of the authors and are not necessarily endorsed by the United States Government.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 31, 2013.

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Requirements Terminology
• 3. Structures of the With-MAC key-wrap algorithm
• 4. Actions of the sender
• 5. Actions of the receiver
• 6. Requirements and Recommendations
• 7. Security considerations
• 8. IANA Considerations
• 9. Acknowledgements
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Appendix A. ASN.1 Module
• Authors' Addresses

1. Introduction

KEK1( CPK ) || KEK2( CPK ) || ... || CPK( data )
	

KEK1'( CPK ), MAC1'( CPK( data ) ) || 
  KEK2'( CPK ), MAC2'( CPK( data) ) ||... || CPK( data )
	

This document extends the Cryptographic Message Syntax (CMS) [RFC5652] so as to allow EncryptedKey values to contain both an encrypted key and a message authentication code (MAC) value. CMS is a standard notation and representation for cryptographic messages. Specifically, CMS uses ASN.1 notation [X.680] [X.681] [X.682] [X.683] to define a number of structures for encrypted data, signed data, authenticated data, and so on. Such structures carry both:

CMS supports several different types of wrap-keys, including:

Furthermore, a single top-level structure can hold multiple key-wrap structures, as might be the case when a single message has multiple distinct receivers. In this case, every wrap-structure in the message will encrypt the same CPK. This means, unfortunately, that the top-level CMS structures described above do not provide data-origin authentication. Consider, for example, the following sequence of events:

This same 'attack' can be successfully launched against EnvelopedData and AuthenticatedData structures. We rush to note, however, that none of these structures were actually designed to provide 'data-origin authentication'. By data-origin authentication, we mean the guarantee that a recipient will not accept a message that was not sent, exactly as received, by the ostensible sender. This would require that the messages identify the ostensible sender, but these structures might not do so:

Unfortunately, this is not a universal solution. In particular, the sender may not have a certified public signature key, or the ability to send their signature-verification key to the recipients in an authenticated manner. In this case, the SignedData structure will not be able to provide data-origin authentication guarantees to the recipients(s). Also, 'small' hardware implementations may not be able to include the number-theoretic algorithms that underlie public-key signature schemes, and would therefore be unable to create or process SignedData structures.

Given this, it is desirable to identify alternate methods to achieve data-origin authentication in CMS. In this document, we describe a method by which EnvelopedData, AuthenticatedData, and AuthEnvelopedData structures can provide data-origin authentication using only symmetric cryptographic algorithms. Specifically, we define the With-MAC key-wrap 'algorithm.' In actuality, this 'algorithm' is a pseudo-algorithm which allows key-wrap structures to contain both:

In this way, the With-MAC algorithm provides the following guarantees:

Because the With-MAC algorithm uses only symmetric-key algorithms, it may also be more appropriate than the SignedData structure for resource-constrained (e. g., power, space) hardware implementations. Lastly, we note that MAC values tend to be smaller than digital signatures. Under some circumstances, such as when there are relatively few key-wraps, the With-MAC algorithm may result in shorter messages than a SignedData structure.

• The cryptographically-protected information, and
• Key-management information regarding the keys used.

Of particular interest here are three 'top-level' structures:

• EnvelopedData, which holds encrypted (but not necessarily authenticated) information [RFC5652],
• AuthenticatedData, which holds authenticated (MACed) information [RFC5652], and
• AuthEnvelopedData, which holds information protected by authenticated encryption: a cryptographic scheme that combines encryption and authentication [RFC5083].

All three of these structures are constructed in the same basic way.

• First, the message-creator generates a fresh symmetric key. In context of EnvelopedData structures, AuthenticatedData structures and AuthEnvelopedData structures, this key is called the content-encryption key, the authentication key, and the content-authenticated-encryption key respectively. We will use the term CPK as a generic term when speaking of all three of these structures in the aggregate.
• Next, the creator uses the CPK to cryptographically protect the content.
• Lastly, the CPK is then wrapped for each recipient. That is, copies of the CPK are encrypted in a sequence of 'wrap keys' (one copy per wrap-key) such that every recipient knows or can compute at least one wrap-key.

A recipient, upon receiving the message, decrypts one of the wraps to retrieve the CPK and then uses the CPK to decrypt or verify the content.

• Key transport: the wrap key is the public encryption key of some recipient.
• Key agreement: the wrap key is a key-encryption key (KEK) created using a key-agreement scheme (such as Diffie-Hellman [RFC3370]) and a key-derivation function (KDF).
• Key-encryption key: the wrap key is a previously-distributed symmetric key-encrypting key known to the recipient.
• Password: the wrap key is a key-encryption key derived from a password.

Each of these methods is represented by a different 'key wrap' structure, called the KeyTransRecipientInfo, KeyAgreeRecipientInfo, KEKRecipientInfo and PasswordRecipientInfo structures, respectively. Each such structure is an instance of the RecipientInfo type, which can be embedded in each of EnvelopedData, AuthenticatedData and AuthEnvelopedData, respectively. Thus, each key-wrap method can be used in each top-level structure mentioned above.

• Alice sends an AuthEnvelopedData message to both Bob and Mallory. This message uses a fresh, new content-authenticated-encryption key to protect the plaintext with authenticated-encryption algorithm. This algorithm will produce both ciphertext and MAC value, thus providing both confidentiality and integrity guarantees. Furthermore, Alice will wrap this content-authenticated-encryption key to both Bob and Mallory. The final AuthEnvelopedData message contains the ciphertext, the MAC value, and both wrap-structures (one for Bob and one for Mallory).
• Mallory intercepts the message and prevents Bob from receiving it.
• Mallory unwraps the content-authenticated-encryption key from the wrap intended for her. Mallory then creates new plaintext of her choice, and encrypts it using the same authenticated-encryption algorithm and the same content-authenticated-encryption key used by Alice.
• Mallory then replaces the ciphertext and MAC value of Alice's message with the values just generated. She may additionally remove her key-wrap structure from Alice's message.
• Mallory sends the modified message to Bob.
• Bob receives the message, unwraps the content-authenticated-encryption key, and decrypts/authenticates the message.

At this point, Bob has received and validated a message that appears to have been sent by Alice, but whose content was chosen by Mallory. Furthermore, Mallory may not even be an apparent receiver of the modified message.

• These structures do contain an OriginiatorInfo field, which would identify the sender. This value is sometimes optional, however.
• The key-wrap structures, listed above, may partially identify the sender. The use of password-based key-wrap, for example, implies that the (ostensible) sender is among the entities that know the password. Likewise, the use of key-encrypting-key key-wrap implies that the (ostensible) sender is among the entities that know the key. This is only partial identification, however, and the key-transport key-wrap method will not identify the ostensible sender. (The key-agreement method will identify the sender, if the sender uses a certified public value [RFC6278].)

We also note that it is not strictly necessary for these top-level CMS structures to provide data-origin authentication. CMS already provides an entirely separate structure for this purpose: the SignedData structure, which applies digital signatures to the encapsulated 'plaintext.' Furthermore, these top-level structures can be encapsulated in each other. Alice, above, can entirely prevent the described attack by encapsulating the AuthEnvelopedData structure in a SignedData structure. Then the AuthEnvelopedData structure would be signed by Alice, and Mallory could not change that structure's plaintext without invalidating Alice's signature.

• A content-protecting symmetric key (encrypted, as before), and
• A MAC value protecting the contents of the enclosing EnvelopedData, AuthenticatedData, or AuthEnvelopedData structure.

If the standard CMS encryption operation in an EnvelopedData structure is

• When the key-wrap mechanism is based on a shared key-encrypting key (KEKRecipientInfo) it guarantees to the receiver that the data was sent by someone who knows the relevant key-transportation key.
• When the key-wrap mechanism is based on passwords (PasswordRecipientInfo) it guarantees to the receiver that the data was sent by someone who knows the relevant password.
• When the key-wrap mechanism is based on key-agreement mechanisms (KeyAgreeRecipientInfo) and the sender uses a long-term, certified value, it guarantees to the receiver that the data was sent by someone who knows the sender's private key-agreement key.

The With-MAC algorithm can not be used when the key-wrap method is based on key-transport. It can be used when the key-wrap method is based on key-agreement and the sender uses an ephemeral value, but it provides no data-authentication properties.

2. Requirements Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Structures of the With-MAC key-wrap algorithm

AlgorithmIdentifier  ::=  SEQUENCE  {
     algorithm     OBJECT IDENTIFIER,
     parameters    ANY DEFINED BY algorithm OPTIONAL  }

	  

id-alg-WithMACWrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) X }

	  

WithMACParameters  ::=  SEQUENCE  {
     wrapAlgorithm   KeyEncryptionAlgorithmIdentifier,
     kdfAlgorithm    KeyDerivationAlgorithmIdentifier,
     macAlgorithm    MessageAuthenticationCodeAlgorithm }

	  

EncryptedKeyWithMACValue  ::=  SEQUENCE  {
     encryptedKey             EncryptedKey,
     macValue                 MessageAuthenticationCode }

	  

In the KeyTransRecipientInfo, KeyAgreeRecipientInfo, PasswordRecipientInfo and KEKRecipientInfo, the CPK-wrapping algorithm is identified through an AlgorithmIdentifier structure [RFC5280]:

• The wrapAlgorithm value identifies the algorithm which will be used to wrap the CPK.
• The kdfAlgorithm value identifies the key-derivation function which will be used to derive the wrap-encryption key and the wrap-MAC key from the wrap-key.
• The macAlgorithm value identifies the MAC algorithm used to provide data-origin authentication.

The With-MAC algorithm CAN NOT be used in a KeyTransRecipientInfo structure, but CAN be used in a KeyAgreeRecipientInfo, KEKRecipientInfo or PasswordRecipientInfo structure. When the With-MAC key-wrap algorithm is provided as the key-wrap algorithm in one of these three structures, the encryptedKey field of that structure MUST hold the DER encoding of a EncryptedKeyWithMACValue value:

• The encryptedKey field holds the wrapped CPK, and
• The macValue holds a MAC value computed over the 'ciphertext' of the enclosing EnvelopedData, AuthenticatedData, or AuthEnvelopedData. That is, this document follows the 'encrypt then MAC' paradigm, in which the plaintext is encrypted and the ciphertext MACed.

These fields are discussed in more detail in the next sections.

4. Actions of the sender

AuthenticatedDataAuthenticatedContents  ::=  SEQUENCE  {
     encapContentInfo        EncapsulatedContentInfo, 
     authAttrs               AuthAttributes OPTIONAL }

		  

AuthEnvelopedDataAuthenticatedContents  ::=  SEQUENCE  {
     authEncryptedContentInfo        EncapsulatedContentInfo, 
     authAttrs                       AuthAttributes OPTIONAL }

		  

The specific actions of the sender depend on whether it is being used as the key-wrap algorithm of a KeyAgreeRecipientInfo, PasswordRecipientInfo or KEKRecipientInfo structure, and whether that structure is in an EnvelopedData, AuthenticatedData or AuthEnvelopedData structure. In all cases, the sender chooses a key-encryption algorithm, a key-derivation algorithm, and a MAC algorithm. It then encodes these choices and their associated parameters in a WithMACParameters structure. If the kdfAlgorithm parameters includes a 'key length' field of any type (e.g. PBKDF2 [RFC3370]) then this MUST be set to zero. The sender then creates an AlgorithmIdentifier structure composed of the id-alg-WithMACWrap value in the algorithm field and that WithMACParameters structure in the parameters field.

The sender then places this AlgorithmIdentifier in the keyEncryptionAlgorithm of the key-wrap structure being constructed (KeyAgreeRecipientInfo, KEKRecipientInfo, or PasswordRecipientInfo). Then, the sender performs the following actions once per EncryptedKey value in the key-wrap structure. This will be exactly once, in the case of KEKRecipientInfo and PasswordRecipientInfo, and once per RecipientEncryptedKey in the case of KeyAgreeRecipientInfo.

• First, the sender generates the CPK and uses it to protect the payload of the EnvelopedData, AuthenticatedData or AuthEnvelopedData structure as described in [RFC5652].
• Then, the sender generates the wrap-key according to the standard CMS process for this key-wrap type:
  • In the case of PasswordRecipientInfo, the wrap key is generated by applying a key-derivation function (identified in the keyDerivationAlgorithm field of the PasswordRecipientInfo structure) to the password.
  • In the case of KEKRecipientInfo, the wrap key is the key identified by the kekid field of that structure.
  • And in the case of KeyAgreeRecipientInfo, the wrap key is generated by applying the relevant key-agreement algorithm to the public value or the sender (identified in the originator field of the KeyAgreeRecipientInfo structure), the public value of the receiver (identified in the rid field of the RecipientEncryptedKey structure being built) and the fresh per-message randomness (in the ukm field if the KeyAgreeRecipientInfo structure) if present.

• The sender then derives the wrap-encryption key from the wrap-key by applying the KDF identified in the kdfAlgorithm field of the WithMACParameters structure. Typically, key-derivation functions are used to transform a password into a key, and some take an additional 'context' or 'info' input [HKDF] [RFC5869]:
  • If the KDF takes a 'context' or 'info' parameter, then the 'password' input to the KDF is the wrap key and the 'context'/'info' parameter will be the value of the wrapAlgorithm field of the WithMACParameters structure. That is, the type and length bytes are omitted.
  • If the KDF does not take a 'context' or 'info' parameter, then the 'password' input to the KDF is the concatenation of the wrap-key and the value of the wrapAlgorithm field of the WithMACParameters structure. That is, the type and length bytes are omitted.

  In both cases, the length of the key to be generated is that required by the algorithm identified in the wrapAlgorithm field of the WithMACParameters structure.

• The sender then uses the wrap-encryption key to wrap the CPK, which depends on the top-level structure being built:
  • In the case of EnvelopedData, the CPK is the content-encryption key.
  • In the case of AuthenticatedData, the CPK is the authentication key.
  • In the case of AuthEnvelopedData, the CPK is the content-authenticated-encryption key.

  In all cases, the CPK is wrapped according to the algorithm and parameters identified in the wrapAlgorithm field of the WithMACParameters structure created above. This process results in an EncryptedKey value, which we will call the 'inner EncryptedKey'.

• The sender then derives the wrap-MAC key from the wrap-key by applying the KDF identified in the kdfAlgorithm field of the WithMACParameters structure:
  • If this KDF takes a 'context' or 'info' parameter, then the 'password' input to the KDF is the wrap key and the 'context'/'info' parameter will be the value of the macAlgorithm field of the WithMACParameters structure. That is, the type and length bytes are omitted.
  • If the KDF does not take a 'context' or 'info' parameter, then the 'password' input to the KDF is the concatenation of the wrap-key and the value of the macAlgorithm field of the WithMACParameters structure. That is, the type and length bytes are omitted.

  In both cases, the length of the key to be generated is that required by the algorithm identified in the macAlgorithm field of the WithMACParameters structure.

• The sender then computes a MAC value by applying the MAC algorithm identified in the macAlgorithm field of the WithMACParameters structure to the wrap-MAC key and the data to be protected:
  • In the case of an EnvelopedData structure, the data to be protected is the value of the structure's encryptedContentInfo field. The type and length bytes are omitted.
  • In the case of an AuthenticatedData structure, the data to be protected is the the DER encoding of the following structure:
  • In the case of an AuthEnvelopedData structure, the data to be protected is the DER encoding of the following structure:

  The MAC algorithm will output a MessageAuthenticationCode value.

• The sender then embeds the inner EncryptedKey value and this MessageAuthenticationCode value in an EncryptedKeyWithMACValue structure.
• The sender then DER-encodes this EncryptedKeyWithMACValue structure, and embeds these octets (the 'outer EncryptedKey value') in the encryptedKey field being constructed.

5. Actions of the receiver

When the receiver processes an EnvelopedData, AuthenticatedData or AuthEnvelopedData structure, and

• has selected has selected a RecipientInfo structure to process for the CPK, and
• recognizes the id-alg-WithMACWrap value in the algorithm field of the AlgorithmIdentifier value in the keyEncryptionAlgorithm field of that RecipientInfo structure,

it will perform the following steps:

• It first parses the parameters field of that AlgorithmIdentifier as a WithMACParameters structure, above. If the AlgorithmIdentifier in the kdfAlgorithm field contains a key-length parameter in the Parameters field, this MUST be set to zero.
• The receiver then generates or retrieves the wrap-key according to the standard CMS process for this key-wrap type. It then derives a wrap-encryption key and wrap-MAC key from the wrap-key as described in Section 4, using the algorithm identified in the kdfAlgorithm field of the WithMACParameters structure.
• It then parses the encryptedKey field of that RecipientInfo structure (or the relevant RecipientEncryptedKey structure, in the case of a KeyAgreeRecipientInfo) as the DER encoding of a EncryptedKeyWithMACValue. In this way, it recovers the 'inner' EncryptedKey value and a MessageAuthenticationCode value.
• It then decrypts the inner EncryptedKey value with the wrap-encryption key, according to the algorithm identified in the wrapAlgorithm field of the WithMACParameters structure, In doing so, it recovers the wrapped key--be it content-encryption key, authentication key, or content-authenticated-encryption key.
• At this point, the receiver MUST both:
  • Use the wrapped key to process the encryptedContentInfo, encapContentInfo, or authEncryptedContentInfo as specified in [RFC5652], [RFC5652] and [RFC5083] respectively, and
  • Use the wrap-MAC key and the MAC algorithm specified in the macAlgorithm field of the WithMACParameters structure to verify the integrity of the protected data (defined in Section 4).

  The receiver SHOULD reject the entire top-level structure (EnvelopedData, AuthenticatedData, or AuthEnvelopedData) if the MAC value fails to verify.

6. Requirements and Recommendations

This document does not define the actions of sender or receiver when the top-level structure is EncryptedData or DigestedData. Therefore, this algorithm MUST NOT be used in EncryptedData or DigestedData structures. Similarly, this document does not define the actions of sender or receiver when the key-wrap mechanism is key-transport. Therefore, the With-MAC algorithm MUST NOT be used when the key-wrap structure is KeyTransRecipientInfo. This algorithm MAY but SHOULD NOT be used when the key-wrap method is based on key-agreement and the sender uses an ephemeral value, as the algorithm provides no data-origin guarantees in this case. (See Section 7.) However, receivers that support the use of this algorithm when the sender uses a static key-agreement key MUST also gracefully accept this use of this algorithm when the sender uses an ephemeral value. Such receivers MUST also reject the entire top-level structure when the MAC fails to verify, as in Section 5, even when the sender uses an ephemeral value.

It is RECOMMENDED that implementations of this specification support EnvelopedData, AuthenticatedData and AuthEnvelopedData.

Implementations that support this specification MUST support the following key-wrap algorithms: id-aes128-wrap, id-aes192-wrap, id-aes256-wrap [RFC3394].

Implementations that support this specification MUST support the following key-derivation function algorithm: id-PBKDF2 [RFC3370]. Furthermore, implementations that support this specification MUST support the use of the MAC algorithms of the next paragraph for use as the prf or this KDF [SP800-132].

Implementations that support this specification MUST support the following MAC algorithms: id-hmacWithSHA224, id-hmacWithSHA256, id-hmacWithSHA384, id-hmacWithSHA512, all with parameters present but set to type NULL [RFC4231].

7. Security considerations

The goal of this document is to add data-origin authentication to EnvelopedData, AuthenticatedData, and AuthEnvelopedData structures without weakening the existing security properties of those structures. To that end, it is essential that the key-derivation function used to derive the wrap-encryption and wrap-MAC key from the wrap key be sufficiently strong. Such algorithms are designed to take two inputs: some secret, weak randomness and some public, strong randomness, and are designed to output strong, secret randomness. In this application, the strong, public randomness is a salt value included in the AlgorithmIdentifier structure in the kdfAlgorithm field. However, this salt will be used twice: either to derive two keys from two related 'passwords' (the wrap-key concatenated with either the wrapAlgorithm value or the macAlgorithm value) or the same password (the wrap-key) in two different contexts (the wrapAlgorithm value or the macAlgorithm value). The security of this algorithm requires that the KDF ensure two resulting key (the wrap-encryption and wrap-MAC keys) are cryptographically independent. See [HKDF] for details. It is not yet known whether the PBKDF2 function satisfies this property, but there is no evidence to the contrary either. However, the HKDF scheme [RFC5869] provably achieves this property, and should be added to Section 6 as a required and default algorithm when it receives an object identifier.

In keeping with [RFC6476], this specification uses the 'encrypt then MAC' approach to combining encryption and integrity, rather than the 'MAC then encrypt' approach. For a discussion of this issue, see [EncryptThenAuth].

This algorithm provides no data-origin guarantees when there is no binding between the wrap-key and the data-origin. Therefore, this document does not define the usage of this algorithm when the key-wrap mechanism is key-transport. Similarly, this algorithm will provide no data-origin guarantees when the key-wrap mechanisms is key-agreement and the data-origin uses an ephemeral key-agreement key value. Although such usage is valid under this specification, there is no advantage to using this algorithm rather than the algorithm identified in the wrapAlgorithm field of the WithMACParameters structure.

8. IANA Considerations

This document makes use of object identifiers. These object identifiers have been registered in an arc delegated to the IETF S/MIME Working Group. This arc and its registration procedures will be transferred to IANA soon. No further action by IANA is necessary for this document or any anticipated updates.

9. Acknowledgements

The authors would like thank Jim Schaad for informing them of the attack described in Section 1. We would also like to thank Russ Housely and Sean Turner for their valuable comments.

10. References

10.1. Normative References

10.2. Informative References

Appendix A. ASN.1 Module

WithMACKeyEncryption
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
    smime(16) modules(0) XX } 

DEFINITIONS IMPLICIT TAGS ::= 

BEGIN 

-- EXPORTS ALL  

IMPORTS 

   KeyEncryptionAlgorithmIdentifier,
   KeyDerivationAlgorithmIdentifier,
   MessageAuthenticationCodeAlgorithm,
   EncryptedKey,
   MessageAuthenticationCode,
   AuthAttributes,
   EncapsulatedContentInfo,
   EncryptedContentInfo
     FROM CryptographicMessageSyntax2004
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
         smime(16) modules(0) cms-2004(24)}
   ;

id-alg-WithMACWrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) X }

WithMACParameters  ::=  SEQUENCE  {
     wrapAlgorithm               KeyEncryptionAlgorithmIdentifier,
     kdfAlgorithm                KeyDerivationAlgorithmIdentifier,
     macAlgorithm                MessageAuthenticationCodeAlgorithm }

EncryptedKeyWithMACValue  ::=  SEQUENCE  {
     encryptedKey             EncryptedKey,
     macValue                 MessageAuthenticationCode }


AuthenticatedDataAuthenticatedContents  ::=  SEQUENCE  {
     encapContentInfo        EncapsulatedContentInfo, 
     authAttrs               AuthAttributes OPTIONAL }

AuthEnvelopedDataAuthenticatedContents  ::=  SEQUENCE  {
     authEncryptedContentInfo        EncryptedContentInfo, 
     authAttrs                       AuthAttributes OPTIONAL }

END 
	  

This appendix provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [X.680] through [X.683].

Authors' Addresses