Zusammenfassung

  • Ein Staple ist eine signierte Aussage zu einer CertID und bestimmten Zeiten. Die Signatur belegt Aussagebefugnis, nicht Kenntnis jedes späteren Widerrufs oder Erzeugung für diesen Handshake.
  • producedAt, thisUpdate und nextUpdate sind getrennte Uhren. Abruf, HTTP-Alter, Installation, Client-Uhr und Höchstalter kommen hinzu.
  • TLS transportiert den Beleg; der Client entscheidet. CertID, Delegation, Status, Zeit, Cache-Herkunft, Kettenposition, Must-Staple und Fehlerpolitik müssen rekonstruierbar bleiben.

Eine gültige Antwort überdauerte das Ereignis

Der Responder signierte um 09:55 Uhr, der Server lud um 09:57 Uhr. Der Widerruf zehn Minuten später konnte in diesen Bytes nicht enthalten sein. Eine bestandene Signatur- und Zeitprüfung macht aus der älteren Sicht keine neue.

CertID bindet die Frage an Hashes von Ausstellername und -schlüssel, Seriennummer und Algorithmus. Eine perfekte Antwort für eine andere Seriennummer beantwortet eine andere Frage; eine Leaf-Antwort deckt kein Intermediate automatisch ab.

RFC 6960 fasst good eng: Mindestens ist kein aktuell gültiges Zertifikat mit dieser Seriennummer als widerrufen verzeichnet. Das beweist nicht zwingend die Ausstellung und keine sofortige Aufnahme späterer Ereignisse.

Der Aussteller oder ein ausdrücklich zum OCSP-Signieren bevollmächtigter Responder muss unterzeichnen. Eine mathematisch richtige Signatur ohne Delegation besitzt keine Autorität; ein autorisierter Responder kann eine ältere Sicht signieren. CertID, Kettenposition, Responder-Zertifikat, Delegation, Prüfergebnis und Rohdaten-Hash gehören daher zusammen.

Zeit und Cache gehören zum Sicherheitszustand

producedAt nennt die Signaturzeit, thisUpdate den letzten bekannten korrekten Stand, nextUpdate die Grenze für neuere Information. Vorproduktion ist erlaubt; RFC 9919 macht Caching und nextUpdate zum Kern seines Profils.

Im Betrieb folgen Widerrufs-, Ingestions-, HTTP-Date/Age-, Abruf-, Revalidierungs-, Installations-, Handshake- und Client-Zeit. Uhrtoleranz ist keine zusätzliche Frische. Zu zukünftiges thisUpdate, vergangenes nextUpdate und überschrittenes lokales Höchstalter brauchen eigene Gründe.

Caching spart Latenz, schützt Privatsphäre und entfernt den Responder aus jedem Handshake. Date, Expires, ETag und Cache-Control steuern Wiederverwendung. Der Server muss Quelle, Header, Hash, Abruf, Revalidierung, Installation und Erneuerungsfrist festhalten. Eine beim Start gültige Antwort beweist keinen laufenden Refresh.

Nonce, TLS und Must-Staple setzen andere Grenzen

Eine Nonce bindet Anfrage und Antwort. Ein gemeinsam verwendetes Staple trägt gewöhnlich nicht pro Client eine neue Nonce; seine Aktualität beruht auf signiertem Intervall, Höchstalter und Refresh. Ein neuer Handshake ist keine neue Erzeugung.

Bis TLS 1.2 fordert der Client mit status_request an und der Server kann CertificateStatus senden; TLS 1.3 ordnet Status Zertifikatseinträgen zu. Der IANA-Code beweist weder Aushandlung noch Akzeptanz.

Vorhandensein ist nicht Gültigkeit: BoringSSL liefert rohe, nicht garantiert wohlgeformte Bytes; OpenSSL trennt Anforderung, Server-Installation und Client-Lesen. Fehlen kann auch von keiner Anforderung, Session-Wiederaufnahme ohne Zertifikate oder Soft-Fail stammen.

Must-Staple erschwert das stille Weglassen: Der Client darf eine fehlende geforderte Antwort ablehnen. Das ist nicht überall gleich durchgesetzt und heilt keine falsche CertID, Delegation, Signatur, Zeit oder Zustände unknown/revoked.

Laufender Refresh ist der Kontrollbeweis

TLS 1.3 kann mehrere Kettenpositionen tragen; ältere Versionen meist eine Leaf-Antwort. Anzahl und Position dürfen nicht zu enabled=true schrumpfen. Eine Wiederaufnahme ohne Zertifikatsaustausch ist keine neue OCSP-Beobachtung.

OpenSSL trennt CertID-Suche, Status, Zeitprüfung mit Toleranz/Höchstalter und Signaturautorität. GnuTLS integriert die Prüfung, verlangt aber periodische Erneuerung und gegebenenfalls einen Credential-Wechsel. BoringSSL empfiehlt Vorabruf und Refresh außerhalb des Handshakes.

Negativtests benötigen falsche Seriennummer, unbefugten Responder, zukünftiges thisUpdate, abgelaufenes nextUpdate, alte Antwort ohne Altersgrenze, beschädigte Bytes, fehlendes Pflicht-Staple, unvollständige Kette, falsch gezählte Wiederaufnahme, gestoppten Refresh und zurückgesetzte Uhr. Der Alarm muss vor der Ablehnung kommen.

Quellen