要約

  • RFC 9964 の AKP は alg と pub を要求し、公開材料と私的材料を分離して、ML-DSA を JOSE と COSE に一貫して載せる。
  • priv に入るのは 32 バイトのシードだけである。シードも展開済み秘密鍵も、漏えいすれば偽造署名を可能にするため、同じ水準の保護を要する。
  • 指紋が比較するのは公開鍵とアルゴリズムである。署名を誰が許すか、いつ交換するか、結果をどのサービスが採用するかは、別の責任である。

同じ公開鍵は、同じ統治を意味しない

JOSE と COSE に ML-DSA を持ち込むには、鍵を表す共通の語彙が必要になる。RFC 9964 は AKP を定め、ML-DSA-44、65、87 を登録する。alg と pub は必須であり、priv を公開鍵に含めてはならない。鍵指紋は kty、alg、pub という公開要素から得られるため、二つの表現が同じ公開鍵と同じアルゴリズムを指しているかを確認できる。

しかし、それは照合可能性であって、権限の割当てではない。指紋にはシードも、組織名も、承認経路も入らない。公開ディレクトリが指紋を保持すれば、鍵の主張を比較する助けにはなる。それだけで、そのディレクトリが署名を許し、交換を命じ、受信側に受理を強制できるわけではない。

FIPS 204 は秘密材料をシード又は展開済み秘密鍵として扱える。RFC 9964 は、双方のエコシステムで一つのコンパクトな表現を得るため、シードだけを選んだ。ここで重要なのは、RFC が両者に同じ保護を要求している点である。どちらを不正に取得しても署名は作れる。標準が解消するのはシリアライゼーションの迷いであり、バックアップ、復旧、委任、物理・論理的な隔離の問題ではない。

実務では、少なくとも五つを別々に記録すべきである。AKP と公開指紋は鍵の証拠、シードの置き場所と保護手段は保管の証拠、要求された操作と範囲は署名要求の証拠、許可した主体は承認の証拠、受信側が適用又は拒否した効果はサービスの証拠である。これらが関係していても、どれか一つの成功が他を代用してはならない。有効な鍵でも要求は拒否でき、有効な署名でもサービスは拒否できる。

大きな署名は大きな中央権限を生まない

ML-DSA はサイズの問題を可視化する。公開鍵と署名は従来の選択肢より大きく、JSON 化すればさらに増える。RFC 9964 は、ネットワーク、メモリ、処理資源が限られる環境に必ずしも適さないと注意する。これは中央の一者が全員へ一つのプロファイルを押し付ける根拠ではない。各参加者は自分の経路を測り、適切なパラメータを選び、適合しないものを拒み、検証中は別経路を残せる。

標準が公表されたことも、採用の証拠ではない。一つの部品が署名を検証できても、全ての依存部品が同じサイズ、用途、アルゴリズムを受け入れるとは限らない。Heng Lu の最小初期仕様という考え方は、形式、比較、検証を共同層にとどめる。保管、承認、受理、退出の選択は、リスクを負うローカルな参加者に残す。

監査に必要なのは「署名が有効」の一行ではない。公開鍵をどう同定したか、秘密材料をどの境界で守ったか、何の目的の要求だったか、誰がいつ認めたか、受信側が何を追加確認したか、誤った承認が後から判明した場合に将来の利用をどう止めるかを、別々に再構成できなければならない。