要約

  • 9月5日に公開された個人Internet-Draftの第01版は、8システムに関する過大な記述を訂正し、ダイジェスト計算と実装状況を追加した。
  • TR-1からTR-4は、記録形式、説明、行為の門番、完全性を累積する。しかしacts:falseと宣言した非実行システムは、門番となる行為が一件もなくてもTR-4へ進める。
  • 新版は、読者が記録だけで決着できる検査と、リスク源や承認者IDの由来のように発行者が証言するだけの検査を分けた。
  • RFC 3161の外部アンカーはダイジェストと時刻を第三者に結び付けるが、証言の正しさ、完全性、唯一性までは証明しない。
  • 調達や監査で必要なのは裸のTR-4ではなく、範囲、各レベル、検証項目、証言項目、完全性方式、検証器を並べた証明マトリクスである。

訂正履歴そのものが第一のテストになる

IETFの告知が示すのは、18ページの第01版が9月5日に利用可能になったことだ。Datatrackerは制度上の上限も明示する。これは活動中の個人Internet-Draftであり、RFCストリーム、担当Area Director、正式な標準化上の地位、IETFの支持を持たない。誰でもI-Dを提出できる。

第00版は、調べた8システムのどれも行為を承認した人のIDを記録しない、と述べていた。第01版は、その調査ではそこまで言えなかったと訂正する。著者以外が書いた関連5システムでは4件が「なし」、1件が「判定不能」だった。残る3件には、IDを記録する著者自身のシステムが含まれていた。

「探して見つからない」「公開部分では判定できない」「自作の参照実装にはある」は同じ観測ではない。機械の信念と根拠の差を残す形式なら、自分の比較にも同じ厳密さが必要になる。新版は強い断言を守るのではなく、証拠の幅に戻した。

公式差分には、もう一つの自己訂正がある。00はダイジェストを要求しながら、アルゴリズム、直列化、順序を定めていなかった。参照検証器は値を再計算せず、フィールドがあるだけで受け入れられた。著者の二つの実装も異なる空白規則を使っていた。

01はcovers順のエントリー、空白のないJSON、Unicodeコードポイント順のキー、下線で始まる閲覧注釈の除外、UTF-8、末尾なしのLF結合、数値範囲、SHA-256を指定した。検証器も計算し直す。「Verifiable」は、ようやく発行者の道具を借りずに争える性質になった。

一段上がるたびに別の問いが加わる

TR-1は、既知の版と型、必須項目、一意なID、書き込み時刻の順序、scopeの整合を確認する。TR-2は、各beliefが根拠を列挙しているかを見る。空配列は根拠がないという正直な値になる。矛盾では両側を保持し、解決した場合は方法、主体、時刻、残した側を記す。

TR-3は外部効果を持つdecisionに移る。risk classはモデル自身の出力ではない源を名乗らなければならない。拒否した行為を実行済みとは書けない。実行した高リスク行為にはhumanのapprovalが要り、IDの源はモデル文ではなく、承認者は提案者と別でなければならない。

TR-4は記録の完全性を見る。対象エントリーが存在し、ダイジェストが再計算でき、外部アンカーの署名対象が同じ値であるかを確かめる。これらは一つの強さの階段ではなく、複数の性質を足した列である。

0.2のscopeは、その混同から生じた実装上の問題への応答だ。記憶装置や観測器のように外部行為を実行も遮断もしない発行者はacts:falseと宣言できる。decisionを持たなければ、門番にする行為がないためTR-3を満たし、完全性によってTR-4へ進む。草案自身が「TR-4, record only」と範囲を添えるよう勧める。

「記録のみ」を落とすと、実際の行為が人間の承認を通ったという印象に変わる。非実行システムが悪いのではない。強い保存能力を、検査対象外だった実行能力の保証に流用することが問題なのである。

scopeは機械が語る自己紹介である

検証器はscopeの真偽を外から確認しない。acts:falseなのに同じ記録へdecisionを書けばTR-1で矛盾を検出できる。しかしコネクターやホストが別経路で行為を出し、その経路が記録に現れなければ、内部整合性は保たれたままだ。

実運用では、提案、承認、dispatch、外部効果の各境界を別に観測する必要がある。どのプロセスが作用を起こせるか、記録器を迂回する経路があるか、declared scopeと実行面を結ぶ独立資料があるか。これがなければ、scopeは当事者の証言でしかない。

Machine Testimonyの公開リポジトリには仕様、検証器、アダプター、適合コーパスがある。第三者が読む、動かす、反証する入口を作った点は重要だ。一方、新しいImplementation Statusは、既知の実装がすべて著者のものだと明記する。PythonとTypeScriptの二つが一致しても、同じ人が解釈した二経路であり、独立実装の証拠ではない。

適合性censusは、対象commitを固定し、absenceにも探索場所を要求し、利益相反と自作システムの欠陥を公開する。優れた証拠管理だが、著者が尺度、参照実装、評価を担う事実は消えない。外部監査という呼び名は使えない。

同じTR-4でも根拠の中身が違う

新版のverified checkは、記録だけで第三者が決着できる。参照されたevidenceがあるか、矛盾の双方が残るか、拒否が実行済みになっていないか、対象から計算したhashが一致するか、外部tokenが別物ではなく同じdigestを署名したか、である。

attested checkは、具体的ではあっても未確認の主張だ。risk classがregistryから来た、承認者名が認証済みsessionから来た、replay engineが同じ結果を再現する、と発行者が書く。記入義務は後日の反証を可能にする。しかし欄を埋めたことは、その外部源を提示したことではない。

一つのTR-4は、ほぼ算術で確定できる記録かもしれない。別のTR-4は、重要な権限情報を発行者の主張に依存する。最高値だけでは、この配合が見えない。

方式による差もある。自己計算のdigestは第三者の変更を検出しても、発行者による歴史の作り直しを止めない。署名は鍵の主体と信頼方針を加える。RFC 3161のTime Stamp Authorityはデータ印影と時刻を外部に置く。依頼者は印影、証明書、方針を検証するが、TSAは証言内容を真実と認定しない。

RFC 8785はJSON canonicalizationの背景を与え、01は対象エントリー用の具体規則を置く。RFC 9162とSCITT architecture 22は、単一発行者の外に検証材料を置く設計を示す。いずれも自己申告scopeの完全性やbeliefの真偽を代行しない。

証明マトリクスに残す項目

意思決定に使う表示は、仕様版とhash、発行者と実行境界、declared scopeと外部裏付けの有無、TR-1からTR-4の個別結果、verifiedとattestedの項目ID・件数、完全性方式とcovers、アンカーのauthority・policy・検証結果、validator build、corpus版、観測時刻を一組にすべきだ。

この表示なら、外部アンカーが強くても承認IDの由来は未確認、と言える。行為の門番を実測できても長期アンカーはない、とも言える。強い一部分が弱い部分を飾らず、弱い一部分も強い証拠を無効にしない。

プライバシーには別の未解決問題がある。草案は機微本文の複製を避け、source IDとdigestを使い、redactionを見える形にするよう勧める。一方、append-only履歴を書き換えれば価値が壊れ、削除対象を履歴へ残せば消去にならない。技術レベルで法的判断はできない。

EU AI Actへの言及も同様だ。草案はこの形式だけで義務を実装したとも、法令順守を証明したとも述べない。具体的な法的評価は当事者と監督機関に残る。

01の進歩は、万能な保証を作ったことではない。自分の過大主張、再計算不能、実装の非独立性を記録し、検証可能な範囲を狭く定義し直した点にある。その姿勢を守るには、TR-4を単独の権威へ変えてはならない。

情報源

  1. IETF：Testimony Record 01公開告知
  2. IETF Datatrackerの状態
  3. Testimony Record第01版
  4. Testimony Record第00版
  5. 第00版と第01版の公式差分
  6. Machine Testimonyリポジトリ
  7. 適合性censusディレクトリ
  8. RFC 3161：Time-Stamp Protocol
  9. RFC 8785：JSON Canonicalization Scheme
  10. RFC 9162：Certificate Transparency 2.0
  11. SCITT architecture第22版
  12. Heng Lu：Running-Code Primacy