search

sigstore / cosign

Code signing and transparency for containers and binaries
Apache License 2.0
4.4k stars 540 forks source link

Allow using a TSA instead of Rekor to validate certs #2331

Closed priyawadhwa closed 1 year ago

priyawadhwa commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

This came up in https://github.com/sigstore/cosign/issues/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 (https://github.com/sigstore/rekor/issues/831), but @cdris will open an issue in Rekor soon.

cc @asraa also

asraa commented 1 year ago

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 commented 1 year ago

Tracking issue - https://github.com/sigstore/root-signing/issues/466

hectorj2f commented 1 year ago

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

asraa commented 1 year ago

@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:

hectorj2f commented 1 year ago

@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 commented 1 year ago

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

priyawadhwa commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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:

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 commented 1 year ago

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 commented 1 year ago

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