Zusammenfassung

  • RFC 9919 verlangt nextUpdate: Fehlt das Feld oder liegt die Clientzeit danach, muss die Antwort abgelehnt werden.
  • Eine gültige Signatur belegt Integrität und einen autorisierten OCSP-Unterzeichner, verlängert aber keinen alten good-Status und schützt keine HTTP-Header.
  • Reproduzierbare Kontrolle verbindet Antwortbytes und Signiererlaubnis mit Uhrqualität, Toleranz, Cacheweg, Validatorregel und Anwendungswirkung.

Eine richtige Unterschrift unter einer abgelaufenen Aussage

Bei einer zwischengespeicherten OCSP-Antwort kann alles technisch sauber aussehen: HTTP 200, wohlgeformte Daten, gültige Signatur, Status good. Die entscheidende Prüfung folgt erst mit der lokalen Uhr. Liegt sie nach nextUpdate, ist die Antwort nach RFC 9919 veraltet und zurückzuweisen.

Das Profil ist für PKI-Umgebungen mit sehr vielen Zertifikaten und noch mehr vertrauenden Parteien gedacht. Es erlaubt vorproduzierte Antworten, kleinere Nachrichten, Client- und Netz-Caches sowie die Mitgabe der Antwort in einem anderen Protokoll. So muss der Responder nicht für jede Verbindung eine neue Antwort erstellen.

Die Skalierung funktioniert, weil das Objekt seine Grenze mitführt. thisUpdate bezeichnet den jüngsten Zeitpunkt, zu dem der gemeldete Status als richtig bekannt war. producedAt ist der Signaturzeitpunkt. nextUpdate setzt die Frist, bis zu der neuere Information verfügbar sein soll. Im leichten Profil ist diese Frist verpflichtend.

Eine Signatur kann noch lange nach der Frist mathematisch korrekt bleiben. Sie bindet einen autorisierten Unterzeichner an bestimmte Bytes. Sie macht aus einer vergangenen Statusaussage keine dauerhafte Erlaubnis. Inzwischen kann eine neue Antwort revoked melden.

good ist kein Gesamturteil über das Zertifikat

RFC 6960 definiert good, revoked und unknown. good besagt mindestens, dass der Responder ein Zertifikat mit der abgefragten Seriennummer innerhalb seiner Gültigkeitsdauer nicht als widerrufen kennt. Der Status beweist nicht zwingend, dass das Zertifikat je ausgestellt wurde. Er ersetzt weder Gültigkeitszeit, Vertrauenskette und Dienstidentität noch die Autorisierung der Anwendung.

Vor Annahme prüft der Client die Zuordnung zum Zielzertifikat, die Signatur, die Berechtigung des Unterzeichners für die betreffende CA und die zeitliche Aktualität. Erst danach fließt das Ergebnis in die übrigen Zertifikats- und Anwendungsregeln ein.

„OCSP erfolgreich“ ist deshalb zu grob. Es unterscheidet Erreichbarkeit, definitive Statusantwort, Signatur, Unterzeichnerberechtigung, Frist, Zertifikatsannahme und Verbindungsfreigabe nicht. In einer Untersuchung bleibt damit unklar, welche Grenze tatsächlich versagt hat.

Die Clientuhr wird zur Sicherheitsabhängigkeit

Ein Nonce pro Anfrage erschwert Vorproduktion und gemeinsames Caching. RFC 9919 rät daher üblicherweise von Request-Erweiterungen ab. Sendet ein Client dennoch einen Nonce und erhält ihn nicht zurück, soll er nicht allein deshalb ablehnen, solange die Nonce-Unterstützung des Responders nicht bekannt ist; er fällt auf Zeitprüfung zurück.

Der Client braucht eine genaue Zeitquelle und muss seine aktuelle Zeit zwischen thisUpdate und nextUpdate einordnen. Eine kleine Toleranz ist für Uhrdifferenzen möglich, muss aber zur messbaren Genauigkeit und Präzision der Umgebung passen. Sie ist kein pauschaler Aufschub.

Eine voreilende Uhr lehnt frische Antworten zu früh ab. Eine nachgehende Uhr kann einen abgelaufenen good-Status akzeptieren, obwohl das Zertifikat inzwischen widerrufen ist. Der Nachweis „Zeitsynchronisation läuft“ genügt nicht. Für eine Rekonstruktion braucht man den tatsächlich verwendeten Zeitwert, Quelle, Abweichung oder Unsicherheit, Toleranz und nahe Zeitsprünge.

HTTP-Frische verteilt Bytes, OCSP-Frische begrenzt Autorität

Kleine Anfragen müssen GET verwenden, damit Caches sie bedienen können. Der Responder liefert Date, Last-Modified, Expires, ETag und Cache-Control. max-age kann Aktualisierungen vor nextUpdate verteilen; must-revalidate verhindert absichtliches Ausliefern veralteter Darstellungen.

RFC 9919 stellt zugleich klar, dass diese Header kryptografisch ungeschützt sind. Sie steuern die Auslieferung. Für die Statusentscheidung zählen die signierten Werte in der OCSP-Antwort. Ein späteres HTTP-Expires verlängert nextUpdate nicht. Auch ein nach HTTP-Regeln frisches Cacheobjekt entbindet die Anwendung nicht von der signierten Zeitprüfung.

Liefert ein Proxy abgelaufene Bytes, kann der Client ihn mit einer No-Cache-Anfrage umgehen. Die neu geholte Antwort durchläuft trotzdem Identitäts-, Signiererlaubnis-, Signatur-, Status- und Zeitprüfung.

TLS-Stapling verschiebt ebenfalls nur die Übergabe. Der TLS-Server transportiert die OCSP-Antwort, wird aber nicht zum Autor ihres Status. Die lokale Entscheidung bleibt beim Client.

SHA-256 modernisiert eine Stufe

RFC 9919 löst RFC 5019 ab und verlangt SHA-256 für die Hashes von Ausstellername und Ausstellerschlüssel in CertID. Dauerhafte SHA-1-Kompatibilität erhöht Implementierungskomplexität und Angriffsfläche; der Umstieg ist daher relevant.

Er beweist aber keine Aktualität. Ein SHA-256-identifiziertes Objekt kann abgelaufen sein. Eine starke Signatur kann von einem für diese CA unberechtigten Signierer stammen. Ein korrekter Cache kann an einen Client mit falscher Uhr liefern. Algorithmusmigration und Statusentscheidung brauchen getrennte Nachweise.

Einen Entscheidungsbeleg statt einer Erfolgszahl bewahren

Der Beleg umfasst Zertifikatsfingerabdruck und Seriennummer, Ausstellernamen- und Schlüss hashes samt Algorithmen, vollständige OCSP-Bytes und Hash, Responder-ID, Signiererkette und Berechtigung, producedAt, thisUpdate, nextUpdate, Status und Widerrufsfelder.

Hinzu kommen Empfangszeit, lokale Zeitquelle und Unsicherheit, Toleranz, Nonce-Verhalten, Validatorversion und Regel, Annahme- oder Ablehnungsgrund sowie die folgende Anwendungsaktion. Cacheknoten, Age, ETag, Expires, Umgehungsversuch und erneutes Ergebnis werden als Liefernachweis aufbewahrt, nicht als signierter Status.

Damit bleiben vier Ebenen getrennt: HTTP zeigt, wie die Bytes ankamen. OCSP zeigt, was ein berechtigter Responder für welchen Zeitraum aussagte. Der lokale Datensatz zeigt, warum der Client entschied. Die Anwendung zeigt die Folge. Ein grüner Zähler ersetzt keine dieser Verbindungen.

Quellen