exp/services/recoverysigner: add mechanism to rotate of unique signing keys for all/subset of accounts

[leighmcculloch]

What

Add a mechanism to rotate the unique signing keys for all accounts or for a subset of all accounts.

Why

In #2343 we are adding support for randomly generated unique signing keys for each registered account. The recoverysigner since #2627 supports rotating its shared signing keys and when unique signing keys are added we should continue to support that capability.

#2343 will focus on adding the capability for a newly registered account to be assigned its own unique key, this issue will track separately the capability to rotate that key.

cc @stellar/vega-backend

[accordeiro]

This makes sense to me. So in other words: this issue covers building a mechanism to rotate unique signing keys, because right now we only had issues to cover rotating shared ones. Is that correct?

If so, one question that crossed my mind: once we support having a unique signing key per each account, what is the point of maintaining the concept of shared keys? I imagine from the client perspective they wouldn't know which are shared and which are not, so it seems like maintaining both concepts only adds more complexity on the recoverysigner side.

[leighmcculloch]

this issue covers building a mechanism to rotate unique signing keys, because right now we only had issues to cover rotating shared ones. Is that correct?

Correct, we already have rotation of shared keys implemented. No mechanism is needed to kick it off because they are configured as environment variables and so the mechanism is entirely human. A human generates a new signing key, adds it to the service configuration, then starts the service. The new for a mechanism to do the generation, encryption, and storing is only a requirement for unique signing keys once it is added in #2343.

what is the point of maintaining the concept of shared keys?

There are two reasons to maintain shared keys:

• There will need to be a long transition period because SEP-30 defines that old keys are always available for clients who have not yet updated their signers to their new unique signing key. We could consider making a job to import a signing key into the database for each account if we want to remove the shared key config.
• It make take sometime for all parties using this reference implementation to enable unique signing keys because it will likely require the use of a key management service like AWS or Google KMS. We could of course build the key encryption so that unique keys are usable without a remote key management service. (That might be worth doing anyway so that the reference implementation is not bound to a provider. cc @howardtw)
• It is also a simpler way to run a recoverysigner which has proven to be really helpful for testing.

I think we can remove shared keys if we see value in doing that, but even if we do we need a period where both shared and unique keys are in use, and we can evaluate at a later point if we should remove shared keys.

[mollykarcher]

Closing all recoverysigner issues