要点

  • draft-skoglund-epp-registry-lock-00は、保護対象ドメインの変更を保留し、期限内に一人以上のロック連絡先が承認するEPP手順を提案する。
  • ポリシーは必要承認数を示し、最終ポーリング結果は承認した連絡先IDを示せる。しかし本人確認、課題の結合、経路や回復の独立性は標準化しない。
  • 変更前後の状態、独立した支配領域、課題、回答、例外、時刻、結果を結ぶ「承認儀式記録」が必要である。これはガバナンス上の提案で、IETF要件ではない。

定足数には分かりやすさがある。一人より二人の方が安全に見える。ところが、二つのアドレスが同じ企業メールにあり、二台の電話が同じ管理者に制御され、どちらも同じヘルプデスクで回復できるなら、二件の回答は二つの独立権限を意味しない。

レジストリロックの目的は、レジストラの通常アカウントとは別にレジストリ側の判断を加えることだ。ネームサーバー変更は通信を迂回させ、登録者やレジストラの変更は法的・運用上の支配を移す。重要ドメインでは、一つの認証情報が破られても変更が完了しないことに価値がある。自動化によって、その分離を票数だけに縮めてはならない。

第00版は2026年6月30日に公開された。表示本文のヘッダーはStandards Trackとする一方、Datatrackerは個人Internet-Draftとして扱い、ストリームも想定RFC種別も空欄で、正式な地位はないと説明する。RFCでもREGEXT合意でもない。

1001は完了ではなく、承認期間の開始である

草案は、既存のロック手続が統一されず、多くに手作業があることを出発点とする。拡張はスポンサークライアントによる設定と管理をEPPへ持ち込む。

ロック後はserverDeleteProhibitedが必須となる。変更が承認待ちならserverPendingUpdateを付ける。ロック設定またはロック済みドメインの更新では結果コード1001を返す。コマンドは受理されたが、処理は未完了である。期限内に承認されれば成功、されなければ失敗をpollで伝える。

最初のclTRIDとsvTRIDは、完了した状態変更ではなく承認事象の起点になる。ポーリング情報はドメイン、操作、以前のサーバー取引ID、承認した連絡先IDを示し、基本EPPはキュー日時と外側の取引IDを与える。

開始と終了は結べる。それでも、その間に誰をどう確かめたかは分からない。

複数行と独立性は別の性質である

ポリシーには任意の期限と正の必要承認数を置ける。第00版では要素名がquoromと綴られている。サーバーは値と連絡先数を制限できる。

数値は、何件で足りるかという不一致をなくす。しかし自然人、雇用主、端末、IDプロバイダー、回復経路が別かどうかは表さない。三つの連絡先が共有受信箱に届くことも、二社が一つの認証基盤を使うこともある。

複数性はデータベースの性質である。独立性は、一度の侵害、命令、回復手続では全承認を作れないという構造の性質だ。企業統治をEPPだけで解く必要はないが、独立性規則なしにquorom=2を二人統制と呼ぶことはできない。

方法ラベルは保証水準ではない

連絡先はIDと任意の方法を持つ。既知の値はemail、text、letter、phone、tokenで、ほかの値も許せる。

名称は配送経路を言うだけだ。メールが署名リンクか通常返信か、SMS番号が最近確認されたか、tokenがハードウェアか転送可能なコードかは分からない。電話も郵便も、記録された課題と受取人がなければ本人性を示さない。

草案は課題内容、変更との暗号的結合、再利用防止、経路登録、本人確認、回復を定めない。初期マッピングとしては合理的でも、approvedByの意味は限定される。レジストリが自らの手続で承認と記録した事実であり、世界共通の保証ではない。

連絡先オブジェクトを凍結しても権限構成は変えられる

ロック連絡先として関連付いた連絡先オブジェクトの更新と削除は拒否しなければならない。先にメールを書き換え、新しい宛先で承認する攻撃を防ぐ。

一方、ロック更新では連絡先の追加・削除や期限・必要数の変更ができる。誰が「承認できる者の変更」を承認するのかという再帰的問題が生じる。

外部組織に属する唯一の連絡先を除くこと、必要数を減らすことは、通常のデータ変更より強い意味を持つ。権限構成の変更は、要求開始時の旧ポリシーと旧集合で審査し、前後を残すべきだ。新しい規則が自分自身の採用を遡って正当化してはならない。

例外が実際の保護範囲を決める

更新は可能であり、草案は自動DNSSECプロビジョニングが承認を迂回することも認め、CDSS/CSYNCスキャナーを例示する。ロック解除は仕様外の手動手続である。

更新を止めれば失効リスクが高まり、DNSSEC自動化は継続性を守り得る。解除を強い手動儀式に残す考えにも合理性がある。ただし「ロック済み」は絶対停止ではなく、名前の付いた開口部を持つ境界である。

DNSSEC例外にはスキャナーの身元、観測値、許可ポリシー、委任の前後を記録する必要がある。仕様外の解除にもEPP履歴と結べる儀式IDが要る。最も強い経路が最も監査しにくい経路になってはならない。

既存サービスは手続の違いを示す

IANAのEPP拡張レジストリには、.seと.nu向けのSwedish Internet Foundation Registry Lock ExtensionがOtherの有効仕様として登録済みである。新しい個人草案の承認を意味しない。

Internetstiftelsenの説明では、保有者確認方法はレジストラごとに決まり、レジストラが解除、変更、再ロックを行う。DENICの.deではロック連絡先を置き、登録済み携帯へトークン、登録済みアドレスへメールを送り、7暦日以内に確認がなければ却下し、DENIC自身も要求を審査する。

どちらも第00版の実装証拠ではない。同じ商品名の下で登録、確認、期限、解除が異なる事実を示す。共通構文ができても、儀式の違いは明示しなければならない。

承認儀式を保存する

私は各保留変更に承認儀式記録を提案する。これはDaniel Kadeのガバナンス提言である。

記録はドメイン、認証済みクライアント、セッション、clTRID、svTRID、時刻、操作、変更前と要求後の正規状態を固定する。旧ポリシー版、期限、必要数、連絡先集合は上書きできない。

各承認者について、代表する権限、登録時刻、方法、独立性に関わる雇用、ID基盤、メール領域、端末管理、電話契約、トークン発行、回復窓口を記録する。機密値は制御された参照でよい。

課題のダイジェストを正確な変更、宛先、発行・失効時刻、回答、検証、再利用防止へ結ぶ。最終判断は独立性規則、採用・除外した回答、例外、手動介入を示す。完了時に元の保留取引、poll、適用状態を結ぶ。

定足数が答えるのは件数である。儀式記録は、その件数が独立した権限を本当に表していたかを答える。

出典