-
-
Notifications
You must be signed in to change notification settings - Fork 35.3k
Accepting CryptoKey in node:crypto APIs #55293
Copy link
Copy link
Open
Labels
cryptoIssues and PRs related to the crypto subsystem.Issues and PRs related to the crypto subsystem.deprecationsIssues and PRs related to deprecations.Issues and PRs related to deprecations.discussIssues opened for discussions and feedbacks.Issues opened for discussions and feedbacks.never-staleMark issue so that it is never considered staleMark issue so that it is never considered stalewebcrypto
Metadata
Metadata
Assignees
Labels
cryptoIssues and PRs related to the crypto subsystem.Issues and PRs related to the crypto subsystem.deprecationsIssues and PRs related to deprecations.Issues and PRs related to deprecations.discussIssues opened for discussions and feedbacks.Issues opened for discussions and feedbacks.never-staleMark issue so that it is never considered staleMark issue so that it is never considered stalewebcrypto
The following APIs accept a
CryptoKeyinstance and process the operation despite the restrictions put forth on theCryptoKeyinstance (e.g. algorithm, usages, extractable)extractable)This list is according to the docs, but i suspect it's possible that hkdf and pbkdf2 allow this too.
This issue is to discuss a way forward to deal with this issues.
KeyObject.from
#37240 attempted to do something about KeyObject.from but i think the outcome would not solve the issues above.
I believe that converting key representations is not an issue so long as the more restrictive key representation's properties are upheld.
We can take a drastic stance and deprecate / in due time remove KeyObject.from entirely, or make KeyObject.from respect the
extractableproperty and duly document that once the key is converted the CryptoKey restrictions are not upheld anymore. I'd much rather see the latter.Another possible approach would be to disable KeyObject.export on keys that came from non-extractable CryptoKey.
APIs accepting CryptoKey but ignoring its parameters.
We could deprecate the use of CryptoKey in these APIs entirely or emulate WebCryptoAPI behaviour and check the CryptoKey usages and algorithm slots, either way this would be a doc-only deprecation at first, then --pending-deprecation, runtime deprecation, throw behaviour at the end.