Closed eest closed 1 year ago
Oh, hmmmmmmmm. This one's a bit tricky...
See, we allow crypto.Signer
to be passed as key
, so that hardware based keys and KMSes can do their thing.
The problem here is that jwk.ECDSA(Private|Public)Key is also a crypto.Signer
.
let me think about it
After some digging around, I've concluded that I can protect users from misusing KNOWN key types (i.e. those that are defined in Go std lib and within this package, but not for other key types that implement crypto.Signer
. I added some notes in the jws.WithKey
documentation as well.
Please check #997 and let me know
Forgot to mention: @eest (just making sure...)
That was some impressive response time :)
I updated my go.mod in order to test your fix
require github.com/lestrrat-go/jwx/v2 gh-996
And now:
go run .
2023/10/18 09:04:00 failed to generate signature for signer #0 (alg=RS256): failed to sign payload: cannot use key of type *ecdsa.PrivateKey to generate RSA based signatures
exit status 1
So it looks good to me, thanks!
@eest merged. Please note that I'm going to wait releasing it for a bit. Please point our go.mod to the commit SHA for the time being, until we make a release.
Great! Even running on a currently released version is good enough for me right now, this was more of an unexpected behaviour when testing what happens when doing things wrong. I'll attempt to do things right instead :)
Describe the bug
I noticed that
jws.Sign()
does not appear to get upset if passed ajws.WithKey(jwa.RS256, jwsSigningKey)
wherejwsSigningKey
contains a*ecdsa.PrivateKey
To Reproduce / Expected behavior
Running it:
While
Verify()
fails it surprises me thatSign()
did not return an error when mixing an RSA-based alg with an ECDSA key. Is this expected?If I change
jwa.RS256
tojwa.ES256
like so:... then
Verify()
is also happy as expected: