fix: add jose compatibility, Symbol.toStringTag values

[boorad]

fixes #681
fixes #683

[boorad]

@panva moving conversation from #681 to the PR

It's likely you're returning a symbol string tag values PublicKeyObject, PrivateKeyObject, AsymmetricKeyObject, or SecretKeyObject instead of just KeyObject which is what Node.js is doing for all these subclasses.

You are correct. fixed ✅

Also the result of this is a KeyObject, not CryptoKey.

Is it? I know that's what the Node docs say. But I traced code in Node.js and it looks like the return is InternalCryptoKey, thus CryptoKey.

The algorithm member of the key is missing required property for its given type. In this case, RsaHashedKeyAlgorithm missing its hash property which itself is supposed to be a KeyAlgorithm dictionary.

Okay, I've changed

hash: algorithm.hash

to

hash: { name: algorithm.hash } as HashAlgorithmIdentifier

in this lib's crypto.subtle.importKey(), i.e. rsaImportKey() and that seems to please Jose. But CryptoKey.algorithm can be string or dictionary, no? RSA

There are other downstream issues with polyfills. The RNQC example app doesn't use TextEncoder/TextDecoder as of a recent change (this PR), but I guess to work with Jose, users will need to add them. When I added them back in, the importJWK test passed. But 72 of 112 subtle import/export tests now fail 🤣

Would love your thoughts on above. And thank you for your time on this issue 🙏

[panva]

Also the result of this is a KeyObject, not CryptoKey.

Is it? I know that's what the Node docs say. But I traced code in Node.js and it looks like the return is InternalCryptoKey, thus CryptoKey.

Is it? Yes. I can't say what you're tracing but crypto.generateKeyPair and crypto.generateKeyPairSync are node:crypto methods that generate node's KeyObject instances, not WebCrypto's CryptoKey.

The algorithm member of the key is missing required property for its given type. In this case, RsaHashedKeyAlgorithm missing its hash property which itself is supposed to be a KeyAlgorithm dictionary.

Okay, I've changed

hash: algorithm.hash

to

hash: { name: algorithm.hash } as HashAlgorithmIdentifier

in this lib's crypto.subtle.importKey(), i.e. rsaImportKey() and that seems to please Jose. But CryptoKey.algorithm can be string or dictionary, no? RSA

You're linking a key gen dictionary, not the resulting crypto key one. This is a rather laborious process but you if were to read the algorithms defined in WebCryptoAPI you'd see that before the algorithm, and in the process of it some of its members like hash, are assigned to an internal [[algorithm]] slot of a CryptoKey instance they get run through a normalization algorithm. Which turns those simple string inputs into dictionaries. Input algorithm identifiers are normalized to a particular casing, only recognized properties are used, it's not as straight forward as taking the user input and assigning it to a key. The fact that it goes through normalization is why the algorithm can be used to determine what the key's for and what its parameters are.

There are other downstream issues with polyfills. The RNQC example app doesn't use TextEncoder/TextDecoder as of a recent change (this PR), but I guess to work with Jose, users will need to add them.

Yeah, they're part of the standard library of any Web API implementing platform.

When I added them back in, the importJWK test passed. But 72 of 112 subtle import/export tests now fail 🤣

Those tests are likely wrong? 🤷

Would love your thoughts on above. And thank you for your time on this issue 🙏

It seems to me the core of webcrypto's algorithm normalization functionality is not implemented in RNQC.

[panva]

You've also helped me discover a few bugs in the webcrypto docs in Node.js, when in doubt the WebCryptoAPI spec is what ought to be used as reference.