[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 #27 from Mark Watson <watsonm@netflix.com> ---
(In reply to Harry Halpin from comment #26)
> Just to be clear, "extension point" means that other specifications *which
> normatively reference the base specification* and *which are not explicitly
> referenced in the base specification itself* can use the operations of the
> base specifications with new algorithms that are not listed in the base
> specification. We have, for example, the Editor's Draft of Curve 25519 from
> Trevor Perrin. 

This was my understanding and apparently the intention of this bug (see
comment#0). But as so often with WebCrypto, the goalposts have changed at the
very last minute: We have Google and Mozilla arguing that the extension
specifications must be referenced from the base (please Ryan and Anne correct
me if I am wrong there).

> 
> I do not see any clear arguments against this and it's a pretty reasonable
> request give the state of crypto right now. 

The argument, IIUC, is that implementors should have a single starting point
from which they can determine what to implement.

> 
> I don't see any normative or informative references to "as yet to written
> specifications" (caveat being that we already have an extension spec for
> Curve 25519), rather than just making sure that the spec as written does not
> hardcode anything that makes it impossible or difficult to extend. 

The Editor's Draft refers to "other specifications", without constraining what
those specifications may be (in common with the 'clone' procedures on which I
based the text). This is what Ryan calls a 'forward reference', like declaring
a class without defining it. What's being asked for now is that we constrain
the 'other specifications' to those referenced from the base specification.

> 
> If folks don't want to implement Cuve25519 or other algorithms, they can
> just not implement them (including anything outside the base specification)
> and this will be recorded in the test suite for the base specification or
> any other future specification like the Curve25519 spec. 
> 
> I do not see how Mark's edits cause more work for implementers and, given
> they provide at least a first try at the needed extensibility points, I do
> not see why they should be removed. "Not liking something" is not a
> sufficient reason I think.

Ryan objects to the fact that my proposal allows extension specifications to
override import / export procedures for existing algorithm / hash combinations.
However, constraining them is quite involved, text-wise. I don't see this is a
problem since whether extension specifications do override those things is
still up to the WebCrypto WG alone.

Anyway, to make progress, and since it seems we have to update the base
specification anyway for all extensions, I suggest we add the extension points
when we need them, instead of now.

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

Received on Wednesday, 8 October 2014 15:39:43 UTC