Résumé

  • draft-ietf-rats-epoch-markers-05 permet à une Epoch Bell d’émettre un repère réutilisable afin que des acteurs distribués évaluent la fraîcheur sans imposer une horloge civile fiable à chaque attester.
  • La signature authentifie le repère et son contexte cryptographique ; elle ne garantit ni la justesse de l’horloge, ni une livraison simultanée, ni l’unicité d’une session.
  • La décision devient vérifiable si un reçu de jonction conserve la Bell, le type de marqueur, le trajet, l’heure de réception locale, le nonce, la fenêtre d’acceptation, l’état antirejeu et la version de la politique.

Une coordonnée commune plutôt qu’une heure absolue

La fraîcheur d’une attestation n’est pas une propriété que l’on lit dans un seul champ. Elle relie le moment où un état est mesuré, celui où une preuve est produite, le trajet de cette preuve et la décision qui s’appuie sur elle. Une horloge digne de confiance aide à situer ces actes. Un défi aléatoire permet de rattacher la réponse à une demande. Mais les appareils contraints ne disposent pas tous d’une heure fiable, et une chaîne d’attestation ne se réduit pas toujours à un échange direct.

Le projet RATS introduit donc l’Epoch Bell. Elle émet des Epoch Markers que les participants peuvent reconnaître comme des positions successives. L’attester place le marqueur, ou un handle compact, dans la preuve signée. Un vérificateur compare ensuite ce repère à l’état qu’il accepte. Le modèle couvre le défi-réponse ponctuel, la diffusion spontanée en broadcast ou multicast et l’abonnement sollicité.

Cette souplesse ne transforme pas la Bell en horloge de la planète. Même lorsqu’un marqueur transporte une date POSIX, son sens dépend de la Bell, de sa clé et de son domaine. Lorsqu’il contient seulement un compteur, il ordonne des émissions dans ce contexte sans les relier nécessairement au temps civil. La fraîcheur reste un jugement local appuyé sur un repère partagé.

Plusieurs formes, plusieurs promesses

La révision 05 décrit des tags temporels CBOR, le TSTInfo classique de RFC 3161, une version CBOR de cette structure, un Epoch Tick, une liste de ticks, un compteur monotone et l’epoclet. Il serait tentant de considérer ces formats comme des emballages équivalents. Ils ne le sont pas.

Les variantes temporelles supposent une horloge fiable du côté de la Bell. Le compteur donne un ordre, à condition que son état survive et que son périmètre soit connu. Le tick peut être partagé par de nombreux consommateurs, contrairement au nonce d’un vérificateur destiné à une seule transaction. La liste facilite un rattrapage, mais exige que le récepteur garde un état et sache se resynchroniser. L’epoclet, d’environ 44 à 64 octets, assemble une heure POSIX, un identifiant de clé propre au déploiement et un HMAC. Sa compacité reporte une partie du risque vers la garde des secrets, leur rotation et la synchronisation des serveurs.

Une signature valide établit donc une phrase limitée : la clé attendue a authentifié ces octets selon ce format. Elle ne dit pas que l’horloge était exacte, qu’un compteur n’a jamais reculé après une panne, ni que tous les destinataires ont vu la même émission au même instant. RFC 9052, RFC 8392, RFC 8949 et RFC 9581 fournissent des structures qui protègent et relient des déclarations. Elles ne certifient pas les hypothèses d’exploitation dont ces déclarations dépendent.

Le délai fait partie de la preuve

Une même émission emprunte des chemins différents. File d’attente, réplication multicast, liaison intermittente et traitement intermédiaire créent du décalage. Un marqueur retardé peut conserver une signature irréprochable. Voilà pourquoi le projet compare son émission et sa réception aux ticks d’une horloge distribuée, avec latence et skew.

Dans le modèle Passport, l’attester peut porter sa preuve vers le relying party après avoir obtenu un repère. Dans le modèle Background-Check, l’évaluation intervient ailleurs et un Attestation Result revient au décideur. Dans les deux cas, le marqueur ou son handle doit rester lié au résultat, tandis que la politique tient compte du chemin réellement emprunté.

Supposons qu’un vérificateur proche ait déjà reçu le tick 820 et qu’un site isolé n’ait reçu que le 818. Utiliser 820 comme frontière mondiale rejette peut-être un équipement honnête du second site. Continuer d’accepter 818 sans échéance rend au contraire un rejeu durable. La fenêtre d’acceptation doit donc nommer son périmètre, inclure le temps de réception local, prévoir transport et traitement, puis expirer selon le risque.

Une fenêtre généreuse réduit les faux rejets des systèmes lents ou endormis, mais prolonge la valeur d’une ancienne preuve correcte. Une fenêtre étroite limite le rejeu tout en augmentant les rejets liés au réseau. Ce choix n’est pas dissimulé dans la cryptographie : il appartient au relying party.

Réutiliser un tick ne crée pas un nouveau défi

Le partage d’un Epoch Tick est voulu. Plusieurs attesters peuvent citer la même émission ; cette propriété rend le service scalable. Elle interdit cependant de traiter le tick comme un nonce à usage unique. Un adversaire peut conserver un repère encore acceptable et tenter de lui associer une preuve plus ancienne si les champs ne sont pas liés dans la même enveloppe protégée.

Le vérificateur doit épingler la clé attendue, le domaine, le type de marqueur et les algorithmes admis. Lorsqu’une session exige l’unicité, il ajoute son propre nonce. Le projet demande au moins 64 bits d’entropie obtenus par un générateur cryptographique et autorise jusqu’à 512 bits. Le nonce répond à « cette réponse vise-t-elle ma demande ? » ; le marqueur répond à « à quelle position de cette Bell la preuve se rattache-t-elle ? »

L’identité ou la clé de l’attester, le condensat de la preuve, le nonce et le marqueur doivent être liés. Une négociation de format mérite également une règle anti-downgrade. Passer d’un jeton temporel à un compteur ou à un epoclet change les hypothèses. Ce n’est pas une préférence de sérialisation sans conséquence.

Le coût de l’état révèle le modèle de gouvernance

Pour comparer ticks et compteurs, le vérificateur mémorise un état. Une seule valeur « la plus haute jamais vue » pour toute la Bell coûte peu. Elle favorise néanmoins le chemin le plus rapide : dès qu’il avance, les preuves venues d’un trajet lent paraissent anciennes. Un état par attester consomme davantage de stockage et de logique, mais respecte mieux des connectivités différentes.

Le bon choix dépend du parc. Un environnement de centre de données homogène peut adopter une frontière globale stricte. Des équipements industriels intermittents peuvent exiger une histoire individuelle, un statut de suspension et une procédure de reprise. Dans les deux cas, l’algorithme de comparaison matérialise une politique. Il ne faut pas le présenter comme une conséquence neutre du numéro.

La resynchronisation doit laisser une trace. Une liste de ticks peut aider un récepteur à rattraper son retard, mais l’acceptation d’un élément ancien demeure une décision. Une perte d’état peut faire ressembler un redémarrage à un rollback. Une rotation de clé ouvre une nouvelle époque de confiance même si l’heure affichée reste continue. Le reçu doit conserver l’ancienne frontière, l’époque de clé et la raison de la transition.

Une bonne signature peut couvrir une mauvaise Bell

Une Bell compromise ou mal configurée peut signer des marqueurs parfaitement vérifiables. Son horloge peut bondir, son compteur se répéter, sa clé fonctionner à deux endroits ou certains destinataires recevoir une vue retardée. Dans ce cas, la vérification cryptographique réussit et la prémisse de fraîcheur échoue.

L’exploitation doit donc rendre visibles l’opérateur responsable, la garde et la rotation des clés, la santé de l’horloge ou du compteur, la distribution et les règles d’incident. Plusieurs Bells ne composent pas automatiquement un temps consensuel. La politique doit préciser si elles sont alternatives, séparées par périmètre ou soumises à un quorum.

Les ticks prévisibles peuvent aussi corréler des messages pourtant protégés : l’observateur regroupe les échanges autour d’une émission. Modifier les intervalles, les incréments ou les périmètres réduit parfois ce risque, mais oblige à recalculer fenêtres et état. La confidentialité et la fraîcheur doivent être conçues ensemble.

Le reçu doit garder la jonction

Un reçu exploitable enregistre l’identité de la Bell, la clé et son époque, le type et le condensat du marqueur, le domaine, le périmètre, la prétention d’émission éventuelle, l’heure locale de réception et le canal de distribution. Il ajoute la latence mesurée ou budgétée et la règle qui fixe l’échéance.

Il relie ensuite l’attester, le condensat de la preuve et le contexte de production. Le nonce du vérificateur et la session sont conservés lorsqu’ils existent. Le reçu indique si l’état était global, propre à l’attester ou partitionné autrement, la frontière précédente, le résultat antirejeu, les événements de resynchronisation et la version exacte de la politique.

Enfin viennent décision, expiration, révocation et date de réexamen. Un incident ultérieur de la Bell doit permettre de retrouver les décisions affectées sans réécrire les faits passés. Ces champs restent un supplément local : charger le marqueur interopérable de toute la gouvernance du déploiement le rendrait moins utile.

Au moment de cette recherche, la révision 05 était un Internet-Draft actif du groupe RATS, mise à jour le 3 juillet 2026 et expirant le 4 janvier 2027. Datatracker indiquait « WG Document Doc Shepherd Follow-up Underway » et l’état IESG « I-D Exists », sans directeur responsable ni téléconférence. L’en-tête annonçait Standards Track, tandis que le champ de statut RFC prévu restait vide. Ce sont des faits de processus, pas des preuves de déploiement.

Sources