Zusammenfassung

  • RFC 9654 verlangt vom modernen Requester einen mindestens 32 Oktette langen Nonce aus einem kryptografisch starken Pseudozufallszahlengenerator; die exakte Rückgabe bindet die Antwort an diese Anfrage.
  • Die Übereinstimmung beweist weder die jüngste Einspeisung von Sperrdaten noch die Autorisierung des Signierenden, die richtige CertID, ein zulässiges Zeitfenster oder die Freigabe durch die Anwendung.
  • Eine belastbare Nachweiskette hält Anfrage und Antwort, Nonce-Erzeugung und Vergleich, Signaturvollmacht, Zertifikatskennung, signierte Zeiten, Quellwasserzeichen, Validatorrichtlinie und Sitzungswirkung getrennt fest.

Das Organigramm hinter einem grünen Feld

Ein Nonce-Match sieht wie ein abgeschlossenes Sicherheitsurteil aus. Tatsächlich bestätigt es einen Übergang: Ein unvorhersehbarer Wert aus der Anfrage erscheint exakt in der überprüften Antwort. Eine ältere Antwort mit einem anderen Wert kann diesen Vergleich nicht bestehen.

RFC 9654 legt den Nonce in requestExtensions und in der Antwort in responseExtensions ab. Beide verwenden id-pkix-ocsp-nonce. Das ist eine kryptografische Bindung von Frage und Antwort.

Die Bindung ernennt keinen Signierenden. Sie wählt kein Zertifikat aus. Sie misst nicht, wann der Responder die letzte Sperränderung erhielt. Sie entscheidet nicht, ob good, revoked oder unknown für eine konkrete Transaktion genügt. Wer all das unter „PKI“ zusammenfasst, verliert die Verantwortlichen genau dort, wo ein Vorfall rekonstruiert werden muss.

Drei Längenregeln statt einer

Der ASN.1-Typ erlaubt 1 bis 128 Oktette. Ein Requester nach RFC 9654 muss mindestens 32 verwenden. Ein Responder, der die Erweiterung unterstützt, muss 16 bis einschließlich 32 akzeptieren. Bei 1 bis 15 oder 33 bis 128 darf er ohne Nonce antworten. Null oder mehr als 128 muss er mit malformedRequest ablehnen.

Die Obergrenze 128 ist daher kein allgemeiner Sollwert. Sie schafft Raum für kryptografische Verfahren mit längeren Ausgaben. Implementierungen nach RFC 8954, dessen Obergrenze 32 betrug, können längere Werte nicht zwingend verarbeiten.

Ein Abnahmetest trennt 16, 32, 33 und 128 sowie die ungültigen Grenzen. Er prüft Antwort mit Echo, Antwort ohne Echo und Ablehnung. Nur so ist sichtbar, ob eine Anwendung im verpflichtenden Interoperabilitätsbereich oder auf optionalem Verhalten arbeitet.

Die ASN.1-Hülle gehört zum Beweis

RFC 9654 stellt klar, dass der äußere extnValue als OCTET STRING den inneren Nonce, ebenfalls OCTET STRING, enthält. Das Beispiel zeigt die Verschachtelung für 32 Oktette. Die OID lautet 1.3.6.1.5.5.7.48.1.2.

Ein Parser kann die richtige OID erkennen und trotzdem die falsche Schicht vergleichen. Ein Log kann die Hexdarstellung kürzen. Eine Bibliothek kann Text normalisieren und dabei die ursprünglichen Bytes verlieren. „Erweiterung erkannt“ ist deshalb kein Nachweis exakter Gleichheit.

Der Beleg bewahrt die vollständigen DER-Bytes und Hashes beider Nachrichten, Position und Länge beider OCTET-STRING-Schichten sowie das Byte-für-Byte-Ergebnis. Die IANA-Registrierung für PKIX-Modulkennungen führt 111 und 112 für RFC 9654. Sie koordiniert die Grammatik, nicht das Verhalten des geladenen Decoders.

Entropie hat einen eigenen Eigentümer

RFC 9654 fordert einen kryptografisch starken Pseudozufallszahlengenerator nach RFC 4086. Ist der nächste Wert vorhersagbar, kann ein Angreifer vorab eine passende Antwort beschaffen. Ist der Raum klein, kann er alle Werte vorbereiten.

Der spätere Vergleich kann in beiden Fällen wahr sein. Verloren ist die Eigenschaft, dass die Herausforderung neu und nicht vorhersehbar war. Deshalb gehören Generatorart, Gesundheitszustand, Erzeugungszeit, Länge, Wiederverwendung und Verhalten nach Neustarts in den Nachweis.

Die Aussage „32 Bytes“ beschreibt nur die Form. Die Aussage „für diese Anfrage frisch und unvorhersehbar“ beschreibt die Sicherheitswirkung. Primat des laufenden Codes verlangt Messungen der zweiten Aussage im realen Prozess.

Die neueste Serverantwort kann aus einem alten Datenstand stammen

RFC 9654 beschreibt eine Antwort mit dem Nonce des Requesters als neueste Antwort des Servers statt als alte Kopie. Das Subjekt ist die Serverantwort. Über die Zufuhr der Sperrdaten macht dieser Satz keine vollständige Aussage.

RFC 6960 trennt producedAt, thisUpdate, nextUpdate und revocationTime. Signierzeit, Zeitpunkt des als richtig bekannten Status, Termin neuer Information und Sperrzeit sind verschieden. Die CertID bindet den Status an Ausstellername, Ausstellerschlüssel und Seriennummer.

Veröffentlicht die CA um 11:00 eine Sperre und übernimmt der Responder sie erst um 11:08, kann er um 11:04 eine brandneue, nonce-gebundene und korrekt signierte Antwort aus seinem verzögerten Stand erzeugen. Der Austausch ist neu; die Quelle ist hinterher. Für Quellfrische braucht es Feed-Cursor, Chargenversion, Übernahmezeit oder einen gleichwertigen Beleg.

Auch die Signaturvollmacht bleibt separat. Nach RFC 6960 muss der Signierende die ausstellende CA, ein direkt vertrauter Responder oder ein entsprechend zertifizierter Beauftragter der CA sein. Ein Nonce erteilt keine Vollmacht. good beweist ebenso wenig Ausstellung, Zertifikatsgültigkeit, Dienstidentität oder Geschäftsberechtigung.

Fehlender Nonce aktiviert eine andere Richtlinie

RFC 5019 ist für hohe Volumina mit vorproduzierten und cachebaren Antworten ausgelegt. Ein individueller Nonce reduziert Wiederverwendung. Deshalb kann ein Responder ihn weglassen, obwohl der Client ihn gesendet hat.

Kennt der Client die Nonce-Unterstützung nicht sicher, soll er nicht allein wegen des Fehlens ablehnen, sondern auf signierte Zeitprüfung zurückfallen. RFC 9654 nennt das Restrisiko: Ein Angreifer auf dem Pfad kann eine ältere, nonce-lose Antwort des Servers liefern. Ein kurzes Intervall zwischen thisUpdate und nextUpdate begrenzt das Fenster.

Betrieblich sind mindestens vier Zustände nötig: exakt passend; zulässig fehlend mit genehmigtem Fallback; vorhanden, aber abweichend; fehlerhaft kodiert oder unzulässig lang. Jeder Zustand wird mit Signatur-, Vollmachts-, Identitäts-, Zeit- und Anwendungsentscheidung fortgeführt.

Der vollständige Entscheidungsbeleg

Am Anfang stehen Fingerabdruck und Seriennummer des Zielzertifikats, Aussteller-Hashes und der erwartete Responder. Dann folgen Anfragebytes, Generator, Erzeugungszeit, Länge, geschützter Wert-Hash und Ziel. Für die Antwort werden Bytes, Status, Responder-ID, Kette, Vollmacht und Signaturprüfung gesichert.

Die Bindungsschicht speichert Vorhandensein und exakte Gleichheit. Die Statusschicht speichert CertID, Status, Zeiten und Sperrfelder. Wenn beobachtbar, wird das Wasserzeichen des Upstream-Feeds getrennt aufgezeichnet. Lokal kommen Uhr, Unsicherheit, Toleranz, Validator-Build und Richtlinienversion hinzu. Die Anwendung schließt mit Pfad, Identität, Zulassung oder Ablehnung und Sitzungsaktion.

Die Realitätsebenen verhindern, dass ein starker Zwischenbeleg spätere Tatsachen verdrängt. Die minimale Anfangsspezifikation standardisiert nur die nötigen gemeinsamen Regeln und lässt Kapazität, Einspeisung und Risikozulassung bei sichtbaren lokalen Verantwortlichen.

Quellen