Résumé

  • Le stapling OCSP place une preuve signée de l’état d’un certificat dans la négociation TLS et évite au client une requête distincte vers le répondeur.
  • L’état good a un sens volontairement limité, tandis que thisUpdate, nextUpdate et producedAt bornent l’affirmation dans le temps.
  • Une signature valide et une réponse encore acceptable ne révèlent pas quand chaque point de terminaison l’a récupérée, ni si une information de révocation plus récente y a été déployée.
  • L’exploitation a donc besoin d’un registre vérifiable de mise à jour de la révocation reliant le certificat et le répondeur aux horodatages, à la cohorte de déploiement et à l’instant de décision du client.

Prenons un incident hypothétique, sans l’attribuer à un fournisseur ni à un événement réel. Une autorité de certification produit une réponse OCSP signée avec l’état good. Un point de terminaison la récupère et la met en cache. Le certificat est ensuite révoqué. Un second point de terminaison reçoit une réponse plus récente, alors que le premier continue de présenter l’ancienne, toujours comprise dans sa fenêtre temporelle. Le client peut valider cette ancienne réponse conformément à sa politique sans pour autant apprendre ce que l’opérateur prétend lorsqu’il affirme que « la révocation est appliquée partout ».

La limite apparaît dans le protocole lui-même. Le RFC 6960 définit OCSP comme un moyen d’obtenir l’état d’un certificat sans télécharger une liste de révocation complète. Une réponse définitive est signée, identifie son répondeur et contient un état pour un certificat donné. Elle apporte donc une preuve bien plus solide qu’un simple indicateur de disponibilité. Elle reste néanmoins une affirmation portant sur un objet, un contexte d’émission et une période déterminés.

Le mot good prête particulièrement à l’exagération. Dans son sens minimal, il indique qu’aucun certificat portant le numéro de série demandé et se trouvant dans sa période de validité n’est alors enregistré comme révoqué. Le RFC limite immédiatement la portée de cette réponse : elle ne prouve pas nécessairement que le certificat a réellement été émis, ni que la réponse a été produite pendant la période de validité du certificat. Des extensions peuvent ajouter d’autres affirmations, mais l’état de base ne garantit pas à lui seul que le certificat, le serveur, le compte et la maîtrise opérationnelle du service sont tous légitimes au moment présent.

Trois horodatages rendent cette frontière observable. thisUpdate indique le dernier instant auquel le répondeur savait l’état déclaré exact. nextUpdate indique l’instant avant lequel des informations plus récentes seront disponibles. producedAt indique quand la réponse a été signée. Ces valeurs ne sont pas interchangeables. Une réponse signée récemment peut décrire un état connu plus tôt. De même, un nextUpdate encore futur ne démontre pas qu’un changement opérationnel survenu depuis a déjà atteint chaque cache et chaque point de terminaison.

Avant d’accepter une réponse signée, la partie qui s’y fie doit vérifier qu’elle correspond au certificat demandé, valider sa signature, établir que le signataire est autorisé, juger thisUpdate suffisamment récent et, lorsqu’il existe, vérifier que nextUpdate est postérieur à l’heure courante. Ces contrôles établissent l’authenticité de l’objet et son acceptabilité selon la politique locale. Ils ne dressent pas l’inventaire du chemin de distribution par lequel l’objet est arrivé sur le serveur qui le présente.

Le RFC 6066 décrit l’extension TLS status_request. Elle permet au serveur de joindre une réponse OCSP à son certificat. L’information arrive dans la négociation elle-même ; le client n’a plus à contacter le répondeur en parallèle. Lorsqu’il reçoit cette réponse, il doit la vérifier et interrompre la négociation si elle n’est pas satisfaisante. Le stapling OCSP améliore ainsi la livraison de la preuve. Il n’élargit pas ce que la preuve affirme.

Cette différence devient importante dans un service distribué. Le même certificat peut être installé sur de nombreux points d’entrée, grappes de terminaison ou régions de diffusion. Chacun peut récupérer, conserver et renouveler ses réponses de statut par un chemin opérationnel différent. La réponse OCSP enregistre la connaissance et les horodatages du répondeur, non la liste complète des points de présence, leur version de configuration, le résultat de leur dernière récupération ou l’accusé de réception du remplacement. « La réponse est valide » et « le dernier état de révocation est appliqué partout » sont deux constats distincts.

Le RFC 7633 fournit un autre levier. Un certificat peut déclarer une fonctionnalité TLS obligatoire, notamment status_request. Un client compatible peut alors rejeter une configuration qui ne fournit pas la preuve attendue. Cette déclaration résout une ambiguïté importante : en son absence, l’omission d’une réponse OCSP jointe ne permet pas de savoir si le serveur légitime ne la prend pas en charge ou s’il la retient. Dans les cas prévus par la spécification, la validation peut néanmoins s’appuyer sur une autre source. Must-Staple impose la livraison d’une preuve ; il ne rajeunit pas une réponse, n’empêche pas toute émission frauduleuse et ne prouve pas que l’exploitant contrôle encore le service applicatif derrière le certificat.

L’erreur opérationnelle consiste à fondre quatre états dans un seul voyant vert. La chaîne du certificat peut être valide. La signature OCSP peut être valide. La réponse peut respecter la politique temporelle du client. Malgré cela, un point de terminaison peut ne pas disposer de l’information la plus récente ou ne pas appartenir à la cohorte que l’opérateur croit avoir mise à jour. Un tableau de bord qui indique uniquement « réponse OCSP présente » ne distingue pas ces situations.

Un registre vérifiable de mise à jour de la révocation utile conserverait cette chaîne au lieu de la réduire. Il nommerait le numéro de série et la chaîne de certification complète, l’identité du répondeur, l’état renvoyé, thisUpdate, nextUpdate, producedAt, l’heure de récupération, la cohorte de points de terminaison ayant installé la réponse, la politique de validation et l’heure de décision. Il enregistrerait aussi les échecs de remplacement et séparerait l’authentification du transport de l’autorisation applicative actuelle.

Cela ne rend pas le stapling OCSP fragile. Cela en précise la portée opérationnelle. Il réduit la fuite d’informations côté client, la latence de négociation et la dépendance à une requête tierce en temps réel. Must-Staple rend l’absence de preuve exploitable par la politique. La signature et les contrôles temporels authentifient une affirmation bornée. Le problème ne commence que lorsque ces avantages sont transformés en une garantie que l’objet ne contient pas.

La décision pertinente n’est donc pas de faire confiance ou non à OCSP en général. Elle consiste à définir quelle affirmation opérationnelle une réponse OCSP jointe peut satisfaire. Pour valider une négociation, une réponse authentique et suffisamment fraîche peut être décisive. Pour affirmer que la révocation a atteint tous les points actifs, il faut une preuve de déploiement supplémentaire. Pour autoriser une action applicative, le service doit produire sa propre décision d’identité et de politique, sans emprunter cette autorité à l’objet de statut du certificat.

Sources

RFC 6960 — Online Certificate Status Protocol ; RFC 6066 — extensions TLS ; RFC 7633 — extension TLS Feature.