Revise in-memory key representation

[lukpueh]

#251 discusses various consistency issues related to securesystemslib (TUF/in-toto) cryptographic keys. This issue splits out the concerns related to the in-memory representation of keys.

Current behavior:

The in-memory format of keys is similar to the "public key metadata format" with the following differences:

• keyids are always included
• the private portion may be included to use the key for signing

Expected behavior:

• Clear distinction between in-memory representation and "public key metadata format"

• Clear API for main tasks:

  • load stand-alone on-disk keys ideally from standard formats (see Revise stand-alone on-disk key format #309) for signing, signature verification, and to be included in tuf/in-toto metadata
  • load from 'public key metadata format', e.g. for signature verification
  • convert to 'public key metadata format' to be included in tuf/in-toto metadata
  • convert 'keyval's to formats supported by lower-level cryptographic functions used for signing and signature verification (see Revise public key metadata format #308 for discussion about consolidating 'keyval' formats)

• Consider a class-based model (see TUF ADR0004 for rationale)

[lukpueh]

We are currently transitioning to a class-based model using independent Signer (for private keys with a signing method) and Key (for public keys with a verify method; available downstream) interfaces.

Some thoughts about those classes are captured in #270 (comment).

[lukpueh]

Some notes about mandatory keyids in the in-memory representation of public keys:

• TUF and in-toto depend on keyids to delegate trust to roles (tuf) or functionaries (in-toto), thus a Key API that can be used to generate TUF/in-toto metadata requires keyids.

• The traditional TUF/in-toto signature wrapper requires keyids on both signatures and public keys for signature verification.

• DSSE makes keyids optional for signatures and signature verification but does not define public keys (see dsse#9), thus a Key object used to verify DSSE signatures may be required to contain a keyid.

• keyids are included in in-toto and excluded in TUF public key metadata (see #308). In both cases they are held in a map {"<keyid>": "<key>". Thus an API that creates Key instances from TUF/in-toto metadata (e.g. Key.from_dict) needs to be able to deal with both cases, e.g. parse keyid from key metadata if present, or require it to be passed as optional parameter otherwise. Similarly, API that serializes Key instances for TUF/in-toto metadata (e.g. Key.to_dict) needs to be able to create metadata with and without keyid included.

• keyids for securesystemslib-style keys are usually generated by hashing the OPLC canonical json representation of the public key metadata format. TAP 12 proposes more keyid flexibility for TUF public key metadata. Thus Key API that can be used to generate Keys from arbitrary key data must accept custom keyids in the constructor but may provide a fallback to generate keyids as described.