> Isn't support for the component mandatory to support the hybrid anyway?
Strictly speaking, not necessarily: I could see support for X-Wing or another hybrid key agreement as a standalone unit, both from a software dependency perspective and protocol API perspective. Whether that works in the long term that also supports the standalone component algorithms, that's another question On Wed, Mar 6, 2024, 11:30 PM Orie Steele <orie@transmute.industries> wrote: > 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
