要約

  • RFC 3494は、RFC 1777に忠実な独立実装が既存LDAPv2実装と相互運用できないと記した。運用側の構文と意味が文書から分岐していたからである。
  • Historicという状態は今後の実装先をLDAPv3へ向けたが、稼働中の端点を停止しない。LDAPv3という番号だけでも認証、完全性、機密性は証明されない。

通常、仕様適合試験は未知の相手と会うための切符である。RFC 3494が残した記録では、その切符の行き先と現実の駅が別れていた。公開文書から新しく作った実装ほど、製品群が長年共有してきた非公開の慣行を知らなかった。

最初の差は文字だった。RFC 1777はLDAPStringをOCTET STRINGとして運びながら、合法な文字をIA5に限った。RFC 1778はT.61を含む属性構文の表現を補った。しかしRFC 3494によれば、既存製品はISO 8859-1、UCS-2、UTF-8、またはホストのローカル文字集合を使っていた。

これは単なる機能拡張ではない。同じバイト列の解釈も、同じ名前の往復表現も実装ごとに変わりうる。ASCIIだけの試験が成功しても、人名や組織名を保存して取り出せるとは限らない。文書が許す入力を正確に受け入れる新実装が、現場で既に使われる文字を拒むこともあった。

二つ目の差はさらに小さい。RFC 1777ではOID 2.5.4.10の属性型をX.500のテキスト名organizationNameで表す。既存LDAPv2製品はLDAPv3スキーマの短いNAMEであるoを一般に使っていた。後継仕様の慣行が、旧仕様の正式な退役より先に旧実装へ流れ込んだのである。

長い名前、短い名前、数字OIDが同じ属性型を指しうるとしても、受信側が同じ写像を持つ保証はない。写像できても、スキーマ受理、アクセス制御、返却値、アプリケーション判断は別の段階である。互換層が一文字へ短縮するたびに、どの権威に従ったかという新しい状態が生まれる。

RFC 3494は「全組合せが失敗する」とは述べなかった。同じ系譜や偏差を共有する製品同士なら動作しうる。述べたのは、仕様が一般に守られておらず、仕様だけを根拠にした独立実装が既存実装と相互運用できないということだった。相互運用性は公開規範ではなく、実装の家系に依存するようになった。

この構図はロックインを生む。既存ベンダーが偏差を直せば顧客が壊れ、新規参入者が形式的正しさを守れば接続できない。試験もRFCへの適合ではなく、有力製品の模倣へ近づく。仕様は誰でも読めるのに、必要な知識は導入履歴の中に閉じる。

安全性も退役理由だった。LDAPv2はデータ完全性と機密性の仕組みを持たず、RFC 3494はDIGEST-MD5、Kerberos V、X.509公開鍵に基づく当時の現代的認証を支えないとした。RFC 1777のsimple bindは平文パスワードであり、Kerberosは第4版だった。RFC 3377はLDAPv3の技術仕様に認証とTLSの文書を明示的に組み込み、以前のIESG注記へ応えた。

それでもLDAPv3は安全性の領収書ではない。RFC 4510が仕様群を再編し、RFC 4513が認証と安全機構を定めた後も、運用者は機構を選び、保護チャネルを成立させ、資格情報を検証し、認可を適用する必要がある。Bindでバージョン3を要求した事実は、その後の状態を代用しない。

退役は依存文書にも及んだ。RFC 1781はRFC 1779の名前構文に依存し、RFC 2253ではその友好名構文が除かれた。RFC 2559はLDAPv2をPKIXリポジトリに適用し、RFC 1777に依存してRFC 1778を更新した。RFC 3494はこれらとLDAPv2本体、さらに既に置換済みのRFC 1484、1485、1487、1488をHistoricへ移すよう勧告した。

Historicは文書の状態であり、プロセス監視値ではない。RFC 2026は新仕様に置換されたか、その他の理由で廃れた仕様にこの水準を与える。RFC 2400は一語の状態は指標にすぎず、詳しい適用説明を読むべきだとした。勧告は新規LDAPv2実装をやめ、LDAPv3を選ぶ方向を示したが、ポートを閉じず、ソフトを削除せず、残存通信量を測らなかった。

LDAPがX.500への参入費用を下げ、実用を広げた功績と、この分岐は両立する。普及したからこそ実装慣行が自力で進化し、文書との距離が拡大した。RFC 3494は過去を消す宣言ではなく、将来の協調先を選び直す文書だった。

監査では文書状態、実装挙動、有効設定、要求版、文字変換、スキーマ別名、安全機構、交換成功、認可、業務結果を別々に記録する。Historicは最初の制度判断を証明できるが、後の実行状態を生成しない。

出典