2. Protocol Overview (Protokollübersicht)

Anstelle von oder als Ergänzung zur Prüfung gegen eine regelmäßige CRL kann es notwendig sein, zeitnahe Informationen über den Widerrufsstatus von Zertifikaten zu erhalten (vgl. [RFC5280], Abschnitt 3.3). Beispiele hierfür sind Überweisungen von hohen Beträgen oder große Aktiengeschäfte.

Das Online Certificate Status Protocol (OCSP) ermöglicht es Anwendungen, den (Widerrufs-)Status identifizierter Zertifikate zu bestimmen. OCSP kann verwendet werden, um einige der betrieblichen Anforderungen an die Bereitstellung zeitnaherer Widerrufsinformationen zu erfüllen, als dies mit CRLs möglich ist, und kann auch verwendet werden, um zusätzliche Statusinformationen zu erhalten. Ein OCSP-Client sendet eine Statusanfrage an einen OCSP-Responder und setzt die Annahme der betreffenden Zertifikate aus, bis der Responder eine Antwort liefert.

Dieses Protokoll spezifiziert die Daten, die zwischen einer Anwendung, die den Status eines oder mehrerer Zertifikate prüft, und dem Server, der den entsprechenden Status bereitstellt, ausgetauscht werden müssen.

2.1. Request (Anfrage)

Eine OCSP-Anfrage enthält die folgenden Daten:

Protokollversion
Dienstanforderung
Zielzertifikatskennung
optionale Erweiterungen, die vom OCSP-Responder verarbeitet werden KÖNNEN (MAY)

Bei Erhalt einer Anfrage stellt ein OCSP-Responder fest, ob:

die Nachricht wohlgeformt ist,
der Responder so konfiguriert ist, dass er den angeforderten Dienst bereitstellt, und
die Anfrage die vom Responder benötigten Informationen enthält.

Wenn eine dieser Bedingungen nicht erfüllt ist, erzeugt der OCSP-Responder eine Fehlermeldung; andernfalls gibt er eine definitive Antwort zurück.

2.2. Response (Antwort)

OCSP-Antworten können von verschiedenen Typen sein. Eine OCSP-Antwort besteht aus einem Antworttyp und den Bytes der eigentlichen Antwort. Es gibt einen grundlegenden OCSP-Antworttyp, der von allen OCSP-Servern und -Clients unterstützt werden MUSS (MUST). Der Rest dieses Abschnitts bezieht sich nur auf diesen grundlegenden Antworttyp.

Alle definitiven Antwortnachrichten SOLLEN (SHALL) digital signiert sein. Der zum Signieren der Antwort verwendete Schlüssel MUSS (MUST) zu einem der Folgenden gehören:

der CA (Zertifizierungsstelle), die das fragliche Zertifikat ausgestellt hat
einem Trusted Responder (Vertrauenswürdiger Responder), dessen öffentlichem Schlüssel der Anforderer vertraut
einem CA Designated Responder (Von der CA benannter Responder/Authorized Responder (Autorisierter Responder), definiert in Abschnitt 4.2.2.2), der ein speziell markiertes, direkt von der CA ausgestelltes Zertifikat besitzt, das anzeigt, dass der Responder OCSP-Antworten für diese CA ausstellen darf

Eine definitive Antwortnachricht setzt sich zusammen aus:

Version der Antwort-Syntax
Kennung des Responders
Zeitpunkt, zu dem die Antwort generiert wurde
Antworten für jedes der Zertifikate in einer Anfrage
optionale Erweiterungen
Signaturalgorithmus-OID
Signatur, die über einen Hash der Antwort berechnet wurde

Die Antwort für jedes der Zertifikate in einer Anfrage besteht aus:

Zielzertifikatskennung
Zertifikatsstatuswert
Antwortgültigkeitsintervall
optionale Erweiterungen

Diese Spezifikation definiert die folgenden definitiven Antwortindikatoren zur Verwendung im Zertifikatsstatuswert:

good (gut/gültig)
revoked (widerrufen)
unknown (unbekannt)

Der Zustand "good" zeigt eine positive Antwort auf die Statusanfrage an. Zumindest zeigt diese positive Antwort an, dass kein Zertifikat mit der angeforderten Zertifikatsseriennummer, das sich derzeit in seinem Gültigkeitsintervall befindet, widerrufen ist. Dieser Zustand bedeutet nicht notwendigerweise, dass das Zertifikat jemals ausgestellt wurde oder dass der Zeitpunkt, zu dem die Antwort erstellt wurde, innerhalb des Gültigkeitsintervalls des Zertifikats liegt. Antwort-Erweiterungen können verwendet werden, um zusätzliche Informationen über Zusicherungen des Responders bezüglich des Status des Zertifikats zu übermitteln, wie z. B. eine positive Aussage über Ausstellung, Gültigkeit usw.

Der Zustand "revoked" zeigt an, dass das Zertifikat widerrufen wurde, entweder vorübergehend (der Widerrufsgrund ist certificateHold) oder dauerhaft. Dieser Zustand KANN (MAY) auch zurückgegeben werden, wenn die zugehörige CA keine Aufzeichnung darüber hat, jemals ein Zertifikat mit der Zertifikatsseriennummer in der Anfrage ausgestellt zu haben, unter Verwendung eines aktuellen oder früheren Ausgabeschlüssels (in diesem Dokument als "non-issued (nicht ausgestelltes)" Zertifikat bezeichnet).

Der Zustand "unknown" zeigt an, dass der Responder nichts über das angeforderte Zertifikat weiß, normalerweise weil die Anfrage einen nicht erkannten Aussteller angibt, der von diesem Responder nicht bedient wird.

HINWEIS: Der Status "revoked" zeigt an, dass ein Zertifikat mit der angeforderten Seriennummer abgelehnt werden sollte, während der Status "unknown" anzeigt, dass der Status von diesem Responder nicht bestimmt werden konnte, wodurch der Client entscheiden kann, ob er eine andere Quelle für Statusinformationen (wie eine CRL) versuchen möchte. Dies macht die "revoked"-Antwort für nicht ausgestellte Zertifikate (wie oben definiert) geeignet, bei denen die Absicht des Responders darin besteht, den Client dazu zu bringen, das Zertifikat abzulehnen, anstatt eine andere Quelle für Statusinformationen zu versuchen. Der Status "revoked" ist für nicht ausgestellte Zertifikate weiterhin optional, um die Abwärtskompatibilität mit Bereitstellungen von RFC 2560 aufrechtzuerhalten. Beispielsweise hat der Responder möglicherweise keine Kenntnis darüber, ob eine angeforderte Seriennummer einem ausgestellten Zertifikat zugewiesen wurde, oder der Responder stellt möglicherweise vorproduzierte Antworten gemäß RFC 5019 bereit und ist aus diesem Grund nicht in der Lage, eine signierte Antwort für alle nicht ausgestellten Zertifikatsseriennummern bereitzustellen.

Wenn ein Responder eine "revoked"-Antwort auf eine Statusanfrage für ein nicht ausgestelltes Zertifikat sendet, MUSS (MUST) der Responder die Antworterweiterung extended revoked definition (erweiterte Widerrufsdefinition) (Abschnitt 4.4.8) in die Antwort aufnehmen, was anzeigt, dass der OCSP-Responder die erweiterte Definition des Zustands "revoked" unterstützt, um auch nicht ausgestellte Zertifikate abzudecken. Darüber hinaus MUSS (MUST) die SingleResponse, die sich auf dieses nicht ausgestellte Zertifikat bezieht:

den Widerrufsgrund certificateHold (6) angeben,
die Widerrufszeit revocationTime als 1. Januar 1970 angeben, und
DARF KEINE (MUST NOT) CRL references extension (CRL-Referenzerweiterung) (Abschnitt 4.4.2) oder CRL entry extensions (CRL-Eintragserweiterungen) (Abschnitt 4.4.5) enthalten.

2.3. Exception Cases (Ausnahmefälle)

Im Falle von Fehlern kann der OCSP-Responder eine Fehlermeldung zurückgeben. Diese Nachrichten sind nicht signiert. Fehler können von den folgenden Typen sein:

malformedRequest (fehlerhafte Anfrage)
internalError (interner Fehler)
tryLater (später versuchen)
sigRequired (Signatur erforderlich)
unauthorized (nicht autorisiert)

Ein Server erzeugt die Antwort "malformedRequest", wenn die empfangene Anfrage nicht der OCSP-Syntax entspricht.

Die Antwort "internalError" zeigt an, dass der OCSP-Responder einen inkonsistenten internen Zustand erreicht hat. Die Abfrage sollte wiederholt werden, möglicherweise mit einem anderen Responder.

Für den Fall, dass der OCSP-Responder betriebsbereit ist, aber keinen Status für das angeforderte Zertifikat zurückgeben kann, kann die Antwort "tryLater" verwendet werden, um anzuzeigen, dass der Dienst existiert, aber vorübergehend nicht antworten kann.

Die Antwort "sigRequired" wird in Fällen zurückgegeben, in denen der Server verlangt, dass der Client die Anfrage signiert, um eine Antwort zu erstellen.

Die Antwort "unauthorized" wird in Fällen zurückgegeben, in denen der Client nicht autorisiert ist, diese Abfrage an diesen Server zu stellen, oder der Server nicht in der Lage ist, autoritativ zu antworten (vgl. [RFC5019], Abschnitt 2.2.3).

2.4. Semantics of thisUpdate, nextUpdate, and producedAt (Semantik von thisUpdate, nextUpdate und producedAt)

In diesem Dokument definierte Antworten können vier Zeiten enthalten -- thisUpdate, nextUpdate, producedAt und revocationTime. Die Semantik dieser Felder ist:

thisUpdate: Der jüngste Zeitpunkt, zu dem der angezeigte Status dem Responder als korrekt bekannt war.

nextUpdate: Der Zeitpunkt, zu dem oder vor dem neuere Informationen über den Status des Zertifikats verfügbar sein werden.

producedAt: Der Zeitpunkt, zu dem der OCSP-Responder diese Antwort signiert hat.

revocationTime: Der Zeitpunkt, zu dem das Zertifikat widerrufen oder zurückgestellt wurde.

2.5. Response Pre-Production (Antwort-Vorproduktion)

OCSP-Responder KÖNNEN (MAY) signierte Antworten vorproduzieren, die den Status von Zertifikaten zu einem bestimmten Zeitpunkt angeben. Der Zeitpunkt, zu dem der Status als korrekt bekannt war, SOLL (SHALL) im thisUpdate-Feld der Antwort wiedergegeben werden. Der Zeitpunkt, zu dem oder vor dem neuere Informationen verfügbar sein werden, wird im nextUpdate-Feld wiedergegeben, während der Zeitpunkt, zu dem die Antwort erstellt wurde, im producedAt-Feld der Antwort erscheint.

2.6. OCSP Signature Authority Delegation (Delegierung der OCSP-Signaturautorität)

Der Schlüssel, der die Statusinformationen eines Zertifikats signiert, muss nicht derselbe Schlüssel sein, der das Zertifikat signiert hat. Der Aussteller eines Zertifikats delegiert die OCSP-Signaturautorität explizit durch die Ausstellung eines Zertifikats, das einen eindeutigen Wert für die Erweiterung extended key usage (erweiterte Schlüsselverwendung) (definiert in [RFC5280], Abschnitt 4.2.1.12) im Zertifikat des OCSP-Unterzeichners enthält. Dieses Zertifikat MUSS (MUST) dem Responder direkt von der zuständigen CA ausgestellt werden. Siehe Abschnitt 4.2.2.2 für Details.

2.7. CA Key Compromise (CA-Schlüsselkompromittierung)

Wenn ein OCSP-Responder weiß, dass der private Schlüssel einer bestimmten CA kompromittiert wurde, KANN (MAY) er den Status "revoked" für alle von dieser CA ausgestellten Zertifikate zurückgeben.