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

On Mon, Sep 8, 2014 at 12:14 PM, Ryan Sleevi <sleevi@google.com> wrote:

>
>
> On Mon, Sep 8, 2014 at 9:53 AM, Mark Watson <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> 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.
>

What I meant was that step 7 of this algorithm doesn't constrain what the
"cloning steps" are:

​"7. ​
Run any cloning steps defined for node in other applicable specifications
and pass copy, node, document and the clone children flag if set, as
parameters.
​"​


The cloning steps could be anything that operates on copy, node, document
and the clone children flag. A more restrictive approach would constrain
the cloning steps to be steps that copy things from node to copy, like in
Step 4 (or even more restrictive, instead of "cloning steps" there could be
a list of items to copy that is dependent on the type of node.)

​I'm suggesting we take a similar approach for WebCrypto.

...Mark​




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