Résumé

  • RFC 9654 impose au demandeur moderne un nonce d’au moins 32 octets, produit par un générateur pseudo-aléatoire cryptographiquement robuste ; sa reprise exacte lie la réponse à cette requête.
  • Cette égalité ne prouve ni l’actualité du flux de révocation du répondeur, ni l’habilitation du signataire, ni l’identité du certificat, ni la validité temporelle de l’assertion, ni l’autorisation finale de l’application.
  • L’audit doit conserver des reçus distincts pour les octets échangés, la génération et la comparaison du nonce, le signataire, le CertID, les temps signés, l’âge des données sources et l’action de l’application.

Le voyant vert n’est pas la conclusion

Le problème commence souvent après une vérification correcte. Le client a créé un nonce, le serveur l’a renvoyé, la comparaison binaire réussit. L’équipe d’audit résume alors l’épisode par « réponse fraîche » et fait disparaître tout ce qui n’entrait pas dans cette case.

RFC 9654 protège un lien bien défini. Le nonce figure dans les extensions de la requête puis dans celles de la réponse, sous l’identifiant id-pkix-ocsp-nonce. Si la valeur imprévisible est reprise à l’identique dans une réponse OCSP valablement vérifiée, une ancienne réponse portant une autre valeur ne peut pas passer pour la réponse à cette requête.

Ce résultat est puissant. Il ne dit pas quand le répondeur a reçu la dernière information de l’autorité de certification. Il ne vérifie pas que le statut concerne le certificat voulu. Il ne délègue pas le pouvoir de signer. Il ne décide pas si good, revoked ou unknown conduit l’application à accepter une connexion.

Trois tailles, trois contrats

La syntaxe de RFC 9654 autorise de 1 à 128 octets. Ce seul intervalle pourrait laisser croire que toutes les tailles ont le même statut opérationnel. Ce n’est pas le cas.

Un demandeur qui met en œuvre la nouvelle extension doit utiliser au moins 32 octets. Un répondeur qui la prend en charge doit accepter de 16 à 32 octets. Pour 1 à 15 octets ou 33 à 128 octets, il peut répondre sans nonce. À zéro ou au-delà de 128, il doit retourner malformedRequest.

La valeur 128 est donc une limite de représentation, non une promesse universelle de réflexion. Elle répond aux environnements où une construction cryptographique produit une valeur dépassant l’ancienne limite de 32 octets de RFC 8954. Un parc ancien peut légitimement ne pas savoir traiter ces valeurs plus longues.

Une recette d’interopérabilité doit tester au moins 16, 32, 33 et 128 octets, ainsi que les cas interdits. Elle doit enregistrer si le répondeur a rejeté, accepté avec reprise, ou répondu sans l’extension. « HTTP 200 » ou « OCSP successful » ne décrit aucune de ces branches avec assez de précision.

L’encodage est une preuve observable

RFC 9654 clarifie aussi l’encodage ASN.1. L’extnValue de l’extension est un OCTET STRING qui encapsule le Nonce, lui-même OCTET STRING. L’exemple de 32 octets montre explicitement cette enveloppe et sa valeur interne.

Ce détail évite une catégorie d’erreurs silencieuses. Une bibliothèque peut détecter l’OID correct mais comparer l’enveloppe complète à la valeur interne. Une autre peut accepter une longueur décodée incorrecte. Une troisième peut journaliser une chaîne hexadécimale tronquée et empêcher toute reconstruction.

Le reçu utile conserve les octets DER de la requête, leur empreinte, les octets de la réponse, leur empreinte, l’emplacement de l’extension, la longueur externe, la longueur interne et le résultat de l’égalité exacte. Le registre IANA des identifiants de modules PKIX enregistre les modules ASN.1 111 et 112 de RFC 9654 ; cette inscription coordonne le module, elle ne remplace pas la preuve de ce que le parseur chargé a effectivement décodé.

Une valeur longue peut rester prévisible

La longueur n’est pas l’entropie. RFC 9654 exige un générateur pseudo-aléatoire cryptographiquement robuste et renvoie à RFC 4086. Si l’adversaire peut prédire la prochaine valeur, il peut demander à l’avance une réponse qui la contient. Si l’espace est minuscule, il peut préparer toutes les possibilités.

Dans ces deux cas, l’égalité future peut être parfaite. C’est la signification anti-rejeu qui a disparu. L’audit doit donc commencer à la génération : source d’aléa, état de santé, instant de création, longueur, absence de réutilisation et isolement entre processus. Une politique « 32 octets » sans preuve de fraîcheur du tirage ne contrôle que le format.

Cette séparation suit la primauté du code en fonctionnement. La norme décrit l’invariant. Le générateur chargé, ses mesures, la capture et la comparaison montrent si l’invariant a existé dans cette exécution.

La réponse la plus récente peut utiliser des données anciennes

Le texte de RFC 9654 indique que l’inclusion du nonce garantit la réponse la plus récente du serveur plutôt qu’une ancienne copie. Le sujet de cette phrase doit rester visible : la réponse du serveur à la requête. Ce n’est pas un certificat sur la chaîne d’approvisionnement des données du serveur.

RFC 6960 distingue producedAt, moment de signature, thisUpdate, moment où le statut indiqué était connu comme correct, et nextUpdate, moment où une information plus récente sera disponible. Le CertID identifie l’émetteur et le numéro de série. Le message porte aussi le statut, l’identité du répondeur et une signature.

Supposons que l’autorité marque un certificat révoqué à 10 h 00, mais que son flux n’atteigne le répondeur qu’à 10 h 05. À 10 h 03, celui-ci peut fabriquer une réponse neuve, correctement liée au nonce et correctement signée à partir de l’état qu’il possède. L’échange est neuf ; la donnée amont est en retard. Affirmer davantage demande un filigrane du flux, une version de lot ou une autre preuve d’ingestion.

L’autorité du signataire reste une autre porte. RFC 6960 autorise l’autorité émettrice, un répondeur explicitement approuvé ou un répondeur délégué muni du certificat approprié. Une valeur aléatoire ne crée aucune de ces habilitations. De même, le statut good a une portée étroite : il ne garantit pas l’émission, l’identité du sujet, la période de validité du certificat ou la permission métier.

L’absence n’est pas la discordance

RFC 5019 traite les environnements à fort volume, où les réponses préproduites et mises en cache réduisent la charge. Un répondeur peut omettre le nonce même si le client l’a envoyé. Si le client ne sait pas que le serveur le prend en charge, il ne devrait pas rejeter pour ce seul motif ; il revient à la fraîcheur temporelle signée.

RFC 9654 décrit alors le risque résiduel : un attaquant sur le chemin peut substituer une ancienne réponse du serveur dépourvue de nonce. Une fenêtre courte entre thisUpdate et nextUpdate réduit la durée exploitable. Cette branche n’a pas la même preuve qu’une égalité, et elle n’a pas la même signification qu’une valeur différente.

Les quatre états minimaux sont donc : présent et identique ; absent avec repli autorisé ; présent mais différent ; requête ou réponse mal formée. Chacun doit porter le résultat des contrôles suivants. Les comprimer dans un seul taux de succès rend invisible une dégradation de politique.

Une chaîne de reçus, pas un slogan de fraîcheur

Le dossier commence par l’empreinte et le numéro de série du certificat, les hachages de l’émetteur et le répondeur attendu. Il ajoute les octets de requête, la preuve de génération du nonce et la destination. La réponse apporte ses octets, son identité, la chaîne du signataire, l’habilitation et la signature.

Ensuite seulement viennent la présence et l’égalité du nonce, le CertID, le statut et les temps. L’observation du flux amont reste séparée. Enfin, le client consigne son horloge, sa tolérance, sa version, sa politique et sa raison ; l’application consigne validation de chaîne, identité, admission et effet de session.

Les couches de réalité empêchent la première preuve séduisante d’absorber les suivantes. La spécification initiale minimale maintient le bien commun au bon endroit : format, limites, aléa et comparaison sont partagés ; ingestion, tolérance et acceptation restent attribuées aux opérateurs responsables.

Sources