Résumé

  • Une réponse OCSP agrafée porte sur un CertID précis et sur des instants définis. La signature établit le droit du répondeur à faire cette déclaration ; elle ne prouve ni qu’il connaissait une révocation ultérieure, ni qu’il a produit la réponse pour cette connexion.
  • producedAt, thisUpdate et nextUpdate répondent à trois questions distinctes. L’heure de collecte, l’âge HTTP, l’installation dans le serveur, l’horloge du client et sa limite d’âge ajoutent d’autres frontières.
  • TLS transporte la preuve, tandis que le client décide de sa conséquence. Une décision défendable conserve l’identité du certificat, l’habilitation du signataire, les temps, le cache, la place dans la chaîne, Must-Staple et le choix explicite entre échec souple et échec ferme.

Le feu vert qui a traversé la révocation

Le répondeur signe good à 09 h 55. Le serveur télécharge la réponse à 09 h 57. Dix minutes plus tard intervient la révocation, puis un nouveau client reçoit la copie en mémoire.

La signature passe. thisUpdate n’est pas dans le futur et nextUpdate n’est pas dépassé. Ces contrôles ne peuvent toutefois ajouter à une réponse un événement survenu après le moment où son statut était connu correct.

Parler de faux confondrait authenticité et actualité. Parler de révocation vérifiée confondrait les autorités du répondeur, du cache, de TLS et du client. La question utile est plus exacte : qui a affirmé quel état, pour quel certificat, selon quelle période de connaissance et sous quelle règle d’acceptation ?

CertID délimite l’objet de la preuve

OCSP n’attribue pas un état global à un site. CertID associe le hachage du nom de l’émetteur, celui de sa clé, le numéro de série du certificat et l’algorithme de hachage. Une réponse valide pour un autre numéro de série répond à une autre question.

Il en va de même pour la chaîne. Une réponse attachée au certificat final ne dit rien, à elle seule, sur un intermédiaire. Les traces doivent conserver les empreintes, l’émetteur, le numéro de série, le CertID exact et la position de chaque réponse.

Le mot good est volontairement limité dans la RFC 6960. Au minimum, aucun certificat actuellement valide portant ce numéro de série n’est enregistré comme révoqué. Le terme ne prouve pas nécessairement l’émission du certificat et ne promet pas l’absorption immédiate d’un événement postérieur à thisUpdate.

La signature confère un mandat, pas l’omniscience

Une réponse définitive doit être signée par l’émetteur ou par un répondeur auquel celui-ci a explicitement délégué la signature OCSP. Le client doit vérifier la signature et ce lien d’habilitation.

Un signataire non habilité échoue même si le calcul cryptographique est correct. Un signataire habilité peut, lui, exprimer fidèlement une vue qui n’a pas encore reçu le dernier changement. Le mandat et l’âge de l’information sont deux axes indépendants.

Il faut donc conserver le certificat du répondeur, sa relation à l’émetteur, son usage de signature OCSP, le résultat cryptographique et le hachage des octets reçus. Un simple succès de chaîne ne restitue pas cette provenance.

Trois heures signées, puis celles de l’exploitation

producedAt date la signature. thisUpdate désigne le dernier instant où l’état était connu correct. nextUpdate borne la disponibilité annoncée d’une information plus récente. Les réduire à une seule « expiration » détruit leur sens.

La RFC 6960 permet de préproduire des réponses. La RFC 9919 fait du cache un mécanisme explicite, impose nextUpdate dans son profil et demande au client de situer son heure courante entre thisUpdate et nextUpdate.

Restent les heures non signées : inscription de la révocation, ingestion par le répondeur, Date et Age HTTP, collecte et revalidation par le serveur, installation dans les identifiants actifs, poignée de main et horloge du client. Une mesure monotone doit survivre à un retour en arrière de l’horloge murale.

La tolérance de dérive n’est pas un supplément de fraîcheur. Un thisUpdate trop futur, un nextUpdate dépassé ou une réponse plus âgée que la limite locale doivent produire des motifs distincts.

Le cache fait partie du modèle

L’agrafage évite au client un appel OCSP par connexion. Il protège sa confidentialité, réduit la latence et dissocie la disponibilité du répondeur de celle de la poignée de main. La réutilisation est intentionnelle.

Date, Last-Modified, Expires, ETag et Cache-Control organisent la conservation et la revalidation. La durée HTTP doit s’arrêter avant la frontière OCSP. Une copie obsolète fournie par un intermédiaire peut conduire à une nouvelle demande no-cache.

Deux contrôles doivent donc rester séparés : la réponse respecte-t-elle ses temps signés ? Le serveur a-t-il tenu sa promesse de renouvellement ? Pour le second, enregistrer l’origine, les en-têtes HTTP, le hachage, la date de collecte, le résultat de revalidation, l’échéance et la génération d’identifiants active.

Une réponse correcte chargée au démarrage ne suffit pas. Si le renouvellement s’arrête, la commande est déjà perdue avant le premier rejet client.

Une agrafe partagée n’est pas un nonce par client

Le nonce OCSP relie demande et réponse afin de distinguer une nouvelle réponse d’une ancienne copie. La RFC 8954 autorise néanmoins son omission par le répondeur et cite des périodes plus courtes comme réduction du risque de rejeu.

Une même agrafe destinée à des milliers de connexions ne porte généralement pas le nonce aléatoire de chacune. Sa fraîcheur repose sur l’intervalle signé, la limite d’âge locale et le renouvellement. Une nouvelle poignée de main prouve un nouveau transport, pas une nouvelle production.

TLS apporte les octets ; le client rend le verdict

Jusqu’à TLS 1.2, le client propose status_request et le serveur peut répondre par CertificateStatus. TLS 1.3 associe l’état aux entrées de certificat. L’attribution IANA de la valeur 5 identifie l’extension, sans prouver son emploi ni son acceptation.

La présence n’est pas la validité. BoringSSL expose des octets bruts qui ne sont pas garantis bien formés. OpenSSL sépare la demande cliente, l’installation serveur et la lecture cliente. Une métrique de rappel ne démontre ni le CertID, ni la signature, ni le temps.

L’absence possède aussi plusieurs causes : pas de demande cliente, session reprise sans échange de certificat, refus du serveur, certificat sans TLS Feature ou politique d’échec souple. Il faut tracer ClientHello, poignée complète ou reprise, nombre et position des réponses, résultat de chaque contrôle et motif final.

Must-Staple ne valide pas le contenu

L’extension TLS Feature dite Must-Staple empêche que l’exigence de statut disparaisse silencieusement. Le serveur doit satisfaire la demande du client ; sinon, celui-ci peut refuser la connexion. Cette possibilité n’implique pas une application universelle par tous les clients.

Elle n’absout pas davantage une réponse présente. Mauvais CertID, signataire sans mandat, signature incorrecte, temps inacceptable, unknown ou revoked restent des échecs propres. Must-Staple gouverne l’omission ; OCSP gouverne la qualité de ce qui est livré.

Les essais doivent supprimer une agrafe obligatoire puis fournir une agrafe invalide. Compter seulement la présence ne teste aucun des deux contrats.

De la chaîne au processus en cours

Avant TLS 1.3, une seule réponse concerne généralement le certificat final. TLS 1.3 peut associer plusieurs réponses aux entrées de la chaîne. OpenSSL expose cette différence et n’interdit pas les positions vides. Cela n’impose pas une règle universelle de couverture, mais interdit de perdre le nombre et la position.

Lors d’une reprise sans certificat, OpenSSL n’appelle pas le rappel de statut. La connexion peut s’appuyer sur un état d’authentification antérieur ; elle ne doit pas être comptée comme une nouvelle observation OCSP.

OpenSSL propose séparément la recherche du CertID, l’extraction du statut, le contrôle des temps avec dérive et âge maximal, ainsi que la vérification du signataire. L’application assemble ces faits et décide. Sans nextUpdate, l’âge maximal est essentiel pour qu’une réponse ancienne ne paraisse pas éternellement acceptable.

GnuTLS sait intégrer OCSP à la validation et signaler l’absence sous Must-Staple, mais le serveur doit renouveler périodiquement les réponses, parfois en préparant une nouvelle génération d’identifiants. BoringSSL recommande également collecte et renouvellement en amont, plutôt qu’un accès réseau bloquant dans la poignée de main.

La preuve décisive est donc l’état en cours : quel hachage chaque processus sert, quand il a été installé, si le dernier renouvellement a réussi, quelle marge subsiste et quelle décision les clients ont prise.

Épreuves négatives

Présenter une signature correcte pour un autre numéro de série, un répondeur non habilité, un thisUpdate trop futur, un nextUpdate dépassé, une vieille réponse sans âge maximal ou des octets mal formés. Rejouer un good encore dans son intervalle après une révocation et mesurer la fenêtre au lieu de parler de falsification.

Supprimer une agrafe exigée, omettre un intermédiaire requis par la politique locale et reprendre une session TLS 1.3 sans laisser la télémétrie inventer un nouvel échange. Arrêter le renouvellement : l’alerte doit précéder l’expiration. Reculer l’horloge : l’âge monotone doit continuer. Couper le répondeur : le cache acceptable doit préserver les connexions sans appel synchrone, puis la politique choisie doit s’appliquer à son échéance.

Sources