RFC 5083

RFC 5083: Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type 🎀

Okay bestie, let's get into this one. It's RFC 5083, written by R. Housley of Vigil Security and published in November 2007. It's a Standards Track doc, which means it's a real protocol spec and not just a vibe. It updates RFC 3852 (that's the CMS spec) and doesn't obsolete anything. The title is Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type 💜

Status of This Memo ✨

This doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the official standardization state and status, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸

Abstract 🦋

This doc adds a new content type to the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is made for authenticated encryption modes. The cool part is that every key management technique CMS's enveloped-data content type supports also works here 🔥

1. Introduction ✨

Okay so this doc adds another content type to CMS [CMS]. Authenticated-enveloped-data is built for authenticated encryption modes, where the content gets both authenticated and encrypted. Some associated data, in the form of authenticated attributes, can also be authenticated. And just like enveloped-data, every key management technique is supported too. Iconic 💅

The conventions for using AES-CCM (AES-Counter with Cipher Block Chaining-Message Authentication Code) and AES-GCM (AES-Galois/Counter Mode) with this content type are in [AESALGS]. So if you're into those algorithms, go there 🧚

Like all the other CMS content types, this one uses ASN.1 [X.208-88]. It uses both the Basic Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules (DER) [X.509-88] 🌈

1.1. Terminology 📖

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are interpreted as described in [STDWORDS]. Those are the only places those capitalized words show up, so they're the official rules-of-the-road 🫶

1.2. Version Numbers 🔢

The main data structure, AuthEnvelopedData, has a version number as its first item. The point of that number is to avoid ASN.1 decode errors. Some implementations don't check the version before trying to decode. If a decode error happens, they check the version as part of their error handling. Honestly, that's a smart move, since it keeps the error stuff out of the fast path. It's also forgiving if the sender uses the wrong version number 💖

Whenever the structure gets updated, a higher version number gets assigned. For maximum interoperability, though, the higher number is only used when a new syntax feature is actually in play. So the lowest version number that supports the generated syntax is the one that gets used. Efficient and considerate, bestie 🍓

2. Authenticated-Enveloped-Data Content Type 💜

So the authenticated-enveloped-data content type holds content of any type that's been both authenticated and encrypted, plus the encrypted content-authenticated-encryption keys for one or more recipients. The combo of the authenticated, encrypted content and one encrypted content-authenticated-encryption key for a recipient is called a "digital envelope" for that recipient. Any type of content can be enveloped for any number of recipients, using whichever supported key management technique fits each one. Authenticated-but-not-encrypted attributes may also be provided by the originator ✨

The typical use case is one or more recipients' digital envelopes wrapped around an encapsulated content. Main character energy 👑

Authenticated-enveloped-data gets built in these steps:

1. A content-authenticated-encryption key for a particular content-authenticated-encryption algorithm is generated at random.
2. The content-authenticated-encryption key is encrypted for each recipient. The details depend on the key management algorithm, but there are four general techniques:
   • Key Transport: the content-authenticated-encryption key is encrypted in the recipient's public key.
   • Key Agreement: the recipient's public key and the sender's private key make a pairwise symmetric key-encryption key. Then the content-authenticated-encryption key is encrypted in that pairwise symmetric key-encryption key.
   • Symmetric Key-Encryption Keys: the content-authenticated-encryption key is encrypted in a symmetric key-encryption key that was distributed earlier.
   • Passwords: the content-authenticated-encryption key is encrypted in a key-encryption key derived from a password or some other shared secret value.
3. For each recipient, the encrypted content-authenticated-encryption key and any other recipient-specific info get bundled into a RecipientInfo value, defined in Section 6.2 of [CMS].
4. Any attributes that are supposed to be authenticated but not encrypted get collected into the authenticated attributes.
5. The attributes from step 4 are authenticated, and the CMS content is authenticated and encrypted with the content-authenticated-encryption key. If the authenticated encryption algorithm needs either the additional authenticated data (AAD) or the content padded to a multiple of some block size, then the padding gets added as described in Section 6.3 of [CMS].
6. Any attributes that are provided without authentication or encryption get collected into the unauthenticated attributes.
7. The RecipientInfo values for all the recipients, the authenticated attributes, the unauthenticated attributes, and the authenticated and encrypted content all get collected together into an AuthEnvelopedData value, as defined in Section 2.1 💅

To open the digital envelope, a recipient decrypts one of the encrypted content-authenticated-encryption keys. Then they use the recovered key to decrypt the authenticated and encrypted content, verify its integrity, and verify the integrity of the authenticated attributes 🔐

Here's the big rule: the recipient MUST verify the integrity of the received content before releasing any information, especially the plaintext of the content. And if the integrity check fails, the receiver MUST destroy all of the plaintext of the content. No exceptions, no peeking 💀

Real talk: never show the plaintext before the integrity check passes. If verification fails, the plaintext gets destroyed. That's the whole vibe.

This section has three parts. The first describes the AuthEnvelopedData content type, the second covers the authentication and encryption process, and the third covers the key encryption process ✨

2.1. AuthEnvelopedData Type 🎀

The following object identifier names the authenticated-enveloped-data content type:

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

The authenticated-enveloped-data content type MUST have ASN.1 type AuthEnvelopedData:

   AuthEnvelopedData ::= SEQUENCE {
     version CMSVersion,
     originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
     recipientInfos RecipientInfos,
     authEncryptedContentInfo EncryptedContentInfo,
     authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
     mac MessageAuthenticationCode,
     unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }

Here's what each field means, bestie 🧚

• version is the syntax version number. It MUST be set to 0.
• originatorInfo optionally gives info about the originator. It's only there if the key management algorithm requires it. It may hold certificates and Certificate Revocation Lists (CRLs). The OriginatorInfo type is defined in Section 6.1 of [CMS].
• recipientInfos is a collection of per-recipient info. There MUST be at least one element in the collection. The RecipientInfo type is defined in Section 6.2 of [CMS].
• authEncryptedContentInfo is the authenticated and encrypted content. The CMS enveloped-data content type uses the same type to carry its encrypted content. The EncryptedContentInfo type is defined in Section 6.1 of [CMS].
• authAttrs optionally holds the authenticated attributes. The CMS authenticated-data content type uses the same type to carry authenticated attributes. The authAttrs field MUST be present if the content type carried in EncryptedContentInfo is not id-data. AuthAttributes MUST be DER encoded, even if the rest of the AuthEnvelopedData structure is BER encoded. The AuthAttributes type is defined in Section 9.1 of [CMS], but for this content type the message-digest attribute SHOULD NOT be included. Useful attribute types are defined in Section 11 of [CMS] 🌸
• mac is the integrity check value (ICV) or message authentication code (MAC) generated by the authenticated encryption algorithm. The CMS authenticated-data content type uses the same type to carry a MAC. In this case the MAC covers the authenticated attributes and the content directly, and no digest algorithm is used. The MessageAuthenticationCode type is defined in Section 9.1 of [CMS] 🔐
• unauthAttrs optionally holds the unauthenticated attributes. The CMS authenticated-data content type uses the same type to carry unauthenticated attributes. The UnauthAttributes type is defined in Section 9.1 of [CMS], and useful attribute types are defined in Section 11 of [CMS] 💖

2.2. Authentication and Encryption Process ✨

okay so first things first, the content-authenticated-encryption key gets randomly generated for whichever content-authenticated-encryption algorithm you're using 🔑 no guessing allowed, bestie!

if the authenticated encryption algorithm needs the content padded to a multiple of some block size, then the padding MUST be added as described in Section 6.3 of [CMS] 🧩 this padding method is well defined if and only if the block size is less than 256 octets.

if optional authenticated attributes are present, they get DER encoded 📝 then there's a separate encoding of the authAttrs field that builds the authenticated associated data (AAD) input for the authenticated encryption algorithm. here's the tea: for the AAD, the IMPLICIT [1] tag on authAttrs is NOT used for the DER encoding. instead you use a universal SET OF tag. so the DER encoding of the SET OF tag (not the IMPLICIT [1] tag) goes into the AAD construction, along with the length and content octets of the authAttrs value 💅 if the authenticated encryption algorithm needs the AAD padded to a multiple of some block size, then the padding MUST be added as described in Section 6.3 of [CMS]. this padding method is well defined if and only if the block size is less than 256 octets.

if optional authenticated attributes are absent, then zero bits of input go in for the AAD input to the authenticated encryption algorithm 🫶

the inputs to the authenticated encryption algorithm are the content (the data, padded if needed), the DER-encoded authenticated attributes (the AAD, padded if needed), and the content-authenticated-encryption key 🔥 the operation takes an arbitrary string of octets (the data) and maps it to another string of octets (the ciphertext), and it also computes an authentication tag over the AAD and the data. the encrypted data goes into authEncryptedContentInfo encryptedContent as an OCTET STRING, and the authentication tag goes into mac in the AuthEnvelopedData.

2.3. Key Encryption Process 🔐

the input to the key encryption process (the value you hand to the recipient's key-encryption algorithm) is just the "value" of the content-authenticated-encryption key. simple and iconic 💖

any of the key management techniques we've talked about can be used for each recipient of the same encrypted content 🌸

3. Security Considerations 🔒

okay bestie, this part is SERIOUS, so pay attention 🙈 this specification defines an additional CMS content type, and the security considerations in [CMS] apply to this content type too.

a lot of authenticated encryption algorithms use a block cipher in counter mode to do the encryption. when it's used properly, counter mode gives you strong confidentiality 💜 Bellare, Desai, Jokipii, and Rogaway show in [BDJR] that the privacy guarantees counter mode gives are at least as strong as the ones for Cipher Block Chaining (CBC) mode when you use the same block cipher. iconic.

but ngl, counter mode is super easy to misuse 💀 if counter block values get used for more than one encryption operation with the same key, the same key stream encrypts both plaintexts, and the confidentiality guarantees are voided. not me making that mistake lol.

the good news is that the CMS authenticated-enveloped-data content type gives you all the tools you need to avoid misusing counter mode 🦋 every existing key management technique lets you generate a fresh content-encryption key for each content. plus, existing authenticated encryption algorithms that use counter mode support an unpredictable nonce value in the counter block. that unpredictable nonce (sometimes called a "salt") should be carried in an algorithm identifier parameter.

implementations must randomly generate content-authenticated-encryption keys, padding, and unpredictable nonce values. the generation of public/private key pairs also relies on random numbers 🎲 using inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. an attacker may find it way easier to reproduce the PRNG environment that made the keys, then search the resulting small set of possibilities, instead of brute forcing the whole key space 😱 generating quality random numbers is hard. RFC 4086 [RANDOM] offers important guidance in this area 📚

if the message-digest attribute is included in the AuthAttributes, the attribute value contains the unencrypted one-way hash value of the content's plaintext. disclosing this hash value enables content tracking, and it can be used to figure out whether the plaintext matches one or more candidate contents 👀 for these reasons, the AuthAttributes SHOULD NOT contain the message-digest attribute.

CMS is often used to provide encryption in messaging environments, and that's where unsolicited messages (like spam and phishing) become a big chunk of unwanted traffic 🚫 current mitigation strategies for unwanted messages analyze the message plaintext. if recipients accept unsolicited encrypted messages, they become even more vulnerable, since many current mitigation strategies won't be able to access the plaintext. so software that receives CMS-encrypted messages needs to provide one or more mechanisms to handle unwanted message traffic 🛡️ one approach that doesn't require disclosing keying material to a server is to reject or discard encrypted messages unless they purport to come from a member of a white list.

4. ASN.1 Module 🧩

here's the ASN.1 module, copied exactly so nothing gets lost in translation:

CMS-AuthEnvelopedData-2007
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
    pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData(31) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

-- EXPORTS All
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules.  Other applications may use them for
-- their own purposes.

IMPORTS

  -- Imports from RFC 3852 [CMS], Section 12.1
        AuthAttributes, CMSVersion, EncryptedContentInfo,
        MessageAuthenticationCode, OriginatorInfo, RecipientInfos,
        UnauthAttributes
           FROM CryptographicMessageSyntax2004
                { iso(1) member-body(2) us(840) rsadsi(113549)
                  pkcs(1) pkcs-9(9) smime(16) modules(0)
                  cms-2004(24) } ;


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

AuthEnvelopedData ::= SEQUENCE {
  version CMSVersion,
  originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
  recipientInfos RecipientInfos,
  authEncryptedContentInfo EncryptedContentInfo,
  authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
  mac MessageAuthenticationCode,
  unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }

END -- of CMS-AuthEnvelopedData-2007

5. References 📚

5.1. Normative References

[CMS]        Housley, R., "Cryptographic Message Syntax (CMS)", RFC
             3852, July 2004.

[STDWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

[X.208-88]   CCITT.  Recommendation X.208: Specification of Abstract
             Syntax Notation One (ASN.1).  1988.

[X.209-88]   CCITT.  Recommendation X.209: Specification of Basic
             Encoding Rules for Abstract Syntax Notation One (ASN.1).
             1988.

[X.509-88]   CCITT.  Recommendation X.509: The Directory-
             Authentication Framework.  1988.

5.2. Informative References

[AESALGS]    Housley, R., "Using AES-CCM and AES-GCM Authenticated
             Encryption in the Cryptographic Message Syntax (CMS)",
             RFC 5084, November 2007.

[BDJR]       Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, "A
             Concrete Security Treatment of Symmetric Encryption:
             Analysis of the DES Modes of Operation", Proceedings
             38th Annual Symposium on Foundations of Computer
             Science, 1997.

[RANDOM]     Eastlake, D., 3rd, Schiller, J., and S. Crocker,
             "Randomness Requirements for Security", BCP 106, RFC
             4086, June 2005.

Author's Address 🎀

Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: housley@vigilsec.com

Full Copyright Statement ⭐

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🌈

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.