Skip to main content

8. Demande de statut de certificat

La vérification de l'état de révocation d'un certificat peut nécessiter que le client contacte un tiers tel qu'une autorité de certification (CA) ou un répondeur de Protocole de Statut de Certificat en Ligne (OCSP). Pour les clients soumis à des contraintes de bande passante, cela peut représenter un coût significatif. L'extension "status_request" permet aux clients de demander au serveur TLS d'obtenir l'état du certificat au nom du client.

8.1. Messages Hello​

Les clients qui demandent le statut du certificat DOIVENT inclure une extension de type "status_request" dans le client hello (étendu). Le champ "extension_data" de cette extension contient "CertificateStatusRequest" où :

struct {
    CertificateStatusType status_type;
    select (status_type) {
        case ocsp: OCSPStatusRequest;
    } request;
} CertificateStatusRequest;

enum { ocsp(1), (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>;

Dans le OCSPStatusRequest, les champs "responder_id_list" et "request_extensions" sont des structures DER encodées [X690] d'un ResponderID et d'Extensions, respectivement, comme défini dans [RFC2560]. "Extensions" est importé du [RFC5280]. Un "ResponderID" encodé en DER de longueur zéro signifie que le répondeur est implicite par le certificat concerné. Un "Extensions" de longueur zéro signifie qu'il n'y a pas d'extensions.

Tant le "ResponderID" que les "Extensions" sont des structures DER codées dans le champ OCSPStatusRequest défini ci-dessus. Pour des raisons de clarté, voici un exemple de codage DER pour un ResponderID :

ResponderID ::= CHOICE {
   byName               [1] Name,
   byKey                [2] KeyHash }

KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
                          -- (i.e., the SHA-1 hash of the value of the
                          -- BIT STRING subjectPublicKey [excluding
                          -- the tag, length, and number of unused
                          -- bits] in the responder's certificate)

Le codage DER de ResponderID est ensuite placé dans un vecteur opaque dans le champ responder_id_list.

Les serveurs qui reçoivent une extension client hello "status_request" PEUVENT renvoyer une extension server hello "status_request" appropriée si le serveur choisit de renvoyer le statut du certificat dans la poignée de main. Si un serveur renvoie une extension "status_request" dans le server hello, alors le serveur DOIT avoir inclus une extension de type "status_request" avec un élément vide "extension_data". Le serveur a plusieurs choix pour renvoyer les informations de statut du certificat :

  • Il peut demander le statut du certificat et le renvoyer dans le message CertificateStatus (étendu) comme décrit dans la Section 8.2.

  • Il peut choisir de ne pas demander le statut du certificat et ne pas inclure une extension "status_request" dans le server hello.

  • Il peut choisir de ne pas demander le statut du certificat même s'il a inclus l'extension "status_request" dans le server hello. Dans ce cas, le serveur ne renvoie pas le message CertificateStatus (étendu).

Dans le cas où le serveur choisit de ne pas renvoyer le statut du certificat dans la poignée de main, le client PEUT choisir de demander directement le statut du certificat à un répondeur OCSP externe.

8.2. Statut du certificat​

Le serveur MAY renvoyer un message "CertificateStatus" dans la poignée de main TLS si le client a demandé un statut de certificat en incluant une extension "status_request" dans le client hello. Si le serveur choisit d'envoyer un CertificateStatus, ce message DOIT être envoyé immédiatement après le message Certificate (et avant tout message ServerKeyExchange ou CertificateRequest, le cas échéant).

La structure du message CertificateStatus est :

struct {
    CertificateStatusType status_type;
    select (status_type) {
        case ocsp: OCSPResponse;
    } response;
} CertificateStatus;

opaque OCSPResponse<1..2^24-1>;

Un "OCSPResponse" contient une structure DER-encodée OCSPResponse complète (telle que définie dans [RFC2560]). Seule une réponse OCSP PEUT être envoyée.

La "CertificateStatus" DOIT contenir une réponse OCSP avec une valeur OCSPResponseStatus de "successful" (0).

Le serveur DOIT envoyer le message "CertificateStatus" si :

  • Il reçoit une extension "status_request" valide dans le client hello et choisit d'honorer la demande, ET
  • Il obtient une réponse OCSP valide pour son certificat.

Si une réponse OCSP valide n'est pas disponible, le serveur NE DEVRAIT PAS envoyer le message "CertificateStatus".

Le client qui demande un statut de certificat DOIT vérifier la réponse OCSP s'il en reçoit une. Si la réponse OCSP n'est pas satisfaisante, le client MAY décider d'avorter la poignée de main. Les considérations que le client utilise pour déterminer si la réponse OCSP est satisfaisante sont au-delà de la portée de ce document. Le client NE DOIT PAS traiter une absence de réponse OCSP (c'est-à-dire, que le serveur n'a pas envoyé de message CertificateStatus) comme la signification d'un échec de la demande de statut, et DEVRAIT continuer la poignée de main normalement dans ce cas.

8.3. Implications pour la mise en cache des réponses OCSP​

Les serveurs qui implémentent cette extension DEVRAIENT mettre en cache les réponses OCSP pour les certificats qu'ils utilisent. Le serveur DEVRAIT également obtenir régulièrement (avant l'expiration du thisUpdate ou du nextUpdate) de nouvelles réponses OCSP pour maintenir la fraîcheur des informations de statut.

Les serveurs PEUVENT maintenir un cache de réponses OCSP agrégées pour gérer efficacement plusieurs certificats. Dans ce cas, le serveur doit s'assurer que les réponses OCSP sont fraîches et correspondantes au certificat du serveur.

Un serveur qui ne peut pas obtenir ou mettre à jour une réponse OCSP en temps opportun PEUT continuer à utiliser une réponse OCSP expirée jusqu'à ce qu'une nouvelle réponse soit disponible. Cependant, il DEVRAIT essayer d'obtenir une nouvelle réponse OCSP dès que possible.

8.4. Considérations de sécurité pour la demande de statut de certificat​

L'extension "status_request" permet à un client de demander au serveur de fournir des informations de statut de certificat (généralement via OCSP) pendant la poignée de main TLS. Cela a des implications de sécurité importantes :

Avantages de sécurité :

  • Vie privée améliorée : Le client n'a pas besoin de contacter directement un répondeur OCSP, ce qui empêche le répondeur OCSP de suivre les activités du client.

  • Performance : Réduit la latence de connexion en évitant un aller-retour supplémentaire vers un répondeur OCSP externe.

  • Fiabilité : Le serveur peut mettre en cache les réponses OCSP, rendant le service plus fiable même si le répondeur OCSP est temporairement indisponible.

Risques de sécurité :

  • Fraîcheur des réponses OCSP : Le serveur peut servir des réponses OCSP obsolètes. Les clients doivent vérifier les champs thisUpdate et nextUpdate dans la réponse OCSP.

  • Réponses OCSP falsifiées : Un serveur compromis pourrait fournir de fausses réponses OCSP. Les clients DOIVENT vérifier la signature de la réponse OCSP.

  • Attaques par déni de service : Un serveur pourrait intentionnellement ne pas fournir de réponse OCSP pour un certificat révoqué. Les clients DEVRAIENT avoir une politique de secours (par exemple, contacter directement le répondeur OCSP ou refuser la connexion).

  • Vie privée du serveur : Le serveur révèle l'identité du répondeur OCSP qu'il utilise, ce qui pourrait révéler des informations sur l'infrastructure du serveur.

Les clients qui implémentent cette extension DOIVENT effectuer une validation complète de la réponse OCSP, y compris la vérification de la signature, la vérification que le répondeur est autorisé, et la vérification que la réponse est fraîche selon la politique du client.

Last updated on