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

Mike, Ryan,
replies in line [Virginie]

All,
your view would be highly appreciated to prepare our next monday call discussion ....

Regards,
Virginie

________________________________
De : Mike Jones [Michael.Jones@microsoft.com]
Date d'envoi : jeudi 7 août 2014 00:09
À : Ryan Sleevi; GALINDO Virginie
Cc: public-webcrypto@w3.org
Objet : RE: [W3C Web Crypto WG] about extensions to Web Crypto specification

Replies inline…

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Wednesday, August 06, 2014 2:23 PM
To: GALINDO Virginie
Cc: public-webcrypto@w3.org
Subject: Re: [W3C Web Crypto WG] about extensions to Web Crypto specification

On Wed, Aug 6, 2014 at 3:18 AM, GALINDO Virginie <Virginie.Galindo@gemalto.com<mailto:Virginie.Galindo@gemalto.com>> wrote:
Dear all,

We have to find a mechanism for extending our Web Crypto API specification, in order to integrate in the future some new algorithms, or algorithm flavors. This corresponds to the bug 25618 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618 .

Here are ideas and requirements that were mentioned during the conference calls and the bugzilla discussions. Those statements are high level, and are here to try to identify requirements and principles on this extension mechanism. Note that this discussion is not only about adding new curves, but should also be applicable to next generation of algorithm. So lets try to be generic, in a first step.

1 Extension can be used to add new algorithm (or new flavor of algorithm) to the Web Crypto API

Not sure what you mean by "new flavor". Perhaps you can elaborate.

Yes, 1 is a clear goal.  I assume that “new flavor” has to do with adding new sub-parameters to an existing algorithm.  For instance, HMAC SHA-3-256 might be a “new flavor” of HMAC.

[Virginie] yes, flavor means new curve or key length, more generically new set of parameters

2 Extension is a separate document from the main specification, which must contain complete description of the new (flavor of) algorithm (reference, registration, dictionary, operations, and if is it part of 'recommended algorithms' or not)

With the exception of "recommended algorithms", agreed. "recommend algorithms" is not something I see being something that makes it to/through CR/CFI. It's merely a 'footnote' in the absence of profiles, meant to guide/prioritize implementation.

Put differently, if every algorithm (in today's spec) was a separate spec - as it should have been from the start - we wouldn't be discussing recommended algorithms, I don't think.

2 also seems like common sense to me.  Ryan, I think we’d be discussing recommended algorithms no matter how the specs were factored, because for interop reasons, people would want to know what to reasonably expect to be broadly implemented.  (Not that that disagreement effects the gist of 2.)

3 Extension existence requires to have hook in the main Web Crypto API spec to declare new key format (please add any other impact)

Hasn't been an identified use case, but presumably, yes. Although I think any algorithms that required specific formats seems sketchy :)

3 seems like it’s required, at least in the general case.  For this same reason, the JWK “kty” field is extensible using a registry, on a specification-required with expert review basis.

4 Extension can be in a form of a wiki, or a Note or a Recommendation (please state your preferred scenario)

Extensions change the API. They MUST be formal documents entered into the W3C process, same as every other platform API is presumed to go.

I agree with Virginie’s statement that extensions should be able to take any of those forms.  If a wiki is used, it should be administered by designated experts appointed by the working group and the W3C.

I disagree with Ryan’s statement that extensions change the API.  Extensions expand the set of data values, such as algorithm identifiers, that are used with the API.  They do not change the signature of any API methods.  As a concrete example, it should not require an API change to begin using the SHA-3 functions in places where the SHA-2 functions are currently used.  It’s only a change to the input data used with the API.

[Virginie] If we want to go for the IP process, we can not edit Note or Wiki. It will have to be a Recommendation

5 The integration of new (flavor of) algorithm requires to go though W3C IP call for exclusion or not (in that case only the Recommendation scenario would work)

Correct

Some may disagree with this, but I think that the W3C should be open to specs by other organizations defining WebCrypto extensions, just like the IETF is open to other organizations defining JOSE extensions.  The WebCrypto spec does this, and both the W3C and the IETF benefit from this ability.  No chaos ensues. :)

Allowing third-party specs to define extensions, with them being added to the W3C wiki/registry based upon expert review, would be good for crypto agility, good for WebCrypto, and good for the W3C.

6 The new (flavor of) algorithm will requires identifier and short name that need to be registered (in IETF or W3C)

No. A spec is sufficient, much in the same way a spec is sufficient to declare that window.performance implements the PerformanceTiming interface.

I agree that new algorithms will often require registration of new identifiers.  A expertly moderated wiki referenced by the core W3C spec is one way to accomplish this.

Defining the identifiers in specs is necessary but not sufficient.  Registration ensures that implementers and developers can easily find the set of extensions using a particular extension point, including finding the specifications that define them (whether they are W3C documents or documents written by others).


This is a strawman proposal expecting your challenge, criticism and alternatives...
Go !

Regards,
Virginie
________________________________
 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.

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