Inflexible and incomplete public key distribution formats

[trishankatdatadog]

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.

[JustinCappos]

I'm not opposed to having a single, unique identifier. Who defines those? Would that be curated along with the spec, in a TAP, or somewhere else?

[trishankatdatadog]

I'm not opposed to having a single, unique identifier. Who defines those? Would that be curated along with the spec, in a TAP, or somewhere else?

I don't see a better place than the spec if we want things to be more standardized.

[JustinCappos]

I don't see a better place than the spec if we want things to be more standardized.

Yes, but the spec is slllloooooowwww to update (wait for @mnm678 to start pinging you about TAPs next week)... :)

Anyways, happy to discuss to see what the best path forward is...

[trishankatdatadog]

More real-world implications: sigstore-rust is unable to update due precisely to this issue...

[haydentherapper]

Another motivation is PQC. While I don't think the TUF spec should be opinionated on PQ signature schemes at this point, having the flexibility to support them long-term would be ideal.