Résumé

  • RFC 9919 autorise la préproduction et la mise en cache des réponses OCSP, tout en précisant que les en-têtes HTTP ne sont pas protégés cryptographiquement et ne servent qu’à piloter le cache.
  • Le client doit relier la réponse au certificat, valider la signature et l’habilitation du signataire, puis comparer son heure exacte à l’intervalle signé thisUpdatenextUpdate.
  • Même récent, good reste un constat limité de non-révocation ; il ne prouve seul ni l’émission, ni toute la validité du certificat, ni un droit applicatif, ni un résultat opérationnel.

Une réponse préparée peut rester une réponse valable

Le profil léger n’exige pas que chaque requête déclenche une nouvelle consultation de base et une nouvelle signature. Il permet au répondeur de préparer une réponse, de la placer dans plusieurs couches de cache et de la faire parvenir au client par HTTP ou dans un autre échange protocolaire. Pour des populations de certificats qui se comptent en millions, cette économie de calcul et de bande passante est structurelle.

RFC 9919, qui remplace RFC 5019, rend cette distribution plus explicite. Les petites requêtes utilisent GET afin d’être mises en cache. Les réponses autoritatives peuvent porter Expires, ETag et Cache-Control. Le client doit lui-même conserver les réponses dont il a validé la signature et dont le statut de réponse est successful.

Deux chronologies se superposent alors. HTTP décide quand une représentation stockée peut être resservie et quand il convient de la rafraîchir. OCSP décide jusqu’à quand une assertion de statut signée demeure acceptable. Les mots se ressemblent ; les preuves non. RFC 9919 avertit que les champs HTTP ne sont pas couverts par la signature et peuvent être modifiés. Ils orientent le cache. Les valeurs contenues dans l’OCSPResponse signée orientent l’acceptation.

Le cache ne perd donc pas sa fonction. Il perd seulement une autorité qu’il n’a jamais reçue. Il transporte le constat ; il ne décide ni de son auteur, ni de son objet, ni de sa durée signée.

Le temps de connaissance, le temps de signature, le prochain état

thisUpdate désigne l’instant où le répondeur savait le statut exact. nextUpdate indique l’instant au plus tard où une information plus récente sera disponible. producedAt est l’heure de signature. Une réponse préproduite peut rapprocher ces valeurs, mais elle ne les rend pas sémantiquement équivalentes.

RFC 9919 rend nextUpdate obligatoire dans son profil. Le client doit le trouver, puis vérifier que son heure GMT actuelle se situe entre thisUpdate et nextUpdate. Après la borne finale, la réponse est périmée. Une petite tolérance locale peut compenser les écarts d’horloge, à condition de la choisir en fonction de la qualité réelle de la synchronisation et de la conserver dans les traces.

Une horloge avancée transforme une réponse encore fraîche en rejet prématuré. Une horloge retardée produit le danger inverse : elle continue d’accepter un ancien good alors qu’une réponse plus récente pourrait être revoked. Dans les deux cas, la signature peut être intacte. L’intégrité du message ne fournit pas l’heure à laquelle le client l’évalue.

Le nonce peut lier cryptographiquement une requête et sa réponse, mais le profil léger privilégie souvent la validation temporelle. Dans les conditions prévues, l’absence du nonce attendu ne suffit pas à rejeter ; le client revient aux temps signés. L’horloge, l’intervalle et la tolérance forment donc une seule décision vérifiable.

max-age évite le pic ; nextUpdate ferme la fenêtre

Le max-age HTTP se place après thisUpdate, mais avant nextUpdate. Les clients peuvent demander un remplacement avant l’échéance signée, et le répondeur doit renouveler l’objet avant ce point. Ainsi, tous les utilisateurs d’un certificat populaire ne reviennent pas exactement à la même seconde.

Ce mécanisme lisse la charge. Il ne prolonge pas le statut. Un proxy peut changer un en-tête sans toucher aux octets signés. Même si l’enveloppe paraît fraîche, une réponse située au-delà de nextUpdate ne doit plus être utilisée. Lorsqu’un intermédiaire persiste à servir un objet expiré, le client peut contourner son cache et demander une version nouvelle ; cette relance ne réhabilite jamais l’ancienne.

Le même raisonnement vaut pour l’agrafage OCSP. Inclure la réponse dans TLS supprime une session HTTP et parfois autorise un contrôle hors connexion au répondeur. La poignée de main n’ajoute aucune seconde à l’intervalle signé. L’objet agrafé garde son certificat cible, son signataire, son statut et son échéance.

successful n’est pas good, et good n’est pas « valide »

Le statut supérieur successful signifie que l’infrastructure OCSP possède les enregistrements autoritatifs nécessaires pour répondre. Le statut par certificat est ensuite good, revoked ou unknown. Confondre ces deux niveaux revient déjà à perdre une décision.

RFC 6960 borne encore good. Au minimum, aucun certificat portant le numéro de série demandé et se trouvant dans sa période de validité n’est révoqué. La réponse ne garantit pas nécessairement que le certificat a jamais été émis, ni que l’instant de production tombe dans sa période de validité. Des extensions peuvent ajouter des affirmations ; le mot nu ne peut pas les inventer.

Avant de l’utiliser, le client relie la réponse au CertID demandé, valide sa signature et prouve que le signataire est habilité par l’AC concernée. La construction du chemin, l’identité de service, les règles applicatives et l’autorisation locale restent d’autres étapes.

Une preuve exploitable conservera donc le CertID, le hachage de réponse, le signataire et sa chaîne d’habilitation, l’algorithme, le statut individuel, producedAt, thisUpdate, nextUpdate, l’heure de comparaison, le décalage et la tolérance, ainsi que le comportement du nonce. Côté transport, elle séparera age, max-age, Expires, ETag, revalidation et contournement. La décision finale de l’application et son résultat ne doivent pas être fondus dans « OCSP OK ».

RFC 9919 impose par ailleurs SHA-256 pour les hachages d’émetteur dans CertID. Les anciens clients compatibles RFC 5019 peuvent encore employer SHA-1, mais doivent migrer. Leur nombre mesure une population héritée ; il ne mesure pas la justesse de la fraîcheur.

Sources