W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2014

[Bug 25839] Curve25519 Named Curve

From: <bugzilla@jessica.w3.org>
Date: Sat, 24 May 2014 18:35:12 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25839-7213-HkB4R0VYsH@http.www.w3.org/Bugs/Public/>

--- Comment #12 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Greg Slepak from comment #9)
> (In reply to Ryan Sleevi from comment #8)
> > Yes, there is more than technical discussion here (although Curve25519
> > remains a highly charged technical discussion). The political issues are
> > very much applicable for User Agents, particularly those that need to be
> > available to users in a variety of countries and purposes.
> > 
> > While you can disagree with these, they are real issues that User Agent
> > vendors have to deal with. Things like export controls and FIPS 140-2 remain
> > issues for UAs and UA vendors.
> > 
> > Still, a reasonable path forward is to provide separate curves in a separate
> > specification, which can then look at adding things like Curve25519,
> > Poly1305, Salsa 20, or the BADA55 curves.
> Could you please explain what a separate specification would achieve?
> Would it result in support for Curve25519 in Chrome and Firefox?

Including in this specification is no more or less likely, as noted already.

Each of the algorithms' specification is entirely independent, from the point
of view of our REC track requirements.

That is, you can implement this spec with only support for SHA-1 *and* be fully
spec compliant.

> If not, then what's the point of a separate specification?

Separate specifications encourage separate discussion about the merits of
individual algorithms, including recognizing the fact that UA acceptance is

> That then leads to a fork in the road. Get it? Fork? I made a funny! ;P

You are receiving this mail because:
You are on the CC list for the bug.
Received on Saturday, 24 May 2014 18:35:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:22 UTC