要約

  • draft-ietf-scitt-receipts-ccf-profile-04の包含証明は、葉と左右を示す兄弟ハッシュ列を持つが、明示的な葉インデックスも木のサイズも持たない。
  • 候補の葉からルートを再計算し、署名対象と照合する処理は成立する。注意すべきなのは、その成功を順序や位置の証明として使う場合だ。

整った二分木だけを見ていると、経路は住所のように見える。ところが葉が3枚の木では、実際のインデックス2の経路が1と読める。5枚なら4が1に、9枚なら8が1になる。同じ1という経路に、木全体の形が違うだけで別の番地が割り当てられる。

この指摘は、IETFが『CCF Profile for COSE Receipts』第04版について行っているLast Callで表面化した。Datatrackerでは、IETFストリーム、想定ステータスProposed Standard、IESG提出済み、現在は「In Last Call」と記録されている。期間は2026年8月24日から9月7日までだ。現時点ではInternet-Draftであり、RFCでも、採択済み・否決済みの標準でもない。

正しいルート値は葉の番地ではない

草案の木はCertificate Transparencyと同系統の分割則を用いる。葉が複数ある場合、総数より小さい最大の2の累乗で左右に分ける。葉の総数が2の累乗なら木は均等になる。それ以外では、右側に小さな部分木が残る。

第3節の証明は、候補の葉と兄弟ハッシュの配列で構成される。各ハッシュには左か右かを示すブール値が付く。草案は、この方向列を葉からルートへ読めば、インデックスの二進分解として扱えるとしている。均衡木ならそうなる。しかし、草案自身の分割則で生まれるすべての形に当てはまるわけではない。

9月6日、Henri Sirkkavaaraは自分のレビューを訂正した。葉数2から11を調べると、2、4、8は全葉で一致したが、2の累乗ではないすべてのサイズに少なくとも一つ誤って復元される葉があった。

Emek Can Dogruも独立に再現し、11行のプログラムを公開した。葉数を1,024まで広げると、全葉で一致したのは2の累乗である10種類だけだった。残る1,013種類には少なくとも一つ不一致がある。公開された再現コードは、現象が暗号攻撃ではなく木の形から生じることを端的に示す。

それでも、第3.2節の包含検証は壊れない。検証者は候補葉のハッシュから始め、指定された左右に従って兄弟ハッシュを結合し、ルートを得る。そのルートがCOSE署名で保護された値と一致すれば、候補葉の包含は確認できる。通し番号の復元は、この計算の前提ではない。

つまり、証明は「この候補が署名済みルートの下にあるか」に答える。「何番目だったか」まで答えるとは限らない。問題は暗号ライブラリではなく、その後段で一つ目の答えを二つ目として表示・利用する処理にある。

参照仕様は座標系を明示している

RFC 9162のCertificate Transparency Version 2.0は、包含証明の検証に木のサイズと葉インデックスを明示的に渡す。RFC 9942のCOSEレシートプロファイルも両方を符号化し、インデックスは特定の木サイズに対して相対的だと説明する。

二つの値は単なる実装補助ではない。「位置」という主張の座標系そのものだ。木のサイズを欠いた番号は不完全であり、サイズも番号もない方向列には複数の全体位置が対応し得る。

CCFの運用環境が別の手掛かりを持つ場合はある。MicrosoftのCCFレシート検証文書は、トランザクションIDを指定してレシートを取得する流れを示し、commit_evidenceには完全なTxIDが現れ得る。SCITTプロファイルにもinternal-evidenceという文字列がある。ただし、検証者はそれを無視でき、相互運用可能な葉位置の文法としては定義されていない。ローカルDBで位置を引けることと、レシート自体が位置を運ぶことは別だ。

レビュー参加者はこの点をnon-blockingとし、第04版の公開支持を維持した。偽造署名、ハッシュ衝突、不正ルート、実装侵害を報告したものではない。対処案についての続報でSirkkavaaraは、経路長だけでも木サイズが必要になるため、明示的なインデックスが分かりやすいとした。

権限の膨張は検証後に起きる

レシートは、ソフトウェア公開判定、監査証跡、透明性ダッシュボード、自動化された許可処理へ渡される。必要なのが包含だけなら、現在の証明で足りる場合がある。先後関係や連番で処分・停止を決めるなら、その座標を成り立たせる入力も保存しなければならない。

Heng Luの最小初期仕様は、共通部分を検証可能な最小値に限定し、強い保証を必要とする現場が明示的に採用する設計を促す。現実の層という整理は、数学的な包含関係と組織が語る順序を混同させない。動くコードの優先は、緑色の表示ではなく、検証器が実際に使った値を証拠として残すことを求める。

このプロファイルは用途を狭く名乗ればよい。署名したのが包含なら包含レシートとして使う。位置に効果を持たせるなら、木サイズか明示インデックスを追加で束縛する。

出典

  1. IETF Datatrackerの文書情報
  2. Datatrackerのイベント履歴
  3. CCF Profile for COSE Receipts 第04版
  4. IETF Last Call告知
  5. Henri Sirkkavaaraの訂正
  6. Emek Can Dogruの独立再現
  7. 対処案に関する続報
  8. 再現コード
  9. RFC 9162
  10. RFC 9942
  11. RFC 9943
  12. CCFレシート検証文書
  13. Heng Lu：最小初期仕様
  14. Heng Lu：現実の層
  15. Heng Lu：動くコードの優先