crypto: add keyObject.export() JWK format option

[panva]

Adds JWK keyObject.export format option.

• supported for key types: ec, rsa, ed25519, ed448, x25519, x448, and symmetric keys, resulting in JWK kty (Key Type) values EC, RSA, OKP, and oct.
• rsa-pss is not supported since the JWK format does not support PSS Parameters.
• EC JWK curves supported are P-256, secp256k1, P-384, and P-521

cc @nodejs/crypto

[tniessen]

Code itself LGTM, but I don't really trust my understanding of JWK enough to judge whether this is opening a new can of worms. (And yes, I've read most of the WebCrypto and JWK specs multiple times.)

Code itself LGTM, but I don't really trust my understanding of JWK enough to judge whether this is opening a new can of worms. (And yes, I've read most of the WebCrypto and JWK specs multiple times.)

@tniessen Anything I can do to help you disperse this particular trust issue?

CI: https://ci.nodejs.org/job/node-test-pull-request/35772/

The errors in errors.md are in alphabetical order so before this lands, the names need to be determined and then they need to be moved to the right place in the file. Once that's happened, feel free to clear this request for changes. No need to ping me on it or anything. Just leaving this here to make sure it happens before the code lands.

I also wonder if we want to avoid creating additional error codes and use something fairly generic like the existing ERR_CRYPTO_UNSUPPORTED_OPERATION? If we want to keep separate error codes for unsupported curves and unsupported key types, maybe make a generic ERR_CRYPTO_UNSUPPORTED_X for each of those and use that? I don't feel strongly about this, though. If ERR_CRYPTO_JWK_UNSUPPORTED_CURVE is the way to go, then OK.

I also wonder if we want to avoid creating additional error codes and use something fairly generic like the existing ERR_CRYPTO_UNSUPPORTED_OPERATION? If we want to keep separate error codes for unsupported curves and unsupported key types, maybe make a generic ERR_CRYPTO_UNSUPPORTED_X for each of those and use that? I don't feel strongly about this, though. If ERR_CRYPTO_JWK_UNSUPPORTED_CURVE is the way to go, then OK.

I've kept the specific errors here since i couldn't come up with a generic one. As far as future import feature comes in, these two will be re-used. I will keep the amount of specific error codes to the minimum based on this feedback though.

feedback applied, @Trott said "feel free to clear this request for changes"

I still have my doubts about the integration of WebCrypto/JWK into the crypto module, but that might just be because I spent far too much time on core crypto and not enough time on web crypto standards. It's an incredibly complicated topic.

KeyObjects ignore some JWK properties, e.g., key usages. And that's by design, that's not what KeyObjects are for. But it also means that importing and then exporting a JWK means it loses those additional JWK properties.

ASN.1 remains the most relevant and popular format for public and private keys. I designed the KeyObject class and many other crypto APIs in core, but I cannot fully estimate the impact of the addition of web crypto standards on them. I am fine with these additions as long as they don't get in the way of ASN.1 import and export capabilities, or the mapping of asymmetricKeyType to EVP_PKEY_* in OpenSSL. If JWK key types and EVP_PKEY_* key types ever start diverging, we might be in serious trouble.

CI: https://ci.nodejs.org/job/node-test-pull-request/35899/

Landed in a8d7de1