The currently recommended signer API usage pattern requires two steps to load a signer.

1. Take user inputs to load a public key and configure the signer URI
2. Take public key and signer URI to load a signer and sign

This separation of signer authorisation (e.g. delegate a key via TUF or in-toto metadata) and its usage is especially useful when the two steps are not performed in direct succession or not even on the same host.

However, the signer API may also be useful in a context, where the delegation happens out-of-band or after-the-fact. That is, the invocation is authorisation enough:

1. Take user inputs to load a signer and sign

Here, the separation from above is not intuitive nor efficient. The latter, because all current signing technologies in securesystemslib allow to infer the public key from the private key. Being forced to import the public key first, in order to then load the signer, adds unnecessary work (e.g. additional file read, network request, etc.)

Proposal

Add signer-specific API functions to load a signer including the public key material, e.g.:

class CryptoSigner(Signer):

    @classmethod
    def from_pem(private_bytes, keyid=None, scheme=None, password=None) -> CryptoSigner:
        """
        private_bytes: PKCS8/PEM private bytes
        keyid: use hex digest, if not passed
        scheme: use default for inferred key, if not passed
        password: treat as unencrytped, if not passed 
        """