Some 0.1 bundles fail to verify

[woodruffw]

See python/cpython#122785.

I did some preliminary triage on this: the cause of the problem is that some v0.1 bundles contain an inclusionProof without a checkpoint, which represents the source of signed time from the transparency log. This happened because versions of sigstore-python before 2.x didn't include the checkpoint in the bundle, as the inclusionPromise.signedEntryTimestamp was considered sufficient as a source of signed time.

We became more strict about this starting with 3.x, as part of requiring an inclusion check that's stronger than just a promise.

To fix this, we have a couple of options:

1. Synchronous: we can relax our signed time requirements to allow inclusion promises to be sufficient again. This would allow the current bundles on python.org to be verified as-is, at the cost of making bundle verification malleable w/r/t an unauthenticated field (the bundle's version)
   • The severity of this malleability is debatable (in this case both the proof and promise are signed by the same Rekor keys), but it's arguably a bad precedent to set and could become a more serious security problem in the future. Verification malleability like this is a classic footgun 🙂
2. Synchronous: we could perform an online lookup of the checkpoint, to allow inclusion proof verification. This would allow the current bundles on python.org to be verified as-is, at the cost of a network roundtrip (i.e., these old bundles could not be verified when the user explicitly sets --offline).
3. Asynchronous: we could perform a one-time update on python.org's bundles, to add the missing checkpoint field to each. This would not change the signature or any other cryptographic components, since it's purely an envelope level change, but it would require updating each.
   • To accomplish this, we could pursue the basic idea in CLI: Provide a subcommand for creating bundles from detached materials? #718 and implement a sigstore plumbing bundle upgrade (or similar) command that takes a bundle as input and updates to the latest version + fixes any inconsistencies.

CC @sethmlarson

[woodruffw]

Based on the behavior with other clients (sigstore/sigstore-go#259), I'm leaning towards option (3) -- (1) would allow verification where other clients reject this bundle as malformed, and (2) would require a silent online operation.

@sethmlarson would (3) work for you? Going that route would require a one-time update (but not resigning) of the bundles that are currently hosted on python.org.

[woodruffw]

Some more background context: sigstore/rekor#1566 emphasizes that an inclusion proof is not valid unless it's accompanied by a checkpoint (sigstore/rekor#1566 (comment) says this explicitly). So these bundles are indeed malformed, and clients can choose to handle them in one of two ways: either strictly (consider the bundle invalid) or permissively (verify only the SET and pretend as if the bundle doesn't have an inclusion proof). The latter would be a regression in behavior/strength of checks.

[sethmlarson]

(3) would work for us, I'm in the process of upgrading the release process to the latest Sigstore CLI so we're not generating any more malformed bundles.

[woodruffw]

I've begun work on a sigstore plumbing fix-bundle command here: #1089

[woodruffw]

This got me thinking about the inclusion promise as well: the previous documentation in the protobuf-specs wasn't clear about when the inclusion promise was optional, so I've clarified it here: sigstore/protobuf-specs#380

As a result of that, I'll also strengthen sigstore-python's requirement that the inclusion promise always be present since it's currently the only kind of signed time supported by this client. This shouldn't cause any breaking issues since, unlike the checkpoint, we've always included the promise in all bundles. However, to be absolutely certain, I'll only make that change once I'm done with an integration suite for python.org's releases 🙂

xref sigstore/protobuf-specs#380