Add infrastructure information to trusted root

[loosebazooka]

For a given trusted root (especially with sigstore public good), the fulio/ca instance should optionally be allowed to specify a(or many?) sigstore specific trusted oidc provider(s).

Why? This allows clients to fully initialize their state from a single trusted_root.json, currently the only information missing is what would be required to initialize the oidc client for dex.

For example:

  "certificateAuthorities": [
    {
      "subject": {
        "organization": "sigstore.dev",
        "commonName": "sigstore"
      },
      "uri": "https://fulcio.sigstore.dev",
      //... new oidc providers associated with an instance of fulcio
      oidcProviders: [
        {
           "uri": "oauth2.sigstore.dev/auth"
           "clientId": "sigstore" // should default to this
           "wellKnownConfiguration": "/.well-known/openid-configuration"
        }
      ]
    },

1. This should be optional?
   • Yes? some instances may not want a web oidc option. Also allows us to clear the config is archived CAs.
2. should it be a list?
   • Yes? Allows for extensibility or single config for internal/external usecases
   • No? Client logic now has to check for existence/availability of endpoints as it decides which oidc endpoint to contact
3. should it be per CA?
   • Yes? It's not particularly harder for clients to parse this information.
   • Yes? As the trusted_root is updated, old CAs that are no longer active, will not need to define this. So repetition will be minimal.
4. is URI enough or should we have a bunch of other fields like client_id, well_known_configuration
   • Yes? Extensibility, custom configs

[haydentherapper]

No, you're correct, a rekor entry is not required - code.

This depends on policy, particularly whether we want the client to assert a default policy (what you're suggesting here would be at least one log contains the entry with a default log) vs the user presenting a policy (at which point they can specify which logs to query).

[loosebazooka]

or should it just query ALL logs it knows about (in the trusted_root) until it finds it? Which I think probably makes sense... so maybe this wasn't confusing at all and java just had a weird design.

[haydentherapper]

All as a default, with the option to specify a specific log if you know where it is, seems reasonable.

[kommendorkapten]

I think this may need further clarifications in the client spec, but I would treat it like this.

Signing

When a client is signing an artifact it should publish the signature on every transparency log in the SigningConfig.tlog_urls, unless explicitly instructed via signing options config to only publish to a specific set of uris. This approach will work until we start to see a "massive number" of transparency logs, which I'm not certain will happen in the near time. And also, each trust root config always controls the content of the SigningConfig, so even if there are 100+ tlogs out there, the operators of the trust root can always decide which X logs they would like to utilize. Here I would think X is a small number, maybe no larger than 5.

Verification

Here we don't need any update IMO. We already have support for M tlogs in the bundle, and N trusted logs in the trusted_root. The verification allows for a threshold value x to set. This way we can verify M entries against the N trusted logs and count the valid ones and compare against x. This logic is already present in a few client implementations.

[woodruffw]

I don't want to muddy this conversation even more... but how do we define which log to contact when a rekor entry is not provided during verification?

For sigstore-python, we're moving towards requiring an embedded inclusion proof, full stop. We accept v1 bundles only if they contain an inclusion proof, and reject them otherwise. Given that this is formally required in v2+ bundles anyways, IMO it's the simplest/most workable forwards path 🙂

That being said, I think the changes here don't affect the verification path anyways: the TrustedRoot already lists one or more tlogs for verifying, so a verifying client should not consult SigningConfig.tlog_urls anyways.

[loosebazooka]

Should clients be removing the option of verification separates? Only bundles now?

[woodruffw]

Should clients be removing the option of verification separates? Only bundles now?

That's the direction we're slowly moving to with sigstore-python, since "detached" verification is not really well specified. However, both the conformance suite and the spec itself currently allow for detached materials, so that probably requires an extensive separate discussion 🙂

[haydentherapper]

Here we don't need any update IMO. We already have support for M tlogs in the bundle, and N trusted logs in the trusted_root. The verification allows for a threshold value x to set. This way we can verify M entries against the N trusted logs and count the valid ones and compare against x. This logic is already present in a few client implementations.

As an aside, one thing we don't have currently that ct log lists do is the notion of operators, so that you can group a set of logs together under the same operator. Policy is defined by the number of operators, not unique logs, so you can't submit to two sharded logs by the same operator and pass a policy. We don't need this right now since we freeze old log shards and we don't have multiple logs operated by one shard though, and it should be straightforward to add later on.