Skip to content

Use timestamp time as pkcs7 verification time#174

Merged
facutuesca merged 5 commits into
trailofbits:mainfrom
jku:use-timestamp-time-as-pkcs7-verify-time
Jul 29, 2025
Merged

Use timestamp time as pkcs7 verification time#174
facutuesca merged 5 commits into
trailofbits:mainfrom
jku:use-timestamp-time-as-pkcs7-verify-time

Conversation

@jku

@jku jku commented Jul 21, 2025

Copy link
Copy Markdown
Contributor

Fixes #171. This is based on RFC 3161 Appendix B:

   B) The validity of the digital signature may then be verified in the
      following way:

      ...

      4)    The date/time indicated by the TSA MUST be within the
            validity period of the signer's certificate.

      ...

In other words, current time does not need to be within the validity period, only the timestamp time needs to within the validity time.

Without the changes the included test fails with

Unable to verify pkcs7 signature: ErrorStack([Error { code: 276824181, library: "PKCS7 routines", function: "PKCS7_verify", reason: "certificate verify error", file: "crypto/pkcs7/pk7_smime.c", line: 301, data: "Verify error: certificate has expired" }])

Details:

  • pkcs_verify() now accepts a python datetime as argument and uses it as a verification time parameter
  • _verify_tsr_with_chains() gets the timestamp time from the timestamp response and feeds it to pkcs_verify()
  • I think I got the python method call syntax right in rust but this was the first time I've done that so ....
  • Test data comes from the sigstore-conformance test suite, I'm not sure what the used TSA software is

jku added 2 commits July 21, 2025 12:10
This is based on RFC 3161 Appendix B:

   B) The validity of the digital signature may then be verified in the
      following way:

      ...

      4)    The date/time indicated by the TSA MUST be within the
            validity period of the signer's certificate.

      ...

In other words, current time does *not* need to be within the validity
period, only the timestamp time.

Without the changes the included test fails with

  Unable to verify pkcs7 signature: ErrorStack([Error { code: 276824181, library: "PKCS7 routines", function: "PKCS7_verify", reason: "certificate verify error", file: "crypto/pkcs7/pk7_smime.c", line: 301, data: "Verify error: certificate has expired" }])
On 32 bit systems this will start failing when the timestamp is in 2038.
@jku jku force-pushed the use-timestamp-time-as-pkcs7-verify-time branch from 4f88dfb to e052b98 Compare July 22, 2025 11:27
@jku jku marked this pull request as ready for review July 23, 2025 13:09
@jku jku requested review from DarkaMaul and facutuesca as code owners July 23, 2025 13:09
@jku

jku commented Jul 23, 2025

Copy link
Copy Markdown
Contributor Author

Maybe it's ready for review now?

FYI also @haydentherapper

@woodruffw woodruffw left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, although I no longer have commit bit here 😉

@facutuesca facutuesca left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Just a small suggestion, and could you add an entry to the CHANGELOG?

Comment thread rust/src/lib.rs Outdated
@Hayden-IO

Copy link
Copy Markdown

I wrote up my thoughts on this on sigstore/rekor-tiles#399 (comment). tl;dr - The spec is underspecified on how to handle expiration of a chain. I think it's a decision we need to make as an ecosystem whether we want a TSA expiring to cause an artifact to be distrusted, or even make it a policy decision down the line.

I'm OK with this interpretation from this PR, though we need all sigstore clients to do the same. We should also make it clear that the way that a client will distrust a timestamp signature going forward is by whether or not the timestamping chain is in TUF - if it's not, it's been revoked.

jku added 2 commits July 29, 2025 14:03
I'm avoiding annotating the variable explicitly as time_t since that
requires adding libc to dependencies: my assumption is that this still
"works" on 32 bit.
@jku jku requested a review from facutuesca July 29, 2025 13:08

@facutuesca facutuesca left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks @jku !!

@facutuesca facutuesca merged commit b9e49e7 into trailofbits:main Jul 29, 2025
35 checks passed
@jku jku mentioned this pull request Aug 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

certificate validity should be checked at time of timestamp, not at time of verify

4 participants