Zusammenfassung

  • Nach RFC 3029 konnte ein Validierungsdienst ordnungsgemäß ausgeführt werden und ein signiertes DVC liefern, obwohl das Ergebnis für das geprüfte Objekt ungültig war.
  • Das DVC band Anfrage oder Fingerabdruck, Zeit, Seriennummer, Richtlinie, Gesamtergebnis und Einzeldetails; der Empfänger musste Antwort und Verwendungszweck weiterhin selbst prüfen.

Das Wort Zertifikat klingt nach Bestätigung. Das Data Validation Certificate aus RFC 3029 war dagegen ein signierter Entscheidungsbeleg. Es sagte, was ein Server unter festgelegten Bedingungen festgestellt hatte. Ein negatives Ergebnis war kein defektes Zertifikat, sondern konnte dessen wichtigste Aussage sein.

Die Spezifikation trennt die Ebenen ausdrücklich. DVCSCertInfo wird nach erfolgreicher Ausführung des Dienstes zurückgegeben; diese Ausführung bedeutet jedoch nicht, dass die Validierung erfolgreich war. Anfrageverarbeitung, authentische Serverantwort und Gültigkeit des Gegenstands bleiben drei verschiedene Tatsachen.

Vier Dienste begrenzten vier Aussagen

cpd bestätigte den Besitz tatsächlich vorgelegter Daten. ccpd erhielt nur einen Nachrichtenfingerabdruck und bestätigte den damit verbundenen Besitzanspruch; der Server hatte die ursprünglichen Bytes nicht zwingend gesehen. Ein Nachweis über den Fingerabdruck durfte nicht als Nachweis der Datenübergabe ausgegeben werden.

vsd prüfte signierte Dokumente einschließlich mathematischer Signaturen, Zertifikatsketten, Statusangaben und Vertrauen. vpkc prüfte ein oder mehrere Zertifikate zu einem angegebenen Zeitpunkt. CRLs, OCSP, Verzeichnisse oder andere DVCS konnten Eingaben liefern. RFC 3029 stellte aber klar, dass DVCS CRLs und OCSP in großen offenen Umgebungen nicht ersetzen sollte.

Ähnlich aussehende DVCs beantworteten also verschiedene Fragen: Wurden Daten vorgelegt, wurde ein Fingerabdruck vorgelegt, erfüllt das signierte Dokument die Richtlinie, oder erfüllt ein Zertifikat Pfad- und Statusregeln? Ein gemeinsames „verifiziert“ hätte diese Grenzen verdeckt.

Die Signatur schützte eine gegliederte Antwort

Ein DVC war CMS SignedData. Darin blieben Anfrageinformationen, messageImprint, fortlaufende Seriennummer, Antwortzeit, Richtlinie, Gesamtstatus und Einzelresultate getrennt. Kam die Zeit von einem externen Zeitstempel oder DVC, musste der Server auch diesen Wert validieren.

Der Client durfte deshalb nicht bei der äußeren Signatur stehen bleiben. Er sollte akzeptable Zeit, DVCS-Namen, Anfragebezug, Fingerabdruck, Signatur, Status, Dienst und Richtlinie prüfen und das Signaturzertifikat des DVCS bewerten. Eine korrekt signierte Antwort für den falschen Fingerabdruck beantwortet eine andere Frage. Eine nicht akzeptierte Richtlinie wird durch Kryptografie nicht passend.

Richtlinien erklären unterschiedliche ehrliche Ergebnisse für dasselbe Objekt. Vertrauensanker, Statusquellen und erforderliche Signaturzahlen können abweichen. Das DVC behauptete keine universelle Gültigkeit, sondern hielt fest, welcher Server wann unter welcher Richtlinie für welche Anfrage zu welchem Ergebnis kam.

Gesamtstatus und Einzelergebnis blieben verschieden

Bei mehreren Zertifikaten konnte ein einziges Element den Gesamtfehler verursachen. Bei mehreren Signaturen musste eine fehlerhafte Signatur das Dokument nicht zwingend scheitern lassen, wenn die Richtlinie eine ausreichende Teilmenge akzeptierte; dann war grantedWithMods möglich. Umgekehrt konnten einzeln korrekte Signaturen eine globale Mindestzahl oder Kombination verfehlen. granted war nur erlaubt, wenn alle Signaturen erfolgreich verifiziert wurden.

WAITING war ebenfalls kein vorläufiges Ja, sondern zeigte, dass die endgültige Antwort noch fehlte. Der Gesamtstatus war eine Richtlinienentscheidung, kein Ersatz für Details.

Ein signiertes Nein war kein unsignierter Fehler

Nach ausgeführter Prüfung konnte ein signiertes DVC „ungültig“ melden. Konnte die Anfrage wegen Format oder Authentifizierung gar nicht ausgeführt werden, entstand eine Fehlermeldung. Der erste Fall beantwortete die Sachfrage negativ, der zweite erreichte sie nicht.

Konnte das DVCS selbst keine gültige Signatur erzeugen, etwa bei bekannt kompromittiertem Schlüssel, sah RFC 3029 eine Struktur ohne Signiererinformation vor. Clients mussten sie als kritisch und fatal behandeln und durften dem Inhalt nicht stillschweigend vertrauen. Das signierte negative Urteil ist authentifizierte Evidenz; der unsignierte Fehler ist ein Ausfall der Antwortautorität.

RFC 3029 erschien im Februar 2001 als Experimental und nicht als Internet Standard. RFC 3379 und RFC 5055 behandelten später Anforderungen und Protokoll für delegierte Validierung. Sie belegen keine DVCS-Verbreitung. Die historische Aussage ist enger: Wer die Berechnung delegiert, gibt die Verantwortung für Bedeutung und Folgewirkung nicht automatisch ab.

Quellen

Lu Heng hat RFC 3029 und die zugehörigen PKIX-Standards weder verfasst noch gebilligt. Seine Texte dienen hier als offengelegte analytische Perspektiven.