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

On Tue, Aug 19, 2014 at 10:47 AM, Ryan Sleevi <sleevi@google.com> wrote:

>
>
>
> On Tue, Aug 19, 2014 at 10:30 AM, Mark Watson <watsonm@netflix.com> 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 ?

...Mark



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