要約

  • RFC 1485 は、既知の X.500 Distinguished Name を ASN.1 の外へ出し、名刺やメールでも構造を保てる利用者向け文字列表現を定めた。
  • 「曖昧でなく解析できる」とは、適合する文字列から一つの DN 構造を復元できるという意味である。区切り、配置、属性記述子、OID、引用や符号化の選択により、同じ DN に複数の正当な表記があり得た。
  • 復元された DN は問い合わせの入力になっても、エントリの存在、鮮度、同一性、本人認証、認可、現実の結果を証明しない。

引用符の中に残されたコンマ

組織名そのものにコンマが含まれていたら、その記号を RDN の区切りとして読ませてはいけない。値の先頭や末尾に空白がある場合、連続する空白を保ちたい場合も、見栄えを整える処理に任せれば構造が変わり得る。RFC 1485 は引用とエスケープによって、値の文字と文法の文字を分離した。

この細部は、RFC 1485 の目的をよく示す。X.500 では Distinguished Name がエントリの構造化された鍵であり、プロトコル内部では ASN.1 で扱えた。しかし、名刺や通常のメールは ASN.1 オブジェクトをそのまま運ばない。人が読めて、機械が元の構造へ戻せる境界表現が必要だった。

これは名前を推測する仕組みではない。RFC 1484 は利用者が入力した友好的な「名乗られた名前」から候補 DN を探した。RFC 1485 は DN がすでに分かっている地点から始まる。検索結果を選ぶことと、その結果を文字列化することは別の操作である。

一行の中に保持された階層

属性型と値は = で結ばれた。RDN は人が読みやすいように、より具体的な部分から広い命名コンテキストへ向かう順で示された。コンマまたはセミコロンが RDN を区切り、+ は複数の AttributeTypeAndValue を一つの多値 RDN に束ねた。

+ とコンマの違いは装飾ではない。前者を後者へ置き換えると、一つの命名段階に属した二つの表明が、連続する二段階へ変わってしまう。型を省くことも RFC 1485 の DN 表現では許されない。文字列は、値だけでなく型、RDN 内のまとまり、RDN の順序を運んでいた。

一方、コンマとセミコロン、単一行と複数行という表示の自由は残された。異なる見た目から同じ構造へ戻れることが成功であり、全員が同じ見た目を生成することは成功条件ではなかった。

未知の値を捨てないための「醜い」表現

既知の属性には短い記述子を使える。受信側がその記述子を知らない場合、型はドット区切りの数値 OID で表せた。さらに適切な表示形式を持たない値には、BER 符号化を十六進数で示す退路があった。

RFC はその結果を醜いと認め、病的な場合に限られるだろうと述べた。しかし、一般性を支えたのはこの退路である。身近な姓名だけを美しく書ける形式では、将来の型や私的な型に出会った瞬間に情報が失われる。OID と十六進数は、現在の UI が理解できない事実を、理解したふりをせず保存する。

もちろん、OID を解析できることはスキーマを理解することではない。BER の値を復元できても、その表示法や照合規則が判明するとは限らない。損失のない輸送と意味の理解は、ここでも別の能力だった。

解析の一意性と表記の正規性

適合文字列が一つの DN に戻ることと、一つの DN に唯一の文字列があることは逆向きの命題である。RFC 1485 が求めたのは前者だった。

区切りとレイアウトが選べるだけでも複数表記が生じる。属性型は記述子でも OID でも現れ得る。特殊文字のエスケープ、表示可能な値と符号化値の選択、実装が持つ登録表も出力へ影響する。したがって、生の文字列一致を DN の同一性とみなす根拠はない。

後継文書は境界をさらに明文化した。RFC 1779 が RFC 1485 を置き換え、RFC 2253 が LDAPv3 用の UTF-8 表現を定め、RFC 4514 がそれを更新した。RFC 4514 は DN の正規文字列表現を定義せず、解析可能であれば別の変換アルゴリズムも許す。等価性は文字列のバイト比較ではなく distinguishedNameMatch で決める。

後代の文言を古い RFC に帰属させる必要はない。系譜をたどることで、1993 年の成果が「復元可能な表現」であり「唯一の綴り」ではなかったと正確に位置づけられる。

似て見えることは照合結果ではない

画面は字形を示す。保存メールは、文字集合の扱いが分かれば、送られたバイトを示す。パーサは型と値からなる RDN 列を示す。ディレクトリの照合器はスキーマに従って値を比較する。この四つは同じ証拠ではない。

RFC 4512 は属性型、構文、照合規則、DN を LDAP 情報モデルに置く。RFC 4517 は構文と照合規則を定め、RFC 4518 は国際化文字列のマッピング、正規化、禁止文字、双方向処理を扱う。字形が同じでもコードポイントや構造が異なり得るし、表記が違っても規則上は等しい場合がある。

古い DN を一律に小文字化したり、空白を削ったり、OID を推測したラベルへ交換したりすれば、誤った統合と分割が起こり得る。移行の証拠には、原バイト、符号化、シリアライザとパーサの版、記述子登録表、復元構造、スキーマ、照合規則が要る。

パース完了は問い合わせ開始点だった

RFC 1309 が描いた X.500 は、DUA、DSA、命名コンテキスト、連鎖、参照、複製からなる分散環境だった。RFC 1485 はその状態を固定しない。復元した DN はディレクトリ操作へ渡せるが、その操作の応答ではない。

ゆえに、パース成功はエントリがその時点で存在したこと、参照した複製が新鮮だったこと、アクセス制御で属性が隠されなかったことを証明しない。エントリが見つかっても、DN は現実の人物を認証せず、サービスの支配、役職、支払い、メッセージ配送を保証しない。

RFC 1485 の Security Considerations は安全性を論じていないと明記した。構造保存の文法へ、機密性、完全性、なりすまし耐性、認可を後付けしてはならない。

Historic になっても文字列は残る

RFC Editor の記録 では RFC 1485 は現在 Historic である。RFC 3494 は LDAPv2 技術仕様を Historic へ移す措置の一部だった。後継仕様は UTF-8、エスケープ、記述子、照合の説明を更新した。

しかし、標準上の交代はメール、設定、ログ、バックアップを消去しない。古い表記を読む実装や登録表が残ることも、失われることもある。Historic は現在の標準的推奨を示す地位であり、過去の実装が無価値だったことや、遺物が存在しないことの証明ではない。

境界ごとに判断を止める

Heng Lu の稼働コードの優位、将来判断の局所性、現実の層という議論から読むと、RFC 1485 の小ささは欠点ではない。共有仕様は交換に必要な最小文法を置き、各シリアライザは表示を選び、パーサは構造だけを復元する。現在状態はディレクトリ運用者が持ち、認証と認可は別の主体が決める。

信頼できる記録は、元の構造化 DN、直列化バイト、輸送処理、パース結果、スキーマに基づく照合、ディレクトリの時点状態、エントリ版、認証、認可、結果を分けて残す。一つの文字列に後続判断を代行させれば、便利な表現が不当な権力へ変わる。

RFC 1485 は名前を人間の媒体へ持ち出しても構造を戻せるようにした。その境界を守る最良の方法は、境界の外側まで解決したと主張しないことである。

出典