Résumé

  • Dans draft-ietf-suit-update-management-16, les extensions de gestion restent facultatives et leur prise en charge par un destinataire est une connaissance propre au déploiement, éventuellement obtenue hors bande.
  • Le texte de version destiné à l’humain n’est pas exécutable. Capacité, décision machine, autorisation, attente, installation, activation et état en cours d’exécution exigent des preuves distinctes.

La question que la signature ne peut pas trancher

Une signature répond à une question forte : l’enveloppe reçue est-elle celle qu’un auteur autorisé a produite, sans altération détectable ? Elle ne répond pas à une question différente : le code présent sur ce destinataire sait-il exécuter les commandes optionnelles contenues dans l’enveloppe ?

La seizième révision du projet SUIT place cette séparation au centre de l’exploitation. Les extensions qu’elle définit sont facultatives à implémenter et facultatives à inclure dans un manifeste. La connaissance de leur prise en charge dépend du déploiement et peut être établie hors bande. Un manifeste parfaitement valide peut donc arriver avant la preuve de capacité qui lui donne une trajectoire exécutable.

Le piège est administratif autant que technique. La compatibilité peut vivre dans une fiche fournisseur, un inventaire de parc, une option de compilation ou une convention entre l’auteur du manifeste et l’opérateur. Ces documents peuvent être exacts à leur échelle tout en étant faux pour une unité, un chargeur d’amorçage ou une version logicielle donnée. L’affirmation « cette gamme prend en charge SUIT » perd sa valeur si elle ne nomme ni le sous-ensemble visé, ni la version, ni la date de vérification.

Le projet appelle profil de déploiement la spécification ou l’accord qui fixe les options et les correspondances locales. Ce profil n’est pas un nouvel objet du format sur le fil. Il peut donc être indispensable sans voyager avec le manifeste. La gouvernance commence au moment où l’on cesse de le traiter comme un décor.

Une suppression de texte qui déplace la responsabilité

La comparaison avec la révision 15 éclaire le changement. Le texte précédent imposait le rejet d’un manifeste lorsqu’une commande ou un paramètre n’était pas implémenté. Il demandait aussi à l’auteur, lorsqu’il dépendait de ces mécanismes, de vérifier que les destinataires ciblés annonçaient leur prise en charge.

La révision 16 remplace ce passage par la formule plus ouverte sur la connaissance propre au déploiement et éventuellement hors bande. Il ne faut pas transformer cette différence documentaire en affirmation sur un produit réel. Elle signifie cependant qu’un audit ne peut plus se contenter de rechercher une annonce de capacité dans l’échange. Il doit conserver la source externe qui a autorisé la supposition.

Une preuve de capacité exploitable indique l’acteur qui l’a émise, le modèle et la version auxquels elle s’applique, la population couverte, la méthode de vérification et sa fraîcheur. Elle devrait également pouvoir expirer. Sans ces coordonnées, l’information hors bande devient un pouvoir invisible : elle fait passer ou bloque une mise à jour sans laisser de trace dans l’objet signé.

Deux versions, deux autorités

Le projet distingue soigneusement la version calculable de la version racontée.

suit-set-version porte une représentation lisible par la machine lorsque le numéro de version peut être exprimé sans perte dans le format contraint. suit-parameter-version associe une comparaison à la version d’un composant. Ces valeurs servent aux décisions du processeur. Les métadonnées de build, ignorées dans l’ordre de précédence sémantique, n’y ont pas leur place.

suit-text-current-version et suit-text-version-required s’adressent aux personnes. Le second peut même ressembler à une expression de comparaison. Cette ressemblance ne lui confère aucune autorité. Le processeur ne doit ni interpréter ni traiter ces champs. En cas de divergence, les valeurs machine prévalent.

Le chapitre de sécurité les qualifie en outre d’entrées non fiables. Elles ne doivent pas être évaluées, leur balisage ne doit pas être exécuté et elles ne doivent jamais remplacer une décision issue de suit-set-version ou suit-parameter-version. L’interface qui les affiche doit se protéger contre l’injection dans l’écran, le journal ou les codes de contrôle.

Une console peut donc dire vrai tout en induisant en erreur. Elle peut afficher correctement « version actuelle » ou « version requise », puis colorer la ligne en vert comme si la condition machine avait été évaluée. Le bon reçu conserve le texte pour l’opérateur, mais enregistre séparément le champ machine, le composant observé, la source de sa version et le résultat de la comparaison.

La priorité appelle une décision, elle ne la remplace pas

Le paramètre de priorité classe les mises à jour : une valeur numérique plus petite correspond à une priorité plus forte. La signification concrète reste locale. Une politique peut réserver les valeurs négatives aux corrections critiques et les valeurs positives aux fonctions ordinaires, mais cette convention appartient au déploiement.

La condition d’autorisation transmet cette priorité à l’application et échoue si l’autorisation n’est pas donnée. « Critique » n’est donc pas un droit d’installer. C’est un argument soumis à un décideur local.

Le journal doit distinguer la valeur reçue, la version de politique qui l’a interprétée, l’acteur ou le composant décisionnaire, sa réponse et l’heure. Faute de quoi, l’organisation confond l’urgence déclarée par l’auteur avec le consentement du système qui porte le risque opérationnel.

Attendre n’est pas réussir plus lentement

Le mécanisme d’attente transforme une mise à jour en machine d’états. Il peut attendre une autorisation, une alimentation externe, un réseau, la version d’un autre appareil, une date, une heure locale ou un jour de semaine. Tous les événements déclarés doivent être satisfaits avant la reprise.

La manière d’attendre reste cependant propre à l’implémentation. Blocage sur sémaphore, suspension avec gestionnaire d’événement, interrogation périodique ou abandon suivi d’un redémarrage sont tous possibles. Ces stratégies n’ont pas le même comportement face à une panne, un redémarrage ou une batterie faible.

Certaines conditions n’existent même pas sans contexte local. Une attente en heure locale exige un fuseau et des règles de changement d’heure ; à défaut, elle est non prise en charge. L’attente de la version d’un autre appareil exige un espace de noms pour son identifiant, une portée d’unicité, une source de version et un encodage définis dans le profil. Le même octet peut être précis et inutilisable.

Le projet recommande donc que les interfaces de gestion exposent les extensions prises en charge et la raison pour laquelle une mise à jour attend ou a échoué. La politique doit dire si l’attente survit à un redémarrage, comment l’annuler et quel délai local s’applique.

Un simple compteur « en attente » ne permet pas de distinguer l’absence de capacité, une correspondance locale manquante, une condition légitimement non satisfaite, une reprise défaillante ou un échec ultérieur. Le reçu utile nomme l’état, l’événement manquant, sa source, la dernière évaluation et la transition autorisée suivante.

Un CoSWID n’est pas un témoin de démarrage

Le champ suit-coswid peut relier la mise à jour à l’inventaire, au SBOM et à l’attestation. Il peut être séparable : un intermédiaire ou un destinataire qui n’en a pas besoin peut alors le retirer sans casser la signature du manifeste. Même dans sa forme non séparable, sa présence ne signifie pas que tous les destinataires analysent ses détails.

Cette flexibilité a deux conséquences. D’abord, l’identifiant logiciel dit ce que l’infrastructure devrait attendre ; il ne démontre pas ce qu’un appareil a installé ou exécute. Ensuite, les détails de composant et de version peuvent aider un attaquant. L’accès à ces métadonnées fait donc partie du modèle de contrôle.

La chaîne probante doit poursuivre son chemin après le manifeste : téléchargement, écriture, installation, activation, redémarrage éventuel, mesure du composant actif, rapprochement avec l’inventaire, puis effet applicatif. Une étape ne peut pas signer à la place de la suivante.

Ce qu’il faut conserver

Un registre défendable relie sans les fusionner : l’état exact du document IETF et des registres ; l’enveloppe signée ; le destinataire ciblé ; la provenance et l’âge de sa capacité ; le profil de déploiement ; les champs machine et leurs sources ; chaque résultat de condition ; l’entrée et la sortie d’attente ; l’installation ; l’activation ; enfin l’état observé.

La révision 16 avait reçu l’annonce d’approbation dans Datatracker au moment du gel, mais demeurait un Internet-Draft et les actions IANA restaient en cours. L’approbation institutionnelle n’est ni le numéro RFC final, ni une mesure d’adoption, ni une preuve d’exécution.

Le progrès consiste ici à réduire la portée de chaque assertion. Le manifeste peut être authentique sans être compatible. Le texte peut être exact sans gouverner la machine. L’attente peut être légitime sans être une réussite. L’installation peut être achevée sans que le nouveau composant tourne. C’est la précision des frontières, et non la force d’un seul artefact, qui rend une mise à jour gouvernable.

Sources