Résumé

  • Le brouillon individuel draft-nikolaichuk-scitt-continuity-receipts-01 propose d’inscrire une déclaration signée sur la reprise d’un actif avec les mécanismes SCITT et les reçus COSE de la RFC 9942.
  • Le service peut accepter la demande de manière asynchrone avec HTTP 202 et un identifiant d’entrée. Tant que le Receipt n’est pas résolu, cet identifiant n’est qu’une promesse et la reprise demeure non attestée par le journal.
  • Le Receipt final prouve l’inscription d’une assertion signée, pas la réalité de la reprise, la qualité de l’attestation ni la fidélité fonctionnelle de l’actif.

Deux objectifs qui ne finissent pas ensemble

La reprise après sinistre aime les chronomètres simples. Le service doit revenir en trente minutes. La base doit être remontée avant l’ouverture du marché. Le modèle doit être disponible dans la nouvelle région avant l’épuisement de l’ancienne capacité. Ces objectifs ont une vertu : ils obligent l’organisation à décider combien d’indisponibilité elle accepte.

Ils disent moins bien ce qui doit être prouvé au moment du retour. Une équipe peut reconstruire les octets, lancer l’application et respecter son délai, alors que le service de transparence n’a encore renvoyé qu’un statut 202. Une autre horloge continue de tourner : celle du témoignage vérifiable.

Le texte publié le 29 septembre 2026, au statut visé Informational, porte précisément sur cette seconde horloge. Il s’agit d’un Internet-Draft individuel, pas d’un texte adopté par le groupe SCITT ni d’une RFC. Il décrit une Recovery Statement signée puis inscrite auprès d’un Transparency Service. Le Receipt n’est pas le certificat de bonne santé de la reprise. Il est la preuve que cette déclaration déterminée a pris place dans un journal déterminé.

La distinction paraît fine jusqu’au moment où quelqu’un doit choisir : ouvrir l’accès à l’actif restauré maintenant, ou attendre que l’inscription soit prouvée ?

La reprise est une succession, pas une case verte

Le dispositif proposé commence dans l’environnement de reprise. L’Attester produit des Evidence. Un Verifier les évalue et émet des Attestation Results. Un mécanisme distinct autorise la libération du matériau de clé. L’environnement déchiffre le matériau scellé, recompose l’actif et calcule le condensat du résultat réel.

La Recovery Authority formule ensuite les faits qu’elle affirme avoir observés. Elle signe ces claims sous la forme d’une Signed Statement conforme à l’architecture SCITT de la RFC 9943. Le Transparency Service vérifie sa politique d’admission, ajoute la déclaration à son journal et fournit un Receipt selon la RFC 9942. Enfin, le Relying Party contrôle les éléments qui comptent pour sa propre décision.

Chaque verbe a un sujet différent. Autoriser la clé n’est pas reconstruire. Reconstruire n’est pas évaluer l’attestation. Signer n’est pas auditer. Inscrire n’est pas déclarer l’actif fidèle. Libérer vers le consommateur est encore une autre décision.

Cette grammaire empêche le pouvoir symbolique de remonter la chaîne. Dans les termes de Lu Heng, le registre appartient à une couche de réalité utile, mais bornée. Il ne doit pas devenir l’auteur imaginaire des événements physiques qu’il n’a pas observés.

Le Receipt établit une inscription, rien de plus

Le brouillon fixe sa limite sans ambiguïté. Le Receipt prouve qu’une Recovery Statement précise, signée par un Issuer précis, a été inscrite dans un Transparency Service précis à une position précise de son journal append-only, et que le service a signé cette preuve.

Il ne prouve pas que l’événement de reprise a eu lieu. Il ne prouve pas que les octets restaurés sont ceux de l’original. Il ne dit pas que les Attestation Results référencés ont été vérifiés ou qu’ils étaient favorables. Il ne confirme pas l’état réel de l’environnement. Il ne montre pas non plus que la politique d’inscription a contrôlé ces points.

Le service témoigne d’une assertion. Il ne l’audite pas. Sa valeur est ailleurs : l’assertion devient attribuable, ordonnée, durable et difficile à retirer discrètement. Le système gagne une mémoire opposable. Il ne gagne pas une vérité automatique.

Une interface qui transforme ce Receipt en voyant « reprise vérifiée » efface donc la propriété essentielle du mécanisme. Le lecteur doit voir séparément ce qui est affirmé par l’Issuer, ce qui a été établi par une vérification indépendante et ce qui reste invérifiable.

Le 202 ouvre une dette de preuve

Le brouillon SCRAPI actuel permet une inscription asynchrone. Le Transparency Service accepte la Signed Statement, répond HTTP 202 avec un identifiant d’entrée, puis rend le Receipt disponible plus tard sur la ressource correspondante.

Cette réponse prouve que le traitement a été admis. Elle ne prouve pas l’inclusion dans le journal. Le projet exige alors un choix explicite : bloquer la libération de l’actif jusqu’au Receipt, ou continuer sans lui. Dans le second cas, la reprise doit être enregistrée comme « unwitnessed » jusqu’à résolution.

Une organisation peut raisonnablement choisir de continuer. Lors d’un sinistre, l’arrêt prolongé d’un service critique peut produire plus de dommage que le retard du journal. Mais cette exception doit avoir un propriétaire, une durée, un périmètre de consommateurs et une date de réconciliation. Sinon, l’objectif de reprise devient une autorisation tacite d’abandonner la preuve exactement lorsque la pression opérationnelle est la plus forte.

L’identifiant d’entrée facilite le suivi. Il ne doit jamais être présenté comme le Receipt qu’il permettra peut-être d’obtenir.

Le condensat doit venir des octets restaurés

Le champ recovered-digest est l’ancre de la déclaration. Il doit être calculé sur le texte clair effectivement produit à la fin de la reprise. Copier le condensat attendu depuis un manifeste de sauvegarde ne mesure rien : cela transforme l’attente en résultat.

La même règle vaut pour l’identité de l’environnement. La mesure doit conserver son algorithme et sa longueur d’origine. Le texte cite le code voisin qui réduit à 32 octets des mesures SHA-384 de 48 octets pour AWS Nitro et AMD SEV-SNP. Une telle normalisation ne produit pas une preuve plus pratique ; elle détruit l’égalité exacte avec la valeur évaluée par le moteur de politique.

Le running code doit ainsi laisser des traces du phénomène qu’il a réellement produit, pas remplir le schéma avec les valeurs que l’opérateur espérait retrouver.

Une attestation peut être présente et inutilisable

Les Attestation Results peuvent être référencés par leur condensat, intégrés dans la déclaration ou inscrits séparément. La référence limite la taille et la divulgation, mais suppose que les octets exacts demeurent accessibles. L’intégration facilite la vérification future, au prix d’une exposition accrue des mesures, régions ou identifiants matériels. L’inscription séparée ajoute son propre Receipt, mais aussi une dépendance supplémentaire.

La fraîcheur possède quatre états : nonce, identifiant d’époque, horodatage ou none. Ce dernier n’est pas une erreur de syntaxe. Il révèle que l’Evidence n’était liée à aucun défi et peut être rejouée. Une interface qui résume tout cela par « attested » confond présence, authenticité, fraîcheur et résultat d’évaluation.

Démarrer n’est pas redevenir identique

Le champ d’équivalence est facultatif, et son absence signifie none. byte-identical exige que le condensat observé corresponde au condensat du texte clair enregistré lors du scellement. operational indique seulement la réussite d’un contrôle défini—chargement, démarrage, sonde de santé—avec une référence vers sa définition et son résultat.

Le document qualifie justement cette deuxième assertion de faible. Une base peut démarrer avec des lignes manquantes. Un modèle peut se charger et produire un comportement différent. Une application peut répondre à sa sonde sans restaurer les invariants métiers.

Le projet refuse donc de définir une équivalence sémantique ou comportementale. Ce refus protège davantage que ne le ferait un code de statut flatteur mais invérifiable. Le Receipt peut être parfait tandis que l’équivalence reste absente.

La chaîne de l’Issuer n’est pas l’ordre du journal

Avec prev-event, les reprises successives d’un même subject forment une Continuity Chain. Celle-ci exprime la filiation que l’Issuer revendiquait au moment de signer. Le journal fournit, lui, l’ordre global des inscriptions.

Un trou entre les deux ne doit pas être comblé par le vérificateur. Il peut révéler une reprise intermédiaire inconnue de l’Issuer ou volontairement non reconnue. prev-entry-id et l’indice de feuille aident à retrouver un objet ; seul le condensat de la déclaration précédente relie cryptographiquement les événements.

Si la chaîne traverse plusieurs Transparency Services, chacun garantit son propre ordre. Aucun ne fabrique un ordre universel entre eux. Et sur une longue durée, un reçu d’inclusion doit être complété par des preuves de cohérence reliant les racines successives : appartenir à un arbre isolé ne montre pas que l’ancien arbre n’a pas été remplacé.

La confidentialité déplace la possibilité de contrôle

Un payload attaché permet au Transparency Service d’examiner les claims, mais peut rendre visibles le subject stable, la fréquence des reprises, la région, les relations de service ou des identifiants matériels. Un payload détaché protège mieux ces informations dans le journal. En échange, la politique d’inscription ne peut pas vérifier ce qu’elle ne reçoit pas, et le Relying Party doit obtenir le contenu par une autre voie.

Pseudonymiser le subject réduit la corrélation publique, mais empêche deux custodians de joindre facilement leurs chaînes. La clé de pseudonymisation devient elle-même un secret durable ; sa rotation coupe la continuité. La confidentialité n’est donc pas une option gratuite ajoutée après coup. Elle dessine l’espace de vérification futur.

Le code voisin ne constitue pas une mise en œuvre

Le brouillon reconnaît que l’implémentation de référence adjacente n’implémente pas cette spécification. Elle n’émet aucun COSE Receipt RFC 9942, emploie d’autres liens de journal, ne vérifie pas complètement l’attestation et ne fournit pas de liaison par nonce. Son mécanisme de reconstruction est une chaîne de Markov déterministe d’ordre 3 au niveau des octets, non une preuve de restitution sémantique.

Cette divergence ne condamne ni SCITT ni la proposition. Elle interdit simplement d’écrire « implémenté » lorsque le format, les vérifications et les résultats de déploiement ne se rejoignent pas encore.

Sources et limites

Ces sources décrivent une proposition, des architectures normatives existantes et l’écart d’un prototype. Elles n’établissent ni déploiement, ni incident, ni attaque, ni interopérabilité, ni fidélité d’une reprise réelle. Le dossier de libération ci-dessous est une analyse opérationnelle de Daniel Kade, pas une exigence déjà normalisée par le brouillon.