5. Security Considerations (Sicherheitsüberlegungen)

Damit dieser Dienst effektiv ist, müssen zertifikatsnutzende Systeme eine Verbindung zum Dienstleister für den Zertifikatsstatus herstellen. Falls eine solche Verbindung nicht hergestellt werden kann, könnten zertifikatsnutzende Systeme CRL-Verarbeitungslogik als Fallback-Position implementieren.

Eine Anfälligkeit für Denial of Service (Dienstverweigerung) ist offensichtlich in Bezug auf eine Flut von Anfragen. Die Erstellung einer kryptografischen Signatur wirkt sich erheblich auf die Antwortgenerierungszykluszeit aus, wodurch die Situation verschärft wird. Nicht signierte Fehlerantworten öffnen das Protokoll für einen weiteren Denial-of-Service-Angriff, bei dem der Angreifer falsche Fehlerantworten sendet.

Die Verwendung vorausberechneter Antworten ermöglicht Replay-Angriffe (Replay Attacks), bei denen eine alte (gute) Antwort vor ihrem Ablaufdatum, aber nach dem Widerruf des Zertifikats erneut abgespielt wird. Einsätze von OCSP sollten den Nutzen vorausberechneter Antworten sorgfältig gegen die Wahrscheinlichkeit eines Replay-Angriffs und die Kosten abwägen, die mit seiner erfolgreichen Ausführung verbunden sind.

Anfragen enthalten nicht den Responder, an den sie gerichtet sind. Dies ermöglicht es einem Angreifer, eine Anfrage an eine beliebige Anzahl von OCSP-Respondern erneut abzuspielen.

Das Vertrauen in HTTP-Caching in einigen Einsatzszenarien kann zu unerwarteten Ergebnissen führen, wenn Zwischenserver falsch konfiguriert sind oder bekannt ist, dass sie Cache-Management-Fehler aufweisen. Implementierern wird geraten, die Zuverlässigkeit von HTTP-Cache-Mechanismen zu berücksichtigen, wenn sie OCSP über HTTP einsetzen.

Das Antworten mit einem "revoked" (widerrufen) Status auf ein Zertifikat, das noch nie ausgestellt wurde, kann es jemandem ermöglichen, eine Widerrufsantwort für ein Zertifikat zu erhalten, das noch nicht, aber bald ausgestellt wird, wenn die Zertifikatsseriennummer des Zertifikats, das ausgestellt wird, vom Anforderer vorhergesagt oder erraten werden kann. Eine solche Vorhersage ist einfach für eine CA, die Zertifikate unter Verwendung einer sequenziellen Zertifikatsseriennummernvergabe ausstellt. Dieses Risiko wird in der Spezifikation behandelt, indem konforme Implementierungen verpflichtet werden, den certificateHold-Grundcode zu verwenden, was den dauerhaften Widerruf der Seriennummer vermeidet. Für CAs, die "revoked"-Antworten auf Statusanfragen für nicht ausgestellte Zertifikate unterstützen, besteht eine Möglichkeit, dieses Problem vollständig zu vermeiden, darin, zufällige Zertifikatsseriennummernwerte mit hoher Entropie zuzuweisen.

5.1. Preferred Signature Algorithms (Bevorzugte Signaturalgorithmen)

Der Mechanismus, der zur Auswahl des Antwortsignaturalgorithmus verwendet wird, MUSS (MUST) als ausreichend sicher gegen kryptoanalytische Angriffe für die beabsichtigte Anwendung angesehen werden.

In den meisten Anwendungen reicht es aus, wenn der Signaturalgorithmus mindestens so sicher ist wie der Signaturalgorithmus, der zum Signieren des ursprünglichen Zertifikats verwendet wurde, dessen Status abgefragt wird. Dieses Kriterium gilt jedoch möglicherweise nicht für langfristige Archivierungsanwendungen, bei denen der Status eines Zertifikats für ein Datum in der fernen Vergangenheit abgefragt wird, lange nachdem der Signaturalgorithmus nicht mehr als vertrauenswürdig angesehen wird.

5.1.1. Use of Insecure Algorithms (Verwendung unsicherer Algorithmen)

Es ist für einen Responder nicht immer möglich, eine Antwort zu generieren, von der erwartet wird, dass der Client sie versteht, und die den zeitgenössischen Standards für kryptografische Sicherheit entspricht. In solchen Fällen MUSS (MUST) ein OCSP-Responder-Betreiber das Risiko des Einsatzes einer kompromittierten Sicherheitslösung und die Kosten für die Anordnung eines Upgrades abwägen, einschließlich des Risikos, dass die von den Endbenutzern gewählte Alternative noch weniger Sicherheit oder keine Sicherheit bietet.

In Archivierungsanwendungen ist es durchaus möglich, dass ein OCSP-Responder aufgefordert wird, die Gültigkeit eines Zertifikats zu einem Datum in der fernen Vergangenheit zu melden. Ein solches Zertifikat könnte ein Signierverfahren verwenden, das nicht mehr als akzeptabel sicher angesehen wird. Unter solchen Umständen DARF der Responder KEINE (MUST NOT) Signatur unter Verwendung eines Signiermechanismus generieren, der nicht als akzeptabel sicher angesehen wird.

Ein Client MUSS (MUST) jeden Signaturalgorithmus in einer Antwort akzeptieren, den er in der Anfrage als bevorzugten Signaturalgorithmus angegeben hat. Daraus folgt, dass ein Client keinen Algorithmus als bevorzugten Signaturalgorithmus angeben DARF (MUST NOT), der entweder nicht unterstützt wird oder nicht als akzeptabel sicher angesehen wird.

5.1.2. Man-in-the-Middle Downgrade Attack (Man-in-the-Middle-Downgrade-Angriff)

Der Mechanismus zur Unterstützung der Client-Angabe bevorzugter Signaturalgorithmen ist nicht gegen einen Man-in-the-Middle-Downgrade-Angriff geschützt. Diese Einschränkung wird nicht als signifikantes Sicherheitsbedenken angesehen, da der OCSP-Responder OCSP-Antworten auch auf Anfrage des Clients NICHT (MUST NOT) mit schwachen Algorithmen signieren DARF. Darüber hinaus kann der Client OCSP-Antworten ablehnen, die seine eigenen Kriterien für akzeptable kryptografische Sicherheit nicht erfüllen, unabhängig davon, welcher Mechanismus zur Bestimmung des Signaturalgorithmus der Antwort verwendet wird.

5.1.3. Denial-of-Service Attack (Denial-of-Service-Angriff)

In diesem Dokument definierte Algorithmus-Agilitätsmechanismen führen eine leicht vergrößerte Angriffsfläche für Denial-of-Service-Angriffe ein, bei denen die Client-Anfrage geändert wird, um Algorithmen zu erfordern, die vom Server nicht unterstützt werden. Denial-of-Service-Überlegungen, wie in RFC 4732 [RFC4732] diskutiert, sind für dieses Dokument relevant.