mike-engel/jwt-cli

For (asymmetric) signature algorithms, verification requires a public key, not a secret

codedust opened this issue · 3 comments

codedust commented

Summary

For RSA-/ECC-based signatures, a public key is required for signature verification. Currently, this public key needs to be specified via the --secret parameter which is not intuitive. For RSA-/ECC-based signatures, this parameter should be renamed to --publicKey (or similar).

Steps to reproduce

$ RS256=`cargo run -- encode --alg 'RS256' -S '@./tests/private_rsa_key.der'`
$ cargo run -- decode --alg 'RS256' --secret '@./tests/public_rsa_key.der' $RS256 # <- public key is given via option named `--secret`
...

Expected behavior

# specify public key via `--publicKey` option (for RSA- and ECC-based algorithms)
$ RS256=`cargo run -- encode --alg 'RS256' -S '@./tests/private_rsa_key.der'`
$ cargo run -- decode --alg 'RS256' --publicKey '@./tests/public_rsa_key.der' $RS256
...

# specify secret via `--secret` option (for HMAC-based algorithms)
$ HS256=`cargo run -- encode --alg 'HS256' --secret '1234567890`
$ cargo run -- decode --alg 'HS256' --secret '1234567890` $HS256
...
mike-engel commented

I'm not sure this helps much. As of #130, files can be used in encoding and decoding. I agree that maybe --secret doesn't make sense grammatically all the time, but I'm not sure it's worth it to change the flag. If it did change, I would like to find common ground, like --key or something similar.

codedust commented

Would you be open for a pull request renaming the parameter from --secret to --key? Passing a public key to an argument called --secret feels a bit odd.

mike-engel commented

Yep! We should keep --secret around for a bit, but mark it as deprecated (I'm not sure if clap provides a deprecation function)