RFE: Support configuration to map image references to different sigstore deployments

[lcarva]

Description

There are cases where using the public Sigstore deployment is not an option, e.g. privacy concerns. Some organizations may opt to provide their own Sigstore deployment. Verifiers must then choose which Sigstore deployment to use when verifying an image, cosign initialize ....

Although that workflow works ok, it becomes increasingly difficult to use as the number of Sigstore deployment increases.

I propose a solution that encodes which deployment to be used based on configuration. For example:

[deployments.default.tuf]
mirror = "https://tuf-repo-cdn.sigstore.dev"

[deployments.default.rekor]
url = "https://rekor.sigstore.dev"

[deployments.acme-corp.tuf]
mirror = "https://tuf-repo.acme-corp.io"

[deployments.acme-corp.rekor]
url = "https://rekor.acme-corp.io"

[[matchers]]
image_ref = "registry.acme-corp.io/*"
sigstore_deployment = "acme-corp"

[[matchers]]
image_ref = "*"
sigstore_deployment = "default"

Before performing a verification, cosign (and friends) would consult this file to initialize the tuf root as needed. Of course, this would have to be done in a concurrency-safe manner.

[haydentherapper]

How do you see this being consumed by a verifier? A verifier doesn’t know the URL of the signing service in most cases because verification should be entirely offline. In that case, a verifier would need to explicitly note which TUF environment they trust, which you could also do by reinitializing the local TUF repo.

One way this could be implemented is merging all targets across TUF repos, but this gets a bit complex with verification policies - do you allow verification with targets across multiple TUF repos for a single verification?

Also related, there is a TUF proposal, https://github.com/theupdateframework/taps/blob/master/tap4.md, which is related to this idea of searching across repos.

If you wanted to explore this more, could you make a post on the clients slack channel or open an issue in Sigstore/sig-clients?

Cc @jku @kommendorkapten if yall have thoughts on this as well

[jku]

Are you aware of SigningConfig that was recently added to protobuf specs: https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_trustroot.proto#L150

SigningConfig seems to be solving parts of this ("how can the user configure half a dozen urls? How do we ensure this is not a complete usability mess that will lead to broken client configurations?"). The idea as I see it is:

• the client config is now just the tuf repository URL -- allowing tuf and rekor and all the other details to be selected separately is just asking for misconfiguration
• the TUF repository contains not just the trust root (trusted_root.json) but also signing config (signing_config.json) which the client can use to bootstrap itself. Signing config is the repository specific configuration that is not going to change per user

---

Comparing SigningConfig and your idea:

• I think you don't cover all of the little things that a client really needs to use different deployment (see SigningConfig fields)
• The "matchers" are not covered by SigningConfig -- this does seem neat and solves the problem of "how to avoid having to choose the deployment every time" . It seems like a completely container image specific solution though

---

Also related, there is a TUF proposal, https://github.com/theupdateframework/taps/blob/master/tap4.md, which is related to this idea of searching across repos.

TAP4 is about using multiple TUF repositories at the same time... but we really only want to download the correct trusted_root.json for this situation: you don't need to use multiple repositories at the same time for that. User just needs a way to choose the repository at runtime

[lcarva]

Agree with @jku's assessment regarding TAP4. "An AND relation" is the opposite of what I'm looking for here.

I raised this in the cosign channel a few months back and I was told that Signing Config is meant for creating signatures, not verifying them. I'm happy to pursue my proposal in terms of Signing Config. I believe that would be to simply create a declarative way to map certain artifact identifiers, e.g. image ref, to a Signing Config.

The current proposal is very specific to container images, but we can certainly make it more flexible. I'm just not that familiar with other artifact types.

If this all seems reasonable, I can create a new issue in sigstore/sig-clients with an updated proposal for further discussion.

Thoughts?