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 10:08 PM, Ryan Sleevi wrote:
> On Mon, Aug 4, 2014 at 12:57 PM, Harry Halpin <hhalpin@w3.org>
> wrote:
> 
>> 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.
>> 
> 
> This is not true for a second.
> 
> It does the Web community a great disservice to have a variety of 
> algorithms at a variety of maturities included within the spec. The
> spec - and this WG - would benefit greatly from focusing on
> developing and resolving the issues of the current algorithms,
> without being distracted by another algorithm or set of algorithms
> with known maturity issues.
> 
> This has nothing to do with me preferring NIST ECC curves, and
> everything to do with me preferring that we actually focus on
> developing a half-decent spec that can be reasonably implemented,
> rather than needlessly going in circles on adding in everything and
> the kitchen sink, and using the excuse "It's at risk" to avoid
> having to make the real and hard decisions that "perfect is the
> enemy of the good".
> 
> In either event, I cannot support your proposal, because even
> though I would love to see both NUMS and Curve25519 developed and
> mature, it's unquestionably bad for the spec and bad for the web
> development community to encourage such an addition.

Quick question - is that your opinion as an individual or the opinion
of Google as a company? Just noting that AGL and others are using
Curve25519 in the encrypted email Chrome extension [1].

Again, note some web developers want non-ECC curve and a major browser
vendor.  If some browser, such as Chrome, does not want to implement
the recommended non-NIST ECC curve, this will simply be a lack of
support in CR phase by that browser. If there are not two browsers
supporting a feature, then it will removed by the exit of CR. That's
why "features at risk" exist.

Again, we have objections, comments, and a number of non-NIST ECC
curve specifications being developed, both in this WG and in a number
of other WGs in the IETF. Brian has already outlined the needed
changes for inclusion in the main spec of NUMS, and these changes
could easily be adopted to be Curve 25519 or another ECC curve.

I have attempted to clarify both the publication of extension specs
(i.e. was Working Group Notes, indexed by a wiki) and a way to keep a
non-NIST curves in the spec. These are all perfectly operationalizable
edits and the WG should try to get consensus on them. Without
clarification on at least *one* of the above, we will have a number of
open bugs that will prevent us from getting through Last Call.

   cheers,
      harry

[1] https://github.com/agl/curve25519-donna
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJT3+2lAAoJEPgwUoSfMzqcJlYP/1KHhK8djlFrIsnGB5EYSfcG
rVBTfuN9b2CtNc5HLi9Yj46inu9stzpjqytSfEaT7RenFdWKxUjWRpJPs5Fb5vuW
PwOEFxnIpDGqNpSr/rJKtSJx1kZ9Jeg2Zw2td1rhCRfHNTuV7kSMUwUT0ym5Xggl
0Bf3GGFLZkakSIopGmDzGs9XF22ZBi/tdM9C/Cj3fP7HNo4EjSa0FlmQSc8QB21P
UomCK+A7QT3nb8/O9S4YfhZkDZYEtZKNlG8AGl1vr4vGAgdUgHZNVAABbUUnf8xg
88cSSoACgThNHayC1t5pyOCNf7RDnGlQ7b4ceSB1IvfnMOZ5FJXPfe+e0H/dTD1r
4znfKBJ2EpX+YA1RsUGae30FFhLJvp/OuVsmzGJs/S8GiXy3YYLLKQtxZ9hpfxYm
nXJf7o3M6tK6R/Dl6dFSnEq8DEIg3OibTWVM413Mxr+ZTRiUBPicTK/CJT1CQOM7
AHdfYUBPnUAHl+fN2+HMQm+wnUBNuQgft+b3ggWeMFW7ADHs07X2PmJGpAeaPeav
gEMYMPO+52UY/SDs++weGMs3F2MHd+Zl07JL2I2VKT/emwXaMvpYdPIkC2rtGDJY
rQ2DgD88Wzq2QB4aZB0kDHSdx1nm9z7wdTrKIIfOzsTXWImnh0ZGuWUGStp8q+fJ
7oTil9eLmlDjRDqRyH4x
=sZmo
-----END PGP SIGNATURE-----

Received on Monday, 4 August 2014 20:31:52 UTC