Résumé

  • Dans un appareil composé de plusieurs fournisseurs, une liste d’Endorsers de confiance ne suffit pas : le Verifier doit relier chacun d’eux au Target Environment sur lequel il peut s’exprimer.
  • Une signature valide de l’éditeur de l’OS peut authentifier sa provenance tout en restant hors mandat si elle décrit le matériel ou le micrologiciel.
  • La révision 11 autorise cette liaison dans la politique d’évaluation, dans l’Evidence ou dans les deux ; le résultat doit donc conserver la règle réellement appliquée.

Un constructeur de matériel, un fournisseur de micrologiciel, un éditeur de système et un développeur d’application peuvent tous connaître une partie utile du même appareil. Le piège commence lorsqu’une plateforme les range dans une seule catégorie : « sources approuvées ».

Cette catégorie répond à une question de provenance. Elle ne répond pas à la question de compétence. Un éditeur peut être parfaitement reconnu pour décrire son système d’exploitation sans recevoir le droit d’affirmer la nature de la racine matérielle. Si cette frontière manque, le contrôle cryptographique peut réussir au moment même où le mandat déborde.

La révision 11 de RATS Endorsements met ce problème au centre de son exemple multi-couches. Application, OS, micrologiciel et matériel constituent des Target Environments distincts. Chacun peut recevoir des affirmations supplémentaires de son propre Endorser. Le texte refuse cependant l’idée qu’un ensemble d’Endorsers de confiance règle toute la question. Le Verifier doit pouvoir distinguer lequel est autorisé à fournir une Endorsement sur quel environnement.

L’exemple décisif est sobre : l’Endorser de l’OS peut être admis pour l’OS, pas pour le matériel. Aucun vol de clé n’est nécessaire. Aucun paquet n’a besoin d’être modifié. Une politique trop large suffit pour transformer une identité authentifiée en autorité transversale.

Le projet ne prescrit pas un registre unique de ces mandats. La liaison peut appartenir à l’Appraisal Policy for Evidence. L’Evidence peut aussi désigner l’Endorser recevable pour une couche. Les deux sources peuvent enfin se combiner. Cette souplesse permet plusieurs architectures, mais interdit de traiter l’Endorsement seul comme dossier complet de la décision.

Deux Verifiers peuvent ainsi recevoir les mêmes octets signés et diverger légitimement : leur carte des couches, leur version de politique ou la liaison portée par l’Evidence n’est pas la même. Pour expliquer le verdict, il faut conserver non seulement le message et sa chaîne de certification, mais aussi la règle de portée qui a ouvert la porte à cette affirmation.

Cette lecture prolonge l’architecture de RFC 9334. L’Endorser fournit des affirmations ; le Verifier Owner gouverne l’évaluation de l’Evidence ; le Relying Party Owner décide ensuite comment agir sur l’Attestation Result. Authentifier la source, évaluer l’état et autoriser une opération ne sont pas trois formulations du même acte.

Il faut également séparer la portée d’une règle conditionnelle. Dans une Endorsement conditionnelle, le test peut déterminer si une affirmation devient applicable. Il ne rend pas l’appareil digne de confiance et ne prouve pas que le signataire avait mandat sur la couche ciblée. Le moteur peut donc exécuter correctement la condition tout en admettant une voix au mauvais étage.

Même la découverte de clé ne répare pas cette lacune. Le projet rappelle qu’un identifiant tel que le UEID de RFC 9711 peut permettre de retrouver une clé de vérification. Il laisse pourtant aux protocoles la granularité de cette clé : instance, classe ou autre périmètre. « Bonne clé » ne signifie ni « bonne couche » ni « toutes les affirmations autorisées ».

Un reçu exploitable doit donc joindre sept éléments : Evidence fraîche ; identité et chemin de validation de l’Endorser ; identifiant du Target Environment ; règle autorisant cet Endorser et cette classe d’affirmations ; version du contenu retenu ; identité du Verifier et de sa politique ; puis décision et effet du Relying Party.

L’historique Datatracker place désormais le document en IESG Evaluation pour la téléconférence du 8 octobre 2026. Le différentiel entre 09 et 11 permet d’identifier les changements. Le texte brut de la révision 11 reste néanmoins un Internet-Draft, non un RFC.

La révision 11 de CoRIM apporte un contexte de modèle concret pour les Endorsements et Reference Values. Elle ne remplace pas la politique locale et ne prouve pas qu’une mise en œuvre a gardé intacte la portée du mandat.

Sources