Re: [W3C Web Crypto WG] status on bug 25618 related to NUMS/25519 curves and proposed way forward

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