Have conformance test require signed timestamps for bundles v02

[steiza]

Summary

This is a bit of a philosophical question, although either sigstore-go needs to behave this way or we need to change test_verify_rejects_bad_tsa_timestamp that was added in sigstore/sigstore-conformance#112.

In that conformance test, we have a bundle with media type v0.2 that includes timestampVerificationData (so far so good). But it also includes an inclusionPromise.signedEntryTimestamp, and it expects verification to fail when timestampVerificationData is incorrect but inclusionPromise.signedEntryTimestamp is correct.

This change makes it so v0.2 bundles require valid timestampVerificationData and for those bundles ignores inclusionPromise.signedEntryTimestamp. It's possible that instead we want to require any information provided to be valid.

Release Note

NONE

Documentation

N/A

[haydentherapper]

Slack thread: https://sigstore.slack.com/archives/C03SZ6SHU90/p1702418056454379

It should be possible to have both a signed TSA timestamp and a SignedEntryTimestamp. To me, this is the same as having multiple signed TSA timestamps. A verifier will use its roots of trust to determine which timestamps to trust.

I'm thinking about treating the SET the same as the signed timestamp, removing the ability to configure this in policy, and instead relying on the configured roots of trust. This has some open questions: Do we simply ignore any verification failures and just search for one valid timestamp? Also, should verifiers be able to configure trusting a transparency log for timestamps vs inclusion proofs?

[kommendorkapten]

To re-iterate what I wrote in the slack thread:

@haydentherapper wrote:

A verifier will use its roots of trust to determine which timestamps to trust.

What I believe is that all signatures not under the closure of the trust root should be ignored.

[steiza]

The existing conformance tests supply the trusted root and the bundle (not an explicit policy), but with these changes the conformance driver can infer what the policy should be based on what's in the trusted root and the bundle.