500 の

X.500 は、電子ディレクトリ サービスをカバーするコンピュータ ネットワーク標準のシリーズです。X.500 シリーズは、国際電気通信連合(ITU-T) の電気通信標準化部門によって開発されました。ITU-T は、以前は国際電話電信諮問委員会 (CCITT) として知られていました。X.500 は 1988 年に初めて承認されました。^[1] ディレクトリ サービスは、X.400電子メール交換および名前検索の要件をサポートするために開発されました。国際標準化機構(ISO) と国際電気標準会議(IEC) は、標準の開発においてパートナーとなり、それらを開放型システム間相互接続プロトコル スイートに組み込みました。ISO /IEC 9594 は、対応する ISO/IEC 識別です。

X.500 で定義されているプロトコルには次のものがあります。

* これらのプロトコルは通常、複数の仕様とASN.1モジュールを通じて断片的に定義されます。上記の「定義仕様」列は、どの仕様がプロトコルに最も具体的に貢献するかを (主観的に) 示しています。

これらのプロトコルはOSIネットワーク スタックを使用していたため、インターネット クライアントがTCP/IPネットワーク スタックを使用して X.500 ディレクトリにアクセスできるようにするために、DAP の代替手段がいくつか開発されました。DAPの最もよく知られた代替手段は、軽量ディレクトリ アクセス プロトコル ( LDAP ) です。DAP とその他の X.500 プロトコルは現在 TCP/IP ネットワーク スタックを使用できますが、LDAP は依然として一般的なディレクトリ アクセス プロトコルです。

X.500 プロトコルは、従来、OSIネットワーク スタックを使用します。ただし、Lightweight Directory Access Protocol ( LDAP ) は、トランスポートに TCP/IP を使用します。ITU 勧告 X.519 の後のバージョンでは、Internet Directly-Mapped (IDM) プロトコルが導入され、X.500 プロトコル データ ユニット (PDU) を TCP/IP スタック経由でトランスポートできるようになりました。このトランスポートには、TCP 経由の ISO トランスポートと、プロトコル データグラムをフレーム化する単純なレコードベースのバイナリ プロトコルが含まれます。

X.500 の基本概念は、単一のディレクトリ情報ツリー(DIT)が存在することです。これは、ディレクトリ システム エージェント(DSA) と呼ばれる 1 つ以上のサーバーに分散されたエントリの階層構造です。エントリは属性のセットで構成され、各属性には 1 つ以上の値があります。各エントリには一意の識別名があり、これは相対識別名(RDN)、エントリ自体の 1 つ以上の属性、および DIT のルートまでの上位エントリの RDN を組み合わせて形成されます。LDAP は X.500 と非常によく似たデータ モデルを実装しているため、 LDAPに関する記事にデータ モデルの詳細な説明があります。

X.520 と X.521 は、DIT 内のエントリとして人物や組織を表すために使用される一連の属性とオブジェクト クラスの定義を提供します。これらは、最も広く導入されているホワイト ページ スキーマの 1 つです。

認証フレームワークを提供する標準の一部である X.509は、現在では X.500 ディレクトリ プロトコル以外でも広く使用されています。これは、公開鍵証明書の標準形式を指定します。

ディレクトリ構造の外部でWeb ブラウザーに直接ロードされる X.509v3 証明書の現在の使用は、電子商取引の発展に必要でした。これは、X.500 (1988) で最初に考え出されたように、デジタル証明書のソースとして X.500 ディレクトリを必要としない、安全な Web ベース (SSL/TLS) 通信を可能にすることによって実現されました。X.500 と X.509 の関係を理解するには、X.509 と X.509 の役割を比較する必要があります。X.509 は、WWW 以前は X.500 を更新するための安全なアクセス方法として設計されていましたが、Web ブラウザーが普及すると、Web サイトへのトランスポート層での接続を暗号化する簡単な方法が必要になりました。そのため、サポートされている証明機関の信頼されたルート証明書は、パーソナル コンピューターまたはデバイスの証明書ストレージ領域に事前にロードされていました。

サイバースペースにおけるデジタルアイデンティティを保護する2～3年プロジェクトである、サイバースペースにおける信頼できるアイデンティティのための米国国家戦略の2011～2014年の実施により、セキュリティの強化が見込まれている。 ^[2]

X.509v3 の WWW 電子商取引実装は、X.500 ディレクトリ内の識別名をバインドする元の ISO 標準認証メカニズムを回避しましたが、置き換えませんでした。

これらの証明書パッケージは、エンド ユーザーがソフトウェアに追加または削除できますが、信頼性の継続性については Microsoft と Mozilla によって審査されます。DigiNotarで発生したような問題が発生した場合、ブラウザー セキュリティの専門家は、証明書機関を信頼できないものとしてマークする更新を発行できますが、これは事実上、その CA を「インターネットの信頼」から削除する重大な行為です。 X.500 は、提供されたバンドルの外部で、特定のルート証明書を要求している組織を確認する方法を提供します。これは、ルート証明書が侵害されているかどうかを判断するための別のチェックを追加する「信頼の 4 コーナー モデル」として機能します。侵害された証明書を取り消すための Federal Bridge ポリシーを規定する規則は、www.idmanagement.gov で入手できます。

このブラウザ バンドル アプローチの対照的な点は、X.500 または LDAP では、属性「caCertificate」をディレクトリ エントリに「バインド」して、SSL 警告メッセージが表示されない限りエンド ユーザーが通常は気付かない、デフォルトで事前にロードされた証明書バンドルに加えてチェックできることです。

たとえば、SSL を使用する Web サイト (通常は DNS サイト名「www.foobar.com」) は、証明書がユーザーに提供された信頼されたルート証明書の 1 つによって署名されているかどうかを確認するライブラリを使用するソフトウェアによってブラウザーで検証されます。

したがって、ユーザーが HTTPS 経由で正しい Web サイトにアクセスしたという信頼が生まれます。

ただし、ドメイン名以外のものも検証されたことを示すために、より強力なチェックを行うこともできます。これを X.500 と比較すると、証明書はエントリの多くの属性の 1 つであり、エントリには特定のディレクトリ スキーマで許可されているものなら何でも含めることができます。したがって、X.500 はデジタル証明書を保存しますが、これは、住所、連絡先電話番号、電子メール連絡先など、組織を検証できる可能性のある多くの属性の 1 つです。

CA 証明書または証明機関証明書は、ブラウザーに自動的にロードされるか (Microsoft の更新メカニズムの場合)、またはブラウザーの新しいバージョンの更新時にロードされ、ユーザーには、ロードされた証明機関との個別の信頼関係をインポート、削除、または構築する追加の選択肢が与えられ、OCSP 失効サーバーが到達不能な場合にブラウザーがどのように動作するかを決定します。

これは、属性 caCertificate をリストされた証明機関に関連付けるディレクトリ モデルとは対照的です。

したがって、ブラウザは、読み込まれた承認済み証明書のグループを使用して Web サイトの SSL 証明書を検証したり、ルート証明書を X.500 または LDAP ディレクトリ (または HTTP/S 経由) で検索して、信頼できる証明機関のリストにインポートしたりできます。

「バインドされた」識別名は、ディレクトリ エントリに一致する証明書のサブジェクト フィールドにあります。X.509v3 には、国際ドメイン名以外のコミュニティに応じて、他の拡張機能を含めることができます。インターネットでの広範な使用のために、RFC-5280 PKIX では、暗号化された電子メールなどのアプリケーションに役立つ可能性のあるフィールドのプロファイルについて説明しています。

ブラウザや電子メールに提示される証明書の信頼性を信頼しているエンド ユーザーには、提示された偽造証明書 (おそらくブラウザの警告をトリガーする) と有効な証明書を簡単に比較する方法がなく、X.500 DIT で検索するように設計された DN (識別名) を検証する機会も与えられません。

証明書自体は公開されており、偽造不可能であると考えられているため、どのような方法でも配布できますが、ディレクトリでは ID への関連付けが行われます。バインドとは、証明書と、その証明書を使用していると主張する ID をリンクすることです。たとえば、Federal Bridge を実行する X.500 ソフトウェアには、証明機関間の信頼を可能にする相互証明書があります。

ドメイン名の単純な同形異義語の一致により、ドメインが正当なものであるように見えても実際にはそうではないフィッシング攻撃が発生することがあります。

X.509v3 証明書がディレクトリ内の有効な組織の識別名にバインドされている場合は、ブラウザに表示される内容とディレクトリに存在する内容を比較することで、証明書の信頼性に関する簡単なチェックを行うことができます。

公証人をチェックして、証明書が最近確認されたばかりで、侵害されている可能性が高いかどうかを確認するオプションがいくつかあります。^[3]証明書が信頼される可能性があり、ドメイン名がわずかに一致していないために失敗する場合、最初はブラウザで失敗しますが、その後、公証人の信頼の対象となり、ブラウザの警告を回避できます。

o=FoobarWidgets などの有効な組織エントリには、英数字の OID も関連付けられます。これは ANSI によって「ID 証明」されており、証明書と ID のバインドに関する別の保証レイヤーを提供します。

最近の出来事 (2011 年) は、証明書を偽造した国家内の未知のアクターによる脅威を示しています。これは、 Web 経由で Facebook にアクセスするシリアの政治活動家に対するMITM攻撃を仕掛けるために行われました。通常、これはブラウザの警告を引き起こしますが、MITM 証明書がブラウザや他のソフトウェアによってすでに信頼されている有効な認証局によって発行された場合は、警告は発生しません。同様の攻撃は Stuxnet でも使用され、ソフトウェアが信頼されたコードを偽装することができました。証明書の透明性のポイントは、エンド ユーザーが簡単な手順で証明書が実際に有効かどうかを判断できるようにすることです。デフォルトの証明書バンドルと照合するだけでは不十分な場合があり、追加のチェックが必要です。証明書の透明性に関するその他の提案も提出されています。^[4]

証明機関である Comodo に対しては別の攻撃が行われ、その結果、有名な通信 Web サイトを狙った偽造証明書が発行されました。このため、主要ブラウザに緊急パッチを適用する必要がありました。これらの証明書は実際には信頼できる証明機関から発行されたものであるため、偽造 Web サイトにアクセスしたユーザーには警告がありませんでした。これは、Palo Alto を Alto Palo に置き換えたり、シリアル番号を間違えたりするなど、証明書が粗雑に偽造されていたシリアでの事件とは対照的です。

PHI (保護された健康情報) ( HIPAA の機密性が高いと見なされる) を交換するように設計された一部のプロジェクトでは、CERT DNS リソース レコードまたは LDAP から X.500[2008] ディレクトリを介して X.509v3 証明書を取得する場合があります。権威あるバインドの問題は、DNSSEC を使用してルートから署名することで保護される DNS 情報の正確性に関連する RFC で詳しく説明されています。

ルート ネーム サーバーの概念は、インターネット コミュニティで大きな論争の的となってきましたが、DNS に関してはほぼ解決されています。X.500 に関連付けられた名前空間は、従来、国家の命名機関から始まると考えられてきました。これは、国家の代表によるグローバル システムに対する ISO/ITU のアプローチを反映しています。したがって、さまざまな国が独自の X.500 サービスを作成します。USX500 は、米国政府が既知の政府機関以外への X.500 または DNS 登録を提供しなくなった 1998 年に民営化されました。

X.500 パイロット プロジェクトは商業分野で開発が進められており、このテクノロジは、企業のデータ センター内の数百万のユーザーの主要な導入環境や、米国政府内で認証に使用され続けています。

RFC 2693 ( SPKIに関する) の著者は、「元の X.500 計画が実現する可能性は低い。ディレクトリ エントリのコレクションは、リストを所有する者によって貴重または機密と見なされ、X.500 ディレクトリ サブツリーの形式で世界に公開される可能性は低い」と指摘し、「識別名 (エンティティを参照するときに誰もが使用できる単一のグローバルに一意の名前) という X.500 のアイデアも実現する可能性は低い」と述べています。

• ISO/IEC JTC 1/SC 6

• Hardcastle-Kille, S. (1993). 「RFC1485: 識別名の文字列表現」. doi : 10.17487/RFC1485 . 2021-02-10に取得。多くの OSI アプリケーションは、OSI ディレクトリで定義されている識別名 (DN) を使用します。これは一般に X.500 [CCI88] として知られています。この仕様は、X.500 と識別名の概念に精通していることを前提としています。 {{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です
• Chadwick, DW (1994)。「X.500 を理解する - ディレクトリ」 。2017年 12 月 6 日閲覧。
• X500Standard.com – X.500 標準のガイドであり、標準に関する既存および新規の作業のリポジトリでもある X.500 コミ​​ュニティ サイト。Wayback Machineで閲覧可能 (2019 年 1 月 4 日アーカイブ)