Résumé

  • RFC 9919 impose la présence de nextUpdate et le rejet d'une réponse OCSP lorsque l'heure du client a dépassé cette échéance signée.
  • La signature atteste l'origine autorisée et l'intégrité des champs OCSP ; elle ne protège pas les en-têtes HTTP et ne prolonge pas un ancien statut good.
  • L'audit doit conserver la réponse exacte, la qualité de l'horloge, la tolérance, le chemin de cache et la décision applicative, et non un simple compteur de succès.

Une preuve authentique qui n'est plus actuelle

Une réponse peut être authentique et inutilisable. C'est le point de départ le plus utile pour lire RFC 9919. Le profil vise des infrastructures de clés publiques où les certificats et les parties utilisatrices se comptent par millions. Il autorise donc la préproduction des réponses, leur distribution par des caches et leur insertion dans d'autres échanges. Cette économie évite de transformer le répondeur OCSP en point de passage en temps réel pour chaque connexion.

Elle ne supprime pas le temps ; elle le rend décisif. thisUpdate indique le moment le plus récent auquel le statut était tenu pour correct. producedAt indique la signature de la réponse. nextUpdate annonce au plus tard quand une information plus récente doit être disponible. Dans le profil léger, ce dernier champ est obligatoire. Sans lui, le client rejette. Après lui, il rejette pour péremption.

La signature ne « vieillit » pas comme une session. Des années plus tard, le calcul cryptographique peut encore être exact. Ce qui a pris fin, c'est le mandat temporel de l'affirmation. Entre-temps, une réponse plus récente peut annoncer la révocation du certificat. Accepter l'ancienne réponse parce que sa signature reste valide reviendrait à transformer une preuve datée en autorisation permanente.

Le mot good ne dit pas tout ce que l'interface suggère

RFC 6960 limite soigneusement le sens des états OCSP. good signifie au minimum que le répondeur ne considère pas comme révoqué un certificat portant le numéro de série demandé dans son intervalle de validité. Cet état ne garantit pas nécessairement que le certificat a réellement été émis. Il ne valide pas à lui seul sa période de validité, le nom du service, la chaîne complète ni le droit de l'utilisateur à effectuer une opération.

Avant d'accepter une réponse, le client doit relier celle-ci au certificat visé, valider la signature, établir que le signataire est autorisé par l'autorité de certification concernée et vérifier la fraîcheur. Les contrôles d'identité et la politique de l'application viennent encore après.

L'expression « OCSP est vert » efface cette chaîne. Elle ne permet pas de savoir si le service répondait, si le message portait un état définitif, si le signataire avait le bon mandat, si les dates étaient valides ou si l'application a finalement accepté le certificat. Un bon dossier d'incident décompose ces résultats au lieu de les réunir sous une couleur.

L'horloge du client entre dans la frontière de sécurité

Un nonce permettrait de lier une réponse à une requête particulière, mais limiterait la préproduction et le partage des réponses. RFC 9919 recommande donc aux clients de ne pas ajouter normalement d'extensions à la requête. Lorsqu'un client envoie malgré tout un nonce et que le répondeur ne le reproduit pas, l'absence ne suffit généralement pas à rejeter : le client revient au contrôle temporel, sauf s'il sait que le répondeur prend les nonces en charge.

Le client doit disposer d'une heure exacte. Il compare son heure courante à thisUpdate et nextUpdate. Une petite marge peut tenir compte d'écarts d'horloge, mais sa taille dépend de la précision disponible. Une marge d'une journée dans un environnement très contraint et une marge de quelques secondes dans un centre de données n'ont ni le même coût ni le même sens.

Une horloge trop avancée provoque des refus prématurés. Une horloge trop lente accepte potentiellement un ancien good après révocation. La supervision de l'heure ne peut donc pas se réduire à l'existence d'un démon de synchronisation. Il faut connaître la valeur employée par le processus de validation, son incertitude, les sauts récents et la marge configurée.

Deux fraîcheurs circulent dans le même message

Pour les petites requêtes, RFC 9919 impose HTTP GET afin de permettre le cache. Le répondeur fournit notamment Date, Last-Modified, Expires, ETag et Cache-Control. max-age peut inciter les clients à renouveler une réponse avant nextUpdate et ainsi répartir la charge. must-revalidate empêche un cache de choisir délibérément de servir du contenu périmé.

Ces mécanismes répondent à une question de distribution : l'intermédiaire peut-il réutiliser l'objet sans interroger l'origine ? La fraîcheur OCSP répond à une autre question : l'affirmation signée sur ce certificat est-elle encore recevable ? RFC 9919 précise que les en-têtes HTTP ne sont pas protégés cryptographiquement. Ils servent de guide au cache ; l'autorité vient des valeurs signées dans la réponse OCSP.

Un Expires manipulé ne peut donc pas repousser nextUpdate. Un objet déclaré frais par un cache ne dispense pas le client de vérifier son intervalle signé. À l'inverse, un en-tête incohérent peut justifier de contourner le proxy et de redemander la réponse, sans modifier par lui-même les octets signés.

L'agrafage TLS obéit à la même frontière. Le serveur TLS transmet une réponse OCSP et économise une connexion supplémentaire. Il n'acquiert pas pour autant le pouvoir de définir le statut. Le client vérifie toujours le signataire autorisé, l'identifiant du certificat, l'état et les dates.

SHA-256 répare une couche, pas toute la décision

RFC 9919 remplace le profil de 2007 et demande aux nouveaux clients d'utiliser SHA-256 pour les empreintes de nom et de clé de l'émetteur dans CertID. La migration réduit la dépendance durable à SHA-1 et la surface logicielle nécessaire à la compatibilité ancienne.

Cette amélioration n'est pas une preuve de fraîcheur. Un identifiant calculé avec SHA-256 peut accompagner une réponse périmée. Un algorithme moderne peut signer un état trop ancien. Un client à l'heure fausse peut mal interpréter une réponse parfaitement conforme. L'inventaire des exceptions SHA-1 est nécessaire, mais il doit rester distinct du contrôle de statut.

Conserver une décision reproductible

Le reçu devrait contenir l'empreinte et le numéro de série du certificat, les empreintes d'émetteur et leurs algorithmes, les octets exacts de la réponse, l'identité du répondeur, la chaîne et l'autorisation du signataire, producedAt, thisUpdate, nextUpdate, l'état et les informations de révocation. Il faut y ajouter l'heure locale utilisée, sa source et son incertitude, la marge, le comportement du nonce, la version du validateur, la règle appliquée et l'action finale de l'application.

Les données HTTP ont également leur place, mais comme traces d'acheminement : cache ayant servi l'objet, âge déclaré, ETag, expiration, contournement et nouvelle tentative. Elles expliquent la garde des octets. Elles ne deviennent pas pour autant une partie de la déclaration signée.

La distinction respecte les couches de réalité. L'échange HTTP prouve une livraison. La réponse signée prouve une déclaration bornée. Le journal local prouve une décision donnée avec une horloge et une politique données. Le journal applicatif montre la conséquence. Aucun voyant unique ne réunit ces quatre faits.

Sources