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

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