IETF 126で取り上げられたCBOR/CDDLのDeep Diveを読み解く

こんにちは、富士榮です。

今日は、IETFのセッションで用いられたTechnical Deep Dive（TDD）のスライド資料として、CBORとCDDLを題材に、相互運用性検証やテスト生成の勘所を整理したコンテンツを取り上げます。セッション情報と資料はIETF Datatrackerにまとまっています^[1]。

この資料は、バイナリ表現であるCBORと、その構造を形式的に記述するCDDLを、技術的検討の観点からどう結びつけるかを端的に整理している点が有益です^[1]。CBORはJSONに近いデータモデルを持ちつつ、IoTやセキュア要素を含む制約環境でも扱いやすい効率的なエンコーディングを提供します^[2]。一方CDDLは、CBOR/JSONのデータ構造を機械可読かつ人間にも読みやすい形で定義するための記述言語で、スキーマ由来の例示や制約をテストに直結させやすい特性を持ちます^[3][8]。以下に、関係を俯瞰する概念図（図1）とテスト生成フロー（図2）を示します。

本セッションでは、CDDLのスキーマとサンプル、CBORの決定論的エンコーディングやラウンドトリップ性検証を軸に、実装間の整合とリグレッション防止をどう設計に織り込むかが示されています^[1][2]。

デジタルアイデンティティ分野では、FIDO CTAP2のメッセージやISO/IEC 18013-5のモバイル運転免許証（mDL/mdoc）など、CBOR/COSE系の仕様が増えています^[4][5][10]。また、W3CのVerifiable Credentials（VC）周辺でもJOSE/COSEバインディングの検討が進み、CBOR/COSEでの表現や検証の実装機会が確実に増えています^[6]。Decentralized Identifier（DID）/VCの実装を進める際にも、CDDLを「形式的な単一の真実源（SSOT）」として扱い、そこからテストベクタを体系的に導出する流れは、実装の品質と標準準拠性の両方を押し上げるはずです。

要点

• CDDLを仕様の「単一の真実源」とし、そこから正例・負例・プロパティを導出してテスト作成を自動／半自動化するアプローチが示されています^[1][3]。
• CBORのラウンドトリップ（エンコード→デコード→エンコード）不変性と、決定論的エンコーディング（canonical/diagnosticとの整合）を主要な検査対象として明示します^[2]。
• 相互運用性確認のため、複数実装間で共通のCDDLとテストベクタを共有し、差分の出る境界条件を早期に可視化します^[1]。
• デジタルアイデンティティ分野（FIDO、mDL/mdoc、VCのCOSE表現など）で直接応用できる設計原則とワークフローを提供します^{[4][5][6][10]}。

注目すべき点

注目すべき部分はこちらです。

We use CDDL to specify CBOR data structures and to drive test generation for encoders and decoders.^[1]

CDDLを単なる「添付のスキーマ」に留めず、テスト生成のドライバにまで昇格させる設計思想が明確に表明されています。データ構造の境界条件（選択肢の網羅、数値範囲、可変長配列、マップの必須・任意キー、タグやラベルの扱いなど）をスキーマの表現力で捉え、そこから正例・負例・プロパティベースのテストを機械的に導出できれば、人的レビューに依存しがちな相互運用性のリスクを大きく減らせます^[1][3][8]。この観点は、後方互換性の検証やドラフト更新時のリグレッション対策にも有効です^[2]。

なぜ重要か

アイデンティティのプロトコル実装は、相互運用性が成立して初めて価値を持ちます。DIDやVCの流通基盤、FIDOやmDocの提示検証フローはいずれもマルチベンダー・マルチプラットフォームでの整合が前提で、曖昧なスキーマや実装依存のバグは早期に発見・隔離する必要があります。本Technical Deep Diveが示すCDDL主導のテスト生成・検証フローは、仕様（CDDL）→テストベクタ→リファレンス実装→相互運用イベントという流れを一貫させ、ドラフト段階からバイナリ整合性と境界条件の網羅性を可視化します^[1][3]。特にCBORは、決定論的エンコーディングやタグ利用、COSEとの連携など、実装差が表れやすいポイントが多く、ここを体系的に押さえることは運用上の事故や相互運用性障害の低減に直結します^[2][10]。

実装・標準化への影響

実装者・仕様策定者の双方に、次のような具体的インパクトがあります。

• 単一のCDDLを真実源にする
  • 仕様本文の例示とCDDLに食い違いが出ないよう、CDDLをリポジトリの必須アーティファクトに格上げし、CIで妥当性検査を回します^[3]。
  • CDDLのコントロール演算子（範囲、正規表現、サイズ制約など）を活用し、境界条件がテストに落ちやすい記述にします^[3][8]。
• テストベクタの体系化
  • 正例（should/shall pass）と負例（shall fail）をCDDL由来でペア生成し、仕様更新のたびにCIでリグレッションを検出します^[1][3]。
  • プロパティベーステスト（例：マップの順序に依存しない、未知キーを無視／拒否する、数値境界で桁溢れしない）を明示し、複数実装に共通適用します^[2]。
• 決定論・往復検証の義務化
  • CBORの決定論的エンコード（RFC 8949に準拠）で一致すること、encode→decode→encodeでバイト列が変化しないことを必須チェックにします^[2]。
  • COSE署名（例: Sign1）の対象バイト列が決定論的であることをテストで担保し、検証互換性を高めます^[10]。
• ツール連携と自動化
  • zcbor等のCDDL駆動コード生成・検証ツールでエンコーダ／デコーダのスケルトンやテストを自動生成し、手作業のバグ混入を減らします^[7]。
  • cddlツールやcbor-diagで診断表記（diag）との相互変換を用い、レビュー容易性と機械検査の両立を図ります^[8][9]。
• 適用領域別のヒント
  • FIDO CTAP2では、CBORマップのキー順や既知/未知パラメータの扱いを負例込みで明確化します^[4]。
  • mDL/mdocでは、属性コンテナやCOSE署名対象のバイト列の正規形を中心に、相互運用テストを共有します^[5][10]。
  • VCのCOSE表現では、証明書チェーン検証とCBOR構造検査を分離しつつ、CDDLで構造の真偽をまず確定させる順序を徹底します^[6][10]。

全体として、CDDLをエンコーディング仕様の付録ではなく「テスト生成エンジン」に据える姿勢は、実装者と標準策定者の共通言語を増やし、相互運用性の摩擦を減らします。IETFのTechnical Deep Dive資料という文脈での整理は、現場に持ち帰ってすぐに使える観点が多く、開発や相互運用イベント準備の基盤づくりに役立つと感じます。

参考情報

1. https://datatracker.ietf.org/meeting/126/session/tdd