Cryptographic Message Syntax (CMS)
obsoletes
- rfc-3852 — Cryptographic Message Syntax (CMS)
updated by
- rfc-8933 — Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection
- rfc-9629 — Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)
also
- std-70
Extracted elements (26)
CMS structures permit single-pass processing using BER indefinite-length encoding, which is critical for large or streamed content. DER is required only for signed attributes and authenticated attributes because recipients must be able to verify signatures even when unrecognized attributes are present, requiring deterministic encoding.
Version numbers are placed first in each major data structure to avoid ASN.1 decode errors; some implementations check the version only as part of error handling after a failed decode, which is acceptable. The lowest version number that supports the generated syntax MUST be used to maximize interoperability with older implementations.
CMS defines eContent as OCTET STRING while PKCS #7 defines it as ANY. For non-Data content types (e.g., RFC 2634 signed receipts), the message digest is computed differently: CMS digests the entire OCTET STRING value, while PKCS #7 digests only the value octets of the DER-encoded inner type, making the two formats incompatible for non-Data content.
A recipient X.509 v3 certificate used in KeyTransRecipientInfo MUST assert the keyEncipherment bit in its key usage extension; a certificate used in KeyAgreeRecipientInfo MUST assert the keyAgreement bit.
All implementations MUST gracefully handle unimplemented versions of SignerInfo and MUST gracefully handle unimplemented signature algorithms when they are encountered in a SignedData structure.
An implementation conforming to this specification MUST implement ContentInfo and MUST implement the data, signed-data, and enveloped-data content types. The other content types (digested-data, encrypted-data, authenticated-data) MAY be implemented.
For message digest calculation when signedAttrs is present, the IMPLICIT [0] tag is NOT used; instead an EXPLICIT SET OF tag MUST be applied. The DER encoding of the SET OF tag, length, and SignedAttributes value octets are included in the digest input.
Implementations MUST support key transport (ktri), key agreement (kari), and previously distributed symmetric key-encryption keys (kekri). All implementations MUST gracefully handle unimplemented RecipientInfo alternatives, unimplemented versions, and unknown ori alternatives.
subjectKeyIdentifier MUST be used in SignerIdentifier (or RecipientIdentifier) when referring to a public key contained in a non-X.509 certificate.
The AuthAttributes structure MUST be DER encoded. If authAttrs is present it MUST contain at minimum a content-type attribute and a message-digest attribute; authAttrs MUST be present when the EncapsulatedContentInfo content type is not id-data, and if present, digestAlgorithm MUST also be present.
The EnvelopedData version MUST be 4 if 'other' certificate/CRL types appear in originatorInfo; version 3 if ACv2 certificates, pwri, or ori are present; version 0 if originatorInfo absent, unprotectedAttrs absent, and all RecipientInfos are version 0; otherwise version 2.
The recipient MUST NOT rely on any MAC values or message digest values computed by the originator. The recipient independently computes the MAC and digest; both must equal the received values for authentication to succeed.
The recipient MUST NOT rely on any message digest values computed by the originator. If signedAttributes are present, the content message digest MUST be independently recalculated by the recipient and MUST match the messageDigest attribute for the signature to be valid.
The SignedData version MUST be 5 if 'other' certificate/CRL types are present; 4 if ACv2 attribute certificates are present; 3 if ACv1 certificates, version-3 SignerInfos, or a non-id-data eContentType are present; otherwise version MUST be 1.
When signedAttrs is present it MUST be DER encoded even if the rest of the structure is BER, and MUST contain at minimum a content-type attribute and a message-digest attribute. The signedAttrs field MUST be present whenever the encapsulated content type is not id-data.
ContentInfo is the top-level CMS encapsulation structure, containing a contentType OID and the associated content. The syntax MUST have ASN.1 type ContentInfo: a SEQUENCE of contentType (ContentType OID) and content ([0] EXPLICIT ANY).
EncapsulatedContentInfo contains an eContentType OID and an optional eContent OCTET STRING. Omitting eContent creates an 'external signature': the signature is computed as though eContent were present, but the content is conveyed separately.
KeyAgreeRecipientInfo (version always 3) specifies the originator key via issuerAndSerialNumber, subjectKeyIdentifier, or raw originatorKey; includes optional User Keying Material (UKM) to ensure key uniqueness per session; and carries per-recipient encrypted content-encryption keys.
PasswordRecipientInfo (version always 0) transfers a content-encryption key encrypted under a key-encryption key derived from a password or shared secret via an optional keyDerivationAlgorithm. If the derivation algorithm field is absent, the key-encryption key is supplied from an external source such as a hardware token.
RecipientInfo is a CHOICE of five key management variants: ktri (KeyTransRecipientInfo), kari ([1] KeyAgreeRecipientInfo), kekri ([2] KEKRecipientInfo), pwri ([3] PasswordRecipientInfo), and ori ([4] OtherRecipientInfo). Any technique may be used per recipient of the same encrypted content.
The most critical security invariant in CMS is that recipients must never trust cryptographic values supplied by the originator. Digest and MAC values MUST be independently recomputed by the recipient and compared; failure to do so allows an attacker to substitute arbitrary content while presenting a valid-looking structure.
AuthenticatedData is a SEQUENCE containing version, optional originatorInfo, recipientInfos, macAlgorithm, optional digestAlgorithm ([1]), encapContentInfo, optional authAttrs ([2] IMPLICIT AuthAttributes), mac (MessageAuthenticationCode OCTET STRING), and optional unauthAttrs ([3] IMPLICIT).
Content encryption uses PKCS#5-style block padding: trailing octets of value k-(lth mod k) are appended to make the plaintext length a multiple of block size k. All input is padded (even input already a multiple of k receives k padding bytes). Valid only when k < 256.
EnvelopedData is a SEQUENCE with version, optional originatorInfo ([0] IMPLICIT), recipientInfos (SET SIZE(1..MAX) OF RecipientInfo), encryptedContentInfo (EncryptedContentInfo SEQUENCE with contentType, contentEncryptionAlgorithm, optional encryptedContent OCTET STRING), and optional unprotectedAttrs ([1] IMPLICIT).
SignedData is encoded as a SEQUENCE containing version (CMSVersion), digestAlgorithms (SET OF DigestAlgorithmIdentifier), encapContentInfo, optional certificates ([0] IMPLICIT CertificateSet), optional crls ([1] IMPLICIT RevocationInfoChoices), and signerInfos (SET OF SignerInfo). Supports zero or more parallel signers.
SignerInfo is a SEQUENCE of version, sid (SignerIdentifier CHOICE: issuerAndSerialNumber or subjectKeyIdentifier [0]), digestAlgorithm, optional signedAttrs ([0] IMPLICIT SignedAttributes), signatureAlgorithm, signature (OCTET STRING), and optional unsignedAttrs ([1] IMPLICIT UnsignedAttributes).