要約

  • リビジョン03では、typed digest reference の処理結果を Malformed、Unresolved、Failed、Verified の四つに分ける。構文が正しく署名対象であることだけでは content binding の証拠にならない。
  • Verified が示すのは、認可された一つの digest context で取得物を再計算し、宣言された表現のまま一致したことだけである。発行者の権限、鮮度、妥当性、方針適合、利用許可は別判定だ。
  • 運用記録には carrier、構文、プロファイル、文脈選択、取得、実行、比較、署名、発行者、Transparency Service の receipt、対象物評価、ローカル決定を別々に残す必要がある。

リビジョン03は一つの成功表示を四つの結果へ戻した

対象文書 draft-mih-sokolov-scitt-payload-binding-03 の日付は2026年9月5日である。Datatracker 上は個人提出の active Internet-Draft で、著者は SCITT Working Group を希望する議論先としている。しかし IETF の stream、担当 AD、telechat、合意状態はなく、RFC でもない。以下は提案された境界の分析であり、標準化済み機能や導入実績の報告ではない。

03版は CPB を payload-neutral な仕組みとして整理し、typed digest reference を四メンバーの抽象情報モデルにした。payload profile は独自の payload 内表現を定義でき、共通側は COSE protected header に置く任意の cpb-refs 形式を一つ用意する。02版までの artifact-type registry 構想を CPB から外し、受け入れる artifact type と digest context は consuming profile が安定した規範参照で指定する。

これにより、検証ライブラリが「見たことのあるハッシュ」を勝手に解釈する余地が狭まる。03版は reference processing を Malformed、Unresolved、Failed、Verified に分類し、COSE signature の結果と issuer authentication を別に返す。RFC 9943 の Full-Content Mode と RFC 9995 の Hash Envelope Mode も区別し、一つの Signed Statement に typed-reference carrier を一つしか許さない。

整形式の次に Unresolved がある

Malformed は入口の失敗だ。必須メンバーの欠落、CBOR type の違い、サイズや配列数の超過、重複 key、同一 tuple の反復、閉じた内側 map への未知 key はここに入る。cpb-refs の一項でも malformed なら、同じ header 値に含まれる別項だけを Verified として救済してはならない。first-wins、last-wins、部分成功、重複による重み付けも禁止される。

しかし構文合格は証拠の成立ではない。Unresolved は、参照が正しくても consuming profile が認可する digest context を一つに絞れない場合に使う。対象 artifact を取得できない場合、あるいは正当な context は判明しても実装がその構築法を実行できない場合も同じだ。ここには「不一致」という観測はない。あるのは検証を終えられないという事実である。

Failed では一つの context が選ばれている。そのうえで digest_alg や representation が宣言と衝突した、token が恒久的に未定義または禁止されている、または取得物を再計算した値が一致しなかった。Unresolved と Failed を一つの error にまとめると、設定の曖昧さ、保管障害、実装能力不足、実データ不一致の責任境界が消える。

Verified に達するには、一つの認可 context を選択し、artifact を取得し、その context の field set、exclusion set、canonicalization、domain separation、preimage encoding、hash、出力表現を実行し、同じ表現で一致させる必要がある。それが証明するのは、その context における content binding である。

type と purpose はポリシーへの接続点

Digest context は hash algorithm の別名ではない。入力フィールド、除外フィールド、正規化法、ドメイン分離、preimage の符号化、出力表現まで含む。見た目が同じ hex でも、二つの値の完全な context が互換だと確立されなければ比較できない。

context 選択には reference の type と任意の purpose を使う。ある type に認可 context が一つなら purpose は省略できるが、書くなら一致しなければならない。複数 context を許すなら、それぞれに異なる非空 purpose が必要で、reference 側も明示する。該当なし、または規範情報が複数候補を残す状態は Unresolved である。

実装は配列順、digest の長さ、payload の形、慣れた文字列、可変な registry snapshot から選んではならない。この制約は責任を consuming profile に戻す。汎用ライブラリは RFC 8785 JCS や SHA-256 を実行できても、組織がどの profile 版と除外規則を承認したかは決められない。

payload に carried derived identifier があっても、それは advisory である。verifier は規範的な exclusion set と、もし定義されていれば明示された変換順に従って再計算する。producer の値を読み、それを同じ producer の値と照合する実装は、検証ではなく転記を行っている。

carrier は一つ、二つの入力集合は統合しない

CPB を用いる profile は、各 Signed Statement で cpb-refs envelope carriage か profile-owned payload carriage のどちらかを選ぶ。両方を使った statement は nonconforming であり、profile-aware verifier は二つを merge したり一方を優先したりしてはならない。

この規則がなければ、payload 側の参照が protected header を上書きしたように見える実装、重複を多数決として数える実装、解析順で結果が変わる実装が生まれる。carrier の単一化は単なる美観ではなく、どの入力集合を判定したかを一意にする admission rule だ。

cpb-refs は protected header にのみ置かれ、1件から64件の配列を持つ。各 map は整数 key で type、任意 purpose、digest_alg、digest を表す。内側 map は閉じており、値の type と長さにも境界がある。duplicate key は通常のオブジェクトへ変換して消える前に検出しなければならない。

一方、CDDL はデータモデルを規定するのであって、CBOR の一種類の wire encoding だけを正解にしない。fixture と byte 列が違うだけで適合する encoding を拒否してはならない。この点は、同じ COSE 署名入力に至る複数 framing の exact-wire hash を扱った既存記事と区別できる。本稿の焦点は、入った reference が一つの認可 context と外部 artifact を結べるかどうかだ。

表現の自動変換は新しいプロトコル処理である

32-byte の raw digest、64文字の小文字 hexadecimal、prefix 付き text は別の representation である。context が raw octets を指定しているのに hex text が届いた場合、verifier は親切心で変換してはならない。規格または適用 profile が変換と比較後の表現を定義している場合だけ実行できる。

取得も比較の一部だ。context が一意でも artifact が取れなければ Unresolved である。ネットワーク停止、access denial、retention object の消失、cache miss、未対応 retrieval scheme はそれぞれ観測可能な原因だ。後の retry で取れたとしても、最初の未解決イベントは消さない方がよい。

構築法を実装していない場合も Unresolved だ。別の verifier へ route する、承認済み機能を追加する、保留する、ローカル方針で拒否するという選択肢がある。できない検証を、他コンポーネントの過去の成功表示で埋めてはならない。

signature、issuer、reference、receipt は直列の同義語ではない

cpb-refs は protected header のため signature-covered である。ただし署名が暗号学的に有効でも、その key が asserted issuer を代表する権限までは確立しない。03版は Signature-Valid と Issuer-Authenticated を別状態として定義する。

Issuer-Authenticated になっても cited artifact は Verified ではない。逆に digest の再計算が一致しても、失敗した signature の issuer を認証できない。UI と API は statement の signature result と各 reference result を別々に返すべきである。

SCITT receipt も独立している。RFC 9943 の receipt-backed status を主張するなら、信頼する Transparency Service の key で receipt を検証し、protected header の VDS identifier に従う。receipt が登録の証拠を与えても、参照先を取得せずに content binding を完成させることはない。

さらに Verified reference から artifact validity、scope、freshness、revocation、policy compliance、semantic acceptance、application authorization を導いてはならない。CPB は再利用可能な join を与える。調達、配備、実行という帰結は、その結果を負担する主体が決める。

protected は confidential ではない

COSE protected header は署名後に改変検知できるが暗号化されない。cpb-refs は type、purpose、algorithm、digest と citation graph を公開する。stable digest は複数 statement を相関させ、低エントロピー artifact は辞書攻撃の対象になり得る。

公開 header に置くべきでない関連なら、草案は cpb-refs を省略するか、profile-defined confidential payload carrier を用いるよう示す。選択は配布前に必要だ。署名済み graph が複製された後で access control を変更しても、関係は回収できない。

IANA への request と allocation を分ける

03版は Canonicalization Algorithm Registry の作成と cpb-refs COSE Header Parameter の登録を IANA に要求する。これは草案内の request であって、完了済み allocation の証拠ではない。試験実装は draft revision、provisional coordinate、migration assumption を記録する必要がある。

Heng Lu の minimum initial specification の視点では、共有層は小さな事実だけを運ぶ方が長生きする。一つの宣言 context を一つの取得物へ適用し、一つの比較結果を得た。その先の意味、freshness、revocation、採用判断を各 participant に残すことで、将来の profile が現在の一組織の default に拘束されない。

範囲と不確実性

本稿は IETF adoption、WG consensus、IANA action、製品対応、実運用、incident、benchmark、exploit、prevalence を主張しない。appendix の field instance を広い interoperability の証拠として使わない。03版は変更、置換、失効し得る。

canonicalization が payload の意味を正しくするとも言わない。四状態の処理が与えるのは限定された evidence record である。signature、issuer、receipt、reference、appraisal、decision、observed effect は異なる owner と問いを持つため、別々に保持する。

情報源