Allow using a TSA instead of Rekor to validate certs

[priyawadhwa]

Right now, cosign assumes that every Fulcio cert has an associated entry in Rekor. The time that the entry was added to Rekor is used to verify that the signature happened during the cert's validity period.

We can get the same guarantee with a TSA. We'll need to refactor cosign to allow using a TSA instead of Rekor. We'll also want to store this TSA in the bundle so offline verification still works.

It would be nice to give users the option to choose between Rekor or the TSA!

[znewman01]

CC @haydentherapper I know you've talked about this before, I thought there was somewhere this was being tracked but I can't find it.

[haydentherapper]

This came up in #2194, when discussing how to handle expired certificates. Either a Rekor entry or a signed timestamp should suffice as a countersignature over time. A TSA doesn't offer public auditability however, so it's not exactly equivalent to a Rekor entry. A verifier may want both a timestamp and Rekor entry - The timestamp to provide a third-party assertion over time, and the Rekor entry to provide an auditable record.

I've been working on spinning up a timestamp authority - https://github.com/sigstore/timestamp-authority. Sigstore will deploy one, and any other interested community members can spin up their own TSA too.

Support for timestamps within Rekor entries, to provide immutable timestamps and replace the integrated time, is something that @cdris is working on! Ceri will be sharing a doc with the community shortly about how we can currently verify entries with a TSA, propose how to include timestamps in Rekor entries, and where we want to go from there.

The bundle that's been proposed does have support for RFC3161 timestamps, as we plan to add them into Rekor entries in the near future.

We don't have an open issue yet - Related is a discussion on Roughtime (sigstore/rekor#831), but @cdris will open an issue in Rekor soon.

cc @asraa also

[asraa]

It would be nice to give users the option to choose between Rekor or the TSA!

We can start with an env var for trusting a TSA root CA, but we also need a plan for inserting a TSA root CA into TUF. Just FYI: if Sigstore deploys one, no problem, but as we do this work I'll track changes we'll need fro mthe TUF side.

[haydentherapper]

Tracking issue - sigstore/root-signing#466

[hectorj2f]

FYI: I'm working on this feature in case anyone else is working on a similar direction.

[asraa]

@hectorj2f how do you plan to approach it?

I think we have a lot of efforts by many people in the same direction: e.g. the Sigstore bundle has support for RFC 3161 as well: maybe something like:

• Do you plan on making it work for OCI and blobs?
• How will the timestamp be formatted? RFC 3161?
• How will the root cert for the TSA be loaded or passed in?

[hectorj2f]

@asraa The idea is to get a first shareable version, so we can discuss more details or any considerations. I am making use of sigstore/timestamp-authority, so the timestamp is formatted to RFC 3161. Initially I am working on getting these changes for OCI, but blobs are also part of the effort (coming afterwards).

How will the root cert for the TSA be loaded or passed in?

In this draft version, i thought about relying on a KMS service, but I could be wrong. Maybe @priyawadhwa has some other thoughts around this decision.

I'd be happy to hear your thoughts about this approach.

[haydentherapper]

I think it would be good to sync on this to avoid duplicated work.

[priyawadhwa]

We can start with an env var for trusting a TSA root CA,

Yep +1, this follows the current pattern we have in cosign. We can stick with RFC3161 timestamps since that's what sigstore/timestamp-authority uses.

I think this will likely require some refactoring of cosign so we can easily use rekor vs the TSA for all commands.

@hectorj2f can start with adding in the env var, and TSA support for images. IIUC nobody else is working on that in cosign, so work shouldn't be duplicated. We can sync at the next GA meeting in two weeks.

[asraa]

@hectorj2f can start with adding in the env var, and TSA support for images. IIUC nobody else is working on that in cosign, so work shouldn't be duplicated. We can sync at the next GA meeting in two weeks.

Agreed! As long as we sync here and make sure the scope is right: for OCI it won't interfere with the Sigstore bundle format work, and is a little more easily extensible.

Fine with starting with an env var as well: when timestamp-authority is finalized and productionized, I'll include it in the TUF root so the trust is automatically fetched. sounds good with me

EDIT: Just maybe want to share with @cdris too: who is working on storing these timestamps in Rekor

[haydentherapper]

Now at a keyboard, so typing a bit more haha. Here's the current efforts, if I understand this ticket correctly and combining the ongoing work:

• Adding support in Cosign for using a TSA in addition to (or instead of?) Rekor, split up by OCI and blobs - I'd like to make sure we're super clear on the security properties of this too. If a TSA is used instead of Rekor, the signed timestamp should come from outside of the Sigstore domain.
• Spinning up a Sigstore-operated TSA
• Updating the TUF targets to distribute the Sigstore TSA root
• Adding support in Rekor for providing a timestamp (and subsequently adding support in Cosign for uploading a timestamp to Rekor)

All of these can be done in parallel. As Asra mentioned, no one is working on Cosign OCI support currently. Ceri is looking into working on Rekor. Meredith and I are looking into a Sigstore-operated TSA.

Let's find some time to sync if we don't get a chance in the GA meeting. It'd be great if we could also have a design doc for the Cosign work so we can chat more about the threat model, and understand more about using a TSA instead of vs in addition to Rekor.

[priyawadhwa]

Yep this ticket is only meant to cover that first point, adding support in cosign for using a TSA instead of Rekor, and we can definitely start with the OCI support. If you'd prefer to sync sooner we can try to set something up this week, or find time to chat in-person next week. I don't think there's anything blocking getting started on this in cosign though.

[hectorj2f]

Closing this issue! We added support for this feature request.