[TLS] Re: Composite ML-DSA

[Sean Turner <[e-mail]>]

Top posting here because the subject has changed and mailer (and maybe yours) seems to show this part of the ML-DSA WGLC thread.

Note that we are *NOT* currently running a WG adoption call for composite ML-DSA.

spt

> On Apr 15, 2026, at 01:43, tirumal reddy <[e-mail]> wrote:
> 
> Hi Yaroslav,
> 
> Thanks for the feedback. This draft significantly reduces the number of code points compared to what is defined in ietf-lamps-pq-composite-sigs, registering only the subset of composite ML-DSA algorithms that are compatible with the traditional signature algorithms already recommended in TLS 1.3, rather than the full set defined in the LAMPS draft. 
> 
> Beyond code point allocation, simply registering code points without a TLS specification would lead to interoperability failures. For example, ietf-lamps-pq-composite-sigs defines a context string parameter for signing and verification, without explicitly requiring an empty context string for TLS use, implementations could make different choices, causing signature verification failures between peers. There are several other such TLS-specific decisions discussed in the draft that cannot be addressed through code point registration alone. 
> 
> We believe these issues justify adoption of the specification in the TLS working group rather than a standalone code point registration.
> 
> Cheers,
> -Tiru
> 
> On Tue, 14 Apr 2026 at 05:22, Yaroslav Rosomakho <yrosomakho=[e-mail] <mailto:[e-mail]>> wrote:
>> I think allocating codepoints to the zoo of ML-DSA composites would be good, but I don't see a good reason to adopt the composites specification in the TLS working group.
>> 
>> -yaroslav
>> 
>> On Tue, Apr 14, 2026 at 12:02 AM David Adrian <[e-mail] <mailto:[e-mail]>> wrote:
>>> I am perfectly fine defining composite certificates however, I will go further than other David and say that Chrome cannot, should not, must not, and will not implement composite certificates in TLS. 
>>> 
>>> On Mon, Apr 13, 2026 at 3:51 PM Filippo Valsorda <[e-mail] <mailto:[e-mail]>> wrote:
>>>> We have no plans to implement composite certificates either.
>>>> 
>>>> 2026-04-14 00:20 GMT+02:00 Watson Ladd <[e-mail] <mailto:[e-mail]>>:
>>>>> I do not think composite certs make sense for TLS.
>>>>> 
>>>>> On Mon, Apr 13, 2026 at 12:33 PM David Benjamin <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> >
>>>>> > On Mon, Apr 13, 2026 at 10:51 AM Viktor Dukhovni <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> >>
>>>>> >> On Mon, Apr 13, 2026 at 04:30:34PM +0000, Andrei Popov wrote:
>>>>> >>
>>>>> >> > Just to weigh in on this: I would support adoption of
>>>>> >> > draft-reddy-tls-composite-mldsa. There is customer demand for
>>>>> >> > composite certs, and I would like to get these implemented in the
>>>>> >> > Windows TLS stack.
>>>>> >>
>>>>> >> I don't know what sort of interoperability you are expecting with these,
>>>>> >> I am strongly inclined to NOT implement any of the composite signature
>>>>> >> algorithms, at least not in TLS.  It may be harder to fend off their
>>>>> >> adoption in CMS, but ideally sit that out as well, until we either have
>>>>> >> CRQCs and hybrids are pointless, or we don't have CRQCs and know why
>>>>> >> we're never going to have them.
>>>>> >
>>>>> >
>>>>> > We're also not planning to implement composite ML-DSA in TLS.
>>>>> >
>>>>> > David
>>>>> > _______________________________________________
>>>>> > TLS mailing list -- [e-mail] <mailto:[e-mail]>
>>>>> > To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Astra mortemque praestare gradatim
>>>>> 
>>>>> _______________________________________________
>>>>> TLS mailing list -- [e-mail] <mailto:[e-mail]>
>>>>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> TLS mailing list -- [e-mail] <mailto:[e-mail]>
>>>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>>> _______________________________________________
>>> TLS mailing list -- [e-mail] <mailto:[e-mail]>
>>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>> 
>> 
>> This communication (including any attachments) is intended for the sole use of the intended recipient and may contain confidential, non-public, and/or privileged material. Use, distribution, or reproduction of this communication by unintended recipients is not authorized. If you received this communication in error, please immediately notify the sender and then delete all copies of this communication from your system._______________________________________________
>> TLS mailing list -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]