Custom sign and encrypt key management functions

[FurlanLuka]

Hello,

I've been working on a project that heavily relies on elliptic curve cryptography on both backend (node) and front-end (browser). The curve of choice is Curve25519. The issue I'm having is that subtle crypto does not support Curve25519 which makes it impossible to use this library for JWS / JWE. My suggestion would be to add setSignFunction and setKeyManagementFunction to respective objects that will allow to pass custom sign / key management functions inside the library. This would allow me to use non-subtle crypto variants of Curve25519 which work on browser (https://www.npmjs.com/package/@noble/ed25519). An example of usage would look like this

const signature = await new jose.CompactSign(dataBytes) .setProtectedHeader({ alg: 'ES256' }) .setSignFunction(customEd25519) .sign(privateSigningKey);

[panva]

• https://wicg.github.io/webcrypto-secure-curves/
• Implementation status WICG/webcrypto-secure-curves#20

I don't think the effort and increased footgun api surface is worth it given that (see above links) curve25519 is not far out from being part of the webcrypto api algorithm suite.

In the meantime, use algorithms that are available in both your target runtimes.

[FurlanLuka]

@panva Unfortunately the browser supported EC algorithms aren't considered safe. (https://safecurves.cr.yp.to/) If I opened a PR adding the functionality of being able to provide your own sign/verify/encrypt/decrypt functions could it be considered for merge? I'm fully ready to own the feature and also clean it up once the curve25519 is released

[panva]

It's not the case that the supported algorithms are no longer fit for use, if that was the case they would be made deprecated or removed from the spec.

I will not be adding this API for the reasons stated above - it is a footgun to some and "safe" curves are on the way, in the meantime use what's available or roll custom jws/jwt.