- From: Harry Halpin <hhalpin@w3.org>
- Date: Mon, 11 Aug 2014 17:23:07 +0200
- To: Mike Jones <Michael.Jones@microsoft.com>, GALINDO Virginie <Virginie.Galindo@gemalto.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- CC: "webcrypto@trevp.net" <webcrypto@trevp.net>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/11/2014 05:12 PM, Mike Jones wrote: > I vehemently disagree with the “potentially removing NIST curves” > possibility. These are standards and are used in practice in many > application areas. We need to leave them in (as well as provide > extension points so other algorithms can also be used with > WebCrypto as they are developed). > I don't think anyone is discussing removing non-NIST curves, so Greg dropped that proposal in the Bugzilla. To re-state the proposals said by Virginie with NUMS curves in terms of W3C process: 1) NUMs curves a separate extension spec 2) Integrate NUMS into main spec, but drop at CR if it's not implemented. 3) Integrate [Result of CFRG/TLS discussion] non-NIST curve into main spec, but drop at CR if it's not implemented. cheers, harry > I don’t have a problem with extension specs being written for > either NUMS or 25519. In fact, it would be good to have these > written before we’re done, as they will test parts of our extension > mechanisms in the main spec. > > -- Mike > > From: GALINDO Virginie [mailto:Virginie.Galindo@gemalto.com] Sent: > Monday, August 11, 2014 3:02 AM To: public-webcrypto@w3.org Cc: > Harry Halpin; webcrypto@trevp.net Subject: [W3C Web Crypto WG] > status on bug 25618 related to NUMS/25519 curves and proposed way > forward > > 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<mailto: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] Sent: Monday, August 4, > 2014 3:02 PM To: GALINDO Virginie Cc: > public-webcrypto@w3.org<mailto: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 ---- > > > 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. >>> > > > ________________________________ 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) iQIcBAEBAgAGBQJT6N/bAAoJEPgwUoSfMzqclosQAKb64rj1PQ29DEnyG+fSjhGE FeuowRyU5LnGpdFTVj8PMDEaoaX7TxIGpf41FWJ8ob+3fGck3FqC5O6Sox2ij7/J cWXaQzNZ3WPfNZoBllZzudhYwv41XutIFirxKm5FQ5uSqt7pex0P9QYYPN+zVRpk xDqaQc0gtTxKH354U7SIzWsgVN1OL+dUUXWUm4j4Oc6iivmEVpcry1W/Wh+drR4V Oc+pbLVq87Sp7P3oNNKA6imXxIigX/rcDljztZjUzDD6luoBWQovPugjW31yOl6r e1HvN3tryISlsz1bMApqSrZ3ZnA2ZogcZjEhHzQl/ofCM51AglnTeJSyyVdzJC3z Aq4Yo/KGX9T/ZQtOFAj+vj0FZJjhwwG72/0cZUPbpZ2WdIFdWJcN0aGZM/mZzFnl K2onG5WJmbLjgq3g+/4+TBMBqkFvxNzWh+BWmg01DykxjJfv1dnwu7DDmwQxNlfI 6uk7sUvO+SG16wLkwSnLl2o0RAdZ8h5JFEIl5XupGbhj0WFxmT+C+mPS4v8k3yjP K/tRPZlrmIKV+/ceB1sXRxT2nBDizEvZxq8zVqabXTlNV8bais4XnqHuQvs12dq0 4aQpKp81R5+VkKEuQiQVDG05pVJtOFryXtIOFrpDK7OCkvBaJ0fjRKsEbAmUxrrX X6TxgjmsgEFJLh0rqfwX =W30N -----END PGP SIGNATURE-----
Received on Monday, 11 August 2014 15:23:21 UTC