Zusammenfassung

  • RFC 5276 kann Evidence Records für von SCVP gelieferte Zertifikate, vollständige oder partielle Pfade und Sperrinformationen zurückgeben; die Beweise gelten für genau zugeordnete Bytes.
  • Die Langzeitwirkung entsteht nur durch rechtzeitige Erneuerung, nachprüfbare Antwortauthentizität und erhaltene Richtlinien — nicht dadurch, dass ein alter Pfad unverändert gespeichert wird.

Ein Archiv kann jeden Datenträger überleben und trotzdem seinen Beweis verlieren. Die Bytes sind noch da, der erste Archivzeitstempel ist noch lesbar, der Zertifikatspfad liegt unverändert daneben. Aber der Signaturalgorithmus des Zeitstempels wurde Jahre zuvor untragbar, und niemand hatte rechtzeitig eine neue Schicht darübergelegt.

Das ist kein Speicherfehler. Es ist ein Wartungsfehler.

RFC 5276 beschreibt, wie SCVP Antworten zusammen mit Evidence Records für langfristige Zertifikatsprüfung liefern kann. RFC 4998 beschreibt, was diese Langfristigkeit verlangt: erneuerte Archivzeitstempel, bei Bedarf neue Hash-Bäume und die fortlaufende Erhaltung aller Prüfdaten. Der Beweis bleibt belastbar, weil er vor dem Verfall weitergeführt wird — nicht weil sein erstes Siegel magisch zeitlos wäre.

Zwei Arten der Erneuerung

Ein Archivzeitstempel belegt, dass bestimmte Daten oder eine Datengruppe zu einem Zeitpunkt existierten. Verliert die Signatur des Zeitstempels an Stärke oder läuft das maßgebliche Zertifikat aus, deckt ein neuer Zeitstempel den vorherigen ab. Diese Zeitstempelerneuerungen bilden eine Kette.

Wird dagegen der Hash-Algorithmus des geschützten Baums schwach, genügt es nicht, nur den letzten Zeitstempel erneut zu signieren. Eine Hash-Baum-Erneuerung deckt die alten Zeitstempel und die archivierten Daten mit einer neuen Hash-Konstruktion ab und eröffnet eine neue Kette. Mehrere Ketten bilden die Sequenz des Evidence Record.

Die operative Konsequenz ist klar: Jede Beweiskette hat ein nächstes Eingriffsdatum. Verantwortliche müssen die letzte starke Schicht, Algorithmusgrenzen, Zeitstempelzertifikate und vorhandene Verifikationsdaten überwachen. Eine Erneuerung nach einer unbelegten Lücke kann die fehlende Kontinuität nicht allein zurückerfinden.

RFC 9169 liefert modernere ASN.1-Module für RFC 4998 und RFC 5276. Das verbessert die Darstellungsgrundlage, ändert aber nicht die semantische Pflicht zur Erneuerung und unabhängigen Vertrauensentscheidung.

RFC 5276 bindet den Beweis an den Rückgabewert

SCVP kann über WantBacks zusätzliche Zertifikatsdaten liefern. RFC 5276 definiert EvidenceRecord-WantBacks für ein Endzertifikat, einen vollständigen Pfad, einen Teilpfad und Sperrinformationen.

Für einen Pfad deckt der EvidenceRecord den DER-codierten CertBundle-Wert der korrespondierenden Antwort ab. Für ein einzelnes Zertifikat ist der Zertifikatswert in CertReply das Ziel. Bei CRLs oder OCSP-Antworten muss jedes Sperrobjekt einem Beweis zugeordnet werden; derselbe Beweis kann mehrere Objekte abdecken, wenn ihr Hash im ersten Archivzeitstempel auffindbar ist.

Die Sammelform benennt durch targetWantBack, welche Antwortart ein EvidenceRecord schützt, und verlangt eine Eins-zu-eins-Zuordnung. Das verhindert, dass ein gültiger Beweis für Material A als Beweis für Material B präsentiert wird.

Ein langlebiger Beweis ist damit immer eine Aussage mit Objektbereich: diese Bytes, diese Hash-Beziehung, diese Zeitstempelsequenz. Er bestätigt nicht automatisch, dass der Pfad für jede Anwendung akzeptabel oder das zugehörige Archivdokument mit dem Endzertifikat signiert wurde.

Fehlender Beweis und negatives Ergebnis sind verschieden

Kann der Server den verlangten EvidenceRecord nicht liefern, enthält die entsprechende Antwort einen leeren Wert. In der Sammelform fehlt das Beweisfeld für das Ziel. Wird der EvidenceRecord ohne das zu schützende Objekt angefordert, ist der WantBack unbefriedigt.

Diese Zustände sagen etwas über Beweisverfügbarkeit, nicht unmittelbar über Zertifikatsgültigkeit. Ein leeres Feld ist keine Sperrung. Ein verifizierter EvidenceRecord ist keine Aufhebung einer Sperrung. Zertifikatsstatus und Erhaltungsstatus brauchen getrennte Achsen.

Auch „Anfrage verarbeitet“ genügt nicht. Eine belastbare Anzeige trennt Syntaxannahme, Objektlieferung, Beweislieferung, Beweisprüfung, Pfadentscheidung und spätere Anwendungsentscheidung. Nur dann lässt sich ein lokaler Mangel beheben, ohne eine pauschale Erzählung zu erfinden.

Teilpfade verschieben die Wartungsgrenze

Ein vollständiger Pfad enthält das Endzertifikat bis zum Vertrauensanker. Ein partieller Pfad beginnt bei der ausstellenden CA; das Endzertifikat kann zusammen mit dem signierten Archivdokument geschützt werden. Viele Dokumente ähnlichen Alters können dadurch denselben oberen Pfad nutzen.

Die Optimierung verteilt die Wartung. Das Dokumentarchiv muss die Bindung zwischen Datei, Signatur und Endzertifikat erhalten. Der SCVP-nahe Bestand erhält den Teilpfad und Sperrmaterial. Der spätere Prüfer muss beide Bestände zusammenführen und nachweisen, dass das Endzertifikat an den Teilpfad anschließt.

Eine Seite kann perfekt gepflegt und die andere unbrauchbar sein. Deshalb braucht jeder Teilpfad eine explizite Beziehungsakte: Dokumenthash, Signatur, Zertifikatshash, Pfadkennung, Sperrzeitraum, EvidenceRecord-Zuordnung und Richtlinie. Speicherersparnis ohne diese Metadaten erzeugt Rekonstruktionsschulden.

Richtlinie und Vertrauensanker altern anders als Kryptografie

RFC 5055 erlaubt dem Client, Validierungsrichtlinie, Zeitpunkt, Vertrauensanker, Schlüsselverwendung, erweiterte Verwendung und Sperrprüfung zu bestimmen. RFC 5280 behandelt den Vertrauensanker als Eingabe. Verschiedene Anwendungen können verschiedene Anker und zusätzliche Einschränkungen verwenden.

Darum kann ein unveränderter Pfad bei einer späteren Prüfung anders bewertet werden. Die Kryptografie des Evidence Record kann vollständig intakt sein, während eine Anwendung den ursprünglichen Anker nicht mehr akzeptiert oder eine strengere Zweckbindung verlangt.

RFC 5276 verlangt zudem, die Signatur der SCVP-Antwort mit einem vom vertrauenden Empfänger akzeptierten öffentlichen Schlüssel zu prüfen. In der Antwort transportierte Anker können für innere ERS-Schichten genutzt oder zugunsten extern bezogener Anker verworfen werden. Ein nicht signierter Transport verleiht seinen Ankern keine Glaubwürdigkeit.

Wartung betrifft daher nicht nur Algorithmen. Auch Richtlinienreferenzen, Parameter, Ankerherkunft und die Vertrauensbasis für den SCVP-Antwortschlüssel müssen erhalten werden. Sonst bleibt eine prüfbare Signatur ohne nachvollziehbare Bedeutung.

Historische Antworten brauchen einen Korrekturpfad

Mit validationTime kann SCVP den bekannten Zertifikatsstatus zu einem früheren Zeitpunkt beurteilen. Fehlen geeignete historische Daten, muss der Server einen Fehler melden. Das verhindert, dass heutiges Ablaufdatum und damalige Gültigkeit verwechselt werden.

RFC 5055 warnt dennoch: Später kann eine Sperrmitteilung bekannt werden, deren invalidityDate vor dem abgefragten Zeitpunkt liegt. Die frühere positive Antwort war dann womöglich korrekt authentisiert und nach damaligem Wissen richtig, wird aber durch spätere Information überholt.

Ein Langzeitarchiv muss deshalb Erkenntniszeit und Gegenstandszeit führen. Es bewahrt die ursprüngliche Antwort, ergänzt aber eine nachvollziehbare Ablösung. Unveränderlichkeit bedeutet, dass die alte Aussage nicht heimlich umgeschrieben wird; sie bedeutet nicht, dass die Aussage jede spätere Evidenz beherrscht.

Nonce-Prüfung und Antwortschutz gehören zur Erwerbskette. Ohne sie kann eine alte Antwort wiederholt oder verändert werden. Was bei der Aufnahme nicht authentisiert wurde, gewinnt durch jahrelange Lagerung keine neue Herkunft.

Zusatzinformationen sind nicht automatisch mitgestempelt

cryptoInfos in RFC 4998 kann Zertifikate, Sperrdaten, Vertrauensanker oder historische Eignungsbewertungen von Algorithmen aufnehmen. Genau hier setzt der Text eine Grenze: Diese Daten sind nicht durch einen Zeitstempel geschützt und müssen über andere Mechanismen verifiziert werden.

Das ist ein Muster für das gesamte System. Container, Nähe und Nützlichkeit sind keine Authentizitätsnachweise. Ein Prüfbericht sollte ausweisen, welche Bytes ein Archivzeitstempel tatsächlich deckt und welche Kontextinformationen außerhalb dieses Bereichs liegen.

Die gleiche Genauigkeit gilt für SCVP. Die Antwortsignatur deckt die Aussage des Servers. Der EvidenceRecord deckt die zugeordnete Information. Die Dokumentensignatur deckt das Archivdokument. Die Anwendungsrichtlinie entscheidet den zulässigen Zweck. Kein Siegel springt automatisch über die Grenze des anderen.

Wartung als nachvollziehbarer Kontrollplan

Ein belastbarer Bestand führt pro Entscheidung: Archivdokument und Hash, Signatur und Endzertifikat, Anfragezeit, Validierungsrichtlinie, Vertrauensanker, SCVP-Responder und Antwortschutz, zurückgegebene Pfad- und Sperrobjekte, jeweilige EvidenceRecords, Erneuerungsfristen, tatsächliche Erneuerungen, spätere Korrekturinformationen und die Anwendungsentscheidung.

Dieser Plan macht Störungen begrenzt. Ein veralteter Hash löst eine Beweiserneuerung aus. Ein neuer Sperrhinweis löst eine zeitlich begrenzte Neubewertung aus. Ein Richtlinienwechsel erzeugt eine neue Entscheidung neben der alten. Ein fehlender WantBack bleibt als Unsicherheit sichtbar, statt als pauschaler Fehler umetikettiert zu werden.

RFC 5276 behauptet weder aktuelle Verbreitung noch Erfolg eines Produkts oder rechtliche Wirkung. Seine Stärke liegt in der überprüfbaren Beziehung zwischen Rückgabewert und Langzeitbeweis.