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

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

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

Received on Monday, 4 August 2014 16:00:19 UTC