Nick Mathewson nickm@freehaven.net wrote Tue, 2 Jun 2020 11:51:07 -0400:
One issue with the ssh-agent protocol as I see it is that it isn't originally designed for decryption or for high-volume usage. If we want to support those in the future, we'll need to make sure that we have an extension path for them in whatever vault tool we're using.
Good point. The extension mechanism defined for the protocol (see [draft-miller-ssh-agent-04] section 4.7) could be used for finding out if and how other types of operations are supported by the "vault" or "crypto daemon". This sounds like an invitation to complicate things though, like defining an extension function returning a new endpoint for a separate, more powerful, protocol. But maybe we should be able to constrain ourselves.
An alternative to using the ssh-agent protocol extension would be to have the internal key data type in tor include a protocol and an endpoint and let the user set things up through torrc (default "call_openssl://path/to/privkey"). This would allow for expressing that your signing keys have moved from "ssh-agent://path/to/ssh-agent.socket" to "new-and-shiny://path/to/powerful-crypto-daemon.socket".
And even if I don't like it much, there's always the option of defining something new, encompassing all our needs from start. To be weighed against the upside of being able to use already well established software for our specific needs of signing. One could argue that the minimal implementation of such a protocol, only for signing, could forward requests to a running instance of ssh-agent but the number of moving parts just went up. Simple is better here IMO.
[draft-miller-ssh-agent-04] https://www.ietf.org/id/draft-miller-ssh-agent-04.txt