### What is the problem this feature will solve? The fix for #15113, #24234, added support for crypto key objects, but the issue notes that ["Loading keys from engines is not supported yet."](https://github.com/nodejs/node/issues/15113#issuecomment-449851562). Later, https://github.com/nodejs/node/commit/c2ce8d05474c38c503b6ac57e94366421c960762 (see #28973) added support for loading engine keys specifically for TLS, which means that [the requisite calls to OpenSSL had to be added](https://github.com/nodejs/node/blob/c2ce8d05474c38c503b6ac57e94366421c960762/src/node_crypto.cc#L803) but only for `SecureContext` objects. In the interim, this code has migrated over to [crypto_context.cc](https://github.com/nodejs/node/blob/5fad0b93667ffc6e4def52996b9529ac99b26319/src/crypto/crypto_context.cc#L648), but it is still exclusively associated with `SecureContext` objects, meaning, I think, that it is still not possible to use the lower-level cryptographic primitives of the `crypto` API with engine keys. This impacts node.js downstream libraries, by requiring that applications handle exposed private key material to, for example, construct JWTs. See https://github.com/Azure/azure-sdk-for-js/issues/22011 and https://github.com/octokit/auth-app.js/issues/336 . ### What is the feature you are proposing to solve the problem? I would like the API of #24234 to be extended to support loading key objects from engines. This should be, I think, a fairly straightforward refactoring of existing code. ### What alternatives have you considered? There appear to be no general-purpose, viable alternatives that do not require exposing keying material to the running `node.js` application. It could be possible to specifically modify https://github.com/auth0/node-jwa to reach around node.js to, say, contact an `openssh` agent for PKCS#11 services, but this is much less preferable to just allowing the built-in `crypto` layer, which `jwa` already uses, able to load engine keys.