JPH10322326A - 公開鍵証明証管理方法及びその記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 重複登録なく正当な処理を可能とする。 【解決手段】 申請書の名前（ＤＮ）を住所の広い地域
を上位階層、一般名を最下位階層とした木構造管理と
し、最下位階層及びその一段上位の階層を除く各階層ご
とに、そのエントリ名とその各テーブル名が登録された
管理テーブル１５を設け、最下位層から一段上位の各リ
ーフに一般名をエントリとし、その証明証を登録する証
明証テーブル２１を設ける。申請中のＤＮを各階層に分
解し、各部が対応テーブル１５の何れかにあるかをチェ
ックし、これに合格すると申請中の種別が作成なら、該
当テーブル２１に、ＤＮの最下端と一致する一般名がな
ければ、公開鍵証明証を作り、その一般名と証明証を該
当テーブル２１に登録し、種別が追加なら、ＤＮの最下
端と一致する一般名があれば、その既登録の証明証を用
いて、申請の署名を検証し、合格なら、証明証を新たに
作り、追加登録し、種別が削除なら、ＤＮの最下端が該
当テーブル２１の一般名にあれば、その証明証で申請中
の署名を検証し、合格すれば該当、一般名と証明証を削
除する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、コンピュータネ
ットワーク上でＥＤＩ（電子データ交換）やＥＣ（電子
商取引）などを実現する際に、送信データの秘匿性や改
ざん防止の目的で利用される認証システム（Ｃｅｒｔｉ
ｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ：以下ＣＡと記
す）の構成方法、特に公開鍵暗号方式にもとづく、その
公開鍵証明証を発行／管理する機関における管理方法及
びその方法のプログラムを記録した記録媒体に関するも
のである。

【０００２】

【従来の技術】コンピュータネットワーク上でＥＤＩ
（電子データ交換）やＥＣ（電子商取引）を実現する際
には、盗聴／なりすまし／改ざん／送信否認などの脅威
が想定されるため、それを防御するために暗号通信やデ
ィジタル署名通信が用いられるのが一般的である。この
暗号通信、及びディジタル署名通信を行う有力な方法と
して、公開鍵暗号方式がある。この方式は、参考文献
「Ｄｉｆｆｉｅ，Ｗ．ａｎｄＨｅｌｍａｎ，Ｍ．：Ｎｅ
ｗ Ｄｉｒｅｃｔｉｏｎ ｉｎ Ｃｒｙｐｔｏｇｒａｐ
ｈｙ，ＩＥＥＥ Ｔｒａｎｓ．Ｉｎｆ．Ｔｈｅｏｒｙ，
ＩＴ−２２，６ｐｐ．６４４−６５４，１９７６」で発
表されており、世の中で広く知られているところとなっ
ている。この公開鍵暗号方式では、鍵の持ち主を証明す
る第三者機関が必要であり、それがＣＡ（Ｃｅｒｔｉｆ
ｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ）と呼ばれている
ものである。ＣＡは、日本の実社会で、実印の持主を証
明する印鑑証明書を役所が発行するのと同様に、ディジ
タル通信の世界において、暗号化鍵の持ち主を証明する
公開鍵証明証を発行する機能を持ったシステムであると
いうことができる。

【０００３】一般的に知られているＣＡの機能は、次の
通りである。 ・公開鍵登録機能…利用者が申請した公開鍵に対して、
公開鍵証明証を作成／登録／発行する。 ・証明証参照機能…ＣＡで管理している公開鍵証明証を
利用者から参照可能とする。 ・公開鍵無効化機能…公開鍵証明証を無効化し、無効化
リストに掲載する。 ・無効化リスト参照機能…無効化された公開鍵証明証の
一覧を利用者から参照可能とする。

【０００４】これらの機能は、コンピュータシステムや
暗号アルゴリズムが提供する一般的な手段を用いて構築
可能であり、申請時に申請書を用いた依頼を行うこと、
ＣＡと利用者の間ではディジタル署名通信を行うこと、
公開鍵証明証や無効化リストはディレクトリやデータベ
ースに管理しておくこと、など基本的な構成方式につい
ては、一般的方法であると認知されている。さて、ＣＡ
を構築する際にはディレクトリの概念（Ｘ．５００、Ｉ
ＳＯ／ＩＥＣ／ＤＩＳ ９５９４−１）が広く利用され
ている。従って、ＣＡで管理する公開鍵証明証等もそれ
に準拠した形式が採用されることが想定される。公開鍵
証明証内に記述される「名前」もＸ．５００勧告で規定
された形式で広く用いられている。「名前」は１文字列
で指定するのではなく、いくつかの階層（以降、エント
リとする）名称を並べた形式であり、それが名前、いわ
ゆるＤＮ（Ｄｉｓｔｉｎｉｇｕｉｓｈｅｄ Ｎａｍｅ）
となる。これらＤＮは、ＣＡ内でＸ．５００勧告の木構
造、いわゆるＤＩＴ（Ｄｉｒｅｃｔｏｒｙ Ｉｎｆｏｒ
ｍａｔｉｏｎ Ｔｒｅｅ）で管理されるのが一般であ
る。ここでＤＮとＤＩＴに関して例をあげて説明する
と、図１で「日本」が木構造の最上位となり、その下に
枝わかれしていく。これをＤＩＴ構造という。また、Ｄ
ＩＴは各エントリ、「神奈川」、「横浜」等の階層で構
成され、その最下端が個人となる一般名で示される。こ
のＤＩＴ構造で「鈴木」をＤＮで示すと、Ｃ＝日本、Ｌ
＝神奈川、ＳＴ＝横浜、ＣＮ＝鈴木と最上位からの階層
で示される。ここで、Ｃは国名、Ｌは地方名、ＳＴは地
域名、ＣＮは一般名である。ただし、このＤＩＴには構
造の規定は無く、ＣやＬ等のエントリの属性付与基準だ
けがあるのが現状である。通常ディレクトリの概念で
は、エントリの生成、追加、削除の要求があった場合は
それらの処理を行うが、それをＣＡとして確立する場
合、そのＤＮの内容と関係をＤＩＴ管理テーブル内に登
録されているかを確認し、許可していないＤＮに対する
処理を行わないような機構が必要となる。これら、Ｘ．
５００に準拠したシステムを構築することは、コンピュ
ータシステムの応用範囲として一般的に存在するものと
捉えることができる。しかし、その効率的な実現方法に
ついては技術的な仕組みが必要になるため、色々な方法
が考えられるところである。この発明も、その実現方法
の１つとして提案するもので、許可されていないＤＮを
確認することに着目した管理方法を示したものである。

【０００５】一般的なＣＡでは、公開鍵証明証を作成す
る場合、利用者が申請書内に自分のＤＮを記述し、これ
を受け付けたＣＡは、申請者の指定したＤＮに基づいて
公開鍵証明証を作成する。また一度公開鍵証明証の登録
を行った利用者が、さらに別の公開鍵に対する証明証の
発行を依頼、つまり登録する公開鍵の追加を行う場合に
は、新規登録時と同様に証明証の作成を行う。さらに削
除処理では、指定されたＤＮ等に該当する公開鍵証明証
を削除する。これら処理を行う時のキーとなるのはＤＮ
である。このような構成方式においては、申請書内のＤ
Ｎのエントリ付与基準や、＝（イコール）で区切られて
いる等の書式に関しての確認は行われている。

【０００６】

【発明が解決しようとする課題】前述したように一般的
なＣＡにおいては、ＤＮの書式を確認するのみで各エン
トリの内容や、関係に関しては触れずに、利用者の指定
したＤＮにしたがって証明証を作成するため、許可され
ていないＤＮや、利用者の入力ミス等によるＤＮを申請
書に記述して登録申請された場合には、いたずらに様々
な名称を持ったエントリが増加したり、意味を持たない
ＤＮを持った公開鍵証明証が増加するおそれがある。し
たがって、ＣＡが許可するＤＮのエントリ名称や属性、
関係をすべて管理し、いかに少ない情報でチェックでき
るか、同時に公開鍵証明証をいかに容易に管理できるか
がこの発明の目的である。

【０００７】

【課題を解決するための手段】この発明は、許可するＤ
Ｎの最下端より一階層上位までのエントリ名称を全てＤ
ＩＴ管理テーブルで登録、管理し、申請があった際の確
認対象とする。ＤＮの最下端のエントリは、管理テーブ
ルとは別に個々の公開鍵証明証テーブルで管理し、一般
名（ＣＮ名称）をキーとして、かつその一般名に対する
公開鍵証明証を格納する。それ以外は各階層毎のＤＮ管
理テーブルでその階のエントリ名と、下位階層の管理テ
ーブルの指定を管理する。

【０００８】この発明の管理方法はこれを実行する機能
としてはＤＩＴ管理テーブルへの検索手段、公開鍵
証明証の作成手段、公開鍵証明証の追加手段、公開
鍵証明証の削除手段、及びこれらの機能を呼び出す処理
によって構成される。なお、この管理方法の実行の前提
とし、ＤＩＴ管理テーブル作成手段、エントリ名称
登録手段、により管理テーブル、公開鍵証明証テーブル
の作成が予めなされる。

【０００９】これらテーブルの作成から、この発明方法
の実行は例えば図２に示すようにこれらの手段を用いて
処理される。 （１）システム初期生成処理において、許可するＤＮの
エントリ名称（階層）分だけＤＩＴ管理テーブル作成手
段を用いてデータベースのテーブルを生成する。 （２）エントリ名称登録処理において、ＣＡが許可する
中間階層のエントリ名称をエントリ登録手段を用いて登
録する。 （３）ＤＮチェックステップにおいて、利用者からの申
請書情報に含まれているＤＮ情報を取り出し、階層毎に
分割し、ＤＩＴ管理テーブルへの検索手段を用いて上位
層から最下端より一階層上位までのＤＮが許可されてい
るか否かの確認を行う。 （４）サービス振分けステップにおいて、利用者からの
申請書に含まれる「処理種別」情報により、公開鍵証明
証作成ステップ、公開鍵証明証追加ステップ、公開鍵証
明証削除ステップの何れかに振分ける。 （５）公開鍵証明証作成ステップにおいて、申請された
ＤＮの最下端（一般名）が該当の公開鍵証明証テーブル
に存在していないことを確認した後、このテーブルにエ
ントリ（その一般名）を作成する。そして、申請書情報
から公開鍵証明証を作成し、該当の公開鍵証明証管理テ
ーブルの該当のエントリにこの公開鍵証明証を登録す
る。またここですでに一般名が登録されている場合に
は、この申請は却下される。 （６）公開鍵証明証追加ステップにおいて、申請された
ＤＮの最下端（一般名）が該当の公開鍵証明証テーブル
に存在していることを確認し、該当のエントリに登録済
の公開鍵証明証を用いて申請書に付与された電子署名を
検証することにより、エントリに該当する利用者と同一
の利用者であることを確認する。その後、申請書情報か
ら公開鍵証明証を作成し、該当する公開鍵証明証管理テ
ーブル内の該当ＤＮの一般名に作成した公開鍵証明証を
追加する。 （７）公開鍵証明証削除ステップにおいて、申請された
ＤＮの最下端（一般名）が該当の公開鍵証明証テーブル
に存在していることを確認し、該当のエントリに登録済
の公開鍵証明証を用いて申請書に付与された電子署名を
検証することにより、エントリに該当する利用者と同一
の利用者であることを確認する。その後、該当公開鍵証
明証を削除する。また、ここで、その一般名の所持して
いる証明証が全て削除された場合は、その一般名（エン
トリ）も削除される。

【００１０】図２において例えば、システム初期生成ス
テップにはＤＩＴ管理テーブルの作成以外にもいろいろ
な初期化ステップが存在するため、左右方向の矢印はそ
の処理が一部として、図中の手段を呼び出すことを意味
している。この発明の方法によれば、利用者からの申請
書情報に含まれるＤＮ情報の正当性のチェックを行うこ
とが可能になり、同時に許可するエントリの重複登録な
く、公開鍵証明証を管理するシステムを構築することが
できる。

【００１１】

【発明の実施の形態】この発明の実施例を以下に説明す
る。この発明では申請書中の名前（ＤＮ）を木構造で管
理し、その木構造の最下位階層を除く、各階層ごとにＤ
Ｎ管理テーブルを作り、最下位階層から一段上位の各リ
ーフに公開鍵証明証テーブルを作る。これらの具体例を
図３に示す。この図３は図１に示したＤＮの木構造を例
としたものである。

【００１２】まず、最上位の「日本」は固定であり、日
本の配下にくるエントリを検索するために、テーブル名
称１４が「日本．ｔｂｌ」のＤＩＴ管理テーブル１５を
参照する。各ＤＩＴ管理テーブル１５には、そのテーブ
ル名称の欄１４、エントリ名が記録される欄１６、その
属性が記録される欄１７、その下位に位置することがで
きる属性が記録される欄１８、その下位属性、つまり下
位の階層をエントリとするＤＮ管理テーブルの名称が記
録される欄１９が設けられている。「日本．ｔｂｌ」の
管理テーブルにはエントリ名欄１６に「東京」、「神奈
川」が登録されているため、「日本」の配下には「東
京」と「神奈川」のみの指定が可能となる。また「神奈
川」の属性は「Ｌ」であり、その配下に位置できるエン
トリ（階層）属性は「ＳＴ」となる。同じようにテーブ
ル名称が「神奈川．ｔｂｌ」のＤＮ管理テーブル、つま
り「神奈川」の配下に登録されているエントリ名称は
「横浜」であり、属性は「ＳＴ」である。

【００１３】これらＤＩＴ管理テーブル１５とは別に設
ける「公開鍵証明証テーブル」２１は最下端の階層であ
る利用者の一般名と公開鍵証明証そのものを管理する。
つまり各地域（木構造のリーフ）の下に個々の公開鍵証
明証テーブル２１が存在する。公開鍵証明証テーブル２
１は、テーブル名称の欄２２、エントリされる一般名が
記録される欄２３、公開鍵証明証などのデータが記録さ
れる欄２４がそれぞれ設けられている。このような公開
鍵証明証テーブル２１を設けるのは登録者が増えた場合
の検索範囲を狭める効果と同姓同名でも地域が違えば登
録が可能であることを示している。また、最下端とそれ
以外の階層の管理を分けた理由については、利用者が追
加／削除できる階層とできない階層にわけていることに
ある。図１のＤＩＴで説明すると、ＣＡが申請書に記述
されたＤＮとＣＡ内で管理するＤＮ管理テーブル１５と
で比較確認する階層は、 Ｃ＝日本、Ｌ＝神奈川、ＳＴ＝横浜、 Ｃ＝日本、Ｌ＝東京、ＳＴ＝港区、など であり、「鈴木」、「高橋」といった最下端の一般名に
ついては該当の公開鍵証明証テーブル２１によって管理
される。もしその一般名が該当の公開鍵証明証テーブル
に存在しない場合で、それが利用者からの公開鍵証明証
の新規登録であった場合には、当然「公開鍵証明証テー
ブル」２１にそのエントリを追加する。逆に一般名が該
当の公開鍵証明証テーブル２１に存在していた場合に
は、利用者からの公開鍵証明証の新規登録の受付を拒否
し、同一利用者による公開鍵証明証の追加登録に限って
この申請を受け付け、該当のエントリに公開鍵証明証を
追加登録することにする。これによって、違う利用者が
同一のＤＮを持つといったＤＮの重複を防ぐことが可能
になる。ここで、同一利用者であるか否かを確認する手
法としては、利用者が追加登録をする際の申請書に、す
でに登録済の公開鍵によって検証可能な電子署名を付与
してもらい、ＣＡは、公開鍵証明証テーブル２１の該当
のエントリに既に登録されている公開鍵証明証を用いて
申請書に付与された電子署名を検証し、これが正常に完
了したことを確認することにより、該当のエントリを持
つ利用者と同一の利用者による追加登録申請であること
を確認する。このことは、登録した利用者のみが、その
登録済の公開鍵によって検証可能な電子署名を付与する
ことが可能であるということを利用しているものであ
る。またこの同一利用者であるか否かの確認は、公開鍵
証明証の削除処理においても行われる。これは、同じＤ
Ｎを名乗る異なる利用者が、該当のエントリに登録され
た公開鍵証明証を、勝手に削除することがないようにす
るためである。

【００１４】以上のように、最下端のエントリ名称につ
いては、該当の公開鍵証明証テーブル２１に存在しない
場合に限ってエントリとして追加することを可能とし、
最下端より上位の階層のエントリについては、データベ
ースのアクセス制御により利用者からの問い合わせに対
しては「読込み」だけで「書き込み不可」とし、勝手に
中間のエントリを追加することができないようにする。
従って、利用者からの申請書で例えば、図１の状況にお
いて Ｃ＝日本、Ｌ＝神奈川、ＳＴ＝横須賀、ＣＮ＝・・・ のようなＤＮで申請された場合は、名称が「神奈川．ｔ
ｂｌ」のＤＮ管理テーブル１５内に「横須賀」が登録さ
れていないため、その申請書に対する要求は却下され、
処理を打ち切ることになる。

【００１５】以上のように、ＤＮ管理テーブル１５と公
開鍵証明証テーブル２１によってＤＮを管理することに
より、悪意のあるアクセスや、利用者のＤＮの指定ミス
に対してその確認が可能になると同時に、新規利用者の
エントリの追加、新規利用者のエントリの重複登録の防
止などが可能となる。次に図３に示したＤＮ管理テーブ
ル１５と公開鍵証明証テーブル２１を設けて、公開鍵証
明証の管理を行うこの発明の具体的な実施例を図４及び
図５を用いて説明する。

【００１６】まずこの発明方法を実行する前提である各
テーブルの作成手順を説明する。 （１）システム初期生成ステップ ＣＡの初期生成処理では、各種の初期生成処理を行う
が、その処理の一部としてＤＩＴ管理テーブル作成手段
８を呼び出す。ＣＡで許可するＤＩＴの階層分だけデー
タベースのＤＩＴ管理テーブル１５の群を生成する。 （２）エントリ名称登録ステップ ＣＡで許可するエントリ名称をエントリ登録手段９を用
いて対応する階層のＤＩＴ管理テーブル１５に登録す
る。ただし、これに関しては既にコンピュータシステム
で一般的に提供されているデータベースへのデータの登
録などの機能を用いればよく、この発明で特に新しいも
のではない。また、登録するエントリ名称はＤＩＴの中
間階層にあたるもののみであり、公開鍵証明証テーブル
２１には登録を行わない。

【００１７】通常、このエントリ名称の登録は、初期生
成時に１度行う処理であり、次にＤＩＴ構造の変更が無
い限りはエントリ登録処理は行なわなくてよい。 （３）ＤＮチェックステップ ＤＮチェックステップでは、ＤＩＴ管理テーブル検索手
段１０を呼び出し、利用者から送られてくる申請書内の
情報に含まれるＤＮ情報を取り出し、エントリ毎に分解
し、最下端エントリより一階層上位のエントリ名称まで
について、これが各ＤＩＴ管理テーブル１５内に存在す
るかを繰り返し検索する。最下端のエントリ名称は確認
の対象にはならない。仮に申請書情報のＤＮが Ｃ＝日本、Ｌ＝神奈川、ＳＴ＝横浜、ＣＮ＝石田 とすると、Ｃ＝日本、Ｌ＝神奈川、ＳＴ＝横浜までをＤ
ＩＴ管理テーブル１５で検索して許可されていることを
確認し、ＣＮ＝石田は確認対象ではない。 （４）サービス振分けステップ サービス振分けステップは、ＤＮチェックステップでＤ
Ｎの正当性が確認された後、申請書情報の一部であるサ
ービス（処理）種別情報、いわゆる利用者からの問い合
わせ種別を判別して、公開鍵証明証作成ステップ、公開
鍵証明証追加ステップ、公開鍵証明証削除ステップの何
れかのステップに振分けを行う処理である。 （５）公開鍵証明証作成ステップ 公開鍵証明証作成ステップでは、公開鍵証明証作成手段
１１を呼び出す。ここでは利用者から申請されたＤＮの
最下端（一般名）が該当の公開鍵証明証テーブル２１に
存在していないことを確認した後、このテーブルにエン
トリを作成する。そして申請書情報をもとに公開鍵証明
証を作成し、該当の公開鍵証明証テーブル２１内の該当
のエントリに新規に登録する。公開鍵証明証の作成依頼
の際の利用者のＤＮを Ｃ＝日本、Ｌ＝神奈川、ＳＴ＝横浜、ＣＮ＝石田 で説明すると、公開鍵証明証テーブル２１に「石田」の
エントリ名称と公開鍵証明証が追加されることになる。
図３を用いて説明すると、該当の公開鍵証明証テーブル
２１に「石田」のエントリが作成され、証明証１が登録
される。ただし、既にＳＴ＝横浜の配下に「石田」のエ
ントリが存在する場合は、この申請を却下する。 （６）公開鍵証明証追加ステップ 公開鍵証明証追加ステップでは、申請されたＤＮの最下
端（一般名）が該当の公開鍵証明証テーブル２１に存在
していることを確認し、該当のエントリに登録済の公開
鍵証明証を用いて申請書に付与された電子署名を検証す
ることにより、そのエントリに該当する利用者と同一の
利用者であることを確認する。その後、申請書情報から
公開鍵証明証を作成し、該当する公開鍵証明証管理テー
ブル２１内の該当ＤＮのエントリに公開鍵証明証を追加
する。追加ステップを作成ステップと同様に、 Ｃ＝日本、Ｌ＝神奈川、ＳＴ＝横浜、ＣＮ＝石田 で説明すると、既にＣＮの「石田」は公開鍵証明証テー
ブル２１に存在しており、そのエントリには証明証１が
存在していた場合に、この利用者が新たに違う公開鍵証
明証（例えば、異なる暗号アルゴリズムで用いる公開鍵
の登録等）を追加作成依頼した場合には、既に存在する
証明証１を用いて同一利用者であることを確認した後、
登録済の証明証１に続いて、証明証２を追加する。これ
により利用者は公開鍵証明証を複数所持することが可能
になる。図３を用いて説明すると、当該の公開鍵証明証
テーブル２１に既に「石田」のエントリは存在している
ため、証明証２を追加する形となる。追加申請におい
て、申請されたＤＮの最下端（一般名）が該当の公開鍵
証明証テーブル２１に存在していなかった場合には、こ
の申請を却下する。 （７）公開鍵証明証削除ステップ 公開鍵証明証削除ステップでは、申請されたＤＮの最下
端（一般名）が該当の公開鍵証明証テーブル２１に存在
していることを確認し、該当のエントリに登録済の公開
鍵証明証を用いて申請書に付与された電子署名を検証す
ることにより、エントリに該当する利用者と同一の利用
者であることを確認する。その後、申請された「通し番
号」に該当する公開鍵証明証を削除する。ここで、その
一般名の所持している証明証が全て削除された場合は、
その一般名のエントリも削除されることになる。図３を
用いて説明すると、該当の公開鍵証明証テーブル２１の
該当エントリの証明証１、もしくは証明証２が削除され
る形となる。ここで、証明証１、２が両方とも削除され
たとすると、「石田」自体のエントリも削除される。

【００１８】上述においてＤＮチェックステップ３で全
階層のＤＩＴ管理テーブル１５のエントリ名との一致が
各１つずつとれると、振分ステップに移ったが、振分ス
テップに移る前に、そのＤＮの最下端と一致する一般名
のエントリが該当の公開鍵証明証テーブル２１に在るか
否かをチェックし、その後、振分ステップを実行し、そ
の際、先の例における一般名のエントリの有無のチェッ
クに省略する。また削除ステップでは申請書の内容に応
じて、該当一般名に複数の証明証が登録されていても、
その全ての証明証と一般名を削除し、つまりそのエント
リを削除してもよい。更にＤＮの木構造ＤＩＴとして
は、図１に示す例に限らず、例えば組織の上下関係を用
いて構成してもよい。つまり、申請書に用いられるＤＮ
に応じた木構造を作成すればよい。

【００１９】

【発明の効果】以上の説明から明らかになるように、こ
の発明の方法及び記録媒体によると、公開鍵証明証の新
規作成／追加／削除サービスをＤＮチェック処理と同時
に実現し、かつこのサービスを実現するシステムを構築
することが可能となる。

【図面の簡単な説明】

【図１】ＤＩＴ構造の例を示す図。

【図２】この発明の処理の流れを示す図。

【図３】この発明に用いるデータベースのテーブル構築
例を示す図。

【図４】この発明方法の処理手順の例を示す図。

【図５】図４の結果を示す図。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 小川 貴志 神奈川県横浜市中区山下町223番１ エ ヌ・ティ・ティ・ソフトウェア株式会社内

Claims (9)

【特許請求の範囲】
1. 【請求項１】 公開鍵証明証に記述される名前を、その
   一般名を最下位階層とした木構造で管理し、利用者から
   の申請に応じて公開鍵証明証の作成、追加、削除、確認
   などの管理を行う方法において、 上記木構造の最下位階層及びその一段上位階層（リー
   フ）を除く、各階層ごとにＤＩＴ管理テーブルを設け、 各ＤＩＴ管理テーブルにはそれぞれその各エントリ名
   と、その下位階層をエントリとする管理テーブル名を設
   け、 上記木構造の最下位階層から一段上位の各リーフごとに
   公開鍵証明証テーブルを設け、 各公開鍵証明証テーブルにはその各一般名の欄とその公
   開鍵証明証の欄とを設けたことを特徴とする公開鍵証明
   証管理方法。
2. 【請求項２】 上記各ＤＩＴ管理テーブルは読み出しの
   みを可能とし、上記各公開鍵証明証テーブルは読み出し
   と書き込みと消去を可能としたことを特徴とする請求項
   １記載の公開鍵証明証管理方法。
3. 【請求項３】 上記申請中の名前を上記木構造の階層ご
   とに分解し、その分解した名前の各部が対応する上記Ｄ
   ＩＴ管理テーブルのエントリ名に存在するかを調べるＤ
   Ｎチェックステップと、 上記ＤＮチェックステップに全てのチェックが合格であ
   れば上記申請中の名前の最下端がこれと対応する上記公
   開鍵証明証テーブルの一般名に存在するか否かを調べる
   ＣＮチェックステップと、 上記ＣＮチェックステップで一般名が存在せず、かつ上
   記申請中の処理種別が作成であれば公開鍵証明証を作成
   し、上記申請中の名前の最下端から一段上位のエントリ
   名と対応する上記公開鍵証明証テーブルに、上記申請中
   の名前の一般名と、上記作成した公開鍵証明証とを新た
   に書込む作成ステップとを有することを特徴とする請求
   項２記載の公開鍵証明証管理方法。
4. 【請求項４】 上記ＣＮチェックステップで一般名が存
   在し、かつ上記申請中の処理種別が削除であれば、上記
   申請中の名前の最下端から一段上位のエントリ名と対応
   する上記公開鍵証明証テーブル中の上記対応する一般名
   に対する証明証を削除する削除ステップとを有すること
   を特徴とする請求項３記載の公開鍵証明証管理方法。
5. 【請求項５】 上記ＣＮチェックステップで一般名が存
   在し、かつ上記申請中の処理種別が削除であれば上記申
   請中の名前の最下端から一段上位のエントリ名と対応す
   る上記公開鍵証明証テーブル中の上記対応する一般名及
   びその証明証を削除する削除ステップとを有することを
   特徴とする請求項３記載の公開鍵証明証管理方法。
6. 【請求項６】 上記ＣＮチェックステップで一般名が存
   在し、かつ上記申請中の処理種別が追加であれば公開鍵
   証明証を新たに作成し、上記申請中の名前の最下端から
   一段上位のエントリ名と対応する上記公開鍵証明証テー
   ブルの、上記申請中の名前の最下端と一致した一般名に
   対し、上記新たに作成した公開鍵証明証を追加すること
   を特徴とする請求項４記載の公開鍵証明証管理方法。
7. 【請求項７】 上記ＣＮチェックステップで一般名が存
   在していると、その一般名と対応する登録済の公開鍵証
   明証を用いて、上記申請に付けられた電子署名を検証
   し、その検証に合格すると、その後の処理に移ることを
   特徴とする請求項４〜６の何れかに記載の公開鍵証明証
   管理方法。
8. 【請求項８】 公開鍵証明証に記載される名前を、その
   一般名を最下位階層とした木構造で管理し、その木構造
   の最下位層及びその一段上位階層を除く各階層ごとに、
   その各エントリ名と、その下位階層のエントリに対応す
   る各管理テーブル名とを有するＤＩＴ管理テーブルを設
   け、最下位階層から一段上位の各リーフごとに、その一
   般名の欄と公開鍵証明証の欄を有する公開鍵証明証テー
   ブルとを設け、 利用者からの申請に応じて公開鍵証明証の作成、追加、
   削除、確認などの管理をコンピュータにより行うプログ
   ラムを記録した記録媒体であって、 上記ＤＩＴ管理テーブルに対しては読み出しのみ可能と
   し、上記公開鍵証明証テーブルに対しては読み出しと、
   書き込み、削除とを可能とし、 上記申請中の名前を上記木構造の階層ごとに分解し、そ
   の分解された名前の各部が対応する上記ＤＮ管理テーブ
   ルのエントリ名に存在するかを調べるＤＮチェックステ
   ップと、 上記ＤＮチェックステップで全てのチェックに合格する
   と、上記申請中の処理種別が作成か、削除か追加かを判
   定する振分けステップと、 上記振分けステップで作成と判定されると、上記申請中
   の名前の最下端がその一段上位のエントリ名と対応する
   上記公開鍵証明証テーブルの一般名に在るか否かを調
   べ、なければ公開鍵証明証を作成し、上記公開鍵証明証
   テーブルに、その最下端の一般名と、上記作成した公開
   鍵証明証を書き込む作成ステップと、 上記振分けステップで削除と判定されると、上記申請中
   の名前の最下端が、その一段上位のエントリ名と対応す
   る上記公開鍵証明証テーブルの一般名に在るか否かを調
   べ、在れば上記公開鍵証明証テーブルの少くともその一
   般名に対する公開鍵証明証を消去する削除ステップと、 上記振分けステップで追加と判定されると、上記申請中
   の名前の最下端が、その一段上位のエントリ名と対応す
   る上記公開鍵証明証テーブルの一般名に在るか否かを調
   べ、在れば、新たに公開鍵証明証を作成し、上記公開鍵
   証明証テーブルに、その最下端の一般名の証明証欄に上
   記新たに作成した公開鍵証明証を追加する追加ステップ
   とを上記プログラムが有するコンピュータにより読み出
   し可能な記録媒体。
9. 【請求項９】 上記削除ステップ及び上記追加ステップ
   は、上記一般名が在れば、その一般名と対応する登録済
   の公開鍵証明証を用いて、上記申請に付けられた電子署
   名を検証し、その検証に合格すると、その後の処理に移
   るステップを含むことを特徴とする請求項８記載の記録
   媒体。