BoringSSL has a pair of implementations ready (in C and in our fork of Go's TLS stack for testing). We're using the value in the TLS 1.3 draft, so 29. It's not currently enabled in any Chrome builds, but I'm expecting to change this soon.
David On Tue, Jan 19, 2016 at 12:54 PM Joseph Salowey <j...@salowey.net> wrote: > Any objections to early allocation for X25519 and X448? Are there > implementers with code ready to test interop? > > Thanks, > > Joe > > On Thu, Jan 14, 2016 at 3:22 PM, Brian Smith <br...@briansmith.org> wrote: > >> Simon Josefsson <si...@josefsson.org> wrote: >> >>> Allocating a code point for X25519 could be done and is long overdue >>> (first draft September 2013). X448 is also stable. Code points for >>> Ed25519 and Ed448 is more problematic since TLS authentication has >>> historically had interaction with PKIX certs. I agree with Yoav's >>> assertion that the curve point verification issue is not big enough to >>> stall code point allocation. >> >> >> I agree with this. >> >> Cheers, >> Brian >> > > _______________________________________________ > 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
