最終更新日：2002年12月27日
証明書や CRL を配布する手段として、リポジトリに証明書や CRL をまとめて格納する方法があります。リポジトリを用意すれば、利用者は必要なときにリポジトリにアクセスすることによって証明書や CRL を取得できます。リポジトリには、証明書や CRL だけでなく、電話番号や住所などの様々な情報を格納することができます。リポジトリを用いると情報の一元管理が可能になるため、利用者は容易に最新の証明書や CRL を得ることができます。
図 6-4 リポジトリの使用
リポジトリには、以下の 2つの機能があります。：
(1) 登録機能
リポジトリに証明書や CRL を登録することができます。
(2) 検索機能
利用者がオンデマンドで、証明書や CRL を検索することができます。
PKI におけるリポジトリの実装については、いくつかの方法が提案されています（表 6-1）。このうち、LDAP と X.500 ディレクトリは、様々な情報を一元的に管理するディレクトリと呼ばれる技術を使用しています。
表 6-1 リポジトリの種類
|
種類 |
関連標準 |
|
LDAP |
[RFC2559] Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 [RFC2587] Internet X.509 Public Key Infrastructure LDAPv2 Schema. ※LDAPv3 のスキーマは策定中 |
|
X.500 ディレクトリ |
ITU-T X.500シリーズ |
|
FTP, HTTP |
[RFC2585] Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP. |
|
DNS |
[RFC2538] Storing Certificates in the Domain Name System (DNS). |
ディレクトリとは、人やサーバなどの実世界の物（オブジェクト）を一元管理するために考案された、一種のデータベースです。RDB（リレーショナルデータベース）と違い、情報はツリー構造に管理されます。また、検索処理が早いことが特徴であり、検索に特化しているため逆に更新処理は遅く、頻繁に情報が更新される用途には不向きです。ディレクトリは PKI に限らず、様々な用途に利用できます（表 6-2）。
表 6-2 ディレクトリの用途
|
用途 |
説明 |
|
PKI |
証明書や CRL の配布手段として利用する。 |
|
ネットワーク管理 |
ルータやサーバの設定情報を管理する。 |
|
ユーザ管理 |
ユーザ ID やパスワードを一元的に管理する。 |
ディレクトリには、X.500 ディレクトリおよび LDAP (Lightweight Directory Access Protocol) が存在します。
X.500 ディレクトリは、ITU/T と ISO/IEC によって策定された、OSI 参照モデルで動作する高機能なディレクトリです。X.500 ディレクトリへアクセスするための通信プロトコルとして、DAP (Directory Access Protocol)が用いられます。
LDAP は、X.500 ディレクトリをインターネット（主にTCP/IP）で利用するために IETF において策定された通信プロトコルです。X.500 DAP の機能を簡略化することにより、軽量に動作することが可能になっています。LDAP は通信プロトコルを規定したものであり、ディレクトリサーバの内部には X.500 ディレクトリや独自のディレクトリを用いることができます。LDAP の最新バージョン (LDAPv3) は、RFC2251 - 2255 として仕様化されています。
ディレクトリを構成する要素を以下に示します（表 6-3）。
表 6-3 ディレクトリの構成要素
|
要素 |
説明 |
|
DIT |
ディレクトリを構成するツリーを指します。 |
|
エントリ |
DIT上の各ノードを指します。エントリはオブジェクト（実世界での人、物、組織など）に相当します。 |
|
ルート |
ツリーの頂点に存在するエントリを指します。ルートエントリには、ディレクトリサーバ特有の情報が格納されます。 |
|
属性 |
エントリに格納される情報を指します。属性は、種類を表す属性型とデータを表す属性値から構成されます。1つの属性型が複数の属性値を持つこともあります。1つのエントリには、1つ以上の属性が含まれます。 |
|
オブジェクトクラス (objectClass) |
エントリの種別を指します。オブジェクトクラスによって、エントリが持つ属性が決まります。例えば、あるエントリのオブジェクトクラスが人に所属する場合は、そのエントリは名前や役職などの属性を持ち、組織に所属する場合は、組織名や住所などの属性を持ちます。 |
|
スキーマ |
ディレクトリが持つオブジェクトクラスや属性を定めたものを指します。 |
DIT 上の各エントリを区別するために、各エントリには「相対識別名 (RDN: Relative Distinguished Name)」および「識別名 (DN: Distinguished Name)」と呼ばれる名前を付与します（表 6-4）。
表 6-4 エントリの識別名
|
要素 |
説明 |
|
相対識別名(RDN) |
エントリの名前を表します。RDN は、そのエントリを構成する属性のうち、特定の一つの属性を使用します。 |
|
識別名(DN) |
DIT 上におけるエントリの位置を表します。DN は、注目するエントリからルートエントリまでの RDN を順番に並べたものになります。 |
以下に、LDAP によるディレクトリの構成例 [68] を示します（図 6-5）。この例では、「Suzuki Taro」と呼ばれる人 [69] は、「B Government」と呼ばれる組織 [70] の「A部」の「C課」に所属し、役職がマネージャであること [71] が分かります。また、userCertificate 属性として証明書が格納されています。
図 6-5 ディレクトリ構成例
エントリの種別を表すオブジェクトクラスは、オブジェクト指向でいう継承(is-a)関係を持ちます（図 6-6）。全てのオブジェクトクラスは top というオブジェクトクラスから派生しています。topオブジェクトクラスは、objectClass 属性型を持ちます。
下位のオブジェクトクラスは、親のオブジェクトクラスが持つ属性型を持つことができます。下位のオブジェクトクラスの objectClass 属性値には、自身および全ての親クラスの名前を指定します。先ほどの例（図 6-5）では省略していますが、inetOrgPerson オブジェクトの場合は objectClass 属性値として、inetOrgPerson およびその親クラスである、organizationPerson, person, top を指定します。
図 6-6 オブジェクトクラス
LDAP において使用される主なオブジェクトクラスと、そのオブジェクトクラスが持つ代表的な属性型を示します（表 6-5）。PKI に関連するスキーマは、RFC2587 にて pkiCA (CA), pkiUser (証明書所有者), cRLDistributionPoint (CRL 配布点) が規定されています。LDAP を PKI で利用する場合は、X.509 証明書の主体者(subject)フィールドおよび発行者(issuer)フィールドが、証明書を格納するディレクトリサーバ上のエンドユーザエントリや CA エントリの DN とそれぞれ一致する必要があります。
よく利用される属性型には省略形が定義されています。commonName, organizationName の省略形は、それぞれ cn, o となります。
表 6-5 主なオブジェクトクラスと属性
|
オブジェクトクラス |
主な属性型 |
説明 |
|
top (共通) |
objectClass |
そのクラス自身および全ての親クラス。 |
|
country (国) |
c (countryName) |
国の名前 |
|
description |
国の説明 |
|
|
organization (組織) |
o (organizationName) |
組織の名前 |
|
l (localityName) |
都市、地域 |
|
|
organizationUnit (組織単位) |
ou (organizationUnitName) |
部署などの名前 |
|
l (localityName) |
都市、地域 |
|
|
inetOrgPerson (インターネットユーザ) |
cn (commonName) |
一般名。 氏名、社員番号などを表します。 |
|
sn (surname) |
姓 |
|
|
givenName |
名 |
|
|
initials |
イニシャル |
|
|
mail (rfc822Mailbox) |
メールアドレス |
|
|
title |
役職 |
|
|
employeeNumber |
従業員番号 |
|
|
telephoneNumber |
電話番号 |
|
|
facsimileTelephoneNumber |
FAX番号 |
|
|
st (StateOrProvince) |
都道府県 |
|
|
l (localityName) |
都市、地域 |
|
|
o (organizationName) |
組織 |
|
|
ou (organizationUnitName) |
部署 |
|
|
userCertificate |
X.509 証明書 |
|
|
userPKCS12 |
PKCS#12 |
|
|
userSMIMECertificate |
S/MIMEに用いる証明書 |
|
|
userPassword |
パスワード |
|
|
certificationAuthority (認証局) |
cn |
CA の名前 |
|
cACertificate |
CA の証明書 |
|
|
authorityRevocationList |
認証局失効リスト (ARL) |
|
|
certificateRevocationList |
証明書失効リスト (CRL) |
|
|
pkiUser |
userCertificate |
ユーザの証明書 |
|
PkiCA |
cACertificate |
CA の証明書 |
|
certificateRevocationList |
証明書失効リスト (CRL) |
|
|
authorityRevocationList |
認証局失効リスト (ARL) |
|
|
crossCertificatePair |
相互認証証明書 |
|
|
cRLDistributionPoint |
cn (commonName) |
X.500 識別名 |
|
certificateRevocationList |
証明書失効リスト (CRL) |
|
|
authorityRevocationList |
認証局失効リスト (ARL) |
|
|
deltaRevocationList |
デルタ CRL |
|
|
DeltaCRL |
deltaRevocationList |
デルタ CRL |
クライアントから LDAP サーバーへの問い合わせの手順を以下に示します。
(1) LDAP クライアントの認証を行います。
(2) LDAP サーバーに対して、情報の検索や更新を行います。
(3) LDAP サーバーとのセッションを終了します。
以下に、問い合わせに使用するメッセージの種別を示します（表 6-6）。
表 6-6 LDAP のメッセージ (LDAPMessage)
|
種別 |
操作 |
説明 |
|
認証 |
bindRequest, bindResponse |
クライアントの認証を行います。 |
|
unbindRequest |
LDAP セッションを終了します。 |
|
|
問い合わせ |
searchRequest, searchResEntry, searchResDone, searchResRef |
情報の検索を行います。 |
|
compareRequest, compareResponse |
情報の比較を行います。 |
|
|
更新 |
addRequest, addResponse |
エントリを追加します。 |
|
delRequest, delResponse |
エントリを削除します。 |
|
|
modifyRequest, modifyResponse |
エントリの情報を変更します。 |
|
|
modDNRequest, modDNResponse |
エントリの RDN や DIT 上の位置を変更します。 |
|
|
放棄 |
abandonRequest |
要求中の操作を放棄します。 |
|
拡張 |
extendedReq, extendedResp |
操作メッセージの拡張領域です。 |
LDAP においては、以下のようなクライアントの認証手段が規定されています。
(1) 匿名ユーザとしての認証
(2) 名前のみ、名前とパスワードによる認証
(3) SASL（チャレンジレスポンス、SSL などを用いる）による認証
認証後のアクセス制御については標準が無く、IETF において標準化作業が進められています。なお、LDAP の製品によっては、X.500 ディレクトリの基本アクセス制御をサポートするものもあります。
以下に、LDAP サーバーへの検索に使用するパラメータを示します（表 6-7）。LDAP における検索は、エントリが持つ属性に対して行われます。エントリの識別名（DN） は検索の対象になりません。
表 6-7 LDAP の検索パラメータ
|
種別 |
説明 |
|
ホスト名 |
LDAP サーバーのホスト名およびポート番号を指定します。 |
|
ベース DN |
DIT上での検索の起点となるエントリ名を DN で指定します。 |
|
属性 |
検索結果として表示する属性を指定します。 |
|
範囲 |
検索範囲を base (ベース DN の階層のみ), one( ベース DN および 1つ下の階層), sub(ベース DN 以下すべての階層)から指定します。 |
|
検索フィルタ |
検索したいエントリの属性を指定します。AND, OR などの論理条件も指定することができます。検索フィルタの記述方法は、RFC2254 において提案されています。 |
また、LDAP サーバーへの検索に URL を用いることもできます。この方法は、LDAP URL と呼ばれ、RFC2255 において提案されています。LDAP URL のフォーマットを以下に示します。
|
ldap://[ホスト名]/[ベースDN]?[属性]?[範囲]?[検索フィルタ]?[拡張領域]
|
PKI を大規模で運用する場合や、複数のCAを連携させる場合は、ディレクトリを複数に分散させる必要が生じることがあります。X.500 ディレクトリは、分散管理のためにディレクトリの複製（シャドウイング）と連携（チェイニング）機能を保有していますが、LDAP には該当する機能がありません。
LDAP によって分散管理を実現するためには、LDAP v3 において追加されたリフェラル機能を用います（図 6-7）。
図 6-7 リフェラル機能
リフェラル機能を使用すると、
(1) LDAP サーバーは、自身が保持していないエントリに関する問い合わせを受けた場合、
(2) そのエントリを保持している LDAP サーバーの情報（リフェラルポイントと呼びます）をクライアントに返し、
(3) この情報を元にクライアントはエントリの情報をもつ LDAP サーバーにアクセスします。
このようにして、複数の LDAP サーバーを連携させることができます。
LDAP サーバー間で情報の複製を行うプロトコルは、IETF が策定作業を行っています。現段階では LDIF (LDAP Data Interchange Format) [72] と呼ばれるファイルフォーマットを用いて、LDAP サーバー間の複製を行います。
LDAP サーバーとクライアントとの通信を保護したい場合は、TLS/SSL を適用した LDAPS プロトコルが利用できます。LDAPS を使用すると、通信経路の暗号化と証明書によるクライアント認証が実現できます。
前のページ 目次 次のページ Copyright © 2002 Information-technology Promotion Agency, Japan. All rights reserved.