要約

  • RFC 5105 は、有効な署名を有効な Validation Token の必要条件であって十分条件ではないとする。Registry は参照要素、変換、アルゴリズム、証明書、VE 認定、Registrar、番号、方式、日付、再利用方針を別に確認する。
  • Token は検証結果を運ぶ文書である。Registry の認可、EPP 処理、権威 DNS への公開、リゾルバからの観測、通信成立そのものではない。

署名検証器は成功を返した。しかし Reference が指していたのは Token 全体ではなく、任意の連絡先データだけだった。このとき暗号計算は正しい。ENUM 委任の根拠としては役に立たない。

RFC 5105 がセキュリティ節で強調するのは、この種の境界である。Reference URI="#TOKEN" と Token 要素上の Id="TOKEN" を組み合わせ、署名が完全な Token を覆う必要がある。ID を tokendata に移せば、署名の用途は失われる。

これは XML 固有の細部であると同時に、組織設計の原則でもある。検証器は参照された対象についてしか答えない。対象の選択が間違っていれば、緑の結果は間違った問いに対する正しい答えになる。

ENUM の委任には複数の主体が関与する。RFC 4725 は E.164 番号の Assignee、ENUM Registrant、Validation Entity、Registrar、Registry、DNS サービス事業者、アプリケーション事業者を分ける。VE は権利関係を検証し、Registrar は申請し、Registry は委任データベースと権威ゾーンを運用する。

RFC 5105 は VE の結果を署名 XML 文書として持ち運べるようにした。Registrar が番号の利用権を自ら証明できない場合でも、VE の声明を改変せず Registry に届けられる。署名の価値はここにある。だが、運搬される証拠と受入れを決める権限は別である。

必須の validation 要素には、VE ごとに一意な serial、E.164 番号、任意の番号範囲末尾、VE ID、Registrar ID、方式 ID、実行日、任意の有効期限が入る。連絡先情報は別の任意領域に入る。Registry はこれらを申請と方針に照らして評価する。

serial の一意性は VE 内に限られる。番号だけを中央表に保存すれば、衝突しないという根拠を失う。少なくとも VE と serial を組にし、さらに Token の正確なハッシュ、Registrar、E.164 範囲、方式、日付、方針時点を残す必要がある。

番号範囲も表現どおりに扱う。最初の E.164 番号と任意の lastE164Number が閉じた範囲を示し、双方の長さは同じでなければならない。途中のシステムが先頭構造を落としたり範囲を広げたりすれば、署名された主張とは別物になる。

XML-DSIG は enveloped 形式で用いられ、exclusive canonicalization が要求される。Token が EPP など外側の XML 文書に埋め込まれても、継承した名前空間宣言によって署名入力が変わらないようにするためである。canonicalization は表現の安定化であり、意味や権限の検証ではない。

Registry は汎用署名検査の成功だけを採用できない。承認された変換と暗号アルゴリズムであること、Token 要素を参照していること、鍵が認定済み VE に属することを確かめる。RFC の署名例は「有効な署名は必要だが十分ではない」と明記し、証明書と XML Schema も追加検査として挙げる。

埋め込まれた X.509 証明書も自己認可ではない。Registry は自ら CA になることも、公的 CA を認めることも、事前登録鍵だけを使うこともできる。どのモデルを採用するかはローカル方針である。証明書は検査材料を提供するが、信頼アンカーや VE 資格を選ばない。

したがって監査には、決定時の trust store と認定状態が要る。証明書の期間内でも制度上の VE 認定が終了しているかもしれない。逆に後日の方針変更は、過去のシステムが当時受け入れた事実を消すべきではない。現在の再評価と歴史的判断を並べて保持する。

日付も単純な期限判定ではない。executionDate は検証実施日、expirationDate は検証終了日を表す。期限を省けば形式上は無期限になるが、Registry は無期限が方針に合うか確認しなければならない。さらに方針は、実施日から何日間 Token を委任認可に使えるか定める。

有効期限が未来でも、提示可能期間が終わっていることがある。期限省略が形式上可能でも、Registry が拒むことがある。日付が正しくても別の Registrar 用かもしれない。署名検証器はこれらの判断に必要な Registry 方針を持たない。

Registrar ID は再利用攻撃の境界を示す。別の Registrar が盗み見た Token を自分の申請に添付しても、署名は変わらない。Registry が Token と申請を突合すれば、署名済み ID 自体が不一致を示す。暗号の成功と認可の失敗は矛盾しない。

methodID も方式の名前であって、実行証明ではない。RFC 4725 は検証方式が当事者、データ源、Assignee の選択、規制要件で変わり得るとする。Registry はその方式が当該番号と時点で最低要件を満たすか判断する。ラベルだけを信じれば、方針がデータから消える。

委任には継続的な整合も必要である。番号の Assignee が変われば ENUM 状態も追随しなければならない。再検証が成功すれば継続でき、失敗すれば明示的操作または期限によって停止される。古い成功 Token の署名が今も検証できることは、新しい失敗を取り消さない。

再利用防止には使用履歴が必要である。同じ Token が初回、失敗後の再試行、別申請への二度目の利用のどれなのかは、serial だけでは分からない。VE、serial、ハッシュ、Registrar、番号範囲、初回観測、決定、許容窓を結び付ける。

任意連絡先は補助情報にとどまる。組織名やメールは再検証を助けても、現在の番号割当を証明しない。また Token 自体は暗号化されない。機密性が必要なら別の仕組みを用いる。署名、通信路暗号化、データ最小化、認可を一つの「secure」にまとめてはならない。

アルゴリズム受入れにも時点がある。RFC 5105 は RSA-SHA1 と RSA-SHA256 の対応を求める一方、SHA-1 への懸念を既に記していた。実際に受け入れる方式と鍵長は Registry が決める。ライブラリが古い方式を計算できることは、現在の認可方針ではない。

Token が受け入れられても、公開はまだ先にある。RFC 5076 は EPP で検証情報を追加、変更、削除、照会する拡張を定める。EPP 成功はその取引の証拠であり、権威 DNS の更新を直接観測した証拠ではない。

Registry のデータベースが更新されても、ゾーン生成や配布が失敗し得る。権威サーバが更新されても、再帰キャッシュは旧状態を返し得る。RFC 3761 に従う ENUM 検索が URI を得ても、URI が正しい、宛先に到達できる、通信が完了するとは限らない。

証拠モデルは各遷移を別の receipt として残すべきだ。暗号 receipt は原文バイト、ハッシュ、parser、Schema、解決した ID、参照ノード、変換、canonicalized 入力、アルゴリズム、証明書経路、信頼アンカー、結果を記録する。

方針 receipt は VE 認定、方式許可、Registrar と番号の一致、実行日と期限、提示窓、方針版、再利用履歴を記す。Registry は受入れまたは拒否を別に発行する。EPP、委任表、権威公開、リゾルバ観測、アプリ結果もそれぞれ自分の時計と根拠を持つ。

こうすれば障害を切り分けられる。署名対象が誤っていたのか、鍵が未認定だったのか、Registrar が違ったのか、方式が古かったのか、EPP が失敗したのか、DNS 公開が遅れたのかが分かる。単一の「validated」では、どの権限が何を決めたかを再現できない。

Heng Lu の reality layers に照らせば、署名は表現と出所の層にある強い事実である。その強さを保つには、Registry の判断や実運用の代わりに語らせないことが必要だ。running code は各システムが実際に行った遷移を示すところから始まる。

出典