Ledger Validator app should allow for multiple keys

[jleni]

@jleni Will there be an equivalent to a key_id we can put into the config? e.g. for yubihsm we can have sth like keys = [{ id = "gaia-9000", key = 1 }]. I guess this makes sense here, too?
I'll add a TODO here and merge for now.

@jleni:
The validator app needs to rely on Ledger's crypto API for Ed25519 so in practice there is a Bip32 derivation path. At the moment, this is not exposed in the API but it would be actually possible to have different keys to allow for something like that. Actually, it could be even possible to have both secp256k1 and ed25519 in the same device.

Should we open an issue for this new feature?

Originally posted by @liamsi in #176

[tarcieri]

Note that when I start working on #60, one of the things I wanted to do was change those key IDs to be a tendermint::chain::Id, or potentially a list of them.

This is also important for solving #111 (which, IMO, is a launch blocker)

[jleni]

That sounds very good.
I would add a couple of fields like main_pubkey and path though key=[number] is already good enough.

keys = [{ id = "gaia-6000", main_pubkey="123....", key = 1 }]
keys = [{ id = "gaia-7000", main_pubkey="123....", key = 2 }]
keys = [{ id = "gaia-9000", main_pubkey="456....", key = 1 }]

If I have multiple devices plugged to the same KMS, I would like to identify the correct device by its pubkey and later derive signatures using some bip32 path.

From my side, the biggest changes will be on the app side rather than in KMS. But it is a good thing.

Actually, another thing that I would love to have.. is some kind of tmkms refresh that can be run to reload the config without stopping the kms. For instance, switching a device, etc. Maybe I should open an issue for that..

[tarcieri]

Yeah, we should definitely support hot config reloads. Feel free to open an issue.

I'd also be +1 for including some identifier for the public key in each config entry.