Résumé

  • La révision 01 du document SEAT distingue la liaison au canal, la fraîcheur de la preuve, l’authentification composée, l’attestation en cours d’exécution et la dérive d’état des connexions longues ou reprises.
  • Une connexion TLS ou DTLS peut rester cryptographiquement valide après une modification de l’environnement attesté. Le handshake prouve un état borné dans le temps, pas une autorisation perpétuelle.

À 9 heures, un serveur établit une connexion TLS et présente une preuve d’attestation fraîche, liée au transcript de cette connexion. Le vérificateur accepte le firmware, le système, le workload et la configuration de sécurité. Le service remet alors un secret. À 14 heures, les enregistrements TLS sont toujours authentiques, mais le workload a chargé un module, l’agent IA a reçu un nouvel outil ou la plateforme a migré.

Le transport n’a pas échoué. Pourtant, la raison initiale d’autoriser peut ne plus être vraie.

C’est la frontière temporelle mise en évidence par draft-ietf-seat-use-cases-01, mis à jour le 15 septembre 2026 et expirant le 19 mars 2027. Il s’agit d’un Internet-Draft du groupe SEAT, au statut I-D Exists. La page de garde vise Informational, tandis que Datatracker ne renseigne aucun Intended RFC status. Aucun shepherd, area director responsable ou telechat n’est enregistré. Le texte ne demande aucune action IANA. Il décrit le « pourquoi » et le « quoi » destinés à guider une future solution ; il ne définit ni le protocole, ni la politique d’évaluation, ni une implémentation ou un déploiement.

Identité du canal et état de la machine

TLS et DTLS authentifient normalement un pair par sa clé et son identité réseau. L’attestation distante ajoute des preuves concernant le Target Environment : matériel, firmware, logiciel et paramètres de sécurité. La partie utilisatrice peut donc distinguer l’identité de celui qui tient la connexion de l’acceptabilité de l’environnement qui l’exécute.

Ces preuves ne se remplacent pas. Un certificat valide ne prouve pas que la clé reste non exportable ou que le secure boot est actif. Une preuve valide produite par une plateforme ne montre pas, à elle seule, que cette plateforme tient le canal sur lequel la preuve est présentée.

La révision 01 demande donc une liaison cryptographique entre Evidence ou Attestation Result et la connexion précise. Elle vise le relais d’une preuve authentique mais sans rapport, provenant d’une autre machine ou d’un autre contexte. Le texte sépare aussi authentification composée, identifiant de machine, interaction avec l’authentification du pair et fraîcheur des credentials d’attestation. Un voyant vert ne couvre pas automatiquement ces dimensions.

La fraîcheur du handshake ne suspend pas le temps

Une preuve fraîche empêche qu’un ancien état acceptable soit simplement rejoué. Une liaison au canal empêche son transfert vers une connexion étrangère. Ensemble, elles montrent qu’une assertion suffisamment récente, selon une règle donnée, appartient à un contexte de connexion donné.

Elles ne garantissent pas la stabilité ultérieure. Le projet nomme expressément la dérive d’état sur les connexions longues et reprises. Il traite aussi l’attestation runtime et oppose les modèles périodique et à la demande. Cette séparation est essentielle : une assertion peut être parfaitement authentique et devenir obsolète.

Un agent IA illustre le problème. Son binaire peut rester identique alors que modèle, prompt, outils ou autorisations changent. Une charge confidentielle peut migrer. Une référence d’évaluation peut être révoquée. Une mesure de protection de clé peut être désactivée. Aucun de ces changements ne doit nécessairement casser le record layer TLS.

La revendication défendable est limitée : un environnement a produit une preuve évaluée sous une version de politique et une règle de fraîcheur, liée à une connexion, à un instant. La continuité cryptographique et la continuité de confiance ne sont pas synonymes.

Reprendre une session ne renouvelle pas la preuve

La resumption crée une nouvelle connexion à partir d’un état dérivé d’une relation antérieure. Elle peut conserver une continuité cryptographique sans répondre à quatre questions : la preuve est-elle encore assez récente, l’environnement cible est-il le même, le vérificateur et la politique ont-ils changé, et une hausse de privilège exige-t-elle une nouvelle mesure ?

Le document demande aux futurs designs de traiter ce cas, sans imposer une durée universelle. Une lecture télémétrique, une remise de secret et une migration de workload n’ont pas le même risque. Mais garder le nombre local n’autorise pas à ne pas l’enregistrer.

TLS KeyUpdate offre une comparaison utile. Le renouvellement des clés de trafic peut limiter l’exposition sans refaire tout le handshake. Il ne remesure ni firmware, ni outils d’un agent, ni état d’un module cryptographique. Fraîcheur de clé de transport, fraîcheur de preuve et fraîcheur d’autorisation ont besoin de reçus séparés.

Passport et Background Check déplacent le compromis

L’architecture RATS distingue le modèle Passport, où l’Attester obtient un résultat puis le présente, du Background Check, où la partie utilisatrice consulte un vérificateur. La révision 01 associe le second aux besoins de fraîcheur maximale, et le premier à l’échelle, aux performances ou à l’indisponibilité du vérificateur.

Les deux modèles vieillissent. Le passeport exige une validité et une politique anti-rejeu. Le contrôle en arrière-plan exige disponibilité, latence et règle de timeout. Réduire la durée diminue la fenêtre d’état périmé mais accroît charge et exposition au déni de service. L’allonger préserve la continuité au prix d’une approbation héritée plus longtemps.

La vie privée impose une autre limite. Une preuve peut révéler la composition de la plateforme, sa configuration ou l’identité du workload. Attester plus souvent peut améliorer l’actualité tout en augmentant corrélation, conservation et divulgation. Le projet traite séparément les pertes de confidentialité après compromission des clés éphémères ou des secrets de trafic.

Deux clés compromises, deux échecs

La compromission de la clé d’authentification TLS permet éventuellement de la réhéberger. L’attestation n’aide que si elle lie assez fortement cette clé, l’environnement et la connexion pour révéler la substitution. La compromission de la clé d’attestation, elle, peut permettre de fabriquer une preuve acceptable : une liaison de canal plus forte ne rend pas honnête un attester compromis.

L’attestation de clé au moment de l’émission du certificat montre la même borne. Elle peut prouver où une clé a été créée ou stockée lors de l’enrôlement. Elle ne garantit pas l’état du module au moment d’une connexion ultérieure, encore moins pendant toute sa durée.

L’autorisation reste locale

Evidence et Attestation Results sont des entrées d’une décision, pas des ordres universels d’autoriser. La partie utilisatrice applique sa politique au résultat, à l’opération et au risque du moment. Le texte laisse explicitement cette politique hors périmètre.

Lors d’une dérive, une nouvelle mesure peut être valide mais ne plus satisfaire une politique modifiée. Un même état peut autoriser la lecture et rester insuffisant pour remettre une clé. Un timeout peut provoquer une dégradation contrôlée dans un service et une fermeture immédiate dans un autre.

La doctrine de spécification initiale minimale de Heng Lu soutient un contrat interopérable borné pour liaison, fraîcheur et sémantique, sans imposer une technologie de plateforme. La primauté du code en fonctionnement demande ensuite la preuve que le déploiement réclame effectivement une nouvelle attestation, invalide l’approbation héritée et retire les droits.

Les opérateurs devraient conserver liaison au transcript, identifiants de preuve et de résultat, base de fraîcheur, vérificateur et génération de politique, identité de l’environnement, lignée de resumption et dernière acceptation. Ils devraient définir des déclencheurs pour migration, reprise, hausse de privilège, modification d’outils, rotation de clé, alerte, révocation et âge maximal. Ce sont des recommandations éditoriales, pas des exigences de la révision 01.

Le canal peut continuer à remplir parfaitement sa promesse de transport après que la machine a cessé de remplir la condition d’accès. La liaison ferme l’écart de substitution. La réattestation et le retrait d’autorisation ferment l’écart temporel.

Sources