Résumé

  • draft-ietf-opsawg-yang-provenance-07 protège par COSE un contenu YANG canonisé et permet des contresignatures, mais celles-ci restent liées au même contenu d’origine et ne certifient pas automatiquement une sortie transformée.
  • La vérification doit distinguer le périmètre signé, la résolution locale de la clé, les signataires exigés, les étapes absentes, la fraîcheur, l’analyse, l’autorisation, l’exécution et l’effet observé.

Le message broker reçut une notification YANG signée par l’équipement. Il vérifia la signature, convertit les unités, arrondit les valeurs, supprima trois champs puis ajouta sa contresignature. Le tableau de bord afficha deux signataires et conclut que les données normalisées possédaient une chaîne complète.

La conclusion était fausse. La contresignature portait sur l’objet COSE existant, donc sur le contenu canonisé initial. La nouvelle table n’avait jamais été signée.

La révision 07 de Applying COSE Signatures for YANG Data Provenance, publiée le 6 juillet 2026 et valable jusqu’au 7 janvier 2027, est un Internet-Draft actif du groupe OPSAWG. Son en-tête vise le Standards Track. Ce n’est ni une RFC, ni une attribution IANA achevée, ni un rapport d’interopérabilité, de déploiement ou de certification. Le Datatracker signalait quatre erreurs YANG et aucun avertissement le 25 août 2026. Le projet mentionne une implémentation Java et des démonstrations de hackathon ; ces faits n’attestent pas un usage de production.

Le domaine cryptographique doit être nommé

Le mécanisme construit un objet COSE_Sign1 sans charge utile incorporée. Le contenu YANG exact devient donnée externe après canonisation. L’algorithme, le kid et la méthode de sérialisation sont protégés ; les paramètres propres à l’algorithme suivent les conventions COSE.

Le choix de sérialisation n’est pas décoratif. CBOR utilise l’encodage déterministe « length-first », JSON le JCS et XML la canonisation XML exclusive. Une signature correcte affirme qu’un ensemble précis d’octets canonisés correspond à la clé vérifiée. Elle ne s’étend pas aux champs exclus, à une autre représentation ni à une interprétation métier apparue ensuite.

Le journal de preuve doit conserver le nœud ou l’instance couverte, la sérialisation, le profil de canonisation, le hachage, l’algorithme et l’identité de la clé résolue. Un simple booléen ne permet pas de rejouer l’analyse.

La contresignature n’est pas un reçu de conversion

RFC 9338 permet à des entités supplémentaires de contresigner l’objet COSE. Le projet précise que cette opération ne modifie ni la signature primaire ni son entrée canonisée. Elle lie le nouveau signataire au même objet signé.

Cette propriété est précieuse pour établir qu’un courtier, un contrôleur ou un domaine a vu et endossé un objet. Elle devient trompeuse si l’interface l’appelle « signature de la sortie ». Lorsqu’un intermédiaire transforme les données, deux objets existent : l’entrée et la sortie. Pour prouver la relation, il faut un reçu indiquant leurs hachages, la version du transformateur, ses paramètres et le temps d’exécution, puis une signature sur ce reçu ou sur la sortie.

Empiler les contresignatures ne remplit pas ce vide. Cela multiplie les acteurs cryptographiquement liés à l’original sans raconter ce qui s’est passé entre les représentations.

La politique du vérificateur change le sens de « valide »

Le texte autorise la vérification de la signature primaire, d’une partie des contresignatures ou de toutes, selon la politique locale. Un produit peut donc dire « provenance vérifiée » après avoir contrôlé un seul signataire, tandis qu’un autre exige la chaîne complète attendue.

Le résultat doit indiquer la politique et son édition, les signataires obligatoires, ceux réellement vérifiés, les clés utilisées, les échecs et les omissions tolérées. Sans cette liste, deux voyants verts peuvent représenter des assurances incompatibles.

Le kid renforce ce caractère local. Son association à une clé publique est laissée au déploiement. Une signature peut être mathématiquement correcte alors que l’annuaire associe le kid au mauvais contrôleur, à un ancien domaine ou à une clé compromise non révoquée.

Une étape absente ne se dénonce pas elle-même

Le projet reconnaît que la piste de provenance n’est complète qu’à hauteur des signatures présentes. Son mécanisme ne garantit pas la continuité et ne détecte pas seul qu’un intermédiaire n’a pas signé.

Il faut donc un modèle externe du chemin attendu. La chaîne opérationnelle doit dire qu’une donnée part de l’équipement, passe par un courtier, une normalisation, un moteur analytique et une validation humaine ou politique avant le contrôleur. Une signature prouve l’intégrité d’un maillon fourni ; la comparaison avec ce graphe révèle le maillon manquant.

Cette distinction évite une erreur institutionnelle classique : prendre la liste des participants visibles pour le mandat complet du système. La présence cryptographique est une preuve. Elle ne crée ni les acteurs absents ni l’autorité qu’ils devaient exercer.

L’ancien objet reste parfaitement signé

La fraîcheur se situe hors du mécanisme de base. Une configuration signée hier peut être rejouée aujourd’hui avec une signature intacte. Un horodatage, un nonce, une durée de validité ou un identifiant de demande doit être lié au contexte pour réduire ce risque.

Même l’heure ne suffit pas si la source de temps et la fenêtre d’acceptation ne sont pas gouvernées. Il faut confronter l’objet aux révocations de clés, aux changements de politique, aux gels opérationnels et à l’état courant de l’autorité.

Le projet exclut également la correction intrinsèque des données. Le détenteur légitime d’une clé peut signer une mesure erronée ou malveillante. Une clé compromise peut produire une signature valide. La cryptographie détecte la modification après signature ; elle ne remonte pas dans le capteur pour vérifier la réalité.

Vérifier avant traitement ne suffit pas après traitement

La signature doit être la dernière action avant mise à disposition, et la vérification devrait précéder le traitement par l’application. Cette règle ferme une fenêtre importante. Elle ne donne pas au traitement suivant la provenance de son entrée.

Une validation de schéma ajoute une autre propriété : conformité structurelle. Un modèle d’IA ajoute une inférence. Un moteur de règles ajoute une décision. Un contrôleur ajoute une tentative d’exécution. Chacune de ces couches doit identifier ses entrées et signer son propre résultat si l’on veut conserver une piste rejouable.

L’autorisation demeure distincte. Une signature d’équipement ne mandate pas automatiquement un changement de réseau. Le principal responsable—opérateur, propriétaire du service ou règle d’automatisation explicitement déléguée—doit fournir une décision actuelle et limitée.

Le résultat vit hors de l’enveloppe

Le contrôleur peut accepter une commande sans que tous les appareils l’appliquent. Une configuration peut apparaître dans le datastore sans modifier le forwarding. Un acquittement peut précéder une dégradation de service.

La chaîne complète doit donc relier objet source, transformations, analyse, autorisation, commande, état lu sur l’équipement et observation indépendante du service. Les quatre modes d’inclusion proposés—feuille, notification YANG-Push, métadonnée d’instance et annotation—facilitent le transport de la preuve. Ils ne transforment pas son transport en verdict.

La promesse utile reste forte parce qu’elle demeure bornée : ce contenu canonisé n’a pas changé depuis sa signature par le détenteur de cette clé. Le reste—continuité, vérité, mandat et résultat—doit garder son propre propriétaire.

Sources