要点

  • 9月14日に公開されたLAMPSワーキンググループ草案の改訂03は、承認されればRFC 5652を更新し、CMS SignedDataの新規用途でid-dataを禁止する。
  • 新規かどうかは、将来の文書発行日以降に、その用途を仕様が初めて定義したかで決まる。ソフトウェアの実装日や配備日を基準にはしない。
  • 既存用途には同じ絶対禁止ではなく、移行と検証の指針が適用される。移行経路なしの一律変更が、配備済み送信者との相互運用性を壊し得るためだ。
  • 現在はBCPを目指す有効なInternet-Draftであり、RFCでも採択済み規則でもない。攻撃発生や特定製品の脆弱性を示す資料でもない。

境界日はまだ存在しない

改訂03は、ヘッダーと要約に重要な一文を加えた。承認されれば、現在のCryptographic Message Syntax標準であるRFC 5652を更新し、新規のCMS SignedData用途にid-dataを使わせないという内容だ。

追加された定義によれば、将来この文書が発行された日以降に、ある応用でSignedDataをどう生成・処理するかを初めて定める仕様が「新規用途」になる。その後の仕様がRFCかどうか、IANAにコンテンツタイプを登録するかどうかは問わない。発行日前に定義済みなら既存用途である。

形式上は鮮明な線だが、今日すでに効力を持つ線ではない。Datatrackerが示すのは、予定ステータスをBest Current Practiceとする作業中のWG草案だ。RFC 2026もInternet-Draftを作業文書と位置付ける。改訂03は今の審議を動かせるが、提出されたというだけでSTD 70を書き換えることはできない。

仕様年齢と配備年齢は一致しない

公式差分には、区別すべき二つの時計がある。

一つは、最初の仕様の日付で用途を分類する時計だ。もう一つは、新規用途の禁止が配備済み実装の適合性を遡って変えない、とする説明である。矛盾はしないが、証拠は異なる。仕様だけが先に存在して配備が進まないことも、基礎仕様の何年も後に実装が出ることも、後継版の登場後も古い送信者が残ることもある。

草案は、この三つを結ぶ実態調査を公開しておらず、公開したとも述べていない。付録はid-dataを使うRFCを列挙し、適用可能性を検討する。しかしRFCへの参照はインストール台数ではない。IANAの行も識別子と参照先は示せるが、実際のコード経路、受信者によるsignedAttrs検査、鍵のプロトコル間共用までは証明しない。

安全性はラベルではなく挙動にかかる。RFC 5652は、封入タイプがid-dataならsignedAttrsを省略できる。草案は、その差を使って、署名者が明示的に意図しなかった構造でも署名検証が成立し得ると説明する。同時に、適用範囲も限定する。署名属性を必須にする既存プロトコルがあり、正しい受信検査は攻撃を止め、メッセージ構造が攻撃可能性を狭める場合があり、他の緩和策もある。「既存」は「脆弱」の別名ではなく、「新規」も安全な実装の証明ではない。

互換性は例外ではなく設計条件

新規用途はid-dataをMUST NOTで禁止される。MIMEコンテンツでは、より用途限定の識別子に理由がない限り、提案中のmimeDataをSHOULDで使う。草案はIANAに三つの処理を求めるが、値はまだTBDだ。現在のSMI NumbersとCMS Inner Content Typesは、草案の空欄を自動的に割当済みにしない。

既存用途では、プロトコル更新時にid-dataを廃止することが推奨される。残すなら、安全上のトレードオフを査読者が評価できる理由を書く。後方互換の拡張だけを加える時に破壊的移行を強いると、拡張自体が配備されないことがある。一方、メジャー版や元から互換性を壊す変更は、移行に適した機会になり得る。

これは隠れた免除ではなく、明記された相互運用性判断である。既存送信者は、厳格化された規則どおりにsignedAttrsを生成しないかもしれない。一律のMUSTは移行路ができる前に正当な旧トラフィックを拒絶させ得る。必要なのは裁量の消去ではなく、どの仕様で誰が裁量を使い、何を根拠にいつ見直すかを残すことだ。

鍵とアプリケーションにも境界がある

改訂03は鍵分離の節を新設した。あるプロトコルで署名属性を必須にしても、同じ鍵が属性を必須としない旧版や別プロトコルでも使われれば、対策は完結しない。別鍵を用いるか、その鍵による全署名処理に同じ緩和策を適用する考え方が示される。

汎用CMSライブラリーについても役割が分かれる。新規用途では、期待するコンテンツタイプと署名属性の存在を検査する。ライブラリーがプロトコル固有の判断を持たないなら、受信タイプをアプリケーション層へ渡し、そこで規則を実行できるようにしなければならない。

仕様作成者、ライブラリー保守者、アプリケーション運営者、鍵管理者、IANAが別々の状態を持つ。どの一者も、配備全体が安全に移行したとは単独で証明できない。

全体判定より移行台帳

公開するなら、用途ごとの短い台帳がよい。最初の仕様と日付、コンテンツタイプとsignedAttrs規則、数を捏造しない配備証拠の種類、鍵の共用可能性、次の破壊的変更機会、id-dataを残す・替える理由、仕様責任者、次回レビュー日、訂正履歴を一行につなぐ。

これはDaniel Kadeの提案であり、草案の要求ではない。古い用途を一括して危険と判定するものでもない。検査を強制する古い仕様、挙動不明の古い配備、将来規則に従う新しい仕様を別々に扱うための記録だ。

発行日は形式上の線として残せる。その周囲の運用地図を台帳が補う。

出典