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

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

> Hi Brian,
>
>
> On Mon, Aug 25, 2014 at 5:33 PM, Brian LaMacchia <bal@microsoft.com>
> wrote:
>
>>  I strongly object to this resolution.  Contrary to the statements below
>> I have seen no good reasons on the list for why adding new elliptic curves
>> for use with ECDSA and ECDH should be treated as new algorithms instead of
>> as new parameters for existing algorithms (which is what they are). Reading
>> the minutes of the “informal call” with Trevor adds no clarity either.
>>
>
> ​I confess to not being fully conversant with the technical details. but I
> understood that at least some curves that have been proposed were not
> defined in a way that makes it easy to fit them into the structure that we
> already have.
>

Curve25519 does not fit, but the NUMS curves do. Hence the tension.


> So, we might more simply rename the existing algorithms and add new curves
> as new algorithms. The primary advantage I see of that is that we do not
> need to delay our specification further with extensive changes to the
> structure of the EC and ECDH sections.
>

We still need to formally resolve this, which I'm hoping consensus will be
declared soon.


>
> What are the ​disadvantages you see with this approach ?
>
> ...Mark
>
>
>
>>
>>
>> --bal
>>
>>
>>
>> *From:* Mark Watson [mailto:watsonm@netflix.com]
>> *Sent:* Monday, August 25, 2014 5:26 PM
>> *To:* Ryan Sleevi
>> *Cc:* GALINDO Virginie; public-webcrypto@w3.org
>>
>> *Subject:* Re: [W3C Web Crypto WG] about extensions to Web Crypto
>> specification
>>
>>
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> ...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.
>> >>>>
>> >>>
>> >>
>> >
>>
>>
>>
>>
>>
>
>