Zusammenfassung

  • ES-T belegte eine frühe Existenz der Signatur, ES-C verwies auf Zertifikate und Sperrdaten, ES-X bewahrte oder schützte diese Daten, und ES-A erlaubte eine erneute Zeitstempelung vor dem Schwächerwerden des bisherigen Schutzes.
  • Dauer entstand nicht aus einem Formatnamen. Sie verlangte exakte Bytes, echte Validierungswerte, die richtige Policy und rechtzeitige Erneuerung.

Die Signatur blieb, ihre Beweisumgebung nicht

Digitale Bits lassen sich verlustfrei kopieren. Die Umgebung einer Signatur altert: Zertifikate laufen ab, alte Sperrlisten verschwinden, OCSP-Dienste werden eingestellt, TSA-Zertifikate enden, und Hashverfahren verlieren ihre Eignung.

RFC 3126 erschien im September 2001 als Informational und machte diese Zeitdifferenz zum Thema. Auf der Policy-Signatur aus RFC 3125 baute sie mit CMS, ESS, X.509, Sperrinformationen und vertrauenswürdigen Zeitstempeln weiter. Aufzubewahren war nicht nur der Signaturwert, sondern die Begründung der ersten Validierung.

ES-T datierte Existenz, nicht Wahrheit

Die Grundform ES enthielt die Signatur. ES-T ergänzte einen Zeitstempel. Lieferte der Unterzeichner ihn nicht, musste der Prüfer ihn beim ersten Empfang erzeugen oder einen sicheren Zeitnachweis nahe der ersten Prüfung führen.

RFC 3161 begrenzte die Aussage: Eine TSA signiert einen Message Imprint und zeigt, dass die dargestellten Daten zu einem Zeitpunkt existierten. Sie muss das Dokument nicht lesen. Der Stempel beweist weder Wahrheitsgehalt noch Vertretungsmacht, vollständige Policy-Erfüllung oder Geschäftserfolg.

Die zeitliche Ordnung blieb wertvoll. Wurde der Schlüssel später kompromittiert, konnte ein früherer Stempel die Signatur vor dem Vorfall verorten. Doch auch die TSA hatte Schlüssel, Zertifikat, Policy und begrenzte Lebensdauer. Vertrauen wurde verlagert.

ES-C bewahrte das Validierungsrezept

ES-C baute auf ES-T auf und enthielt Referenzen auf Zertifizierungspfad und Sperrinformationen. Ein späterer Prüfer konnte feststellen, welche Zertifikate, CRLs oder Statusantworten die damalige Entscheidung getragen hatten.

Vollständige Daten waren beim Signieren nicht immer verfügbar. Eine Sperrinformation konnte eine Schonfrist brauchen; eine vorläufige Suspendierung musste sich erst klären. Langzeitbeweise entstanden deshalb in mehreren Arbeitsschritten.

Eine Referenz war noch kein Wert. Verschwand das Repository, half sein Identifier nicht. X-Long nahm die tatsächlichen Zertifikate und Sperrwerte auf. Das war der Unterschied zwischen Katalogeintrag und archiviertem Werk.

Auch OCSP urteilte begrenzt. RFC 2560 unterschied good, revoked und unknown zu bestimmten Zeiten. Good belegte nicht jede Zertifikatsbedingung, die Befugnis des Unterzeichners oder das Ergebnis des Geschäfts.

ES-X schützte die Geschichte der Nachweise

ES-X behandelte Verfügbarkeit und spätere Kompromittierung. X-Long speicherte Werte. X-Time-Stamp Typ 1 versah das gesamte ES-C mit Zeit, Typ 2 die Zertifikats- und Sperrreferenzen; Kombinationen waren möglich.

Wurde ein CA-Schlüssel Jahre später gestohlen, zeigte eine im Streit vorgelegte Kette allein nicht, dass sie schon vorher existierte. Ein früher Zeitstempel über den Validierungsdaten konnte diese Reihenfolge unter der anwendbaren Policy stützen.

Eine zusätzliche Schicht heilte keine falsche Erfassung. Fehlender Inhalt, ein falscher Pfad oder ein erst nach dem Vorfall erzeugter Stempel blieben Fehler in einer aufwendigeren Hülle.

ES-A machte Archivierung zu Wartung

ES-A richtete sich gegen das Altern des Schutzes selbst. Bevor Algorithmen, Schlüssel oder frühere Zeitstempelzertifikate schwach wurden, sollten signierte Daten, ES-C und ES-X erneut gestempelt werden, möglichst mit stärkerem Algorithmus oder längerer Schlüssellänge. Der Vorgang war wiederholbar.

Der Archivstempel umfasste Inhalt, signierte Attribute, Signatur, ersten Zeitstempel, Referenzen, gespeicherte Werte, ES-X-Schutz und alle früheren Archivstempel. So entstand eine kryptografische Verwahrungskette.

Unsterblich war sie nicht. Der Verwahrer musste erneuern, solange die vorige Schicht noch prüfbar war. Ein gebrochener Hash, ein TSA-Schlüssel ohne belastbare Zeitgrenze oder verlorene Werte ließen sich mit einem neuen Stempel nicht rückwirkend reparieren. RFC 4998 unterschied später allgemeiner zwischen Zeitstempelerneuerung und Erneuerung mit neuem Hash.

Exakte Bytes gehörten zum historischen Objekt

RFC 3126 verlangte bei jeder Prüfung denselben OCTET STRING. Eine Archivmigration konnte die Evidenz bei gleichem Aussehen zerstören: normalisierte Zeilenenden, neue Zeichenkodierung, verlorener Detached Content oder ein erneuter Export änderten den kryptografischen Eingang.

Das dauerhafte Objekt war ein Bündel aus Bytes, Signatur, Attributen, Policy, Zertifikatspfad, datiertem Status, Tokens, Werten und Erneuerungen. Ein lesbares Dokument plus Datenbankfeld „gültig“ reichte nicht zur Wiederholung der Entscheidung.

RFC 5126 löste RFC 3126 ab und behielt CAdES-T, CAdES-C, CAdES-X und CAdES-A. Diese Kontinuität belegt den Fortbestand des Entwurfs, nicht dessen universelle Nutzung im Jahr 2001.

Langzeitfähigkeit verteilte Verantwortung

Der Unterzeichner steuerte den ursprünglichen Akt. Der Prüfer erfasste Zeit und Daten. CAs und Statusdienste lieferten begrenzte Nachweise. Die TSA datierte den Imprint. Der Archivverwalter bewahrte und erneuerte. Ein späterer Schiedsrichter wandte Policy und äußeres Rechts- oder Vertragsinstrument an.

Der historische Beitrag von RFC 3126 war diese operative Disziplin: festhalten, was der erste Prüfer wusste; aufnehmen, was entfernte Dienste vergessen könnten; die Beweise vor späterer Kompromittierung schützen; und erneuern, bevor alte Annahmen fallen. Der Beweis überlebte den Schlüssel nur, weil die Kette weiterarbeitete.

Quellen

  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