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= [email protected]> 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 <[email protected]> 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 <[email protected]> >> wrote: >> >>> We have no plans to implement composite certificates either. >>> >>> 2026-04-14 00:20 GMT+02:00 Watson Ladd <[email protected]>: >>> >>> I do not think composite certs make sense for TLS. >>> >>> On Mon, Apr 13, 2026 at 12:33 PM David Benjamin <[email protected]> >>> wrote: >>> > >>> > On Mon, Apr 13, 2026 at 10:51 AM Viktor Dukhovni < >>> [email protected]> 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 -- [email protected] >>> > To unsubscribe send an email to [email protected] >>> >>> >>> >>> -- >>> Astra mortemque praestare gradatim >>> >>> _______________________________________________ >>> TLS mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>> >>> _______________________________________________ >>> TLS mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > > > 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
