Inflexible and incomplete public key distribution formats

TUF is supposed to be about crypto agility (vs what I call "crypto rigidity"), but unfortunately, the specification currently falls somewhere in the middle.

Some cryptosystems are deliberately simple so that they cannot easily be misconfigured, but others are deliberately complicated in order to allow for a rich variety of options. However, rigid assumptions in the spec have unfortunately made their way into implementations such as python-tuf and go-tuf. To take a few examples:

1. For the RSA key type, the spec (and thus implementations) uses the PSS scheme by default, but do not allow for configuring the salt lengths.
2. For the RSA key type again, the spec seems to have moved from from the PKCS#1 v1.5 scheme to PSS, which unfortunately broke go-tuf (even in v2).
3. For the ECDSA key type, the key type itself was "ecdsa-sha2-nistp256", when that should have been relegated to the scheme. This was true as recently as v1.0.31, and has caused problems for users such as Sigstore that depend on implementations like go-tuf (v1).

Anyway, my point is that the spec is not flexible enough to capture all the options in cryptosystems (regardless of whether we plan to officially support some of them or not). To compound the problem, the spec does not prescribe how different implementations across different languages should communicate unambiguously about the complete choices of any particular cryptosystem (i.e., it doesn't even talk about, say, other curve sizes defined by NIST for ECDSA).

I believe the very idea of key types and schemes are too error-prone and inflexible to describe all possible options in cryptosystems. (E.g., do we add salt lengths for RSA PSS by appending to the key scheme?) @mnm678 and Zachary Newman had proposed something like a single, unique identifier that can be used to capture all the standard configurations of standard cryptosystems. We would then have a complete mapping of such configurations which is larger than what we have now, but hopefully not large enough to be intractable. Regardless of the solution we arrive upon, the current state of affairs is not ideal.

Start by reading the specification v1.0.33 key file-format and ECDSA key-type sections, then compare the affected behavior in python-tuf and go-tuf. Done requires an agreed, unambiguous format that represents complete cryptosystem configurations without the current rigid assumptions.