Summary

  • RFC 3126 separated four jobs: ES-T anchored when a signature existed, ES-C recorded the certificate and revocation evidence needed to validate it, ES-X retained or protected that evidence, and ES-A allowed the whole record to be timestamped again before older protection weakened.
  • The format never made trust automatic or eternal. Long-term validation depended on preserving exact bytes and status material, applying the right signature policy, and renewing the archive chain while earlier timestamps and algorithms were still defensible.

A signature could survive its certificate and still lose its proof

Digital signatures are often described as durable because copied bits do not fade. Their evidence environment does. A signer's certificate expires. A certification authority stops publishing old revocation lists. An online status responder changes or disappears. A timestamp authority's certificate reaches the end of its life. A hash once considered adequate becomes vulnerable. An archive migrates a file and changes the octets that were actually signed.

RFC 3126, published as Informational in September 2001, began from that temporal mismatch. It aimed to define electronic signatures that could be validated over long periods, including in a later dispute. It built on the policy-aware signature of RFC 3125, CMS and ESS containers, X.509 certificates, revocation evidence and trusted timestamping. The hard problem was not simply keeping the signature value. It was keeping enough of the world around that value to reconstruct a decision.

This was not a claim that every old signature must remain valid. A later verifier still needed the applicable signature policy, acceptable trust anchors and credible evidence. RFC 3126 designed a container and process for preserving that evidence; it did not appoint the container as judge.

ES-T fixed an early point in time

The base electronic signature, ES, carried the digital signature and other signer-supplied information. ES-T added a signature timestamp. If the signer did not supply one, the verifier was required either to create it on first receipt or to keep a secure time record close to the first validation.

RFC 3161 clarifies what that timestamp could say. A Time-Stamping Authority signed a message imprint and asserted that the represented datum existed at a particular time. The authority did not have to inspect the underlying document. It therefore established an order in time, not the truth of the statement, the signer's business authority, compliance with every policy rule or successful completion of the transaction.

That narrow claim mattered after compromise. If a signing key was stolen later, a timestamp obtained before the compromise could help distinguish the earlier signature from a forgery made with the stolen key. But the timestamp had its own certificate, algorithm, policy and validation history. The first temporal anchor shifted trust; it did not eliminate it.

ES-C captured the validation recipe before it vanished

Complete validation data, ES-C, built on ES-T. Its minimum form added references to the certification path and the revocation information used in validation. The verifier could later identify which certificates, certificate revocation lists or status responses supported the original decision.

Timing complicated this step. Complete revocation information might not exist at the instant of signing. RFC 3126 allowed time for status material to become available and noted that a temporary certificate suspension might have to resolve. Long-term evidence was therefore assembled as a process, not emitted whole by the signing operation.

References were still only pointers. A URL or identifier would not preserve a certificate or status response after a repository disappeared. RFC 3126 made that boundary visible by defining extended forms that could include the actual values. The distinction resembles the difference between a catalogue entry and the archived book: each is useful, but only one contains the material needed when the shelf is gone.

OCSP also had a bounded vocabulary. RFC 2560 defined good, revoked and unknown states and attached times to the response. “Good” answered a status inquiry; it did not prove every certificate condition, signer authority or transaction fact. Saving the response preserved one input to a later policy decision, not a universal verdict.

ES-X protected the evidence about the evidence

The ES-X family addressed availability and later compromise. X-Long carried the actual certificate and revocation values referenced by ES-C so a future verifier would not depend on external repositories. X-Time-Stamp added protection to validation data: Type 1 timestamped the ES-C as a whole, while Type 2 timestamped its certificate and revocation references. The forms could be combined.

This extra layer answered a subtle historical problem. Suppose a certification-authority key was compromised years after a document was signed. Merely presenting certificates during a dispute would not show that the path and status material existed before the compromise. A dated wrapper around the validation evidence could establish that ordering, subject to the timestamp authority and governing policy.

The design did not require every extended form. RFC 3126 marked ES-X support as optional. Nor did it claim that one layer repaired a broken earlier layer. If the archive had lost the signed content, captured the wrong certificate path or waited until after a compromise to timestamp the evidence, a more elaborate container could preserve the mistake more precisely.

ES-A turned preservation into scheduled maintenance

Archive validation data, ES-A, confronted the expiry of the protective machinery itself. Before algorithms, keys or prior timestamp certificates became weak, the signed data, ES-C and relevant ES-X material were to be timestamped again, preferably with stronger algorithms or longer keys. The process could be repeated whenever protection for the previous archive timestamp weakened.

The archive timestamp covered more than the signature value. It incorporated the signed content, signed attributes, signature, early timestamp, certificate and revocation references, retained values, optional extended timestamps and every previous archive timestamp. The result was a chain of custody in cryptographic form.

This was renewal, not immortality. A custodian had to watch the security horizon and act while the old evidence could still be validated. Once a hash was practically forgeable, a TSA key had been compromised without a reliable temporal boundary, or the underlying values had vanished, a fresh timestamp could not recover the lost history. Later RFC 4998 would make the same maintenance logic explicit for general evidence records, distinguishing ordinary timestamp renewal from renewal that also rehashed archived data.

Exact bytes were part of the historical record

RFC 3126 warned that the OCTET STRING used to generate the signature had to remain the same whenever a verifier or arbitrator checked it. That requirement sounds mechanical, but it made archive migration a governance issue. Character-set conversion, line-ending normalization, detached-content loss or a well-intentioned re-export could break the evidence while leaving the document visually unchanged.

The durable object was therefore a bundle: exact signed bytes, signature and attributes, the applicable policy, certificate path, time-bounded revocation material, timestamp tokens, retained validation values and the history of archive renewals. Keeping only a rendered PDF and a database field marked “valid” discarded the reproducible decision.

RFC 5126 later obsoleted RFC 3126 and retained the family under CAdES-T, CAdES-C, CAdES-X and CAdES-A terminology. That continuity shows that the evidence ladder remained useful as a design pattern. It does not establish how widely any 2001 profile was deployed.

Long-term validation redistributed custody

The signer controlled the original act and might supply early evidence. The verifier could create the first timestamp and assemble complete validation data. Certificate and status services supplied bounded records. A TSA supplied a dated imprint under its own policy. An archive operator preserved exact bytes and renewed the chain. An arbitrator or later relying party interpreted the record under a policy and external legal or contractual instrument.

No single participant owned the whole truth. That distribution was the strength and the operational burden of the design. It prevented a later verifier from relying only on the signer's current key or the memory of an online service, but it created deadlines, storage duties and dependency records that had to survive staff and system changes.

The historical lesson is more exact than “timestamps make signatures last.” RFC 3126 made durability an active process: capture what the first verifier knew, retain what remote services might forget, protect that evidence against later compromise, and renew the protection before its assumptions fail. A long-lived signature was not a frozen act. It was an evidence chain that had to keep moving.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3126.txt
  2. https://www.rfc-editor.org/info/rfc3126
  3. https://datatracker.ietf.org/doc/rfc3126/
  4. https://www.rfc-editor.org/rfc/rfc3125.txt
  5. https://www.rfc-editor.org/rfc/rfc3161.txt
  6. https://www.rfc-editor.org/rfc/rfc2630.txt
  7. https://www.rfc-editor.org/rfc/rfc2634.txt
  8. https://www.rfc-editor.org/rfc/rfc2459.txt
  9. https://www.rfc-editor.org/rfc/rfc2560.txt
  10. https://www.rfc-editor.org/rfc/rfc4998.txt
  11. https://www.rfc-editor.org/rfc/rfc5126.txt
  12. https://www.rfc-editor.org/rfc/rfc5652.txt