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

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

>
>
>
> On Mon, Aug 25, 2014 at 5:31 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>>
>> 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?
>>
>
> ​The various SHA flavors in the specification are already distinct
> algorithms. I don't see any problem adding more with the algorithm
> extensibility mechanism.​
>

Apologies for not being clearer.

How does SHA-3 work with RSA? With ECDSA? With HKDF? With Concat? With
PBDKF2?

I realize that your answer may very well be "I don't know", because no such
thing exists as SHA-3 yet (beyond Keccak with some undefined set of
parameters and uses).

The point being that we don't know HOW interoperability will work in this
case.


>
>
>>
>>
>>>
>>> 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?
>>
>
> ​I don't see we necessarily need any change to the specification, but I it
> would make sense to rename the existing algorithms to "EC-NIST" or similar.
> But that is a separate issue. ​
>

I think it's inextricably linked with how we treat extensibility.


>
>
>> And what of the other SEGC curves? How do they or do they not fit in?
>>
>
> ​New curves can be added as new algorithms, either in the main
> specification or in extension documents as we decide.
>

And with respect to SECG, and with how both ECDSA and ECDH are currently
specified, this is internally inconsistent. This is an issue that we have
to solve, and that we have not solved.


>
>
>> And what of normalization, which you've raised concerns with the
>> HashAlgorithm interface? For example, what are the implications for CONCAT
>> or HKDF?
>>
>
> ​I made a proposal to solve the problem I raised in the appropriate bug. -
> I'll refresh that.
>
>
>>
>> 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.
>>
>
> ​Sure. A good way to obtain consensus is to have concrete proposals and
> see if anyone objects.
>

I don't really see a "Ignore them", which seems to be the answer, to be a
concrete proposal.


>
> Regarding curves, we need consensus on how new curves should be added to
> the specification, but we do not need consensus on which curves and whether
> they should be in the main specification or separate extension documents,
> which are the more controversial points.
>

And consensus for new curves directly relates to how we handle existing
curves and usages.

Both Curve25519 (which is in wide use, but does not fit ECDSA/ECDH, and to
which Richard objects to because it's not been blessed by the CFRG) and
NUMS (which is in no practical use or review, but which easily fits within
the SECG space and thus ECDSA/ECDH) demonstrate that this remains an open
issue as to how we handle OTHER curves, such as the Koblitz curves.


>
> More guidance on how to extend the specification would be good - I'm happy
> to draft something, though we already have the details of the main
> "supported algorithms" mechanism.
>
> ...Mark
>
>
>
>>
>>
>>>
>>> ...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.
>>>>> >>>>
>>>>> >>>
>>>>> >>
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
>