Cosign cannot verify intoto attestations

[cperlman]

Description

Cosign is generating tlog entries with an entry type that isn't supported by Rekor.

Create blob attestation like so:

cosign attest-blob file-to-attest \
  --new-bundle-format --bundle attestation.bundle \
  --predicate ./predicate.json \
  --type slsaprovenance1 \
  --output-attestation ./attestation  \
  --rekor-url <rekor-url> \
  --fulcio-url <fulcio-url> \
  --identity-token "$token" \
  --rekor-entry-type intoto

So far so good but when we want to verify the attestation this happens:

cosign verify-blob-attestation file-to-attest \
  --bundle attestation.bundle \
  --new-bundle-format \
  --rekor-url <rekor-url> \
  --certificate-oidc-issuer <issuer> \
  --certificate-identity <identity> \
  --trusted-root=./trusted-root.json

Error: failed to verify log inclusion: unsupported entry type: *intoto.V001Entry

Looking at the source code, it appears that the problem is rooted here where cosign uses the intoto 0.0.1 specification, whereas rekor (via sigstore-go) expects version 0.0.2.

Version

GitVersion:    v2.4.1-3-g29568b22
GitCommit:     29568b22a0647fd85f38ebf25165293c973dedb5
GitTreeState:  clean
BuildDate:     2024-10-09T09:39:55Z
GoVersion:     go1.23.2
Compiler:      gc
Platform:      darwin/arm64

[haydentherapper]

Thanks for filing. As you noted, the issue is --rekor-entry-type intoto generates a Rekor entry with an intoto-v001 entry scheme. If you drop this flag, it will generate an entry following the dsse-v001 entry scheme, which is supported by sigstore-go.

Is there a reason you need the intoto type? That type is effectively deprecated in Rekor, which is why all Sigstore clients default to the dsse Rekor type.

cc @steiza

[cperlman]

Thanks for filing. As you noted, the issue is --rekor-entry-type intoto generates a Rekor entry with an intoto-v001 entry scheme. If you drop this flag, it will generate an entry following the dsse-v001 entry scheme, which is supported by sigstore-go.

Is there a reason you need the intoto type? That type is effectively deprecated in Rekor, which is why all Sigstore clients default to the dsse Rekor type.

cc @steiza

i'm aware that intoto is on its way out but we want it since it's seemingly the only way the attestation will be included in the rekor entry. is there a way that we can easily get the attestation associated with an artefact if we use the dsse entry type?

[haydentherapper]

A global attestation store is a tricky problem. Without knowing the contents of the attestations being uploaded, the store becomes a vector for spam. Additionally, a log should not be a source of truth for content (e.g. search index, attestation store) - it should only be a verifiable set of claims for an ecosystem.

Attestations should be stored alongside artifacts, and we've been working with package registries and CI platforms to implement support for storing attestations. Is there a particular ecosystem where you're producing attestations for?

I would be interested to see a community-run attestation store, but it will have to be more opinionated regarding the content of the attestation to avoid spam.

[cperlman]

I see how a community store could be a difficult problem but in our case we are hosting Sigstore locally with fairly restricted access so the spam aspect doesn't feel that likely to be an issue for us.

What is the recommended approach with regards to attestations if you do host Sigstore locally? Just having the attestations in a bucket but no obvious way to connect them with artefacts renders them rather useless.

[haydentherapper]

Thanks for the context, that makes more sense why you're using intoto Rekor types.

I'd suggest looking at content address storage (CAS), which is effectively what Rekor has implemented. Rekor stores attestations keyed by Rekor leaf hash in Google Cloud Storage. If you're deploying Rekor in a cloud environment, GCS/S3/Azure Blob would all be good options. I've also looked into https://github.com/google/ent as a lightweight CAS before as well.

As for what Sigstore can do to support this, we would like to split out the attestation storage from Rekor into its own dedicated service. If someone wants to add Ent or another CAS project to sigstore/helm-charts, I'd be supportive of that.