up:: In the Protocols MOC

Long-Term Signature Validity

Long-term signature validity is the practice of keeping a signature that was made years ago still usable as evidence today, after the algorithm that produced it has weakened or broken. Migrating to post-quantum signatures fixes everything you sign from now on, and it does nothing for the signed records already sitting in your archive. Those are kept provable by a different mechanism: a trusted timestamp that records when the signature existed, wrapped in an evidence record that gets renewed with a stronger algorithm before the old one falls, so each renewal vouches for the one beneath it. The governing standards are the Time-Stamp Protocol in RFC 3161 and the Evidence Record Syntax in RFC 4998, with an XML form in RFC 6283 and a European profile in the ETSI CAdES standard.

Sources: C. Adams, P. Cain, D. Pinkas and R. Zuccherato, “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP),” RFC 3161, August 2001, RFC 3161, which states that “a time-stamping service supports assertions of proof that a datum existed before a particular time.” T. Gondrom, R. Brandner and U. Pordesch, “Evidence Record Syntax (ERS),” RFC 4998, August 2007, RFC 4998, whose abstract sets the goal as proving “the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time.”

The short version:

• A signature’s evidentiary value dies when its algorithm does, because from that moment a verifier cannot tell a genuine old signature from one minted after the key became forgeable.
• A trusted timestamp fixes that by proving the signature existed before the break, which is why timestamping is the standard mitigation for archives and legal records that cannot be re-signed.
• One timestamp is not enough, because the timestamp authority signs with its own key using its own algorithms, and those age too.
• RFC 4998 solves the regress by chaining timestamps into an evidence record with two renewal modes, one cheap and one expensive, chosen by which thing weakened.
• This is recoverable, and only until the old algorithm breaks. Harvested ciphertext is already lost, so nothing you do now recovers it. A signed archive is still savable today, which makes the deadline the date your archive is re-anchored rather than the date your new signing is migrated.

Picture an evidence locker in a courthouse. Each box is closed with a tamper seal, and the seals used in 1995 can now be duplicated by anyone with the right equipment, so a 1995 seal on its own proves nothing about whether the box was opened in the meantime. You cannot go back and re-seal the boxes as they were, because the moment you cut the old seal the chain is broken. What the clerk does instead is put the sealed boxes into a larger container and seal that with a current seal, recording the date. The old seal is now vouched for by a newer one applied while the old one was still sound, and the record shows the box was already closed at that point. When the new seal design ages, the whole thing goes into a bigger container again. Long-term signature validity is that practice, done with hashes and timestamps.

Why doesn’t migrating to post-quantum signatures fix the signatures you already made?

Because migration changes what you produce from today forward, and the archive is full of things produced before today. A contract RSA-signed in 2022, an audit log ECDSA-signed last quarter, a notarized filing from 2019: none of those get re-signed by a migration project, and many of them cannot be re-signed at all, because re-signing a historical record with today’s date destroys the very thing that made it evidence.

The problem those records face is not that the signature stops verifying. Mathematically it still checks. The problem is that it stops proving anything, because once the signing key can be recovered from the public key, more than one party could have produced that signature, and nothing in the signature says which one did. The non-repudiation property collapses at that moment for every classical signature still in play, including ones made legitimately years earlier. That is why a signed record needs an answer to a question distinct from confidentiality: until what date does this record have to be provable?

Which puts signed records in an odd position relative to the rest of the migration. Under The Two-Lane Split, signatures sit in the deliberate lane, because a forgery needs a working quantum computer and there is nothing to harvest today. An archive of signed records inherits that mechanism and a much harder calendar, in the same way signing keys on 15-year field devices do. The work is Lane 2 and the deadline behaves like Lane 1.

What does a trusted timestamp actually prove?

It proves a specific, narrow thing: that a particular piece of data existed before a particular time. RFC 3161 defines a request and response protocol with a Time Stamping Authority, which receives the hash of your data, adds a time, signs the pair, and returns a token. The TSA never sees the data itself, only its hash.

That narrow claim is what rescues the archive. A verifier in 2040 holding a 2026 signature plus a timestamp token from 2026 escapes the ambiguity entirely, because the token establishes that the signature already existed at a moment when forging it was not possible. The forgery hypothesis requires the signature to have been created after the key became recoverable, and the timestamp rules that out. This is the mitigation forge-later attacks and Non-HNDL both point at, and it is the mechanism behind the timestamping half of the answer in Non-repudiation.

RFC 3161 puts real operational weight on the authority to make that claim trustworthy. The TSA “MUST sign each time-stamp message with a key reserved specifically for that purpose,” and its certificate carries a dedicated extended key usage so a timestamping key cannot be quietly used for anything else. The standard is equally blunt about the failure case: if the TSA’s private key is compromised, “any token signed by the TSA using that private key cannot be trusted anymore.”

Source: RFC 3161, §2.1 and §4, August 2001, RFC 3161, for the key-reservation requirement and the compromise consequence, both quoted above.

Why isn’t one timestamp enough?

Because the timestamp authority signed its token with a key, using a hash function and a signature algorithm, and all of those age on the same schedule as everything else. A 2008 token signed with a 1024-bit RSA key over SHA-1 is not a foundation you want your 2040 evidence resting on. Solving the signature’s mortality with a single timestamp just moves the mortality one layer up.

The regress has a real solution rather than a philosophical one: keep stacking, on a schedule. Each new timestamp is applied while the layer beneath it is still sound, so the new one attests to something that was still trustworthy at the moment of attestation. Run correctly, this is an unbroken chain of “this was already true when it was still checkable,” and the chain can be extended indefinitely as algorithms turn over. Run late, even once, and the chain has a link that was already forgeable when it was made, which no later timestamp can repair.

That scheduling requirement is the entire operational discipline here, and it is why this belongs on a migration plan rather than in a standards appendix. The renewal has to happen before the break, and a break is not always announced in advance.

What are the two renewal modes in an evidence record?

RFC 4998 defines an Evidence Record built from Archive Timestamps, and it names exactly two ways to renew one, chosen by which thing weakened. The distinction matters enormously in practice, because one is cheap and one requires touching every object you have ever archived.

Renewal mode	Triggered when	What gets re-timestamped	Cost
Timestamp Renewal	The Timestamping Unit’s private key is compromised, or the signature algorithm or key size used for the timestamps has fallen below the strength it needs	The existing timestamp only	Low, the archived data is not touched
Hash-Tree Renewal	The hash algorithm used to build the evidence loses its required security properties	Every archived data object, plus the complete Archive Timestamps covering them, hashed and timestamped again under a new hash algorithm	High, the whole archive is re-read

The asymmetry is the practical lesson. A compromised or aging signing key at the timestamp authority is an inconvenience. A weakened hash function is an archive-wide event, because every proof in the structure is built from hashes of your actual data, so nothing short of re-hashing all of it restores the guarantee. Hash-Tree Renewal starts a new Archive Timestamp Chain, and the chains together form an Archive Timestamp Sequence, which is the audit trail a verifier walks decades later.

Anyone who sizes this work only against the signature migration will underestimate it. The question to carry into a storage review is how long it takes to read, hash and re-timestamp the entire archive, because that duration is the real notice period you need before a hash function is deprecated.

Source: RFC 4998, §1.2 and §5, August 2007, RFC 4998. The standard states that timestamp renewal becomes necessary when a Timestamping Unit’s private key has been compromised, or when an asymmetric or hash algorithm used to generate the timestamps has ceased to be secure at the given key size, and that hash-tree renewal is required when the hash algorithm used to build the evidence loses its required security properties. In the hash-tree case its words are that “all evidence data must be accessed and timestamped,” which it then spells out as covering the timestamps, the complete Archive Timestamps and the archived data objects beneath them, all of which “must be hashed and timestamped again by a new Archive Timestamp.”

Which standards cover this, and what is missing?

Four documents carry the weight, and one notable absence shapes what a US program can point at.

Document	What it gives you	Status
RFC 3161 (2001)	The Time-Stamp Protocol itself, the TSA’s obligations, the token format	Standards Track, updated by RFC 5816
RFC 4998 (2007)	Evidence Record Syntax, the Archive Timestamp, the two renewal modes	Standards Track
RFC 6283 (2010)	XMLERS, the same evidence-record model expressed in XML for XML-native archives	Standards Track
ETSI EN 319 122-1 (2023)	The European CAdES profile, including archive-time-stamp-v3 and the attributes for long-term availability and integrity of validation material	European Standard, current
NIST SP 800-102 (2009)	US federal guidance on digital signature timeliness and Trusted Timestamp Authorities	Withdrawn 1 July 2025, in its entirety, with no superseding publication

The withdrawal is worth stating plainly, because it changes what an auditor can be pointed at. US federal guidance specifically on signature timeliness currently has no replacement, so a program that needs a citable basis for its timestamping design is working from the IETF standards and the European profiles rather than from a current NIST special publication. That is a documentation gap rather than a technical one, and it is the sort of thing worth writing into a risk register before somebody asks for the reference in an audit.

The European side is more complete than the US side here. EN 319 122-1 specifies the archive-time-stamp-v3 attribute and the ats-hash-index-v3 attribute that fixes exactly which certificates, revocation information and unsigned attributes an archive timestamp covers, so a verifier years later knows precisely what was protected and what was not. That level of specificity is what separates a long-term profile from a timestamp bolted onto a signature.

Sources: NIST, “Recommendation for Digital Signature Timeliness,” SP 800-102, September 2009, withdrawal notice dated 1 July 2025 stating “SP 800-102 is withdrawn in its entirety” with the superseding-publication field marked “N/A,” csrc.nist.gov. ETSI, “Electronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 1: Building blocks and CAdES baseline signatures,” EN 319 122-1 V1.3.1, June 2023, clause 5.5.3 and Annex A, etsi.org, for the archive-time-stamp-v3 and ats-hash-index-v3 attributes and the stated purpose of “long term availability and integrity of validation data.” A. J. Blazic, S. Saljic and T. Gondrom, “Extensible Markup Language Evidence Record Syntax (XMLERS),” RFC 6283, July 2011, RFC 6283. ⚠️ None of these documents discusses quantum computing or assigns a migration order; the ranking guidance below is this Guide’s analysis.

How do you rank an archive by trust lifetime?

By asking the records the same question The Shelf-Life Question asks of data, reworded for evidence: until what date does this record have to be provable? Confidentiality asks how long something must stay secret. A signing key asks how long it must stay unforgeable. A signed record asks how long it must stay checkable by somebody who was not there.

The sort works the same way and carries the same trap. Rank every class of signed record by that date, descending, and re-anchor the longest-lived first. The trap is that the longest-lived record sets the whole bucket: one 30-year retention obligation inside a class you think of as 3-year makes the entire class a 30-year problem, and averaging it away is how exposure disappears from a report.

Four places usually carry the longest answers, and they are rarely the places a migration plan starts:

1. Regulated audit logs and transaction records, where the obligation is to demonstrate to a regulator years later that an event happened as recorded.
2. Notarized and legally-executed documents, where the signature is the instrument rather than a wrapper around it.
3. Medical and pharmaceutical records, where the provability horizon can run the length of a patient’s life or a product’s liability tail.
4. Firmware and software artifacts already in the field, which overlap with PQC in Firmware and Code Signing and are the one category where re-signing is sometimes possible.

The output of that ranking is a re-anchoring schedule, and it belongs in the risk register next to the migration schedule rather than inside it, because the two have different deadlines and different owners. The migration is an engineering project. The re-anchoring is an archive project, and the team that owns the archive is usually not in the room when the migration is planned.

Has this happened before?

It has happened to this exact machinery, which is the most useful version of the lesson. RFC 3161, the protocol designed specifically to let signatures outlive their algorithms, was itself pinned to a hash function that then weakened. Its original 2001 specification identified the signer’s certificate using a structure built on SHA-1, and as confidence in SHA-1 eroded, that hardcoding became a problem for the very documents the protocol existed to protect.

The fix arrived in March 2010 as RFC 5816, which updates RFC 3161 to permit ESSCertIDv2 so the hash of the signer’s certificate can be computed with a function other than SHA-1. 9 years between the standard and the patch, on a protocol whose entire purpose is surviving algorithm turnover.

The point is not that anyone erred. It is that a long-term validity system needs agility in its own plumbing as much as in the signatures it protects, because the layer doing the vouching is made of the same perishable material as the layer being vouched for. When you design a re-anchoring schedule, schedule a review of the anchoring mechanism too.

Sources: RFC 3161, August 2001, RFC 3161. S. Santesson and N. Pope, “ESSCertIDv2 Update for RFC 3161,” RFC 5816, March 2010, RFC 5816, whose abstract states that it “allows the use of ESSCertIDv2, as defined in RFC 5035, to specify the hash of a signer certificate when the hash is calculated with a function other than the Secure Hash Algorithm (SHA-1).”

Common misconceptions

• “If we migrate our signing to ML-DSA, our signed records are covered.” Migration protects what you sign from now on. Records already signed with RSA or ECDSA keep whatever evidentiary value they had, and that value collapses when the old algorithm does, unless they were timestamped or re-anchored first.
• “A timestamp makes a signature permanently valid.” A timestamp proves the signature existed at a point in time, and the timestamp token is itself a signature with its own algorithm and its own expiry of trust. Long-term validity is a chain of renewals, not a single act.
• “We can re-timestamp after the algorithm breaks.” Renewal works because each layer is applied while the layer beneath it is still sound. A timestamp applied after the break attests to something that was already forgeable when it was attested, so it adds a date and no assurance.
• “Re-anchoring is just re-signing, so it scales with our signing volume.” Under Hash-Tree Renewal the archived objects themselves are re-read, re-hashed and re-timestamped, so the work scales with the size of the archive rather than with how often you sign.
• “Nobody actually does this, it’s a standards exercise.” Archival, legal and regulated-records systems have run evidence records for nearly two decades, and the European CAdES profile specifies the archive timestamp in normative detail. What is new is the size of the algorithm turnover coming.
• “Signed records are Lane 2, so they can wait.” They are Lane 2 by mechanism, because a forgery needs the machine. The calendar behaves like Lane 1, because the window to preserve an old record closes at the break rather than at your migration date.

Questions people ask

Does a timestamp protect a signature made with a broken algorithm? It protects the claim that the signature existed before a given time, which is usually the disputed point. It does not repair the signature, and it only helps if the timestamp itself was applied while the signing algorithm was still sound.

Who runs the timestamp authority? Either a third-party service or an internal one. RFC 3161 explicitly allows both, noting that a TSA may run as a Trusted Third Party or that “an organization might require a TSA for internal time-stamping purposes.” For evidence intended to persuade an outside party, an independent authority is the stronger position.

What happens if the timestamp authority’s key is compromised? RFC 3161 is unambiguous that every token signed with that key becomes untrustworthy, so the exposure is every record anchored to it. That is a concentration risk worth naming in a risk register, and it is one reason evidence records chain across authorities and algorithms over time.

Is there a post-quantum version of all this? The mechanisms are algorithm-agnostic by design, so the practical move is to run the chain forward using post-quantum signatures and hash functions with adequate margin. The circularity to watch is that a post-quantum evidence record still needs a timestamp authority that is itself signing with post-quantum algorithms, and authority migration is not in your control.

How is an evidence record different from a certificate transparency log? A CT log proves that a certificate was published to a public append-only log, which is a statement about disclosure. An evidence record preserves the provability of a specific document or signature across algorithm turnover, which is a statement about durability. Both use Merkle trees, for different ends.

What is the deadline for this work? The date your existing archive is re-anchored, which can sit well ahead of the date your new signing is migrated. Any re-anchoring must land before the old algorithm falls, so the real planning input is how long a full pass over your archive takes.

Do we need this if we keep the original documents? Keeping the document preserves the content, and the disputed question is usually authorship rather than content. Without a timestamp or evidence record, a stored document plus an old signature cannot distinguish a genuine signing from a later forgery once the key is recoverable.

Go deeper

The property being preserved is Non-repudiation, and the reason it decays is set out in Forge-Later Attack and Non-HNDL. The syntactic base these profiles build on is the CMS container described in PQC in S-MIME and CMS, and the revocation information an archive timestamp captures is covered in Certificate Revocation (CRL and OCSP). The European standards body and its signature framework are in ETSI. The upstream premise, that algorithms have finite lives, is argued in Do Cryptographic Algorithms Last Forever. The hub for the applied signing surfaces is In the Protocols MOC.

• The Shelf-Life Question: reworded for evidence, it asks until what date a record has to stay provable, which is the sort that orders a re-anchoring schedule.
• The Two-Lane Split: signed records are Lane 2 by mechanism and Lane 1 by calendar, the same exception shape as signing keys on long-lived field devices.

---

Everything here is the map, given freely. When your team needs its signed archives ranked by how long each record has to stay provable, with a re-anchoring schedule that lands before the algorithms it depends on are deprecated, that’s a working session with your team.

Last verified 2026-09-23 · Updated 2026-09-23 · Maintained by Addie LaMarr, LaMarr Labs.