review default signer & key selection

[jku]

It's maybe worth looking at the default set of keys signers? Some potential points to discuss

• is there a path to get SigstoreSigner in the default set? Maybe some sort of mini spec to define keytype, scheme and sig?
• should we remove untested signers from the default set? As an example it's pretty much impossible to maintain AWSSigner if there is no way to run the code (this is a suggestion to use as rule of thumb in general, see feat: Adds AWS KMS signing. #609 for AWS testing)
• is Sphincs maintained in the way we are comfortable with? both pyspx and sphincsplus itself feel a bit academic (there's not much maintenance action, the build system is... shall we say "minimal", etc)

[jku]

is Sphincs maintained in the way we are comfortable with? both pyspx and sphincsplus itself feel a bit academic (there's not much maintenance action, the build system is... shall we say "minimal", etc)

I wrote this thinking the sphincs signer and key are in the default set but they are not: I have no complaints against having the implementations in the source code like now

[jku]

Current default Signers:

CryptoSigner (file based keys)
GCPSigner (Google cloud KMS)
HSMSigner (yubikeys and such.)
GPGSigner
AzureSigner (azure KMS)
AWSSigner  (aws KMS)

Keys:

SSlibKey,
GPGKey,

I think this is fine:

• SPX, Sigstore and sigstore are not part of the default set, I think reasonably
• Vault is still a PR (Add VaultSigner and tests #800)
• GPG is arguable: using a complicated command line tool from a library makes me go ewww... but I guess it has a grand father clause since its been supported before

So I guess the default set is reasonable?

[jku]

Closing per previous comment