- From: Richard Barnes <rlb@ipv.sx>
- Date: Mon, 11 Aug 2014 12:34:48 -0400
- To: GALINDO Virginie <Virginie.Galindo@gemalto.com>
- Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>, Harry Halpin <hhalpin@w3.org>, "webcrypto@trevp.net" <webcrypto@trevp.net>
- Message-ID: <CAL02cgTZ09DeBqgpijWurEE=_5YMTWqJqOTvgYnpMC06uC3wAA@mail.gmail.com>
For both my preference would be (1), but I would be OK with (2). That is, I would be OK with the WG taking on a deliverable to support whatever curve(s) CFRG and TLS agree on, and with Brian and Trevor working to get their proposals in shape while that debate is going on. --Richard On Mon, Aug 11, 2014 at 6:01 AM, GALINDO Virginie < Virginie.Galindo@gemalto.com> wrote: > Dear all, > > > > A status on the bug 259839 related to integration of NUMS and 25519 curves > in our deliverables : https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839 > > > > There were some discussions about the possible options to move forward to > integrate the new curves (see below). > > Here is again the possible options for each of the curves. Note that by > extension, we mean here a specification, which has its own Recommendation > Track and that will be following the W3C Recommendation process. > > > > · Dealing with NUMS curves > > Algorithm description is attached to > http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0041.html , > editor Brian LaMacchia. > > Note : that contribution was submitted on time to be considered by the WG > as included in our deliverable [1]. > > Option 1 : integration of NUMS curve as an extension to the Web Crypto API > specification, based on what was proposed by Brian LaMacchia (potentially > removing NIST curves) > > Option 2 : agreement as a principle to integrate the NUMS curves into the > WG deliverables, but expect Candidate Recommendation to make decision to > integrate the algorithm in the main spec or as an extension, final set of > algorithm would align with IETF/CFRG recommendations for TLS deployment > > Option 3 : integration of NUMS Non-NIST curves in the main spec as a > feature at risk and remove it at Candidate Recommendation, if it happens > that no interoperable implementation is demonstrated. > > > > > > · Dealing with Curve25519 > > Algorithm description > http://htmlpreview.github.io/?https://github.com/trevp/curve25519_webcrypto/blob/master/Curve25519_WebCrypto.html, > editor Trevor. > > Note : that contribution was submitted lately to the WG. > > Option 1 : integration of curve 25519 as an extension to the Web Crypto > API specification based on what was proposed by Trevor Perrin > > Option 2 : agreement as a principle to integrate the curve25519 curves > into the WG deliverables, but expect Candidate Recommendation to make > decision to integrate the algorithm in the main spec or as an extension, > taking into account IETF/CFRG recommendations for TLS deployment > > Option 2 : integration of curve25519 in the main spec as a feature at > risk, and remove it at Candidate Recommendation, if it happens hat no > interoperable implementation is demonstrated. > > > > I have the feeling that the WG consensus would be to go for **NUMS curve > option 1** and **Curve 25519 option 1**, based on feedback I heard (see > below). > > Anyone unhappy with that possible way to move forward ? > > Anyone having another idea ? > > (again a formal call for consensus will be made this week, but I am trying > to test options acceptance, and alternatives). > > > > Regards, > > Virginie > > > > [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839#c39 > > > > > > > > *From:* Brian LaMacchia [mailto:bal@microsoft.com] > *Sent:* mardi 5 août 2014 04:16 > *To:* Richard Barnes; 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 > > > > 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 <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> 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> 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> 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> > >>>>> 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. > > > ------------------------------ > 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. >
Received on Monday, 11 August 2014 16:35:16 UTC