Summary

  • Un Internet-Draft individuel propose qu’un Identity Document Service compatible RATS transforme un résultat d’attestation acceptable en clé, jeton ou justificatif que des parties utilisatrices non compatibles RATS savent déjà traiter.
  • Cette compatibilité ouvre un intervalle après l’émission : le justificatif peut rester recevable selon ses règles ordinaires alors que la preuve, la politique d’évaluation, l’emplacement ou une affirmation déterminante a changé.
  • Daniel Kade propose un bail entre attestation et justificatif, liant durée, statut et révocation aux époques de preuve, aux versions de politique, aux classes d’affirmations, à la clé de la charge et aux événements déclencheurs. C’est une proposition éditoriale, non une exigence de l’IETF.

Le contrôle qui réussit puis vieillit

Le cas du déplacement géographique est précieux parce qu’il ne met en scène aucune compromission. La charge de travail fournit des Evidence, un Verifier les apprécie, puis un service intermédiaire accepte l’Attestation Result et délivre un justificatif. Le canal peut être correctement protégé, la clé privée rester dans la charge et chaque signature être valide. L’orchestrateur effectue ensuite une migration légitime.

Le draft-bdnr-rats-trustworthy-credentials-02 indique qu’un déplacement de l’Allemagne vers la France peut rendre inexacte l’affirmation Country=Germany tout en laissant vraie l’affirmation Region=Europe. La conséquence n’est pas prédéterminée. Une autorisation valable dans toute l’Europe peut subsister ; une autorisation dépendant d’une localisation allemande doit être réexaminée. Le même événement modifie donc certaines capacités et pas nécessairement les autres.

Pendant ce temps, la partie utilisatrice traditionnelle continue d’observer un objet parfaitement conforme à son modèle. Elle n’a reçu ni les Evidence, ni la version de politique, ni le changement de lieu. Le défaut de gouvernance ne consiste pas à lui reprocher cette ignorance voulue. Il consiste à ne pas désigner l’acteur chargé de convertir le changement de confiance en un événement qu’elle saura appliquer.

Réduire le périmètre du changement est légitime

Le projet part d’un obstacle concret. Des clients et serveurs existants ne savent pas interpréter les Evidence RATS, les résultats d’attestation ou les politiques d’évaluation. Certains sont des binaires tiers, d’autres relèvent d’une pile technique difficile à modifier, d’un contrôle réglementaire coûteux ou d’une organisation où plusieurs équipes doivent s’accorder. Exiger une adaptation universelle condamnerait le déploiement à attendre le système le moins modifiable.

L’intermédiaire apporte une réponse pragmatique. Un Credential Broker, Key Broker ou Credential Authority cumule les fonctions de Relying Party RATS et d’Identity Document Service. Il reçoit le résultat et, s’il est recevable, remet un document d’identité familier aux collaborateurs de la charge. Le terme recouvre une clé, un jeton ou un justificatif, de courte ou de longue durée. Le texte examine notamment un courtier de clés, un justificatif de preuve de possession préinstallé et l’émission d’un nouveau justificatif de possession ou d’un jeton porteur bref.

Le bénéfice annoncé—un rayon d’impact limité—est sérieux. Les mécanismes TLS, PKI ou jetons déjà déployés peuvent rester en place. La clé privée peut demeurer dans la charge de travail. L’application historique n’a pas besoin d’apprendre une taxonomie nouvelle pour chaque attestation.

Mais cette simplicité est déplacée, pas détruite. En rendant RATS invisible aux services, l’intermédiaire devient responsable du passage inverse : quand le jugement change, il doit parler le langage d’expiration, de statut ou de révocation que ces services connaissent.

Trois temporalités qui ne se confondent pas

RFC 9334 distingue l’évaluation des Evidence par le Verifier et la décision de la Relying Party sur l’Attestation Result. La première s’appuie sur une Appraisal Policy for Evidence ; la seconde sur une Appraisal Policy for Attestation Results adaptée à un usage. L’authenticité du résultat ne décide pas à elle seule d’une autorisation.

La fraîcheur est bornée. Un résultat est produit à un instant estimé et ne doit pas être utilisé au-delà de sa validité. RFC 9334 reconnaît aussi une course irréductible : l’environnement ou la politique peut évoluer immédiatement après la production du résultat. Une période valide borne l’usage ; elle n’immobilise pas le monde.

L’émission d’un justificatif ajoute sa propre temporalité. Un certificat porte des dates, un jeton une expiration, un système de statut une fréquence de mise à jour. Ce sont les seules bornes visibles par un service non compatible RATS. Si le justificatif dure huit heures et qu’une affirmation essentielle ne mérite que cinq minutes de fraîcheur, la conversion ne transforme pas cinq minutes en huit heures. Elle masque l’écart.

La courte durée réduit l’exposition sans résoudre la liaison. Un justificatif de dix minutes peut dépasser une donnée fiable cinq minutes. Une attestation continue peut détecter le mouvement mais ne dit pas encore quoi faire du certificat déjà distribué. Une révocation n’agit que si l’émetteur sait quels droits dépendent du fait modifié et si chaque service consulte effectivement le mécanisme de statut.

Une signature exacte peut conserver une prémisse périmée

Une signature JWS conforme à RFC 7515 protège l’intégrité d’un objet et rattache celui-ci à une clé. La validation de chemin décrite par RFC 5280 évalue émetteurs, contraintes, période et informations de révocation selon la configuration locale. La preuve de possession montre que le présentateur contrôle la clé privée correspondante. Aucun de ces contrôles ne réexécute l’appréciation des Evidence qui a précédé l’émission.

Le service traditionnel peut donc prendre une décision correcte dans son univers et néanmoins prolonger une autorité dont la justification a vieilli. Tant que l’objet n’est ni expiré ni révoqué, son acceptation est cohérente. Le point de contrôle reste chez l’IDS, seul acteur ayant nécessairement observé le jugement RATS et le justificatif créé en conséquence.

Cet IDS relie deux mondes. D’un côté, des Evidence, valeurs de référence, Endorsements, politiques et affirmations changent à des rythmes distincts. De l’autre, une application applique durée, rotation de clé, introspection ou révocation. Le lien doit devenir un état opérationnel consultable et actionnable, pas seulement une trace d’émission disponible après l’incident.

Les affirmations ne vieillissent pas en bloc

L’exemple France–Allemagne empêche de traiter l’Attestation Result comme un feu vert indivisible. Un pays peut changer sans que la région change. L’opérateur d’hébergement peut évoluer tandis que le composant mesuré reste identique. Une configuration peut dériver alors que le démarrage sécurisé demeure attesté. Une nouvelle politique peut refuser un algorithme sans nier tous les autres attributs de la charge.

Il faut relier chaque portée d’autorité au minimum d’affirmations qui l’a justifiée. Si un droit est européen, le pays peut être informatif et non déterminant. Si le droit exige un traitement en Allemagne, le pays est une dépendance forte. Regrouper ces droits dans un seul justificatif grossier rend la correction disproportionnée : conserver l’objet maintient trop d’autorité ; le révoquer entièrement coupe aussi ce qui reste justifié.

Une carte des dépendances protège ainsi la sécurité et la disponibilité. Si chaque modification entraîne une panne générale, les équipes apprennent à ignorer les signaux d’attestation. Si aucune modification ne produit d’effet avant l’expiration, la signature devient un conservateur d’autorité obsolète. La décision vérifiable est plus précise : quelle affirmation commande quelle capacité, et pourquoi le changement a-t-il conduit à une action ou à une absence d’action ?

Ne pas confondre le demandeur technique et l’identité attestée

Le draft envisage qu’un client EST se trouve dans un hyperviseur ou un orchestrateur, hors du périmètre de confiance de la charge. Ce client peut s’authentifier pour établir le canal, mais son identité ne doit pas déterminer celle de la charge dont le justificatif sera renvoyé. Les Evidence et l’attestation doivent établir cette liaison ; la clé privée devrait rester dans la charge.

Cette discipline doit survivre à l’émission. Un événement de migration ou de réévaluation doit retrouver le justificatif par la clé et l’identité attestées, non par la seule session de l’orchestrateur qui a transporté la demande. Sinon, toutes les interactions peuvent être authentifiées tout en agissant sur le mauvais objet.

Le projet LAMPS sur l’attestation des CSR rend visible une obligation voisine. Lorsqu’une CA ou une RA emploie l’attestation, elle doit relier les différentes déclarations entre elles et à la clé publique de la demande ; ses exigences devraient être documentées dans sa Certification Practice Statement. Cela éclaire l’attribution de responsabilité, sans prouver que le draft sur les trustworthy credentials a déjà fixé son régime après émission.

Les travaux WIMSE séparent également le justificatif qui représente une identité de charge et la preuve de possession. Contrôler une clé répond à la question du présentateur. Cela ne confirme pas que l’emplacement, la configuration ou la mesure qui avaient permis l’émission sont toujours valides.

Le bail entre attestation et justificatif

Daniel Kade propose que l’IDS conserve un bail entre l’attestation et chaque justificatif. Ce bail n’est pas un nouveau format public imposé aux applications historiques. Il est un état minimal qui garde connectés le régime dynamique de RATS et les mécanismes natifs de validité de l’application.

Il identifie d’abord le justificatif et son type, l’identité de la charge, la clé publique détenue par celle-ci et la liaison de preuve de possession. Il enregistre ensuite l’époque des Evidence, leur limite de fraîcheur, l’identité du Verifier, la version de sa politique d’évaluation, puis la version de la politique avec laquelle l’IDS a accepté l’Attestation Result. Un changement de Verifier ou de politique permet ainsi de retrouver les justificatifs concernés.

Une carte associe les capacités aux classes d’affirmations : pays, région, état logiciel mesuré, protection de clé, environnement d’exploitation. Elle précise si la dépendance est obligatoire, informative ou seulement utilisée pour raccourcir la durée. Il n’est pas nécessaire de recopier les Evidence brutes. Une référence protégée, une époque et un condensat peuvent suffire, avec des limites de conservation et de confidentialité.

Le bail fixe aussi un horizon. La durée du justificatif ne devrait pas dépasser sans explication la dépendance matérielle la plus courte. Une observation continue et une voie de statut prouvée peuvent fournir un contrôle équivalent. Il ne s’agit donc pas d’exiger systématiquement le certificat le plus bref, mais d’empêcher qu’un profil de huit heures soit adopté par simple habitude.

Enfin, les événements ont une traduction prévue. Migration, rotation de clé, nouvelle politique, retrait d’une valeur de référence, modification logicielle, échec de remédiation ou changement d’Endorsement peuvent déclencher une nouvelle attestation. La conséquence sera une réémission, une réduction de portée, une suspension, une révocation ou une décision motivée de ne rien faire si l’affirmation modifiée n’est pas pertinente. L’IDS doit prouver non seulement la décision, mais la remise du signal natif aux catégories de services concernées.

La révocation doit arriver jusqu’au dernier service

Une ligne marquée « révoqué » dans une base ne retire pas encore l’autorité. Certains services mettent en cache les réponses, d’autres ne vérifient qu’à l’ouverture d’une session, d’autres encore attendent l’expiration d’un jeton court. Une session déjà établie peut continuer. Le bail doit nommer la voie d’application et son retard maximal.

L’audit suit donc une séquence : origine de l’événement de migration, délai de réévaluation, mécanisme de statut du certificat ou du jeton, traitement des sessions, comportement face à une partie indisponible et extinction de l’ancien justificatif par rapport à l’usage du nouveau. Le succès d’un appel d’API de révocation ne prouve pas la fin de l’usage.

Une exception est elle aussi un état temporel. Une autorité d’incident peut autoriser trente minutes de continuité pendant une panne du Verifier. Cette décision doit contenir portée, responsable, expiration, observation compensatoire et disposition finale. À défaut, une tolérance temporaire devient silencieusement une seconde chaîne de confiance.

Ce que les documents ne prouvent pas

Le draft sur les trustworthy credentials reconnaît des parties inachevées. La voie du jeton porteur exige un autre protocole ou une extension ; l’adaptation de /serverkeygen demande encore des détails. Le texte impose des canaux protégés et insiste sur les clés, mais n’offre pas un régime complet de gouvernance du cycle postérieur à l’émission.

Au jour de cette recherche, il reste un Internet-Draft individuel sans statut formel à l’IETF. Les documents LAMPS et WIMSE sont eux aussi des travaux en cours. Les sources gelées ne prouvent aucun déploiement nommé, aucune durée courante, aucun incident de migration, aucune violation réglementaire, aucune performance ni aucun taux d’adoption. Le scénario illustre une possibilité explicitement relevée par le draft ; il n’accuse aucun opérateur. Le bail proposé relève de l’analyse éditoriale, pas d’un consensus normatif.

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-bdnr-rats-trustworthy-credentials-02
  5. https://datatracker.ietf.org/doc/draft-bdnr-rats-trustworthy-credentials/
  6. https://datatracker.ietf.org/doc/draft-bdnr-rats-trustworthy-credentials/history/
  7. https://author-tools.ietf.org/iddiff?url1=draft-bdnr-rats-trustworthy-credentials-01&url2=draft-bdnr-rats-trustworthy-credentials-02
  8. https://www.rfc-editor.org/rfc/rfc9334.html
  9. https://www.rfc-editor.org/rfc/rfc9711.html
  10. https://datatracker.ietf.org/doc/html/draft-ietf-lamps-csr-attestation-29
  11. https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds-02
  12. https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-08
  13. https://www.rfc-editor.org/rfc/rfc7030.html
  14. https://www.rfc-editor.org/rfc/rfc5280.html
  15. https://www.rfc-editor.org/rfc/rfc7515.html