RE: [W3C Web Crypto WG] about extensions to Web Crypto specification

As I’ve already written, I *did* speak to Brian yesterday and he’s also against removing the NIST EC support.  I know of no one at Microsoft who would support removing it, as doing so would needlessly make the spec less useful.

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Thursday, August 28, 2014 9:37 AM
To: Mike Jones
Cc: GALINDO Virginie; Mark Watson; public-webcrypto@w3.org; Harry Halpin
Subject: RE: [W3C Web Crypto WG] about extensions to Web Crypto specification


On Aug 28, 2014 9:33 AM, "Mike Jones" <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:
>
> I strongly disagree.  There’s no reason to pull our existing EC support, because it’s already well-defined and useful.  Keeping it needn’t hold up approval of the spec in any way (which I believe is what Mark is worried about).
>

Mike,

It absolutely has and does continue to hold up the spec, as demonstrated by your colleagues objections over publishing anything without something either unspecified (a placeholder) or inappropriate (NUMS).

Again, I strongly encourage you and your colleagues to work together to jointly figure out your position, because this WG is continuining to receive different messages that make it unclear what represents personal opinion and what represents the opinion of Microsoft as a member.

>
>
> As we decide to add new algorithms, we can use extension points to do so.  We need to get those right regardless of what algorithms we include now.
>
>
>
> All of that is separate from a decision on whether we want to *also* add additional algorithms before approval (which is what I hear Mark primarily speaking against).  That’s a point that people of good intent have shown disagreement about, and probably should be the actual focus of discussion and possibly a consensus call.
>
>
>
>                                                             -- Mike
>
>
>
> From: Mark Watson [mailto:watsonm@netflix.com<mailto:watsonm@netflix.com>]
> Sent: Thursday, August 28, 2014 9:22 AM
> To: Harry Halpin
> Cc: Ryan Sleevi; GALINDO Virginie; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
>
> Subject: Re: [W3C Web Crypto WG] about extensions to Web Crypto specification
>
>
>>
>>
>> >>
>> >
>>
>> > I think we need a clear proposal for how to deal with our existing
>> > (three) NIST curves, the NUMS curves, and a way that is consistent
>> > with curves we've had others ask for (the SECG koblitz curves, as
>> > used by Bitcoin) or related (such as Brainpool).
>>
>> +1
>>
>> >
>> > Of course, it seems that the zeitgeist of at least Harry and Brian,
>> > and perhaps I'm misreading, is that we MUST NOT add these curves
>> > unless/until the CFRG blesses them, even though they are defined
>> > curves in real use and real applications.
>>
>> No, we should support generically curves in general. The issue that
>> Brian brought up, and I support, is not MUST NOT add these curves.
>> It's that *if* CFRG does recommend non-NIST curves, we MUST add them
>> eventually.
>>
>> The spec should be as generic as possible to allow extensions of
>> different curve types.
>
>
>
> ​The spec is *already* much more generic than this as it *already* allows addition of arbitrary new algorithms, not just new curve types.
>
>
>
> IIUC, Ryan suggests that he would prefer generic EC and ECDH algorithms to which new curves could be added, provided they are sufficiently similar in the way they are defined. I see this as a "nice-to-have", but not necessary. We could have separate algorithms for similar (e.g. "NIST-like") curves. There would be a lot of duplicate text, but we have not shied away from duplicate text where a generic solution would suffice anywhere else. To specifically answer Ryan's question, yes,
>
> this impl
>
> ​ies that​
>
> we
>
> ​would ​
>
> have EC-NIST, EC-SECG, EC-NUMS, and variants of each for ECDSA & ECDH, even though they all fit within the same encoding space (in terms of SPKI, PKCS#8, and JOSE) and the same operational space (in terms of referenced specifications?)
>
> ​.
>
>
>
> I don't see this as ideal, but it's a possibility. I just want to be clear that we are NOT in a position where the existing specification cannot be extended for new curves - it can.​
>
>
>
> However, as suggested earlier in the week, the desire for extensibility of the existing EC / ECDH algorithms, the desire to include non-NIST curves, the desire to wait for CFRG, the fact that some curves are defined in a very different way from our existing ones and the desire for the specification to progress (all positions held in different combinations by different people) together point very strongly to pulling our EC and ECDH for the moment. That will not delay approval of EC and ECDH, given all of the above. Anything else WILL delay the main specification.
>
>
>
> ...Mark
>
> ​
>
>