From a127fea308947e86c13c52cc8a311c9ce43289a0 Mon Sep 17 00:00:00 2001 From: Imran Siddique Date: Sat, 12 Sep 2026 10:48:43 -0700 Subject: [PATCH] content(registry): the witness deploy does not reach the September 7 capture The page said both fields stay false for that capture because the signature covers the header, which is true and is the weaker reason. The witness deployed iat and grade signing on September 12 and confirmed that /checkpoints deduplicates on a content-addressed entry hash, so checkpoint 1 cannot be re-submitted for a new receipt at all, and because that hash is derived from the signed fields rather than the submitted bytes, reformatting does not produce a new one either. A receipt carrying a witness time needs a checkpoint the witness has not seen. This is the page the witness operator flagged as the one that would go stale at deploy time, since the sentence lives here rather than in the repo README. It now matches trace-registry LIMITATIONS.md (#77, #78). Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01X2GDChXjA7BAdDNzCAmBJv --- registry/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/registry/index.html b/registry/index.html index d61f7b0..5499d16 100644 --- a/registry/index.html +++ b/registry/index.html @@ -152,7 +152,7 @@

A signed checkpoint commits to the history

Independent witnesses

One checkpoint, one verified external receipt

Checkpoint 1's signing-body digest is included under a Merkle root signed by a separately operated witness. The returned receipt and two independently fetched copies agree; verification runs offline against an explicitly pinned witness key. This was demonstrated on September 7, 2026, ahead of the September 9 briefing.

-

The response reports countersigned-observed. Whether a receipt carries a witness time or a signed grade is a property of that receipt rather than of the profile, so the verifier reports witness_time_established and grade_cryptographically_bound instead of asserting either. Both are false for the September 7 capture and stay false for it: that receipt's protected header is algorithm and tree profile only, and the witness signature covers that header, so a receipt carrying either field is a separately signed receipt rather than this one re-read. The receipt does not certify registry continuity. It authenticates inclusion of the signing-body digest, with the registry signature checked separately.

+

The response reports countersigned-observed. Whether a receipt carries a witness time or a signed grade is a property of that receipt rather than of the profile, so the verifier reports witness_time_established and grade_cryptographically_bound instead of asserting either. Both are false for the September 7 capture and stay false for it: that receipt's protected header is algorithm and tree profile only, and the witness signature covers that header, so a receipt carrying either field is a separately signed receipt rather than this one re-read. The witness deployed support for both fields on September 12, 2026, and that does not change this capture: it registers a checkpoint by a content-addressed entry hash and deduplicates on it, so re-submitting checkpoint 1 returns the original receipt. Because that hash is derived from the signed fields rather than the submitted bytes, reformatting the submission does not produce a new one either. A receipt carrying a witness time therefore requires a checkpoint the witness has not seen. The receipt does not certify registry continuity. It authenticates inclusion of the signing-body digest, with the registry signature checked separately.

No recurring witness submission, reciprocal witnessing, or second witness is claimed. Parallel independent witnesses remain a deployment choice; original records stay with their holders.

Receipt, key provenance and offline verification