Best Practices for Signed Attributes in CMS SignedData

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 August 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The Cryptographic Message Syntax (CMS) [RFC5652] signed-data content type allows any number of signers in parallel to sign any type of content.¶

CMS gives a signer two options when generating a signature on some content:¶

• Generate a signature on the whole content; or¶

• Compute a hash over the content, place this hash in the message-digest attribute in the SignedAttributes type, and generate a signature on the SignedAttributes. The SignedAttributes type is placed in the signedAttrs field of the SignedData type.¶

The resulting signature does not commit to the presence of the SignedAttributes type, allowing an attacker to influence verification behaviour. An attacker can perform two different types of attacks:¶

1. Take an arbitrary CMS signed message M which was originally signed with SignedAttributes present and rearrange the structure such that the SignedAttributes field is absent and the original DER-encoded SignedAttributes appears as an encapsulated or detached content of type id-data, thereby crafting a new structure M' that was never explicitly signed by the signer. M' has the DER-encoded SignedAttributes of the original message as its content and verifies correctly against the original signature of M.¶

2. Let the signer sign a message of the attacker's choice without SignedAttributes. The attacker chooses this message to be a valid DER-encoding of a SignedAttributes object. The attacker can then add this encoded SignedAttributes object to the signed message and change the signed message to the one that was used to create the messageDigest attribute within the SignedAttributes. The signature created by the signer is valid for this arbitrary attacker-chosen message.¶

This vulnerability was presented by Falko Strenzke to the LAMPS working group at IETF 121 [LAMPS121] and is detailed in [Str23].¶

Section 5.3 of [RFC5652] states:¶

• signedAttrs is a collection of attributes that are signed. The field is optional, but it MUST be present if the content type of the EncapsulatedContentInfo value being signed is not id-data.¶

Thus, if a verifier accepts a content type of id-data in the EncapsulatedContentInfo type when used in SignedData, then a SignerInfo within the SignedData may or may not contain a signedAttrs field and will be vulnerable to this attack. On the other hand, if the verifier doesn't accept a content type of id-data, the sender always adds the signedAttrs field, and the recipient verifies that signedAttrs is present, the attack will not succeed.¶

The limited flexibility of either the signed or the forged message in either attack variant may mean the attacks are only narrowly applicable. Nevertheless, due to the wide deployment of the affected protocols and the use of CMS in many proprietary systems, the attacks cannot be entirely disregarded.¶

As a mitigation, this document defines the new mimeData content type to be used in new uses of the CMS SignedData type when the encapsulated content is MIME encoded and thus avoid the use of the id-data content type. This document further describes best practices and mitigations that can also be applied to those protocols or systems that continue to use the content type id-data.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. mimeData Content Type

The following object identifier identifies the mimeData content type:¶

  id-mime-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
      us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1)
      TBD2 }

The mimeData content type is intended as a replacement for the id-data content type in new uses of the CMS SignedData type where the content is MIME encoded.¶

4. Best Practices

This section describes the best practices to avoid the vulnerability at the time of writing.¶

New uses of the CMS SignedData MUST NOT use the id-data EncapsulatedContentInfo content type. If the new content is MIME encoded, the mimeData content type SHOULD be used.¶

5. Mitigations

This section describes mitigations for cases where the best practices given above cannot be applied. When the id-data EncapsulatedContentInfo content type is used, the following mitigations MAY be applied to protect against the vulnerability described in Section 1.¶

6. Security Considerations

The vulnerability is not present in systems where the use of signedAttrs is mandatory, as long as recipients enforce the use of signedAttrs. Some examples where the use of signedAttrs is mandatory are SCEP, Certificate Transparency, RFC 4018 firmware update, German Smart Metering CMS data format. Any protocol that uses an EncapsulatedContentInfo content type other than id-data is required to use signed attributes. However, this security relies on a correct implementation of the verification routine that ensures the correct content type and presence of signedAttrs.¶

When the message is signed and then encrypted, though in the general case this will make it difficult for the attacker to learn the signature, the vulnerability might still be present if mitigations are not applied:¶

• Signing and encryption might not be done on the same endpoints, in which case an attacker between the endpoints might be able to learn the signature for which it could remove or add the signedAttrs.¶

• IND-CPA encryption does not give theoretical guarantees against an active attacker and thus does not guarantee that an attacker cannot rearrange the structure.¶

Conceivably vulnerable systems:¶

• Unencrypted firmware update denial of service¶

  • Secure firmware updates often use signatures without encryption. If the forged message can bring a device, due to lack of robustness in the parser implementation, into an error state, this may lead to a denial of service vulnerability. The possibility of creating a targeted exploit can be excluded with great certainty in this case due to the lack of control the attacker has over the forged message.¶

• Dense message space¶

  • If a protocol has a dense message space, i.e. a high probability that the forged message represents a valid command or the beginning of a valid command, then, especially if the parser is permissive with respect to trailing data, there is a risk that the message is accepted as valid. This requires a protocol where messages are signed but not encrypted.¶

• Signing unstructured data¶

  • Protocols that sign unencrypted unstructured messages, e.g. tokens, might be affected in that the signature of one token might result in the corresponding forged message being another valid token.¶

• External signatures over unstructured data¶

  • The probably strongest affected class of systems would be one that uses external signatures, i.e. CMS signatures with absent content (that may be transmitted encrypted separately) over unstructured data, e.g. a token of variable length. In that case the attacker could create a signed data object for a known secret.¶

• Systems with permissive parsers¶

  • In addition to potential issues where the protocol parser is permissive (e.g. with respect to trailing space), if the CMS parser is permissive (e.g. allows non-protocol content types, or allows missing signedAttrs with content types other than id-data) then this could result in accepting invalid messages.¶

Further note that it is generally not good security behaviour to sign data received from a 3rd party without first verifying that data. Section 5.2 describes just one verification step that can be performed, specific to the vulnerability described in Section 1.¶

7. ASN.1 Module

<CODE STARTS>

MimeData-2026 { iso(1) member-body(2) usa(840)
        rsadsi(113549) pkcs(1) pkcs9(9) smime(16) modules(0)
        id-mod-mime-data-2026(TBD1) }
DEFINITIONS EXPLICIT TAGS ::= BEGIN

IMPORTS
    CONTENT-TYPE
    FROM  CryptographicMessageSyntax-2010
      { iso(1) member-body(2) us(840) rsadsi(113549)
         pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }
    ;

    id-mime-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
        us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1)
        TBD2 }

    ct-MimeData CONTENT-TYPE ::= { IDENTIFIED BY id-mime-data }

END

<CODE ENDS>

8. IANA Considerations

In the "SMI Security for S/MIME Module Identifier" registry, create a new entry to point to this document.¶

In the "SMI Security for S/MIME Content Types" registry, add a new entry for id-mime-data that points to this document.¶

In the table "CMS Inner Content Types" add a new entry:¶

9. References

Appendix A. RFCs Using the id-data EncapsulatedContentInfo Content Type

This appendix lists RFCs which use the id-data content type in EncapsulatedContentInfo. It is a best-effort list by the authors at time of authorship. The list can be used as a starting point to determine if any of BCPs in this document can be applied.¶

The following table summarizes the RFCs' usages of signed attributes.¶

An RFC requiring or forbidding signed attributes does not necessarily mean that a recipient will enforce this requirement when verifying, their CMS implementation may simply process the message whether or not signed attributes are present. If one of the signed attributes is necessary for the recipient to successfully verify the signature or to successfully process the CMS data then the vulnerability will not apply; at least not when assuming the signer is well-behaved and always signs with signed attributes present in accordance with the applicable specification.¶

Acknowledgments

The authors would like to thank Russ Housley, Carl Wallace, and John Preuß Mattsson for their valuable feedback on this document.¶

Authors' Addresses