Add initial support for using ssh keys for signing - #18

This is awesome! I learned a lot reading this review.

Looking at your sample program, I really like the simplicity of it. The httpsig is basically "construct, sign". The only thing that stuck out to me was the comment "using nil for privatekey". I think that's a great warning sign that, somehow that method needs to change so that when a client wants to use a SSHSigner they don't need to pass a nil. We can do that internally though as a shortcut.

I think there's a great opportunity to put SSH Signing on the road to being even more of a first-class supported feature. In that spirit, I have some suggested changes and additions, if you're willing & able to do them. I also include optional bullets if you'd like to extend it to all private key types supported by both SSH & HTTPSignatures, not just ed25519. Those optional bullets don't have to be tackled in this review; I just need someplace to park the vision of fully supporting SSH signing.

What do you think about the following (numbered) adjustments?

1. Making a type SSHSigner interface dedicated type (so now httpsig.SSHSigner exists)
2. It has SignRequest and SignResponse similar to Signer but w/o the crypto.PrivateKey parameter. Now this fixes the nil private key parameter being exposed: it no longer exists in the interface.
3. Now NewSignerFromSSHSigner needs to return a SSHSigner instead of a Signer. It'll do so by passing the buck and calling newSignerFromSSHSigner
   • Optional: Pull out the switch/case statement for the various SSH s.PublicKey().Type() to an Algorithm string (ex: "ssh-ed25519" => ED25519) to be a tiny function, use that tiny function when internally calling newSignerFromSSHSigner.
4. Now newSignerFromSSHSigner needs to return a SSHSigner. Let's create a new type that simply wraps the existing SignRequest functionality, passes the nil for us, plus hides the existing non-SSH SignRequest for the new type:

type asymmSSHSigner struct {
  *asymmSigner
}
func (a *asymmSSHSigner) SignRequest(pubKeyId string, r *http.Request, body []byte) error {
  return a.asymmSigner.SignRequest(nil, pubKeyId, r, body)
} //etc, similar for SignResponse

var _ SSHSigner = &asymmSSHSigner{} // This compiles
var _ Signer = &asymmSSHSigner{} // This is a compilation error

5. Wrap the asymmSigner in newSignerFromSSHSigner with asymmSSHSigner.
   • Optional: Do a similar wrapping plus delegation for the algorithms, something like:

type sshAlgorithm struct {
  sshSigner ssh.Signer
  delegate signer // our internal type
}
func (s *sshAlgorithm) Sign(rand io.Reader, p crypto.PrivateKey, sig []byte) ([]byte, error) {
  // Your use of s.sshSigner goes here
}
func (s *sshAlgorithm) Verify(pub crypto.PublicKey, toHash, signature []byte) error {
  return s.delegate.Verify(pub, toHash, signature)
}
func (s *sshAlgorithm) String() string {
  return s.delegate.String()
}

• Optional: This means signerFromSSHSigner can change: get any signer from signerFromString (you got the string from the "tiny-function" in step 3's optional) and then just wrap it with a sshAlgorithm and your sshSigner. No need to hardcode ed25519 in signerFromSSHSigner any longer.

Again, no pressure to do the Optional bullets. The numbered steps I think are worth considering to keep the API for SSH users happy, and welcome your thoughts & feedback!

Awesome job! Thanks a ton!