RE: W3C Web Crypto WG - about the NUMS/25519 curves integration in Web Crypto API

No, your point (b) below is not quite correct.  Since no Curve25519 proposal was received by the deadline set by Virginie, Curve25519 is off the table for consideration for the main spec and would have to be presented in an extension spec.  However, the WG has not yet made a decision about whether the NUMS curves would go into the main spec or an extension spec – that’s been pushed out to the next call (along with other issues).

                                                                                --bal

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Monday, August 4, 2014 3:02 PM
To: GALINDO Virginie
Cc: public-webcrypto@w3.org; Harry Halpin
Subject: Re: W3C Web Crypto WG - about the NUMS/25519 curves integration in Web Crypto API

I'm still catching up on the thread, but I think I'm generally on the same page as Ryan here.

I thought that we came out of our last call with pretty clear agreement that (a) the base spec needs to have sufficient extension points to support whatever comes out of IETF/CFRG, and (b) any WebCrypto support for new curves would be implemented using those extension points, *not* in the main spec.

As to all this worry that TLS/CFRG will not come to resolution, I estimate that probability to be quite small.  There is good momentum for *some* decision to be made there.  So I would oppose any complications to W3C process to hedge against that.

--Richard



On Mon, Aug 4, 2014 at 4:25 PM, GALINDO Virginie <Virginie.Galindo@gemalto.com<mailto:Virginie.Galindo@gemalto.com>> wrote:
Any other opinion from WG participants ?
Virginie

---- Harry Halpin a écrit ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 08/04/2014 09:44 PM, Ryan Sleevi wrote:
> Will happily endorse Option 1 (separate spec), but would object to
> Harry's option / any options that promote Feature at Risk / main
> spec inclusion.
>
> I don't feel there has been significant review from the
> cryptographic community or from implementors to make any reasonable
> assessments about NUMS, either in implementation or in API surface,
> thus would not want to include on the main track. I think features
> at risk are a copout that tries to kick decision making down the
> curb until inertia wins, and do a disservice to everyone. We should
> not be throwing everything into a spec with the label "At Risk"at
> this point - that is, at best, poor leadership from the W3C, and at
> worst, detrimental towards security and the viability of the spec.
> The only reason this was done with respect to the algorithms
> selected was due to the incredibly limited feedback from the WG,
> particularly UAs, on the shape of the API, and thus was necessary
> to reverse engineer the shape, as it were.

Note again it's that it's not letting inertia win. It's letting the
CFRG and TLS WG decide, and then a proposal that we include that TBD
non-NIST curve in the main spec.

As noted by BAL and Wendy, these groups have a schedule and lots of
active discussion. Since their schedule may slip, we should have a
final deadline for ourselves. That deadline I specified was out was
our exit from CR.

I think we all understand that you do not want a non-NIST ECC curve in
the spec. However, there seems to be a vocal group of developers and
at least one browser vendor that does want this, so we need to reach
some sort of consensus to resolve their concerns and exit Last Call,
while recognizing the validity of your concerns about whether or not
any non-ECC curve is specified well enough to be widely implemented. I
believe the CFRG and TLS WG could make that decision.

> On Aug 4, 2014 12:31 PM, "GALINDO Virginie"
> <Virginie.Galindo@gemalto.com<mailto:Virginie.Galindo@gemalto.com>> wrote:
>
>> Harry,
>>
>> Thanks for reminder about non-NIST curves mentionned by Brian. I
>> understand that your proposal is a new option.
>>
>> Lets call it OPTION 3 : we can decide to integrate Non-NIST
>> curves ( because we bet on their attractivity for IETF) in the
>> main specification,  with a mention 'feature at risk', and we
>> drop it if it happens that there is no implementation nor
>> requirement from IETF.
>>
>> To all, What I am trying to get is a direction where the WG want
>> to go. I dont want to enter into the details of the way the
>> option 1 or 2 or 3 will be implemented. So please state your
>> favorite option, the one you could live with, the one you would
>> object to. This is an informal vote, take it as a mean to prepare
>> consensus...
>>
>> Virginie
>>
>>
>> Copying other options as a reminder OPTION 1 : - We can decide to
>> have an extension for NUMS and already have an editor for it - We
>> can decide to have an extension for curves 25519 and have a
>> potential draft with an editor coming on 10th of august - We can
>> decide to have that/those extension(s) mandatory in the future
>> browser profile Or OPTION 2 : - We can decide ‘not to choose
>> between extension and main spec’ but decide on the principle to
>> develop the NUMS/curve 25519 descriptions and put it into the
>> spec once it is tested and proven it is available
>>
>>
>> ---- Ryan Sleevi a écrit ----
>>
>>
>>
>> On Aug 4, 2014 9:00 AM, "Harry Halpin" <hhalpin@w3.org<mailto:hhalpin@w3.org>> wrote:
>>>
>
>
> On 08/04/2014 05:52 PM, Ryan Sleevi wrote:
>>>>> Harry,
>>>>>
>>>>> Is this an official endorsement of a third proposal? It
>>>>> seemed that for the entirity of discussion, it has
>>>>> specifically been two proposals, precisely so that we could
>>>>> avoid your third proposal.
>
> This is an argument for Virginie's third proposal and a way to
> operationalize it.
>
> "We can decide ‘not to choose between extension and main spec’ but
> decide on the principle to develop the NUMS/curve 25519
> descriptions and put it into the spec once it is tested and
> proven"
>
> It seemed to reflect the sentiment in the last telecon that while
> BAL has provided text for NUMS and Trevor has promised 25519 text,
> deciding now might be a bad idea as though it was pretty clear that
> at least one non-NIST curve would be recommended by TLS/CFRG
> eventually, it was unclear about the timeline or which precise
> curve.
>
> Again, it's easy to add "features at risk" and take them out
> sensibly if the decision by TLS/CFRG never resolves. It seems as if
> it does resolve, it would be a good idea to keep open the
> possibility of adding that TBD non-NIST curve in the spec without
> going back to Last Call.
>>>
>>> OK. I don't think this proposal is practical nor realistic, in
>>> as much as it fails to address the issues, and presumes a
>>> non-trivial amount of editing work at some later point that
>>> will meaningfully alter the spec in surprising ways, but sure,
>>> at least it's out there.
>>>
>
> I've added suggestions on the monkey-patching bug to
> operationalize how we can deal with extension specs formally in the
> spec.
>
> cheers, harry
>
>
>
>>>>> On Aug 4, 2014 7:14 AM, "Harry Halpin" <hhalpin@w3.org<mailto:hhalpin@w3.org>>
>>>>> wrote:
>>>>>
>>>>> The problem, as BAL pointed on the call, is that we do
>>>>> *not* have resolution on a single curve from TLS or CFRG.
>>>>> It is unclear when those decisions will be made, although a
>>>>> decision is likely I would say before we exist CR. However,
>>>>> chosing between NUMS and 25519 may be premature
>>>>> optimization at this point. Nonetheless, as BAL noted on
>>>>> the call and was backed up on the Bugzilla, there is a real
>>>>> demand for non-NIST ECC curve support in Web Crypto.
>>>>>
>>>>> In general, in W3C process it is *more* difficult to add
>>>>> features than to subtract them when going into CR. Thus,
>>>>> the "feature at risk" mechanism.
>>>>>
>>>>> So, I'd like to add another proposal.  I suggest that we
>>>>> simply add a "feature at risk", using a modification of
>>>>> BAL's edits, for a "TBD non-NIST" curve in the main spec.
>>>>> This TBD curve, if not resolved and supported by CFRG/TLS
>>>>> by the time we exit from CR, is then to be removed from the
>>>>> main spec. If it is later resolved after we have exited CR,
>>>>> then we propose to add these curves using the standard
>>>>> extension mechanism.
>>>>>
>>>>> cheers, harry
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 08/04/2014 03:40 PM, GALINDO Virginie wrote:
>>>>>>>> Hello Web Crypto participants,
>>>>>>>>
>>>>>>>> Following our call last week [1], I have listed the
>>>>>>>> different ideas/directions that were raised about the
>>>>>>>> way to proceed on the integration of NUMS and 25519
>>>>>>>> curves, as discussed in bug
>>>>>>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839

>>>>>>>>
>>>>>>>> ** Two possible options to handle NUMS and 25519
>>>>>>>> curves integration OPTION 1 : - We can decide to have
>>>>>>>> an extension for NUMS and already have an editor for
>>>>>>>> it - We can decide to have an extension for curves
>>>>>>>> 25519 and have a potential draft with an editor
>>>>>>>> coming on 10th of august - We can decide to have
>>>>>>>> that/those extension(s) mandatory in the future
>>>>>>>> browser profile Or OPTION 2 : - We can decide ‘not to
>>>>>>>> choose between extension and main spec’ but decide on
>>>>>>>> the principle to develop the NUMS/curve 25519
>>>>>>>> descriptions and put it into the spec once it is
>>>>>>>> tested and proven it is available
>>>>>>>>
>>>>>>>> ** Other requirements : - We have to stay
>>>>>>>> synchronized with IETF/CFRG - TLS requirements, which
>>>>>>>> may require new algorithms → this is in favor of
>>>>>>>> delaying the decision, expecting IETF decision -
>>>>>>>> Learning loop : We have to decide how to make our
>>>>>>>> spec extensible → this is favor to make early choice
>>>>>>>> and beta test extension addition
>>>>>>>>
>>>>>>>> I would like to have your views on the preferred path
>>>>>>>> to progress, option 1 or option 2. If you have
>>>>>>>> another option, feel free to suggest.
>>>>>>>>
>>>>>>>> Note that we have a call scheduled next Monday 11th
>>>>>>>> of August to discuss that question, but early opinion
>>>>>>>> are helping to make calls efficient.
>>>>>>>>
>>>>>>>> Regards, Virginie Chair of the web crypto WG
>>>>>>>>
>>>>>>>>
>>>>>>>> [1]
>>>>>>>>
>>> http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0144.html

>>>>>>>>
>>>>>>>>
>>>>>>>>
>
>>>
(please ignore statement below)
>>>>>>>>
>>>>>>>> ________________________________ 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.
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>> ------------------------------ 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.
>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


iQIcBAEBAgAGBQJT3+WRAAoJEPgwUoSfMzqcFDYP/RIelB1EOPTNKdtdanNZoWHU
bFCqa+78zVxlxIip/6T9jhdT62LRzAWFxzojjEng2FdCHbdPTGsyeVIdN4N8VHbS
MopwEYHUiGjzD4VKcd6ob9OEd+Pyp0Uzl6PwJXlUysnbsCrJkHd7OKTebBIcFppL
/6cXm9ViILc1Zx1lfnDJ0NotlKeV+KaLxSG8DMKVIwpCObVA4hXqceG7d/5KJZ89
SlSdH+GgTZDUwj5UAnSAmpE2A0cIoQpu9B2FCLCTYXjx4TLmfk7InX08MNIXlDbP
4wBaQe5WxersnAClXzU9vmNy4ipABNH+rQPo+l8nvymOWNO6g/pY9fTbRjRpjDNF
V/5gZQwBV1VNCtGiT+1rMXsRdIE7Rxo2xu0e3lDz0JjrZul0WXKXQZpzkvASH8+c
ZNF4Mb1Y58TU+cP/Ia9FBgX+LiBkDQ+S3jaCZtyDFR20AwYMw/Kq0WWI3OZWrkZo
sqgs69uvr6HACzbjdZNAvb2/KAejHlOI3f5Hi/eP2fipOFs4PQboyBIF6jr6KC1R
h65r5gbqt9sRt1MComODq9/qak1wk2djBfN8d6tttLZ2G17smaQldt6Ho69DleRy
w/Jdbbyw0TYhbXK023WcsWTOlM0/B17Cs+LKVz2U7cP+84dP5z8Dt3zKnT/Sp6Rg
LoRtGyPMzuomn8OG5b2f
=dhOJ
-----END PGP SIGNATURE-----

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