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

Note that it would take a few days to replicate this approach across the
other parameterizable algorithms. I suggest we set a deadline and in the
absence of constructive comments or concrete alternatives we go ahead with
this approach.

... Mark

Sent from my iPhone

On Sep 16, 2014, at 6:48 AM, GALINDO Virginie <Virginie.Galindo@gemalto.com>
wrote:

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






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