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

Hi all,

Any reaction to that proposal ? Silent means consent, at this stage.
Reminder : we will exit Last Call Monday 29th of Sept. And this one is the last outstanding bug open…

Regards,
Virginie

From: Mark Watson [mailto:watsonm@netflix.com]
Sent: jeudi 11 septembre 2014 19:18
To: Mike Jones
Cc: Ryan Sleevi; GALINDO Virginie; public-webcrypto@w3.org; Harry Halpin; Wendy Seltzer
Subject: Re: [W3C Web Crypto WG] about extensions to Web Crypto specification

All,

So, by way of an example and to move the discussion forward I have implemented extensibility for RSA-OAEP hash algorithms in the Editor's Draft. Obviously we need to agree a common approach for all algorithms, so this text is subject to change.

As it happens, the encrypt, decrypt and generate key procedures are already independent of the hash algorithm. In Generate it just copies the name (in particular, generate key does not fail if the hash algorithm is unsupported, though we might want to reconsider that). For encrypt and decrypt, the RFC3447 procedures referenced are not hash-algorithm-specific.

So we are left with import and export. We could take an approach where an extension specification must define procedures which map OIDs to hash algorithm names, hash algorithm names to OIDs, JWK alg values to hash algorithm names and hash algorithm names to JWK alg values i.e. there would be four procedures in the extension specification which we might call "OID to hash algorithm mapping steps" etc.

However, this is a limited form of extensibility, in that it assumes that any future hash algorithm is fully specified only by its name. One can imagine parameterized hash algorithms, like { name: "sha-next+1", params: { iterations: 200 } } and the limited extensibility above would not support that.

What I have implemented is more general (and also simpler to implement in the specification). Extension specifications are free to define their own import / export process and only if the extension specification steps return "NotSupportedError", or if there are no applicable specifications, do we follow the procedures of our specification.

Comments welcome!

...Mark

On Wed, Sep 10, 2014 at 3:53 PM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:
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<mailto:sleevi@google.com>]
Sent: Monday, September 08, 2014 12:15 PM
To: Mark Watson
Cc: Mike Jones; GALINDO Virginie; public-webcrypto@w3.org<mailto: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.



________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.