-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Curve25519 in WebCrypto #67
Comments
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. |
(To my knowledge this is technically a good idea but it would be nice to get this in a proper standards-track venue). |
@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. |
Hey 👋 The reason it's in WICG is because the new WebAppSec charter says that
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 :)
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. |
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. |
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. |
|
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. |
Apologies for the delay, done now: #82. Thanks! |
Closing as we've identified our position. |
Request for position on an emerging web specification
Information about the spec
Design reviews and vendor positions
Bugs tracking this feature
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.
The text was updated successfully, but these errors were encountered: