Description

Joshuas original TUF PR and the "sigstore TUF client" design doc contain the idea of not fetching remote metadata if it's not required:

• the PR just checked if timestamp was expired or not
• the doc invents a "client metadata cache validity" configuration item

I did not include either approach in the merged TUF implementation as it felt unnecessary for v1 and not completely ready. The rough idea still makes sense: e.g. a CI calling sigstore verify a thousand times in a row should work, and there should be no need to make the root and timestamp requests that TUF clients normally do at startup more than once during those thousand calls.

I've made an experimental PR for python-tuf that tries to implement the timestamp expiry idea a bit more robustly but I don't think this is purely a python-tuf feature, sigstore-python is going to need changes as well:

• what is the policy that sigstore-python actually wants? is "timestamp is valid and verify succeeds" good enough for sigstore-python, or should there be an additional "we've updated tuf metadata less than X days ago" requirement
• how do we deal with e.g. verify failure because the signature uses a key/cert that we don't know about because we're using three days old certs and new ones were published yesterday? This is a bit complicated but certainly possible:
  • try to verify using tuf, allowing caching
  • if verify fails (maybe with specific failures), retry silently but this time force tuf update