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

[Bug 25839] Curve25519 Named Curve

From: <bugzilla@jessica.w3.org>
Date: Thu, 24 Jul 2014 17:48:57 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25839-7213-9x0aKnY22v@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839

--- Comment #47 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Trevor Perrin from comment #46)
> (In reply to Ryan Sleevi from comment #45)
> > - Suitable normative reference (TLS is still debating this)
> > - Suitable key format reference (TLS is still debating this)
> 
> Is Dan Bernstein's paper from PKC 2006 not a sufficient reference?  It's
> available at stable URLs in a couple places, contains a detailed algorithm
> description, and is widely cited as "the" curve25519 paper:
> 
> http://cr.yp.to/ecdh/curve25519-20060209.pdf
> http://www.iacr.org/cryptodb/archive/2006/PKC/3351/3351.pdf
> 
> There are multiple independent implementations.  I've never heard of interop
> problems.

Nope! It's not, that's part of the delay.

For example, how do you represent such a key in a subjectPublicKeyInfo? Is it a
OID for a NamedCurve (which is the only format that Web Crypto supports) on an
id-ecPublicKey AlgorithmInfo? Is it something else?

What about for PKCS#8?

Should it work with JWK? If so, who is responsible for the JWA registration,
and how does that relate with JWA's choice to represent points (see
https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms - JOSE knows
that the format won't work with Curve25519 as written)


> > - Suitable proposal (in a separate spec) by someone motivated for support
> > for this
> >   - Which also makes sure to update ECDH / ECDSA descriptions to be explicit
> > about what Curve25519 is and is not suitable for
> 
> Has no-one provided these?  I'd be happy to do so, though it might take a
> few weeks, and I believe you're on a tight schedule?

The schedule is irrelevant, because it wouldn't be part of the "main" spec.

That is, it's best to think of the "main spec" as a set of API definitions (the
IDL bindings), and then a set of otherwise-independent algorithm
specifications. The fact that this isn't obvious today is, in part, due to Bug
25618 not yet being resolved suitably (see the discussion on the NUMS curves -
http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0041.html )

> 
> Whether this makes sense in the core document or a separate one I don't know.
> 
> But if there are issues with including Curve25519 in WebCrypto's notion of a
> "curve", as some comments in this bug imply, it may be worth working this
> out before the core documents issue, in case this reflects limitations of
> WebCrypto.

I wholeheartedly agree that, regardless of 'main' spec or 'sub-spec', it would
be good to nail down a definition, so that we can identify and resolve the
issues with Bug 25618 as reasonably quickly as possible, to make sure the
language *supports* extensibility. See the NUMS curves discussion
(particularly,
http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0045.html ) to
understand more of my concerns there.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 24 July 2014 17:49:00 UTC

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