要約

  • RFC 1485 は既知の ASN.1 構造である DN を人向け文字列へ変換した。省略名からエントリを探索する仕様ではない。
  • 区切り、折り返し、引用、OID、16進値、多値 RDN により、同じ構造に複数の表示が生まれ得る。
  • 現行 LDAP は正準文字列を定義せず、DN 等価性を schema と matching rule に委ねる。エントリの信頼性はさらに別問題である。

最初の受け手は人だった

RFC 1485 が想定した場面は、ディレクトリ同士の通信だけではない。ASN.1 で表された Distinguished Name を、名刺やメールや文章で人から人へ渡す必要があった。RFC Editor の記録は、1993年7月の standards-track 文書が現在 Historic であることを示す。

ここでは検索対象はすでに決まっている。RFC 1484 の UFN が扱ったのは、不完全な人間の入力から候補を探す過程だった。RFC 1485 は、その結果として得られた構造をどう外へ出すかを扱う。同じ「名前」でも制御面が違う。

一般性は例外を隠さなかった

普通の名では CN、O、OU、L、ST、C が読みやすい。未知の属性型には点区切り OID、通常表示しにくい値には16進表現が用意された。仕様自身が後者を ugly と呼んだ点は重要だ。例外を自然に見せかけず、損失なく通す経路として露出させた。

最小共通仕様の役割は、すべてを一つの美しい語彙へ押し込むことではない。受け手が型と値を復元でき、未知のものを未知のまま保持できることにある。

RDN の順序と AVA の順序は同じではない

RFC 1485 は最も具体的な RDN を先に書いた。RDN 間はコンマまたはセミコロン、値中の特殊文字は引用またはエスケープ、複数 AVA からなる RDN は + で表す。空白や改行による折り返し、文章中の山括弧も認められた。

ところが線形表示には二種類の順序が投影される。RFC 4512によれば、DN は RDN の列だが、一つの RDN は AVA の順序なし集合である。RDN の位置は経路を変え得る一方、同じ RDN 内で AVA を入れ替えても別名にはならない。

文字列比較だけでは、この構造差を見抜けない。コンマが値の一部か境界か、短い属性名がどの OID か、エスケープがどの octet を示すかは parser と schema が決める。

後継仕様は契約の版を可視化した

RFC 1779 の記録と本文は、1485 を置き換え、エスケープを整え、区切りの混用を避けた経緯を残す。RFC 2253は LDAPv3 と UTF-8 へ移り、記録に後継関係が残る。現在の LDAP 表現は RFC 4514とその記録にある。

この変更史は、古い文字列を現在の parser へ黙って投入してはいけない理由になる。受理される区切り、登録済み descriptor、Unicode の扱いが版ごとに違う。保存対象は文字列だけでなく、それを読める契約である。

また RFC 4514 は、ユーザーインターフェースが属性型名を現地語へ翻訳する可能性を認める。画面の自然さとプロトコル上の相互運用性は同じ層ではない。

等価性は実行される

RFC 4514 は DN の正準文字列を定義しない。他の適合 encoder が異なる表記を出せるため、等価性は RFC 4517 の distinguishedNameMatch で判定する。

同規則は RDN の数と位置を比べ、RDN 内の AVA 順序を無視し、各属性値をその属性型の equality matching rule で比べる。RFC 4518は国際化文字列の map、normalize、禁止文字、空白処理を定める。条件によっては結果が Undefined になる。

したがって、raw text の一致は高速な近道であって、DN 等価性ではない。違う表記を別ユーザーとして登録したり、異なる schema で解釈された似た文字列を同一化したりする危険がある。

CN=Sam は元の型を語れない

RFC 4514 の例では、TeletexString の Sam と PrintableString の Sam が同じ CN=Sam になり得る。そこから元の BER/DER を常に再構成できるわけではない。証明書処理などで exact DER が必要なら、# 付き16進表現を使うべきだとする。

読みやすい転送、DN の等価性、元 octet の保存は三つの要件だ。一つの表示がすべてを満たすとは限らない。

指すことと証明すること

RFC 4512 は、DN がディレクトリ木の一つのエントリを曖昧なく指すと述べる。エントリは対象に関する属性を持つ。しかし文字列の送信者、エントリの管理者、属性の現在性、証明書の有効性、操作権限は別の証拠を要する。

DN には氏名、メールや IP アドレス、所在地、所属が含まれ、開示リスクもある。RFC 4514 は命名規則とアクセス制御を促すが、RFC 1485 は security issues を論じなかった。階層的な外観は安全機構ではない。

Heng Lu のrunning-code primacy、最小仕様とローカルな判断、現実の層を適用すると境界は明快だ。文法は構造を運ぶ。schema は意味を決める。ディレクトリはエントリを返す。アプリケーションは認証し、認可し、結果を記録する。

RFC 1485 は最初の境界を強くした。その文字列に残りの権限まで与えないことが、設計を守る。

出典