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

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.
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:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> >
> > 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.
> > >>>>
> > >>
> > >>
> > >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.11 (GNU/Linux)
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iQIcBAEBAgAGBQJT364FAAoJEPgwUoSfMzqclJQP/jdmamFstA42yZWykBXD85T1
> > g4JGMvBypOdzFwezi67gVjHvqVYLsQNojxwO1tJEqZhMb6LvthQZ4H6itMnA2VyT
> > mdYPLvLNEJp+L8H+ot8tGPhSU+AlgMZiXYkf66RZzeT8L+LKPwI9zdMP+Wv7ub17
> > 86aCmh5Jp7OCIg8sD5P6/Ygif/vRkKMcf+0hapEtNH7iNHkv9/MlE/N/pdIVAPXo
> > gi/JQNi4H7QGHrKE4jjG5lJ/R3BUzKXxX4U1KKonlaTLJ9GDgt1eHtghKAe9KIHv
> > dJtU1XlspYRKZxmHXv2YcVnoAc6y9yAXiY8y0xrtite+QYZqStIIlV6PIpdlTxa9
> > m98LlyNbUjXlTjXixyPJL4f43NFUrSmIaURrQbFOxoYSHLKKArmOFO85cWyPNRgE
> > 873p8+SDrt016g59T077t1fniH12NmzfqLy6/qjDKGDEKfK30kjpZGvptrFBA28b
> > /AXafI5Rz+xwlgCzxK980cFnNAp5BS2PB9UHZY1eFbvbXGhRUdroKuoG+Y9WTybR
> > S71sDxl0EisuRlPfUKWTkKSB15j8N5agQO5ooDm6mC7X/A+pHIp+M1YMs4NF8Nuj
> > PlUm7UDV3yDz6aV5CLBEXccmhB+jQnmmn3z9QLvFfs+o3VmOdR3v6P36lDfYvFSh
> > ltF8Z1EVJ3Nuu/lgCiIi
> > =0n1c
> > -----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.
>