This looks fine, except that all of this stuff should presumably be signed -- maybe signing needs to move into the client?

This is mostly a judgement call on what the simplest thing we can get away with for now while still doing SSH key auth is. This is slightly more formal than the original implementation was because I think a couple of pieces of it weren't quite heavyweight enough to survive to SAAS. I think this is about the least we can get away with.

The possibly-overengineered part here is the "Consign" signature algorithm. There's some discussion of this and reasoning in D10401. The previous version of this just signed JSON. I picked this by balancing these concerns:

• Cons
  • Custom algorithm that I might have screwed up.
  • Third parties will have to implement this if they want to do SSH signing (but we don't expect anyone to use SSH keys for now).
• Pros
  • Works for binary data, which signing JSON doesn't.
  • Signature is indepenent of key order in dictionaries, which signing JSON isn't.
  • Works for nested dictionaries, which other algorithms like the AWS algorithm don't. I think allowing nested objects/lists in the API is generally good (e.g., apply a list of transaction dictionaries).
  • Relatively small signature algorithm (e.g., no dependency on msgpack or BSON).
  • Signature input is human-readable, which signing msgpack or something like that isn't.
  • If this is stupid, the "Consign1.0/" prefix lets us unstupid it later.

Overall doing a custom thing seems not-that-terrible so I went with it. It has a unit test! This algorithm is structurally similar to serialization schemes like msgpack.

I also made host + port part of the signature.