[Bug 25839] Curve25519 Named Curve

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

--- Comment #48 from Trevor Perrin <webcrypto@trevp.net> ---
(In reply to Ryan Sleevi from comment #47)
> (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?

Don't care!

The several Javascript crypto projects I'm advising don't use PKIX, S/MIME,
JOSE, or PKCS#8.  If Curve25519 needs number registration for those, then that
seems like an issue for those protocols, not a concern for a low-level crypto
library.

Are you saying WebCrypto can't support new algorithms unless they're registered
with a half-dozen IETF protocols most people don't care about?

I guess I expected a low-level API to just provide Curve25519 keys with ECDH,
and Ed25519 keys with sign/verify (since by convention and for
performance/security reasons, Curve25519 is mostly used with different
encodings for public/private keys in signatures vs ECDH, and Schnorr signatures
are used rather than ECDSA).

I could imagine these creating some issues for your API, and those seem like
good things to discuss further.  But having to specify PKIX or JWK bindings
seems unnecessary and a layering violation.


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

I think that's for someone who cares about "JWK" to worry about.


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

So what's the way forward?  Should this discussion switch to Bug 25618?  Is
anyone working on a more streamlined way to add new algorithms?

Trevor

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

Received on Thursday, 24 July 2014 20:26:43 UTC