[Bug 25618] Extensibility: Offer spec-blessed ways to extend the algorithms and curves, rather than monkey-patching the spec

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618

--- Comment #4 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Mark Watson from comment #2)
> Specifically regarding new eliptic curves, presently, each of the existing
> algorithms is associated with a single definition of the key material on
> which is it based, with serializations of this keying material being
> independent of any other algorithm parameters.
> 
> If we are to add additional curves to the existing EC algorithms, we break
> this pattern. This might involve quite extensive re-working of some aspects
> of the specification.

Mark,

I'm having trouble making sense of this, so I'm hoping you can explain.

> 
> Would it make sense to model different families of Elliptic Curves as
> separate algorithms ? So, the existing algorithms become ECDSA-NIST etc. and
> we can add ECDSA-NUMS in a separate specification ?

For NUMS, no, it certainly doesn't make sense. The point of NUMS is to be
compatible with the NIST (which is really the specification of the SECG, and
plenty of other related bits). Brainpool also fits into this.

There's no technical reason that prevents Curve25519 from not fitting into this
pattern either, other than the proponents of Curve25519 not wanting to go
through the effort. Having Curve25519 fit into this model is something that's
being discussed within the IETF, but the proponents for WebCrypto don't want to
wait on this effort.

Just making sure we're clear as to the limitations or lack thereof.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 28 July 2014 18:55:27 UTC