現代のネットワークインフラにおいて、ユーザー情報やデバイスの管理に欠かせない「ディレクトリサービス」の原点とも言えるのがX.500です。1988年に国際電気通信連合（ITU-T）によって承認されたこの規格群は、もともとX.400電子メール交換における名前解決や要件をサポートするために設計されました。国際標準化機構（ISO）および国際電気標準会議（IEC）との連携により、OSI（開放型システム間相互接続）プロトコルスイートの一部として体系化されています。
Key Facts
- 開発主体：ITU-T、ISO、IECによる共同開発。
- 目的：電子ディレクトリサービスの標準化と、X.400メールシステムのサポート。
- データ構造：ディレクトリ情報ツリー（DIT）という階層構造を採用。
- 主要な派生：現代のインターネットで広く使われるLDAPやX.509証明書の基礎となった。
- 識別番号：ISO/IEC 9594として定義されている。
X.500のデータモデルと構造
X.500の核心は、ディレクトリ情報ツリー（DIT）と呼ばれる階層的な組織構造にあります。このツリーは、1つまたは複数のディレクトリシステムエージェント（DSA）と呼ばれるサーバーに分散して配置されます。
DIT内の各「エントリ」は、複数の属性とそれに対応する値で構成されています。各エントリには、ルートからそのエントリに至るまでの相対識別名（RDN）を組み合わせた、世界で唯一の識別名（Distinguished Name: DN）が割り当てられます。このモデルは、後のLDAP（Lightweight Directory Access Protocol）にも色濃く受け継がれています。
また、X.520およびX.521では、個人や組織をエントリとして表現するための属性やオブジェクトクラスが定義されており、これらは「ホワイトページ」スキーマとして広く普及しました。
通信プロトコルの詳細
X.500では、役割に応じて複数のプロトコルが定義されています。当初はOSIネットワークスタックを使用していましたが、後にTCP/IPスタック上での動作を可能にするIDM（Internet Directly-Mapped）プロトコルなどが導入されました。
| プロトコル名 | 役割と機能 | 主な仕様 |
|---|---|---|
| DAP (Directory Access Protocol) | クライアント（DUA）とサーバー（DSA）間のリクエスト交換 | ITU-T X.511 |
| DSP (Directory System Protocol) | DSAサーバー同士の相互通信 | ITU-T X.518 |
| DISP (Directory Information Shadowing Protocol) | サーバー間でのデータ複製（レプリケーション） | ITU-T X.525 |
| DOP (Directory Operational Bindings Management Protocol) | レプリケーション等の運用上の合意管理 | ITU-T X.501 |
| CASP / AVMP / TBP | 証明書発行、権限検証、信頼ブローカー機能 | X.509 / X.510 |
OSIスタックの複雑さを解消するため、インターネット環境向けに開発されたのがLDAPです。LDAPはDAPの代替としてTCP/IPを利用し、より軽量なアクセスを実現したため、現在でも主流のプロトコルとして利用されています。
X.509証明書と現代のWebセキュリティ
X.500規格の一部であるX.509は、認証フレームワークとして独立して発展し、現在では公開鍵証明書の標準フォーマットとして世界中で利用されています。もともとはX.500ディレクトリを介して証明書を管理する設計でしたが、Webの普及に伴い、ブラウザにルート証明書をあらかじめ組み込む方式（ブラウザバンドル方式）が主流となりました。
これにより、SSL/TLS通信による安全な電子商取引が可能になりましたが、一方でディレクトリによる厳格な「バインディング（証明書と実在する組織の紐付け）」というプロセスはバイパスされる傾向にあります。X.500モデルでは、証明書を単なる属性の一つとして扱い、物理的な住所や電話番号などの他の属性と併せて検証することで、より強固な信頼性を確保できるとされています。
過去には、国家レベルの攻撃者による証明書の偽造や、認証局（CA）の侵害による不正発行などのセキュリティ事件が発生しました。こうした背景から、単に信頼済みリストにあるかを確認するだけでなく、証明書の正当性を透明に検証する「証明書の透明性（Certificate Transparency）」への取り組みが進んでいます。
その他の応用とガバナンス
証明書の配布には、ディレクトリサービスのほか、DNS（Domain Name System）が利用されるケースもあります。例えば、米国のヘルスケア業界（Direct Project）では、S/MIME証明書の公開にDNSやLDAPが活用されています。DNSは可用性が高く、証明書やアイデンティティの配布に適しているためです。
また、名前空間の管理についても、DNSがルートサーバー方式を採用しているのに対し、X.500は伝統的に国家的な命名権限に基づいた構造を持っており、国ごとに独自のサービスを展開する傾向があります。
X.500シリーズの主要規格一覧
- X.500 (ISO/IEC 9594-1): 概念、モデル、サービスの概要
- X.501 (ISO/IEC 9594-2): モデルの定義
- X.509 (ISO/IEC 9594-8): 公開鍵および属性証明書フレームワーク
- X.511 (ISO/IEC 9594-3): 抽象サービス定義
- X.518 (ISO/IEC 9594-4): 分散運用の手順
- X.519 (ISO/IEC 9594-5): プロトコル仕様
- X.520 (ISO/IEC 9594-6): 選択された属性タイプ
- X.521 (ISO/IEC 9594-7): 選択されたオブジェクトクラス
- X.525 (ISO/IEC 9594-9): レプリケーション
- X.530 (ISO/IEC 9594-10): 管理のためのシステム管理利用
Frequently Asked Questions
X.500とLDAPの最大の違いは何ですか？
最大の違いはトランスポート層のプロトコルと複雑さにあります。X.500は元々OSIスタックを用いて設計された重厚な規格ですが、LDAPはTCP/IPを利用してインターネット上で効率的に動作するように設計された「軽量（Lightweight）」な代替プロトコルです。
X.509証明書は今でもX.500の一部なのですか？
はい、規格上の定義としてはX.500シリーズの一部です。しかし、実運用においてはX.500ディレクトリから切り離され、WebブラウザやOSに組み込まれた信頼済みルート証明書として独立して広く利用されています。
DIT（ディレクトリ情報ツリー）とはどのような構造ですか？
DITは、情報を階層的に整理したツリー構造です。ルートから末端のエントリまでが親子関係で結ばれており、各エントリは一意の識別名（DN）を持つことで、大規模な分散環境でも正確にデータを特定できるようになっています。
なぜX.500の構想は完全に実現しなかったと言われているのですか？
RFC 2693などの指摘によれば、ディレクトリ情報を所有する組織がそのリストを機密情報と見なし、世界的に公開されるX.500サブツリーとして提供することに消極的だったため、グローバルに一貫した単一の識別名体系を構築することが困難だったためと考えられています。
証明書の「バインディング」とは何を意味しますか？
バインディングとは、デジタル証明書をディレクトリ内の特定の識別名（DN）や実在する組織のアイデンティティに紐付けることです。これにより、証明書単体の検証だけでなく、その証明書を提示している主体が本当に正しい組織であるかをディレクトリ上の他の属性（住所や電話番号など）を用いて多角的に検証することが可能になります。
References
- X.500 and LDAPcollectionscanada.gc.ca Archived 2021-04-01 at the
- "National Strategy for Trusted Identities in Cyberspace". Archived from the original on 15 August 2016. Retrieved 10 September 2023.
- K. Zeilenga (June 2006). Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates. Network Working Group. :10.17487/RFC4523. 4523. Proposed Standard. Obsoletes RFC 2252, 2256 and 2587.
- "Modernize Federal Identities". www.idmanagement.gov.
- Wendlandt, Dan; Andersen, David G.; Perrig, Adrian (June 2008). "Perspectives: Improving SSH-style Host Authentication with Multi-Path Probing" (PDF). Proceedings of the 2008 USENIX Annual Technical Conference: 321–334.
- P. Hoffman; J. Schlyter (August 2012). The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. . :10.17487/RFC6698. 2070-1721. 6698. Proposed Standard. Updated by RFC 8749, 7218 and 7671.
- P. Hoffman; J. Schlyter (May 2017). Using Secure DNS to Associate Certificates with Domain Names for S/MIME. . :10.17487/RFC8162. 8162. Experimental.
- Direct Trust. "ANSI/DS 2019-01-100-2021: Applicability Statement for Secure Health Transport Version 1.3".
- J. Peterson; O. Kolkman; H. Tschofenig; B. Aboba (October 2013). Architectural Considerations on Application Features in the DNS. . :10.17487/RFC6950. 2070-1721. 6950. Informational.
- ICANN Root Server System Advisory Committee. RSSAC 023v2: History of the Root Server System (Report). ICANN. Retrieved 4 October 2025.