Use securesystemslib signer API as intended

[lukpueh]

What do you want to share with us?

RSTUF does not use the securesystemslib Signer API as intended. Understandably, because the preferred usage pattern is not self-explanatory and not yet well documented.

But the API is actually quite simple and powerful. The underlying assumptions are that signers are authorized prior to being used, and that the authorization is known to the application when loading the signer. Both is true for RSTUF.

To load any signer for a public key, we can then use the generic Signer.from_priv_key_uri interface and pass it a URI to the private key material. The URI can e.g. contain a path to a local key file, or a keyid for a cloud kms, etc.

The nice thing about this usage pattern is that the application code does not need to know about the specific signer implementation.

Here is an implementation for a generic SignerStore to load, cache and use arbitrary signers for online signing in the RSTUF worker: f3d1d63

Implementation Notes:

• Includes signer-specific code in order to parse the existing signer-specific config into URIs. If we store URIs directly in config, we can make the implementation completely signer agnostic and further simplify the implementation.

• Works around the missing "public key" to "signer" mapping in config, by just picking the first signer in the store for any public key. This is similar to what ILocalKeyVault currently does, and should be fixed.

If we choose the proposed approach, I recommend updating the signer config format to list <keyid>=<signer uri> pairs and to automate the config creation in the RSTUF CLI.

An alternative approach, which works without additional config at all, is to include signer URIs with the public keys in root metadata, as custom fields. This is what tuf-on-ci does to configure online signers.

References

No response

Code of Conduct

• I agree to follow this project's Code of Conduct