Does the argument about hybrid code points first generalize to all PQ Code points?
Is it equally true of hybrid signatures? I don't understand why registering composite components first wouldn't be assumed. Isn't support for the component mandatory to support the hybrid anyway? Let's assume CRQC drops tomorrow, why did we not register ML-KEM first? Assume it never drops, you still needed to implement ML-KEM to use the hybrid. If the goal is to prohibit ML-KEM without a traditional component, just register it as prohibited. OS On Wed, Mar 6, 2024, 10:10 PM Bas Westerbaan <bas= 40cloudflare....@dmarc.ietf.org> wrote: > Back to the topic at hand. I think it'd very bad if we'd have a codepoint > for pure ML-KEM before we have a codepoint for an ML-KEM hybrid. Process > wise, I think that's up to the designated experts of the IANA registry. > > Best, > > Bas > > > On Wed, Mar 6, 2024 at 3:16 AM Deirdre Connolly <durumcrustu...@gmail.com> > wrote: > >> I have uploaded a preliminary version of ML-KEM for TLS 1.3 >> <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/> >> and have a more fleshed out >> <https://github.com/dconnolly/draft-tls-mlkem-key-agreement> version to >> be uploaded when datatracker opens. It is a straightforward new >> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a >> very similar style to -hybrid-design >> <https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/>. >> >> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 >> compatible) ready to go when users are ready to use them. >> >> Cheers, >> Deirdre >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
