Can we add secp256r1_kyber768 option for those who prefer NIST curves?
I support this. I would also like secp384r1_kyber1024 option, please. Thanks On 29 Mar 2023, at 10:48, Christopher Wood <c...@heapingbits.net> wrote: As discussed during yesterday's meeting, we would like to assess consensus for moving draft-ietf-tls-hybrid-design forward with the following strategy for allocating codepoints we can use in deployments. 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this document through the process towards publication. 2. Write a simple -00 draft that specifies the target variant of X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully did this for us already [1].) Once this is complete, request a codepoint from IANA using the standard procedure. The intent of this proposal is to get us a codepoint that we can deploy today without putting a "draft codepoint" in an eventual RFC. Please let us know if you support this proposal by April 18, 2023. Assuming there is rough consensus, we will move forward with this proposal. Best, Chris, Joe, and Sean [1] https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
