要約

  • RFC 9879はPKCS #12でPBMAC1を使えるようにし、PBKDF2/HMAC-SHA-256の共通実装を求め、RFC 9579のパスワード符号化を訂正した。
  • 新しいMACを解釈できない旧読者が検証失敗を無視して暗号化鍵へ進む互換経路は残り、弱いパスワードやKDF設定も別問題として残る。
  • 移行の証拠は、実パラメータ、MACの結果、失敗時の挙動、インポート後の鍵保管を分けて記録しなければならない。

PKCS #12は証明書や秘密鍵を異なる機械、アプリケーション、ブラウザへ運ぶための容器である。容器を扱えたという事実は、完全性が確認されたことを含まない。構文の受理、復号、MAC検証、ローカル基準への適合、鍵の保管先は、それぞれ独立した状態である。

2025年9月にInformational RFCとして公開されたRFC 9879は、RFC 9579を廃止し、RFC 7292とRFC 8018を更新した。PKCS #12のDigestInfoでid-PBMAC1を使うことを認め、その場合には整合したPBMAC1-paramsを必須とする。authSafeに対するダイジェストも、そこに記された条件で計算しなければならない。

更新の中心は拡張可能性にある。従来のPKCS #12固有の導出方法では、主として基礎となるダイジェストしか替えられなかった。PBMAC1ではKDFと認証関数が明示される。全実装がPBKDF2とHMAC-SHA-256の組合せをサポートし、PBKDF2のPRFにもHMAC-SHA-256を使えることが最低線になる。他のSHA-2系HMACは推奨され、scryptなどは任意で追加できる。

選択肢が増えるほど、名前ではなくパラメータを見る必要がある。導出鍵長は明示必須で、keyLengthのないPBKDF2パラメータは受理できない。HMAC-SHA-256なら32オクテットが基準となる。HMAC-SHA-1を使うPBKDF2は避けるべきで、160ビット以下の別ダイジェストは禁止される。

外側の古い値にも罠がある。PBMAC1を選んだ場合、PKCS #12のmacSaltとiterationsは計算上無視しなければならない。一方、旧実装との互換のため空値やゼロにしないことが勧められる。監査ツールが外側の反復回数だけを表示すれば、実際のPBMAC1に使われなかった数字を強度の証拠と誤認しかねない。

そしてRFC 9879は、旧アプリケーションが新しい完全性保護を理解できなくても、MAC検証失敗を無視できるなら暗号化鍵を復号できるように設計したと説明する。移行中の到達性を保つ仕掛けである。同時に、「鍵が開いた」と「MACが正しかった」を別記録にしなければならない理由でもある。仕様は、その挙動を持つ製品名や普及率を示していない。

パスワード符号化の訂正も、実行結果と文面を区別する好例だ。RFC 9579はNULL終端のBMPStringを要求した。しかし検証済みErratum 7974によると、テストベクトル作成実装はパスワードをUTF-8のまま扱っていた。RFC 9879はUTF-8を正式ルールにし、NULL終端とBOMを付けないと定めた。同じ文字列表示でも、KDFに渡るバイト列が違えば同じ入力ではない。

付録のベクトルは、SHA-256やSHA-512を使う有効例と、反復回数、ソルト、鍵長欠落に関する無効例を含む。合格は計算手順の適合を示す。運用パスワードの強さ、未知アルゴリズムでの閉じ方、全読者への展開、秘密鍵の保管先までは示さない。

RFC 9879自身も、KDFが1オクテットほどの短い出力を許し得ること、KDFパラメータ自体は暗号学的に保護されないことを警告する。短い鍵はHMACへの総当たりを容易にする。20オクテット未満の鍵長を拒否することが推奨され、弱い条件をローカルに拒否する余地が明記された。余地があることと、全製品が拒否することは違う。

RFC 8018はさらに、パスワード暗号がオフライン探索を許す限界を述べる。ソルトと反復は一試行の費用を上げるが、予測しやすいパスワードを強くはしない。scryptは並列ハードウェアの優位をメモリ費用で抑える狙いを持つが、RFC 9879では任意である。PBMAC1という一語から一つの強度を推定してはいけない。

残すべき証拠は順序を持つ。容器の受領、生成側と読取側の版、アルゴリズムと実パラメータ、ポリシー判断、符号化されたパスワードバイト、MAC結果、別個の復号結果、鍵利用許可、保管先、再出力時の挙動である。後段の成功で前段の空欄を埋めないことが、移行を監査可能にする。

出典