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


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