W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > January 2013

Re: ECC Curves

From: Harry Halpin <hhalpin@w3.org>
Date: Thu, 31 Jan 2013 11:22:11 +0100
Message-ID: <510A45D3.5070004@w3.org>
To: Ryan Sleevi <sleevi@google.com>
CC: Richard Barnes <rbarnes@bbn.com>, Björn Kinscher <bjoern.kinscher@googlemail.com>, public-webcrypto-comments@w3.org
On 01/29/2013 09:43 PM, Ryan Sleevi wrote:
> On Tue, Jan 29, 2013 at 6:00 AM, Richard Barnes <rbarnes@bbn.com> wrote:
>> Hi Björn,
>>
>> Thanks for your comments on this.
>>
>> Unfortunately, I don't think allowing apps to specify curve parameters necessarily gets you what you want, unless implementations are required by the specification to accept and use any set of parameters.  Otherwise, an implementation can say, "These parameters are legal in the syntax, but I will not use them", in which case you're back where you started.
> Considering that RFC 5480 explicitly discourages (MUST NOT) using
> arbitrary curve for the ECParameters, which are explicitly supported
> by X9.62's ASN.1 production, I think it's sufficient to say that "this
> is a mess" and it's a bad mode to start with.
>
>> That requirement would be pretty onerous on implementors, for exactly the reason you state.  Namely, browsers get their crypto from underlying crypto libraries, so if the underlying libraries don't support custom curves, then the browser would have to re-implement basically the entire EC computation stack.
> Which I don't see happening for any value of sane, least of all for
> the very same regulatory/legal frameworks that strongly favour a lack
> of MTI.
>
>> I think a safer route would be to have a registry for named curves (or re-use one, z.B., [1][2]) with a fairly liberal policy for how curves are admitted.  That would at least give crypto library implementors a consolidated, finite list of curves to support if they want their library to be useful for the web.
> In theory yes, in practice, no, but this is the registry discussion
> all over again, so I'll save that for the original and ongoing thread.

Just to clarify, if Germany or another nation wants a non-standard ECC 
curvie, then it makes sense for them to write it down, mature it, 
ideally produce code-patches for the Web browsers, and register it 
whatever registry we end up using (IANA has come up) that will live past 
the lifetime of the spec. There will be some extensibility mechanism for 
new crypto built into the spec.

The key is likely to get that extensibility at the right level. I expect 
a registry is the right way rather than building custom ECC curves into 
spec itself.Thus, you'd have to register your curve with the registry.  
Does that satisfy your use-case Bjorn?
>
>> Cheers,
>> --Richard
>>
>> [1] http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-8
>> [2] http://tools.ietf.org/html/rfc4492
>>
>>
>>
>>
>> On Jan 29, 2013, at 5:07 AM, Björn Kinscher <bjoern.kinscher@googlemail.com> wrote:
>>
>>> Hi,
>>>
>>> I attended the talk of Harry Halpin at the 29c3, where I heard that
>>> there is still a lot of ongoing work on the webcrypto api. I would
>>> like to know if it is considered to give api users the possibility of
>>> defining their own curves for ECDSA and ECDH.
>>> Last year I worked with the new german identity card. It uses recently
>>> defined curves, which are not available in any classic encryption
>>> libraries. Thus I think it is necessary to enable api users to define
>>> their own curves to ensure compatibility with other applications.
>>> I do not want api users to create their own curves, but that they are
>>> able to use recently approved ones without waiting for user agent
>>> vendors to implement them. I know there is a risk of users creating
>>> weak ones, but I still think the possibility to define new curves
>>> would be very useful. Especially since a user agent can't include all
>>> possible useful curves.
>>>
>>> My suggestion is to extend EcKeyGenParams with something like the
>>> following to give api users the possibility to define their custom
>>> curves:
>>>
>>> typedef (namedCurve or customCurve) CurveIdentifier;
>>>
>>> dictionary customCurve {
>>>   // prime number
>>>   BigInteger prime;
>>>   // a and b are definded by the equatation y^2 = x^3 + a*x + b
>>>   BigInteger a;
>>>   BigInteger b;
>>>   // generator of the group
>>>   ECPoint generator;
>>>   // order of the group
>>>   BigInteger order;
>>>   // index of the sub-group
>>>   BigInteger cofactor;
>>> }
>>>
>>> dictionary EcKeyGenParams : AlgorithmParameters {
>>>   // A named or a custom curve
>>>   CurveIdentifier curve;
>>> };
>>>
>>> Another option would be to add an interface to register new named
>>> curves with these parameters.
>>>
>>> Regards
>>> Björn Kinscher
>>>
>>>
>>
Received on Thursday, 31 January 2013 10:22:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 31 January 2013 10:22:24 GMT