Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

I concur.

-Ekr

On Thu, Jan 14, 2016 at 7:14 AM, Simon Josefsson <simon@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 <joe@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.melnikov@isode.com>
> > wrote:
> >
> >>
> >> > On 12 Jan 2016, at 21:31, Ilari Liusvaara <ilariliusvaara@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 <simon@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
>
>