JP5785875B2 - 公開鍵証明書の検証方法、検証サーバ、中継サーバおよびプログラム - Google Patents

Description

本発明は、公開鍵認証基盤（Public Key Infrastructure；以下「ＰＫＩ」という）において必要となる、公開鍵証明書の有効性を検証する技術に関する。

ＰＫＩにおいて、電子文書などの電子データを送付する際に、対象となる電子データに、送信者の保有する秘密鍵（Private Key）を用いて電子署名（以下「署名」という）を付与し、認証局が発行する送信者の公開鍵証明書を添付する。受信者は、受信データに添付された署名と公開鍵証明書の有効性を確認することにより、送付された電子データが改ざんされていないことと、確かに送信者本人から送られた電子データであることを確認する。公開鍵証明書の発行と有効性の確認は、ＰＫＩにおいて行われ、その標準仕様はＲＦＣ５２８０（Internet X.509 Public Key Infrastructure Certificate and CRL Profile）等にて規定されている。

公開鍵証明書は、その有効期間が終了する前に、その公開鍵証明書の記載内容に変更があった場合等には、その公開鍵証明書を発行した認証局（Certificate Authority）により失効される。そこで、受信者は、受信した公開鍵証明書の有効性確認において、その公開鍵証明書が失効しているか否かを確認する必要がある。

証明書が失効しているか否かの確認には、認証局が発行する公開鍵証明書失効リスト（Certificate Revocation List：以下「ＣＲＬ」という）を用いる。ＣＲＬには、認証局が発行した有効期間内の公開鍵証明書のうち失効した公開鍵証明書のシリアルナンバーや、ＣＲＬの有効期間（今回更新日時（thisUpdate）、次回更新日時（nextUpdate））等が記載され、認証局の署名が付与されており、認証局によって定期的に発行される。公開鍵証明書のシリアルナンバーとは、公開鍵証明書を発行する認証局が、自身が発行した公開鍵証明書を一意に識別できるよう設定した情報である。受信者は、認証局からＣＲＬを取得し、受信データに添付された有効性を確認する対象の公開鍵証明書のシリアルナンバーが、ＣＲＬに記載されているかどうかを確認する。シリアルナンバーがＣＲＬに記載されている場合は、この公開鍵証明書は失効していると判断し、記載されていない場合には、この公開鍵証明書は有効であると判断する。

しかしながら、認証局が発行する公開鍵証明書の数は多数あり、かつ失効する公開鍵証明書が多い場合、ＣＲＬの容量は膨大になる。このため、受信データに添付された公開鍵証明書の有効性を確認したい受信者にとっては、ＣＲＬの取得に時間がかかり、公開鍵証明書の有効性確認処理に時間がかかるという課題がある。これに対応するために、公開鍵証明書が失効しているかどうかの確認要求をオンラインで受け付けて、これに応答するサービスである検証サーバがあり、その標準仕様は非特許文献１に規定されている。

検証サーバは、認証局が発行するＣＲＬを定期的に取り込んでおき、公開鍵証明書の失効確認をする受信者が利用する端末（以下「端末装置」という）からの公開鍵証明書の失効確認要求（以下「検証要求」という）を受け付ける。検証要求には、検証対象の公開鍵証明書（以下「検証対象証明書」という）を特定するための情報（以下「ＣｅｒｔＩＤ」という）が記述される。ＣｅｒｔＩＤには、検証対象証明書を発行した認証局の名前情報と、認証局の公開鍵の情報と、検証対象証明書のシリアルナンバー等が含まれる。このうち認証局の名前情報と、認証局の公開鍵の情報とは、認証局の名前データと公開鍵データとを、端末装置が使用するハッシュアルゴリズムでそれぞれハッシュ計算して得られる情報である。

検証要求を受け付けた検証サーバは、検証対象証明書のシリアルナンバーが予め取り込んだＣＲＬに記載されているかどうかを調べ、この検証対象証明書である公開鍵証明書が失効しているかどうかを端末装置に応答する。検証サーバが作成した、検証対象証明書に対する検証を行った結果情報（以下「検証結果」という）には、検証対象証明書の状態が有効（good）、失効（revoked）、不明（unknown）のいずれかで記載される。さらに、検証結果には検証した検証サーバの署名および証明書（以下「検証サーバ証明書」という）が付与されて端末装置に送信される。この署名および証明書を確認することにより、端末装置の利用者は、この検証サーバによって確かに送付された検証結果であることを確認できる。

なお、ＣＲＬは、認証局によって失効された公開鍵証明書の情報の一覧であり、認証局は、認証局のポリシに基づくタイミングで、自身の発行した公開鍵証明書の失効情報を反映した新しいＣＲＬを発行する。そして、ＣＲＬには、認証局がＣＲＬを作成したその時点で失効している公開鍵証明書のシリアルナンバーがすべて記載されている。そして、ＣＲＬの発行タイミングは、ＣＲＬに記載される次回更新日時（nextUpdate）までには、新しいＣＲＬが発行されることとなっている。

そのため、検証者および検証サーバは、検証時に出来る限り最近に発行されたＣＲＬを取得して、公開鍵証明書の有効性確認を行うことが望ましい。ＣＲＬが発行された後に失効された公開鍵証明書に関しては、次のＣＲＬが発行され、その失効した公開鍵証明書のシリアルナンバーがＣＲＬに記載されるまでの間は、その公開鍵証明書が失効していることを知らず、有効として検証してしまうことになる。また、検証サーバは、次のＣＲＬの発行日時を正確に知ることができないため、検証サーバはＣＲＬに記載されている次回更新日時を参考に、ＣＲＬを取得しにいくことになる。

以上のような理由から、失効されている公開鍵証明書が、実際に失効として検証されるまでには、時間的な遅れが発生してしまうという課題があった。公開鍵証明書が失効してから、その公開鍵証明書に対して失効の検証が行われるまでの時間的な遅れは、次の二つの期間に分けて考えることが出来る。

（ａ）認証局が公開鍵証明書の失効依頼を受け付け、公開鍵証明書を失効させてから、次回ＣＲＬを発行し、当該公開鍵証明書のシリアルナンバーがＣＲＬに記載されるまでの期間
（ｂ）ＣＲＬが発行されてから、検証サーバが発行されたＣＲＬを取得するまでの期間
（ｂ）を解決するための技術として、nextUpdateのタイミングでＣＲＬを取得するだけでなく、検証者自身によって定義したタイミングでＣＲＬの取得要求を認証局に出し、ＣＲＬが発行された後、短時間でＣＲＬを取得する技術が、特許文献１に開示されている。

（ａ）および（ｂ）を解決するための技術として、ＣＲＬを利用せず、端末装置から検証要求を受信した際に、その時点での失効情報を認証局に直接問い合わせて取得する技術が、特許文献２に開示されている。

特開２００３−１５２７１５号公報 ＵＳ６９７０８６２Ｂ２号公報

"X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP(RFC2560）",page 2"2.1 Request" "2.2 Response",［online］,1999年6月、The Internet Engineering Task Force（IETF）,［平成23年9月28日検索］インターネット＜URL：http://ietf.org/rfc/rfc2560.txt＞

特許文献１では、（ｂ）の遅れを解決することが出来るが、失効した公開鍵証明書がＣＲＬに記載されるまでの（ａ）の遅れには対応できていない。公開鍵証明書が失効したという情報が、検証サーバに反映されるまでの遅れを解決し、リアルタイムに近い正確さで検証を行うためには、（ａ）の遅れも解決しなければならないという問題が発生する。

特許文献２では、検証要求のたびに、検証サーバが認証局へ直接失効情報を取得にいくため、検証要求時点の公開鍵証明書の有効性を検証することが出来る。しかし、公開鍵証明書の検証を行うたびに認証局とアクセスしなくてはならないため、アクセス頻度が高く、検証サーバの処理負荷が高くなり、公開鍵証明書の検証に時間がかかるという問題が発生する。

また、特許文献１、２ともに、認証局が一つである場合しか想定していない。しかし、認証局は複数存在しているため、一つの認証局にしか対応できない検証サーバでは、利用者が検証対象証明書を発行した認証局に合せて、検証サーバを選択しなければならないという問題がある。

本発明は上記課題に鑑みてなされたものであり、複数の認証局に対応し、公開鍵証明書が失効されてから、当該公開鍵証明書に対して失効の検証が行われるまでの時間的な遅れを低減し、かつ公開鍵証明書の検証処理を効率的に行うことができる公開鍵証明書の検証方法、これを実施する検証サーバ、中継サーバおよびプログラムを提供することを目的とする。

本発明の代表的な一例は次の通りである。すなわち、本発明は、公開鍵証明書の有効性を検証する検証サーバにおける公開鍵証明書の検証方法であって、
前記検証サーバは、認証局が発行した公開鍵証明書失効リストの情報を記憶する公開鍵証明書失効リスト情報記憶部を有し、
前記検証サーバにより、
端末装置から前記公開鍵証明書の検証要求を受信し、
前記公開鍵証明書失効リスト情報記憶部の情報を用いて前記受信した検証要求に含まれる検証対象の前記公開鍵証明書の有効性を検証し、
該検証の結果、前記検証対象の前記公開鍵証明書の情報が前記公開鍵証明書失効リスト情報記憶部に存在しない場合に、
前記検証対象の公開鍵証明書を発行した認証局から、該認証局が前記公開鍵証明書失効リストに記載する前の前記公開鍵証明書の失効情報を取得し、
前記取得した失効公開鍵証明書の情報を用いて前記検証対象の公開鍵証明書の有効性を検証し、
該検証の結果を前記端末装置へ応答する。

本発明によれば、認証局が複数ある場合であっても、失効した公開鍵証明書がＣＲＬに記載されるまでの期間において、公開鍵証明書の検証を正しく行うことを可能とし、公開鍵証明書が失効されてから、当該公開鍵証明書に対して失効の検証が行われるまでの時間的な遅れを低減し、かつアクセス処理の負荷を軽減して公開鍵証明書の検証処理を効率的に行うことができる。

第一の実施例における、検証サーバのシステム構成を示す図である。 第一の実施例における、検証サーバの構成を示す図である。 端末装置の構成を示す図である。 認証局の構成を示す図である。 検証サーバ、端末装置、認証局の各ハードウェア構成例を示す図である。 認証局識別テーブルの例を示す図である。 検証サーバにおける、ＣＲＬの更新処理フローである。 ＣＲＬ情報テーブルの例を示す図である。 検証サーバにおける、公開鍵証明書の検証処理のフローチャートである。 第二の実施例における、検証サーバの構成を示す図である。 検証サーバにおける、セッションプール時の処理シーケンスである。 第三の実施例における、失効情報更新エージェントおよび検証サーバのシステム構成を示す図である。 第三の実施例における、失効情報更新エージェントの構成を示す図である。 第三の実施例における、検証サーバの構成を示す図である。 失効情報更新エージェントにおける、予め設定したタイミングで失効データを取得する、失効データ取得処理のフローチャートである。 失効情報更新エージェントにおける、失効データ取得処理の詳細フローチャートである。 失効情報更新エージェントにおける、認証局からの更新イベントをタイミングとして失効データを取得する、失効データ取得処理のフローチャートである。 失効データテーブルの例を示す図である。 第三の実施例における、検証サーバにおける、公開鍵証明書の検証処理のフローチャートである。 失効情報更新エージェントが存在する場合における、検証サーバ１１のリフレッシュ処理のフローチャートである。

以下、ＰＫＩにおける公開鍵証明書の有効性確認の検証処理に係る失効情報取得方法を実施例として説明する。本発明の実施例について、図面を参照して詳細に説明する。

なお、これらの実施例によって本発明が限定されるものではない。ＰＫＩの公開鍵証明書の有効性確認の検証だけでなく、オンラインでＩＣカードの失効情報を確認するシステムなどにも適用できる。

最初に、本実施例の説明で用いる用語について解説する。ＰＫＩ技術において、電子データの送信者の電子署名には、送信者の秘密鍵が用いられる。その送信者の秘密鍵と対をなす公開鍵を認証局が証明し、署名した証明書が公開鍵証明書である。公開鍵証明書への認証局による署名には、認証局の秘密鍵が用いられ、その認証局の秘密鍵と対をなす公開鍵に対して他の認証局が証明した公開鍵証明書を、認証局証明書と呼ぶ。本実施形態には、公開鍵証明書の失効情報を確認し、公開鍵証明書の有効性を検証する検証サーバがある。失効情報は、検証結果に検証サーバの秘密鍵を用いて署名した検証応答として利用者に提供される。検証サーバの秘密鍵と対をなす公開鍵を認証局が証明し、署名した証明書も公開鍵証明書である。この検証サーバの秘密鍵と対をなす公開鍵の公開鍵証明書を検証サーバ証明書と呼ぶ。以上のように、公開鍵証明書、認証局証明書、検証サーバ証明書は、公開鍵に係わる情報に署名が付されたものであるが、これらの証明書には、以下の説明から明らかになる認証局を特定する情報としての認証局名や、シリアルナンバーなどの公開鍵証明書を特定する情報や、各々が証明する端末装置、認証局、検証サーバに関する情報も含まれる。

図１は、本発明の第一の実施例における検証システムの全体構成例を示す図である。検証システムは、公開鍵証明書の有効性を検証する検証サーバ１１と、電子的に手続き（電子データの送信など）を実行する複数の端末装置１２₁〜１２_m（以下、特定しない場合は端末装置１２とする）と、公開鍵証明書を発行および失効させ、発行した公開鍵証明書の失効情報（ＣＲＬ１６）を発行する認証局１３₁〜１３_n（以下、特定しない場合は認証局１３とする）と、それぞれを接続するインターネット等のネットワーク１４を有する。そして、端末装置１２は、公開鍵証明書の検証を依頼するために検証要求１５を検証サーバ１１へ送信し、証明書の検証結果を検証応答として受信する。また、検証サーバ１１は、認証局１３の発行するＣＲＬと、認証局１３の保持する失効データ１７を取得する。

図２は、検証サーバ１１の構成を示す図である。検証サーバ１１は、処理部２０ａと、記憶部２０ｂと、ネットワーク１４を介して他の装置と通信するための通信部２０ｃと、各種証明書等の入出力や、検証サーバ１１の管理者からの指示を受け付ける入出力部２０ｄとを有する。

処理部２０ａは、管理部２１と、失効情報管理部２２と、検証処理を行う検証処理部２３と、検証サーバ１１の各部を制御する制御部２４とを有する。

記憶部２０ｂは、検証サーバ１１の各種設定を保持する設定情報保持部２５と、失効情報保持部２６と、検証サーバ証明書を保持する検証サーバ証明書保持部２７と、検証サーバ１１の秘密鍵を保持する鍵保持部２８とを有する。

管理部２１は、ＣＲＬ更新タイミング等の各種設定情報を、設定情報保持部２５へ登録する。検証サーバ１１の管理者は、予めＣＲＬ１６の更新タイミングの設定を行う。具体的には、検証サーバ１１が対応する認証局ごとに、ＣＲＬ１６を更新するタイミングを、入出力部２０ｄを介して入力し、検証サーバ１１の管理部２１がこのＣＲＬ更新タイミングを設定情報保持部２５へ登録する。

失効情報管理部２２は、通信部２０ｃを介して認証局１３へアクセスしＣＲＬ１６を取得するＣＲＬ取得機能２２０と、検証サーバ１１が対応する複数の認証局１３への接続に対応するＣＡ振分け機能２２１と、認証局１３等の、検証サーバ１１外部の装置が具備するデータベース（以下、「ＤＢ」という）へ直接アクセスし失効データ１７を取得する外部ＤＢ参照機能２２２と、取得したＣＲＬ１６から後述するＣＲＬ情報テーブル８０を作成、更新するなど、失効情報等のデータの書き込みを処理するファイル書込み機能２２３とを有する。

ＣＲＬ取得機能２２０は、設定情報保持部２５に設定されたＣＲＬ更新タイミングに従ってＣＲＬ１６を取得し、後述するＣＲＬ情報保持部２６１に保持されるＣＲＬ情報テーブル８０を更新する。

ＣＡ振分け機能２２１は、後述する認証局情報保持部２６０に保持される認証局識別テーブル６０に設定されたＣＲＬ取得先情報や、失効データ取得先情報を用いて接続先の認証局１３を決定する。

外部ＤＢ参照機能２２２は、ＣＡ振分け機能２２１によって決定された認証局１３のＤＢに対し接続を行い、失効データ１７を取得する。失効データ１７には、失効した公開鍵証明書を識別する情報と、公開鍵証明書を発行した認証局を識別する情報を含む。

ファイル書込み機能２２３は、認証局情報保持部２６０に保持される認証局識別テーブル６０や、ＣＲＬ情報保持部２６１に保持されるＣＲＬ情報テーブル８０等、検証サーバ１１の保持する各テーブルに対応するデータを書き込み、テーブルの作成、更新を行う。

検証処理部２３は、端末装置１２から通信部２０ｃを介して検証要求１５を受け付けると、ＣＲＬ情報テーブル８０を参照して検証要求された検証対象証明書が失効しているか否かを確認する。そして、ＣＲＬ情報テーブル８０に検証対象証明書のシリアルナンバーが存在しない場合には、ＣＡ振分け機能２２１により認証局識別テーブル６０を参照し、外部ＤＢ参照機能２２２を用いて認証局１３から直接失効データ１７を取得して、検証対象証明書の有効性を確認する。そのようにして検証結果を作成し、検証処理部２３は、検証要求１５に対応する検証サーバ証明書を検証サーバ証明書保持部２７から取得し、鍵保持部２８に保持される、検証サーバ１１の秘密鍵を用いて検証結果に署名を付与する。署名が付与された検証結果と、検証サーバ証明書は、通信部２０ｃを介して端末装置１２へ送信される。

失効情報保持部２６は、認証局識別テーブル６０を保持する認証局情報保持部２６０と、ＣＲＬ情報テーブル８０を保持するＣＲＬ情報保持部２６１とを有する。検証サーバ１１が複数の認証局１３に対応する（複数の認証局１３が発行するＣＲＬ１６を取り込む）場合、各テーブルは、認証局識別子を用いて認証局１３を識別できるように保持される。認証局識別子には、例えば、認証局の名前データと公開鍵データを、端末装置１２が使用するハッシュアルゴリズムでそれぞれハッシュ計算して得られる情報等が用いられる。

図３は、端末装置１２の構成を示す。端末装置１２₁は、処理部３０ａと、記憶部３０ｂと、ネットワーク１４を介して他の装置と通信するための通信部３０ｃと、端末装置１２₁のユーザが作成した電子文書や他の端末装置１２₂から受け取った電子文書の入出力やユーザからの指示を受け付ける入出力部３０ｄとを有する。

以下の端末装置１２₁の説明では、説明を分かり易くするために、端末装置１２₁のユーザが作成した電子文書を他の端末装置１２₂へ送信するときに添付する公開鍵証明書を自公開鍵証明書、他の端末装置１２₂から受信した電子文書に添付されている公開鍵証明書を他公開鍵証明書と呼ぶ。

処理部３０ａは、端末装置１２₁の秘密鍵を用いて電子文書に署名を付与した署名付き電子文書を作成する署名付き文書作成部３１と、他の端末装置１２₂からの署名付き電子文書の署名および他公開鍵証明書の検証を行う署名・証明書検証部３２と、端末装置１２₁の各部を制御する制御部３３を有する。

記憶部３０ｂは、ユーザが作成した電子文書を保持する電子文書保持部３４と、署名を生成するための秘密鍵と、この秘密鍵と対をなす公開鍵について、認証局１３に証明されて発行された自公開鍵証明書と、この端末装置１２₁が利用する認証局１３の認証局証明書とを保持する鍵保持部３５と、他の端末装置１２₂から受け取った署名付き電子文書と他公開鍵証明書を保持する検証対象保持部３６を有する。

制御部３３は、入出力部３０ｄを介して端末装置１２₁を利用するユーザから、他ユーザの端末装置１２₂へ、電子文書保持部３４に保持している電子文書の送信指示を受け付ける。送信の指示に対応して、制御部３３は、指定された電子文書を電子文書保持部３４から読み出し、これを署名付き文書作成部３１へ渡す。署名付き文書作成部３１は、鍵保持部３５に保持されている秘密鍵を用いて、渡された電子文書に対する署名を生成し、電子文書に生成した署名を付与した署名付き電子文書を作成する。制御部３３は、通信部３０ｃを介して、署名付き文書作成部３１で生成された署名付き電子文書と、鍵保持部３５に保持されている自公開鍵証明書とをユーザから指示された送信先の端末装置１２₂へ送信する。

また、制御部３３は、通信部３０ｃを介して、他の端末装置１２₂から署名付き電子文書と他公開鍵証明書を受け取ると、これらを関連付けて検証対象保持部３６に保持させると共に、これらの検証を署名・証明書検証部３２に要求する。

署名・証明書検証部３２は、検証対象保持部３６に保持されている署名付き電子文書の署名を、関連付けて保持されている他公開鍵証明書を用いて検証する。そして、署名・証明書検証部３２は、署名付き電子文書の署名の検証に使用した他公開鍵証明書を検証対象証明書として、鍵保持部３５に保持する認証局１３の認証局証明書を用いて検証する。署名・証明書検証部３２は、検証対象証明書の署名の検証および、検証対象証明書の有効期間が切れていないことの確認、検証対象証明書が失効しているかどうかの確認など検証処理を実行する。

署名・証明書検証部３２は、検証対象証明書（検証対象の他公開鍵証明書）が失効しているかどうかを確認するために、検証サーバ１１に検証要求１５を送信する。署名・証明書検証部３２は、検証サーバ１１から検証対象証明書が失効していないとの検証結果の受信を含めて、検証処理に成功した場合に、この検証対象証明書は有効であり、この検証対象証明書が添付されていた署名付き電子文書が正当なものであるとして、必要に応じて入出力部３０ｄを介して署名付き電子文書の署名および検証対象証明書の検証結果を出力する。

図４は、認証局１３の構成を示す図である。認証局１３は、処理部４０ａと、記憶部４０ｂと、ネットワーク１４を介して他の装置と通信するための通信部４０ｃと、各種証明書等の入出力や、この認証局１３の操作者からの指示の受け付けや、処理結果の出力を行う入出力部４０ｄとを有する。

処理部４０ａは、公開鍵証明書を発行する発行部４１と、発行部４１が発行した公開鍵証明書を管理する管理部４２と、認証局１３の各部を制御する制御部４３とを有する。

記憶部４０ｂは、発行部４１が発行した公開鍵証明書を保持する証明書保持部４４と、証明書保持部４４に保持されている各公開鍵証明書の発行先が記述されている発行先管理リストを保持する発行先管理リスト保持部４５と、公開鍵証明書の失効情報が記述されているＣＲＬ１６を保持するＣＲＬ保持部４６と、前回ＣＲＬ１６発行後に公開鍵証明書の失効依頼を受け付け、発行済みＣＲＬ１６にはシリアルナンバーが未記載の、失効済み公開鍵証明書の情報を保持する失効データ保持部４７とを有する。

認証局１３は、公開鍵証明書の発行依頼を受け付け、発行依頼に対応する公開鍵証明書を作成し、認証局１３の秘密鍵を用いて作成した公開鍵証明書に署名をする。そして、作成した公開鍵証明書を入出力部４０ｄまたは通信部４０ｃを介して、郵送あるいは通信により発行依頼元へ渡す。

管理部４２は、公開鍵証明書の失効依頼を受け付けると、失効対象の公開鍵証明書を証明書保持部４４から削除すると共に、この公開鍵証明書の発行先の情報を発行先管理リスト保持部４５に保持されている発行先管理リストから削除する。そして、管理部４２は、証明書保持部４４から削除した公開鍵証明書のシリアルナンバーを、次にＣＲＬ１６を発行するまで失効データ保持部４７に保持する。管理部４２は、定期的にＣＲＬ１６を作成し、認証局１３の秘密鍵を用いてＣＲＬ１６に署名を付与して、署名を付与したＣＲＬ１６をＣＲＬ保持部４６に保持する。制御部４３は、通信部４０ｃを介して、検証サーバ１１等の他の装置よりＣＲＬ取得要求を受け付けると、ＣＲＬ保持部４６に保持されているＣＲＬ１６を、通信部４０ｃを介して、ＣＲＬ取得要求を発行した他の装置に送信する。また、署名を付与したＣＲＬ１６は、外部リポジトリなどのＤＢに格納されてもよく、検証サーバ１１等は、ＣＲＬ取得要求をリポジトリに対して行い、リポジトリからＣＲＬ１６を取得してもよい。

図５は、検証サーバ１１、端末装置１２、認証局１３の各々のハードウェア構成例を示す図である。検証サーバ１１、端末装置１２、および認証局１３は、各種処理や演算、装置全体の制御等を行うＣＰＵ（Central Processing Unit）５１と、メモリ５２と、各種プログラムおよびデータを記憶するハードディスク等の外部記憶装置５３と、通信ネットワーク１４を介して他装置と通信を行うための通信装置５４と、キーボードやボタン等の入力装置５５と、モニタやプリンタ等の出力装置５６と、ＣＤ−ＲＯＭやＵＳＢ等の可搬性を有する記憶媒体５８から情報を読み取る読取装置５７と、これらの各装置間のデータ送受を行う内部通信線（例えば、ＢＵＳ）５０とを備えた、一般的なコンピュータ（電子計算機）である。ＣＰＵ５１は、外部記憶装置５３から各種プログラムをメモリ５２にロードし、所定のプログラムを実行することにより上術の各処理部を実現する。すなはち、処理部２０ａ、３０ａ、４０ａは、ＣＰＵ５１の処理プロセスとして実現され、記憶部２０ｂ、３０ｂ、４０ｂは、ＣＰＵ５１がメモリ５２や外部記憶装置５３を利用することにより実現される。また、通信部２０ｃ、３０ｃ、４０ｃは、ＣＰＵ５１が通信装置５４を利用することにより実現され、入出力部２０ｄ、３０ｄ、４０ｄは、ＣＰＵ５１が入力装置５５や出力装置５６や読取装置５７を利用することにより実現される。各処理部を実現する所定のプログラムは、予め外部記憶装置５３に格納されていても良いし、電子計算機が利用可能な可搬性を有する記憶媒体５８に格納されており読取装置５７を介して必要に応じて読み出されても良いし、あるいは、電子計算機が利用可能な通信媒体であるネットワークまたはネットワーク上を伝搬する搬送波を利用する通信装置５４と接続された他の装置から必要に応じてダウンロードされて外部記憶装置５３に格納されるものであっても良い。

図６は、検証サーバ１１の認証局情報保持部２６０に設ける認証局識別テーブル６０の例を示す図である。認証局識別テーブル６０は、認証局６１に対応して、複数の認証局に対応する場合に認証局を識別するための認証局識別子６２と、ＣＲＬ１６が保持されている場所や取得方法を示すＣＲＬ取得先情報６３と、失効データ１７が保持されている場所や取得方法を示す失効データ取得先情報６４とが格納される。認証局識別子６２は、例えば、認証局の名前データと公開鍵データを、ハッシュアルゴリズムでそれぞれハッシュ計算して得られる情報等を認証局識別子６２として用い、ＣＲＬ情報テーブル８０や失効データテーブル９０等、検証サーバ１１内部の情報を検索する際の識別子とする。

認証局識別テーブル６０は、管理者によって入出力部２０ｄを介して入力されるか、もしくは、管理部２１によって次のように作成される。管理者は、検証サーバ１１が対応する認証局の名前を認証局識別テーブル６０の認証局６１の行に記述する。もしくは、管理部２１が、設定情報保持部２５に保持されている認証局証明書を取得し、取得した認証局証明書の名前を認証局識別テーブル６０の認証局６１の行に記述する。次に、認証局証明書に記述される、認証局の名前データならびに公開鍵データのハッシュ値を計算して得られる情報を認証局識別子として、対応する認証局６１の認証局識別子６２欄に記述する。さらに、ＣＲＬ１６を入手するための情報として、ＣＲＬ１６を配布するＵＲＩ（Uniform Resource Identifier）等を該当の認証局６１のＣＲＬ取得先情報６３欄に記述する。同様に、失効データ１７を入手するための情報を該当の認証局６１の失効データ取得先情報６４欄に記述する。

図７は、検証サーバ１１のＣＲＬ取得機能２２０が実行するＣＲＬ更新処理のフローチャートを示す図である。

検証サーバ１１のＣＲＬ取得機能２２０は、設定情報保持部２５に予め設定されたＣＲＬ更新タイミング（例えば１日）を取得し、ＣＲＬ１６を以前に取得した日時から、ＣＲＬ更新タイミングを経過している認証局が存在するかを確認する（ステップ７０１）。ＣＲＬ更新タイミングを経過している認証局が存在する場合、ＣＲＬ取得機能２２０は、ＣＡ振分け機能２２１により、認証局識別テーブル６０から該当の認証局のＣＲＬ取得先情報６３を取得する（ステップ７０２）。そしてＣＲＬ取得機能２２０は、取得したＣＲＬ取得先情報６３に基づいて、通信部２０ｃを介してＣＲＬ取得要求を当該認証局１３へ送信する（ステップ７０３）。認証局１３は、ＣＲＬ取得要求を受信する（ステップ７０４）と、認証局１３のＣＲＬ保持部４６に保持されるＣＲＬ１６を検証サーバ１１へ送信する（ステップ７０５）。このＣＲＬ１６には、ＣＲＬ１６を作成した時点の、認証局１３の名前、認証局１３の鍵情報、認証局１３が発行した有効期間内の公開鍵証明書のうち失効した公開鍵証明書のシリアルナンバー、ＣＲＬ１６の有効期間（今回更新日時（thisUpdate）、次回更新日時（nextUpdate））等が記載されている。検証サーバ１１の失効情報管理部２２は、認証局１３からのＣＲＬ１６を受信する（ステップ７０６）と、認証局証明書を用いてＣＲＬ１６に記載されている認証局の署名を確認し（ステップ７０７）、ＣＲＬ情報テーブル８０を参照して、受信したＣＲＬ１６が既に取得しているＣＲＬ１６より更新されているかどうかを確認する（ステップ７０８）。ＣＲＬ１６には、認証局１３によるＣＲＬ１６の作成日時が記載されているため、認証局１３から受信したＣＲＬ１６の作成日時（thisUpdate）が前回取得したＣＲＬ１６の作成日時よりも新しくなっていた場合、認証局１３のＣＲＬ１６が更新されていると判断し、ステップ７０９へ進む。受信した認証局１３のＣＲＬ１６が更新されていなかった場合、ステップ７０１へ進む。なお、認証局１３から初めてＣＲＬ１６を受信する場合は、ステップ７０９へ進む。次に、検証サーバ１１の失効情報管理部２２のファイル書込み機能２２３は、受信したＣＲＬ１６の認証局識別子をキーとして、ＣＲＬ情報テーブル８０の作成または更新を行い、取得したＣＲＬ１６の情報をＣＲＬ情報保持部２６１へ格納する（ステップ７０９）。これらステップ７０１からステップ７０９の処理を、ＣＲＬ更新タイミングの経過している認証局１３全てに行う。また、設定情報保持部２５に設定されるＣＲＬ更新タイミングは、認証局１３ごとに設定してもよいし、検証サーバ１１が対応する認証局１３全てに対して一つを設定してもよい。

図８は、ＣＲＬ情報テーブル８０の例を示す図である。ＣＲＬ情報テーブル８０は、取得したＣＲＬ１６に記載されている情報を元に、認証局識別子８１に対応して、thisUpdateならびにnextUpdateからなるＣＲＬ有効期間８２と、失効した証明書のシリアルナンバー８３と、証明書の失効日時８４と、証明書の失効理由８５とが格納される。

ＣＲＬ情報テーブル８０は、次のように作成または更新する。検証サーバ１１の失効情報管理部２２のファイル書込み機能２２３は、取得したＣＲＬ１６に記述される認証局の名前データならびに公開鍵データのハッシュ値を計算し得られる認証局識別子を、ＣＲＬ情報テーブル８０の認証局識別子８１欄から検索する。なお、同じ認証局識別子が存在しない場合には、ファイル書込み機能２２３は、取得したＣＲＬ１６が、新たに認証局識別テーブル６０に登録した認証局１３のＣＲＬ１６であると判断し、ＣＲＬ情報テーブル８０の認証局識別子８１欄へ、求めた認証局識別子を新たに追加する。次に、ファイル書込み機能２２３は、認証局識別子８１に対応する、ＣＲＬ有効期間８２欄へ、有効期間（thisUpdate、nextUpdate）を記述または更新する。次に、ファイル書込み機能２２３は、認証局識別子８１に対応する、失効した証明書のシリアルナンバー８３欄へ、ＣＲＬ１６に記述されている失効した公開鍵証明書のシリアルナンバーを登録し、証明書の失効日時８４欄へ、失効公開鍵証明書の失効日時を登録し、証明書の失効理由８５欄へ、公開鍵証明書の該当する失効理由を登録する。なお、失効理由は、その番号に対応する意味がＲＦＣ５２８０で規定されている。

図９は、検証サーバ１１が実行する公開鍵証明書の検証処理のフローチャートを示す図である。

端末装置１２₁の署名・証明書検証部３２は、他の端末装置１２₂からの電子文書に添付されていた公開鍵証明書(図２の説明時の他公開鍵証明書)が失効しているかどうかを確認するために、検証要求１５を作成し、通信部３０ｃを介して、検証サーバ１１へ送信する（ステップ１０００）。検証サーバ１１の検証処理部２３は、検証要求１５を受信すると（ステップ１１００）、検証要求１５に含まれるＣｅｒｔＩＤを取得する（ステップ１１０１）。ＣｅｒｔＩＤには、検証対象証明書を発行した認証局の名前情報と、認証局の公開鍵の情報と、検証対象証明書のシリアルナンバー等が含まれる。このうち認証局の名前情報と、認証局の公開鍵の情報とは、認証局の名前データと公開鍵データを、端末装置１２₁が使用するハッシュアルゴリズムでそれぞれハッシュ計算して得られる情報であり、検証サーバ１１がＣＲＬ情報テーブル８０に持つ、認証局識別子８１に対応する。検証処理部２３は、ＣｅｒｔＩＤに指定された認証局識別子をキーとしてＣＲＬ情報テーブル８０を照合し、ＣｅｒｔＩＤに指定された認証局識別子がＣＲＬ情報テーブル８０に存在するかどうかを確認する（ステップ１１０２）。存在しない場合、検証サーバ１１が、この検証要求１５に対応する認証局１３の失効情報を保持していないことを意味するので、検証処理部２３は、検証対象証明書の失効情報（CertStatus）を不明（unknown）とする検証結果データを作成し（ステップ１１０３）、ステップ１１１０へ進む。ＣｅｒｔＩＤに指定された認証局識別子がＣＲＬ情報テーブル８０に存在する場合、検証処理部２３は、ＣＲＬ情報テーブル８０の当該認証局識別子の失効した証明書のシリアルナンバー８３欄に、ＣｅｒｔＩＤに記載された検証対象証明書のシリアルナンバーが存在するかどうかを確認する（ステップ１１０４）。ＣｅｒｔＩＤに記載された検証対象証明書のシリアルナンバーがＣＲＬ情報テーブル８０に存在する場合、検証処理部２３は、検証対象証明書の失効情報（CertStatus）を失効（revoked）とする検証結果データを作成して（ステップ１１０５）、ステップ１１１０に進む。そして、ＣｅｒｔＩＤに記載された検証対象証明書のシリアルナンバーがＣＲＬ情報テーブル８０に存在しない場合、ステップ１１０６へ進む。ここで、検証サーバ１１は、ＣＲＬ１６に記載前の失効している公開鍵証明書の中に検証対象証明書が存在しないか認証局に確認するため、失効データ要求を検証処理部２３から失効情報管理部２２へ送信する（ステップ１１０６）。失効情報管理部２２は、失効データ要求を受信する（ステップ１２００）と、失効情報管理部２２のＣＡ振分け機能２２１が、ステップ１１０２で取得した認証局識別子をキーとして、認証局識別データ６０から当該認証局の失効データ取得先情報６４を取得する（ステップ１２０１）。そして失効情報管理部２２の外部ＤＢ参照機能２２２は、取得した失効データ取得先情報に基づいて、通信部２０ｃを介して失効データ要求を該当認証局１３へ送信する（ステップ１２０２）。そして、認証局１３は失効データ要求を受信し（ステップ１３００）、失効データ保持部４７に保持している失効データ１７を取得し（ステップ１３０１）、失効データ１７を検証サーバ１１へと送信する（ステップ１３０２）。ここで、外部ＤＢ参照機能２２２は、認証局１３に対し、認証局１３の失効データ保持部４７が保持する失効データ全てを要求してもよいし、指定する日時以降に失効された失効データのみを要求するなど、失効データの要求を特定してもよい。検証サーバ１１の外部ＤＢ参照機能２２２は、通信部２０ｃを介して失効データ１７を受信する（ステップ１２０３）と、検証処理部２３へ取得した失効データ１７を送信する（ステップ１２０４）。そして、検証処理部２３は、失効データ１７を取得し（ステップ１１０７）、取得した失効データ１７のシリアルナンバーの中に、ＣｅｒｔＩＤに記載された検証対象証明書のシリアルナンバーが存在するかどうかを確認する（ステップ１１０８）。ＣｅｒｔＩＤに記載された検証対象証明書のシリアルナンバーが、ステップ１１０７で取得した失効データ１７に存在する場合、検証処理部２３は、検証対象証明書の失効情報（CertStatus）を失効（revoked）とする検証結果データを作成し（ステップ１１０５）、ステップ１１１０へ進む。ＣｅｒｔＩＤに記載された検証対象証明書のシリアルナンバーが取得した失効データ１７に存在しない場合、検証処理部２３は、検証対象証明書の失効情報（CertStatus）を有効（good）とする検証結果データを作成して（ステップ１１０９）、ステップ１１１０へ進む。次に、検証処理部２３は、鍵保持部２８に保持されている検証サーバの秘密鍵を取得し（ステップ１１１０）、検証結果データに署名を付与して、署名付きの検証応答を作成する（ステップ１１１１）。そして、検証サーバ１１の処理部２０ａは、通信部２０ｃを介して、作成した検証応答を端末装置１２₁へ送信し（ステップ１１１２）、端末装置１２₁は、ステップ１０００で送信した検証要求に対する検証応答を受信する（ステップ１００１）。

ここで、検証サーバ１１がステップ１１０７で取得した失効データ１７は、一時的な検証にのみ利用するデータとしてメモリ上にのみ保持してもよいし、後述する失効データテーブル９０のようにテーブルとして失効情報保持部２６に保持し、ステップ１１０６のタイミングで認証局１３へ失効データを取得に行く前に、失効データテーブル９０内を確認してもよい。そして、失効データテーブル９０を保持する場合は、後述するリフレッシュ機能２２５（図１４）を検証サーバ１１に持ち、重複データの管理を行う。

以上、本発明の第一の実施例を説明した。本実施例によれば、認証局が複数ある場合であっても、失効した公開鍵証明書がＣＲＬに記載されるまでの期間において、公開鍵証明書の検証を正しく行うことを可能とし、公開鍵証明書が失効されてから、当該公開鍵証明書に対して失効の検証が行われるまでの時間的な遅れを低減することができる。

図１０は、本発明の第二の実施例における検証サーバ１１の構成を示す図である。検証サーバ１１は、第一の実施例と同様に、処理部２０ａと、記憶部２０ｂと、ネットワーク１４を介して他の装置と通信するための通信部２０ｃと、各種証明書等の入出力や、検証サーバ１１の管理者からの指示を受け付ける入出力部２０ｄとを有する。

処理部２０ａは、管理部２１と、失効情報管理部２２と、検証処理部２３と、検証サーバ１１の各部を制御する制御部２４とを有する。

第一の実施例との相違点として、失効情報管理部２２は、複数の認証局１３各々と、ログイン状態を維持したセッションを確立し、そのセッションを保持するセッションプール機能２２４を有する。セッションプール機能２２４は、検証サーバ１１の起動の際に認証局１３とのセッションを確立し、検証サーバ１１の起動中は確立したセッションを保持し続け、検証サーバ１１の終了時にセッションを切断する。

図１１は、セッションプール機能２２４によるセッションプールの際の、検証サーバ１１の起動から停止までのシーケンスである。セッションプールを行うことにより、検証サーバ１１が認証局１３へアクセスする際に発生する処理負荷を軽減することが出来る。

最初に、検証サーバ１１の管理者は、検証サーバ１１に対して起動要求を行う（ステップ８０１）。起動要求を受け付けた検証サーバ１１の制御部２４は、起動処理を行い（ステップ８０２）、検証サーバ１１を起動する。そして、制御部２４は、セッション確立要求をセッションプール機能２２４に送信する（ステップ８０３）。次に、セッションプール機能２２４は、初期化処理を行い（ステップ８０４）、認証局１３に対してログイン要求を行う（ステップ８０５）。認証局１３は、検証サーバ１１に対してユーザ認証を行い（ステップ８０６）、ログイン結果を検証サーバ１１に送信する（ステップ８０７）。そして、セッションプール機能２２４は、認証局１３の失効データ保持部４７のデータを取得できるログイン状態を維持したセッションを確立し、検証サーバ１１の起動中の間、保持し続ける。また、検証サーバ１１の対応する認証局１３が複数あった場合には、セッションプール機能２２４は、認証局１３ごとにそれぞれログイン状態を維持したセッションを確立し、そのセッションを保持する。

ここで、図９で示した検証サーバ１１における公開鍵証明書の検証処理のステップ１２０２のタイミングで、検証サーバ１１の外部ＤＢ参照機能２２２は、ＣＡ振分け機能２２１により取得した、検証対象証明書の失効データ取得先情報６４と失効データ要求をセッションプール機能２２４に送信する（ステップ８０８）。セッションプール機能２２４は、受信した失効データ取得先情報に該当する認証局１３に、保持しているセッションの一つを利用して失効データ要求を送信する（ステップ８０９）。認証局１３は、失効データ保持部４７に保持している失効データを取得し（ステップ８１０）、検証サーバ１１のセッションプール機能２２４へ失効データを送信する（ステップ８１１）。失効データを受信したセッションプール機能２２４は、取得した失効データを外部ＤＢ参照機能２２２に送信する（ステップ８１２）。失効データを取得した外部ＤＢ参照機能２２２は、検証処理のステップ１２０４へ戻る。図１１の点線部分は、ステップ１２０２〜ステップ１２０４に対応し、検証処理が行われるたびに実行される。

最後に、検証サーバ１１を停止する際に、管理者は停止要求を検証サーバ１１へと送信する（ステップ８１３）。停止要求を受け付けた検証サーバ１１の制御部２４は、セッション切断要求をセッションプール機能２２４に送信する（ステップ８１４）。次に、セッションプール機能２２４は、認証局１３に対してログアウト要求を行う（ステップ８１５）。認証局１３は、ログアウトを行い、ログアウト結果を検証サーバ１１に送信する（ステップ８１６）。次にセッションプール機能２２４は、終了処理を行い（ステップ８１７）、切断結果を制御部２４に送信する（ステップ８１８）。制御部は、サーバの停止処理を行い、検証サーバ１１を停止させる（ステップ８１９）。

以上、本発明の第二の実施例を説明した。本実施例によれば、認証局が複数ある場合であっても、失効の検証が行われるまでの時間的な遅れを低減し、かつ、セッションをプールすることにより検証サーバ１１のアクセス処理の負荷を軽減して公開鍵証明書の有効性確認処理を効率的に行うことができる。

本発明の第三の実施例では、第一の実施例、第二の実施例で述べた機能の一部を失効情報更新エージェント（中継サーバ）１８として、別の装置として認証局１３と検証サーバ１１の間に構築し、失効データ取得などの処理を検証サーバ１１の代わりに実施する事により、検証サーバ１１の処理負荷を少なくする例である。

図１２は、本発明の第三の実施例における検証システムの全体構成例を示す図である。図１で示した全体構成例に加え、失効情報更新エージェント１８を有する。失効情報更新エージェント１８は、認証局１３の保持する失効データ１７を取得し、検証サーバ１１へ送信済みのデータとの差分失効データ１９を作成し、検証サーバ１１へ送信する。

図１３は、失効情報更新エージェント１８の構成を示す図である。失効情報更新エージェント１８は、処理部７０ａと、記憶部７０ｂと、ネットワーク１４を介して他の装置と通信するための通信部７０ｃと、管理者が設定情報を入力し、確認するための入出力部７０ｄとを有する。

処理部７０ａは、第二の実施例のセッションプール機能２２４と同様に、失効情報更新エージェント１８と認証局１３とのログイン状態を維持したセッションを複数確立し、そのセッションを保持するセッションプール機能７１と、通信部７０ｃを介して認証局１３等の外部装置のＤＢへ直接アクセスし失効データ１７を取得する外部ＤＢ参照機能７２と、取得した失効データ１７をその時点より前に送信したデータと比較して、未送信のデータのみを抽出した差分失効データ１９を作成する差分作成機能７３と、ＣＡ振分け機能７６とを有する。

失効情報更新エージェント１８は、認証局１３ごとに構築してもよいし、複数の認証局１３に対して１台の失効情報更新エージェント１８を構築してもよい。複数の認証局１３に対して１台の失効情報更新エージェント１８を構築する場合には、複数の認証局１３への接続に対応するためのＣＡ振分け機能７６を失効情報更新エージェント１８が持つ。

記憶部７０ｂは、前述した認証局識別テーブル６０を保持する認証局情報保持部７４と、以前に検証サーバ１１へと送信済みの失効データ１７の情報を保持する送信済み失効データ保持部７５とを有する。

失効情報更新エージェント１８は、図５で示すハードウェア構成例と同様である。

また、認証局１３等の外部装置のＤＢへ直接アクセスし失効データ１７を取得する外部ＤＢ参照機能７２は、失効情報データを取得するタイミングを、予め記憶部７０ｂに設定してもよいし、認証局１３が新しい失効データ１７を生成すると同時に失効情報更新エージェント１８に対して更新イベントを送信するように構築し、更新イベントのタイミングに合せて失効データ１７を取得してもよい。

図１４は、本発明の第三の実施例における検証サーバ１１の構成を示す図である。検証サーバ１１は、第一の実施例と同様に、処理部２０ａと、記憶部２０ｂと、ネットワーク１４を介して他の装置と通信するための通信部２０ｃと、各種証明書等の入出力や、検証サーバ１１の管理者からの指示を受け付ける入出力部２０ｄとを有する。

第一の実施例との相違点として、失効情報管理部２２は、検証サーバ１１がＣＲＬ１６を取得したタイミングで、検証サーバ１１が取得し失効データ保持部２６２に保持している失効データをと、取得したＣＲＬ１６とを比較し、ＣＲＬ１６に記載された公開鍵証明書のシリアルナンバーを失効データ保持部２６２から消去するリフレッシュ機能２２５とを有する。

また、記憶部２０ｂは、第一の実施例で示した構成に加えて、失効情報更新エージェント１８から受信した差分失効データ１９を保持する失効データ保持部２６２を有する。

図１５、および図１６は、予め設定した取得タイミングで失効データ１７を取得する場合の、失効情報更新エージェント１８の失効データ取得処理のフローチャートを示す図である。

失効情報更新エージェント１８は、第二の実施例と同様に、セッションプール機能７１を用いて、失効情報更新エージェント１８の起動時から認証局１３とのログイン状態を維持したセッションを確立し、そのセッションを保持する。失効情報更新エージェント１８が複数の認証局１３に対応している場合は、各認証局１３とログイン状態を維持したセッションを確立し、そのセッションを保持する。

失効情報更新エージェント１８の処理部７０ａは、記憶部７０ｂに予め設定された失効データ取得タイミング（例えば１時間に１回）を取得し、以前に失効データ１７を取得した日時から、失効データ取得タイミングを経過したかを確認する（ステップ２１０１）。失効データ取得タイミングを経過している場合、ＣＡ振分け機能７６は、認証局情報保持部７４に保持する、認証局情報テーブル６０から一つ目の認証局識別子６２に対して、接続先の該当の認証局１３の失効データ取得先情報を取得し（ステップ２１０２）、図１６のＡに進む。

失効データ取得先情報を取得した失効情報更新エージェント１８は、予め、セッションプール機能７１によって、実施例２と同様にプールされたセッションを用いて、通信部２０ｃを介して失効データ要求を該当認証局１３へ送信する（ステップ２１０４）。認証局１３は、失効データ要求を受信し（ステップ２２００）、記憶部４０ｂの失効データ保持部４７に保持されている失効データ１７を取得し（ステップ２２０１）、失効情報更新エージェント１８へ失効データ１７を送信する（ステップ２２０２）。ここで、失効情報更新エージェント１８は、認証局１３に対し、認証局１３の失効データ保持部４７が保持する失効データ全てを要求してもよいし、指定する日時以降に失効された失効データのみを要求するなど、失効データの要求を特定してもよい。失効情報更新エージェント１８は、通信部７０ｃを介して失効データ１７を受信する（ステップ２１０５）。そして、失効情報更新エージェント１８の差分作成機能７３は、送信済み失効データ保持部７５に保持している、以前に検証サーバ１１へ送信した失効データの情報と、取得した失効データ１７を比較する（ステップ２１０６）。そして、失効情報更新エージェント１８は、取得した失効データ１７が検証サーバ１１へ未送信であるかを確認する（ステップ２１０７）。差分作成機能７３は、取得した失効データ１７のシリアルナンバーを一つずつ、送信済み失効データ保持部７５に保持されているシリアルナンバーと比較していく。取得した失効データ１７のシリアルナンバーのすべてが、送信済み失効データ保持部７５に保持されているデータの中に存在する場合、失効データ１７は検証サーバ１１へ未送信のデータが無いと判断し、Ｂへ進む。取得した失効データ１７のシリアルナンバーのうち、送信済み失効データ保持部７５に保持されているデータの中に同じシリアルナンバーが一つでも存在しない場合、ステップ２１０９へ進む。差分作成機能７３は、送信済み失効データ保持部７５に保持されていなかったシリアルナンバーに関する失効データのみを抽出し、差分失効データ１９を作成する（ステップ２１０８）。処理部７０ａは、作成した差分失効データ１９を送信済み失効データ保持部７５に新たに保存する（ステップ２１０９）。処理部７０ａは、通信部７０ｃを介して、作成した差分失効データ１９を検証サーバ１１に送信する（ステップ２１１０）。検証サーバ１１は、通信部２０ｃを介して、差分失効データ１９を受信し（ステップ２０００）、処理部２０ａのファイル書込み機能２２２は、受信した差分失効データ１９を、記憶部２０ｂの失効データ保持部２６２へと書き込み、後述する失効データテーブル９０を更新する（ステップ２００１）。次に、検証サーバ１１の処理部２０ａは、差分失効データ格納完了通知を失効情報更新エージェント１８に送信する（ステップ２００２）。失効情報更新エージェント１８は、差分失効データ格納完了通知を受信し（ステップ２１１１）、Ｂへ進む。

失効情報更新エージェント１８の処理部７０ａは、認証局情報保持部７４に保持される、認証局識別テーブル６０を参照し、記載されている認証局識別子６２の全てに対して、失効データ１７を取得したかを確認する（ステップ２１０３）。認証局識別テーブル６０に未アクセスの認証局識別子６２が存在する場合、処理部７０ａは、認証局識別テーブル６０の次の認証局識別子６２を取得し、ステップ２１０２へ進む。全ての認証局識別子６２に対応した場合、失効情報更新エージェント１８の失効データ取得処理は終了する。

また、記憶部７０ｂに保持される失効データ取得タイミングは、認証局１３ごとに個別の間隔を設定してもよく、個別に設定する場合は、ステップ２１０１とステップ２１０２の処理順序は逆となる。

図１７は、認証局１３が新しい失効データ１７を生成すると同時に失効情報更新エージェント１８に対して更新イベントを送信し、失効情報更新エージェント１８が更新イベントのタイミングに合せて失効データ１７を取得する場合の、失効データ取得処理のフローチャートを示す図である。

認証局１３は、公開鍵証明書の失効要求を受付け、公開鍵証明書を失効すると、記憶部４０ｂの失効データ保持部４７に、ＣＲＬ１６記載前の失効データを保持する。そのタイミングで、認証局１３は、失効データの更新イベントを、自身が対応する失効情報更新エージェント１８に送信する（ステップ２２０３）。失効情報更新エージェント１８は、その失効データの更新イベントを受信する（ステップ２１１２）。失効情報更新エージェント１８のＣＡ振分け機能７６は、更新イベントを送信してきた認証局１３の認証局識別子を取得して、認証局情報保持部７４に保持する認証局識別テーブル６０から該当の認証局１３の失効データ取得先情報６４を取得し（ステップ２１１３）、図１６のＡへ進む。そして、図１６のステップ２１０４〜ステップ２１１１を行い、図１７のＢへ戻ると失効データ取得処理を終了する。

図１８は、失効データテーブル９０の例を示す図である。失効データテーブル９０は、取得した差分失効データ１９に記載されている情報を元に、認証局識別子９１に対応して、失効した証明書のシリアルナンバー９２と、証明書の失効日時９３と、証明書の失効理由９４とが格納される。

失効データテーブル９０は、次のように作成または更新する。検証サーバ１１の失効情報管理部２２のファイル書込み機能２２３は、失効情報更新エージェント１８から受信した、差分失効データ１９に記述される、認証局の名前データならびに公開鍵データのハッシュ値を計算して、認証局識別テーブル６０に登録されている認証局識別子６２を求める。そして、求めた認証局識別子をキーにして、失効データテーブル９０の認証局識別子９１欄から同じ認証局識別子を検索する。次に、ファイル書込み機能２２３は、認証局識別子９１に対応する、失効した証明書のシリアルナンバー９２欄へ、差分失効データ１９に記述されている失効した公開鍵証明書のシリアルナンバーを登録し、証明書の失効日時９３欄へ、失効した公開鍵証明書の失効日時を登録し、証明書の失効理由９４欄へ、公開鍵証明書の該当する失効理由を登録する。なお、失効理由は、その番号に対応する意味がＲＦＣ５２８０で規定されている。

ここで、失効データテーブル９０を検証サーバ１１で保持する場合、ＣＲＬが発行されるたびにＣＲＬ情報テーブル８０と失効データテーブル９０に重複するデータが存在するようになってしまう。ＣＲＬ情報テーブル８０と失効情報テーブル９０に重複するデータが存在してしまうと、検証処理時に後述するステップ４１０４およびステップ４１０６で同じ情報をチェックしてしまうため、図２０で示すリフレッシュ機能２２５が必要である。

図１９は、第三の実施例における、検証サーバ１１が実行する、公開鍵証明書の検証処理のフローチャートを示す図である。

端末装置１２の署名・証明書検証部３２は、他の端末装置１２からの電子文書に添付されていた公開鍵証明書(図２の説明時の他公開鍵証明書)が失効しているかどうかを確認するために、検証要求１５を作成し、通信部３０ｃを介して、検証サーバ１１へ送信する（ステップ４１００）。検証サーバ１１の検証処理部２３は、検証要求１５を受信すると（ステップ４１００）、検証要求１５に含まれるＣｅｒｔＩＤを取得する（ステップ４１０１）。ＣｅｒｔＩＤには、検証対象証明書を発行した認証局の名前情報と、認証局の公開鍵の情報と、検証対象証明書のシリアルナンバー等が含まれる。このうち認証局の名前情報と、認証局の公開鍵の情報とは、認証局の名前データと公開鍵データを、端末装置が使用するハッシュアルゴリズムでそれぞれハッシュ計算して得られる情報であり、検証サーバ１１がＣＲＬ情報テーブル８０に持つ、認証局識別子８１に対応する。検証処理部２３は、ＣｅｒｔＩＤに指定された認証局識別子をキーとしてＣＲＬ情報テーブル８０を照合し、ＣｅｒｔＩＤに指定された認証局識別子がＣＲＬ情報テーブル８０に存在するかどうかを確認する（ステップ４１０２）。存在しない場合、検証サーバ１１が、この検証要求１５に対応する失効情報を保持していないことを意味するので、検証処理部２３は、検証対象証明書の失効情報（CertStatus）を不明（unknown）とする検証結果データを作成し（ステップ４１０３）、ステップ４１０８へ進む。ＣｅｒｔＩＤに指定された認証局識別子がＣＲＬ情報テーブル８０に存在する場合、検証処理部２３は、ＣＲＬ情報テーブル８０の当該認証局識別子の失効した証明書のシリアルナンバー８３欄に、ＣｅｒｔＩＤに記載された検証対象証明書のシリアルナンバーが存在するかどうかを確認する（ステップ４１０４）。ＣｅｒｔＩＤに記載された検証対象証明書のシリアルナンバーがＣＲＬ情報テーブル８０に存在する場合、検証処理部２３は、検証対象証明書の失効情報（CertStatus）を失効（revoked）とする検証結果データを作成して（ステップ４１０５）、ステップ４１０８に進む。そして、ＣｅｒｔＩＤに記載された検証対象証明書のシリアルナンバーがＣＲＬ情報テーブル８０に存在しない場合、ステップ４１０６へ進む。次に、検証処理部２３は、ステップ４１０２で取得した認証局識別子をキーとして、失効データ保持部２６２に保持される失効データテーブル９０を照合し、認証局識別子に対応する失効した証明書のシリアルナンバー９２に、ＣｅｒｔＩＤに記載された検証対象証明書のシリアルナンバーが存在するかどうかを確認する（ステップ４１０６）。ＣｅｒｔＩＤに記載された検証対象証明書のシリアルナンバーが失効データテーブル９０に存在する場合、検証処理部２３は、検証対象証明書の失効情報（CertStatus）を失効（revoked）とする検証結果データを作成し（ステップ４１０５）、ステップ４１０８へ進む。ＣｅｒｔＩＤに記載された検証対象証明書のシリアルナンバーが失効データテーブル９０に存在しない場合、検証処理部２３は、検証対象証明書の失効情報（CertStatus）を有効（good）とする検証結果データを作成して（ステップ４１０７）、ステップ４１０８へ進む。次に、検証処理部２３は、鍵保持部２８に保持されている検証サーバの秘密鍵を取得し（ステップ４１０８）、検証結果データに署名を付与して、署名付きの検証応答を作成する（ステップ４１０９）。そして、検証サーバ１１の処理部２０ａは、通信部２０ｃを介して、作成した検証応答を端末装置１２へ送信し（ステップ４１１０）、端末装置１２は、ステップ１０００で送信した検証要求に対する検証応答を受信する（ステップ４００１）。

図２０は、失効データテーブル９０が存在する場合における、検証サーバ１１のリフレッシュ処理のフローチャートを示す図である。

検証サーバ１１のＣＲＬ取得機能２２０が実行するＣＲＬの更新処理ステップ３０００〜ステップ３００６は図７で示したＣＲＬ更新処理とほぼ同じである。その後、検証サーバ１１のリフレッシュ機能２２５により、ステップ３００７〜ステップ３００８を実行する。

具体的には、検証サーバ１１のＣＲＬ取得機能２２０は、設定情報保持部２５に予め設定されたＣＲＬ更新タイミング（例えば１日）を取得し、ＣＲＬ１６を以前に取得した日時から、ＣＲＬ更新タイミングを経過したかを確認する（ステップ３０００）。ＣＲＬ更新タイミングを経過している場合、ＣＲＬ取得機能２２０は、ＣＡ振分け機能２２１により、認証局識別テーブル６０から該当の認証局のＣＲＬ取得先情報を取得する（ステップ３００１）。そしてＣＲＬ取得機能２２０は、取得したＣＲＬ取得先情報に基づいて、通信部２０ｃを介してＣＲＬ取得要求を当該認証局１３へ送信する（ステップ３００２）。認証局１３は、ＣＲＬ取得要求を受信する（ステップ３１００）と、認証局１３のＣＲＬ保持部４６に保持されるＣＲＬ１６を検証サーバ１１へ送信する（ステップ３１０１）。そして、検証サーバ１１の失効情報管理部２２は、認証局１３からのＣＲＬ１６を受信する（ステップ３００３）と、認証局証明書（認証局１３の公開鍵証明書）を用いてＣＲＬ１６に記載されている認証局の署名を確認し（ステップ３００４）、ＣＲＬ情報テーブル８０を参照して、受信したＣＲＬ１６が既に取得しているＣＲＬ１６より更新されているかどうかを確認する（ステップ３００５）。認証局１３から受信したＣＲＬ１６の作成日時が前回取得したＣＲＬ１６の作成日時よりも新しくなっていた場合、認証局１３のＣＲＬ１６が更新されていると判断し、ステップ３００６へ進む。受信した認証局１３のＣＲＬ１６が更新されていなかった場合、ステップ３０００へ進む。なお、認証局１３から初めてＣＲＬ１６を受信する場合は、ステップ３００６へ進む。次に、検証サーバ１１の失効情報管理部２２のファイル書込み機能２２３は、受信したＣＲＬ１６の認証局識別子をキーとして、ＣＲＬ情報テーブル８０の作成または更新を行い、取得したＣＲＬ１６の情報をＣＲＬ情報保持部２６１へ格納する（ステップ３００６）。

次に、検証サーバ１１のリフレッシュ機能２２５は、取得したＣＲＬ
１６の認証局識別子をキーとして、失効データ保持部２６２に保持された失効データテーブル９０の当該認証局識別子欄９１の失効したシリアルナンバー９２を取得し、ＣＲＬ情報テーブル８０の同じ認証局識別子８１欄の失効した証明書のシリアルナンバー８３の中に同じシリアルナンバーがないかを確認する（ステップ３００７）。同一認証局識別子の失効データテーブル９０とＣＲＬ情報テーブル８０に同じシリアルナンバーが存在した場合、ステップ３００８に進む。同じシリアルナンバーが存在しない場合、検証サーバ１１は、処理を終了する。

失効データテーブル９０とＣＲＬ情報テーブル８０に同じシリアルナンバーが存在した場合、リフレッシュ機能２２５は、失効データテーブル９０内の当該シリアルナンバーの行を消去する。リフレッシュ機能２２６は、同一認証局識別子の失効データテーブル９０とＣＲＬ情報テーブル８０に同じシリアルナンバーが存在しなくなるまで、失効データテーブル９０の該当のシリアルナンバーの消去を行い（ステップ３００８）、同じシリアルナンバーが存在しなくなった場合に、処理を終了する。

以上、本発明の第三の実施例を説明した。本実施例によれば、失効情報更新エージェントを用いて認証局が失効要求を受け付けて、公開鍵証明書が失効するとすぐに失効データを取得し、プッシュ型で検証サーバに失効データを送信するため、失効の検証が行われるまでの時間的な遅れをさらに低減し、かつセッションをプールすることにより検証サーバ１１におけるアクセス処理の負荷を軽減し、かつ検証サーバ１１内に重複するデータを保持しないように消去することで、公開鍵証明書の有効性確認処理を効率的に行うことができる。

１１ 検証サーバ
１２ 端末装置
１３ 認証局
１４ ネットワーク
１５ 検証要求
１６ ＣＲＬ
１７ 失効データ
１８ 失効情報更新エージェント
１９ 差分失効データ
２０ａ 処理部
２０ｂ 記憶部
２０ｃ 通信部
２０ｄ 入出力部
２１ 管理部
２２ 失効情報管理部
２３ 検証処理部
２４ 制御部
２５ 設定情報保持部
２６ 失効情報保持部
２７ 検証サーバ証明書保持部
２８ 鍵保持部
３０ａ 処理部
３０ｂ 記憶部
３０ｃ 通信部
３０ｄ 入出力部
３１ 署名付き文書作成部
３２ 署名・証明書検証部
３３ 制御部
３４ 電子文書保持部
３５ 鍵保持部
３６ 検証対象保持部
４０ａ 処理部
４０ｂ 記憶部
４０ｃ 通信部
４０ｄ 入出力部
４１ 発行部
４２ 管理部
４３ 制御部
４４ 証明書保持部
４５ 発行先管理リスト保持部
４６ ＣＲＬ保持部
４７ 失効データ保持部
５０ 内部通信線
５１ ＣＰＵ
５２ メモリ
５３ 外部記憶装置
５４ 通信装置
５５ 入力装置
５６ 出力装置
５７ 読取装置
５８ 可搬性を有する記憶媒体
７０ａ 処理部
７０ｂ 記憶部
７０ｃ 通信部
７０ｄ 入出力部
７１ セッションプール機能
７２ 外部ＤＢ参照機能
７３ 差分作成機能
７４ 認証局情報保持部
７５ 送信済み失効データ保持部
２２０ ＣＲＬ取得機能
２２１ ＣＡ振分け機能
２２２ 外部ＤＢ参照機能
２２３ ファイル書込み機能
２２４ セッションプール機能
２２５ リフレッシュ機能
２６０ 認証局情報保持部
２６１ ＣＲＬ情報保持部
２６２ 失効データ保持部

Claims (9)

1. 公開鍵証明書の有効性を検証する検証サーバにおける公開鍵証明書の検証方法であって、
   前記検証サーバは、認証局が発行した公開鍵証明書失効リストの情報を記憶する公開鍵証明書失効リスト情報記憶部を有し、
   前記検証サーバにより、
   端末装置から前記公開鍵証明書の検証要求を受信し、
   前記公開鍵証明書失効リスト情報記憶部の情報を用いて前記検証要求に含まれる検証対象の前記公開鍵証明書の有効性を検証し、
   該検証の結果、前記検証対象の前記公開鍵証明書の情報が前記公開鍵証明書失効リスト情報記憶部に存在しない場合に、
   前記検証要求で指定された認証局から、該認証局が前記公開鍵証明書失効リストに記載する前の前記公開鍵証明書の失効情報を取得し、
   該失効情報を用いて前記検証対象の公開鍵証明書の有効性を検証し、
   該検証の結果を前記端末装置へ応答する、
   ことを特徴とする公開鍵証明書の検証方法。
2. 公開鍵証明書の有効性を検証する検証サーバにおける公開鍵証明書の検証方法であって、
   前記検証サーバは、認証局が発行した公開鍵証明書失効リストの情報を記憶する公開鍵証明書失効リスト情報記憶部を有し、
   前記検証サーバにより、
   端末装置から前記公開鍵証明書の検証要求を受信し、
   前記公開鍵証明書失効リスト情報記憶部の情報を用いて前記検証要求に含まれる検証対象の前記公開鍵証明書の有効性を検証し、
   該検証の結果、前記検証対象の前記公開鍵証明書の情報が前記公開鍵証明書失効リスト情報記憶部に存在しない場合に、
   前記検証要求で指定された認証局と接続された中継サーバから、前記検証要求で指定された認証局が前記公開鍵証明書失効リストに記載する前の前記公開鍵証明書の失効情報を取得し、
   該失効情報を用いて前記検証対象の公開鍵証明書の有効性を検証し、
   該検証の結果を前記端末装置へ応答する、
   ことを特徴とする公開鍵証明書の検証方法。
3. 前記検証サーバは、さらに前記失効情報を記憶する失効情報記憶部を有し、
   前記検証サーバにより、
   前記端末装置から前記公開鍵証明書の検証要求を受信し、
   前記公開鍵証明書失効リスト情報記憶部の情報を用いて前記検証要求に含まれる検証対象の前記公開鍵証明書の有効性を検証し、
   該検証の結果、前記検証対象の公開鍵証明書の情報が前記公開鍵証明書失効リスト情報記憶部に存在しない場合に、
   前記失効情報記憶部に記憶されている前記失効情報を用いて前記検証対象の公開鍵証明書の有効性を検証し、
   該検証の結果を前記端末装置へ応答する、
   ことを特徴とする請求項２に記載の公開鍵証明書の検証方法。
4. 前記検証サーバにより、
   所定のタイミングで、前記認証局から前記公開鍵証明書失効リストを受信し、
   該公開鍵証明書失効リストの情報に基づき、前記公開鍵証明書失効リスト情報記憶部に記憶されている前記公開鍵証明書失効リストの情報を更新し、
   前記失効情報記憶部と前記失効リスト情報記憶部に重複情報が有る場合、前記失効情報記憶部から前記重複情報を消去する、
   ことを特徴とする請求項３に記載の公開鍵証明書の検証方法。
5. 認証局が発行した公開鍵証明書失効リストの情報を記憶する公開鍵証明書失効リスト情報記憶部と、
   端末装置から公開鍵証明書の検証要求を受信し、
   前記公開鍵証明書失効リスト情報記憶部の情報を用いて前記検証要求に含まれる検証対象の前記公開鍵証明書の有効性を検証し、
   該検証の結果、前記検証対象の前記公開鍵証明書の情報が前記公開鍵証明書失効リスト情報記憶部に存在しない場合に、
   前記検証要求で指定された認証局から、該認証局が前記公開鍵証明書失効リストに記載する前の前記公開鍵証明書の失効情報を取得し、
   該失効情報を用いて前記検証対象の公開鍵証明書の有効性を検証し、
   該検証の結果を前記端末装置へ応答する処理部と、
   を有する、
   ことを特徴とする検証サーバ。
6. 認証局が発行した公開鍵証明書失効リストの情報を記憶する公開鍵証明書失効リスト情報記憶部と、
   端末装置から前記公開鍵証明書の検証要求を受信し、
   前記公開鍵証明書失効リスト情報記憶部の情報を用いて前記検証要求に含まれる検証対象の前記公開鍵証明書の有効性を検証し、
   該検証の結果、前記検証対象の前記公開鍵証明書の情報が前記公開鍵証明書失効リスト情報記憶部に存在しない場合に、
   前記検証要求で指定された認証局と接続された中継サーバから、前記検証要求で指定された認証局が前記公開鍵証明書失効リストに記載する前の前記公開鍵証明書の失効情報を取得し、
   該失効情報を用いて前記検証対象の公開鍵証明書の有効性を検証し、
   該検証の結果を前記端末装置へ応答する処理部と、
   を有する、
   ことを特徴とする検証サーバ。
7. 前記検証サーバは、さらに前記取得した失効公開鍵証明書の情報を記憶する失効情報記憶部を有し、
   前記処理部は、
   前記端末装置から前記公開鍵証明書の検証要求を受信し、
   前記公開鍵証明書失効リスト情報記憶部の情報を用いて前記検証要求に含まれる検証対象の前記公開鍵証明書の有効性を検証し、
   該検証の結果、前記検証対象の公開鍵証明書の情報が前記公開鍵証明書失効リスト情報記憶部に存在しない場合に、
   前記失効情報記憶部に記憶されている前記失効公開鍵証明書の情報を用いて前記検証対象の公開鍵証明書の有効性を検証し、
   該検証の結果を前記端末装置へ応答する、
   ことを特徴とする請求項６に記載の検証サーバ。
8. 前記処理部は、
   所定のタイミングで、前記認証局から前記公開鍵証明書失効リストを受信し、
   該公開鍵証明書失効リストの情報に基づき、前記公開鍵証明書失効リスト情報記憶部に記憶されている前記公開鍵証明書失効リストの情報を更新し、
   前記失効情報記憶部と前記失効リスト情報記憶部に重複情報が有る場合、前記失効情報記憶部から前記重複情報を消去する、
   ことを特徴とする請求項７に記載の検証サーバ。
9. コンピュータに、請求項１乃至請求項４の何れか１項に記載の公開鍵証明書の検証方法を実行させるプログラム。

Images