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

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