Cryptographic Message Syntax (CMS)
Extracted elements (29)
Algorithm specifications were separated from the CMS protocol into a companion document [CMSALG] to allow independent updates. CMS does not mandate any specific algorithm; protocols using CMS are expected to choose appropriate algorithms for their environment.
Each CMS content type is designed to permit single-pass BER processing to handle large or streamed content. Only signed attributes and authenticated attributes require DER encoding so that recipients can verify content containing unrecognized attributes.
OtherRecipientInfo (ori) provides an OID-identified extensibility point for future key management techniques, allowing new schemes to be specified in future documents without changing the CMS structure.
The recipientInfos field in EnvelopedData is placed before encryptedContentInfo so that an EnvelopedData value may be processed in a single pass by a recipient who can identify and decrypt the content-encryption key before encountering the encrypted content.
CMS defines eContent as an OCTET STRING while PKCS #7 defines content as ANY DEFINED BY contentType. This causes incompatibility when encapsulated content is not id-data: the message digest covers different byte ranges. Implementations MAY attempt to fall back to PKCS #7 ANY decoding for backward compatibility.
A recipient X.509 v3 certificate with a key usage extension used for key transport MUST assert the keyEncipherment bit. For key agreement, the certificate MUST assert the keyAgreement bit.
All implementations MUST gracefully handle unimplemented versions of SignerInfo and unimplemented signature algorithms when encountered in a SignedData signerInfos collection.
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.
EnvelopedData version MUST be 3 if any version 2 attribute certificates are present in originatorInfo or any RecipientInfo includes pwri or ori; version 2 if originatorInfo or unprotectedAttrs is present or any RecipientInfo version is not 0; otherwise version 0.
Implementations MUST support key transport (ktri), key agreement (kari), and symmetric key-encryption key (kekri) RecipientInfo types. All implementations MUST gracefully handle unimplemented alternatives within the RecipientInfo CHOICE, including unknown ori alternatives.
In AuthenticatedData, if the digestAlgorithm field is present then the authAttrs field MUST also be present, and vice versa. authAttrs MUST be DER encoded and MUST contain at minimum content-type and message-digest attributes when present.
KeyAgreeRecipientInfo version MUST always be 3; implementations MUST support all three originator alternatives (issuerAndSerialNumber, subjectKeyIdentifier, originatorKey) and MUST support recipient processing of ukm fields even if UKMs are not otherwise used.
SignedAttributes MUST be DER encoded even if the rest of the CMS structure is BER encoded. When the signedAttrs field is present, it MUST contain at minimum a content-type attribute and a message-digest attribute.
SignerInfo version MUST be 1 when SignerIdentifier is issuerAndSerialNumber and MUST be 3 when it is subjectKeyIdentifier. Implementations MUST support reception of both SignerIdentifier forms.
Signing-time dates between 1 January 1950 and 31 December 2049 MUST be encoded as UTCTime expressed as YYMMDDHHMMSSZ in Zulu. Dates outside this range MUST use GeneralizedTime (YYYYMMDDHHMMSSZ); GeneralizedTime values MUST NOT include fractional seconds.
The content-type attribute MUST be present whenever signed attributes are present in signed-data or authenticated attributes are present in authenticated-data. It MUST be a signed or authenticated attribute and MUST NOT appear as an unsigned, unauthenticated, or unprotected attribute.
The message-digest attribute MUST be present when any signed or authenticated attributes are present. It MUST have exactly one attribute value; zero or multiple instances are not permitted within SignedAttributes or AuthAttributes.
The recipient MUST NOT rely on any MAC values or message digest values computed by the originator in AuthenticatedData. The recipient must independently compute the MAC and verify it equals the mac field; when authAttrs is present, the message digest must also be independently 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 value in signedAttributes.
The SignedData version field MUST be 4 if version 2 attribute certificates are present; MUST be 3 if version 1 attribute certificates are present, eContentType is not id-data, or any SignerInfo is version 3; otherwise MUST be 1.
AuthenticatedData is a SEQUENCE containing version, optional originatorInfo, recipientInfos, macAlgorithm, optional digestAlgorithm, encapContentInfo, optional authAttrs (MUST be DER encoded if present), mac (MessageAuthenticationCode as OCTET STRING), and optional unauthAttrs.
ContentInfo is the top-level CMS encapsulation structure: a SEQUENCE containing a contentType OID and an EXPLICIT ANY content field. All CMS content types are wrapped in ContentInfo identified by id-ct-contentInfo.
EnvelopedData is a SEQUENCE containing version, optional originatorInfo, recipientInfos (SET SIZE 1..MAX of RecipientInfo), encryptedContentInfo (contentType, contentEncryptionAlgorithm, optional encryptedContent OCTET STRING), and optional unprotectedAttrs.
RecipientInfo is a CHOICE of: ktri (KeyTransRecipientInfo) for public-key transport, kari [1] (KeyAgreeRecipientInfo) for Diffie-Hellman style key agreement, kekri [2] (KEKRecipientInfo) for pre-distributed symmetric KEK, pwri [3] (PasswordRecipientInfo) for password-based, and ori [4] (OtherRecipientInfo) for extensibility.
SignedData is a SEQUENCE containing version (CMSVersion), digestAlgorithms (SET OF DigestAlgorithmIdentifier), encapContentInfo (EncapsulatedContentInfo), optional certificates and crls, and signerInfos (SET OF SignerInfo), supporting zero or more parallel signers.
SignerInfo is a SEQUENCE containing version, sid (SignerIdentifier: CHOICE of issuerAndSerialNumber or subjectKeyIdentifier), digestAlgorithm, optional signedAttrs, signatureAlgorithm, signature (OCTET STRING), and optional unsignedAttrs.
Recipients must independently compute all message digest and MAC values and must not rely on originator-supplied values. The signing-time attribute is not verified for correctness; acceptance of a purported signing time is at the recipient's discretion, though timestamp authorities may be implicitly trusted.
Block cipher content-encryption padding: input is padded at the trailing end with k-(lth mod k) octets each having value k-(lth mod k), where k is the block size. All input is padded including lengths already a multiple of k. Valid only when k < 256.
Message digest is computed only over the value octets of the encapContentInfo eContent OCTET STRING, not the tag or length octets. When signedAttrs is present, the digest is computed over the DER encoding of SignedAttrs using an EXPLICIT SET OF tag (not the IMPLICIT [0] tag).