Curve25519 in WebCrypto

[javifernandez]

Request for position on an emerging web specification

• WebKittens who can provide input:

Information about the spec

• Spec Title: Curve25519 in WebCrypto
• Spec URL: https://wicg.github.io/webcrypto-secure-curves/
• GitHub repository: https://github.com/WICG/webcrypto-secure-curves
• Issue Tracker: https://github.com/WICG/webcrypto-secure-curves/issues
• Explainer: https://github.com/WICG/webcrypto-secure-curves/blob/main/explainer.md

Design reviews and vendor positions

• TAG Design Review: Curve25519 in Web Cryptography w3ctag/design-reviews#466
• Mozilla standards-positions issue: X25519 in Web Cryptography mozilla/standards-positions#271

Bugs tracking this feature

• WebKit Bugzilla: https://bugs.webkit.org/show_bug.cgi?id=245778
• Radar:

Anything else we need to know

This proposal tries to address the problems caused by the lack of in-browser implementations of safe curves by adding support for Curve25519 and Curve448 algorithms in the Web Cryptography API, namely the signature algorithms Ed25519 and Ed448, and the key agreement algorithms X25519 and X448.

See the WICG issue for details.

[othermaciej]

It this going to be proposed to WebAppSec (which owns the Web Crypto API)? Why is it in a separate WICG repo?

The WICG repo creation issue says WebAppSec rejected adding these algorithms to Web Crypto, but doesn't cite a source for their rejection. And neither the issue nor the explainer seem to explain the reasoning for WebAppSec's rejection, which seems like it may be relevant.

[othermaciej]

(To my knowledge this is technically a good idea but it would be nice to get this in a proper standards-track venue).

[annevk]

@othermaciej it seems that they did the drafting in WICG and as per w3c/webcrypto#196 would move it into the WebAppSec draft if there's browser implementer support. I suspect it's done that way because there's also non-browser implementers, but not entirely sure. @twiss might be able to tell us.

[twiss]

Hey 👋 The reason it's in WICG is because the new WebAppSec charter says that

The WG may adopt well-supported proposals from incubation for maintenance of the Web Cryptography API.

and AFAIU the intention behind that was that new proposals would happen in the WICG, and mostly be discussed there. Nevertheless, there was also some discussion in the WebAppSec group, e.g. at TPAC, the minutes of which are here.

In fact, as far as I understood from @johnwilander (in that conversation), someone at Apple (not sure who) is already working on implementing Curve25519 :)

The WICG repo creation issue says WebAppSec rejected adding these algorithms to Web Crypto, but doesn't cite a source for their rejection. And neither the issue nor the explainer seem to explain the reasoning for WebAppSec's rejection, which seems like it may be relevant.

So yeah, it was discussed in WebAppSec and it wasn't rejected there, I'm not sure where or how I raised that impression, but once it's well-supported, these algorithms should be added to the main Web Crypto API specification.

---

While I have your attention, I'd like to raise the main open issue in the WICG repo, WICG/webcrypto-secure-curves#10, which is about error handling, specifically for small-order elements, and whether we want to do so during key import or key derivation (in the case of X25519 and X448), for example. There is an associated PR switching from the latter to the former, with a bunch of discussion; it would be great to get your input on this point.

[othermaciej]

Looking again, and I think it's a late-night misreading on my part. the WICF proposal issue only said that Web Crypto doesn't support safe curves; it doesn't say there was explicit refusal to add them.

[othermaciej]

@twiss

While I have your attention, I'd like to raise the main open issue in the WICG repo, WICG/webcrypto-secure-curves#10, which is about error handling, specifically for small-order elements, and whether we want to do so during key import or key derivation (in the case of X25519 and X448), for example. There is an associated PR switching from the latter to the former, with a bunch of discussion; it would be great to get your input on this point.

If you need a WebKit view on this (it's ok for the requests to be about issues, not necessarily just whole specs) please file a separate standards-positions issue so it doesn't get lost.

[othermaciej]

concerns: venue label was added because this is a WICG spec patching/extending a WebAppSec spec. Seems this is understood though and the progression path is to move to WebAppSec if there is browser interest.

[annevk]

Chatting with colleagues it seems everyone thinks this is a reasonable addition. As such I suggest we label this "position: support" in 7 days.

Hopefully that'll also help resolve the venue concern discussed above.