1. Introduction (Einführung)

1. Introduction (Einführung)

Dieses Dokument spezifiziert ein Protokoll, das nützlich ist, um den aktuellen Status eines digitalen Zertifikats zu bestimmen, ohne dass CRLs erforderlich sind. Zusätzliche Mechanismen, die PKIX-Betriebsanforderungen adressieren, werden in separaten Dokumenten spezifiziert.

Diese Spezifikation macht [RFC2560] und [RFC6277] obsolet. Der Hauptgrund für die Veröffentlichung dieses Dokuments besteht darin, Unklarheiten zu beseitigen, die seit der Veröffentlichung von RFC 2560 festgestellt wurden. Dieses Dokument unterscheidet sich von RFC 2560 nur in wenigen Bereichen:

• Abschnitt 2.2 erweitert die Verwendung der Antwort "revoked (widerrufen)", um diesen Antwortstatus für Zertifikate zuzulassen, die nie ausgestellt wurden.

• Abschnitt 2.3 erweitert die Verwendung der Fehlerantwort "unauthorized (nicht autorisiert)", wie in [RFC5019] spezifiziert.

• Die Abschnitte 4.2.1 und 4.2.2.3 geben an, dass eine Antwort Widerrufsstatusinformationen für Zertifikate enthalten kann, die nicht in der Anfrage enthalten waren, wie in [RFC5019] zulässig.

• Abschnitt 4.2.2.2 stellt klar, wann ein Responder als Authorized Responder (Autorisierter Responder) gilt.

• Abschnitt 4.2.2.3 stellt klar, dass das Feld ResponderID dem Signaturzertifikat des OCSP-Responders entspricht.

• Abschnitt 4.3 ändert den Satz kryptografischer Algorithmen, die Clients unterstützen müssen, und den Satz kryptografischer Algorithmen, die Clients unterstützen sollten, wie in [RFC6277] spezifiziert.

• Abschnitt 4.4.1 spezifiziert für die Nonce-Erweiterung die ASN.1-Syntax, die in RFC 2560 fehlte.

• Abschnitt 4.4.7 spezifiziert eine neue Erweiterung, die in eine Anforderungsnachricht aufgenommen werden kann, um Signaturalgorithmen anzugeben, die der Client vom Server zum Signieren der Antwort bevorzugen würde, wie in [RFC6277] spezifiziert.

• Abschnitt 4.4.8 spezifiziert eine neue Erweiterung, die anzeigt, dass der Responder die erweiterte Verwendung der Antwort "revoked" für in Abschnitt 2.2 definierte, nicht ausgestellte Zertifikate unterstützt.

• Anhang B.2 stellt ein ASN.1-Modul bereit, das die 2008-Syntax von ASN.1 verwendet, was [RFC5912] aktualisiert.

Ein Überblick über das Protokoll wird in Abschnitt 2 gegeben. Funktionale Anforderungen werden in Abschnitt 3 spezifiziert. Einzelheiten des Protokolls werden in Abschnitt 4 erörtert. Wir behandeln Sicherheitsprobleme mit dem Protokoll in Abschnitt 5. Anhang A definiert OCSP über HTTP, Anhang B stellt ASN.1-Syntaxelemente bereit und Anhang C spezifiziert die MIME-Typen für die Nachrichten.

1.1. Requirements Language (Anforderungssprache)

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in RFC 2119 [RFC2119] beschrieben.