2.2 Multiple Certificate Status Request Record
Clients, die ein Zertifikatsstatus-Protokoll wie OCSP unterstützen, KÖNNEN die status_request_v2-Erweiterung an den Server senden, um den TLS-Handshake zur Übertragung solcher Daten zu verwenden, anstatt sie über separate Verbindungen herunterzuladen. Bei Verwendung dieser Erweiterung MUSS das extension_data-Feld (definiert in Abschnitt 7.4.1.4 von [RFC5246]) der Erweiterung eine CertificateStatusRequestListV2 enthalten, wobei:
struct {
CertificateStatusType status_type;
uint16 request_length; /* Length of request field in bytes */
select (status_type) {
case ocsp: OCSPStatusRequest;
case ocsp_multi: OCSPStatusRequest;
} request;
} CertificateStatusRequestItemV2;
enum { ocsp(1), ocsp_multi(2), (255) } CertificateStatusType;
struct {
ResponderID responder_id_list<0..2^16-1>;
Extensions request_extensions;
} OCSPStatusRequest;
opaque ResponderID<1..2^16-1>;
opaque Extensions<0..2^16-1>;
struct {
CertificateStatusRequestItemV2
certificate_status_req_list<1..2^16-1>;
} CertificateStatusRequestListV2;
In der OCSPStatusRequest (ursprünglich definiert von [RFC6066]) liefert die ResponderID eine Liste von OCSP-Respondern, denen der Client vertraut. Eine responder_id_list-Sequenz der Länge Null hat die besondere Bedeutung, dass die Responder dem Server implizit bekannt sind, z.B. durch vorherige Vereinbarung, oder durch die vom Server verwendeten Zertifikate identifiziert werden. Extensions ist eine DER-Kodierung [X.690] der OCSP-Request-Extensions, und wenn der Server die Weiterleitung von OCSP-Request-Extensions unterstützt, MUSS dieser Wert ohne Änderung weitergeleitet werden.
Sowohl ResponderID als auch Extensions sind DER-kodierte ASN.1-Typen, wie in [RFC6960] definiert. Extensions wird aus [RFC5280] importiert. Ein request_extensions-Wert der Länge Null bedeutet, dass es keine Extensions gibt (im Gegensatz zu einer DER-kodierten ASN.1 SEQUENCE der Länge Null, die für den Extensions-Typ nicht gültig ist).
Server, die die Auswahl von Respondern durch einen Client unter Verwendung des ResponderID-Feldes unterstützen, könnten diese Auswahl implementieren, indem sie die Responder-ID-Werte aus der Liste des Clients mit den ResponderIDs bekannter OCSP-Responder abgleichen, entweder durch einen binären Vergleich der Werte oder durch eine Hash-Berechnung und Vergleichsmethode.
Im Fall der "id-pkix-ocsp-nonce" OCSP-Extension ist [RFC2560] unklar über seine Kodierung; zur Klarstellung MUSS die Nonce ein DER-kodierter OCTET STRING sein, der als ein weiterer OCTET STRING gekapselt ist (beachten Sie, dass Implementierungen, die auf einem bestehenden OCSP-Client basieren, auf Konformität mit dieser Anforderung überprüft werden müssen). Dies wurde in [RFC6960] klargestellt.
Die Elemente in der Liste der CertificateStatusRequestItemV2-Einträge sind entsprechend der Präferenz des Clients geordnet (bevorzugte Wahl zuerst).
Ein Server, der ein Client Hello erhält, das die status_request_v2-Erweiterung enthält, KANN eine geeignete Zertifikatsstatus-Response-Nachricht zusammen mit der Zertifikatsnachricht des Servers an den Client zurückgeben. Wenn OCSP angefordert wird, SOLLTE er die in der Erweiterung enthaltenen Informationen bei der Auswahl eines OCSP-Responders verwenden und SOLLTE request_extensions in der OCSP-Anfrage einschließen.
Der Server gibt eine Zertifikatsstatus-Response zusammen mit seinem Zertifikat zurück, indem er unmittelbar nach der Certificate-Nachricht (Abschnitt 7.4.2 von [RFC5246]) (und vor allen ServerKeyExchange- oder CertificateRequest-Nachrichten) eine CertificateStatus-Nachricht (ursprünglich definiert von [RFC6066]) sendet. Wenn ein Server eine CertificateStatus-Nachricht als Antwort auf eine status_request_v2-Anfrage zurückgibt, dann MUSS der Server eine Erweiterung vom Typ status_request_v2 mit leerem extension_data im erweiterten Server Hello eingeschlossen haben.
Die CertificateStatus-Nachricht wird unter Verwendung des Handshake-Nachrichtentyps certificate_status (definiert in [RFC6066]) wie folgt übermittelt (aktualisiert von der Definition in [RFC6066]):
struct {
CertificateStatusType status_type;
select (status_type) {
case ocsp: OCSPResponse;
case ocsp_multi: OCSPResponseList;
} response;
} CertificateStatus;
opaque OCSPResponse<0..2^24-1>;
struct {
OCSPResponse ocsp_response_list<1..2^24-1>;
} OCSPResponseList;
Ein OCSPResponse-Element (ursprünglich definiert von [RFC6066]) enthält eine vollständige, DER-kodierte OCSP-Response (unter Verwendung des ASN.1 [X.680]-Typs OCSPResponse, definiert in [RFC6960]). Nur eine OCSP-Response mit einer Länge von mindestens einem Byte darf für status_type "ocsp" gesendet werden.
Eine ocsp_response_list enthält eine Liste von OCSPResponse-Elementen, wie oben spezifiziert, wobei jedes die OCSP-Response für das entsprechende übereinstimmende Zertifikat in der Certificate TLS-Handshake-Nachricht des Servers enthält. Das heißt, der erste Eintrag ist die OCSP-Response für das erste Zertifikat in der Certificate-Liste, der zweite Eintrag ist die Response für das zweite Zertifikat, und so weiter. Die Liste KANN weniger OCSP-Responses enthalten, als es Zertifikate in der Certificate-Handshake-Nachricht gab, aber es DARF NICHT mehr Responses geben, als es Zertifikate in der Liste gab. Einzelne Elemente der Liste KÖNNEN eine Länge von 0 (Null) Bytes haben, wenn der Server die OCSP-Response für dieses bestimmte Zertifikat nicht gespeichert hat, in welchem Fall der Client so handeln MUSS, als ob keine Response für dieses bestimmte Zertifikat empfangen wurde. Wenn der Client eine ocsp_response_list erhält, die keine Response für eines oder mehrere der Zertifikate in der abgeschlossenen Zertifikatskette enthält, SOLLTE der Client versuchen, das Zertifikat mit einer alternativen Abrufmethode zu validieren, wie z.B. dem Herunterladen der relevanten CRL; OCSP SOLLTE in dieser Situation nur für das End-Entity-Zertifikat verwendet werden, nicht für Zwischenzertifizierungs-CA-Zertifikate, aus den oben genannten Gründen.
Beachten Sie, dass ein Server sich auch entscheiden KANN, keine CertificateStatus-Nachricht zu senden, selbst wenn er eine status_request_v2-Erweiterung in der Client Hello-Nachricht erhalten hat und eine status_request_v2-Erweiterung in der Server Hello-Nachricht gesendet hat. Beachten Sie zusätzlich, dass ein Server die CertificateStatus-Nachricht NICHT senden DARF, es sei denn, er hat entweder eine status_request- oder status_request_v2-Erweiterung in der Client Hello-Nachricht erhalten und eine entsprechende status_request- oder status_request_v2-Erweiterung in der Server Hello-Nachricht gesendet.
Clients, die eine OCSP-Response anfordern und eine oder mehrere OCSP-Responses in einer CertificateStatus-Nachricht erhalten, MÜSSEN die OCSP-Response(s) überprüfen und den Handshake mit einem bad_certificate_status_response(113) Alert abbrechen, wenn die Response einen "revoked"-Status oder andere inakzeptable Responses hat (wie durch die Client-Richtlinie bestimmt). Dieser Alert ist immer fatal.
Wenn die vom Server erhaltene OCSP-Response nicht zu einem definitiven "good"- oder "revoked"-Status führt, ist sie nicht schlüssig. Ein TLS-Client in einem solchen Fall KANN die Gültigkeit des Serverzertifikats durch andere Mittel überprüfen, z.B. durch direkte Abfrage des Zertifikatausstellers. Wenn eine solche Verarbeitung immer noch zu einer nicht schlüssigen Response führt, dann muss die Anwendung, die die TLS-Verbindung verwendet, entscheiden, ob die Verbindung geschlossen werden soll oder nicht. Beachten Sie, dass dieses Problem nicht durch den generischen TLS-Client-Code ohne Informationen von der Anwendung entschieden werden kann. Wenn die Anwendung keine solchen Informationen bereitstellt, dann MUSS der Client die Verbindung abbrechen, da das Serverzertifikat nicht ausreichend validiert wurde.
Ein Beispiel, bei dem die Anwendung möglicherweise fortfahren möchte, ist bei EAP-TLS (Extensible Authentication Protocol - TLS), bei dem die Anwendung einen anderen Mechanismus verwenden kann, um den Status eines Zertifikats zu überprüfen, sobald sie Netzwerkzugriff erhält. In diesem Fall könnte die Anwendung den Client den Handshake fortsetzen lassen, aber sie DARF NICHT einen Benutzernamen und ein Passwort offenlegen, bis sie das Serverzertifikat vollständig validiert hat.