Résumé

  • RFC 9943 décrit SCITT : un émetteur signe une déclaration sur un artefact, un service de transparence l’enregistre suivant une politique, puis un reçu atteste des propriétés bornées de cet enregistrement.
  • La preuve rend l’historique contrôlable ; elle ne rend pas la déclaration vraie, ne force pas l’émetteur à tout publier et ne remplace pas le jugement local d’une partie utilisatrice.

La force du modèle tient précisément à ce qu’il ne promet pas. Dans SCITT, l’émetteur attache son identité et un sujet à une déclaration protégée. Le Transparency Service, ou TS, vérifie la signature, applique sa politique d’enregistrement, place la déclaration acceptée dans une structure de données vérifiable, puis remet un reçu COSE. Avec ce reçu, la déclaration devient transparente au sens technique : une partie peut contrôler une preuve d’inclusion et des auditeurs peuvent examiner la cohérence de la séquence. C’est une avancée considérable pour rendre visibles les affirmations après coup.

Ce n’est pas une étiquette de qualité collée à l’artefact.

Chaque rôle parle pour une chose différente. L’émetteur répond de l’assertion qu’il a signée. Le TS répond de l’enregistrement, de sa politique annoncée et de la structure dont émane son reçu. L’auditeur répond de sa méthode de contrôle. La partie utilisatrice répond de la décision : accepter un composant, limiter son usage, différer un déploiement ou le refuser. Lorsque l’interface présente le reçu comme une autorisation déjà acquise, elle confond ces quatre voix et rend la responsabilité introuvable.

La procédure d’enregistrement rend cette frontière visible. RFC 9943 impose au TS de vérifier cryptographiquement la signature, de lier l’identité de l’émetteur à l’en-tête protégé, de conserver des ancres de confiance et de maintenir des politiques d’enregistrement explicites. Mais le texte laisse à l’implémentation l’étendue des contrôles supplémentaires — y compris l’absence de contrôle supplémentaire. L’authentification et l’autorisation du client relèvent elles aussi de l’implémentation et sortent du périmètre de l’architecture. Le reçu peut donc prouver qu’une déclaration déterminée a passé une porte déterminée.

Il ne dit pas que toutes les questions importantes ont été posées à cette porte.

Une politique stricte ne change pas ce point. Elle peut exiger une clé connue, un émetteur protégé, un sujet, un type de contenu ou certains attributs. Elle produit une règle d’admission que l’on peut relire et auditer. Elle ne démontre pas qu’une nomenclature de composants est exhaustive, qu’un avis de vulnérabilité est encore actuel, qu’un environnement de construction était sain ou qu’un fournisseur a révélé les informations défavorables. Le TS rend son propre acte vérifiable ; il ne doit pas se faire passer pour l’auteur de la vérité ni pour le décideur final.

RFC 9943 formule même la limite sans ambiguïté : un émetteur peut produire une déclaration fausse, volontairement ou non, et l’enregistrement prouve seulement qu’elle vient de cet émetteur. Une déclaration ultérieure peut la remplacer ; un autre émetteur peut la corriger. Un émetteur peut aussi choisir de ne soumettre qu’une partie de ses déclarations. La transparence améliore la possibilité de détecter et d’attribuer ces comportements. Elle ne convertit pas le silence en divulgation complète.

La séquence du registre exige la même retenue. Une preuve d’inclusion situe une déclaration dans une structure vérifiable. Elle ne signifie pas nécessairement que l’ordre du registre est celui de l’émission, sauf si la politique du TS le promet. Elle ne transforme pas non plus la dernière ligne visible en vérité la plus importante, ni en récit exhaustif de la vie de l’artefact. Une chronologie cryptographique est une preuve sur une structure ; ce n’est pas automatiquement une chronologie de toutes les causes et de tous les effets.

La bonne question est donc graduée. Qu’a exactement affirmé l’émetteur ? Quelle signature et quel sujet ont été vérifiés ? Sous quelle politique le TS a-t-il enregistré cette déclaration ? Quelle clé et quelle identité de reçu la partie utilisatrice accepte-t-elle ? Enfin, quelle règle locale transforme — ou refuse de transformer — cet ensemble d’éléments en décision ? RFC 9943 autorise explicitement une validation arbitraire après la vérification : enveloppe, reçu, charge utile et état local peuvent y entrer. Cette dernière étape n’est pas une faiblesse. C’est l’endroit où doit demeurer la responsabilité.

La note de Heng Lu sur la spécification initiale minimale éclaire ce choix. Un mécanisme commun gagne en portée lorsqu’il rend une proposition limitée vérifiable sans confisquer les décisions futures de ceux qui en supportent le risque. Le reçu SCITT circule parce qu’il parle d’un fait précis sur une déclaration enregistrée. Le transformer implicitement en garantie, en autorisation d’achat ou en feu vert de déploiement reviendrait à importer une politique inconnue dans chaque organisation. L’exécution d’un contrôle prouve qu’un contrôle nommé a été exécuté sur un matériau nommé ; elle ne désigne pas le propriétaire des conséquences.