crypto: add CFRG curves to Web Crypto API

[panva]

As per https://wicg.github.io/webcrypto-secure-curves and WICG/proposals#46

This

• Adds Ed25519, X25519, and X448 in full as described by https://wicg.github.io/webcrypto-secure-curves as of May 2022
• Adds Ed448 as described by https://wicg.github.io/webcrypto-secure-curves as of May 2022 with the exception of its sign/verify optional context algorithm property which it only accepts as a zero-length value, otherwise throws "not implemented" due to lack of this option in the underlying C++ implementation.
• removes NODE-ED25518 and NODE-ED448 algorithms (replaced by Ed25519 and Ed448)
• removes NODE-X25519 and NODE-X448 ECDH namedCurve values (replaced by X25519 and X448 algorithms)
• simplifies the webcrypto docs by utilizing the AlgorithmIdentifier "class". This means that other than the other NODE-* extensions the only "classes" documented follow the defined WebCryptoAPI dictionaries.

[nodejs-github-bot]

Review requested:

• @nodejs/crypto

[panva]

Marking as never-stale Mark issue so that it is never considered stale as we wait for a consensus on the draft moving forward.

[panva]

Since the entire webcrypto module is experimental Issues and PRs related to experimental features. I feel like this could land and replace the proprietary extension before the draft moves forward. Pending further thoughts

/cc @jasnell @tniessen

[tniessen]

Since the entire webcrypto module is experimental Issues and PRs related to experimental features. I feel like this could land and replace the proprietary extension before the draft moves forward. Pending further thoughts

Ah, the usual Web Crypto dilemma... There is not much point in implementing Web Crypto except compatibility across runtimes, yet the set of compatible features is extremely small. I don't see much point in landing this before WICG/proposals#46 is resolved and other runtimes consider implementing it.

[panva]

There is not much point in implementing Web Crypto except compatibility across runtimes

That seems like a pretty strong point towards removing the other NODE-* extensions, isn't it?

[tniessen]

There is not much point in implementing Web Crypto except compatibility across runtimes

That seems like a pretty strong point towards removing the other NODE-* extensions, isn't it?

I don't see much point in having them except that the crypto Issues and PRs related to the crypto subsystem. module doesn't support JWK at the moment (thanks for pointing out that it does @panva!).

That doesn't mean I am in favor of removing them, I just personally don't think they are relevant.

[tniessen]

@panva @jasnell I'm trying to make sense of the node-specific extensions. Much of it surprises me. For example, should this really work?

await crypto.webcrypto.subtle.generateKey({ name: 'NODE-ED25519', // signature algorithm namedCurve: 'NODE-X25519' // key exchange algorithm ??? }, true, ['sign'])

[panva]

@panva @jasnell I'm trying to make sense of the node-specific extensions. Much of it surprises me. For example, should this really work?

await crypto.webcrypto.subtle.generateKey({ name: 'NODE-ED25519', // signature algorithm namedCurve: 'NODE-X25519' // key exchange algorithm ??? }, true, ['sign'])

It should not. We fixed a number of these for importKey but did not notice for generateKey. The implementation in this PR does not have these issues since it does not piggyback on the ECDSA/ECDH algorithms.

[jasnell]

Agreed. That's a bug that should get fixed.