TSA request message digest defaults to sha256

[ramonpetgrave64]

Client support for Rekor V2: sigstore-python

Description

The request to the Timestamp Authority defaults to sha512,

• sigstore-python/sigstore/_internal/timestamp.py

  Lines 95 to 97 in 2199d9b

  	timestamp_request = (
  	TimestampRequestBuilder().data(signature).nonce(nonce=True).build()
  	)

• https://github.com/trailofbits/rfc3161-client/blob/c331b83648355f57d529c1a7d3f4616637a8aa0f/src/rfc3161_client/base.py#L80-L81

but then when verifying, assumes sha256.

• sigstore-python/sigstore/verify/verifier.py

  Lines 188 to 190 in 2199d9b

  	# The Signer sends a hash of the signature as the messageImprint in a TimeStampReq
  	# to the Timestamping Service
  	signature_hash = sha256_digest(bundle.signature).digest

We should either explicitly request sha256, or implement the example logic to determine the what the correct message digest was. Or, wait for a fix in rfc3163-client's verify() that accepts a message, instead of a digest.

• https://github.com/trailofbits/rfc3161-client/blob/c331b83648355f57d529c1a7d3f4616637a8aa0f/README.md?plain=1#L93-L97
• Inconsistent API when building Request and Verifying Response trailofbits/rfc3161-client#130

Version

sigstore-python v3.6.2

Using TSA timestamp.sigstage.dev

[jku]

Well that seems like an obvious bug -- do we not have a test where we verify a timestamp produced/requested by sigstore-python?

We should either explicitly request sha256, or implement the example logic to determine the what the correct message digest was

I assume sigstore specs specify (or should specify ) what the correct choice is when timestamps are added in a bundle? We want the bundles produced by sigstore-python to be verifiable by other clients (and vice versa): making sigstore-python work with sigstore-python is only a partial win...

In any case

• We should get rfc3163 sorted: verify must at least try to use the hash that was used when creating the timestamp
• If you need the quick fix to unblock some other work I suppose we can change the hard coded value now but that seems like it will just break later (when we verify bundles produced by another client)
• I guess a third alternative is to access timestamp_response.tst_info.message_imprint.hash_algorithm() in our verifier to create the correct hash but this really feels like something rfc3163 should handle