Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection
updates
- rfc-5652 — Cryptographic Message Syntax (CMS)
Extracted elements (18)
CMS signed-data, unlike X.509 certificates, is vulnerable to algorithm substitution attacks because it does not cryptographically bind the algorithm identifier. An attacker can change the algorithm identifier or its parameters to alter the verification process. This document addresses this by requiring consistent use of the same hash algorithm and recommending the CMSAlgorithmProtection attribute.
No requirement is placed on a TSA to ensure the digest algorithm for a TimeStampToken matches the digest algorithm for the MessageImprint embedded within TSTInfo, in order to preserve validity of TimeStampToken values generated before this update.
Requiring the same hash algorithm for both the message content digest and the signed attributes digest is a convention already followed by most implementations, so backward compatibility impact is expected to be minimal. Signatures using two different digest algorithms will be considered invalid by implementations following this specification.
Some signature algorithms (e.g., RSASSA-PKCS1-v1_5) internally protect the digest algorithm identifier, while others (e.g., RSASSA-PSS) do not. Because newer algorithms may lack this 'firewall,' signers need an explicit mechanism — such as CMSAlgorithmProtection or certificate extensions — to signal which digest algorithms are permitted for signature verification.
When a digest algorithm produces a result larger than needed by the signature algorithm, the digest is reduced (e.g., by truncation). This means an attacker only needs to find a collision with the reduced digest value. For example, SHA-512 with ECDSA P-256 requires only a collision in the first half of the digest.
For timestamping systems where the originator does not share message content with the TSA, the originator sends a MessageImprint with a digest algorithm identifier and digest value. The TSA uses the originator-provided digest, so the TSA's own digest algorithm must match the MessageImprint algorithm for new TimeStampTokens, but legacy tokens are not invalidated.
Implementations that previously allowed different digest algorithms for message content and signed attributes will produce signatures that are invalid under this specification. However, most existing implementations already enforced same-algorithm usage, so real-world incompatibility is expected to be rare.
The message digest algorithm SHOULD be among those listed in the digestAlgorithms field of the associated SignedData. Implementations MAY fail to validate signatures that use a digest algorithm not included in the SignedData digestAlgorithms set.
The originator of a signed-data content type that includes signed attributes SHOULD include the CMSAlgorithmProtection attribute (RFC 6211) as one of the signed attributes.
The originator of an authenticated-data content type that includes authenticated attributes SHOULD include the CMSAlgorithmProtection attribute (RFC 6211) as one of the authenticated attributes.
The recipient MUST NOT rely on any message digest values computed by the originator. If the SignedData signerInfo includes the signedAttrs field, the content message digest MUST be calculated using the same digest algorithm to compute both the digest of the encapContentInfo eContent OCTET STRING and the message-digest attribute.
When producing a TimeStampToken, the TSA MUST use the same digest algorithm to compute the digest of the encapContentInfo eContent (an OCTET STRING containing TSTInfo) and the message-digest attribute within the SignerInfo.
When the signedAttrs field is present in the SignerInfo, the same digest algorithm MUST be used to compute both the digest of the SignedData encapContentInfo eContent (carried in the message-digest attribute) and the digest of the DER-encoded signedAttrs passed to the signature algorithm.
When the signedAttrs field is present, the same digest algorithm MUST be used to compute the digest of the encapContentInfo eContent OCTET STRING and the digest of the collection of attributes that are signed.
The CMSAlgorithmProtection attribute (defined in RFC 6211) binds the algorithm identifiers used by the originator as a signed or authenticated attribute, making algorithm substitution attacks significantly more difficult. It is recommended for inclusion whenever signed or authenticated attributes are present.
For authenticated-data content types, the improvements force an attacker to mount a MAC algorithm substitution attack, which is difficult because the attacker does not know the authentication key.
The CMSAlgorithmProtection attribute provides no protection for algorithm identifiers in the enveloped-data, digested-data, encrypted-data, or authenticated-enveloped-data content types. Protection for those types is identified as future work.
The improvements in this document force an attacker targeting signed-data to mount a hash algorithm substitution attack on the overall signature rather than only on the message digest of the encapContentInfo eContent, significantly raising the difficulty of such attacks.