signer: Improved the "file-based signer"

[lukpueh]

Originally posted by @jku in #604 (comment)

NOTE: Adopt in docs/CRYPTO_SIGNER.md (remove signer registration)

[jku]

I no longer remember if CryptoSigner is the best place, but we should have a nice file-based signer (a signer that reads private keys from a file) in securesystemslib:

• securesystemslib examples really need a working file signer
• RSTUF has a file signer that works for them: we should move it somehow to securesystemslib
• the main "feature" in RSTUF is a environment variable that defines the "base directory" where the private keys are searched for: this matches e.g. the various KMS keys pretty well
• we should make it clear we don't recommend storing private keys on disk: this is mostly for examples and testing

TODO:

• Add links to RSTUF implementation here
• decide on correct place -- is CryptoSigner good or should we add a new signer?

[lukpueh]

An existing FileNameSigner with usage context can be found in RSTUF.

The implementation can be copy-pasted to securesystemslib with little change:

• the environment variable name ONLINE_KEY_DIR is rather RSTUF-specific, and should be more generic in securesystemslib
• as Jussi mentions above, a bit of discussion is left as to how FileNameSigner relates to CryptoSigner

[lukpueh]

how FileNameSigner relates to CryptoSigner

Currently, FileNameSigner subclasses CryptoSigner to make use of its sign, but add its own from_priv_key_uri. This makes sense for CryptoSigner, which is mainly characterised by its sign implementation, but could implement several different ways of accessing the private key material, e.g. from file path (CryptoSigner, SSlibSigner), file name (FileNameSigner), environment variable (SSlibSigner), etc.

The signer API, however, is not designed to separate the two tasks and all other signers, so far, are clearly characterised by both their sign and from_priv_key_uri methods together.

For the sake of a simple consistent interface, and given that file-based signing should be an edge case, I suggest we keep CryptoSigner only and update its from_priv_key_uri to behave like FileNameSigner. This still allows applications to subclass CryptoSigner for its sign method, and implement their own from_priv_key_uri.

[jku]

this might not be ready today but I'll handle it

[lukpueh]

Addressed in #759