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

I think it would be highly useful to see an actual write-up.  That way we’d have something to review and either adopt or tweak.

                                                            -- Mike

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Monday, September 08, 2014 12:15 PM
To: Mark Watson
Cc: Mike Jones; GALINDO Virginie; public-webcrypto@w3.org; Harry Halpin; Wendy Seltzer
Subject: Re: [W3C Web Crypto WG] about extensions to Web Crypto specification



On Mon, Sep 8, 2014 at 9:53 AM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:

​Would people find it useful to see, in our specification, what the approach referenced by Anne [0] for adopt [1] and clone [2]  in DOM would look like ?

I'd be happy to draft the changes for one algorithm (say RSA-AOEP) to enable extensibility in the choice of hash algorithm.

We should bear in mind that this approach allows only for very specific extensions to existing algorithms. For example adding a new hash algorithm to RSA-OAEP. If you want to do something that we don't explicitly provide for, then you need a new algorithm.

One comment to Ryan below...

...Mark

[0] http://annevankesteren.nl/2014/02/monkey-patch

[1] http://dom.spec.whatwg.org/#concept-node-adopt

[2] http://dom.spec.whatwg.org/#concept-node-clone


On Thu, Sep 4, 2014 at 11:46 AM, Ryan Sleevi <sleevi@google.com<mailto:sleevi@google.com>> wrote:
The previous proposed wording was presented as a general "Any other spec can modify anything about this", which is itself the definition of monkey patching.

The concern is that we need to be explicit and judicious in what and how something is extended and how that's reflected to the user, as the named curve discussion has shown at great length.

For example, in the clone example above, it's precisely stated what the inputs are and what the viable outputs are. We would need that same level of precision, at a minimum, at our extension points.


​Actually, those examples precisely state the inputs to the "additional steps" defined by "applicable specifications", but they don't appear to constrain what those additional steps can be - that it, the outputs are not defined.

Sure it does. Read Step 2 and Step 7 of Clone. You get a node back that implements the same interfaces as the source.


In the example of providing for future hash algorithms with RSA-OAEP, we would explicitly defer to "applicable specifications" how the hash algorithm is represented in JWK, say, by referring to "JWK serialization steps" defined by that "applicable specification" to be run when the name attribute of the hash parameter has a value defined by that specification. But we would not need to constrain those "JWK serialization steps" to providing only the "alg" member of the JWK.