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
​