[Bug 25839] Curve25519 Named Curve

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

--- Comment #49 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Trevor Perrin from comment #48)
> 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.

No, it's a concern for our library too, with regards to importKey, exportKey,
and wrap/unwrap.

Even if you decide to hand-wave these formats to the ground (which doesn't seem
entirely appropriate, since there is active work going on precisely to
standardize these), you still have to define what "raw" means, in the specific
context of WebCrypto, and ideally in a way that will interoperate with other,
non-WebCrypto things.

Of the multiple Curve25519 implementations, very few that I'm aware of try to
actually interoperate with eachother, or with any other protocol. Even the
native language bindings for things like NaCl attempt to just use the
djb-reference implementation, and just wrap that. So it is a bit questionable
on the 'interoperability', but it at a minimum requires a formal definition for
what format(s) are supported for these operations.

For what it's worth, people do care about JWK, and they do care about SPKI.

> 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 didn't say anything close to that.

I just mentioned that these are exposed API surfaces of WebCrypto, and, as of
yet, no one has proposed on how to deal with them. Your proposal is "Don't deal
with them", which is a proposal, and one which should be discussed on it's
merits, preferably when reviewing such text.

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

Yes, I can reasonably imagine that, but imagination and specification are two
different things.

The fact that Curve25519 does not work with ECDSA, or that the Schnorr
signatures are used, are exactly the kind of things that need specification in
order for interoperability (and without just aping the djb@ code, even if it is
extremely high quality and correct and reasonably licensed for most needs) 

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

I imagine that you missed importKey, exportKey, wrap and unwrap during review.

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

WebCrypto cares about JWK.

> 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

Concrete steps:
- Make an effort to write an independent specification for Curve25519
- Everywhere you find you cannot (e.g. every time you have to "monkey patch"
the spec and say something like "Add this line to this conditional") file a bug
against the spec, as that's something that blocks Bug 25618
- At the end of the day, you will have a specification that describes how UAs
can/should implement Curve25519 (and presumably Ed25519)
- The WG will discuss as to whether to add this as a chartered work item
- Convince UAs to implement

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

Received on Thursday, 24 July 2014 21:52:08 UTC