要約

  • RFC 9935 は ML-KEM 秘密鍵に seed、expandedKey、both の三形式を定め、長さの推測ではなく ASN.1 タグで識別させる。
  • both を受け取った側はシードから展開鍵を作り直して比較すべきであり、確認して不一致なら拒否しなければならない。

暗号移行では、インポート成功の表示が証拠を過大に見せやすい。RFC 9935 が切り分けるのは、ファイルが読めることと、内部の鍵材料が整合していることの差である。

公開鍵側では、ML-KEM-512、768、1024 に別々の NIST OID があり、AlgorithmIdentifier のパラメータは付けない。公開鍵長も固定される。証明書に keyUsage がある場合は keyEncipherment だけを立てる。これで形式と用途表示は読めるが、証明書パスの承認、秘密鍵の保有、業務上の許可までは分からない。

秘密鍵は三通りある。seed は 64 バイトで、そこから展開済み秘密鍵と公開鍵を決定的に生成できる。expandedKey は大きな復号鍵そのものを持つ。both は、シードを保存する装置と展開鍵しか扱えない装置の間をつなぐため両方を格納する。

識別は外側の長さでは行わない。[0] がシード、OCTET STRING が展開鍵、SEQUENCE が両方を表す。SEQUENCE を正しく解析した時点で確認できるのは、二つの欄が存在したことだけだ。派生関係は別の検査である。

受領側はシードから規定の処理で展開鍵を再生成し、同梱値とバイト単位で比較するのが原則だ。処理コストを避けて省略する余地はあるものの、その場合は一致を確認できない。検査を行って不一致なら、RFC 9935 は不正な秘密鍵として拒否を求める。

したがって、監査項目は「解析」「形式判定」「比較実行」「一致」「受理」「使用」に分けなければならない。解析済みという一行を、鍵が正しいという記録へ膨らませてはならない。

展開鍵にはさらに FIPS 203 の検査がある。復号前に型、長さ、内部ハッシュを確認する。より広い鍵ペア検査には、シードがある場合の整合性と、封入・復号を一往復させる確認も含まれる。それでも、鍵ペアが正規の KeyGen 出力だったことまでは保証しない。

保管判断は後戻りできない。シードから展開鍵は作れるが、シードを捨てた後に展開鍵から元のシードを復元することはできない。シード保存は可搬性と災害復旧に利く一方、鍵全体を再生成できる秘密を残す。展開鍵だけにすれば表現は一つ減るが、将来のシード輸出を閉ざす。

RFC 5958 の容器や RFC 9936 の CMS 利用は周辺構造を与える。しかし、誰がどの実装で比較し、どの判断を下したかは運用側の記録でしか証明できない。ログには秘密値ではなく、パッケージ指紋、形式、検査版、結果、受理・拒否、変換履歴を残すべきだ。

情報源