signer API: review exceptions specifically for Key.verify_signature

[lukpueh]

API docs say that Key.verify_signature raises either UnverifiedSignatureError (Failed to verify signature), or VerificationError (Signature verification process error.)

As a consequence, we have the following pattern in current Key implementations:

try:
  - prepare key and signature (e.g. pop value from dict, deserialize)
  - verify signature

except implementation-specific "unverified signature"-error:
  - re-raise as UnverifiedSignatureError

except everything else:
  - re-raise as VerificationError

During review of #585, we discussed, if catching generic Exception was acceptable here, and if the method should pass through or raise other exception types like ValueError (e.g. if a keyids in key and signature don't match) or UnsupportedLibraryError.

The underlying question is, how should a client be able to handle (e.g. fail, ignore, recover) all types of verification errors? This includes failures due to key or signature formats, which are not supported by the library (at all, or because an optional dependency is missing).

---

EDIT: Let's also make sure that this is properly tested.

[lukpueh]

Some thoughts about requirements:

• Applications should be able to use a threshold verification algorithm, which only cares for valid signatures.
• This means, applications should be able to successfully parse metadata (using Key.from_dict), and attempt verification (using key.verify_signature), even with keys with unknown or unsupported keytypes or schemes.
• Known keytypes and schemes with invalid formats should fail parsing or verification.

[lukpueh]

• Applications should be able to use a threshold verification algorithm, which only cares for valid signatures.
• This means, applications should be able to successfully parse metadata (using Key.from_dict), and attempt verification (using key.verify_signature), even with keys with unknown or unsupported keytypes or schemes.

Currently, Key.from_dict raises an error on unknown keytypes and schemes. If the application just catches the error and skips the unknown key, it will break any signature verification of the container metadata, if it depends on canonicalisation. Which is the default for tuf and in-toto.