pyproject: bump sigstore-protobuf-specs

[woodruffw]

This bumps sigstore-protobuf-specs to the 0.2.x series which, among other things, changes the required status of a few fields.

Draft until I figure out what needs to change on our client side.

[woodruffw]

To summarize what's happening here:

1. We now check the bundle version explicitly, and apply different requirements based on the version. More specifically, we require the inclusion proof on 0.2, or the inclusion promise on 0.1.
2. Internally, we enforce that verification begins with an inclusion promise, an inclusion proof, or both, but not neither. In other words: the weakest verification we'll do is an offline verification with just the inclusion promise or proof.

I need to think a bit more about (2) and ensure that we're doing what's stated above, but this should be consistent with both bundle formats.

[woodruffw]

One edge case that (I think) still needs to be covered here is around checkpoints. Here are the different states we can be in (limited to just inclusion proofs and checkpoints, not considering inclusion promises):

1. 0.1 bundle: no inclusion proof, no checkpoint
2. 0.1 bundle: inclusion proof and checkpoint
3. 0.1 bundle: inclusion proof but no checkpoint
4. 0.2 bundle: inclusion proof and checkpoint

When in online mode, all of these variants are handle-able: (1) and (3) should cause us to perform an online entry lookup, while (2) and (4) will be handled using the supplied inclusion proof.

When in offline mode, (1) and (3) are murky: it's unclear whether they should be error cases, whether we should verify the inclusion promise instead (if present), or something else. My intuition is that they should be error cases unless the inclusion promise is present, but it'd be nice to have some guidance/normative behavior here.

CC @znewman01 for opinions on the client behavior side + @haydentherapper for behavioral opinions as well 🙂

[haydentherapper]

My intuition is that they should be error cases unless the inclusion promise is present, but it'd be nice to have some guidance/normative behavior here.

I agree with this, but we should decide at what point we deprecate this behavior and mandate inclusion proofs. Do we have a deprecation policy in place yet?

For justification, an inclusion proof without a checkpoint should be considered invalid since there's no link to the log. If you can't query online or do not have a promise (both checkpoints and promises are signed with the same key, so while each commits to something different, they're still both commitments from the log), the client must return an error.

[woodruffw]

I agree with this, but we should decide at what point we deprecate this behavior and mandate inclusion proofs. Do we have a deprecation policy in place yet?

Agreed! I don't think we have a deprecation policy in place; CC @znewman01 as clients czar 🙂

[znewman01]

I think deprecation is up to each individual client. For instance, Go mandates a strict adherence to semver. Other ecosystems may have other conventions. You can look at the Cosign versioning policy for an example: https://github.com/sigstore/cosign/blob/main/VERSIONING.md

My preference is probably:

• library API should be pretty stable, new major version for brekaing changes (releasing new library major version is cheap)
• CLI behavior should try not to break without warning. But a rolling deprecation train is way easier than trying to cram every breaking change in at the same time.

---

+1 to offline-mode being totally offline and erroring out if additional information is needed.

[woodruffw]

This should be good to go now, and will unblock fixing the conformance tests; CC @di and @tnytown for review.

[haydentherapper]

@jku Do you want to take a look too?

[tnytown]

Is the inclusion promise/SET optional for 0.2 bundles?

[woodruffw]

Yep. 0.2 inverts the behavior here:

1. With 0.1, the SET is mandatory and the inclusion proof is optional;
2. With 0.2, the SET is optional and the inclusion proof is mandatory.

[woodruffw]

CC @di for review, if you have the time 🙂