Hi Bas, a big yes to recommending X25519MLKEM768 as soon as possible. I would even go further and update the mandatory-to-implement section of RFC 8446 (which looks interesting right now with some potential "D" algorithms).
Marking algorithms as "D" has little effect as long as registering new PQ-vulnerable "N" algorithms is just "Specification required". Also, you may have missed arbitrary_explicit_prime_curves and arbitrary_explicit_char2_curves? I am against recommending any other algorithms right now, but could be convinced to make an exception for the remainder of draft-ietf-ecdhe-mlkem, as long as it's not MTI. -- TBB
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
