要約

  • Wathīqaの個人Internet-Draftは、同じコンテンツアドレスを異なる署名方式で更新し、直前リンクの正規ハッシュを次のリンクに取り込む証拠チェーンを提案する。
  • 透明性ログの包含レシートは「遅くともこの時刻には存在した」ことを示す認証済み材料とされる。一方、ランダムネス・ビーコンのアンカーは「この時刻より前ではない」というメタデータを持つが、リビジョン00ではビーコン証明を検証しない。
  • ウィットネスの検査は、呼び出し側が信頼する公開鍵集合Wを渡した場合に限って必須になる。Wがなければ、内容、署名、前リンクのハッシュだけでチェーンを受理し得る。
  • 文書はExperimentalを意図した個人草案であり、IETF標準でもワーキンググループの決定でもない。完全な実装があると記す一方、独立した暗号レビューは未実施で、リポジトリや固定コミットも示されていない。
  • 運用上は、チェーンの暗号学的妥当性、特定のウィットネス方針で確認した時間上限、未確認の時間下限、ローカル方針による採否を別々に返す必要がある。

守るべきなのは署名だけでなく更新の順番だ

保存対象のビット列が変わらなくても、その署名に対する評価は変わる。新しい解析手法、鍵の侵害、安全強度に関する指針の変更によって、昨日まで許容された方式が将来は使えなくなる。旧方式が破られた後に新しい署名を重ねても、破られる前のどの版が真正だったかを後から決めることはできない。

RFC 4998のEvidence Record Syntaxは、この先回りを前提にしている。アーカイブ・タイムスタンプは、利用中のアルゴリズムが弱くなるか証明書が無効になる前に更新しなければならない。同RFCは、アルゴリズムの劣化や侵害リスク、寿命に関する情報を構文の外側に置く。形式は判断結果を保存できるが、暗号研究の将来を観測することはできない。

Wathīqaリビジョン00は、署名方式そのものを切り替えられるチェーンを設計する。最初に保存データのコンテンツアドレスを作り、各リンクがそのアドレスを署名する。後続リンクは、自分の方式を明記するとともに、前リンクの正規表現のハッシュを含める。草案が挙げるML-DSAとSLH-DSAは、それぞれFIPS 204とFIPS 205で標準化されている。ただし、アルゴリズムの標準化はWathīqaの設計や実装を検証するものではなく、採用組織の更新時期も決めない。

ログは上限を示し、ビーコンはまだ主張を運ぶ

時間を挟む二つの仕組みは、向きが異なる。透明性ログ側では、リンクの署名をMerkle木の葉にし、包含経路で署名付きツリーヘッドへ結ぶ。ログ鍵を信頼し、経路と署名を検証できれば、そのツリーヘッドの時刻までにリンクがログへ入っていたと示せる。これはRFC 6962の包含証明などを参照した「not-after」の証拠である。

もう一方は、まだ公表されていない公開乱数を利用する。ある時刻に初めて出た予測不能な値をリンクへ結び付け、そのパルス自体を認証できれば、リンクがパルス公開前に完成していなかったと示せる。NIST Randomness Beacon 2.0は、番号、時刻、署名、前パルスのハッシュを持つ出力を公開する。NISTのページは2.0を現在もベータ版かつ作業中と表記している。

Wathīqaは、このパルスに関する値をリンクへ含める。しかしリビジョン00の検証器は、パルスの署名や証明を確認しない。アンカーに記録されたハッシュとリンク署名の対応は検査するため、後から別のアンカーへ単純に差し替えることは難しい。それでも、記載されたパルスをNISTが本当に発行したことは証明されない。

草案のSecurity Considerationsは、この限界を明示している。攻撃者は任意のnot-beforeメタデータを設定でき、現行アンカーを認証済み時刻として頼ってはならない。これは発見された実装攻撃ではない。提案者自身が残した仕様上の境界である。画面設計が二つの時刻を同じ色で表示すれば、その正直な境界を消してしまう。

Wはオプションだが、結論への影響は大きい

ログのレシートも、ファイルに存在するだけでは検証済みにならない。手順は、信頼するウィットネス公開鍵の集合Wを任意の入力として受け取る。Wが与えられた場合、全リンクに有効な包含レシートを求め、署名付きツリーヘッドがW内の鍵で検証できること、さらに時刻が後戻りしないことを確認する。

Wが省略されると、これらの条件は走らない。コンテンツアドレス、各署名、前リンクへのコミットメントは検査されるため、構造と暗号だけの意味で受理される可能性がある。つまり同じバイト列に対する二つの正常終了が、異なる主張を表す。一方は「チェーンが整合した」、他方は「指定したウィットネス方針の下で時間上限も検証した」である。

一つの緑色チェックは、この差を伝えられない。監査者はWが空だったことに気付かず、組織間では別々の鍵リストを用いた結論が同じものとして交換される恐れがある。鍵はローテーションし、ログ運営者は交代し、保存期間は組織の寿命を越え得る。

草案は、ウィットネス鍵の継承を定足数で承認し、追記専用で記録し、長寿命のアンカーへ固定する案を勧める。必要な論点を指してはいるが、定足数の構成、侵害時の緊急切替、競合履歴の扱い、運営組織が消えた後の保管者までは定めていない。暗号チェーンの可搬性と、信頼方針の可搬性は別問題である。

公開された草案と稼働する仕組みの間

IETF Datatrackerでは、この文書はRFC streamを持たない個人Internet-Draftである。日付は2026年9月3日、意図する状態はExperimental、有効期限は2027年3月7日。9月5日のI-D告知は初版が流通した証拠であって、IETFの支持やWG採用を意味しない。

草案は、Pythonの完全な参照実装と、正規チェーンハッシュを同一バイトで再現するJavaScriptおよびRustの検証器、共有適合ベクトルが存在すると述べる。その一方で、セキュリティの論証は独立した暗号レビューを受けていないとも記す。リビジョン00にはリポジトリURLもコミットIDもないため、本稿では実装の主張を独立に再現していない。

文書内部にも、実装対象を固定する前に直すべき継ぎ目がある。4.3節は、ラップしたASN.1 DER形式をプロファイル版3と呼び、詳細モジュールは将来本文へ入れるまで外部Pythonファイルを正本とするとしている。ところが付録Bは現在のDERプロファイルを版4とし、版1〜3は引き続きデコード可能だが出力は版4だけだと述べる。RFC 9169にはERSの現代的なASN.1モジュールが公開されているものの、Wathīqa固有の二つの版表示を仲裁するものではない。

初稿の編集漏れである可能性は高い。これだけで脆弱性や実装障害を主張することはできない。ただし、仕様、コード、ベクトル、識別子が一つの不変なリリースを指すまでは、第三者が同じ対象を実装したとは確認できない。提案される二つのメディアタイプも、IANAへの手続きは未申請と記されている。

現時点で証明できる範囲

今の草案から局所的に検証できるものは明確だ。保存データからコンテンツアドレスを計算し直し、各署名を確認し、リンクの順序を前ハッシュで追える。Wを明示すれば、信頼するログのレシートを使ってnot-afterの境界を加えられる。定義された手順だけでは、not-before側はまだ認証できない。

さらに、記録はアルゴリズムの許容期限を決めず、暗号情報の提供者も、信頼するログも、鍵継承の責任者も選ばない。これらは利用者側の正当な判断である。問題はローカルであることではなく、ローカルの判断をファイル固有の性質に見せる出力である。

Wathīqaを評価するなら、万能な耐量子証明としてではなく、更新可能な共通フォーマットと利用者の方針を切り分ける初期提案として読むべきだ。欠けた下限を明記した点は、その切り分けを完成させる出発点になる。