should support KMS signing

[jku]

Signing using a KMS would be useful: as an example a TUF repository could sign metadata with online keys without having access to the private key material.

The implementation should not be difficult but there are a couple of tricky bits:

• testing requires a KMS (mocking is not very useful in this case)
• the authentication to KMS is going to complicate setting up (but likely not the code)
• Signing (private) key identification may require a rethink to make the API most usable. See the comment below
• signing is the most important part, but smooth key changes (rotation etc) may require some additional functionality: key generation and public key extraction. See should support KMS key generation/import  #446

I have a draft PR #442

[jku]

Signing (private) key identification

The discussion that maybe makes sense at this point is private key abstraction in general -- in other words how to decide which Signer to use and how to initialize that signer. Since we don't have a solution for this, we end up with having to change code when the keytype changes:

SSLibSigner(key_dict) # here key_dict is expected to include public and private key 
GPGSigner(gpg_key_id)
KMSSigner.from_keyref(keyref, key_dict)

If there was a global way to identify a private key (privkeyref) that we can load from configuration, we could just have a single call that just works:
Signer.from_private_keyref(privkeyref, key_dict)
This method would act as a factory method/dispatcher that returns the correct Signer subclass -- see KMSSigner in this PR for an example that currently dispatches to just one subclass.

I wonder if the simple "privkeyref" string approach in the linked PR would actually work in general? The idea here is that the public key is provided -- we only need the private key details from the private key storage:

• GCP KMS:
  "gcpkms://projects/openssf/locations/global/keyRings/securesystemslib-test-keyring/cryptoKeys/securesystemslib-test-key/cryptoKeyVersions/1"
• GPG
  "gpg://C5A0ABE6EC19D0D65F85E2C39BE9DF5131D924E9"
• keyval.private content
  "raw://788b012147f9afe9c1a151...f94dc32a281baa"
• file with keyval.private content
  "file:///home/jku/rsa_key"

The point of keeping this as "just a string" is to make it easy to load the private key identifier from configuration and get a Signer without modifying code (this should make it easy to expose all of this via CLI tools if needed)

[jku]

I've moved the private key id proposal to #447

[jku]

This is done now I suppose: Google Cloud KMS is supported and working fine. Other KMS implementations can be added.