要点

  • CBOR作業部会の現行ドラフトは、general、preferred-plus、deterministicという三つの集合を定義する。決定的シリアル化はpreferred-plusに、決定的に符号化したマップキーのバイト列による辞書順ソートを加える。結果は再現可能になるが、マップに業務上の順序が生まれるわけではない。
  • 決定性が必要なのは、署名、ハッシュ、コンテンツアドレス、キャッシュキーなどの入力を当事者が別々に組み立てる場合である。保護対象の生バイトがそのまま届く場合には通常不要であり、同一バイトは完全性、鮮度、認可、効果の証明にもならない。

障害票には「署名不正」とだけ書かれていた。送信サービスのログにも受信サービスのログにも、同じ整数と同じ文字列を持つ同じマップが出ていた。ところが16進表現を比べると、一方は引数を長い合法形式で出力し、挿入順でキーを並べていた。もう一方は最短形式を使い、キーをソートしていた。どちらも有効なCBORだったが、暗号が見たのは異なるバイト列だった。

draft-ietf-cbor-serialization-08は、この空白に名前を与える。2026年7月29日付の文書は、CBOR作業部会のWorking Group Last Callにある現役Internet-Draftで、Datatracker上のIESG状態はI-D Existsである。最終RFCでも、製品の適合証明でもない。重要なのは、プロトコル設計者が表現の自由をどこまで残すかを三種類の契約として明示できる点だ。

CBORのデータモデルとバイト表現は同じ層ではない。一つの値に複数の合法な符号化があり得る。その柔軟性はストリーミングや制約機器に役立つ。問題は、後段がバイト列を署名入力や識別子として使うのに、どの符号化を選ぶか合意していないときに起きる。

三つの集合は優劣表ではない

CBORベースのプロトコルが何も指定しない場合、理論上の既定はgeneral serializationである。対応する型について、デコーダーは確定長と不定長を含む許可された符号化を受け入れる必要がある。ドラフトは同時に、この広い受理能力が現実には十分普及していないと述べる。「CBOR対応」というラベルだけでは、何を受け取れるか分からない。

preferred-plus serializationはエンコーダーの自由を狭める。引数は最短形、浮動小数点は値を正確に保つ最短表現、長さは確定長とし、規定のNaN処理と整数・bignumの正規化を用いる。多くのプロトコル向けの実務的な選択だが、マップのソートは求めない。

deterministic serializationはpreferred-plusに一つの中心規則を加える。各キーを決定的に符号化したバイト列で、マップ項目をバイト単位の辞書順に並べる。データモデルと周辺規則が確定していれば、独立したエンコーダーが同一結果へ収束できる。

最後の集合が常に最良なのではない。generalは、不定長で逐次出力する能力、通常整数とbignumを区別するモデル、非自明なNaNペイロードなどを残す。決定性は再現性のためにそれらを外す。必要な性質から選ぶべきで、他の合法表現を劣ったものと扱うべきではない。

出力と入力も別契約である。deterministic decodingはpreferred-plus decoding以上の条件を加えない。決定的な一形式だけを出しつつ、受信時には広い集合を認める設計は可能だ。非決定的入力を拒否したいなら、端点プロトコルが別途そう定め、互換性を試験しなければならない。

バイトが運ばれるのか、作り直されるのか

送信者がCBORペイロードの生バイトに署名し、その同じバイトを署名と一緒に送るなら、受信者は受け取った列を検証できる。値をデコードして同じ表現を再生成する必要はない。ドラフトが示すCOSE payloadはこの型である。暗号が要求するのは保護対象バイトの一致であり、システム中の全CBORを一意化することではない。

双方が入力を別々に構築する場合は違う。COSEのSig_structureは署名者と検証者がそれぞれ組み立てる。引数幅、浮動小数点、キー順の既定値が違えば、値が同じでも署名入力は変わる。コンテンツアドレス、キャッシュキー、重複排除、再現可能マニフェストにも同じ境界がある。

したがって決定性は局所的に指定する。Sig_structureの規則が、内包ペイロードや外側の封筒まで自動的に支配するわけではない。一か所の再構成問題を解くためにプラットフォーム全体を凍結すれば、ストリーミングや既存データに不要な負担を課す。

設計審査では、どのバイトが無変更で届くか、どのオブジェクトが一度デコードされ再符号化されるかを図にする。プロキシやキャッシュが「透過的」と称して署名済みペイロードを再符号化していないかも確認する。

マップキーのソートは業務順序ではない

CBORの一般データモデルでマップは順序を持たない。決定的ソートは反復可能なバイト配置を選ぶだけで、評価順、優先順位、表示順を定めない。

デバッガーはキーを一列に見せるため、誤解しやすい。ある言語は挿入順を保持し、あるライブラリは受信順を返し、ハッシュ表は別の順で走査する。それでも値としては同じマップである。順序が意味を持つなら、配列、優先度フィールド、明示規則で表現すべきだ。

ソートは重複キー、許可するタグ、未知フィールド、スキーマ更新、等価性も決めない。マップがなければpreferred-plusが結果的に決定的になることはあるが、欠落フィールドが認可を変えるか、タグが許可されるかまでは答えない。

バイト同一性は意味の同一性より厳しすぎる場合がある。アプリケーション上等価な二値をハッシュは別物にする。他方、同じバイトでも内容は期限切れ、不十分、悪意あるものかもしれない。文字列正規化、数値領域、既定値、タグ解釈は端点プロトコルの責任だ。

「canonical CBOR」という無限定の表現も避ける。別文書draft-mcnally-deterministic-cbor-17はCBORをさらに絞るアプリケーションプロファイルで、その制約を作業部会ドラフトへ黙って移せない。監査にはプロファイル名と版が必要である。

有効な署名が証明する範囲

決定的に再構成したバイトで署名検証が成功すれば、特定の鍵とアルゴリズムがその列を保護したという強い受領証になる。しかし、その列が判断に必要な事実をすべて含むとは証明しない。

スキーマの十分性、タグの許容、時刻の鮮度、署名者の現時点の権限、重要な任意フィールドの欠落、ローカルポリシーの許可は別問題である。承認された操作が実際に完了したかも署名には見えない。

情報モデル、CBORモデル、シリアル化バイト、暗号検証、意味検証、ポリシー、認可、実行試行、観測結果に別々の受領証を持たせる。一つの「verified」フラグに統合すると、暗号の限定的証拠が組織の権限へ膨張する。

CDDLはCBORデータ形状を記述でき、ドラフトのシリアル化制御は符号化要件も表現できる。しかしスキーマは実行コードでも認可でもない。CDDL一致から、動いたパーサー版、重複キー方針、信頼アンカー、状態変更の完了は分からない。

COSEやCWTのような枠組みは多数の端点プロトコルを支える。すべての再構成、ストリーミング、業務条件を枠組み側で知ることはできない。枠組みが指定しないとき、ドラフトはpreferred-plusを推奨し、組み込むプロトコルに最終要件を委ねる。ライブラリ既定値はその代わりにならない。

実際のデコーダーを測る

generalの理論的受理範囲と実装の現実には差がある。ある製品は不定長文字列を拒否し、別の製品は代替幅を未試験のまま受け入れ、さらに別の実装はbignumを変換するかもしれない。

実行証拠にはライブラリ、版、ビルド、オプション、エンコーダーモード、デコーダー受理集合、スキーマ版、入力値、出力バイト、受理・拒否した変種、後続結果を含める。ゴールデンベクトルは独立実装間で交換する。同じライブラリの往復は自分の前提を再現するだけである。

合法なgeneral形式をgeneral対応の受信機へ送り、非最短形式をpreferred-plusゲートへ送り、挿入順を変えたマップを比較する。整数とbignum、確定長と不定長、浮動小数点幅、NaNも境界試験する。「解析成功」だけでなく、得られた値と通った政策経路を記録する。

特殊値と隠れた情報モデル

preferred-plusは正確な最短浮動小数点表現と、規定された平凡なquiet NaNを選ぶ。だがNaNのペイロードを保存し意味づける領域もある。そのビットが情報モデルの一部なら、別のシリアル化契約が必要である。

bignumと通常整数を区別する場合、全長が未確定のまま送信を始める場合も同じだ。generalまたは特殊プロファイルが正しいことはある。危険なのは例外自体ではなく、エンコーダーの隠れた設定として存在し、端点合意になっていないことだ。

最小初期仕様は、相互運用に必要な最小面を共有する。独立再構成にだけ決定性を置き、通常交換には条件が合えばpreferred-plusを使い、必要な場所だけgeneralや特殊形式を残す。一つの署名入力のために全将来選択を中央化しない。

一つの隠れ通信路を狭める

同じ値の複数表現は、デコード後に消える情報を運べる。侵害されたエンコーダーが引数幅や不定長分割を選び、ビットを漏らすことも可能だ。preferred-plusと決定性はこの自由を減らし、予期しない差異を検出しやすくする。

しかし全漏えいを排除しない。攻撃者は許可された値、時刻、タグ、別層のパディング、パケットの大きさや時系列を利用できる。試験から言えるのは、固定モデル入力に対してこのビルドが期待バイトを出したことまでである。

プライバシーと保存期間を管理しつつ、信頼境界で正規化モデルと生バイトのダイジェストを記録する価値はある。決定性を約束した生産者が同じテストで別ダイジェストを出せば、入力、版、設定を調査する。差異は手掛かりであって侵害の自動判定ではない。

ライブラリ更新後も残る受領証

有用な記録は、プロトコルと版、各境界の集合、CBORモデルプロファイル、タグとキー型、重複方針、エンコーダーとデコーダーの版・設定、スキーマ、入力、実バイトまたは追跡可能なダイジェスト、暗号入力、鍵の来歴、検証、意味検査、政策、認可、実行、効果を結ぶ。

責任は分ける。プロトコル設計者はバイト境界、実装者は送受信証拠、セキュリティはパーサーと暗号、アプリ所有者は意味、政策所有者は認可、運用者は効果を持つ。限定された取引識別子と時刻で結合しても、一つの断言へ潰さない。

Lu HengのRunning-Code Primacyは、設計書のラベルではなく実際に走った版と設定を問う。Reality Layersは、決定的バイトがスキーマの権威を借り、署名が認可の権威を借りることを防ぐ。CBORの決定性が解くのは、独立エンコーダーが同一バイトへ到達するという明確な問題であり、それ以上ではない。

出典