Cryptographic Message Syntax
obsoleted by
Extracted elements (30)
CMS uses indefinite-length BER throughout (except for signed and authenticated attributes) to enable single-pass processing, which is essential when content is large, streamed, or piped. DER is required only where recipients must re-encode to verify, making a single-pass DER encode infeasible for the whole structure.
The originatorKey alternative in KeyAgreeRecipientInfo includes an uncertified ephemeral public key, permitting originator anonymity. The optional UKM field ensures a distinct pairwise key is derived even when the same two parties communicate repeatedly with the same ephemeral key.
CMS is derived from PKCS #7 v1.5 (RFC 2315) with backward compatibility preserved where possible. Breaking changes were required to support attribute certificate transfer and key agreement key management. CertificateChoices includes PKCS #6 extended certificates for backward compatibility, but their use should be avoided as PKCS #6 is obsolete.
A conforming implementation must implement ContentInfo and the data, signed-data, and enveloped-data content types. The digested-data, encrypted-data, and authenticated-data content types are optional.
Any symmetric content-encryption algorithm included in a CMS implementation must also be supported as a key-encryption algorithm. Implementations must include Triple-DES wrapping of Triple-DES content-encryption keys.
CMS implementations must include DSA (always paired with SHA-1); RSA signatures may be included. Key agreement must include X9.42 Ephemeral-Static Diffie-Hellman with Triple-DES key wrapping; RC2 key wrapping should also be included.
CMS implementations must include SHA-1; MD5 should also be included. SHA-1 AlgorithmIdentifiers must be generated with NULL parameters; implementations should also accept absent parameters.
For X9.42 ESDH, the originator field must be the originatorKey alternative carrying the sender's ephemeral public key with the dh-public-number OID, and keyEncryptionAlgorithm must be id-alg-ESDH with a mandatory KeyWrapAlgorithm parameter.
Signed attributes and authenticated attributes must be transmitted in DER form; they are the only CMS types requiring DER. All other CMS data may use indefinite-length BER to support single-pass processing.
SignedData version must be 1 when no attribute certificates are present, encapsulated type is id-data, and all SignerInfos are version 1; version must be 3 if attribute certificates are present, encapsulated type is not id-data, or any SignerInfo is version 3.
The recipient must not rely on any message digest values computed by the originator; it must independently compute the digest and verify it equals the messageDigest attribute in signedAttributes for the signature to be considered valid.
When the signedAttributes field is present in SignerInfo it must contain at minimum a content-type attribute and a message-digest attribute. The signedAttributes field must be present if the encapsulated content type is not id-data.
AuthenticatedData provides MAC-based integrity for one or more recipients; version is always 0. Its SEQUENCE includes originatorInfo, recipientInfos, macAlgorithm, optional digestAlgorithm, encapContentInfo, optional authenticatedAttributes (DER-encoded SET), mac (OCTET STRING), and optional unauthenticatedAttributes.
ContentInfo is the top-level CMS encapsulation structure, an ASN.1 SEQUENCE containing a contentType OID and an EXPLICIT ANY content field typed by the OID. All six defined content types are carried within ContentInfo.
DigestedData (version 0 for id-data content, 2 otherwise) consists of digestAlgorithm, encapContentInfo, and digest (OCTET STRING). Ordering of fields enables single-pass verification. Typically used to provide integrity before enveloping.
EncapsulatedContentInfo holds eContentType (OID) and optional eContent (OCTET STRING). When eContent is absent the structure represents an external signature where the signed content is conveyed out-of-band; signature generation proceeds as if eContent were present.
EnvelopedData is a SEQUENCE containing version, optional originatorInfo, recipientInfos (SET OF RecipientInfo, at least one required), encryptedContentInfo, and optional unprotectedAttrs. The recipientInfos field precedes encryptedContentInfo to enable single-pass decryption.
KEKRecipientInfo (version always 4) transfers the content-encryption key using a previously distributed symmetric key-encryption key identified by kekid (KEKIdentifier with keyIdentifier OCTET STRING, optional date GeneralizedTime, optional other OtherKeyAttribute).
KeyAgreeRecipientInfo (version always 3) transfers keys to one or more recipients sharing the same key agreement algorithm. Fields include originator (OriginatorIdentifierOrKey CHOICE), optional ukm (UserKeyingMaterial OCTET STRING), keyEncryptionAlgorithm, and recipientEncryptedKeys (SEQUENCE OF RecipientEncryptedKey).
KeyTransRecipientInfo transfers the content-encryption key to one recipient via their public key; fields are version (0 or 2 depending on rid CHOICE), rid (issuerAndSerialNumber or subjectKeyIdentifier), keyEncryptionAlgorithm, and encryptedKey (OCTET STRING).
RecipientInfo is a CHOICE among KeyTransRecipientInfo (ktri, no tag), KeyAgreeRecipientInfo (kari, IMPLICIT [1]), and KEKRecipientInfo (kekri, IMPLICIT [2]), allowing heterogeneous key management per recipient of the same encrypted content.
SignedData is a SEQUENCE containing version (CMSVersion), digestAlgorithms (SET OF), encapContentInfo, optional certificates and CRLs, and signerInfos (SET OF SignerInfo). It supports zero or more signers in parallel on arbitrary content.
SignerInfo is a per-signer SEQUENCE containing version, sid (CHOICE of issuerAndSerialNumber or subjectKeyIdentifier), digestAlgorithm, optional signedAttrs (SET OF Attribute), signatureAlgorithm, signature (OCTET STRING), and optional unsignedAttrs.
No requirement is imposed on the correctness of the signing time; acceptance of a purported signing time is at the recipient's discretion. Only implicitly trusted signers such as time-stamp servers should be relied upon for accurate signing time.
RSA key transport as defined in RFC 2313 (PKCS#1 block type 02) has a known chosen-ciphertext vulnerability (Bleichenbacher attack). The vulnerability is primarily relevant to interactive applications rather than store-and-forward messaging; countermeasures are discussed in the Security Considerations section.
The recipient must not rely on any MAC or message digest values computed by the originator in authenticated-data; the recipient must independently compute and compare both to verify integrity. Authentication fails if they do not match.
Block-cipher content encryption uses PKCS#5 padding: the input is padded with k-(lth mod k) octets each of value k-(lth mod k), where k is the block size. Input already a multiple of k is padded by a full block of value k. Defined only when k < 256.
SigningTime uses UTCTime (YYMMDDHHMMSSZ) for dates 1950–2049 and GeneralizedTime (YYYYMMDDHHMMSSZ) for dates outside that range. Both forms must be in GMT (Zulu), include seconds, and GeneralizedTime must not include fractional seconds.
When authenticatedAttributes are present, MAC input is the DER encoding of AuthAttributes with the IMPLICIT [2] tag replaced by an EXPLICIT SET OF tag. If authenticatedAttributes are absent, MAC input is directly the value octets of eContent OCTET STRING.
When signedAttributes are present, the message digest is computed over the DER encoding of SignedAttributes but with the IMPLICIT [0] tag replaced by an EXPLICIT SET OF tag; the tag and length octets of the eContent OCTET STRING are excluded from the digest.