Dustin Ingram

Agreed that we should allow users to verify any information that's available and not artificially prevent them from doing so. I do have concerns about this becoming unwieldy given the...

Yes, I think we're blocked on some movement on https://github.com/sigstore/cosign/issues/1964 so we can resolve https://github.com/sigstore/sigstore-python/issues/108 and have a way to verify arbitrary extensions (without needing to provide some GitHub-specific mechanism).

I think we should just support both as the same option for now, with no deprecation warning, to ensure this remains intuitive for `cosign` users as well as make sense...

(updated b/c I pasted in a cert from a different CI run by accident)

I agree! FWIW, the actual entry seems to be here: ``` $ rekor-cli get --log-index 532 --rekor_server https://rekor.sigstage.dev --format json | jq ."Body".HashedRekordObj.signature.publicKey.content -r | base64 -d -----BEGIN CERTIFICATE----- MIIFkjCCBRmgAwIBAgIUOebUzszQJFuWEaZmjIu8vdoRK+IwCgYIKoZIzj0EAwMw...

That's super weird! Where does the log index come from in that case?

This seems like a dealbreaker. From https://circleci.com/docs/2.0/openid-connect-tokens/#format-of-the-openid-connect-id-token > `aud`: The audience. Currently, this is a fixed value "\", a string containing a UUID that identifies the job’s project’s organization.

Marking this as blocked on https://circleci.canny.io/cloud-feature-requests/p/customizable-audience-claim-in-oidc-tokens, please upvote that feature request if you need this feature.

When we're ready to merge this, we should go to https://app.circleci.com/settings/project/github/sigstore/sigstore-python/advanced and re-enable "GitHub Status Updates" before rebasing.

Since we're trying to maintain parity with `cosign`, marking this blocked on https://github.com/sigstore/cosign/issues/2056.