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. -- 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
