Résumé

  • Le projet CoSERV du groupe RATS permet au destinataire qui ne satisfait pas toute une requête RIM-ID de ne rendre qu’un sous-ensemble ; dans le cas limite, un résultat vide demeure valide.
  • Encodage déterministe, liaison à la requête, signature et expiration protègent l’échange rendu, mais n’attestent ni la complétude du fonds interrogé ni la justesse de la décision locale.
  • Une quittance de récupération doit conserver séparément la portée demandée, la génération du jeu de données, les éléments rendus et omis, leur provenance, le chemin de cache, les vérifications et l’action décidée.

Le piège du résultat vert

Dans une chaîne d’attestation, un témoin cryptographique n’est jamais toute l’histoire. L’attesteur fournit des preuves, le vérificateur les apprécie et la partie utilisatrice décide d’accorder ou de refuser une capacité. La RFC 9334 rend cette séparation explicite afin qu’un résultat d’attestation ne se transforme pas, par glissement de vocabulaire, en certificat universel de confiance.

La récupération des valeurs de référence et des endossements mérite la même précision. Le projet de groupe de travail Concise Selector for Endorsements and Reference Values, dit CoSERV, organise des requêtes compactes destinées à obtenir les matériaux utiles à l’appréciation. La révision 07 est un Internet-Draft actif du groupe RATS. Elle n’est ni une RFC ni une décision finale de l’IETF.

La construction est exigeante sur ce qu’elle promet. La requête repose sur un CBOR déterministe. Dans la liaison HTTP, les octets stables se prêtent à une URL GET et à une clé de cache stables. La réponse signée est liée à la requête : substituer l’objet d’une autre requête doit faire échouer la vérification. Un résultat possède une expiration obligatoire, ne peut dépasser la validité du matériau RIM qu’il contient et écarte les RIM invalides.

Ces garanties répondent à quatre questions essentielles : l’objet vient-il du signataire annoncé ? Ses octets ont-ils été modifiés ? Correspond-il à la requête précise ? Est-il encore dans le temps déclaré ? Une cinquième question ne s’y trouve pas : le fournisseur détenait-il et a-t-il rendu tous les objets applicables ?

Cette cinquième question n’est pas « plus de cryptographie ». C’est une affirmation sur une population. Pour la prouver, il faut définir cette population, connaître l’état de la collection, observer les exclusions et relier l’ensemble à la décision. Une signature ne peut pas rendre visible un objet que la collecte n’a jamais reçu.

Un ensemble vide peut être une réponse conforme

La phrase décisive du texte de la révision 07 concerne les requêtes RIM-ID. Si le destinataire n’est pas en mesure de satisfaire toute la requête, il peut ne retourner qu’un sous-ensemble. Au pire, l’ensemble vide est encore un résultat valide.

Le choix est raisonnable. Une collection partielle ne doit pas inventer des valeurs ni produire une réponse mal formée pour dissimuler qu’elle ne sait pas. La difficulté commence lorsque l’exploitation convertit « valide » en « complet ». Un résultat vide peut dire honnêtement que ce destinataire a renvoyé zéro élément selon les règles de l’échange. Il ne dit pas qu’aucun endossement pertinent n’existe, qu’aucune source amont ne le possède ou qu’un autre demandeur autorisé recevrait la même réponse.

Prenons cinq clés demandées et trois clés rendues. Les trois artefacts peuvent être authentiques, récents et exactement liés à la requête. Pour les deux absences, plusieurs mondes restent compatibles avec la même réussite cryptographique : le fournisseur ne les a jamais collectés ; ils sont présents mais interdits à ce demandeur ; le sélecteur ne les fait pas correspondre ; une ingestion est en retard ; le format n’est pas pris en charge ; une panne d’index les masque. La signature protège les trois présences, pas l’explication des deux absences.

La notion de dernière révision doit elle aussi rester bornée. Lorsque les étiquettes emploient un compteur entier, le compteur le plus élevé désigne la dernière révision pertinente. C’est un ordre cohérent parmi les données disponibles. Si la source amont a déjà publié une révision que la collection n’a pas encore vue, le maximum local reste correctement calculé et néanmoins dépassé.

Le sélecteur est une décision de portée

CoSERV prévoit qu’une requête d’environnement choisisse une seule nature : instance, groupe ou classe. Une sélection d’instance ou de groupe ne se combine pas avec une sélection de classe dans la même requête. Plusieurs sélecteurs d’une même nature fonctionnent comme des alternatives. Dans un sélecteur de classe, les champs renseignés doivent correspondre ensemble, tandis que les champs absents servent de jokers. Des mesures d’environnement avec état peuvent encore resserrer la correspondance.

Cette grammaire rend la demande reproductible, mais elle ne rend pas sa portée naturelle ou inévitable. Une personne ou une politique a choisi l’instance plutôt que la classe, rempli certains champs et laissé les autres ouverts. Un champ trop précis peut retirer du champ les références utiles ; un joker trop large peut attirer un jeu de résultats mal adapté ou exposer une population sensible.

Il faut donc conserver non seulement les octets ou leur empreinte, mais aussi la raison du choix. Quelle décision le sélecteur devait-il éclairer ? Qui en a approuvé la portée ? Quelle alternative avait été écartée ? Sans cela, « aucun résultat » peut devenir une formule commode pour « nous n’avons regardé que là où nous savions ne rien trouver ».

La confidentialité impose toutefois une retenue. Le projet souligne qu’un sélecteur d’instance peut être sensible. Une piste d’audit ne devrait pas publier des identifiants de dispositifs au nom de la transparence. Les octets exacts peuvent rester dans un coffre probatoire à accès contrôlé, tandis que le journal courant conserve une empreinte protégée, la nature du sélecteur et l’autorité qui l’a approuvé.

La provenance du fonds ne tient pas dans l’enveloppe

Un service peut remettre des artefacts de source et des artefacts collectés ou agrégés. Une enveloppe signée prouve qui l’a formée et qu’elle n’a pas changé. Elle ne prouve pas que le collecteur a consulté toutes les sources, achevé toutes les importations, pris en charge tous les formats ou rendu tout ce que sa politique d’accès autorisait.

La métaphore de l’archive est utile : le scellé d’un dossier peut être irréprochable alors qu’un tiroir manque dans le dépôt. Vérifier le scellé ne reconstitue pas le tiroir.

Il faut aussi empêcher une confiance « profonde » de naître d’une vérification seulement « superficielle ». La partie utilisatrice peut vérifier l’enveloppe CoSERV, puis le CoRIM inclus, puis l’autorité d’un endossement, avant de décider si les affirmations s’appliquent aux preuves observées. Ces étapes ne sont pas interchangeables. L’autorité du conditionneur n’est pas forcément celle de chaque émetteur amont, et aucune des deux ne prend la décision métier à la place de la partie utilisatrice.

L’expiration apporte un autre axe, pas une réponse à la couverture. Elle limite la durée pendant laquelle le résultat peut circuler comme actuel. Une réponse émise il y a une minute peut pourtant provenir d’une collection incomplète. La fraîcheur mesure un temps ; l’exhaustivité mesure un périmètre.

Le cache ajoute une horloge

Grâce à l’encodage déterministe, une même requête peut devenir une clé de cache stable. C’est utile : les objets signés peuvent être réutilisés, les calculs évités, la disponibilité améliorée. Mais le cache introduit une date intermédiaire entre l’état du fournisseur et la décision de la partie utilisatrice.

Un cache peut servir correctement, plusieurs fois, un résultat partiel encore valide. Il n’a pas trahi le protocole. L’échec de gouvernance survient si le journal final ne garde que « signature valide ». Il devient alors impossible de retrouver quel cache a répondu, à quel moment il avait obtenu l’objet, quelles directives de fraîcheur s’appliquaient et si le jeu de données du fournisseur avait changé entre-temps.

Dans sa revue HTTPDIR précoce du 15 août 2026, Lucas Pardue a conclu « Not Ready » et soulevé des questions relatives au cache, à la confidentialité, à HEAD, à la taille des requêtes, aux validateurs et à la fraîcheur. Il s’agit de l’avis d’un réviseur, non d’un consensus du groupe. L’argument sur l’exhaustivité vient du texte normatif autorisant sous-ensembles et résultat vide ; la revue montre seulement combien le trajet HTTP peut compliquer l’histoire d’une réponse pourtant correcte.

Une quittance de récupération à côté du protocole

Il serait excessif de demander au résultat CoSERV de devenir une preuve universelle d’exhaustivité. Une solution plus honnête consiste à garder un objet d’exploitation distinct. Cette quittance devrait relier :

  • les octets déterministes de la requête, ou leur empreinte protégée avec accès à l’original ;
  • le profil, le type de résultat et la sémantique des sélecteurs ;
  • les clés RIM ou branches demandées ;
  • l’identité du fournisseur, la génération du jeu consulté et sa déclaration de couverture ;
  • les clés et artefacts rendus ;
  • les omissions connues et leurs motifs—indisponible, non autorisé, sans correspondance, invalide, non pris en charge ou erreur de récupération ;
  • la distinction entre source et objet collecté, avec la chaîne de provenance ;
  • les périodes de validité, l’expiration, l’heure de récupération et le chemin de cache ;
  • les résultats de vérification ;
  • l’appréciation locale, l’action et le déclencheur d’une nouvelle requête.

Il faut résister à la tentation de calculer un nouveau voyant unique. La couverture déclarée reste une affirmation du fournisseur. Une raison d’omission signée prouve que le fournisseur l’a énoncée, non qu’elle est vraie. La décision de la partie utilisatrice constitue une troisième réalité.

Un dossier intelligible peut alors dire : trois clés sur cinq ont été rendues ; une quatrième était soumise à autorisation, la cinquième indisponible dans cette génération ; les trois objets ont été validés ; l’application a limité les capacités et prévu une nouvelle requête après mise à jour du fonds. Cette chaîne est plus longue qu’un statut « OK », mais c’est enfin une chaîne de responsabilité.

Sources