Add dsse tests for rekor v2 entries

[loosebazooka]

Similar to #175 for rekor v2. Will verify against clients before moving on.
Based off the bundles in : sigstore/sigstore-java#1031
Created using experimental dsse signer in: sigstore/sigstore-java#1029

This doesn't have failure cases for issues with the bundle other than the dsse structure

[loosebazooka]

Oh I need to add the custom trusted root...

[loosebazooka]

also need to rerun the generator on these using the conformance-oidc-token

[loosebazooka]

Not sure why python is failing here, but sigstore-java fails as expected (which is to be expected, I designed around it).

However sigstore-go seems to want to check signature in the timestamp before verifying the dsse properties. Every test fails with failed to verify timestamps: threshold not met for verified signed timestamps: 0 < 1; error: unable to verify signed timestamps: hashed messages don't match, instead of dsse error messages
I think I need to muck around with the timestamp too for these tests.

@jku when you get back, if I still haven't figured out the python failures, maybe you could take a quick look

[jku]

sigstore-python says

not enough timestamps validated to meet the validation threshold

with the reason from rfc3161-client (the timestamp client):

Certificates neither found in the answer or in the Verification Options.

Checking the timestamp in the test content:

jq -r .verificationMaterial.timestampVerificationData.rfc3161Timestamps[0].signedTimestamp < test/assets/bundle-verify/rekor2-dsse-happy-path/bundle.sigstore.json | base64 -d > ts.bin
openssl ts -reply -token_out -in ts.bin  | openssl pkcs7 -inform DER -print

there is indeed no certificate at all in the timestamp -- this is by spec but surprising to me.

So two potential things to look at:

• there is no certificate embedded in the timestamp -- this is legal but when I created the material for the first batch of rekor 2 tests, I'm pretty sure the signing certificate was included. Has something changed in timestamp.sigstage.dev?
• for some reason rfc3161-client fails to use the certificates that are in trustedroot in this specific case (when the timestamp does not contain a cert)... I think this might be a bug in sigstore-python: the rfc3161-client API is a bit too fancy, the sigstore-python code clearly tries to be as simple as possible and may take a shortcut it shouldn't. I will test this by tomorrow

[jku]

• for some reason rfc3161-client fails to use the certificates that are in trustedroot in this specific case (when the timestamp does not contain a cert)... I think this might be a bug in sigstore-python

I am 99% sure this is true. I will send a fix to sigstore-python when I have a moment to also write a regression test

[loosebazooka]

there is no certificate embedded in the timestamp -- this is legal but when I created the material for the first batch of rekor 2 tests, I'm pretty sure the signing certificate was included. Has something changed in timestamp.sigstage.dev?

I know we talked about this in person, but just adding in here for posterity. Sigstore-java timestamp requests, by default, do no request the certificate be embedded. Spec here: https://www.ietf.org/rfc/rfc3161.txt

Adams, et al.               Standards Track                     [Page 4]

RFC 3161               Time-Stamp Protocol (TSP)             August 2001


     --time-stamped
   reqPolicy             TSAPolicyId              OPTIONAL,
   nonce                 INTEGER                  OPTIONAL,
   certReq               BOOLEAN                  DEFAULT FALSE,
   extensions            [0] IMPLICIT Extensions  OPTIONAL  }

[loosebazooka]

updated tests and readmes. Weirdly sigstore-go is failing conformance (failure cases are passing?). I'll have to go check that out.

Since sigstore-java doesn't have an attest command yet, I'm still using the custom code in #sigstore/sigstore-java#1029

[jku]

the python fix is in now: If you modify the hash in selftest-requirements.txt to 3adc3d4a154a872621b0bf38a5e1a55cd1eecab4 (current main HEAD), the selftest should start passing

[jku]

Weirdly sigstore-go is failing conformance (failure cases are passing?)

we think the test cases look ok and have two clients that agree so I'm fine with merging this -- would be good to look at this before we make a release though