should support KMS key generation/import

[jku]

This depends on #445.

If we have KMS signing, we should consider key generation using the KMS: currently the process of rotating KMS keys would be very manual.

Key update process for a TUF key looks like this in general:

1. create key (locally, KMS, HW key)
2. • if KMS: export the public key
   • elif HW key: export public key
   • else: upload the private key to signing key storage
3. convert public key to TUF format
4. add the key to delegating metadata
5. get metadata signed by delegating keys

I think securesystemslib should aim to provide steps 1-3 (or at least 2-3) for all key types with easy method calls.

• This is already somewhat true for normal file based keys (just call keys.generate_*() and you're done)
• I am not sure if you can create a GPG key with securesystemslib but gpg.export_pubkeys() handles numbers 2 & 3

For KMS (this is based on GCP experience, should roughly apply to others):

1. key generation is a KMS method and requires some specific permission. Takes some service specific algorithm parameters and returns a KMS key identifier -- this step could still stay manual (but note that the algorithm parameters are needed in step 3)
2. public key export is a KMS method and requires another permission. Takes key identifier as input and returns public key content
3. TUF public key can be created using the algorithm parameters and the public key content

[jku]

cc @kairoaraujo based on earlier discussion

[jku]

Current thinking: I believe most users would not want code that creates new keys. At least I don't want to give that permission on my projects... So key generation is not a super interesting feature.

Key import however is something useful: this is implemented in #480

[jku]

Closing this: key import is supported (requires cloudkms.publicKeyViewer permission on google cloud), new key generation is not supported