Zusammenfassung

  • CTT lässt die Zeitstempelstelle über das kodierte COSE-Signaturfeld stempeln. TTC lässt sie über die Nutzlast stempeln und bindet Token und Nutzlast erst danach durch eine COSE-Signatur zusammen.
  • Ein geschützter 3161-ttc-Header belegt keine rückwirkende Signaturzeit. Für historische Zertifikatsgültigkeit darf nur der Signaturumfang die Zeitfolgerung tragen.

Die Sperrmeldung war eindeutig, die Prüfmaske ebenfalls. Das Zertifikat war widerrufen; der Zeitstempel lag davor; die COSE-Signatur war gültig. Aus drei korrekten Befunden entstand ein falscher Satz: „Die Signatur wurde vor dem Widerruf erstellt.“

Der Fehler steckt nicht in der Kryptografie, sondern im Bezugspunkt des Zeitstempels. Hat eine Partei zuerst nur den Hash der Nutzlast an eine Time Stamping Authority (TSA) gesendet, kann sie deren Token später—auch nach einem Widerruf—gemeinsam mit der Nutzlast signieren. Das spätere COSE-Objekt schützt dann den älteren Token. Es macht die damals noch nicht vorhandene Signatur aber nicht zu einem damals vorhandenen Objekt.

RFC 9921 schafft dafür zwei getrennte COSE-Headerparameter auf Basis von RFC 3161. Die Unterscheidung ist nicht optional. Die Sicherheitsbetrachtung des RFC nennt ausdrücklich die Gefahr, eine nach Schlüsselwiderruf erzeugte Signatur wegen eines älteren, nur die Nutzlast betreffenden Zeitstempels zu akzeptieren.

CTT und TTC beantworten nicht dieselbe Frage

Bei COSE, Then Timestamp (CTT) wird zuerst die COSE-Signatur erzeugt. Anschließend wird der Hash des CBOR-kodierten Felds signature bei COSE_Sign1 beziehungsweise des CBOR-kodierten Felds signatures bei COSE_Sign an die TSA gegeben. Der zurückgelieferte Token steht im ungeschützten Headerparameter 3161-ctt.

Damit bezieht sich der TSA-Nachweis auf die Signaturbytes in dem von RFC 9921 festgelegten Kodierungsumfang. Wenn COSE-Signatur, Token, TSA-Zertifikat und anwendbare Vertrauens- und Zeitrichtlinie validiert sind, lässt sich begrenzt feststellen: Die Signatur lag zur TSA-Zeit bereits vor. Diese Konstruktion ist der Weg für langfristige Signaturen, bei denen ein späterer Ablauf oder Widerruf eines Zertifikats den korrekt belegten früheren Vorgang nicht auslöschen soll.

Timestamp, Then COSE (TTC) beginnt dagegen mit den Bytes der Nutzlast. Deren Hash—ohne CBOR-bstr-Umhüllung und ohne eine noch nicht vorhandene Signatur—wird gestempelt. Der Token kommt in den geschützten Headerparameter 3161-ttc; erst danach signiert COSE den geschützten Header und die Nutzlast.

TTC bewahrt eine andere, wichtige Kette. Es kann einen Nachweis der früheren Nutzlast innerhalb einer später signierten Erklärung erhalten. RFC 9921 verwendet das bei Transparenz und Notarisierung: Der Token bleibt im signierten Statement, bevor dessen signierte Teile in ein append-only Log gelangen. Daraus folgt jedoch weder automatisch die Log-Aufnahme noch die Identität des Ausstellers, weder eine Widerrufsreihenfolge noch eine Handlungsbefugnis. Und es folgt besonders nicht, dass die COSE-Signatur schon zur Zeit des TSA-Tokens existierte.

Der Headerplatz bestimmt die begleitende Kontrolle

Dass 3161-ctt ungeschützt ist, ist eine Folge der Reihenfolge. Der Token kommt erst nach der COSE-Signatur zurück; die frühere Signatur kann ihn nicht nachträglich schützen. RFC 9921 weist deshalb darauf hin, dass ein Angreifer den Header entfernen oder ersetzen kann. Die nötige Ergänzung ist Integritätsschutz für die vollständige COSE Signed Message während Transport und Aufbewahrung.

Das bedeutet nicht, CTT sei minderwertig. Es bedeutet, dass die Beweiskette ihren Träger nennen muss. Archiv und Transport sollen Objekt-Hash, CTT-Modus, exakte Imprint-Eingabe, TSA-Zertifikat und -Policy, Statusnachweise und die Schutzschicht der Aufbewahrung festhalten. Fehlt der CTT-Token nach einer Migration, fehlt der historische Zeitnachweis. Ein Statusfeld darf nicht so tun, als sei die Beweislage unverändert.

Der geschützte TTC-Header löst ein anderes Problem: Eine Änderung des Tokens nach der COSE-Signatur wird sichtbar. Er dreht die Reihenfolge der Ereignisse nicht um. „Geschützt“ sagt, was der spätere Signierer einbezog; es sagt nicht, was die TSA zuvor gesehen hat.

Von der Tokenprüfung zur verantwortlichen Entscheidung

RFC 3161 stempelt eine Hash-Repräsentation, nicht die Bedeutung eines Dokuments. Ein Client prüft Antwortstatus, TSA-Identität und -Zertifikat, angeforderte Imprint, Algorithmus, Frische über Nonce oder vertrauenswürdige lokale Zeit, Zertifikatsstatus und Policy-Akzeptanz. genTime ist der Ausgabezeitpunkt des TSA-Tokens; Genauigkeit, Auflösung, Latenz und Policy begrenzen die daraus abgeleitete Aussage.

RFC 9921 verlangt zusätzlich die konkrete Bindungsprüfung. Der Empfänger muss die MessageImprint über genau die Bytes neu berechnen, die der gewählte Modus verlangt: Signaturfeld für CTT, Nutzlast für TTC. Ein gültiger CMS-Token irgendwo im Paket ist kein Ersatz. Ohne diese erneute Berechnung fehlt der Beweis, welche Aussage das System überhaupt treffen darf.

Die Betriebsakte sollte daher nicht „Zeitstempel vorhanden“ sagen, sondern die Kette ausweisen: Modus; relevante Bytes; Token- und COSE-Validierung; TSA-Policy; Status- und Genauigkeitsannahmen; Widerrufsregel; bei Transparenz zusätzlich Inclusion- und Consistency-Proof; verantwortliche Entscheidung; beobachtete Wirkung. Heng Lus Hinweis auf laufenden Code ist hier konkret: Entscheidend ist der Pfad, der diese Schritte tatsächlich ausführt, nicht ein Kontrollkästchen im Design-Dokument.

Sources