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

Thanks for the clarification.  Regardless of where we stand process-wise at
this point, my preference would be to hold non-NIST curves for an
extension, to let the TLS/CFRG discussion play out.


On Mon, Aug 4, 2014 at 10:16 PM, Brian LaMacchia <bal@microsoft.com> wrote:

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