On Tue, Jun 30, 2026 at 6:14 AM Yaakov Stein <ystein= [email protected]> wrote:
> > It makes sense to let the user pick what suits best. That has been the > traditional approach at IETF > > > > Actually, the traditional approach at the IETF has been to sanction a > single mandatory-to-implement approach > > supplemented by optional-to-implement alternatives when these have strong > use cases not well treated by the mandatory approach. > This isn't really right. TLS has always been quite permissive about which algorithms it allowed people to use, even when those algorithms were effectively duplicative of existing algorithms. For example, RFC 4492 specified 25 distinct named curves, all the way from 163 bits to 521 bits, including both secp256r1 (P-256) and secp256k1. In the pre-RFC 8447 era, some of these registries required RFCs, and so there were a lot of RFCs specifying new code points, which is an even more permissive situation. I'll once again remind people that what's being debated here is *not* whether the code points will be available and whether people will be able to use them. Those code points have already been registered. Rather, it is whether the IETF will publish an RFC specifying them. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
