#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)