Résumé

  • RFC 9943 permet d’établir qu’un service de transparence a enregistré une déclaration signée selon une politique donnée et a produit un reçu vérifiable. Ce fait ne constitue ni une certification du logiciel ni une autorisation de le livrer.
  • Le choix de faire confiance à un émetteur, d’interpréter une preuve, d’appliquer une règle locale et d’assumer une exception reste à la charge de la partie qui peut arrêter, corriger ou retirer le déploiement.

Le registre ajoute une preuve, il ne déplace pas la responsabilité

Le vocabulaire de la transparence peut rapidement donner une illusion de clôture. Un artefact dispose d’une déclaration signée, celle-ci a été enregistrée, un reçu est vérifiable : l’affaire paraît réglée. RFC 9943, publié en juin 2026 comme RFC IETF sur la voie Standards Track, est plus précis. Il décrit le moyen de rendre transparentes des déclarations signées portant sur des artefacts de chaîne logistique. Il ne confie pas au service de transparence le pouvoir de décider qu’un logiciel peut entrer en production.

Dans cette architecture, un émetteur produit une déclaration concernant un artefact : une nomenclature de composants, un avis de fin de vie, une attestation, un avis de sécurité ou une autre information sérialisable. Un Transparency Service, ou TS, peut l’enregistrer. L’enregistrement applique la politique d’enregistrement du service, ajoute la déclaration à une structure de données vérifiable et produit un reçu. Le reçu sert notamment à démontrer une propriété de cette structure, par exemple l’inclusion de la déclaration.

Cette propriété est précieuse. Elle aide un auditeur à examiner une histoire append-only plutôt qu’une page modifiable. Elle peut permettre de comparer des reçus, de vérifier la cohérence d’une séquence ou de retrouver les déclarations associées à un émetteur. Mais une preuve d’inclusion n’est pas une appréciation de sécurité, un ordre d’achat, une décision juridique, une acceptation de risque, ni une autorisation d’exploitation. Un registre rend une assertion observable; il ne porte pas la perte causée par un mauvais choix opérationnel.

Quatre faits différents, quatre autorités différentes

Le premier fait est cryptographique : un émetteur a signé une déclaration. La signature peut lier une clé, un contenu et des métadonnées. Elle ne prouve pas, à elle seule, que cet émetteur est celui que le lecteur devait croire, qu’il disposait d’un mandat pour cette catégorie d’affirmation ou que son contenu est exact.

Le deuxième fait concerne le TS : ce service a accepté la déclaration selon sa propre Registration Policy, l’a placée dans sa structure de données et a délivré un reçu. La politique est une condition préalable fondée sur les métadonnées et l’en-tête non opaque de l’enveloppe. Elle peut être rigoureuse ou volontairement limitée. Le résultat dit donc quelles vérifications ce service a appliquées à ce moment-là; il ne dit pas que toutes les vérifications pertinentes pour chaque client ont été accomplies.

Le troisième fait appartient à la relying party. RFC 9943 lui demande de faire confiance à la clé ou au certificat et à l’identité associée d’au moins un émetteur de reçu. Elle peut juger qu’un seul reçu suffit et appliquer ensuite des politiques de validation arbitraires. Autrement dit, le reçu n’embarque pas une règle universelle d’acceptation. Une personne ou une institution doit encore choisir les clés, les profils, la fraîcheur, les émetteurs et les circonstances qui comptent.

Le quatrième fait est la décision opérationnelle. Une équipe de mise en production peut autoriser un binaire. Une équipe de sécurité peut le bloquer. Un acheteur peut l’accepter dans un périmètre contractuel précis. Un opérateur peut conserver une version déjà exécutée tout en refusant la suivante. Ces actes n’ont ni le même mandat ni le même dommage possible. Aucun ne découle mécaniquement de la bonne forme d’un reçu.

Les quatre faits peuvent se succéder sans se confondre. Une déclaration peut être enregistrée alors qu’un client refuse son émetteur. Un reçu peut être valablement contrôlé tandis qu’une règle locale impose une attente à cause d’une incompatibilité, d’un risque connu ou d’une exception expirée. Un déploiement d’urgence peut même nécessiter une régularisation documentaire ultérieure; ce n’est pas une permission de négliger la preuve, mais la raison de documenter séparément l’exception et sa révision.

Une politique possède une version et une date

Le texte de RFC 9943 empêche une confusion supplémentaire. L’opérateur d’un TS peut modifier sa politique d’enregistrement ou ses ancres de confiance. Le même opérateur doit toutefois laisser aux auditeurs assez de matière pour reproduire les contrôles définis par la politique au moment exact de l’enregistrement. La question utile n’est donc pas seulement « la signature du reçu est-elle valide ? ». Il faut aussi demander : quelle politique, quelle clé, quel service, quelle déclaration et quelle date ont produit ce résultat ?

Un changement de politique peut être nécessaire. Une règle peut devoir se durcir, une clé être remplacée, un profil évoluer. Il ne faut simplement pas laisser la politique actuelle réécrire la signification d’un ancien enregistrement, ni laisser un ancien reçu devenir silencieusement la politique actuelle de mise en production d’une entreprise.

La séquence elle-même demande la même modestie. Une structure append-only ordonne les déclarations enregistrées. RFC 9943 précise qu’en l’absence d’annonce dans la politique, le lecteur ne peut pas supposer que cet ordre correspond à l’ordre d’émission. Une position dans le registre ne démontre donc pas que l’avis a précédé le correctif, que l’équipe a vu une information avant son choix, ou qu’une décision s’est produite dans la même fenêtre temporelle. Ces liens exigent d’autres horodatages et d’autres dépositaires.

La transparence ne tranche pas non plus le vrai et le faux. Le RFC indique qu’un émetteur peut faire une déclaration erronée, volontairement ou non; une déclaration peut être remplacée et plusieurs émetteurs peuvent produire des versions contradictoires au sujet du même artefact. L’architecture rend le désaccord inspectable. Elle ne nomme pas un arbitre universel de l’exactitude.

Le document qui manque est souvent celui de la décision

Dans une organisation, les éléments techniques sont fréquemment conservés : empreinte de l’artefact, attestation, reçu, identifiant de politique. Le moment qui compte le plus finit dans une conversation, un bouton d’interface ou une dérogation d’urgence sans propriétaire lisible. Lorsque le logiciel devient problématique, on peut alors prouver que quelque chose a été enregistré sans pouvoir expliquer pourquoi quelqu’un l’a laissé passer.

Un reçu de décision de mise en production, distinct de SCITT, résout ce manque sans publier la totalité des informations sensibles. Il peut relier la version immuable de l’artefact, la déclaration et son émetteur, le TS, la politique et l’instant d’enregistrement, le contrôle du reçu et sa date de relecture, la règle locale ou l’exception appliquée, l’autorité qui a décidé, le résultat — autoriser, retenir, refuser —, l’échéance de réexamen et la voie de correction ou de retour arrière.

Ce reçu décisionnel n’est pas prescrit par RFC 9943. C’est précisément son intérêt : il n’attribue pas à la norme un pouvoir qu’elle ne revendique pas. Des détails de test, des identités de clients ou des informations exploitables peuvent rester protégés. L’auditeur habilité doit néanmoins pouvoir retrouver qui a utilisé quelle preuve pour prendre quelle décision et comment celle-ci peut être revue.

L’automatisation ne supprime pas cette exigence. Une chaîne CI peut vérifier automatiquement un reçu et appliquer une règle préétablie. Le dossier doit encore nommer la version de cette règle, l’autorité qui l’a adoptée, les entrées qu’elle a évaluées et le résultat qu’elle a produit. Dire « le registre l’a permis » masque le fait réel : une règle humaine ou institutionnelle avait été choisie auparavant.

Une norme de preuve, pas un gouvernement du déploiement

RFC 9943 laisse explicitement hors champ la manière de gérer et stocker les déclarations, ainsi que la découverte et la notification des changements entre participants. Cette retenue est utile. Un producteur, une administration, un hôpital, un intégrateur et un projet bénévole peuvent vérifier le même reçu sans partager le même mandat de risque.

Le problème commence lorsqu’une propriété technique sert de raccourci institutionnel. Une entreprise d’achat peut prétendre qu’une déclaration enregistrée achève sa diligence. Une équipe de livraison peut confondre une inclusion avec l’accord d’un responsable de risque. Un opérateur peut laisser croire qu’une signature d’émetteur maintient à elle seule l’adéquation d’un composant après l’apparition d’une vulnérabilité. Dans chaque cas, un fait exact mais limité absorbe une décision que personne n’a explicitement assumée.

La séquence plus solide est simple à dire et exigeante à pratiquer : vérifier la preuve pour la propriété qu’elle établit, conserver la politique et l’instant qui la rendent interprétable, puis inscrire l’autorité qui a décidé de l’usage de cette preuve. Elle permet de distinguer une défaillance cryptographique d’une défaillance de gouvernance au lieu de les mêler.

Sources

  1. RFC 9943 : An Architecture for Trustworthy and Transparent Digital Supply Chains
  2. IETF Datatracker : RFC 9943
  3. RFC 9942 : CBOR Object Signing and Encryption (COSE) Receipts
  4. RFC 9162 : Certificate Transparency Version 2.0
  5. RFC 9052 : CBOR Object Signing and Encryption (COSE): Structures and Process