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

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).

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
​