Time, and Signatures That Must Outlive Their Keys

34.0 What this chapter gives you#

1. You will be able to name the three mechanisms by which a good signature becomes unverifiable over time, and say which one is a problem of cryptography and which two are problems of record-keeping.
2. You will be able to explain what a trusted timestamp proves and, more usefully, the much longer list of things it does not prove.
3. You will be able to read an RFC 3161 timestamp request and token field by field in the raw bytes, and find the generation time, the accuracy and the serial number without a library.
4. You will be able to state what a timestamp authority must do under ETSI EN 319 421, including how close its clock must be to universal time and what it must do the moment it loses that certainty.
5. You will be able to say what “long-term validation” adds to a signed file, name the structures that hold it in a PDF and in a CMS signature, and explain why gathering it late is worse than not gathering it.
6. You will be able to distinguish the four baseline levels B-B, B-T, B-LT and B-LTA on sight, say what each costs, and pick the right one for a job.
7. You will be able to explain why an archive timestamp has to be renewed and what a renewal proves that the previous one no longer can.
8. You will be able to build a small RFC 4998 evidence record by hand and say when a simple renewal is enough and when you must rebuild the whole tree.
9. You will be able to plan a hash algorithm migration for an archive holding millions of signatures, using the SHA-1 case as the worked precedent.
10. You will be able to write an archive strategy with real intervals, real triggers and a named owner, and defend every interval in it.

A signature is a claim about a moment. The mathematics fixes the bytes and the certificate names the signer, but neither contains a clock. The whole apparatus is checked at some later instant against a world that has moved on: the signer’s certificate has expired, the list recording whether it had been cancelled was deleted years ago, the authority that issued it has closed, and the hash function everybody agreed on has been publicly broken by two researchers with a rack of graphics cards.

None of that means the signature was bad. It means you can no longer show that it was good. Those are different failures, and the difference is the subject of this chapter. A signature does not rot. The evidence around it rots, on a schedule you can predict, which means it can be prevented on a schedule you can plan.

The discipline that prevents it has an unglamorous name, long-term validity, and a simple central idea: capture the proof while the proof still exists, and then keep proving that you captured it when you said you did. Every mechanism in this chapter is a variation on that one sentence.

Two boundaries, stated once. What a signature means in front of a judge, and the three legal tiers of electronic signature that Europe, the United States and India each define differently, is chapter 33, “What a Signature Means in Law”. The public failures of certificate authorities, and the controls each produced, is chapter 35, “When a Certificate Authority Fails”. This chapter is about time.

The plain version#

The stamp that stops being a stamp#

Picture a district registrar’s office. Reshma brings in a deed transferring four thousand shares in a small company to Anil, and the registrar puts her stamp on it. The stamp is a metal die with a number on it, kept in a locked drawer, and the office issues each registrar a licence saying which die is hers and between which dates she is entitled to use it. Reshma’s registrar holds licence number 4097, valid from the first of January 2026 to the thirty-first of December 2028. The deed is stamped in March of 2026, comfortably inside those dates, and everybody goes home happy.

Fifteen years later there is a dispute, and a clerk pulls the deed out of the file. He looks at the stamp, then at the register of licences, and finds that licence 4097 stopped being valid at the end of 2028. What is he supposed to conclude?

The wrong conclusion, and the one people reach constantly, is that the deed is no good because the licence has expired. A licence with an end date says when the holder may make new marks, not how long old marks last. A driving licence that ran out in 2028 does not un-drive the journeys you made in 2026.

The right conclusion is more awkward: the clerk cannot tell. The stamp is consistent with a deed stamped in March of 2026, which would be perfectly good. It is equally consistent with a deed stamped last Tuesday by somebody who stole the die out of the drawer in 2030 and wrote an old date on the page. The mark itself carries no time, and the date written beside it was written by the same hand that made the mark.

There is a second problem, quieter and worse. Suppose the registrar’s bag was snatched in June of 2027, and the office published a notice cancelling licence 4097 from that date. A deed stamped in March of 2026 is still good, because the theft came afterwards. A deed stamped that August is worthless. To tell them apart, the clerk needs two things: the date the deed was stamped, and the office’s cancellation notices from around that date. The office keeps those notices for two years and then destroys them, because they take up space and nobody ever asks. It is now 2041 and they are gone.

So we have a genuine mark, made by a genuine die, on a genuine deed, that nobody can vouch for any more. Nothing was forged. The evidence evaporated while everyone was looking elsewhere.

A clerk who writes down the time and never reads the letter#

The fix for the first problem is a second office, and it has to be a different office, because the whole point is that its word does not depend on the registrar’s word.

Call it the clock office. It sits across the square, keeps an accurate clock, and keeps a day-book. You may bring it anything. The clerk does not read what you bring, and is not allowed to, because half the people who come to him are bringing documents they do not want read.

Instead, you run your document through a machine first. The machine reads every mark on every page and prints one short code, sixty-four characters long, made of the digits nought to nine and the letters a to f. The same pages always give the same code. Change one comma and the code changes completely, in a way nobody can predict or steer. And from the code you cannot get back to the pages, because the code is short and the pages are long. Call that code the fingerprint of the document.

Reshma’s deed is one hundred and sixty-eight characters of text:

Share Transfer Deed. KedByte Technologies Private
Limited. Transferor: Reshma Nair. Transferee: Anil
Kumar. 4,000 equity shares of INR 10 each. Executed
12 March 2026.

Its fingerprint, printed in groups of eight so it fits the page:

e02b11be 3e5b96d8 0c41b164 48cd9786
28c21126 9c0c8a42 2138fb81 06617873

You take that code across the square, and nothing else. The clerk copies it into the day-book, writes the date and the time beside it, gives the entry a serial number, and signs the line himself with the clock office’s own die. Then he tears off a carbon copy and hands it to you. The copy says, in effect: whoever brought this, and whatever it was, a document with this fingerprint existed at eighteen minutes past ten on the twelfth of March 2026, and the clock office puts its name to that.

Note what the clerk did not learn. He does not know the shares, the names, the price, or that it was a deed at all. He knows a code and a time. That ignorance is a feature: it is what lets a hospital, a law firm and a bank all use the same clock office without any of them worrying. Note also what the copy is worth on its own, which is nothing. It only becomes evidence when it is held next to the document, because only then can anybody re-run the machine, get the same code, and see that the two match.

Now go back to our clerk in 2041 with his awkward deed. He has the deed, the stamp, and the carbon copy from the clock office. He runs the deed through the machine, gets that same code beginning e02b11be, and matches it against the day-book copy. He now knows the deed existed in March of 2026. He looks at licence 4097, sees it ran to the end of 2028, and the expiry stops being a problem: the mark was made while the licence was live. That is the first repair, and it is the one everybody knows about.

The envelope of proof, packed while the proof still exists#

The second problem is not fixed by the clock office at all, and this is the part most people miss.

The clerk still needs the cancellation notices from March 2026, and they were destroyed in 2028. Knowing the date has not brought them back. Timing tells him which notice he needs; it does not tell him what it said.

So we need a habit rather than a device. On the day the deed is stamped, or soon after, while everything is still on hand, you gather the surrounding paperwork and put it in the file with the deed: the registrar’s licence itself, a full copy rather than a reference to a register; the licence of whoever issued that licence, all the way up to the head office whose authority everybody accepts; the office’s cancellation notice for that week, showing licence 4097 in good standing; and the same set again for the clock office’s own die, because the clock office has a licence too and it also expires. Then you seal the whole bundle in one envelope and get the clock office to fingerprint and date the envelope.

That last step is what makes the bundle worth anything. Without it, the cancellation notice in the file is just a piece of paper somebody could have slipped in yesterday. With the outer date on it, you can show the notice was in the envelope in 2026, when it was genuine, and the whole package stands or falls together.

The habit has a rule attached, and the rule is the entire discipline in one line: gather the evidence while it still exists, not when you need it. The cancellation notice for March 2026 is worth collecting in March 2026. In 2029 it is unobtainable at any price. There is no supplier. Nobody kept it.

Restamping before the old ink fades#

There is a third problem, slower than the other two, and it eats the repair rather than the original.

The clock office’s die also sits under a licence with an end date. The carbon copy from 2026 was signed with a die whose licence ran to 2029, so from 2030 onwards our clerk is looking at an old mark from an expired licence again, one level up. We have moved the problem, not solved it.

And there is something worse. The fingerprint machine is a machine, and machines get out-thought. Around 2038, say, a university announces that with enough computing it can now build two genuinely different documents that come out of the old machine with the same code. The moment that is true, a fingerprint from the old machine stops meaning “this document” and means “one of the documents that give this code”, and somebody with money can produce a second one to suit themselves.

Both problems have the same answer, and the answer only works if you are early. Before the clock office’s licence expires, and before the old machine is discredited, you take the whole envelope back across the square and get a fresh entry made over all of it with the current die and the current machine.

The new entry says that all of this existed in this exact form on this date. If that date is before the old machine was discredited, the old carbon copy inside the envelope was already there while it was still trustworthy, and it keeps its meaning. The new mark vouches for the old one. Do the same again before the new die expires, and again before the newer machine is doubted, and you have a chain in which every link was made while the previous link was still believed.

Miss one and the chain does not merely weaken, it snaps, and you cannot repair it afterwards. A fresh entry made in 2039 over a document whose only older evidence is a 2038-machine fingerprint proves that the bundle looked like this in 2039. Everything before the gap becomes assertion.

One deed, thirty years, on a single page#

Here is the whole plan for Reshma’s deed, from signature to the day the company’s records may finally be destroyed in 2056.

Notice that four of the seven rows are done because something is about to stop being true, not because something has gone wrong. That is the shape of the whole discipline: the work is done early, on a calendar, against an event that has not happened yet. There is no version of it that can be done in a hurry after the argument starts.

Where the plain version stops being true#

A date is not a truth, and it never was#

The clock office writes down that a fingerprint existed at a time. That is all. It does not say the document was correct, that Reshma agreed to it, that Anil ever saw it, or even that the document was signed. You can take the fingerprint of a blank page, a forgery or a confession and the entry looks identical.

The honest version: a trusted timestamp is a proof of existence at a time, and proof of existence is much smaller than people assume. It supports two inferences. First, that the document was not created after that time. Second, that anything which happened later, such as a key being stolen, cannot have influenced it. Every other conclusion comes from elsewhere in the system.

Expiry and cancellation are different, and confusing them breaks both ways#

The plain version treats the registrar’s expired licence as harmless once you know the date. That is right, and it is one of two possible policies, and the argument between them is live.

Under the first policy, the shell model, everything must be valid at the instant you are checking, so an expired signing certificate makes the signature invalid. This is what most software does by default, and it is why a two-year-old signed PDF opens with a warning. Under the second, the chain model, each element is judged at the time it was used: the signing certificate must have been valid when the signature was made, the certificate above it when it signed the one below, and so on, so an expired certificate is entirely normal.

Neither model is wrong. They answer different questions, and long-term validation is only coherent under something close to the second, which ETSI EN 319 102-1 formalizes as validation using proofs of existence at a past time. The point is that “is this signature valid” is not a well-formed question until you say at which instant you are asking, and under which model.

The honest version: expiry does not invalidate a past signature under the chain model, but revocation might, depending on when the revocation took effect and whether the revocation record says so. A certificate revoked with the reason “key compromise” and no stated date of compromise casts doubt on every signature it ever made, including the old ones, because you cannot show the key was not already in the wrong hands.

The clock office is not outside time#

In the plain version the clock office is a fixed point. It is not. Its signing key sits in a certificate with an end date, that certificate can be revoked, and the authority itself can close or be withdrawn from the national list of recognized providers.

So a timestamp is not self-supporting. To validate one in 2041 you need the authority’s certificate chain and its revocation information from around the time the timestamp was made, exactly as you needed them for the signer. A timestamp added to fix a long-term problem creates a smaller copy of the same problem. The system does not collapse into infinite regress only because each new timestamp is fresher than the thing it covers, and the chain terminates at whatever you are willing to trust today.

Late evidence can be worse than no evidence#

The plain version says gather the paperwork early. The stronger statement is that evidence gathered late may be useless in a technical sense, not merely unavailable.

Revocation information carries its own timing. A revocation list states when it was issued and when the next one is due. An online status response states the time the status was produced and, if the responder supports it, how far back its archive reaches. Collect a status response in 2031 for a certificate that expired in 2028 and a well-run responder will say it has no information rather than say the certificate was good, because it stopped tracking it. A badly-run responder will cheerfully answer “good” for a certificate it has never heard of, which is worse than silence, because it looks like proof.

There is also a subtler trap, the grace period. A certificate revoked at ten in the morning may not appear on a published revocation list until the next scheduled issue, so evidence collected five minutes after signing cannot show whether a revocation was already in flight. Careful practice is to collect after the next list is published, so the step is deliberately delayed.

Hash functions do not fail all at once#

The plain version says the machine gets out-thought and its codes stop meaning anything. That is too crude, and the crudeness matters enormously when you own an archive full of old fingerprints.

A hash function can fail in at least three ways, and they are not equally serious for archives. Collision resistance fails when somebody can produce two different documents with the same code, both of their choosing. Second-preimage resistance fails when somebody can take your existing document and produce a different one with the same code. Preimage resistance fails when somebody can go from a code back to a document.

For SHA-1, collision resistance is comprehensively gone, and second-preimage resistance has never been publicly broken. That distinction decides what you must do. If your archive holds SHA-1 fingerprints of documents that were already fixed and beyond an attacker’s influence, an attacker cannot manufacture a replacement for any particular one of them. If a document was supplied by somebody who knew it would be hashed with SHA-1 and archived, that person could have prepared a pair in advance and can swap them later.

The honest version: broken collision resistance retroactively poisons documents an attacker could have influenced before hashing, and does not retroactively poison documents they could not. Since you usually cannot prove which is which across a whole archive, the correct operational answer is still to migrate everything. But it is a precaution, not a fire, and knowing the difference is what lets you run the migration over three years instead of panicking over a weekend.

One signature from one company is a thin kind of proof#

An RFC 3161 timestamp token is a signed statement from a single organization. If that organization is careless, dishonest or compelled, the statement is wrong and nothing in the format reveals it. The design assumes an audited, supervised authority, which is why the requirements later in this chapter matter as much as the byte layout.

There is an older family of designs that assumes less. Linked timestamping, proposed by Stuart Haber and W. Scott Stornetta in their 1991 paper “How to Time-Stamp a Digital Document” in the Journal of Cryptology, chains each timestamp to the previous ones so that the authority cannot alter one without disturbing everything after it. Their later work with Dave Bayer replaced the chain with a tree, which is far more efficient. A commercial service built on this, Surety, began operating in January 1995 and has since published a value derived from its accumulated records as a classified advertisement in The New York Times each week, so that a physical, widely distributed copy exists that the company itself cannot alter. Most of the world uses the simpler signed-token model anyway, because it is easier to operate and because regulation supplies the trust the design does not. That was a choice.

Nothing in any file format makes anyone do the work#

The last and largest gap. Every mechanism in this chapter is voluntary and periodic. A file format can define an archive timestamp; it cannot come round in 2038 and apply one. A specification can say evidence must be renewed before the algorithms weaken; it cannot notice that they have. Long-term validity fails in practice almost entirely through this gap. What is missing, in most organizations that need it, is a named person, a calendar, a monitored list of algorithm deadlines and a budget line. The rest of this chapter gives you the mechanisms and then, at the end, the calendar.

The technical version#

Three decay mechanisms, three different clocks#

The three causes of decay have different timescales, different owners and different remedies. Treating them as one problem is why so many archive strategies address only the first.

The first is certificate expiry. Every certificate carries a notBefore and notAfter time, and the signer’s certificate typically lasts one to three years. Expiry is scheduled, known in advance to the day, and by itself harmless provided you can establish that the signature predates the notAfter time. This is what a timestamp fixes, and it is the only one of the three that a timestamp fixes on its own.

The second is loss of revocation data. To decide whether a certificate was in good standing at the moment of signing you need the issuer’s statement about it from around that moment. RFC 5280 section 3.3 requires only that an entry not be removed from a certificate revocation list “until it appears on one regularly scheduled CRL issued beyond the revoked certificate’s validity period”. After that the issuer may drop it, and issuers do, because lists that never shrink become unusable. Online responders behave similarly: RFC 6960 section 4.4.4 defines an archive cutoff extension precisely so a responder can declare how far back its knowledge reaches, with the example of a seven-year retention policy. This is not a cryptographic failure at all; it is a records retention decision made by somebody else, usually without consulting you.

The third is algorithm ageing. Hash functions and signature schemes have finite useful lives, measured in decades, and they end in public. This is the slowest of the three and the only one that can invalidate evidence you already hold rather than merely make it unobtainable.

The three interact badly. A timestamp fixes expiry but needs its own revocation data; collected revocation data needs a timestamp to be believed; both need re-timestamping before their algorithms age. No single step handles all three, and any product claiming otherwise is describing one of them.

Proof of existence, and validation at a past time#

The organizing concept is the proof of existence, usually shortened to POE: evidence that a given object existed before a given instant. ETSI EN 319 102-1, whose current version as of August 2026 is V1.4.1 of June 2024, builds its whole validation model on POEs. A timestamp token yields a POE for whatever it covers, and a POE for a container yields a POE for everything inside it, which is why timestamping a bundle is so much cheaper than timestamping each item.

Validation then proceeds backwards. You begin with what you trust today, a trust anchor and a set of algorithms you still consider sound, and find the most recent POE you can validate under today’s rules. That POE establishes that the material it covers, including older POEs and older revocation data, existed at its time. You then validate the next layer down under the rules that applied then, using the revocation data whose existence you have just established, and repeat until you reach the original signature. The whole structure is a ladder of POEs walking backwards in time, and every rung must have been created while the rung above it was still sound. A rung created too late is a rung attached to nothing.

Experts disagree about which validation model should be the default in general-purpose software: the shell model, evaluating everything at the current instant, is safer against sloppy evidence, while the chain model, which is what the past-signature validation process in EN 319 102-1 formalizes, is the only one that matches how documentary evidence works in law. Most PDF readers sit between the two and report a confidence indicator rather than a yes or no.

RFC 3161: the request, byte by byte#

The Internet X.509 Public Key Infrastructure Time-Stamp Protocol was published as RFC 3161 in August 2001. Parallel efforts produced ISO/IEC 18014, whose part 1 framework reached its second edition in 2008 and whose part 3 covers linked tokens, and ANSI ASC X9.95 of June 2005 for financial services. RFC 3161 won, it is short, it has aged well, and it has one substantive update, RFC 5816 of March 2010.

The request is a small DER-encoded structure:

TimeStampReq ::= SEQUENCE {
  version         INTEGER { v1(1) },
  messageImprint  MessageImprint,
  reqPolicy       TSAPolicyId  OPTIONAL,
  nonce           INTEGER      OPTIONAL,
  certReq         BOOLEAN      DEFAULT FALSE,
  extensions  [0] IMPLICIT Extensions OPTIONAL }

MessageImprint ::= SEQUENCE {
  hashAlgorithm   AlgorithmIdentifier,
  hashedMessage   OCTET STRING }

Only the imprint is compulsory. The nonce is a random number you include so that a replayed old response cannot be passed off as fresh; the authority must copy it back. The certReq flag asks the authority to include its own certificate in the reply, which you almost always want, because without it the token cannot be validated by anyone who does not already hold that certificate. The policy field lets you demand a particular service level.

Here is a real request for Reshma’s deed, generated on 18 August 2026 with OpenSSL 3.0.13, all fifty-nine bytes of it:

30 39 02 01 01 30 31 30 0d 06 09 60 86 48 01 65
03 04 02 01 05 00 04 20 e0 2b 11 be 3e 5b 96 d8
0c 41 b1 64 48 cd 97 86 28 c2 11 26 9c 0c 8a 42
21 38 fb 81 06 61 78 73 01 01 ff

Read it left to right. The 30 39 is a SEQUENCE of 0x39, fifty-seven, bytes. 02 01 01 is version 1. Then 30 31 opens the MessageImprint, forty-nine bytes. Inside it, 30 0d holds the algorithm identifier, whose object identifier 06 09 60 86 48 01 65 03 04 02 01 is 2.16.840.1.101.3.4.2.1, SHA-256, followed by 05 00, an explicit NULL parameter. Then 04 20 is an OCTET STRING of thirty-two bytes, and those bytes beginning e0 2b 11 be are the SHA-256 digest of the deed. The trailing 01 01 ff is certReq set to TRUE. There is no nonce and no policy in this one.

Fifty-nine bytes leave the building. The deed does not. RFC 3161 section 2.1 makes that a rule rather than a courtesy: the authority “shall not examine the imprint being time-stamped in any way (other than to check its length)” and shall not include any identification of the requester in the token.

Transport is deliberately dull. RFC 3161 defines the media types application/timestamp-query and application/timestamp-reply, with file extensions .tsq and .tsr, and describes carriage over electronic mail, plain files, a TCP socket protocol on port 318, and HTTP. In practice everything uses HTTP POST:

openssl ts -query -data deed.txt -sha256 -cert \
  -out deed.tsq

curl -H "Content-Type: application/timestamp-query" \
  --data-binary @deed.tsq \
  -o deed.tsr https://tsa.example.net/tsr

RFC 3161: the token, byte by byte#

The reply wraps a status and, if all went well, the token itself:

TimeStampResp ::= SEQUENCE {
  status          PKIStatusInfo,
  timeStampToken  TimeStampToken OPTIONAL }

TSTInfo ::= SEQUENCE {
  version         INTEGER { v1(1) },
  policy          TSAPolicyId,
  messageImprint  MessageImprint,
  serialNumber    INTEGER,
  genTime         GeneralizedTime,
  accuracy        Accuracy      OPTIONAL,
  ordering        BOOLEAN       DEFAULT FALSE,
  nonce           INTEGER       OPTIONAL,
  tsa         [0] GeneralName   OPTIONAL,
  extensions  [1] IMPLICIT Extensions OPTIONAL }

The failure codes in PKIStatusInfo are worth knowing because a badly configured client meets several of them: badAlg (0) for a hash the authority will not use, badRequest (2), badDataFormat (5), timeNotAvailable (14) when the authority has lost confidence in its own clock, unacceptedPolicy (15), unacceptedExtension (16), addInfoNotAvailable (17) and systemFailure (25). The fourteenth shows the design working: an authority that cannot trust its clock refuses rather than guesses.

A TimeStampToken is a CMS SignedData structure whose eContentType is id-ct-TSTInfo, object identifier 1.2.840.113549.1.9.16.1.4, and whose eContent is the DER encoding of TSTInfo. The signing certificate must contain the extended key usage id-kp-timeStamping, 1.3.6.1.5.5.7.3.8, it must be the only extended key usage present, and RFC 3161 requires that extension to be marked critical, so that software which does not understand time-stamping refuses the certificate rather than treating it as general-purpose.

Here is the TSTInfo from a token issued by a laboratory authority for the request above, one hundred and seventy-nine bytes of DER, broken across lines for the page:

30 81 b0 02 01 01 06 08 2b 06 01 04 01 eb 42 03
30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05
00 04 20 e0 2b 11 be 3e 5b 96 d8 0c 41 b1 64 48
cd 97 86 28 c2 11 26 9c 0c 8a 42 21 38 fb 81 06
61 78 73 02 02 2a 1a 18 0f 32 30 32 36 30 38 31
38 30 31 32 34 30 32 5a 30 0a 02 01 01 80 02 01
f4 81 01 64 01 01 ff a0 4a ...

Field by field. 02 01 01 is version 1. The 06 08 2b 06 01 04 01 eb 42 03 is the policy identifier 1.3.6.1.4.1.13762.3. The MessageImprint that follows is byte-identical to the one in the request, which is the first thing a verifier checks. 02 02 2a 1a is the serial number 0x2A1A, decimal 10778, unique to this authority. Then 18 0f introduces a GeneralizedTime of fifteen characters, and those characters spell 20260818012402Z: the eighteenth of August 2026, at 01:24:02, Coordinated Universal Time.

The 30 0a that follows is the Accuracy structure. Inside, 02 01 01 is one second, 80 02 01 f4 is context tag zero holding 500 milliseconds, and 81 01 64 is context tag one holding 100 microseconds. Then 01 01 ff sets ordering to TRUE, meaning this authority guarantees its tokens can be ordered against each other even when their times fall inside each other’s accuracy windows. Finally a0 4a opens the optional tsa field, a GeneralName holding the authority’s directory name.

Where ordering is FALSE, which is the default and the common case, RFC 3161 is explicit that two tokens may only be ordered if the difference between their genTime values exceeds the sum of their accuracies. Two tokens 400 milliseconds apart from an authority declaring one-second accuracy are simultaneous, and a system that reads them as sequential is reading something that is not there.

Two practical notes on the CMS wrapper. First, the signed attributes of the token typically include a signingTime attribute alongside the content type, message digest and signing certificate reference. That signingTime is not the trusted time; it is an ordinary CMS attribute, and the authoritative value is genTime inside TSTInfo. Software that reads signingTime and reports it as the timestamp is common and wrong. Second, RFC 5816 of March 2010 updated RFC 3161 so that the signing certificate may be identified by ESSCertIDv2 inside a SigningCertificateV2 attribute rather than the original SHA-1-based ESSCertID, and requires SigningCertificateV2 whenever any algorithm other than SHA-1 is used.

Verification at the command line, then the same file with one digit of the share count altered:

openssl ts -verify -data deed.txt -in deed.tsr \
  -CAfile ca.crt -untrusted tsa.crt
Verification: OK

openssl ts -verify -data tampered.txt -in deed.tsr \
  -CAfile ca.crt -untrusted tsa.crt
error ... ts_check_imprints:message imprint mismatch
Verification: FAILED

The failure is at the imprint comparison, before any signature mathematics is attempted, which is the correct order: there is no point verifying a statement about a document you do not have.

What a timestamp authority has to be#

The protocol is the easy half. A timestamp is only worth what the organization behind it is worth, and in Europe that organization is regulated in detail. ETSI EN 319 421, “Policy and Security Requirements for Trust Service Providers issuing Time-Stamps”, is the governing document, and its current version as of August 2026 is V1.3.1 of July 2025, replacing the original V1.1.1 of March 2016.

The requirements that matter most when deciding whether to believe a token are in clause 7.7.2, on time-stamping unit clocks. The unit’s clock must be synchronized with Coordinated Universal Time as defined in ITU-R Recommendation TF.460-6, within the declared accuracy, and that accuracy must be one second or better. Calibration must be maintained so the clock does not drift outside it. The authority must detect drift or a jump that takes the clock outside synchronization, and if it does, the unit must stop issuing timestamps. Leap second handling is specified, with the adjustment made in the last minute of the relevant month and its exact time recorded.

Clause 5.2 defines a best practices time-stamp policy, whose identifier sits under the arc itu-t(0) identified-organization(4) etsi(0) time-stamp-policy(2023) policy-identifiers(1). Clause 7.6.5 requires that a time-stamping unit certificate not be valid beyond the period the cryptographic algorithm in use remains fit for purpose, which is the standard quietly acknowledging the third decay mechanism. Clause 7.12 lists the events that must be logged: every key life cycle event, every certificate event, every clock synchronization event and every loss of synchronization. The token profile itself is ETSI EN 319 422 V1.1.1 of March 2016.

On top of this sits regulation. Under Regulation (EU) No 910/2014, the eIDAS Regulation, Article 3(33) defines an electronic time stamp as data in electronic form which binds other data to a particular time, establishing evidence that the latter existed at that time. Article 42 sets three requirements for a qualified electronic time stamp: it binds date and time to data “in such a manner as to reasonably preclude the possibility of the data being changed undetectably”; it is based on an accurate time source linked to Coordinated Universal Time; and it is signed using an advanced electronic signature or sealed with an advanced electronic seal of the qualified trust service provider, or by an equivalent method. Article 41 then supplies the payoff: an electronic time stamp is not denied legal effect merely for being electronic or non-qualified, and a qualified electronic time stamp “shall enjoy the presumption of the accuracy of the date and the time it indicates and the integrity of the data to which the date and time are bound”.

That presumption, which shifts who has to prove what, is the entire commercial reason qualified timestamps cost more than free ones. The mechanics of the shift, and the equivalent positions under United States and Indian law, are chapter 33, “What a Signature Means in Law”.

Long-term validation: putting the evidence inside the file#

Long-term validation, usually abbreviated LTV, means embedding in the signed file everything a future verifier will need, so the file is self-contained and no longer depends on servers that will not be there.

In CAdES, the ETSI profile of Cryptographic Message Syntax defined in EN 319 122-1, whose current version as of August 2026 is V1.3.1 of June 2023, this is done with unsigned attributes attached to the SignerInfo. The signature-time-stamp attribute, id-aa-signatureTimeStampToken with object identifier 1.2.840.113549.1.9.16.2.14, carries an RFC 3161 token over the signature value. The certificate-values and revocation-values attributes carry the full certificates and revocation responses, while complete-certificate-references and complete-revocation-references carry digests of the same material for cases where the data is stored elsewhere. The archive-time-stamp-v3 attribute, id-aa-ets-archiveTimestampV3, carries a token computed over a defined concatenation of the content, the signed attributes, the signature value and all unsigned attributes already present, together with an ats-hash-index-v3 attribute pinning down exactly which elements were included, so the computation can be repeated years later without ambiguity.

In PDF the same job is done differently, because a PDF can be extended without rewriting it. An incremental update appends new objects and a new cross-reference section to the end of the file, leaving every existing byte in place, which is essential: the original signature’s byte ranges must not move. The added material goes into a Document Security Store, a dictionary reachable from the document catalogue under the key DSS, described in ETSI EN 319 142-1 clause 5.4.2. It has four keys of interest:

<< /Type /DSS
   /Certs   [ 41 0 R 42 0 R 43 0 R ]
   /OCSPs   [ 44 0 R 45 0 R ]
   /CRLs    [ 46 0 R ]
   /VRI     << /0AE1C3A2AF703A6F2534D7C771ED5A6D840CB967
                 << /Cert [ 41 0 R 42 0 R ]
                    /OCSP [ 44 0 R ]
                    /TU   (D:20260326104402Z) >> >>
>>

Certs, OCSPs and CRLs are arrays of indirect references to streams, each holding one DER-encoded certificate, status response or revocation list. VRI is validation-related information, a dictionary whose keys say which material belongs to which signature; each key is the base-16 encoded, upper case, SHA-1 digest of the signature value it applies to. That SHA-1 is an index, not a security mechanism, and is the one place in this chapter where SHA-1 is unobjectionable.

Alongside the DSS goes a document timestamp: an ordinary PDF signature dictionary whose SubFilter is ETSI.RFC3161 and whose Contents holds an RFC 3161 token rather than a CMS signature, covering the ByteRange of the whole file as extended. The signature itself uses SubFilter ETSI.CAdES.detached. The layout of a file that has been through all of this:

+----------------------------------------------+
| original document objects                    |
| signature dict, SubFilter ETSI.CAdES.detached|
| xref, trailer                                 |  signed
+----------------------------------------------+
| incremental update 1                          |
|   DSS: certs, CRLs, OCSPs, VRI                |
|   doc timestamp, SubFilter ETSI.RFC3161       |  2026
+----------------------------------------------+
| incremental update 2                          |
|   DSS: fresh data for the 2026 timestamp      |
|   doc timestamp 2                             |  2029
+----------------------------------------------+
| incremental update 3                          |
|   doc timestamp 3, stronger hash              |  2035
+----------------------------------------------+

Each document timestamp covers everything above it, including the previous timestamps and the previous validation data. That is what makes it a chain rather than a pile.

The history is worth one line. This machinery first appeared in ETSI TS 102 778-4, the PAdES long-term profile of July 2009, revised that December, when the DSS dictionary was an ETSI invention layered on ISO 32000-1. It was later absorbed into the PDF standard itself, ISO 32000-2:2020, the second edition of PDF 2.0, of December 2020.

The four baseline levels, B-B to B-LTA#

ETSI defines four conformance levels and uses the same four names across CAdES, XAdES, PAdES and JAdES, so a single word describes the same guarantee in any format. For PDF they are in ETSI EN 319 142-1 V1.2.1 of January 2024, clause 6, with the detailed requirements in Table 1 of clause 6.3.

B-B is the basic level: the signed and unsigned attributes present when the signature is generated, and nothing more. It proves who signed what, with no protection against the signing certificate expiring and no evidence about revocation. It is what almost every “sign this document” feature produces.

B-T adds a trusted token proving the signature existed at a given time, a signature timestamp in CAdES or a document timestamp in PDF. This single addition solves the expiry problem and nothing else.

B-LT adds all the material required for validation, the full certificate chains and the full revocation data, embedded. A B-LT file can be validated with no network connection, provided the algorithms are still sound.

B-LTA adds one or more further timestamps over the whole assembly, including the validation material, and commits you to adding more over time. It is the only level that addresses algorithm ageing, and the only one that is an ongoing obligation rather than a single act.

There is an important asymmetry between the levels. B-B to B-T must be done within hours or days of signing, because you cannot go back and prove a document existed last year. B-T to B-LT must be done within weeks, while the revocation data is still published. B-LT to B-LTA can be done at any time before the algorithms weaken, but must then be repeated for ever. Those are three quite different operational commitments, and organizations routinely buy the third while implementing only the first.

One legal note, because it surprises people. Commission Implementing Decision (EU) 2015/1506 of 8 September 2015 obliges Member States that require an advanced electronic signature to recognize XML, CMS or PDF advanced electronic signatures at conformance level B, T or LT, referencing the ETSI baseline profiles of the day: TS 103 171 for XAdES, TS 103 172 for PAdES, TS 103 173 for CAdES and TS 103 174 for containers. As of August 2026 the Decision still names those older specifications, although the technical work moved long ago to the EN 319 122, 132, 142 and 162 series. A legal instrument and a technical standard age at different speeds.

Archive timestamps: what the chain actually protects#

An archive timestamp does not make the old signature stronger. It creates a new, independent proof that the old signature, together with its validation data and its previous timestamps, existed in exactly this form at a time when the algorithms used inside it were still considered sound.

That last clause is the whole thing. Consider a signature made with SHA-256 in 2026 and archive-timestamped with SHA-512 in 2035, years before any credible doubt about SHA-256. A verifier in 2050 who no longer accepts SHA-256 can still reason as follows: the 2035 timestamp is sound under today’s rules; it proves the 2026 material existed in 2035; SHA-256 was sound in 2035; therefore the 2026 signature was not forged by a SHA-256 attack, because no such attack existed at the only time the material could have been introduced.

Now consider the same signature archive-timestamped for the first time in 2050, after SHA-256 has been broken. The 2050 timestamp proves the material existed in 2050 and says nothing about 2026, because an attacker with a working SHA-256 collision could have produced the whole bundle in 2049. The evidence is void, and no amount of later timestamping repairs it.

This is why the rule is always stated as a deadline. ETSI EN 319 142-1 clause 5.4.3 puts it in terms of the validation data for the last document timestamp becoming at risk of obsolescence, or the technology used for its signature becoming at risk of successful attack, at which point updates need to take place. The wording is cautious. The arithmetic is not: renew before, or lose everything before the gap.

A related trap concerns what the renewal covers. In PDF, a document timestamp covers the whole file as it stands, so a new one automatically covers all the old ones. In CAdES, archive-time-stamp-v3 covers a concatenation that explicitly includes all previously present unsigned attributes, which is why ats-hash-index-v3 exists: without an unambiguous record of what was included, a verifier decades later cannot reconstruct the input.

Evidence records: RFC 4998 and the hash tree#

Everything so far treats documents one at a time. That works for a hundred contracts a year. It does not work for a land registry with two hundred million records, where one timestamp per document per renewal cycle is an impossible bill.

The Evidence Record Syntax, RFC 4998 of August 2007, solves this by timestamping a Merkle hash tree over the whole collection at once, and then handing each document a small extract of that tree, sufficient to prove its own membership and nothing else. The companion requirements document, RFC 4810 of March 2007, obliges a long-term archive service to maintain a cryptographic maintenance policy defining what happens “should one of the hash or asymmetric algorithms used to create a digital signature become weak”. An XML expression of the same ideas, XMLERS, is RFC 6283 of July 2011.

The structures are compact:

EvidenceRecord ::= SEQUENCE {
  version                   INTEGER { v1(1) },
  digestAlgorithms          SEQUENCE OF AlgorithmIdentifier,
  cryptoInfos           [0] CryptoInfos OPTIONAL,
  encryptionInfo        [1] EncryptionInfo OPTIONAL,
  archiveTimeStampSequence  ArchiveTimeStampSequence }

ArchiveTimeStamp ::= SEQUENCE {
  digestAlgorithm  [0] AlgorithmIdentifier OPTIONAL,
  attributes       [1] Attributes OPTIONAL,
  reducedHashtree  [2] SEQUENCE OF PartialHashtree OPTIONAL,
  timeStamp            ContentInfo }

PartialHashtree          ::= SEQUENCE OF OCTET STRING
ArchiveTimeStampChain    ::= SEQUENCE OF ArchiveTimeStamp
ArchiveTimeStampSequence ::= SEQUENCE OF ArchiveTimeStampChain

The two-level nesting is the clever part. An ArchiveTimeStampChain is a run of timestamps all using the same hash algorithm, each renewing the one before it. An ArchiveTimeStampSequence is a run of chains, one per hash algorithm, in order. When you change hash algorithm you close the current chain and open a new one, so the shape of the structure records the archive’s cryptographic history and a verifier can read it off.

Here is a real four-document tree. The documents are Reshma’s deed and three supporting records, hashed with SHA-256:

d1 deed        e02b11be3e5b96d8 ... 06617873
d2 minute      2f4f27f9dac793a8 ... 00d9d4f4
d3 valuation   b5839ee16ffb032b ... 81a95391
d4 consent     a0157604086ed222 ... 1855288e

RFC 4998 section 4.2 builds inner nodes by sorting the child hash values in binary ascending order, concatenating them, and hashing the result. So:

        R = 3462e7f0 ... 148ba190   <- timestamped
          /                    \
    A = 2ba50af9...       B = b84b0f61...
      /       \             /        \
   h(d1)    h(d2)        h(d3)      h(d4)

The authority timestamps R and nothing else. One request, one token, four documents, and the same one token would have served four million.

The extract handed to the deed’s owner, its reduced hash tree, is the short list of values needed to walk from the deed to the root:

partial hash tree 1 : { h(d1), h(d2) }
partial hash tree 2 : { B }

Verification, from RFC 4998 section 4.3, is four steps. Compute h of the document and check it is a member of the first partial hash tree. Sort and concatenate all members of that partial tree and hash them, giving A. For each following partial tree, check whether the running value is a member; if not, add it, then sort, concatenate and hash. Compare the result with the value in the timestamp token. Running the real numbers, hashing h(d1) with h(d2) yields 2ba50af9 and so on, and hashing that with B yields 3462e7f0 and so on, which is exactly the timestamped root. The owner of the deed learns the digests of three other documents and nothing else, and in a registry those digests can be salted so that even that leaks nothing.

Renewal comes in two kinds, and choosing between them correctly is the single most valuable thing in RFC 4998.

Timestamp renewal, section 5.2, is used when the timestamp authority’s signature is weakening but the hash algorithm is still sound. You take the previous archive timestamp, hash it, build a small tree over the previous timestamps of all the documents, and get one new token. The archived documents are never touched, so it can be run against the evidence records alone.

Hash tree renewal is used when the hash algorithm itself is weakening. The old tree is now worthless as a structure, because its internal nodes were computed with the doubted function. You must read every archived document again, hash each one with the new algorithm together with its existing evidence, rebuild the entire tree, and timestamp the new root, opening a new ArchiveTimeStampChain. For a two-hundred-million-document archive that is a project with a budget, and it must complete before the old algorithm is considered broken, not after.

Germany drove much of this work and has the most complete national expression of it. The federal information security office publishes BSI TR-03125, “Preservation of Evidence of Cryptographically Signed Documents”, known as TR-ESOR, whose version 1.3 of 12 December 2022 includes an annex profiling evidence records under RFC 4998 and RFC 6283 for public-sector archives.

Hash algorithm migration, and the SHA-1 case#

SHA-1 is the worked precedent for every migration that will follow, including the one now beginning for signature algorithms under quantum computing, so it is worth having the dates exactly right.

The first public break of a hash function in an actual attack came with MD5, not SHA-1: a team demonstrated a rogue certificate authority certificate built on an MD5 chosen-prefix collision on 30 December 2008, and the Flame malware discovered in 2012 used an MD5 collision against a Microsoft certificate to sign itself as a Windows update.

For SHA-1, the first public collision was SHAttered, announced on 23 February 2017 by Marc Stevens and Pierre Karpman of CWI Amsterdam with Elie Bursztein, Ange Albertini and Yarik Markov of Google. It produced two different PDF files sharing the SHA-1 value 38762cf7f55934b34d179ae6a4c80cadccbb7f0a, at a cost given as roughly nine quintillion SHA-1 computations, about 6,500 CPU years and 110 GPU years run in parallel. This was an identical-prefix collision: the attacker controlled both documents from the start.

The more dangerous result came on 7 January 2020, when Gaetan Leurent of INRIA and Thomas Peyrin of Nanyang Technological University published “SHA-1 is a Shambles”, the first practical chosen-prefix collision for SHA-1, reducing the cost from around two to the power 67.1 to around two to the power 63.4 operations. They ran it on 900 consumer graphics cards over two months at a cost of about seventy-five thousand United States dollars, and demonstrated it by forging a PGP key certification, transferring a genuine signature onto a key bearing another person’s identity. Their conclusion ends the argument: all attacks practical on MD5 are now practical on SHA-1.

The formal retirements followed. NIST SP 800-131A Revision 2, “Transitioning the Use of Cryptographic Algorithms and Key Lengths”, of March 2019, places SHA-1 as disallowed for digital signature generation except where specific NIST protocol guidance permits it, and as legacy use for verification, which is the standards-body way of saying you may check old signatures but must not make new ones. NIST announced the full retirement of SHA-1 on 15 December 2022, recommending migration to SHA-2 or SHA-3 as soon as possible and setting 31 December 2030 as the date by which SHA-1 should be phased out entirely, with FIPS 180-5 to remove it. An initial public draft of SP 800-131A Revision 3 was issued on 21 October 2024 with comments closing on 4 December 2024; as of August 2026 Revision 2 remains the final version in force.

In Europe the equivalent reference is ETSI TS 119 312, “Cryptographic Suites”, whose current version as of August 2026 is V2.1.1 of June 2026. It recommends SHA-256, SHA-384 and SHA-512 together with the SHA-3 family, does not list SHA-1 among usable functions at all, treats SHA-224 as legacy with a phase-out date of 31 December 2028, and advises that archiving beyond about twenty years should use the longer digests, on the reasoning that an archive must survive several generations of attack rather than one. The same version introduces the post-quantum signature algorithms standardized by NIST in August 2024, ML-DSA in FIPS 204 and SLH-DSA in FIPS 205, and describes hybrid combinations pairing a classical scheme with a post-quantum one where a signature is accepted only if both parts verify. For long-lived archives that construction is the practical near-term answer, because it fails safe whichever of the two families turns out to be weak.

What should the owner of a SHA-1 archive actually do? Stop creating new SHA-1 evidence, which most organizations did years ago. Establish which documents could have been influenced by an outside party before hashing, since those are the ones genuinely at risk from a collision attack. Run a hash tree renewal over the whole archive with SHA-512, opening a new ArchiveTimeStampChain, while SHA-1 second-preimage resistance is still intact. Then record the completion date, because from then on the archive’s claim is that everything in it existed in this form before that date.

Preservation as a service#

Not every organization should build this, and the European framework recognizes preservation as a trust service in its own right. ETSI TS 119 511, “Policy and security requirements for trust service providers providing long-term preservation of digital signatures or general data using digital signature techniques”, is the governing document, and its current version as of August 2026 is V1.2.1 of October 2025, replacing V1.1.1 of June 2019.

Clause 4.1 distinguishes three storage models. With storage, where the service keeps your submitted data objects and the preservation objects derived from them. With temporary storage, where it holds your data only long enough to produce evidence, then keeps the evidence alone. Without storage, where you keep everything and the service produces evidence synchronously, retaining only its activity records. Clause 4.2 distinguishes what is preserved: general data, meaning proof of existence over long periods; digital signatures, meaning the ability to keep validating them; the two combined; and augmentation of evidence supplied by somebody else.

Clause 9.2 fixes the permitted evidence formats: timestamp tokens under RFC 3161 as updated by RFC 5816, and evidence records under RFC 4998 or RFC 6283. Clause 7.14 requires the provider to monitor the strength of the algorithms in use and to act when they weaken or when certificates are about to expire. Clause 7.15 states the obligation plainly: the preservation service shall augment the preservation evidences before they can no longer be used. The standard sets no fixed calendar interval. It defines an expected evidence duration, dependent on key validity, certificate validity, availability of revocation information and the collision resistance of the hash function in use, and requires augmentation before that duration runs out. The consequence for you is that “we re-timestamp annually” is not a policy; “we re-timestamp when the earliest of these four expiries falls within eighteen months” is.

Above all this sits eIDAS Article 34, which provides that a qualified preservation service for qualified electronic signatures may only be provided by a qualified trust service provider using procedures and technologies capable of extending the trustworthiness of the signature beyond the technological validity period. That phrase, technological validity period, is the regulation’s name for everything this chapter is about.

A worked archive strategy, with intervals and triggers#

Now the calendar, for Reshma’s deed and the nine hundred thousand other documents in the same registry. The deed is signed in March of 2026 with a three-year signing certificate and SHA-256, the retention period is thirty years, and the archive must stand until 2056. Every interval below is derived from something, because an interval you cannot defend is an interval somebody will quietly stop honouring.

STEP 1  at signing, within 24 hours
        obtain signature timestamp        -> level B-T
        interval: 24 h. Derived from: you cannot
        prove existence retrospectively.

STEP 2  at signing + 14 days
        collect full chains, CRLs, OCSP   -> level B-LT
        embed in DSS, add document timestamp
        interval: 14 d. Derived from: longest CRL
        issuance period among issuers (7 d) doubled,
        so the revocation that was in flight at
        signing has certainly been published.

STEP 3  first archive timestamp, at + 30 days
        document timestamp over everything -> B-LTA
        interval: 30 d. Derived from: step 2 must
        have completed and been checked.

STEP 4  recurring archive timestamp
        interval: the earliest of
          (a) TSU certificate notAfter minus 6 months
          (b) hash algorithm sunset minus 24 months
          (c) 36 months since the last one
        whichever comes first.

The watch conditions deserve unpacking. Condition (a) exists because when the timestamping unit’s own certificate expires you must already have a newer timestamp in place, made while that certificate was valid and its revocation data still published; six months is enough margin to notice a failed job and rerun it. Condition (b) exists because migrations take time and must finish while the old algorithm is still trusted; twenty-four months is the observed duration of large migrations. Condition (c) is the floor, because a job that runs only when triggered is a job whose failure nobody notices, and a routine three-yearly run keeps the pipeline warm and staffed.

One further condition is not a timer at all: any announcement of a practical attack against an algorithm in use, or any change to ETSI TS 119 312 or NIST SP 800-131A that moves an algorithm to legacy status, triggers an immediate review rather than waiting for the next scheduled run.

The costs, for nine hundred thousand documents, look like this. One timestamp per document per renewal means nine hundred thousand tokens a cycle. An evidence record makes the whole archive one Merkle tree and one token a cycle, plus a reduced hash tree of a few hundred bytes beside each document. That difference is why RFC 4998 exists.

Finally, the receiving end, because evidence nobody can check is not a strategy. When an archived signature lands on your desk in 2056, work backwards from today. Validate the newest archive timestamp first, using a trust anchor you chose and algorithms you currently accept, and use it to establish the existence time of everything under it. Move to the next timestamp down, validating it under the rules and revocation data the layer above has just proved were in place. Continue until you reach the signature itself, then validate that against the embedded chain and revocation data at the proven signing time, recording which POE you relied on at each step. If a layer fails, the answer is not “invalid” but “cannot be established after this date”, and that difference is worth a great deal in an argument.

34.98 Common wrong ideas#

Wrong: A signature made with an expired certificate is invalid. Right: Expiry limits when new signatures may be created, not how long old ones last. Under the chain model used by ETSI EN 319 102-1, a signature is judged against the state of the world at the time it was made. What you actually need is independent evidence that the signature predates the notAfter time, which a trusted timestamp supplies, plus evidence about revocation at that time, which expiry alone does not tell you.

Wrong: Adding a timestamp makes a signature valid for ever. Right: A timestamp fixes one of three decay mechanisms, certificate expiry, and creates a smaller instance of the same problem, because the timestamp authority’s own certificate expires and its own algorithms age. A timestamped signature with no embedded revocation data and no renewal plan is level B-T, which is a real improvement over B-B and not a solution.

Wrong: You can add long-term validation data whenever you get round to it. Right: Revocation data has a publication life measured in months to a few years. RFC 5280 section 3.3 requires an entry to remain on a revocation list only until one regularly scheduled list has been issued past the certificate’s validity period, and RFC 6960 section 4.4.4 lets an online responder declare an archive cutoff, with a seven-year retention interval given as the example. Collect within weeks of signing; after the issuer’s retention window closes there is no supplier at any price.

Wrong: The timestamp authority sees the document. Right: It receives a hash algorithm identifier and a digest, fifty-nine bytes in total for SHA-256 with no nonce. RFC 3161 section 2.1 forbids the authority from examining the imprint other than to check its length, and forbids it from putting any identification of the requester in the token. It can neither read your document nor prove later that you were the one asking.

Wrong: Two timestamps let you prove which document was signed first. Right: Only if the difference between the two genTime values exceeds the sum of the two accuracy values, or the ordering field is TRUE and both tokens come from the same authority. An authority declaring an accuracy of one second, which is the ETSI EN 319 421 requirement, cannot distinguish two events four hundred milliseconds apart, and RFC 3161 says so explicitly.

Wrong: SHA-1 being broken means every SHA-1 timestamp in the archive is worthless. Right: SHA-1 collision resistance is gone, demonstrated by SHAttered on 23 February 2017 and made cheap and chosen-prefix by Leurent and Peyrin in January 2020, but SHA-1 second-preimage resistance has not been publicly broken. Documents beyond an attacker’s influence before hashing cannot be substituted today. You must still migrate the whole archive with a hash tree renewal, because you usually cannot prove which documents were attacker-influenced, but as a planned project rather than an emergency.

Wrong: A document timestamp added today protects a signature from 2010 against an attack on the 2010 algorithms. Right: It proves only that the bundle existed today. If the algorithm was already broken when the timestamp was applied, an attacker could have constructed the whole bundle last week, and the timestamp confirms that possibility rather than excluding it. Every renewal must happen while the material it covers is still sound, which is why archive timestamps are scheduled against future deadlines and never applied retrospectively.

Wrong: An RFC 4998 evidence record and a chain of RFC 3161 timestamps are two names for the same thing. Right: An evidence record is a structure built on top of RFC 3161 tokens that amortizes one token across any number of documents using a Merkle hash tree, and records its own cryptographic history in nested ArchiveTimeStampChains, one per hash algorithm. It also distinguishes timestamp renewal, which touches only the previous tokens, from hash tree renewal, which requires reading every archived object again. A plain chain of timestamps on one file has neither property.

Wrong: Buying a qualified preservation service means the problem is solved. Right: It transfers the mechanics, under ETSI TS 119 511 and eIDAS Article 34, but not the responsibility for choosing a preservation period, deciding what is submitted, or checking that evidence was produced. Clause 7.15 obliges the provider to augment evidence before it stops being usable; nothing obliges you to submit the right documents, and no provider will tell you that you forgot to.

Wrong: Long-term validity is a cryptography problem. Right: One of its three causes is cryptographic and the other two are record-keeping. The technology has existed since RFC 3161 in August 2001 and RFC 4998 in August 2007, and it works. It fails in the field because nobody owns the calendar, nobody monitors algorithm deprecation announcements, and the renewal job silently stops running after its author changes team.

34.99 Chapter summary in 20 lines#

1. A signature does not decay, but the evidence needed to verify it does, through three mechanisms with different timescales.
2. Certificate expiry is scheduled and harmless provided you can show the signature predates the notAfter time, which is what a timestamp does.
3. Revocation data disappears on the issuer’s retention schedule, not yours, and once gone no amount of money will produce it again.
4. Algorithm ageing is the only cause that can invalidate evidence you already hold rather than merely make it unobtainable.
5. RFC 3161 of August 2001 defines a timestamp request as a hash algorithm identifier and a digest, with optional nonce, policy and certReq flag.
6. The token is a CMS SignedData over a TSTInfo whose genTime carries the authoritative time and whose accuracy field states the uncertainty.
7. The signing certificate must carry the extended key usage id-kp-timeStamping as its only such usage, marked critical.
8. RFC 5816 of March 2010 added ESSCertIDv2 in a SigningCertificateV2 attribute, required whenever anything other than SHA-1 is used.
9. ETSI EN 319 421 V1.3.1 of July 2025 requires a declared clock accuracy of one second or better against Coordinated Universal Time.
10. The same standard requires a unit that detects loss of clock synchronization to stop issuing timestamps rather than guess.
11. Under eIDAS Article 41 a qualified electronic time stamp enjoys a legal presumption of the accuracy of its time and the integrity of its data.
12. Long-term validation embeds the certificate chains and revocation data in the file so it can be checked with no network at all.
13. In PDF that material lives in a Document Security Store with the keys Certs, CRLs, OCSPs and VRI, added by an incremental update.
14. A document timestamp is a signature dictionary with SubFilter ETSI.RFC3161 covering the whole file including all earlier timestamps.
15. The four baseline levels are B-B for the bare signature, B-T adding trusted time, B-LT adding validation material and B-LTA adding renewal.
16. B-LTA is the only level that is a continuing obligation, and the only one that addresses algorithm ageing.
17. RFC 4998 of August 2007 amortizes one timestamp across an entire archive using a Merkle hash tree, giving each document a reduced hash tree.
18. Timestamp renewal touches only the previous tokens; hash tree renewal requires reading every archived object and opens a new chain.
19. SHA-1 collisions became real on 23 February 2017 and cheap and chosen-prefix in January 2020, and NIST set 2030 for full phase-out.
20. Every renewal must be performed while the material it covers is still trusted, which makes long-term validity a calendar discipline first.

Chapter sources: RFC 3161 of August 2001, Internet X.509 Public Key Infrastructure Time-Stamp Protocol, sections 2.1, 2.2, 2.4.1, 2.4.2 and 3.1 to 3.4; RFC 5816 of March 2010 for ESSCertIDv2; RFC 5652 of September 2009 for the Cryptographic Message Syntax the token is wrapped in; RFC 5280 section 3.3 on removing entries from certificate revocation lists; RFC 6960 of June 2013, section 4.4.4, for the OCSP archive cutoff extension and its seven-year retention example; RFC 4998 of August 2007, Evidence Record Syntax, sections 3.1, 4.1, 4.2, 4.3 and 5.2; RFC 4810 of March 2007, Long-Term Archive Service Requirements; RFC 6283 of July 2011 for XMLERS; ETSI EN 319 421 V1.3.1 of July 2025, clauses 5.2, 7.6.5, 7.6.7, 7.7.1, 7.7.2 and 7.12, with ETSI EN 319 422 V1.1.1 of March 2016 for the token profile; ETSI EN 319 142-1 V1.2.1 of January 2024, clauses 5.4.2, 5.4.3 and 6.1 to 6.3 including table 1; ETSI EN 319 122-1 V1.3.1 of June 2023 for the CAdES attributes and baseline levels; ETSI EN 319 102-1 V1.4.1 of June 2024 for proofs of existence and past signature validation; ETSI TS 119 511 V1.2.1 of October 2025, clauses 4.1, 4.2, 4.4, 4.5, 7.14, 7.15, 9.2 and annex A; ETSI TS 119 312 V2.1.1 of June 2026 for cryptographic suites; ETSI TS 102 778-4 V1.1.1 of July 2009 and V1.1.2 of December 2009 for the original PAdES long-term profile; ISO 32000-2:2020, PDF 2.0, second edition of December 2020; ISO/IEC 18014-1:2008, second edition, with part 3 covering linked tokens; ANSI ASC X9.95 of June 2005; Regulation (EU) No 910/2014, articles 3(33), 3(34), 34, 41 and 42, as consolidated to 18 October 2024; Commission Implementing Decision (EU) 2015/1506 of 8 September 2015, articles 1 and 3 and its annex; NIST SP 800-131A Revision 2 of March 2019, with the initial public draft of Revision 3 issued 21 October 2024 and still in draft as of August 2026; the NIST announcement retiring SHA-1 of 15 December 2022, setting 31 December 2030 for phase-out; FIPS 204 and FIPS 205 of 13 August 2024; BSI TR-03125 version 1.3 of 12 December 2022, TR-ESOR, with its evidence record annex; Stuart Haber and W. Scott Stornetta, “How to Time-Stamp a Digital Document”, Journal of Cryptology volume 3 number 2, 1991, pages 99 to 111, and the later tree construction with Dave Bayer; the Surety linked timestamping service from January 1995 and its weekly New York Times classified advertisement; the SHAttered collision of 23 February 2017 by Stevens, Karpman, Bursztein, Albertini and Markov; “SHA-1 is a Shambles” by Gaetan Leurent and Thomas Peyrin, 7 January 2020; the MD5 rogue certificate authority demonstration of 30 December 2008 and the Flame malware of 2012. Laboratory values, including the fifty-nine-byte timestamp request, the token with serial 0x2A1A and genTime 20260818012402Z, and the four-leaf hash tree, were generated with OpenSSL 3.0.13 on 18 August 2026 against a laboratory timestamp authority trusted by nothing.