[Bug 25839] Curve25519 Named Curve

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

--- Comment #51 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Trevor Perrin from comment #50)
> The "raw" definitions would be straightforward, as the Curve25519 and
> Ed25519 papers specify exact encodings for keys and signatures.

Though I don't agree with that, it's something better discussed when reviewing
a spec you wrote, rather than on this bug.

> > Of the multiple Curve25519 implementations, very few that I'm aware of try
> > to actually interoperate with eachother, or with any other protocol.
> 
> I've talked to some developers of these libraries who indeed have performed
> interop tests.  The DJB specs are very clear, and the formats are very
> simple.  I'd be surprised if any serious implementations of Curve25519 ECDH
> and Ed25519 signatures failed to interoperate.

Though I don't agree with this either, it's something better discussed when
reviewing a spec you wrote, rather than on this bug.

> That speaks to the quality of these implementations, it doesn't imply
> interop problems.

If the only way to interop is to read source, that is an interop problem.
If the only way to interop is to use one of the canonical sources, that too is
an interop problem (c.f. WebSQL)

> > For what it's worth, people do care about JWK, and they do care about SPKI.
> 
> Some people do, some people don't.
> 
> Personally I'm more interested in TextSecure, Tor, PGP, SSH, OTR and
> variants, CryptoCat/miniLock, and others.  I don't think WebCrypto should
> refuse algorithms of interest to large communities just because they aren't
> used within PKIX or JOSE.

We're neither accepting nor refusing. I'm simply giving you a set of concerns
that you'll likely need to address during discussion.

I don't think I'd be supportive of this without at least JWK support.

> My proposal would be to define the "raw" formats for import/export now, and
> add other formats ("jwk", "pkcs8", "spki") if/when they become available.

"Someone" has to define the JWK spec. Look at ours - we already register
several JWAs specifically to support JWK with WebCrypto. It's certainly
possible for your spec to do the same.

Whether or not you do is your choice, but it's one that will at least be
discussed. I don't think without at least JWK I'd be supportive.


> "Aping" code for these isn't needed.  Like Curve25519 ECDH, the Ed25519
> signature format is well-specified in a published paper:
> 
> http://ed25519.cr.yp.to/ed25519-20110926.pdf

While I appreciate the enthusiasm, it may be worth re-reading that paper. It
doesn't (at least as far as I recall and found) specify how to deal with octet
strings. That is, the algorithms are defined in terms of integers, but the
format conversions are left ambiguous.

> I see them, I just think it's strange for this API to be concerned with
> outputting keys in various application formats.
> 
> Adding or parsing JSON/XML/ASN.1/etc boilerplate can be done in Javascript
> without special performance or security considerations.  It doesn't seem
> that important to perform this in the browser.
> 
> It's also weird to favor such specific protocols, to the point that not
> being used in them is an argument against adopting crypto that's widely used
> elsewhere.

Every modern crypto API supports some form of key input. You can either
abstractly reduce it to the same primitives of SPKI (e.g. reducing an
RSAPublicKey to n/e params, an RSAPrivateKey to n/e/d/p/q/etc) or you can take
the forms in native.

This is a Web API, and using a JSON-like structure for parameters is idiomatic.
As it happens, JWK is a JSON-like structure for parameters, and takes the
primitives you want.

I would disagree on the assertion of both "without special performance"
concerns (which we can show to be false), and, at least by the arguments in
favour of wrapKey/unwrapKey and the "extractable" flag, some members of the WG
clearly feel that there are security concerns.

Specifically, if you only support "raw", then you cannot "securely" (a term I
use based on other members' recorded views) support unwrapping of Curve25519
keys. That is, the 'sender' can control extractability by setting the JWK "ext"
attribute prior to wrapping, then wrap the key. The recipient is documented as
respecting the "ext" attribute independent of the content script's parameters
to unwrapKey.

> > Concrete steps:
> > - Make an effort to write an independent specification for Curve25519
> 
> OK.  
> 
> So if I specified "Curve25519" and "Ed25519" algorithms that only define
> import/export using the "raw" formats and the DJB-defined standard
> encodings, this would be considered?

If you specified them with no encodings, it'd be considered.
If you specified them with the Trevor Perrin Awesome Encodings, it'd be
considered.

The point being that, as a WG, we'll "consider" all submissions. But the choice
or absence of some features will have an affect on whether or not the WG adopts
it as a WG item, and whether or not the WG is able to progress on this.

> Is there an example template for producing add-on algorithm documents?  Are
> any spec editors or other people willing to help, as I'm new here?

No example templates. New territory being charted here. Each "Algorithm"
section in the main spec "SHOULD" (e.g. if the main spec's main UA processing
algorithms) be an example of what's necessary. In practice, I suspect it's not
- least of all because of how the "NamedCurve" enum behaves - and those are
bugs that need to be filed against the spec. I don't know all the places, which
is why we have the general bug, because we do know it's wrong, but none of the
people who have reviewed the spec have taken the time to call out the places
they see.

As for formatting, well, it's W3C, use whatever you want. ReSpec.js is pretty
hip and popular. It just has to pass the W3C PubRules checks if we were to push
it.

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

Received on Friday, 25 July 2014 17:44:57 UTC