Zusammenfassung

  • draft-ietf-rats-epoch-markers-05 lässt eine Epoch Bell wiederverwendbare Marker ausgeben, damit verteilte Beteiligte Frische bewerten können, ohne jedem Attester eine zuverlässige bürgerliche Uhr abzuverlangen.
  • Eine gültige Signatur authentifiziert Marker und Bell-Schlüssel; sie beweist weder gleichzeitige Zustellung noch Sitzungsunikat, korrekte Bell-Zeit oder den Messzeitpunkt der Evidenz.
  • Ein Frische-Verknüpfungsbeleg sollte Bell und Typ, Verteilungsweg, lokale Empfangszeit, Nonce, Akzeptanzfenster, Replay-Zustand und angewandte Policy-Version festhalten.

Frische ist kein einzelner Zeitpunkt

Die praktische Frage der Attestation lautet nicht, wie spät es ist, sondern ob ein gemessener Zustand für eine Entscheidung noch jung genug ist. Messung, Evidenzerstellung, Transport, Appraisal und Nutzung finden zu verschiedenen Zeiten statt. Eine vertrauenswürdige Uhr kann sie verorten, eine zufällige Challenge kann die Antwort an eine Anfrage binden. Beschränkte Geräte unterhalten aber nicht immer eine belastbare Uhr, und ein Relying Party erreicht nicht jedes Gerät unmittelbar.

Die Epoch Bell stellt einen gemeinsamen Takt bereit. Sie sendet Epoch Markers; der Attester bindet einen Marker oder dessen Handle in geschützte Evidenz ein. Der Verifier vergleicht diese Position später mit seiner akzeptierten Grenze. Der Entwurf unterstützt spontanes Challenge-Response, unaufgeforderten Broadcast oder Multicast sowie angeforderte Subscriptions.

Ein gemeinsamer Takt ist keine absolute Zeit. Enthält die Form POSIX-Zeit, hängt die Aussage von Uhr und Betrieb dieser Bell ab. Ein Zähler liefert lediglich Reihenfolge in dem Kontext, der seinen Zustand erhält. Frische entsteht erst aus Emission, Zustellung, Evidenzerstellung und lokalem Fenster.

Formate verschieben die Vertrauensannahme

Revision 05 nennt CBOR-Zeit-Tags, klassisches TSTInfo aus RFC 3161, eine CBOR-Fassung, Epoch Tick, Tick List, monotonen Zähler und epoclet. Diese Varianten sind nicht bloß andere Codierungen.

Zeitformen benötigen eine verlässliche Bell-Uhr. Zähler benötigen kontinuierlichen Zustand. Ein Tick ist unter vielen Verbrauchern wiederverwendbar und unterscheidet sich damit von einer Verifier-Nonce für einen Austausch. Eine Liste erleichtert das Aufholen, verlangt aber Empfängerzustand und Regeln zur Resynchronisierung. Das etwa 44 bis 64 Byte große epoclet kombiniert POSIX-Zeit, deployment-spezifische Schlüsselkennung und HMAC. Seine Kürze verlagert Verantwortung auf Shared-Key-Verwahrung, Rotation und Synchronisation der Serveruhren.

Signatur oder MAC beweisen eine eng begrenzte Aussage: Der erwartete Schlüssel authentifizierte diese Bytes in diesem Format. Sie beweisen nicht, dass die Uhr richtig ging, ein Zähler nach einem Ausfall nicht zurückfiel oder alle Empfänger dieselbe Emission zugleich sahen. COSE, CWT, CBOR und die RATS-Nachrichtenmodelle schützen Aussagen und verbinden Claims; aus Betriebsannahmen machen sie keine Naturtatsachen.

Dieselbe Emission hat viele Ankunftszeiten

Queues, Multicast-Replikation, intermittierende Leitungen und Zwischenverarbeitung erzeugen Latenz und Skew. Ein verzögert eintreffender Marker bleibt authentisch. Verifier A kann Tick 820 kennen, während ein abgelegener Verifier B noch 818 akzeptiert. Ein globaler Grenzwert 820 würde die Sicht des schnellsten Pfades verallgemeinern und ehrliche Evidenz bei B verwerfen. Unbegrenzte Gültigkeit von 818 verlängert dagegen die Chance eines Replay.

Das gilt für Passport und Background-Check. Im Passport-Fluss trägt der Attester die Evidenz zum Relying Party. Beim Background-Check kann ein anderer Dienst die Bewertung durchführen und ein Attestation Result liefern. Der Marker oder Handle bleibt an das Resultat gebunden; die Policy muss den tatsächlichen Weg des Entscheiders berücksichtigen.

Ein breites Fenster verträgt Entfernung, Schlafphasen und Verarbeitung, verlängert aber die Nutzbarkeit aufgezeichneter guter Evidenz. Ein enges Fenster begrenzt Replay und produziert mehr Fehlablehnungen. Lokale Empfangszeit, Kanal, Transport- und Verarbeitungsbudget sowie Ablaufzeit gehören deshalb in die Entscheidung. Das Protokoll enthält kein universell richtiges Fenster.

Wiederverwendbar heißt nicht einmalig

Ein Epoch Tick soll geteilt werden. Viele Attester können dieselbe Bell-Emission referenzieren. Diese Skalierung bedeutet zugleich, dass der Tick keine einmalige Challenge ersetzt, nur weil er in einem signierten Token steht.

Benötigt eine Sitzung Einmalbindung, liefert der Verifier eine eigene Nonce. Der Entwurf verlangt mindestens 64 Bit Entropie aus einem kryptographisch sicheren Zufallsgenerator und erlaubt bis zu 512 Bit. Die Nonce fragt: „Antwortet dies auf meine Anfrage?“ Der Marker fragt: „An welcher Bell-Position hängt die Evidenz?“ Beide müssen mit Attester-Identität oder -Schlüssel und Evidenz-Digest geschützt verbunden werden.

Ohne diese Verknüpfung lässt sich ein noch zulässiger Marker zu älterer Evidenz oder in eine andere Sitzung tragen. Bell, Schlüssel, Domain, Scope, Marker-Typ und Algorithmus gehören ebenfalls in die Policy. Darf eine nicht vertrauenswürdige Seite die schwächste Variante auswählen, wird Aushandlung zum Downgrade.

Zustandsumfang verteilt Kosten und Fehlablehnung

Ticks und Zähler brauchen gespeicherten Zustand. Ein einziger höchster Wert für die gesamte Bell-Domain ist billig, lässt aber den schnellsten Pfad die Grenze aller Attester vorantreiben. Langsame Teilnehmer wirken dann veraltet, obwohl sie korrekt gearbeitet haben. Zustand pro Attester kostet mehr, trennt aber Verlauf und Konnektivität.

Ein homogenes Rechenzentrum kann mit globaler Grenze und kurzem Fenster auskommen. Eine zeitweise getrennte Industrieflotte benötigt womöglich individuelle Historie, ausgewiesene Pausen und eine Wiederanlaufregel nach Bell- oder Verifier-Neustart. Die Kryptographie entscheidet diese Verteilung nicht. Sie betrifft Speicheraufwand, Verfügbarkeit und die Stelle, an der falsche Ablehnungen landen.

Auch Resynchronisierung braucht Provenienz. Eine Tick List kann Positionen nachliefern, entscheidet aber nicht, wie lange ein älteres Element zulässig bleibt. Verlorener Counter-Zustand kann wie Rollback aussehen. Ein Schlüsselwechsel beginnt eine neue Vertrauensepoche, auch wenn die sichtbare Zeit weiterläuft. Vorherige Grenze, Schlüsselepoche, Ursache und Freigabe der Transition müssen erhalten bleiben.

Eine Bell kann gültig signieren und trotzdem falsch liegen

Eine kompromittierte oder falsch konfigurierte Bell kann kryptographisch makellose Marker ausgeben. Ihre Uhr kann springen, der Zähler sich wiederholen, derselbe Schlüssel an zwei Orten laufen oder ausgewählte Empfänger verspätete Sichten bekommen. Dann gelingt die Signaturprüfung, während die Frischeannahme scheitert.

Bell-Governance braucht benannte Betreiber, Key Custody, Rotation und Widerruf, Überwachung von Uhr oder Zustand, Messung der Verteilung sowie eine Incident-Regel für unsichere Perioden. Mehrere Bells bilden nicht automatisch Konsenszeit. Die Policy muss sie als Alternativen, getrennte Scopes oder Quorum definieren.

Vorhersagbare Ticks können außerdem geschützte Nachrichten korrelierbar machen, weil Beobachter Verkehr um eine Emission gruppieren. Variierende Abstände, Schritte oder Scopes können Linkability reduzieren, verändern jedoch Fenster und Zustand. Datenschutz und Frische sind gemeinsam zu entwerfen.

Den Join aufbewahren, nicht nur den Marker

Ein belastbarer Frischebeleg beginnt mit Bell-Identität, Prüfschlüssel und Schlüsselepoche; Marker-Typ, Bytes oder Digest; Domain, Scope und gegebenenfalls behaupteter Emissionszeit. Getrennt erfasst er lokale Empfangszeit, Verteilungskanal sowie gemessene oder budgetierte Latenz und die Fensterregel.

Danach verbindet er Attester, Evidenz-Digest und Messkontext. Wurde eine Verifier-Nonce genutzt, bleiben Nonce und Sitzung erhalten. Der Beleg nennt globalen, attesterspezifischen oder anders partitionierten Zustand, vorige Grenze, Replay- oder Reordering-Ergebnis, Resynchronisierung und exakte Policy-Version. Entscheidung, Ablauf, Widerruf und Review schließen den Datensatz ab.

Ein späterer Bell-Vorfall kann so betroffene Entscheidungen finden, ohne die Vergangenheit umzuschreiben. Diese Felder sind ein lokaler Governance-Zusatz, kein Auftrag, den interoperablen Marker aufzublähen. Das gemeinsame Objekt bleibt minimal, spätere Entscheidungen bleiben lokal, und die tatsächlich beobachtete Realität bleibt nachprüfbar.

Zum Recherchezeitpunkt war Revision 05 ein aktiver RATS-Arbeitsgruppenentwurf, aktualisiert am 3. Juli 2026 und mit Ablauf am 4. Januar 2027. Datatracker zeigte „WG Document Doc Shepherd Follow-up Underway“ und den IESG-Status „I-D Exists“, ohne zuständigen Area Director oder Telechat. Der Kopf bezeichnete Standards Track, das Feld für den beabsichtigten RFC-Status blieb leer. Diese Abweichung ist zu erhalten; Prozessstand ist kein Einsatznachweis.

Quellen