[Bug 25839] Curve25519 Named Curve

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839

Harry Halpin <hhalpin@w3.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hhalpin@w3.org

--- Comment #21 from Harry Halpin <hhalpin@w3.org> ---
(In reply to Ryan Sleevi from comment #20)
> (In reply to Henri Sivonen from comment #15)
> > When different CPU architectures have distinct implementations, you could
> > count x86_64 impl. by person A and armv7 impl. by person B as distinct
> > implementations.
> 
> There are zero *implementations*, let alone interoperable, in the
> cryptographic libraries used of *any* user agent implementing WebCrypto at
> present. All of the implementations have, at present, deferred crypto to the
> appropriate library.
> 
> As noted, the cryptographic libraries of two major implementors are
> presently tied to major OS releases. The two cryptographic libraries in use
> by the other implementors (NSS and OpenSSL) equally lack implementations of
> Curve25519.
> 
> There is no specification of Curve25519. The IETF has made talks of it, but
> has yet to actually make headway. It is simply "The code speaks for itself".
> While there are many implementations of Curve25519, for different platforms,
> they are all based on the same djb initial code and still re-use aspects of
> it.
> 
> It's popularity, unquestionable as it is - even within the organizations of
> at least two UAs - is not something at any level of maturity that the
> document can even place a normative reference on.
> 
> I disagree on the assertion that the x86_64 impl can be seen as
> interoperable with the armv7 impl on two grounds. The first is that the
> common implementation is not hand-rolled assembly but the common dbj C code.
> The second is that we've already seen past APIs that use a common
> code/library (eg: WebSQL -> SQLite), lacking definition or truly ground-up
> implementations, be rejected.
> 
> I don't oppose Curve25519 on crypto reasons; it's unquestionably desirable.
> But if we're going to talk about interoperability and well-defined
> algorithms, at present, this is lacking.

As mentioned in another bug, Curve22519 is an example of an algorithm with real
use-cases and actual demand from developers that can be registered (although it
does lack a proper IETF RFC etc.) but may likely not be implemented by browsers
(for whatever reason), but nonetheless should likely be registered and tested
to be strictly fair with regards to the curve *and* the amount of demand for
it. So "it's unlikely to be implemented" is not a good argument to not register
it until test the interop to prove it isn't implemented. 

I am not arguing that we should test every possible curve and algorithm, but
when multiple develoipers with use-cases want something tested and don't
believe it's not implemented, then it probably is worthwhile for the WG to test
it even if it's not implemented. 

Who knows - if demand keeps increasing, maybe browsers will implement?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 11 June 2014 10:02:21 UTC