I concur. -Ekr
On Thu, Jan 14, 2016 at 7:14 AM, 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. > > /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 > > > > _______________________________________________ > 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
