SCT verification should compare timestamp against CT log validity window

[haydentherapper]

Description

As a reminder, the purpose of validity windows is to mitigate two risks:

1. An old signing key for a service is compromised and produces an artifact after the service is turned down
2. A service that was turned down is brought back online and issues a cert or proof after it's been marked as rotated

I've been looking over the code and wanted to confirm if we are verifying validity windows for root metadata. Here's what I've found so far:

• TSA
  • The TSA validity window is compared to the TSA timestamp - https://github.com/sigstore/sigstore-go/blob/main/pkg/verify/tsa.go#L106-L111
  • [Potential bug] There is no comparison for the intermediate and root certificates.
• Rekor
  • The Rekor validity window is compared to the entry integrated time from the SET - https://github.com/sigstore/sigstore-go/blob/main/pkg/tlog/entry.go#L271-L277
  • [Discussion topic] There is no timestamp comparison during verification of a proof because there is no SET. We should not use the integrated timestamp because it is not signed. This means that we cannot verify a log proof was generated during a validity window.
• Fulcio
  • CA validity window is compared to the certificate's not before/after - https://github.com/sigstore/sigstore-go/blob/main/pkg/verify/certificate.go#L27-L32
  • [Potential bug] There is no comparison for the intermediate and root certificates.
• CT log
  • [Potential bug] It doesn't look like we compare the SCT timestamp to the CT log validity window in https://github.com/sigstore/sigstore-go/blob/main/pkg/verify/sct.go

In terms of how to structure the code, as is currently implemented, each service (CA, CT log, Rekor, TSA) should be responsible for comparing any of its artifacts that contain timestamps against the validity windows. TODOs below:

• [x] TSA compared against issued signed timestamps
• [x] TSA compared for each certificate in its chain
• [x] Rekor compared against issued SETs
• [x] CA compared against issued leaf certificates
• [x] CA compared for the root and intermediate CA certificates
• [ ] CT log compares against issued SCTs

The metadata I don't know how to verify is if a log proof was created during a log's validity window, since there is no timestamp. Using a certificate's timestamp is not accurate because a certificate may be logged long after a signing event. In the case of BYO PKI, there may also be no timestamps, if you log a signing event with a key. I think there's nothing to compare against in these cases.

[codysoyland]

Thank you for documenting these!

TSA [Potential bug] There is no comparison for the intermediate and root certificates.

I think this should be covered if I understand correctly. If you follow the code paths from tsaverification.VerifyTimestampResponse, it does eventually hit https://github.com/digitorus/pkcs7/blob/master/verify.go#L204, which uses the TSR timestamp as the CurrentTime when verifying the cert chain, which will verify that the TSR time is within the validity period of every cert in the chain.

I'll continue to look at some of these other potential bugs and comment individually if I find anything.

[codysoyland]

Fulcio [Potential bug] There is no comparison for the intermediate and root certificates.

Again, the CurrentTime is passed to cert.Verify, therefore the entire chain is checked. In this case, the leaf cert timestamps are used as the "current time" for the purpose of checking the validity period.

Edit: I would be in favor of changing this comparison to use observerTimestamp instead of the leaf cert times for clarity here. This block was written before observerTimestamp was an input to this func.

[haydentherapper]

Good find. Talking out loud to convince myself there's no issue:

• Let's imagine time exists from 0 to 100
• The TSA root and intermediate are valid from 10 - 90
• The TSA leaf is valid from 20 - 80
• The TSA service is marked as valid from 30 - 40
• A signed timestamp is issued at time 35
  • We check that the signed timestamp's time is during the service validity currently
  • To verify the CA chain, current time comes from the signed timestamp, which verifies it falls during the each cert's validity window
• A misconfigured service issues a timestamp is issued at 50
  • This would fail the current check since the signed timestamp was issued outside the service's validity window

So yea, TSA seems all good.

Edit: I would be in favor of changing this comparison to use observerTimestamp instead of the leaf cert times for clarity here. This block was written before observerTimestamp was an input to this func.

Good call, agreed.

[haydentherapper]

@codysoyland, I believe "CT log compares against issued SCTs" is still missing, so I've updated the title accordingly.