前のページ 目次 次のページ

最終更新日:2002年12月27日


6.4  リポジトリの利用

6.4.1  概要

証明書や 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).

6.4.2  ディレクトリ

ディレクトリとは、人やサーバなどの実世界の物(オブジェクト)を一元管理するために考案された、一種のデータベースです。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 オブジェクトクラス

6.4.3  LDAP の詳細

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.