Résumé

  • Dans draft-mih-scitt-checkpointed-local-log-01, une preuve de cohérence MMR démontre qu’un historique présenté prolonge son propre prédécesseur ; elle ne démontre pas que le producteur n’a pas entretenu une seconde branche.
  • La continuité exige un témoin indépendant qui conserve le dernier point de contrôle accepté pour la même identité de journal. Une inscription SCITT ordinaire atteste l’inclusion, et l’heure seulement si elle est signée, mais pas l’absence de bifurcation.

Un service de décision automatique peut produire des milliers de reçus par jour. Publier chaque reçu exposerait des données privées et rendrait le contrôle coûteux. Garder tous les fichiers chez le producteur est moins cher, mais l’auditeur doit alors croire que la collection montrée est bien celle qui existait au moment des faits.

Le Checkpointed Local Log cherche une position intermédiaire. Les enregistrements restent locaux. Leurs condensats sont ajoutés à une Merkle Mountain Range, puis un petit point de contrôle signé engage la taille et l’état du journal. Le point de contrôle peut être transmis à un service de transparence ou à un autre témoin sans révéler le contenu.

La construction est utile, mais sa limite est décisive : une branche peut être parfaitement vérifiable sans être l’unique branche.

La cohérence répond à une question locale

Le point de contrôle transporte log_size, commitment, prev_size et prev_commitment. Avec une preuve de cohérence, un vérificateur constate que les entrées déjà engagées dans cette branche n’ont pas été retirées, réordonnées ou réécrites.

Un producteur malhonnête peut pourtant donner la branche A à un client et la branche B à un autre. A2 prolonge correctement A1 ; B2 prolonge correctement B1. Chaque vérificateur hors ligne voit une chaîne mathématiquement valable. Aucun ne peut comparer son point de contrôle à celui qu’il n’a jamais reçu.

Le témoin conscient des points de contrôle ajoute précisément cet état manquant. Il mémorise le dernier couple taille-engagement accepté pour l’identité (émetteur, identifiant du journal). La soumission suivante doit citer ce prédécesseur. Si elle en cite un autre, le témoin doit refuser l’inscription ou la contresignature et traiter l’écart comme un indice de mutation, jamais comme une erreur transitoire à rejouer.

La continuité dépend donc de trois choses que le champ de signature ne contient pas : une mémoire antérieure, une identité de journal stable et l’autorité de refuser.

Un reçu SCITT ne change pas spontanément de sens

Le projet réutilise l’architecture SCITT de la RFC 9943. Un point de contrôle peut être inscrit comme Signed Statement et recevoir un Receipt COSE conforme à la RFC 9942. Ce reçu fournit une preuve tierce d’inclusion sous la clé du service. Il ne fournit une preuve temporelle que si une heure signée figure réellement dans le reçu.

Un service peut effectuer cette inscription sans appliquer la règle CLL de continuité. Son reçu reste valide pour l’inclusion, mais n’atteste pas que le point reçu prolonge le dernier état que ce service avait accepté. Seul un service qui conserve cet état et compare le prédécesseur devient un témoin conscient des points de contrôle.

Cette différence doit apparaître dans les contrats et les tableaux de bord. « Inscrit dans un service de transparence » ne dit pas si le service vérifie la continuité, combien de temps il garde les anciens points, quelle identité indexe sa mémoire ni comment il signale un conflit.

Une contresignature directe ne contourne pas l’exigence : le témoin doit effectuer la même comparaison avant de signer. La révision 01 reconnaît aussi qu’un mécanisme voisin n’est pas mûr. Les marqueurs locaux de test, dits stubs, sont renvoyés à un travail futur car aucune implémentation livrée ne produit encore la structure RFC 9338 proposée. Un marqueur privé n’est pas un témoin.

Le miroir du producteur reste un miroir

Le producteur doit nommer les témoins invoqués. Un témoin qu’il exploite lui-même est une réplique : il peut améliorer la disponibilité, pas déplacer l’autorité capable de fabriquer deux branches.

Plusieurs témoins indépendants rendent l’équivoque plus difficile, car le producteur doit isoler chacun d’eux dans la branche qui lui est destinée. Mais le bénéfice disparaît si les témoins partagent le même contrôle ou si le vérificateur n’en consulte qu’un. Le nombre brut ne remplace ni la cartographie des autorités ni la politique de consultation.

La frontière de couverture est tout aussi stricte. Les entrées postérieures au dernier point de contrôle effectivement témoigné ont la force d’un journal non témoigné. Un ancien reçu ne verdit pas automatiquement la queue courante.

La cadence rend enfin le silence mesurable. Publier des points de contrôle est facultatif ; après cette élection, le producteur doit annoncer un intervalle maximal. Une absence devient alors un événement détectable. Elle ne donne pas une datation instantanée : la fenêtre de rétrodatage reste la cadence déclarée plus la latence du témoin.

Un témoin de forme, pas un juge du contenu

Le témoin reçoit l’engagement, pas les enregistrements. Il peut soutenir l’existence, l’ordre, l’intégrité et la complétude d’une plage sous un point de contrôle. Il ne peut pas restituer de lui-même un reçu individuel. Le producteur ou un autre dépositaire doit fournir l’enregistrement et la preuve d’inclusion.

Si un segment archivé est perdu, le point de contrôle peut montrer qu’une entrée existait sans recréer ses octets. La réponse honnête est alors « rétention expirée », et non « cette entrée n’a jamais existé ».

Surtout, un journal parfaitement témoigné peut contenir des affirmations fausses. Ni la vérité d’un reçu, ni l’autorité de son signataire, ni l’exécution d’une action, ni le résultat réel ne dérivent du témoin. Le CLL ne démontre pas davantage que le producteur n’a qu’un journal ou qu’il a ajouté chaque enregistrement créé.

La révision 01 fixe aussi une vérité de fil : l’engagement transmis doit être la liste canonique des pics MMR encodée en CBOR. Une racine « bagged » peut accélérer des comparaisons internes, mais son pliage n’est pas normalisé et ne doit pas être envoyé. C’est une règle d’interopérabilité proposée, pas une preuve de déploiement. Le document reste une soumission individuelle sans statut formel dans le processus IETF.

Sources