You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 3, 2020. It is now read-only.
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:
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:
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.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
The text was updated successfully, but these errors were encountered: