要約

  • RFC 3402 では、非終端規則の置換結果は次の規則集合を取得するための鍵になる一方、その次の規則も開始時の Application Unique String そのものに適用された。
  • この不変条件によって、委任先を変える権限と対象の同一性を書き換える権限が切り離された。探索経路は動いても、何を探索しているかは動かなかった。

「書換規則」という語からは、前の出力を次の入力にする処理が思い浮かぶ。文字列が工程ごとに姿を変え、最後に目的の形へ到達する仕組みである。ところが分散した権威をつなぐ場合、この直感は危うい。途中の小さな変形が、その後の全規則にとって新しい対象となり、末端では最初に何を解決しようとしていたのかさえ曖昧になるからだ。

2002 年 10 月に標準化過程の文書として公開された RFC 3402 は、Dynamic Delegation Discovery System の第 2 部である。扱うのは遅延束縛のアルゴリズムだった。アプリケーションが Application Unique String、すなわち AUS を与え、クライアントが必要な規則を動的に取得しながらデータベースをたどり、終端規則が所定の結果を返すまで進む。

設計の中心には、出力の役割を限定する考えがあった。非終端規則の置換結果は、次のデータベース検索に使う鍵である。それは新しい AUS ではない。次段で得た規則の置換式も、改めて最初の AUS に適用する。RFC 3402 は前段の出力へ規則を適用することを明確に禁じ、アプリケーション仕様にも同じ禁止を定義するよう求めた。

最初の遷移だけは、動的な規則取得に任せなかった。アプリケーションが First Well Known Rule を定め、その規則が AUS から最初の正当な鍵を生成した。どこから探索を始めるかをアプリケーション契約に固定するためである。あるデータベースが入力形式を受け付けるというだけでは、そこが委任の起点である証明にはならない。

データベース検索は順序付き規則集合を返した。クライアントは各置換式を元の AUS に順番に適用し、空でない結果が得られる規則を探す。ただし一致だけで採用は決まらない。Services は提供される意味や能力を示し、Flags は終端性などを示し、Priority は同等な候補の選好を示した。

一致した規則の Services をクライアントが受け入れられない場合、処理は失敗で終わらない。同じ取得済みリストの、その規則より後ろから再開する。これは監査に重要な規定である。どの規則が一致し、なぜ拒否され、どの位置へ戻ったかを保存できる。拒否を隠して別の経路だけを後から提示することはできない。

受理した規則が非終端なら、置換結果を次の鍵として検証する。データベースが定める鍵形式に合わない結果は問い合わせに使うべきではない。誤った正規表現は、見かけ上もっともらしくても不正な鍵を作り得る。それでも、その文字列を新しい探索対象へ昇格させる権限は生じない。

RFC 3402 は、出力を次々に対象化する方式を sendmail 型の連鎖書換えになぞらえ、壊れやすく誤りを招くと述べた。累積方式では早い段階のずれが後続処理の意味をすべて変える。DDDS の方式なら、各規則を同じ AUS に対して個別に再実行し、中間出力を鍵または終端値として別々に検査できる。

別の仕組みへ移る道は用意されていた。Flags によって現在の DDDS アプリケーションを停止し、別の DDDS アプリケーションやプロトコル固有処理へ引き渡せる。RFC 3404 の p フラグが例である。しかしこれは文脈の切替を宣言する境界であり、古いアプリケーションの規則が中間鍵を AUS と偽って処理し続ける例外ではない。

終端規則は、アプリケーションが定めた形式の結果を Flags と Services とともに返す。「終端」はアルゴリズムが止まることを意味するだけで、現実のサービスが利用可能であること、規則発行者が正当な権威であること、利用側が結果を採用したことまでは証明しない。最終値だけを成功証明として扱えば、複数の責任層が消える。

Priority にも狭い意味しかなかった。同等な規則のうち、より良い、速い、安いなどの選好を表す。RFC は負荷分散ではないと明記した。トラフィック配分が必要なら、適用可能な場合の SRV など別の仕組みで行い、その判断を別の証拠として残さなければならない。

規則の鮮度は最適化より優先された。クライアントは以前の鍵や規則を記憶できるが、データベースの有効期限を守る必要がある。経路上の規則が一つでも失効していれば、処理は第 1 段階からやり直す。古い前半と新しい後半を接いだ経路は、どの時点にも存在しなかった可能性がある。

したがって RFC 3402 だけで完全な実装仕様にはならない。アプリケーション仕様は AUS、最初の規則、利用可能なデータベース、文字集合、期待する終端出力を定義する。データベース仕様は保存、検索、鍵と規則の形式、挿入方法、アプリケーション間の衝突回避を定義する。RFC 3401 がシリーズを一部だけ読む危険を警告したのは、この組合せが適合性を作るためだった。

抽象アルゴリズムは外部世界の判断も引き受けなかった。時刻、支払い、権利、取引状態など、AUS と規則だけでは分からない条件がある。そうした条件を不透明な結果へ埋め込めば、DDDS が実際より広い決定権を持つように見えてしまう。

安全性もアプリケーションとデータベースの組が決まって初めて具体化する。RFC 3403 は DNS と NAPTR、RFC 3404 は URI Resolution、先行する RFC 2916 は ENUM を記述した。それぞれは利用例であって、すべての DDDS クライアントが全用途を理解する証明でも、全規則が正当である証明でもない。

IANA の ENUM Service Registrations は、後の一つの DDDS 用途でサービス識別子がどう調整されるかを示す。登録は識別子の調整を証明するが、実行、鮮度、発行権限、正常終端、下流サービスの成功は証明しない。RFC Editor が現在掲げる RFC 3402 の検証済み編集上の正誤票は 7049 の一件で、RFC 3404 の p フラグに関する参照先を 4.4 節から 4.3 節へ直す。不変条件への変更ではない。

実行証拠には、元の AUS、アプリケーションと版、First Well Known Rule、データベース種別、全検索鍵、順序付き規則集合、規則の識別子と期限、置換の一致と結果、Services の拒否と再開位置、Priority の選択、終端フラグ、期待出力の検証、そして利用側の最終動作が必要になる。

Lu Heng の最小初期仕様という原則は、この分業を理解する助けになる。独立実装が共有すべき最小境界だけを標準化し、用途の意味と保存機構を個別仕様へ残した。稼働コード優先の原則から見れば、抽象契約は実測可能でなければならない。捕捉した規則で AUS を再生し、鍵と再開位置を追い、中間出力が対象へすり替わっていないことを示す必要がある。

RFC 3402 が守ったのは、委任のなかの同一性だった。規則は次に尋ねる場所を何度でも変えられる。けれど、各権威が答えるべき対象まで変えることはできない。経路は可変であり、対象は不変だった。

出典