証明書の有効性確認方法、検証サーバ、プログラム及び記憶媒体
【課題】証明書の有効性確認処理を安全にかつ迅速に行うことができる証明書の有効性確認方法、これを実施する検証サーバ、プログラム及び記憶媒体を提供する。
【解決手段】検証サーバは、証明書の電子署名に利用されている暗号方式に関する情報を記憶する記憶部を有し、端末装置からの有効性確認依頼に含まれる証明書から第一の暗号方式に関する情報を取得し、前記第一の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されていない場合に、前記第一の暗号方式に関する情報を無効と判断し、また、前記第一の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されており、かつ、認証パスの検証時に、前記認証パス中の前記証明書に記載の第二の暗号方式に関する情報が前記記憶部に記憶されていない場合に、前記第二の暗号方式に関する情報を無効と判断する。
【解決手段】検証サーバは、証明書の電子署名に利用されている暗号方式に関する情報を記憶する記憶部を有し、端末装置からの有効性確認依頼に含まれる証明書から第一の暗号方式に関する情報を取得し、前記第一の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されていない場合に、前記第一の暗号方式に関する情報を無効と判断し、また、前記第一の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されており、かつ、認証パスの検証時に、前記認証パス中の前記証明書に記載の第二の暗号方式に関する情報が前記記憶部に記憶されていない場合に、前記第二の暗号方式に関する情報を無効と判断する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、公開鍵認証基盤（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ；以下、「ＰＫＩ」と記述する）において、証明書の有効性を確認するのに好適な技術に関する。
【背景技術】
【０００２】
政府認証基盤（ＧＰＫＩ）をはじめとして、電子文書の作成者を明らかにし、かつ、当該電子文書が改ざんされていないことを保証するために、公開鍵認証基盤（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ；以下、「ＰＫＩ」と記載する）を利用したシステムが普及してきている。ＰＫＩを利用したシステムでは、電子文書に対して、電子署名を行う者（以下、署名者、と記載する）のみが保有する、秘密鍵（Ｐｒｉｖａｔｅ Ｋｅｙ）と呼ばれる鍵によって、一定の処理手順（以下、「暗号アルゴリズム」と記載する）に従い、電子署名が施される。電子署名が施された電子文書を受信した場合には、署名者の秘密鍵とペアであり、また、他人に公開しても良い、公開鍵（Ｐｕｂｌｉｃ Ｋｅｙ）と呼ばれる鍵によって、上記電子署名を検証することで、電子文書の作成者と、当該電子文書が改ざんされていないことと、を確認する。高い信頼が要求される用途では、署名者と公開鍵の結びつきを保証するために、認証局（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ；以下、「ＣＡ」と記載する）が、上記署名者の公開鍵証明書（以下、「証明書」と記載する）を発行する。証明書には、ＣＡの名前、有効期限、所有者の名前、所有者の公開鍵に関する情報など、また、オプションとして、鍵使用目的、証明書ポリシなどが含まれる。証明書ポリシとは、各ＣＡが証明書を発行する際に定める証明書の利用目的やセキュリティレベルなどを規定するものであり、証明書ポリシには、この証明書ポリシを一意に示すＩＤが付与されている。さらに、証明書の記載内容を保証するために、ＣＡは、ＣＡの秘密鍵を利用し、定められた暗号アルゴリズムに従って、該証明書に対する電子署名を生成し、証明書に付与する。証明書の記載内容は、非特許文献１の「 ４． Ｃｅｒｔｉｆｉｃａｔｅ ａｎｄ Ｃｅｒｔｉｆｉｃａｔｅ Ｅｘｔｅｎｓｉｏｎｓ Ｐｒｏｆｉｌｅ」に詳細に記載されている。
【０００３】
より厳密な電子署名の検証を行うためには、ＣＡが発行した、上記署名者の証明書に含まれている、公開鍵と呼ばれる鍵によって、当該電子署名を検証するだけではなく、上記署名者の証明書が電子署名を検証する者（以下、「検証者」と記載する）にとって利用目的等やセキュリティレベルを満足する有効な証明書であるか否か、を確認する必要がある。上記署名者の証明書が上記検証者にとって有効であるか否か、を検証するには、（１）認証パスの構築、（２）認証パスの検証、という、処理が必要である。
【０００４】
（１）認証パスの構築の処理において、検証者の信頼するＣＡ（トラストアンカ、以下、「トラストアンカ」は「ＴＡ」と記載する）から署名者の証明書までの信頼の連鎖である証明書チェーンを構築する。証明書チェーンは、複数の証明書の連なったものであり、ある証明書の主体者名が次の証明書の発行者名に一致し、また、証明書の主体者の鍵識別子が次の証明書の発行者の鍵識別子に一致している関係が、連鎖する証明書の列である。検証者は、各ＣＡのリポジトリにアクセスして、上記の証明書チェーンを構成する証明書を取得し、上記連鎖の確認を行う。特に、認証局の運用主体が異なるような、異なるドメインのＣＡ同士が接続したＰＫＩモデルにおいては、ＣＡ同士がお互いに相互認証証明書と呼ばれる証明書を発行し合う。一般に、この、相互認証証明書には、異なるドメイン間で証明書ポリシなどの調整を行い相互運用するための情報が記載されていることが多い。このため、複数の異なるドメインに渡る認証パスを構築する場合、証明書チェーンに相互認証証明書が含まれることになる。認証パスを構築する方法については、非特許文献２に詳細に記載されている。
【０００５】
（２）認証パスの検証の処理において、（１）の処理で構築した認証パスを構成する証明書チェーンの証明書が全て有効であることを確かめる。具体的には、ＣＡが発行する証明書失効リスト（Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ；以下、「ＣＲＬ」と記載する）やＯＣＳＰ（Ｏｎｌｉｎｅ Ｃｅｒｔｉｆｉｃａｔｅ Ｓｔａｔｕｓ Ｐｒｏｔｏｃｏｌ）レスポンダを利用して、証明書が有効か否かを判定する。また、検証者が受け入れ可能な証明書ポリシと、署名者の証明書に含まれる証明書ポリシが一致することを確かめる。認証パスを検証する方法については、非特許文献１の「 ６． Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ｐａｔｈ Ｖａｌｉｄａｔｉｏｎ」に詳細に記載されている。
【０００６】
証明書の有効性を検証するモデルには、検証者自身が証明書の有効性を確認するエンドエンティティモデルと、検証者に代わってオンラインで証明書の有効性を確認する機能を提供する証明書検証サーバ（以下、「検証サーバ」と記載する）を利用する検証サーバモデルがある。検証サーバモデルの仕様は非特許文献３に記載されている。
【０００７】
上記検証サーバモデルは、上記エンドエンティティモデルに比べて、次のような利点がある。まず、上記検証サーバモデルでは、上記認証パスを構築する認証パス構築機能をクライアントに実装する必要がないため、クライアントの証明書検証プログラムを小さくすることができる。また、クライアントは上記検証サーバの判定結果を信頼するため、上記検証サーバの設定を変更するだけで、システム構成の変化に柔軟に対応できる。
【０００８】
証明書の有効性確認を行う毎に、検証サーバが認証パスを構築し、また、ＣＡからＣＲＬを取得すると、有効性確認処理にかかる時間が長くなるため、特許文献１では、検証サーバが有効性確認処理を行った上記ＣＲＬや上記認証パスを登録することにより次回からの証明書の有効性確認処理を高速化する方式が開示されている。
【０００９】
一方で、電子文書に対する電子署名生成やＣＡによる証明書の電子署名生成において、署名者やＣＡは、電子署名に利用する暗号アルゴリズム、パラメータ、並びに公開鍵の鍵長に関して、複数の選択肢の中から利用するものを選択しているが、近年の暗号解読技術の進歩や電子計算機能力の向上により、一部の暗号アルゴリズム、また、鍵長の短い公開鍵は、安全性に問題があることが指摘されている。米国連邦政府の標準暗号を制定する米国立標準技術研究所では、２０１０年までに、米国政府での情報システムにおいて、電子署名に利用するハッシュ関数を、ＳＨＡ−１からＳＨＡ-２へ移行することを強く推奨している。ＳＨＡ−１の安全性に関するコメントは、非特許文献４に詳細に記載されている。
【００１０】
非特許文献４のコメントを受け、各国の認証局は、現行の暗号アルゴリズムを利用している情報システムとの互換性を保ちつつ、利用者の公開鍵や、証明書の電子署名に利用する暗号アルゴリズムを、より安全性の高いものに移行することとしている。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２００２−７２８７６号公報
【非特許文献】
【００１２】
【非特許文献１】Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile (RFC5280), 2008年5月, [online], [平成21年11月17日検索], インターネット＜URL:http://www.ietf.org/rfc/rfc5280.txt＞
【非特許文献２】Internet X.509 Public Key Infrastructure Certification Path Building (RFC4158), 「 2. Certification Path Building」, 2005年9月, [online], [平成21年11月17日検索], インターネット＜URL:http://www.ietf.org/rfc/rfc4158.txt＞
【非特許文献３】Delegated Path Validation and Delegated Path Discovery Protocol Requirements (RFC3379), 2002年9月, [online], [平成21年11月17日検索], インターネット＜URL:http://www.ietf.org/rfc/rfc3379.txt＞
【非特許文献４】NIST Comments on Cryptanalytic Attacks on SHA-1, 2006年4月, [online], [平成21年11月17日検索], インターネット＜URL:http://csrc.nist.gov/groups/ST/hash/statement.html＞
【発明の概要】
【発明が解決しようとする課題】
【００１３】
認証局が暗号アルゴリズムを移行している時期（以下、「暗号移行期」と記載する）では、暗号移行前に現行の暗号アルゴリズムで電子署名した証明書と、暗号移行後に、より安全性の高い暗号アルゴリズムで電子署名した証明書が混在することとなる。そのため、検証者が明示的に特定の暗号アルゴリズムで電子署名した証明書を受け入れたくない場合や、現行の暗号アルゴリズムの安全性が著しく低下し、暗号アルゴリズム危殆化と判断された場合には、その暗号アルゴリズムを利用する証明書の検証を失敗とする必要がある。
【００１４】
また、上記非特許文献１では、検証者が、有効性確認依頼時に、明示的に受け入れる証明書ポリシを指定することで、検証者自身が、有効性確認の制約を設ける手法が記載されている。しかし、暗号移行期では、複数の情報システムの相互運用性確保のために、暗号移行中のＣＡが、まだ暗号移行を行っていないＣＡと相互認証を行うことで、暗号強度の高い証明書ポリシを、暗号強度の低い証明書ポリシに、マッピングし、ポリシーマッピングの情報を相互認証証明書に記載する場合がある。このような場合において、暗号移行を行ったＣＡを信頼点とする検証者が、暗号移行を行っていないＣＡから発行された証明書に対して有効性確認処理を行うと、上記相互認証証明書から、暗号強度の高い証明書ポリシが暗号強度の低い証明書と同等と判断され、有効性確認処理の結果が有効となる可能性がある。検証者は、暗号強度の高い証明書ポリシを指定しても、暗号強度の低い暗号アルゴリズムで電子署名した証明書を除外することができないため、有効性確認処理結果の信頼性が失われてしまう。
【００１５】
さらに、上記非特許文献１や上記特許文献１に記載の技術では、ＣＡの電子署名が付与された証明書、ＣＲＬやＯＣＳＰレスポンスをＣＡから取得して、認証パスの検証を行っているが、暗号移行期に、暗号アルゴリズム危殆化が発生し、該当する暗号アルゴリズムの使用停止の通達が政府機関等から出た場合においては、認証パスの検証で次に述べる課題が発生する。
【００１６】
ＣＡが暗号移行を行う前や、暗号移行を行っている途中に、現行の暗号アルゴリズムの危殆化が発生した場合に、ＣＡは、電子署名に利用する暗号アルゴリズムをより安全性の高いものへ移行した後、危殆化した暗号アルゴリズムを利用した証明書を失効し、さらに、新しい暗号アルゴリズムで証明書失効リストや証明書を発行する必要がある。しかし、上記は対応するのに時間を要する処置であるため、ＣＡが迅速に対応できない可能性が高い。したがって、このような場合は、ＣＡから提供される、危殆化した暗号アルゴリズムで電子署名された情報を、認証パスの検証で利用することになるため、有効性確認処理結果の信頼性が失われてしまう。
【００１７】
本発明は上記事項に鑑みてなされたものであり、証明書の有効性確認処理を安全にかつ迅速に行うことができる証明書の有効性確認方法、これを実施する検証サーバ、プログラム及び記憶媒体を提供することを課題とする。
【課題を解決するための手段】
【００１８】
上記課題を解決するための一手段を説明する。本発明では、複数の端末装置及び複数の認証局とネットワークに接続された検証サーバにより、任意の端末装置からネットワークを介して証明書の有効性確認依頼を受信し、第一の認証局から第二の認証局までの認証パスを構築し、該認証パスの検証を行い、該検証結果を前記証明書の有効性確認依頼元の端末装置へ前記ネットワークを介して送信する、証明書の有効性確認処理において、前記検証サーバが、以下に示す構成を有することを特徴とする。
【００１９】
前記検証サーバは、前記証明書の電子署名に利用されている暗号方式に関する情報を記憶する記憶部を有することを特徴とする。
【００２０】
前記検証サーバは、前記有効性確認依頼に含まれる証明書から第一の暗号方式に関する情報を取得し、前記第一の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されていない場合に、前記第一の暗号方式に関する情報を無効と判断することを特徴とする。
【００２１】
また、前記検証サーバは、前記第一の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されており、かつ、前記認証パスの検証時に、前記認証パス中の前記証明書に記載の第二の暗号方式に関する情報が前記記憶部に記憶されていない場合に、前記第二の暗号方式に関する情報を無効と判断することを特徴とする。
【発明の効果】
【００２２】
本発明によれば、証明書の有効性確認処理を安全にかつ迅速に行うことができる証明書の有効性確認方法、これを実施する検証サーバ、プログラム及び記憶媒体を提供することができる。
【図面の簡単な説明】
【００２３】
【図１】本発明の実施形態に係る検証システムの構成を示す図である。
【図２】端末装置１１の構成を示す図である。
【図３】ＣＲＬを利用して失効情報を提供するＣＡ装置１２の構成を示す図である。
【図４】ＯＣＳＰレスポンダを利用して失効情報を提供するＣＡ装置１２の構成を示す図である。
【図５】検証サーバ１３の構成を示す図である。
【図６】図２〜４に示す端末装置１１、ＣＡ装置１２、検証サーバ１３の各々のハードウェア構成例を示す図である。
【図７】検証サーバ１３において、設定情報保持部４８に記憶されている、検証者が受け入れない暗号方式とこの暗号方式を例外的に有効とする認証局の情報を示す図である。
【図８】検証サーバ１３において、設定情報保持部４８に記憶されている、検証者が受け入れる暗号方式とこの暗号方式を例外的に無効とする認証局の情報を示す図である。
【図９】検証サーバ１３において、設定情報保持部４８に記憶されている、検証者が受け入れない証明書ポリシに関する情報を示す図である。
【図１０】検証サーバ１３において、証明書有効性確認処理を示すフローチャートである。
【図１１】検証サーバ１３において、図１０の有効性確認依頼の暗号方式チェック処理を示すフローチャートである。
【図１２】検証サーバ１３において、図１０の認証パス検証処理を示すフローチャートである。
【図１３】検証サーバ１３において、図７を利用した、図１１及び図１２の暗号方式のチェック処理を示すフローチャートである。
【図１４】検証サーバ１３において、図８を利用した、図１１及び図１２の暗号方式のチェック処理を示すフローチャートである。
【発明を実施するための形態】
【００２４】
以下に、本発明の実施形態について、図面を参照して、詳細に説明する。
【００２５】
図１は、本発明の実施形態に係る検証システムの構成を示す図である。
【００２６】
本実施形態では、電子的に手続を行う複数の端末装置１１１〜端末装置１１Ｍ（「端末装置１１」と総称する）と、証明書発行及び失効業務を行うＣＡ装置１２１〜ＣＡ装置１２Ｎ（「ＣＡ装置１２」と総称する）と、証明書の失効情報を提供する検証サーバ１３と、それぞれを接続するインターネット等のネットワーク１４からなる。
【００２７】
次に、図１の検証システムを構成する各装置について説明する。
【００２８】
まず、図２を用いて、端末装置１１を説明する。
【００２９】
端末装置１１は、処理部２０ａと記憶部２０ｂと、ネットワーク１４を介して他装置と通信を行うための通信部２０ｃと、端末装置１１のユーザが作成した電子文書や他の端末装置１１から受け取った電子文書の入出力やユーザからの指示の受付を行う入出力部２０ｄと、を有する。
【００３０】
処理部２０ａは、電子文書に対して署名を付与し、署名付き文書を作成する署名付き文書作成部２１と、署名付き電子文書の署名及び証明書の検証を行う署名・証明書検証部２２と、端末装置の各部を統括的に制御する制御部２３と、を有する。
【００３１】
記憶部２０ｂは、ユーザが作成した電子文書を保持する電子文書保持部２４と、署名を生成するための秘密鍵と、これと対になる公開鍵の証明書と、当該端末装置１１を利用するユーザが信頼するＣＡのＣＡ証明書を保持する鍵保持部２５と、他の端末装置１１から受け取った署名付き電子文書と証明書を保持する検証対象保持部２６と、を有する。
【００３２】
このような構成において、制御部２３は、入出力部２０ｄを介してユーザから、電子文書保持部２４に保持してある電子文書を他のユーザに送信すべき旨の指示を受け付けると、当該電子文書を電子文書保持部２４から読み出し、これを署名付き文書作成部２１に渡す。署名付き文書作成部２１は、鍵保持部２５に保持されている秘密鍵を用いて、渡された当該電子文書に対する署名を生成する。そして、渡された電子文書に生成した署名を付与して署名付き電子文書を作成する。制御部２３は、署名付き文書作成部２１で作成された署名付き電子文書と、鍵保持部２５に保持されている証明書とを、通信部２０ｃを介して、ユーザから指示された送信先の端末装置１１へ送信する。
【００３３】
また、制御部２３は、通信部２０ｃを介して、他の端末装置１１から署名付き電子文書と証明書を受け取ると、これらを関連づけて検証対象保持部２６に保持させると共に、これらの検証要求を署名・証明書検証部２２に通知する。
【００３４】
これを受けて、署名・証明書検証部２２は、検証対象保持部２６に保持されている署名付き電子文書の署名を、同時に受け取った証明書を用いて検証する。そして、署名・証明書検証部２２は、署名付き電子文書の署名検証に使用した当該証明書を検証対象証明書として、鍵保持部２５に保持するユーザが信頼するＣＡのＣＡ証明書を用いて検証する。署名・証明書検証部２２は、当該検証対象証明書の検証処理において、当該検証対象証明書の署名の検証や、有効期間が切れていない事の確認や、その他制限事項の検証や、当該検証対象証明書が失効しているかどうかを確認する。
【００３５】
署名・証明書検証部２２は、当該検証対象証明書が失効しているかどうかの確認を行うために、検証サーバ１３に対して検証要求を送信する。そして、全ての検証が成功し、かつ、検証サーバ１３から当該証明書が失効されていない旨の検証結果を受信した場合に、当該検証対象証明書が有効であり、署名付き電子文書が正当なものと扱い、必要に応じて入出力部２０ｄから署名付き文書の署名及び証明書の検証結果を出力する。
【００３６】
次に、図３と図４を用いてＣＡ装置１２を説明する。ＣＡ装置１２はＣＲＬを利用して失効情報を提供する場合、図３の構成をとり、ＯＣＳＰレスポンダを利用して失効情報を提供する場合、図４の構成をとる。
【００３７】
ＣＡ装置１２は、処理部３０ａと、記憶部３０ｂと、ネットワーク１４を介して他装置と通信を行うための通信部３０ｃと、証明書等の入出力や当該ＣＡ装置の操作者からの指示の受付や処理結果の出力を行う入出力部３０ｄと、を有する。
【００３８】
処理部３０ａは、証明書を発行する発行部３１と、発行部３１が発行した証明書の管理を行う管理部３２と、ＣＡ装置１２の各部を統括的に制御する制御部３３と、を有する。なお、図４の構成をとるＣＡ装置１２は証明書有効性確認部３７も有する。
【００３９】
記憶部３０ｂは、発行部３１が発行した証明書を保持する証明書データベース（ＤＢ）３４と、証明書データベース３４に保持されている各証明書の発行先が記載されていた発行先管理リストを保持する発行先管理リスト保持部３５と、ＣＲＬ保持部３６と、を有する。なお、図４の構成をとるＣＡ装置１２はＣＲＬ保持部３６を保持しない。
【００４０】
このような構成において、制御部３３は、入出力部３０ｄあるいは通信部３０ｃを介して証明書の発行依頼を受け付けると、その旨を発行部３１に伝える。これを受けて、発行部３１は、これに対する証明書を作成する。この際、ＣＡの秘密鍵で証明書に署名をする。そして、作成した証明書を入出力部３０ｄあるいは通信部３０ｃを介して、郵送あるいは通信により、発行依頼元に渡す。また、この証明書を証明書データベース３４に登録すると共に、その発行先（つまり発行依頼元）の情報を、発行先管理リスト保持部３５に保持されている発行先管理リストに記載する。
【００４１】
また、制御部３３は、入出力部３０ｄあるいは通信部３０ｃを介して、証明書の失効依頼を受け付けると、その旨を管理部３２に伝える。これを受けて、管理部３２は、失効対象の証明書を証明書データベース３４から削除すると共に、発行先管理リスト保持部３５に保持されている当該証明書の情報に失効状態と失効理由を追記する。
【００４２】
そして、図３の構成をとるＣＡ装置１２の管理部３２は、失効依頼により証明書データベース３４から削除した証明書のシリアルナンバーを記載した失効証明書リスト（ＣＲＬ）を、定期的に作成し、これをＣＲＬ保持部３６に保持させる。なお、作成したＣＲＬには、当該ＣＡ装置が発行した証明書のうち、有効期限内にもかかわらず失効した証明書のシリアルナンバーと、当該証明書が失効した日時と、当該証明書が失効した理由がリストとして記載される。さらに、ＣＲＬには、次回のＣＲＬ作成予定時刻が記載され、当該ＣＡ装置の秘密鍵を用いて署名が付与される。
【００４３】
また、図３の構成をとるＣＡ装置１２の制御部３３は、通信部３０ｃを介して、他装置からＣＲＬ取得要求を受け取ると、ＣＲＬ保持部３６に保持されているＣＲＬを、通信部３０ｃを介して、問い合わせをした他装置に送信する。
【００４４】
あるいは、図４の構成をとるＣＡ装置１２の制御部３３は、通信部３０ｃを介して、他装置から証明書の失効情報を問い合わせするためのＯＣＳＰリクエストを受け取ると、証明書有効性確認部３７が証明書データベース３４に保持されている証明書の情報から当該証明書が有効か否かを表すＯＣＳＰレスポンスを作成し、通信部３０ｃを介して、問い合わせをした他装置に送信する。なお、ＯＣＳＰレスポンスには、当該証明書の状態が記載され、当該ＣＡ装置の秘密鍵あるいはＯＣＳＰレスポンダの秘密鍵を用いて署名が付与される。
【００４５】
次に、図５を用いて、検証サーバ１３を説明する。
【００４６】
検証サーバ１３は、処理部４０ａと、記憶部４０ｂと、ネットワーク１４を介して他装置と通信を行うための通信部４０ｃと、証明書等の入出力や検証サーバ１３の操作員からの指示の受付けを行う入出力部４０ｄと、を有する。
【００４７】
処理部４０ａは、定期自動更新部４１と、証明書失効情報更新部４２と、証明書更新部４３と、証明書検証部４４と、を有する。
【００４８】
記憶部４０ｂは、認証パス保持部４５と、証明書失効情報保持部４６と、証明書保持部４７と、設定情報保持部４８と、を有する。
【００４９】
定期自動更新部４１は、証明書失効情報保持部４６に記憶されている証明書失効情報を定期的に更新する時間や次回更新日時に達すると証明書失効情報更新部４２に通知する。ここで証明書失効情報とは、ＣＲＬとＯＣＳＰレスポンスを表す。また、証明書保持部４７に記憶されている証明書を定期的に更新する時間に達すると、証明書更新部４３に通知する。証明書失効情報と証明書の定期更新時間は設定情報保持部４８に記憶されている。
【００５０】
証明書失効情報更新部４２は、定期自動更新部４１から通知を受けると、当該証明書失効情報の発行元から最新の証明書失効情報を取得し、証明書失効情報保持部４６に記憶されている証明書失効情報を更新する。また、証明書失効情報更新部４２は、証明書更新部４３からの証明書失効情報更新通知を受けて、証明書失効情報保持部４６に記憶されている証明書失効情報を更新する。
【００５１】
証明書更新部４３は、定時自動更新部４１から通知を受けると、当該証明書を発行しているＣＡ装置１２の証明書データベース３４から取得する。なお、当該証明書が更新されている場合は、証明書更新部４３は、証明書保持部４７に記憶されている証明書を更新する。また、当該証明書の有効期間が切れている場合や失効している場合は、証明書更新部４３は、証明書保持部４７に記憶されている証明書を削除する。また、証明書更新部４３は、証明書検証部４４からの証明書更新通知を受けて、証明書保持部４７に記憶されている証明書を更新し、更に証明書失効情報更新通知を証明書更新部４４へ通知する。
【００５２】
証明書検証部４４は、通信部４０ｃを介して、端末装置１１から有効性確認依頼を受け付けると、認証パス保持部４５に記憶されている認証パスや証明書失効情報保持部４６に記憶されている証明書失効情報や証明書保持部４７に記憶されている証明書を利用して、有効性確認対象の証明書から検証者のトラストアンカまでの認証パスを構築し、認証パス中の証明書の有効性を順に検証する。また、検証者が受け入れ可能な証明書ポリシと、署名者の証明書に含まれる証明書ポリシが一致することを認証パスの証明書を順に利用して確かめる。また、検証サーバ１３の署名を付与した有効性確認結果を、通信部４０ｃを介して、端末装置１１に送付する。
【００５３】
なお、図２〜図５に示す端末装置１１、ＣＡ装置１２、検証サーバ１３の各々は、例えば、図６に示すような、ＣＰＵ５１と、メモリ５２と、ハードディスク等の外部記憶装置５３と、ＣＤ−ＲＯＭ等の可搬性を有する記憶媒体５９から情報を読み取る読取装置５４と、ネットワーク１４を介して他装置と通信を行うための通信装置５５と、キーボードやマウス等の入力装置５６と、モニタやプリンタ等の出力装置５７と、これらの各装置間のデータ送受を行う内部通信線５０とを備えた、一般的な電子計算機（コンピュータ）上に構築できる。
【００５４】
そして、ＣＰＵ５１が外部記憶装置５３からメモリ５２上にロードされた所定のプログラムを実行することにより、上述の各処理部を実現できる。すなわち、通信部２０ｃ、３０ｃ、４０ｃは、ＣＰＵ５１が通信装置５５を利用することにより、入出力部２０ｄ、３０ｄ、４０ｄは、ＣＰＵ５１が入力装置５６や出力装置５７や読取装置５４を利用することにより、そして、記憶部２０ｂ、３０ｂ、４０ｂは、ＣＰＵ５１がメモリ５２や外部記憶装置５３を利用することにより実現される。また、処理部２０ａ、３０ａ、４０ａは、ＣＰＵ５１のプロセスとして実現される。
【００５５】
上記所定のプログラムは、予め外部記憶装置５３に格納されていても良いし、上記電子計算機が利用可能な記憶媒体５９に格納されており、読み取り装置５４を介して、必要に応じて読み出され、あるいは、上記電子計算機が利用可能な通信媒体であるネットワークまたはネットワーク上を伝搬する搬送波を利用する通信装置５６と接続された他の装置から、必要に応じてダウンロードされて、外部記憶装置５３に導入されるものであっても良い。
【００５６】
次に図８を用いて、設定情報保持部４８に記憶されている、検証者が受け入れる暗号方式を設定したテーブルと、例外的に検証者が受け入れる暗号方式を無効にする認証局と暗号方式の関係を設定したテーブルについて説明する。なお、本実施形態において、暗号方式は、電子署名に利用する暗号アルゴリズム、公開鍵の鍵長、及び公開鍵のパラメータを表す。
【００５７】
テーブルの行の順にフィルタ番号７１の列にフィルタ番号を記載し、フィルタ番号７２の列に「署名アルゴリズム」あるいは「公開鍵アルゴリズム」のどちらかを記載する。また、検証者が受け入れる暗号アルゴリズムの名称を暗号アルゴリズム７３の列に記載し、さらに、その暗号アルゴリズムのＯＩＤ（Ｏｂｊｅｃｔ ＩＤｅｎｔｉｆｉｅｒ）を暗号アルゴリズムＯＩＤ７４の列に記載する。フィルタ種別７２が公開鍵アルゴリズムである場合、受け入れる公開鍵の鍵長を鍵長７５の列に記載する。該当する暗号アルゴリズムにおいて、全ての鍵長を受け入れる場合は、鍵長７５の列に何も記載しない。また、受け入れる公開鍵のパラメータをパラメータ７６の列に記載し、さらにそのパラメータのＯＩＤをパラメータＯＩＤ７７に記載する。該当する暗号アルゴリズムにおいて、全てのパラメータを受け入れる場合は、パラメータ７６とパラメータＯＩＤ７７の列に何も記載しない。フィルタ種別７２が署名アルゴリズムである場合、鍵長７５の列、パラメータ７６の列、パラメータＯＩＤ７７の列には何も記載しない。
【００５８】
例外的に特定の暗号アルゴリズムを特定の認証局から発行された証明書に対してのみ無効とする場合は、認証局の名称を認証局名７８の列に記載する。また、暗号アルゴリズムを指定するために、フィルタ番号７１に記されるフィルタ番号を例外的に無効とするフィルタ番号７９に記載する。例外的に検証者が受け入れる暗号方式を無効としない場合は、認証局７８の列と例外的に無効とするフィルタ番号７９の列に何も記載しない。
【００５９】
次に図９を用いて、設定情報保持部４８に記憶されている、検証者が受け入れない証明書ポリシに関する情報を設定したテーブルを説明する。
【００６０】
検証者が受け入れない証明書ポリシの名称を証明書ポリシ８１の列に記載し、さらに、その証明書ポリシのＯＩＤをＯＩＤ８２に記載する。また、ＣＡが公開しているＣＰＳからＣＡが証明書の電子署名に利用する暗号アルゴリズムを抜粋し、暗号アルゴリズム８３に記載する。
【００６１】
次に図１０を用いて、証明書検証部４４における証明書の有効性確認処理を説明する。
【００６２】
証明書検証部４４は、任意の端末装置１１からの証明書の有効性確認依頼を、通信部４０ｃを介して受信する（ステップＳ１００１）と、有効性確認依頼に含まれているＥＥ（Ｅｎｄ Ｅｎｔｉｔｙ）証明書、トラストアンカ証明書や中間証明書の証明書の暗号方式チェックを行う（ステップＳ１００２）。なお、本実施形態では、ＥＥ証明書は、公開鍵の利用者に発行する証明書であり、署名者が署名に利用する証明書を表している。また、トラストアンカ証明書は、検証者が信頼するルートＣＡの証明書を表している。また、中間証明書は、ＥＥ証明書を発行し、かつ、ＥＥの信頼するルートＣＡの下位に位置するＣＡの証明書を表している。ＥＥ証明書、トラストアンカ証明書や中間証明書の証明書の暗号方式チェックに失敗した場合、認証パス構築（ステップＳ１００５）並びに認証パス検証（ステップＳ１００７）を実施する前に、証明書検証応答作成（ステップＳ１００４）ができるため、ステップＳ１００２により、証明書検証応答を迅速に端末装置１１に送信することが可能である。図１１において、有効性確認依頼の暗号方式チェック処理の詳細について述べる。有効性確認依頼の暗号方式チェックに失敗した場合（ステップＳ１００３でＮｏ）、証明書検証部４４は、暗号方式チェックで判定したエラーコードを付与して、有効性確認結果を無効とする証明書検証応答を作成する（ステップＳ１００４）。
【００６３】
有効性確認依頼の暗号方式チェックに成功した場合（ステップＳ１００３でＹｅｓ）、証明書検証部４４は、トラストアンカからＥＥ証明書の発行者までの認証パスを構築する（ステップＳ１００５）。
【００６４】
認証パス構築に失敗した場合（ステップＳ１００６でＮｏ）、証明書検証部４４は、認証パス構築時に判定したエラーコードを付与して、ステップＳ１００４へ進む。
【００６５】
認証パス構築に成功した場合（ステップＳ１００６でＹｅｓ）、ステップＳ１００５で構築した認証パスの検証を行う（ステップＳ１００７）。ステップＳ１００７においても、暗号方式のチェックを実施することにより、認証パス中の全ての証明書の暗号方式のチェックを実施することが可能である。なお、図１２において、認証パス検証処理の詳細について述べる。
【００６６】
認証パス検証に失敗した場合（ステップＳ１００８でＮｏ）、証明書検証部４４は、認証パス検証で作成したエラー通知から、ＥＥ証明書の失効や、ＥＥ証明書の署名不正などのＥＥ証明書のエラーを原因とする認証パス検証失敗であるかどうか判断する（ステップＳ１００９）。ＥＥ証明書のエラーが原因ではない場合（ステップＳ１００９でＮｏ）、同一のトラストアンカからＥＥ証明書の発行者について、新たな認証パス構築を行うためにステップＳ１００５に戻る。ＥＥ証明書のエラーが原因の場合（ステップＳ１００９でＹｅｓ）、ステップＳ１００４へ進む。
【００６７】
認証パス検証に成功した場合（ステップＳ１００８でＹｅｓ）、証明書検証部４４は、有効性確認結果を有効とする証明書検証応答を作成する（ステップＳ１０１０）。
【００６８】
次に図１１を用いて、証明書検証部４４における、有効性確認依頼に含まれる証明書のの暗号方式のチェックの処理（図１０、ステップＳ１００２）の詳細について述べる。
【００６９】
証明書検証部４４は、ステップＳ１００１で受信したＥＥ証明書を読み込み（ステップＳ２００１）、ＥＥ証明書の電子署名に利用されている暗号方式のチェックを行う（ステップＳ２００２）。ＥＥ証明書の暗号方式が有効ではないと判定した場合（ステップＳ２００３でＮｏ）、証明書検証部４４は、有効性確認処理のエラーの原因を無効な暗号方式を含むとするエラー通知を作成する（ステップＳ２００４）。
【００７０】
ＥＥ証明書の暗号方式が有効であると判定した場合（ステップＳ２００３でＹｅｓ）、証明書検証部４４は、ステップＳ１００１で受信したトラストアンカ証明書を読み込む（ステップＳ２００５）。次に、証明書検証部４４は、トラストアンカ証明書の電子署名に利用されている暗号方式のチェックを行う（ステップＳ２００６）。トラストアンカ証明書の暗号方式が有効ではないと判定した場合（ステップＳ２００７でＮｏ）、証明書検証部４４は、Ｓ２００４へ進む。
【００７１】
トラストアンカ証明書の暗号方式が有効である場合（ステップＳ２００７でＹｅｓ）、証明書検証部４４は、有効性確認依頼に中間証明書が含まれているかどうか判定する（ステップＳ２００８）。中間証明書が含まれていない場合（ステップＳ２００８でＮｏ）、証明書検証部４４は、有効性確認依頼の暗号方式チェックの処理を成功として終了し、図１０のステップＳ１００５へ進む。
【００７２】
中間証明書が含まれている場合（ステップＳ２００８でＹｅｓ）、証明書検証部４４は、ステップＳ１００１で受信した中間証明書を読み込む（ステップＳ２００９）。次に、証明書検証部４４は、中間証明書の電子署名に利用されている暗号方式のチェックを行う（ステップＳ２０１０）。中間証明書の暗号方式が有効ではないと判定した場合（ステップＳ２０１１でＮｏ）、証明書検証部４４は、ステップＳ２００４へ進む。
【００７３】
中間証明書の暗号方式が有効であると判定した場合（ステップＳ２０１１でＹｅｓ）、証明書検証部４４は、有効性確認依頼の暗号方式チェックの処理を成功として終了し、図１０のステップＳ１００３へ進む。
【００７４】
なお、図１４において、ステップＳ２００２、ステップＳ２００６、ステップＳ２０１０の暗号方式チェックの処理の詳細について述べる。
【００７５】
次に図１２を用いて、証明書検証部４４における、図１０の認証パス検証処理（ステップＳ１００７）の詳細について述べる。
【００７６】
図１０のステップＳ１００５で構築した認証パスの全ての証明書（トラストアンカが発行した証明書からＥＥ証明書の順番）の中から次の証明書を選択する（ステップＳ３００１）。ただし、1回目は最初の証明書を選択する。
【００７７】
証明書検証部４４は、ステップＳ３００１で選択した証明書、の電子署名に利用されている暗号方式のチェックを行う（ステップＳ３００２）。選択した証明書の暗号方式が有効ではないと判定した場合（ステップＳ３００３でＮｏ）、証明書検証部４４は、有効性確認処理のエラーの原因を無効な暗号方式を含むとするエラー通知を作成する（ステップＳ３００４）。
【００７８】
なお、図１４において、ステップＳ３００２の暗号方式チェックの処理の詳細について述べる。
【００７９】
選択した証明書の暗号方式が有効であると判定した場合（ステップＳ３００３でＹｅｓ）、証明書検証部４４は、選択した証明書を認証パス中の一つ前の証明書で署名検証を行う（ステップＳ３００５）。ただし、1回目は、ステップＳ１００１（図１０）で取得したトラストアンカの証明書で署名検証を行う。
【００８０】
署名検証に失敗した場合（ステップＳ３００６でＮｏ）、証明書検証部４４は、エラーとなった証明書の種類と有効性確認処理のエラーの原因を署名不正とするエラー通知を作成する（ステップＳ３００７）。署名検証に成功した場合（ステップＳ３００６でＹｅｓ）、証明書検証部４４は、ステップＳ３００８へ進む。
【００８１】
ステップＳ３００１で選択した証明書、の証明書失効情報（ＣＲＬ、あるいは、ＯＣＳＰレスポンス）が、証明書失効情報保持部４６にあるか確認し、証明書失効情報保持部４６にある場合、証明書検証部４４は、対応する証明書失効情報を取得する。また、証明書失効情報保持部４６にない場合、証明書検証部４４は、証明書失効情報を提供するＣＡにアクセスし、最新の証明書失効情報を取得する（ステップＳ３００８）。
【００８２】
次に、証明書検証部４４は、ステップＳ３００８で取得した証明書失効情報の電子署名を、すでに認証パスの検証で有効と判定された証明書を利用して検証する（ステップＳ３００９）。証明書失効情報が有効ではないと判定した場合（ステップＳ３０１０でＮｏ）、証明書検証部４４は、エラーとなった証明書の種類と有効性確認処理のエラーの原因を失効した証明書を含むとするエラー通知を作成する（ステップＳ３０１１）。
【００８３】
証明書失効情報の検証処理に成功した場合（ステップＳ３０１０でＹｅｓ）、証明書検証部４４は、証明書失効情報に記載されている内容を確認し、ステップＳ３００１で選択した証明書が有効であるかどうか判定する（ステップＳ３０１２）。選択した証明書が有効ではないと判定した場合（ステップＳ３０１２でＮｏ）、証明書検証部４４は、ステップＳ３０１１へ進み、また選択した証明書が有効であると判定した場合（ステップＳ３０１２でＹｅｓ）、ステップＳ３０１３へ進む。
【００８４】
証明書検証部４４は、相互認証しているＣＡ間で有効と定義された証明書ポリシを認証パス中の証明書から、順次、解析することで、認証パス中で有効な証明書ポリシを導出し、かつ、検証者が有効性確認依頼に指定した証明書ポリシと一致しているか確認する、といったポリシ制御を行う。ステップＳ３００１で選択した証明書に有効な証明書ポリシが存在してない場合（ステップＳ３０１３でＮｏ）、証明書検証部４４は、有効性確認処理のエラーの原因を無効な証明書ポリシ含むとするエラー通知を作成する（ステップＳ３０１４）。
【００８５】
ポリシ制御を行い、ステップＳ３００１で選択した証明書、に有効な証明書ポリシが存在している場合（ステップＳ３０１３でＹｅｓ）、証明書検証部４４は、選択した証明書ポリシが、設定情報保持部４８の、検証者が受け入れない（無効とする）証明書ポリシを設定したテーブル（図９）に含まれているか判定する（ステップＳ３０１５）。
【００８６】
検証者が無効とする証明書ポリシが含まれる場合（ステップＳ３０１５でＹｅｓ）、証明書検証部４４は、ステップＳ３０１４へ進む。検証者が無効とする証明書ポリシが含まれない場合（ステップＳ３０１５でＮｏ）、証明書検証部４４は、ステップＳ３０１６へ進む。
【００８７】
選択した証明書がＥＥ証明書でない場合（ステップＳ３０１６でＮｏ）、証明書検証部４４は、ステップＳ３００１へ戻る。選択した証明書がＥＥ証明書である場合（ステップＳ３０１６でＹｅｓ）、証明書検証部４４は、有効性確認処理結果を有効とする正常終了通知を作成する（ステップＳ３０１７）。
【００８８】
次に図１４を用いて、証明書証部４４における、図１１の暗号方式チェックの処理（ステップＳ２００２、ステップＳ２００６、ステップＳ２０１０）と、図１２の暗号方式チェックの処理（ステップＳ３００２）の詳細について述べる。図１４では、図８の検証者が受け入れる暗号方式を設定したテーブルを利用する。
【００８９】
証明書検証部４４は、ステップＳ２００１、ステップＳ２００５あるいはステップＳ２００９で読み込んだ証明書に記載の署名アルゴリズム（ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ）の項目から署名アルゴリズムのＯＩＤを、また、所有者公開鍵情報（ｓｕｂｊｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏ）から公開鍵のアルゴリズムのＯＩＤ、鍵長、パラメータのＯＩＤを取得する（ステップＳ５００１）。
【００９０】
ステップＳ５００１で取得した暗号方式が、図８の検証者が受け入れる暗号方式を設定したテーブルに含まれていない場合（ステップＳ５００２でＮｏ）、証明書検証部４４は、暗号方式が無効と通知して（ステップＳ５００３）処理を終了する。
【００９１】
ステップＳ５００１で取得した暗号方式が、図８の検証者が受け入れる暗号方式を設定したテーブルに含まれる場合（ステップＳ５００２でＹｅｓ）、証明書検証部４４は、ステップＳ５００１で取得した暗号方式に該当するフィルタ番号を図８のフィルタ番号８１から取得する（ステップＳ５００４）。次に、証明書検証部４４は、ステップＳ２００１、ステップＳ２００５あるいはステップＳ２００９で読み込んだ証明書の発行者名（ｉｓｓｕｅｒ）の項目からＣＡ装置の情報（例えば、認証局名）を取得する（ステップＳ５００５）。
【００９２】
ステップ５００４で取得したフィルタ番号とステップＳ５００５で取得した認証局名の組み合わせが、図８の認証局名７７と例外的に無効とするフィルタ番号７８に存在する場合（ステップＳ５００６でＹｅｓ）、証明書検証部４４は、ステップＳ５００３へ進む。
【００９３】
ステップ５００４で取得したフィルタ番号とステップＳ５００５で取得した認証局名の組み合わせが、図８の認証局名７７と例外的に無効とするフィルタ番号７８に存在しない場合（ステップＳ５００６でＮｏ）、証明書検証部４４は、暗号方式が有効と通知して（ステップＳ５００７）処理を終了する。
【００９４】
(他の実施形態)
上記実施形態では、図８に示す、検証者が受け入れる暗号方式とこの暗号方式を例外的に無効とする認証局の情報を利用して、図１４に示す暗号方式のチェック処理を行う場合を例にとり説明したが、図７に示す、検証者が受け入れる暗号方式とこの暗号方式を例外的に有効とする認証局の情報を利用して、図３に示す暗号方式のチェック処理を行うようにしても良い。
【００９５】
図７を用いて、設定情報保持部４８に記憶されている、検証者が受け入れない暗号方式を設定したテーブルと、例外的に検証者が受け入れない暗号方式を有効にする認証局と暗号方式の関係を設定したテーブルについて説明する。
【００９６】
テーブルの行の順にフィルタ番号６１の列にフィルタ番号を記載し、フィルタ番号６２の列に「署名アルゴリズム」あるいは「公開鍵アルゴリズム」のどちらかを記載する。また、検証者が受け入れない暗号アルゴリズムの名称を暗号アルゴリズム６３の列に記載し、さらに、その暗号アルゴリズムのＯＩＤ（Ｏｂｊｅｃｔ ＩＤｅｎｔｉｆｉｅｒ）を暗号アルゴリズムＯＩＤ６４の列に記載する。フィルタ種別６２が公開鍵アルゴリズムである場合、受け入れない公開鍵の鍵長を鍵長６５の列に記載する。該当する暗号アルゴリズムにおいて、全ての鍵長を受け入れない場合は、鍵長６５の列に何も記載しない。また、受け入れない公開鍵のパラメータをパラメータ６６の列に記載し、さらにそのパラメータのＯＩＤをパラメータＯＩＤ６７に記載する。該当する暗号アルゴリズムにおいて、全てのパラメータを受け入れない場合は、パラメータ６６とパラメータＯＩＤ６７の列に何も記載しない。フィルタ種別６２が署名アルゴリズムである場合、鍵長６５の列、パラメータ６６の列、パラメータＯＩＤ６７の列には何も記載しない。
【００９７】
例外的に特定の暗号アルゴリズムを特定の認証局から発行された証明書に対してのみ有効とする場合は、認証局の名称を認証局名６８の列に記載する。また、暗号アルゴリズムを指定するために、フィルタ番号６１に記されるフィルタ番号を例外的に有効とするフィルタ番号６９に記載する。例外的に検証者が受け入れない暗号方式を有効としない場合は、認証局６８の列と例外的に有効とするフィルタ番号６９の列に何も記載しない。
【００９８】
次に図１３を用いて、証明書検証部４４における、図１１の暗号方式チェックの処理（ステップＳ２００２、ステップＳ２００６、ステップＳ２０１０）と、図１２の暗号方式チェックの処理（ステップＳ３００２）の詳細について述べる。図１３では、図７の検証者が受け入れない暗号方式を設定したテーブルを利用する。
【００９９】
証明書検証部４４は、ステップＳ２００１、ステップＳ２００５あるいはステップＳ２００９で読み込んだ証明書の署名アルゴリズム（ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ）の項目から署名アルゴリズムのＯＩＤを、また、所有者公開鍵情報（ｓｕｂｊｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏ）から公開鍵のアルゴリズムのＯＩＤ、鍵長、パラメータのＯＩＤを取得する（ステップＳ４００１）。
【０１００】
ステップＳ４００１で取得した暗号方式が、図７の検証者が受け入れない暗号方式を設定したテーブルに含まれない場合（ステップＳ４００２でＮｏ）、証明書検証部４４は、暗号方式が有効と通知して（ステップＳ４００３）、処理を終了する。
【０１０１】
ステップＳ４００１で取得した暗号方式が、図７の検証者が受け入れない暗号方式を設定したテーブルに含まれる場合（ステップＳ４００２でＹｅｓ）、証明書検証部４４は、ステップＳ４００１で取得した暗号方式に該当するフィルタ番号を図７のフィルタ番号６１から取得する（ステップＳ４００４）。次に、証明書検証部４４は、ステップＳ２００１、ステップＳ２００５あるいはステップＳ２００９で読み込んだ証明書の発行者名（ｉｓｓｕｅｒ）の項目から認証局名を取得する（ステップＳ４００５）。
【０１０２】
ステップ４００４で取得したフィルタ番号６１とステップＳ４００５で取得した認証局名の組み合わせが、図７の認証局名６７と例外的に有効とするフィルタ番号６８に存在する場合（ステップＳ４００６でＹｅｓ）、ステップＳ４００３へ進む。
【０１０３】
ステップ４００３で取得したフィルタ番号とステップＳ４００４で取得した認証局名の組み合わせが、図７の認証局名６７と例外的に有効とするフィルタ番号６８に存在しない場合（ステップＳ４００６でＮｏ）、証明書検証部４４は、暗号方式が無効と通知して（ステップＳ４００７）、処理を終了する。
【０１０４】
また、上記実施形態では、認証パス検証前の証明書の有効性確認依頼を受信した時と認証パス検証時に、証明書の電子署名に利用されている暗号方式をチェックする処理を例にとり説明したが、何れか一方を実施する形態であっても良い。
【０１０５】
また、上記実施形態では、暗号方式を、電子署名に利用する暗号アルゴリズム、公開鍵の鍵長、及び公開鍵のパラメータとして定義して、証明書の有効性確認処理を説明したが、暗号方式は何れか一つかあるいは二つを実施する形態であっても良い。
【０１０６】
以上本発明の実施形態について詳述したが、上記実施形態によれば、証明書の有効性確認処理を安全にかつ迅速に行うことができる証明書の有効性確認方法、これを実施する検証サーバ、プログラム及び記憶媒体を提供することができる。また、証明書の有効性確認処理における、認証パスの構築や認証パスの検証を安全かつ迅速に行うことができる。
【０１０７】
また、本発明は上記実施形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【符号の説明】
【０１０８】
１１：端末装置、１２：ＣＡ装置、１３：検証サーバ、１４：ネットワーク、２０ａ、３０ａ、４０ａ：処理部、２０ｂ、３０ｂ、４０ｂ：記憶部、２０ｃ、３０ｃ、４０ｃ：通信部、２０ｄ、３０ｄ、４０ｄ：入出力部、２１：署名付き文書作成部、２２：署名・証明書検証部、２３、３３：制御部、２４：電子文書保持部、２５：鍵保持部、２６：検証対象保持部、３１：発行部、３２：管理部、３４：証明書ＤＢ、３５：発行先管理リスト保持部、３６：ＣＲＬ保持部、３７：証明書有効性確認部、４１：定期自動更新部、４２：証明書失効情報更新部、４３：証明書更新部、４４：証明書検証部、４５：認証パス保持部、４６：証明書失効保持部、４７：証明書保持部、４８：設定情報保持部、５０：内部通信線、５１：ＣＰＵ、５２：メモリ、５３：外部記憶装置、５４：読取装置、５５：通信装置、５６：入力装置、５７：出力装置、５９：可搬性を有する記憶媒体。
【技術分野】
【０００１】
本発明は、公開鍵認証基盤（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ；以下、「ＰＫＩ」と記述する）において、証明書の有効性を確認するのに好適な技術に関する。
【背景技術】
【０００２】
政府認証基盤（ＧＰＫＩ）をはじめとして、電子文書の作成者を明らかにし、かつ、当該電子文書が改ざんされていないことを保証するために、公開鍵認証基盤（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ；以下、「ＰＫＩ」と記載する）を利用したシステムが普及してきている。ＰＫＩを利用したシステムでは、電子文書に対して、電子署名を行う者（以下、署名者、と記載する）のみが保有する、秘密鍵（Ｐｒｉｖａｔｅ Ｋｅｙ）と呼ばれる鍵によって、一定の処理手順（以下、「暗号アルゴリズム」と記載する）に従い、電子署名が施される。電子署名が施された電子文書を受信した場合には、署名者の秘密鍵とペアであり、また、他人に公開しても良い、公開鍵（Ｐｕｂｌｉｃ Ｋｅｙ）と呼ばれる鍵によって、上記電子署名を検証することで、電子文書の作成者と、当該電子文書が改ざんされていないことと、を確認する。高い信頼が要求される用途では、署名者と公開鍵の結びつきを保証するために、認証局（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ；以下、「ＣＡ」と記載する）が、上記署名者の公開鍵証明書（以下、「証明書」と記載する）を発行する。証明書には、ＣＡの名前、有効期限、所有者の名前、所有者の公開鍵に関する情報など、また、オプションとして、鍵使用目的、証明書ポリシなどが含まれる。証明書ポリシとは、各ＣＡが証明書を発行する際に定める証明書の利用目的やセキュリティレベルなどを規定するものであり、証明書ポリシには、この証明書ポリシを一意に示すＩＤが付与されている。さらに、証明書の記載内容を保証するために、ＣＡは、ＣＡの秘密鍵を利用し、定められた暗号アルゴリズムに従って、該証明書に対する電子署名を生成し、証明書に付与する。証明書の記載内容は、非特許文献１の「 ４． Ｃｅｒｔｉｆｉｃａｔｅ ａｎｄ Ｃｅｒｔｉｆｉｃａｔｅ Ｅｘｔｅｎｓｉｏｎｓ Ｐｒｏｆｉｌｅ」に詳細に記載されている。
【０００３】
より厳密な電子署名の検証を行うためには、ＣＡが発行した、上記署名者の証明書に含まれている、公開鍵と呼ばれる鍵によって、当該電子署名を検証するだけではなく、上記署名者の証明書が電子署名を検証する者（以下、「検証者」と記載する）にとって利用目的等やセキュリティレベルを満足する有効な証明書であるか否か、を確認する必要がある。上記署名者の証明書が上記検証者にとって有効であるか否か、を検証するには、（１）認証パスの構築、（２）認証パスの検証、という、処理が必要である。
【０００４】
（１）認証パスの構築の処理において、検証者の信頼するＣＡ（トラストアンカ、以下、「トラストアンカ」は「ＴＡ」と記載する）から署名者の証明書までの信頼の連鎖である証明書チェーンを構築する。証明書チェーンは、複数の証明書の連なったものであり、ある証明書の主体者名が次の証明書の発行者名に一致し、また、証明書の主体者の鍵識別子が次の証明書の発行者の鍵識別子に一致している関係が、連鎖する証明書の列である。検証者は、各ＣＡのリポジトリにアクセスして、上記の証明書チェーンを構成する証明書を取得し、上記連鎖の確認を行う。特に、認証局の運用主体が異なるような、異なるドメインのＣＡ同士が接続したＰＫＩモデルにおいては、ＣＡ同士がお互いに相互認証証明書と呼ばれる証明書を発行し合う。一般に、この、相互認証証明書には、異なるドメイン間で証明書ポリシなどの調整を行い相互運用するための情報が記載されていることが多い。このため、複数の異なるドメインに渡る認証パスを構築する場合、証明書チェーンに相互認証証明書が含まれることになる。認証パスを構築する方法については、非特許文献２に詳細に記載されている。
【０００５】
（２）認証パスの検証の処理において、（１）の処理で構築した認証パスを構成する証明書チェーンの証明書が全て有効であることを確かめる。具体的には、ＣＡが発行する証明書失効リスト（Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ；以下、「ＣＲＬ」と記載する）やＯＣＳＰ（Ｏｎｌｉｎｅ Ｃｅｒｔｉｆｉｃａｔｅ Ｓｔａｔｕｓ Ｐｒｏｔｏｃｏｌ）レスポンダを利用して、証明書が有効か否かを判定する。また、検証者が受け入れ可能な証明書ポリシと、署名者の証明書に含まれる証明書ポリシが一致することを確かめる。認証パスを検証する方法については、非特許文献１の「 ６． Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ｐａｔｈ Ｖａｌｉｄａｔｉｏｎ」に詳細に記載されている。
【０００６】
証明書の有効性を検証するモデルには、検証者自身が証明書の有効性を確認するエンドエンティティモデルと、検証者に代わってオンラインで証明書の有効性を確認する機能を提供する証明書検証サーバ（以下、「検証サーバ」と記載する）を利用する検証サーバモデルがある。検証サーバモデルの仕様は非特許文献３に記載されている。
【０００７】
上記検証サーバモデルは、上記エンドエンティティモデルに比べて、次のような利点がある。まず、上記検証サーバモデルでは、上記認証パスを構築する認証パス構築機能をクライアントに実装する必要がないため、クライアントの証明書検証プログラムを小さくすることができる。また、クライアントは上記検証サーバの判定結果を信頼するため、上記検証サーバの設定を変更するだけで、システム構成の変化に柔軟に対応できる。
【０００８】
証明書の有効性確認を行う毎に、検証サーバが認証パスを構築し、また、ＣＡからＣＲＬを取得すると、有効性確認処理にかかる時間が長くなるため、特許文献１では、検証サーバが有効性確認処理を行った上記ＣＲＬや上記認証パスを登録することにより次回からの証明書の有効性確認処理を高速化する方式が開示されている。
【０００９】
一方で、電子文書に対する電子署名生成やＣＡによる証明書の電子署名生成において、署名者やＣＡは、電子署名に利用する暗号アルゴリズム、パラメータ、並びに公開鍵の鍵長に関して、複数の選択肢の中から利用するものを選択しているが、近年の暗号解読技術の進歩や電子計算機能力の向上により、一部の暗号アルゴリズム、また、鍵長の短い公開鍵は、安全性に問題があることが指摘されている。米国連邦政府の標準暗号を制定する米国立標準技術研究所では、２０１０年までに、米国政府での情報システムにおいて、電子署名に利用するハッシュ関数を、ＳＨＡ−１からＳＨＡ-２へ移行することを強く推奨している。ＳＨＡ−１の安全性に関するコメントは、非特許文献４に詳細に記載されている。
【００１０】
非特許文献４のコメントを受け、各国の認証局は、現行の暗号アルゴリズムを利用している情報システムとの互換性を保ちつつ、利用者の公開鍵や、証明書の電子署名に利用する暗号アルゴリズムを、より安全性の高いものに移行することとしている。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２００２−７２８７６号公報
【非特許文献】
【００１２】
【非特許文献１】Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile (RFC5280), 2008年5月, [online], [平成21年11月17日検索], インターネット＜URL:http://www.ietf.org/rfc/rfc5280.txt＞
【非特許文献２】Internet X.509 Public Key Infrastructure Certification Path Building (RFC4158), 「 2. Certification Path Building」, 2005年9月, [online], [平成21年11月17日検索], インターネット＜URL:http://www.ietf.org/rfc/rfc4158.txt＞
【非特許文献３】Delegated Path Validation and Delegated Path Discovery Protocol Requirements (RFC3379), 2002年9月, [online], [平成21年11月17日検索], インターネット＜URL:http://www.ietf.org/rfc/rfc3379.txt＞
【非特許文献４】NIST Comments on Cryptanalytic Attacks on SHA-1, 2006年4月, [online], [平成21年11月17日検索], インターネット＜URL:http://csrc.nist.gov/groups/ST/hash/statement.html＞
【発明の概要】
【発明が解決しようとする課題】
【００１３】
認証局が暗号アルゴリズムを移行している時期（以下、「暗号移行期」と記載する）では、暗号移行前に現行の暗号アルゴリズムで電子署名した証明書と、暗号移行後に、より安全性の高い暗号アルゴリズムで電子署名した証明書が混在することとなる。そのため、検証者が明示的に特定の暗号アルゴリズムで電子署名した証明書を受け入れたくない場合や、現行の暗号アルゴリズムの安全性が著しく低下し、暗号アルゴリズム危殆化と判断された場合には、その暗号アルゴリズムを利用する証明書の検証を失敗とする必要がある。
【００１４】
また、上記非特許文献１では、検証者が、有効性確認依頼時に、明示的に受け入れる証明書ポリシを指定することで、検証者自身が、有効性確認の制約を設ける手法が記載されている。しかし、暗号移行期では、複数の情報システムの相互運用性確保のために、暗号移行中のＣＡが、まだ暗号移行を行っていないＣＡと相互認証を行うことで、暗号強度の高い証明書ポリシを、暗号強度の低い証明書ポリシに、マッピングし、ポリシーマッピングの情報を相互認証証明書に記載する場合がある。このような場合において、暗号移行を行ったＣＡを信頼点とする検証者が、暗号移行を行っていないＣＡから発行された証明書に対して有効性確認処理を行うと、上記相互認証証明書から、暗号強度の高い証明書ポリシが暗号強度の低い証明書と同等と判断され、有効性確認処理の結果が有効となる可能性がある。検証者は、暗号強度の高い証明書ポリシを指定しても、暗号強度の低い暗号アルゴリズムで電子署名した証明書を除外することができないため、有効性確認処理結果の信頼性が失われてしまう。
【００１５】
さらに、上記非特許文献１や上記特許文献１に記載の技術では、ＣＡの電子署名が付与された証明書、ＣＲＬやＯＣＳＰレスポンスをＣＡから取得して、認証パスの検証を行っているが、暗号移行期に、暗号アルゴリズム危殆化が発生し、該当する暗号アルゴリズムの使用停止の通達が政府機関等から出た場合においては、認証パスの検証で次に述べる課題が発生する。
【００１６】
ＣＡが暗号移行を行う前や、暗号移行を行っている途中に、現行の暗号アルゴリズムの危殆化が発生した場合に、ＣＡは、電子署名に利用する暗号アルゴリズムをより安全性の高いものへ移行した後、危殆化した暗号アルゴリズムを利用した証明書を失効し、さらに、新しい暗号アルゴリズムで証明書失効リストや証明書を発行する必要がある。しかし、上記は対応するのに時間を要する処置であるため、ＣＡが迅速に対応できない可能性が高い。したがって、このような場合は、ＣＡから提供される、危殆化した暗号アルゴリズムで電子署名された情報を、認証パスの検証で利用することになるため、有効性確認処理結果の信頼性が失われてしまう。
【００１７】
本発明は上記事項に鑑みてなされたものであり、証明書の有効性確認処理を安全にかつ迅速に行うことができる証明書の有効性確認方法、これを実施する検証サーバ、プログラム及び記憶媒体を提供することを課題とする。
【課題を解決するための手段】
【００１８】
上記課題を解決するための一手段を説明する。本発明では、複数の端末装置及び複数の認証局とネットワークに接続された検証サーバにより、任意の端末装置からネットワークを介して証明書の有効性確認依頼を受信し、第一の認証局から第二の認証局までの認証パスを構築し、該認証パスの検証を行い、該検証結果を前記証明書の有効性確認依頼元の端末装置へ前記ネットワークを介して送信する、証明書の有効性確認処理において、前記検証サーバが、以下に示す構成を有することを特徴とする。
【００１９】
前記検証サーバは、前記証明書の電子署名に利用されている暗号方式に関する情報を記憶する記憶部を有することを特徴とする。
【００２０】
前記検証サーバは、前記有効性確認依頼に含まれる証明書から第一の暗号方式に関する情報を取得し、前記第一の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されていない場合に、前記第一の暗号方式に関する情報を無効と判断することを特徴とする。
【００２１】
また、前記検証サーバは、前記第一の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されており、かつ、前記認証パスの検証時に、前記認証パス中の前記証明書に記載の第二の暗号方式に関する情報が前記記憶部に記憶されていない場合に、前記第二の暗号方式に関する情報を無効と判断することを特徴とする。
【発明の効果】
【００２２】
本発明によれば、証明書の有効性確認処理を安全にかつ迅速に行うことができる証明書の有効性確認方法、これを実施する検証サーバ、プログラム及び記憶媒体を提供することができる。
【図面の簡単な説明】
【００２３】
【図１】本発明の実施形態に係る検証システムの構成を示す図である。
【図２】端末装置１１の構成を示す図である。
【図３】ＣＲＬを利用して失効情報を提供するＣＡ装置１２の構成を示す図である。
【図４】ＯＣＳＰレスポンダを利用して失効情報を提供するＣＡ装置１２の構成を示す図である。
【図５】検証サーバ１３の構成を示す図である。
【図６】図２〜４に示す端末装置１１、ＣＡ装置１２、検証サーバ１３の各々のハードウェア構成例を示す図である。
【図７】検証サーバ１３において、設定情報保持部４８に記憶されている、検証者が受け入れない暗号方式とこの暗号方式を例外的に有効とする認証局の情報を示す図である。
【図８】検証サーバ１３において、設定情報保持部４８に記憶されている、検証者が受け入れる暗号方式とこの暗号方式を例外的に無効とする認証局の情報を示す図である。
【図９】検証サーバ１３において、設定情報保持部４８に記憶されている、検証者が受け入れない証明書ポリシに関する情報を示す図である。
【図１０】検証サーバ１３において、証明書有効性確認処理を示すフローチャートである。
【図１１】検証サーバ１３において、図１０の有効性確認依頼の暗号方式チェック処理を示すフローチャートである。
【図１２】検証サーバ１３において、図１０の認証パス検証処理を示すフローチャートである。
【図１３】検証サーバ１３において、図７を利用した、図１１及び図１２の暗号方式のチェック処理を示すフローチャートである。
【図１４】検証サーバ１３において、図８を利用した、図１１及び図１２の暗号方式のチェック処理を示すフローチャートである。
【発明を実施するための形態】
【００２４】
以下に、本発明の実施形態について、図面を参照して、詳細に説明する。
【００２５】
図１は、本発明の実施形態に係る検証システムの構成を示す図である。
【００２６】
本実施形態では、電子的に手続を行う複数の端末装置１１１〜端末装置１１Ｍ（「端末装置１１」と総称する）と、証明書発行及び失効業務を行うＣＡ装置１２１〜ＣＡ装置１２Ｎ（「ＣＡ装置１２」と総称する）と、証明書の失効情報を提供する検証サーバ１３と、それぞれを接続するインターネット等のネットワーク１４からなる。
【００２７】
次に、図１の検証システムを構成する各装置について説明する。
【００２８】
まず、図２を用いて、端末装置１１を説明する。
【００２９】
端末装置１１は、処理部２０ａと記憶部２０ｂと、ネットワーク１４を介して他装置と通信を行うための通信部２０ｃと、端末装置１１のユーザが作成した電子文書や他の端末装置１１から受け取った電子文書の入出力やユーザからの指示の受付を行う入出力部２０ｄと、を有する。
【００３０】
処理部２０ａは、電子文書に対して署名を付与し、署名付き文書を作成する署名付き文書作成部２１と、署名付き電子文書の署名及び証明書の検証を行う署名・証明書検証部２２と、端末装置の各部を統括的に制御する制御部２３と、を有する。
【００３１】
記憶部２０ｂは、ユーザが作成した電子文書を保持する電子文書保持部２４と、署名を生成するための秘密鍵と、これと対になる公開鍵の証明書と、当該端末装置１１を利用するユーザが信頼するＣＡのＣＡ証明書を保持する鍵保持部２５と、他の端末装置１１から受け取った署名付き電子文書と証明書を保持する検証対象保持部２６と、を有する。
【００３２】
このような構成において、制御部２３は、入出力部２０ｄを介してユーザから、電子文書保持部２４に保持してある電子文書を他のユーザに送信すべき旨の指示を受け付けると、当該電子文書を電子文書保持部２４から読み出し、これを署名付き文書作成部２１に渡す。署名付き文書作成部２１は、鍵保持部２５に保持されている秘密鍵を用いて、渡された当該電子文書に対する署名を生成する。そして、渡された電子文書に生成した署名を付与して署名付き電子文書を作成する。制御部２３は、署名付き文書作成部２１で作成された署名付き電子文書と、鍵保持部２５に保持されている証明書とを、通信部２０ｃを介して、ユーザから指示された送信先の端末装置１１へ送信する。
【００３３】
また、制御部２３は、通信部２０ｃを介して、他の端末装置１１から署名付き電子文書と証明書を受け取ると、これらを関連づけて検証対象保持部２６に保持させると共に、これらの検証要求を署名・証明書検証部２２に通知する。
【００３４】
これを受けて、署名・証明書検証部２２は、検証対象保持部２６に保持されている署名付き電子文書の署名を、同時に受け取った証明書を用いて検証する。そして、署名・証明書検証部２２は、署名付き電子文書の署名検証に使用した当該証明書を検証対象証明書として、鍵保持部２５に保持するユーザが信頼するＣＡのＣＡ証明書を用いて検証する。署名・証明書検証部２２は、当該検証対象証明書の検証処理において、当該検証対象証明書の署名の検証や、有効期間が切れていない事の確認や、その他制限事項の検証や、当該検証対象証明書が失効しているかどうかを確認する。
【００３５】
署名・証明書検証部２２は、当該検証対象証明書が失効しているかどうかの確認を行うために、検証サーバ１３に対して検証要求を送信する。そして、全ての検証が成功し、かつ、検証サーバ１３から当該証明書が失効されていない旨の検証結果を受信した場合に、当該検証対象証明書が有効であり、署名付き電子文書が正当なものと扱い、必要に応じて入出力部２０ｄから署名付き文書の署名及び証明書の検証結果を出力する。
【００３６】
次に、図３と図４を用いてＣＡ装置１２を説明する。ＣＡ装置１２はＣＲＬを利用して失効情報を提供する場合、図３の構成をとり、ＯＣＳＰレスポンダを利用して失効情報を提供する場合、図４の構成をとる。
【００３７】
ＣＡ装置１２は、処理部３０ａと、記憶部３０ｂと、ネットワーク１４を介して他装置と通信を行うための通信部３０ｃと、証明書等の入出力や当該ＣＡ装置の操作者からの指示の受付や処理結果の出力を行う入出力部３０ｄと、を有する。
【００３８】
処理部３０ａは、証明書を発行する発行部３１と、発行部３１が発行した証明書の管理を行う管理部３２と、ＣＡ装置１２の各部を統括的に制御する制御部３３と、を有する。なお、図４の構成をとるＣＡ装置１２は証明書有効性確認部３７も有する。
【００３９】
記憶部３０ｂは、発行部３１が発行した証明書を保持する証明書データベース（ＤＢ）３４と、証明書データベース３４に保持されている各証明書の発行先が記載されていた発行先管理リストを保持する発行先管理リスト保持部３５と、ＣＲＬ保持部３６と、を有する。なお、図４の構成をとるＣＡ装置１２はＣＲＬ保持部３６を保持しない。
【００４０】
このような構成において、制御部３３は、入出力部３０ｄあるいは通信部３０ｃを介して証明書の発行依頼を受け付けると、その旨を発行部３１に伝える。これを受けて、発行部３１は、これに対する証明書を作成する。この際、ＣＡの秘密鍵で証明書に署名をする。そして、作成した証明書を入出力部３０ｄあるいは通信部３０ｃを介して、郵送あるいは通信により、発行依頼元に渡す。また、この証明書を証明書データベース３４に登録すると共に、その発行先（つまり発行依頼元）の情報を、発行先管理リスト保持部３５に保持されている発行先管理リストに記載する。
【００４１】
また、制御部３３は、入出力部３０ｄあるいは通信部３０ｃを介して、証明書の失効依頼を受け付けると、その旨を管理部３２に伝える。これを受けて、管理部３２は、失効対象の証明書を証明書データベース３４から削除すると共に、発行先管理リスト保持部３５に保持されている当該証明書の情報に失効状態と失効理由を追記する。
【００４２】
そして、図３の構成をとるＣＡ装置１２の管理部３２は、失効依頼により証明書データベース３４から削除した証明書のシリアルナンバーを記載した失効証明書リスト（ＣＲＬ）を、定期的に作成し、これをＣＲＬ保持部３６に保持させる。なお、作成したＣＲＬには、当該ＣＡ装置が発行した証明書のうち、有効期限内にもかかわらず失効した証明書のシリアルナンバーと、当該証明書が失効した日時と、当該証明書が失効した理由がリストとして記載される。さらに、ＣＲＬには、次回のＣＲＬ作成予定時刻が記載され、当該ＣＡ装置の秘密鍵を用いて署名が付与される。
【００４３】
また、図３の構成をとるＣＡ装置１２の制御部３３は、通信部３０ｃを介して、他装置からＣＲＬ取得要求を受け取ると、ＣＲＬ保持部３６に保持されているＣＲＬを、通信部３０ｃを介して、問い合わせをした他装置に送信する。
【００４４】
あるいは、図４の構成をとるＣＡ装置１２の制御部３３は、通信部３０ｃを介して、他装置から証明書の失効情報を問い合わせするためのＯＣＳＰリクエストを受け取ると、証明書有効性確認部３７が証明書データベース３４に保持されている証明書の情報から当該証明書が有効か否かを表すＯＣＳＰレスポンスを作成し、通信部３０ｃを介して、問い合わせをした他装置に送信する。なお、ＯＣＳＰレスポンスには、当該証明書の状態が記載され、当該ＣＡ装置の秘密鍵あるいはＯＣＳＰレスポンダの秘密鍵を用いて署名が付与される。
【００４５】
次に、図５を用いて、検証サーバ１３を説明する。
【００４６】
検証サーバ１３は、処理部４０ａと、記憶部４０ｂと、ネットワーク１４を介して他装置と通信を行うための通信部４０ｃと、証明書等の入出力や検証サーバ１３の操作員からの指示の受付けを行う入出力部４０ｄと、を有する。
【００４７】
処理部４０ａは、定期自動更新部４１と、証明書失効情報更新部４２と、証明書更新部４３と、証明書検証部４４と、を有する。
【００４８】
記憶部４０ｂは、認証パス保持部４５と、証明書失効情報保持部４６と、証明書保持部４７と、設定情報保持部４８と、を有する。
【００４９】
定期自動更新部４１は、証明書失効情報保持部４６に記憶されている証明書失効情報を定期的に更新する時間や次回更新日時に達すると証明書失効情報更新部４２に通知する。ここで証明書失効情報とは、ＣＲＬとＯＣＳＰレスポンスを表す。また、証明書保持部４７に記憶されている証明書を定期的に更新する時間に達すると、証明書更新部４３に通知する。証明書失効情報と証明書の定期更新時間は設定情報保持部４８に記憶されている。
【００５０】
証明書失効情報更新部４２は、定期自動更新部４１から通知を受けると、当該証明書失効情報の発行元から最新の証明書失効情報を取得し、証明書失効情報保持部４６に記憶されている証明書失効情報を更新する。また、証明書失効情報更新部４２は、証明書更新部４３からの証明書失効情報更新通知を受けて、証明書失効情報保持部４６に記憶されている証明書失効情報を更新する。
【００５１】
証明書更新部４３は、定時自動更新部４１から通知を受けると、当該証明書を発行しているＣＡ装置１２の証明書データベース３４から取得する。なお、当該証明書が更新されている場合は、証明書更新部４３は、証明書保持部４７に記憶されている証明書を更新する。また、当該証明書の有効期間が切れている場合や失効している場合は、証明書更新部４３は、証明書保持部４７に記憶されている証明書を削除する。また、証明書更新部４３は、証明書検証部４４からの証明書更新通知を受けて、証明書保持部４７に記憶されている証明書を更新し、更に証明書失効情報更新通知を証明書更新部４４へ通知する。
【００５２】
証明書検証部４４は、通信部４０ｃを介して、端末装置１１から有効性確認依頼を受け付けると、認証パス保持部４５に記憶されている認証パスや証明書失効情報保持部４６に記憶されている証明書失効情報や証明書保持部４７に記憶されている証明書を利用して、有効性確認対象の証明書から検証者のトラストアンカまでの認証パスを構築し、認証パス中の証明書の有効性を順に検証する。また、検証者が受け入れ可能な証明書ポリシと、署名者の証明書に含まれる証明書ポリシが一致することを認証パスの証明書を順に利用して確かめる。また、検証サーバ１３の署名を付与した有効性確認結果を、通信部４０ｃを介して、端末装置１１に送付する。
【００５３】
なお、図２〜図５に示す端末装置１１、ＣＡ装置１２、検証サーバ１３の各々は、例えば、図６に示すような、ＣＰＵ５１と、メモリ５２と、ハードディスク等の外部記憶装置５３と、ＣＤ−ＲＯＭ等の可搬性を有する記憶媒体５９から情報を読み取る読取装置５４と、ネットワーク１４を介して他装置と通信を行うための通信装置５５と、キーボードやマウス等の入力装置５６と、モニタやプリンタ等の出力装置５７と、これらの各装置間のデータ送受を行う内部通信線５０とを備えた、一般的な電子計算機（コンピュータ）上に構築できる。
【００５４】
そして、ＣＰＵ５１が外部記憶装置５３からメモリ５２上にロードされた所定のプログラムを実行することにより、上述の各処理部を実現できる。すなわち、通信部２０ｃ、３０ｃ、４０ｃは、ＣＰＵ５１が通信装置５５を利用することにより、入出力部２０ｄ、３０ｄ、４０ｄは、ＣＰＵ５１が入力装置５６や出力装置５７や読取装置５４を利用することにより、そして、記憶部２０ｂ、３０ｂ、４０ｂは、ＣＰＵ５１がメモリ５２や外部記憶装置５３を利用することにより実現される。また、処理部２０ａ、３０ａ、４０ａは、ＣＰＵ５１のプロセスとして実現される。
【００５５】
上記所定のプログラムは、予め外部記憶装置５３に格納されていても良いし、上記電子計算機が利用可能な記憶媒体５９に格納されており、読み取り装置５４を介して、必要に応じて読み出され、あるいは、上記電子計算機が利用可能な通信媒体であるネットワークまたはネットワーク上を伝搬する搬送波を利用する通信装置５６と接続された他の装置から、必要に応じてダウンロードされて、外部記憶装置５３に導入されるものであっても良い。
【００５６】
次に図８を用いて、設定情報保持部４８に記憶されている、検証者が受け入れる暗号方式を設定したテーブルと、例外的に検証者が受け入れる暗号方式を無効にする認証局と暗号方式の関係を設定したテーブルについて説明する。なお、本実施形態において、暗号方式は、電子署名に利用する暗号アルゴリズム、公開鍵の鍵長、及び公開鍵のパラメータを表す。
【００５７】
テーブルの行の順にフィルタ番号７１の列にフィルタ番号を記載し、フィルタ番号７２の列に「署名アルゴリズム」あるいは「公開鍵アルゴリズム」のどちらかを記載する。また、検証者が受け入れる暗号アルゴリズムの名称を暗号アルゴリズム７３の列に記載し、さらに、その暗号アルゴリズムのＯＩＤ（Ｏｂｊｅｃｔ ＩＤｅｎｔｉｆｉｅｒ）を暗号アルゴリズムＯＩＤ７４の列に記載する。フィルタ種別７２が公開鍵アルゴリズムである場合、受け入れる公開鍵の鍵長を鍵長７５の列に記載する。該当する暗号アルゴリズムにおいて、全ての鍵長を受け入れる場合は、鍵長７５の列に何も記載しない。また、受け入れる公開鍵のパラメータをパラメータ７６の列に記載し、さらにそのパラメータのＯＩＤをパラメータＯＩＤ７７に記載する。該当する暗号アルゴリズムにおいて、全てのパラメータを受け入れる場合は、パラメータ７６とパラメータＯＩＤ７７の列に何も記載しない。フィルタ種別７２が署名アルゴリズムである場合、鍵長７５の列、パラメータ７６の列、パラメータＯＩＤ７７の列には何も記載しない。
【００５８】
例外的に特定の暗号アルゴリズムを特定の認証局から発行された証明書に対してのみ無効とする場合は、認証局の名称を認証局名７８の列に記載する。また、暗号アルゴリズムを指定するために、フィルタ番号７１に記されるフィルタ番号を例外的に無効とするフィルタ番号７９に記載する。例外的に検証者が受け入れる暗号方式を無効としない場合は、認証局７８の列と例外的に無効とするフィルタ番号７９の列に何も記載しない。
【００５９】
次に図９を用いて、設定情報保持部４８に記憶されている、検証者が受け入れない証明書ポリシに関する情報を設定したテーブルを説明する。
【００６０】
検証者が受け入れない証明書ポリシの名称を証明書ポリシ８１の列に記載し、さらに、その証明書ポリシのＯＩＤをＯＩＤ８２に記載する。また、ＣＡが公開しているＣＰＳからＣＡが証明書の電子署名に利用する暗号アルゴリズムを抜粋し、暗号アルゴリズム８３に記載する。
【００６１】
次に図１０を用いて、証明書検証部４４における証明書の有効性確認処理を説明する。
【００６２】
証明書検証部４４は、任意の端末装置１１からの証明書の有効性確認依頼を、通信部４０ｃを介して受信する（ステップＳ１００１）と、有効性確認依頼に含まれているＥＥ（Ｅｎｄ Ｅｎｔｉｔｙ）証明書、トラストアンカ証明書や中間証明書の証明書の暗号方式チェックを行う（ステップＳ１００２）。なお、本実施形態では、ＥＥ証明書は、公開鍵の利用者に発行する証明書であり、署名者が署名に利用する証明書を表している。また、トラストアンカ証明書は、検証者が信頼するルートＣＡの証明書を表している。また、中間証明書は、ＥＥ証明書を発行し、かつ、ＥＥの信頼するルートＣＡの下位に位置するＣＡの証明書を表している。ＥＥ証明書、トラストアンカ証明書や中間証明書の証明書の暗号方式チェックに失敗した場合、認証パス構築（ステップＳ１００５）並びに認証パス検証（ステップＳ１００７）を実施する前に、証明書検証応答作成（ステップＳ１００４）ができるため、ステップＳ１００２により、証明書検証応答を迅速に端末装置１１に送信することが可能である。図１１において、有効性確認依頼の暗号方式チェック処理の詳細について述べる。有効性確認依頼の暗号方式チェックに失敗した場合（ステップＳ１００３でＮｏ）、証明書検証部４４は、暗号方式チェックで判定したエラーコードを付与して、有効性確認結果を無効とする証明書検証応答を作成する（ステップＳ１００４）。
【００６３】
有効性確認依頼の暗号方式チェックに成功した場合（ステップＳ１００３でＹｅｓ）、証明書検証部４４は、トラストアンカからＥＥ証明書の発行者までの認証パスを構築する（ステップＳ１００５）。
【００６４】
認証パス構築に失敗した場合（ステップＳ１００６でＮｏ）、証明書検証部４４は、認証パス構築時に判定したエラーコードを付与して、ステップＳ１００４へ進む。
【００６５】
認証パス構築に成功した場合（ステップＳ１００６でＹｅｓ）、ステップＳ１００５で構築した認証パスの検証を行う（ステップＳ１００７）。ステップＳ１００７においても、暗号方式のチェックを実施することにより、認証パス中の全ての証明書の暗号方式のチェックを実施することが可能である。なお、図１２において、認証パス検証処理の詳細について述べる。
【００６６】
認証パス検証に失敗した場合（ステップＳ１００８でＮｏ）、証明書検証部４４は、認証パス検証で作成したエラー通知から、ＥＥ証明書の失効や、ＥＥ証明書の署名不正などのＥＥ証明書のエラーを原因とする認証パス検証失敗であるかどうか判断する（ステップＳ１００９）。ＥＥ証明書のエラーが原因ではない場合（ステップＳ１００９でＮｏ）、同一のトラストアンカからＥＥ証明書の発行者について、新たな認証パス構築を行うためにステップＳ１００５に戻る。ＥＥ証明書のエラーが原因の場合（ステップＳ１００９でＹｅｓ）、ステップＳ１００４へ進む。
【００６７】
認証パス検証に成功した場合（ステップＳ１００８でＹｅｓ）、証明書検証部４４は、有効性確認結果を有効とする証明書検証応答を作成する（ステップＳ１０１０）。
【００６８】
次に図１１を用いて、証明書検証部４４における、有効性確認依頼に含まれる証明書のの暗号方式のチェックの処理（図１０、ステップＳ１００２）の詳細について述べる。
【００６９】
証明書検証部４４は、ステップＳ１００１で受信したＥＥ証明書を読み込み（ステップＳ２００１）、ＥＥ証明書の電子署名に利用されている暗号方式のチェックを行う（ステップＳ２００２）。ＥＥ証明書の暗号方式が有効ではないと判定した場合（ステップＳ２００３でＮｏ）、証明書検証部４４は、有効性確認処理のエラーの原因を無効な暗号方式を含むとするエラー通知を作成する（ステップＳ２００４）。
【００７０】
ＥＥ証明書の暗号方式が有効であると判定した場合（ステップＳ２００３でＹｅｓ）、証明書検証部４４は、ステップＳ１００１で受信したトラストアンカ証明書を読み込む（ステップＳ２００５）。次に、証明書検証部４４は、トラストアンカ証明書の電子署名に利用されている暗号方式のチェックを行う（ステップＳ２００６）。トラストアンカ証明書の暗号方式が有効ではないと判定した場合（ステップＳ２００７でＮｏ）、証明書検証部４４は、Ｓ２００４へ進む。
【００７１】
トラストアンカ証明書の暗号方式が有効である場合（ステップＳ２００７でＹｅｓ）、証明書検証部４４は、有効性確認依頼に中間証明書が含まれているかどうか判定する（ステップＳ２００８）。中間証明書が含まれていない場合（ステップＳ２００８でＮｏ）、証明書検証部４４は、有効性確認依頼の暗号方式チェックの処理を成功として終了し、図１０のステップＳ１００５へ進む。
【００７２】
中間証明書が含まれている場合（ステップＳ２００８でＹｅｓ）、証明書検証部４４は、ステップＳ１００１で受信した中間証明書を読み込む（ステップＳ２００９）。次に、証明書検証部４４は、中間証明書の電子署名に利用されている暗号方式のチェックを行う（ステップＳ２０１０）。中間証明書の暗号方式が有効ではないと判定した場合（ステップＳ２０１１でＮｏ）、証明書検証部４４は、ステップＳ２００４へ進む。
【００７３】
中間証明書の暗号方式が有効であると判定した場合（ステップＳ２０１１でＹｅｓ）、証明書検証部４４は、有効性確認依頼の暗号方式チェックの処理を成功として終了し、図１０のステップＳ１００３へ進む。
【００７４】
なお、図１４において、ステップＳ２００２、ステップＳ２００６、ステップＳ２０１０の暗号方式チェックの処理の詳細について述べる。
【００７５】
次に図１２を用いて、証明書検証部４４における、図１０の認証パス検証処理（ステップＳ１００７）の詳細について述べる。
【００７６】
図１０のステップＳ１００５で構築した認証パスの全ての証明書（トラストアンカが発行した証明書からＥＥ証明書の順番）の中から次の証明書を選択する（ステップＳ３００１）。ただし、1回目は最初の証明書を選択する。
【００７７】
証明書検証部４４は、ステップＳ３００１で選択した証明書、の電子署名に利用されている暗号方式のチェックを行う（ステップＳ３００２）。選択した証明書の暗号方式が有効ではないと判定した場合（ステップＳ３００３でＮｏ）、証明書検証部４４は、有効性確認処理のエラーの原因を無効な暗号方式を含むとするエラー通知を作成する（ステップＳ３００４）。
【００７８】
なお、図１４において、ステップＳ３００２の暗号方式チェックの処理の詳細について述べる。
【００７９】
選択した証明書の暗号方式が有効であると判定した場合（ステップＳ３００３でＹｅｓ）、証明書検証部４４は、選択した証明書を認証パス中の一つ前の証明書で署名検証を行う（ステップＳ３００５）。ただし、1回目は、ステップＳ１００１（図１０）で取得したトラストアンカの証明書で署名検証を行う。
【００８０】
署名検証に失敗した場合（ステップＳ３００６でＮｏ）、証明書検証部４４は、エラーとなった証明書の種類と有効性確認処理のエラーの原因を署名不正とするエラー通知を作成する（ステップＳ３００７）。署名検証に成功した場合（ステップＳ３００６でＹｅｓ）、証明書検証部４４は、ステップＳ３００８へ進む。
【００８１】
ステップＳ３００１で選択した証明書、の証明書失効情報（ＣＲＬ、あるいは、ＯＣＳＰレスポンス）が、証明書失効情報保持部４６にあるか確認し、証明書失効情報保持部４６にある場合、証明書検証部４４は、対応する証明書失効情報を取得する。また、証明書失効情報保持部４６にない場合、証明書検証部４４は、証明書失効情報を提供するＣＡにアクセスし、最新の証明書失効情報を取得する（ステップＳ３００８）。
【００８２】
次に、証明書検証部４４は、ステップＳ３００８で取得した証明書失効情報の電子署名を、すでに認証パスの検証で有効と判定された証明書を利用して検証する（ステップＳ３００９）。証明書失効情報が有効ではないと判定した場合（ステップＳ３０１０でＮｏ）、証明書検証部４４は、エラーとなった証明書の種類と有効性確認処理のエラーの原因を失効した証明書を含むとするエラー通知を作成する（ステップＳ３０１１）。
【００８３】
証明書失効情報の検証処理に成功した場合（ステップＳ３０１０でＹｅｓ）、証明書検証部４４は、証明書失効情報に記載されている内容を確認し、ステップＳ３００１で選択した証明書が有効であるかどうか判定する（ステップＳ３０１２）。選択した証明書が有効ではないと判定した場合（ステップＳ３０１２でＮｏ）、証明書検証部４４は、ステップＳ３０１１へ進み、また選択した証明書が有効であると判定した場合（ステップＳ３０１２でＹｅｓ）、ステップＳ３０１３へ進む。
【００８４】
証明書検証部４４は、相互認証しているＣＡ間で有効と定義された証明書ポリシを認証パス中の証明書から、順次、解析することで、認証パス中で有効な証明書ポリシを導出し、かつ、検証者が有効性確認依頼に指定した証明書ポリシと一致しているか確認する、といったポリシ制御を行う。ステップＳ３００１で選択した証明書に有効な証明書ポリシが存在してない場合（ステップＳ３０１３でＮｏ）、証明書検証部４４は、有効性確認処理のエラーの原因を無効な証明書ポリシ含むとするエラー通知を作成する（ステップＳ３０１４）。
【００８５】
ポリシ制御を行い、ステップＳ３００１で選択した証明書、に有効な証明書ポリシが存在している場合（ステップＳ３０１３でＹｅｓ）、証明書検証部４４は、選択した証明書ポリシが、設定情報保持部４８の、検証者が受け入れない（無効とする）証明書ポリシを設定したテーブル（図９）に含まれているか判定する（ステップＳ３０１５）。
【００８６】
検証者が無効とする証明書ポリシが含まれる場合（ステップＳ３０１５でＹｅｓ）、証明書検証部４４は、ステップＳ３０１４へ進む。検証者が無効とする証明書ポリシが含まれない場合（ステップＳ３０１５でＮｏ）、証明書検証部４４は、ステップＳ３０１６へ進む。
【００８７】
選択した証明書がＥＥ証明書でない場合（ステップＳ３０１６でＮｏ）、証明書検証部４４は、ステップＳ３００１へ戻る。選択した証明書がＥＥ証明書である場合（ステップＳ３０１６でＹｅｓ）、証明書検証部４４は、有効性確認処理結果を有効とする正常終了通知を作成する（ステップＳ３０１７）。
【００８８】
次に図１４を用いて、証明書証部４４における、図１１の暗号方式チェックの処理（ステップＳ２００２、ステップＳ２００６、ステップＳ２０１０）と、図１２の暗号方式チェックの処理（ステップＳ３００２）の詳細について述べる。図１４では、図８の検証者が受け入れる暗号方式を設定したテーブルを利用する。
【００８９】
証明書検証部４４は、ステップＳ２００１、ステップＳ２００５あるいはステップＳ２００９で読み込んだ証明書に記載の署名アルゴリズム（ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ）の項目から署名アルゴリズムのＯＩＤを、また、所有者公開鍵情報（ｓｕｂｊｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏ）から公開鍵のアルゴリズムのＯＩＤ、鍵長、パラメータのＯＩＤを取得する（ステップＳ５００１）。
【００９０】
ステップＳ５００１で取得した暗号方式が、図８の検証者が受け入れる暗号方式を設定したテーブルに含まれていない場合（ステップＳ５００２でＮｏ）、証明書検証部４４は、暗号方式が無効と通知して（ステップＳ５００３）処理を終了する。
【００９１】
ステップＳ５００１で取得した暗号方式が、図８の検証者が受け入れる暗号方式を設定したテーブルに含まれる場合（ステップＳ５００２でＹｅｓ）、証明書検証部４４は、ステップＳ５００１で取得した暗号方式に該当するフィルタ番号を図８のフィルタ番号８１から取得する（ステップＳ５００４）。次に、証明書検証部４４は、ステップＳ２００１、ステップＳ２００５あるいはステップＳ２００９で読み込んだ証明書の発行者名（ｉｓｓｕｅｒ）の項目からＣＡ装置の情報（例えば、認証局名）を取得する（ステップＳ５００５）。
【００９２】
ステップ５００４で取得したフィルタ番号とステップＳ５００５で取得した認証局名の組み合わせが、図８の認証局名７７と例外的に無効とするフィルタ番号７８に存在する場合（ステップＳ５００６でＹｅｓ）、証明書検証部４４は、ステップＳ５００３へ進む。
【００９３】
ステップ５００４で取得したフィルタ番号とステップＳ５００５で取得した認証局名の組み合わせが、図８の認証局名７７と例外的に無効とするフィルタ番号７８に存在しない場合（ステップＳ５００６でＮｏ）、証明書検証部４４は、暗号方式が有効と通知して（ステップＳ５００７）処理を終了する。
【００９４】
(他の実施形態)
上記実施形態では、図８に示す、検証者が受け入れる暗号方式とこの暗号方式を例外的に無効とする認証局の情報を利用して、図１４に示す暗号方式のチェック処理を行う場合を例にとり説明したが、図７に示す、検証者が受け入れる暗号方式とこの暗号方式を例外的に有効とする認証局の情報を利用して、図３に示す暗号方式のチェック処理を行うようにしても良い。
【００９５】
図７を用いて、設定情報保持部４８に記憶されている、検証者が受け入れない暗号方式を設定したテーブルと、例外的に検証者が受け入れない暗号方式を有効にする認証局と暗号方式の関係を設定したテーブルについて説明する。
【００９６】
テーブルの行の順にフィルタ番号６１の列にフィルタ番号を記載し、フィルタ番号６２の列に「署名アルゴリズム」あるいは「公開鍵アルゴリズム」のどちらかを記載する。また、検証者が受け入れない暗号アルゴリズムの名称を暗号アルゴリズム６３の列に記載し、さらに、その暗号アルゴリズムのＯＩＤ（Ｏｂｊｅｃｔ ＩＤｅｎｔｉｆｉｅｒ）を暗号アルゴリズムＯＩＤ６４の列に記載する。フィルタ種別６２が公開鍵アルゴリズムである場合、受け入れない公開鍵の鍵長を鍵長６５の列に記載する。該当する暗号アルゴリズムにおいて、全ての鍵長を受け入れない場合は、鍵長６５の列に何も記載しない。また、受け入れない公開鍵のパラメータをパラメータ６６の列に記載し、さらにそのパラメータのＯＩＤをパラメータＯＩＤ６７に記載する。該当する暗号アルゴリズムにおいて、全てのパラメータを受け入れない場合は、パラメータ６６とパラメータＯＩＤ６７の列に何も記載しない。フィルタ種別６２が署名アルゴリズムである場合、鍵長６５の列、パラメータ６６の列、パラメータＯＩＤ６７の列には何も記載しない。
【００９７】
例外的に特定の暗号アルゴリズムを特定の認証局から発行された証明書に対してのみ有効とする場合は、認証局の名称を認証局名６８の列に記載する。また、暗号アルゴリズムを指定するために、フィルタ番号６１に記されるフィルタ番号を例外的に有効とするフィルタ番号６９に記載する。例外的に検証者が受け入れない暗号方式を有効としない場合は、認証局６８の列と例外的に有効とするフィルタ番号６９の列に何も記載しない。
【００９８】
次に図１３を用いて、証明書検証部４４における、図１１の暗号方式チェックの処理（ステップＳ２００２、ステップＳ２００６、ステップＳ２０１０）と、図１２の暗号方式チェックの処理（ステップＳ３００２）の詳細について述べる。図１３では、図７の検証者が受け入れない暗号方式を設定したテーブルを利用する。
【００９９】
証明書検証部４４は、ステップＳ２００１、ステップＳ２００５あるいはステップＳ２００９で読み込んだ証明書の署名アルゴリズム（ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ）の項目から署名アルゴリズムのＯＩＤを、また、所有者公開鍵情報（ｓｕｂｊｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏ）から公開鍵のアルゴリズムのＯＩＤ、鍵長、パラメータのＯＩＤを取得する（ステップＳ４００１）。
【０１００】
ステップＳ４００１で取得した暗号方式が、図７の検証者が受け入れない暗号方式を設定したテーブルに含まれない場合（ステップＳ４００２でＮｏ）、証明書検証部４４は、暗号方式が有効と通知して（ステップＳ４００３）、処理を終了する。
【０１０１】
ステップＳ４００１で取得した暗号方式が、図７の検証者が受け入れない暗号方式を設定したテーブルに含まれる場合（ステップＳ４００２でＹｅｓ）、証明書検証部４４は、ステップＳ４００１で取得した暗号方式に該当するフィルタ番号を図７のフィルタ番号６１から取得する（ステップＳ４００４）。次に、証明書検証部４４は、ステップＳ２００１、ステップＳ２００５あるいはステップＳ２００９で読み込んだ証明書の発行者名（ｉｓｓｕｅｒ）の項目から認証局名を取得する（ステップＳ４００５）。
【０１０２】
ステップ４００４で取得したフィルタ番号６１とステップＳ４００５で取得した認証局名の組み合わせが、図７の認証局名６７と例外的に有効とするフィルタ番号６８に存在する場合（ステップＳ４００６でＹｅｓ）、ステップＳ４００３へ進む。
【０１０３】
ステップ４００３で取得したフィルタ番号とステップＳ４００４で取得した認証局名の組み合わせが、図７の認証局名６７と例外的に有効とするフィルタ番号６８に存在しない場合（ステップＳ４００６でＮｏ）、証明書検証部４４は、暗号方式が無効と通知して（ステップＳ４００７）、処理を終了する。
【０１０４】
また、上記実施形態では、認証パス検証前の証明書の有効性確認依頼を受信した時と認証パス検証時に、証明書の電子署名に利用されている暗号方式をチェックする処理を例にとり説明したが、何れか一方を実施する形態であっても良い。
【０１０５】
また、上記実施形態では、暗号方式を、電子署名に利用する暗号アルゴリズム、公開鍵の鍵長、及び公開鍵のパラメータとして定義して、証明書の有効性確認処理を説明したが、暗号方式は何れか一つかあるいは二つを実施する形態であっても良い。
【０１０６】
以上本発明の実施形態について詳述したが、上記実施形態によれば、証明書の有効性確認処理を安全にかつ迅速に行うことができる証明書の有効性確認方法、これを実施する検証サーバ、プログラム及び記憶媒体を提供することができる。また、証明書の有効性確認処理における、認証パスの構築や認証パスの検証を安全かつ迅速に行うことができる。
【０１０７】
また、本発明は上記実施形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【符号の説明】
【０１０８】
１１：端末装置、１２：ＣＡ装置、１３：検証サーバ、１４：ネットワーク、２０ａ、３０ａ、４０ａ：処理部、２０ｂ、３０ｂ、４０ｂ：記憶部、２０ｃ、３０ｃ、４０ｃ：通信部、２０ｄ、３０ｄ、４０ｄ：入出力部、２１：署名付き文書作成部、２２：署名・証明書検証部、２３、３３：制御部、２４：電子文書保持部、２５：鍵保持部、２６：検証対象保持部、３１：発行部、３２：管理部、３４：証明書ＤＢ、３５：発行先管理リスト保持部、３６：ＣＲＬ保持部、３７：証明書有効性確認部、４１：定期自動更新部、４２：証明書失効情報更新部、４３：証明書更新部、４４：証明書検証部、４５：認証パス保持部、４６：証明書失効保持部、４７：証明書保持部、４８：設定情報保持部、５０：内部通信線、５１：ＣＰＵ、５２：メモリ、５３：外部記憶装置、５４：読取装置、５５：通信装置、５６：入力装置、５７：出力装置、５９：可搬性を有する記憶媒体。
【特許請求の範囲】
【請求項１】
複数の端末装置及び複数の認証局とネットワークに接続された検証サーバにより、任意の端末装置からネットワークを介して証明書の有効性確認依頼を受信し、第一の認証局から第二の認証局までの認証パスを構築し、該認証パスの検証を行い、該検証結果を前記証明書の有効性確認依頼元の端末装置へ前記ネットワークを介して送信する、証明書の有効性確認方法において、
前記検証サーバは、前記証明書の電子署名に利用されている暗号方式に関する情報を記憶する記憶部を有し、
前記検証サーバにより、
前記有効性確認依頼に含まれる証明書から第一の暗号方式に関する情報を取得し、
前記第一の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されていない場合に、前記第一の暗号方式に関する情報を無効と判断する、
ことを特徴とする証明書の有効性確認方法。
【請求項２】
複数の端末装置及び複数の認証局とネットワークに接続された検証サーバにより、任意の端末装置からネットワークを介して証明書の有効性確認依頼を受信し、第一の認証局から第二の認証局までの認証パスを構築し、該認証パスの検証を行い、該検証結果を前記証明書の有効性確認依頼元の端末装置へ前記ネットワークを介して送信する、証明書の有効性確認方法において、
前記検証サーバは、前記証明書の電子署名に利用されている暗号方式に関する情報を有効な情報として記憶する記憶部を有し、
前記検証サーバにより、
前記認証パスの検証時に、前記認証パス中の前記証明書に記載の暗号方式に関する情報が前記記憶部に記憶されていない場合に、前記暗号方式に関する情報を無効と判断する、
ことを特徴とする証明書の有効性確認方法。
【請求項３】
前記検証サーバにより、
前記第一の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されており、かつ、前記認証パスの検証時に、前記認証パス中の前記証明書に記載の第二の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されていない場合に、前記第二の暗号方式に関する情報を無効と判断する、
ことを特徴とする請求項１に記載の証明書の有効性確認方法。
【請求項４】
前記検証サーバにより、
前記第一、第二の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されており、かつ、前記証明書が、前記第一、第二の暗号方式を有効とする認証局から発行されていない場合に、前記第一、第二の暗号方式を無効と判断する、
ことを特徴とする請求項３に記載の証明書の有効性確認方法。
【請求項５】
前記検証サーバにより、
前記第一、第二の暗号方式に関する情報が、無効な情報として、前記記憶部に記憶されており、かつ、前記証明書が、前記第一、第二の暗号方式を有効とする認証局から発行されていない場合に、前記第一、第二の暗号方式を無効と判断する、
ことを特徴とする請求項３に記載の証明書の有効性確認方法。
【請求項６】
前記記憶部には、前記証明書の証明書ポリシに関する情報が記憶されており、
前記検証サーバにより、
前記認証パスの検証時に、前記記憶部の前記証明書の証明書ポリシの情報に基づいて、前記認証パス中の前記証明書の証明書ポリシが有効か否かを判定する、
ことを特徴とする請求項１乃至５の何れか１項に記載の証明書の有効性確認方法。
【請求項７】
前記証明書は、ＥＥ（Ｅｎｄ Ｅｎｔｉｔｙ）証明書、トラストアンカ証明書及び中間証明書であり、
前記暗号方式に関する情報は、前記証明書の電子署名に利用される暗号アルゴリズム、パラメータ及び公開鍵の鍵長の何れかである、
ことを特徴とする請求項１乃至６の何れか1項に記載の証明書の有効性確認方法。
【請求項８】
複数の端末装置及び複数の認証局とネットワークに接続された検証サーバであって、任意の端末装置からネットワークを介して証明書の有効性確認依頼を受信し、第一の認証局から第二の認証局までの認証パスを構築し、該認証パスの検証を行い、該検証結果を前記証明書の有効性確認依頼元の端末装置へ前記ネットワークを介して送信する前記検証サーバにおいて、
前記証明書の電子署名に利用されている暗号方式に関する情報を記憶する記憶部と、
前記有効性確認依頼に含まれる証明書から第一の暗号方式に関する情報を取得し、前記第一の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されていない場合に、前記第一の暗号方式に関する情報を無効と判断する処理部と、を有する、
ことを特徴とする検証サーバ。
【請求項９】
複数の端末装置及び複数の認証局とネットワークに接続された検証サーバであって、任意の端末装置からネットワークを介して証明書の有効性確認依頼を受信し、第一の認証局から第二の認証局までの認証パスを構築し、該認証パスの検証を行い、該検証結果を前記証明書の有効性確認依頼元の端末装置へ前記ネットワークを介して送信する前記検証サーバにおいて、
前記証明書の電子署名に利用されている暗号方式に関する情報を記憶する記憶部と、
前記認証パスの検証時に、前記認証パス中の前記証明書に記載の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されていない場合に、前記暗号方式に関する情報を無効と判断する、
ことを特徴とする検証サーバ。
【請求項１０】
前記処理部は、
前記第一の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されており、かつ、前記認証パスの検証時に、前記認証パス中の前記証明書に記載の第二の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されていない場合に、前記第二の暗号方式に関する情報を無効と判断する、
ことを特徴とする請求項８に記載の検証サーバ。
【請求項１１】
前記処理部は、
前記第一、第二の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されており、かつ、前記証明書が、前記第一、第二の暗号方式を有効とする認証局から発行されていない場合に、前記第一、第二の暗号方式を無効と判断する、
ことを特徴とする請求項１０に記載の検証サーバ。
【請求項１２】
前記処理部は、
前記第一、第二の暗号方式に関する情報が、無効な情報として、前記記憶部に記憶されており、かつ、前記証明書が、前記第一、第二の暗号方式を有効とする認証局から発行されていない場合に、前記第一、第二の暗号方式を無効と判断する、
ことを特徴とする請求項１０に記載の検証サーバ。
【請求項１３】
前記記憶部には、前記証明書の証明書ポリシに関する情報が記憶されており、
前記処理部は、
前記認証パスの検証時に、前記記憶部の前記証明書の証明書ポリシの情報に基づいて、前記認証パス中の前記証明書の証明書ポリシが有効か否かを判定する、
ことを特徴とする請求項８乃至１２の何れか１項に記載の検証サーバ。
【請求項１４】
前記証明書は、ＥＥ（Ｅｎｄ Ｅｎｔｉｔｙ）証明書、トラストアンカ証明書および中間証明書であり、
前記暗号方式に関する情報は、前記証明書の電子署名に利用される暗号アルゴリズム、パラメータおよび公開鍵に鍵長の何れかである、
ことを特徴とする請求項８乃至１３の何れか1項に記載の検証サーバ。
【請求項１５】
コンピュータに、請求項１乃至７の何れか1項に記載の証明書の有効性確認方法を実行させるためのプログラム。
【請求項１６】
コンピュータにより読み出し可能なプログラムを格納した記憶媒体であって、請求項１５に記載のプログラムを格納した、
ことを特徴とする記憶媒体。
【請求項１】
複数の端末装置及び複数の認証局とネットワークに接続された検証サーバにより、任意の端末装置からネットワークを介して証明書の有効性確認依頼を受信し、第一の認証局から第二の認証局までの認証パスを構築し、該認証パスの検証を行い、該検証結果を前記証明書の有効性確認依頼元の端末装置へ前記ネットワークを介して送信する、証明書の有効性確認方法において、
前記検証サーバは、前記証明書の電子署名に利用されている暗号方式に関する情報を記憶する記憶部を有し、
前記検証サーバにより、
前記有効性確認依頼に含まれる証明書から第一の暗号方式に関する情報を取得し、
前記第一の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されていない場合に、前記第一の暗号方式に関する情報を無効と判断する、
ことを特徴とする証明書の有効性確認方法。
【請求項２】
複数の端末装置及び複数の認証局とネットワークに接続された検証サーバにより、任意の端末装置からネットワークを介して証明書の有効性確認依頼を受信し、第一の認証局から第二の認証局までの認証パスを構築し、該認証パスの検証を行い、該検証結果を前記証明書の有効性確認依頼元の端末装置へ前記ネットワークを介して送信する、証明書の有効性確認方法において、
前記検証サーバは、前記証明書の電子署名に利用されている暗号方式に関する情報を有効な情報として記憶する記憶部を有し、
前記検証サーバにより、
前記認証パスの検証時に、前記認証パス中の前記証明書に記載の暗号方式に関する情報が前記記憶部に記憶されていない場合に、前記暗号方式に関する情報を無効と判断する、
ことを特徴とする証明書の有効性確認方法。
【請求項３】
前記検証サーバにより、
前記第一の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されており、かつ、前記認証パスの検証時に、前記認証パス中の前記証明書に記載の第二の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されていない場合に、前記第二の暗号方式に関する情報を無効と判断する、
ことを特徴とする請求項１に記載の証明書の有効性確認方法。
【請求項４】
前記検証サーバにより、
前記第一、第二の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されており、かつ、前記証明書が、前記第一、第二の暗号方式を有効とする認証局から発行されていない場合に、前記第一、第二の暗号方式を無効と判断する、
ことを特徴とする請求項３に記載の証明書の有効性確認方法。
【請求項５】
前記検証サーバにより、
前記第一、第二の暗号方式に関する情報が、無効な情報として、前記記憶部に記憶されており、かつ、前記証明書が、前記第一、第二の暗号方式を有効とする認証局から発行されていない場合に、前記第一、第二の暗号方式を無効と判断する、
ことを特徴とする請求項３に記載の証明書の有効性確認方法。
【請求項６】
前記記憶部には、前記証明書の証明書ポリシに関する情報が記憶されており、
前記検証サーバにより、
前記認証パスの検証時に、前記記憶部の前記証明書の証明書ポリシの情報に基づいて、前記認証パス中の前記証明書の証明書ポリシが有効か否かを判定する、
ことを特徴とする請求項１乃至５の何れか１項に記載の証明書の有効性確認方法。
【請求項７】
前記証明書は、ＥＥ（Ｅｎｄ Ｅｎｔｉｔｙ）証明書、トラストアンカ証明書及び中間証明書であり、
前記暗号方式に関する情報は、前記証明書の電子署名に利用される暗号アルゴリズム、パラメータ及び公開鍵の鍵長の何れかである、
ことを特徴とする請求項１乃至６の何れか1項に記載の証明書の有効性確認方法。
【請求項８】
複数の端末装置及び複数の認証局とネットワークに接続された検証サーバであって、任意の端末装置からネットワークを介して証明書の有効性確認依頼を受信し、第一の認証局から第二の認証局までの認証パスを構築し、該認証パスの検証を行い、該検証結果を前記証明書の有効性確認依頼元の端末装置へ前記ネットワークを介して送信する前記検証サーバにおいて、
前記証明書の電子署名に利用されている暗号方式に関する情報を記憶する記憶部と、
前記有効性確認依頼に含まれる証明書から第一の暗号方式に関する情報を取得し、前記第一の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されていない場合に、前記第一の暗号方式に関する情報を無効と判断する処理部と、を有する、
ことを特徴とする検証サーバ。
【請求項９】
複数の端末装置及び複数の認証局とネットワークに接続された検証サーバであって、任意の端末装置からネットワークを介して証明書の有効性確認依頼を受信し、第一の認証局から第二の認証局までの認証パスを構築し、該認証パスの検証を行い、該検証結果を前記証明書の有効性確認依頼元の端末装置へ前記ネットワークを介して送信する前記検証サーバにおいて、
前記証明書の電子署名に利用されている暗号方式に関する情報を記憶する記憶部と、
前記認証パスの検証時に、前記認証パス中の前記証明書に記載の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されていない場合に、前記暗号方式に関する情報を無効と判断する、
ことを特徴とする検証サーバ。
【請求項１０】
前記処理部は、
前記第一の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されており、かつ、前記認証パスの検証時に、前記認証パス中の前記証明書に記載の第二の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されていない場合に、前記第二の暗号方式に関する情報を無効と判断する、
ことを特徴とする請求項８に記載の検証サーバ。
【請求項１１】
前記処理部は、
前記第一、第二の暗号方式に関する情報が、有効な情報として、前記記憶部に記憶されており、かつ、前記証明書が、前記第一、第二の暗号方式を有効とする認証局から発行されていない場合に、前記第一、第二の暗号方式を無効と判断する、
ことを特徴とする請求項１０に記載の検証サーバ。
【請求項１２】
前記処理部は、
前記第一、第二の暗号方式に関する情報が、無効な情報として、前記記憶部に記憶されており、かつ、前記証明書が、前記第一、第二の暗号方式を有効とする認証局から発行されていない場合に、前記第一、第二の暗号方式を無効と判断する、
ことを特徴とする請求項１０に記載の検証サーバ。
【請求項１３】
前記記憶部には、前記証明書の証明書ポリシに関する情報が記憶されており、
前記処理部は、
前記認証パスの検証時に、前記記憶部の前記証明書の証明書ポリシの情報に基づいて、前記認証パス中の前記証明書の証明書ポリシが有効か否かを判定する、
ことを特徴とする請求項８乃至１２の何れか１項に記載の検証サーバ。
【請求項１４】
前記証明書は、ＥＥ（Ｅｎｄ Ｅｎｔｉｔｙ）証明書、トラストアンカ証明書および中間証明書であり、
前記暗号方式に関する情報は、前記証明書の電子署名に利用される暗号アルゴリズム、パラメータおよび公開鍵に鍵長の何れかである、
ことを特徴とする請求項８乃至１３の何れか1項に記載の検証サーバ。
【請求項１５】
コンピュータに、請求項１乃至７の何れか1項に記載の証明書の有効性確認方法を実行させるためのプログラム。
【請求項１６】
コンピュータにより読み出し可能なプログラムを格納した記憶媒体であって、請求項１５に記載のプログラムを格納した、
ことを特徴とする記憶媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１１−１９３４１６（Ｐ２０１１−１９３４１６Ａ）
【公開日】平成２３年９月２９日（２０１１．９．２９）
【国際特許分類】
【出願番号】特願２０１０−６０１２４（Ｐ２０１０−６０１２４）
【出願日】平成２２年３月１７日（２０１０．３．１７）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２３年９月２９日（２０１１．９．２９）
【国際特許分類】
【出願日】平成２２年３月１７日（２０１０．３．１７）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]