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