镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Inflexible and incomplete public key distribution formats #302

Open

Description

@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.

Activity

  1. JustinCappos commented on Mar 9, 2024

    @JustinCappos
    Member

    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?

  2. trishankatdatadog commented on Mar 11, 2024

    @trishankatdatadog
    ContributorAuthor

    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.

  3. JustinCappos commented on Mar 11, 2024

    @JustinCappos
    Member

    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...

  4. trishankatdatadog commented on Mar 15, 2024

    @trishankatdatadog
    ContributorAuthor

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

  5. Hayden-IO commented on Mar 19, 2024

    @Hayden-IO

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions