Implement OCI 1.1 discovery in verify-attestation

[falcorocks]

Summary

Resolves one item of #4335. This PR implements OCI 1.1 support for cosign verify-attestation. The implementation discovers attestations using the OCI 1.1 Referrers API instead of legacy tag-based discovery (.att tags), then extracts and verifies DSSE envelopes directly. This enables verification of attestations stored using modern OCI 1.1 specification (for instance Google Cloud Build SLSA build level 3 attestations!)

Release Note

• add experimental OCI1.1 support to cosign verify-attestation

Documentation

I don't think it's necessary, but I'm happy to write something!

[haydentherapper]

To confirm my understanding, this differs from what's been implemented because this is discovery of DSSE attestations stored in OCI referring artifacts, not Sigstore bundles?

If so, I have a couple of thoughts:

• This is going in the opposite direction that we want to take Cosign, to have it be a conformant Sigstore client where its outputs and inputs are bundles, not plain signatures or attestations. In a future major version of Cosign, our plan is to have verify-attestation exclusively verify bundles stored in referring artifacts.
• Without a bundle, you're missing the other verification material - the certificate or key hint, and the log proof. So we are still reliant on the detached verification material stored in either an annotation or in a referring artifact via the very-unsupported experimental-oci flag.
• On the note of this flag, I would rather not continue its proliferation, as it's confusing to have the default be bundles stored using the OCI 1.1 Referrers API but still have some functionality gated behind this flag. My plan was to remove this flag in a later revision when we also removed support for detached verification material.

Why not download the attestation via oras and verify it with cosign verify-blob-attestation? It not being in a bundle will be an issue longer-term, so you may also need to use cosign bundle create with that attestation and any other detached material. I'd be open to a cosign download verification-material, or something like that, that retrieves attestations and other verification material to construct a bundle, meant as a transitionary step towards using bundles exclusively.

[falcorocks]

To confirm my understanding, this differs from what's been implemented because this is discovery of DSSE attestations stored in OCI referring artifacts, not Sigstore bundles?

If so, I have a couple of thoughts:

• This is going in the opposite direction that we want to take Cosign, to have it be a conformant Sigstore client where its outputs and inputs are bundles, not plain signatures or attestations. In a future major version of Cosign, our plan is to have verify-attestation exclusively verify bundles stored in referring artifacts.
• Without a bundle, you're missing the other verification material - the certificate or key hint, and the log proof. So we are still reliant on the detached verification material stored in either an annotation or in a referring artifact via the very-unsupported experimental-oci flag.
• On the note of this flag, I would rather not continue its proliferation, as it's confusing to have the default be bundles stored using the OCI 1.1 Referrers API but still have some functionality gated behind this flag. My plan was to remove this flag in a later revision when we also removed support for detached verification material.

Why not download the attestation via oras and verify it with cosign verify-blob-attestation? It not being in a bundle will be an issue longer-term, so you may also need to use cosign bundle create with that attestation and any other detached material. I'd be open to a cosign download verification-material, or something like that, that retrieves attestations and other verification material to construct a bundle, meant as a transitionary step towards using bundles exclusively.

@haydentherapper thank you for the quick review! I agree with the future that you have in mind for cosign, and I'm happy about the changes that you see towards that end. Specifically here, I want to implement this in cosign because this code is what the sigstore policy controller uses to fetch attestations. I've opened a PR there (that I do not necessarily plan to actually propose, it's just an undocumented proof of concept for now) to demonstrate how this change enables the policy controller to work with attestations stored using OCI 1.1: sigstore/policy-controller#1892.

I want to make the sigstore policy controller work with in-toto provenance v1.0 attestations produced by Google Cloud Build, as google own admission control solution is not as good. GCB stores attestations using OCI 1.1, but it does not use Sigstore Fulcio for signing (I wish!) and it does not produce a bundle. At verification we must pass a reference to the kms address where the GCB attestor stores its public key. GCB does not provide any way to change how any of this work unfortunately... I have no insight at google intention with regards to the future of provenance attestations in GCB (do you? 😁). I would love for them to run their own Fulcio like Github does and for them to support the new bundle spec... but none of this is here now.

But meanwhile:

1. I felt that implementing this flag would be useful at cosign too, since right now the flag does not really work for attestations but it does for signatures, and that is a pity.
2. I felt that it would be easier to fix this here this way rather than at the policy controller.

As a compromise, would you be open to consider accepting this PR on v2 (v2.6.2?) until full support is there for OCI 1.1 discovery in cosign? I feel like the sigstore ecosystem would benefit greatly from improving interoperability between in-toto attestations producers and consumers before we all adopt the new bundle spec. In fact keeping it at v2 would make proposing a change at the policy controller simpler, as now v3 breaks a number of things there...