要約

  • Concise Diagnostic Notation第28版はCBORの可読表現と登録制のアプリ拡張を整理するが、ソースだけで実行時の意味が完結するわけではない。
  • 重要な処理では、草案版、レジストリのスナップショット、拡張実装と版、許可リスト、無視された指示子、警告、生成値、必要なら符号化バイトを固定した「解釈受領書」が要る。

診断表記は、バイナリを人間が確認できる形にする。その強みは、文字が読めるために実行条件まで読めたと思わせる弱点にもなる。

IETF CBORワーキンググループのConcise Diagnostic Notation草案は、CBORデータモデルのテキスト表記を集約し、形式化しようとしている。接頭辞付き文字列では、接頭辞がアプリ拡張を選ぶ。hやb64は文字からバイト列を作り、dtは日時、ipはIPアドレスやプレフィックスを扱う。接頭辞付きシーケンスはパラメータを渡し、一つのデータ項目を返せる。

しかし、ソースが示すのは呼びたい名前である。どのレジストリ時点で名前を解決したか、どの仕様と実装を使ったか、実装の版は何か、運用者がその拡張を有効にしたかまでは自動的に証明しない。オプション、プラグイン構成、許可リスト、警告の保存方法はソース外にある。

第28版自身が限界を明記する。CDNは人間向けで、決定的表現ではない。値から表記へ、表記から値へ戻しても、同じ文字列や同じ符号化バイトになる保証はない。拡張の引数に符号化指示子があっても、その拡張が特別な処理を定義しなければ、消費側は処理するか無視することで受理する。処理しない場合は警告が推奨される。従って「パース成功」は、画面に見えた全記号が結果に反映された証拠ではない。

安全性の節は、運用者が意図しない拡張を攻撃者に起動させないよう求める。明示的な有効化や許可リストを用い、必要なものだけ帯域外で有効にできる。同じ構文を理解する二つのツールが、一方では値を作り、他方では拒否しても、それはローカルな権限設計の違いかもしれない。

登録は名前の衝突を防ぐ

草案はアプリ拡張識別子レジストリを設け、h、b64、t1、b1、dt、ipを実装必須とする。共通名は協調コストを下げるが、レジストリ項目、拡張仕様、実行コード、配備方針を一つにはしない。

登録方針はExpert Reviewである。完全な仕様がまだ利用できない場合や、既に配備された識別子を衝突回避のため登録する場合も想定される。従って「登録済み」は名称調整の証拠であり、完全な意味、全実装の一致、安全な有効化、後続操作の権限をまとめて証明する言葉ではない。

開発環境が全拡張を自動読込し、本番環境が最小許可リストを使う場面を考える。同一ハッシュのファイルでも前者は値を作り、後者は拒否する。違いは文書でなく運用判断にある。あるいは両方が成功しても、一方が指示子を処理し、他方が無視して警告を出し、その警告がCI画面で落ちれば、緑の表示だけが一致する。

第28版の不確実性を消さない

Datatracker上、第28版はCBORワーキンググループの活動中Internet-Draftで、ワーキンググループ最終確認中、IESG状態は「I-D Exists」である。RFCでも承認済み標準でもない。

状態欄にも食い違いがある。本文ヘッダーは「Intended status: Standards Track」、Datatracker APIは「Informational」と記録する。本稿はどちらかを勝手に採用せず、最終状態とも呼ばない。

第28版の注記は、27版から機能削除を反映した差分であり、本文が部分的に不整合で、説明節の一部は技術内容を完全には反映せず誤解を招き得ると述べる。CDNやb1/t1の名称についてもWGの意見がまだない。実際の差分では、CRI拡張、符号化指示子レジストリ、CDN入力のバイナリタグ表現などが削除された。

だから「第28版対応」という一行は足りない。削除機能が実装から消えたか、互換フラグに残るか、どのレジストリ時点を使うか、古い説明に由来する挙動がないかを確かめる必要がある。

「有効」を七つに分ける

少なくとも、ソースの正確なバイトとハッシュ、受理した文法版、識別子を解決したレジストリ、拡張の仕様・実装・版、パラメータと許可設定、指示子の扱いと警告、生成されたデータモデル値と必要時の符号化バイトを別々に記録すべきである。

それぞれは独立して変わる。ソースが同じでも拡張パッケージは更新できる。レジストリが同じでも許可リストは変えられる。値が同じでもバイトは変わり得る。バイトが一致しても、それを使って装置を変更する権限までは生まれない。

そこで必要なのが解釈受領書である。これはDaniel Kadeの運用提案であり、第28版の要件ではない。受領書にはソースハッシュ、草案版、レジストリ時点、識別子、拡張仕様、実装と版、パラメータ、帯域外設定、許可リスト、指示子方針、全警告、結果値の安定表現、必要ならエンコーダ設定とバイトハッシュを入れる。

受領書の終点も重要だ。スキーマ検証、署名、操作権限、ネットワーク変更、事業結果は別の証拠である。一つの「valid」に統合すると、どの現実層で差が生じたか分からなくなる。

凍結した資料は採用率、相互運用試験、具体的製品、脆弱性、事故、性能を証明しない。本稿もそれらを主張しない。拡張モデル、指示子を無視できる条件、レジストリ方針、帯域外有効化、非決定性だけで、外部依存の存在は十分示される。

RFC 8949、8610、4648、3339はCBOR、CDDL、基数符号化、日時の各層を説明するが、二つの配備が同一コードと設定を使うことは保証しない。RFC 9741の決定的符号化は、値が決まった後の問いであり、拡張がどの値を作るかを決めない。