JP2003309555A - 公開鍵基盤の登録局、その構築方法とそのプログラム、該プログラムを記録した記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 一台の汎用コンピュータ上に複数の登録局を
構築可能とし、導入コスト、運用コストを減らすこと、
ならびに証明書利用者が証明書を発行・失効する際に、
証明書利用者が簡易な決まった方法で証明書の発行・失
効の申請ができるシステムを提供すること。 【解決手段】 ユーザからの要求に応じて公開鍵基盤証
明書を発行する複数の発行局とともに認証局を構成する
登録局であって、前記複数の発行局についての情報と証
明書の発行および失効に必要な情報をそれぞれ保持する
複数のＲＡセルと、ユーザ毎に異なるユーザ情報を格納
するデータベースと、前記ＲＡセルに保持されている発
行局固有の情報と前記データベースに格納されているユ
ーザ固有の情報を参照して前記複数の発行局との通信を
行なうＲＡコア部とが設けられた１つのコンピュータに
より構成される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は公開鍵基盤（ＰＫ
Ｉ：Public Key Infrastructure）における証明書管理
システム、証明書管理方法および証明書管理用プログラ
ムを記録した記録媒体に関する。

【０００２】

【従来の技術】公開鍵基盤（ＰＫＩ）の運営の主体とな
る、認証局（ＣＡ）は、クライアントの所持する公開鍵
の正当性を第三者に保証する機関である。それぞれの認
証局は独自に運用ポリシーを持つものであるが、いずれ
においてもクライアントからの認証要求に対し、安易に
認証をするべきではなく、必ずクライアント本人の確認
を行うべきであるとされている。このため、認証局に対
するクライアントからの申請を検証し、本人を確認した
上で、認証局に申請書を送付する信頼ある機関として、
登録局（ＲＡ）が設けられるようになった。

【０００３】通常、認証局を運営するためにはサーバを
２台用意し、発行局サーバ（ＩＡサーバ）と登録局サー
バ（ＲＡサーバ）を別途構築する必要があった。このた
め、最小構成でも、１台のサーバ上にＩＡサーバとＲＡ
サーバを同居させ、一つの認証局を構築するのが限界で
あった。

【０００４】また、発行される証明書の内容・目的、証
明書のライフサイクルの規定、申請の方法などは、認証
局によって異なり、クライアントは認証局毎に異なる方
法によって対応する登録局へ申請を行う必要があった。

【０００５】

【発明が解決しようとする課題】第１の問題点は、通
常、認証局ＣＡを運営するためには、汎用コンピュータ
を１台用意し、その中にＣＡ用のソフトウェアをインス
トールして、その他ネットワーク等の設定を行い、認証
局を構築する。この場合、運営できるＣＡは一つであ
る。また、登録局ＲＡと発行局ＩＡに分ける構成とする
には、２台の汎用コンピュータを用意し、別々にインス
トールすること、および、ネットワーク等周辺の設定す
ることが必要であり、面倒である。

【０００６】さらに、構築するＲＡやＩＡの数が増加す
ると導入の際のコスト（汎用コンピュータ代、インスト
ール費、設定の煩雑さなど）のみでなく、運用の際に
も、サーバごとにバックアップしたり、ログの解析をし
たりする必要があり、運用にかかるコストも膨大なもの
になる。

【０００７】第２の問題点は、ＣＡによって申請に使用
するアプリケーションが異なる場合や、申請内容（使用
する鍵長、鍵アルゴリズム等）が異なる場合があるた
め、証明書利用者が証明書を取得・失効する際に準備し
なければならない知識・情報が多く、さらに、ＣＡ毎に
異なる方法で申請する必要があり、証明書利用者は煩雑
な処理を要求されるということである。

【０００８】本発明は上述したような従来の技術が有す
る問題点に鑑みてなされたものであって、一台の汎用コ
ンピュータ上に複数の登録局を構築可能とし、導入コス
ト、運用コストを減らすこと、ならびに証明書利用者が
証明書を発行・失効する際に、証明書利用者が簡易な決
まった方法で証明書の発行・失効の申請ができるシステ
ムを提供することを目的とする。

【０００９】

【課題を解決するための手段】本発明の公開鍵基盤の登
録局は、ユーザからの要求に応じて公開鍵基盤証明書を
発行する複数の発行局とともに認証局を構成する登録局
であって、前記複数の発行局についての情報と証明書の
発行および失効に必要な情報をそれぞれ保持する複数の
ＲＡセルと、ユーザ毎に異なるユーザ情報を格納するデ
ータベースと、前記ＲＡセルに保持されている発行局固
有の情報と前記データベースに格納されているユーザ固
有の情報を参照して前記複数の発行局との通信を行なう
ＲＡコア部とが設けられた１つのコンピュータにより構
成されることを特徴とする。

【００１０】本発明による認証局は、上記の登録局を用
いて構成されていることを特徴とする。

【００１１】本発明による公開鍵基盤システムは、上記
の登録局を用いて構成されていることを特徴とする。

【００１２】本発明の公開鍵基盤の登録局の構築方法
は、ユーザからの要求に応じて公開鍵基盤証明書を発行
する複数の発行局とともに認証局を構成する登録局の構
築方法であって、前記複数の発行局についての情報と証
明書の発行および失効に必要な情報をそれぞれ保持する
複数のＲＡセルと、ユーザ毎に異なるユーザ情報を格納
するデータベースと、前記ＲＡセルに保持されている発
行局固有の情報と前記データベースに格納されているユ
ーザ固有の情報を参照して前記複数の発行局との通信を
行なうＲＡコア部とを１つのコンピュータに設けること
を特徴とする。

【００１３】本発明の公開鍵基盤の登録局を構築するプ
ログラムは、ユーザからの要求に応じて公開鍵基盤証明
書を発行する複数の発行局とともに認証局を構成する登
録局を構築するプログラムであって、１つのコンピュー
タに、前記複数の発行局についての情報と証明書の発行
および失効に必要な情報をそれぞれ保持する複数のＲＡ
セルと、ユーザ毎に異なるユーザ情報を格納するデータ
ベースと、前記ＲＡセルに保持されている発行局固有の
情報と前記データベースに格納されているユーザ固有の
情報を参照して前記複数の発行局との通信を行なうＲＡ
コア部とを作製する処理が記述されていることを特徴と
する。

【００１４】本発明の記録媒体は、ユーザからの要求に
応じて公開鍵基盤証明書を発行する複数の発行局ととも
に認証局を構成する登録局を構築するプログラムを格納
した記録媒体であって、１つのコンピュータに、前記複
数の発行局についての情報と証明書の発行および失効に
必要な情報をそれぞれ保持する複数のＲＡセルと、ユー
ザ毎に異なるユーザ情報を格納するデータベースと、前
記ＲＡセルに保持されている発行局固有の情報と前記デ
ータベースに格納されているユーザ固有の情報を参照し
て前記複数の発行局との通信を行なうＲＡコア部とを作
製する処理が記述されているプログラムが記録されてい
る。

【００１５】上記のように構成される本発明において
は、複数の発行局に対応して設けられたＲＡセルと、ユ
ーザに対応した情報を格納するデータベースと、ＲＡセ
ルに保持されている情報とデータベースに格納されてい
る情報を参照して複数の発行局との通信を行なうＲＡコ
ア部を１つのコンピュータに構築することにより、複数
の発行局に対応する複数の登録局が構築されることとな
り、システムを構築するコンピュータの数を少なくする
ことができる。

【００１６】また、１つのコンピュータに登録局が複数
構築されることから、使用される申請に使用するアプリ
ケーションを同じとすることができる。また、ユーザ固
有の情報はＲＡセルに保持されるため、証明書利用者が
証明書を取得・失効する際に準備しなければならない知
識・情報は少なくなる。

【００１７】

【発明の実施の形態】次に、本発明の実施の形態につい
て図面を参照して詳細に説明する。

【００１８】図１は本発明の第１の実施形態の構成を示
すブロック図である。本実施形態は、複数のクライアン
ト端未１００と、ＲＡサーバ２００およびデータベース
２０３を備える登録局３００と、ＩＡサーバ４００を備
える発行局５００と、各クライアント端末１００、ＲＡ
サーバ２００およびＩＡサーバ４００を結ぶネットワー
ク１０から構成されている。ＲＡサーバ２００はＲＡコ
ア部２０１および複数のＲＡセル２０２を備えている。

【００１９】クライアント端未１００は、そのユーザが
認証局５００へ認証を要求し、証明書の発行や失効を申
請する際に用いる端未であり、汎用のコンピュータで構
成されている。クライアント端未１００には、Ｗｅｂブ
ラウザが組み込まれており、ＲＡサーバ２００ヘインタ
ーネットなどのネットワーク１０を通じて申請をするこ
とが可能である。また、ＲＡサーバ２００から処理結果
を受信し、表示することが可能である。さらに、証明書
を発行する際には、証明書をＩＣカード等の外部媒体へ
出力することも可能である。

【００２０】上述したようにＲＡサーバ２００はＲＡコ
ア部２０１と複数のＲＡセル２０２およびデータベース
（ＤＢ）２０３とから構成され、登録局３００はＩＡサ
ーバ４００から構成される。ＲＡサーバ２００は、通信
装置を備えた汎用コンピュータで構成され、インターネ
ット等のネットワーク１０を通じて、クライアント端末
１００、および複数のＩＡサーバ４００と接続されてい
る。

【００２１】ＲＡセル２０２は、ＲＡの最小単位で、Ｒ
Ａが接続するＩＡの個々に異なる情報を保持するもので
あり、証明書を発行する際に使用する証明書発行ポリシ
ー、証明書を失効する際に使用する証明書失効ポリシー
等、ＲＡとしての機能を果たすために必要となるＩＡ固
有の情報を保持する。

【００２２】ＤＢ２０３は、個別に異なるユーザ情報を
格納するもので、ユーザ情報には例えば名前や住所など
が挙げられる。

【００２３】ＲＡコア部２０１は、ＲＡとしての機能を
果たすために必要となる機能を備えるものであり、ＲＡ
セル２０２に保持されているＩＡ固有の情報とＤＢ２０
３に格納されているユーザ固有の情報を参照してＩＡと
の通信を行なう。

【００２４】ＩＡサーバ４００は、実際に証明書を作成
したり、失効したりするサーバで、通信装置を備えた汎
用コンピュータで構成され、インターネット等のネット
ワーク１０を通じて、複数のＲＡサーバ２００と接続さ
れている。

【００２５】次に、本実施形態の実際の動作について順
を追って説明する。

【００２６】事前設定 事前に行なわれる設定動作は以下の通りである。 ・ＲＡサーバのプログラムをインストールする。 ・ＲＡセル２０２を必要な数だけ構築する。 ・証明書発行申請のために必要な情報を設定する（ＩＡ
情報、鍵長、アルゴリズム、発行ポリシーなど）。 ・証明書失効申請のために必要な情報を設定する（ＩＡ
情報、失効ポリシーなど）。 ・ＲＡを管理する管理者（ＲＡ管理者）を登録し、操作
可能な（管理する）ＲＡセルを設定する。 ・ＲＡ管理者は、複数のＲＡセル２０２を作成すること
が可能である。 ・実際にクライアント端未１００を操作するオペレータ
を登録する。オペレータには、操作可能な処理を設定す
る。例えば、あるオペレータＡは、証明書発行のみが可
能な設定とし、オペレータＢは、証明書発行と証明書失
効の両方が可能な設定とすることが出来る。さらに、オ
ペレータの操作可能なＲＡセルを複数設定することが可
能である。このことは後に図面を用いて詳述する。 ・オペレータは、自身の認証情報をＲＡサーバに設定す
る。認証情報は、ＤＢ２０３に保管される。 ・ＲＡは、複数のＲＡセルから構成される。 ・ＲＡは、クライアントからの要求を「申請」として受
け付け、その申請の処理の進捗状況を管理する。

【００２７】証明書の発行 次に、本実施形態の証明書発行の動作について、そのフ
ローチャートである図２および図３を参照して詳細に説
明する。

【００２８】まず、クライアント端未１００に対して端
未オペレータによりオペレータの認証を行なう旨および
そのための情報の入力がなされ（ステップ１−０）、ク
ライアント端未１００からＲＡサーバ２００へ認証の要
求が行なわれる（ステップ１−１）。

【００２９】認証要求を受け取ったＲＡサーバ２００
は、ＤＢ２０３に保管されたオペレータ認証情報からオ
ペレータを認証する（ステップ１−２）。

【００３０】オペレータの認証が完了すると、クライア
ント端未１００にそのオペレータが操作可能な操作メニ
ューが表示される（ステップ１−３）。

【００３１】オペレータは、操作メニューから証明書取
得を選択し（ステップ１−４）、証明書取得を要求した
ユーザの名前等の必定情報を入力する（ステップ１−
５）。オペレータが証明書の利用者であるユーザを登録
する際には、一つのＲＡセル２０２を選択し、そのユー
ザが所属するＲＡセル２０２を特定する。

【００３２】すべての入力がなされたことがクライアン
ト端末１００で確認されると、ＲＡサーバ２００へ証明
書発行の申請内容が送信される（ステップ１−６）。

【００３３】クライアント端末１００からの申請内容を
受け付けたＲＡサーバ２００では、申請内容をＤＢ２０
３へ保管し（ステップ１−７）、さらにＤＢ２０３か
ら、ステップ１−５で指定されたＲＡセル２０２の発行
申請ポリシーを読み出す（ステップ１−８）。この後、
ＲＡサーバ２００はクライアント端未１００から送られ
てきたユーザの発行申請内容が、ステップ１−８で読み
出した発行申請ポリシーに適合するかのチェックを行な
う（ステップ１−９）。

【００３４】ステップ１−９におけるチェックでは、チ
ェックとともに必要に応じてユーザの発行申請内容を発
行申請ポリシーに適合させるための変更あるいは追加さ
せることが行なわれる。変更や追加の例としては以下が
挙げられる。

【００３５】ユーザの発行申請内容：「証明書の有効期
限は2001年3月3日〜2003年4月1日」 発行申請ポリシー：「証明書の有効期限は１年間」 上記の場合にはユーザの発行申請内容と発行申請ポリシ
ーとは一致しないため、本来は不適合である旨がユーザ
に通知されるが、あらかじめユーザの発行申請内容と発
行申請ポリシーとが重複する部分に関しては適合させる
ようにユーザの発行申請内容を変更するように設定して
おくと、ユーザの発行申請内容を「証明書の有効期限は
2001年3月3日〜2003年3月2日」と変更して適合とする。

【００３６】ステップ１−９におけるチェックの結果、
ユーザの発行申請内容と発行申請ポリシーとが適合しな
かった場合、ＲＡサーバ２００は、クライアント端未１
００へ不適切な申請である旨を送信する（ステップ１−
１０）。

【００３７】ユーザの発行申請内容と発行申請ポリシー
とが適合する場合、ＲＡサーバ２００は、証明書発行状
況を発行処理中へ変更する（ステップ１−１１）。

【００３８】続いて、ＲＡサーバ２００は、ＤＢ２０３
から、証明書発行申請書を作成するために必要な、ステ
ップ１−５で指定されたＲＡセル２０２の発行申請ポリ
シーを読み取って（ステップ１−１２）、証明書発行申
請書を作成し（ステップ１−１３）、ＤＢ２０３からス
テップ１−５で指定されたＲＡセル２０２のＩＡ情報を
取得し、作成した証明書発行申請書をＩＡサーバ４００
へ送信する（ステップ１−１４）。

【００３９】ＩＡサーバ４００は、ＲＡサーバ２００か
ら受け取った証明書発行申請書を処理し、証明書を作成
し（ステップ１−１５）、ＲＡサーバ２００へ報告書を
送付する（ステップ１−１６）。

【００４０】ＲＡサーバ２００は、ＩＡサーバ４００か
らの報告書を解析し（ステップ１−１７）、正常に処理
されたかを確認する。

【００４１】ＲＡサーバ２００は、正常に処理されたこ
とが確認された場合、ＲＡサーバ２００は発行された証
明書を取得し、ＤＢ２０３へ保管して（ステップ１−１
８）、証明書発行状況を発行済みへ変更する（ステップ
１−１９）。

【００４２】また、正常に処理されたことが確認されな
い場合には、ＲＡサーバ２００は、クライアント端末１
００に対して異常終了あるいは処理が受け付けられなか
った旨を返信する。

【００４３】クライアント端未１００を利用するオペレ
ータは、クライアント端未１００に対して証明書発行処
理状況を参照する旨の入力を行い、これに応じてクライ
アント端未１００からＲＡサーバ２００には証明書の発
行状況を参照する旨の問い合わせがなされ（ステップ１
−２０）、ＲＡサーバからクライアント端未１００には
証明書の発行状況が送付される（ステップ１−２１）。

【００４４】クライアント端未１００は、証明書発行処
理状況の確認を行う。このとき、証明書発行処理状況が
「発行済み」、あるいは「エラー」であることが確認さ
れるまで証明書の発行状況を参照する旨の問い合わせ
を、しばらく間をおきながら、証明書発行処理状況を参
照する（ステップ１−２２）。

【００４５】証明書発行処理状況が「発行済み」になっ
た時点で、クライアント端未１００は、ＲＡサーバ２０
０に対して証明書を取得する要求を行い（ステップ１−
２３）、ＲＡサーバ２００から該当する証明書のダウン
ロードが行なわれる（ステップ１−２４）。この後、ク
ライアント端未１００を利用するオペレータは、ＩＣカ
ード等の外部媒体へ証明書を格納し、証明書の利用者で
あるユーザに利用可能な状態とする。

【００４６】証明書の失効 次に、本実施形態における証明書失効の動作について、
そのフローチャートである図４および図５を参照して詳
細に説明する。

【００４７】まず、クライアント端未１００に対して端
未オペレータによりオペレータの認証を行なう旨および
そのための情報の入力がなされ（ステップ１−０）、ク
ライアント端未１００からＲＡサーバ２００へ認証の要
求が行なわれる（ステップ２−１）。

【００４８】認証要求を受け取ったＲＡサーバ２００
は、ＤＢ２０３に保管されたオペレータ認証情報からオ
ペレータを認証する（ステップ２−２）。

【００４９】オペレータの認証が完了すると、クライア
ント端未１００にそのオペレータが操作可能な操作メニ
ューが表示される（ステップ２−３）。

【００５０】オペレータは、操作メニューから証明書失
効を選択し（ステップ２−４）、証明書失効を要求した
ユーザの名前等の必定情報を入力する（ステップ２−
５）。オペレータが証明書の利用者であるユーザを登録
する際には、一つのＲＡセル２０２を選択し、そのユー
ザが所属するＲＡセル２０２を特定する。

【００５１】すべての入力がなされたことがクライアン
ト端末１００で確認されると、ＲＡサーバ２００へ証明
書失効の申請内容が送信される（ステップ２−６）。

【００５２】クライアント端末１００からの申請内容を
受け付けたＲＡサーバ２００では、申請内容をＤＢ２０
３へ保管し（ステップ２−７）、さらにＤＢ２０３か
ら、ステップ１−５で指定されたＲＡセル２０２の失効
申請ポリシーを読み出す（ステップ２−８）。この後、
ＲＡサーバ２００はクライアント端未１００から送られ
てきたユーザの失効申請内容が、ステップ２−８で読み
出した失効申請ポリシーに適合するかのチェックを行な
う（ステップ２−９）。

【００５３】ステップ２−９におけるチェックでは、チ
ェックとともに必要に応じてユーザの発行申請内容を発
行申請ポリシーに適合させるための変更あるいは追加さ
せることが行なわれる。変更や追加の例としては以下が
挙げられる。

【００５４】ユーザの発行申請内容：「証明書の有効期
限は2001年3月3日〜2003年4月1日」 発行申請ポリシー：「証明書の有効期限は１年間」 上記の場合にはユーザの発行申請内容と発行申請ポリシ
ーとは一致しないため、本来は不適合である旨がユーザ
に通知されるが、あらかじめユーザの発行申請内容と発
行申請ポリシーとが重複する部分に関しては適合させる
ようにユーザの発行申請内容を変更するように設定して
おくと、ユーザの発行申請内容を「証明書の有効期限は
2001年3月3日〜2003年3月2日」と変更して適合とする。

【００５５】ステップ２−９におけるチェックの結果、
ユーザの失効申請内容と失効申請ポリシーとが適合しな
かった場合、ＲＡサーバ２００は、クライアント端未１
００へ不適切な申請である旨を送信する（ステップ２−
１０）。

【００５６】ユーザの失効申請内容と失効申請ポリシー
とが適合する場合、ＲＡサーバ２００は、証明書失効状
況を失効処理中へ変更する（ステップ２−１１）。

【００５７】続いて、ＲＡサーバ２００は、ＤＢ２０３
から、証明書失効申請書を作成するために必要な、ステ
ップ２−５で指定されたＲＡセル２０２の失効申請ポリ
シーを読み取って（ステップ２−１２）、証明書失効申
請書を作成し（ステップ２−１３）、ＤＢ２０３からス
テップ２−５で指定されたＲＡセル２０２のＩＡ情報を
取得し、作成した証明書失効申請書をＩＡサーバ４００
へ送信する（ステップ２−１４）。

【００５８】ＩＡサーバ４００は、ＲＡサーバ２００か
ら受け取った証明書失効申請書を処理し、証明書を作成
し（ステップ２−１５）、ＲＡサーバ２００へ報告書を
送付する（ステップ２−１６）。

【００５９】ＲＡサーバ２００は、ＩＡサーバ４００か
らの報告書を解析し（ステップ２−１７）、正常に処理
されたかを確認する。

【００６０】ＲＡサーバ２００は、正常に処理されたこ
とが確認された場合、ＲＡサーバ２００は発行された証
明書を取得し、ＤＢ２０３へ保管して（ステップ２−１
８）、証明書失効状況を失効済みへ変更する（ステップ
２−１９）。

【００６１】また、正常に処理されたことが確認されな
い場合には、ＲＡサーバ２００は、クライアント端末１
００に対して異常終了あるいは処理が受け付けられなか
った旨を返信する。

【００６２】クライアント端未１００を利用するオペレ
ータは、クライアント端未１００に対して証明書失効処
理状況を参照する旨の入力を行い、これに応じてクライ
アント端未１００からＲＡサーバ２００には証明書の失
効状況を参照する旨の問い合わせがなされ（ステップ２
−２０）、ＲＡサーバからクライアント端未１００には
証明書の失効状況が送付される（ステップ２−２１）。

【００６３】クライアント端未１００は、証明書失効処
理状況の確認を行う。このとき、証明書失効処理状況が
「失効済み」、あるいは「エラー」であることが確認さ
れるまで証明書の失効状況を参照する旨の問い合わせ
を、しばらく間をおきながら、証明書失効処理状況を参
照する（ステップ２−２２）。

【００６４】証明書失効処理状況が「失効済み」になっ
た時点で、オペレータがクライアント端未１００に表示
されている操作メニューから失効となった証明書情報の
リストであるＣＲＬ（Certificate Revocation List）
の検証を選択すると、クライアント端未１００からＲＡ
サーバ２００を介してＩＡサーバ４００にＣＲＬ検証依
頼がかけられる（ステップ２−２３，２−２４）。これ
を受けてＩＡサーバ４００からＲＡサーバ２００を介し
てクライアント端未１００にＣＲＬ検証結果が通知され
（ステップ２−２５，２−２６）。ＣＲＬ検証結果を受
け取ったクライアント端未１００ではＣＲＬ検証結果の
表示を行い（ステップ２−２７）、ＣＲＬ検証結果をユ
ーザヘ通知する。

【００６５】次に、本実施形態の効果について説明す
る。

【００６６】本実施形態では、申請ポリシーや証明書の
発行・失効に必要な情報やＩＡサーバにアクセスするた
めの情報がＲＡセル２０２という単位で保持されてお
り、ＲＡとＩＡの組み合わせを複雑に設定可能で、実際
の運用に合わせた柔軟な運用が可能である。

【００６７】図１０は本実施形態による効果を示す図で
あり、図１０（ａ）は従来行なわれていた構成が示さ
れ、図１０（ｂ）には本実施形態による構成が示されて
いる。

【００６８】図１０（ａ）に示される従来の構成では、
３個の登録局を構築する場合、各認証局毎にＲＡサーバ
２００およびＩＡサーバ４００を設ける必要があり、ま
た、クライアント端末１００には各認証局毎にブラウザ
を用意するとともにそれぞれ異なる情報を管理する必要
があった。

【００６９】図１０（ｂ）に示される本実施形態の場合
には、一台のＲＡサーバ２００内に複数のＲＡセル２０
２を用意することにより、擬似的に複数台のＲＡサーバ
を構築したことと同じ効果を得ることができるものとな
っている。また、ＲＡセル２０２を複数用意し、ＲＡセ
ルごとに接続先のＩＡを変え、申請方法を設定しておく
ことにより、一つのＲＡセルが複数のＩＡへ申請をする
ような構成も可能である。

【００７０】さらに、クライアント端未１００にＲＡセ
ル２０２が持っているような多くの情報を保持しておく
必要は無く、クライアント端未１００には、１つのブラ
ウザのみを用意すればよく、オペレータの操作や設定も
簡単になる。

【００７１】審査機能の追加 次に、機能が追加された実施形態について説明する。本
実施形態において、 ・ＲＡ管理者は、オペレータを役割別に申請者、審査者
に分けることが出来る。ここで、 ・申請者とは、クライアント端未１００からユーザ情報
を入力し、発行・失効の申請のみを行う者である。 ・審査者とは、申請者によって申請された申請情報を参
照し、申請内容が正しいかどうか確認をし、申請を認め
るかどうかを審査する者である。

【００７２】事前設定 本実施形態で行なわれる事前設定は先に述べた実施形態
とほぼ同様である。異なる点は、オペレータの登録に関
することで、 ・実際にクライアント端未１００を操作するオペレータ
を登録するが、このとき、オペレータを申請者と審査者
に分けて登録する。 ・申請者の登録の際、例えば、ある申請者Ａは、証明書
発行申請のみを可能とし、申請者Ｂは、証明書発行申請
と証明書失効申請の両方を可能とすることが出来る。さ
らに、申請者の操作可能なＲＡセルを複数設定すること
が可能である。 ・審査者については、例えば、ある申請者Ａは、証明書
発行申請のみを可能にし、審査者Ｂは証明書発行審査と
証明書失効審査の両方を可能とすることが出来る。さら
に、審査者の操作可能なＲＡセルを複数設定することが
可能である。 ・申請者、審査者は、共に各々、自身の認証情報をＲＡ
サーバに設定する。認証情報はＤＢ２０３に保管され
る。 ・ＲＡ毎に審査基準をあらかじめ決定し、審査者はその
審査基準を把握あるいは審査基準の書かれたマニュアル
を見て操作を行う。

【００７３】図９は上記のような構成とされる実施形態
の概念図である。

【００７４】ＲＡに設けられるＲＡセル１〜ＲＡセル３
のうち、ＲＡセルに１はユーザ１およびユーザ２に対応
するＩＡサーバへの申請方法が設定され、ＲＡセルに２
はユーザ３およびユーザ４に対応するＩＡサーバへの申
請方法が設定され、ＲＡセルに３はユーザ５に対応する
ＩＡサーバへの申請方法が設定されている。オペレータ
ＡはＲＡセル１およびＲＡセル２に対する申請者および
審査者として設定され、オペレータＢはＲＡセル３に対
する申請者および審査者として設定されている。

【００７５】証明書の発行（審査機能追加） 次に、審査機能が追加された本実施形態の証明書発行の
動作について、そのフローチャートである図６ないし図
８を参照して詳細に説明する。

【００７６】まず、クライアント端未１００に対して申
請者により申請者の認証を行なう旨およびそのための情
報の入力がなされ（ステップ３−０）、クライアント端
未１００からＲＡサーバ２００へ認証の要求が行なわれ
る（ステップ３−１）。

【００７７】認証要求を受け取ったＲＡサーバ２００
は、ＤＢ２０３に保管されている申請者認証情報から申
請者を認証する（ステップ３−２）。

【００７８】申請者の認証が完了すると、クライアント
端未１００にその申請者が操作可能な操作メニューが表
示される（ステップ３−３）。

【００７９】申請者は、操作メニューから証明書取得を
選択し（ステップ３−４）、証明書取得を要求したユー
ザの名前等の必定情報を入力する（ステップ３−５）。
申請者が証明書の利用者であるユーザを登録する際に
は、一つのＲＡセル２０２を選択し、そのユーザが所属
するＲＡセル２０２を特定する。

【００８０】すべての入力がなされたことがクライアン
ト端末１００で確認されると、ＲＡサーバ２００へ証明
書発行の申請内容が送信される（ステップ３−６）。

【００８１】クライアント端末１００からの申請内容を
受け付けたＲＡサーバ２００では、申請内容をＤＢ２０
３へ保管し（ステップ３−７）、さらにＤＢ２０３か
ら、ステップ３−５で指定されたＲＡセル２０２の発行
申請ポリシーを読み出す（ステップ３−８）。

【００８２】ここで申請者の処理は、一旦終了となる。

【００８３】次に、クライアント端未１００から審査者
がＲＡサーバ２００へ認証を要求する（ステップ４−
１）。

【００８４】認証要求を受け取ったＲＡサーバ２００
は、ＤＢ２０３に登録された審査者認証情報から審査者
を認証する（ステップ４−２）。

【００８５】申請者の認証が完了すると、クライアント
端未１００にその審査者が操作可能な操作メニューが表
示される（ステップ４−３）。

【００８６】審査者は、操作メニューから申請情報参照
を選択する（ステップ４−４）。

【００８７】審査者が、クライアント端末１００に表示
された申請情報を見て、証明書発行申請の内容が審査基
準を満たしているかを判断し、その結果を審査合格また
は不合格としてＲＡ２００に通知する（ステップ４−
５、４−６）。

【００８８】ＲＡ２００は、ＤＢ２０３に申請情報ごと
の合格、不合格の記録を保管する（ステップ４−７）。

【００８９】以下の処理は審査合格となった申請に関し
てのみ進められる。

【００９０】審査合格となった申請について、ＲＡサー
バ２００は申請内容に従ってＤＢ２０３から該当するＲ
Ａセル２０２の発行申請ポリシーを読み出す（ステップ
３−９）。

【００９１】次に、クライアント端未１００から送られ
たユーザの申請内容が、発行申請ポリシーに適合するか
をチェックする（ステップ３−１０）。

【００９２】ステップ３−１０におけるチェックでは、
チェックとともに必要に応じてユーザの発行申請内容を
発行申請ポリシーに適合させるための変更あるいは追加
させることが行なわれる。変更や追加の例としては以下
が挙げられる。

【００９３】ユーザの発行申請内容：「証明書の有効期
限は2001年3月3日〜2003年4月1日」発行申請ポリシー：
「証明書の有効期限は１年間」上記の場合にはユーザの
発行申請内容と発行申請ポリシーとは一致しないため、
本来は不適合である旨がユーザに通知されるが、あらか
じめユーザの発行申請内容と発行申請ポリシーとが重複
する部分に関しては適合させるようにユーザの発行申請
内容を変更するように設定しておくと、ユーザの発行申
請内容を「証明書の有効期限は2001年3月3日〜2003年3
月2日」と変更して適合とする。

【００９４】ユーザの申請内容が発行申請ポリシーに適
合しなかった場合は、クライアント端未１００へ不適切
な申請である旨を送信する（ステップ３−１１）。ま
た、ユーザの申請内容が発行申請ポリシーに適合した場
合は、証明書発行状況を発行処理中へ変更する（ステッ
プ３−１２）。

【００９５】次に、ＤＢ２０３から証明書発行申請書を
作成するために必要な情報を読み取り（ステップ３−１
３）、証明書発行申請書を作成する（ステップ３−１
４）。

【００９６】続いて、ＤＢ２０３から該当するＲＡセル
２０２のＩＡ情報を取得し、作成した証明書発行申請書
をＩＡサーバヘ送信する（ステップ３−１５）。

【００９７】ＲＡサーバ２００からの証明書発行申請書
を受け取ったＩＡサーバ４００は、ＲＡサーバ２００か
ら受け取った証明書発行申請書を処理し、証明書を作成
する証明書発行処理を行い（ステップ３−１６）、ＲＡ
サーバ２００へその報告書を送付する（ステップ３−１
７）。

【００９８】ＲＡサーバ２００は、ＩＡサーバ４００か
ら送られてきた報告書を解析する（ステップ３−１
８）。

【００９９】ＲＡサーバ２００は、正常に処理されたこ
とが確認された場合、ＲＡサーバ２００は発行された証
明書を取得し、ＤＢ２０３へ保管して（ステップ３−１
９）、証明書発行状況を発行済みへ変更する（ステップ
３−２０）。

【０１００】また、正常に処理されたことが確認されな
い場合には、ＲＡサーバ２００は、クライアント端末１
００に対して異常終了あるいは処理が受け付けられなか
った旨を返信する。

【０１０１】クライアント端未１００を利用するオペレ
ータは、クライアント端未１００に対して証明書発行処
理状況を参照する旨の入力を行い、これに応じてクライ
アント端未１００からＲＡサーバ２００には証明書の発
行状況を参照する旨の問い合わせがなされ（ステップ３
−２１）、ＲＡサーバからクライアント端未１００には
証明書の発行状況が送付される（ステップ３−２２）。

【０１０２】クライアント端未１００は、証明書発行処
理状況の確認を行う。このとき、証明書発行処理状況が
「発行済み」、あるいは「エラー」であることが確認さ
れるまで証明書の発行状況を参照する旨の問い合わせ
を、しばらく間をおきながら、証明書発行処理状況を参
照する（ステップ３−２３）。

【０１０３】証明書発行処理状況が「発行済み」になっ
た時点で、クライアント端未１００は、ＲＡサーバ２０
０に対して証明書を取得する要求を行い（ステップ３−
２４）、ＲＡサーバ２００から該当する証明書のダウン
ロードが行なわれる（ステップ３−２５）。この後、ク
ライアント端未１００を利用するオペレータは、ＩＣカ
ード等の外部媒体へ証明書を格納し、証明書の利用者で
あるユーザに利用可能な状態とする。

【０１０４】上記のように、本発明は複数のＲＡセル
と、データベースと、ＲＡセルに保持されている発行局
固有の情報とデータベースに格納されているユーザ固有
の情報を参照して複数の発行局との通信を行なうＲＡコ
ア部とを１つのコンピュータ（サーバ）に設けるもので
ある。このような構成とすることはコンピュータ（サー
バ）へのプログラム入力により実行されるものであり、
本発明は上記の構成とするためのプログラムおよび該プ
ログラムが記録された記録媒体をも含む。

【０１０５】

【発明の効果】本発明は以上説明したように構成されて
いるので、以下に記載するような効果を奏する。

【０１０６】第１の効果は、ＲＡとＩＡの組み合わせを
複雑に設定可能で、実運用にあわせ柔軟な運用が可能で
ある。例えば、一台のＲＡサーバ内に複数のＲＡセルを
用意することにより、擬似的に複数台のＲＡサーバを構
築したことと同じ効果が得られることにある。

【０１０７】その理由はＲＡセルという単位で申請ポリ
シーや証明書の発行・失効に必要な情報やＩＡサーバに
アクセスするための情報を保持しているためである。

【０１０８】第２の効果は、オペレータの操作や設定が
簡単にできることにある。その理由は、クライアント端
末にＲＡセルが持っているような多くの情報を保持して
おく必要は無く、クライアンと端末には、Ｗｅｂブラウ
ザのみ用意すればよいためである。

【図面の簡単な説明】

【図１】本発明の第１の実施形態の構成を示すブロック
図である。

【図２】本発明の実施形態の証明書発行動作を示すフロ
ーチャートである。

【図３】本発明の実施形態の証明書発行動作を示すフロ
ーチャートである。

【図４】本発明の実施形態の証明書失効動作を示すフロ
ーチャートである。

【図５】本発明の実施形態の証明書失効動作を示すフロ
ーチャートである。

【図６】審査機能が追加された本発明の実施形態の証明
書発行動作を示すフローチャートである。

【図７】審査機能が追加された本発明の実施形態の証明
書発行動作を示すフローチャートである。

【図８】審査機能が追加された本発明の実施形態の証明
書発行動作を示すフローチャートである。

【図９】審査機能が追加された本発明の実施形態の概念
図である。

【図１０】本発明の実施形態による効果を示す図であ
り、（ａ）は従来行なわれていた構成が示され、（ｂ）
には本実施形態による構成が示されている。

【符号の説明】 １０ ネットワーク １００ クライアント端末 ２００ ＲＡサーバ ２０１ ＲＡコア部 ２０２ ＲＡセル ２０３ データベース ３００ 登録局 ４００ ＩＡサーバ ５００ 発行局

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｌ 9/00 ６０１Ｆ

Claims (6)

【特許請求の範囲】
1. 【請求項１】 ユーザからの要求に応じて公開鍵基盤証
   明書を発行する複数の発行局とともに認証局を構成する
   登録局であって、 前記複数の発行局についての情報と証明書の発行および
   失効に必要な情報をそれぞれ保持する複数のＲＡセル
   と、 ユーザ毎に異なるユーザ情報を格納するデータベース
   と、 前記ＲＡセルに保持されている発行局固有の情報と前記
   データベースに格納されているユーザ固有の情報を参照
   して前記複数の発行局との通信を行なうＲＡコア部とが
   設けられた１つのコンピュータにより構成されることを
   特徴とする公開鍵基盤の登録局。
2. 【請求項２】 請求項１記載の登録局を用いて構成され
   ていることを特徴とする認証局。
3. 【請求項３】 請求項１記載の登録局を用いて構成され
   ていることを特徴とする公開鍵基盤システム。
4. 【請求項４】 ユーザからの要求に応じて公開鍵基盤証
   明書を発行する複数の発行局とともに認証局を構成する
   登録局の構築方法であって、 前記複数の発行局についての情報と証明書の発行および
   失効に必要な情報をそれぞれ保持する複数のＲＡセル
   と、 ユーザ毎に異なるユーザ情報を格納するデータベース
   と、 前記ＲＡセルに保持されている発行局固有の情報と前記
   データベースに格納されているユーザ固有の情報を参照
   して前記複数の発行局との通信を行なうＲＡコア部とを
   １つのコンピュータに設けることを特徴とする公開鍵基
   盤の登録局の構築方法。
5. 【請求項５】 ユーザからの要求に応じて公開鍵基盤証
   明書を発行する複数の発行局とともに認証局を構成する
   登録局を構築するプログラムであって、 １つのコンピュータに、 前記複数の発行局についての情報と証明書の発行および
   失効に必要な情報をそれぞれ保持する複数のＲＡセル
   と、 ユーザ毎に異なるユーザ情報を格納するデータベース
   と、 前記ＲＡセルに保持されている発行局固有の情報と前記
   データベースに格納されているユーザ固有の情報を参照
   して前記複数の発行局との通信を行なうＲＡコア部とを
   作製する処理が記述されていることを特徴とする公開鍵
   基盤の登録局を構築するプログラム。
6. 【請求項６】 ユーザからの要求に応じて公開鍵基盤証
   明書を発行する複数の発行局とともに認証局を構成する
   登録局を構築するプログラムを格納した記録媒体であっ
   て、 １つのコンピュータに、 前記複数の発行局についての情報と証明書の発行および
   失効に必要な情報をそれぞれ保持する複数のＲＡセル
   と、 ユーザ毎に異なるユーザ情報を格納するデータベース
   と、 前記ＲＡセルに保持されている発行局固有の情報と前記
   データベースに格納されているユーザ固有の情報を参照
   して前記複数の発行局との通信を行なうＲＡコア部とを
   作製する処理が記述されているプログラムが記録されて
   いる記録媒体。