Add support for providing a trust root file for private deployments

[haydentherapper]

Description

Goal is to provide a simple interface for users to provide their own roots of trust for services (Rekor, Fulcio, CT log, TSA) by using the "trust root" specification.

Related to #3548, as the public good instance trust root will be provided through TUF.

This will obsolete many open issues around providing root key material. TODO is to find them all and link them here. Long-term, we will deprecate many of the CLI flags and environment variables in favor of using this trust root file.

[jku]

sigstore-python has added this via a --trust-config option that accepts a json file matching the ClientTrustConfig definition: this is a mashup of TrustedRoot and SigningConfig.

While SigningConfig is not yet available via TUF, in the future the two client configuration paths should likely be:

• (default) client fetches TrustedRoot and SigningConfig with TUF
• (BYO PKI case) user provides the client a ClientTrustConfig that contains TrustedRoot + SigningConfig. This could happen via a CLI flag or a configuration file

The second case could be handled by two separate options (--trusted-root and --signing-config instead of the combined --trust-config) as well but optimally clients should eventually agree on the same configuration method.

[steiza]

While working on #3139, we made some progress here, but also left some other parts undone.

We did add --trusted-root to verify-blob and verify-blob-attestation, but only in combination with --new-bundle-format (e.g. when cosign is calling into sigstore-go to perform the verification).

As more Sigstore / cosign users transition to using a trusted root file, it seems like a good idea to support --trusted-root in other cases as well, like if you're supplying material to be verified with flags like --certificate or --rfc3161-timestamp.

There's more than one way this could be done. Two likely implementations both require refactoring cosign a bit so collecting trusted verification content is more separated from collecting signed materials and verifying, and then we could either:

• parse out the trusted verification content in the file specified by --trusted-root into existing cosign variables, and use the pre-existing cosign verification paths

• lean into sigstore-go being the future preferred verification path by assembling the signed materials into a bundle, and have cosign always use sigstore-go when --trusted-root is specified

[haydentherapper]

We have somewhat already separated out how to fetch trust root material - each time a target is required, a TUF client is initialized and that target is requested, like https://github.com/sigstore/sigstore/blob/main/pkg/fulcioroots/fulcioroots.go. We instead pull trust root material from trust_root.json rather than each target file. That seems straightforward without much refactoring.

[steiza]

I started going down the path of using existing cosign verification paths but ran into a bit of a snag.

There's a substantial difference between providing a single certificate chain and supplying a trusted root file. The public good instance periodically rotates its signing material, and so in the public good trusted root file there are two entries for certificateAuthorities with different time ranges (and over time there will be many more). We could look at the signed material we're trying to verify and narrow down which certificate authority was valid during that time, except the validFor ranges of these certificate authorities overlap, and so there are definitely cases where we'll have more than one potential certificate chain to use.

Cosign's current verification path today assumes that you provide one certificate chain. We could change this, of course, to match the logic that's in sigstore-go, but that makes me lean in the direction of using sigstore-go whenever a trusted root is provided.

[haydentherapper]

@steiza This also gets into the idea of pools over chains which was discussed in sigstore/protobuf-specs#249 - moving towards allowing pools of trusted certs and push chain building to the x509 library rather than rely on a user to build their chains.

With what we have currently, I think we can do the same in Cosign even without pools - If you provide a trust root with multiple CAs, then we merge all roots together (assuming the last in the chain is the root) and merge all intermediates together into their respective pools, and then pass that to the verifier.

[haydentherapper]

We should also update https://docs.sigstore.dev/system_config/custom_components/.

[steiza]

I added sigstore/docs#327 to update the docs.

[cmurphy]

I think this has some overlap with #3548, should they maybe be combined?

[haydentherapper]

These issues should be distinct, though there might be some overlap when implementing.

#3548 should fetch the same set of targets as the current implementation, namely the individual target files by name, and also fetching targets by custom metadata using the v1 TUF client. This should effectively be a no-op, as we should fetch the same set of files using both clients. Once we've done that, we can then mark the custom metadata as deprecated.

#3700 is about providing a spec-compliant trust root bundle to begin deprecating the many options in Cosign to provide trust root targets. Technically you could use the v1 TUF client to fetch the trust root by file name as well.

The overlap is in the merger of both of these, using the newest TUF client to fetch the trust root. I think we can implement each as separate improvements - the TUF v2 client change should be largely invisible to users, and the trust root bundle option shouldn't be a breaking change as it will be in addition to other options.

To be discussed more: In Cosign v3, I'd propose removing support for the custom TUF metadata and the individual CLI flags for trust root metadata. I think this is a small enough breaking change that we should see adoption of Cosign v3 quickly.