John, thanks for clarifying how TLS 1.3 interacts with the certificate 
signature algorithms, that was indeed not on my map. That lead me to put 
some more effort into verifying the correctness of your arguments about 
SUF-CMA leading to "non-malleable" certificates, i.e. those where the 
signature cannot be modified without invalidating the signature. The 
result is that they don't hold for practical purposes.

The write-up and sample files proving malleability of ML-DSA signatures 
of X.509 certificates with OpenSSL certificate verification is here: 
https://github.com/crypto-security-tools/on-composites-signatures

I paste the text here for convenience:


    Strongly unforgeable signatures do not lead to unique X.509 certificates

Here we provide counter evidence to the claim that the use of signature 
schemes that fulfill Strong Unforgeability under Chosen Message Attack 
(SUF-CMA) lead to X.509 certificates that are unique, i.e., even their 
signature cannot be modified. This argument has been used [3] to show 
that the lack of SUF-CMA in the composite signature scheme defined in 
draft-ietf-lamps-pq-composite-sigs [1] is a real-world weakness.

In particular we show that even in a certificate signed with ML-DSA, 
which achieves SUF-CMA, the signature can be modified while retaining 
its verifiability with OpenSSL.

The sample file |mldsa.der| is the original certificate. The sample file 
|mldsa.modified.der| has an extraneous zero octet in the length encoding 
of the signature. The |dumpasn1| tool detects this:

|<03 83 00 0C EE 00 0A C4 03 D3 21 1D 13 E6 7C E5 F8 A2 97 28 A8 C7 52 
A5> 1577 3310: BIT STRING : 0A C4 03 D3 21 1D 13 E6 7C E5 F8 A2 97 28 A8 
C7 : 52 A5 9D 2C 30 BD 29 A1 94 35 50 75 AD 84 1A C7 : 89 B1 DB 82 EC 5F 
2B 9C A1 8E 6F 84 1C 25 79 98 : AE 97 B4 80 E7 86 C4 35 A1 64 39 6D 10 
E7 59 AD : 83 F9 9A D3 12 F5 3E 52 74 05 89 B0 20 17 DB 6C : 8C BA 6A 78 
9A 8D C1 69 15 B0 7A C4 2C 47 EE B3 : C1 28 A3 74 97 5C 11 D0 77 89 20 
4D 46 FD A8 99 : 3A A2 B6 6D 46 90 5E 46 44 9E A2 DA 0C 12 77 AF : [ 
Another 3181 bytes skipped ] : Error: Length '83 00 0C EE' has 
non-canonical encoding. : } |

However, both sample certificates can be verified with OpenSSL [2] 
against the issuer certificate:

|$ openssl verify -CAfile dsa-ca.crt.pem mldsa.modified.der 
mldsa.modified.der: OK |

This shows that achieving unique binary encodings of signatures requires 
far more than SUF-CMA signature schemes. Besides a superfluous length 
octet, other subtle modifications are conceivable, such as playing with 
the number of unused bits in the bit string, or the encoding of NULL 
parameters in the algorithm identifier (instead of their absence) 
preceding the signature.

In the context of Bitcoin, for which malleable signatures lead to a 
critical vulnerability, the first attempt to solve the problem was BIP 
62 <https://en.bitcoin.it/wiki/BIP_0062>, which tries to achieve unique 
binary encoding of the signature. It explicitly addresses strict DER 
encoding as a necessity. However, the long term solution was to remove 
the reliance on SUF-CMA and unique signature encodings in BIP 141 
<https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki>. BIP 
141 solves the problem in a robust way by separating out the signature 
from the transaction data.

------------------------------------------------------------------------

[1] https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/
[2] We used OpenSSL 3.5.6 7 Apr 2026 (Library: OpenSSL 3.5.6 7 Apr 2026) 
on Debian 13
[3] https://mailarchive.ietf.org/arch/msg/tls/Wo9h9hhKZyqxkjYLDhjFpqvBaoU/


Am 06.06.26 um 18:45 schrieb John Mattsson:
>
> An answer to your prvious mail can be found here:
> https://mailarchive.ietf.org/arch/msg/tls/SqcgdaAGom_8pjGWrEQ2oMbfWfs/
>
> I respectfully disagree with all of your arguments for why these 
> technical aspects should not be discussed in the TLS WG. The TLS WG 
> and TLS libraries are not required to support anything defined in the 
> ITU-T X.509 ecosystem, including new cryptographic algorithms designed 
> in LAMPS. Furthermore, draft-reddy-tls-composite-mldsa proposes 
> registering new cryptographic algorithms for use with the 
> signature_algorithms_cert extension, making their impact on TLS 
> directly relevant to this discussion. Moreover, since a stated 
> objective of draft-reddy-tls-composite-mldsa is to address 
> implementation issues in ML-DSA, it is equally relevant to examine 
> whether it may introduce implementation issues in TLS systems, which 
> it clearly can.
>
> I believe my technical comments clearly explain why malleable 
> signatures can create significant vulnerabilities in systems using TLS 
> and why use of such signatures should be phased out, not expanded.
>
> Cheers,
> John Preuß Mattson
>
> *From: *Falko Strenzke <falko.strenzke@mtg.de>
> *Date: *Wednesday, 3 June 2026 at 12:28
> *To: *John Mattsson <john.mattsson@ericsson.com>; Loganaden Velvindron 
> <loganaden@gmail.com>
> *Cc: *Sophie Schmieg <sschmieg@google.com>; IETF TLS <tls@ietf.org>; 
> last-call@ietf.org <last-call@ietf.org>
> *Subject: *Re: [TLS] Re: [Last-Call] Re: Re: Last Call: 
> <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to 
> Informational RFC
>
> Am 03.06.26 um 10:17 schrieb John Mattsson:
>
>     Loganaden Velvindron wrote:
>
>     >What are the security issues you see in this pr ?
>
>     >_https://github.com/djmdjm/openssh-wip/pull/64_
>     <https://github.com/djmdjm/openssh-wip/pull/64>
>
>     The PR is based on draft-ietf-lamps-pq-composite-sigs [1]. As I
>     wrote previously:
>
>     All modern signature schemes (RSA-PSS, EdDSA, LMS, XMSS, ML-DSA,
>     SLH-DSA, FN-DSA) avoid trivial attacks on strong unforgeability
>     and are widely believed to provide a high level of SUF-CMA
>     security [2]. The transition to PQC provides an excellent
>     opportunity to phase out signatures with trivial attacks on strong
>     unforgeability. Malleable signatures have enabled serious attacks
>     in the past [3] and will likely do so again if they continue to be
>     used.
>
>     Malleable signatures can undermine system integrity, auditability,
>     and provenance, and, in the worst case, may even enable replay
>     attacks, see [4]. This is also true for certificates. There is a
>     significant gap between what people think a certificate
>     fingerprint represents and what cryptography actually guarantees
>     when a certificate is signed with a malleable signature algorithm.
>     With such signature algorithms, a CA does not issue a single
>     certificate; instead, it issues a set of valid certificates, each
>     with its own fingerprint.
>
> As I pointed out before on this list, irrespectively of the 
> correctness of this point, it is not relevant to the draft we are 
> discussing here. ML-DSA-composite X.509 CA certificates are already 
> standardised once draft-ietf-lamps-pq-composite-sigs becomes an RFC. 
> The only relevant point in the discussion at hand can be whether TLS 
> end-entity certificates with ML-DSA-composite keys introduce problems. 
> Since EE certificates don't sign other certificates, I wonder what 
> exactly you are referring to when you write about mismatching 
> fingerprints. You should point out where in the TLS protocol such 
> malleable fingerprints occur and why they are a problem, as this is 
> the only point where the composite signatures performed by TLS EE 
> certificates will occur.
>
> Falko
>
>     This mismatch has practical consequences. Logging, SIEM, and
>     threat intelligence systems often record events such as “Observed
>     certificate fingerprint X connecting to service Y,” implicitly
>     treating the fingerprint as a stable identifier. Similarly, some
>     firewall blocklists operate on fingerprints (e.g., “Block
>     fingerprint X”), see e.g., [5], and incident response workflows
>     often rely on fingerprints as unique identifiers when searching
>     for the attacker across datasets. In the presence of only EUF-CMA
>     guarantees, these assumptions break down, as the same underlying
>     certificate can appear under many fingerprints. Nation-state
>     attackers are known to deliberately confuse logging systems, evade
>     signature-based detection, and introduce ambiguity into forensic
>     analysis, and they can be expected to exploit signature
>     malleability for these purposes as well.
>
>
>     Some poorly designed composite signature constructions such as [1]
>     not only significantly reduce the security properties of ML‑DSA by
>     inheriting the malleability of ECDSA, but also introduce
>     additional malleability weaknesses. The composites in [1] also
>     significantly weaken the security of ML-DSA by failing to preserve
>     its beyond-unforgeability (BUFF) properties [6–7]. As shown in
>     [8], existential unforgeability alone does not capture the
>     guarantees required by real-world protocols, and the lack of
>     beyond unforgeability (BUFF) properties in traditional signature
>     schemes has enabled concrete attacks on deployed systems; see
>     [6–7]. We note that there exist signature combiners that preserve
>     both SUF-CMA and BUFF properties [9].
>
>     [1] Composite ML-DSA for use in X.509 Public Key Infrastructure
>
>     _https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-sigs_
>     <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-sigs>
>
>     [2] Digital signature schemes with strong existential unforgeability
>
>     _https://pmc.ncbi.nlm.nih.gov/articles/PMC9925878/_
>     <https://pmc.ncbi.nlm.nih.gov/articles/PMC9925878/>
>
>     [3] Bitcoin Transaction Malleability and MtGox
>
>     _https://link.springer.com/chapter/10.1007/978-3-319-11212-1_18_
>     <https://link.springer.com/chapter/10.1007/978-3-319-11212-1_18>
>
>     [4] OWASP, Signature Malleability
>     _https://scs.owasp.org/SCWE/SCSVS-CRYPTO/SCWE-054/_
>     <https://scs.owasp.org/SCWE/SCSVS-CRYPTO/SCWE-054/>
>
>     [5] Secure Firewall - Blacklisted SSL Certificate Fingerprint
>     _https://research.splunk.com/network/c43f7b49-2dab-4e76-892e-7f971c2f20f1/_
>     <https://research.splunk.com/network/c43f7b49-2dab-4e76-892e-7f971c2f20f1/>
>
>     [6] BUFFing signature schemes beyond unforgeability and the case
>     of post-quantum signatures
>
>     _https://ieeexplore.ieee.org/document/9519420_
>     <https://ieeexplore.ieee.org/document/9519420>
>
>     [7] A Framework for Advanced Signature Notions
>
>     _https://eprint.iacr.org/2025/960.pdf_
>     <https://eprint.iacr.org/2025/960.pdf>
>
>     [8] Seems Legit: Automated Analysis of Subtle Attacks on Protocols
>     that Use Signatures
>
>     _https://eprint.iacr.org/2019/779.pdf_
>     <https://eprint.iacr.org/2019/779.pdf>
>
>     [9] Bird of Prey: Practical Signature Combiners Preserving Strong
>     Unforgeability
>
>     _https://eprint.iacr.org/2025/1844.pdf_
>     <https://eprint.iacr.org/2025/1844.pdf>
>
>     ---
>
>     Some comments on the PR conversation
>
>     >Non-canonical S is also accepted
>
>     1. This implies that the Ed25519 implementation is based on old
>     code not compliant with RFC 8032 and retains known
>     vulnerabilities. Contrary to claims made on the TLS list, Ed25519
>     has not been "stable since 2010." The original Ed25519
>     specification was vulnerable to malleability attacks, and this
>     vulnerability were addressed by CFRG in RFC 8032 in 2017. The 2010
>     version should not be used.
>
>     2. Simply fixing this bug and bringing the implementation into
>     conformance with RFC 8032 does not address the malleability
>     issues. The new signature algorithms defined in
>     draft-ietf-lamps-pq-composite-sigs introduce a new malleability
>     vulnerability.
>
>     >I don't think this matters for OpenSSH's use case since you aren't
>     building a cryptocurrency
>
>     >yeah, we haven't cared about SUF-CMA previously because (like you said)
>     it's totally irrelevant to SSH
>
>
>     That is incorrect. SSH signatures are general-purpose and are used
>     in a wide range of contexts outside of the SSH protocol. The new
>     algorithms defined in draft-ietf-lamps-pq-composite-sigs introduce
>     a malleability attack that is not present in EdDSA or ML-DSA, and
>     they eliminate the BUFF properties provided by ML-DSA. Both
>     signature malleability and the absence of BUFF properties have
>     been the root cause of serious attacks in the past.
>
>     > but that crowd does incredibly dumb things with cryptography so I
>     can't entirely rule out downstream impact to them.
>
>     I find this quite arrogant. Signatures should not be malleable,
>     and no standardized signature schemes are, except ECDSA, which was
>     designed by the NSA. Stating that people who do not except
>     signatures to be malleable are "incredibly dumb" is like saying
>     that Bernstein is incredibly dumb for not understanding how to use
>     SHA-2 securely in SPHINCS+. If anything is incredibly dumb, it is
>     to standardize, implement, and deploy new malleable signatures.
>
>     ---
>
>     I find the idea that ML-DSA is an NSA backdoor to be absurd, but
>     if that conspiracy theory is in any way a driving factor for this
>     PR, it is illogical to use Ed25519, whose security ultimately
>     depends on SHA-2, a hash function designed by the NSA. ML-DSA and
>     SHA-3 were primarily designed by European cryptographers.
>
>     ---
>
>     I am starting to think that
>     /draft-ietf-lamps-pq-composite-sigs/ [1] is one of the worst
>     things to come out of the IETF in a very long time:
>
>     - It is very poorly designed. It removes the BUFF properties of
>     ML-DSA and introduces a new malleability weakness. One would think
>     the reason to wait for FIPS 204 was to ensure that all security
>     properties of ML-DSA were preserved, but this is not the case.
>     Composite signatures are new cryptographic constructions and
>     should be designed within CFRG.
>
>     - The design goals were not security. The goal is shady business
>     practices of selling FIPS-validated RSA and ECDSA as
>     “quantum-resistant.” You can slap on ML-DSA reference code from
>     2017 and suddenly you have a “FIPS-validated” ML-DSA hybrid.
>
>     - It is now the biggest obstacle to the urgent migration of roots
>     of trust in PKI and long-lived devices. If standalone ML-DSA is
>     not trusted, standalone SLH-DSA by Bernstein and others is an
>     excellent alternative for roots of trust.
>
>     - It is a Trojan horse for well-designed composite and
>     non-composite hybrid schemes that could actually be deployed. It
>     is consuming time that could be spent on other approaches, while
>     being so poorly designed that it cannot be deployed. Ericsson will
>     not support [1] in any of our libraries, products, or services. We
>     will use non-composite hybrids signatures.
>
>     Cheers,
>
>     John Preuß Mattsson
>
>
>     _______________________________________________ TLS mailing list
>     -- tls@ietf.org To unsubscribe send an email to tls-leave@ietf.org
>
> --
>
> *MTG AG*
> Dr. Falko Strenzke
>
> Phone:
> +49 6151 8000 24
> E-Mail:
> falko.strenzke@mtg.de
> Web:
> mtg.de <https://www.mtg.de>
> ------------------------------------------------------------------------
>
> MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
> Commercial register: HRB 8901
> Register Court: Amtsgericht Darmstadt
> Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
> Chairman of the Supervisory Board: Dr. Thomas Milde
>
> This email may contain confidential and/or privileged information. If 
> you are not the correct recipient or have received this email in error,
> please inform the sender immediately and delete this 
> email.Unauthorised copying or distribution of this email is not permitted.
>
> Data protection information: Privacy policy 
> <https://www.mtg.de/en/privacy-policy>
>
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: +49 6151 8000 24
E-Mail: falko.strenzke@mtg.de
Web: mtg.de <https://www.mtg.de>

------------------------------------------------------------------------

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If 
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised 
copying or distribution of this email is not permitted.

Data protection information: Privacy policy 
<https://www.mtg.de/en/privacy-policy>