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