How to best propose features and show implementor interest

[panva]

@twiss Thank you for volunteering as editor for the Web Crypto specification, it is refreshing to see updates being published to the Editor's Draft. I am following a number of open issues in this tracker most of which are labeled with [needs implementor interest].

The things they share in common is that they don't appear to be active at all, there are barely any positive or negative signals from implementors. It seems that most of the requests come from users of the API, not its implementors nor its authors. There's no ranking, there's no curated list, etc. From looking at how these issues are being handled it would appear that, given implementor interest is the prerequisite, unless feedback is chased to be provided by said implementors the feature requests are bound to just get stuck.

The following questions are coming from the background of wishing there was more modern ciphers and algorithm options in this API and willing to do something about organising and collecting feedback both from users of the API as well as new implementors.

• Is there a forum where implementors discuss these feature requests? How to best solicit actual implementor feedback/interest?
• Who is considered an implementor? Is it just the three browser engine vendors? Safari, Chromium-based, Firefox? Web Standard APIs implementations including Web Cryptography API are now also featured in Node.js, Deno, and Cloudflare Workers. For Deno and Cloudflare Workers these are the only cryptography APIs available in said runtime.
• Is there an example of a "good" feature request?

I'm expecting requests from developers asking for features such as EdDSA, ECDH w/ X25519, ECDSA with secp256k1 from the new implementors - most notably, Deno and Cloudflare Workers, where there's no other crypto API but Web Cryptography API. How would a request like, say, Ed25519 sign/verify support go if all of Node, Deno, Cloudflare maintainers and contributors shown interest but there would be the usual crickets from browser vendors?

[twiss]

Hey @panva, thanks, good questions. I'll start with the good news; I've reached out to the browser vendors re. Curve25519 and Curve448, and have received some positive signals regarding those. I'm planning to push that forward myself, and then move on to gathering signals re. more secure/modern ciphers and algorithms (e.g. a KDF, and an AEAD algorithm). New features (e.g. #73, #270) are last on my list. Then, for some bad news, I've received negative signals re. secp256k1, so it's not on the list.

This repository's issue board is not a bad place to post proposals, but another option (or, perhaps, good next step) is the WICG Discourse board. In general, any major additions to this spec should go through the WICG (i.e. post to the discourse with a proposal, then create a repo with an explainer document, collect feedback, etc.). I will do so for Curve25519&Curve448, if you want to take up any of the others, please feel free to (or if you care about and want to push forward one from the list above let me know, I can reach out to the browser vendors about interest). One other example that did so is crypto.randomUUID(), which is expected to be merged into the Web Crypto spec.

Re. Node.js's and Deno's implementations, I was aware of them and consider them important. I wasn't aware of the implementation in Cloudflare Workers, thanks for that. I think it would still be good to get interest from the browser vendors, though. Hopefully the above gives you some confidence that that might be possible ^.^

[panva]

Thank you so much for your answer here. I will do my best to digest and maybe shoot a couple of follow up questions.

Then, for some bad news, I've received negative signals re. secp256k1, so it's not on the list.

Interesting, a hypothetical exercise - all non-browser implementors would show positive signals on it, what then?

[panva]

cc'ing @jasnell (Cloudflare Workers & Node collaborator), @lucacasonato (Deno core team), @littledivy (Deno contributor) for visibility. Myself also Node collaborator.

[twiss]

Interesting, a hypothetical exercise - all non-browser implementors would show positive signals on it, what then?

I'm not sure. For secp256k1, as I mentioned in #82 (comment), I think there are good reasons not to add it, and I think we should push users towards Curve25519 and Curve448 instead wherever possible. If you disagree, we can discuss that in that issue.

For any other hypothetical case, I think it's a bit hard to discuss in the abstract; if it's e.g. one of the other issues I listed, I'm happy to go and try to convince the browser vendors that it should be implemented. I think we should try that before considering other options. The goal of the spec is to have interoperability between all implementations, so if all browsers are opposed, then it would be difficult to achieve that, and it may be sign that the feature somehow isn't a good fit for the web platform. If that's not the case and the signals are "neutral", e.g. due to a lack of bandwidth, then that may be a different story.

[TJKoury]

@twiss I for one will help you make a case for including secp256k1, and recommend that you reopen that issue. The SafeCurves exclusion issue is way overblown and a nitpick at best.

It’s clearly a secure curve in practice, backed by an over $2T ecosystem (at the time of this comment) including Bitcoin. I don’t think anyone in this space is saying Bitcoin is going away, and if the Bitcoin Core devs decide to use a different curve for security reasons, it would be trivial to deprecate.

What everyone seems to be thinking but is too polite to say out loud is the appearance of big tech companies fighting decentralization and not supporting it with their products (like Chrome).

[twiss]

@TJKoury Thanks for the offer, but - not to seem too pessimistic, but - I'm currently already having some trouble getting engagement from implementers on the Secure Curves in WebCrypto draft, which adds Curve25519 and Curve448. I got more positive signals from implementers about those curves than about secp256k1, so - if we can't get Curve25519 and Curve448 added, then - frankly - secp256k1 has no chance. To phrase that in a more positive way, if you want to help, please also help by championing Curve25519 and Curve448.

To be honest, I think at this point, what we really need is someone willing to implement these curves, in some or all open source implementations. This is not an easy task, but may be helped by existing implementations for TLS - though most browsers currently only support X25519, not Ed25519 nor X448 and Ed448 (see https://bugzilla.mozilla.org/show_bug.cgi?id=1325335 and https://bugzilla.mozilla.org/show_bug.cgi?id=1597057 for Firefox bugs on that). If someone is willing to write patches for these, and the browsers are willing to accept them, that would be the strongest signal possible to show implementer interest :)

[panva]

@twiss

I'm currently already having some trouble getting engagement from implementers

Curve25519 and Curve448 can be added, relatively fast, to Node, Deno, and Cloudflare Workers (with it also Vercel Edge Functions). Which I believe was signalled clearly.

I asked previously

Interesting, a hypothetical exercise - all non-browser implementors would show positive signals on it, what then?

And it, indeed, seems like even very positive signals or intents to implement from non-browser implementors weigh very little here.

[TJKoury]

@twiss Unless there’s some sort of issue we can use the OpenSSL implementations of all these curves.

[twiss]

(Sorry for the delay.) @panva I understand and partly share your frustration. However, looking at WICG/proposals#46, it may not be totally obvious that there are intents to implement. Could you (and maybe @lucacasonato and @jasnell) leave a comment there stating as much, perhaps? Then I'll try to ping some people from the W3C and hopefully get this moved to the WICG.

@TJKoury Not every implementation uses OpenSSL. Deno uses ring (I believe), Firefox uses NSS, Chrome uses BoringSSL (which admittedly is a fork of OpenSSL), and none of those include an implementation of Curve448, for example (though perhaps OpenSSL's implementation of Curve448 could be added to BoringSSL). In any case, it's not entirely trivial, and I believe that for the implementations that haven't signaled an intent to implement yet, it's mainly about lack of bandwidth to implement, not any opposition to doing so.

[panva]

cc @littledivy Please see @twiss message ☝️

[TJKoury]

@twiss My point was and remains that OpenSSL is well tested, open source, has a permissive license, and contains everything that is required. It’s a good starting point.