tmkms is presently a signing oracle with no AuthN/AuthZ, and though it establishes an outbound TCP connection, it will connect to any remote peer that implements the Secret Connection protocol, i.e. while Secret Connection provides AuthN in the form of Ed25519 certificates, there is presently no AuthZ around which peers can connect to the KMS or use specific keys whatsoever. (Edit: mostly implemented)

Some mechanism is needed to authorize which remote peers are allowed to use which keys, e.g. some sort of Access Control List in the configuration. While there are other methods of AuthZ which might be interesting (ocap or other credential-centric systems), for now an ACL is probably the simplest.

@zmanian had suggested tagging each key in the signing keyring with a chain ID (which was already sort of happing in an ad hoc, stringly typed manner), in which case I think the ACL can map peer IDs to chain IDs they are validators for.

This is definitely a launch blocker, but also shouldn't be that difficult to implement. (Edit: mostly implemented) We already tag validators in the configuration with their chain_id, e.g.

[[validator]]
addr = "tcp://example1.example.com:26658"
chain_id = "gaia-9000"
reconnect = true
secret_key = "path/to/secret_connection.key"

Next steps:

• AuthN: ensure the remote peer ID matches the peer ID in the [validator] tcp:// string or else abort the connection. TODO: optional, make mandatory.
• AuthZ: Tag every key in the keyring with a chain_id, in a first-class manner with the tendermint::chain::Id type, and partition the signing keyring by chain ID (completed in Initial chain registry (fixes #60, #178) #205)
• AuthZ: When a signing request is received, only use the keyring for that validator's chain_id