要約

  • SCITTの共同議長は9月25日、Merkle Mountain Range向けCOSE受領証の個人草案を作業部会で採用するか、10月9日まで理由を添えた意見を求めた。
  • 7月のIETF 126で行われたのは査読への参加意思を尋ねる調査であり、草案採用の合意ではない。
  • RFC 9942は、検証可能データ構造が違えば、同じ受領証の枠組みでも相互運用を期待してはならないと注意している。

受領証を受け取った側が最初に知るべきなのは、COSEという外形よりも、その中で何を証明しているかだ。SCITTの議長団が意見を求める draft-bryce-cose-receipts-mmr-profile-03 は、後順に構築される二分Merkle木、いわゆるMerkle Mountain Rangeを対象にする。募集はその文書を今後の作業の土台とするかの判断であり、完成や公刊の準備が整ったという宣言ではない。

議長の案内は、賛否だけでなく理由と、査読・寄稿・実装に協力する意思を問う。締め切りは10月9日だが、その日に標準が成立するわけではない。Datatrackerは現行の-03を個人提出のInternet-Draftと表示し、IETFによる正式な支持はないと明記する。

7月の会議記録も慎重に読む必要がある。IETF 126では在席34人のうち4人が査読する意思を示し、反対は0、意見なしが3だった。質問自体は「この草案を査読するか」であって、「作業部会の仕様として採用するか」ではない。今回のメールによる正式な採用意見募集は、その続きを公開の場で進めるものだ。小さな参加意思調査を採用済みという証拠に変えるべきではない。

草案は二種類の証明を記す。ある要素が署名された木の状態に含まれることを示す証明と、以前の状態が後の状態へ一貫してつながることを示す証明だ。構造の識別子は保護されたCOSEヘッダーに入り、証明そのものは専用の表現を持つ。署名確認の前に検証者が証明から根を再計算するよう、署名対象のペイロードは分離される。単なるメッセージ解読では足りない理由がここにある。

RFC 9942が共通にしたのは受領証の運び方と識別の仕組みであり、異なる木の検証手順を一つにまとめたわけではない。同RFCは構造をまたぐ相互運用を想定しないよう求めている。SCITTにはCCF向けの別の作業部会草案もある。一方の証明を扱える検証者が、もう一方にも対応すると推定してはならない。草案が採用されれば作業対象は広がり得るが、既存ソフトの機能が増えるわけではない。

利用者に必要なのは、対応する構造識別子、証明の種類、規則の版と、再現可能な検査結果の組だ。これはDaniel Kadeによる運用上の確認項目であり、SCITTが定めた義務ではない。草案自身も、包含の証明は記録の正当性まで判断せず、初めから記録されなかった項目の発見も対象外としている。今回の焦点はその一般論ではなく、特定の証明方式を誰が整備し、誰が実際に読めるのかという境界にある。

出典