Add comment that integration time is only trustworthy with an SET

[haydentherapper]

This was something that we ran into in sigstore-go, that the timestamp was used regardless if the signature over the timestamp was verified. This comment is meant to couple these fields together.

Summary

Release Note

Documentation

[woodruffw]

LGTM, although out of curiosity: does the signed checkpoint count as an alternative source of time? In other words, is the requirement:

inclusion_promise OR rfc3161_timestamp

or is it:

inclusion_promise OR signed_checkpoint OR rfc3161_timestamp

I ask because we might have a similar gap in sigstore-python: we require a signed checkpoint and verify the inclusion promise if the latter is present, but the latter is not currently mandatory.

(I think the ambiguity here originally came from the fact that signed checkpoints included timestamps in their ancillary data, but I'm not clear on whether this is still true...)

[haydentherapper]

It is inclusion_promise OR rfc3161_timestamp. A signed_checkpoint is not sufficient because it has no timestamp (and you're right, it used to, but that got removed because that timestamp was unrelated to time of inclusion).

In sigstore-go, we have verification of Rekor-related metadata and verification of RFC3161 timestamps. For the former, we a) verify an inclusion proof and signed checkpoint if present, b) verify an inclusion promise if present AND return integrated_time. We then verify RFC 3161 timestamps. Then we gather all verified timestamps together and try to verify the certificate with those timestamps.

[woodruffw]

Got it, thanks! This change makes sense to me, then, and it sounds like I need to strengthen the inclusion promise requirement within sigstore-python.