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). Allocating new values when that creates additional costs and no improved clarity seems wasteful to me. This approach is what people have suggested for most other allocations here, so I prefer to stick to that philosophy unless it is clear that there is consensus for something else. What do others think? /Simon
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
