[Meta] Support for Timestamp Protocol verification

[DarkaMaul]

Improve the support of sigstore-python for signing and verification APIs and CLIs for accepting signed time from a TSA versus an artifact transparency log (or both).

Description

We developed a new rfc3161-client to perform the parsing and generation of the Timestamp Request/Response objects.

This set of changes aims to integrate this new client into sigstore-python. We'll split the contributions into several PRs to make their review slightly easier.

• Write the TimestampVerificationData models
• Update TrustedRoot to provide the Timestamps Authority information.
  ⚠️ This field is planned for removal ( [targets v11] What to do with the GitHub TSA in trusted_root.json root-signing#1268 , Signing event: sign/update-targets-1 root-signing-staging#156 )
• Add the Timestamp verification mechanism itself.
• Add the possibility to sign the bundle with a TSA
• Add a CLI parameter require-timestamp to trigger the verification

/cc @woodruffw @facutuesca

[jku]

Can I get a short explanation for the use cases:

Support for Timestamp Protocol verification

vs

This field is planned for removal ( [targets v11] What to do with the GitHub TSA in trusted_root.json root-signing#1268 , Signing event: sign/update-targets-1 root-signing-staging#156 )

If the public good instance is not going to support this, is it worth the additional code and dependency in this client?

[DarkaMaul]

Rationale

The idea is to use a Timestamp Authority to attest or verify when the signature has been generated.

The current approach offers a way of verifying the signature time using the timestamp on the inclusion proof. However, this is unreliable because the time here is not verifiable. To quote the spec :

Timestamping. Currently, the Transparency Service includes a timestamp in its response to the Signer. This timestamp comes from the Transparency Service's internal clock, which is not externally verifiable or immutable.

Using a dedicated Time Source (such as a TSA) separates concerns between the timestamp and logging. A TSA provides a cryptographically verifiable, trusted timestamp designed for this purpose (following RFC 3161). This is particularly important for the "hybrid model" of certificate verification described in the spec, where signatures must have a valid timestamp while every certificate in the chain up to the root is valid.

And as an excellent point, it allows us to be more closely aligned with the spec:

For this reason, a Signer SHOULD get their signatures timestamped.

This also improves the verification flexibility where we can now support three different scenarios :

• Using only TSA timestamp
• Using only Transparency Service timestamp ( not recommended)
• Use both for additional security

Implementation design

Most of the required components are already available in Sigstore's protobuf models, and the main part of the work is to do some plumbing.
We also have a baseline implementation in sigstore-go, which we can follow for recommended practices for verifying the timestamp.

Some key choices :

The workflow for verifying a bundle should not change. As specified in the spec, if the bundle embeds signed timestamps, they must be verified, or the verification will end with an error.

• By default, a bundle generated by sigstore-python should include a signed timestamp, following the spec's recommendation that "a Signer SHOULD get their signatures timestamped"

[woodruffw]

Thanks for the summary @DarkaMaul. Yeah, from my perspective this feature is primarily useful to the "BYO PKI" case: the Sigstore client spec says that a bundle can use an RFC 3161 timestamp as a source of verifiable time instead of the inclusion promise time, and (to my understanding) RFC 3161 deployments are "dime a dozen" at larger companies.

I agree that this has marginal-to-no impact on public instances users, at least for the time being. The only case it might it if a public instance user directly modifies their trust config to require one or more TSAs, although I'm not aware of anybody doing that (or planning to) 🙂