It seems that presence of methods like canVerify and checks in verify method itself should prevent invalid use. Just curious. Use case is that a key used only for signing, not verifying.
The SSHKey piece is what I was working on independently before I refactored to support the Joyent spec, so the default primacy of the ssh-rsa algorithm is an artifact of that. I haven't had much feedback from users outside of my own tooling ecosystem, so the ergonomics of this library have not really followed the node-http-signature implementation very closely. I'm happy to keep incorporating your feedback as long as you are actively using this library. I can probably safely change the default signature algorithm for ssh keys to be rsa-256 or rsa-512 to match whatever is most commonly supported to reduce the need for rotation requests.
I think the reason for requiring the public key in the constructor is that it is necessary to compute the key fingerprint. Looking at it now it doesn't make much sense to have that error message there.
1)
KeyFormat.SSH_RSA
hasAlgorithm.SSH_RSA
as the first candidate for algorithm, but it is not supported by node-http-signature:https://github.com/adamcin/httpsig-java/blob/2b1fc5601bbc17ee4b953c0063423fffe2ccd0bb/ssh-jce/src/main/java/net/adamcin/httpsig/ssh/jce/KeyFormat.java#L53
https://github.com/joyent/node-http-signature/blob/529441d9d04a8ecb296a2a152929332526344673/lib/utils.js#L13
For this to work without algorithms rotations, i do the following after a signer creation:
Is this how it is supposed to be used? Can't there be more "out of the box experience" for this?
2) Why
SSHKey
here must have public key?https://github.com/adamcin/httpsig-java/blob/2b1fc5601bbc17ee4b953c0063423fffe2ccd0bb/ssh-jce/src/main/java/net/adamcin/httpsig/ssh/jce/SSHKey.java#L64
It seems that presence of methods like
canVerify
and checks inverify
method itself should prevent invalid use. Just curious. Use case is that a key used only for signing, not verifying.