要約

  • draft-ietf-lamps-rfc6211-update-01は、RFC 6211に記載された1.2.840.113549.1.9.52を、IANA登録値1.2.840.113549.1.9.16.2.52へ訂正する。草案の著者は、RFCとレジストリを別々に採用した二つの実装が相互運用できなかったと報告している。
  • 移行では、旧OIDを「読める」こと、「有効な保護として信頼する」こと、「新たに生成する」こと、「履歴オブジェクトを原形のまま保つ」ことを分離する必要がある。識別子の優先順位と互換性終了を管理する台帳が、その境界を可視化する。

数字の列が二つに分かれた

IANAのS/MIME属性レジストリは1.2.840.113549.1.9.16.2を根とし、その52番がid-aa-cmsAlgorithmProtectである。ところが2011年のRFC 6211では、本文の定義とASN.1モジュールから16.2が抜け、1.2.840.113549.1.9.52と記された。

これは表記上の揺れではない。OIDはエンコードされたオブジェクトの意味を決めるため、異なる数列は異なる識別子になる。更新草案によれば、既知の二つの実装のうち、一つはRFCの値を、もう一つはIANAの値を用い、相互運用に失敗した。

この記述だけから、影響製品数や攻撃の有無を推測してはならない。草案は市場規模も被害件数も示していない。しかし、中央レジストリが正しければ実装も自然に揃う、という前提を崩すには十分な事実である。

RFC付属モジュールをコンパイルするのも、IANAで割当てを確かめるのも、どちらも合理的な実装手順だ。公式な二つの入口が別のバイト列へ導いたなら、最後にコードを書いた人だけを責めても原因は残る。

セキュリティ属性にも識別が要る

CMSは、署名・認証・暗号化された内容を運ぶための構文である。RFC 6211が追加した属性は、処理に使うアルゴリズム識別子を保護対象へ結び付ける。攻撃者がアルゴリズムやパラメーターを書き換え、検証側に別の処理をさせる「アルゴリズム置換」への対策だ。

しかし検証器が属性を見つけられなければ、その保護は評価できない。生成側が短いOIDで印を付け、受信側が登録済みOIDだけを探す場合、属性が存在するかどうかについてすら合意できない。更新草案のセキュリティ考察は、同じASN.1 OIDを使わなければ保護は成功しない、と明記している。

未知属性を受けた実装の挙動は一様ではない。オブジェクト全体を拒否するもの、属性だけを無視するもの、別のローカル規則で処理するものがあり得る。したがって具体的な脆弱性を断定するのではなく、確認できる境界を守るべきだ。セキュリティ制御の名前は、制御の外側にある事務情報ではない。

ASN.1モジュールは読まれるだけではない

規格文書には複数の利用面がある。人は説明文を読み、エンジニアは定義をコピーし、ツールはASN.1をコードへ変換する。テストは出力されたバイト列を正解として固定し、依存パッケージはその結果を長年運ぶ。

IANAレジストリには割当ての権威がある。RFCには規範文書としての権威がある。モジュールには自動化へ直結する実務上の力がある。本件では、正しい割当てが存在しても、誤ったモジュールの配布力を打ち消せなかった。

改訂01は、もう一つのずれも縮める。RFC 6211の本文は、属性集合にアルゴリズム保護属性を一つだけ含めるよう求めていた。新しいASN.1定義はCOUNTS MAX 1を追加し、その制約を機械可読な場所へ移す。

機械可読なら必ず安全、という話ではない。誤ったスキーマは誤りを高速に複製する。必要なのは、規範文、レジストリ、モジュール、例、適合性テストを同じリリース単位として照合することだ。

訂正と導入は同じ時計で進まない

Errata 9144と9145は2026年8月19日に報告された。対象はそれぞれ付録Aと第2節である。9月13日時点で、どちらの状態もReportedだった。報告済みは検証済みと同義ではない。更新草案も作業中であり、00版が9月1日にLAMPS作業部会の最終確認へ入り、01版は9月9日UTCに提出された。

文書側の進行は共同記録を整える。一方、導入側には別の時間が流れる。ベンダーは修正版を作り、利用者は保守窓を選び、更新不能な装置は隔離方法を探す。過去に署名されたオブジェクトは、そのときの検証を再現するため原バイトの保存が必要かもしれない。

最終文書が出ても、導入済みの定数は自動で置換されない。逆に、組織はIETFの最終決定を待たず、公開情報に基づく限定的な対策を取れる。ただし、それをIETF合意ではなくローカル方針と明示し、後続改訂で見直せる状態にしておく必要がある。

二つを受け入れる、では足りない

移行策として「両方のOIDを受け入れる」と言うと、重要な差が消える。アーカイブ閲覧ソフトは旧OIDを識別して履歴を説明できる。監視装置は検出して生成元を数えられる。ポリシー検証器はデコードできても、保護要件を満たしたとは判断しないかもしれない。生成器は旧OIDを一切出してはならない。

つまり、認識、観測、信頼、生成を別々に制御する。期限のない二重受入れは短期の障害を減らすが、誤ったOIDを恒久的な別名へ変える。全面即時拒否は、履歴証拠を読めなくしたり、同日に更新できないシステムを止めたりする。

現実的な順序は非対称だ。新規生成を最初に止める。旧値の検出は残し、誰がまだ出しているかを測る。生成者を修正し、用途ごとに読取り例外を狭め、期限を設ける。入力を黙って新OIDへ書き換えるのは避ける。とりわけ署名対象のバイトを変えれば、由来だけでなく証拠そのものを失う。

識別子優先順位・互換性終了台帳

必要な運用物は、曖昧な「RFC 6211対応」一覧ではない。二つの完全なOID、出典、目標値、旧値の扱いを最初に記した台帳である。目標はIANA登録値とし、短い値には「旧誤記」など組織が審査した状態と再確認日を付ける。

次に、製品名だけでなく処理単位を並べる。署名サービス、検証器、S/MIMEゲートウェイ、暗号ハードウェア、アーカイブ閲覧、解析ツール、再シリアライズ処理は別々の行を持つ。各バージョンについて、どちらを認識するか、どちらを有効とみなすか、何を生成するか、読み書きで原バイトを保つかを記録する。

申告はテストコーパスで裏付ける。それぞれのOIDを持つオブジェクト、属性なし、二個の属性、属性内のアルゴリズムと外側のCMS構造が食い違う例を含める。オブジェクトのハッシュ、ソフトウェア版、ポリシー版、結果コードを保存する。COUNTS MAX 1も実行時に試す。スキーマへ書かれた制約を全ライブラリが自動で強制するとは限らない。

廃止欄では、旧値の新規出力停止日、残存生成元、例外責任者、期限、最終拒否条件を定める。履歴オブジェクトは原形を保ち、必要なら外部メタデータで状態を説明する。観測によって新規旧形式が止まり、例外が管理下に入ったことを示して初めて、互換性終了を判断できる。

修正には来歴を添える

修正版の受領書は五つの問いに答えるべきだ。目標OIDを確定した資料は何か。どのモジュールまたは定数を変えたか。生成バイトを証明するテストは何か。既存オブジェクトをどう扱うか。互換期間の終了を誰が承認したか。

これがなければ、「修正済み」はエンコーダーだけを直してアーカイブ閲覧を壊した状態かもしれない。両方を永久に信頼しながら旧値を生成し続ける状態かもしれない。保存物を再符号化し、過去の署名を説明する材料を失った状態さえあり得る。

台帳に秘密鍵や本文を置く必要はない。試験物のハッシュ、版、結果、例外番号と決定日で足りる。残すのは機密データではなく、権威が文書から動作へ移った証拠である。

共通仕様は小さく保てる

IETF草案は、すべての業界向け移行計画まで抱え込む必要はない。共通層が定めるべきなのは、一つのOID、一インスタンスの制約、その一致が安全性に必要だという説明である。長期保存や更新不能機器の扱いは、費用と責任を負う場所で決められる。

これはHeng Luの最小初期仕様という考え方に沿う。相互運用に不可欠な意味は共有し、将来の高コストな選択はローカルに残す。ただしローカル例外が共通のワイヤ上の意味を変えたり、世界共通の第二ルールを名乗ったりしてはならない。

Policy Mirrorの視点では、主語と動詞を省かないことが重要だ。「IANAの登録は正しい」「この読取り器は旧OIDを認識する」「このポリシーはそれを有効な保護とみなす」「この生成器は新OIDだけを出す」は別の事実である。全部を「RFC 6211対応」に畳むと、監査票は簡単になるが、相互運用性の説明は壊れる。

正しいレジストリは収束先を示す。モジュール、コード、テスト、保存データがそこへ移り、旧経路を閉じられる証拠が揃って初めて、訂正は運用上の修復になる。

出典