要約

  • IANAはML-DSA-44をDNSSECアルゴリズム18番に登録し、署名と検証への利用欄をMAYとした。親ゾーンへのDS申請にはレジストリのEPP受け付けも要る。
  • Joe AbleyはRIPE 93で、自分が確かめた範囲での受理の壁と、一つの例外が開いた経緯を話した。10月の個人草案は受け入れ基準をIANAの登録簿に結び付ける案だ。

番号18はIANAの表に載った。次は親ゾーンにDSを登録する番だ。レジストラがEPPで送っても、親ゾーンを管理するレジストリが申請を受け付けなければ、DNSSECの切り替えはそこで止まる。

10月29日、Joe AbleyはRIPE 93で自分が試した範囲を話した。調べたシステムではアルゴリズム18を受け付ける登録機関が見つからなかったという。例外は一つあった。Garth Millerとの会話の後、保守者がコード変更をマージすると、その経路が開いた。個別の修正は一件の申請を通す。共通の受け入れ基準がなければ、次の運用者も登録機関へ問い合わせることになる。

IANAの現在の表は18番をML-DSA-44とする。ゾーン署名に使用できる値で、署名と検証への利用・実装の基準はMAYだ。これは仕様上の許容レベルであり、登録機関、署名システム、検証リゾルバーに導入済みかどうかは別に確かめる必要がある。

RFC 5910はEPPでDSを扱う方法を定める。algはDSが参照するDNSKEYの署名アルゴリズム、digestTypeはDSを作る要約方式を示す。Joe Ableyの10月14日付の個人草案はこの二つの値を対象にする。DNSSECの安全性を提供できない値を除き、IANAのアルゴリズム・ダイジェスト表に沿って受け入れる案だ。Datatrackerに掲載された版は00のみで、状態はI-D Exists。IETF標準として採択された文書ではない。

つまり、切り替えには別々の関門がある。まずレジストリが新しいDSをEPPで受け付ける。次に、利用者のリゾルバーがそのアルゴリズムを検証できる。前者が拒否すれば親ゾーンにDSを登録できず、後者が対応していなければ受け付けられたDSを安全に検証できない。

RFC 4035では、対応しないアルゴリズムのDSを検証リゾルバーが利用しない。対応可能なDSが残らなければ、その子ゾーンは安全に検証できない扱いになる。受付と検証は同じ処理ではない。

草案の方針差を測るには、試験日・登録機関名・EPP応答をそろえた互換性一覧が必要で、各レジストリがそれを公開すれば差の広がりが見える。

一次資料：RIPE 93講演 · RIPE 93セッション記録 · IANA DNSSECアルゴリズム表 · RFC 5910 · RFC 4035 · Joe Ableyの個人草案・版00。