crypto: don't crash on unknown keyObject.asymmetricKeyType by panva · Pull Request #26786 · nodejs/node (original) (raw)

I share this concern. We could choose something inbetween such as ${oid}-unsupported.

Its in-between, but has the exact same problem as key-id-$(nid).

Anything, other than an actual string specific to the key id will eventually change, and be semver-major when we start to support the numeric type. This argues strongly against returning any string for the .asymetricKeyType if we don't recognize the numeric key type. Perhaps the property should be defined, but with an actual value of undefined? Changing that to a string when we add support for a new EVP key ID should not be semver-major.

(EDIT: I rewrote the above slightly, sorry, I think the old text was confusing).

I can think of a couple solutions:

1. add a property that has an OID valud (or nid, it doesn't matter to me that its an openssl API artifact, we only support openssl), because they will always exist, and in order to not have people be typing OIDs into their code, add crypto.constants.KEY_ID_RSA, crypto.constants.KEY_ID_EC, etc., that have an OID as a value, and tell people to start using those constants to check key types, not .asymetricKeyType. Maybe .asymetricKeyType can be deprecated.
2. Start throwing errors. If someone gets the error thrown, they can make a feature request for support.
3. Add every one of the existing key ids, along with a node.js string equivalent, to the switch statement of key types, and stop calling them "supported key types" in our docs, just "key types". Do this along with 2. (which should no longer happen, unless there is an openssl update that adds a key type and we didn't notice).