Re: [Cfrg] revised requirements for new curves

On Mon, Sep 8, 2014 at 7:30 AM, Manuel Pégourié-Gonnard <mpg@elzevir.fr> wrote:
> On 08/09/2014 15:49, William Whyte wrote:
>> IN1: I don't understand how a curve could be incompatible with a TLS RFC. A
>> new curve would be a new ciphersuite: to support a new curve, you reserve a
>> ciphersuite identifier and define behavior for that ciphersuite identifier.
>
> I guess you mean a NamedCurve identifier (RFC 4492 sec. 5.1.1) rather than a
> ciphersuite identifier. Currently, ciphersuites only specify the high-level
> mechanism (ECDH(E), ECDSA), not the specific curve(s) used by this mechanism.
> (There is a draft for including curve selection in the ciphersuite identifier,
> but for now it's only a draft). And possibly some new ECPointFormat (sec 5.1.2)
> in addition, if the new curves support other representations than short
> Weierstrass, and the decision is made to allow those representations on the wire
> (rather than to force conversion to short Weierstrass).
>
> By the way, the TLS curve/point negotiation doesn't allow peers to negotiate the
> use of different point formats for different curves. That's probably something
> to bear in mind when discussing point formats.

I think that is more wrong than right. Currently all curves are short
Weierstrass. If we say "curveXYZ means you do this instead, and adjust
the point formats accordingly", is that really a problem? Certainly
the Curve25519 in TLS draft didn't think so.

Sincerely,
Watson Ladd

>
> Manuel.
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin