Cryptographic Message Syntax (CMS)
obsoleted by
- rfc-5652 — Cryptographic Message Syntax (CMS)
obsoletes
- rfc-3369 — Cryptographic Message Syntax (CMS)
updated by
Extracted elements (30)
Each CMS content type is designed to permit single-pass processing using indefinite-length BER encoding, which is especially helpful for large or piped content. The tradeoff is that only signed attributes and authenticated attributes require the stricter DER encoding, as these must be independently re-encoded by recipients for verification.
Specific cryptographic algorithms were moved from the CMS specification into a separate document (CMSALG). This separation allows the IETF to update protocol and algorithm specifications independently; CMS itself does not require implementation of any particular algorithms, leaving the choice to protocols that use CMS.
The content-type attribute MUST NOT be included in a countersignature unsigned attribute. This prevents type confusion where a countersignature's signed context could be misinterpreted as applying to a different content type than the original signature.
Version numbers are included as the first field in each major data structure to avoid ASN.1 decode errors. The lowest version number supporting the generated syntax is always used to maximize interoperability; higher version numbers are reserved for when new syntax features are actually employed.
CMS and PKCS #7 SignedData types are incompatible when the encapsulated content is not the Data type. CMS eContent is an OCTET STRING, while PKCS #7 uses ANY DEFINED BY contentType; for non-Data content (e.g., an RFC 2634 signed receipt), this causes different message digest inputs and produces incompatible signatures.
An implementation conforming to this specification MUST implement the ContentInfo protection content and MUST implement the data, signed-data, and enveloped-data content types. The digested-data, encrypted-data, and authenticated-data content types MAY be implemented.
AuthAttributes MUST be DER encoded even if the rest of AuthenticatedData is BER encoded. When authAttrs is present, it MUST contain at minimum a content-type attribute and a message-digest attribute, and the digestAlgorithm field MUST also be present; authAttrs MUST be present if the eContentType is not id-data.
Implementations MUST support key transport (ktri), key agreement (kari), and previously distributed symmetric key-encryption keys (kekri). Password-based (pwri) and other (ori) alternatives MAY be supported. All implementations MUST gracefully handle unimplemented RecipientInfo alternatives and versions.
SignedAttributes MUST be DER encoded even if the rest of the SignedData structure is BER encoded. When signedAttrs is present, it MUST contain at minimum a content-type attribute and a message-digest attribute; signedAttrs MUST be present if the eContentType is not id-data.
The recipient MUST NOT rely on any MAC values or message digest values computed by the originator. The recipient must independently compute the MAC and verify it equals the mac field; when authAttrs is present, the content message digest must also be independently recomputed and verified.
The recipient MUST NOT rely on any message digest values computed by the originator. The recipient must independently calculate the message digest and verify it matches the messageDigest attribute in signedAttributes; the content-type attribute value must also match the encapContentInfo eContentType.
The subjectKeyIdentifier form of SignerIdentifier MUST be used to refer to a public key contained in a non-X.509 certificate. For key transport, a recipient X.509 v3 certificate with a key usage extension MUST assert the keyEncipherment bit; for key agreement it MUST assert the keyAgreement bit.
When computing the message digest over signedAttrs, the EXPLICIT SET OF tag must be used rather than the IMPLICIT [0] tag. The DER encoding of the SET OF tag, along with the length and content octets of the SignedAttributes value, are all included in the digest computation.
AuthenticatedData provides integrity protection via MAC rather than digital signature. It contains version, optional originatorInfo, recipientInfos, macAlgorithm, optional digestAlgorithm, encapContentInfo, optional authAttrs (DER encoded AuthAttributes SET), mac OCTET STRING, and optional unauthAttrs.
CertificateChoices is a CHOICE among X.509 Certificate, obsolete ExtendedCertificate, deprecated v1AttrCert, v2AttrCert (X.509-2000), and OtherCertificateFormat (OID plus ANY value). The OtherCertificateFormat extension point allows CMS to carry non-X.509 certificate formats without further specification changes.
ContentInfo is the top-level CMS wrapper, an ASN.1 SEQUENCE containing a contentType OID and an associated content field. It encapsulates one of six defined content types: data, signed-data, enveloped-data, digested-data, encrypted-data, or authenticated-data.
EncapsulatedContentInfo contains an eContentType OID and an optional eContent OCTET STRING. Omitting eContent enables 'external signatures' where the signed content is not transmitted within the SignedData structure; the signatureValue is still calculated as though eContent were present.
EnvelopedData is an ASN.1 SEQUENCE containing version, optional originatorInfo, recipientInfos SET (at least one element required), encryptedContentInfo, and optional unprotectedAttrs. It supports four key management techniques: key transport, key agreement, previously distributed symmetric KEK, and password-based.
KEKRecipientInfo carries the content-encryption key encrypted under a previously distributed symmetric key-encryption key. It contains version (always 4), kekid (KEKIdentifier with keyIdentifier OCTET STRING and optional date/other), keyEncryptionAlgorithm, and encryptedKey.
KeyAgreeRecipientInfo uses a sender-recipient pairwise key to encrypt the content-encryption key. It contains version (always 3), originator (OriginatorIdentifierOrKey — three alternatives including an anonymous originatorKey), optional ukm (UserKeyingMaterial OCTET STRING), keyEncryptionAlgorithm, and recipientEncryptedKeys.
KeyTransRecipientInfo transfers the content-encryption key encrypted in the recipient's public key. It contains version (0 or 2), RecipientIdentifier (issuerAndSerialNumber or subjectKeyIdentifier CHOICE), keyEncryptionAlgorithm, and encryptedKey OCTET STRING.
PasswordRecipientInfo (specified in RFC 3211) carries the content-encryption key encrypted under a key derived from a password. It contains version (always 0), optional keyDerivationAlgorithm, keyEncryptionAlgorithm, and encryptedKey OCTET STRING.
RecipientInfo is a CHOICE among ktri (KeyTransRecipientInfo), kari (KeyAgreeRecipientInfo), kekri (KEKRecipientInfo), pwri (PasswordRecipientInfo), and ori (OtherRecipientInfo). Each encodes the encrypted content-encryption key for a different key management scheme.
RevocationInfoChoices is a SET OF RevocationInfoChoice, which is a CHOICE between a CertificateList (CRL) and OtherRevocationInfoFormat (OID plus ANY value). This extension mechanism allows OCSP responses and other revocation formats to be carried in CMS structures without modifying the CMS specification.
SignedData is an ASN.1 SEQUENCE containing a version, digestAlgorithms SET, encapContentInfo, optional certificates (CertificateSet), optional crls (RevocationInfoChoices), and signerInfos SET. It supports zero or more parallel signers over content of any type.
SignerInfo is an ASN.1 SEQUENCE containing version, SignerIdentifier (issuerAndSerialNumber or subjectKeyIdentifier CHOICE), digestAlgorithm, optional signedAttrs, signatureAlgorithm, signature OCTET STRING, and optional unsignedAttrs. It captures all per-signer information for a single digital signature.
Both signature verification (Section 5.6) and MAC verification (Section 9.3) require the recipient to independently recompute digest and authentication values without trusting originator-supplied values. This protects against an attacker who supplies a crafted digest value to bypass integrity checks.
Block cipher padding appends k-(lth mod k) octets each having the value k-(lth mod k) to the plaintext, where k is the block size and lth is the input length. Input already a multiple of k receives a full block of padding (value k repeated k times). This scheme is only well-defined when k < 256.
The EnvelopedData version is assigned as follows: version 4 if originatorInfo is present with other-typed certs or CRLs; version 3 if v2 attribute certificates, pwri, or ori RecipientInfo structures are present; version 0 if originatorInfo and unprotectedAttrs are absent and all RecipientInfos are version 0; otherwise version 2.
The SignedData version field is assigned deterministically: version 5 if other-typed certificates or CRLs are present; version 4 if v2 attribute certificates are present; version 3 if v1 attribute certificates, v3 SignerInfo structures, or a non-id-data eContentType are present; otherwise version 1.