3
  • What happens when the timestampers certificate expires?
  • If the code is now untrusted, can it be re-stamped without re-signing?
  • If not, what good does this timestamp do me if my cert is valid until the same date?

TimeStamperCertificate : [Subject]
                               CN=COMODO SHA-1 Time Stamping Signer, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB

                         [Issuer]
                           CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US

                         [Serial Number]
                           1688F039255E638E69143907E6330B

                         [Not Before]
                           12/30/2015 6:00:00 PM

                         [Not After]
                           7/9/2019 1:40:36 PM

                         [Thumbprint]
                           03A5B14663EB12023091B84A6D6A68BC871DE66B

3 Answers3

4

What happens when the timestampers certificate expires?

Literally, nothing.

If the code is now untrusted, can it be re-stamped without re-signing?

it is not correct statement. Timestamped signature remains valid even when all certificates in chains (both, signing and timestamping) are expired. This is what timestamping does -- keeps signature valid after certificate expiration. Timestamp in signature proves the signing time and it must be within all certificates validity periods.

Moreover, timestamped signature is still valid when signing certificate was revoked after signing time. Signature validation code can determine whether the signing certificate was valid (not revoked) at timestamping date and time.

You can read my blog post on the subject in more details: Digital signatures and timestamps

Crypt32
  • 5,750
  • 12
  • 24
  • Thanks for the blog. It's very informative. Who do you consider a reliable service for timestamping, considering distribution of expired root certificates?------ Also, just to be thorough, have you experienced this in a production environment? I have read that other people encountered problems after the timestamp certificate expired. Maybe this was because of missing certificates from the local store needed to validate the chain? – Jonathon Anderson Oct 16 '18 at 15:52
  • 1
    `Who do you consider a reliable service for timestamping, considering distribution of expired root certificates?` -- it is very opinionated question and is considered as offtopic here. `I have read that other people encountered problems after the timestamp certificate expired.` -- it depends on signature validation libraries. OS libraries often are pretty reliable. Custom code is often error-prone. The blog post was written against Microsoft CryptoAPI library, but can be extended to major OS libraries too. – Crypt32 Oct 16 '18 at 16:20
  • Thanks for the information. I realized later that my question of distribution is really a question of whether expired root CA's are available. I also realized I can handle this by maintaining a copy of the certificates and distributing them by GPO. Even if MS no longer distributes them, we will still have them available. Thanks again for the great blog. – Jonathon Anderson Oct 16 '18 at 16:50
  • This is not fully correct! If the TSA certificate of the timestamp has been revoked and the revocation either lacks the reasonCode extension, or the reasonCode extension is anything other than unspecified (0), affiliationChanged (3), superseded (4) or cessationOfOperation (5), then the timestamp will become permanently invalid (see section 4 of RFC3161 specification) and as such also the timestamped signature will not be valid anymore beyond its expiry date! It is thus always necessary to verify the TSA certificate using current and/or historical CRLs. – matthias_buehlmann Feb 16 '21 at 02:10
1

The accepted answer here is absolutely wrong! The timestamp is signed with a certificate issued for the specific purpose of signing timestamps. This certificate has its own expiration time and validity period, which is usually longer (much longer for sha256) than the validity period of a certificate issued for SSL/TLS/code signing, however, not infinite (answer to your 3rd part). Also, it is not your cert, it is on secure server. As soon as the certificate used to sign a timestamp expires, the timestamp expires as well. As per section 4.3 of RFC 3161, such a timestamp should be redone or notarized to renew the existing trust in the timestamp.

If the timestamping certificate is revoked (claimed as invalid by the CA that has issued it), there are two cases possible, as per sections 4.1 and 4.2 of RFC 3161:

If the revocation reason code indicates that the key has not been compromised but the TSA itself will not be operating in the future, then the timestamping certificate should not be used for timestamping in the future (after revocation). Previously made timestamps, however, don't become invalid. If the revocation reason code indicates code compromise, then all timestamps signed with the compromised certificate become invalid.

Moreover in one system there even existed OID 1.3.6.1.4.1.311.10.3.13 that forced any timestamp cert to be not used after expiration of signing cert. http://web.archive.org/web/20160405182742/https://forum.startcom.org/viewtopic.php?f=15&hilit=lifetime+signing&p=6827&t=2215

  • So that would mean if a system is left disconnected long enough for its timestamp root certificate to expire, it can no longer consider ''anything'' valid and could only be updated through other, non-cryptographic channels (like directly accessing its data storage)? – Medinoc Mar 05 '21 at 23:08
  • No, the system still has public keys of the timestamp tree (usually as well 3 certificates). For example Nvidia drivers have sha1 and sha256 signatures of 3 cert. each and a timestamp of 3 cert. each. That is 12 certificates. – Валерий Заподовников Mar 06 '21 at 16:57
0

What happens when the timestampers certificate expires?

You can extend this question to a more general one:

"Is a signature still valid if the signer's certificate expired?"

Well, it depends on which requirements are implemented by a validator.

Mainly the signer confirms the payload's authenticity, e.g. timestamp, with the signature. Some validators implementing certain signature standards consider any signature invalid in case any of the certs needed for validation expired in the mean-time. The reason is that the original assertion(s) cannot be longer securely verified because the formerly used crypto systems (e.g. signature algorithms, key-length) might have been weakened over time (better cryptanalysis). So these standards mandate that signatures have to be re-created every now and then. This gets very interesting if you think about archiving data for decades or centuries.

As an example consideration:

Would you still trust a code signature done with RSA-1024 and MD5 let's say 20 years ago?