要約

  • RFC 3058はIDEAによるコンテンツ暗号と鍵ラップに別々の識別子とパラメータ規則を与えた。ワイヤ表現は正確になったが、対応は任意のままで、文脈によりパラメータは欠落、NULL、八オクテットIV付きのいずれにもなった。
  • 署名されたS/MIME能力は順序付きの自己申告であり、実行の受領書ではない。実利用には両端の実装、ローカル選好、個別合意、法的制約、鍵へのアクセス、アンラップ成功、本文処理成功がなお必要だった。

一つの暗号に二つの仕事

「IDEAを使う」だけでは暗号ソフトウェアは相互運用できない。CMSメッセージにはアルゴリズム識別子、パラメータ、各値の置き場所が要る。本文を保護する処理と、コンテンツ暗号鍵を保護する処理も区別しなければならない。2001年2月にInformationalとして公開されたRFC 3058は、この精度を提供した。

一つのOIDはコンテンツ暗号用のIDEA-CBCを、もう一つはIDEA鍵ラップを示す。前者は128ビット秘密鍵で64ビットブロックの本文を処理する。後者は16オクテットのコンテンツ暗号鍵に八オクテットの検査値を結合し、32オクテットのラップ値を作る。「IDEA対応」という一語では二つの機能を代替できない。

OIDはAscomに対応するprivate-enterprise分岐に置かれた。価値は調整にある。独立した実装が同じ機能を同じ番号で表せる。しかし登録は、すべてのS/MIMEクライアントにコードがあること、すべての利用者が有効化できること、暗号メールが誰かに届いたことを意味しない。選択肢はまず可読になったのであって、端点で自動的に利用可能になったのではない。

欠落、NULL、IVは同じ「空」ではない

コンテンツ暗号の識別子はIDEA-CBCParを持ち、ちょうど八オクテットのIVを任意に含む。IVがパラメータにある場合はそれを使い、暗号文の先頭には入れない。パラメータがない場合は暗号文先頭の64ビットをIVと解釈するが、RFCはCMSやS/MIMEで後者を使うべきでないとした。

鍵ラップ識別子では規則が違い、パラメータはNULLでなければならない。二つのS/MIME能力表現ではさらに別で、能力パラメータは欠落しなければならない。日常語ならいずれも「値なし」に見える。ASN.1では別のバイト列であり、別の処理指示である。

文書の中心はここにある。識別子は文脈とパラメータ規約があって初めて完全な命令になる。欠落とNULLを同一視する実装は正しい構造を拒むか、合意していない意味を受け入れる。「IDEA」だけを記録する監視も再現に必要な証拠を失う。

後年のErrata 5913はこの層の違いを補強する。Held for Document Updateとなった訂正は、ASN.1識別子IDEA-CBCを小文字で始められるid-IDEA-CBCへ直すべきだとする一方、数値OIDは変えない。人向け名称、ASN.1ソース識別子、登録番号は関連するが同じものではない。

ラップの内側はランダム、外側は固定

鍵ラップ手順は厳密である。16オクテットのコンテンツ鍵に八オクテットの整合性検査値を加え、八オクテットのランダムIVを生成して24オクテットをIDEA-CBCで暗号化する。ランダムIVを前置し、32オクテット全体を逆順にして、固定の外側IV 4adda22c79e82105でもう一度暗号化する。アンラップは逆順で実行し、検査値が合わなければ拒否する。

固定の外側IVだけを切り出せば誤解しやすい。内側の新しいランダムIVは失われていない。反対に、ランダム性があり検査値が合っても、送信を誰が許可したか、受信者がこの方式を望んだか、復号内容が有用かは証明しない。検査値が答えるのは取り出した鍵についての限定的な処理結果である。

CMSが層を分けるのは役割が違うからだ。コンテンツ鍵が本文を守り、鍵暗号鍵がその鍵を守り、ラップ形式が運び、封筒がアルゴリズムと受信者を示す。一層の成功は全層の受領書ではない。

署名済み能力は順序付きだが不完全

S/MIMEクライアントは署名属性にSMIMECapabilitiesを載せられる。RFC 3058はIDEA-CBCとIDEA鍵ラップについて正確なDERバイト列を示し、別々の論理カテゴリに置いた。並び順は選好を示し得る。後続仕様も、この一覧は部分的であり全対応機能の列挙は不要だと説明する。

検証済み署名が示すのは、その署名メッセージの文脈で誰が能力を申告したかであり、証明書と署名時刻の検査も伴う。現在の受信プロセスを照会したわけではない。ソフトウェアは更新・再設定され、暗号プロバイダは外れ、鍵は使えず、ポリシーが実装済み機能を止めることもある。一覧が網羅的でないため、対応していても掲載しない場合もある。

RFC 3058自身も選択を登録簿へ委ねなかった。判断には受信した能力、個別合意、利用者の選好、法的制約が関わると書いた。利用者がIDEAを要求するなら両端クライアントが対応し、選好も設定されなければならない。OIDはバイトの曖昧さを消せても、これらの権限を代行できない。

ライセンス層はワイヤ形式の隣にあった

当時のIPR通知は、AscomがIDEAの特許を保有し、合理的かつ非差別的条件で非独占ライセンスを提供し、非商用利用を無料とすると述べた。これは2001年の文書が示した境界の史料であり、現在の法的助言ではない。技術標準化が当時表明されたライセンス層を消さなかったことが分かる。

実装はOIDを認識しても暗号コードを持たないことがある。開発者がコードを持っても組織が条件を受け入れないことがある。受信者が能力を示しても送信側ポリシーは別方式を選べる。技術登録はそうした判断を吸収しなかった。

RFC 3370は一般的なCMSアルゴリズム規約を中核構文から分離し、RFC 5652は後のCMSを定義した。RFC 8551のS/MIME 4.0はAES系とChaCha20-Poly1305に要件レベルを与えつつ、能力と帯域外情報による選択を残した。後世の基準はIDEAの配備を証明せず、新しい必須一覧にないことも旧OIDの削除とは違う。

RFC 3058の長期的な教訓はIDEAの勝敗ではない。標準化は判断を再現可能にしても普遍化しない。番号が選択を示し、パラメータが読み方を示し、署名能力が申告者を示す。ポリシーと法が選択可能性を決め、実交換だけが両端の完了を示せる。

出典

Lu HengはRFC 3058の執筆者でも承認者でもない。ここでは象徴的登録と実行挙動を分ける公開済み分析レンズとしてのみ参照する。