Skip to content

Feature discussion: Support Rekor-less repos (such as GitHub Sigstore) using TSA-based verification #539

@procr1337

Description

@procr1337

Description

We have been working on adding support for GitHub's Sigstore instance, which uses timestampAuthorities instead of tlogs/ctlogs (see https://tuf-repo.github.com/targets/66f65a7b9520d5e15f0bec628d6046ddd821ab732f8acdfceca21ec1c30c83a0.trusted_root.json)

We'd like to understand if there is interest in upstreaming such a feature, and how it should be designed. Currently we went a minimally invasive approach, which is highlighted by procr1337@77c35ee:

  1. TrustRoot is extended by a tsa_certs function and a TrustRootFeatures struct which describes whether the trusted root supports Rekor and/or TSA: https://github.com/procr1337/sigstore-rs/blob/tsa/src/trust/mod.rs#L24-L28

  2. Bundle verification is generalized by specifying a new VerificationStrategy as either Rekor or TSA https://github.com/procr1337/sigstore-rs/blob/tsa/src/bundle/verify/verifier.rs#L62. The requested verification strategy has to match the trusted root. If needed, a helper method could determine a "default" strategy for a trusted root based on its features (e.g., prefer Rekor if available). However it is useful to be generic, for example to allow TSA-based verification offline even for trust roots that also have Rekor configured. On top of these generalizations, it is quite easy to also generalize SigstoreTrustRoot to represent trust roots from arbitrary TUF repos. Here we also renamed SigstoreTrustRoot::new() to SigstoreTrustRoot::public_good() since it is now a special case. We also gave the option to communicate an "expected" feature set here, to make sure that callers can specify that they expect Rekor to be used, for example

This prototype code is well tested against the GitHub trust root use case in an offline scenario, but is not really production ready (e.g. missing proper unit tests)

Please let me know if you're willing to entertain some iteration of this as a potential breaking API change. In that case I'm happy to work on it more with your feedback and turn it into a full PR.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions