2.2 Multiple Certificate Status Request Record (Record di Richiesta di Stato di Certificati Multipli)
I client che supportano un protocollo di stato del certificato come OCSP possono inviare l'estensione "status_request_v2" al server per utilizzare l'handshake TLS per trasferire tali dati invece di scaricarli tramite connessioni separate. Quando si utilizza questa estensione, il campo "extension_data" (definito nella Sezione 7.4.1.4 di [RFC5246]) dell'estensione DEVE contenere un CertificateStatusRequestListV2 dove:
struct {
CertificateStatusType status_type;
uint16 request_length; /* Lunghezza del campo request in byte */
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;
Nel OCSPStatusRequest (originariamente definito da [RFC6066]), il "ResponderID" fornisce un elenco di responder OCSP di cui il client si fida. Una sequenza "responder_id_list" di lunghezza zero ha il significato speciale che i responder sono implicitamente noti al server, ad esempio, per accordo precedente, o sono identificati dai certificati utilizzati dal server. "Extensions" è una codifica DER [X.690] delle estensioni della richiesta OCSP, e se il server supporta l'inoltro delle estensioni della richiesta OCSP, questo valore DEVE essere inoltrato senza modifiche.
Sia "ResponderID" che "Extensions" sono tipi ASN.1 codificati in DER come definito in [RFC6960]. "Extensions" è importato da [RFC5280]. Un valore "request_extensions" di lunghezza zero significa che non ci sono estensioni (al contrario di una SEQUENCE ASN.1 di lunghezza zero codificata in DER, che non è valida per il tipo "Extensions").
I server che supportano la selezione dei responder da parte di un client utilizzando il campo ResponderID potrebbero implementare questa selezione abbinando i valori dell'ID del responder dall'elenco del client con i ResponderID dei responder OCSP noti, utilizzando un confronto binario dei valori o un metodo di calcolo e confronto dell'hash.
Nel caso dell'estensione OCSP "id-pkix-ocsp-nonce", [RFC2560] non è chiaro sulla sua codifica; per chiarimento, il nonce DEVE essere un OCTET STRING codificato in DER, che è incapsulato come un altro OCTET STRING (si noti che le implementazioni basate su un client OCSP esistente dovranno essere verificate per la conformità a questo requisito). Questo è stato chiarito in [RFC6960].
Gli elementi nell'elenco delle voci CertificateStatusRequestItemV2 sono ordinati secondo la preferenza del client (scelta preferita per prima).
Un server che riceve un client hello contenente l'estensione "status_request_v2" PUÒ restituire un messaggio di risposta di stato del certificato adeguato al client insieme al messaggio del certificato del server. Se viene richiesto OCSP, DOVREBBE utilizzare le informazioni contenute nell'estensione quando seleziona un responder OCSP e DOVREBBE includere request_extensions nella richiesta OCSP.
Il server restituisce una risposta di stato del certificato insieme al suo certificato inviando un messaggio "CertificateStatus" (originariamente definito da [RFC6066]) immediatamente dopo il messaggio "Certificate" (Sezione 7.4.2 di [RFC5246]) (e prima di qualsiasi messaggio "ServerKeyExchange" o "CertificateRequest"). Se un server restituisce un messaggio "CertificateStatus" in risposta a una richiesta "status_request_v2", allora il server DEVE aver incluso un'estensione di tipo "status_request_v2" con "extension_data" vuoto nel server hello esteso.
Il messaggio "CertificateStatus" è trasmesso utilizzando il tipo di messaggio handshake "certificate_status" (definito in [RFC6066]) come segue (aggiornato dalla definizione 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;
Un elemento "OCSPResponse" (originariamente definito da [RFC6066]) contiene una risposta OCSP completa e codificata in DER (utilizzando il tipo ASN.1 [X.680] OCSPResponse definito in [RFC6960]). Solo una risposta OCSP, con una lunghezza di almeno un byte, può essere inviata per status_type "ocsp".
Un "ocsp_response_list" contiene un elenco di elementi "OCSPResponse", come specificato sopra, ciascuno contenente la risposta OCSP per il certificato corrispondente corrispondente nel messaggio handshake Certificate TLS del server. Cioè, la prima voce è la risposta OCSP per il primo certificato nell'elenco Certificate, la seconda voce è la risposta per il secondo certificato, e così via. L'elenco PUÒ contenere meno risposte OCSP di quanti certificati c'erano nel messaggio handshake Certificate, ma NON DEVE esserci più risposte di quanti certificati c'erano nell'elenco. I singoli elementi dell'elenco POSSONO avere una lunghezza di 0 (zero) byte se il server non ha la risposta OCSP per quel particolare certificato memorizzata, nel qual caso il client DEVE agire come se non fosse stata ricevuta una risposta per quel particolare certificato. Se il client riceve un "ocsp_response_list" che non contiene una risposta per uno o più certificati nella catena di certificati completata, il client DOVREBBE tentare di convalidare il certificato utilizzando un metodo di recupero alternativo, come il download della CRL pertinente; OCSP DOVREBBE in questa situazione essere utilizzato solo per il certificato dell'entità finale, non per i certificati CA intermedi, per le ragioni sopra indicate.
Si noti che un server PUÒ anche scegliere di non inviare un messaggio "CertificateStatus", anche se ha ricevuto un'estensione "status_request_v2" nel messaggio client hello e ha inviato un'estensione "status_request_v2" nel messaggio server hello. Inoltre, si noti che un server NON DEVE inviare il messaggio "CertificateStatus" a meno che non abbia ricevuto un'estensione "status_request" o "status_request_v2" nel messaggio client hello e abbia inviato un'estensione "status_request" o "status_request_v2" corrispondente nel messaggio server hello.
I client che richiedono una risposta OCSP e ricevono una o più risposte OCSP in un messaggio "CertificateStatus" DEVONO controllare la/e risposta/e OCSP e interrompere l'handshake se la risposta è uno stato "revoked" (revocato) o altre risposte inaccettabili (come determinato dalla policy del client) con un avviso bad_certificate_status_response(113). Questo avviso è sempre fatale.
Se la risposta OCSP ricevuta dal server non risulta in uno stato definitivo "good" (buono) o "revoked", è inconcludente. Un client TLS in tal caso PUÒ verificare la validità del certificato del server attraverso altri mezzi, ad esempio, interrogando direttamente l'emittente del certificato. Se tale elaborazione risulta ancora in una risposta inconcludente, allora l'applicazione che utilizza la connessione TLS dovrà decidere se chiudere la connessione o meno. Si noti che questo problema non può essere deciso dal codice client TLS generico senza informazioni dall'applicazione. Se l'applicazione non fornisce tali informazioni, allora il client DEVE interrompere la connessione, poiché il certificato del server non è stato sufficientemente convalidato.
Un esempio di dove l'applicazione potrebbe voler continuare è con EAP-TLS (Extensible Authentication Protocol - TLS, Protocollo di Autenticazione Estensibile - TLS), dove l'applicazione può utilizzare un altro meccanismo per controllare lo stato di un certificato una volta ottenuto l'accesso alla rete. In questo caso, l'applicazione potrebbe far continuare il client con l'handshake, ma NON DEVE divulgare un nome utente e una password fino a quando non ha completamente convalidato il certificato del server.