How to determine that a key is a usable signing key?

[mrbanzai]

I've spent a lot of time reading through the jwk.Key interface and the code surrounding and supporting jws.Sign in the v3 branch, but I've not found a clean way (within the library, at least) to determine whether a jwk.Key is generally a usable signing key. I understand that, in the name of flexibility, it might be impossible to make that determination for registered custom keys, algorithms, and signers, but I only need to interrogate those natively supported by jwx.

My use case is an internal toolkit / wrapper library that we're attempting to migrate to jwx while maintaining a backwards-compatible interface, and one of the interface methods determines whether we have registered a valid signing key for a given ID/kid. I could explicitly try to mirror the supported types within the library (eg. checking for raw key types of []byte, *rsa.PrivateKey, etc.), but this seems quite brittle. Am I overlooking some simple method?

[mrbanzai]

To clarify somewhat, I understand that the definition of "usable" ultimately depends on the signing algorithm, so obviously we have to rely on the alg being set; I am not concerned with ascertaining whether a key can be used to sign any of the registered algorithms.

[lestrrat]

Sorry for the late reply; @mrbanzai I'm a bit confused what your usecase is.
Are you trying to do this?

isValidKeyFor( kid, []byte / *ecdsa.PrivateKey / ...) // --> true
isValidKey( kid, MyAwesomeKey ) // --> false

But since the mapping between kid and the key type can only be validated by the application, you're probably asking if, given a key, jwx supports it? e.g.

isValidKey( []byte / *ecdsa.PrivateKey / *rsa.PrivateKey / .... etc ....) // --> true

I don't believe we have anything like that as public API. This is because since jwx allows algorithms and key types to be registered later, it's pretty hard to have a "definitive" list of supported key types. This is compounded by the fact that, for example, x25519 keys could be represented as EC keys (for encryption) or EdDSA keys (for signing).

I'm sure there could be some way to implement it, but right now I have the feeling that supporting this long term would be more maintenance work than it's worth (at least for me :). You are welcome to convince me otherwise, though; I'm not against the idea, but I'm not yet convinced I'm ready to maintain it.

[mrbanzai]

That's understandable, and honestly expected. I anticipated that the ability to register additional algorithms and key types would make it impossible (or at least quite difficult) to provide a definitive method. In essence, I notice that there are several places throughout the various packages where explicit types are referenced (eg. *ecdsa.PrivateKey or *rsa.PrivateKey), and I was generally trying to ensure that the key a caller provides (perhaps associated with a given signature algorithm) is valid for signing, when registered in a signing context.

For now, I believe I've managed to cobble something together using a combination of jws.AlgorithmsForKey(), jwk.IsPrivateKey(), and a type assertion against jwk.SymmetricKey.

Thanks for the reply.