JP3842664B2 - ネットワークシステムおよびネットワークシステムの制御方法 - Google Patents
ネットワークシステムおよびネットワークシステムの制御方法 Download PDFInfo
- Publication number
- JP3842664B2 JP3842664B2 JP2002035924A JP2002035924A JP3842664B2 JP 3842664 B2 JP3842664 B2 JP 3842664B2 JP 2002035924 A JP2002035924 A JP 2002035924A JP 2002035924 A JP2002035924 A JP 2002035924A JP 3842664 B2 JP3842664 B2 JP 3842664B2
- Authority
- JP
- Japan
- Prior art keywords
- public key
- key certificate
- certificate
- rule information
- name
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、PKIで利用される多種の照合規則環境において、公開鍵が認証局に登録された際に使用された照合規則を利用者（業務システムを含む）で認識することができないことによる課題を解決し、利便性を向上させる照合規則情報格納装置、照合規則情報格納方法、公開鍵証明書取得装置、公開鍵証明書取得方法、利用可否判定装置、利用可否判定方法、コンピュータプログラムおよびコンピュータプログラムを記録した記録媒体に関する。
【０００２】
【従来の技術】
ＰＫＩ（公開鍵基盤：PublicKeyInfrastructure）においては、“認証局（ＣＡ）への公開鍵登録”,“ディレクトリからの公開鍵証明書取得”,“利用者アプリケーションにおける利用者許可判定”の３つの場面において、照合規則に応じた名前変換および照合が必要である。
【０００３】
図１７は、ＰＫＩにおける名前変換と照合の場面を示す図である。
【０００４】
先ず、“ＣＡへの公開鍵登録”の場面での名前変換について説明する。ＣＡ１０００は、利用者から申請された公開鍵登録申請書における公開鍵証明書の作成対象となる所有者名を、Ｘ．５００照合やＲＦＣ２４５９照合にしたがった変換方法で、ディレクトリにおける公開鍵証明書の検索ラベルとしての名前に変換する。
【０００５】
図１８は、Ｘ．５００照合とＲＦＣ２４５９照合を前提とした名前変換を示す図である。
【０００６】
公開鍵証明書の所有者名はDistinguished Name（DN）、つまりストリングタイプ（形式）とそのストリング（内容）とから成り、このストリングタイプは、例えばPrintableStringやUTF8Stringを区別できるものとして申請される。また、所有者名のストリングは、人や団体などの登場人物（Party）を特定するものであり、通常は大文字と小文字が混在しており、また任意の箇所にスペース（図１７，１８では￥で示す）を含んでいる。
【０００７】
さて、この所有者名の名前変換を説明する前に、ＲＦＣ２４５９に規定されたＸ．５００照合とＲＦＣ２４５９照合の規則を説明する。
【０００８】
【数１】
次に変換例を説明する。なお「\」はスペースを示す。
【０００９】
ここで所有者名が、▲１▼PrintableStringのa\\b，▲２▼UTF8Stringのa\\b，▲３▼PrintableStringのA\B，▲４▼UTF8StringのA\B，▲５▼PrintableStringのA\\B，▲６▼UTF8StringのA\\Bである場合を説明する。
【００１０】
Ｘ．５００照合による名前変換では、▲１▼から▲６▼すべてが（A\B）に変換される。一方、ＲＦＣ２４５９照合では、▲１▼と▲３▼と▲５▼は（PrintableString:A\B）に変換され、▲２▼と▲４▼と▲６▼はそれぞれ異なる名前（UTF8String:a\\b,UTF8String:A\B,UTF8String:A\\B)に変換される。
【００１１】
なお、ＣＡ１０００は、変換前の名前を所有者名として含んだ公開鍵証明書を公開鍵登録申請者へと発行し、公開鍵登録申請者はこの公開鍵証明書を取得する。
【００１２】
そして公開鍵証明書はディレクトリ２０００に登録されるのであるが、その際には検索ラベルに対応づけられた格納場所（エントリ）にLDAPプロトコルにより格納される。
【００１３】
ただし、検索ラベルを全て“文字列”で格納すると、例えばPrintableStringのA\BとUTF8StringのA\Bに代表されるようなＲＦＣ２４５９照合におけるストリングタイプ区別を行うことができなくなるため、検索ラベルは、Ｘ．５００照合の時とＲＦＣ２４５９照合のPrintableStringの場合には文字列で、一方、ＲＦＣ２４５９照合のPrintableString以外の場合には16進数で格納される。これにより、ＣＡとディレクトリにおける名前の１対１対応を可能としている。これは、RFC2253において、“値のDER形式の再構成を要求する（つまりRFC2459に示されるストリング区別を行うような）アプリケーションは、文字列でアクセスするべきではなく、16進数表記でアクセスするべき”と規定されていることによるものである。
【００１４】
次に、“ディレクトリからの公開鍵証明書取得”の場面での名前変換について説明する。
公開鍵証明書の発行を受けた利用者が、業務処理を提供するコンピュータシステム（業務システム３０００）を利用しようとするときは、利用者（利用希望者）に使用される利用者端末４から、業務システム３０００に対し、ディジタル署名を含んだ署名文書が送信され、さらに利用希望者名の公開鍵証明書の所有者名が通知されることになる。
【００１５】
この署名文書を受け取った業務システム３０００は、ディレクトリ２へアクセスすることにより利用希望者の公開鍵証明書を取得し、この公開鍵証明書でディジタル署名の検証を行う。
【００１６】
ここでも、“ＣＡへの公開鍵登録”の場面での名前変換と同様の名前変換が行われる。つまり、例えば、利用希望者名としてUTF8String:A\\Bが送信されると、業務システム３０００では、例えばＸ．５００照合を前提とした名前変換により、UTF8String:A\\BをA\B(文字列)に変換する。そして、これを検索キーとしてディレクトリ２０００に公開鍵証明書を要求すると、ディレクトリ２０００は、これに対応する公開鍵証明書を検索して返送する。そして、業務システム３０００は、署名がこの公開鍵証明書で検証でき、かつその公開鍵証明書のパス検証を行うことにより業務システム３０００の信頼する公開鍵証明書にたどりついたときは、利用許可判定処理へと移行する。なお、Ｘ．５００照合を前提とした名前変換を行うか、ＲＦＣ２４５９照合を前提とした名前変換を行うかは、予め業務システム３０００に設定される。
【００１７】
次に、“利用者アプリケーションにおける利用者許可判定”の場面での名前変換および照合について説明する。例えば業務システム３０００がＲＦＣ２４５９照合を前提としたものであるときは、署名及び認証パスの検証後、利用希望者の公開鍵証明書の所有者名をＲＦＣ２４５９照合を前提とした変換方法で変換し、一方、利用許可者名も当該照合規則を前提とした変換方法で変換する。そして、これらのコードを照合し、前者が後者のいずれかに一致すれば業務システム３０００は利用できるようになる。
【００１８】
【発明が解決しようとする課題】
しかし、上記従来の方法では、ＣＡへの公開鍵登録時にＣＡが行った名前変換の前提となる照合規則を業務システム３０００で認識することができないことから以下の問題が生じる。
【００１９】
つまり、ＣＡへの公開鍵登録時にＣＡが行った名前変換の前提となる照合規則に基づきＣＡが生成したラベルと、業務システム３０００が利用者の公開鍵証明書をディレクトリから取得するために指定した検索ラベルが異なる場合、公開鍵証明書を取得できなく、他の照合規則に対応した検索ラベルで再度ディレクトリアクセスを行う必要がある。したがって、業務システム３０００とディレクトリ２０００の双方で処理の負担が増す。また、業務システム３０００が、かかる２重の検索を行えないようになっているときは、結果的に公開鍵証明書を取得できない。
【００２０】
また、“利用者アプリケーションにおける利用者許可判定”において、ＣＡへの公開鍵登録時にＣＡが行った名前変換の前提となる照合規則がＲＦＣ２４５９照合であるにもかかわらず、業務システムにおいてＸ．５００照合を用いてしまった場合、ＲＦＣ２４５９照合を適用する場合においては別人と判定される利用者が同一人と判定されてしまう場合がある。そのため、業務システムが不正に利用されてしまう畏れがあった。
【００２１】
つまり、ＰＫＩにあっては照合規則が混在しており、それらの照合規則の中でどの照合規則をＣＡが使用しているのかを業務システム３０００等で認識することができないことから様々な問題があり、それが利便性を損ねる原因となっている。
【００２２】
そこで本発明は上記従来の課題に鑑みなされたものであり、その目的とするところは、PKIで利用される多種の照合規則環境において、公開鍵が認証局に登録された際に使用された照合規則を利用者（業務システムを含む）で認識することができないことによる課題を解決し、利便性を向上させる照合規則情報格納装置、照合規則情報格納方法、公開鍵証明書取得装置、公開鍵証明書取得方法、利用可否判定装置、利用可否判定方法、コンピュータプログラムおよびコンピュータプログラムを記録した記録媒体を提供することにある。
【００２３】
【課題を解決するための手段】
上記従来の課題を解決するために、請求項１の本発明は、公開鍵が登録された際および当該登録後の公開鍵証明書の所有者名が公開鍵証明書の検索ラベルに変換された際に使用された照合規則を示す照合規則情報を当該公開鍵証明書に格納する照合規則情報格納手段と、当該公開鍵証明書を登録申請元の利用者端末に送信する公開鍵証明書送信手段とを備える１以上の認証局、１以上の認証局から該認証局で生成された公開鍵証明書とその所有者名から変換された検索ラベルとを受信する公開鍵証明書受信手段と、当該公開鍵証明書と検索ラベルとが格納される公開鍵証明書格納手段と、当該公開鍵証明書の検索に際して送信される検索キーと当該検索ラベルとを照合して公開鍵証明書格納手段から公開鍵証明書を検索して検索キーの送信元に送信する公開鍵証明書送信手段とを備えるディレクトリ、前記認証局から送信された公開鍵証明書を受信した利用者端末から当該公開鍵証明書と署名文書が送信された際に当該公開鍵証明書の公開鍵により前記署名文書の署名検証を行う署名検証手段と、当該公開鍵証明書から照合規則情報を抽出する照合規則情報抽出手段と、当該公開鍵証明書の発行者名を当該照合規則情報に応じた変換方法により検索キーに変換する名前変換手段と、当該検索キーを前記ディレクトリに送信するとともに当該ディレクトリから送信された公開鍵証明書により当該利用者端末から送信された公開鍵証明書の信頼性検証を行う証明書信頼性検証手段とを備える業務処理システムを有することを特徴とするネットワークシステムをもって解決手段とする。
【００２４】
請求項２の本発明は、前記業務処理システムは、利用許可者名を格納された利用許可者名格納手段を備え、前記名前変換手段は、前記署名文書とともに送信された公開鍵証明書の所有者名と前記利用許可者名格納手段に格納された利用許可者名を前記抽出された照合規則情報に応じた変換方法により変換するものであり、前記業務処理システムは、前記変換後の所有者名と変換後の利用許可者名とを照合することにより利用許可するか否かを判定する利用可否判定手段を備えることを特徴とする請求項１記載のネットワークシステムをもって解決手段とする。
【００２５】
請求項３の本発明は、公開鍵が登録された際および当該登録後の公開鍵証明書の所有者名が公開鍵証明書の検索ラベルに変換された際に使用された照合規則を示す照合規則情報をディレクトリに送信する照合規則情報送信手段と、当該公開鍵証明書を登録申請元の利用者端末に送信する公開鍵証明書送信手段とを備える１以上の認証局、１以上の認証局から該認証局で生成された公開鍵証明書とその所有者名から変換された検索ラベルならびに当該変換の際の照合規則情報を受信する公開鍵証明書受信手段と、当該公開鍵証明書と検索ラベルとが格納される公開鍵証明書格納手段と、当該受信された照合規則情報が格納される照合規則情報格納手段と、当該公開鍵証明書の検索に際して送信される検索キーと当該検索ラベルとを照合して公開鍵証明書格納手段から公開鍵証明書を検索して検索キーの送信元に送信するとともに前記格納された照合規則情報をその要求元に送信する公開鍵証明書送信手段とを備えるディレクトリ、前記認証局から送信された公開鍵証明書を受信した利用者端末から当該公開鍵証明書の所有者名が通知されるとともに署名文書が送信された際に前記ディレクトリに要求して照合規則情報を取得する照合規則情報取得手段と、当該公開鍵証明書の所有者名を当該照合規則情報に応じた変換方法により検索キーに変換する名前変換手段と、当該検索キーを前記ディレクトリに送信するとともに当該ディレクトリから送信される公開鍵証明書の公開鍵により前記署名文書の署名検証を行う署名検証手段とを備える業務処理システムを有することを特徴とするネットワークシステムをもって解決手段とする。
【００２６】
請求項４の本発明は、前記業務処理システムは、利用許可者名を格納された利用許可者名格納手段を備え、前記名前変換手段は、前記利用許可者名格納手段に格納された利用許可者名を前記取得された照合規則情報に応じた変換方法により変換するものであり、
前記業務処理システムは、前記変換後の所有者名と変換後の利用許可者名とを照合することにより利用許可するか否かを判定する利用可否判定手段を備えることを特徴とする請求項３記載のネットワークシステムをもって解決手段とする。
【００２７】
請求項５の本発明は、請求項１記載のネットワークシステムの制御方法であって、前記照合規則情報格納手段が、公開鍵が登録された際および当該登録後の公開鍵証明書の所有者名が公開鍵証明書の検索ラベルに変換された際に使用された照合規則を示す照合規則情報を当該公開鍵証明書に格納する照合規則情報格納段階と、前記１以上の認証局の公開鍵証明書送信手段が、当該公開鍵証明書を登録申請元の利用者端末に送信する公開鍵証明書送信段階と、前記公開鍵証明書受信手段が、１以上の認証局から該認証局で生成された公開鍵証明書とその所有者名から変換された検索ラベルとを受信する公開鍵証明書受信段階と、前記ディレクトリの公開鍵証明書送信手段が、公開鍵証明書の検索に際して送信される検索キーと検索ラベルとを照合して公開鍵証明書格納手段から公開鍵証明書を検索して検索キーの送信元に送信する公開鍵証明書送信段階と、前記署名検証手段が、前記認証局から送信された公開鍵証明書を受信した利用者端末から当該公開鍵証明書と署名文書が送信された際に当該公開鍵証明書の公開鍵により前記署名文書の署名検証を行う署名検証段階と、前記照合規則情報抽出手段が、当該公開鍵証明書から照合規則情報を抽出する照合規則情報抽出段階と、前記名前変換手段が、当該公開鍵証明書の発行者名を当該照合規則情報に応じた変換方法により検索キーに変換する名前変換段階と、前記証明書信頼性検証手段が、当該検索キーを前記ディレクトリに送信するとともに当該ディレクトリから送信された公開鍵証明書により当該利用者端末から送信された公開鍵証明書の信頼性検証を行う証明書信頼性検証段階とを備えることを特徴とするネットワークシステムの制御方法をもって解決手段とする。
【００２８】
請求項６の本発明は、請求項３記載のネットワークシステムの制御方法であって、前記１以上の認証局の照合規則情報送信手段が、公開鍵が登録された際および当該登録後の公開鍵証明書の所有者名が公開鍵証明書の検索ラベルに変換された際に使用された照合規則を示す照合規則情報をディレクトリに送信する照合規則情報送信段階と、前記１以上の認証局の公開鍵証明書送信手段が、当該公開鍵証明書を登録申請元の利用者端末に送信する公開鍵証明書送信段階と、前記公開鍵証明書受信手段が、１以上の認証局から該認証局で生成された公開鍵証明書とその所有者名から変換された検索ラベルを受信する公開鍵証明書受信段階と、前記公開鍵証明書受信手段が、１以上の認証局から照合規則情報を受信する照合規則情報受信段階と、前記ディレクトリの公開鍵証明書送信手段が、当該公開鍵証明書の検索に際して送信される検索キーと検索ラベルとを照合して公開鍵証明書格納手段から公開鍵証明書を検索して検索キーの送信元に送信する公開鍵証明書送信段階と、前記ディレクトリの公開鍵証明書送信手段が、前記格納された照合規則情報をその要求元に送信する照合規則情報送信段階と、前記照合規則情報取得手段が、前記認証局から送信された公開鍵証明書を受信した利用者端末から当該公開鍵証明書の所有者名が通知されるとともに署名文書が送信された際に前記ディレクトリに要求して照合規則情報を取得する照合規則情報取得段階と、前記名前変換手段が、当該公開鍵証明書の所有者名を当該照合規則情報に応じた変換方法により検索キーに変換する名前変換段階と、前記署名検証手段が、当該検索キーを前記ディレクトリに送信するとともに当該ディレクトリから送信される公開鍵証明書の公開鍵により前記署名文書の署名検証を行う署名検証段階と備えることを特徴とするネットワークシステムの制御方法をもって解決手段とする。
【００３３】
請求項７の本発明は、請求項５または６記載の方法を実行させるコンピュータプログラムをもって解決手段とする。
【００３４】
請求項８の本発明は、請求項５または６記載の方法を実行させるコンピュータプログラムを記録した記録媒体をもって解決手段とする。
【００３５】
請求項１または５の本発明では、１以上の認証局が照合規則情報を公開鍵証明書に格納して利用者端末に送信し、その照合規則情報を利用した名前変換を行うことで、業務処理システムが公開鍵証明書の信頼性検証を行う。
【００３６】
請求項３または６の本発明では、１以上の認証局が照合規則情報をディレクトリに送信し、その照合規則情報を業務処理システムが取得し、その照合規則情報を利用した名前変換を行うことで、業務処理システムが署名文書の署名検証を行う。
【００３７】
請求項２または４の本発明では、公開鍵証明書からあるいはディレクトリから取得した照合規則情報による利用許可者名の名前変換を行うことで、業務処理システムが利用可否の判定を行う。
【００４０】
請求項７の本発明によれば、PKIで利用される多種の照合規則環境において、公開鍵が認証局に登録された際に使用された照合規則を利用者（業務システムを含む）で認識することができないことによる課題を解決し、利便性を向上させるプログラムを流通させることができる。
【００４１】
請求項８の本発明によれば、PKIで利用される多種の照合規則環境において、公開鍵が認証局に登録された際に使用された照合規則を利用者（業務システムを含む）で認識することができないことによる課題を解決し、利便性を向上させるプログラムを記録媒体により流通させることができる。
【００４２】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して説明する。
[第１の実施の形態]
図１は、本発明の第１の実施の形態を説明するネットワークの構成を示す図である。図１において複数の認証局（Certification Authority：以下ＣＡという）１、ディレクトリ２および業務システム３のそれぞれは、演算装置と記憶装置とを備えるコンピュータシステムであり、特にＣＡ１はオペレータに操作されるため入力装置と表示装置を備える。そして、これらがネットワークとして相互通信を可能に構成されている。また、図１の各利用者端末４は業務システム３を利用しようとする利用者名Ａ、Ｂ、…の各利用者（便宜的に利用者Ａ、…のように記す）により使用されるものであり、演算装置、記憶装置、表示装置および入力装置を備える。なお、記憶装置はハードディスク装置や半導体メモリにより構成される。入力装置はキーボードやマウスである。表示装置はＣＲＴや液晶により構成される。
なお、公開鍵証明書は単に証明書ともいい、図面においてはこの略称で示すものとする。
【００４３】
図２は、ＣＡ１の構成図である。ＣＡ１は、照合規則情報管理テーブル１１と照合規則情報設定部１２と照合規則情報抽出部１３と証明書発行部１４と利用者情報データベース１５を備える。
【００４４】
照合規則情報管理テーブル１１は、ＣＡ１が公開鍵を登録する際および当該登録後の公開鍵証明書の所有者名を公開鍵証明書の検索ラベル（単にラベルという）に変換する際に使用する照合規則を示す照合規則情報が設定される記憶領域である。照合規則情報設定部１２は、オペレータの操作により生成された照合規則情報を照合規則情報管理テーブル１１に設定する処理部である。照合規則情報抽出部１３は、照合規則情報管理テーブル１１に設定された照合規則情報を抽出する処理部である。証明書発行部１４は、公開鍵証明書を発行する処理部であり、証明書生成部１４１と照合規則情報格納部１４２とラベル生成部１４３と証明書送信部１４４とを備える。証明書生成部１４１は照合規則情報を含まない公開鍵証明書を生成する処理部である。照合規則情報格納部１４２は生成された公開鍵証明書に照合規則情報を格納する処理部である。ラベル生成部１４３は、公開鍵証明書の所有者名を照合規則情報を使用して当該公開鍵証明書を検索するためのラベルに変換する処理部である。証明書送信部１４４は、照合規則情報を格納することにより完成した公開鍵証明書や生成されたラベルの送信を行う処理部である。利用者情報データベース１５は、利用許可された公開鍵証明書等の申請者の名前が登録者名として格納されたデータベースである。
【００４５】
なお、照合規則情報を公開鍵証明書に格納した後に署名するように認証局を構成することも可能である。また、ＣＡ１は、公開鍵証明書以外の申請に対応する処理を行う図示しない処理部を備える。また、各ＣＡ１は階層的に構成でき、上位のＣＡ１が下位のＣＡ１の公開鍵証明書を発行することも可能になっている。
【００４６】
照合規則情報は、具体的には、”ＲＦＣ２４５９”や”Ｘ．５００”等のキャラクタコードである。前者は、”ＲＦＣ２４５９照合”という照合規則を示しており、後者は、”Ｘ．５００照合”という照合規則を示している。また、照合規則情報としては、日本語特有の濁音や長音を正規化する照合規則などの任意の照合規則を示すものを設定することが可能である。
【００４７】
図３は、ディレクトリ２の構成図である。ディレクトリ２は、証明書受信部２１と証明書格納部２２と証明書送信部２３とを備える。証明書受信部２１は、ＣＡ１から送信された公開鍵証明書を受信して証明書格納部２２に格納する処理部である。証明書格納部２２は、公開鍵証明書と該公開鍵証明書を検索するためのラベルとが対応づけて格納される記憶領域である。証明書送信部２３は、利用者端末４から送信された検索キーと証明書格納部２２に設定されたラベルとを照合し、両者が等しいと判断したときは、そのラベルに対応する公開鍵証明書を証明書格納部２２から取り出して検索キーの送信元に送信する処理部である。なお、説明の便宜上、ディレクトリ２には、当該照合規則としてＲＦＣ２４５９照合が設定されていることとする。
【００４８】
図４は、業務システム３の構成図である。業務システム３は、署名及び認証パス検証部３１と業務処理部３２と名前変換部３３を備える。署名及び認証パス検証部３１は、利用者端末４から送信された署名文書の署名を検証するとともに業務システム３が信頼する公開鍵証明書までたどりつくかの認証パスの検証を行う処理部であり、証明書データベース３１１と署名検証部３１２と証明書信頼性検証部３１３とを備える。証明書データベース３１１は、信頼実績のあるＣＡの公開鍵証明書が格納される記憶領域である。署名検証部３１２は、署名文書や公開鍵証明書の署名を検証する処理部である。証明書信頼性検証部３１３は、署名文書に添付された公開鍵証明書やディレクトリ２から送信された公開鍵証明書の信頼性を個別に検証する処理部である。
【００４９】
業務処理部３２は、利用許可者名データベース３２１と利用可否判定部３２２と主業務処理部３２３とを備える。利用許可者名データベース３２１は、利用許可された複数の利用者の名前が利用許可者名として格納されたデータベースである。利用可否判定部３２２は、利用許可の判定処理を行う処理部である。主業務処理部３２３は、利用許可されたときに本来の業務を処理する処理部である。
【００５０】
名前変換部３３は、証明書信頼性検証部３１３または利用可否判定部３２２に呼び出された際に変換要求された名前を、照合規則情報が示す照合規則による照合を前提とした変換方法で変換する処理部である。
【００５１】
なお、ＣＡ１、ディレクトリ２および業務システム３の各処理部は、コンピュータプログラムが該プログラムを記憶した記憶媒体から当該各コンピュータシステムに読み込まれて該システムの演算処理装置で実行されることにより実現されるものである。
【００５２】
次に、第１の実施の形態の動作を説明する。
図５は、ＣＡ１の事前処理を示す図である。照合規則情報設定部１２は、オペレータにより入力装置が操作されて照合規則情報１００が生成されると、これを照合規則情報管理テーブル１１に設定する。なお、この処理はいずれのＣＡ１においても行われる。
【００５３】
図６は、ＣＡ１の公開鍵証明書発行に関わる処理を示すフローチャートである。なお、この処理はいずれのＣＡ１においても行われる。
【００５４】
さて、例えば利用者Ａの利用者端末４から申請に関わる情報送信がある（ステップＳ２）と、照合規則情報抽出部１３は、照合規則情報管理テーブル１１から照合規則情報１００を抽出する（ステップＳ３）。なお、この申請が公開鍵証明書作成の申請の場合は、利用者端末４からＣＡ１に対し、公開鍵証明書の所有者名として利用者名Ａや証明対象である所有者Ａの公開鍵などが送信される。
【００５５】
ＣＡ１は、この申請が公開鍵証明書の申請かそれ以外の申請であるを判定し（ステップＳ４）、公開鍵証明書以外の申請であると判定したときはその申請に対応する処理を行う（ステップＳ５）。
【００５６】
一方、公開鍵証明書の申請のときは、作成する公開鍵証明書の所有者名になる利用者名Ａを利用者データベース１５の登録者名と、ステップＳ３で抽出した照合規則情報に対応した照合規則による名前変換を行った後に照合して、利用者名Ａが新規登録者のものか既登録者のものかを判断する等の各種処理を行い（ステップＳ７）、申請が受理された時は、証明書発行部１４が公開鍵証明書を発行する。
【００５７】
具体的には、証明書生成部１４１が、所有者Ａの公開鍵を含みかつ、利用者名Ａを当該作成しようとする公開鍵証明書の所有者名として（以下、これを所有者名Ａという）、当該ＣＡ１の名前を当該公開鍵証明書を発行した発行者名としてそれぞれ含む公開鍵証明書を生成する（ステップＳ９）。
【００５８】
これらの名前は、名前のストリング（String)だけでなく「ストリングタイプ(StringType」を含み、例えばPrintableStringやUTF8Stringを区別できるようになっており、一般にはDistinguish Name(DN)と呼ばれる。また、第１および第２の実施の形態で言及する名前はいずれにしても当該構成を有するものである。
【００５９】
次に照合規則情報格納部１４２はこの生成された公開鍵証明書に照合規則情報１００を格納する（ステップＳ１１）。次に証明書送信部１４４は、照合規則情報１００を設定された公開鍵証明書（以下、利用者名Ａを所有者名として含むので公開鍵証明書Ａ０１という）を利用者端末４に送信する（ステップＳ１３）。なお、利用者端末４は、この公開鍵証明書Ａ０１を受信して自身の記憶装置内に記憶する。
【００６０】
次に、ラベル生成部１４３は、所有者名Ａを照合規則情報１００に応じた変換方法でラベルに変換する（ステップＳ１５）。この変換後の所有者名をラベルＡＬ１という。
【００６１】
例えば、照合規則情報１００が”ＲＦＣ２４５９”や”Ｘ．５００”の場合のように正規化が必要な場合は、所有者名Ａのストリングを、その照合規則情報１００に応じた正規化方法で正規化する（ステップＳ１５１）。そして、所有者名Ａまたは必要な正規化が行われた後の所有者名Ａのストリングを、照合規則情報１００と所有者名に含まれたストリングタイプの組み合わせに応じた変換方法により変換する（ステップＳ１５３）。例えば、照合規則情報１００が”Ｘ．５００”の場合は、所有者名は大文字と小文字のうちの予め決められた一方に変換される。また、照合規則情報１００が”ＲＦＣ２４５９”でかつストリングタイプがPrintableString以外の場合は、所有者名が１６進表記に変換される。なお、照合規則情報によってはステップＳ１５１が不要な場合もある。
【００６２】
以下において、照合規則情報１００が”ＲＦＣ２４５９”でかつストリングタイプがPrintableString以外の場合を例にして言及する。
【００６３】
次に、証明書送信部１４４は、利用者端末４に送信した公開鍵証明書Ａ０１と生成された１６進表記のラベルＡＬ１とを対応づけてディレクトリ２に送信する（ステップＳ１７）。
【００６４】
ディレクトリ２では、証明書受信部２１が、ＣＡ１から送信された公開鍵証明書Ａ０１とラベルＡＬ１とを受信し、さらにこれらを対応づけて証明書格納部２２に格納する。
【００６５】
なお、ＣＡ１は、いずれの利用者端末４からの公開鍵証明書の申請に対しても上記した公開鍵証明書発行に関わる処理を行う。また、上位のＣＡ１にあっては、下位のＣＡ１からの申請に対しても上記した公開鍵証明書発行に関わる処理を行う。このときの公開鍵証明書には下位のＣＡ１の名前が所有者名として含まれる。また、各ＣＡ１は、該ＣＡ１自身についても上記した公開鍵証明書発行に関わる処理を行う。このときの公開鍵証明書には該ＣＡ１の名前が所有者名および発行者名として含まれる。
【００６６】
このようにしてディレクトリ２の証明書格納部２２には、各利用者および各ＣＡ１の公開鍵証明書が格納される。
【００６７】
さて、利用者Ａが利用者端末４から業務システム３を利用しようとするときは以下の如く処理がなされる。なお、この処理は、この処理はいずれの利用者端末４からの利用に際しても行われる。
【００６８】
図７は、業務システム３の処理を示すフローチャートである。利用者端末４からは、業務システム３の利用に際して、利用者の署名を含む署名文書と公開鍵証明書Ａ０１が送信される（ステップＳ３０）。
【００６９】
まず、署名及び認証パス検証部３１は、署名検証部３１２により公開鍵証明書Ａ０１を用いて署名文書の署名の検証を試みる（ステップＳ３１）。ここで、検証できなかったときは処理を終了させる一方、検証できたときは、証明書信頼性検証部３１３が、その公開鍵証明書Ａ０１を検証対象にして証明書信頼性検証処理を行う（ステップＳ３３）。
【００７０】
図８は、証明書信頼性検証処理を示すフローチャートである。先ず、検証対象である公開鍵証明書Ａ０１から照合規則情報１００を取り出し所定の記憶領域に格納する（ステップＳ３３１）。次に、証明書信頼性検証部３１３は、公開鍵証明書Ａ０１に含まれた発行者名を取り出す（ステップＳ３３３）とともに、名前変換部３３を呼び出して、この発行者名を変換対象として名前変換を指示する。名前変換部３３は、この変換要求に応じ名前変換処理を行う（ステップＳ３３５）。
【００７１】
図９は、名前変換部３３が行う名前変換処理を示すフローチャートである。
【００７２】
名前変換部３３は、照合規則情報１００が”ＲＦＣ２４５９”や”Ｘ．５００”の場合のように正規化が必要な場合は、発行者名のストリングを、その照合規則情報１００に応じた正規化方法で正規化する（ステップＳ３３５１）。そして、公開鍵証明書Ａ０１に含まれた利用者名Ａまたは必要な正規化が行われた後の発行者名のストリングを、照合規則情報１００に応じた変換方法により変換する（ステップＳ３３５３）。この名前変換処理は、ＣＡ１の証明書発行部１４が行ったステップＳ１５１および１５２の処理と同様のものである。具体例では、発行者名が１６進表記の名前に変換される。
【００７３】
図８に戻り、証明書信頼性検証処理の説明を続ける。このようにして名前変換処理が終わると、証明書信頼性検証部３１３は、公開鍵証明書の取得要求を行うが、そのときは変換後の発行者名を検索キーとしてディレクトリ２に送信する（ステップＳ３３７）。
【００７４】
これに対し、ディレクトリ２では、証明書送信部２３が、送信された検索キーと証明書格納部２２内に設定されたラベルとを比較し、両者が等しいと判断したときは、そのラベルに対応する公開鍵証明書を証明書格納部２２から取り出して検索キーの送信元である業務システム３に送信する。
【００７５】
証明書信頼性検証部３１３は、署名検証部３１２に指示して、ディレクトリ２から取得した公開鍵証明書で検証対象の公開鍵証明書の署名を検証させる（ステップＳ３３８）。そして、この検証ができたときは、証明書信頼性検証部３１３が、送信された公開鍵証明書が信頼できるか否かを判定する（ステップＳ３３９）。具体的には、証明書データベース３１１の公開鍵証明書のいずれかに一致するか否かを判定する。一致すると判定したときは、署名及び認証パス検証部３１に検証終了を通知し（ステップＳ３４１）、一方、一致しないと判定されたときは、送信された公開鍵証明書を検証対象として設定し（ステップＳ３４３）、その後処理を終える。
【００７６】
図７に戻り、業務システム３の処理の説明を続ける。
【００７７】
署名及び認証パス検証部３１は、検証終了の通知の有無により公開鍵証明書のパス検証が終了したか否かを判定し（ステップＳ３５）、検証終了していない場合は、証明書信頼性検証部３１３が証明書信頼性検証処理を行う一方、検証終了した場合は、業務処理部３２に制御が移される。なお、証明書信頼性検証部３１３は、証明書信頼性検証部３１３がステップＳ３４２で設定した公開鍵証明書を検証対象として証明書信頼性検証処理を行う。この検証終了までに至る処理を公開鍵証明書のパス検証という。
【００７８】
業務処理部３２の処理にあっては、先ず利用可否判定部３２２が利用許可判定処理を行う（ステップＳ３７）。
【００７９】
図１０は、利用可否判定部３２２が行う利用許可判定処理を示すフローチャート図である。
【００８０】
利用可否判定部３２２は、利用希望者の公開鍵証明書の所有者名を変換する（ステップＳ３７１）。具体的には名前変換部３３を呼び出して、最初に利用者端末４から送信された利用希望者の公開鍵証明書の所有者名を変換対象として名前変換を指示する。名前変換部３３は、この変換要求に対し、上述のように照合規則情報１００に応じた名前変換処理を行い、変換後の利用希望者名を利用可否判定部３２２に返す。
【００８１】
次に、利用可否判定部３２２は、利用許可者名データベース３２１の各利用許可者名を変換する（ステップＳ３７３）。具体的には、名前変換部３３を呼び出して、利用許可者名データベース３２１の各利用許可者名を変換対象として名前変換を指示する。名前変換部３３は、この変換要求に対し、上述のように照合規則情報１００に応じた名前変換処理を行い、変換後の利用許可者名を利用可否判定部３２２に返す。
【００８２】
次に、利用可否判定部３２２は、変換後の利用希望者の公開鍵証明書の所有者名が変換後の利用許可者名のいずれかに一致するか否かを判定する（ステップＳ３７５）。
【００８３】
図７に戻り、業務システム３の処理の説明を続ける。
図１０におけるステップＳ３７５で、変換後の利用希望者の公開鍵証明書の所有者名が変換後の利用許可者名のいずれかに一致すると判定されたときは、主業務処理部３２３が利用者端末４に対して業務処理を提供する（ステップＳ３９）。つまり、利用者端末４からの指示にしたがって業務処理を行い、その結果を利用者端末４に送信し表示等させる。
【００８４】
一方、利用可否判定部３２２は、変換後の利用希望者の公開鍵証明書の所有者名が変換後の利用許可者名のいずれにも一致しないと判定されたときは、利用者端末４に対し業務処理を提供できないという利用不可通知を行う（ステップＳ４１）。
【００８５】
以上説明したように、本発明の第１の実施の形態は、公開鍵が登録された際および当該登録後の公開鍵証明書の所有者名が公開鍵証明書の検索ラベルに変換された際に使用された照合規則を示す照合規則情報を当該公開鍵証明書に格納する照合規則情報格納手段（照合規則情報格納部１４２）／照合規則情報格納段階（ステップＳ１１）と、当該公開鍵証明書を登録申請元の利用者端末に送信する公開鍵証明書送信手段（証明書送信部１４４）／公開鍵証明書送信段階（ステップＳ１３）と、１以上の認証局から該認証局で生成された公開鍵証明書とその所有者名から変換された検索ラベルとを受信する公開鍵証明書受信手段（証明書受信部２１）／公開鍵証明書受信段階（ステップＳ１７）と、当該公開鍵証明書と検索ラベルとが格納される公開鍵証明書格納手段（証明書格納部２２）と、当該公開鍵証明書の検索に際して送信される検索キーと当該検索ラベルとを照合して公開鍵証明書格納手段から公開鍵証明書を検索して検索キーの送信元に送信する公開鍵証明書送信手段（証明書送信部２３）／公開鍵証明書送信段階（ステップＳ３３７とＳ３３８の間のディレクトリ２からの公開鍵証明書送信）と、認証局から送信された公開鍵証明書を受信した利用者端末から当該公開鍵証明書と署名文書が送信された際に当該公開鍵証明書の公開鍵により署名文書の署名検証を行う署名検証手段（署名検証部３１２）／署名検証段階（ステップＳ３１）と、当該公開鍵証明書から照合規則情報を抽出する照合規則情報抽出手段（証明書信頼性検証部３１３）／照合規則情報抽出段階（ステップＳ３３１）と、当該公開鍵証明書の発行者名を当該照合規則情報に応じた変換方法により検索キーに変換する名前変換手段（名前変換部３３）／名前変換段階（ステップＳ３３５）と、当該検索キーをディレクトリに送信するとともに当該ディレクトリから送信された公開鍵証明書により当該利用者端末から送信された公開鍵証明書の信頼性検証を行う証明書信頼性検証手段（証明書信頼性検証部３１３）／証明書信頼性検証段階（ステップＳ３３）とを備えるので、業務処理システムが公開鍵証明書の信頼性検証を行うことができる。
【００８６】
また、業務処理システムは、利用許可者名を格納された利用許可者名格納手段（利用許可者名データベース３２１）を備え、名前変換手段は、署名文書とともに送信された公開鍵証明書の所有者名と利用許可者名格納手段に格納された利用許可者名を当該抽出された照合規則情報に応じた変換方法により変換するものであり、業務処理システムは、変換後の所有者名と変換後の利用許可者名とを照合することにより利用許可するか否かを判定する利用可否判定手段（利用可否判定部３２２）を備えるので、PKIで利用される多種の照合規則環境において、業務処理システムが利用可否の判定を行うことができる。
【００８８】
[第２の実施の形態]
図１１は、本発明の第２の実施の形態を説明するネットワークの構成を示す図である。第２の実施の形態では、図１のネットワーク構成において、ＣＡ１に代えてＣＡ１Ａが、ディレクトリ２に代えてディレクトリ２Ａが、業務システム３に代えて業務システム３Ａがそれぞれ適用される。第２の実施の形態の説明でも、照合規則情報１００が”ＲＦＣ２４５９”でかつストリングタイプがPrintableString以外の場合を例にして言及する。
【００８９】
図１２はＣＡ１Ａの構成図であり、図１３はディレクトリ２Ａの構成図であり、図１４は業務システム３Ａの構成図である。ＣＡ１Ａは、その構成要素のほとんどがＣＡ１のものと共通であるため、ＣＡ１の構成要素との差違を説明する。なお、ディレクトリ２Ａおよび業務システム３Ａについても同様である。
【００９０】
図１２に示すようにＣＡ１Ａは、証明書発行部１４に代えて、照合規則情報格納部１４２を備えない証明書発行部１４Ａを設け、さらに、照合規則情報送信部１６を加入した構成となっている。照合規則情報送信部１６は、照合規則情報抽出部１３により抽出された照合規則情報をディレクトリ２Ａに送信する処理部である。
【００９１】
図１３に示すようにディレクトリ２Ａは照合規則情報格納部２４を加入した構成となっている。照合規則情報格納部２４は、証明書受信部２１がＣＡ１Ａから受信した照合規則情報が格納される記憶領域である。照合規則情報格納部２４は、具体的には、NameComparisonType属性型のエントリといった特定のエントリが使用される。
【００９２】
図１４に示すように業務システム３Ａは、署名及び認証パス検証部３１に代えて署名及び認証パス検証部３１Ａを備える。署名及び認証パス検証部３１Ａには、署名及び認証パス検証部３１に照合規則情報取得部３１４を加入した構成となっている。照合規則情報取得部３１４は、署名文書の署名の検証に先立ち、ディレクトリ２Ａから照合規則情報を取得する処理部である。取得された照合規則情報は名前変換部３３で利用される。
【００９３】
次に、第２の実施の形態の動作を説明する。
先ず、図５を参照して説明した処理と同様に、ＣＡ１Ａの照合規則情報設定部１２は、オペレータにより入力装置が操作されて照合規則情報１００が生成されると、これを照合規則情報管理テーブル１１に設定する。すなわち、この処理は第１の実施の形態の処理と同様であり、各ＣＡ１Ａで行われる。
【００９４】
図１５は、ＣＡ１Ａが行う照合規則情報の格納処理を示す図である。
【００９５】
さて、例えばオペレータが入力装置に対し各種ポリシーの設定や変更の操作を行うと、照合規則情報抽出部１３は、照合規則情報管理テーブル１１から照合規則情報１００を抽出する（ステップＳ５１）。そして、照合規則情報送信部１６が、抽出された照合規則情報をディレクトリ２Ａに送信する（ステップＳ５３）。
【００９６】
ディレクトリ２Ａでは、証明書受信部２１が、ＣＡ１Ａから送信された照合規則情報を受信し、これを照合規則情報格納部２４に格納する。
【００９７】
次に、図６を説明の便宜上参照して、ＣＡ１Ａの公開鍵証明書発行に関わる処理を説明する。なお、各ステップの参照番号は流用することにする。この処理はいずれのＣＡ１Ａにおいても行われる。
【００９８】
さて、例えば利用者Ａの利用者端末４から申請に関わる情報送信がある（ステップＳ２）と、照合規則情報抽出部１３は、照合規則情報管理テーブル１１から照合規則情報１００を抽出する（ステップＳ３）。なお、この申請が公開鍵証明書作成の申請の場合は、利用者端末４からＣＡ１Ａに対し、公開鍵証明書の所有者名として利用者名Ａや証明対象である所有者Ａの公開鍵などが送信される。
【００９９】
ＣＡ１Ａは、この申請が公開鍵証明書の申請かそれ以外の申請であるを判定し（ステップＳ３）、公開鍵証明書以外の申請であると判定したときはその申請に対応する処理を行う（ステップＳ５）。
【０１００】
一方、公開鍵証明書の申請のときは、作成する公開鍵証明書の所有者名になる利用者名Ａを利用者データベース１５の登録者名と、ステップＳ３で抽出した照合規則情報に対応した照合規則による名前変換を行った後に照合して、利用者名Ａが新規登録者のものか既登録者のものかを判断する等の各種処理を行い（ステップＳ７）、申請が受理された時は、証明書発行部１４が公開鍵証明書を作成して送信する。
【０１０１】
具体的には、証明書生成部１４１が、所有者Ａの公開鍵を含みかつ、利用者名Ａを当該作成しようとする公開鍵証明書の所有者名として（以下、所有者名Ａという）、当該ＣＡ１Ａの名前を当該公開鍵証明書を発行した発行者名としてそれぞれ含む公開鍵証明書を生成する（ステップＳ９）。
【０１０２】
証明書送信部１４４は、生成された公開鍵証明書（以下、公開鍵証明書Ａ０２という）を利用者端末４に送信する（ステップＳ１３）。つまり、ステップＳ１１の処理は行われないのである。なお、利用者端末４は、この公開鍵証明書Ａ０２を受信して記憶装置に記憶する。
【０１０３】
次に、ラベル生成部１４３は、所有者名Ａを照合規則情報１００に応じた変換方法でラベルに変換する（ステップＳ１５）。この変換後の所有者名をラベルＡＬ１という。
【０１０４】
次に、証明書送信部１４４は、利用者端末４に送信した公開鍵証明書Ａ０２と生成されたラベルＡＬ１とを対応づけてディレクトリ２Ａに送信する（ステップＳ１７）。
【０１０５】
ディレクトリ２Ａでは、証明書受信部２１が、ＣＡ１Ａから送信された公開鍵証明書Ａ０２とラベルＡＬ１とを受信し、さらにこれらを対応づけて証明書格納部２２に格納する。
【０１０６】
なお、ＣＡ１Ａは、いずれの利用者端末４からの公開鍵証明書の申請に対しても上記した公開鍵証明書発行に関わる処理を行う。また、上位のＣＡ１Ａにあっては、下位のＣＡ１Ａからの申請に対しても上記した公開鍵証明書発行に関わる処理を行う。このときの公開鍵証明書には下位のＣＡ１Ａの名前が所有者名として含まれる。また、各ＣＡ１Ａは、該ＣＡ１Ａ自身についても上記した公開鍵証明書発行に関わる処理を行う。このときの公開鍵証明書には該ＣＡ１Ａの名前が所有者名および発行者名として含まれる。
【０１０７】
このようにしてディレクトリ２Ａの証明書格納部２２には、各利用者および各ＣＡ１Ａの公開鍵証明書が格納される。
【０１０８】
図１６は、業務システム３Ａの処理を示すフローチャートである。
【０１０９】
利用者端末４からは、業務システム３Ａの利用に際して、利用者の署名を含む署名文書が送信され、さらに利用者Ａの公開鍵証明書の所有者名（例ではPrintableString以外のストリングタイプを含む）が利用希望者名として通知される（ステップＳ６０）。まず、署名及び認証パス検証部３１Ａが署名及び認証パスを検証するのであるが、最初に照合規則情報取得部３１４が、ディレクトリ２Ａに対し照合規則情報を要求する（ステップＳ６１）。
【０１１０】
ディレクトリ２Ａでは、証明書送信部２３が、照合規則情報格納部２４から照合規則情報を読み出して、業務システム３Ａに送信し、照合規則情報取得部３１４は、送信された照合規則情報を受信する（ステップＳ６３）。
【０１１１】
署名及び認証パス検証部３１Ａは、名前変換部３３を呼び出して、この利用希望者名Ａを変換対象として名前変換を指示する。名前変換部３３は、図９を参照して説明した内容と同様の名前変換処理を行う（ステップＳ６５）。
【０１１２】
次に、署名及び認証パス検証部３１Ａは公開鍵証明書の取得要求を行うが、そのときは変換後の利用希望者名を検索キーとしてディレクトリ２Ａに送信する（ステップＳ６７）。
【０１１３】
これに対し、ディレクトリ２Ａでは、証明書送信部２３が、送信された検索キーと証明書格納部２２内に設定されたラベルと照合し、両者が等しいと判断したときは、そのラベルに対応する公開鍵証明書を証明書格納部２２から取り出して検索キーの送信元である業務システム３Ａに送信する。
【０１１４】
次に、署名及び認証パス検証部３１Ａは、この公開鍵証明書Ａ０２を最初の検証対象として、図７のステップＳ３１からステップＳ３５までの処理と同様の処理を行い、署名及び認証パスの検証が終了すると業務処理部３２が図７のステップＳ３７以降の処理と同様の処理を行う。なお、ステップＳ３３では証明書信頼性検証部３１３が、ステップＳ３７では利用可否判定部３２２がそれぞれ呼び出される。
【０１１５】
以上説明したように、本発明の第２の実施の形態は、公開鍵が登録された際および当該登録後の公開鍵証明書の所有者名が公開鍵証明書の検索ラベルに変換された際に使用された照合規則を示す照合規則情報をディレクトリに送信する照合規則情報送信手段（照合規則情報送信部１６）／照合規則情報送信段階（ステップＳ５３）と、当該公開鍵証明書を登録申請元の利用者端末に送信する公開鍵証明書送信手段（証明書送信部１４４）／公開鍵証明書送信段階（ステップＳ１３）と、１以上の認証局から該認証局で生成された公開鍵証明書とその所有者名から変換された検索ラベルならびに当該変換の際の照合規則情報を受信する公開鍵証明書受信手段（証明書受信部２１）／公開鍵証明書受信段階（ステップＳ１７）と、照合規則情報を受信する公開鍵証明書受信手段（証明書受信部２１）／照合規則情報受信段階（ステップＳ５３）と、当該公開鍵証明書と検索ラベルとが格納される公開鍵証明書格納手段（証明書格納部２２）と、当該受信された照合規則情報が格納される照合規則情報格納手段（照合規則情報格納部２４）と、当該公開鍵証明書の検索に際して送信される検索キーと当該検索ラベルとを照合して公開鍵証明書格納手段から公開鍵証明書を検索して検索キーの送信元に送信する公開鍵証明書送信手段（証明書送信部２３）／公開鍵証明書送信段階（ステップＳ３３７とＳ３３８の間のディレクトリ２からの公開鍵証明書送信）と、当該格納された照合規則情報をその要求元に送信する公開鍵証明書送信手段（証明書送信部２３）／照合規則情報送信段階（ステップＳ６１とＳ６３の間のディレクトリ２からの照合規則情報送信）と、認証局から送信された公開鍵証明書を受信した利用者端末から当該公開鍵証明書の所有者名が通知されるとともに署名文書が送信された際にディレクトリに要求して照合規則情報を取得する照合規則情報取得手段（照合規則情報取得部３１４）／照合規則情報取得段階（ステップＳ６３）と、当該公開鍵証明書の所有者名を当該照合規則情報に応じた変換方法により検索キーに変換する名前変換手段（名前変換部３３）／名前変換段階（ステップＳ６５）と、当該検索キーをディレクトリに送信するとともに当該ディレクトリから送信される公開鍵証明書の公開鍵により署名文書の署名検証を行う署名検証手段（署名及び認証パス検証部３１Ａ）／署名検証段階（ステップＳ３１）とを備えるので、業務処理システムが署名検証を行うことができる。
【０１１６】
また、業務処理システムは、利用許可者名を格納された利用許可者名格納手段（利用許可者名データベース３２１を備え、名前変換手段は、利用許可者名格納手段に格納された利用許可者名を前記取得された照合規則情報に応じた変換方法により変換するものであり、業務処理システムは、変換後の所有者名と変換後の利用許可者名とを照合することにより利用許可するか否かを判定する利用可否判定手段（利用可否判定部３２２）を備えるので、PKIで利用される多種の照合規則環境において、業務処理システムが利用可否の判定を行うことができる
【０１１７】
なお、上記説明した処理を実行させるコンピュータプログラムは、半導体メモリ、磁気ディスク、光ディスク、光磁気ディスク、磁気テープなどのコンピュータ読み取り可能な記録媒体に記録したり、インターネットなどの通信網を介して伝送させて、広く流通させることができる。
【０１１８】
【発明の効果】
以上説明したように、本発明によれば、PKIで利用される多種の照合規則環境において、公開鍵証明書を確実に取得することができるようになり、また、的確な利用可否の判定を行うことができるので、利便性を格段に向上させることができる。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態を説明するネットワークの構成を示す図である。
【図２】ＣＡ１の構成図である。
【図３】ディレクトリ２の構成図である。
【図４】業務システム３の構成図である。
【図５】ＣＡ１の事前処理を示す図である。
【図６】ＣＡ１の公開鍵証明書発行に関わる処理を示すフローチャートである。
【図７】業務システム３の処理を示すフローチャートである。
【図８】証明書信頼性検証処理を示すフローチャートである。
【図９】名前変換部３３が行う名前変換処理を示すフローチャートである。
【図１０】利用可否判定部３２２が行う利用許可判定処理を示すフローチャート図である。
【図１１】本発明の第２の実施の形態を説明するネットワークの構成を示す図である。
【図１２】ＣＡ１Ａの構成図である。
【図１３】ディレクトリ２Ａの構成図である。
【図１４】業務システム３Ａの構成図である。
【図１５】ＣＡ１Ａが行う照合規則情報の格納処理を示す図である。
【図１６】業務システム３Ａの処理を示すフローチャートである。
【図１７】ＰＫＩにおける名前変換と照合の場面を示す図である。
【図１８】Ｘ．５００照合とＲＦＣ２４５９照合を前提とした名前変換を示す図である。
【符号の説明】
１，１Ａ ＣＡ
２，２Ａ ディレクトリ
３，３Ａ 業務システム
４ 利用者端末
１１ 照合規則情報管理テーブル
１２ 照合規則情報設定部
１３ 照合規則情報抽出部
１４，１４Ａ 証明書発行部
１５ 利用者情報データベース
１６ 照合規則情報送信部
２１ 証明書受信部
２２ 証明書格納部
２３ 証明書送信部
２４ 照合規則情報格納部
３１，３１Ａ 署名及び認証パス検証部
３２ 業務処理部
３３ 名前変換部
１００ 照合規則情報
１４１ 証明書生成部
１４２ 照合規則情報格納部
１４３ ラベル生成部
１４４ 証明書送信部
３１１ 証明書データベース
３１２ 署名検証部
３１３ 証明書信頼性検証部
３１４ 照合規則情報取得部
３２１ 利用許可者名データベース
３２２ 利用可否判定部
３２３ 主業務処理部
Ａ 利用者名
Ａ０１，Ａ０２ 公開鍵証明書
ＡＬ１ ラベル
【発明の属する技術分野】
本発明は、PKIで利用される多種の照合規則環境において、公開鍵が認証局に登録された際に使用された照合規則を利用者（業務システムを含む）で認識することができないことによる課題を解決し、利便性を向上させる照合規則情報格納装置、照合規則情報格納方法、公開鍵証明書取得装置、公開鍵証明書取得方法、利用可否判定装置、利用可否判定方法、コンピュータプログラムおよびコンピュータプログラムを記録した記録媒体に関する。
【０００２】
【従来の技術】
ＰＫＩ（公開鍵基盤：PublicKeyInfrastructure）においては、“認証局（ＣＡ）への公開鍵登録”,“ディレクトリからの公開鍵証明書取得”,“利用者アプリケーションにおける利用者許可判定”の３つの場面において、照合規則に応じた名前変換および照合が必要である。
【０００３】
図１７は、ＰＫＩにおける名前変換と照合の場面を示す図である。
【０００４】
先ず、“ＣＡへの公開鍵登録”の場面での名前変換について説明する。ＣＡ１０００は、利用者から申請された公開鍵登録申請書における公開鍵証明書の作成対象となる所有者名を、Ｘ．５００照合やＲＦＣ２４５９照合にしたがった変換方法で、ディレクトリにおける公開鍵証明書の検索ラベルとしての名前に変換する。
【０００５】
図１８は、Ｘ．５００照合とＲＦＣ２４５９照合を前提とした名前変換を示す図である。
【０００６】
公開鍵証明書の所有者名はDistinguished Name（DN）、つまりストリングタイプ（形式）とそのストリング（内容）とから成り、このストリングタイプは、例えばPrintableStringやUTF8Stringを区別できるものとして申請される。また、所有者名のストリングは、人や団体などの登場人物（Party）を特定するものであり、通常は大文字と小文字が混在しており、また任意の箇所にスペース（図１７，１８では￥で示す）を含んでいる。
【０００７】
さて、この所有者名の名前変換を説明する前に、ＲＦＣ２４５９に規定されたＸ．５００照合とＲＦＣ２４５９照合の規則を説明する。
【０００８】
【数１】
【０００９】
ここで所有者名が、▲１▼PrintableStringのa\\b，▲２▼UTF8Stringのa\\b，▲３▼PrintableStringのA\B，▲４▼UTF8StringのA\B，▲５▼PrintableStringのA\\B，▲６▼UTF8StringのA\\Bである場合を説明する。
【００１０】
Ｘ．５００照合による名前変換では、▲１▼から▲６▼すべてが（A\B）に変換される。一方、ＲＦＣ２４５９照合では、▲１▼と▲３▼と▲５▼は（PrintableString:A\B）に変換され、▲２▼と▲４▼と▲６▼はそれぞれ異なる名前（UTF8String:a\\b,UTF8String:A\B,UTF8String:A\\B)に変換される。
【００１１】
なお、ＣＡ１０００は、変換前の名前を所有者名として含んだ公開鍵証明書を公開鍵登録申請者へと発行し、公開鍵登録申請者はこの公開鍵証明書を取得する。
【００１２】
そして公開鍵証明書はディレクトリ２０００に登録されるのであるが、その際には検索ラベルに対応づけられた格納場所（エントリ）にLDAPプロトコルにより格納される。
【００１３】
ただし、検索ラベルを全て“文字列”で格納すると、例えばPrintableStringのA\BとUTF8StringのA\Bに代表されるようなＲＦＣ２４５９照合におけるストリングタイプ区別を行うことができなくなるため、検索ラベルは、Ｘ．５００照合の時とＲＦＣ２４５９照合のPrintableStringの場合には文字列で、一方、ＲＦＣ２４５９照合のPrintableString以外の場合には16進数で格納される。これにより、ＣＡとディレクトリにおける名前の１対１対応を可能としている。これは、RFC2253において、“値のDER形式の再構成を要求する（つまりRFC2459に示されるストリング区別を行うような）アプリケーションは、文字列でアクセスするべきではなく、16進数表記でアクセスするべき”と規定されていることによるものである。
【００１４】
次に、“ディレクトリからの公開鍵証明書取得”の場面での名前変換について説明する。
公開鍵証明書の発行を受けた利用者が、業務処理を提供するコンピュータシステム（業務システム３０００）を利用しようとするときは、利用者（利用希望者）に使用される利用者端末４から、業務システム３０００に対し、ディジタル署名を含んだ署名文書が送信され、さらに利用希望者名の公開鍵証明書の所有者名が通知されることになる。
【００１５】
この署名文書を受け取った業務システム３０００は、ディレクトリ２へアクセスすることにより利用希望者の公開鍵証明書を取得し、この公開鍵証明書でディジタル署名の検証を行う。
【００１６】
ここでも、“ＣＡへの公開鍵登録”の場面での名前変換と同様の名前変換が行われる。つまり、例えば、利用希望者名としてUTF8String:A\\Bが送信されると、業務システム３０００では、例えばＸ．５００照合を前提とした名前変換により、UTF8String:A\\BをA\B(文字列)に変換する。そして、これを検索キーとしてディレクトリ２０００に公開鍵証明書を要求すると、ディレクトリ２０００は、これに対応する公開鍵証明書を検索して返送する。そして、業務システム３０００は、署名がこの公開鍵証明書で検証でき、かつその公開鍵証明書のパス検証を行うことにより業務システム３０００の信頼する公開鍵証明書にたどりついたときは、利用許可判定処理へと移行する。なお、Ｘ．５００照合を前提とした名前変換を行うか、ＲＦＣ２４５９照合を前提とした名前変換を行うかは、予め業務システム３０００に設定される。
【００１７】
次に、“利用者アプリケーションにおける利用者許可判定”の場面での名前変換および照合について説明する。例えば業務システム３０００がＲＦＣ２４５９照合を前提としたものであるときは、署名及び認証パスの検証後、利用希望者の公開鍵証明書の所有者名をＲＦＣ２４５９照合を前提とした変換方法で変換し、一方、利用許可者名も当該照合規則を前提とした変換方法で変換する。そして、これらのコードを照合し、前者が後者のいずれかに一致すれば業務システム３０００は利用できるようになる。
【００１８】
【発明が解決しようとする課題】
しかし、上記従来の方法では、ＣＡへの公開鍵登録時にＣＡが行った名前変換の前提となる照合規則を業務システム３０００で認識することができないことから以下の問題が生じる。
【００１９】
つまり、ＣＡへの公開鍵登録時にＣＡが行った名前変換の前提となる照合規則に基づきＣＡが生成したラベルと、業務システム３０００が利用者の公開鍵証明書をディレクトリから取得するために指定した検索ラベルが異なる場合、公開鍵証明書を取得できなく、他の照合規則に対応した検索ラベルで再度ディレクトリアクセスを行う必要がある。したがって、業務システム３０００とディレクトリ２０００の双方で処理の負担が増す。また、業務システム３０００が、かかる２重の検索を行えないようになっているときは、結果的に公開鍵証明書を取得できない。
【００２０】
また、“利用者アプリケーションにおける利用者許可判定”において、ＣＡへの公開鍵登録時にＣＡが行った名前変換の前提となる照合規則がＲＦＣ２４５９照合であるにもかかわらず、業務システムにおいてＸ．５００照合を用いてしまった場合、ＲＦＣ２４５９照合を適用する場合においては別人と判定される利用者が同一人と判定されてしまう場合がある。そのため、業務システムが不正に利用されてしまう畏れがあった。
【００２１】
つまり、ＰＫＩにあっては照合規則が混在しており、それらの照合規則の中でどの照合規則をＣＡが使用しているのかを業務システム３０００等で認識することができないことから様々な問題があり、それが利便性を損ねる原因となっている。
【００２２】
そこで本発明は上記従来の課題に鑑みなされたものであり、その目的とするところは、PKIで利用される多種の照合規則環境において、公開鍵が認証局に登録された際に使用された照合規則を利用者（業務システムを含む）で認識することができないことによる課題を解決し、利便性を向上させる照合規則情報格納装置、照合規則情報格納方法、公開鍵証明書取得装置、公開鍵証明書取得方法、利用可否判定装置、利用可否判定方法、コンピュータプログラムおよびコンピュータプログラムを記録した記録媒体を提供することにある。
【００２３】
【課題を解決するための手段】
上記従来の課題を解決するために、請求項１の本発明は、公開鍵が登録された際および当該登録後の公開鍵証明書の所有者名が公開鍵証明書の検索ラベルに変換された際に使用された照合規則を示す照合規則情報を当該公開鍵証明書に格納する照合規則情報格納手段と、当該公開鍵証明書を登録申請元の利用者端末に送信する公開鍵証明書送信手段とを備える１以上の認証局、１以上の認証局から該認証局で生成された公開鍵証明書とその所有者名から変換された検索ラベルとを受信する公開鍵証明書受信手段と、当該公開鍵証明書と検索ラベルとが格納される公開鍵証明書格納手段と、当該公開鍵証明書の検索に際して送信される検索キーと当該検索ラベルとを照合して公開鍵証明書格納手段から公開鍵証明書を検索して検索キーの送信元に送信する公開鍵証明書送信手段とを備えるディレクトリ、前記認証局から送信された公開鍵証明書を受信した利用者端末から当該公開鍵証明書と署名文書が送信された際に当該公開鍵証明書の公開鍵により前記署名文書の署名検証を行う署名検証手段と、当該公開鍵証明書から照合規則情報を抽出する照合規則情報抽出手段と、当該公開鍵証明書の発行者名を当該照合規則情報に応じた変換方法により検索キーに変換する名前変換手段と、当該検索キーを前記ディレクトリに送信するとともに当該ディレクトリから送信された公開鍵証明書により当該利用者端末から送信された公開鍵証明書の信頼性検証を行う証明書信頼性検証手段とを備える業務処理システムを有することを特徴とするネットワークシステムをもって解決手段とする。
【００２４】
請求項２の本発明は、前記業務処理システムは、利用許可者名を格納された利用許可者名格納手段を備え、前記名前変換手段は、前記署名文書とともに送信された公開鍵証明書の所有者名と前記利用許可者名格納手段に格納された利用許可者名を前記抽出された照合規則情報に応じた変換方法により変換するものであり、前記業務処理システムは、前記変換後の所有者名と変換後の利用許可者名とを照合することにより利用許可するか否かを判定する利用可否判定手段を備えることを特徴とする請求項１記載のネットワークシステムをもって解決手段とする。
【００２５】
請求項３の本発明は、公開鍵が登録された際および当該登録後の公開鍵証明書の所有者名が公開鍵証明書の検索ラベルに変換された際に使用された照合規則を示す照合規則情報をディレクトリに送信する照合規則情報送信手段と、当該公開鍵証明書を登録申請元の利用者端末に送信する公開鍵証明書送信手段とを備える１以上の認証局、１以上の認証局から該認証局で生成された公開鍵証明書とその所有者名から変換された検索ラベルならびに当該変換の際の照合規則情報を受信する公開鍵証明書受信手段と、当該公開鍵証明書と検索ラベルとが格納される公開鍵証明書格納手段と、当該受信された照合規則情報が格納される照合規則情報格納手段と、当該公開鍵証明書の検索に際して送信される検索キーと当該検索ラベルとを照合して公開鍵証明書格納手段から公開鍵証明書を検索して検索キーの送信元に送信するとともに前記格納された照合規則情報をその要求元に送信する公開鍵証明書送信手段とを備えるディレクトリ、前記認証局から送信された公開鍵証明書を受信した利用者端末から当該公開鍵証明書の所有者名が通知されるとともに署名文書が送信された際に前記ディレクトリに要求して照合規則情報を取得する照合規則情報取得手段と、当該公開鍵証明書の所有者名を当該照合規則情報に応じた変換方法により検索キーに変換する名前変換手段と、当該検索キーを前記ディレクトリに送信するとともに当該ディレクトリから送信される公開鍵証明書の公開鍵により前記署名文書の署名検証を行う署名検証手段とを備える業務処理システムを有することを特徴とするネットワークシステムをもって解決手段とする。
【００２６】
請求項４の本発明は、前記業務処理システムは、利用許可者名を格納された利用許可者名格納手段を備え、前記名前変換手段は、前記利用許可者名格納手段に格納された利用許可者名を前記取得された照合規則情報に応じた変換方法により変換するものであり、
前記業務処理システムは、前記変換後の所有者名と変換後の利用許可者名とを照合することにより利用許可するか否かを判定する利用可否判定手段を備えることを特徴とする請求項３記載のネットワークシステムをもって解決手段とする。
【００２７】
請求項５の本発明は、請求項１記載のネットワークシステムの制御方法であって、前記照合規則情報格納手段が、公開鍵が登録された際および当該登録後の公開鍵証明書の所有者名が公開鍵証明書の検索ラベルに変換された際に使用された照合規則を示す照合規則情報を当該公開鍵証明書に格納する照合規則情報格納段階と、前記１以上の認証局の公開鍵証明書送信手段が、当該公開鍵証明書を登録申請元の利用者端末に送信する公開鍵証明書送信段階と、前記公開鍵証明書受信手段が、１以上の認証局から該認証局で生成された公開鍵証明書とその所有者名から変換された検索ラベルとを受信する公開鍵証明書受信段階と、前記ディレクトリの公開鍵証明書送信手段が、公開鍵証明書の検索に際して送信される検索キーと検索ラベルとを照合して公開鍵証明書格納手段から公開鍵証明書を検索して検索キーの送信元に送信する公開鍵証明書送信段階と、前記署名検証手段が、前記認証局から送信された公開鍵証明書を受信した利用者端末から当該公開鍵証明書と署名文書が送信された際に当該公開鍵証明書の公開鍵により前記署名文書の署名検証を行う署名検証段階と、前記照合規則情報抽出手段が、当該公開鍵証明書から照合規則情報を抽出する照合規則情報抽出段階と、前記名前変換手段が、当該公開鍵証明書の発行者名を当該照合規則情報に応じた変換方法により検索キーに変換する名前変換段階と、前記証明書信頼性検証手段が、当該検索キーを前記ディレクトリに送信するとともに当該ディレクトリから送信された公開鍵証明書により当該利用者端末から送信された公開鍵証明書の信頼性検証を行う証明書信頼性検証段階とを備えることを特徴とするネットワークシステムの制御方法をもって解決手段とする。
【００２８】
請求項６の本発明は、請求項３記載のネットワークシステムの制御方法であって、前記１以上の認証局の照合規則情報送信手段が、公開鍵が登録された際および当該登録後の公開鍵証明書の所有者名が公開鍵証明書の検索ラベルに変換された際に使用された照合規則を示す照合規則情報をディレクトリに送信する照合規則情報送信段階と、前記１以上の認証局の公開鍵証明書送信手段が、当該公開鍵証明書を登録申請元の利用者端末に送信する公開鍵証明書送信段階と、前記公開鍵証明書受信手段が、１以上の認証局から該認証局で生成された公開鍵証明書とその所有者名から変換された検索ラベルを受信する公開鍵証明書受信段階と、前記公開鍵証明書受信手段が、１以上の認証局から照合規則情報を受信する照合規則情報受信段階と、前記ディレクトリの公開鍵証明書送信手段が、当該公開鍵証明書の検索に際して送信される検索キーと検索ラベルとを照合して公開鍵証明書格納手段から公開鍵証明書を検索して検索キーの送信元に送信する公開鍵証明書送信段階と、前記ディレクトリの公開鍵証明書送信手段が、前記格納された照合規則情報をその要求元に送信する照合規則情報送信段階と、前記照合規則情報取得手段が、前記認証局から送信された公開鍵証明書を受信した利用者端末から当該公開鍵証明書の所有者名が通知されるとともに署名文書が送信された際に前記ディレクトリに要求して照合規則情報を取得する照合規則情報取得段階と、前記名前変換手段が、当該公開鍵証明書の所有者名を当該照合規則情報に応じた変換方法により検索キーに変換する名前変換段階と、前記署名検証手段が、当該検索キーを前記ディレクトリに送信するとともに当該ディレクトリから送信される公開鍵証明書の公開鍵により前記署名文書の署名検証を行う署名検証段階と備えることを特徴とするネットワークシステムの制御方法をもって解決手段とする。
【００３３】
請求項７の本発明は、請求項５または６記載の方法を実行させるコンピュータプログラムをもって解決手段とする。
【００３４】
請求項８の本発明は、請求項５または６記載の方法を実行させるコンピュータプログラムを記録した記録媒体をもって解決手段とする。
【００３５】
請求項１または５の本発明では、１以上の認証局が照合規則情報を公開鍵証明書に格納して利用者端末に送信し、その照合規則情報を利用した名前変換を行うことで、業務処理システムが公開鍵証明書の信頼性検証を行う。
【００３６】
請求項３または６の本発明では、１以上の認証局が照合規則情報をディレクトリに送信し、その照合規則情報を業務処理システムが取得し、その照合規則情報を利用した名前変換を行うことで、業務処理システムが署名文書の署名検証を行う。
【００３７】
請求項２または４の本発明では、公開鍵証明書からあるいはディレクトリから取得した照合規則情報による利用許可者名の名前変換を行うことで、業務処理システムが利用可否の判定を行う。
【００４０】
請求項７の本発明によれば、PKIで利用される多種の照合規則環境において、公開鍵が認証局に登録された際に使用された照合規則を利用者（業務システムを含む）で認識することができないことによる課題を解決し、利便性を向上させるプログラムを流通させることができる。
【００４１】
請求項８の本発明によれば、PKIで利用される多種の照合規則環境において、公開鍵が認証局に登録された際に使用された照合規則を利用者（業務システムを含む）で認識することができないことによる課題を解決し、利便性を向上させるプログラムを記録媒体により流通させることができる。
【００４２】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して説明する。
[第１の実施の形態]
図１は、本発明の第１の実施の形態を説明するネットワークの構成を示す図である。図１において複数の認証局（Certification Authority：以下ＣＡという）１、ディレクトリ２および業務システム３のそれぞれは、演算装置と記憶装置とを備えるコンピュータシステムであり、特にＣＡ１はオペレータに操作されるため入力装置と表示装置を備える。そして、これらがネットワークとして相互通信を可能に構成されている。また、図１の各利用者端末４は業務システム３を利用しようとする利用者名Ａ、Ｂ、…の各利用者（便宜的に利用者Ａ、…のように記す）により使用されるものであり、演算装置、記憶装置、表示装置および入力装置を備える。なお、記憶装置はハードディスク装置や半導体メモリにより構成される。入力装置はキーボードやマウスである。表示装置はＣＲＴや液晶により構成される。
なお、公開鍵証明書は単に証明書ともいい、図面においてはこの略称で示すものとする。
【００４３】
図２は、ＣＡ１の構成図である。ＣＡ１は、照合規則情報管理テーブル１１と照合規則情報設定部１２と照合規則情報抽出部１３と証明書発行部１４と利用者情報データベース１５を備える。
【００４４】
照合規則情報管理テーブル１１は、ＣＡ１が公開鍵を登録する際および当該登録後の公開鍵証明書の所有者名を公開鍵証明書の検索ラベル（単にラベルという）に変換する際に使用する照合規則を示す照合規則情報が設定される記憶領域である。照合規則情報設定部１２は、オペレータの操作により生成された照合規則情報を照合規則情報管理テーブル１１に設定する処理部である。照合規則情報抽出部１３は、照合規則情報管理テーブル１１に設定された照合規則情報を抽出する処理部である。証明書発行部１４は、公開鍵証明書を発行する処理部であり、証明書生成部１４１と照合規則情報格納部１４２とラベル生成部１４３と証明書送信部１４４とを備える。証明書生成部１４１は照合規則情報を含まない公開鍵証明書を生成する処理部である。照合規則情報格納部１４２は生成された公開鍵証明書に照合規則情報を格納する処理部である。ラベル生成部１４３は、公開鍵証明書の所有者名を照合規則情報を使用して当該公開鍵証明書を検索するためのラベルに変換する処理部である。証明書送信部１４４は、照合規則情報を格納することにより完成した公開鍵証明書や生成されたラベルの送信を行う処理部である。利用者情報データベース１５は、利用許可された公開鍵証明書等の申請者の名前が登録者名として格納されたデータベースである。
【００４５】
なお、照合規則情報を公開鍵証明書に格納した後に署名するように認証局を構成することも可能である。また、ＣＡ１は、公開鍵証明書以外の申請に対応する処理を行う図示しない処理部を備える。また、各ＣＡ１は階層的に構成でき、上位のＣＡ１が下位のＣＡ１の公開鍵証明書を発行することも可能になっている。
【００４６】
照合規則情報は、具体的には、”ＲＦＣ２４５９”や”Ｘ．５００”等のキャラクタコードである。前者は、”ＲＦＣ２４５９照合”という照合規則を示しており、後者は、”Ｘ．５００照合”という照合規則を示している。また、照合規則情報としては、日本語特有の濁音や長音を正規化する照合規則などの任意の照合規則を示すものを設定することが可能である。
【００４７】
図３は、ディレクトリ２の構成図である。ディレクトリ２は、証明書受信部２１と証明書格納部２２と証明書送信部２３とを備える。証明書受信部２１は、ＣＡ１から送信された公開鍵証明書を受信して証明書格納部２２に格納する処理部である。証明書格納部２２は、公開鍵証明書と該公開鍵証明書を検索するためのラベルとが対応づけて格納される記憶領域である。証明書送信部２３は、利用者端末４から送信された検索キーと証明書格納部２２に設定されたラベルとを照合し、両者が等しいと判断したときは、そのラベルに対応する公開鍵証明書を証明書格納部２２から取り出して検索キーの送信元に送信する処理部である。なお、説明の便宜上、ディレクトリ２には、当該照合規則としてＲＦＣ２４５９照合が設定されていることとする。
【００４８】
図４は、業務システム３の構成図である。業務システム３は、署名及び認証パス検証部３１と業務処理部３２と名前変換部３３を備える。署名及び認証パス検証部３１は、利用者端末４から送信された署名文書の署名を検証するとともに業務システム３が信頼する公開鍵証明書までたどりつくかの認証パスの検証を行う処理部であり、証明書データベース３１１と署名検証部３１２と証明書信頼性検証部３１３とを備える。証明書データベース３１１は、信頼実績のあるＣＡの公開鍵証明書が格納される記憶領域である。署名検証部３１２は、署名文書や公開鍵証明書の署名を検証する処理部である。証明書信頼性検証部３１３は、署名文書に添付された公開鍵証明書やディレクトリ２から送信された公開鍵証明書の信頼性を個別に検証する処理部である。
【００４９】
業務処理部３２は、利用許可者名データベース３２１と利用可否判定部３２２と主業務処理部３２３とを備える。利用許可者名データベース３２１は、利用許可された複数の利用者の名前が利用許可者名として格納されたデータベースである。利用可否判定部３２２は、利用許可の判定処理を行う処理部である。主業務処理部３２３は、利用許可されたときに本来の業務を処理する処理部である。
【００５０】
名前変換部３３は、証明書信頼性検証部３１３または利用可否判定部３２２に呼び出された際に変換要求された名前を、照合規則情報が示す照合規則による照合を前提とした変換方法で変換する処理部である。
【００５１】
なお、ＣＡ１、ディレクトリ２および業務システム３の各処理部は、コンピュータプログラムが該プログラムを記憶した記憶媒体から当該各コンピュータシステムに読み込まれて該システムの演算処理装置で実行されることにより実現されるものである。
【００５２】
次に、第１の実施の形態の動作を説明する。
図５は、ＣＡ１の事前処理を示す図である。照合規則情報設定部１２は、オペレータにより入力装置が操作されて照合規則情報１００が生成されると、これを照合規則情報管理テーブル１１に設定する。なお、この処理はいずれのＣＡ１においても行われる。
【００５３】
図６は、ＣＡ１の公開鍵証明書発行に関わる処理を示すフローチャートである。なお、この処理はいずれのＣＡ１においても行われる。
【００５４】
さて、例えば利用者Ａの利用者端末４から申請に関わる情報送信がある（ステップＳ２）と、照合規則情報抽出部１３は、照合規則情報管理テーブル１１から照合規則情報１００を抽出する（ステップＳ３）。なお、この申請が公開鍵証明書作成の申請の場合は、利用者端末４からＣＡ１に対し、公開鍵証明書の所有者名として利用者名Ａや証明対象である所有者Ａの公開鍵などが送信される。
【００５５】
ＣＡ１は、この申請が公開鍵証明書の申請かそれ以外の申請であるを判定し（ステップＳ４）、公開鍵証明書以外の申請であると判定したときはその申請に対応する処理を行う（ステップＳ５）。
【００５６】
一方、公開鍵証明書の申請のときは、作成する公開鍵証明書の所有者名になる利用者名Ａを利用者データベース１５の登録者名と、ステップＳ３で抽出した照合規則情報に対応した照合規則による名前変換を行った後に照合して、利用者名Ａが新規登録者のものか既登録者のものかを判断する等の各種処理を行い（ステップＳ７）、申請が受理された時は、証明書発行部１４が公開鍵証明書を発行する。
【００５７】
具体的には、証明書生成部１４１が、所有者Ａの公開鍵を含みかつ、利用者名Ａを当該作成しようとする公開鍵証明書の所有者名として（以下、これを所有者名Ａという）、当該ＣＡ１の名前を当該公開鍵証明書を発行した発行者名としてそれぞれ含む公開鍵証明書を生成する（ステップＳ９）。
【００５８】
これらの名前は、名前のストリング（String)だけでなく「ストリングタイプ(StringType」を含み、例えばPrintableStringやUTF8Stringを区別できるようになっており、一般にはDistinguish Name(DN)と呼ばれる。また、第１および第２の実施の形態で言及する名前はいずれにしても当該構成を有するものである。
【００５９】
次に照合規則情報格納部１４２はこの生成された公開鍵証明書に照合規則情報１００を格納する（ステップＳ１１）。次に証明書送信部１４４は、照合規則情報１００を設定された公開鍵証明書（以下、利用者名Ａを所有者名として含むので公開鍵証明書Ａ０１という）を利用者端末４に送信する（ステップＳ１３）。なお、利用者端末４は、この公開鍵証明書Ａ０１を受信して自身の記憶装置内に記憶する。
【００６０】
次に、ラベル生成部１４３は、所有者名Ａを照合規則情報１００に応じた変換方法でラベルに変換する（ステップＳ１５）。この変換後の所有者名をラベルＡＬ１という。
【００６１】
例えば、照合規則情報１００が”ＲＦＣ２４５９”や”Ｘ．５００”の場合のように正規化が必要な場合は、所有者名Ａのストリングを、その照合規則情報１００に応じた正規化方法で正規化する（ステップＳ１５１）。そして、所有者名Ａまたは必要な正規化が行われた後の所有者名Ａのストリングを、照合規則情報１００と所有者名に含まれたストリングタイプの組み合わせに応じた変換方法により変換する（ステップＳ１５３）。例えば、照合規則情報１００が”Ｘ．５００”の場合は、所有者名は大文字と小文字のうちの予め決められた一方に変換される。また、照合規則情報１００が”ＲＦＣ２４５９”でかつストリングタイプがPrintableString以外の場合は、所有者名が１６進表記に変換される。なお、照合規則情報によってはステップＳ１５１が不要な場合もある。
【００６２】
以下において、照合規則情報１００が”ＲＦＣ２４５９”でかつストリングタイプがPrintableString以外の場合を例にして言及する。
【００６３】
次に、証明書送信部１４４は、利用者端末４に送信した公開鍵証明書Ａ０１と生成された１６進表記のラベルＡＬ１とを対応づけてディレクトリ２に送信する（ステップＳ１７）。
【００６４】
ディレクトリ２では、証明書受信部２１が、ＣＡ１から送信された公開鍵証明書Ａ０１とラベルＡＬ１とを受信し、さらにこれらを対応づけて証明書格納部２２に格納する。
【００６５】
なお、ＣＡ１は、いずれの利用者端末４からの公開鍵証明書の申請に対しても上記した公開鍵証明書発行に関わる処理を行う。また、上位のＣＡ１にあっては、下位のＣＡ１からの申請に対しても上記した公開鍵証明書発行に関わる処理を行う。このときの公開鍵証明書には下位のＣＡ１の名前が所有者名として含まれる。また、各ＣＡ１は、該ＣＡ１自身についても上記した公開鍵証明書発行に関わる処理を行う。このときの公開鍵証明書には該ＣＡ１の名前が所有者名および発行者名として含まれる。
【００６６】
このようにしてディレクトリ２の証明書格納部２２には、各利用者および各ＣＡ１の公開鍵証明書が格納される。
【００６７】
さて、利用者Ａが利用者端末４から業務システム３を利用しようとするときは以下の如く処理がなされる。なお、この処理は、この処理はいずれの利用者端末４からの利用に際しても行われる。
【００６８】
図７は、業務システム３の処理を示すフローチャートである。利用者端末４からは、業務システム３の利用に際して、利用者の署名を含む署名文書と公開鍵証明書Ａ０１が送信される（ステップＳ３０）。
【００６９】
まず、署名及び認証パス検証部３１は、署名検証部３１２により公開鍵証明書Ａ０１を用いて署名文書の署名の検証を試みる（ステップＳ３１）。ここで、検証できなかったときは処理を終了させる一方、検証できたときは、証明書信頼性検証部３１３が、その公開鍵証明書Ａ０１を検証対象にして証明書信頼性検証処理を行う（ステップＳ３３）。
【００７０】
図８は、証明書信頼性検証処理を示すフローチャートである。先ず、検証対象である公開鍵証明書Ａ０１から照合規則情報１００を取り出し所定の記憶領域に格納する（ステップＳ３３１）。次に、証明書信頼性検証部３１３は、公開鍵証明書Ａ０１に含まれた発行者名を取り出す（ステップＳ３３３）とともに、名前変換部３３を呼び出して、この発行者名を変換対象として名前変換を指示する。名前変換部３３は、この変換要求に応じ名前変換処理を行う（ステップＳ３３５）。
【００７１】
図９は、名前変換部３３が行う名前変換処理を示すフローチャートである。
【００７２】
名前変換部３３は、照合規則情報１００が”ＲＦＣ２４５９”や”Ｘ．５００”の場合のように正規化が必要な場合は、発行者名のストリングを、その照合規則情報１００に応じた正規化方法で正規化する（ステップＳ３３５１）。そして、公開鍵証明書Ａ０１に含まれた利用者名Ａまたは必要な正規化が行われた後の発行者名のストリングを、照合規則情報１００に応じた変換方法により変換する（ステップＳ３３５３）。この名前変換処理は、ＣＡ１の証明書発行部１４が行ったステップＳ１５１および１５２の処理と同様のものである。具体例では、発行者名が１６進表記の名前に変換される。
【００７３】
図８に戻り、証明書信頼性検証処理の説明を続ける。このようにして名前変換処理が終わると、証明書信頼性検証部３１３は、公開鍵証明書の取得要求を行うが、そのときは変換後の発行者名を検索キーとしてディレクトリ２に送信する（ステップＳ３３７）。
【００７４】
これに対し、ディレクトリ２では、証明書送信部２３が、送信された検索キーと証明書格納部２２内に設定されたラベルとを比較し、両者が等しいと判断したときは、そのラベルに対応する公開鍵証明書を証明書格納部２２から取り出して検索キーの送信元である業務システム３に送信する。
【００７５】
証明書信頼性検証部３１３は、署名検証部３１２に指示して、ディレクトリ２から取得した公開鍵証明書で検証対象の公開鍵証明書の署名を検証させる（ステップＳ３３８）。そして、この検証ができたときは、証明書信頼性検証部３１３が、送信された公開鍵証明書が信頼できるか否かを判定する（ステップＳ３３９）。具体的には、証明書データベース３１１の公開鍵証明書のいずれかに一致するか否かを判定する。一致すると判定したときは、署名及び認証パス検証部３１に検証終了を通知し（ステップＳ３４１）、一方、一致しないと判定されたときは、送信された公開鍵証明書を検証対象として設定し（ステップＳ３４３）、その後処理を終える。
【００７６】
図７に戻り、業務システム３の処理の説明を続ける。
【００７７】
署名及び認証パス検証部３１は、検証終了の通知の有無により公開鍵証明書のパス検証が終了したか否かを判定し（ステップＳ３５）、検証終了していない場合は、証明書信頼性検証部３１３が証明書信頼性検証処理を行う一方、検証終了した場合は、業務処理部３２に制御が移される。なお、証明書信頼性検証部３１３は、証明書信頼性検証部３１３がステップＳ３４２で設定した公開鍵証明書を検証対象として証明書信頼性検証処理を行う。この検証終了までに至る処理を公開鍵証明書のパス検証という。
【００７８】
業務処理部３２の処理にあっては、先ず利用可否判定部３２２が利用許可判定処理を行う（ステップＳ３７）。
【００７９】
図１０は、利用可否判定部３２２が行う利用許可判定処理を示すフローチャート図である。
【００８０】
利用可否判定部３２２は、利用希望者の公開鍵証明書の所有者名を変換する（ステップＳ３７１）。具体的には名前変換部３３を呼び出して、最初に利用者端末４から送信された利用希望者の公開鍵証明書の所有者名を変換対象として名前変換を指示する。名前変換部３３は、この変換要求に対し、上述のように照合規則情報１００に応じた名前変換処理を行い、変換後の利用希望者名を利用可否判定部３２２に返す。
【００８１】
次に、利用可否判定部３２２は、利用許可者名データベース３２１の各利用許可者名を変換する（ステップＳ３７３）。具体的には、名前変換部３３を呼び出して、利用許可者名データベース３２１の各利用許可者名を変換対象として名前変換を指示する。名前変換部３３は、この変換要求に対し、上述のように照合規則情報１００に応じた名前変換処理を行い、変換後の利用許可者名を利用可否判定部３２２に返す。
【００８２】
次に、利用可否判定部３２２は、変換後の利用希望者の公開鍵証明書の所有者名が変換後の利用許可者名のいずれかに一致するか否かを判定する（ステップＳ３７５）。
【００８３】
図７に戻り、業務システム３の処理の説明を続ける。
図１０におけるステップＳ３７５で、変換後の利用希望者の公開鍵証明書の所有者名が変換後の利用許可者名のいずれかに一致すると判定されたときは、主業務処理部３２３が利用者端末４に対して業務処理を提供する（ステップＳ３９）。つまり、利用者端末４からの指示にしたがって業務処理を行い、その結果を利用者端末４に送信し表示等させる。
【００８４】
一方、利用可否判定部３２２は、変換後の利用希望者の公開鍵証明書の所有者名が変換後の利用許可者名のいずれにも一致しないと判定されたときは、利用者端末４に対し業務処理を提供できないという利用不可通知を行う（ステップＳ４１）。
【００８５】
以上説明したように、本発明の第１の実施の形態は、公開鍵が登録された際および当該登録後の公開鍵証明書の所有者名が公開鍵証明書の検索ラベルに変換された際に使用された照合規則を示す照合規則情報を当該公開鍵証明書に格納する照合規則情報格納手段（照合規則情報格納部１４２）／照合規則情報格納段階（ステップＳ１１）と、当該公開鍵証明書を登録申請元の利用者端末に送信する公開鍵証明書送信手段（証明書送信部１４４）／公開鍵証明書送信段階（ステップＳ１３）と、１以上の認証局から該認証局で生成された公開鍵証明書とその所有者名から変換された検索ラベルとを受信する公開鍵証明書受信手段（証明書受信部２１）／公開鍵証明書受信段階（ステップＳ１７）と、当該公開鍵証明書と検索ラベルとが格納される公開鍵証明書格納手段（証明書格納部２２）と、当該公開鍵証明書の検索に際して送信される検索キーと当該検索ラベルとを照合して公開鍵証明書格納手段から公開鍵証明書を検索して検索キーの送信元に送信する公開鍵証明書送信手段（証明書送信部２３）／公開鍵証明書送信段階（ステップＳ３３７とＳ３３８の間のディレクトリ２からの公開鍵証明書送信）と、認証局から送信された公開鍵証明書を受信した利用者端末から当該公開鍵証明書と署名文書が送信された際に当該公開鍵証明書の公開鍵により署名文書の署名検証を行う署名検証手段（署名検証部３１２）／署名検証段階（ステップＳ３１）と、当該公開鍵証明書から照合規則情報を抽出する照合規則情報抽出手段（証明書信頼性検証部３１３）／照合規則情報抽出段階（ステップＳ３３１）と、当該公開鍵証明書の発行者名を当該照合規則情報に応じた変換方法により検索キーに変換する名前変換手段（名前変換部３３）／名前変換段階（ステップＳ３３５）と、当該検索キーをディレクトリに送信するとともに当該ディレクトリから送信された公開鍵証明書により当該利用者端末から送信された公開鍵証明書の信頼性検証を行う証明書信頼性検証手段（証明書信頼性検証部３１３）／証明書信頼性検証段階（ステップＳ３３）とを備えるので、業務処理システムが公開鍵証明書の信頼性検証を行うことができる。
【００８６】
また、業務処理システムは、利用許可者名を格納された利用許可者名格納手段（利用許可者名データベース３２１）を備え、名前変換手段は、署名文書とともに送信された公開鍵証明書の所有者名と利用許可者名格納手段に格納された利用許可者名を当該抽出された照合規則情報に応じた変換方法により変換するものであり、業務処理システムは、変換後の所有者名と変換後の利用許可者名とを照合することにより利用許可するか否かを判定する利用可否判定手段（利用可否判定部３２２）を備えるので、PKIで利用される多種の照合規則環境において、業務処理システムが利用可否の判定を行うことができる。
【００８８】
[第２の実施の形態]
図１１は、本発明の第２の実施の形態を説明するネットワークの構成を示す図である。第２の実施の形態では、図１のネットワーク構成において、ＣＡ１に代えてＣＡ１Ａが、ディレクトリ２に代えてディレクトリ２Ａが、業務システム３に代えて業務システム３Ａがそれぞれ適用される。第２の実施の形態の説明でも、照合規則情報１００が”ＲＦＣ２４５９”でかつストリングタイプがPrintableString以外の場合を例にして言及する。
【００８９】
図１２はＣＡ１Ａの構成図であり、図１３はディレクトリ２Ａの構成図であり、図１４は業務システム３Ａの構成図である。ＣＡ１Ａは、その構成要素のほとんどがＣＡ１のものと共通であるため、ＣＡ１の構成要素との差違を説明する。なお、ディレクトリ２Ａおよび業務システム３Ａについても同様である。
【００９０】
図１２に示すようにＣＡ１Ａは、証明書発行部１４に代えて、照合規則情報格納部１４２を備えない証明書発行部１４Ａを設け、さらに、照合規則情報送信部１６を加入した構成となっている。照合規則情報送信部１６は、照合規則情報抽出部１３により抽出された照合規則情報をディレクトリ２Ａに送信する処理部である。
【００９１】
図１３に示すようにディレクトリ２Ａは照合規則情報格納部２４を加入した構成となっている。照合規則情報格納部２４は、証明書受信部２１がＣＡ１Ａから受信した照合規則情報が格納される記憶領域である。照合規則情報格納部２４は、具体的には、NameComparisonType属性型のエントリといった特定のエントリが使用される。
【００９２】
図１４に示すように業務システム３Ａは、署名及び認証パス検証部３１に代えて署名及び認証パス検証部３１Ａを備える。署名及び認証パス検証部３１Ａには、署名及び認証パス検証部３１に照合規則情報取得部３１４を加入した構成となっている。照合規則情報取得部３１４は、署名文書の署名の検証に先立ち、ディレクトリ２Ａから照合規則情報を取得する処理部である。取得された照合規則情報は名前変換部３３で利用される。
【００９３】
次に、第２の実施の形態の動作を説明する。
先ず、図５を参照して説明した処理と同様に、ＣＡ１Ａの照合規則情報設定部１２は、オペレータにより入力装置が操作されて照合規則情報１００が生成されると、これを照合規則情報管理テーブル１１に設定する。すなわち、この処理は第１の実施の形態の処理と同様であり、各ＣＡ１Ａで行われる。
【００９４】
図１５は、ＣＡ１Ａが行う照合規則情報の格納処理を示す図である。
【００９５】
さて、例えばオペレータが入力装置に対し各種ポリシーの設定や変更の操作を行うと、照合規則情報抽出部１３は、照合規則情報管理テーブル１１から照合規則情報１００を抽出する（ステップＳ５１）。そして、照合規則情報送信部１６が、抽出された照合規則情報をディレクトリ２Ａに送信する（ステップＳ５３）。
【００９６】
ディレクトリ２Ａでは、証明書受信部２１が、ＣＡ１Ａから送信された照合規則情報を受信し、これを照合規則情報格納部２４に格納する。
【００９７】
次に、図６を説明の便宜上参照して、ＣＡ１Ａの公開鍵証明書発行に関わる処理を説明する。なお、各ステップの参照番号は流用することにする。この処理はいずれのＣＡ１Ａにおいても行われる。
【００９８】
さて、例えば利用者Ａの利用者端末４から申請に関わる情報送信がある（ステップＳ２）と、照合規則情報抽出部１３は、照合規則情報管理テーブル１１から照合規則情報１００を抽出する（ステップＳ３）。なお、この申請が公開鍵証明書作成の申請の場合は、利用者端末４からＣＡ１Ａに対し、公開鍵証明書の所有者名として利用者名Ａや証明対象である所有者Ａの公開鍵などが送信される。
【００９９】
ＣＡ１Ａは、この申請が公開鍵証明書の申請かそれ以外の申請であるを判定し（ステップＳ３）、公開鍵証明書以外の申請であると判定したときはその申請に対応する処理を行う（ステップＳ５）。
【０１００】
一方、公開鍵証明書の申請のときは、作成する公開鍵証明書の所有者名になる利用者名Ａを利用者データベース１５の登録者名と、ステップＳ３で抽出した照合規則情報に対応した照合規則による名前変換を行った後に照合して、利用者名Ａが新規登録者のものか既登録者のものかを判断する等の各種処理を行い（ステップＳ７）、申請が受理された時は、証明書発行部１４が公開鍵証明書を作成して送信する。
【０１０１】
具体的には、証明書生成部１４１が、所有者Ａの公開鍵を含みかつ、利用者名Ａを当該作成しようとする公開鍵証明書の所有者名として（以下、所有者名Ａという）、当該ＣＡ１Ａの名前を当該公開鍵証明書を発行した発行者名としてそれぞれ含む公開鍵証明書を生成する（ステップＳ９）。
【０１０２】
証明書送信部１４４は、生成された公開鍵証明書（以下、公開鍵証明書Ａ０２という）を利用者端末４に送信する（ステップＳ１３）。つまり、ステップＳ１１の処理は行われないのである。なお、利用者端末４は、この公開鍵証明書Ａ０２を受信して記憶装置に記憶する。
【０１０３】
次に、ラベル生成部１４３は、所有者名Ａを照合規則情報１００に応じた変換方法でラベルに変換する（ステップＳ１５）。この変換後の所有者名をラベルＡＬ１という。
【０１０４】
次に、証明書送信部１４４は、利用者端末４に送信した公開鍵証明書Ａ０２と生成されたラベルＡＬ１とを対応づけてディレクトリ２Ａに送信する（ステップＳ１７）。
【０１０５】
ディレクトリ２Ａでは、証明書受信部２１が、ＣＡ１Ａから送信された公開鍵証明書Ａ０２とラベルＡＬ１とを受信し、さらにこれらを対応づけて証明書格納部２２に格納する。
【０１０６】
なお、ＣＡ１Ａは、いずれの利用者端末４からの公開鍵証明書の申請に対しても上記した公開鍵証明書発行に関わる処理を行う。また、上位のＣＡ１Ａにあっては、下位のＣＡ１Ａからの申請に対しても上記した公開鍵証明書発行に関わる処理を行う。このときの公開鍵証明書には下位のＣＡ１Ａの名前が所有者名として含まれる。また、各ＣＡ１Ａは、該ＣＡ１Ａ自身についても上記した公開鍵証明書発行に関わる処理を行う。このときの公開鍵証明書には該ＣＡ１Ａの名前が所有者名および発行者名として含まれる。
【０１０７】
このようにしてディレクトリ２Ａの証明書格納部２２には、各利用者および各ＣＡ１Ａの公開鍵証明書が格納される。
【０１０８】
図１６は、業務システム３Ａの処理を示すフローチャートである。
【０１０９】
利用者端末４からは、業務システム３Ａの利用に際して、利用者の署名を含む署名文書が送信され、さらに利用者Ａの公開鍵証明書の所有者名（例ではPrintableString以外のストリングタイプを含む）が利用希望者名として通知される（ステップＳ６０）。まず、署名及び認証パス検証部３１Ａが署名及び認証パスを検証するのであるが、最初に照合規則情報取得部３１４が、ディレクトリ２Ａに対し照合規則情報を要求する（ステップＳ６１）。
【０１１０】
ディレクトリ２Ａでは、証明書送信部２３が、照合規則情報格納部２４から照合規則情報を読み出して、業務システム３Ａに送信し、照合規則情報取得部３１４は、送信された照合規則情報を受信する（ステップＳ６３）。
【０１１１】
署名及び認証パス検証部３１Ａは、名前変換部３３を呼び出して、この利用希望者名Ａを変換対象として名前変換を指示する。名前変換部３３は、図９を参照して説明した内容と同様の名前変換処理を行う（ステップＳ６５）。
【０１１２】
次に、署名及び認証パス検証部３１Ａは公開鍵証明書の取得要求を行うが、そのときは変換後の利用希望者名を検索キーとしてディレクトリ２Ａに送信する（ステップＳ６７）。
【０１１３】
これに対し、ディレクトリ２Ａでは、証明書送信部２３が、送信された検索キーと証明書格納部２２内に設定されたラベルと照合し、両者が等しいと判断したときは、そのラベルに対応する公開鍵証明書を証明書格納部２２から取り出して検索キーの送信元である業務システム３Ａに送信する。
【０１１４】
次に、署名及び認証パス検証部３１Ａは、この公開鍵証明書Ａ０２を最初の検証対象として、図７のステップＳ３１からステップＳ３５までの処理と同様の処理を行い、署名及び認証パスの検証が終了すると業務処理部３２が図７のステップＳ３７以降の処理と同様の処理を行う。なお、ステップＳ３３では証明書信頼性検証部３１３が、ステップＳ３７では利用可否判定部３２２がそれぞれ呼び出される。
【０１１５】
以上説明したように、本発明の第２の実施の形態は、公開鍵が登録された際および当該登録後の公開鍵証明書の所有者名が公開鍵証明書の検索ラベルに変換された際に使用された照合規則を示す照合規則情報をディレクトリに送信する照合規則情報送信手段（照合規則情報送信部１６）／照合規則情報送信段階（ステップＳ５３）と、当該公開鍵証明書を登録申請元の利用者端末に送信する公開鍵証明書送信手段（証明書送信部１４４）／公開鍵証明書送信段階（ステップＳ１３）と、１以上の認証局から該認証局で生成された公開鍵証明書とその所有者名から変換された検索ラベルならびに当該変換の際の照合規則情報を受信する公開鍵証明書受信手段（証明書受信部２１）／公開鍵証明書受信段階（ステップＳ１７）と、照合規則情報を受信する公開鍵証明書受信手段（証明書受信部２１）／照合規則情報受信段階（ステップＳ５３）と、当該公開鍵証明書と検索ラベルとが格納される公開鍵証明書格納手段（証明書格納部２２）と、当該受信された照合規則情報が格納される照合規則情報格納手段（照合規則情報格納部２４）と、当該公開鍵証明書の検索に際して送信される検索キーと当該検索ラベルとを照合して公開鍵証明書格納手段から公開鍵証明書を検索して検索キーの送信元に送信する公開鍵証明書送信手段（証明書送信部２３）／公開鍵証明書送信段階（ステップＳ３３７とＳ３３８の間のディレクトリ２からの公開鍵証明書送信）と、当該格納された照合規則情報をその要求元に送信する公開鍵証明書送信手段（証明書送信部２３）／照合規則情報送信段階（ステップＳ６１とＳ６３の間のディレクトリ２からの照合規則情報送信）と、認証局から送信された公開鍵証明書を受信した利用者端末から当該公開鍵証明書の所有者名が通知されるとともに署名文書が送信された際にディレクトリに要求して照合規則情報を取得する照合規則情報取得手段（照合規則情報取得部３１４）／照合規則情報取得段階（ステップＳ６３）と、当該公開鍵証明書の所有者名を当該照合規則情報に応じた変換方法により検索キーに変換する名前変換手段（名前変換部３３）／名前変換段階（ステップＳ６５）と、当該検索キーをディレクトリに送信するとともに当該ディレクトリから送信される公開鍵証明書の公開鍵により署名文書の署名検証を行う署名検証手段（署名及び認証パス検証部３１Ａ）／署名検証段階（ステップＳ３１）とを備えるので、業務処理システムが署名検証を行うことができる。
【０１１６】
また、業務処理システムは、利用許可者名を格納された利用許可者名格納手段（利用許可者名データベース３２１を備え、名前変換手段は、利用許可者名格納手段に格納された利用許可者名を前記取得された照合規則情報に応じた変換方法により変換するものであり、業務処理システムは、変換後の所有者名と変換後の利用許可者名とを照合することにより利用許可するか否かを判定する利用可否判定手段（利用可否判定部３２２）を備えるので、PKIで利用される多種の照合規則環境において、業務処理システムが利用可否の判定を行うことができる
【０１１７】
なお、上記説明した処理を実行させるコンピュータプログラムは、半導体メモリ、磁気ディスク、光ディスク、光磁気ディスク、磁気テープなどのコンピュータ読み取り可能な記録媒体に記録したり、インターネットなどの通信網を介して伝送させて、広く流通させることができる。
【０１１８】
【発明の効果】
以上説明したように、本発明によれば、PKIで利用される多種の照合規則環境において、公開鍵証明書を確実に取得することができるようになり、また、的確な利用可否の判定を行うことができるので、利便性を格段に向上させることができる。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態を説明するネットワークの構成を示す図である。
【図２】ＣＡ１の構成図である。
【図３】ディレクトリ２の構成図である。
【図４】業務システム３の構成図である。
【図５】ＣＡ１の事前処理を示す図である。
【図６】ＣＡ１の公開鍵証明書発行に関わる処理を示すフローチャートである。
【図７】業務システム３の処理を示すフローチャートである。
【図８】証明書信頼性検証処理を示すフローチャートである。
【図９】名前変換部３３が行う名前変換処理を示すフローチャートである。
【図１０】利用可否判定部３２２が行う利用許可判定処理を示すフローチャート図である。
【図１１】本発明の第２の実施の形態を説明するネットワークの構成を示す図である。
【図１２】ＣＡ１Ａの構成図である。
【図１３】ディレクトリ２Ａの構成図である。
【図１４】業務システム３Ａの構成図である。
【図１５】ＣＡ１Ａが行う照合規則情報の格納処理を示す図である。
【図１６】業務システム３Ａの処理を示すフローチャートである。
【図１７】ＰＫＩにおける名前変換と照合の場面を示す図である。
【図１８】Ｘ．５００照合とＲＦＣ２４５９照合を前提とした名前変換を示す図である。
【符号の説明】
１，１Ａ ＣＡ
２，２Ａ ディレクトリ
３，３Ａ 業務システム
４ 利用者端末
１１ 照合規則情報管理テーブル
１２ 照合規則情報設定部
１３ 照合規則情報抽出部
１４，１４Ａ 証明書発行部
１５ 利用者情報データベース
１６ 照合規則情報送信部
２１ 証明書受信部
２２ 証明書格納部
２３ 証明書送信部
２４ 照合規則情報格納部
３１，３１Ａ 署名及び認証パス検証部
３２ 業務処理部
３３ 名前変換部
１００ 照合規則情報
１４１ 証明書生成部
１４２ 照合規則情報格納部
１４３ ラベル生成部
１４４ 証明書送信部
３１１ 証明書データベース
３１２ 署名検証部
３１３ 証明書信頼性検証部
３１４ 照合規則情報取得部
３２１ 利用許可者名データベース
３２２ 利用可否判定部
３２３ 主業務処理部
Ａ 利用者名
Ａ０１，Ａ０２ 公開鍵証明書
ＡＬ１ ラベル
Claims (8)
- 公開鍵が登録された際および当該登録後の公開鍵証明書の所有者名が公開鍵証明書の検索ラベルに変換された際に使用された照合規則を示す照合規則情報を当該公開鍵証明書に格納する照合規則情報格納手段と、当該公開鍵証明書を登録申請元の利用者端末に送信する公開鍵証明書送信手段とを備える１以上の認証局、
１以上の認証局から該認証局で生成された公開鍵証明書とその所有者名から変換された検索ラベルとを受信する公開鍵証明書受信手段と、当該公開鍵証明書と検索ラベルとが格納される公開鍵証明書格納手段と、当該公開鍵証明書の検索に際して送信される検索キーと当該検索ラベルとを照合して公開鍵証明書格納手段から公開鍵証明書を検索して検索キーの送信元に送信する公開鍵証明書送信手段とを備えるディレクトリ、
前記認証局から送信された公開鍵証明書を受信した利用者端末から当該公開鍵証明書と署名文書が送信された際に当該公開鍵証明書の公開鍵により前記署名文書の署名検証を行う署名検証手段と、当該公開鍵証明書から照合規則情報を抽出する照合規則情報抽出手段と、当該公開鍵証明書の発行者名を当該照合規則情報に応じた変換方法により検索キーに変換する名前変換手段と、当該検索キーを前記ディレクトリに送信するとともに当該ディレクトリから送信された公開鍵証明書により当該利用者端末から送信された公開鍵証明書の信頼性検証を行う証明書信頼性検証手段とを備える業務処理システムを有することを特徴とするネットワークシステム。 - 前記業務処理システムは、
利用許可者名を格納された利用許可者名格納手段を備え、
前記名前変換手段は、前記署名文書とともに送信された公開鍵証明書の所有者名と前記利用許可者名格納手段に格納された利用許可者名を前記抽出された照合規則情報に応じた変換方法により変換するものであり、
前記業務処理システムは、
前記変換後の所有者名と変換後の利用許可者名とを照合することにより利用許可するか否かを判定する利用可否判定手段
を備えることを特徴とする請求項１記載のネットワークシステム。 - 公開鍵が登録された際および当該登録後の公開鍵証明書の所有者名が公開鍵証明書の検索ラベルに変換された際に使用された照合規則を示す照合規則情報をディレクトリに送信する照合規則情報送信手段と、当該公開鍵証明書を登録申請元の利用者端末に送信する公開鍵証明書送信手段とを備える１以上の認証局、
１以上の認証局から該認証局で生成された公開鍵証明書とその所有者名から変換された検索ラベルならびに当該変換の際の照合規則情報を受信する公開鍵証明書受信手段と、当該公開鍵証明書と検索ラベルとが格納される公開鍵証明書格納手段と、当該受信された照合規則情報が格納される照合規則情報格納手段と、当該公開鍵証明書の検索に際して送信される検索キーと当該検索ラベルとを照合して公開鍵証明書格納手段から公開鍵証明書を検索して検索キーの送信元に送信するとともに前記格納された照合規則情報をその要求元に送信する公開鍵証明書送信手段とを備えるディレクトリ、
前記認証局から送信された公開鍵証明書を受信した利用者端末から当該公開鍵証明書の所有者名が通知されるとともに署名文書が送信された際に前記ディレクトリに要求して照合規則情報を取得する照合規則情報取得手段と、当該公開鍵証明書の所有者名を当該照合規則情報に応じた変換方法により検索キーに変換する名前変換手段と、当該検索キーを前記ディレクトリに送信するとともに当該ディレクトリから送信される公開鍵証明書の公開鍵により前記署名文書の署名検証を行う署名検証手段とを備える業務処理システムを有することを特徴とするネットワークシステム。 - 前記業務処理システムは、
利用許可者名を格納された利用許可者名格納手段を備え、
前記名前変換手段は、前記利用許可者名格納手段に格納された利用許可者名を前記取得された照合規則情報に応じた変換方法により変換するものであり、
前記業務処理システムは、
前記変換後の所有者名と変換後の利用許可者名とを照合することにより利用許可するか否かを判定する利用可否判定手段
を備えることを特徴とする請求項３記載のネットワークシステム。 - 請求項１記載のネットワークシステムの制御方法であって、
前記照合規則情報格納手段が、公開鍵が登録された際および当該登録後の公開鍵証明書の所有者名が公開鍵証明書の検索ラベルに変換された際に使用された照合規則を示す照合規則情報を当該公開鍵証明書に格納する照合規則情報格納段階と、前記１以上の認証局の公開鍵証明書送信手段が、当該公開鍵証明書を登録申請元の利用者端末に送信する公開鍵証明書送信段階と、
前記公開鍵証明書受信手段が、１以上の認証局から該認証局で生成された公開鍵証明書とその所有者名から変換された検索ラベルとを受信する公開鍵証明書受信段階と、前記ディレクトリの公開鍵証明書送信手段が、公開鍵証明書の検索に際して送信される検索キーと検索ラベルとを照合して公開鍵証明書格納手段から公開鍵証明書を検索して検索キーの送信元に送信する公開鍵証明書送信段階と、
前記署名検証手段が、前記認証局から送信された公開鍵証明書を受信した利用者端末から当該公開鍵証明書と署名文書が送信された際に当該公開鍵証明書の公開鍵により前記署名文書の署名検証を行う署名検証段階と、前記照合規則情報抽出手段が、当該公開鍵証明書から照合規則情報を抽出する照合規則情報抽出段階と、前記名前変換手段が、当該公開鍵証明書の発行者名を当該照合規則情報に応じた変換方法により検索キーに変換する名前変換段階と、前記証明書信頼性検証手段が、当該検索キーを前記ディレクトリに送信するとともに当該ディレクトリから送信された公開鍵証明書により当該利用者端末から送信された公開鍵証明書の信頼性検証を行う証明書信頼性検証段階とを備えることを特徴とするネットワークシステムの制御方法。 - 請求項３記載のネットワークシステムの制御方法であって、
前記１以上の認証局の照合規則情報送信手段が、公開鍵が登録された際および当該登録後の公開鍵証明書の所有者名が公開鍵証明書の検索ラベルに変換された際に使用された照合規則を示す照合規則情報をディレクトリに送信する照合規則情報送信段階と、前記１以上の認証局の公開鍵証明書送信手段が、当該公開鍵証明書を登録申請元の利用者端末に送信する公開鍵証明書送信段階と、
前記公開鍵証明書受信手段が、１以上の認証局から該認証局で生成された公開鍵証明書とその所有者名から変換された検索ラベルを受信する公開鍵証明書受信段階と、前記公開鍵証明書受信手段が、１以上の認証局から照合規則情報を受信する照合規則情報受信段階と、前記ディレクトリの公開鍵証明書送信手段が、当該公開鍵証明書の検索に際して送信される検索キーと検索ラベルとを照合して公開鍵証明書格納手段から公開鍵証明書を検索して検索キーの送信元に送信する公開鍵証明書送信段階と、前記ディレクトリの公開鍵証明書送信手段が、前記格納された照合規則情報をその要求元に送信する照合規則情報送信段階と、
前記照合規則情報取得手段が、前記認証局から送信された公開鍵証明書を受信した利用者端末から当該公開鍵証明書の所有者名が通知されるとともに署名文書が送信された際に前記ディレクトリに要求して照合規則情報を取得する照合規則情報取得段階と、前記名前変換手段が、当該公開鍵証明書の所有者名を当該照合規則情報に応じた変換方法により検索キーに変換する名前変換段階と、前記署名検証手段が、当該検索キーを前記ディレクトリに送信するとともに当該ディレクトリから送信される公開鍵証明書の公開鍵により前記署名文書の署名検証を行う署名検証段階と備えることを特徴とするネットワークシステムの制御方法。 - 請求項５または６記載の方法を実行させるコンピュータプログラム。
- 請求項５または６記載の方法を実行させるコンピュータプログラムを記録した記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002035924A JP3842664B2 (ja) | 2002-02-13 | 2002-02-13 | ネットワークシステムおよびネットワークシステムの制御方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002035924A JP3842664B2 (ja) | 2002-02-13 | 2002-02-13 | ネットワークシステムおよびネットワークシステムの制御方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003244133A JP2003244133A (ja) | 2003-08-29 |
| JP3842664B2 true JP3842664B2 (ja) | 2006-11-08 |
Family
ID=27777974
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002035924A Expired - Fee Related JP3842664B2 (ja) | 2002-02-13 | 2002-02-13 | ネットワークシステムおよびネットワークシステムの制御方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3842664B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003258786A (ja) * | 2002-02-27 | 2003-09-12 | Nippon Telegr & Teleph Corp <Ntt> | 公開鍵証明書検索装置、公開鍵証明書検索方法、コンピュータプログラムおよびコンピュータプログラムを記録した記録媒体 |
| KR100736101B1 (ko) | 2005-01-13 | 2007-07-06 | 삼성전자주식회사 | 분산 디바이스 환경에서 상속 구조를 갖는 권리객체를소비하는 방법 및 이를 위한 디바이스 |
| US7647494B2 (en) | 2005-06-08 | 2010-01-12 | International Business Machines Corporation | Name transformation for a public key infrastructure (PKI) |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH05334363A (ja) * | 1992-06-01 | 1993-12-17 | Nippon Telegr & Teleph Corp <Ntt> | データベース検索システム |
| JP3202341B2 (ja) * | 1992-08-11 | 2001-08-27 | 日本電気株式会社 | データベースシステム |
| JPH07200627A (ja) * | 1993-12-28 | 1995-08-04 | Toshiba Corp | マルチメディアデータベース検索装置 |
| JP3327377B2 (ja) * | 1997-03-31 | 2002-09-24 | 日本電信電話株式会社 | 認証システムにおける公開鍵証明証管理方法 |
| JPH1115845A (ja) * | 1997-06-25 | 1999-01-22 | Nippon Telegr & Teleph Corp <Ntt> | 情報検索方法および装置と情報検索プログラムを格納した記録媒体 |
| JP2000285129A (ja) * | 1999-03-31 | 2000-10-13 | Fuji Photo Film Co Ltd | 医療画像検索方法および装置 |
| JP3883756B2 (ja) * | 1999-09-20 | 2007-02-21 | 日本電信電話株式会社 | 認証局装置並びに認証局装置の制御方法及び認証局装置の制御方法をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体 |
-
2002
- 2002-02-13 JP JP2002035924A patent/JP3842664B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003244133A (ja) | 2003-08-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4006796B2 (ja) | 個人情報管理方法および装置 | |
| US7574605B2 (en) | Method of managing digital signature, apparatus for processing digital signature, and a computer readable medium for recording program of managing digital signature | |
| KR100464755B1 (ko) | 이메일 주소와 하드웨어 정보를 이용한 사용자 인증방법 | |
| JP4838610B2 (ja) | 文書管理装置、文書管理方法、プログラム | |
| US7035442B2 (en) | User authenticating system and method using one-time fingerprint template | |
| JP3943897B2 (ja) | 本人確認システム及び装置 | |
| US20060075231A1 (en) | Terminal for exchanging electronic business cards | |
| JP5365502B2 (ja) | ファイル管理装置、ファイル管理プログラム、およびファイル管理方法 | |
| US20050228687A1 (en) | Personal information management system, mediation system and terminal device | |
| US7100045B2 (en) | System, method, and program for ensuring originality | |
| US20060136425A1 (en) | Data-centric distributed computing | |
| WO2006001153A1 (ja) | ファイル管理プログラム | |
| US6950934B2 (en) | Method for managing certificate revocation list by distributing it | |
| WO2007020942A1 (ja) | 本人認証システム、これで用いる端末、認証検証装置、及びプログラム | |
| RU2373572C2 (ru) | Система и способ для разрешения имен | |
| US20030196090A1 (en) | Digital signature system | |
| JP2002318634A (ja) | 電子署名検証方法及びシステム、並びに電子署名検証プログラム及びこのプログラムを記録した記録媒体 | |
| JP3842664B2 (ja) | ネットワークシステムおよびネットワークシステムの制御方法 | |
| JP4027725B2 (ja) | 電子署名付与方法 | |
| US20040186997A1 (en) | Encrypted data sharing system and encrypted data sharing method | |
| JPH09146843A (ja) | 情報処理装置 | |
| JP3408228B2 (ja) | サービス提供側装置及び記録媒体 | |
| JP3697212B2 (ja) | ユーザ認証システム、ユーザ認証方法、ユーザ認証プログラム、及び、コンピュータ読取可能な記録媒体 | |
| JP2000235569A (ja) | 電子文書の管理方法及び文書管理システム | |
| JP2002312319A (ja) | パスワードシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040319 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051017 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051025 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051222 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060606 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060707 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060801 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060810 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090818 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100818 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100818 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110818 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120818 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130818 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |