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.
/Simon Joseph Salowey <j...@salowey.net> writes: > Hi All, > > Looks like I jumped too soon on this one. In particular, both the CFRG > signature draft and 4492bis need to be updated. Let's hold of on code > point assignment until then. > > Thanks, > > Joe > (crawling back under my rock now) > > On Wed, Jan 13, 2016 at 3:04 AM, Alexey Melnikov <alexey.melni...@isode.com> > wrote: > >> >> > On 12 Jan 2016, at 21:31, Ilari Liusvaara <ilariliusva...@welho.com> >> wrote: >> > >> >> On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote: >> >> >> >>> On 12 Jan 2016, at 9:26 PM, Simon Josefsson <si...@josefsson.org> >> wrote: >> >>> >> >>> The same concern still applies: what does it mean to allocate code >> >>> point for the 4492bis-05 description? >> >> >> >> Allocating code points just means an implementation of draft-05 is >> >> likely to interoperate just fine with an implementation of the final >> >> RFC. >> >> >> >> Of course nothing is ever final until the RFC is out, so there’s >> >> always a risk involved, but it is considered prudent to allocate >> >> numbers when we’re reasonably certain of the calculations and on- >> >> the-wire formats. Any debate about whether we should or should not >> >> check certain inputs for certain conditions need not be a bar for >> >> allocating numbers. >> > >> > Assuming CFRG chairs really did declare consensus on Ed448 hash, then >> > the final characteristics of Ed448 are known and I have a reference >> > implementation. >> > >> > And the PKIX draft looks implementable (has wrong example?) >> > >> > More serious interop hazard is what to do with X25519/X448 and THS >> > (some of the proposed stuff is not wire-compatible). >> >> This CFRG co-chair would like to see an updated CFRG draft before the code >> point is allocated. >> >> _______________________________________________ >> 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 >
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
