On Tuesday 14 July 2015 17:23:44 Simon Josefsson wrote:
> Hubert Kario <hka...@redhat.com> writes:
> > On Sunday 12 July 2015 16:39:37 Simon Josefsson wrote:
> >> Hubert Kario <hka...@redhat.com> writes:
> >> > As is described in secion 5.1. of RFC 4492, and then reiterated in
> >> > section 2.2. of this draft - the elliptic_curves (a.k.a.
> >> > supported_groups)
> >> > guides both the ECDH curves and curves understandable by peer for ECDSA
> >> > signatures.
> >> >
> >> > As Curve25519 and Curve448 can only be used for ECDHE, maybe they
> >> > should
> >> > be
> >> >
> >> > defined/named in the registry as such, to remove any ambiguity[1]:
> >> > enum {
> >> >
> >> > Curve25519_ecdh(TBD1),
> >> > Curve448_ecdh(TBD2),
> >> >
> >> > } NamedCurve;
> >>
> >> I don't care strongly. One disadvantage with this is that if we decide
> >> to reuse these NamedCurve allocations to have something to do with
> >> Ed25519, the naming above will be confusing. However, I believe it is
> >> already likely that Ed25519 will have its own NamedCurve.
> >
> > Given that there certainly will be implementations that support ecdh
> > and not the signatures, we certainly *don't* want to reuse this
> > codepoint for anything else.
> >
> > So unless the PKIX and TLS parts are defined at the same time, in the same
> > document, we definitely need to keep them apart.
>
> It is conceivable to reuse the NamedCurve values for TLS authentication
> without affecting the ECHDE use, nor delaying the Curve25519 ECDHE work.
>
> Compare how we "reuse" the ECDHE ciphersuite values to refer to
> Curve25519 (instead of defining new ciphersuites for Curve25519), and
> how we are "reusing" the "uncompressed" code point to refer to
> Curve25519-compressed code points (instead of defining new
> ECPointFormat).the point is, that if Ed25519 for signatures is defined, an implementation that doesn't understand it[1] can't advertise that fact 1 - be it because it wasn't updated yet, or because the programmers don't consider it important enough yet - that doesn't matter -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
