ML-DSA and SLH-DSA in X.509: The Underwhelming Role of Context Strings

When NIST published the specifications for the PQC digital signature algorithms ML-DSA and SLH-DSA, they included a feature that is not seen in classical digital signature algorithms such as RSA and ECDSA. The feature allows applications that use ML-DSA and SLH-DSA to specify a “context string”, which is a safeguard against cross-protocol attacks. Cross-protocol attacks occur when the sender creates a message of a particular type, but the receiver is misled (via replaying or tampering of the message by an on-path attacker on the network, etc.) to interpret the message as a different type. The receiver then acts on the contents of the incorrectly interpreted message.

Historically, applications and protocols have included their own safeguards against such attacks (or ignore the problem entirely and include no safeguards at all), but the inclusion of the “context string” parameter in the signing and verification routines of ML-DSA and SLH-DSA moves this safeguard directly into the signature algorithm specification. Including the message type directly in the signed content through the context string allows applications to implement “domain separation” (the term used to denote this protection against cross-protocol attacks) in a standard manner. For example, X.509 can specify “CERTIFICATE” as the context string for certificates to ensure that certificates cannot be confused with CRLs (which may use their own context string, such as “X509 CRL”) or messages for other protocols. Since the context string is signed alongside the message itself, any attempt to consume a message of the wrong type will lead to a signature verification error, preventing the receiver from further processing the incorrect message.

However, leveraging this new feature in existing protocols and cryptographic implementations poses implementation challenges that may prevent its widespread use. Historically, signature algorithms define a function for signing messages and a function for verifying messages. Expressed as pseudocode:

Sign(PrivateKey, Message) -> Signature (bit string)

Verify(PublicKey, Message, Signature) -> IsValid (true/false)

Many libraries expose this interface with these function parameters. Additionally, standards such as PKCS #11 (which many cryptographic modules use to expose their functionality) define signing and verification interfaces in the way described above. However, ML-DSA and SLH-DSA expose the signing and verification functions like this:

Sign(PrivateKey, Message, ContextString) -> Signature

Verify(PublicKey, Message, Signature, ContextString) -> IsValid (true/false)

While the addition of the ContextString parameter may be useful for applications to implement domain separation in a standard way, concerns about the ability to update existing libraries and standards to accommodate its inclusion is already causing standards groups to not use the feature. For example, the LAMPS working group of the IETF will not be using the context string feature for X.509 certificates and CRLs due to the lack of support of the context string in existing implementations. Instead, the draft specifications detailing how to use ML-DSA and SLH-DSA in X.509 will specify that the empty string be used for the context string value when signing and verifying certificates and CRLs (the empty string is the default value and the standard way for applications to not use context string parameter). If other protocols follow suit and do not define their own context strings and instead elect to use the default empty string, then the usefulness of this feature will be lost.

There are proponents of breaking backwards compatibility in favor of leveraging the context string for X.509, and the discussion is still ongoing. However, given the current state of the draft specifications, it appears that the context string feature will not be used for X.509.