JP2002014613A - 証明書発行システム、証明書発行方法及び記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 認証局に依存せずに証明書を発行する。 【解決手段】 本発明の証明書発行システムは、エンド
エンティティの公開鍵の認証要求をウェブサーバ（１
２）を介して認証局サーバ（３１）へ発行するサブスク
ライバ（１１）と、エンドエンティティの認証要求の可
否を決定するＲＡオペレータ（１３，１４）と、サブス
クライバ（１１）から発行された認証要求であって、Ｒ
Ａオペレータ（１３，１４）で許可された認証要求を受
理し、予め定められた検証手順を行って処理結果を認証
局サーバ（３１）へ送信する登録局サーバ（２１）とを
備える。登録局サーバ（２１）はサブスクライバ（１
１）、ＲＡオペレータ（１３，１４）、及び認証局サー
バ（３１）を互いに関連付けたサイトを構築し、サブス
クライバ（１１）による認証要求の発行から認証局サー
バ（３１）における証明書発行に至るまでのサイト内に
おける各端末間の証明書発行手順を認証局サーバ（３
１）に依存せずに定義する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は公開鍵インフラスト
ラクチャにおける証明書発行システム及び方法に関す
る。

【０００２】

【従来の技術】公開鍵インフラストラクチャ（Public k
ey Infrastructure：ＰＫＩ）の運営主体である認証局
（Certification Authority：ＣＡ）は、エンドエンテ
ィティの所有する公開鍵の正当性を第三者に保証する第
三者機関であり、エンドエンティティの要求に応じてデ
ジタル署名による証明書を発行する。証明書の詳細につ
いてはＩＴＵ−Ｔ勧告のＸ．５０９に定義されており、
本人情報（所属組織、識別名、名前等）、公開鍵、有効
期限、シリアルナンバ、シグネチャ等が含まれている。
証明書の発行を求めるエンドエンティティとしては通
常、個人や組織、或いはＷｅｂサーバ若しくはそのプロ
グラムなどが該当する。

【０００３】それぞれの認証局には独自のポリシー（規
約）があり、エンドエンティティからの認証要求に対し
て簡単に認証をすべきでなく、本人確認を行う必要があ
る。このため、認証局に対するエンドエンティティから
の各種証明書申請を検証し、その結果（承認／拒否）を
認証局に送信する信頼性ある機関として登録局（Regist
ration Authority:ＲＡ）が設けられた。

【０００４】

【発明が解決しようとする課題】しかし、鍵の保管状
況、証明書の発行プロセス、発行される証明書の内容・
目的、証明書のライフサイクル等は認証局毎に相違する
ため、エンドエンティティは証明書の利用目的に応じて
認証局を選択する必要があるが、登録局における本人確
認等の検証手順を含む一連の証明書発行手順が認証局に
依存しているため、これらの証明書発行手順をエンドエ
ンティティが自由に定義するこができないという不便さ
が生じていた。

【０００５】そこで、本発明は証明書発行手順を認証局
に依存せずに登録局において自由に定義することで、エ
ンドエンティティの自由度を高めることのできる証明書
発行システム及び方法を提供することを課題とする。

【０００６】

【課題を解決するための手段】上記の課題を解決するべ
く、本発明の証明書発行システムは、エンドエンティテ
ィの公開鍵の認証要求を認証局サーバへ発行する認証要
求端末と、エンドエンティティの認証要求の可否を決定
する承認端末と、認証要求端末から発行された認証要求
であって、前記承認端末で許可された認証要求を受理
し、予め定められた検証手順を行って処理結果を認証局
サーバへ送信する登録局サーバとを備える。登録局サー
バは認証要求端末、承認端末、及び認証局サーバを互い
に関連付けたサイトを構築し、認証要求端末による認証
要求の発行から認証局サーバにおける証明書発行に至る
までのサイト内における各端末間の証明書発行手順を認
証局サーバに依存せずに定義する。

【０００７】また、本発明の証明書発行方法では、エン
ドエンティティの公開鍵の認証要求を認証局サーバへ発
行する認証要求端末、エンドエンティティの認証要求の
可否を決定する承認端末、及び認証局サーバを互いに関
連付けたサイトを構築し、認証要求端末による認証要求
の発行から認証局サーバにおける証明書発行に至るまで
のサイト内における各端末間の証明書発行手順を認証局
サーバに依存せずに定義する。

【０００８】本発明のコンピュータ読取可能な記録媒体
は、上記の証明書発行方法をコンピュータに実行させる
ためのプログラムを記録したコンピュータ読取可能な記
録媒体である。ここで、コンピュータ読取可能な記録媒
体とは、何らかの電子的手段或いは物理的手段によりプ
ログラム等が記録されているものであって、コンピュー
タ端末に所望の機能を実現させることができるものをい
う。従って、何らかの手段でコンピュータにダウンロー
ドし、所望の機能を実現させるものであればよい。例え
ば、ＲＯＭ、フレキシブルディスク、ハードディスク、
ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ
ＡＭ、ＤＶＤ−Ｒ、ＰＤディスク、ＭＤディスク、ＭＯ
ディスク等がある。

【０００９】

【発明の実施の形態】以下、各図を参照して本実施の形
態について説明する。

【００１０】図１を参照して本発明の証明書発行システ
ムの構成について説明する。同図において、ユーザシス
テム１０はサブスクライバ（Subscriver）１１、ウェブ
サーバ（Web Server）１２、ＲＡオペレータ（Registra
tion Authority Operator:ＲＡＯ）１３、ＲＡオペレー
タ１４、ＫＲオペレータ（Key Recovery Operator:ＫＲ
Ｏ）１５、及びＫＲオペレータ１６を備えて構成されて
いる。

【００１１】サブスクライバ１１はエンドエンティティ
が認証局３０へ認証要求するための認証要求端末であ
り、汎用のコンピュータ端末などで構成されている。サ
ブスクライバ１１にはネットスケープ・ナビゲーターや
インターネット・エクスプローラなどのブラウザが組み
込まれており、インターネット経由で認証局３０へ証明
書の発行申請を行う。例えば、ブラウザとして、インタ
ーネットエクスプローラを用いる場合は、ActiveＸを使
用して鍵生成と証明書要求を行うことができる。ウェブ
サーバ１２はサブスクライバ１１からの証明書発行申請
を受付け、専用のメッセージプロトコルに変換した後、
ＲＡサーバ２１に証明書発行申請をするための端末であ
る。ウェブサーバ１２とＲＡサーバ２１間の通信はＨＴ
ＴＰ／Ｓによる。

【００１２】ＲＡオペレータ１３、及びＲＡオペレータ
１４はエンドエンティティの証明書発行申請や失効要求
に関する審査を行う承認端末であり、エンドエンティテ
ィの正当性を保証する。通常はエンドエンティティのシ
ステム管理者が管理する。ＲＡオペレータが複数ある場
合には、１つのＲＡオペレータのアクションを他のＲＡ
オペレータが承認することで、セキュアな証明書発行申
請を実現できる。また、後述するように、ＲＡオペレー
タ１３、及びＲＡオペレータ１４はＣＡサーバ３１から
のＰＫＣＳ（Public Key Cryptography Standards）＃
１２の申請や取得、或いはＰＩＮ（ＰＫＣＳ＃１２を暗
号化・復号化するためのパスワード）の取得も行う。ま
た、ウェブサーバ１２と同等の権限が与えられた場合に
は、ＲＡオペレータ１３又はＲＡオペレータ１４からＲ
Ａサーバ２１へ証明書の発行申請を直接行うこともでき
る。ＲＡオペレータ１３、及びＲＡオペレータ１４とＲ
Ａサーバ２１間の通信はＨＴＴＰ／Ｓによる。

【００１３】ＫＲオペレータ１５、及びＫＲオペレータ
１６は鍵（秘密鍵と公開鍵のキーペア）の回復を行うと
きに使用される鍵回復端末である。通常は２台のＫＲオ
ペレータが設置されており、エンドエンティティのシス
テム管理者が管理する。ＲＡサーバ２１で鍵生成を行っ
た場合、予め定められた手順に従って鍵のバックアップ
が生成されるが、エンドエンティティが鍵を破損した場
合に、ＫＲオペレータがＲＡサーバ２１に鍵の回復申請
を行う。このとき、証明書の発行申請と同等のセキュリ
ティレベルを保つために、ＫＲオペレータ１５の鍵回復
申請をＫＲオペレータ１６が許可することで、ＲＡサー
バ２１に鍵回復申請が行われる。また、ＫＲオペレータ
１５、及びＫＲオペレータ１６は緊急時において、第三
者が暗号化された情報にアクセスできるように、鍵の取
得を許可された第三者へ鍵を提供する役割をも担う。Ｋ
Ｒオペレータ１５、及びＫＲオペレータ１６とＲＡサー
バ２１間の通信はＨＴＴＰ／Ｓによる。

【００１４】登録局２０はＲＡサーバ２１、及びＲＡコ
ンソール２２を備えて構成されている。ＲＡサーバ２１
は証明書の発行申請や失効申請を認証局３０へ渡すと同
時に、それぞれの申請の詳細情報を管理する。申請によ
ってはキーペアの生成も行う。証明書発行や失効の履歴
もＲＡサーバ２１で管理される。ＲＡサーバ２１は機能
別に、リモートアクセスエリア、コアエリア、ＣＡアク
セスエリア、キーストレージエリア、及びトランザクシ
ョンエリアから構成されている。リモートアクセスエリ
アにはウェブサーバ、ＲＡオペレータ、及びＫＲオペレ
ータが利用する共通ＡＰＩ（Application Program Inte
rface）が用意されている。コアエリアはＲＡサーバ２
１のエンジン部で、証明書の発行申請や失効申請に基づ
き、登録局への証明書発行要求を出すとともに、発行さ
れた証明書を利用してＰＫＣＳ＃１２やＰＩＮを生成す
る。キーペアの生成もここで行われる。

【００１５】ＣＡアクセスエリアは各種認証局に対応す
るインターフェース仕様を備えている。認証局がＵｎｉ
ＣＥＲＴの場合にはＰＫＩＸ（Public Key Infrastruct
ureX.509）に準拠している。キーストレージエリアはコ
アエリアで生成された秘密鍵と公開鍵のキーペアを格納
する。トランザクションエリアはキーペアの生成から証
明書の発行や失効の過程で生じたトランザクションログ
を保管する。証明書の発行や失効要求の履歴情報、及び
証明書の保管も行う。

【００１６】ＲＡコンソール２２は登録局２０における
システム構成の定義や管理を行うための管理ツールであ
る。詳細については後述する。認証局３０はＣＡサーバ
３１、及びＣＡオペレータ（Certification Authority
Operator:ＣＡＯ）３２を備えている。ＣＡサーバ３１
はＲＡサーバ２１から渡される申請情報に従って、証明
書の発行を行う。ＣＡオペレータ３２はＣＡサーバ３１
の初期設定、証明書に記載される拡張項目の設定、運用
メンテナンス等に使用される端末であり、権限が与えら
れた管理者のみが操作することができる。

【００１７】本明細書においては、証明書発行要求から
証明書発行に至るまでの一連の証明書発行手順に係わる
端末を互いに関連付けてグループ化し、これをサイトと
呼ぶ。例えば、図２に示すように、ＲＡオペレータ１
３、ＲＡオペレータ１４、ＫＲオペレータ１５、ＫＲオ
ペレータ１６、及びＣＡサーバ３１から１つのサイトが
構築される。また、本明細書において、サイトによって
定義された各端末の証明書発行手順をシナリオと呼ぶ。
サイトやシナリオの登録、更新、削除はＲＡコンソール
２２から自由に設定することができる。ＲＡコンソール
２２で定義できるのは、ＲＡオペレータやＫＲオペレー
タ、ＣＡサーバを含むシステム構成や、証明書の発行や
失効の処理の流れ（シナリオ）である。これらの設定情
報はサイト毎に管理される。

【００１８】シナリオで定義されたＲＡオペレータは自
分自身の権限を把握しており、それぞれの決められた範
囲内の業務を行う。例えば、同図に示す構成では、サイ
ト内に２台のＲＡオペレータがあるため、それぞれのＲ
Ａオペレータが承認しないとＣＡサーバ３１に証明書の
発行申請をしないように構成することで、ユーザシステ
ム１０におけるセキュリティを強化することができる。

【００１９】また、サイトは１つの登録局において複数
設定することができる。例えば、登録局２０において、
図２に示すサイトを構築するとともに、図３に示すサイ
トを別途構築してもよい。図３では、ＲＡオペレータ１
７、ＲＡオペレータ１８、及びＣＡサーバ３３から１つ
のサイトが構築されている。ＲＡオペレータ１７、ＲＡ
オペレータ１８は図２に示すサイトのエンドエンティテ
ィとは別のエンドエンティティのＲＡオペレータであっ
てもよく、同一エンティティのものでもよい。また、Ｃ
Ａサーバ３３はＣＡサーバ３１とは異なる認証局のＣＡ
サーバであってもよく、同一認証局のＣＡサーバであっ
てもよい。

【００２０】次に、図４乃至図７を参照して証明書発行
手順を説明する。証明書の発行パターンには４類ある。
まず、パターン１について、図４を参照して説明する。
本パターンではサブスクライバ１１から証明書の発行申
請を行い、ＲＡサーバ２１ではキーペアの生成を行わな
い。まず、サブスクライバ１１でキーペアの生成を行う
（ステップＳ１０１）。サブスクライバ１１は証明書の
発行申請をＰＫＣＳ＃１０形式でウェブサーバ１２に行
う（ステップＳ１０２）。サブスクライバ１１からウェ
ブサーバ１２へ証明書の発行申請があるとウェブサーバ
１２はこれを受付け、専用のメッセージプロトコルに変
換した後、ＲＡサーバ２１に証明書発行申請をする（ス
テップＳ１０３）。これにより、ＲＡサーバ２１には証
明書発行申請の一覧が蓄積される。

【００２１】続いて、ＲＡオペレータ１３がＲＡサーバ
２１に対して証明書発行申請の一覧を要求すると（ステ
ップＳ１０４）、ＲＡサーバ２１はＲＡオペレータ１３
に対して証明書発行申請の一覧を提示する（ステップＳ
１０５）。これに対し、ＲＡオペレータ１３は証明書の
発行申請の承認／拒否の通知を行う（ステップＳ１０
６）。同様の処理ステップをＲＡオペレータ１４も行う
（ステップＳ１０７〜ステップＳ１０９）。ＲＡオペレ
ータ１３、及びＲＡオペレータ１４に証明書発行申請が
許可されると、ＲＡサーバ２１はＣＡサーバ３１に証明
書発行要求をする（ステップＳ１１０）。すると、ＣＡ
サーバ３１はＲＡサーバ２１に証明書を発行する（ステ
ップＳ１１１）。ＲＡサーバ２１にはＰＫＣＳ＃７形式
などの証明書が保管される。

【００２２】サブスクライバ１１がＰＫＣＳ＃７形式な
どの証明書の取得をウェブサーバ１２に要求すると（ス
テップＳ１１２）、ウェブサーバ１２はこれを受付け、
専用のメッセージプロトコルに変換した後、ＲＡサーバ
２１にＰＫＣＳ＃７形式などの証明書の取得を要求する
（ステップＳ１１３）。これに対し、ＲＡサーバ２１は
ＰＫＣＳ＃７形式などの証明書をウェブサーバ１２に送
信し（ステップＳ１１４）、これを受け取ったウェブサ
ーバ１２はサブスクライバ１１にＰＫＣＳ＃７形式など
の証明書を転送する（ステップＳ１１５）。

【００２３】次に、パターン２について、図５を参照し
て説明する。本パターンではサブスクライバ１１から証
明書の発行申請を行い、ＲＡサーバ２１でキーペアの生
成を行う。サブスクライバ１１からウェブサーバ１２へ
証明書の発行申請があると（ステップＳ２０１）、ウェ
ブサーバ１２はこれを受付け、専用のメッセージプロト
コルに変換した後、ＲＡサーバ２１に証明書発行申請を
する（ステップＳ２０２）。これにより、ＲＡサーバ２
１には証明書発行申請の一覧が蓄積される。続いて、Ｒ
Ａオペレータ１３がＲＡサーバ２１に対して証明書発行
申請の一覧を要求すると（ステップＳ２０３）、ＲＡサ
ーバ２１はＲＡオペレータ１３に対して証明書発行申請
の一覧を提示する（ステップＳ２０４）。これに対し、
ＲＡオペレータ１３は証明書の発行申請の承認／拒否の
通知を行う（ステップＳ２０５）。同様の処理ステップ
をＲＡオペレータ１４も行う（ステップＳ２０６〜ステ
ップＳ２０８）。ＲＡオペレータ１３、及びＲＡオペレ
ータ１４に証明書発行申請が許可されると、ＲＡサーバ
２１はキーペア生成を行い（ステップＳ２０９）、ＣＡ
サーバ３１に証明書発行要求をする（ステップＳ２１
０）。すると、ＣＡサーバ３１はＲＡサーバ２１に証明
書を発行する（ステップＳ２１１）。ＲＡサーバ２１に
はＰＫＣＳ＃１２形式の証明書とＰＩＮが保管される。

【００２４】ＲＡオペレータ１３はＰＫＣＳ＃１２形式
の証明書の取得をＲＡサーバ２１に要求すると（ステッ
プＳ２１２）、ＲＡサーバ２１はＰＫＣＳ＃１２形式の
証明書をＲＡオペレータ１３に送信する（ステップＳ２
１３）。一方、ＲＡオペレータ１４はＰＩＮの取得をＲ
Ａサーバ２１に要求すると（ステップＳ２１４）、ＲＡ
サーバ２１はＰＩＮをＲＡオペレータ１４に送信する
（ステップＳ２１５）。このように、ＰＫＣＳ＃１２形
式の証明書とＰＩＮをそれぞれ異なるＲＡオペレータか
ら取得することで、セキュリティを強化することができ
る。

【００２５】次に、パターン３について、図６を参照し
て説明する。本パターンではＲＡオペレータ１３はウェ
ブサーバ１２と同等の権限を有し、証明書の発行申請を
行う。また、ＲＡサーバ２１でキーペアの生成を行う。
まず、ＲＡオペレータ１３がＲＡサーバ２１に証明書の
発行申請を行う（ステップＳ３０１）。ＲＡオペレータ
１３がＲＡサーバ２１に対して証明書発行申請の一覧を
要求すると（ステップＳ３０２）、ＲＡサーバ２１はＲ
Ａオペレータ１３に対して証明書発行申請の一覧を提示
する（ステップＳ３０３）。これに対し、ＲＡオペレー
タ１３は証明書の発行申請の承認／拒否の通知を行う
（ステップＳ３０４）。同様の処理ステップをＲＡオペ
レータ１４も行う（ステップＳ３０５〜ステップＳ３０
７）。ＲＡオペレータ１３、及びＲＡオペレータ１４に
証明書発行申請が許可されると、ＲＡサーバ２１はキー
ペア生成を行い（ステップＳ３０８）、ＣＡサーバ３１
に証明書発行要求をする（ステップＳ３０９）。する
と、ＣＡサーバ３１はＲＡサーバ２１に証明書を発行す
る（ステップＳ３１０）。ＲＡサーバ２１にはＰＫＣＳ
＃１２形式の証明書とＰＩＮが保管される。

【００２６】ＲＡオペレータ１３はＰＫＣＳ＃１２形式
の証明書の取得をＲＡサーバ２１に要求すると（ステッ
プＳ３１１）、ＲＡサーバ２１はＰＫＣＳ＃１２形式の
証明書をＲＡオペレータ１３に送信する（ステップＳ３
１２）。一方、ＲＡオペレータ１４はＰＩＮの取得をＲ
Ａサーバ２１に要求すると（ステップＳ３１３）、ＲＡ
サーバ２１はＰＩＮをＲＡオペレータ１４に送信する
（ステップＳ３１４）。

【００２７】最後に、パターン４について、図７を参照
して説明する。本パターンは予め個人情報を管理する別
のシステムが存在する場合に使用するものであり、別シ
ステムで既に個人用ＰＩＮの管理がされており、本証明
書発行システムで新たに作成されたＰＩＮと２重の管理
をしたくない場合に利用できる。本パターンにおいては
ＲＡオペレータ１４がウェブサーバ１２と同等の権限を
有し、ＲＡサーバ２１に証明書の発行申請を行う。ま
た、キーペアはＲＡサーバ２１で生成される。

【００２８】まず、ＲＡオペレータ１４は、予め用意さ
れたＰＩＮを外部から取り込む（ステップＳ４０１）。
ＲＡオペレータ１４がＲＡサーバ２１に証明書の発行申
請を行う（ステップＳ４０２）。ＲＡオペレータ１４が
ＲＡサーバ２１に対して証明書発行申請の一覧を要求す
ると（ステップＳ４０３）、ＲＡサーバ２１はＲＡオペ
レータ１４に対して証明書発行申請の一覧を提示する
（ステップＳ４０４）。これに対し、ＲＡオペレータ１
４は証明書の発行申請の承認／拒否の通知を行う（ステ
ップＳ４０５）。同様の処理ステップをＲＡオペレータ
１３も行う（ステップＳ４０６〜ステップＳ４０８）。
ＲＡオペレータ１３、及びＲＡオペレータ１４に証明書
発行申請が許可されると、ＲＡサーバ２１はキーペア生
成を行い（ステップＳ４０９）、ＣＡサーバ３１に証明
書発行要求をする（ステップＳ４１０）。すると、ＣＡ
サーバ３１はＲＡサーバ２１に証明書を発行する（ステ
ップＳ４１１）。ＲＡサーバ２１にはＰＫＣＳ＃１２形
式の証明書とＰＩＮが保管される。

【００２９】ＲＡオペレータ１３はＰＫＣＳ＃１２形式
の証明書の取得をＲＡサーバ２１に要求すると（ステッ
プＳ４１２）、ＲＡサーバ２１はＰＫＣＳ＃１２形式の
証明書をＲＡオペレータ１３に送信する（ステップＳ４
１３）。一方、ＲＡオペレータ１４はＰＩＮの取得をＲ
Ａサーバ２１に要求すると（ステップＳ４１４）、ＲＡ
サーバ２１はＰＩＮをＲＡオペレータ１４に送信する
（ステップＳ４１５）。

【００３０】尚、上述のパターン１〜パターン４は証明
書申請の単発行及び複数の証明書を一括して発行できる
ものであったが、複数の証明書申請を一括して行う（バ
ルク発行）こともできる。

【００３１】以上、説明したように、本実施の形態によ
れば、証明書発行手順に係わる各端末をサイトという概
念で関連付け、証明書に付帯する各種情報の管理から証
明書の発行や失効といったサイト内の処理の流れをシナ
リオとして定義したため、認証局３０に依存せずに証明
書発行手順を任意に定義することができる。

【００３２】また、証明書発行手順にサイトという概念
を導入したため、１つの登録局２０で複数のサイトを定
義することができる。このため、ポリシーやシナリオが
異なる複数のサイトを１つの登録局２０で管理すること
ができるため、複数の認証局に対応することが可能であ
る。

【００３３】また、ＫＲオペレータを設置することで、
証明書の有効期間内に鍵を破損した場合でも、証明書の
再発行をする必要がない。また、キーペアや証明書の扱
いは標準プロトコルであるＰＫＣＳに準拠し、互換性に
優れている。また、企業での利用には欠かせない証明書
発行の一括処理（バルク処理）にも対応できる。

【００３４】

【発明の効果】本発明によれば、認証局に依存せずに証
明書発行手順を任意に定義することができる。また、１
つの登録局で複数の認証局に対して証明書の発行手順を
定めることができる。さらに、登録局で生成された鍵を
回復するための端末を設けたため、証明書の有効期限内
に鍵を紛失等した場合にも証明書の再発行をする必要が
ない。

【図面の簡単な説明】

【図１】証明書発行システムの構成図である。

【図２】サイトの説明図である。

【図３】サイトの説明図である。

【図４】証明書発行手続における各端末の交信図であ
る。

【図５】証明書発行手続における各端末の交信図であ
る。

【図６】証明書発行手続における各端末の交信図であ
る。

【図７】証明書発行手続における各端末の交信図であ
る。

【符号の説明】

１０…ユーザシステム、１１…サブスクライバ、１２…
ウェブサーバ、１３…ＲＡオペレータ、１４…ＲＡオペ
レータ、１５…ＫＲオペレータ、１６…ＫＲオペレー
タ、１７…ＫＲオペレータ、１８…ＫＲオペレータ、２
０…登録局、２１…ＲＡサーバ、２２…ＲＡコンソー
ル、３０…認証局、３１…ＣＡサーバ、３２…ＣＡオペ
レータ、３３…ＣＡサーバ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 西村 孝司 東京都千代田区紀尾井町４−１ ニューオ ータニ ガーデンコート ８階 日本ボル チモアテクノロジーズ株式会社内 (72)発明者 新田 英由 東京都千代田区紀尾井町４−１ ニューオ ータニ ガーデンコート ８階 日本ボル チモアテクノロジーズ株式会社内 Ｆターム(参考） 5J104 AA07 AA16 EA05 KA02 MA04 NA02 NA05

Claims (9)

【特許請求の範囲】
1. 【請求項１】 エンドエンティティの公開鍵の認証要求
   を認証局サーバへ発行する認証要求端末と、エンドエン
   ティティの認証要求の可否を決定する承認端末と、認証
   要求端末から発行された認証要求であって、前記承認端
   末で許可された認証要求を受理し、予め定めれた検証手
   順を行って処理結果を認証局サーバへ送信する登録局サ
   ーバとを備え、前記登録局サーバは認証要求端末、承認
   端末、及び認証局サーバを互いに関連付けたサイトを構
   築し、認証要求端末による認証要求の発行から認証局サ
   ーバにおける証明書発行に至るまでのサイト内における
   各端末間の証明書発行手順を認証局サーバに依存せずに
   定義する証明書発行システム。
2. 【請求項２】 前記登録局サーバは複数のサイトを構築
   する請求項１に記載の証明書発行システム。
3. 【請求項３】 前記登録局サーバは複数の認証局サーバ
   との間でサイトを構築する請求項１又は請求項２に記載
   の証明書発行システム。
4. 【請求項４】 前記登録局サーバで生成された鍵を回復
   するための鍵回復端末をサイト内に定義し、鍵回復端末
   を含めたサイト内における各端末間の証明書発行手順を
   定義した請求項１乃至請求項３のうち何れか１項に記載
   の証明書発行システム。
5. 【請求項５】 エンドエンティティの公開鍵の認証要求
   を認証局サーバへ発行する認証要求端末、エンドエンテ
   ィティの認証要求の可否を決定する承認端末、及び認証
   局サーバを互いに関連付けたサイトを構築し、認証要求
   端末による認証要求の発行から認証局サーバにおける証
   明書発行に至るまでのサイト内における各端末間の証明
   書発行手順を認証局サーバに依存せずに定義する証明書
   発行方法。
6. 【請求項６】 登録局サーバが複数のサイトを構築し、
   それぞれのサイト毎に定義された証明書発行手順に従っ
   て証明書を発行する請求項５に記載の証明書発行方法。
7. 【請求項７】 登録局サーバが複数の認証局サーバとの
   間でサイトを構築する請求項５又は請求項６に記載の証
   明書発行方法。
8. 【請求項８】 登録局サーバで生成された鍵を回復する
   ための鍵回復端末をサイト内に定義し、鍵回復端末を含
   めたサイト内における各端末間の証明書発行手順を定め
   た請求項５乃至請求項７のうち何れか１項に記載の証明
   書発行方法。
9. 【請求項９】 請求項５乃至請求項８のうち何れか１項
   に記載の証明書発行方法を登録局サーバに実行させるプ
   ログラムを記録したコンピュータ読み取り可能な記録媒
   体。