(57)【特許請求の範囲】
【請求項１】
公開鍵証明証に記述される名前を、前記名前に含まれる一般名を最下位階層とした木構造で管理し、利用者からの申請情報に応じて公開鍵証明証の作成、追加、削除を行う公開鍵証明証管理方法において、
前記木構造の最下位階層及び前記最下位階層の一段上位階層を除く各階層に、自テーブルのテーブル名称と、自テーブルの下位階層の各名称（以下エントリ名という）と前記エントリ名に対応するテーブル名称とを関連付けて記録保持するＤＩＴ管理テーブルと、
前記木構造の最下位階層から一段上位の階層にあるエントリ名毎に、自テーブルのテーブル名称と前記エントリの階層にある一般名と前記一般名に対応した公開鍵証明証とを関連付けて記録保持している公開鍵証明証テーブルとをデータベースに設け、
前記各ＤＩＴ管理テーブルを読み出しのみを可能とし、前記各公開鍵証明証テーブルの読み出しと書き込みと消去を可能とするデータベースのアクセス制御手段を有し、
前記申請情報中の名前を前記木構造の階層毎に分解し、前記分解した名前の各部が対応する前記ＤＩＴ管理テーブルのエントリ名に存在するかを調べるＤＮチェックステップと、
前記ＤＮチェックステップにより、前記分解した名前を構成する全ての階層の前記ＤＩＴ管理テーブルに該当するエントリが存在すると判定された場合には、前記分解した名前の最下位層にある一般名が対応する前記公開鍵証明証テーブルに存在するか否かを調べるＣＮチェックステップと、
前記申請情報中の処理種別が作成か削除か追加かを調べるサービス振り分けステップと、
前記申請処理が公開鍵証明証の作成の場合であって、前記ＣＮチェックステップで前記一般名が存在しないと判定された場合は、公開鍵証明証を作成し、前記申請情報中の名前の最下端から一段上位のエントリ名と対応する前記公開鍵証明証テーブルに、前記申請情報中の名前の一般名と、前記作成した公開鍵証明証とを新たに書き込む公開鍵証明証作成ステップと、前記申請処理が公開鍵証明証の削除の場合であって、前記ＣＮチェックステップで前記一般名が存在すると判定された場合は、前記公開鍵証明証テーブルの前記一般名に対応づけられている公開鍵証明証から前記申請処理で指定された公開鍵証明証を削除する公開鍵証明証削除ステップと前記申請処理が公開鍵証明証の追加の場合であって、前記ＣＮチェックステップで前記一般名が存在すると判定された場合には、公開鍵証明証を新たに作成し、前記申請情報中の名前の最下端から一段上位のエントリ名と対応する前記公開鍵証明証テーブルの、前記申請情報中の名前の最下端と一致した一般名に対し、前記新たに作成した公開鍵証明証を追加登録する公開鍵証明証追加ステップとを有することを特徴とする公開鍵証明証管理方法。
【請求項２】
前記公開鍵証明証削除ステップにおいて、前記公開鍵証明書を削除した結果、前記一般名に関連付けられた公開鍵証明証が存在しなくなった場合は、前記一般名を前記公開鍵証明証テーブルから削除するステップを有することを特徴とする請求項１に記載の公開鍵証明証管理方法。
【請求項３】
前記ＣＮチェックステップで一般名が存在していると、その一般名と対応する登録済の公開鍵証明証を用いて、前記申請情報中に付けられた電子署名を検証し、その検証に合格すると、その後の処理に移ることを特徴とする請求項１〜２に記載の公開鍵証明証管理方法。
【請求項４】
請求項１〜３のいずれかに記載した公開鍵証明証管理方法の各ステップをコンピュータに実行させるためのプログラムを記録したコンピュータにより読み出し可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、コンピュータネットワーク上でＥＤＩ（電子データ交換）やＥＣ（電子商取引）などを実現する際に、送信データの秘匿性や改ざん防止の目的で利用される認証システム（Ｃｅｒｔｉｆｉｃａｔｉｏｎ  Ａｕｔｈｏｒｉｔｙ：以下ＣＡと記す）の構成方法、特に公開鍵暗号方式にもとづく、その公開鍵証明証を発行／管理する機関における管理方法及びその方法のプログラムを記録した記録媒体に関するものである。
【０００２】
【従来の技術】
コンピュータネットワーク上でＥＤＩ（電子データ交換）やＥＣ（電子商取引）を実現する際には、盗聴／なりすまし／改ざん／送信否認などの脅威が想定されるため、それを防御するために暗号通信やディジタル署名通信が用いられるのが一般的である。この暗号通信、及びディジタル署名通信を行う有力な方法として、公開鍵暗号方式がある。この方式は、参考文献「Ｄｉｆｆｉｅ，Ｗ．ａｎｄＨｅｌｍａｎ，Ｍ．：Ｎｅｗ  Ｄｉｒｅｃｔｉｏｎ  ｉｎ  Ｃｒｙｐｔｏｇｒａｐｈｙ，ＩＥＥＥ  Ｔｒａｎｓ．Ｉｎｆ．Ｔｈｅｏｒｙ，ＩＴ−２２，６ｐｐ．６４４−６５４，１９７６」で発表されており、世の中で広く知られているところとなっている。この公開鍵暗号方式では、鍵の持ち主を証明する第三者機関が必要であり、それがＣＡ（Ｃｅｒｔｉｆｉｃａｔｉｏｎ  Ａｕｔｈｏｒｉｔｙ）と呼ばれているものである。ＣＡは、日本の実社会で、実印の持主を証明する印鑑証明書を役所が発行するのと同様に、ディジタル通信の世界において、暗号化鍵の持ち主を証明する公開鍵証明証を発行する機能を持ったシステムであるということができる。
【０００３】
一般的に知られているＣＡの機能は、次の通りである。
・公開鍵登録機能…利用者が申請した公開鍵に対して、公開鍵証明証を作成／登録／発行する。
・証明証参照機能…ＣＡで管理している公開鍵証明証を利用者から参照可能とする。
・公開鍵無効化機能…公開鍵証明証を無効化し、無効化リストに掲載する。
・無効化リスト参照機能…無効化された公開鍵証明証の一覧を利用者から参照可能とする。
【０００４】
これらの機能は、コンピュータシステムや暗号アルゴリズムが提供する一般的な手段を用いて構築可能であり、申請時に申請書を用いた依頼を行うこと、ＣＡと利用者の間ではディジタル署名通信を行うこと、公開鍵証明証や無効化リストはディレクトリやデータベースに管理しておくこと、など基本的な構成方式については、一般的方法であると認知されている。さて、ＣＡを構築する際にはディレクトリの概念（Ｘ．５００、ＩＳＯ／ＩＥＣ／ＤＩＳ  ９５９４−１）が広く利用されている。従って、ＣＡで管理する公開鍵証明証等もそれに準拠した形式が採用されることが想定される。公開鍵証明証内に記述される「名前」もＸ．５００勧告で規定された形式で広く用いられている。「名前」は１文字列で指定するのではなく、いくつかの階層（以降、エントリとする）名称を並べた形式であり、それが名前、いわゆるＤＮ（Ｄｉｓｔｉｎｉｇｕｉｓｈｅｄ  Ｎａｍｅ）となる。これらＤＮは、ＣＡ内でＸ．５００勧告の木構造、いわゆるＤＩＴ（Ｄｉｒｅｃｔｏｒｙ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｒｅｅ）で管理されるのが一般である。ここでＤＮとＤＩＴに関して例をあげて説明すると、図１で「日本」が木構造の最上位となり、その下に枝わかれしていく。これをＤＩＴ構造という。また、ＤＩＴは各エントリ、「神奈川」、「横浜」等の階層で構成され、その最下端が個人となる一般名で示される。このＤＩＴ構造で「鈴木」をＤＮで示すと、
Ｃ＝日本、Ｌ＝神奈川、ＳＴ＝横浜、ＣＮ＝鈴木
と最上位からの階層で示される。ここで、Ｃは国名、Ｌは地方名、ＳＴは地域名、ＣＮは一般名である。ただし、このＤＩＴには構造の規定は無く、ＣやＬ等のエントリの属性付与基準だけがあるのが現状である。通常ディレクトリの概念では、エントリの生成、追加、削除の要求があった場合はそれらの処理を行うが、それをＣＡとして確立する場合、そのＤＮの内容と関係をＤＩＴ管理テーブル内に登録されているかを確認し、許可していないＤＮに対する処理を行わないような機構が必要となる。これら、Ｘ．５００に準拠したシステムを構築することは、コンピュータシステムの応用範囲として一般的に存在するものと捉えることができる。しかし、その効率的な実現方法については技術的な仕組みが必要になるため、色々な方法が考えられるところである。この発明も、その実現方法の１つとして提案するもので、許可されていないＤＮを確認することに着目した管理方法を示したものである。
【０００５】
一般的なＣＡでは、公開鍵証明証を作成する場合、利用者が申請書内に自分のＤＮを記述し、これを受け付けたＣＡは、申請者の指定したＤＮに基づいて公開鍵証明証を作成する。また一度公開鍵証明証の登録を行った利用者が、さらに別の公開鍵に対する証明証の発行を依頼、つまり登録する公開鍵の追加を行う場合には、新規登録時と同様に証明証の作成を行う。さらに削除処理では、指定されたＤＮ等に該当する公開鍵証明証を削除する。これら処理を行う時のキーとなるのはＤＮである。このような構成方式においては、申請書内のＤＮのエントリ付与基準や、＝（イコール）で区切られている等の書式に関しての確認は行われている。
【０００６】
【発明が解決しようとする課題】
前述したように一般的なＣＡにおいては、ＤＮの書式を確認するのみで各エントリの内容や、関係に関しては触れずに、利用者の指定したＤＮにしたがって証明証を作成するため、許可されていないＤＮや、利用者の入力ミス等によるＤＮを申請書に記述して登録申請された場合には、いたずらに様々な名称を持ったエントリが増加したり、意味を持たないＤＮを持った公開鍵証明証が増加するおそれがある。したがって、ＣＡが許可するＤＮのエントリ名称や属性、関係をすべて管理し、いかに少ない情報でチェックできるか、同時に公開鍵証明証をいかに容易に管理できるかがこの発明の目的である。
【０００７】
【課題を解決するための手段】
この発明は、許可するＤＮの最下端より一階層上位までのエントリ名称を全てＤＩＴ管理テーブルで登録、管理し、申請があった際の確認対象とする。ＤＮの最下端のエントリは、管理テーブルとは別に個々の公開鍵証明証テーブルで管理し、一般名（ＣＮ名称）をキーとして、かつその一般名に対する公開鍵証明証を格納する。それ以外は各階層毎のＤＮ管理テーブルでその階のエントリ名と、下位階層の管理テーブルの指定を管理する。
【０００８】
この発明の管理方法はこれを実行する機能としては▲１▼ＤＩＴ管理テーブルへの検索手段、▲２▼公開鍵証明証の作成手段、▲３▼公開鍵証明証の追加手段、▲４▼公開鍵証明証の削除手段、及びこれらの機能を呼び出す処理によって構成される。なお、この管理方法の実行の前提とし、▲１▼ＤＩＴ管理テーブル作成手段、▲２▼エントリ名称登録手段、により管理テーブル、公開鍵証明証テーブルの作成が予めなされる。
【０００９】
これらテーブルの作成から、この発明方法の実行は例えば図２に示すようにこれらの手段を用いて処理される。
（１）システム初期生成処理において、許可するＤＮのエントリ名称（階層）分だけＤＩＴ管理テーブル作成手段を用いてデータベースのテーブルを生成する。
（２）エントリ名称登録処理において、ＣＡが許可する中間階層のエントリ名称をエントリ登録手段を用いて登録する。
（３）ＤＮチェックステップにおいて、利用者からの申請書情報に含まれているＤＮ情報を取り出し、階層毎に分割し、ＤＩＴ管理テーブルへの検索手段を用いて上位層から最下端より一階層上位までのＤＮが許可されているか否かの確認を行う。
（４）サービス振分けステップにおいて、利用者からの申請書に含まれる「処理種別」情報により、公開鍵証明証作成ステップ、公開鍵証明証追加ステップ、公開鍵証明証削除ステップの何れかに振分ける。
（５）公開鍵証明証作成ステップにおいて、申請されたＤＮの最下端（一般名）が該当の公開鍵証明証テーブルに存在していないことを確認した後、このテーブルにエントリ（その一般名）を作成する。そして、申請書情報から公開鍵証明証を作成し、該当の公開鍵証明証管理テーブルの該当のエントリにこの公開鍵証明証を登録する。またここですでに一般名が登録されている場合には、この申請は却下される。
（６）公開鍵証明証追加ステップにおいて、申請されたＤＮの最下端（一般名）が該当の公開鍵証明証テーブルに存在していることを確認し、該当のエントリに登録済の公開鍵証明証を用いて申請書に付与された電子署名を検証することにより、エントリに該当する利用者と同一の利用者であることを確認する。その後、申請書情報から公開鍵証明証を作成し、該当する公開鍵証明証管理テーブル内の該当ＤＮの一般名に作成した公開鍵証明証を追加する。
（７）公開鍵証明証削除ステップにおいて、申請されたＤＮの最下端（一般名）が該当の公開鍵証明証テーブルに存在していることを確認し、該当のエントリに登録済の公開鍵証明証を用いて申請書に付与された電子署名を検証することにより、エントリに該当する利用者と同一の利用者であることを確認する。その後、該当公開鍵証明証を削除する。また、ここで、その一般名の所持している証明証が全て削除された場合は、その一般名（エントリ）も削除される。
【００１０】
図２において例えば、システム初期生成ステップにはＤＩＴ管理テーブルの作成以外にもいろいろな初期化ステップが存在するため、左右方向の矢印はその処理が一部として、図中の手段を呼び出すことを意味している。
この発明の方法によれば、利用者からの申請書情報に含まれるＤＮ情報の正当性のチェックを行うことが可能になり、同時に許可するエントリの重複登録なく、公開鍵証明証を管理するシステムを構築することができる。
【００１１】
【発明の実施の形態】
この発明の実施例を以下に説明する。この発明では申請書中の名前（ＤＮ）を木構造で管理し、その木構造の最下位階層を除く、各階層ごとにＤＮ管理テーブルを作り、最下位階層から一段上位の各リーフに公開鍵証明証テーブルを作る。これらの具体例を図３に示す。この図３は図１に示したＤＮの木構造を例としたものである。
【００１２】
まず、最上位の「日本」は固定であり、日本の配下にくるエントリを検索するために、テーブル名称１４が「日本．ｔｂｌ」のＤＩＴ管理テーブル１５を参照する。各ＤＩＴ管理テーブル１５には、そのテーブル名称の欄１４、エントリ名が記録される欄１６、その属性が記録される欄１７、その下位に位置することができる属性が記録される欄１８、その下位属性、つまり下位の階層をエントリとするＤＮ管理テーブルの名称が記録される欄１９が設けられている。「日本．ｔｂｌ」の管理テーブルにはエントリ名欄１６に「東京」、「神奈川」が登録されているため、「日本」の配下には「東京」と「神奈川」のみの指定が可能となる。また「神奈川」の属性は「Ｌ」であり、その配下に位置できるエントリ（階層）属性は「ＳＴ」となる。同じようにテーブル名称が「神奈川．ｔｂｌ」のＤＮ管理テーブル、つまり「神奈川」の配下に登録されているエントリ名称は「横浜」であり、属性は「ＳＴ」である。
【００１３】
これらＤＩＴ管理テーブル１５とは別に設ける「公開鍵証明証テーブル」２１は最下端の階層である利用者の一般名と公開鍵証明証そのものを管理する。つまり各地域（木構造のリーフ）の下に個々の公開鍵証明証テーブル２１が存在する。公開鍵証明証テーブル２１は、テーブル名称の欄２２、エントリされる一般名が記録される欄２３、公開鍵証明証などのデータが記録される欄２４がそれぞれ設けられている。このような公開鍵証明証テーブル２１を設けるのは登録者が増えた場合の検索範囲を狭める効果と同姓同名でも地域が違えば登録が可能であることを示している。また、最下端とそれ以外の階層の管理を分けた理由については、利用者が追加／削除できる階層とできない階層にわけていることにある。図１のＤＩＴで説明すると、ＣＡが申請書に記述されたＤＮとＣＡ内で管理するＤＮ管理テーブル１５とで比較確認する階層は、
Ｃ＝日本、Ｌ＝神奈川、ＳＴ＝横浜、
Ｃ＝日本、Ｌ＝東京、ＳＴ＝港区、など
であり、「鈴木」、「高橋」といった最下端の一般名については該当の公開鍵証明証テーブル２１によって管理される。もしその一般名が該当の公開鍵証明証テーブルに存在しない場合で、それが利用者からの公開鍵証明証の新規登録であった場合には、当然「公開鍵証明証テーブル」２１にそのエントリを追加する。逆に一般名が該当の公開鍵証明証テーブル２１に存在していた場合には、利用者からの公開鍵証明証の新規登録の受付を拒否し、同一利用者による公開鍵証明証の追加登録に限ってこの申請を受け付け、該当のエントリに公開鍵証明証を追加登録することにする。これによって、違う利用者が同一のＤＮを持つといったＤＮの重複を防ぐことが可能になる。ここで、同一利用者であるか否かを確認する手法としては、利用者が追加登録をする際の申請書に、すでに登録済の公開鍵によって検証可能な電子署名を付与してもらい、ＣＡは、公開鍵証明証テーブル２１の該当のエントリに既に登録されている公開鍵証明証を用いて申請書に付与された電子署名を検証し、これが正常に完了したことを確認することにより、該当のエントリを持つ利用者と同一の利用者による追加登録申請であることを確認する。このことは、登録した利用者のみが、その登録済の公開鍵によって検証可能な電子署名を付与することが可能であるということを利用しているものである。またこの同一利用者であるか否かの確認は、公開鍵証明証の削除処理においても行われる。これは、同じＤＮを名乗る異なる利用者が、該当のエントリに登録された公開鍵証明証を、勝手に削除することがないようにするためである。
【００１４】
以上のように、最下端のエントリ名称については、該当の公開鍵証明証テーブル２１に存在しない場合に限ってエントリとして追加することを可能とし、最下端より上位の階層のエントリについては、データベースのアクセス制御により利用者からの問い合わせに対しては「読込み」だけで「書き込み不可」とし、勝手に中間のエントリを追加することができないようにする。従って、利用者からの申請書で例えば、図１の状況において
Ｃ＝日本、Ｌ＝神奈川、ＳＴ＝横須賀、ＣＮ＝・・・
のようなＤＮで申請された場合は、名称が「神奈川．ｔｂｌ」のＤＮ管理テーブル１５内に「横須賀」が登録されていないため、その申請書に対する要求は却下され、処理を打ち切ることになる。
【００１５】
以上のように、ＤＮ管理テーブル１５と公開鍵証明証テーブル２１によってＤＮを管理することにより、悪意のあるアクセスや、利用者のＤＮの指定ミスに対してその確認が可能になると同時に、新規利用者のエントリの追加、新規利用者のエントリの重複登録の防止などが可能となる。
次に図３に示したＤＮ管理テーブル１５と公開鍵証明証テーブル２１を設けて、公開鍵証明証の管理を行うこの発明の具体的な実施例を図４及び図５を用いて説明する。
【００１６】
まずこの発明方法を実行する前提である各テーブルの作成手順を説明する。
（１）システム初期生成ステップ
ＣＡの初期生成処理では、各種の初期生成処理を行うが、その処理の一部としてＤＩＴ管理テーブル作成手段８を呼び出す。ＣＡで許可するＤＩＴの階層分だけデータベースのＤＩＴ管理テーブル１５の群を生成する。
（２）エントリ名称登録ステップ
ＣＡで許可するエントリ名称をエントリ登録手段９を用いて対応する階層のＤＩＴ管理テーブル１５に登録する。ただし、これに関しては既にコンピュータシステムで一般的に提供されているデータベースへのデータの登録などの機能を用いればよく、この発明で特に新しいものではない。また、登録するエントリ名称はＤＩＴの中間階層にあたるもののみであり、公開鍵証明証テーブル２１には登録を行わない。
【００１７】
通常、このエントリ名称の登録は、初期生成時に１度行う処理であり、次にＤＩＴ構造の変更が無い限りはエントリ登録処理は行なわなくてよい。
（３）ＤＮチェックステップ
ＤＮチェックステップでは、ＤＩＴ管理テーブル検索手段１０を呼び出し、利用者から送られてくる申請書内の情報に含まれるＤＮ情報を取り出し、エントリ毎に分解し、最下端エントリより一階層上位のエントリ名称までについて、これが各ＤＩＴ管理テーブル１５内に存在するかを繰り返し検索する。最下端のエントリ名称は確認の対象にはならない。仮に申請書情報のＤＮが
Ｃ＝日本、Ｌ＝神奈川、ＳＴ＝横浜、ＣＮ＝石田
とすると、Ｃ＝日本、Ｌ＝神奈川、ＳＴ＝横浜までをＤＩＴ管理テーブル１５で検索して許可されていることを確認し、ＣＮ＝石田は確認対象ではない。
（４）サービス振分けステップ
サービス振分けステップは、ＤＮチェックステップでＤＮの正当性が確認された後、申請書情報の一部であるサービス（処理）種別情報、いわゆる利用者からの問い合わせ種別を判別して、公開鍵証明証作成ステップ、公開鍵証明証追加ステップ、公開鍵証明証削除ステップの何れかのステップに振分けを行う処理である。
（５）公開鍵証明証作成ステップ
公開鍵証明証作成ステップでは、公開鍵証明証作成手段１１を呼び出す。ここでは利用者から申請されたＤＮの最下端（一般名）が該当の公開鍵証明証テーブル２１に存在していないことを確認した後、このテーブルにエントリを作成する。そして申請書情報をもとに公開鍵証明証を作成し、該当の公開鍵証明証テーブル２１内の該当のエントリに新規に登録する。公開鍵証明証の作成依頼の際の利用者のＤＮを
Ｃ＝日本、Ｌ＝神奈川、ＳＴ＝横浜、ＣＮ＝石田
で説明すると、公開鍵証明証テーブル２１に「石田」のエントリ名称と公開鍵証明証が追加されることになる。図３を用いて説明すると、該当の公開鍵証明証テーブル２１に「石田」のエントリが作成され、証明証１が登録される。ただし、既にＳＴ＝横浜の配下に「石田」のエントリが存在する場合は、この申請を却下する。
（６）公開鍵証明証追加ステップ
公開鍵証明証追加ステップでは、申請されたＤＮの最下端（一般名）が該当の公開鍵証明証テーブル２１に存在していることを確認し、該当のエントリに登録済の公開鍵証明証を用いて申請書に付与された電子署名を検証することにより、そのエントリに該当する利用者と同一の利用者であることを確認する。その後、申請書情報から公開鍵証明証を作成し、該当する公開鍵証明証管理テーブル２１内の該当ＤＮのエントリに公開鍵証明証を追加する。追加ステップを作成ステップと同様に、
Ｃ＝日本、Ｌ＝神奈川、ＳＴ＝横浜、ＣＮ＝石田
で説明すると、既にＣＮの「石田」は公開鍵証明証テーブル２１に存在しており、そのエントリには証明証１が存在していた場合に、この利用者が新たに違う公開鍵証明証（例えば、異なる暗号アルゴリズムで用いる公開鍵の登録等）を追加作成依頼した場合には、既に存在する証明証１を用いて同一利用者であることを確認した後、登録済の証明証１に続いて、証明証２を追加する。これにより利用者は公開鍵証明証を複数所持することが可能になる。図３を用いて説明すると、当該の公開鍵証明証テーブル２１に既に「石田」のエントリは存在しているため、証明証２を追加する形となる。追加申請において、申請されたＤＮの最下端（一般名）が該当の公開鍵証明証テーブル２１に存在していなかった場合には、この申請を却下する。
（７）公開鍵証明証削除ステップ
公開鍵証明証削除ステップでは、申請されたＤＮの最下端（一般名）が該当の公開鍵証明証テーブル２１に存在していることを確認し、該当のエントリに登録済の公開鍵証明証を用いて申請書に付与された電子署名を検証することにより、エントリに該当する利用者と同一の利用者であることを確認する。その後、申請された「通し番号」に該当する公開鍵証明証を削除する。ここで、その一般名の所持している証明証が全て削除された場合は、その一般名のエントリも削除されることになる。図３を用いて説明すると、該当の公開鍵証明証テーブル２１の該当エントリの証明証１、もしくは証明証２が削除される形となる。ここで、証明証１、２が両方とも削除されたとすると、「石田」自体のエントリも削除される。
【００１８】
上述においてＤＮチェックステップ３で全階層のＤＩＴ管理テーブル１５のエントリ名との一致が各１つずつとれると、振分ステップに移ったが、振分ステップに移る前に、そのＤＮの最下端と一致する一般名のエントリが該当の公開鍵証明証テーブル２１に在るか否かをチェックし、その後、振分ステップを実行し、その際、先の例における一般名のエントリの有無のチェックに省略する。また削除ステップでは申請書の内容に応じて、該当一般名に複数の証明証が登録されていても、その全ての証明証と一般名を削除し、つまりそのエントリを削除してもよい。更にＤＮの木構造ＤＩＴとしては、図１に示す例に限らず、例えば組織の上下関係を用いて構成してもよい。つまり、申請書に用いられるＤＮに応じた木構造を作成すればよい。
【００１９】
【発明の効果】
以上の説明から明らかになるように、この発明の方法及び記録媒体によると、公開鍵証明証の新規作成／追加／削除サービスをＤＮチェック処理と同時に実現し、かつこのサービスを実現するシステムを構築することが可能となる。
【図面の簡単な説明】
【図１】ＤＩＴ構造の例を示す図。
【図２】この発明の処理の流れを示す図。
【図３】この発明に用いるデータベースのテーブル構築例を示す図。
【図４】この発明方法の処理手順の例を示す図。
【図５】図４の結果を示す図。
【図１】
0003851939.tif 000002
【図２】
0003851939.tif 000003
【図３】
0003851939.tif 000004
【図４】
0003851939.tif 000005
【図５】
0003851939.tif 000006