Skip to content
This repository has been archived by the owner on Jun 3, 2020. It is now read-only.

Support for more than one key per (chain-specific) keyring #368

Open
tarcieri opened this issue Nov 4, 2019 · 2 comments
Open

Support for more than one key per (chain-specific) keyring #368

tarcieri opened this issue Nov 4, 2019 · 2 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@tarcieri
Copy link
Contributor

tarcieri commented Nov 4, 2019

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

@tarcieri tarcieri added enhancement New feature or request question Further information is requested labels Nov 4, 2019
@melekes
Copy link

melekes commented Nov 6, 2019

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".

@alexanderbez
Copy link

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants