Design prevents inextricable long-term keys

[nbraud]

The design of the kms::KmsProvider trait means that users cannot keep the long-term secret out of system memory (the Ed25519 identity key, or whatever “seed” it is derived from) and can only bind the initial decryption of that secret to a local HSM or a remote KMS.

In other words, the current implementations assumes the key must be decrypted into system memory, and the delegation signed in software. This is not necessary: some commercially-available Hardware Security Modules can perform Ed25519 key generation and signing internally; the recent [Yubikey 5] is probably the most well-known and commonplace but other HSMs have supported Ed25519 for a while.

Would there be interest in implementing an API similar to RustCrypto's signature::Signer or signatory's, or using either of those abstractions outright, to support such usecases?

The main benefit is that a securely-implemented HSM can prevent the server's long-term identity key from being leaked, even if the host's operating system was compromised.

[int08h]

the current implementations assumes the key must be decrypted into system memory, and the delegation signed in software

Very good point. The current design is entirely software oriented for the signing mechanics. Probably due to a lack of good options (like the Yubikey 5 or some of the other HSM-ish implementations you linked to) at the time.

I welcome an implementation that evolves the design to use hardware and/or other methods for delegating signing to secure elements. Securing the long-term secret was the original motivation for the kms functionality to begin with. 😉

P.S. Apologies for the lateness of my reply.