要約

  • RFC 1959 は、LDAP サーバーの場所、識別名、返してほしい属性、検索範囲、フィルターを一つの URL に記述した。省略欄に入る既定値は検索を組み立てる規則であり、観測結果ではない。
  • ホスト名は省略でき、資格情報を記述する欄はなかった。同じ URL でも、選んだサーバー、セッション、アクセス方針、実行時刻が違えば返答は変わり得る。
  • URL は一回の検索方法を示す。接続先、許可された属性、検索の完了、結果を使うアプリケーションの行為を証明しない。

空欄を含む形式が便利だった

1996 年の RFC 1959 は、LDAP を URL を扱えるインターネットクライアントへ接続した。当時 LDAP は X.500 の軽量な入口として説明されていたが、書式は単独の LDAP サーバーにも使えるようにされた。外側の URL は運搬の仕組みであり、内側のディレクトリは固有の名前、検索、アクセス規則を保った。

並び順は明確だった。ldap:// の後に任意のホストとポート、スラッシュの後に識別名を置き、必要なら属性、範囲、フィルターを疑問符で区切った。ホストは接続先、識別名は検索の起点、属性は返答希望、範囲は基点・一階層・部分木、フィルターは一致条件を表す。

既刊の RFC 1558 論考が扱うのは、読みやすい Filter が実行可能な述語であり続ける境界である。本稿が扱うのは、その Filter をほかの検索項目と一緒に運ぶ外側の封筒だ。フィルターだけではサーバーも起点も範囲も決まらず、URL の外形だけではフィルター内部の意味は決まらない。

RFC 1959 は空欄にも働きを与えた。ポートを省けば TCP 389、属性を省けば全属性の要求、範囲を省けば基点検索、フィルターを省けば (objectClass=*) となる。これらはサーバーから得た事実ではなく、クライアントが SearchRequest を作るための既定値だ。

ミシガン大学を部分木検索する例では、二つの疑問符が続く。属性欄を空にしたまま、その後の sub とフィルターを正しい位置に置くためである。空欄は誤記ではない。決定を既定規則へ渡す構文だった。

省略可能ということは、決定が消えることではない。仕様上の既定値へ移るか、クライアントや運用環境へ残る。記録が目に見える値だけを保存すれば、「書かなかったこと」が実際に生んだ選択を失う。

一つの URL の中に二つの構文があった

識別名とフィルターにはそれぞれ内側の文法がある。さらに、空白など URL で使えない文字を RFC 1738 の百分率符号化で包む。検証済み Errata 528 は、識別名の参照先を RFC 1485 から RFC 1779 へ訂正した。

百分率符号化は文字列を運べる形にする。識別名を唯一の正規表現にするわけでも、フィルターを安全にするわけでもない。受信側は外側を復号し、その後で内側を解析する。届いたバイト列と、検索されたディレクトリ項目は別の証拠である。

サーバー名の省略は選択権を残した

ldap:/// で始まる例にはホストがない。RFC 1959 は、対象が X.500 名前空間にある場合、X.500 のバックエンドを提供する任意の LDAP サーバーへ問い合わせられるとした。

参照を一台に固定しない利点はあった。同時に、その文字列だけでは実際の接続先、到達性、サーバーが見せた複製やビュー、問い合わせ時刻が分からない。「任意」は「すべて」でも「権威ある一台」でもない。X.500 を前提とした解決経路を示したにすぎない。

後継の RFC 2255 は、ホストを省くクライアントには適切なサーバーについての事前知識が必要だと明記した。接続を新設するか再利用するか、どの安全機構や認証を使うか、URL にないサイズ上限、時間上限、別名参照をどう設定するかもクライアント側に残った。

これは RFC 1959 の隠れた機能ではない。後の文書が処理手順を説明したことで、初期 URL が運んでいなかった情報が見えるようになったのである。

資格情報のない検索とアクセス許可は同じではない

RFC 1959 は、URL に資格情報を書く方法がないため、解決は未認証になると予想した。未認証検索は直ちに不正アクセスを意味しない。匿名公開を意図したディレクトリもあり得る。しかし、URL に列挙した属性を受け取る権利も生まれない。

属性欄の省略は広い要求を作る。サーバーに保護データの開示を命じるものではない。後の RFC 4511 は、検索と返される属性がアクセス制御や管理上の制限を受け、返された項目に値が一つも含まれない場合さえあると明記する。

同じ文字列を持つ二人が、同じ主体になることもない。匿名セッション、許可された認証セッション、別の方針時点では、公開属性、制限されたビュー、エラーという異なる結果が生じ得る。相違は URL の矛盾ではなく、サーバー、セッション、方針、時刻の事実だ。

検索結果は文字列の中に保存されなかった

現在の RFC 4511 では、検索はゼロ個以上の項目や参照を返し、最後に SearchResultDone が成功またはエラーを示す。RFC 1959 はこのメッセージ列を URL に圧縮せず、URL をスナップショットにもしていない。

URL が示せるのは、意図した起点、範囲、フィルター、要求属性である。別時点に同じデータが評価されたこと、制限による打ち切りがないこと、参照が追跡されたこと、最後の成功応答が到着したことは示せない。

一件の返答も全体の証明ではない。あるサーバーが結果列の一地点で、あるクライアントへ何を出したかを示すだけだ。利用側は、件数が十分か、空結果に意味があるか、参照を追うか、その後の行為が安全かを別に判断する。

小さな共通形式に余分な権力を載せない

RFC 4516 は LDAPv3 用の現行 URL 形式を定め、すべての SearchRequest パラメータを表現できるわけではないと明記した。URL は参照知識にも使われるが、クライアントが安全方針の中で解釈し、実行する関係は変わらない。

Heng Lu の最小初期仕様という視点では、RFC 1959 の価値は共通面が小さく、運搬可能だったことにある。その便利さへサーバー発見、本人性、許可、完全性、アプリケーション意図まで読み込めば、仕様にない権限を後から加えることになる。

文書、文字列、解析、接続、LDAP 応答、後続行為はそれぞれ証拠を持つべきだ。RFC 1959 は検索を旅させた。検索を権威にはしなかった。

出典と限界

RFC の同一性、状態、履歴は IETF Datatracker と RFC Editor 情報ページ にある。原文は RFC 1959 HTML と テキスト、DN 参照の訂正は Errata 528 で確認できる。背景仕様は RFC 1777、RFC 1558、RFC 1738、後継境界は RFC 2255、RFC 4511、RFC 4516 に基づく。

分析の枠組みは Heng Lu の Running-Code Primacy、Minimum Initial Specification、Reality Layers から得た。これらは LDAP 配備の証拠ではない。

資料は仕様上の境界を示すが、現在の普及率、製品適合性、実在ディレクトリの内容、侵害、現行アクセス方針、利用側の判断は証明しない。