Résumé

  • Les deux protocoles d’émission de RFC 9578 produisent un reçu cryptographique très précis : l’authentificateur correspond à une entrée de jeton et à une clé d’émetteur.
  • L’identité, la réussite d’un défi, l’absence d’automatisation, la non-réutilisation, la décision d’accès et la livraison appartiennent à d’autres autorités et exigent leurs propres preuves.

Le défaut le plus dangereux n’est pas qu’un jeton Privacy Pass soit faux. C’est qu’un système lui fasse dire beaucoup plus que ce qu’il établit.

Une interface d’exploitation peut afficher « jeton valide » à côté d’une requête autorisée. La proximité visuelle transforme alors deux décisions en une seule. Pourtant, RFC 9578 pose une limite nette : le jeton ne prouve rien d’autre que sa création passée par un serveur donné. Le dossier du RFC Editor, la fiche Datatracker, l’historique du document et la recherche d’errata identifient la norme et son état. Aucun ne décrit l’exécution d’un déploiement particulier.

Le reçu commence par une configuration

Avant toute émission, le client doit connaître un type de jeton, le nom de l’émetteur, un point de terminaison et, pour la variante publiquement vérifiable, une clé publique. Cette configuration est déjà une surface de confiance. Sa provenance, sa fraîcheur et son empreinte déterminent la clé à laquelle le résultat sera rattaché.

Le protocole privé s’appuie sur un VOPRF sur P-384 avec SHA-384. Seul l’émetteur muni de sa clé privée peut vérifier le jeton final. La variante publique utilise une signature RSA aveugle avec un module de 2048 bits ; toute partie disposant de la clé publique peut vérifier. RFC 9497 fournit le VOPRF et RFC 9474 la signature RSA aveugle. Ces primitives protègent l’échange qui leur est confié ; elles n’ajoutent aucune déclaration sur la personne, l’intention ou le droit d’accès.

Le client fabrique une entrée comprenant le type, un nonce neuf de 32 octets, le condensat SHA-256 d’un défi opaque et l’identifiant de clé. Il aveugle ensuite cette entrée. L’émetteur contrôle la forme et le type pris en charge, évalue ou signe l’élément aveuglé, puis renvoie sa réponse. Le client la finalise en authentificateur.

La cécité empêche l’émetteur de voir directement le jeton final au moment de l’émission. Elle ne fait pas disparaître l’heure réseau, le contexte de compte, les signaux d’attestation, l’adresse d’origine ni le contrôle commun des différents rôles. Une propriété locale n’est pas une mesure d’intraçabilité de bout en bout.

Le défi n’explique pas sa propre signification

RFC 9578 manipule un défi opaque. RFC 9577 peut le fournir dans le cadre de l’authentification HTTP et de la rédemption. Le hachage lie le jeton à des octets ; il ne prouve ni qui les a choisis, ni ce qu’ils représentent, ni qu’un contrôle annoncé a réellement été réussi.

Si le défi est censé refléter un CAPTCHA, une attestation d’appareil ou un quota acheté, le composant responsable doit conserver le reçu correspondant. L’émetteur peut prouver qu’il a exécuté le protocole sur l’entrée reçue. Il ne peut pas reconstruire la preuve absente d’un test métier.

L’architecture Privacy Pass de RFC 9576 distingue client, origine, attesteur et émetteur, et analyse métadonnées et collusion. Cette séparation est un plan d’architecture, pas un certificat attestant que l’exploitant a effectivement isolé les rôles. L’article antérieur de BTW sur RFC 9614 conserve la question distincte de la séparation architecturale et de l’intraçabilité ; ici, l’objet est la chaîne allant de l’émission au résultat.

La vérification précède encore la décision

Dans le protocole privé, l’émetteur recalcule le résultat VOPRF. Dans le protocole public, le vérificateur contrôle la signature avec la clé publique. Un succès établit la correspondance entre authentificateur, entrée et clé. Il ne dit pas si tous les clients ont reçu la même vue de clé, si le jeton est frais, s’il a déjà été dépensé ou si l’action demandée est permise.

La rédemption nécessite donc un registre d’usage et une politique d’origine. Le registre IANA Privacy Pass coordonne types et formats ; l’inscription n’est ni une preuve d’adoption ni un verdict d’autorisation. Les travaux actuels sur la cohérence des clés d’émetteur et les jetons de limitation de débit montrent que la vue des clés et le quota sont des problèmes séparés. Ce sont des projets en cours, pas des normes définitives ni des preuves de déploiement.

Un dossier vérifiable doit relier l’origine et l’empreinte de configuration, l’identifiant de clé, les octets du défi et sa version de politique, le nonce, l’empreinte d’entrée, la réponse d’émission, la finalisation, le vérificateur, l’état de rédemption, la décision motivée de l’origine et le résultat applicatif. Cette chaîne doit être minimisée pour la vie privée, mais pas comprimée en un voyant vert.

La doctrine des couches de réalité de Heng Lu interdit à la validité cryptographique d’absorber l’autorité politique. Running-Code Primacy demande d’observer les composants en fonctionnement. Pourquoi BTW Media existe fixe la règle éditoriale : publier la portée exacte du reçu, pas l’histoire rassurante que l’organisation aimerait lui attribuer.

Sources