Support for more than one key per (chain-specific) keyring
tarcieri opened this issue · comments
KMS was designed to support a one-keyring-per-chain model, where the same key can exist in multiple keyrings if so desired. However, at the level of an individual chain, the "keyring" isn't of much use as only one key per keyring is supported:
https://github.com/tendermint/kms/blob/master/src/keyring.rs#L96
For proposed features like key rotation, it would be immensely helpful if multiple keys could be active at the same time:
https://github.com/cosmos/cosmos-sdk/pull/5233/files
An open question is what is responsible for determining which key is "active". The KMS could potentially decide this via some value easily changed at runtime, or Tendermint could potentially signal which key to attempt to use, and then fall back to an old one in the event the new one fails. This would require including a key ID / public key in messages like SignProposal/SignVote:
https://github.com/tendermint/kms/blob/master/src/session.rs#L162
An open question is what is responsible for determining which key is "active". The KMS could potentially decide this via some value easily changed at runtime, or Tendermint could potentially signal which key to attempt to use, and then fall back to an old one in the event the new one fails. This would require including a key ID / public key in messages like SignProposal/SignVote:
If I understood ADR 016 correctly, Tendermint will have no knowledge of the change, so this leaves us only one possibility - "some value easily changed at runtime".
Correct @melekes. Unless that is, of course, we modify Tendermint. To keep things as simple as possible (initially), I would consider a runtime configuration/signaling method.