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

On Tue, Aug 19, 2014 at 10:47 AM, Ryan Sleevi <> wrote:

> On Tue, Aug 19, 2014 at 10:30 AM, Mark Watson <> wrote:
>> All,
>> I would like to make a concrete proposal for two additional extensibility
>> points to be added to our specification. First, please note that we *already
>> have* the ability to add new algorithms without monkey-patching, so no
>> change to the specification is require for that. The two additions I
>> propose are:
>> (1) Allow for the addition of new key formats
> I do not support this. Unlike algorithms, key formats are integral parts
> of the API (in as much as all formats must be supported). Because of this,
> I would rather see it embodied in the API itself, because it's not really a
> separable part.
>> (2) Allow for the addition of new curves to ECDSA and ECDH, for the case
>> where those curves are described in such a way that they are drop-in
>> replacements for the NIST curves
> I think Trevor makes solid arguments as to why we should NOT do (2), and
> have come around to agreeing.

​Were Trevor's arguments specific to Curve​25519 ? I thought the NUMS
curves could easily added to the existing ECDSA / ECDH algorithms ?

Are there any other extensibility points you think we need, or are we
essentially done with the existing ability to add new algorithms ?


>> [Curves that are not drop-in replacements for the NIST ones would need to
>> be added as new algorithms. I'm aware that the phrase "drop-in replacement"
>> begs a clearer definition].
>> In my opinion these two extensibility points, together with the ability
>> to add new Algorithms, are sufficient. I could be convinced that (1) is not
>> necessary.
>> What do others think ?
>> ...Mark
>> On Wed, Aug 6, 2014 at 3:18 AM, GALINDO Virginie <
>>> 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
>>> .
>>> 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
>>> 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)
>>> 3 Extension existence requires to have hook in the main Web Crypto API
>>> spec to declare new key format (please add any other impact)
>>> 4 Extension can be in a form of a wiki, or a Note or a Recommendation
>>> (please state your preferred scenario)
>>> 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)
>>> 6 The new (flavor of) algorithm will requires identifier and short name
>>> that need to be registered (in IETF or W3C)
>>> 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.

Received on Tuesday, 19 August 2014 17:52:02 UTC