No objection there 👍 On Wed, Mar 6, 2024, 11:10 PM Bas Westerbaan <b...@cloudflare.com> 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
