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

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