Zusammenfassung

  • Ein RFC-3161-Token bindet einen Hash an Zeit, Policy und Signaturidentität; es enthält aber nicht den vollständigen Nachweis, dass die TSA ihre Policy beim Signieren tatsächlich einhielt.
  • RFC 3628 trennte Policy und Praxis und verlangte UTC(k)-Rückführung, Erkennung von Synchronisationsverlust, Ausgabestopp, genau einen aktiven Schlüssel pro TSU, Audit und Offenlegung außerhalb des Tokens.
  • Auch eine qualifizierte Aussage ist nur ein Hinweis. Vertrauenslistenstatus, Praxisversion, Uhr- und Schlüsselhistorie, betroffene Tokenmenge und Langzeitnachweise müssen gesondert erhalten bleiben.

Ein Feld kann einen institutionellen Zustand nur behaupten

RFC 3161 gibt dem Zeitstempel eine klare Form. messageImprint muss den angeforderten Hash wiedergeben. Die Seriennummer bleibt für die TSA eindeutig, auch über Betriebsunterbrechungen hinweg. genTime bezeichnet den Zeitpunkt der Tokenerzeugung. Das Policy-Feld benennt die angewandten Regeln. Ein angeforderter Nonce wird zurückgegeben. Signatur und Signiererzertifikatskennung verbinden die Antwort mit einem Schlüssel.

Diese Eigenschaften belegen nicht, dass das Ausgangsdokument wahr, vollständig oder rechtmäßig ist. Sie beweisen weder Urheberschaft noch Eingang bei einem fremden Server oder Annahme durch eine Anwendung. Eine angegebene Genauigkeit macht aus dem sichtbaren Zeitpunkt ein Intervall. Ist ordering nicht gesetzt, lassen sich zwei Token derselben TSA nur dann zeitlich ordnen, wenn ihr Abstand größer als die Summe der Genauigkeiten ist.

Das Token belegt also eine signierte Behauptung mit definierten Grenzen. Es enthält keinen vollständigen Bericht darüber, wie die Organisation, die Uhr und der Schlüssel im Signiermoment arbeiteten. Ein grünes Prüfergebnis für Syntax und Signatur kann neben einer nicht belegten Betriebsgeschichte stehen.

Policy und Praxis sind absichtlich getrennt

RFC 3628 erschien 2003 als Informational RFC und war technisch mit einer damaligen ETSI-Spezifikation gleichwertig. Er ist weder ein heutiger Internet Standard noch allein ein vollständiger Konformitätsmaßstab. Seine Trennung bleibt jedoch präzise: Die Zeitstempel-Policy sagt, was einzuhalten ist; die TSA Practice Statement beschreibt, wie ein bestimmter Anbieter dies in Organisation, Einrichtungen und Systemen umsetzt.

Die Objektkennung einer Policy passt in das Token. Nicht enthalten sind die an diesem Tag geltende Praxisversion, ihre Genehmigung, die Zeitquellentopologie, die Schlüsselzeremonie, die Rollenverteilung, Unterauftragnehmer und Vorfälle. RFC 3628 sah vor, dass eine TSA ihre Konformitätsbehauptung durch verfügbare Nachweise oder unabhängige Bewertung stützt. Die OID war ein Verweis auf Belege, kein selbstauthentisierender Beleg.

Auslagerung verschiebt die Verantwortung nicht. Ein Dienstleister kann die Zeitquelle, das Kryptomodul oder den Wiederanlauf betreiben. Die TSA bleibt für Policykontrollen und Offenlegung verantwortlich. Verträge müssen deshalb Beweiszugang, Verwahrung, Integrität und Übergabe regeln, nicht nur Verfügbarkeit.

Der Buchstabe Z ist keine metrologische Kette

RFC 3628 verlangte eine Zeit, die auf einen von einem UTC(k)-Labor verteilten Echtzeitwert rückführbar und innerhalb der erklärten Genauigkeit synchronisiert ist. Nationale Institute und benannte Labore betreiben lokale Echtzeitrealisierungen UTC(k). Das BIPM berechnet UTC und veröffentlicht die Differenzen zwischen UTC und UTC(k) in der monatlichen Circular T. Sie liefert die definitive Rückführungsinformation.

Rapid UTC oder UTCr erscheint wöchentlich und hilft der laufenden Steuerung. Das BIPM stellt jedoch klar, dass UTCr UTC ergänzt, aber weder die endgültigen Ergebnisse noch die Rückführung über Circular T ersetzt. Schnelle operative Information und definitive metrologische Feststellung dienen verschiedenen Entscheidungen.

Das Z in genTime nennt weder Labor noch Verteilweg, gemessene Abweichung, Unsicherheit, Alter der letzten Synchronisation oder Holdover-Zustand. Die Signatur beweist die Bindung an den Zeitwert, nicht dessen Weg zu UTC.

Auch die Referenzen ändern sich. RFC 3628 zitierte ITU-R TF.460-5; diese Fassung ist ersetzt, TF.460-6 gilt. ETSI EN 319 421 V1.3.1 von 2025 verwendet die aktuelle Referenz. Eine stabile Policykennung macht ihre Abhängigkeiten nicht zeitlos.

Der Signierstopp ist eine Ausübung von Autorität

Sobald eine Drift oder ein Sprung außerhalb der erklärten Genauigkeit erkannt wird, verlangt RFC 3628, dass die Time-Stamping Unit keine weiteren Token ausgibt. Erst nach Wiederherstellung darf sie fortfahren. Die aktuelle ETSI-Norm behält diesen Grundsatz bei und verlangt Schutz vor unentdeckten Änderungen sowie Protokolle für normale Synchronisation, Rekalibrierung und Synchronisationsverlust.

Damit wird Verfügbarkeit zu einem ambivalenten Signal. Eine TSA, die am richtigen Schwellenwert stoppt, wahrt die Beweisgrenze. Eine TSA, die trotz ungewisser Uhr weiter signiert, vergrößert eine später kaum klassifizierbare Population.

„Jetzt synchron“ sagt nicht, wann die Abweichung begann, wann der Detektor anschlug, wie viele Token bis zum Stopp entstanden oder was die Wiederaufnahme legitimierte. Der brauchbare Datensatz verbindet letzte gute Kalibrierung, erste verdächtige Beobachtung, Erkennung, Ausgabestopp, Wiederherstellung und den betroffenen Zeit- oder Serienbereich. Auch bei einer Schaltsekunde muss der tatsächliche Übergang innerhalb der erklärten Genauigkeit protokolliert werden.

Ein aktiver Schlüssel ist kein Zertifikatsfeld

RFC 3628 verstand eine Time-Stamping Unit als gemeinsam verwaltete Hardware und Software mit genau einem aktiven Zeitstempel-Signierschlüssel zur selben Zeit. Eine TSA kann mehrere identifizierbare TSUs betreiben, doch jede besitzt ihre eigene Schlüsselgrenze. ETSI EN 319 421 V1.3.1 hält an einem aktiven Schlüssel fest und fordert Vertrauensrollen, Vier-Augen-Kontrolle, sichere Kryptogeräte, ausschließlichen Zeitstempelzweck und automatische Ablehnung nach Ende der privaten Schlüsselnutzungsdauer.

Eine Zertifikatsprüfung beantwortet eine andere Frage. Sie kann die Zertifizierung des öffentlichen Schlüssels und die Gültigkeit der Signatur zeigen. Sie beweist nicht, dass kein zweiter Schlüssel aktiv war, dass Sicherungen geschützt wurden, dass die Erzeugung unter dualer Kontrolle stattfand oder dass qualifizierte und nicht qualifizierte Dienste getrennte Identitäten und Zugänge nutzten.

RFC 5816 ergänzte ESSCertIDv2 und modernisierte damit die Bindung an das Signiererzertifikat. Das ist wichtige Kryptopflege. Schlüsselzeremonie, Exklusivität und Lebenszyklus bleiben dennoch außerhalb des Tokens.

Eine Störungsmeldung braucht eine Mengenbegrenzung

RFC 3628 verpflichtete die TSA, Kompromittierung, Verdacht auf Kompromittierung oder Verlust der Uhrenkalibrierung offenzulegen, die Ausgabe bis zur Wiederherstellung einzustellen und nach Möglichkeit die betroffenen Token identifizierbar zu machen. ETSI EN 319 421 V1.3.1 führt diese Logik fort und verlangt getrennte Aufzeichnungen zu Schlüssel- und Zertifikatslebenszyklus, normaler Synchronisation, Rekalibrierung und Synchronisationsverlust.

„Störung behoben“ erlaubt keine Auswahl. Eine relying party braucht TSU und Zertifikat, letzten guten Zustand, Verdachtsintervall, Serienbereich, Stoppzeit und Wiederherstellungskriterium. Fehlt diese Grenze, bleiben kryptografisch intakte Token betrieblich unklassifizierbar.

Ein Audit Trail kann echte Token von nachträglich erzeugten Fälschungen nach einer Schlüsselkompromittierung unterscheiden. Zwei unabhängige TSAs können eine zweite Beobachtung beitragen. Unabhängigkeit muss aber belegt werden: Beide können dieselbe Zeitquelle, Kryptoplattform oder Bewertungsstelle nutzen.

Die Vertrauensliste entscheidet über den Anspruch

Regulation (EU) No 910/2014 gibt einem qualifizierten elektronischen Zeitstempel eine Vermutung für die Richtigkeit der angegebenen Zeit und die Integrität der gebundenen Daten. Commission Implementing Regulation (EU) 2025/1929 nennt mit Anpassungen ETSI EN 319 421 V1.3.1 und EN 319 422 V1.1.1 als Referenznormen für die Konformitätsvermutung.

Der qualifizierte Hinweis im Token ist dennoch keine Selbstqualifikation. ETSI bezeichnet ihn als Indikation des Anspruchs und erwartet, dass sich die relying party anhand der einschlägigen Vertrauensliste vom qualifizierten Status überzeugt. Aufsichtsstatus, Konformitätsbewertung und der damalige Snapshot der Vertrauensliste liegen außerhalb des Tokens.

Die aktuelle Regelung verstärkt außerdem Kontrollen zu Kryptozertifizierung, Ausbildung, Schwachstellenscans, jährlichen Penetrationstests, sicherem Transport und Beendigungsplanung. Keine davon wird sichtbar, nur weil das Token erfolgreich parst. Ein rechtlicher Status ist ein zeitgebundener institutioneller Zustand, kein Bit, das sich selbst legitimiert.

Nach Zertifikatsablauf beginnt eine neue Prüfung

RFC 3628 warnte, dass ein heute verifizierbares Token morgen nicht notwendig verifizierbar bleibt. Während der TSU-Zertifikatslaufzeit sind aktuelle Sperrinformationen zu prüfen. Nach Ablauf kann die übliche Statusveröffentlichung nicht mehr ausreichen, um eine nie erfolgte Kompromittierung des privaten Schlüssels zu belegen. Kollisionsresistenz und Signaturstärke altern ebenfalls.

Anhang C beschreibt Langzeitgültigkeit daher als fortlaufendes Wissen: Der Schlüssel blieb unkompromittiert, der Hash kollisionsresistent und die Signatur außerhalb realistischer Angriffe. Lassen sich diese Bedingungen nicht unmittelbar bewahren, kann ein zusätzlicher schützender Zeitstempel nötig werden. Ein alter grüner Haken ist eine datierte Beobachtung, keine dauerhafte Eigenschaft.

Das haltbare Paket umfasst exakte Tokenbytes und Hash, Policy-, Praxis- und Offenlegungsversion, Zertifikatskette und Statusbelege, UTC(k)-Quelle und Synchronisationsnachweise, Schlüssellebenszyklus, Vorfallmeldungen, gegebenenfalls Vertrauenslistenstatus, Algorithmusbewertung, Erhaltungsereignisse und die eigene Reliance-Entscheidung.

Quellen

  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