Common keytypes collection

The specification actively does not require implementations to support specific keytypes, and only recommends supporting three specific keytypes. This is understandable but creates a situation where

• understanding which keytypes are supported by which implementations is difficult: this makes integrating TUF more difficult
• compatibility mistakes are easy to make when new keytypes are added or existing ones are modified (this has already happened several times)

There should be a list of keytypes that are either "recommended" (or in other words already commonly supported or clearly getting there), or "candidates" (keytypes that are either still experimental or have not been commonly supported yet). At least the former list should be tested in tuf-conformance. Even the former list should probably not be integrated into the spec. The lists don't need to live in a TAP either but I'm filing an issue here to say that a TAP could be a possible path forward.

Initial "Established Keytypes" proposal

As a starting point I would suggest this as the "Established Keytypes":

• ecdsa: ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521
• ed25519: ed25519
• rsa: rsassa-pss-sha256, rsassa-pss-sha384, rsassa-pss-sha512, rsa-pkcs1v15-sha256, rsa-pkcs1v15-sha384, rsa-pkcs1v15-sha512

These are the spec defined keytypes with slightly expanded scheme options.

Candidate Keytypes

I'd like this list to document the keytypes that are not yet commonly supported but have potential to develop. The bar to add things to this list should be quite low -- the idea is to point other developers to already existing keytype definitions if they are considering adding new experimental ones to their implementations

• sigstore: Fulcio
  • experimental "keyless signing" support in python-tuf via securesystemslib
  • draft TAP
• sphincs: sphincs-shake-128s
  • experimental PQC support in python-tuf via securesystemslib
• mldsa
  • No implementation exists but Sigstore project is currently evaluating PQC options
  • It's noteworthy that TUF use case would likely benefit from also having the prehashed algorithm variant (to enable signing with cloud KMS and harware keys) but those are lagging behind the pure variant

Start by reviewing the existing specification-defined keytypes, the tuf-conformance project, and the proposed TAP, including the linked securesystemslib definitions. Determine where the established and candidate lists should live and how the established list would be tested; done means the lists, criteria, and conformance coverage are documented.