On Wed, Apr 15, 2026 at 11:13:17AM +0530, tirumal reddy wrote:
> 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.
Well, a code point registration isn't JUST an entry in the IANA table,
it must be accompanied by a reference to a specification of how that
code point integrates into the TLS protocol. That specification need
not always be a TLS WG RFC (though I and many others still support that
outcome for the pure ML-KEM draft).
In the case of composite ML-DSA, the various issues you're highlighting,
such as the context strings, can all be handled in such a non-WG
document.
Given the apparent lackluster enthusiasm to implement composite ML-DSA
in TLS, perhaps that document can in fact be published in another stream
(ISE) or somewhere else entirely?
There's precedent for that, see for example:
https://datatracker.ietf.org/doc/html/rfc8998
https://datatracker.ietf.org/doc/html/draft-yang-tls-hybrid-sm2-mlkem-03
and associated IANA code points:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
0x00,0xC6 TLS_SM4_GCM_SM3
0x00,0xC7 TLS_SM4_CCM_SM3
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
41 curveSM2
4590 curveSM2MLKEM768
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme
0x0708 sm2sig_sm3
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
