Remove the timestamping authority before GA

[haydentherapper]

Description

TSAs provide an alternative to transparency logs - Witnessing an event at a point in time, but without the ability to audit the signed timestamp issuances. Rekor operates a timestamping authority that:

• Issues signed RFC 3161 timestamps
• Writes the timestamps to the transparency log

The purpose of the TSA is that if you don't want to trust Rekor's internal clock, you can request a signed timestamp, and then provide a signed timestamp to the log. Rekor will include an inclusion time in the entry, but a client can choose to only use the signed timestamp time if they don't want to trust Rekor's clock. However, it adds no value for Rekor to operate both the log and TSA, especially in the same binary - The trust model is the same. You trust Rekor to operate its log without lying about the time, and the timestamping authority to do the same.

If you don't want to trust Rekor's clock, then you should request a signed timestamp from a third party TSA (FreeTSA/Digicert/etc), and include that in the log. Auditing the log can also mitigate concerns around a misconfigured/not honest internal clock.

There's some issues with the current implementation that need to be fixed:

• Doesn't respect the certReq bit
• TSA policy ID is invalid, we need to create a policy or use an existing one (and conform to the policy)
• The timestamping signing certificate is generated in memory, meaning after a reboot, there's no way to fetch a certificate chain to validate a previously issue timestamp
• Also because to the above, every instance of Rekor has its own certificate chain. This means it's difficult to fetch the correct certificate chain to validate a timestamp (1/number of instances chance)
• The timestamping certificate is chained off of the Rekor log key - Unexpected reuse of the key in my opinion

According to metrics, this API is barely used - 2/3 requests per minute. If I'm incorrect, please post in the issue if you're actively using the endpoints /api/v1/timestamp and /api/v1/timestamp/certchain.

We could consider keeping the TSA, but making it optional to run. However, for folks running their own internal instance of Rekor, there's no reason to operate a TSA from a trust perspective, unless you really need RFC 3161 timestamps, though I'd guess at that point you're probably operating an internal TSA already. If there's a use-case, please let me know! We'd still need to make the changes to make it compliant/functional. It's also worth noting that the RFC 3161 is an older RFC. There's newer approaches to trusted timestamps like Roughtime that are more well defined. If there was some need to keep timestamping around, I'd prefer we switch from RFC 3161 to Roughtime.

[haydentherapper]

cc @asraa

[nsmith5]

Definitely in favour of making the timestamping authority optional at least if we don't remove completely! Its a bit of an operational head ache getting a certificate authority set up for it and many operators don't want / need this functionality 🙏🏻

[dlorenc]

I think splitting it off makes sense but we should still support one somehow in sigstore. They're useful for compatibility into other ecosystems that require them, and logging the timestamp signatures into Rekor provides a form of timestamp transparency that's not handled elsewhere.

1-2 per minute is actually relative high. Rekor as a whole only takes 5-7 log entries a minute on average.

[haydentherapper]

Timestamp transparency is only useful if the timestamp authority runs independent of the log. Even as its own service, both will still be operated by the same community, so there is no increase in trust or transparency. You only get more trust when you use a third party TSA. I don't want to mislead users by operating both.

From the community meeting, based on the number of entries in the log, these metrics seem inaccurate. There's <200 timestamps in the log, so this feature is barely used.

At the very least, I'd prefer that we remove the TSA from the Rekor repository and move it to its own repo. There is some novelty in an OSS TSA service, but it's so different than Rekor that I'd like to fully decouple the two. Verification via the cert chain is currently broken, so it can be fixed after the code is moved out.

How does this sound?

[dlorenc]

Timestamp transparency is only useful if the timestamp authority runs independent of the log. Even as its own service, both will still be operated by the same community, so there is no increase in trust or transparency. You only get more trust when you use a third party TSA. I don't want to mislead users by operating both.

From the community meeting, based on the number of entries in the log, these metrics seem inaccurate. There's <200 timestamps in the log, so this feature is barely used.

At the very least, I'd prefer that we remove the TSA from the Rekor repository and move it to its own repo. There is some novelty in an OSS TSA service, but it's so different than Rekor that I'd like to fully decouple the two. Verification via the cert chain is currently broken, so it can be fixed after the code is moved out.

How does this sound?

Works for me. If the request rate is actually 2/3 per minute, we'll need to investigate before breaking the code because that's pretty significant. If it's just a few a day like @nsmith5 found, then we can just drop it. Any idea how to dig in?

[nsmith5]

Here is the data I have on rfc3161 entries:

NB: This is grouped by month so the counts really are minuscule

CSV of the data here:

query_result_2022-05-12T15 04 16.55594Z.csv

[haydentherapper]

I'm now seeing data consistent with Nathan's data. Initially I was viewing data using the Count aggregator - I think it wasn't aggregating how I expected. Switching the aggregation, we can see that the endpoint was only called for one day around early May.

I'll move forward with the PR to remove the TSA, and create an issue to track its replacement.

[dlorenc]

SGTM!