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

On Mon, Aug 25, 2014 at 5:25 PM, Mark Watson <watsonm@netflix.com> wrote:

> All,
>
> Based on the lack of response to my questions below, I propose we close
> this issue as a "non-issue". As far as I can tell the specification
> contains all the extensibility that we need in the form of the ability to
> add additional algorithms.
>

And what of SHA-3?


>
> In particular, noone is arguing for extensibility of key formats (and some
> arguments against have been made). Good reasons have also been presented as
> to why additional Elliptic Curves should be added as new algorithms.
>

And what of our existing-named EC curves? How do they or do they not fit in?
And what of the other SEGC curves? How do they or do they not fit in?
And what of normalization, which you've raised concerns with the
HashAlgorithm interface? For example, what are the implications for CONCAT
or HKDF?

My biggest concern is holistic consistency here. In order to achieve that,
we first need consensus on curves, and then we can (and MUST) evaluate
whether the spec is internally consistent with those decisions and provides
clear guidance for those that wish to extend.


>
> ...Mark
>
>
> On Tue, Aug 19, 2014 at 11:44 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>>
>>
>>
>> On Tue, Aug 19, 2014 at 11:00 AM, Ryan Sleevi <sleevi@google.com> wrote:
>>
>>>
>>> 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.
>>>
>> ​Ok. So I am personally fine with requiring new algorithms for new
>> curves, and possibly renaming our existing ECDSA/ECDH to be NIST-specific.​
>>
>>> >
>>> > 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.
>>>
>> ​In what sense ? That we don't yet have consensus ?​
>>
>>
>>>  There is an overall issue of ensuring we  have things be extensible
>>> where they should be - or consistent overall.
>>>
>> ​So, in the interest of actually making progress, what - specifically -
>> do you think we need to look at ? I've looked through the specification and
>> I don't see a need for any other extensibility points.
>>
>> ...Mark​
>>
>>
>>
>>
>>> >
>>> > ...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.
>>> >>>>
>>> >>>
>>> >>
>>> >
>>>
>>
>>
>