Résumé

  • Le projet draft-ietf-privacypass-batched-tokens-08 décrit deux objets différents : un lot VOPRF vérifié par une preuve commune et une enveloppe générique où chaque position peut réussir ou rester vide.
  • Le code HTTP, la validité de la preuve et le nombre demandé ne donnent pas, à eux seuls, le nombre de jetons finalisés puis enregistrés de façon durable.
  • Un opérateur doit rapprocher les comptes à chaque frontière sans transformer son journal d’audit en identifiant permettant de relier émission et rédemption.

Dans une trésorerie, personne n’inscrirait soixante-quatre unités en caisse parce qu’un fournisseur a accepté une commande de soixante-quatre. Il faudrait compter ce qui a été livré, contrôlé et effectivement rangé. Avec des jetons anonymes, cette discipline paraît moins naturelle : la réponse est binaire, la preuve est mathématique et le mot « émission » laisse croire que l’inventaire existe déjà.

C’est précisément l’angle mort ouvert par le traitement par lot. La révision 08, datée du 4 mai 2026, appartient au groupe Privacy Pass et vise la filière Standards Track. Au 2 octobre, elle a été soumise à l’IESG mais se trouve en AD Evaluation::Revised I-D Needed. Elle n’est pas un RFC. Le registre IANA public montre encore 0x0001 et 0x0002; la valeur 0x0005 proposée pour VOPRF avec ristretto255 et SHA-512 n’est pas encore une allocation active.

Ce statut ne retire rien à l’intérêt du mécanisme. Il oblige seulement à nommer exactement ce qu’il prouve.

Le mot « lot » recouvre deux comptabilités

Dans la variante amortie, le client crée plusieurs entrées aveuglées d’un même genre de jeton privé. L’émetteur évalue chaque élément puis produit une seule preuve sur les deux listes. Le client vérifie cette relation collective avant de fabriquer les authentificateurs individuels.

Dans la variante générique, le lot est plutôt un classeur. Il peut contenir des demandes de types différents. La réponse garde une position pour chaque demande, mais cette position est optionnelle. Une case vide signifie que l’émetteur a échoué ou refusé la demande correspondante. S’il en sert seulement une partie, il doit répondre 206 Partial Content et poursuivre le traitement des demandes suivantes. S’il n’en sert aucune, il répond 400.

Un tableau de bord unique intitulé « lots réussis » détruit donc l’information. La preuve commune de la première variante crée une frontière atomique; les cases optionnelles de la seconde rendent la réussite partielle explicite. Le modèle d’exploitation doit conserver cette différence.

Il faut distinguer au minimum : demandes préparées, demandes admises, réponses présentes, éléments finalisés, enregistrements durablement écrits et jetons encore disponibles. Aucun de ces nombres n’est automatiquement égal au précédent.

Le nonce frais est une propriété cryptographique, pas un inventaire

Pour chaque jeton amorti, le client tire un nonce frais de 32 octets. Il entre dans la valeur aveuglée avec le type, l’empreinte du défi et l’identifiant de clé de l’émetteur. Le regroupement ne doit donc pas effacer l’individualité des entrées.

Mais il reste au logiciel à maintenir l’association positionnelle. Le ie résultat évalué doit retrouver le ie nonce et la bonne tranche d’authentificateur. Une permutation, une troncature ou un défaut de reprise peut casser cette relation alors même que l’interface résume l’opération par « preuve valide ».

Puis vient le stockage. Le processus peut tomber après la finalisation et avant la transaction de base de données. Il peut écrire quarante lignes, redémarrer et en réécrire quelques-unes. Une sauvegarde peut réintroduire un jeton déjà consommé. Le protocole ne décide ni l’atomicité du magasin ni la règle de reprise.

Une bonne implémentation conserve la correspondance le temps nécessaire pour finaliser et commettre les jetons, puis réduit les données de corrélation. Garder éternellement un identifiant de lot joint à chaque rédemption offrirait à la télémétrie ce que l’aveuglement voulait retirer à l’émetteur.

L’économie porte sur la preuve, pas sur tout le coût

La fonction BlindEvaluateBatch effectue toujours une évaluation par élément. Sa complexité reste linéaire en Nr. Le gain vient de la génération mutualisée de la preuve; le texte estime que le coût pratique tend vers environ la moitié de Nr émissions séparées lorsque le lot grandit.

Cela ne veut pas dire « soixante-quatre jetons pour le coût d’un ». La validation d’entrée, la bande passante, le quota, l’état côté client, la finalisation et le stockage continuent de croître. La variante générique est elle aussi explicitement décrite comme linéaire.

La mutualisation concentre également l’échec. Un type non pris en charge, une clé tronquée inconnue, un lot trop grand ou un élément aveuglé impossible à désérialiser conduit l’émetteur amorti à répondre 422. Côté client, une désérialisation ou une vérification de preuve défaillante fait abandonner l’échange.

Le bon plafond de lot dépend donc du coût d’une perte corrélée. Un lot plus grand améliore le débit mais place davantage d’actions futures derrière le même parseur, la même clé, la même décision d’admission et la même preuve. Un lot plus petit paie plus de frais mais limite le rayon d’échec.

Le 206 est la réponse la plus honnête du protocole

Dans beaucoup de systèmes, 206 est traité comme une anomalie de transport. Ici, il décrit précisément la réalité métier du lot générique : certains jetons existent, d’autres non.

Le client ne doit ni jeter le corps parce que le statut n’est pas 200, ni créditer toutes les demandes parce que le statut appartient à la classe 2xx. Il doit lire chaque position, ignorer les cases vides, finaliser les autres avec leur demande correspondante et ne créditer que les enregistrements effectivement commis.

Cette sémantique devient importante lors d’un changement de clé. Le projet indique qu’un émetteur peut renvoyer 206 lorsque des demandes d’un même type emploient plusieurs identifiants de clé tronqués. La réussite partielle révèle alors une incohérence de configuration. La masquer par une relance globale supprime une alerte utile.

La formule de contrôle est simple :

demandé ≠ retourné ≠ finalisé ≠ stocké ≠ consommé.

Le mot « émis » devrait toujours être qualifié par l’observateur. L’émetteur peut avoir produit une réponse que le client n’a jamais reçue. Le client peut l’avoir reçue mais pas finalisée. Il peut l’avoir finalisée sans réussir l’écriture durable. Ces événements n’ont ni le même responsable ni le même remède.

La relance est un choix d’autorité

Après un 206, faut-il relancer tout le lot ou seulement les cases vides? Après une coupure réseau, comment savoir si l’émetteur a déjà consommé le quota? Après un crash local, faut-il répéter l’échange ou réparer le magasin?

Le protocole ne peut pas trancher sans l’état local. Une relance totale peut produire des jetons supplémentaires valides. Une relance partielle exige de reconstruire exactement la correspondance. L’absence de relance protège la comptabilité mais peut laisser le service sans réserve.

La règle doit être décidée avant l’incident. Chaque position a besoin d’une empreinte de demande non sensible, d’un type, d’une époque de clé, d’un état de réponse, d’un résultat de finalisation et d’un état de commit. Cette preuve d’exploitation doit rester distincte du jeton porteur et des journaux de rédemption.

Un simple timeout ne doit jamais autoriser une nouvelle émission. Il ne dit pas où l’opération s’est arrêtée.

Les limites de lot sont une politique d’allocation

L’émetteur amorti peut fixer le nombre maximal de jetons par lot. La variante générique lui permet d’ignorer les demandes au-delà d’une limite. Les recommandations de sécurité encouragent aussi des limites par client et par clé.

Ces paramètres répartissent un pouvoir économique. De grands lots favorisent le préchargement et réduisent la dépendance en ligne. De petits lots maintiennent l’émetteur sur le chemin critique. Une limite par clé peut provoquer une falaise pendant une rotation. Une limite modifiée sans annonce ressemble à une panne cryptographique alors qu’il s’agit d’une décision de capacité ou d’abus.

Il faut donc versionner et attribuer ces règles. L’IETF coordonne les structures et les codes de réponse; il ne doit pas devenir l’autorité universelle du quota. À l’inverse, l’émetteur ne doit pas faire passer une politique locale pour une nécessité du standard.

Le registre, le logiciel et le service sont trois reçus

Le projet demande un type 0x0005 et quatre types de média. La capture IANA ne comporte pas encore cette ligne. L’examen de l’Area Director demande d’ailleurs de clarifier l’allocation suggérée et certaines références.

Une allocation future prouverait qu’un numéro a été coordonné. Elle ne prouverait pas qu’un logiciel l’implémente. Un rapport d’implémentation ne démontrerait pas l’interopérabilité. Une interopérabilité ne garantirait pas la justesse du livre de stock. Et un stock correct ne garantirait aucune décision de l’origine.

Le shepherd signale un fort consensus dans un petit groupe et des rapports d’implémentations, sans fournir de recensement ni de matrice de tests. L’énoncé fidèle est donc modeste : le mécanisme a suscité du code et se trouve en évaluation IESG.

Construire un reçu qui ne devienne pas une balise

Le reçu de lot doit répondre à une question étroite : combien de jetons utilisables le magasin a-t-il effectivement ajoutés?

Au niveau du lot, conserver la variante, l’émetteur, l’époque de clé, le nombre demandé, le statut HTTP, la longueur du vecteur, une empreinte de réponse, le plafond appliqué et le résultat de preuve. Au niveau des positions, conserver temporairement l’empreinte de demande, la présence de réponse, la désérialisation, la finalisation et le commit. Au niveau du stock, tenir un solde transactionnel : ouverture, ajouts commis, quarantaine, consommations confirmées, résultats ambigus et clôture.

Ne pas réutiliser l’identifiant de lot dans la présentation au site d’origine. Ne pas joindre automatiquement les journaux d’attestation, d’émission, de stock et de rédemption. Un audit qui permet de reconstruire le parcours de chaque utilisateur détruit l’objectif de séparation décrit par RFC 9576.

La chaîne correcte est :

configurer -> attester -> demander -> admettre -> répondre -> finaliser -> commettre -> sélectionner -> présenter -> autoriser -> observer.

Le lot rend une partie de cette chaîne moins chère. Il n’en supprime aucune frontière.