Zusammenfassung

  • RFC 9919 erlaubt vorproduzierte OCSP-Antworten in Client-, Proxy- und Server-Caches, behandelt HTTP-Header aber nur als Cache-Hinweise, weil sie nicht kryptografisch geschützt sind.
  • Der Client ordnet die Antwort dem Zertifikat zu, prüft Signatur und Berechtigung des Responders und vergleicht signiertes thisUpdate und nextUpdate mit einer genauen lokalen Uhr.
  • Ein frisches good ist begrenzte Sperrstatus-Evidenz. Es beweist allein weder Ausstellung noch vollständige Gültigkeit, Anwendungsberechtigung oder Betriebswirkung.

Der Responder muss nicht live antworten

Bei sehr großen Zertifikatspopulationen wäre eine neue Berechnung und Signatur pro Anfrage teuer und anfällig für Lastspitzen. RFC 9919 ersetzt RFC 5019 und baut auf Vorproduktion, kleineren Nachrichten, GET für kurze Anfragen und der Wiederverwendung in mehreren Cache-Ebenen auf.

Damit entstehen zwei ähnlich benannte Entscheidungen. HTTP-Frische sagt, ob eine gespeicherte Repräsentation erneut ausgeliefert werden darf. OCSP-Frische sagt, ob die Statusaussage eines berechtigten Signierers noch innerhalb ihres signierten Zeitraums liegt. Expires, ETag und Cache-Control organisieren die erste Entscheidung; sie sind kein Bestandteil der OCSP-Signatur.

RFC 9919 warnt ausdrücklich, dass diese Header verändert werden können. Clients sollen sie nur zur Cache-Steuerung verwenden und sich letztlich auf die Werte in der signierten OCSPResponse stützen. Ein Cache-Treffer beweist einen effizienten Lieferweg. Er beweist keine neue Statusabfrage zum Zeitpunkt des Treffers.

Drei Zeitfelder und die Uhr des Clients

thisUpdate gibt an, wann der Responder den gemeldeten Status als korrekt kannte. nextUpdate bezeichnet den Zeitpunkt, zu dem spätestens neuere Information verfügbar wird. producedAt ist der Signaturzeitpunkt. Bei Vorproduktion können Werte zusammenfallen, ohne dieselbe Bedeutung zu haben.

RFC 9919 verlangt nextUpdate in diesem Profil. Der Client muss das Feld finden und seine aktuelle GMT-Zeit zwischen thisUpdate und nextUpdate einordnen. Danach ist die Antwort stale. Eine kleine lokale Toleranz kann geringe Uhrabweichungen abfangen, muss aber zur tatsächlichen Synchronisationsqualität passen und in der Entscheidungsaufzeichnung erscheinen.

Eine vorgehende Uhr weist eine noch frische Antwort zu früh ab und macht Zeitfehler zum Verfügbarkeitsproblem. Eine nachgehende Uhr akzeptiert eine abgelaufene good-Antwort weiter, obwohl eine neuere bereits revoked melden könnte. In beiden Fällen kann die Signatur korrekt sein. Kryptografische Integrität korrigiert den Vergleichszeitpunkt nicht.

Ein Nonce bindet Anfrage und Antwort gegen Replay. Das leichte Profil muss jedoch zeitbasierte Frische beherrschen und verwirft unter den vorgesehenen Bedingungen nicht allein wegen eines fehlenden erwarteten Nonce. Uhr, Zeitfenster, Toleranz und Nonce-Verhalten gehören deshalb in einen gemeinsamen Prüfbeleg.

max-age verteilt Last; nextUpdate beendet die Aussage

RFC 9919 legt HTTP max-age nach thisUpdate, aber vor nextUpdate. Clients können Ersatz holen, bevor das signierte Fenster schließt; der Responder muss vorher eine neue Antwort bereitstellen. Bei populären Zertifikaten kehren so nicht alle Clients in derselben Sekunde zurück.

Das ist Laststeuerung, keine Verlängerung des Status. Ein Proxy kann den äußeren Header ändern, während die signierten Bytes gleich bleiben. Nach nextUpdate darf die Antwort trotz eines freundlich aussehenden HTTP-Umschlags nicht mehr verwendet werden. Liefert ein Zwischen-Cache weiter eine abgelaufene Kopie, kann der Client ihn bei einer neuen Anfrage umgehen. Der alte Gegenstand wird dadurch nicht wieder gültig.

Auch OCSP-Stapling in TLS folgt dieser Grenze. Es spart eine HTTP-Verbindung und Round Trips, erneuert aber nicht die Antwort. Ziel-CertID, Signierer, Status und Zeitfenster bleiben Eigenschaften des eingebetteten OCSP-Objekts.

successful und good sind keine Synonyme

Das übergeordnete successful bedeutet, dass die OCSP-Infrastruktur über autoritative Datensätze verfügt und antworten kann. Für das einzelne Zertifikat folgen good, revoked oder unknown. Eine erfolgreiche Antwort kann daher nicht als Zertifikatsurteil gelesen werden.

Auch good ist in RFC 6960 eng definiert. Mindestens ist kein Zertifikat mit der angefragten Seriennummer, das innerhalb seiner Gültigkeit liegt, gesperrt. Das muss weder beweisen, dass das Zertifikat je ausgestellt wurde, noch dass die Antwort innerhalb seiner Gültigkeit produziert wurde. Pfadvalidierung, Identität, Zweck und lokale Autorisierung bleiben weitere Prüfungen.

Der Client bestätigt zuerst die Zuordnung zum angefragten CertID, prüft die Signatur und die Befugnis des Signierers für die betreffende CA. Ein reproduzierbarer Beleg speichert Antwort-Hash, Signierer und Autorisierungskette, Algorithmus, Einzelstatus, producedAt, thisUpdate, nextUpdate, Vergleichszeit, Offset, Toleranz und Nonce. HTTP age, max-age, Expires, ETag, Revalidierung und Cache-Umgehung werden getrennt erfasst. Anwendungsentscheidung und Wirkung folgen danach.

RFC 9919 verlangt außerdem SHA-256 für die Aussteller-Hashes im CertID. Alte RFC-5019-Clients dürfen in der Übergangszeit SHA-1 senden, sollen aber migrieren. Ihr Anteil ist ein Kompatibilitätssignal, kein Frischenachweis.

Quellen