Replace the timestamping authority

[haydentherapper]

Description

The timestamping authority is being removed as per https://github.com/sigstore/rekor/issues/812. We will replace it with an improved timestamping authority that will live in its own repository or run as a separate service.

We can also take this opportunity to update to using a newer timestamp standard like Roughtime, since RFC 3161 is an older standard with ambiguous requirements.

[haydentherapper]

Relevant links:

• https://datatracker.ietf.org/doc/html/rfc3628 - For a TSA policy
• https://www.rfc-editor.org/rfc/rfc3161 - RFC for 3161
• https://datatracker.ietf.org/doc/html/rfc5816 - Updates for certificate inclusion to 3161
• Use of RFC 3628's policy ID - https://cs.github.com/?scopeName=All+repos&scope=&q=%220.4.0.19422.1.1%22
• Policy requirements as per EU - https://www.etsi.org/deliver/etsi_en/319400_319499/319422/01.01.00_30/en_319422v010100v.pdf
• More policy requirements - https://www.etsi.org/deliver/etsi_en/319400_319499/319421/01.01.01_60/en_319421v010101p.pdf

[asraa]

We will replace it with an improved timestamping authority that will live in its own repository or run as a separate service.

Agreed, this sounds good: rekor-tsa or something similar.

Before jumping the gun on implementing a new timestamping authority, should we consider more about how feasible it is for Sigstore to operate it's on TSA with full compliance.

If we can't reach the policy requirements for RFC 3161, we should definitely drop it. But it seems like the general Sigstore ecosystem may have a need for it, and having a purely OSS TSA is a worthwhile endeavor.

For Roughtime, there are only a few trusted Roughtime servers. The compliance requirements aren't listed on the RFC https://tools.ietf.org/id/draft-roughtime-aanchal-00.html, do we need a support team for it?

[haydentherapper]

Support is definitely something to consider for both of these. This is another reason to split timestamping services out, because we'll want a high SLO for these with a high QPS.

[haydentherapper]

I've begun this work, moving the old code into a new repo.

[dlorenc]

I've begun this work, moving the old code into a new repo.

Should we file an issue in the TSC repo for this? Is it going to live in sigstore/ ?

[haydentherapper]

Yes, I'd like it to live in the sigstore org. I'll file!

[haydentherapper]

@dlorenc, would you prefer I start this now even with an incomplete repo, or wait until I've finished moving all of the code?

[dlorenc]

@dlorenc, would you prefer I start this now even with an incomplete repo, or wait until I've finished moving all of the code?

It doesn't really matter, we can create it as an empty repo or wait until later.

[dlorenc]

I don't see this as a GA blocker, but I really want to have it!

[haydentherapper]

Want to add this as a blocker? I’m working on it now, I do think this will be done by GA (will make the transfer request once the service is functional).

[priyawadhwa]

I believe only fulcio, rekor and cosign are in scope for GA. I think removing the TSA from rekor would be in scope, but setting it up as a separate service shouldn't be a GA blocker since we don't plan on releasing TSA 1.0

[dlorenc]

Yeah sorry, I mean I really like this idea and want the service, but don't think it needs to be part of GA.

[haydentherapper]

Agreed that we shouldn’t offer an SLO for a fresh service. We could scope it such that the TSA is complete but as a beta offering.

[dlorenc]

I'm not quite sure I understand. I see GA blockers as things were not comfortable declaring GA without.

We can launch the TSA whenever it's ready in whatever tier makes sense at the time, but I don't think it's a blocker here as much as I want to use it myself for gitsign and other services.

[haydentherapper]

I’ve mentioned it before, but I would like a way to prioritize GA blockers. There are some that are absolutely musts, like defining an SLO. There are some that we would really like, but if they slipped past GA, that would be ok, such as creating certain playbooks or features like this issue. Maybe we can discuss this more in a GA sync?

I see this issue as a nice to have but not critical. We are working on a proposal to embed signed timestamps in Rekor entries, and GitHub has expressed interest in operating a TSA in the NPM RFC, so having this service complete, even if not yet deployed, would be ideal.

[dlorenc]

I see this issue as a nice to have but not critical.

Right - I think that's the issue. Release "blockers" are only the absolute must-have critical things. Stuff that's a nice to have isn't a blocker, by definition.

[dlorenc]

Dropping as a ga_candidate per maintainer discussion.

[haydentherapper]

Available at https://github.com/sigstore/timestamp-authority