Appendix A. OCSP over HTTP (OCSP über HTTP)

Dieser Abschnitt beschreibt die Formatierung, die an der Anfrage und Antwort vorgenommen wird, um HTTP [RFC2616] zu unterstützen.

A.1. Request (Anfrage)

HTTP-basierte OCSP-Anfragen können entweder die GET- oder die POST-Methode verwenden, um ihre Anfragen zu übermitteln. Um HTTP-Caching zu ermöglichen, KÖNNEN (MAY) kleine Anfragen (die nach der Codierung kleiner als 255 Byte sind) mit GET übermittelt werden. Wenn HTTP-Caching nicht wichtig ist oder wenn die Anfrage größer als 255 Byte ist, SOLLTE (SHOULD) die Anfrage mit POST übermittelt werden. Wo Datenschutz eine Anforderung ist, KÖNNEN (MAY) OCSP-Transaktionen, die über HTTP ausgetauscht werden, unter Verwendung von Transport Layer Security/Secure Socket Layer (TLS/SSL) oder einem anderen Protokoll niedrigerer Schicht geschützt werden.

Eine OCSP-Anfrage unter Verwendung der GET-Methode wird wie folgt konstruiert:

GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest}

wobei {url} aus dem Wert der Erweiterung für den Zugriff auf Autoritätsinformationen (authority information access) in dem Zertifikat abgeleitet werden kann, das auf Widerruf geprüft wird, oder aus einer anderen lokalen Konfiguration des OCSP-Clients.

Eine OCSP-Anfrage unter Verwendung der POST-Methode wird wie folgt konstruiert: Der Content-Type-Header hat den Wert "application/ocsp-request", während der Körper der Nachricht der Binärwert der DER-Codierung der OCSPRequest ist.

A.2. Response (Antwort)

Eine HTTP-basierte OCSP-Antwort besteht aus den entsprechenden HTTP-Headern, gefolgt vom Binärwert der DER-Codierung der OCSPResponse. Der Content-Type-Header hat den Wert "application/ocsp-response". Der Content-Length-Header SOLLTE (SHOULD) die Länge der Antwort angeben. Andere HTTP-Header KÖNNEN (MAY) vorhanden sein und KÖNNEN (MAY) ignoriert werden, wenn sie vom Anforderer nicht verstanden werden.