要約

  • RFC 1484 の User Friendly Name は、利用者が提示する purported name であり、保存済みの識別子ではない。検索して初めて一つ以上の Distinguished Name に結びつく。
  • 解決結果は、順序付きのローカル環境、スキーマ、現在の項目、代替値、照合規則、そして曖昧な場合の人間の選択に左右された。
  • 得られた DN が一意に指すのはディレクトリ項目である。本人認証、権限、属性の真実性、後続処理の成功は別の証拠を要する。

一意性には有効期限があった

RFC 1484 は、人が会議で聞いた名前をそのまま入力できる仕組みを目指した。型付きの X.500 Distinguished Name を名刺に書き写し、複雑なフォームへ分解する必要をなくすためである。

しかし文書は、入力を DN とは呼ばない。purported name、つまり「そうだと提示された名前」と呼ぶ。属性型、上位の階層、中間の組織単位を省き、略称、別値、近似綴り、親しみのある国名を使える代わりに、ディレクトリが不足分を解かなければならない。

RFC 1484 が解決後の DN を原則として保存するよう勧めた理由は明快だった。新しい名前が現れれば、昨日まで曖昧でなかった purported name が曖昧になり得る。短い文字列の一意性は、成長する名簿の状態に期限付きで成立する性質だった。

省略はローカル設定へ移された

型を省いても、型そのものが不要になったわけではない。既定スキーマは末端を Common Name、上位を Country、その間を Organisation や Organisational Unit として補える。文脈依存やデータ依存の既定も想定された。

規則だけで決められない部分は検索になる。同じ二文字が国、州、組織のどれとして扱われるかは、ツリー上の位置や登録値に依存する。中間要素を飛ばした短縮名は、複数属性と複数階層を探させる。

そのため、画面に残った入力欄だけでは判断を再現できない。必要なのはクライアント、言語、パーサ、既定スキーマ、起点、検索フィルタ、ディレクトリ時点、候補と応答である。人に見える簡潔さは、機械側の文脈を消すのではなく見えなくした。

environment の順番が「近く」を決めた

RFC 1484 のローカル environment は、DIT 内の非リーフ DN を並べたリストである。入力要素数に応じて使うリストが変わり、個々の利用者が制御できることが望まれた。

大学内 DUA の例では、一要素の名前を学科、大学、国、ルートの順で探す。二要素では国や大学から始まる。米国の公共 DUA には別の順序がある。

この差は UI の好みではない。最初に見つけた exact match が後の探索を止めるなら、順番が選択結果に介入する。同じ姓を大学内で入力した人と、公共端末で入力した人は、違う候補集合を受け取り得る。

短名を監査するなら environment を設定値ではなく判断入力として保存しなければならない。保存されなければ、なぜ別の組織が探索されなかったのか説明できない。

exact、good、poor は分岐条件だった

提案アルゴリズムは照合を exact、good、poor に分ける。exact は常に追跡する。exact がなければ good を追う。poor しかなければ利用者に候補を示し、すべて拒否されたら次の environment を試す。

姓のイニシャルを同一人物の別表現とみなすか、略称を登録済みの別値とみなすか、短い鍵で部分一致を許すか。これらは検索の枝を変える実装判断である。ユーザーの確認もアルゴリズム外の雑音ではなく、結果を決める入力だった。

後の RFC 4511 では、LDAP 検索に base、scope、alias 処理、size/time limit、filter、属性選択がある。応答は項目だけでなく continuation reference を含み、最後に結果が来る。最初の一件を見たことは検索完了の証明ではない。

UFN、DN、DN 文字列を分ける

RFC 1309 の X.500 モデルでは、項目は Directory Information Tree に置かれ、根からの RDN 列が DN になる。RFC 1309 の既存記事は DUA/DSA、chaining、referral、alias、複製の管理を扱う。RFC 1484 の焦点は、その完全な道筋を知らない人がどう探すかである。

同時期の RFC 1485 は、既知 DN を曖昧なく文字列化する別問題を扱った。その表記は RFC 1779、RFC 2253、RFC 4514 へ更新された。

RFC 4514 は、一つの canonical string を定めないと明記する。DN の等価性は distinguishedNameMatch に従う。表示文字列の完全一致を項目同一性に置き換えてはならない。

RFC 4512 では、属性型が構文と照合規則を持ち、RDN は兄弟間で一意、DN はツリー内の項目を一意に参照する。RFC 4518 は国際化文字列の照合準備を定める。見た目、符号化、照合値、項目参照は別の層である。

ディレクトリ項目は本人の宣誓ではない

DN が項目を一意に参照しても、端末の利用者がその項目の本人だとは限らない。項目は対象についての属性集合であり、属性の更新責任、アクセス制御、複製の時点、外部制度との関係は別に存在する。

利用者が同姓同名から一人を選んでも、認証は終わらない。アプリケーションは認証済み主体、権限規則、使った属性版、実行内容と結果を残す必要がある。宛先発見はメール配送の証拠でも、アカウント作成の承認でもない。

RFC 1484 が扱ったのは「探しやすさ」であり、「信じる資格」ではなかった。

実装経験は成功談だけではなかった

文書は PSI Pilot の FRED と配布リスト管理プロトタイプでの実装を報告し、利用者反応を favourable とした。仕様が稼働したという一次資料である。

同時に、多段の Organisational Unit を飛ばすと弱いこと、前後ワイルドカード検索が高コストになり得ることを記した。曖昧性、効用、性能、アルゴリズム変種は将来調査の対象だった。形式は安定し得ても、解決手順は経験で変えるべきだとした。

RFC Editor の記録 は文書の位置を示すが、採用率を測らない。Experimental 文書であり、Security Considerations は安全性を議論しないと述べる。プライバシーや本人保証を後から付け足すことはできない。

使いやすさを証拠連鎖の先頭に置く

Heng Lu の稼働コード優先、最小仕様と局所的な将来判断、現実の層という視点は、RFC を越えた主張ではなく境界を読む補助線になる。共通形式は小さく、検索環境はローカルに、現行データはディレクトリに、曖昧な選択は利用者に、実行権限はアプリケーションに残った。

完全な履歴は、入力文字列だけでも最終 DN だけでもない。発話、purported name、environment、検索、候補、選択、DN、項目版、認証、認可、結果をつなぐ。RFC 1484 の親しみやすさは、この連鎖を不要にしたのではなく、人間の入り口を良くしたのである。

出典