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

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

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