要約

  • RFC 9690では、証明書のrsaEncryptionはRSA-KEMを受け入れる意思を示さない。能力は別に、しかも具体的な構成として確認する必要がある。
  • 送信判断には、証明書、能力表明の由来と鮮度、二つのKDF、KEK長、wrap方式、CMS内容種別を一つの期限付き記録に結び付けなければならない。

証明書チェーンが通り、RSA鍵長も方針を満たし、公開鍵の形式も読める。多くの自動化はここで「この相手にはRSA-KEMで送れる」と判定する。しかし、RFC 9690は、通常のrsaEncryption識別子からその結論を出してはいけないと明記する。識別子が語るのは鍵の表現であり、受信者が現在どの処理経路を有効にしているかではない。

RSA-KEMは一個のアルゴリズム名だけで完結しない。新しい乱数整数zをRSA公開鍵で暗号化し、内部KDFで共有秘密を得る。その後、CMSのKEMRecipientInfo層が別のKDF、otherInfo、鍵長を用いてKEKを導出し、内容鍵をunwrapする。RFC 9690は、この二つのKDFが異なってよいとしている。KDF3/SHA-256とAES-Wrap-128は必須の最低線だが、実装は他の組み合わせも持てる。

したがって「RSA-KEM対応」という一列の台帳では足りない。内側のKDFとハッシュ、CMS側KDF、KEK長、wrap方式、内容種別まで揃って初めて、相互運用可能性の候補になる。

鍵を示す証明書と、能力を示す記録

受信者が一般のrsaEncryptionで鍵を提示する場合、その鍵は幅広いRSA用途と共存できるが、RSA-KEMの受諾は表明されない。別途、RFC 8551のSMIMECapabilities属性や、RFC 4262の証明書拡張で意思を示せる。

ただしSMIMECapabilitiesは部分リストである。以前受け取った署名済みメールに能力が書かれていても、それは当時の一実装が述べた事実だ。現在の端末が同じソフトウェア、設定、証明書、内容種別を使っていることまでは証明しない。リストにない能力を直ちに非対応と決めることもできない。

RSA-KEM専用鍵ならid-rsa-kem-spkiを使う。パラメータがなければ共有秘密の導出はKDF3/SHA-256。パラメータがあればGenericHybridParametersでなければならず、KEMRecipientInfoのKDF、KEK長、wrap方式を拘束する。keyUsageがある場合はkeyEnciphermentだけが許される。この証明書は意図を強く表すが、秘密鍵の現在の所在、サービスの稼働、相手方の承認、実際のdecapsulationまでは語らない。

後方互換は同一の処理を意味しない

RFC 5990はKeyTransRecipientInfoを用い、RSA暗号文Cとwrapped key WKをEK = C || WKとして連結した。RFC 9690はRFC 9629の汎用KEM構造に移り、kemctとencryptedKeyを別フィールドに置く。旧方式を後方互換で扱えることや、ASN.1モジュールのビット列が維持されることは、移行を助ける。

しかし、送信側が選んだ契約は記録しなければならない。RFC 5990経路なのかRFC 9690経路なのか、どの証明書と能力表明が選択を支え、どのパラメータが許可範囲を決めたのか。RSA演算が同じでも、コンテナ、フィールド、交渉、失敗箇所は同じではない。

受信側の結果も段階化できる。暗号文の長さと範囲の検査、秘密鍵演算、共有秘密の導出、CMS側KEKの導出、unwrap、内容の認証・復号、アプリケーション受理は別々だ。送信側がkemctを正しく作った事実から、最後の受理までを推定してはならない。

期限のある能力レシート

運用台帳には、証明書指紋と検証結果、公開鍵識別子、パラメータの有無と生バイト、keyUsage、能力表明の署名者・時刻・出所・証明書対応を残す。そのうえで、内部KDF/ハッシュ、CMS側KDF、KEK長、wrap方式、内容種別を展開し、RFC 5990とRFC 9690のどちらを選んだかを明記する。

証明書更新、クライアント更新、アルゴリズム無効化、内容種別変更、初回の構成別エラーは、キャッシュ済み能力を期限切れにする契機だ。不明なときにrsaEncryptionから推測するのではなく、確認するか、別途承認された手段に切り替える。

RFC 8017のRSA表現、RFC 3394のAES Key Wrap、RFC 4086の乱数要件、RFC 5280の証明書検証は、それぞれ重要な境界を担う。しかし、どれも受信者の現在の「はい」を代筆しない。

Lu Hengの最小初期仕様という見方では、共通必須部品は狭く定め、将来の選択はローカルな責任として残すべきだ。現実層の見方では、証明書、能力表明、メッセージ構造、秘密計算、アプリケーション判断を混同しない。running codeを優先するなら、最終的な事実は受信側が実際に何をしたかであり、OIDが何を可能に見せたかではない。

情報源