Allow bundles to contain sigstore entries

[loosebazooka]

The bazel BCR provenance proposal is proposing using intoto bundles (*.intoto.json) as the attestation storage format.

For compatibility with popular slsa generators (like the github attestation generator) and signing paradigms (sigstore), can we include sigstore bundles in the intoto bundle specificiation here https://github.com/in-toto/attestation/blob/main/spec/v1/bundle.md#data-structure ?

[marcelamelara]

Thanks for the issue @loosebazooka ! The bundle spec, as written, already doesn't prescribe what you can put into a jsonl formatted attestation bundle. So from my perspective, I think adding specific bundle/envelope implementations to our spec would only make it more prescriptive.

[adityasaky]

The bundle spec does require each entry to be a signature envelope, and I agree with not being too prescriptive in the spec about specific envelope types.

Separately, it looks like this spec doesn't meet ITE-5 perfectly. The attestation framework should recommend DSSE but otherwise just set constraints accepted in ITE-5 for the properties a non-DSSE format should meet to meet the in-toto specification. And this would of course also extend to the attestation bundle spec in what's allowed in a bundle?

[trishankatdatadog]

Agree: any discussion about what's allowed in an in-toto attestation bundle should first discuss what are allowed as envelopes, and it's not clear to me whether the Sigstore "Bundle" is an envelope that meets ITE-5.

[adityasaky]

Related: #21

[TomHennen]

FWIW I'd support allowing Sigstore 'bundles' in this bundle even if it doesn't meet ITE-5.

The rationale is that Sigstore is quite well adopted, if we don't allow it, then we cut off a potentially quite large use case.
In addition, allowing it in also provides a transition path away from the Sigstore format and to the DSSE. (Folks will be able to include the old Sigstore style bundles and the corresponding DSSE w/ Sigstore information embedded in the same file).

Further, the spec doesn't require each line to be an Envelope, it is only listed as 'SHOULD'.

Finally, what would happen if we don't allow this? People that have some Sigstore signed attestations would have to communicate those separately from any in-toto attestations (in DSSEs). E.g. if you use cosign and witness you won't be able to transmit the relevant attestations in the same file, you'd have to have multiple different methods to do so.

I'd suggest that it's better for the overall ecosystem if the bundle format is less opinionated at this layer as that will aid broader adoption.

[TomHennen]

Suggestion: include something along the lines of

"Sigstore formatted bundles MAY be included as individuals lines, but users SHOULD prefer to transition to Sigstore-in-DSSE when possible"

NOTE: I'm not sure I got the terminology right there.

[marcelamelara]

To be clear, while the Sigstore Bundle isn't an ITE-5 compliant envelope, I agree that we shouldn't restrict its use in in-toto Bundles. In fact, the Bundle spec already allows this: "each line within a Bundle SHOULD be an Envelope". I don't recommend making this requirement stricter.

[trishankatdatadog]

FWIW I'd support allowing Sigstore 'bundles' in this bundle even if it doesn't meet ITE-5.

I'd suggest that it's better for the overall ecosystem if the bundle format is less opinionated at this layer as that will aid broader adoption.

Makes sense, but TBF, I think we should also see an evolution of Sigstore "Bundles". For one thing, while Sigstore Bundle refers to a bundle of verification materials (i.e., cert chains or public keys), it unfortunately clashes with the Attestation Bundle, which is a collection of envelopes. My understanding is that the Sigstore Bundle was developed before DSSE Signature Extensions, but maybe it's time we formally discuss a proper Sigstore Envelope that reuses DSSE Signature Extensions? Ofc backwards-compatibility will be an important consideration there, but I think we should discuss it and decide one way or another. WDYT?

[TomHennen]

FWIW I'd support allowing Sigstore 'bundles' in this bundle even if it doesn't meet ITE-5.
I'd suggest that it's better for the overall ecosystem if the bundle format is less opinionated at this layer as that will aid broader adoption.

Makes sense, but TBF, I think we should also see an evolution of Sigstore "Bundles". For one thing, while Sigstore Bundle refers to a bundle of verification materials (i.e., cert chains or public keys), it unfortunately clashes with the Attestation Bundle, which is a collection of envelopes. My understanding is that the Sigstore Bundle was developed before DSSE Signature Extensions, but maybe it's time we formally discuss a proper Sigstore Envelope that reuses DSSE Signature Extensions? Ofc backwards-compatibility will be an important consideration there, but I think we should discuss it and decide one way or another. WDYT?

YES! 100% agree. Maybe that's something @haydentherapper can help with?

[adityasaky]

Are we worried about the validation of attestation bundle entries since a sigstore bundle may contain a dsse payload or it may not? It's more layers to unwrap to validate. Note that this is a question that'd extend to all consumers / implementers of this spec, not just for any validation tooling we provide for attestation bundles in this repo (we don't currently).

Further, the spec doesn't require each line to be an Envelope, it is only listed as 'SHOULD'.

Does this undermine ITE-5 even with #431? Can anyone bypass ITE-5's envelope requirements by wrapping any arbitrary envelope as an attestation bundle, perhaps even as the only entry in the .jsonl file? 😬

[TomHennen]

Are we worried about the validation of attestation bundle entries since a sigstore bundle may contain a dsse payload or it may not? It's more layers to unwrap to validate. Note that this is a question that'd extend to all consumers / implementers of this spec, not just for any validation tooling we provide for attestation bundles in this repo (we don't currently).

The entries are independent of the bundle itself. A consumer that understands the Sigstore format would be responsible for validating it themselves as they are today if those attestations are conveyed outside of an in-toto bundle.

Further, the spec doesn't require each line to be an Envelope, it is only listed as 'SHOULD'.

Does this undermine ITE-5 even with #431? Can anyone bypass ITE-5's envelope requirements by wrapping any arbitrary envelope as an attestation bundle, perhaps even as the only entry in the .jsonl file? 😬

It shouldn't? Bundles aren't authenticated and it's made explicit that attackers are able to tamper with the contents. As such consumers need to be properly verify each line independently.

Basically, no one should use the in-toto bundle for anything other than a convenient way to aggregate multiple attestations. If attestations being present in a bundle somehow introduces a bug in how individual attestations within that bundle are processed they're doing something wrong?

Relevant section?

[adityasaky]

Basically, no one should use the in-toto bundle for anything other than a convenient way to aggregate multiple attestations. If attestations being present in a bundle somehow introduces a bug in how individual attestations within that bundle are processed they're doing something wrong?

I agree with this from the perspective of how a bundle ought to be used. My question is whether having stricter requirements for an individual envelope distributed by itself and weaker requirements for the envelope being part of an in-toto attestation bundle incentivizes the use of bundles to bypass requirements while still using in-toto specification semantics. For example, if some envelope format E doesn't meet all the ITE-5 requirements, the spec seems to permit its usage (pending @marcelamelara's patch) directly for some in-toto attestation. However, serializing the same envelope into a .jsonl and calling it an attestation bundle would be fine? Does this gap entirely undermine the whole point of ITE-5 / the envelope.md part of the attestation spec?

[marcelamelara]

I don't think we're undermining the attestation spec by being less restrictive in the bundle because the bundle (really just a jsonl blob) is ultimately just a "transport" layer (agreeing with @TomHennen here).

Perhaps what this discussion points out is that we need to make the scope of the Attestation Framework spec clearer. We're concerned with authenticated claims about the SW supply chain. This covers all of the layers from envelope down into predicates. How these authenticated claims are transported/stored/represented to humans isn't (or IMO, shouldn't be) within the scope of the spec. We can make recommendations, but I don't think we should be more prescriptive than that.

So, with that said, here's a different take: What if we made the current in-toto bundle spec explicitly a recommendation, rather than a requirement in the Attestation Framework? This would require the following changes to our current spec a) Make it explicitly clear that jsonl is a recommended format for bundles, b) rather than describe a data structure, we should describe assumptions/expectations for ingesting in-toto attestations, and c) possibly remove the concept of a Bundle from the spec.

[adityasaky]

Reviewing this thread again: it looks like there's an answer for @loosebazooka's question? Is there something we can do to make things happen in the short and long term? E.g., short term -> use sigstore bundle in an in-toto attestation bundle, long term -> work in DSSE and Sigstore to support extensions so tools can eventually just store DSSE envelopes in an in-toto attestation bundle.

[haydentherapper]

I'll point to sigstore/cosign#4019 (comment) which I think is in line with this thread, that we need more composable utilities so that we don't have to be overly opinionated on envelopes, predicates, etc. I agree with a framework providing a recommendation, but allowing for deviations.

In the short-term, we can also create utilities to go between DSSE envelope <-> Sigstore bundle <-> COSE (for SCITT). Less optionality in formats lowers the burden for tool maintainers, e.g the Sigstore tool maintainers can stick with Sigstore bundles but we can still be compatible across ecosystems.