Summary

  • An RFC 3161 token binds a message imprint to a stated time, policy and signing identity; it does not contain the full evidence that the authority followed that policy when it signed.
  • RFC 3628 separated policy from practice and required UTC traceability, loss-of-sync detection, issuance suspension, key isolation, audit and disclosure outside the token. ETSI EN 319 421 V1.3.1 preserves that boundary today.
  • A defensible reliance decision needs a policy-to-operation receipt that joins the token to the applicable practice version, clock and key history, affected-token interval, trusted status and long-term verification evidence.

A valid object can still have an unproved operating history

RFC 3161 gives the token a disciplined shape. Its messageImprint must reproduce the hash supplied by the requester. Its serial number must remain unique for the issuing authority even across a service interruption. genTime records when the authority created the token. The policy field identifies the rules under which the response was produced. A nonce, when requested, must return unchanged. The signature and signer-certificate identifier bind the response to a key.

Those are substantial guarantees. They are also bounded ones. The imprint says nothing about whether the original datum was true, lawful, complete or authored by the person later associated with it. genTime is not the requester's creation time, a server-receipt time or an application's acceptance time. An optional accuracy value turns the displayed instant into an interval. Unless ordering is asserted for tokens from one authority, RFC 3161 permits chronological comparison only when the two accuracy intervals do not overlap.

The token is therefore evidence about an assertion, not a miniature history of the service that made it. The distinction becomes operationally important when the signature verifies but the authority's clock, key management or disclosure record cannot be reconstructed.

RFC 3628 put the missing half in the operating system

RFC 3628 was published as Informational in 2003 and reflected an ETSI policy specification of its period. It is not a current Internet Standard or a complete contemporary compliance manual. Its architectural separation, however, is explicit and durable: a time-stamp policy states what is to be adhered to; a TSA practice statement explains how one provider adheres to it in a particular organisation, facility and computing environment.

That division prevents a common category error. The policy object identifier inside a token names a ruleset. It does not embed the practice statement, the version that applied that day, the time-source topology, the key ceremony or the incident log. RFC 3628 allowed a provider to claim conformance by making supporting evidence available on request or by obtaining independent assessment. The claim was never designed to authenticate itself.

The authority also retains responsibility when work is outsourced. A hosted clock source, managed cryptographic module or subcontracted token generator may perform the work, but the TSA remains responsible for the policy controls and for disclosing the relevant practices. A supply-chain diagram cannot replace that allocation of accountability.

Z is notation; traceability is a chain

RFC 3628 required token time to be traceable to a real-time value distributed by a UTC(k) laboratory and synchronized within the declared accuracy. BIPM now describes the same metrological structure more plainly. National institutes and designated laboratories maintain local real-time realizations called UTC(k). BIPM computes UTC and publishes differences between UTC and UTC(k) in Circular T. That monthly publication is the definitive traceability record.

Rapid UTC, or UTCr, provides weekly operational information. It is useful precisely because final UTC results arrive later. BIPM is explicit that UTCr complements UTC; it does not replace the definitive result or Circular T's traceability information. A fast monitor and an authoritative comparison serve different decisions.

The character Z in genTime exposes none of this chain. It does not identify the UTC(k) laboratory, distribution path, observed offset, uncertainty, last successful calibration, synchronization age or holdover state. A valid signature over Z proves that the signer committed to the value. It does not prove how the value met UTC.

RFC 3628 cited ITU-R TF.460-5. That revision is now superseded; TF.460-6 is in force. ETSI EN 319 421 V1.3.1, adopted in 2025, uses the current reference. Treating the old citation as timeless would repeat the very mistake the policy architecture was meant to prevent: confusing a stable identifier with the state of its dependencies.

The most important clock control is the refusal to sign

Both the historical RFC and the current ETSI standard make loss of synchronization a change in authority, not merely a telemetry warning. The authority must detect a drift or jump outside its stated accuracy. Once detected, the time-stamping unit must stop issuing. Recovery must precede resumed issuance.

This is the point at which a generic health dashboard becomes inadequate. “Clock synchronized now” cannot establish when the deviation began, when the detector fired, whether tokens were issued during the suspect interval, or whether a recovery procedure verified the clock before signing resumed. The useful record connects last known-good calibration, first suspect observation, detection, issuance stop, recovery, rekey if applicable and the exact serial or time range that may be affected.

Leap handling reveals the same need. The clock must remain synchronized through a notified leap second, and the exact time of the adjustment must be recorded within the declared accuracy. The requirement is not satisfied by showing that the current wall clock looks right after the event. It requires evidence of the transition.

The key boundary is operational too

RFC 3628 defined a Time-Stamping Unit as one managed hardware-and-software unit with a single active time-stamp signing key at a time. A TSA can run several identifiable TSUs, but each unit has its own key boundary. The current ETSI standard retains one active key, trusted roles, dual control, a secure cryptographic device, time-stamp-only key purpose and automatic rejection when the private-key lifetime ends.

A certificate check answers a different question. It can show that the public key was certified and that the token signature verifies. It cannot demonstrate that no second key was active for that TSU, that a backup was protected, that dual control was used, that the private key had not exceeded its operational expiry, or that qualified and non-qualified services were kept on separate identities and access points.

RFC 5816 improved the signer-certificate binding by adding ESSCertIDv2 for modern hash choices. That is valuable cryptographic maintenance. It does not move the ceremony, exclusivity or lifecycle evidence into the token.

A compromise notice needs a population boundary

RFC 3628 required the TSA to disclose a compromise, suspected compromise or loss of clock calibration, halt issuance until recovery and, where possible, provide information that identifies affected tokens. ETSI EN 319 421 V1.3.1 continues the same logic. It separately requires logs for key and certificate lifecycle events, normal synchronization, recalibration and detected synchronization loss.

“The service was restored” is not enough. A relying party needs to know which TSU and certificate were involved, which interval is suspect, which serials or other identifiers fall within it, when issuance stopped and what constituted recovery. Otherwise every token is left in an ambiguous population: cryptographically intact, operationally unclassifiable.

The standards note two useful mitigations. An audit trail can distinguish genuine tokens from false backdated ones after a key compromise. Independent tokens from two authorities can add another observation. Neither is magic. A missing audit cannot be recreated from the token, and two authorities sharing the same failed time source do not provide two independent clock chains.

Qualification is another external decision

The current European framework makes the separation unusually visible. Regulation (EU) No 910/2014 gives a qualified electronic time stamp a presumption of the accuracy of its indicated date and time and the integrity of the bound data. Commission Implementing Regulation (EU) 2025/1929 names ETSI EN 319 421 V1.3.1 and EN 319 422 V1.1.1, with adaptations, as reference standards for the presumption of compliance.

That legal route does not turn a token extension into a self-issued qualification decision. ETSI says the qualified statement in a token is only an indication of the claim; the relying party is expected to use the relevant trusted list to establish qualified status. The supervisory status, conformity assessment and applicable trusted-list snapshot remain outside the token.

The same regulation strengthens operational controls—cryptographic certification, training, vulnerability scanning, annual penetration testing, HTTPS and termination planning. None is visible merely because the token parses. The more consequential the presumption, the more important it is to preserve the evidence that supports it.

Long-term verification is a sequence, not a verdict

RFC 3628 warned that a token verified today may not remain verifiable tomorrow. During the TSU certificate's validity, current revocation information must be checked. After expiry, ordinary certificate-status publication may no longer establish that the private key was never compromised. Collision resistance and signature strength can also decay.

Annex C therefore treats long-term validity as continuing evidence: knowledge that the key remained uncompromised, that the hash still resists collisions and that the signature remains beyond feasible attack. When those conditions cannot be preserved directly, an additional protective time stamp may be needed. The green check is a time-bounded observation, not a permanent property stored inside the original file.

The minimum durable package is consequently larger than the token: exact bytes and hash; policy, practice and disclosure versions; certificate chain and status evidence; UTC(k) source and synchronization receipts; key lifecycle; incident publications; trusted-list state where qualification matters; algorithm assessment; preservation events; and the relying party's own decision. Each component keeps its own custodian and clock.

Sources

  1. RFC 3628 — Policy Requirements for Time-Stamping Authorities
  2. RFC 3628 plain text
  3. RFC Editor information for RFC 3628
  4. IETF Datatracker record for RFC 3628
  5. RFC 3628 errata search
  6. RFC 3161 — Time-Stamp Protocol
  7. RFC Editor information for RFC 3161
  8. IETF Datatracker record for RFC 3161
  9. RFC 3161 with inline errata
  10. RFC 5816 — ESSCertIDv2 Update for RFC 3161
  11. RFC Editor information for RFC 5816
  12. IETF Datatracker record for RFC 5816
  13. ETSI EN 319 421 V1.3.1
  14. ETSI EN 319 422 V1.1.1
  15. BIPM Circular T
  16. BIPM Coordinated Universal Time
  17. BIPM Rapid UTC
  18. ITU-R Recommendation TF.460
  19. ITU-R Recommendation TF.536-2
  20. Consolidated Regulation (EU) No 910/2014
  21. Commission Implementing Regulation (EU) 2025/1929
  22. Lu Heng — Running Code Primary
  23. Lu Heng — Minimum Initial Specification
  24. Lu Heng — On Reality Layers
  25. Lu Heng — On Authority and Belief