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

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

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