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

On Aug 28, 2014 9:33 AM, "Mike Jones" <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]
> Sent: Thursday, August 28, 2014 9:22 AM
> To: Harry Halpin
> Cc: Ryan Sleevi; GALINDO Virginie; 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
>
> ​
>
>