Populate URIs for TimestampVerificationResult

[haydentherapper]

Description

Currently, the URIs for TimestampVerificationResult structs are not populated on verification - 1, 2, 3, 4.

In order to implement this, we would need to plumb through the trust material, particularly the URI, from the verifier for each verified timestamp.

cc @phillmv

[cmurphy]

For the first instance - the verification result comes from the transparency log, which does not have a URI in the trusted root. What value do you expect for the URI here? baseUrl?

For the last instance it doesn't look like this is a verification result, just a transfer of data from the leaf certificate to the result struct. Should the URI be inferred from the issuing certificate authority?

For the other timestamp authority instances, the production trusted_root.json does not include a URI for the timestamp authorities, so most users viewing this verification result would get an empty string here, is that what you're wanting?

[cmurphy]

Partial implementation minus the unanswered questions #270

[haydentherapper]

As a meta comment, I'm not sure how we expect URI to be used. If this is just for logging purposes, then best effort population of the URI seems sufficient.

For the first instance, yea, base_url should be the correct value.

For the last instance, this looks incorrect, you shouldn't be verifying a certificate with its own timestamp, that would always verify.
As for the URI, I guess empty would be fine since there is no URI.

For the TSA, yea you're right. I think this came up once before as a blocker, that there is no way to tie a verifier back to its issuing TSA since that URI is only given on signing.

With all this said...Taking a step back, do you think URI is useful? Is there something else we can provide to note the timestamp's source?

[cmurphy]

With all this said...Taking a step back, do you think URI is useful?

I could imagine someone creating a policy that checked the URI in the verification result.

Is there something else we can provide to note the timestamp's source?

Maybe we could use the subject in the TSA leaf cert?

there is no way to tie a verifier back to its issuing TSA since that URI is only given on signing.

I may be misunderstanding, but I think it is possible to use the URI as long as it is given in a private trusted_root.json. I was just noting that it doesn't happen to be given in the p-g-i trusted_root.json. Maybe we could change that?

[haydentherapper]

I could imagine someone creating a policy that checked the URI in the verification result.

I think this would be OK, though I'd rather see policies around only around cryptographic keys. A URI seems more like human-readable output.

Maybe we could use the subject in the TSA leaf cert?

That seems good!

I may be misunderstanding, but I think it is possible to use the URI as long as it is given in a private trusted_root.json. I was just noting that it doesn't happen to be given in the p-g-i trusted_root.json. Maybe we could change that?

Ah you're right, missed that. Yes, we should encourage URI to be included. We're actually removing GitHub's TSA from the trust root, but I think it'd be sufficient to assume that the provided trust root would include a URI (fyi @kommendorkapten, for the trust root GitHub ships)

[kommendorkapten]

The TSA in sigstore targets is about to be removed as @haydentherapper mentioned. But the TSA should contain an URI. GitHub's trusted root contains the URI. I think the reason the Sigstore one does not contain is because we added it prior to the service was deployed, and we never went on to actually update it.

As @haydentherapper said, base_url for the tlog is what to use.

A general note on storing the URI in the verification result is more a nice to have, I'm not sure about any concrete use-cases. As the general approach to verify is to first provide the trust root, i.e the trusted set of TSAs, this means that if verification succeeds, it's verified against your trusted TSAs. So there is no real need to actually have a second policy against the verification result, as they only contain trusted TSAs. That said, there could be cases for such a policy, but I just can't think of it right now. But during verification it's nice to provide that list to the user:

verification successful, verified against:
* transparency log rekor.sigstore.dev
* TSA timestamp.foo.com
etc eetc

I.e. see the URI more for informational purposes as of now.