(57)【要約】【課題】グループツリーの改変時等に、従来方式よりも属性証明書（AC）の更新枚数を減らすことができる属性証明書処理装置を提供する。【解決手段】有効な各属性証明書を特定する情報を保持する有効証明書保持ＤＢ４４と、すべての属性証明書に対して有効なグループツリーを保持する有効グループツリー保持ＤＢ４５と、属性証明書毎に有効なグループツリーを保持する有効グループツリー保持ＤＢ（証明書毎）４３と、それらに保持されている情報とに基づいて、クライアント３からの属性証明書に関する検証要求を受け付けて検証処理を行う検証受付モジュール４１とを設けている。【選択図】            図１
2006310938.tif 000002
【特許請求の範囲】
【請求項１】
有効な各属性証明書を特定する情報を保持する有効証明書保持手段と、
すべての属性証明書に対して有効なグループツリーを保持する有効グループツリー保持手段と、
有効グループツリー保持手段が保持するグループツリーに基づいて構成された属性証明書毎に有効なグループツリーを保持する証明書毎有効グループツリー保持手段と、
前記有効証明書保持手段に保持されている情報と前記証明書毎有効グループツリー保持手段に保持されている情報とに基づいて、利用者からの属性証明書に関する検証要求を受け付けて検証処理を行う検証手段と
を備えることを特徴とする属性証明書処理装置。
【請求項２】
前記属性証明書に記述されているグループ情報が、当該属性証明書の所有者が属するグループを示す情報とそのグループの親のグループを示す情報とから構成されている
ことを特徴とする請求項１に記載の属性証明書処理装置。
【請求項３】
前記検証手段が、検証処理を要求された属性証明書が前記有効証明書保持手段に存在するか否かを判定し、存在する場合に前記証明書毎有効グループツリー保持手段に保持されている当該属性証明書に対応する情報を取得して利用者に送付するものである
ことを特徴とする請求項１又は２に記載の属性証明書処理装置。
【請求項４】
各属性証明書を事前に検証し、前記有効証明書保持手段の保持情報及び前記有効グループツリー保持手段の保持情報を更新する事前検証手段を
さらに備えることを特徴とする請求項１〜３のいずれか1項に記載の属性証明書処理装置。
【請求項５】
有効な各属性証明書を特定する情報を保持する有効証明書保持手段と、
すべての属性証明書に対して有効なグループツリーを保持する有効グループツリー保持手段と、
有効グループツリー保持手段が保持するグループツリーに基づいて構成された属性証明書毎に有効なグループツリーを保持する証明書毎有効グループツリー保持手段と
を用いて、
前記有効証明書保持手段に保持されている情報と前記証明書毎有効グループツリー保持手段に保持されている情報とに基づいて、利用者からの属性証明書に関する検証要求を受け付けて行う検証処理をコンピュータによって実行するための記述を含む
ことを特徴とする属性証明書処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、公開鍵基盤等の暗号化、電子署名等に係る技術においてユーザの権限を証明する属性証明書の発行や検証を行う際に用いて好適な属性証明書処理装置及びそのプログラムに関する。
【背景技術】
【０００２】
属性証明書（ＡＣ（Ａｔｔｒｉｂｕｔｅ  Ｃｅｒｔｉｆｉｃａｔｅ））に記述されているグループ情報は、ＡＳＮ．１（Ａｂｓｔｒａｃｔ  Ｓｙｎｔａｘ  Ｎｏｔａｔｉｏｎ  Ｏｎｅ）のＤｉｒｅｃｔｏｒｙ  Ｎａｍｅ（ディレクトリネーム）形式で記述されていることが一般的である。すなわち、グループ情報は、通常、複数のグループ間のつながりを示すグループ識別情報のシーケンスによって記述されている。また、異なる記述形式を利用している場合でも、あるユーザが属するグループは、グループツリーを全て記述し、一意に判断可能な形式で記述されている。
【０００３】
また、属性証明書（ＡＣ）の検証時間を短縮させる技術として特許文献１のような手法が提案されている。特許文献１に記載されている属性証明書の検証方法は、限られたリソースを持つクライアントでの属性証明書（ＡＣ）検証時間の短縮を目標とし、通常クライアントが行う属性証明書（ＡＣ）の検証処理を検証局という第三者に依頼している。しかし、検証局内で行う処理は、通常の処理とあまり変わりがない。そのため、高いリソースを持つクライアントを利用する場合には、自分で属性証明書（ＡＣ）を検証するのに比べて、検証時間を大幅に短縮することはできない。
【特許文献１】特開２００３−３４８０７７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述したように属性証明書においては一般的にユーザのグループがDirectoryName形式により一意に決定されるように定義されている。そのため、グループツリー中の節部分に該当するグループが削除された場合や、節と節の間にグループが追加された場合など、グループツリーの上位にて変更が行われた場合には、その節に紐付いている属性証明書（AC）を全て更新する必要がある。よって、グループの改変が多く行われるシステムでは、1回のグループ改変における更新枚数が非常に多くなってしまうという問題がある。
【０００５】
この発明は、上記の事情に鑑みてなされたものであり、グループツリーの改変時等に、従来方式よりも属性証明書（ＡＣ）の更新枚数を減らすことができる属性証明書処理装置及びそのプログラムを提供することを目的とする。
【０００６】
この発明は、また、属性証明書の検証処理の際に、より短い時間で検証結果を取得することが可能となる属性証明書処理装置及びそのプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するため、請求項１記載の発明は、有効な各属性証明書を特定する情報を保持する有効証明書保持手段と、すべての属性証明書に対して有効なグループツリーを保持する有効グループツリー保持手段と、有効グループツリー保持手段が保持するグループツリーに基づいて構成された属性証明書毎に有効なグループツリーを保持する証明書毎有効グループツリー保持手段と、前記有効証明書保持手段に保持されている情報と前記証明書毎有効グループツリー保持手段に保持されている情報とに基づいて、利用者からの属性証明書に関する検証要求を受け付けて検証処理を行う検証手段とを備えることを特徴とする。
【０００８】
請求項２記載の発明は、前記属性証明書に記述されているグループ情報が、当該属性証明書の所有者が属するグループを示す情報とそのグループの親のグループを示す情報とから構成されていることを特徴とする。
【０００９】
請求項３記載の発明は、前記検証手段が、検証処理を要求された属性証明書が前記有効証明書保持手段に存在するか否かを判定し、存在する場合に前記証明書毎有効グループツリー保持手段に保持されている当該属性証明書に対応する情報を取得して利用者に送付するものであることを特徴とする。
【００１０】
請求項４記載の発明は、各属性証明書を事前に検証し、前記有効証明書保持手段の保持情報及び前記有効グループツリー保持手段の保持情報を更新する事前検証手段をさらに備えることを特徴とする。
【００１１】
請求項５記載の発明は、有効な各属性証明書を特定する情報を保持する有効証明書保持手段と、すべての属性証明書に対して有効なグループツリーを保持する有効グループツリー保持手段と、有効グループツリー保持手段が保持するグループツリーに基づいて構成された属性証明書毎に有効なグループツリーを保持する証明書毎有効グループツリー保持手段とを用いて、前記有効証明書保持手段に保持されている情報と前記証明書毎有効グループツリー保持手段に保持されている情報とに基づいて、利用者からの属性証明書に関する検証要求を受け付けて行う検証処理をコンピュータによって実行するための記述を含むことを特徴とする。
【発明の効果】
【００１２】
この発明によれば、有効証明書保持手段に保持されている情報と証明書毎有効グループツリー保持手段に保持されている情報とに基づいて、利用者からの属性証明書に関する検証要求を受け付けて検証処理を行うようにしたので、属性証明書に記述されているグループ情報を当該属性証明書の所有者が属するグループを示す情報とそのグループの親のグループを示す情報とから構成することが可能となり、したがって、グループツリーの改変時等に、変更対象となる属性証明書がその改変に直接関係する親グループ又は子のグループの記述からなるグループ情報を含むもののみに限定されることになるので、従来方式よりも属性証明書の更新枚数を減らすことが可能となる。
【００１３】
また、事前検証手段を備えることで、複数枚の属性証明書を用いた検証処理をより短い時間で行うことが可能となる。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照してこの発明による属性証明書処理装置の実施の形態について説明する。図１は、本実施の形態の構成及び情報の流れを示すシステム図である。本実施の形態は、図示していないネットワーク（通信網あるいは通信回線）を介して接続されている認証局１、属性認証局２、クライアント３及び属性証明書検証機関４から構成されている。ただし、図１では、認証局１、属性認証局２、クライアント３及び属性証明書検証機関４を各一つのみ示しているが、各構成は複数であってもよい。また、各構成は、１又は複数台のコンピュータ及びその周辺装置と、そのコンピュータ上で実行されるプログラムとによって実現することができる。
【００１５】
認証局１は、ＣＡ（Ｃｅｒｔｉｆｉｃａｔｅ  ｕｔｈｏｒｉｔｙ）と呼ばれるものであり、電子的な身分証明書を発行し、その管理を行う。本実施の形態において認証局１は、ＰＫＩ（Ｐｕｂｌｉｃ  Ｋｅｙ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ：公開鍵基盤）による公開鍵証明書の発行、管理を行う。認証局１には、公開鍵証明書等を表す公開情報を格納するデータベースであるリポジトリ１１が設けられている。このリポジトリ１１は、発行済証明書管理ＤＢ（データベース）１２と、無効証明書管理ＤＢ（データベース）１３とから構成されている。発行済証明書管理ＤＢ１２は、発行済み公開鍵証明書を管理するためのデータベースであり、無効証明書管理ＤＢ１３は、発行した公開鍵証明書の中で無効となった公開鍵証明書を管理するためのデータベースである。
【００１６】
クライアント３は、認証局１、属性認証局２、又は属性証明書検証機関４に対して、各種処理の実行を要求する端末である。
【００１７】
属性認証局２は、ＡＡ（Ａｔｔｒｉｂｕｔｅ  Ａｕｔｈｏｒｉｔｙ）と呼ばれるものであり、利用者（ユーザ）の属性を証明するための属性証明書（ＡＣ）を発行、管理する。属性認証局２は、属性証明書発行モジュール２１と、リポジトリ２２とから構成されている。属性証明書発行モジュール２１は、属性証明書発行処理を行うためのプログラムである。リポジトリ２２は、属性証明書等の公開情報を格納するデータベースであり、発行済属性証明書管理ＤＢ２３と、無効属性証明書管理ＤＢ２４とから構成されている。発行済属性証明書管理ＤＢ２３は、発行済み属性証明書を管理するためのデータベースである。無効属性証明書管理ＤＢ２４は、無効となった属性証明書を管理するためのデータベースであり、無効となった属性証明書（ＡＣ）を格納するリストをＡＣＲＬ（Ａｔｔｒｉｂｕｔｅ  Ｃｅｒｔｉｆｉｃａｔｅ  Ｒｅｖｏｃａｔｉｏｎ  Ｌｉｓｔ：属性証明書失効リスト）として保持している。
【００１８】
属性認証局２によって発行される属性証明書には、その属性証明書の所有者が属するグループにおけるその所有者の権限に関する属性を表す情報、その属性証明書の内容を検証する際に使用される公開鍵証明書を示す情報のほか、そのグループの親グループの情報を示すグループ情報が記述されている。本実施の形態においては、グループ情報が、「所有者のグループ情報」と「所有者の親グループの情報」の２つの要素のみから構成されている。「所有者のグループ情報」は、当該属性証明書の所有者が属するグループを表す情報であり、「所有者の親グループの情報」は当該所有者が属するグループが属する上位のグループ（親グループ）を表す情報である。すなわち、本実施の形態においては、グループ情報に、当該グループの親グループのさらに親のグループへのリンクを示す情報が含まれないようになっている。上記の「所有者の親グループの情報」は、所有者が属するグループの親グループに対するリンクを表す情報として扱われる。これらのグループ情報は、ＤｉｒｅｃｔｏｒｙＮａｍｅ形式とは異なる形式（例えば単なる文字列）にて記述されている。
【００１９】
図２は、図１の属性認証局２によって、グループＡ〜Ｆに対して発行される属性証明書２５１〜２５７に含まれるグループ情報の内容を示す図である。図２のグループＡ〜Ｆは、例えば、国、業界、企業、部署等の団体を単位として構成されるものであり、各グループＡ〜Ｆには１又は複数の利用者が所属している。グループＡは、親グループが無く、子グループのみを保持しているグループであり、その属性証明書２５１には「所有者のグループ情報」として「Ａグループ」、「所有者の親グループの情報」として「ＲｏｏｔＧｒｏｕｐ」（親グループが無いことを示す表示）が記述されている。グループＢは、親グループがグループＡであり、その属性証明書２５２には「所有者のグループ情報」として「グループＢ」、「所有者の親グループの情報」として「グループＡ」が記述されている。
【００２０】
また、図２のグループＦは、親グループがグループＢとグループＣの２つであり、グループＦに対しては２つの属性証明書２５６と属性証明書２５７が発行されている。属性証明書２５６には「所有者のグループ情報」として「グループＦ」、「所有者の親グループの情報」として「グループＢ」が記述されている。属性証明書２５７には「所有者のグループ情報」として「グループＦ」、「所有者の親グループの情報」として「グループＣ」が記述されている。
【００２１】
図２に示すように、本実施の形態では、属性証明書内に記述されるグループ情報が「所有者のグループ情報」と「所有者の親グループの情報」のみであり、それ以外のさらに親の（あるいはさらに子の）グループの情報が含まれていない。そのため、例えば、グループ間のあるリンク状態が変更されたときには、その変更されたリンクの親グループと子グループの各属性証明書のグループ情報のみ更新することで変更後の状態に対応することが可能となる。つまり、変更前の親グループのさらに親のグループあるいは変更前の子グループのさらに子のグループのグループ情報については変更する必要がない。したがって、本実施の形態によれば、グループ情報の変更が必要となる属性証明書の枚数を従来よりも容易に減少することが可能となる。
【００２２】
図１の属性証明書検証機関４は、検証受付モジュール４１、事前検証モジュール４２、有効グループツリー保持ＤＢ（証明書毎）４３、有効証明書保持ＤＢ４４、及び有効グループツリー保持ＤＢ４５から構成されている。検証受付モジュール４１は、クライアント３からの属性証明書に関する検証要求（依頼）を受け付けて処理するプログラムである。事前検証モジュール４２は、各属性証明書を事前に検証しておき、属性証明書／属性証明書の記述に基づくグループツリーを管理（登録・作成・更新）したり、各属性証明書毎に有効なグループツリーを管理するためのプログラムである。有効グループツリー保持ＤＢ（証明書毎）４３は、属性証明書毎に有効なグループツリーを保持するデータベースである。有効証明書保持ＤＢ４４は、有効な各属性証明書を特定する情報を保持するデータベースである。有効グループツリー保持ＤＢ４５は、すべての属性証明書に対して有効なグループツリーを保持するデータベースである。
【００２３】
なお、属性証明書検証機関４は、属性検証局（ＡＶＡ（Ａｔｔｒｉｂｕｔｅ  Ｖａｌｉｄａｔｉｏｎ  Ａｕｔｈｏｒｉｔｙ））として独立に準備する場合と、属性認証局２と同居した形で準備する場合の二通りが考えられる。
【００２４】
図３は、有効証明書保持ＤＢ４４で保持・管理される情報を説明するための図である。有効証明書保持ＤＢ４４では、属性証明書毎に、発行元の属性認証局２を識別するための情報（「発行元ＡＡ」）、属性証明書の証明書番号（「証明書Ｎｏ．」）及び各属性証明書の有効期限（「有効期限」）が保持されている。これらの情報は、発行時、変更時等に必要に応じて登録され、また更新される。
【００２５】
図４は、有効グループツリー保持ＤＢ４５で管理される情報を説明するための図である。有効グループツリー保持ＤＢ４５には、図４に示すような、グループノードＡ〜Ｑに対して有効な全てのグループツリーを示す情報が管理／保持される。図４では、グループノードを各グループ名を表す英字を丸で囲んで表し、属性証明における従属関係が存在する各グループノード間のつながり（チェーン）をグループノードを表す丸印間を結んだ直線で表している。図４において、上側に位置するグループ（例えばグループＡ（又はグループＢ））が親グループであり、下側に位置するグループ（例えばグループＢ（又はグループＤ））が子グループである。
【００２６】
また、有効グループツリー保持ＤＢ４５には、各グループ間のチェーン４５１Ａ、４５１Ｂ、…を構築するために必要となるチェーン情報４５２Ａ、４５２Ｂ、…も併せて管理／保持されている。各チェーン情報４５２Ａ、４５２Ｂ、…は、信頼点（認証局ａ、認証局ｂ、…）、属性認証局２の識別情報（ＡＡ）（ｘｘｘ、ｘｘｘ、…）、公開鍵証明書のシリアル番号（Ｓｅｒｉａｌ  Ｎｏ．）（ｘｘｘｘｘｘ、ｘｘｘｘｘｘ、…）等を表す情報から構成されている。ここで、信頼点とは、当該グループの公開鍵証明書の信頼の基点となる認証局（認証局１）を示している。
【００２７】
図４において、チェーン情報４５２Ａは、子グループＢの信頼点が「認証局ｂ」であり、子グループＢの親グループＡに対する属性を表す属性証明書の発行を行った属性認証局２が「ｘｘｘ」であり、子グループＢの属性証明書の検証を行う際に用いられる公開鍵証明書のシリアル番号が「ｘｘｘｘｘｘ」であることを示している。チェーン情報４５２Ｂは、子グループＣの信頼点が「認証局ａ」であり、子グループＣの親グループＡに対する属性を表す属性証明書の発行を行った属性認証局２が「ｘｘｘ」であり、子グループＣの属性証明書の検証を行う際に用いられる公開鍵証明書のシリアル番号が「ｘｘｘｘｘｘ」であることを示している。
【００２８】
また、図４において、グループＨは、チェーン４５１ＣによってグループＤに属するとともに、チェーン４５１ＤによってグループＥに属することが示されている。すなわちグループＨに対しては、２つの親グループが存在している。このグループＨに対しては、グループＤに対するものと、グループＥに対するものの２枚の属性証明書が発行されることになるので、チェーン情報についてもチェーン情報４５２Ｃとチェーン情報４５２Ｄの二つの情報が保持されている。
【００２９】
なお、図４に破線のチェーン４５１Ｅとして示す子グループＬと親グループＦの属性関係が無効となった場合や、図示していない新たな属性関係の結合が生じた場合には、それらの変更に応じて有効グループツリー保持ＤＢ４５内のデータが更新される。
【００３０】
図５は、有効グループツリー保持ＤＢ（証明書毎）４３で管理される情報を説明するための図である。有効グループツリー保持ＤＢ（証明書毎）４３には、属性証明書毎に、属性証明書の発行元である属性認証局２の識別情報（発行元ＡＡ）、属性証明書の証明書番号（証明書Ｎｏ．）及びその属性証明書の所有者が属するグループを示すグループ情報（有効グループ）と、そのグループから最上位のグループ（親グループが無いグループ）までのツリー構成を表す情報とが管理／保持されている。
【００３１】
図５の当該グループから最上位のグループまでのツリー構成を表す情報は、図４に示すグループツリー構成に対応して記載されている。証明書番号が「０００００００３」の属性証明書に対しては、当該グループ（グループＨ）の親グループ（グループＤ及びグループＥ）とその各チェーンの信頼点（認証局ｂ及び認証局ａ）の情報、親グループ（グループＤ及びグループＥ）の親グループ（グループＢ並びにグループＢ及びグループＣ）とその各チェーンの信頼点（認証局ｂ並びに認証局ｂ及び認証局ａ）の情報、及び、親グループ（グループＢ及びグループＣ）の親グループ（グループＡ及びグループＡ）とその各チェーンの信頼点（認証局ｂ及び認証局ａ）の情報が記載されている。
【００３２】
次に、図６〜図８を参照して、図１に示す属性証明書検証機関４における処理の流れについて説明する。本実施の形態の属性証明書検証機関４は、次の二つの処理を実施することで、属性証明書の検証時間を短縮するための準備を行う。これらの処理は、属性証明書検証機関４内の事前検証モジュール４２によって実行される。
（１）属性証明書（AC）の事前検証処理。
（２）有効データ管理処理。
【００３３】
属性証明書（ＡＣ）の事前検証処理の処理フローを図６に示す。この処理では、属性認証局２のリポジトリ２２内の発行済属性証明書管理ＤＢ２３から発行済み属性証明書を取得するとともに、無効属性証明書管理ＤＢ２４から無効となった属性証明書がリストされているACRLを取得する（ステップＳ１１）。そして、ACRLを利用して属性証明書の事前検証を実施する（ステップＳ１２）。その結果を有効証明書保持ＤＢ４４及び有効グループツリー保持ＤＢ４５に反映させる（ステップＳ１３）。そして、有効グループツリー保持ＤＢ４５から、属性証明書番号毎に有効なグループツリーを検索し、その結果を有効グループツリー保持ＤＢ（証明書毎）４３に反映させる（ステップＳ１４）。
【００３４】
次に、有効データ管理処理の処理フローを図７に示す。この処理では、ある属性証明書が新たにACRLに登録された場合や、有効期限が切れてしまった場合に、有効証明書保持ＤＢ４４、有効グループツリー保持ＤＢ４５、有効グループツリー保持ＤＢ（証明書毎）４６を正しい状態に保持する。ここでは、まず、ＡＣＲＬに挙げられている属性証明書番号（Ｙとする）を取得する（ステップＳ２１）。次に、有効証明書保持ＤＢ４４内で期限切れとなる属性証明書番号（Ｘとする）を取得し、属性証明書番号（Ｘ）や（Ｙ）に該当するレコードを削除する（ステップＳ２２）。次に、有効グループツリー保持ＤＢ４５内で、属性証明書番号（Ｘ）や（Ｙ）に該当するチェーンを切断する（ステップＳ２３）。そして、有効グループツリー保持ＤＢ４５から、属性証明書毎に有効なグループツリーを検索し、その結果を有効グループツリー保持ＤＢ（証明書毎）４３に反映させる（ステップＳ２４）。
【００３５】
次に、図８を参照して、属性証明書検証機関４が、クライアント３から属性証明書（ＡＣ）の検証依頼を受けて、該当属性証明書（ＡＣ）の有効性と有効グループについて検索し、クライアント３に対して回答を返信する際の処理について説明する。
【００３６】
ここでは、クライアント３をユーザＡ及びユーザＢとして、ユーザＡがユーザＢに対して属性証明書を提示し、ユーザＢが属性証明書検証機関４に対してその検証を依頼する場合を例として説明を行う。まず、自分の属性を提示したいユーザＡは、提示先のユーザＢに対して自分の属性証明書（ＡＣ）と公開鍵証明書の二つを提示する。ユーザＢでは、属性証明書検証機関４に対して、ユーザＡの属性証明書（ＡＣ）と公開鍵証明書の二つを送り、検証を依頼する。
【００３７】
属性証明書検証機関４は、検証受付モジュール４１によって、ユーザＢ（クライアント３）から、検証対象となる属性証明書ＸとユーザＡ（他のクライアント３）の公開鍵証明書Ｙを受け付ける（ステップＳ３１）。属性証明書検証機関４は、有効証明書保持ＤＢ４４を参照して、属性証明書Ｘが存在するか否かを判定する（ステップＳ３２）。属性証明書Ｘが存在する場合、有効グループツリー保持ＤＢ（証明書毎）４３から、公開鍵証明書Ｙの信頼点に矛盾しない有効なグループツリーを取得する（ステップＳ３３）。そして、検証結果を示す情報（有効）と有効なグループ情報をユーザＢに送付する（ステップＳ３４）。
【００３８】
他方、ステップＳ３２で属性証明書Ｘが存在しないと判定された場合、その旨を示す検証結果（無効）をユーザＢ（クライアント３）に対して送付する（ステップＳ３５）。
【００３９】
ユーザＢは、属性証明書検証機関４にアクセスして、ユーザＡの属性証明書（ＡＣ）から公開鍵証明書へのリンクが正しく張られていることを確認することで、属性証明書（ＡＣ）内に記述されている属性情報が正しいものであることを確認することができる。
【００４０】
なお、本実施の形態では、属性証明書（ＡＣ）内に記述されているグループ情報が「親グループの情報」と「自分のグループの情報」のみであるため、属性証明書検証機関４が、ユーザＢからの依頼に応じてユーザＡが所属するグループツリー全てを確認するためには、そこに記述されている親グループの属性証明書（ＡＣ）（更に他の属性証明書（ＡＣ）にリンクが張られている場合には、その属性証明書（ＡＣ）、…）も確認する必要がある。すなわち、本実施の形態では一つの属性が複数の属性証明書（ＡＣ）に分割して記述される形になるため、その属性の正当性を検証するためには、複数の全ての属性証明書（ＡＣ）のチェーンを検証する必要がある。また、あるグループノードが複数の属性証明書（ＡＣ）を保持する場合には、親グループが複数となる場合も存在する。そのため、現状の属性証明書（ＡＣ）を検証する場合よりも対象となる属性証明書の検証枚数が増加するとともに、検証パスが複雑になり、結果的に検証時間が大きくなってしまうことも考えられる。
【００４１】
しかしながら本実施の形態では、上述したように、クライアント３からの要求に応じて属性証明書（AC）の検証を行う属性証明書検証機関４において、前もって、（１）属性証明書（AC）の事前検証処理と、（２）有効データ管理処理とを行っておくことで、検証時間の短縮が図られている。
【００４２】
以上のように、本実施の形態では、グループ情報を「所有者のグループ情報」と「所有者の親グループの情報」のみから構成し、これを例えばＤｉｒｅｃｔｏｒｙＮａｍｅ形式とは異なる形式で記述して、複数枚の属性証明書（ＡＣ）を用いてグループツリーを提示／確認する方式を採用したので、グループツリーの改変時等に、従来方式よりも属性証明書（ＡＣ）の更新枚数を減らすことが可能となる。
【００４３】
また、グループツリーを分割し、複数の属性証明書（ＡＣ）に記述すると、グループ属性を検証するために複数枚の属性証明書（ＡＣ）を検証する必要があるため、検証の都度、複数枚の属性証明書（ＡＣ）を取得することとすると、全体としての検証時間が増加してしまうことが考えられるが、その検証処理を、予め検証処理に使用する情報を取得、保持する属性証明書検証機関に依頼して行うようにしたので、現状の検証よりも短い時間で検証結果を取得することが可能となる。
【００４４】
なお、この発明の実施の形態は、上記の構成に限らず、各構成を統合したり、分離してネットワークを介して配置したり、あるいは各構成の機能を他の構成に移動あるいは分担させることなどの変更が適宜可能である。また、本実施の形態を構成するプログラムはコンピュータ読み取り可能な記録媒体あるいは通信回線を介して提供することが可能である。
【図面の簡単な説明】
【００４５】
【図１】この発明の実施の形態の構成を示すシステム図である。
【図２】図１の実施の形態における属性証明書のグループ情報の記述例を示す図である。
【図３】図１の有効証明書保持ＤＢ４４で管理される情報を説明するための図である。
【図４】図１の有効グループツリー保持ＤＢ４５で管理される情報を説明するための図である。
【図５】図１の有効グループツリー保持ＤＢ（証明書毎）４３で管理される情報を説明するための図である。
【図６】図１の属性証明書検証機関４による事前検証処理の流れを示すフローチャートである。
【図７】図１の属性証明書検証機関４による有効データ管理処理の流れを示すフローチャートである。
【図８】図１の属性証明書検証機関４による検証受付／検証処理の流れを示すフローチャートである。
【符号の説明】
【００４６】
１…認証局  ２…属性認証局  ３…クライアント  ４…属性証明書検証機関  ４１…検証受付モジュール  ４２…事前検証モジュール  ４３…有効グループツリー保持ＤＢ（証明書毎）  ４４…有効証明書保持ＤＢ  ４５…有効グループツリー保持ＤＢ  ２５１〜２５７…属性証明書
【図１】
2006310938.tif 000003
【図２】
2006310938.tif 000004
【図３】
2006310938.tif 000005
【図４】
2006310938.tif 000006
【図５】
2006310938.tif 000007
【図６】
2006310938.tif 000008
【図７】
2006310938.tif 000009
【図８】
2006310938.tif 000010