trustroot: Should OAuth issuer(s) be included?

[jku]

This is not a fully defined feature request but I wanted to write this down before holidays...

I was testing if a sigstore client (sigstore-python) really can choose the "sigstore instance" purely based on trusted_root.json: verification seems to work pretty well without any hard coded urls etc, but signing still has a an issue or at least a usability problem: A signing client can use trusted_root.json to select the Fulcio instance it uses, but it also has to choose the OAuth issuer (dex) URL and for things to work that issuer needs to be accepted by the Fulcio instance.

Should the sigstore_trustroot CertificateAuthority message include a parameter that describes the accepted OAuth issuers that this Fulcio instance claims to accept? Something like repeated string oath_issuers or even just a string oath_issuer -- the idea isn't necessarily limit the fulcio instance to just these issuers but help clients choose an issuer that is likely to work with the fulcio instance.

[kommendorkapten]

That is an interesting thought! So far I have mostly considered trusted_root.json from the point of a verifier.

If I get your question correct, we would list the issuers next to each CA, as an example the Public Good Instance Fulcio would countain [github.com, google.com, microsoft.com]? If say google creates a private sigstore instance that only accepts [google.com], would that complicate it for the client? I.e do we expect the list of issuers to always be disjoint?

The second question, would this imply that we need to sign and publish a new trusted_root.json if a new issuer is added to a Fulcio instance?

[jku]

If I get your question correct, we would list the issuers next to each CA, as an example the Public Good Instance Fulcio would countain [github.com, google.com, microsoft.com]?

otherwise yes, except this is about the non-federated issuer (dex). Correct me if I'm wrong but I believe both production and staging fulcio only accept a single issuer for "actual users" (https://oauth2.sigstore.dev/auth and https://oauth2.sigstage.dev/auth respectively)

[woodruffw]

Registering my support for this idea: I've also mostly been thinking about the trusted root from the verifier's perspective, but (IMO) it makes sense to allow signers to use it to convey their configuration/trusted state as well.

The underlying context here is a pattern that's recurred on a few of the Sigstore clients: to support instances other than PGI and staging, the clients have had to proliferate a large number of configurable knobs/CLI flags: the Fulcio CA cert(s), Rekor pubkey, OIDC issuing endpoint (Dex), etc. These knobs are all essentially co-variant, so placing them under a single --trusted-root BUNDLE input would (1) reduce overall cognitive complexity when using Sigstore with custom instances, and (2) eliminate unnecessary error states/handling conditions when flags are incorrectly mixed.

If I get your question correct, we would list the issuers next to each CA, as an example the Public Good Instance Fulcio would countain [github.com, google.com, microsoft.com]?

Just aligning with what @jku said: I was also thinking of this as solely the instance's own federated issuer, i.e. Dex or whatever else the instance chooses to use. So the PGI would only need to list https://oauth2.sigstore.dev/auth and nothing else.

[jku]

duplicate of #259