(57)【特許請求の範囲】
【請求項１】
認証局が発行した公開鍵証明書の有効性を検証する検証サーバにおける、前記公開鍵証明書の検証結果に付与するレスポンス署名に用いる暗号アルゴリズムの決定方法であって、
前記検証サーバは、失効した前記公開鍵証明書を識別する情報と、前記公開鍵証明書を発行した認証局を識別する情報を含む失効情報を記憶する第１の記憶部と、
当該検証サーバが対応可能な前記暗号アルゴリズムの情報を記憶する第２の記憶部を具備し、
前記検証サーバにより、
端末装置からの、前記公開鍵証明書を識別する情報、前記認証局を識別する情報及び前記暗号アルゴリズムの情報を含む検証要求を受信し、
前記受信した公開鍵証明書の情報及び前記認証局の情報が前記第１の記憶部に無い場合に、前記検証要求に含まれる前記公開鍵証明書を識別する情報に対応する前記公開鍵証明書は有効であるとする検証結果を作成し、
前記検証要求に含まれる前記暗号アルゴリズムの情報、前記失効情報に付与されている前記認証局の署名に用いられた暗号アルゴリズムの情報を用いて、前記公開鍵証明書の前記作成した検証結果に付与する署名に使用可能な暗号アルゴリズムの選択リストを作成し、
前記第２の記憶部の情報と前記作成した選択リストに基づき、前記公開鍵証明書の前記検証結果に付与する署名に用いる暗号アルゴリズムを決定する、
ことを特徴とする暗号アルゴリズムの決定方法。
【請求項２】
前記検証サーバにより、
前記決定した暗号アルゴリズムおよび該暗号アルゴリズムで署名可能な秘密鍵を用いて前記検証結果に署名を付与し、前記端末装置へ送信する、
ことを特徴とする請求項１に記載の暗号アルゴリズムの決定方法。
【請求項３】
前記第２の記憶部には、当該検証サーバが対応可能な前記暗号アルゴリズムがその優先順位を示す情報と対応付けられて記憶されており、
前記選択リストには、前記公開鍵証明書の前記検証結果に付与するレスポンス署名に使用可能な暗号アルゴリズムがその優先順位を示す情報と対応付けられて記載されており、
前記検証サーバにより、
前記第２の記憶部の暗号アルゴリズムと前記選択リストの暗号アルゴリズムとを比較し、それぞれが一致し、かつ前記優先順位が高い暗号アルゴリズムを、前記公開鍵証明書の前記検証結果に付与するレスポンス署名に用いる暗号アルゴリズムとして決定する、
ことを特徴とする請求項２に記載の暗号アルゴリズムの決定方法。
【請求項４】
前記第２の記憶部には、当該検証サーバが対応可能な前記暗号アルゴリズムがその優先順位を示す情報と対応付けられて記憶されており、
前記検証サーバにより、
前記第２の記憶部の暗号アルゴリズムと前記選択リストの暗号アルゴリズムとを比較し、それぞれが一致し、かつ前記優先順位が高い暗号アルゴリズムを、前記公開鍵証明書の前記検証結果に付与するレスポンス署名に用いる暗号アルゴリズムとして決定する、
ことを特徴とする請求項２に記載の暗号アルゴリズムの決定方法。
【請求項５】
前記検証サーバは、ＯＣＳＰ（Ｏｎｌｉｎｅ  Ｃｅｒｔｉｆｉｃａｔｅ  Ｓｔａｔｕｓ  Ｐｒｏｔｏｃｏｌ）レスポンダである、
ことを特徴とする請求項１に記載の暗号アルゴリズムの決定方法。
【請求項６】
前記選択リストには、前記検証要求に含まれる前記暗号アルゴリズムの情報、前記失効情報に付与されている前記認証局の署名に用いられた暗号アルゴリズムの情報、ＲＦＣ２５６０で規定されるＯＣＳＰデフォルトの暗号アルゴリズムの情報を含む、
ことを特徴とする請求項５に記載の暗号アルゴリズムの決定方法。
【請求項７】
前記検証サーバにより、
前記ＯＣＳＰレスポンダの公開鍵証明書であるＯＣＳＰ証明書を前記認証局から取得し、
前記決定した暗号アルゴリズムおよび前記ＯＣＳＰ証明書の公開鍵に対応する秘密鍵を用いて検証結果に署名を付与し、これを前記端末装置へ送信する、
ことを特徴とする請求項６に記載の暗号アルゴリズムの決定方法。
【請求項８】
認証局が発行した公開鍵証明書の有効性を検証する検証サーバであって、
前記検証サーバは、失効した前記公開鍵証明書を識別する情報と、前記公開鍵証明書を発行した認証局を識別する情報を含む失効情報を記憶する第１の記憶部と、
当該検証サーバが対応可能な前記暗号アルゴリズムの情報を記憶する第２の記憶部と、
端末装置からの、前記公開鍵証明書を識別する情報、前記認証局を識別する情報及び前記暗号アルゴリズムの情報を含む検証要求を受信し、
前記受信した公開鍵証明書の情報及び前記認証局の情報が前記第１の記憶部に無い場合に、前記検証要求に含まれる前記公開鍵証明書を識別する情報に対応する前記公開鍵証明書は有効であるとする検証結果を作成し、
前記検証要求に含まれる前記暗号アルゴリズムの情報、前記失効情報に付与されている前記認証局の署名に用いられた暗号アルゴリズムの情報を用いて、前記公開鍵証明書の前記検証結果に付与するレスポンス署名に使用可能な暗号アルゴリズムの選択リストを作成し、
前記第２の記憶部の情報と前記作成した選択リストに基づき、前記公開鍵証明書の前記検証結果に付与する署名に用いる暗号アルゴリズムを決定する処理部と、を有する、
ことを特徴とする検証サーバ。
【請求項９】
前記処理部は、
前記決定した暗号アルゴリズムおよび該暗号アルゴリズムで署名可能な秘密鍵を用いて前記検証結果に署名を付与し、前記端末装置へ送信する、
ことを特徴とする請求項８に記載の検証サーバ。
【請求項１０】
前記第２の記憶部には、当該検証サーバが対応可能な前記暗号アルゴリズムがその優先順位を示す情報と対応付けられて記憶されており、
前記選択リストには、前記公開鍵証明書の前記検証結果に付与するレスポンス署名に使用可能な暗号アルゴリズムがその優先順位を示す情報と対応付けられて記載されており、
前記処理部は、
前記第２の記憶部の暗号アルゴリズムと前記選択リストの暗号アルゴリズムとを比較し、それぞれが一致し、かつ前記優先順位が高い暗号アルゴリズムを、前記公開鍵証明書の前記検証結果に付与するレスポンス署名に用いる暗号アルゴリズムとして決定する、
ことを特徴とする請求項９に記載の検証サーバ。
【請求項１１】
前記第２の記憶部には、当該検証サーバが対応可能な前記暗号アルゴリズムがその優先順位を示す情報と対応付けられて記憶されており、
前記処理部は、
前記第２の記憶部の暗号アルゴリズムと前記選択リストの暗号アルゴリズムとを比較し、それぞれが一致し、かつ前記優先順位が高い暗号アルゴリズムを、前記公開鍵証明書の前記検証結果に付与するレスポンス署名に用いる暗号アルゴリズムとして決定する、
ことを特徴とする請求項９に記載の検証サーバ。
【請求項１２】
前記検証サーバは、ＯＣＳＰ（Ｏｎｌｉｎｅ  Ｃｅｒｔｉｆｉｃａｔｅ  Ｓｔａｔｕｓ  Ｐｒｏｔｏｃｏｌ）レスポンダである、
ことを特徴とする請求項８に記載の検証サーバ。
【請求項１３】
前記選択リストには、前記検証要求に含まれる前記暗号アルゴリズムの情報、前記失効情報に付与されている前記認証局の署名に用いられた暗号アルゴリズムの情報、ＲＦＣ２５６０で規定されるＯＣＳＰデフォルトの暗号アルゴリズムの情報を含む、
ことを特徴とする請求項１２に記載の検証サーバ。
【請求項１４】
前記処理部は、
前記ＯＣＳＰレスポンダの公開鍵証明書であるＯＣＳＰ証明書を前記認証局から取得し、
前記決定した暗号アルゴリズムおよび前記ＯＣＳＰ証明書の公開鍵に対応する秘密鍵を用いて検証結果に署名を付与し、これを前記端末装置へ送信する、
ことを特徴とする請求項１３に記載の検証サーバ。
【請求項１５】
コンピュータに、請求項１に記載の暗号アルゴリズムの決定方法を実行させるプログラム。
【発明の詳細な説明】
【参照による取り込み】
【０００１】
本出願は、２０１１年７月１５日に出願された日本特許出願第２０１１−１５６２５７号の優先権を主張し、その内容を参照することにより本出願に取り込む。
【技術分野】
【０００２】
本発明は、公開鍵証明書の有効性を検証する検証サーバ、検証サーバにおける、署名に用いる暗号アルゴリズムの決定方法およびプログラムに関する。
【背景技術】
【０００３】
公開鍵基盤において、電子文書などの電子データを送付する際に、対象となる電子データに、送信者の電子署名と、認証局が発行する公開鍵証明書を添付する。受信者は、受信データに添付された電子署名（以下「署名」という）と公開鍵証明書の有効性を確認することにより、送付された電子データが改ざんされていないことと、確かに送信者本人から送られた電子データであることを確認する。公開鍵証明書の発行と有効性の確認は、公開鍵基盤において行われ、その標準仕様はＲＦＣ５２８０（Ｉｎｔｅｒｎｅｔ  Ｘ．５０９  Ｐｕｂｌｉｃ  Ｋｅｙ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  Ｃｅｒｔｉｆｉｃａｔｅ  ａｎｄ  ＣＲＬ  Ｐｒｏｆｉｌｅ）等にて規定されている。
公開鍵証明書は、その有効期間が終了する前に、その公開鍵証明書の記載内容に変更があった場合等には、その公開鍵証明書を発行した認証局（Ｃｅｒｔｉｆｉｃａｔｅ  Ａｕｔｈｏｒｉｔｙ）により失効され、無効となる。そこで、受信者は、受信した公開鍵証明書の有効性確認において、その公開鍵証明書が失効しているか否かを確認する必要がある。【０００４】
証明書が失効しているか否かの確認には、認証局が発行する公開鍵証明書失効リスト（Ｃｅｒｔｉｆｉｃａｔｅ  Ｒｅｖｏｃａｔｉｏｎ  Ｌｉｓｔ：以下「ＣＲＬ」という）を用いる。ＣＲＬには、認証局の名前（ｉｓｓｕｅｒＮａｍｅ）、認証局の鍵情報（ａｕｔｈｏｒｉｔｙＫｅｙＩｄｅｎｔｉｆｉｅｒ）、認証局が発行した有効期間内の公開鍵証明書のうち失効した公開鍵証明書のシリアルナンバー（ｓｅｒｉａｌＮｕｍｂｅｒ）、ＣＲＬの有効期間等が記載され、この認証局の署名が付与されており、認証局によって定期的に発行される。シリアルナンバーは、公開鍵証明書を発行する認証局が、自身が発行した公開鍵証明書を一意に識別できるよう設定した情報である。受信者は、認証局からＣＲＬを取得し、受信データに添付された公開鍵証明書のシリアルナンバーが、ＣＲＬに記載されているかどうかを確認する。シリアルナンバーがＣＲＬに記載されている場合は、この公開鍵証明書は失効しており無効であると判断し、記載されていない場合には、この公開鍵証明書は有効であると判断する。【０００５】
しかしながら、認証局が発行する公開鍵証明書の数が多数あり、かつ失効する公開鍵証明書が多い場合、ＣＲＬの容量が膨大になる。このため、受信データに添付された公開鍵証明書の有効性を確認したい受信者にとっては、ＣＲＬの取得に時間がかかり、公開鍵証明書の有効性確認処理に時間がかかるという課題がある。これに対応するために、オンラインで公開鍵証明書が失効しているかどうかの確認要求を受け付けて、これに応答するサービスである検証サーバがある。そして、検証サーバの一形態として、ＣＲＬを用いて公開鍵証明書の状態を確認するＯＣＳＰ（Ｏｎｌｉｎｅ  Ｃｅｒｔｉｆｉｃａｔｅ  Ｓｔａｔｕｓ  Ｐｒｏｔｏｃｏｌ）レスポンダがあり、その標準仕様は非特許文献１に規定されている。【０００６】
ＯＣＳＰレスポンダは、認証局が発行するＣＲＬを定期的に取り込んでおき、公開鍵証明書の失効確認をする受信者が利用する端末（以下「端末装置」という）からの公開鍵証明書の失効確認要求（以下、「検証要求」という）を受け付ける。検証要求には、検証対象証明書（検証対象の公開鍵証明書）を特定するための情報（以下、「ＣｅｒｔＩＤ」という）が記述される。ＣｅｒｔＩＤには、端末装置が使用するハッシュアルゴリズム（ｈａｓｈＡｌｇｏｒｉｔｈｍ）と、検証対象証明書を発行した認証局の名前情報（ｉｓｓｕｅｒＮａｍｅＨａｓｈ）と、認証局の鍵情報（ｉｓｓｕｅｒＫｅｙＨａｓｈ）と、検証対象証明書のシリアルナンバー（ｓｅｒｉａｌＮｕｍｂｅｒ）が含まれる。このうち認証局の名前情報と、認証局の鍵情報とは、認証局の名前データ（ｉｓｓｕｅｒＮａｍｅ）と、鍵データ（ａｕｔｈｏｒｉｔｙＫｅｙＩｄｅｎｔｉｆｉｅｒ）を端末装置が使用するハッシュアルゴリズム（ｈａｓｈＡｌｇｏｒｉｔｈｍ）でそれぞれハッシュ計算したものである。【０００７】
検証要求を受け付けたＯＣＳＰレスポンダは、検証対象証明書のシリアルナンバーが予め取り込んだＣＲＬに記載されているかどうかを調べ、この検証対象証明書である公開鍵証明書が失効しているかどうかを端末装置に応答する。ＯＣＳＰレスポンダから端末装置へ送付される検証結果の応答電文（以下、「レスポンス」という）には、検証対象証明書の状態が有効（ｇｏｏｄ）、失効（ｒｅｖｏｋｅｄ）、不明（ｕｎｋｎｏｗｎ）のいずれかで記載される。さらに、レスポンスには検証したＯＣＳＰレスポンダの署名（以下、「レスポンス署名」という）及び証明書（以下、「ＯＣＳＰ証明書」という）が付与され、これにより端末装置の利用者は、このＯＣＳＰレスポンダによって確かに送付されたレスポンスであることを確認できる。【０００８】
なお、ＣＲＬには、認証局がＣＲＬを作成した時点で失効している公開鍵証明書のシリアルナンバーがすべて記載されている。【０００９】
また、認証局が秘密鍵の鍵更新を行うと、鍵更新後に発行される公開鍵証明書やＣＲＬは更新された新しい鍵で署名がなされる。鍵更新前に認証局から発行された公開鍵証明書は、有効期間内であっても有効性が確認できない場合が生じる。このような場合に、鍵更新の前後に係わらず認証局の発行した公開鍵証明書の有効性を検証し、受信者にレスポンスを応答するＯＣＳＰレスポンダについての技術が特許文献１に開示されている。【００１０】
近年、暗号解読技術の進歩や、電子計算機の能力向上により一部の暗号アルゴリズムの危殆化が指摘されている。２００５年、署名に用いられているハッシュ関数ＳＨＡ−１の危殆化がＮＩＳＴ（Ｎａｔｉｏｎａｌ  Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｓｔａｎｄａｒｄｓ  ａｎｄ  Ｔｅｃｈｎｏｌｏｇｙ：米国標準技術研究所）により発表され、現行のＳＨＡ−１からＳＨＡ−２へと暗号アルゴリズムの移行が強く推奨された。これを受け、各国の認証局は、現行の暗号アルゴリズムを利用している情報システムとの互換性を保ちつつ、利用者の公開鍵や公開鍵証明書の署名に利用する暗号アルゴリズムを安全性の高いものへと移行する方針としている。このような暗号アルゴリズムの危殆化は技術の進歩に伴いある一定の期間ごとに行われる事となる。【００１１】
暗号アルゴリズム危殆化に伴う暗号アルゴリズム移行を受け、検証対象証明書、ＯＣＳＰレスポンダに検証要求を送信する利用者（以下、「利用者」という）、認証局の発行するＣＲＬごとに、用いられる暗号アルゴリズムが異なるという状況が発生する。ＯＣＳＰレスポンダは、古い暗号アルゴリズムによる署名が用いられた公開鍵証明書や、古い暗号アルゴリズムにしか対応していない端末装置に対しても検証を行い、レスポンスを送信する必要があり、複数の暗号アルゴリズムへの対応が必要となる。【００１２】
これらの状況から、標準化策定組織であるＩＥＴＦ（Ｔｈｅ  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）にて、ＯＣＳＰレスポンダが検証結果に対して付与する、レスポンス署名の暗号アルゴリズムの選択方法についての検討がなされており、非特許文献２に開示されている。非特許文献２では、利用者は検証要求の要求拡張（ｒｅｑｕｅｓｔＥｘｔｅｎｓｉｏｎｓ）領域に、利用者が指定する署名の暗号アルゴリズムであるＰＳＡ（Ｐｒｅｆｅｒｒｅｄ  Ｓｉｇｎａｔｕｒｅ  Ａｌｇｏｒｉｔｈｍ）を設定し、ＯＣＳＰレスポンダの付与するレスポンス署名の暗号アルゴリズムを指定することもできる。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２０１０−１１８８５８号公報
【非特許文献】
【００１４】
【非特許文献１】“Ｘ．５０９  Ｉｎｔｅｒｎｅｔ  Ｐｕｂｌｉｃ  Ｋｅｙ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  Ｏｎｌｉｎｅ  Ｃｅｒｔｉｆｉｃａｔｅ  Ｓｔａｔｕｓ  Ｐｒｏｔｏｃｏｌ    ＯＣＳＰ（ＲＦＣ２５６０）”，ｐａｇｅ  ２“２．１  Ｒｅｑｕｅｓｔ”  “２．２  Ｒｅｓｐｏｎｓｅ”，［ｏｎｌｉｎｅ］，１９９９年６月、Ｔｈｅ  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ），［平成２３年５月１２日検索］インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２５６０．ｔｘｔ＞
【非特許文献２】“Ｏｎｌｉｎｅ  Ｃｅｒｔｉｆｉｃａｔｅ  Ｓｔａｔｕｓ  Ｐｒｏｔｏｃｏｌ  Ａｌｇｏｒｉｔｈｍ  Ａｇｉｌｉｔｙ（ＲＦＣ６２７７）”，［ｏｎｌｉｎｅ］，２０１１年６月、Ｔｈｅ  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ），［平成２３年６月１４日検索］インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ６２７７．ｔｘｔ＞
【発明の概要】
【発明が解決しようとする課題】
【００１５】
非特許文献１では、暗号アルゴリズム移行について考慮されていないため、関係する各装置・利用者間で利用される暗号アルゴリズムが異なるという状況に対して言及されていない。そのため、ＯＣＳＰレスポンダが利用者へレスポンスを応答する際に、利用する暗号アルゴリズムを選択して付与することができないという問題を見出していない。【００１６】
特許文献１では、レスポンス署名は、認証局の暗号アルゴリズムと同じものを用いて付与されることになっている。ＯＣＳＰレスポンダは、レスポンスに利用するＯＣＳＰ証明書を特定した後、認証局が付与したＯＣＳＰレスポンダの証明書の署名に用いられている暗号アルゴリズムを判断してレスポンス署名を行う。また、認証局の鍵更新により暗号アルゴリズムが変更された際の対応策として、ＯＣＳＰ証明書識別テーブルを持ち、認証局から取得するＣＲＬに付与されている暗号アルゴリズムの変化を管理している。以上の方法により、認証局が暗号アルゴリズム移行を行っていれば新暗号アルゴリズムでレスポンス署名を付与することになり、認証局が暗号アルゴリズム移行未対応であれば、古い暗号アルゴリズムでレスポンス署名を付与することとなる。そのため、利用者が新暗号アルゴリズムに未対応であった場合、利用者の対応できない暗号アルゴリズムを選択してレスポンス署名を付与してしまうという問題が発生する。【００１７】
非特許文献２では、ＯＣＳＰレスポンダのレスポンス署名の暗号アルゴリズムを選択するにあたって考慮すべきデータについて記載されているが、実際のＯＣＳＰレスポンダにおいて、そのデータをどのように参照し、レスポンス署名を選択するのかといった具体的な方法については言及されていない。【００１８】
本発明の目的は、証明書の署名に用いる暗号アルゴリズムの移行状況に係わらず、利用者に適した、検証対象証明書の検証結果に付与するレスポンス署名の暗号アルゴリズムを決定する技術を提供することにある。
【課題を解決するための手段】
【００１９】
上記課題を解決するための一手段を説明する。本発明は、証明書の検証を行う検証サーバにおける、前記証明書の検証結果に付与するレスポンス署名に用いる暗号アルゴリズムの決定方法である。検証サーバは、記憶部に記憶されている複数の証明書の失効情報と、端末装置からの、検証要求に含まれる認証局、該認証局が発行した証明書の情報および暗号アルゴリズムの情報に基づき、前記端末装置からの証明書の有効性を判断し、前記証明書が有効な場合に、前記端末装置からの証明書は有効であるとする検証結果を作成し、前記検証要求に含まれる暗号アルゴリズムの情報と、前記証明書の失効情報に付与されている当該証明書を発行した認証局の署名に用いられた暗号アルゴリズムの情報を用いて、前記証明書の検証結果に付与するレスポンス署名に使用可能な暗号アルゴリズムの選択リストを作成し、前記選択リストと当該検証サーバが対応可能な暗号アルゴリズムの情報に基づき、前記証明書の検証結果に付与するレスポンス署名に用いる暗号アルゴリズムを決定することを特徴とする。
【発明の効果】
【００２０】
本発明によれば、証明書の署名に用いる暗号アルゴリズムの移行状況に係わらず、利用者に適した、検証対象証明書の検証結果に付与するレスポンス署名の暗号アルゴリズムを決定できる。
本発明の他の目的、特徴及び利点は添付図面に関する以下の本発明の実施例の記載から明らかになるであろう。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施例に係わる検証システムの構成を示す図である。
【図２】端末装置の構成を示す図である。
【図３】認証局の構成を示す図である。
【図４】ＯＣＳＰレスポンダの構成を示す図である。
【図５】端末装置、認証局、ＯＣＳＰレスポンダの各々のハードウェア構成例を示す図である。
【図６】認証局識別テーブルの例を示す図である。
【図７】ＯＣＳＰレスポンダにおける、ＣＲＬの更新処理のフローチャートである。
【図８】失効情報テーブルの例を示す図である。
【図９】ＯＣＳＰ証明書識別テーブルの例を示す図である。
【図１０】リクエストテーブルの例を示す図である。
【図１１】署名ポリシーテーブルの例を示す図である。
【図１２】レスポンス署名アルゴリズム選択リストテーブルの例を示す図である。
【図１３】ＯＣＳＰレスポンダにおける、公開鍵証明書の検証処理のフローチャートである。
【図１４】ＯＣＳＰレスポンダにおける、レスポンス署名に用いる暗号アルゴリズムの決定処理のフローチャートである。
【図１５】ＯＣＳＰ証明書識別テーブルを拡張した場合のテーブル例を示す図である。
【図１６】第二の実施例において、ＯＣＳＰレスポンダにおける、レスポンス署名に用いる暗号アルゴリズムの決定処理のフローチャートである。
【図１７】第二の実施例において、レスポンス署名アルゴリズム選択リストテーブルの１項目に複数の暗号アルゴリズムが設定されていた場合に、ＯＣＳＰレスポンダにおける、レスポンス署名に用いる暗号アルゴリズムの決定処理のフローチャートである。
【発明を実施するための形態】
【００２２】
以下、本発明の実施例について、図面を参照して詳細に説明する。
【００２３】
最初に、本実施例の説明で用いる用語について解説する。ＰＫＩ技術において、電子データの送信者の電子署名には、送信者の秘密鍵が用いられる。その送信者の秘密鍵と対をなす公開鍵を認証局が証明し、署名した証明書が公開鍵証明書である。公開鍵証明書への認証局による署名には、認証局の秘密鍵が用いられ、その認証局の秘密鍵と対をなす公開鍵を他の認証局が証明した公開鍵証明書を、認証局証明書と呼ぶ。本実施例では、公開鍵証明書の失効情報を提供する検証サーバの一形態である、ＯＣＳＰレスポンダを例にとり説明する。失効情報は、検証結果に、ＯＣＳＰレスポンダの秘密鍵を用いて署名した検証応答として提供される。ＯＣＳＰレスポンダの秘密鍵と対をなす公開鍵を認証局が証明し、署名した証明書も公開鍵証明書である。このＯＣＳＰレスポンダの秘密鍵と対をなす公開鍵証明書をＯＣＳＰ証明書と呼ぶ。以上のように、公開鍵証明書、ＯＣＳＰ証明書は、公開鍵に係わる情報に署名が付されたものであるが、これらの証明書には、以下の説明から明らかになる認証局を特定する情報としての認証局名や、シリアルナンバーなどの公開鍵証明書を特定する情報や、各々が証明する端末装置、認証局、ＯＣＳＰレスポンダに関する情報も含まれる。また、以下の説明で、単に鍵の更新または秘密鍵の更新と記載する場合があるが、秘密鍵に対応する公開鍵も同時に更新するものであり、秘密鍵と公開鍵の対としての更新を表す。
【実施例１】
【００２４】
図１は、本発明の実施例に係わる検証システムの全体構成例を示す図である。検証システムは、電子的に手続き（電子データの送信など）を実行する複数の端末装置１１１〜１１Ｍと、公開鍵証明書を発行および失効させる認証局１２１〜１２Ｎと、認証局１２が発行した公開鍵証明書の失効情報（ＣＲＬ）に基づいて公開鍵証明書の有効性を検証するＯＣＳＰレスポンダ１３と、それぞれを接続するインターネット等のネットワーク１４を有する。【００２５】
図２は、端末装置１１の構成を示す。端末装置１１は、処理部２０ａと、記憶部２０ｂと、ネットワーク１４を介して他の装置と通信するための通信部２０ｃと、端末装置１１のユーザが作成した電子文書や他の端末装置１１から受け取った電子文書の入出力やユーザからの指示を受け付ける入出力部２０ｄとを有する。【００２６】
以下の端末装置１１の説明では、説明を分かり易くするために、端末装置１１のユーザが作成した電子文書を他の端末装置１１へ送信するときに添付する公開鍵証明書を自公開鍵証明書、他の端末装置１１から受信した電子文書に添付する公開鍵証明書を他公開鍵証明書と呼ぶ。【００２７】
処理部２０ａは、端末装置１１の秘密鍵を用いて電子文書に署名を付与した署名付き電子文書を作成する署名付き文書作成部２１と、他の端末装置１１からの署名付き電子文書の署名および他公開鍵証明書の検証を行う署名・証明書検証部２２と、端末装置１１の各部を制御する制御部２３を有する。【００２８】
記憶部２０ｂは、ユーザが作成した電子文書を保持する電子文書保持部２４と、署名を生成するための秘密鍵と、この秘密鍵と対をなす公開鍵の認証局１２から発行された自公開鍵証明書と、この端末装置１１が利用する認証局１２の認証局証明書とを保持する鍵保持部２５と、他の端末装置１１から受け取った署名付き電子文書と他公開鍵証明書を保持する検証対象保持部２６を有する。【００２９】
制御部２３は、入出力部２０ｄを介して端末装置１１を利用するユーザから、電子文書保持部２４に保持している電子文書の他ユーザへの送信の指示を受け付ける。送信の指示に対応して、制御部２３は、指定された電子文書を電子文書保持部２４から読み出し、これを署名付き文書作成部２１へ渡す。署名付き文書作成部２１は、鍵保持部２５に保持されている秘密鍵を用いて、渡された電子文書に対する署名を生成し、電子文書に生成した署名を付与した署名付き電子文書を作成する。制御部２３は、通信部２０ｃを介して、署名付き文書作成部２１で生成された署名付き電子文書と、鍵保持部２５に保持されている自公開鍵証明書とをユーザから指示された送信先の端末装置１１へ送信する。【００３０】
また、制御部２３は、通信部２０ｃを介して、他の端末装置１１から署名付き電子文書と他公開鍵証明書を受け取ると、これらを関連付けて検証対象保持部２６に保持させると共に、これらの検証を署名・証明書検証部２２に要求する。【００３１】
署名・証明書検証部２２は、署名付き電子文書と他公開鍵証明書の検証要求を受けて、検証対象保持部２６に保持されている署名付き電子文書の署名を、関連付けて保持されている他公開鍵証明書を用いて検証する。そして、署名・証明書検証部２２は、署名付き電子文書の署名の検証に使用した他公開鍵証明書を検証対象証明書として、鍵保持部２５に保持する認証局１２の認証局証明書を用いて検証する。署名・証明書検証部２２は、検証対象証明書の、署名の検証および、有効期間が切れていないことの確認、検証対象証明書が失効しているかどうかの確認などの検証処理を実行する。【００３２】
署名・証明書検証部２２は、検証対象証明書（検証対象の他公開鍵証明書）が失効しているかどうかを確認するために、ＯＣＳＰレスポンダ１３に検証要求を送信する。署名・証明書検証部２２は、ＯＣＳＰレスポンダ１３から検証対象証明書が失効していないとの検証結果の受信を含めて、検証処理に成功した場合に、この検証対象証明書は有効であり、この検証対象証明書が添付されていた署名付き電子文書が正当なものであるとして、必要に応じて入出力部２０ｄを介して署名付き電子文書の署名及び検証対象証明書の検証結果を出力する。【００３３】
図３は、認証局１２の構成を示す図である。認証局１２は、処理部３０ａと、記憶部３０ｂと、ネットワーク１４を介して他の装置と通信するための通信部３０ｃと、各種証明書等の入出力や、この認証局１２の操作者からの指示の受け付けや、処理結果の出力を行う入出力部３０ｄとを有する。【００３４】
処理部３０ａは、公開鍵証明書を発行する発行部３１と、発行部３１が発行した公開鍵証明書を管理する管理部３２と、認証局１２の各部を制御する制御部３３とを有する。【００３５】
記憶部３０ｂは、発行部３１が発行した公開鍵証明書を保持する証明書データベース（以下、「証明書ＤＢ」という）３４と、証明書ＤＢ３４に保持されている各公開鍵証明書の発行先が記述されている発行先管理リストを保持する発行先管理リスト保持部３５と、公開鍵証明書の失効情報が記述されているＣＲＬを保持するＣＲＬ保持部３６とを有する。【００３６】
認証局１２は、特許文献１の処理と同様に、公開鍵証明書の発行依頼を受け付け、発行依頼に対応する公開鍵証明書を作成し、認証局１２の秘密鍵を用いて作成した公開鍵証明書に署名をする。そして、作成した公開鍵証明書を入出力部３０ｄまたは通信部３０ｃを介して、郵送あるいは通信により発行依頼元へ渡す。【００３７】
また、認証局１２の管理部３２は、特許文献１の処理と同様に、公開鍵証明書の失効依頼を受け付けると、失効対象の公開鍵証明書を証明書ＤＢ３４から削除すると共に、この公開鍵証明書の発行先の情報を発行先管理リスト保持部３５に保持されている発行先管理リストから削除する。そして、管理部３２は、証明書ＤＢ３４から削除した公開鍵証明書のシリアルナンバーを記述したＣＲＬを定期的に作成し、認証局１２の秘密鍵を用いてＣＲＬに署名を付与する。制御部３３は、通信部３０ｃを介して、ＯＣＳＰレスポンダ１３等の他の装置よりＣＲＬ取得要求を受け付けると、ＣＲＬ保持部３６に保持されているＣＲＬを、通信部３０ｃを介して、ＣＲＬ取得要求を発行した他の装置に送信する。【００３８】
図４は、ＯＣＳＰレスポンダ１３の構成を示す図である。ＯＣＳＰレスポンダ１３は、処理部４０ａと、記憶部４０ｂと、ネットワーク１４を介して他の装置と通信するための通信部４０ｃと、各種証明書等の入出力や、ＯＣＳＰレスポンダ１３の操作員からの指示を受け付ける入出力部４０ｄとを有する。【００３９】
処理部４０ａは、管理部４１と、失効情報管理部４２と、検証処理部４３と、ＯＣＳＰレスポンダの各部を制御する制御部４４とを有する。【００４０】
記憶部４０ｂは、設定情報保持部４５と、失効情報保持部４６と、ＯＣＳＰ証明書保持部４７と、ＯＣＳＰレスポンダ１３の秘密鍵を保持する鍵保持部４８とを有する。【００４１】
管理部４１は、後述する署名ポリシーテーブル１１０や、ＣＲＬ更新タイミング等の各種設定情報を、設定情報保持部４５へ登録する。また、認証局証明書とＯＣＳＰ証明書から、後述するＯＣＳＰ証明書識別テーブル９０を作成してＯＣＳＰ証明書保持部４７へ登録する。【００４２】
失効情報管理部４２は、通信部４０ｃを介して認証局１２にアクセスしてＣＲＬを取得し、取得したＣＲＬから後述する失効情報テーブル８０を作成して、失効情報保持部４６へ登録する。そして、設定情報保持部４５に予め設定されたＣＲＬ更新タイミングに従ってＣＲＬを取得して、失効情報保持部４６の失効情報テーブル８０を更新する。【００４３】
検証処理部４３は、端末装置１１から通信部４０ｃを介して検証要求を受け付けると、失効情報保持部４６に保持される認証局識別テーブル６０と、失効情報テーブル８０とを参照し、検証要求された検証対象証明書が失効しているか否かを確認する。そして、検証処理部４３は、ＯＣＳＰ証明書識別テーブル９０を参照して、検証要求に対応するＯＣＳＰ証明書を取得し、検証結果データを作成する。そして、検証処理部４３は、署名ポリシーテーブル１１０や、後述するレスポンス署名アルゴリズム選択リストテーブル１２０から、検証結果データに署名する際のレスポンス署名アルゴリズムを決定する。検証結果データに、決定したレスポンス署名アルゴリズムにより、鍵保持部４８に保持されるＯＣＳＰレスポンダ１３の秘密鍵を用いて署名が付与され、ＯＣＳＰ証明書と共に通信部４０ｃを介して端末装置１１へ送信される。
設定情報保持部４５は、ＯＣＳＰレスポンダのデフォルトの暗号アルゴリズムや、ＯＣＳＰプロトコルのｖｅｒｓｉｏｎそれぞれに対して、各ｖｅｒｓｉｏｎで利用必須とする暗号アルゴリズムが予め登録される。【００４４】
また、本実施例で示すＯＣＳＰレスポンダ１３は、特許文献１と同様の認証局証明書の設定動作を行い、認証局証明書と、受け付け可能なハッシュアルゴリズムのオブジェクト識別子（ＯＩＤ）を設定情報保持部４５へ保持する。ＯＣＳＰレスポンダ１３が複数のハッシュアルゴリズムを受け付ける場合には、それら複数のハッシュアルゴリズムのＯＩＤを同様に設定し、そのうちの一つを、基準ハッシュアルゴリズムとして登録する。ＯＣＳＰレスポンダ１３は、登録された認証局証明書と基準ハッシュアルゴリズムに基づいて、認証局識別テーブル６０を作成し、失効情報保持部４６へ保持する。ＯＣＳＰレスポンダ１３が複数の認証局１２に対応する（複数の認証局１２が発行するＣＲＬを取り込む）場合には、ＯＣＳＰレスポンダ１３は、各認証局１２の認証局証明書を同様に登録する。また、認証局１２が秘密鍵を更新した場合は、有効期間を経過していない各世代の秘密鍵に対応する公開鍵情報を含む認証局証明書が保持される。なお、認証局の鍵情報の更新に伴い、ＯＣＳＰレスポンダ１３は認証局証明書を認証局１２からネットワーク１４を介して受信し、登録しても良い。【００４５】
図５は、図２〜４に示す端末装置１１、認証局１２、ＯＣＳＰレスポンダ１３の各々のハードウェア構成例を示す図である。端末装置１１、認証局１２、およびＯＣＳＰレスポンダ１３は、各種処理や演算、装置全体の制御等を行うＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）５１と、メモリ５２と、各種プログラム及びデータを記憶するハードディスク等の外部記憶装置５３と、通信ネットワーク１４を介して他装置と通信を行うための通信装置５４と、キーボードやボタン等の入力装置５５と、モニタやプリンタ等の出力装置５６と、ＣＤ−ＲＯＭやＵＳＢ等の可搬性を有する記憶媒体５８から情報を読み取る読取装置５７と、これらの各装置間のデータ送受を行う内部通信線（例えば、ＢＵＳ）５０とを備えた、一般的なコンピュータ（電子計算機）である。ＣＰＵ５１は、外部記憶装置５３から各種プログラムをメモリ５２にロードし、所定のプログラムを実行することにより上術の各処理部を実現する。すなはち、処理部２０ａ、３０ａ、４０ａは、ＣＰＵ５１の処理プロセスとして実現され、記憶部２０ｂ、３０ｂ、４０ｂは、ＣＰＵ５１がメモリ５２や外部記憶装置５３を利用することにより実現される。また、通信部２０ｃ、３０ｃ、４０ｃは、ＣＰＵ５１が通信装置５４を利用することにより実現され、入出力部２０ｄ、３０ｄ、４０ｄは、ＣＰＵ５１が入力装置５５や出力装置５６や読取装置５７を利用することにより実現される。各処理部を実現する所定のプログラムは、予め外部記憶装置５３に格納されていても良いし、電子計算機が利用可能な可搬性を有する記憶媒体５８に格納されており読取装置５７を介して必要に応じて読み出されても良いし、あるいは、電子計算機が利用可能な通信媒体であるネットワークまたはネットワーク上を伝搬する搬送波を利用する通信装置５４と接続された他の装置から必要に応じてダウンロードされて外部記憶装置５３に格納されるものであっても良い。【００４６】
図６は、ＯＣＳＰレスポンダ１３の失効情報保持部４６に設ける認証局識別テーブル６０の例を示す図である。認証局識別テーブル６０には、認証局証明書６１の名前に対応して、ＯＣＳＰレスポンダ１３が受け付け可能なハッシュアルゴリズムを用いて求めた、認証局証明書に記述される主体者名（ｓｕｂｊｅｃｔ）のハッシュ値と公開鍵（ｓｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏ）のハッシュ値とのペア６２〜６５、認証局証明書を発行した認証局の識別子６６を有する。認証局識別テーブル６０は、管理部４１によって次のように作成される。管理部４１は、設定情報保持部４５に保持されている認証局証明書を取得し、取得した認証局証明書の名前を認証局識別テーブル６０の認証局証明書６１の行に記述する。管理部４１は、設定情報保持部４５に保持されているハッシュアルゴリズムのＯＩＤを参照し、そのハッシュアルゴリズムを用いて、認証局証明書に記述される主体者名（ｓｕｂｊｅｃｔ）のハッシュ値と公開鍵（ｓｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏ）のハッシュ値とをそれぞれ計算し、この二つの値のペアを認証局識別テーブル６０の対応する箇所へ記述する。【００４７】
例えば、図６では、ＯＣＳＰレスポンダ１３は認証局１（ＣＡ１）、認証局２（ＣＡ２）、及び認証局３（ＣＡ３）が発行した公開鍵証明書の失効を確認するように設定されている。認証局１（ＣＡ１）は、鍵を更新し、更新後に発行した新しい認証局証明書（ＣＡ１＿ｎｅｗ証明書）と、更新前の古い認証局証明書（ＣＡ１＿ｏｌｄ証明書）とが有効である（有効期間内にある）ことを示している。認証局２（ＣＡ２）に関しても、認証局１（ＣＡ１）と同様に、新しい認証局証明書（ＣＡ２＿ｎｅｗ証明書）と、古い認証局証明書（ＣＡ２＿ｏｌｄ証明書）とが有効であることを示している。また、ＯＣＳＰレスポンダ１３が受け付け可能なハッシュアルゴリズムとして、ＳＨＡ−１、ＳＨＡ−２５６、ＳＨＡ−５１２、及び任意のハッシュアルゴリズムがあることを示している。【００４８】
認証局証明書が認証局１（ＣＡ１）の新しい認証局証明書（ＣＡ１＿ｎｅｗ証明書）を例に、主体者名（ｓｕｂｊｅｃｔ）のハッシュ値と公開（ｓｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏ）のハッシュ値のペアとの関係を説明する。ＣＡ１＿ｎｅｗ証明書に記述される主体者名（ｓｕｂｊｅｃｔ）のハッシュ値と公開鍵（ｓｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏ）のハッシュ値とをＳＨＡ−１アルゴリズムを用いて計算し、計算結果のペアを認証局識別テーブル６０のＣＡ１＿ｎｅｗ証明書の列のハッシュ値（ＳＨＡ−１）６２の行に記述してある。同様に、ハッシュアルゴリズムＳＨＡ−２５６、ＳＨＡ−５１２、及び任意のハッシュアルゴリズムを用いて計算したハッシュ値のペアを認証局識別テーブル６０のハッシュ値（ＳＨＡ−２５６）６３の行、ハッシュ値（ＳＨＡ−５１２）６４の行、及びハッシュ値（任意のハッシュアルゴリズム）６５の行に記述してある。基準ハッシュアルゴリズムで計算された、認証局証明書に記述される主体者名（ｓｕｂｊｅｃｔ）のハッシュ値を認証局証明書の認証局識別子６６とする。図６では、基準ハッシュアルゴリズムをＳＨＡ−１としている。認証局１（ＣＡ１）場合で説明すると、鍵の更新に伴って、新しい認証局証明書（ＣＡ１＿ｎｅｗ証明書）と古い認証局証明書（ＣＡ１＿ｏｌｄ証明書）との間で、公開鍵（ｓｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏ）のハッシュ値は異なるが、認証局１（ＣＡ１）は同じであるので、その主体者名（ｓｕｂｊｅｃｔ）のハッシュ値「１２３４５」も同じである。なお、基準ハッシュアルゴリズムにより計算した、主体者名（ｓｕｂｊｅｃｔ）のハッシュ値と公開鍵（ｓｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏ）のハッシュ値とのペアを認証局証明書識別子６２として用いる。【００４９】
ＯＣＳＰレスポンダ１３の操作者は、予めＣＲＬの更新タイミングの設定を行う。具体的には、ＯＣＳＰレスポンダ１３が対応する認証局ごとに、ＣＲＬを更新するタイミングを入出力部４０ｄを介して入力し、ＯＣＳＰレスポンダ１３の管理部４１がこのＣＲＬ更新タイミングを設定情報保持部４５へ登録する。【００５０】
図７は、ＯＣＳＰレスポンダ１３が実行するＣＲＬの更新処理のフローチャートを示す。ＯＣＳＰレスポンダ１３の失効情報管理部４２は、予め設定情報保持部４５に設定されたＣＲＬ更新タイミング（例えば１日）を経過したかを確認し（１０００）、経過している場合は通信部４０ｃを介してＣＲＬ取得要求を認証局１２へ送信する（１００１）。認証局１２は、ＣＲＬ取得要求を受信する（１１００）と、ＣＲＬに認証局１２の秘密鍵を用いて署名をし、ＯＣＳＰレスポンダ１３へ送信する（１１０１）。このＣＲＬには、ＣＲＬを作成した時点の認証局１２の名前（ｉｓｓｕｅｒ）、認証局１２の鍵情報（ａｕｔｈｏｒｉｔｙＫｅｙＩｄｅｎｔｉｆｉｅｒ）、認証局１２が発行した有効期間内の公開鍵証明書のうち失効した公開鍵証明書のシリアルナンバー（ｓｅｒｉａｌＮｕｍｂｅｒ）、ＣＲＬの有効期間（ＣＲＬ作成日時、次回ＣＲＬ作成日時）等が記載されている。ＯＣＳＰレスポンダ１３の失効情報管理部４２は、認証局１２からのＣＲＬを受信する（１００２）と、認証局証明書（認証局１２の公開鍵証明書）を用いてＣＲＬに記載されている認証局の署名を確認し（１００３）、受信したＣＲＬが更新されたかどうかを確認する（１００４）。ＣＲＬには、認証局１２によるＣＲＬの作成日時が記載されているため、認証局１２から受信したＣＲＬの作成日時が前回取得したＣＲＬの作成日時よりも新しくなっていた場合、認証局１２のＣＲＬが更新されていると判断し、ステップ１００５へ進む。受信した認証局１２のＣＲＬが更新されていなかった場合、ステップ１０００へ進む。なお、認証局１２から初めてＣＲＬを受信する場合は、ステップ１００５へ進む。次に、ＯＣＳＰレスポンダ１３の失効情報管理部４２は、受信したＣＲＬに基づいて失効情報テーブル８０の作成または更新を行い、失効情報保持部４６へ格納する（１００６）。【００５１】
図８は、失効情報テーブル８０の例を示す。失効情報テーブル８０は、認証局識別子８１に対応して、ＣＲＬの署名アルゴリズムのＯＩＤ（オブジェクトＩＤ）８２と、ＣＲＬ有効期間８３と、失効した証明書のシリアルナンバー（ｕｓｅｒＣｅｒｔｉｆｉｃａｔｅ）８４と、証明書の失効日時８５と、証明書の失効理由８６と、取得したＣＲＬに付与されていた認証局の署名に用いられた暗号アルゴリズムであるＣＲＬ署名アルゴリズム８７とが格納される。【００５２】
失効情報テーブル８０は、次のように作成または更新する。ＯＣＳＰレスポンダ１３の失効情報管理部４２は、取得したＣＲＬに記述される発行者名（ｉｓｓｕｒｅ）および認証局鍵識別子（ａｕｔｈｏｒｉｔｙＫｅｙＩｄｅｎｔｉｆｉｅｒ）の値をキーにして、設定情報保持部４５に登録されている認証局証明書の中から、対応する認証局証明書を特定し、特定した認証局証明書を取得する。その認証局証明書から基準ハッシュアルゴリズムを用いて、認証局識別テーブル６０に登録されている認証局識別子６６を求める。失効情報管理部４２は、求めた認証局識別子をキーにして、失効情報テーブル８０の認証局識別子８１欄から同じ認証局識別子を検索する。なお、同じ認証局識別子が存在しない場合には、失効情報管理部４２は、新たな認証局１２のＣＲＬであると判断し、失効情報テーブル８０の認証局識別子８１欄へ、求めた認証局識別子を追加する。次に、失効情報管理部４２は、検索した認証局識別子８１に対応する、署名アルゴリズムのＯＩＤ８２欄および、ＣＲＬ有効期間８３欄へ、ＣＲＬを発行した認証局がＣＲＬに付与した署名に用いた暗号アルゴリズム（ｓｉｇｎａｔｕｒｅＡｌｇｏｒｉｔｈｍ）のオブジェクトＩＤ（ＯＩＤ）および、有効期間（ｔｈｉｓＵｐｄａｔｅ、ｎｅｘｔＵｐｄａｔｅ）を各々記述または更新する。次に、失効情報管理部４２は、検索した認証局識別子８１に対応する、失効した証明書のシリアルナンバー８４欄へ、ＣＲＬに記述されている失効した公開鍵証明書のシリアルナンバーを登録し、証明書の失効日時８５欄へ、失効した公開鍵証明書の失効日時を登録し、証明書の失効理由８６欄へ、公開鍵証明書の該当する失効理由を登録する。なお、失効理（ｒｅａｓｏｎＣｏｄｅ）は、その番号に対応する意味がＲＦＣ５２８０で規定されている。次に、失効情報管理部４２は、検索した認証局識別子８１に対応する、ＣＲＬ署名アルゴリズム８７欄へ、認証局１２が発行したＣＲＬの署名に用いられた暗号アルゴリズムを登録する。【００５３】
例えば、認証局識別子８１が「１２３４５」の認証局１が、２０１０／９／３０／２４：００に鍵を更新し、更新前の古い認証局証明書（ＣＡ１＿ｏｌｄ証明書）に対応して認証局証明書識別子が「１２３４５／ａａｂｃｅ」であり、更新後の新しい認証局証明書（ＣＡ１＿ｎｅｗ証明書）に対応して認証局証明書識別子が「１２３４５／ａｂｃｄｅ」であるとする。この場合、失効情報テーブル８０の失効した証明書のシリアルナンバー８４の欄にあるシリアルナンバー「３」及び「５」は、認証局の鍵が更新される前に認証局１によって発行された公開鍵証明書のシリアルナンバーであり、シリアルナンバー「１２２」、「１２３」及び「２００」は認証局の鍵が更新された後に認証局１によって発行された公開鍵証明書のシリアルナンバーであり、これらのシリアルナンバーは、鍵の更新の前後にかかわらず、現状の鍵（更新後の鍵）を用いている認証局証明書（ＣＡ１＿ｎｅｗ証明書）に対応したＣＲＬに含まれる。【００５４】
図９は、ＯＣＳＰ証明書識別テーブル９０の例を示す。ＯＣＳＰ証明書識別テーブル９０は、認証局証明書識別子９１に対応して、認証局証明書ファイル名９２、ＯＣＳＰ証明書ファイル名９３を有する。【００５５】
ＯＣＳＰレスポンダ１３の操作者は、入出力部４０ｄを介して認証局証明書とＯＣＳＰ証明書をＯＣＳＰレスポンダ１３へ入力する。ＯＣＳＰレスポンダ１３が複数の認証局１２に対応する場合、ＯＣＳＰレスポンダ１３の操作者は、認証局１２の認証局証明書とその認証局１２が発行したＯＣＳＰ証明書を同様に入力する。また、認証局１２が秘密鍵を更新し、複数世代の認証局証明書を発行している場合は、ＯＣＳＰレスポンダ１３の操作者は、新しい秘密鍵に対応する認証局証明書と古い秘密鍵に対応する認証局証明書、また新しい秘密鍵の認証局１２から発行されたＯＣＳＰ証明書と古い秘密鍵の認証局１２から発行されたＯＣＳＰ証明書（古い秘密鍵が複数世代ある場合には、それらの秘密鍵の認証局証明書とそれらの認証局１２から発行されたＯＣＳＰ証明書のうち、有効期間内のものすべて）の入力を同様に行う。その結果、ＯＣＳＰレスポンダ１３のＯＣＳＰ証明書保持部４７には、ＯＣＳＰレスポンダ１３が対応する有効期間内全ての世代の認証局証明書とそれらの認証局１２から発行された全てのＯＣＳＰ証明書とが登録される。なお、認証局証明書の入力は、前述の設定情報保持部４５へ保持する場合と兼ねて、一度の入力にすると効率的である。ＯＣＳＰレスポンダ１３の管理部４１は、登録された認証局証明書およびＯＣＳＰ証明書に基づいて、ＯＣＳＰ証明書識別テーブル９０を作成し、設定情報保持部４５へ保持する。【００５６】
認証局証明書識別子９１は、基準ハッシュアルゴリズムを用いて、認証局証明書に記述される主体者名（ｓｕｂｊｅｃｔ）のハッシュ値と、公開鍵（ｓｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏ）のハッシュ値とをそれぞれ計算した、この二つの値のペアである。ＯＣＳＰレスポンダ１３の管理部４１は、各認証局証明書識別子９１に対応して、認証局証明書のファイル名を認証局証明書９２の行に登録し、ＯＣＳＰ証明書のファイル名をＯＣＳＰ証明書ファイル名９３の行に記述する。【００５７】
図１０は、リクエストテーブル１００の例を示す。リクエストテーブル１００は、リクエスト識別子１０１に対応して、ｉｓｓｕｅｒＮａｍｅＨａｓｈ／ｉｓｓｕｅｒＫｅｙＨａｓｈ１０２と、シリアルナンバー１０３と、ＰＳＡ（Ｐｒｅｆｅｒｒｅｄ  Ｓｉｇｎａｔｕｒｅ  Ａｌｇｏｒｉｔｈｍ）１０４と、リクエスト署名アルゴリズム１０５とを有する。【００５８】
リクエストテーブル１００は、次のように作成する。ＯＣＳＰレスポンダ１３は、利用者から検証要求を受け付けた際に、ｉｓｓｕｅｒＮａｍｅＨａｓｈ／ｉｓｓｕｅｒＫｅｙＨａｓｈ１０２欄へ、ＣｅｒｔＩＤに含まれる検証対象証明書を発行した認証局の名前情報（ｉｓｓｕｅｒＮａｍｅＨａｓｈ）と認証局の鍵情報（ｉｓｓｕｅｒＫｅｙＨａｓｈ）とを登録し、シリアルＮＯ１０３欄へ、ＣｅｒｔＩＤに含まれる検証対象証明書のシリアルナンバーを登録する。また、検証要求の要求拡張（ｒｅｑｕｅｓｔＥｘｔｅｎｓｉｏｎｓ）領域にＰＳＡが記載されている場合は、ＯＣＳＰレスポンダ１３は、そのＰＳＡをＰＳＡ１０４欄へ登録する。検証要求にＰＳＡが複数記載されている場合は、記載されている順にＰＳＡ１０４欄へ全て登録する。また、検証要求に利用者による署名（リクエスト署名）が付与されている場合は、ＯＣＳＰレスポンダ１３は、リクエスト署名アルゴリズム１０５欄へ、リクエスト署名の暗号アルゴリズムを登録する。また、ＰＳＡが検証要求に指定されていない、またはリクエスト署名が付与されていない場合は、該当するＰＳＡ１０４欄や、リクエスト署名アルゴリズム１０５欄は空欄とする。リクエストテーブル１００は、検証要求ごとに作成され、ＯＣＳＰレスポンダ１３のメモリ上に保持される。ここで、リクエスト識別子１０１は、検証要求を処理するプロセスのＩＤや、スレッドＩＤや、日時のデータや、利用者のＩＰアドレスとポート番号などがあり、特に限定しない。【００５９】
図１１は、署名ポリシーテーブル１１０の例を示す。署名ポリシーテーブル１１０は、ＯＣＳＰレスポンダ１３が対応可能なアルゴリズムの一覧を優先順位順にリストとして保持する。図１１に示すように、署名ポリシーテーブル１１０は、テーブルの列番号を示すＳ１１１に対応して、レスポンス署名アルゴリズム１１２が格納される。署名ポリシーテーブル１１０は、そのＯＣＳＰレスポンダ１３が秘密鍵を保持していて、署名が可能な暗号アルゴリズムが記述され、ＯＣＳＰレスポンダ１３がデフォルトとするレスポンス署名の暗号アルゴリズムから順に優先順位がつけられて登録される。署名ポリシーテーブル１１０は、ＯＣＳＰレスポンダ１３の操作者により予め作成され、ＯＣＳＰレスポンダ１３の設定情報保持部４５に保持される。ここでは、例えば、レスポンス署名アルゴリズム１１２欄に記載されている暗号アルゴリズムのうち、Ｓ１１１欄の番号の若いものがより優先度が高いものとしている。図１１の署名ポリシーテーブル１１０は一例であり、テーブルの形をとらずリストの形式で保持されても良い。【００６０】
図１２は、レスポンス署名アルゴリズム選択リストテーブル１２０の例を示す。レスポンス署名アルゴリズム選択リストテーブル１２０は、テーブルの列番号を示すＴ１２１に対して、項目１２２と列番号Ｕ１２３と暗号アルゴリズム１２４とを有する。Ｔ１２１は、レスポンス署名に用いる暗号アルゴリズムの優先順位を示し、項目１２２は、暗号アルゴリズムの指定箇所を示し、Ｕ１２３は、Ｔ１２１の一つの項目に対して暗号アルゴリズムが複数ある場合に区別するための数値を示し、暗号アルゴリズム１２４は、項目１２２に対応する暗号アルゴリズムを示す。また、レスポンス署名アルゴリズム選択リストテーブル１２０は、利用者からの検証要求ごとに作成され、ＯＣＳＰレスポンダ１３のメモリ上に保持される。図１２のレスポンス署名アルゴリズム選択リストテーブル１２０は一例であり、テーブルの形を取らず、リストの形式で保持されても良い。また、図１２のレスポンス署名アルゴリズム選択リストテーブル１２０は、後述する図１４のレスポンス署名アルゴリズムの決定処理において、項目１２２に該当する暗号アルゴリズムを各指定箇所から取得して該当する暗号アルゴリズム１２４へ登録して作成したが、暗号アルゴリズム１２４は、実際に暗号アルゴリズム名を登録するのではなく、暗号アルゴリズムの指定箇所をポインタなどで指定しても良い。【００６１】
さらに、本実施例では項目１２２とその優先順位を非特許文献２に記載されたレスポンス署名の暗号アルゴリズムの選択順序に従って設定したが、項目１２２の内容や優先順位は、ＯＣＳＰレスポンダ１３のポリシーなどによって設定を変更することが可能である。【００６２】
次に、本実施例において公開鍵証明書が失効しているかどうかの確認を行う検証処理の動作について説明する。【００６３】
図１３は、ＯＣＳＰレスポンダ１３が実行する公開鍵証明書の検証処理のフローチャートを示す図である。【００６４】
端末装置１１の署名・証明書検証部２２は、他の端末装置１１からの電子文書に添付されていた公開鍵証明書（図２の説明時の他公開鍵証明書）が失効しているかどうかの確認のために、検証要求を作成し、通信部２０ｃを介して、検証サーバ１３へ送信する（ステップ２１００）。ＯＣＳＰレスポンダ１３の検証処理部４３は、検証要求を受信すると（２０００）、検証要求に含まれるリクエスト識別子とＣｅｒｔＩＤとＰＳＡ（Ｐｒｅｆｅｒｒｅｄ  Ｓｉｇｎａｔｕｒｅ  Ａｌｇｏｒｉｔｈｍ）、リクエスト署名アルゴリズムとを取得し、リクエストテーブル１００を作成する（２００１）。ここで、検証要求に含まれるＰＳＡが複数設定されている場合、ＰＳＡが設定されている順に、設定されている全てのＰＳＡをリクエストテーブル１００へ記載する。また、ＰＳＡが指定されていない、またはリクエスト署名が付与されていない場合もありうる。各情報が検証要求に含まれていない場合は、該当するＰＳＡ１０４欄や、リクエスト署名アルゴリズム１０５欄は空欄とする。次に、検証処理部４３は、リクエストテーブル１００のｉｓｓｕｒｅＮａｍｅＨａｓｈ／ｉｓｓｕｒｅＫｅｙＨａｓｈ１０２をキーとして、情報保持部４６に保持される認証局識別テーブル６０を照合し（２００２）、リクエストテーブル１００に記載されたｉｓｓｕｒｅＮａｍｅＨａｓｈ／ｉｓｓｕｒｅＫｅｙＨａｓｈのペアが認証局識別テーブル６０に存在するかどうかを確認する（２００３）。リクエストテーブル１００に記載されるｉｓｓｕｒｅＮａｍｅＨａｓｈ／ｉｓｓｕｒｅＫｅｙＨａｓｈのペアが認証局識別テーブル６０に存在しない場合、この検証要求に対応する失効情報を持っていないので、検証処理部４３は、検証対象証明書の失効情報（ＣｅｒｔＳｔａｔｕｓ）を不明（ｕｎｋｎｏｗｎ）とする検証結果データを作成し（２００４）、ステップ２０１０へ進む。リクエストテーブル１００に記載されるｉｓｓｕｒｅＮａｍｅＨａｓｈ／ｉｓｓｕｒｅＫｅｙＨａｓｈのペアが認証局識別テーブル６０に存在する場合、検証処理部４３は、ｉｓｓｕｒｅＮａｍｅＨａｓｈ／ｉｓｓｕｒｅＫｅｙＨａｓｈのペアに対応する、認証局証明書識別子を取得し（２００５）、さらに認証局証明書識別子に対応する認証局識別子を取得する（２００６）。次に、検証処理部４３は、検証要求と失効情報テーブル８０との照合を行う（２００７）。検証処理部４３は、ステップ２００６で取得した認証局識別子をキーとして、失効情報テーブル８０の認証局識別子８１を検索し、取得した認証局識別子と同一の認証局識別子８１を特定する。次に、検証処理部４３は、検証要求に含まれる検証対象証明書のシリアルナンバー（ＣｅｒｔＩＤのｓｅｒｉａｌＮｕｍｂｅｒ）と、特定された認証局識別子８１に対応する失効した証明書のシリアルナンバー８４を比較し、検証対象証明書のシリアル番号が、失効情報テーブル８０の失効した証明書のシリアルナンバー８４に記載されているかどうかを確認する（２００８）。検証要求に含まれる検証対象証明書のシリアルナンバーが失効情報テーブル８０に存在しない場合、検証処理部４３は、検証対象証明書の失効情報（ＣｅｒｔＳｔａｔｕｓ）を有効（ｇｏｏｄ）とする検証結果データを作成し��（２００９）、ステップ２０１１に進み、検証対象証明書のシリアルナンバーが失効情報テーブル８０に存在する場合、検証対象証明書の失効情報（ＣｅｒｔＳｔａｔｕｓ）を失効（ｒｅｖｏｋｅｄ）とする検証結果データを作成して（２０１０）、ステップ２０１１に進む。次に、検証処理部４３は、ステップ２００５で取得した認証局証明書識別子をキーとして、ＯＣＳＰ証明書識別テーブル９０の認証局証明書識別子９１を検索し、取得した認証局証明書識別子と同一の認証局証明書識別子９１を特定する（２０１１）。検証処理部４３は、特定された認証局証明書識別子９１に対応するＯＣＳＰ証明書ファイル名を取得する（２０１２）。次に、検証処理部４３は、レスポンス署名に用いる暗号アルゴリズムの選択処理を行い、暗号アルゴリズムを一つ特定する（２０１３）。レスポンス署名に用いる暗号アルゴリズムの決定処理の動作については、図１４にて詳述する。ここで、暗号アルゴリズムの決定処理により、レスポンス署名に用いる暗号アルゴリズムが特定できたかを確認する（２０１４）。レスポンス署名に用いるアルゴリズムが特定できた場合、検証処理部４３は、ステップ２０１２で取得したＯＣＳＰ証明書ファイル名、ステップ２０１３で特定したレスポンス署名アルゴリズムに用いる暗号アルゴリズムを利用し、鍵保持部４８に保持されているＯＣＳＰ証明書の鍵で検証結果に署名を付与して署名付きの検証応答を作成する（２０１５）。【００６５】
また、暗号アルゴリズムの決定処理により、レスポンス署名に用いる暗号アルゴリズムが特定できなかった場合、検証処理部４３は、検証結果をエラーとする検証応答を作成する（２０１６）。次に、検証処理部４３は、ステップ２０１５またはステップ２０１６で作成した結果データを、通信部４０ｃを介して、端末装置１１へ送信する（２０１７）。端末装置１１は、ＯＣＳＰレスポンダ１３から、検証要求に対応する検証応答を受信し（２１０１）、検証対象証明書が失効しているかどうかを確認する。【００６６】
次に、ステップ２０１３で行った、ＯＣＳＰレスポンダ１３が検証結果に付与するレスポンス署名に用いる暗号アルゴリズムを決定する動作について説明する。【００６７】
図１４は、ＯＣＳＰレスポンダ１３が実行するレスポンス署名に用いる暗号アルゴリズムの決定処理のフローチャートを示す図である。【００６８】
ＯＣＳＰレスポンダ１３の検証処理部４３は、受け付けた検証要求ごとに、レスポンス署名アルゴリズム選択リストテーブル１２０を作成する。具体的には、検証処理部４３は、受け付けた検証要求のリクエスト識別子１０１をキーとして、リクエストテーブル１００からＰＳＡ１０４とリクエスト署名アルゴリズム１０５を取得する（３０００）。次に、検証処理部４３は、ステップ２００６で取得した認証局識別子をキーとして、失効情報テーブル８０からＣＲＬ署名アルゴリズム８７を取得する（３００１）。そして、検証処理部４３は、ステップ３０００とステップ３００１で取得した情報と、設定情報保持部４５に保持されたＯＣＳＰレスポンダ設定署名アルゴリズムとＯＣＳＰのｖｅｒｓｉｏｎで必須とする署名アルゴリズムの情報から、検証要求に対応するレスポンス署名アルゴリズム選択リストテーブル１２０を作成する（３００２）。具体的には、検証処理部４３は、レスポンス署名アルゴリズム選択リストテーブル１２０の項目１２２欄に記載された内容と対応する情報を、暗号アルゴリズム１２４欄へと登録する。ここで、ステップ３０００でＰＳＡを取得する際に、リクエストテーブル１００のキーとなるリクエスト識別子１０１の列に登録されているＰＳＡ１０４が複数あった場合、リクエストテーブル１００に記載されているＰＳＡ１０４全てを記載されている順番どおり取得し、レスポンス署名アルゴリズム選択テーブル１２０の暗号アルゴリズム１２４欄へ全て登録する。このとき、項目１２２一つに対して、暗号アルゴリズム１２４欄が複数存在する場合は、Ｕ１２３欄に順に１から番号を振り、これを優先順位とする。暗号アルゴリズム１２４欄が一つに特定される場合には、Ｕ１２３欄を１とする。【００６９】
次に、検証処理部４３は、作成したレスポンス署名アルゴリズム選択リストテーブル１２０と署名ポリシーテーブル１１０を用いてレスポンス署名に用いる暗号アルゴリズムを選択する。まず、レスポンス署名アルゴリズム選択リストテーブル１２０のＴ１２１欄において、Ｔ＝１とする（３００３）。次に、検証処理部４３は、レスポンス署名アルゴリズム選択テーブル１２０で取得したＴに対応するＵ１２３欄において、Ｕ＝１とする（３００４）。そして、検証処理部４３は、Ｕに対応する暗号アルゴリズム１２４の値が設定されているか（レスポンス署名アルゴリズム選択リストテーブル１２０の該当カラムが埋まっているか）を確認する（３００５）。暗号アルゴリズム１２４が設定されていない場合、検証処理部４３は、ステップ３０１３へ進む。暗号アルゴリズム１２４が設定されている場合、検証処理部４３は、署名ポリシーテーブル１１０が設定情報保持部４５に保持されているかを確認し（３００６）、保持されていた場合、署名ポリシーテーブル１１０のＳ１１１において、Ｓ＝１とする（３００７）。次に、検証処理部４３は、Ｕに対応する暗号アルゴリズム１２４欄に記載された暗号アルゴリズムと、Ｓに対応するレスポンス署名アルゴリズム１１２欄に記載された暗号アルゴリズムを取得し、両者の暗号アルゴリズムが一致するかを確認する（３００８）。両者の暗号アルゴリズムが異なる場合、検証処理部４３は、ステップ３０１１へ進む。両者の暗号アルゴリズムが一致した場合、検証処理部４３は、Ｕに対応する暗号アルゴリズム１２４欄に記載された暗号アルゴリズムで署名可能な秘密鍵が鍵保持部４８に保持されているかを確認する（３００９）。秘密鍵を保持していなかった場合、検証処理部４３は、ステップ３０１３へ進む。Ｕに対応する暗号アルゴリズム１２４欄に記載された暗号アルゴリズムの秘密鍵を保持していた場合、検証処理部４３は、その暗号アルゴリズムをレスポンス署名に用いる暗号アルゴリズムとして決定する（３０１０）。【００７０】
Ｕに対応する暗号アルゴリズム１２４欄に記載された暗号アルゴリズムと、Ｓに対応するレスポンス署名アルゴリズム１１２欄に記載された暗号アルゴリズムが異なった場合（３００８でＮｏになる場合）、検証処理部４３は、Ｓの値が、署名ポリシーテーブル１１０のＳ１１１列の末尾であるかを確認する（３０１１）。Ｓの値が、Ｓ１１１列の末尾ではなかった場合、検証処理部４３は、Ｓの値を１増やして再度ステップ３００８へ進む（３０１２）。【００７１】
ステップ３０１１でＳの値が、Ｓ１１１列の末尾であった場合、またはステップ３００５でＵに対応する暗号アルゴリズム１２４が設定されていなかった場合、または、ステップ３００９でＵに対応する署名アルゴリズムの署名可能な秘密鍵を保持していなかった場合、検証処理部４３は、Ｕの値が、レスポンス署名アルゴリズム選択リストテーブル１２０のＵ１２３列の末尾であるかを確認する（３０１３）。Ｕの値が、Ｕ１２３列の末尾ではなかった場合、検証処理部４３は、Ｕの値を１増やして再度ステップ３００５へ進む（３０１４）。ここでＵの値がＵ１２３列の末尾であった場合、ステップ３０１５へ進む。検証処理部４３は、Ｔの値が、レスポンス署名アルゴリズム選択リストテーブル１２０のＴ１２１列の末尾であるかを確認する（３０１５）。Ｔの値が、Ｔ１２１列の末尾ではなかった場合、検証処理部４３は、Ｔの値を１増やして再度ステップ３００４へ進む（３０１６）。【００７２】
ステップ３０１５でＴの値が、Ｔ１２１列の末尾であった場合、検証処理部４３は、非特許文献２のＲＦＣ６２７７で定義されるＯＣＳＰのｖｅｒｓｉｏｎで利用必須とするデフォルトの暗号アルゴリズムを取得する（３０１７）。そして、ＯＣＳＰｖｅｒ１のデフォルトの暗号アルゴリズムで署名可能な秘密鍵が鍵保持部４８に保持されているかを確認し（３０１８）、秘密鍵を保持していた場合は、ＯＣＳＰｖｅｒ１のデフォルトの暗号アルゴリズムをレスポンス署名に用いる暗号アルゴリズムとして決定する（３０１９）。ＯＣＳＰｖｅｒ１に対応するデフォルトの暗号アルゴリズムの秘密鍵を保持していなかった場合、ＯＣＳＰレスポンダ１３はエラーとなる。【００７３】
以上、本発明の一実施例を説明した。本実施例によれば、証明書の署名に用いる暗号アルゴリズムの移行状況に係わらず、利用者に適した、検証対象証明書の検証結果に付与するレスポンス署名の暗号アルゴリズムを決定できる。【００７４】
また、他の実施例として、図９のＯＣＳＰ証明書識別テーブル９０を拡張した例を示す。【００７５】
図１５は、ＯＣＳＰ証明書識別テーブル９０を拡張した場合のテーブル例を示す図である。【００７６】
ＯＣＳＰ証明書識別テーブル９０は、前述した項目９１〜９３以外に、レスポンス署名アルゴリズム９４を格納する。これは、図１１で前述した署名ポリシーテーブル１１０を、ＯＣＳＰ証明書識別テーブル９０内に設定したものである。レスポンス署名アルゴリズム９４欄は、そのＯＣＳＰレスポンダ１３が秘密鍵を保持していて、署名が可能な暗号アルゴリズムが認証局１２ごとに記述され、ＯＣＳＰレスポンダ１３がデフォルトとするレスポンス署名の暗号アルゴリズムから順に優先順位が高いものから登録される。【００７７】
図１５のようにＯＣＳＰ証明書識別テーブル９０を保持する場合、署名ポリシーテーブル１１０はＯＣＳＰ証明書識別テーブルと同一のテーブルで管理される。【００７８】
上記のようにＯＣＳＰ証明書識別テーブル９０を保持する場合、図１４で示したＯＣＳＰレスポンダ１３が実行するレスポンス署名に用いる暗号アルゴリズムの決定処理で、検証処理部４３は、署名ポリシーテーブル１１０を確認するステップ３００５ではＯＣＳＰ証明書識別テーブル９０のレスポンス署名アルゴリズム欄９４が設定されているかを確認する。さらに、ステップ３００６では、検証処理部４３は、レスポンス署名アルゴリズム欄９４に設定されている署名アルゴリズムを項番Ｓとし、上から順に１、２・・・とみなして署名アルゴリズム選択リストテーブル１２０との比較を行う。【００７９】
以上の結果、ＯＣＳＰレスポンダ１３が複数の認証局１２に対応する（複数の認証局１２が発行するＣＲＬを取り込む）場合において、認証局１２ごとに異なる署名ポリシーを設定することもできる。
【実施例２】
【００８０】
実施例１では、レスポンス署名アルゴリズム選択リストテーブル１２０に登録される暗号アルゴリズム１２４に対して、Ｕ１２３列が優先度を示す場合について説明した。実施例１では、Ｕ１２３列の記載順に優先度が高いものとし、レスポンス署名アルゴリズム選択リストテーブル１２０に登録したが、たとえば、検証要求のＰｒｅｆｅｒｒｅｄＳｉｇｎａｔｕｒｅＡｌｇｏｒｉｔｈｍの記載順が、利用者の意図する優先度とは限らない。【００８１】
そこで、本実施例では、利用者は優先度を意識せず、Ｔ１２１に対応する暗号アルゴリズムが複数存在した場合においても、ＯＣＳＰレスポンダ１３の保持する署名ポリシーテーブル１１０でＯＣＳＰレスポンダがあらかじめ指定した優先度を用いて、レスポンス署名に用いる暗号アルゴリズムを決定する方法について述べる。【００８２】
図１６、１７は、本発明の第二の実施例における、ＯＣＳＰレスポンダ１３が実行するレスポンス署名に用いる暗号アルゴリズムの決定処理のフローチャートを示す図である。【００８３】
図１６で、ＯＣＳＰレスポンダ１３の検証処理部４３は、受け付けた検証要求ごとに、レスポンス署名アルゴリズム選択リストテーブル１２０を作成する。レスポンス署名アルゴリズム選択リストテーブル１２０を作成するために、まず、検証処理部４３は、受け付けた検証要求のリクエスト識別子１０１をキーとして、リクエストテーブル１００からＰＳＡ１０４とリクエスト署名アルゴリズム１０５を取得する（４０００）。次に、検証処理部４３は、ステップ２００６で取得した認証局識別子をキーとして、失効情報テーブル８０からＣＲＬ署名アルゴリズム８７を取得する（４００１）。そして、検証処理部４３は、ステップ４０００とステップ４００１で取得した情報と、設定情報保持部４５に保持されたＯＣＳＰレスポンダ設定署名アルゴリズムとＯＣＳＰのｖｅｒｓｉｏｎで必須とする署名アルゴリズムの情報から、検証要求に対応するレスポンス署名アルゴリズム選択リストテーブル１２０を作成する（４００２）。具体的には、検証処理部４３は、ステップ４０００とステップ４００１で取得した情報を、レスポンス署名アルゴリズム選択リストテーブル１２０の項目１２２欄に記載された内容と対応させ、暗号アルゴリズム１２４欄へと登録する。【００８４】
ここで、対応する暗号アルゴリズムの情報が複数存在する場合、暗号アルゴリズム１２４欄は複数併記して登録する。
たとえば、ステップ４０００でＰＳＡを取得する際に、リクエストテーブル１００のキーとなるリクエスト識別子１０１の列に登録されているＰＳＡ１０４が複数あった場合、リクエストテーブル１００に記載されているＰＳＡ１０４全てを取得し、レスポンス署名アルゴリズム選択テーブル１２０の暗号アルゴリズム１２４欄へ全て登録する。項目１２２一つに対して、暗号アルゴリズム１２４欄が複数存在する場合は、Ｕ１２３欄には、便宜的に１から順に番号を振る。暗号アルゴリズム１２４欄が一つに特定される場合は、Ｕ１２３欄は１とする。【００８５】
次に、図１７のＡのステップ５０００に進む。
図１７は、図１６で作成したレスポンス署名アルゴリズム選択リストテーブル１２０と署名ポリシーテーブル１１０を用いてレスポンス署名に用いる暗号アルゴリズムを選択する処理を示す図である。【００８６】
まず、レスポンス署名アルゴリズム選択リストテーブル１２０のＴ１２１欄において、Ｔ＝１の項目を取得する（５０００）。検証処理部４３は、レスポンス署名アルゴリズム選択リストテーブル１２０のＵ１２３欄において、取得したＴに対応する暗号アルゴリズム１２４欄に暗号アルゴリズムが登録されているかを確認する（５００１）。該当する１２４欄に暗号アルゴリズムが登録されていない場合、ステップ５０１５へ進む。該当する１２４欄に暗号アルゴリズムが登録されている場合、Ｕ＝１の項目を取得する（５００２）。【００８７】
次に、検証処理部４３は、設定情報保持部４５に保持されている署名ポリシーテーブル１１０のＳ１１１欄において、Ｓ＝１の項目を取得する（５００３）。そして、検証処理部４３は、取得しているＵに対応するレスポンス署名アルゴリズム選択リストテーブル１２０の暗号アルゴリズム１２４欄に記載された暗号アルゴリズムと、取得しているＳに対応する署名ポリシーテーブル１１０のレスポンス署名アルゴリズム１１２欄に記載された暗号アルゴリズムが同じものであるか確認する（５００４）。両方の暗号アルゴリズムが一致した場合、検証処理部４３は、現在取得している署名ポリシーテーブル１１０のＳ欄の数値を保存する（５００５）。ステップ５００４において、両方の暗号アルゴリズムが一致しなかった場合、検証処理部４３は、現在取得している項番Ｓの値が、署名ポリシーテーブル１１０のＳ１１１列の末尾であるかを確認する（５００８）。取得している項番Ｓが、Ｓ１１１列の末尾ではなかった場合、検証処理部４３は、Ｓの数値を１増やして再度ステップ５００４へ進む（５００７）。取得している項番Ｓが、Ｓ１１１列の末尾であった場合、ステップ５００８へ進む。【００８８】
ステップ５００５で項番Ｓの数値を保存した場合や、ステップ５００６で取得しているＳの値が、Ｓ１１１列の末尾であった場合、検証処理部４３は、現在取得している項番Ｕの値が、レスポンス署名アルゴリズム選択リストテーブル１２０の該当Ｔ１２１内に複数存在するＵのうち、Ｕ１２３列の末尾であるかを確認する（５００８）。取得している項番Ｕの値が、該当Ｔ１２１欄のＵ１２３列の末尾ではなかった場合、検証処理部４３は、Ｕの数値を１増やして再度ステップ５００３へと進む（５００９）。ここで項番Ｕの値がＵ１２３列の末尾であった場合、ステップ５０１０へ進む。【００８９】
次に、検証処理部４３は、ステップ５００４で一致した項番Ｕと項番Ｓの暗号アルゴリズムが一つ以上あるかどうかを確認する（５０１０）。一つもなかった場合、ステップ５０１５へ進む。一致する暗号アルゴリズムが一つ以上ある場合、検証処理部４３は、ステップ５００５で保存した項番Ｓの数値を比較し、最もＳの数値が小さい暗号アルゴリズム（つまり署名ポリシーテーブル１１０で上位に登録されている暗号アルゴリズム）を選択する（５０１１）。【００９０】
そして、検証処理部４３は、選択した暗号アルゴリズムで署名可能な秘密鍵が、鍵保持部４８に保持されているかを確認する（５０１２）。選択した暗号アルゴリズムの秘密鍵を保持している場合、検証処理部４３は、その暗号アルゴリズムをレスポンス署名に用いる暗号アルゴリズムとして決定し、図１６のＢへと進む（５０１３）。ステップ５０１２で、秘密鍵を保持していなかった場合、検証処理部４３は、ステップ５０１１で選択した暗号アルゴリズムに該当する項番Ｓの数値を除外し、再度ステップ５０１０へ進む（５０１４）。
ステップ５００１で、該当する１２４欄に暗号アルゴリズムが登録されていない場合、または、ステップ５０１０で、項番Ｕと項番Ｓの暗号アルゴリズムが一つも一致しなかった場合、検証処理部４３は、取得しているＴの値が、レスポンス署名アルゴリズム選択リストテーブル１２０のＴ１２１列の末尾であるかを確認する（５０１５）。Ｔの値が、Ｔ１２１列の末尾ではなかった場合、検証処理部４３は、Ｔの値を１増やして再度ステップ５００１へ進む（５０１６）。ステップ５０１５で、取得しているＴの値が、レスポンス署名アルゴリズム選択リストテーブル１２０のＴ１２１列の末尾であった場合、ＯＣＳＰレスポンダ１３はエラーを返す。【００９１】
以上、本発明の第二の実施例を説明した。本実施例によれば、レスポンス署名アルゴリズム選択リストテーブル１２０の１項目１２２に複数の暗号アルゴリズム１２４が優先度付けなく設定されていた場合においても、ＯＣＳＰレスポンダの署名ポリシーに基づいて、利用者に適した、検証対象証明書の検証結果に付与するレスポンス署名の暗号アルゴリズムを決定できる。
上記記載は実施例についてなされたが、本発明はそれに限らず、本発明の精神と添付の請求の範囲の範囲内で種々の変更および修正をすることができることは当業者に明らかである。
【符号の説明】
【００９２】
１１  端末装置
１２  認証局
１３  ＯＣＳＰレスポンダ
１４  ネットワーク
２０ａ  処理部
２０ｂ  記憶部
２０ｃ  入出力部
２０ｄ  通信部
２１  署名付き文書作成部
２２  署名・証明書検証部
２３  制御部
２４  電子文書保持部
２５  鍵保持部
２６  検証対象保持部
３０ａ  処理部
３０ｂ  記憶部
３０ｃ  入出力部
３０ｄ  通信部
３１  発行部
３２  管理部
３３  制御部
３４  証明書ＤＢ
３５  発行先管理リスト保持部
３６  ＣＲＬ保持部
４０ａ  処理部
４０ｂ  記憶部
４０ｃ  入出力部
４０ｄ  通信部
４１  管理部
４２  失効情報管理部
４３  検証処理部
４４  制御部
４５  設定情報保持部
４６  失効情報保持部
４７  ＯＣＳＰ証明書保持部
４８  鍵保持部
５０  内部通信線
５１  ＣＰＵ
５２  メモリ
５３  外部記憶装置
５４  通信装置
５５  入力装置
５６  出力装置
５７  読取装置
５８  可搬性を有する記憶媒体
【図１】
0005576985.tif 000002
【図２】
0005576985.tif 000003
【図３】
0005576985.tif 000004
【図４】
0005576985.tif 000005
【図５】
0005576985.tif 000006
【図６】
0005576985.tif 000007
【図７】
0005576985.tif 000008
【図８】
0005576985.tif 000009
【図９】
0005576985.tif 000010
【図１０】
0005576985.tif 000011
【図１１】
0005576985.tif 000012
【図１２】
0005576985.tif 000013
【図１３】
0005576985.tif 000014
【図１４】
0005576985.tif 000015
【図１５】
0005576985.tif 000016
【図１６】
0005576985.tif 000017
【図１７】
0005576985.tif 000018