Add RFC3161 timestamps to signatures?

[wlynch]

Description

We should be able to add RFC3161 signed timestamps into signatures pretty easily.

Rekor does provide a timestamping authority today, but it's currently going through some changes that we would need to track, and potentially we might need to use another TSA altogether - sigstore/rekor#812

cc @nsmith5 @haydentherapper @dlorenc Any thoughts here? Is this something worth adding or is it not worth it?

[haydentherapper]

Why do we need signed timestamps? Are we gaining much benefit from this? If we're publishing the commit to the log, we have a witness to the signing. The added timestamp transparency doesn't add much.

RFC 3161 is also an old complex standard. I'd prefer to not proliferate its use.

[dlorenc]

I think here it's about compatibility. Git requires x509 s/mime signatures here and assumes RFC3161.

[haydentherapper]

If we're stuck with RFC 3161, then I'd recommend using a third-party TSA, probably not by default and probably making it configurable.

On the note of by default, this gets back to the larger question around the benefit of timestamping. It reduces the need for trusting the timestamp from Rekor, but there may be other ways to guarantee Rekor's clock is trustworthy. I'm fine with this an option for users that want to use timestamping, but I'd probably say to make this optional and off by default.

[dlorenc]

I think we should consider prioritizing this one. The RFC3161 stuff is kind of ugly, but it's integrated into openssl and git when it verifies these signatures. It would make it much easier for providers to support gitsign generated signatures, because they'd just have to add our trust root rather than integrate anything rekor-specific.

[dlorenc]

cc @znewman01

[znewman01]

+1 -- in theory, if you pointed Git at (1) Fulcio's CA and (2) a RFC3161 TSA, you could verify Gitsign signatures with no modifications to Git, just configuration. I think the advantages of that (for end users doing verification, and e.g. displaying "Verified" checkmarks on Git forges) outweigh the drag of the support burden.

I'm not 100% convinced that it will Just Work, but I'd bet we can get there.

[haydentherapper]

Planning to take a look at spinning up a rfc3161 server soon. I don’t think this is blocked though, you can easily use a third party TSA, and frankly it’s a better trust model since you aren’t relying on Sigstore to provide the signature over the time.

[haydentherapper]

@znewman01, are you saying that a Verified check mark occurs when using a TSA? I ask cause i don’t remember seeing this in the docs, I just saw info about the root certificate’s location.

[znewman01]

Planning to take a look at spinning up a rfc3161 server soon. I don’t think this is blocked though, you can easily use a third party TSA, and frankly it’s a better trust model since you aren’t relying on Sigstore to provide the signature over the time.

Correct, this issue is not blocked on a Sigstore-hosted TSA.

@znewman01, are you saying that a Verified check mark occurs when using a TSA? I ask cause i don’t remember seeing this in the docs, I just saw info about the root certificate’s location.

Sorry, that was sloppy. Let me try to be more specific.

The de facto standard for verifying x509 signatures is https://github.com/github/smimesign . smimesign supports a --timestamp-authority flag, and will check that the signature happened at an appropriate time.

If gitsign starts adding RFC3161 timestamps to signatures, then smimesign users should be able to verify gitsign commits for free! Just point smimesign at an appropriate TSA and the Fulcio root.

---

State-of-the-art for Git forges is a little grimmer:

Gitlab implements their own checks (against its own trust root), but seems to aim for rough compatibility with smimesign.

Confusingly, GitLab writes:

For a commit or tag to be verified by GitLab:
[...]The signing time must be in the time range of the certificate validity,

But gives no information on how the "signing time" is determined. The signing time is used here. AFAICT, it comes from the signature itself.

GitHub also validates S/MIME certs (against the web PKI trust roots). GitHub makes no mention (that I could find) to the time of a signature.

But it would be possible for the forges to support TSAs just like smimesign.

If gitsign started adding timestamps to signatures, and forges supported TSAs for the "verified" checkmarks, then they would get gitsign support for free! Just point at the Fulcio CA and some canonical TSA.