Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
updates
- rfc-3852 — Cryptographic Message Syntax (CMS)
Extracted elements (20)
Version numbers are included in AuthEnvelopedData to avoid ASN.1 decode errors. The lowest version number supporting the generated syntax is used to maximize interoperability; higher versions are only used when new syntax features are actually employed.
When constructing the AAD from authenticated attributes, the IMPLICIT [1] tag is not used; instead a universal SET OF tag is used for DER encoding. This ensures a consistent encoding of authenticated attributes as AAD input regardless of context tagging.
This document updates RFC 3852 (CMS) by adding the authenticated-enveloped-data content type. All key management techniques supported by CMS enveloped-data are equally supported by authenticated-enveloped-data, enabling drop-in use of the new content type with existing recipient infrastructure.
AuthAttributes MUST be DER encoded, even if the rest of the AuthEnvelopedData structure is BER encoded.
If AAD padding is required by the authenticated encryption algorithm, the padding MUST be added as described in Section 6.3 of CMS, and is well defined only if the block size is less than 256 octets.
If integrity verification fails, the receiver MUST destroy all of the plaintext of the content.
If the authenticated encryption algorithm requires content padding, 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.
The authAttrs field MUST be present if the content type carried in EncryptedContentInfo is not id-data.
The message-digest attribute SHOULD NOT be included in authAttrs, because its presence discloses the unencrypted hash of the plaintext, enabling content tracking.
The recipient MUST verify the integrity of the received content before releasing any information, especially the plaintext of the content.
The version field of AuthEnvelopedData MUST be set to 0.
There MUST be at least one element in the recipientInfos collection.
Four key management techniques are supported for encrypting the content-authenticated-encryption key: Key Transport (encrypted in recipient's public key), Key Agreement (pairwise symmetric KEK from sender/recipient key pair), Symmetric Key-Encryption Keys (pre-distributed symmetric KEK), and Passwords (KEK derived from password/shared secret).
The authenticated encryption process takes the content (padded if necessary), DER-encoded authenticated attributes (AAD, padded if necessary), and the content-authenticated-encryption key as inputs; it produces ciphertext stored in authEncryptedContentInfo.encryptedContent and an authentication tag stored in the mac field.
The AuthEnvelopedData content type is identified by OID id-ct-authEnvelopedData (1.2.840.113549.1.9.16.1.23) and provides authenticated encryption for arbitrary content along with encrypted content-authenticated-encryption keys for one or more recipients.
Counter mode encryption is easy to misuse: if counter block values are ever reused with the same key, the same keystream encrypts both plaintexts and confidentiality is voided. The CMS authenticated-enveloped-data type mitigates this by generating a fresh content-encryption key per content and using unpredictable nonce values in the counter block.
Implementations must randomly generate content-authenticated-encryption keys, padding, and unpredictable nonce values. Inadequate PRNGs can result in little or no security; RFC 4086 offers guidance on quality random number generation.
Including the message-digest attribute in AuthAttributes discloses the unencrypted hash of the plaintext, enabling content tracking and allowing an attacker to check if the plaintext matches candidate contents. It SHOULD NOT be included for this reason.
Recipients accepting unsolicited CMS-encrypted messages become more vulnerable to spam and phishing because plaintext-analysis mitigation strategies cannot access the content. Software should provide mechanisms such as whitelisting to handle unwanted encrypted traffic.
AuthEnvelopedData is an ASN.1 SEQUENCE containing: version (CMSVersion), optional originatorInfo [0], recipientInfos (RecipientInfos), authEncryptedContentInfo (EncryptedContentInfo), optional authAttrs [1], mac (MessageAuthenticationCode), and optional unauthAttrs [2].