要約

  • KEMRecipientInfo の rid は受信者の証明書または公開鍵を、kem は ML-KEM アルゴリズムを、kemct はその受信者向け暗号文を示す。
  • それは CMS 構造についての限定された事実であり、秘密の復号鍵を誰が保有したか、復号したか、内容を処理したか、決裁したかの証拠ではない。

宛先が表示され、アルゴリズムも暗号文も揃うと、処理完了のように見える。しかし記録が表すのは、公開鍵へ向けて作られた暗号上の経路である。

RFC 9936 は ML-KEM-512、-768、-1024 を CMS で使う規約を定める。送信側は受信者の公開カプセル化鍵から暗号文と共有秘密を作り、受信側は私有の復号鍵と暗号文から対応する共有秘密を得る。CMS での目的は内容暗号鍵の受け渡しだ。

したがって、対象鍵、アルゴリズム、暗号文の存在は確認できる。それだけでは、私有鍵がその時点で保護された環境にあったこと、受信側の実装が処理したこと、アプリケーションが内容を受理したことを導けない。

証明書は公開鍵を運ぶ

ML-KEM 受信者には OtherRecipientInfo の KEMRecipientInfo が必要である。RFC 9936 は、送信者が RFC 9935 の規約に従い受信者証明書から静的公開鍵を得ると説明する。これは鍵配布の前提であり、秘密鍵へのアクセス権、HSM の運用記録、失効への対応、または担当者の権限証明ではない。

SMIMECapabilities の部分的なアルゴリズム対応の表明も、文字どおりに扱う必要がある。対応可能という表明は、このメッセージで使われたことでも、復号されたことでもない。

実行の事実は別の場所にある

カプセル化は公開鍵を使い、復号は秘密鍵と暗号文を使う。RFC は秘密鍵と関連鍵の保護、一時鍵の消去、十分な乱数を求めるが、整形された CMS は特定実装がそれを守った証明にはならない。認証付きの CMS コンテナも、組織の受信箱、アプリケーションの受入れ規則、承認経路を定義しない。

亨路の「検証できる共通事実を越えない」という考え方は、ここでは監査上の節度になる。記録はそのまま保存し、鍵管理、復号、アプリケーションの受理、決裁は別の証拠でつなぐべきである。

情報源