]> CryptoNext Security

daniel.vangeest@cryptonext-security.com

MTG AG

falko.strenzke@mtg.de

Security Limited Additional Mechanisms for PKIX and SMIME Cryptographic Message Syntax CMS The Cryptographic Message Syntax (CMS) has different signature verification behaviour based on whether signed attributes are present or not. This results in a potential existential forgery vulnerability in CMS and protocols which use CMS. This document describes the vulnerability and lists a number of potential mitigations for LAMPS working group discussion. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Cryptographic Message Syntax (CMS) 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 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. He 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 at IETF 121 and is detailed in . Due to the limited flexibility of either the signed or the forged message in either attack variant, the fraction of vulnerable systems can be assumed to be small. But due to the wide deployment of the affected protocols, such instances cannot be excluded.

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 when, and only when, they appear in all capitals, as shown here.

Potential Mitigations Potential mitigations are described in the following sub-sections as input to the working group discussion. If this draft is adopted and the working group has taken a decision which measure(s) should be realized, we'll describe the chosen measures in detail. The mitigations in this section make use of a context string which is passed to the signature algorithm's sign and verify functions. ML-DSA , SLH-DSA , Composite ML-DSA , and Ed448 take a context string during signing and verification. The context string may be up to 255 bytes long. By default the context string is the empty string. RSA, ECDSA and Ed25519 signatures do not take a context string and would not be helped by these mitigations. Ed448 can take a context string but does not currently in CMS . Ed25519ctx takes a context string but is not specified for use in CMS.

Immediate Forced Use of Specific Signature Context Strings Immediately update , , and to require a context string, with a different value for use with and without signated attributes. When signed attributes are present: When signed attributes are absent: Unlike the following mitigations, Ed448 cannot be addressed by this mitigation because it is already published and in use.

Attribute-Specified Use of Implicit Signature Context Strings Like , but the use of the signature context string is indicated by a new, empty (or attribute value ignored), sign-with-context-implicit unsigned attribute. , , and can be published using the default signature context string. ML-DSA, SLH-DSA, Composite-ML-DSA, and Ed448 only use the non-default context string when the new attribute is used.

Signing When signed attributes are present: When signed attributes are absent:

Verifying When signed attributes are present: When signed attributes are absent:

Attribute-Specified Use of Explicit Signature Context Strings Like but the new unsigned attribute (sign-with-context-explict) contains a semi-colon-delimited list of keyword (and optional value) strings. This addresses the possibility of future CMS features that require context parameters. [=value1];...;[=value]" ]]> The list is ordered alphabetically by type string. This list is validated by the verifier and used as the signature context string. (alternative: the SHA-256 hash of the list is used as the signature context string to avoid it getting too long) A proposed list of initial signature context string keywords follows: Potential Context String Keywords

keyword	value	comment
"IETF/CMS"		REQUIRED to be in the sign-with-context-implicit attribute, to differentiate a signature in CMS from a signature with the same private key over some other data.
"signed-attrs"		Present if signed attributes are used, not present if signed attributes are not used. Alternative: always present, value = 0/1, yes/no depending on whether signed attributes are present or not.
"app-ctx"	base64( SHA-256( protocol_context ) )	Allows the protocol using CMS to specify a context. SHA-256 is applied so that the length available to the protocol context isn't dependent on the other context values used in CMS. (alternative: no SHA-256 here, apply SHA-256 to the whole CMS context). base64-encoding is applied so the app context doesn't introduce semi-colons to mess up CMS' parsing of this string.

When a verifier processes a SignerInfo containing the sign-with-context-explicit attribute, it MUST perform the following consistency checks:

• If the "signed-attrs" keyword is present and SignedAttributes is not present in the SignerInfo, fail verification.
• If the "signed-attrs" keyword is not present and SignedAttributes is present in the SignerInfo, fail verification.

If the consistency checks pass, the signature is verified using the string in the sign-with-context-explicit attribute as the signature context (alternative: using SHA-256 of the string in the sign-with-context-explicit attribute). When a verifier processes a SignerInfo without the sign-with-context-explicit attribute, they MUST verify the signature using the default signature context value (""). , , and can be published using the default signature context string. ML-DSA, SLH-DSA, Composite-ML-DSA, and Ed448 only use the non-default context string when the new attribute is used.

Straw Mitigations The following mitigations might not be good ideas but are included just in case there's a seed of genius in them.

Attack Detection in CMS If eContentType is id-data and SignedAttributes is not present, check if the encapsulated or detached content is a valid DER-encoded SignedAttributes structure and fail if it is. The mandatory contentType and messageDigest attributes, with their respective OIDs, should give a low probability of a legitimate message being flagged. If an application protocol deliberately uses such a signed messages, verification would fail. This mitigation does not address the inverse problem where a protocol doesn't used SignedAttributes but for some reason often sends messages which happen to be formatted like valid SignedAttributes encodings, with attacker-controlled bytes where the message digest attribute would be.

Always/Never use SignedAttributes in Your Protocol Individually update each protocol which use CMS to always require or forbid signed attributes. In particular, if an eContentType other than id-data is used, requires that signed attributes are used. During verification, ensure that you are receiving the expected (non-id-data) eContentType and that signed attribues are present.

Attack Detection in Your Protocol but specified in the protocol that uses CMS rather than CMS itself.

Check Content Type Consistency Check that the content type the EncapsulatedContentInfo value being verified is consistent with your application. If the content type of the EncapsulatedContentInfo value being verified is not id-data and signed attributes are not present, verification MUST fail.

RFCs Using the id-data eContentType The RFCs in the following subsections use the id-data eContentType. This table summarizes their usages of signed attributes. RFCs using id-data

RFC	Signed Attributes Usage
	Requires the used of signed attributes
	Says nothing about signed attributes
	RECOMMENDS signed attributes
	Forbids signed attributes
	RECOMMENDS signed attributes
	Says nothing about signed attributes
	Forbids signed attributes
	Requires signed attributes
	Says nothing about signed attributes
	RECOMMENDS signed attributes
	Requires signed attributes
	RECOMMENDS signed attributes

An RFC requiring or forbidding signed attributes does not necessarily mean that a verifier 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 verifier to successfully verify the signature or to successfully process the CMS data then the attack 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.

RFC 8894 Simple Certificate Enrolment Protocol Figure 6 in specifies id-data as the eContentType, and shows the use of signedAttrs. The document itself never refers to signed attributes, but instead to authenticated attributes and an authenticatedAttributes type. Errata ID 8247 clarifies that it should be "signed attributes" and "signedAttrs". Since SCEP requires the use of signedAttrs with the id-data eContentType, and the recipient must process at least some of the signed attributes, it is not affected by the attack.

RFC 8572 Secure Zero Touch Provisioning (SZTP) allows the use of the id-data eContentType, although it also defines more specific content types. It does not say anything about signed attributes.

S/MIME RFCs , , , and require the use of the id-data eContentType. says:

• Receiving agents MUST be able to handle zero or one instance of each of the signed attributes listed here. Sending agents SHOULD generate one instance of each of the following signed attributes in each S/MIME message:

and

• Sending agents SHOULD generate one instance of the signingCertificate or signingCertificateV2 signed attribute in each SignerInfo structure.

So the use of signed attributes is not an absolute requirement.

RFC 6257 Bundle Security Protocol Specification says:

• In all cases where we use CMS, implementations SHOULD NOT include additional attributes whether signed or unsigned, authenticated or unauthenticated.

RFC 5655 IP Flow Information Export (IPFIX) is a file format that uses CMS for detached signatures. It says nothing about the use of signed attributes.

RFC 5636 Traceable Anonymous Certificate says:

• The signedAttr element MUST be omitted.

RFC 5126 CMS Advanced Electronic Signatures (CAdES) specifies mandatory signed attributes. One of the signed attributes is used to determine which certificate is used to verify the signature, so this CaDES is not affected by the attack.

RFC 5024 ODETTE File Transfer Protocol 2 uses the id-data eContentType and says nothing about signed attributes.

RFC 3126 Electronic Signature Formats for long term electronic signatures requires the MessageDigest attribute, which is a signed attribute.

Security Considerations TODO Security The vulnerability is not present in systems where the use of SignedAttributes is mandatory, for example: SCEP, Certificate Transparency, RFC 4018 firmware update, German Smart Metering CMS data format. Any protocol that uses an eContentType 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 presence of SignedAttributes. The vulnerability is also not present when the message is signed and then encrypted, as the attacker cannot learn the signature. Conceivably vulnerable systems (TODO: describe these better):

• Unencrypted firmware update denial of service
• Dense message space
• Signing unstructured data
• External signatures over unstructured data
• Systems with permissive parsers

IANA Considerations This document has no IANA actions.

References Normative References This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (U.S.) Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of ML-DSA [FIPS.204] in hybrid with traditional algorithms RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet security best practices and regulatory requirements. Composite ML-DSA is applicable in any application that uses X.509, PKIX, and CMS data structures and protocols that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This document specifies the conventions for using the Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS. UK National Cyber Security Centre UK National Cyber Security Centre CryptoNext Security The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined in FIPS 204, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the ML-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. Vigil Security, LLC Cisco Systems Amazon Web Services Cloudflare SLH-DSA is a stateless hash-based signature scheme. This document specifies the conventions for using the SLH-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. This document specifies the Simple Certificate Enrolment Protocol (SCEP), a PKI protocol that leverages existing technology by using Cryptographic Message Syntax (CMS, formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates. This document presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems. This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. This document defines the bundle security protocol, which provides data integrity and confidentiality services for the Bundle Protocol. Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various security considerations including some policy options. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community. This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. [STANDARDS-TRACK] This document describes a file format for the storage of flow data based upon the IP Flow Information Export (IPFIX) protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. [STANDARDS TRACK] This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request formats such as PKCS10 (RFC 2986) and CMC (RFC 5272). The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Blind Issuer) and the other for validating the contents of a certificate (Anonymity Issuer). The end entity (EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs). This memo defines an Experimental Protocol for the Internet community. This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates) the validity of the signature. The format can be considered as an extension to RFC 3852 and RFC 2634, where, when appropriate, additional signed and unsigned attributes have been defined. The contents of this Informational RFC amount to a transposition of the ETSI Technical Specification (TS) 101 733 V.1.7.4 (CMS Advanced Electronic Signatures -- CAdES) and is technically equivalent to it. The technical contents of this specification are maintained by ETSI. The ETSI TS and further updates are available free of charge at: http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx This memo provides information for the Internet community. This memo updates the ODETTE File Transfer Protocol, an established file transfer protocol facilitating electronic data interchange of business data between trading partners, to version 2. The protocol now supports secure and authenticated communication over the Internet using Transport Layer Security, provides file encryption, signing, and compression using Cryptographic Message Syntax, and provides signed receipts for the acknowledgement of received files. The protocol supports both direct peer-to-peer communication and indirect communication via a Value Added Network and may be used with TCP/IP, X.25, and ISDN-based networks. This memo provides information for the Internet community. This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 2633. [STANDARDS-TRACK] This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates the validity of the signature). This memo provides information for the Internet community. This document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK]

Acknowledgments TODO acknowledge.