説明

属性証明書処理装置及びそのプログラム

【課題】グループツリーの改変時等に、従来方式よりも属性証明書(AC)の更新枚数を減らすことができる属性証明書処理装置を提供する。
【解決手段】有効な各属性証明書を特定する情報を保持する有効証明書保持DB44と、すべての属性証明書に対して有効なグループツリーを保持する有効グループツリー保持DB45と、属性証明書毎に有効なグループツリーを保持する有効グループツリー保持DB(証明書毎)43と、それらに保持されている情報とに基づいて、クライアント3からの属性証明書に関する検証要求を受け付けて検証処理を行う検証受付モジュール41とを設けている。

【発明の詳細な説明】
【技術分野】
【0001】
この発明は、公開鍵基盤等の暗号化、電子署名等に係る技術においてユーザの権限を証明する属性証明書の発行や検証を行う際に用いて好適な属性証明書処理装置及びそのプログラムに関する。
【背景技術】
【0002】
属性証明書(AC(Attribute Certificate))に記述されているグループ情報は、ASN.1(Abstract Syntax Notation One)のDirectory Name(ディレクトリネーム)形式で記述されていることが一般的である。すなわち、グループ情報は、通常、複数のグループ間のつながりを示すグループ識別情報のシーケンスによって記述されている。また、異なる記述形式を利用している場合でも、あるユーザが属するグループは、グループツリーを全て記述し、一意に判断可能な形式で記述されている。
【0003】
また、属性証明書(AC)の検証時間を短縮させる技術として特許文献1のような手法が提案されている。特許文献1に記載されている属性証明書の検証方法は、限られたリソースを持つクライアントでの属性証明書(AC)検証時間の短縮を目標とし、通常クライアントが行う属性証明書(AC)の検証処理を検証局という第三者に依頼している。しかし、検証局内で行う処理は、通常の処理とあまり変わりがない。そのため、高いリソースを持つクライアントを利用する場合には、自分で属性証明書(AC)を検証するのに比べて、検証時間を大幅に短縮することはできない。
【特許文献1】特開2003−348077号公報
【発明の開示】
【発明が解決しようとする課題】
【0004】
上述したように属性証明書においては一般的にユーザのグループがDirectoryName形式により一意に決定されるように定義されている。そのため、グループツリー中の節部分に該当するグループが削除された場合や、節と節の間にグループが追加された場合など、グループツリーの上位にて変更が行われた場合には、その節に紐付いている属性証明書(AC)を全て更新する必要がある。よって、グループの改変が多く行われるシステムでは、1回のグループ改変における更新枚数が非常に多くなってしまうという問題がある。
【0005】
この発明は、上記の事情に鑑みてなされたものであり、グループツリーの改変時等に、従来方式よりも属性証明書(AC)の更新枚数を減らすことができる属性証明書処理装置及びそのプログラムを提供することを目的とする。
【0006】
この発明は、また、属性証明書の検証処理の際に、より短い時間で検証結果を取得することが可能となる属性証明書処理装置及びそのプログラムを提供することを目的とする。
【課題を解決するための手段】
【0007】
上記課題を解決するため、請求項1記載の発明は、有効な各属性証明書を特定する情報を保持する有効証明書保持手段と、すべての属性証明書に対して有効なグループツリーを保持する有効グループツリー保持手段と、有効グループツリー保持手段が保持するグループツリーに基づいて構成された属性証明書毎に有効なグループツリーを保持する証明書毎有効グループツリー保持手段と、前記有効証明書保持手段に保持されている情報と前記証明書毎有効グループツリー保持手段に保持されている情報とに基づいて、利用者からの属性証明書に関する検証要求を受け付けて検証処理を行う検証手段とを備えることを特徴とする。
【0008】
請求項2記載の発明は、前記属性証明書に記述されているグループ情報が、当該属性証明書の所有者が属するグループを示す情報とそのグループの親のグループを示す情報とから構成されていることを特徴とする。
【0009】
請求項3記載の発明は、前記検証手段が、検証処理を要求された属性証明書が前記有効証明書保持手段に存在するか否かを判定し、存在する場合に前記証明書毎有効グループツリー保持手段に保持されている当該属性証明書に対応する情報を取得して利用者に送付するものであることを特徴とする。
【0010】
請求項4記載の発明は、各属性証明書を事前に検証し、前記有効証明書保持手段の保持情報及び前記有効グループツリー保持手段の保持情報を更新する事前検証手段をさらに備えることを特徴とする。
【0011】
請求項5記載の発明は、有効な各属性証明書を特定する情報を保持する有効証明書保持手段と、すべての属性証明書に対して有効なグループツリーを保持する有効グループツリー保持手段と、有効グループツリー保持手段が保持するグループツリーに基づいて構成された属性証明書毎に有効なグループツリーを保持する証明書毎有効グループツリー保持手段とを用いて、前記有効証明書保持手段に保持されている情報と前記証明書毎有効グループツリー保持手段に保持されている情報とに基づいて、利用者からの属性証明書に関する検証要求を受け付けて行う検証処理をコンピュータによって実行するための記述を含むことを特徴とする。
【発明の効果】
【0012】
この発明によれば、有効証明書保持手段に保持されている情報と証明書毎有効グループツリー保持手段に保持されている情報とに基づいて、利用者からの属性証明書に関する検証要求を受け付けて検証処理を行うようにしたので、属性証明書に記述されているグループ情報を当該属性証明書の所有者が属するグループを示す情報とそのグループの親のグループを示す情報とから構成することが可能となり、したがって、グループツリーの改変時等に、変更対象となる属性証明書がその改変に直接関係する親グループ又は子のグループの記述からなるグループ情報を含むもののみに限定されることになるので、従来方式よりも属性証明書の更新枚数を減らすことが可能となる。
【0013】
また、事前検証手段を備えることで、複数枚の属性証明書を用いた検証処理をより短い時間で行うことが可能となる。
【発明を実施するための最良の形態】
【0014】
以下、図面を参照してこの発明による属性証明書処理装置の実施の形態について説明する。図1は、本実施の形態の構成及び情報の流れを示すシステム図である。本実施の形態は、図示していないネットワーク(通信網あるいは通信回線)を介して接続されている認証局1、属性認証局2、クライアント3及び属性証明書検証機関4から構成されている。ただし、図1では、認証局1、属性認証局2、クライアント3及び属性証明書検証機関4を各一つのみ示しているが、各構成は複数であってもよい。また、各構成は、1又は複数台のコンピュータ及びその周辺装置と、そのコンピュータ上で実行されるプログラムとによって実現することができる。
【0015】
認証局1は、CA(Certificate uthority)と呼ばれるものであり、電子的な身分証明書を発行し、その管理を行う。本実施の形態において認証局1は、PKI(Public Key Infrastructure:公開鍵基盤)による公開鍵証明書の発行、管理を行う。認証局1には、公開鍵証明書等を表す公開情報を格納するデータベースであるリポジトリ11が設けられている。このリポジトリ11は、発行済証明書管理DB(データベース)12と、無効証明書管理DB(データベース)13とから構成されている。発行済証明書管理DB12は、発行済み公開鍵証明書を管理するためのデータベースであり、無効証明書管理DB13は、発行した公開鍵証明書の中で無効となった公開鍵証明書を管理するためのデータベースである。
【0016】
クライアント3は、認証局1、属性認証局2、又は属性証明書検証機関4に対して、各種処理の実行を要求する端末である。
【0017】
属性認証局2は、AA(Attribute Authority)と呼ばれるものであり、利用者(ユーザ)の属性を証明するための属性証明書(AC)を発行、管理する。属性認証局2は、属性証明書発行モジュール21と、リポジトリ22とから構成されている。属性証明書発行モジュール21は、属性証明書発行処理を行うためのプログラムである。リポジトリ22は、属性証明書等の公開情報を格納するデータベースであり、発行済属性証明書管理DB23と、無効属性証明書管理DB24とから構成されている。発行済属性証明書管理DB23は、発行済み属性証明書を管理するためのデータベースである。無効属性証明書管理DB24は、無効となった属性証明書を管理するためのデータベースであり、無効となった属性証明書(AC)を格納するリストをACRL(Attribute Certificate Revocation List:属性証明書失効リスト)として保持している。
【0018】
属性認証局2によって発行される属性証明書には、その属性証明書の所有者が属するグループにおけるその所有者の権限に関する属性を表す情報、その属性証明書の内容を検証する際に使用される公開鍵証明書を示す情報のほか、そのグループの親グループの情報を示すグループ情報が記述されている。本実施の形態においては、グループ情報が、「所有者のグループ情報」と「所有者の親グループの情報」の2つの要素のみから構成されている。「所有者のグループ情報」は、当該属性証明書の所有者が属するグループを表す情報であり、「所有者の親グループの情報」は当該所有者が属するグループが属する上位のグループ(親グループ)を表す情報である。すなわち、本実施の形態においては、グループ情報に、当該グループの親グループのさらに親のグループへのリンクを示す情報が含まれないようになっている。上記の「所有者の親グループの情報」は、所有者が属するグループの親グループに対するリンクを表す情報として扱われる。これらのグループ情報は、DirectoryName形式とは異なる形式(例えば単なる文字列)にて記述されている。
【0019】
図2は、図1の属性認証局2によって、グループA〜Fに対して発行される属性証明書251〜257に含まれるグループ情報の内容を示す図である。図2のグループA〜Fは、例えば、国、業界、企業、部署等の団体を単位として構成されるものであり、各グループA〜Fには1又は複数の利用者が所属している。グループAは、親グループが無く、子グループのみを保持しているグループであり、その属性証明書251には「所有者のグループ情報」として「Aグループ」、「所有者の親グループの情報」として「RootGroup」(親グループが無いことを示す表示)が記述されている。グループBは、親グループがグループAであり、その属性証明書252には「所有者のグループ情報」として「グループB」、「所有者の親グループの情報」として「グループA」が記述されている。
【0020】
また、図2のグループFは、親グループがグループBとグループCの2つであり、グループFに対しては2つの属性証明書256と属性証明書257が発行されている。属性証明書256には「所有者のグループ情報」として「グループF」、「所有者の親グループの情報」として「グループB」が記述されている。属性証明書257には「所有者のグループ情報」として「グループF」、「所有者の親グループの情報」として「グループC」が記述されている。
【0021】
図2に示すように、本実施の形態では、属性証明書内に記述されるグループ情報が「所有者のグループ情報」と「所有者の親グループの情報」のみであり、それ以外のさらに親の(あるいはさらに子の)グループの情報が含まれていない。そのため、例えば、グループ間のあるリンク状態が変更されたときには、その変更されたリンクの親グループと子グループの各属性証明書のグループ情報のみ更新することで変更後の状態に対応することが可能となる。つまり、変更前の親グループのさらに親のグループあるいは変更前の子グループのさらに子のグループのグループ情報については変更する必要がない。したがって、本実施の形態によれば、グループ情報の変更が必要となる属性証明書の枚数を従来よりも容易に減少することが可能となる。
【0022】
図1の属性証明書検証機関4は、検証受付モジュール41、事前検証モジュール42、有効グループツリー保持DB(証明書毎)43、有効証明書保持DB44、及び有効グループツリー保持DB45から構成されている。検証受付モジュール41は、クライアント3からの属性証明書に関する検証要求(依頼)を受け付けて処理するプログラムである。事前検証モジュール42は、各属性証明書を事前に検証しておき、属性証明書/属性証明書の記述に基づくグループツリーを管理(登録・作成・更新)したり、各属性証明書毎に有効なグループツリーを管理するためのプログラムである。有効グループツリー保持DB(証明書毎)43は、属性証明書毎に有効なグループツリーを保持するデータベースである。有効証明書保持DB44は、有効な各属性証明書を特定する情報を保持するデータベースである。有効グループツリー保持DB45は、すべての属性証明書に対して有効なグループツリーを保持するデータベースである。
【0023】
なお、属性証明書検証機関4は、属性検証局(AVA(Attribute Validation Authority))として独立に準備する場合と、属性認証局2と同居した形で準備する場合の二通りが考えられる。
【0024】
図3は、有効証明書保持DB44で保持・管理される情報を説明するための図である。有効証明書保持DB44では、属性証明書毎に、発行元の属性認証局2を識別するための情報(「発行元AA」)、属性証明書の証明書番号(「証明書No.」)及び各属性証明書の有効期限(「有効期限」)が保持されている。これらの情報は、発行時、変更時等に必要に応じて登録され、また更新される。
【0025】
図4は、有効グループツリー保持DB45で管理される情報を説明するための図である。有効グループツリー保持DB45には、図4に示すような、グループノードA〜Qに対して有効な全てのグループツリーを示す情報が管理/保持される。図4では、グループノードを各グループ名を表す英字を丸で囲んで表し、属性証明における従属関係が存在する各グループノード間のつながり(チェーン)をグループノードを表す丸印間を結んだ直線で表している。図4において、上側に位置するグループ(例えばグループA(又はグループB))が親グループであり、下側に位置するグループ(例えばグループB(又はグループD))が子グループである。
【0026】
また、有効グループツリー保持DB45には、各グループ間のチェーン451A、451B、…を構築するために必要となるチェーン情報452A、452B、…も併せて管理/保持されている。各チェーン情報452A、452B、…は、信頼点(認証局a、認証局b、…)、属性認証局2の識別情報(AA)(xxx、xxx、…)、公開鍵証明書のシリアル番号(Serial No.)(xxxxxx、xxxxxx、…)等を表す情報から構成されている。ここで、信頼点とは、当該グループの公開鍵証明書の信頼の基点となる認証局(認証局1)を示している。
【0027】
図4において、チェーン情報452Aは、子グループBの信頼点が「認証局b」であり、子グループBの親グループAに対する属性を表す属性証明書の発行を行った属性認証局2が「xxx」であり、子グループBの属性証明書の検証を行う際に用いられる公開鍵証明書のシリアル番号が「xxxxxx」であることを示している。チェーン情報452Bは、子グループCの信頼点が「認証局a」であり、子グループCの親グループAに対する属性を表す属性証明書の発行を行った属性認証局2が「xxx」であり、子グループCの属性証明書の検証を行う際に用いられる公開鍵証明書のシリアル番号が「xxxxxx」であることを示している。
【0028】
また、図4において、グループHは、チェーン451CによってグループDに属するとともに、チェーン451DによってグループEに属することが示されている。すなわちグループHに対しては、2つの親グループが存在している。このグループHに対しては、グループDに対するものと、グループEに対するものの2枚の属性証明書が発行されることになるので、チェーン情報についてもチェーン情報452Cとチェーン情報452Dの二つの情報が保持されている。
【0029】
なお、図4に破線のチェーン451Eとして示す子グループLと親グループFの属性関係が無効となった場合や、図示していない新たな属性関係の結合が生じた場合には、それらの変更に応じて有効グループツリー保持DB45内のデータが更新される。
【0030】
図5は、有効グループツリー保持DB(証明書毎)43で管理される情報を説明するための図である。有効グループツリー保持DB(証明書毎)43には、属性証明書毎に、属性証明書の発行元である属性認証局2の識別情報(発行元AA)、属性証明書の証明書番号(証明書No.)及びその属性証明書の所有者が属するグループを示すグループ情報(有効グループ)と、そのグループから最上位のグループ(親グループが無いグループ)までのツリー構成を表す情報とが管理/保持されている。
【0031】
図5の当該グループから最上位のグループまでのツリー構成を表す情報は、図4に示すグループツリー構成に対応して記載されている。証明書番号が「00000003」の属性証明書に対しては、当該グループ(グループH)の親グループ(グループD及びグループE)とその各チェーンの信頼点(認証局b及び認証局a)の情報、親グループ(グループD及びグループE)の親グループ(グループB並びにグループB及びグループC)とその各チェーンの信頼点(認証局b並びに認証局b及び認証局a)の情報、及び、親グループ(グループB及びグループC)の親グループ(グループA及びグループA)とその各チェーンの信頼点(認証局b及び認証局a)の情報が記載されている。
【0032】
次に、図6〜図8を参照して、図1に示す属性証明書検証機関4における処理の流れについて説明する。本実施の形態の属性証明書検証機関4は、次の二つの処理を実施することで、属性証明書の検証時間を短縮するための準備を行う。これらの処理は、属性証明書検証機関4内の事前検証モジュール42によって実行される。
(1)属性証明書(AC)の事前検証処理。
(2)有効データ管理処理。
【0033】
属性証明書(AC)の事前検証処理の処理フローを図6に示す。この処理では、属性認証局2のリポジトリ22内の発行済属性証明書管理DB23から発行済み属性証明書を取得するとともに、無効属性証明書管理DB24から無効となった属性証明書がリストされているACRLを取得する(ステップS11)。そして、ACRLを利用して属性証明書の事前検証を実施する(ステップS12)。その結果を有効証明書保持DB44及び有効グループツリー保持DB45に反映させる(ステップS13)。そして、有効グループツリー保持DB45から、属性証明書番号毎に有効なグループツリーを検索し、その結果を有効グループツリー保持DB(証明書毎)43に反映させる(ステップS14)。
【0034】
次に、有効データ管理処理の処理フローを図7に示す。この処理では、ある属性証明書が新たにACRLに登録された場合や、有効期限が切れてしまった場合に、有効証明書保持DB44、有効グループツリー保持DB45、有効グループツリー保持DB(証明書毎)46を正しい状態に保持する。ここでは、まず、ACRLに挙げられている属性証明書番号(Yとする)を取得する(ステップS21)。次に、有効証明書保持DB44内で期限切れとなる属性証明書番号(Xとする)を取得し、属性証明書番号(X)や(Y)に該当するレコードを削除する(ステップS22)。次に、有効グループツリー保持DB45内で、属性証明書番号(X)や(Y)に該当するチェーンを切断する(ステップS23)。そして、有効グループツリー保持DB45から、属性証明書毎に有効なグループツリーを検索し、その結果を有効グループツリー保持DB(証明書毎)43に反映させる(ステップS24)。
【0035】
次に、図8を参照して、属性証明書検証機関4が、クライアント3から属性証明書(AC)の検証依頼を受けて、該当属性証明書(AC)の有効性と有効グループについて検索し、クライアント3に対して回答を返信する際の処理について説明する。
【0036】
ここでは、クライアント3をユーザA及びユーザBとして、ユーザAがユーザBに対して属性証明書を提示し、ユーザBが属性証明書検証機関4に対してその検証を依頼する場合を例として説明を行う。まず、自分の属性を提示したいユーザAは、提示先のユーザBに対して自分の属性証明書(AC)と公開鍵証明書の二つを提示する。ユーザBでは、属性証明書検証機関4に対して、ユーザAの属性証明書(AC)と公開鍵証明書の二つを送り、検証を依頼する。
【0037】
属性証明書検証機関4は、検証受付モジュール41によって、ユーザB(クライアント3)から、検証対象となる属性証明書XとユーザA(他のクライアント3)の公開鍵証明書Yを受け付ける(ステップS31)。属性証明書検証機関4は、有効証明書保持DB44を参照して、属性証明書Xが存在するか否かを判定する(ステップS32)。属性証明書Xが存在する場合、有効グループツリー保持DB(証明書毎)43から、公開鍵証明書Yの信頼点に矛盾しない有効なグループツリーを取得する(ステップS33)。そして、検証結果を示す情報(有効)と有効なグループ情報をユーザBに送付する(ステップS34)。
【0038】
他方、ステップS32で属性証明書Xが存在しないと判定された場合、その旨を示す検証結果(無効)をユーザB(クライアント3)に対して送付する(ステップS35)。
【0039】
ユーザBは、属性証明書検証機関4にアクセスして、ユーザAの属性証明書(AC)から公開鍵証明書へのリンクが正しく張られていることを確認することで、属性証明書(AC)内に記述されている属性情報が正しいものであることを確認することができる。
【0040】
なお、本実施の形態では、属性証明書(AC)内に記述されているグループ情報が「親グループの情報」と「自分のグループの情報」のみであるため、属性証明書検証機関4が、ユーザBからの依頼に応じてユーザAが所属するグループツリー全てを確認するためには、そこに記述されている親グループの属性証明書(AC)(更に他の属性証明書(AC)にリンクが張られている場合には、その属性証明書(AC)、…)も確認する必要がある。すなわち、本実施の形態では一つの属性が複数の属性証明書(AC)に分割して記述される形になるため、その属性の正当性を検証するためには、複数の全ての属性証明書(AC)のチェーンを検証する必要がある。また、あるグループノードが複数の属性証明書(AC)を保持する場合には、親グループが複数となる場合も存在する。そのため、現状の属性証明書(AC)を検証する場合よりも対象となる属性証明書の検証枚数が増加するとともに、検証パスが複雑になり、結果的に検証時間が大きくなってしまうことも考えられる。
【0041】
しかしながら本実施の形態では、上述したように、クライアント3からの要求に応じて属性証明書(AC)の検証を行う属性証明書検証機関4において、前もって、(1)属性証明書(AC)の事前検証処理と、(2)有効データ管理処理とを行っておくことで、検証時間の短縮が図られている。
【0042】
以上のように、本実施の形態では、グループ情報を「所有者のグループ情報」と「所有者の親グループの情報」のみから構成し、これを例えばDirectoryName形式とは異なる形式で記述して、複数枚の属性証明書(AC)を用いてグループツリーを提示/確認する方式を採用したので、グループツリーの改変時等に、従来方式よりも属性証明書(AC)の更新枚数を減らすことが可能となる。
【0043】
また、グループツリーを分割し、複数の属性証明書(AC)に記述すると、グループ属性を検証するために複数枚の属性証明書(AC)を検証する必要があるため、検証の都度、複数枚の属性証明書(AC)を取得することとすると、全体としての検証時間が増加してしまうことが考えられるが、その検証処理を、予め検証処理に使用する情報を取得、保持する属性証明書検証機関に依頼して行うようにしたので、現状の検証よりも短い時間で検証結果を取得することが可能となる。
【0044】
なお、この発明の実施の形態は、上記の構成に限らず、各構成を統合したり、分離してネットワークを介して配置したり、あるいは各構成の機能を他の構成に移動あるいは分担させることなどの変更が適宜可能である。また、本実施の形態を構成するプログラムはコンピュータ読み取り可能な記録媒体あるいは通信回線を介して提供することが可能である。
【図面の簡単な説明】
【0045】
【図1】この発明の実施の形態の構成を示すシステム図である。
【図2】図1の実施の形態における属性証明書のグループ情報の記述例を示す図である。
【図3】図1の有効証明書保持DB44で管理される情報を説明するための図である。
【図4】図1の有効グループツリー保持DB45で管理される情報を説明するための図である。
【図5】図1の有効グループツリー保持DB(証明書毎)43で管理される情報を説明するための図である。
【図6】図1の属性証明書検証機関4による事前検証処理の流れを示すフローチャートである。
【図7】図1の属性証明書検証機関4による有効データ管理処理の流れを示すフローチャートである。
【図8】図1の属性証明書検証機関4による検証受付/検証処理の流れを示すフローチャートである。
【符号の説明】
【0046】
1…認証局 2…属性認証局 3…クライアント 4…属性証明書検証機関 41…検証受付モジュール 42…事前検証モジュール 43…有効グループツリー保持DB(証明書毎) 44…有効証明書保持DB 45…有効グループツリー保持DB 251〜257…属性証明書

【特許請求の範囲】
【請求項1】
有効な各属性証明書を特定する情報を保持する有効証明書保持手段と、
すべての属性証明書に対して有効なグループツリーを保持する有効グループツリー保持手段と、
有効グループツリー保持手段が保持するグループツリーに基づいて構成された属性証明書毎に有効なグループツリーを保持する証明書毎有効グループツリー保持手段と、
前記有効証明書保持手段に保持されている情報と前記証明書毎有効グループツリー保持手段に保持されている情報とに基づいて、利用者からの属性証明書に関する検証要求を受け付けて検証処理を行う検証手段と
を備えることを特徴とする属性証明書処理装置。
【請求項2】
前記属性証明書に記述されているグループ情報が、当該属性証明書の所有者が属するグループを示す情報とそのグループの親のグループを示す情報とから構成されている
ことを特徴とする請求項1に記載の属性証明書処理装置。
【請求項3】
前記検証手段が、検証処理を要求された属性証明書が前記有効証明書保持手段に存在するか否かを判定し、存在する場合に前記証明書毎有効グループツリー保持手段に保持されている当該属性証明書に対応する情報を取得して利用者に送付するものである
ことを特徴とする請求項1又は2に記載の属性証明書処理装置。
【請求項4】
各属性証明書を事前に検証し、前記有効証明書保持手段の保持情報及び前記有効グループツリー保持手段の保持情報を更新する事前検証手段を
さらに備えることを特徴とする請求項1〜3のいずれか1項に記載の属性証明書処理装置。
【請求項5】
有効な各属性証明書を特定する情報を保持する有効証明書保持手段と、
すべての属性証明書に対して有効なグループツリーを保持する有効グループツリー保持手段と、
有効グループツリー保持手段が保持するグループツリーに基づいて構成された属性証明書毎に有効なグループツリーを保持する証明書毎有効グループツリー保持手段と
を用いて、
前記有効証明書保持手段に保持されている情報と前記証明書毎有効グループツリー保持手段に保持されている情報とに基づいて、利用者からの属性証明書に関する検証要求を受け付けて行う検証処理をコンピュータによって実行するための記述を含む
ことを特徴とする属性証明書処理プログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate


【公開番号】特開2006−310938(P2006−310938A)
【公開日】平成18年11月9日(2006.11.9)
【国際特許分類】
【出願番号】特願2005−127698(P2005−127698)
【出願日】平成17年4月26日(2005.4.26)
【国等の委託研究の成果に係る記載事項】(出願人による申告)平成16年度総務省「電子タグの高度利活用技術に関する研究開発」委託研究、産業活力再生特別措置法第30条の適用を受ける特許出願
【出願人】(000102728)株式会社エヌ・ティ・ティ・データ (438)
【Fターム(参考)】