要約

  • ACME個人Internet-Draftの第01版は、第00版にあった厳格な耐量子プロファイルを削除した。旧案ではTLSサーバー認証とJWS要求認証に耐量子またはハイブリッド署名を義務づけ、従来型だけの方式への後戻りを拒否した。
  • 新案は、現行のRFC 8555第6.2節がサーバーに実装を求めるES256を省略できるとする。一方、ES256を残すサーバーは、自ら選ぶ移行期間中、従来型だけのJWS署名を受け入れられる。

通信路を替えても、申請の鍵は別にある

証明書の自動更新では、通信路を守るTLSと、アカウントの申請を認証するJWSが別々に働く。前者の鍵交換を耐量子方式にすれば、記録された通信の将来の解読に備えられる。だが後者で古い署名を受け付け続ければ、証明書の注文を誰が送れるかという判断は昔のままだ。新しいトンネルの出口に古い受付印が置かれている。

六月の草案は、その受付印を使わせない厳格プロファイルを明記した。TLSサーバー側とJWSを送るクライアント側の双方で、耐量子単独または従来方式とのハイブリッド署名を要求し、従来型だけへのフォールバックを拒む。十月の改訂は厳格プロファイルを削除し、単一の「Quantum-Ready Mechanism」にまとめた。TLS 1.3以降と耐量子またはハイブリッドの鍵交換は残る。認証については新方式への対応を掲げつつ、従来型だけの認証を明示的に区切った移行期間内で認める。期間の終点は草案に書かれていない。

JWSの仕様も大きく変わった。旧案は複数のML-DSA方式と複合署名の実装を要求し、ES256も必須にしていた。新案の第4.2節は、JOSE登録簿の署名アルゴリズムをサーバーが選べるとし、特定の方式やパラメータを義務づけない。ES256を実装しない選択さえ認める。逆に残した場合は、運用者が選んだ期間だけ従来型JWSを受け入れられる。同じ看板を掲げた二つの認証局で、同じアカウントの署名が片方では通り、もう片方では拒まれ得る。

文章には未整理の継ぎ目もある。改訂案の序文は耐量子・ハイブリッド署名を「実装必須」と呼ぶのに、第4.2節は「MAY」を使い、特定のJWS方式を義務づけないと明記する。相互接続試験の合格条件を作るには、この二つを整理しなければならない。IETFの記録では、これは十月二十八日更新の個人草案であり、採択済みの規則ではない。実装例と、従来署名の拒否が始まる日付を示す試験結果が次の具体的な証拠になる。

資料：十月改訂／六月案／RFC 8555／IETFの状態。