要約

  • RFC 9964 は汎用的な Algorithm Key Pair（AKP）を導入し、ML-DSA-44、ML-DSA-65、ML-DSA-87 を JOSE と COSE に登録して、鍵とパラメータの表現を揃える。
  • alg と pub が正しく、署名検証が成功しても、鍵配送の根拠、信頼アンカー、主張の受理条件、認可の判断までは与えられない。

検証できることと、信じてよいことは近く見えて別の仕事である。受信したデータに既知の alg があれば、ソフトウェアは計算手順を選び、鍵の型を扱い、形式違反を拒める。その整合性が高いほど、人は次の問いを省略したくなる。誰がこの鍵を配布したのか。この鍵は誰を表すのか。この署名が通ったとき、どの操作を許すのか。

RFC 9964 はその省略を許さない形で、前段だけを定義する。Michael Prorock と Orie Steele による IETF の標準トラック文書は、ML-DSA の鍵と署名を JOSE、COSE と組み合わせる方法を定める。Algorithm Key Pair、AKP は、この RFC 自身に登録されたものに限られないアルゴリズムのための汎用鍵構造である。すべての AKP には alg と pub が必須であり、私的情報を置く priv は公開鍵に含めてはならない。ここで得られるのは、受け取った材料を同じ規則で表し、検査するための足場だ。

ML-DSA の秘密鍵についても、範囲は明快である。FIPS 204 にはシードと、そこから展開された秘密鍵という二つの表現がある。RFC 9964 は JOSE と COSE の相互運用性のためにシードだけを採り、priv を 32 バイトのシードとする。これは鍵管理の差異を減らす選択だが、シードを誰が生成したか、漏えいしていないか、公開鍵がどの経路で届いたかを証明するものではない。

ML-DSA-44、ML-DSA-65、ML-DSA-87 の登録も、共有されたパラメータ名を与えるにとどまる。レジストリは信頼の名簿ではない。鍵を主体へ結び付けず、発行者を審査せず、ペイロードの主張を業務上妥当とせず、検証成功をアクセスや支払い、委任へ変換しない。その変換には、配布経路、信頼アンカー、発行者と主体の検証、そして明示された受理ポリシーが必要になる。

さらに RFC 9964 は、ML-DSA の鍵と署名が大きく、帯域、メモリ、処理能力が限られる場面には適さない場合があると注意する。これは実運用への結論ではなく、形式の適合と運用上の適合を分離する記述である。詳細な安全性分析は FIPS 204 と RFC 9881 を参照するよう示されている。

この共同作業の持続的な意味は、暗号的な語彙を精密にしても、信頼の決定権まで奪わない点にある。Prorock の RFC 9964 は鍵表現を共有可能にする。どの鍵を信頼し、どの主張を受け入れ、何を実行するかは、責任を負う検証者が別に決めなければならない。

Sources