search

sigstore / sigstore-python

A Sigstore client written in Python
https://pypi.org/p/sigstore
Other
232 stars 49 forks source link

[Meta] Support for Timestamp Protocol verification #1182

Open DarkaMaul opened 1 month ago

DarkaMaul commented 1 month ago

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.

/cc @woodruffw @facutuesca

jku commented 1 month ago

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 commented 2 weeks ago

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 :

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.

woodruffw commented 2 weeks ago

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) 🙂