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

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

No, he was in fact suggesting the existing EC methods should be renamed to
indicate they are NIST/FIPS specific, and the curve names are derived from
those specs.

We've seen the same tension from those wanting support for secp256k1, that
our naming of P256 (inherited from JOSE) is at odds with ECDSA as a
'generic' mechanism.

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

The above are still outstanding. There is an overall issue of ensuring we
have things be extensible where they should be - or consistent overall.

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