2.2 Multiple Certificate Status Request Record
Les clients qui prennent en charge un protocole de statut de certificat comme OCSP peuvent envoyer l'extension "status_request_v2" au serveur afin d'utiliser la poignée de main TLS pour transférer de telles données au lieu de les télécharger via des connexions séparées. Lors de l'utilisation de cette extension, le champ "extension_data" (défini dans la section 7.4.1.4 de [RFC5246]) de l'extension DOIT contenir une CertificateStatusRequestListV2 où :
struct {
CertificateStatusType status_type;
uint16 request_length; /* Longueur du champ request en octets */
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;
Dans l'OCSPStatusRequest (initialement défini par [RFC6066]), le "ResponderID" fournit une liste de répondeurs OCSP que le client fait confiance. Une séquence "responder_id_list" de longueur nulle a la signification spéciale que les répondeurs sont implicitement connus du serveur, par exemple, par arrangement préalable, ou sont identifiés par les certificats utilisés par le serveur. "Extensions" est un encodage DER [X.690] des extensions de requête OCSP, et si le serveur prend en charge le transfert des extensions de requête OCSP, cette valeur DOIT être transférée sans modification.
Les "ResponderID" et "Extensions" sont tous deux des types ASN.1 encodés en DER tels que définis dans [RFC6960]. "Extensions" est importé de [RFC5280]. Une valeur "request_extensions" de longueur nulle signifie qu'il n'y a pas d'extensions (par opposition à une SEQUENCE ASN.1 de longueur nulle encodée en DER, qui n'est pas valide pour le type "Extensions").
Les serveurs qui prennent en charge la sélection de répondeurs par un client utilisant le champ ResponderID pourraient implémenter cette sélection en faisant correspondre les valeurs d'ID de répondeur de la liste du client avec les ResponderIDs de répondeurs OCSP connus, soit en utilisant une comparaison binaire des valeurs soit une méthode de calcul et de comparaison de hachage.
Dans le cas de l'extension OCSP "id-pkix-ocsp-nonce", [RFC2560] n'est pas clair sur son encodage ; pour clarification, le nonce DOIT être un OCTET STRING encodé en DER, qui est encapsulé comme un autre OCTET STRING (notez que les implémentations basées sur un client OCSP existant devront être vérifiées pour leur conformité à cette exigence). Cela a été clarifié dans [RFC6960].
Les éléments de la liste d'entrées CertificateStatusRequestItemV2 sont ordonnés selon la préférence du client (choix favori en premier).
Un serveur qui reçoit un client hello contenant l'extension "status_request_v2" PEUT retourner un message de réponse de statut de certificat approprié au client avec le message de certificat du serveur. Si OCSP est demandé, il DEVRAIT utiliser les informations contenues dans l'extension lors de la sélection d'un répondeur OCSP et DEVRAIT inclure request_extensions dans la requête OCSP.
Le serveur retourne une réponse de statut de certificat avec son certificat en envoyant un message "CertificateStatus" (initialement défini par [RFC6066]) immédiatement après le message "Certificate" (section 7.4.2 de [RFC5246]) (et avant tout message "ServerKeyExchange" ou "CertificateRequest"). Si un serveur retourne un message "CertificateStatus" en réponse à une requête "status_request_v2", alors le serveur DOIT avoir inclus une extension de type "status_request_v2" avec "extension_data" vide dans le server hello étendu.
Le message "CertificateStatus" est transmis en utilisant le type de message de poignée de main "certificate_status" (défini dans [RFC6066]) comme suit (mis à jour à partir de la définition dans [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 élément "OCSPResponse" (initialement défini par [RFC6066]) contient une réponse OCSP complète et encodée en DER (utilisant le type ASN.1 [X.680] OCSPResponse défini dans [RFC6960]). Une seule réponse OCSP, d'une longueur d'au moins un octet, peut être envoyée pour status_type "ocsp".
Une "ocsp_response_list" contient une liste d'éléments "OCSPResponse", comme spécifié ci-dessus, chacun contenant la réponse OCSP pour le certificat correspondant dans le message Certificate TLS de la poignée de main du serveur. C'est-à-dire que la première entrée est la réponse OCSP pour le premier certificat dans la liste Certificate, la deuxième entrée est la réponse pour le deuxième certificat, et ainsi de suite. La liste PEUT contenir moins de réponses OCSP qu'il n'y avait de certificats dans le message Certificate de la poignée de main, mais il NE DOIT PAS y avoir plus de réponses qu'il n'y avait de certificats dans la liste. Les éléments individuels de la liste PEUVENT avoir une longueur de 0 (zéro) octets si le serveur n'a pas la réponse OCSP pour ce certificat particulier stockée, auquel cas le client DOIT agir comme si une réponse n'avait pas été reçue pour ce certificat particulier. Si le client reçoit une "ocsp_response_list" qui ne contient pas de réponse pour un ou plusieurs des certificats dans la chaîne de certificats complétée, le client DEVRAIT tenter de valider le certificat en utilisant une méthode de récupération alternative, telle que le téléchargement de la CRL pertinente ; OCSP DEVRAIT dans cette situation être utilisé uniquement pour le certificat d'entité finale, et non pour les certificats CA intermédiaires, pour les raisons énoncées ci-dessus.
Notez qu'un serveur PEUT également choisir de ne pas envoyer de message "CertificateStatus", même s'il a reçu une extension "status_request_v2" dans le message client hello et a envoyé une extension "status_request_v2" dans le message server hello. De plus, notez qu'un serveur NE DOIT PAS envoyer le message "CertificateStatus" à moins d'avoir reçu soit une extension "status_request" soit "status_request_v2" dans le message client hello et d'avoir envoyé une extension "status_request" ou "status_request_v2" correspondante dans le message server hello.
Les clients demandant une réponse OCSP et recevant une ou plusieurs réponses OCSP dans un message "CertificateStatus" DOIVENT vérifier la ou les réponses OCSP et abandonner la poignée de main si la réponse est un statut "revoked" ou d'autres réponses inacceptables (telles que déterminées par la politique du client) avec une alerte bad_certificate_status_response(113). Cette alerte est toujours fatale.
Si la réponse OCSP reçue du serveur ne donne pas un statut définitif "good" ou "revoked", elle est non concluante. Un client TLS dans un tel cas PEUT vérifier la validité du certificat du serveur par d'autres moyens, par exemple, en interrogeant directement l'émetteur du certificat. Si un tel traitement aboutit toujours à une réponse non concluante, alors l'application utilisant la connexion TLS devra décider de fermer la connexion ou non. Notez que ce problème ne peut pas être décidé par le code client TLS générique sans informations de l'application. Si l'application ne fournit aucune information de ce type, alors le client DOIT abandonner la connexion, car le certificat du serveur n'a pas été suffisamment validé.
Un exemple où l'application pourrait souhaiter continuer est avec EAP-TLS (Extensible Authentication Protocol - TLS), où l'application peut utiliser un autre mécanisme pour vérifier le statut d'un certificat une fois qu'elle obtient l'accès réseau. Dans ce cas, l'application pourrait faire continuer le client avec la poignée de main, mais elle NE DOIT PAS divulguer un nom d'utilisateur et un mot de passe tant qu'elle n'a pas entièrement validé le certificat du serveur.