(57)【特許請求の範囲】
【請求項１】
認証局と端末装置とに接続し、前記認証局が発行した公開鍵証明書の有効性を検証する検証サーバによる検証方法であって、
前記認証局の鍵情報の更新に伴って、前記認証局の名前情報と前記更新した鍵情報とを含む前記認証局の認証局証明書を取得し、
前記認証局の前記鍵情報の更新の前後に関わらず、前記認証局が発行し、有効期間内であって失効した公開鍵証明書を示す失効情報を、前記認証局が前記更新した鍵情報に対応して前記認証局から取得し、
前記端末装置からの、前記認証局の名前情報のハッシュ値、前記公開鍵証明書を発行したときの前記認証局の鍵情報のハッシュ値、及び前記公開鍵証明書を特定する情報を含む検証要求に応答して、前記検証要求に含まれる前記認証局の名前情報のハッシュ値が前記認証局証明書に含まれる前記認証局の名前情報から生成するハッシュ値に相当し、前記検証要求に含まれる前記認証局の鍵情報のハッシュ値が前記認証局証明書に含まれる前記認証局の鍵情報から生成するハッシュ値に相当し、前記検証要求に含まれる前記公開鍵証明書を特定する情報が前記失効情報の中になければ、前記検証要求に含まれる前記公開鍵証明書を特定する情報に対応する前記公開鍵証明書は有効であるとする検証結果を作成することを特徴とする公開鍵証明書の検証方法。
【請求項２】
前記検証サーバは、該検証サーバの公開鍵証明書である検証サーバ証明書を前記認証局から取得し、
前記検証サーバ証明書の公開鍵に対応する秘密鍵を用いて、前記検証結果に署名し、
前記署名した検証結果を前記端末装置へ送信することを特徴とする請求項１記載の公開鍵証明書の検証方法。
【請求項３】
前記検証結果への署名には、前記認証局によって予め定められた署名アルゴリズムを用いることを特徴とする請求項２記載の公開鍵証明書の検証方法。
【請求項４】
前記検証サーバは、前記認証局証明書に含まれる前記認証局の名前情報と前記更新した鍵情報の各々から生成したハッシュ値のペアを保持し、
前記端末装置からの前記検証要求に含まれる、前記認証局の名前情報のハッシュ値と前記公開鍵証明書を発行したときの前記認証局の鍵情報のハッシュ値を取得し、前記検証要求のハッシュ値が前記認証局証明書から生成したハッシュ値に相当し、前記検証要求に含まれる前記公開鍵証明書を特定する情報が前記失効情報の中になければ、前記検証要求に含まれる前記公開鍵証明書を特定する情報に対応する前記公開鍵証明書は有効であるとする検証結果を作成することを特徴とする請求項１記載の公開鍵証明書の検証方法。
【請求項５】
前記検証サーバは、前記ハッシュ値を求めるハッシュアルゴリズムを複数種類有し、前記保持するハッシュ値のペアは、前記複数種類のハッシュアルゴリズムの各々に対応して予め求めたハッシュ値のペアであり、前記検証要求に含まれる、前記認証局の名前情報と前記公開鍵証明書を発行したときの前記認証局の鍵情報の各々のハッシュ値のペアが前記複数種類のハッシュアルゴリズムの各々に対応して予め求めたハッシュ値の前記ペアのいずれかに相当するか否かを判定することを特徴とする請求項４記載の公開鍵証明書の検証方法。
【請求項６】
前記認証局の鍵情報の更新に伴って、前記認証局の鍵更新前の認証局証明書を識別する第１の識別子とは異なる第２の識別子を、前記認証局の名前情報と前記更新した鍵情報とを含む前記認証局の認証局証明書に付与することを特徴とする請求項１記載の公開鍵証明書の検証方法。
【請求項７】
前記検証サーバは、該検証サーバの公開鍵証明書である検証サーバ証明書を前記認証局から取得し、
前記検証要求に含まれる前記認証局の名前情報のハッシュ値が前記第１及び第２の識別子のいずれか一方が付与された前記認証局証明書に含まれる前記認証局の名前情報に相当し、前記検証要求に含まれる前記公開鍵証明書を特定する情報が前記失効情報の中になければ、前記検証要求に含まれる前記公開鍵証明書を特定する情報に対応する前記公開鍵証明書は有効であるとする検証結果を作成し、
前記有効である公開鍵証明書を発行した前記第１及び第２の識別子のいずれか一方が付与された認証局によって予め定められた署名アルゴリズムと前記検証サーバ証明書の公開鍵に対応する秘密鍵を用いて、前記検証結果に署名し、
前記署名した検証結果を前記端末装置へ送信することを特徴とする請求項６記載の公開鍵証明書の検証方法。
【請求項８】
前記認証局は複数あり、前記検証サーバは前記複数の認証局と接続し、
前記検証要求に含まれる前記認証局の名前情報のハッシュ値が、前記複数の認証局から発行された前記認証局証明書のいずれか一つに含まれる認証局の名前情報のハッシュ値に相当し、前記検証要求に含まれる前記公開鍵証明書を特定する情報が、前記名前情報のハッシュ値によって特定される前記認証局から取得した前記失効情報の中になければ、前記検証要求に含まれる前記公開鍵証明書を特定する情報に対応する前記公開鍵証明書は有効であるとする検証結果を作成することを特徴とする請求項１記載の公開鍵証明書の検証方法。
【請求項９】
認証局と端末装置とに接続し、
前記認証局の鍵情報の更新に伴う、前記認証局の名前情報と前記更新した鍵情報とを含む前記認証局の認証局証明書を保持する設定情報保持部、
前記認証局の前記鍵情報の更新の前後に関わらず、前記認証局が発行し、有効期間内であって失効した公開鍵証明書を示す失効情報を保持する失効情報保持部、及び
前記端末装置からの、前記認証局の名前情報のハッシュ値、前記公開鍵証明書を発行したときの前記認証局の鍵情報のハッシュ値、及び前記公開鍵証明書を特定する情報を含む検証要求に応答して、前記検証要求に含まれる前記認証局の名前情報のハッシュ値が前記認証局証明書に含まれる前記認証局の名前情報から生成するハッシュ値に相当し、前記検証要求に含まれる前記認証局の鍵情報のハッシュ値が前記認証局証明書に含まれる前記認証局の鍵情報から生成するハッシュ値に相当し、前記検証要求に含まれる前記公開鍵証明書を特定する情報が前記失効情報の中になければ、前記検証要求に含まれる前記公開鍵証明書を特定する情報に対応する前記公開鍵証明書は有効であるとする検証結果を作成する検証処理部を有すること特徴とする公開鍵証明書の検証サーバ。
【請求項１０】
該検証サーバの公開鍵証明書である検証サーバ証明書を保持する検証サーバ証明書保持部をさらに有し、
前記検証処理部は、前記検証サーバ証明書保持部に保持している前記検証サーバ証明書の公開鍵に対応する秘密鍵を用いて、前記検証結果に署名し、前記署名した検証結果を前記端末装置へ送信することを特徴とする請求項９記載の公開鍵証明書の検証サーバ。
【請求項１１】
前記検証結果への署名には、前記認証局によって予め定められた署名アルゴリズムを用いることを特徴とする請求項１０記載の公開鍵証明書の検証サーバ。
【請求項１２】
前記設定情報保持部は、前記認証局証明書に含まれる前記認証局の名前情報と前記更新した鍵情報の各々から生成したハッシュ値のペアを保持し、
前記検証処理部は、前記端末装置からの前記検証要求に含まれる、前記認証局の名前情報のハッシュ値と前記公開鍵証明書を発行したときの前記認証局の鍵情報のハッシュ値を取得し、前記検証要求のハッシュ値が前記認証局証明書から生成したハッシュ値に相当し、前記検証要求に含まれる前記公開鍵証明書を特定する情報が前記失効情報の中になければ、前記検証要求に含まれる前記公開鍵証明書を特定する情報に対応する前記公開鍵証明書は有効であるとする検証結果を作成することを特徴とする請求項９記載の公開鍵証明書の検証サーバ。
【請求項１３】
前記設定情報保持部は、前記ハッシュ値を求める複数種類のハッシュアルゴリズムを保持し、前記保持するハッシュ値のペアは、前記複数種類のハッシュアルゴリズムの各々に対応して予め求めたハッシュ値のペアであり、
前記検証処理部は、前記検証要求に含まれる、前記認証局の名前情報と前記公開鍵証明書を発行したときの前記認証局の鍵情報の各々のハッシュ値のペアが、前記
設定情報保持部に保持された前記複数種類のハッシュアルゴリズムの各々に対応して予め求めたハッシュ値の前記ペアのいずれかに相当するか否かを判定することを特徴とする請求項１２記載の公開鍵証明書の検証サーバ。
【請求項１４】
前記設定情報保持部は、前記認証局の鍵情報の更新に伴って、前記認証局の鍵更新前の認証局証明書を識別する第１の識別子とは異なる第２の識別子を、前記認証局の名前情報と前記更新した鍵情報とを含む前記認証局の認証局証明書に付与して保持することを特徴とする請求項９記載の公開鍵証明書の検証サーバ。
【請求項１５】
該検証サーバの公開鍵証明書である検証サーバ証明書を保持する検証サーバ証明書保持部をさらに有し、
前記検証処理部は、前記検証要求に含まれる前記認証局の名前情報のハッシュ値が前記第１及び第２の識別子のいずれか一方が付与された前記認証局証明書に含まれる前記認証局の名前情報に相当し、前記検証要求に含まれる前記公開鍵証明書を特定する情報が前記失効情報の中になければ、前記検証要求に含まれる前記公開鍵証明書を特定する情報に対応する前記公開鍵証明書は有効であるとする検証結果を作成し、
前記有効である公開鍵証明書を発行した前記第１及び第２の識別子のいずれか一方が付与された認証局によって予め定められた署名アルゴリズムと前記検証サーバ証明書の公開鍵に対応する秘密鍵を用いて、前記検証結果に署名し、
前記署名した検証結果を前記端末装置へ送信することを特徴とする請求項１４記載の公開鍵証明書の検証サーバ。
【請求項１６】
前記認証局は複数あり、前記検証サーバは前記複数の認証局と接続し、
前記検証処理部は、前記検証要求に含まれる前記認証局の名前情報のハッシュ値が、前記複数の認証局から発行された前記認証局証明書のいずれか一つに含まれる認証局の名前情報のハッシュ値に相当し、前記検証要求に含まれる前記公開鍵証明書を特定する情報が、前記名前情報のハッシュ値によって特定される前記認証局から取得した前記失効情報の中になければ、前記検証要求に含まれる前記公開鍵証明書を特定する情報に対応する前記公開鍵証明書は有効であるとする検証結果を作成することを特徴とする請求項９記載の公開鍵証明書の検証サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、公開鍵基盤（Public Key Infrastructure：以下「ＰＫＩ」とも言う。）において、ある端末が受け取った電子手続に対する署名を検証するための公開鍵証明書に関して、その公開鍵証明書が有効であるか否かを確認するのに好適な技術に関する。
【背景技術】
【０００２】
公開鍵基盤において、電子文書などの電子データを送付する際に、対象となる電子データに、送信者の電子署名と、認証局が発行する公開鍵証明書を添付する。受信者は、受信データに添付された電子署名（以下「署名」ともいう）と公開鍵証明書の有効性を確認することにより、送付された電子データが改ざんされていないことと、確かに送信者本人から送られた電子データであることを確認する。公開鍵証明書の発行と有効性の確認は、公開鍵基盤において行われ、その標準仕様はRFC5280（Internet X.509 Public Key Infrastructure Certificate and CRL Profile）等に規定されている。
【０００３】
公開鍵証明書は、その有効期間が終了する前に、その公開鍵証明書の記載内容に変更があった場合等には、その公開鍵証明書を発行した認証局（Certificate Authority）により失効され、無効となる。そこで、受信者は、受信した公開鍵証明書の有効性確認において、その公開鍵証明書が失効しているか否かを確認する。
【０００４】
失効しているか否かの確認には、認証局が発行する公開鍵証明書失効リスト（Certificate Revocation List：以下「ＣＲＬ」という）を用いる。ＣＲＬには、認証局の名前（issuerName）、認証局の鍵情報（authorityKeyIdentifier）、認証局が発行した有効期間内の公開鍵証明書のうち、失効した公開鍵証明書のシリアルナンバー（userCertificate）、ＣＲＬの有効期間等が記載され、この認証局の署名が付与されており、認証局によって定期的に発行される。受信者は、認証局からＣＲＬを取得し、受信データに添付された公開鍵証明書のシリアルナンバーが、取得したＣＲＬに記載されているかどうかを確認する。シリアルナンバーがＣＲＬに記載されている場合は、この公開鍵証明書は失効し、無効であると判断し、記載されていない場合には、この公開鍵証明書は有効であると判断する。
【０００５】
しかしながら、認証局が発行する公開鍵証明書の数が多数あり、かつ失効する公開鍵証明書が多い場合、ＣＲＬの容量が膨大になる。このため、公開鍵証明書が添付された電子データを受信する受信者にとっては、ＣＲＬを取得するために時間がかかり、公開鍵証明書の有効性確認処理に時間がかかるという課題がある。これに対応するために、オンラインで、公開鍵証明書が失効しているかどうかの確認要求を受け付けて、これに応答するサービス（以下「検証サーバ」と呼ぶ。）があり、その標準仕様は非特許文献１に規定されている。
【０００６】
検証サーバは、認証局が発行するＣＲＬを定期的に取り込んでおき、公開鍵証明書の失効確認をする受信者が利用する端末（以下「端末装置」と呼ぶ。）からの公開鍵証明書の失効確認要求（以下「検証要求」と呼ぶ。）を受け付ける。検証要求には検証対象証明書(検証対象の公開鍵証明書)を特定するための情報（CertID）が記述される。検証対象証明書を特定するための情報（CertID）には、端末装置が使用するハッシュアルゴリズム（hashAlgorithm）と、検証対象証明書を発行した認証局の名前情報（issuerNameHash）と、認証局の鍵情報（issuerKeyHash）と、検証対象証明書のシリアルナンバー（seiralNumber）が含まれる。このうち認証局の名前情報（issuerNameHash）と認証局の鍵情報（issuerKeyHash）は、認証局の名前データ（issuerName）と鍵データ（authorityKeyIdentifier）を端末装置が使用するハッシュアルゴリズム（hashAlgorithm）でそれぞれハッシュ計算したものである。
【０００７】
検証要求を受け付けた検証サーバは、検証対象証明書のシリアルナンバーが予め取り込んだＣＲＬに記載されているかどうかを調べ、この検証対象証明書である公開鍵証明書が失効しているかどうかを端末装置に応答する。検証サーバから端末装置へ送付される応答電文（以下「検証結果」と呼ぶ。）には、検証対象証明書の状態が有効(good)、失効(revoked)、不明(unknown) のいずれかで記載される。さらに、検証結果には検証した検証サーバの署名及び証明書（以下「検証サーバ証明書」と言う。）が付与され、これにより端末装置の利用者は、この検証サーバによって確かに送付された検証結果であることを確認できる。
【０００８】
なお、ＣＲＬには、認証局がＣＲＬを作成する時点で失効している公開鍵証明書のシリアルナンバーがすべて記載されている。
【０００９】
また、複数の認証局が運用され、送信者が電子データに添付する公開鍵証明書を発行した認証局と、受信者が利用している認証局とが異なり、送信者の公開鍵証明書の有効性を受信者が確認できない場合が生じる。このような場合に、検証サーバが複数の認証局に対応する技術が特許文献1に開示されている。
【００１０】
【特許文献１】特開2002-139996
【非特許文献１】The Internet Engineering Task Force(IETF),X.509 Internet Public Key Infrastructure Online Certificate Status Protocol  OCSP(RFC2560),page 2 “2.1 Request” “2.2 Response”, ［online］, 1999年6月,［平成18年1月23日検索］インターネット＜URL：http://ietf.org/rfc/rfc2560.txt＞
【発明の開示】
【発明が解決しようとする課題】
【００１１】
認証局が発行する公開鍵証明書やＣＲＬへ署名するために用いる秘密鍵は定期的にあるいは、脆弱化の恐れがあると判断されたときに更新される。これに対応するために認証局が秘密鍵を更新すると、公開鍵証明書やＣＲＬは認証局の更新された新しい秘密鍵で署名されて発行される。秘密鍵を更新する前に発行された公開鍵証明書は、その有効期間内であり、かつ失効事由がなければ、有効に利用される。このような状況においては、検証サーバは新しい秘密鍵で署名されたＣＲＬを認証局から取り込み、端末装置は、認証局の秘密鍵が更新される前に発行された、その認証局の古い秘密鍵で署名された公開鍵証明書の検証要求を検証サーバへ送信することになる。
【００１２】
検証サーバでは、検証要求に含まれる、検証対象証明書である公開鍵証明書を特定するための情報（CertID）の中の、認証局を特定する情報としての名前情報（issuerNameHash）及び認証局の鍵情報（issuerKeyHash）が、取り込んでいるＣＲＬの認証局名（issuerName）と認証局の鍵情報（authorityKeyIdentifier）に対応するかを確認する。認証局の秘密鍵が更新されている場合、検証要求に含まれる鍵情報（issuerKeyHash）と、ＣＲＬに記述される鍵情報（authorityKeyIdentifier）が対応しないため、検証サーバは検証対象証明書の失効確認ができないという問題がある。
【００１３】
非特許文献１では、認証局の秘密鍵が更新される場合について考慮されていないので、検証サーバが検証対象証明書の失効確認ができない場合が発生するという問題を見出していない。
【００１４】
この問題に対して、秘密鍵が更新される前の認証局と秘密鍵が更新された後の認証局とを、異なる複数の認証局と見なし、特許文献1に示される技術の適用を試みると、次のような新たな問題が発生する。
【００１５】
秘密鍵が更新されると、検証サーバは新しい認証局と見なし、その後に取り込むＣＲＬを新しい認証局に対応して記憶し、秘密鍵が更新される前に取り込んだ古い認証局に対応したＣＲＬはもはや更新されない。ＣＲＬに記載された各公開鍵証明書の有効期間満了に伴って、ＣＲＬの容量は徐々に減少していくが、ＣＲＬに記載されたすべての公開鍵証明書の有効期間満了までは残ることになる。ところが、秘密鍵が更新された後に取り込んだＣＲＬには、秘密鍵の更新とは無関係に、その時点で有効期間内であるが、失効しているすべての公開鍵証明書のシリアルナンバーが記載されているので、秘密鍵が更新される前に失効した公開鍵証明書のシリアルナンバーは、検証サーバが保持している２つのＣＲＬに重複して格納されていることになる。失効している公開鍵証明書が多くなれば、重複格納する記憶容量も大きくなるという問題が生じだけでなく、検証サーバが新しい認証局に対応して保持している、古い認証局によって発行され、失効した公開鍵証明書のシリアルナンバーは参照されないという問題を生じる。
【００１６】
さらに、次のような新たな問題も生じる。認証局は必ずしも秘密鍵の更新タイミングをＣＲＬの作成タイミングに合わせる必要はない。そこで検証サーバは、認証局が時刻ｔ1に作成したＣＲＬを取り込み、認証局が時刻ｔ2に秘密鍵を更新し、認証局が時刻ｔ3に作成した次のＣＲＬを取り込んだとする（時刻ｔ1＜ｔ2＜ｔ3）。このとき時刻ｔ1から時刻ｔ2の間に失効した公開鍵証明書は、古い認証局の秘密鍵を用いて発行されたにもかかわらず、古い認証局に対応した、更新されないＣＲＬには含まれず、検証要求に対して有効であるとの誤った検証結果を応答することになる。
【００１７】
以上から、認証局の秘密鍵の更新に伴う、検証サーバが検証対象証明書の失効確認ができない場合が発生するという課題は依然として残されたままである。
【課題を解決するための手段】
【００１８】
本発明は、認証局と端末装置とに接続し、認証局が発行した公開鍵証明書の有効性を検証する検証サーバ及びその検証方法であって、次のような態様である。検証サーバは、検証サーバ認証局の鍵情報の更新に伴う、認証局を特定する第１の情報と更新した鍵情報とを含む認証局の認証局証明書を保持する。また検証サーバは、認証局の鍵情報の更新の前後に関わらず、認証局が発行し、有効期間内であって失効した公開鍵証明書を示す失効情報を保持する。そして端末装置からの、認証局を特定する第２の情報、公開鍵証明書を発行したときの認証局の鍵情報、及び公開鍵証明書を特定する情報を含む検証要求に応答して、検証要求に含まれる認証局を特定する第２の情報が認証局証明書に含まれる認証局を特定する第１の情報に相当し、検証要求に含まれる公開鍵証明書を特定する情報が失効情報の中になければ、検証要求に含まれる公開鍵証明書を特定する情報に対応する公開鍵証明書は有効であるとする検証結果を作成する。
【００１９】
本発明の他の態様は、検証サーバは、検証サーバの公開鍵証明書である検証サーバ証明書を保持し、保持している検証サーバ証明書の公開鍵に対応する秘密鍵を用いて、検証結果に署名し、署名した検証結果を端末装置へ送信する。
【００２０】
本発明のさらに他の態様は、検証サーバは、認証局証明書に含まれる認証局を特定する第１の情報と更新した鍵情報の各々のハッシュ値のペアを保持し、端末装置からの検証要求に含まれる、認証局を特定する第２の情報と公開鍵証明書を発行したときの認証局の鍵情報が各々のハッシュ値のペアであるとき、第２の情報のハッシュ値が第１の情報のハッシュ値に相当するか否かを判定する。
【００２１】
本発明のさらに他の態様は、検証サーバは、認証局の鍵情報の更新に伴って、認証局の鍵更新前の認証局証明書を識別する第１の識別子とは異なる第２の識別子を、認証局を特定する第１の情報と更新した鍵情報とを含む認証局の認証局証明書に付与して保持する。
【００２２】
本発明のさらに他の態様は、検証サーバは、複数の認証局と接続し、検証要求に含まれる認証局を特定する第２の情報が、複数の認証局から発行された認証局証明書のいずれか一つに含まれる認証局を特定する第３の情報に相当し、検証要求に含まれる公開鍵証明書を特定する情報が、第３の情報によって特定される認証局から取得した失効情報の中になければ、検証要求に含まれる公開鍵証明書を特定する情報に対応する公開鍵証明書は有効であるとする検証結果を作成する。
【発明の効果】
【００２３】
本発明によれば、認証局が鍵を更新した場合でも、鍵の更新の前後に係らず認証局が発行した公開鍵証明書の有効性を検証できる。
【発明を実施するための最良の形態】
【００２４】
以下に、本発明の実施形態を用いて説明する。最初に、本実施形態の説明で用いる用語を説明する。電子データの送信者の電子署名には、送信者の秘密鍵が用いられ、その送信者の秘密鍵と対をなす公開鍵を、認証局が証明し、署名した証明書が公開鍵証明書である。公開鍵証明書への認証局による署名には、認証局の秘密鍵が用いられ、その認証局の秘密鍵と対をなす公開鍵を、他の認証局が証明し、署名した証明書も公開鍵証明書である。この他の認証局が証明した公開鍵証明書を、ここでは認証局証明書と呼ぶ。このように他の認証局が証明するので、複数の認証局は階層構造となる。最上位層の認証局はルート認証局と呼ばれ、自ら証明した公開鍵証明書を発行することになるが、利用者が絶対的にルート認証局を信用することにより、公開鍵基盤が成立している。本実施形態では、ルート認証局が発行した公開鍵証明書も、認証局証明書として扱うことができる。本実施形態には、公開鍵証明書の失効情報を提供する検証サーバがある。失効情報は、検証サーバの秘密鍵を用いて署名した検証結果として提供される。検証サーバの秘密鍵と対をなす公開鍵を、認証局が証明し、署名した証明書も公開鍵証明書である。この検証サーバの秘密鍵と対をなす公開鍵を証明する公開鍵証明書を検証サーバ証明書と呼ぶ。以上のように、公開鍵証明書、認証局証明書及び検証サーバ証明書は、公開鍵に関わる情報に署名が付されたものであるが、これらの証明書には、以下の説明から明らかになる、認証局を特定する情報としての認証局名や公開鍵証明書を特定する情報としてのシリアルナンバーなどの認証局に関わる情報や各々が証明する端末装置、認証局、検証サーバに関する情報も含まれる。また、以下の説明で、単に鍵の更新または秘密鍵の更新と記載する場合があるが、秘密鍵に対応する公開鍵も同時に更新するものであり、秘密鍵と公開鍵の対としての更新を表す。
【００２５】
図１は、本実施形態の検証システムの構成を示す図である。検証システムは、電子的に手続（電子データの送信など）を実行する複数の端末装置１１１〜端末装置１１Ｍと、公開鍵証明書を発行および失効させる認証局１２１〜認証局１２Ｎと、認証局１２が発行した公開鍵証明書の失効情報（ＣＲＬ）に基いて、公開鍵証明書の有効性を検証する検証サーバ１３と、それぞれを接続するインターネット等のネットワーク１４を有する。
【００２６】
図２に、端末装置１１の構成を示す。端末装置１１は、処理部２０ａ、記憶部２０ｂ、ネットワーク１４を介して他の装置と通信するための通信部２０ｃ、及び端末装置１１のユーザが作成した電子文書や他の端末装置１１から受け取った電子文書の入出力やユーザからの指示を受け付ける入出力部２０ｄを有する。
【００２７】
以下の端末装置１１の説明では、説明を分かり易くするために、端末装置１１のユーザが作成した電子文書を他の端末装置１１へ送信するときに添付する公開鍵証明書を自公開鍵証明書、他の端末装置１１から受信した電子文書に添付する公開鍵証明書を他公開鍵証明書と呼ぶ。
【００２８】
処理部２０ａは、端末装置１１の秘密鍵を用いて電子文書に署名を付与した署名付き文書を作成する署名付き文書作成部２１、他の端末装置１１からの署名付き電子文書の署名および他公開鍵証明書の検証を行う署名・証明書検証部２２、および端末装置１１の各部を制御する制御部２３を有する。
【００２９】
記憶部２０ｂは、ユーザが作成した電子文書を保持する電子文書保持部２４、署名を生成するための秘密鍵と、この秘密鍵と対の公開鍵の、認証局１２から発行された自公開鍵証明書と、この端末装置１１が利用する認証局１２の認証局証明書とを保持する鍵保持部２５、及び、他の端末装置１１から受け取った署名付き電子文書と他公開鍵証明書を保持する検証対象保持部２６を有する。
【００３０】
制御部２３は、入出力部２０ｄを介してユーザから、電子文書保持部２４に保持してある電子文書の他のユーザへの送信の指示を受け付ける。送信の指示に対応して、制御部２３は、指定された電子文書を電子文書保持部２４から読み出し、これを署名付き文書作成部２１に渡す。署名付き文書作成部２１は、鍵保持部２５に保持されている秘密鍵を用いて、渡された電子文書に対する署名を生成する。そして、渡された電子文書に生成した署名を付与した署名付き電子文書を作成する。制御部２３は、署名付き文書作成部２１で作成された署名付き電子文書と、鍵保持部２５に保持されている自公開鍵証明書とを、通信部２０ｃを介して、ユーザから指示された送信先の端末装置１１へ送信する。
【００３１】
また、制御部２３は、通信部２０ｃを介して、他の端末装置１１から署名付き電子文書と他公開鍵証明書を受け取ると、これらを関連づけて検証対象保持部２６に保持させると共に、これらの検証を署名・証明書検証部２２に要求する。
【００３２】
この要求を受けて、署名・証明書検証部２２は、検証対象保持部２６に保持されている署名付き電子文書の署名を、関連付けて保持されている他公開鍵証明書を用いて検証する。そして、署名・証明書検証部２２は、署名付き電子文書の署名の検証に使用した他公開鍵証明書を検証対象証明書として、鍵保持部２５に保持する認証局１２の認証局証明書を用いて検証する。署名・証明書検証部２２は、検証対象証明書の署名の検証、有効期間が切れていないことの確認、検証対象証明書が失効しているかどうかの確認などの検証処理を実行する。
【００３３】
署名・証明書検証部２２は、検証対象証明書（検証対象の他公開鍵証明書）が失効しているかどうかを確認するために、検証サーバ１３に検証要求を送信する。検証サーバ１３から検証対象証明書が失効していないとの検証結果の受信を含めて、検証処理に成功した場合に、この検証対象証明書は有効であり、この検証対象証明書が添付されていた署名付き電子文書が正当なものであるとして、必要に応じて入出力部２０ｄを介して署名付き文書の署名及び検証対象証明書の検証結果を出力する。
【００３４】
図３に、認証局１２の構成を示す。認証局１２は、処理部３０ａ、記憶部３０ｂ、ネットワーク１４を介して他の装置と通信するための通信部３０ｃ、及び各種証明書等の入出力やこの認証局１２の操作者からの指示の受付や処理結果の出力を行う入出力部３０ｄを有する。
【００３５】
処理部３０ａは、公開鍵証明書を発行する発行部３１、発行部３１が発行した公開鍵証明書を管理する管理部３２、及び認証局１２の各部を制御する制御部３３を有する。
【００３６】
記憶部３０ｂは、発行部３１が発行した公開鍵証明書を保持する証明書データベース３４、証明書データベース３４に保持されている各公開鍵証明書の発行先が記述されている発行先管理リストを保持する発行先管理リスト保持部３５、および公開鍵証明書失効リスト（ＣＲＬ）を保持するＣＲＬ保持部３６を有する。
【００３７】
制御部３３は、入出力部３０ｄまたは通信部３０ｃを介して公開鍵証明書の発行依頼を受け付け、発行部３１に伝える。これを受けて、発行部３１は、発行依頼に対応する公開鍵証明書を作成し、認証局１２の秘密鍵を用いて、作成した公開鍵証明書に署名をする。作成した公開鍵証明書を入出力部３０ｄまたは通信部３０ｃを介して、郵送あるいは通信により、発行依頼元に渡す。また、発行した公開鍵証明書を証明書データベース３４に登録すると共に、その発行先（つまり発行依頼元）の情報を、発行先管理リスト保持部３５に保持されている発行先管理リストに記述する。証明書データベース３４に登録した公開鍵証明書と発行先管理リストの発行先の情報は、公開鍵証明書からその発行先の情報を参照できるように、また、発行した公開鍵証明書をその発行先の情報から参照できるように対応付けてある。
【００３８】
制御部３３は、入出力部３０ｄまたは通信部３０ｃを介して、公開鍵証明書の失効依頼を受け付け、管理部３２に伝える。これを受けて、管理部３２は、失効対象の公開鍵証明書を証明書データベース３４から削除すると共に、この公開鍵証明書の発行先の情報を、発行先管理リスト保持部３５に保持されている発行先管理リストから削除する。管理部３２は、失効依頼に基づいて証明書データベース３４から削除した公開鍵証明書のシリアルナンバーを記述した公開鍵証明書失効リスト（ＣＲＬ）を定期的に作成し、これをＣＲＬ保持部３６に保持する。なお、作成したＣＲＬには、この認証局１２が発行した公開鍵証明書の中で、有効期限内にもかかわらず失効した公開鍵証明書の、シリアルナンバー、失効した日時、および失効した理由がリストとして記述される。さらに、作成したＣＲＬには、次回のＣＲＬ作成予定時刻が記述され、この認証局１２の秘密鍵を用いて署名が付与される。次回作成するＣＲＬにも、有効期限内にもかかわらず失効した公開鍵証明書のシリアルナンバーなどが含まれるので、今回作成のＣＲＬと次回作成のＣＲＬとに同じ公開鍵証明書のシリアルナンバーなどが含まれることがある。すなわち、ＣＲＬ作成時点において有効期限内にもかかわらず失効しているすべての公開鍵証明書の情報(失効情報)がＣＲＬに含まれるので、検証サーバ１３などは最新のＣＲＬを利用する。また、認証局１２は、鍵情報の更新に関わらず、この認証局１２で発行した公開鍵証明書の失効情報をＣＲＬとして作成する。
【００３９】
制御部３３は、通信部３０ｃを介して、検証サーバ１３などの他の装置よりＣＲＬ取得要求を受け取ると、ＣＲＬ保持部３６に保持されているＣＲＬを、通信部３０ｃを介して、ＣＲＬ取得要求を発行した他の装置に送信する。
【００４０】
図４に、検証サーバ１３の構成を示す。検証サーバ１３は、処理部４０ａ、記憶部４０ｂ、ネットワーク１４を介して他の装置と通信するための通信部４０ｃ、および各種証明書等の入出力や検証サーバ１３の操作員からの指示の受付ける入出力部４０ｄを有する。処理部４０ａは、管理部４１、失効情報管理部４２、検証処理部４３、検証サーバの各部を制御する制御部４４を有する。記憶部４０ｂは、設定情報保持部４５、失効情報保持部４６、検証サーバ証明書保持部４７、および検証サーバの秘密鍵を保持する鍵保持部４８を有する。
【００４１】
管理部４１は、後述するように認証局証明書、ハッシュアルゴリズム、署名アルゴリズムを設定情報保持部４５へ登録する。また、登録した認証局証明書とハッシュアルゴリズムから、後述する認証局識別子テーブル６０を作成して失効情報保持部４６へ登録する。また、認証局証明書、検証サーバ証明書を登録し、後述する検証サーバ証明書識別テーブル９０を作成して検証サーバ証明書保持部４７へ登録する。さらに、管理部４１は、ＣＲＬ更新タイミング等の各種設定情報を、設定情報保持部４５へ登録する。
【００４２】
失効情報管理部４２は、通信部４０ｃを介して認証局１２にアクセスしてＣＲＬを取得し、取得したＣＲＬから、後述する失効情報テーブル８０を作成して失効情報保持部４６へ登録し、設定情報保持部４５に予め設定されたＣＲＬ更新タイミングに従ってＣＲＬを取得して失効情報保持部４６の失効情報テーブル８０を更新する。
【００４３】
検証処理部４３は、端末装置１１から通信部４０ｃを介して検証要求を受け付けると、失効情報保持部４６に保持される認証局識別子テーブル６０と失効情報テーブル８０を参照し、検証要求された検証対象証明書が失効しているか否かを確認する。そして、検証サーバ証明書識別テーブル９０を参照して、検証要求に対応する検証サーバ証明書を取得し、署名付き検証結果データを作成し、通信部４０ｃを介して端末装置１１へ応答する。なお、署名付き検証結果データには、鍵保持部４８に保持される検証サーバの秘密鍵を用いて署名が付与され、検証サーバ証明書とともに端末装置１１へ送信される。
【００４４】
なお、図２〜図４に示す端末装置１１、認証局１２、検証サーバ１３の各々は、例えば、図５に示すような、ＣＰＵ５１と、メモリ５２と、ハードディスク等の外部記憶装置５３と、ＣＤ−ＲＯＭ等の可搬性を有する記憶媒体５９から情報を読み取る読み取り装置５４と、ネットワーク１４を介して他の装置と通信するための通信装置５５と、キーボードやマウス等の入力装置５６と、モニタやプリンタ等の出力装置５７と、これらの各装置間のデータ送受を行う内部通信線６８とを備えた一般的な電子計算機上に構築される。
【００４５】
ＣＰＵ５１が、外部記憶装置５３からメモリ５２上にロードされた所定のプログラムを実行することにより、上述の各処理部を実現する。すなわち、通信部２０ｃ、３０ｃ、及び４０ｃは、ＣＰＵ５１が通信装置５５を利用することにより、入出力部２０ｄ、３０ｄ、及び４０ｄは、ＣＰＵ５１が入力装置５６や出力装置５７や読み取り装置５４を利用することにより、そして、記憶部２０ｂ、３０ｂ、及び４０ｂは、ＣＰＵ５１がメモリ５２や外部記憶装置５３を利用することにより実現される。また、処理部２０ａ、３０ａ、及び４０ａは、ＣＰＵ５１の処理プロセスとして実現される。
【００４６】
各処理部を実現する所定のプログラムは、予め外部記憶装置５３に格納されていても良いし、電子計算機が利用可能な記憶媒体５９に格納されており、読み取り装置５４を介して、必要に応じて読み出され、あるいは、電子計算機が利用可能な通信媒体であるネットワークまたはネットワーク上を伝搬する搬送波を利用する通信装置５６と接続された他の装置から、必要に応じてダウンロードされて、外部記憶装置５３に格納されるものであってもよい。
【００４７】
検証サーバ１３の動作には、認証局証明書、ハッシュアルゴリズム、署名アルゴリズムの設定動作と、ＣＲＬ更新動作と、公開鍵証明書の検証動作とがある。
【００４８】
まず、検証サーバ１３が実行する、認証局証明書、ハッシュアルゴリズムの設定動作について説明する。検証サーバ１３の操作者は、検証サーバ１３が対応する認証局１２の認証局証明書及びその認証局１２から発行された検証サーバ証明書の登録と、検証サーバ１３が受け付け可能なハッシュアルゴリズムの設定を行う。
【００４９】
検証サーバ１３の操作者は、入出力部４０ｄを介して認証局証明書を検証サーバ１３へ入力する。管理部４１は、入力された認証局証明書を設定情報保持部４５へ保持する。検証サーバ１３が複数の認証局１２に対応する（複数の認証局１２が発行するＣＲＬを取り込む）場合には、各認証局１２の認証局証明書を同様に登録する。また、ある認証局１２が秘密鍵を更新し、複数の認証局証明書を持っている場合は、新しい秘密鍵に対応する公開鍵情報を含む認証局証明書と古い秘密鍵に対応する公開鍵情報を含む認証局証明書（古い鍵が複数世代ある場合には、それら各世代の秘密鍵に対応する認証局証明書の、有効期間内のもの）の登録を同様に行う。その結果、設定情報保持部４５には、検証サーバ１３が対応する認証局１２の認証局証明書と、それらの認証局１２が秘密鍵を更新した場合には、有効期間を経過していない各世代の秘密鍵に対応する公開鍵情報を含む認証局証明書が保持される。
【００５０】
なお、認証局の鍵情報の更新に伴い、検証サーバ１３は認証局証明書を認証局１２からネットワーク１４を介して受信し、登録しても良い。
【００５１】
また、検証サーバ１３の操作者は、入出力部４０ｄを介して、この検証サーバ１３が受け付け可能なハッシュアルゴリズムのオブジェクト識別子（以下「ＯＩＤ」と記す。）を入力する。管理部４１は、入力されたハッシュアルゴリズムのＯＩＤを設定情報保持部４５へ保持する。検証サーバ１３が複数のハッシュアルゴリズムを受け付ける場合には、それら複数のハッシュアルゴリズムのＯＩＤを同様に設定する。また、ＯＩＤが登録された複数のハッシュアルゴリズムの一つを、基準ハッシュアルゴリズムとして登録する。なお、ＯＩＤで特定される各ハッシュアルゴリズムを実行するプログラムは、予め検証サーバ１３に格納されている。
【００５２】
検証サーバ１３の管理部４１は、登録された認証局証明書と設定されたハッシュアルゴリズムに基づいて、認証局識別テーブルを作成し、失効情報保持部４６へ保持する。
【００５３】
図６に、検証サーバ１３の失効情報保持部４６に設ける認証局識別テーブル６０の例を示す。認証局識別テーブル６０には、認証局証明書６１の名前に対応して、検証サーバ１３が受け付け可能なハッシュアルゴリズムを用いて求めた、認証局証明書に記述される主体者名（subject）のハッシュ値と公開鍵（subjectPublicKeyInfo）のハッシュ値とのペア６２〜６５、認証局証明書を発行した認証局の識別子６６を有する。
【００５４】
この認証局識別テーブル６０は管理部４１によって次のように作成される。管理部４１は、設定情報保持部４５に保持されている認証局証明書を取得し、取得した認証局証明書の名前を認証局識別テーブル６０の認証局証明書６１の行に記述する。管理部４１は、設定情報保持部４５に保持されているハッシュアルゴリズムのＯＩＤを参照し、そのハッシュアルゴリズムを用いて、認証局証明書に記述される主体者名（subject）のハッシュ値と公開鍵（subjectPublicKeyInfo）のハッシュ値とをそれぞれ計算し、この二つの値のペアを認証局識別テーブル６０の対応する箇所へ記述する。
【００５５】
図６では、検証サーバ１３は認証局１(ＣＡ１)、認証局２(ＣＡ２)、及び認証局３(ＣＡ３)が発行した公開鍵証明書の失効を確認するように設定されている。認証局１(ＣＡ１)は、鍵を更新し、更新後に発行した新しい認証局証明書（ＣＡ１＿ｎｅｗ証明書）と、更新前の古い認証局証明書（ＣＡ１＿ｏｌｄ証明書）とが有効である（有効期間内にある）ことを示している。認証局２(ＣＡ２)に関しても、認証局１(ＣＡ１)と同様に、新しい認証局証明書（ＣＡ２＿ｎｅｗ証明書）と、古い認証局証明書（ＣＡ２＿ｏｌｄ証明書）とが有効であることを示している。
【００５６】
また、検証サーバ１３が受け付け可能なハッシュアルゴリズムとして、ＳＨＡ−１、ＳＨＡ−２５６、ＳＨＡ−５１２、及び任意のハッシュアルゴリズムがあることを示している。これは、ハッシュ計算に用いるハッシュアルゴリズムとして現在は主にＳＨＡ−１が用いられているが、ＳＨＡ−１の脆弱化に伴い、今後はＳＨＡ−２５６やＳＨＡ−５１２等の他のアルゴリズムが端末装置１１で用いられる可能性に、検証サーバ１３は対応しなければならないからである。
【００５７】
認証局証明書が認証局１(ＣＡ１)の新しい認証局証明書（ＣＡ１＿ｎｅｗ証明書）を例に、主体者名（subject）のハッシュ値と公開鍵（subjectPublicKeyInfo）のハッシュ値のペアとの関係を説明する。ＣＡ１＿ｎｅｗ証明書に記述される主体者名（subject）のハッシュ値と公開鍵（subjectPublicKeyInfo）のハッシュ値とをＳＨＡ−１アルゴリズムを用いて計算し、計算結果のペアを認証局識別テーブル６０のＣＡ１＿ｎｅｗ証明書の列のハッシュ値（ＳＨＡ−１）６２の行に記述してある。同様に、ハッシュアルゴリズムＳＨＡ−２５６、ＳＨＡ−５１２、及び任意のハッシュアルゴリズムを用いて計算したハッシュ値のペアを認証局識別テーブル６０のハッシュ値（ＳＨＡ−２５６）６３の行、ハッシュ値（ＳＨＡ−５１２）６４の行、及びハッシュ値（任意のハッシュアルゴリズム）６５の行に記述してある。
【００５８】
基準ハッシュアルゴリズムで計算された、認証局証明書に記述される主体者名（subject）のハッシュ値を認証局証明書の認証局識別子６６とする。図６では、基準ハッシュアルゴリズムをＳＨＡ−１としている。認証局１(ＣＡ１)場合で説明すると、鍵の更新に伴って、新しい認証局証明書（ＣＡ１＿ｎｅｗ証明書）と古い認証局証明書（ＣＡ１＿ｏｌｄ証明書）との間で、公開鍵（subjectPublicKeyInfo）のハッシュ値は異なるが、認証局１(ＣＡ１)は同じであるので、その主体者名（subject）のハッシュ値「12345」も同じである。
【００５９】
なお、基準ハッシュアルゴリズムにより計算した、主体者名（subject）のハッシュ値と公開鍵（subjectPublicKeyInfo）のハッシュ値とのペア６２を認証局証明書識別子として用いる。
【００６０】
次に、証明書検証サーバ１３が実行する、署名アルゴリズムの設定動作について説明する。
【００６１】
検証サーバ１３の操作者は、認証局１２が発行した検証サーバ証明書を用いて検証結果に署名を付与する際の署名アルゴリズムを、検証サーバ証明書を発行した認証局１２によって定められた規定に従って設定する。その規定は、検証結果への署名アルゴリズムとして、認証局証明書の署名アルゴリズム、検証サーバ証明書の署名アルゴリズム、及びＣＲＬの署名アルゴリズムのいずれか一つを特定するものである。管理部４１は、設定された署名アルゴリズムを設定情報保持部４５へ保持する。
【００６２】
検証サーバ１３の操作者は、入出力部４０ｄを介して認証局証明書と検証サーバ証明書を検証サーバ１３へ入力する。検証サーバ１３が複数の認証局１２に対応する（複数の認証局１２が発行するＣＲＬを取り込む）場合には、認証局１２の認証局証明書とその認証局１２が発行した検証サーバ証明書を同様に入力する。また、認証局１２が秘密鍵を更新し、複数世代の認証局証明書を発行している場合は、新しい秘密鍵に対応する認証局証明書と古い秘密鍵に対応する認証局証明書、また新しい秘密鍵の認証局１２から発行された検証サーバ証明書と古い秘密鍵の認証局１２から発行された検証サーバ証明書（古い鍵が複数世代ある場合には、それらの秘密鍵の認証局証明書とそれらの認証局１２から発行された検証サーバ証明書のうち、有効期間内のもの全て）の入力を同様に行う。その結果、検証サーバ証明書保持部４７には、検証サーバ１３が対応する全ての認証局１２の認証局証明書とそれらの認証局１２から発行された全ての検証サーバ証明書と、それらの認証局１２が秘密鍵を更新している場合には、有効期間内の全ての世代の秘密鍵に関する認証局証明書とそれらの認証局１２から発行された全ての検証サーバ証明書が登録される。なお、認証局証明書の入力は、前述の設定情報保持部４５へ保持する場合と兼ねて、一度の入力にすると効率的である。
【００６３】
検証サーバ１３の管理部４１は、設定された署名アルゴリズムと登録された認証局証明書および検証サーバ証明書に基づいて、検証サーバ証明書識別テーブルを作成し、設定情報保持部４５へ保持する。
【００６４】
図９に、検証サーバ証明書識別テーブル９０の例を示す。検証サーバ証明書識別テーブル９０には、認証局証明書識別子９１に対応して、認証局証明書ファイル名９２、検証サーバ証明書ファイル名９３、及びレスポンス署名アルゴリズム９４を有する。
【００６５】
認証局証明書識別子９１は、基準ハッシュアルゴリズムを用いて、認証局証明書に記述される主体者名（subject）のハッシュ値と、公開鍵（subjectPublicKeyInfo）のハッシュ値とをそれぞれ計算し、この二つの値のペアであり、図６に示す認証局識別テーブル６０の各認証局証明書識別子６２と同じである。図９に示す例は、図６に示す認証局識別テーブル６０の各認証局証明書識別子６２に対応して、検証サーバ証明書識別テーブル９０の列を構成している。
【００６６】
管理部４１は、各認証局証明書識別子９１に対応して、認証局証明書のファイル名を認証局証明書ファイル名９２の行に記述し、検証サーバ証明書のファイル名を検証サーバ証明書ファイル名９３の行に記述する。
【００６７】
管理部４１は、設定情報保持部４５に保持されている、検証結果に付与する署名のアルゴリズムが、検証サーバ証明書を発行した認証局の認証局証明書の署名アルゴリズムと同一、認証局から発行された検証サーバ証明書の署名アルゴリズムと同一、及び認証局から発行されたＣＲＬの署名アルゴリズムと同一のいずれかを、それぞれの認証局証明書識別子９１に対応させて、レスポンス署名アルゴリズム９４の行に記述する。検証サーバ証明書に対して、検証結果に付与する署名アルゴリズムが認証局証明書の署名アルゴリズムと同一の場合、この署名アルゴリズムのＯＩＤを、対応する認証局証明書に記述される署名アルゴリズム（signatureAlgorithm）を参照して取得する。検証結果に付与する署名アルゴリズムが認証局から発行された検証サーバ証明書の署名アルゴリズムと同一の場合、この署名アルゴリズムのＯＩＤを、対応する検証サーバ証明書に記述される署名アルゴリズム（signatureAlgorithm）を参照して取得する。検証結果に付与する署名アルゴリズムが認証局から発行されたＣＲＬの署名アルゴリズムと同一の場合、この署名アルゴリズムのＯＩＤを、失効情報テーブル８０の署名アルゴリズムＯＩＤの列に記述されている値を参照して取得する。
【００６８】
このとき、検証サーバ証明書識別テーブル９０の認証局証明書識別子９１の行の任意の認証局証明書識別子をデフォルトとして定義し、検証対象証明書を発行した認証局の認証局証明書識別子が認証局識別テーブル６０に存在しなかった場合、デフォルトの検証サーバ証明書を利用して検証結果に署名を付与する。図９に示す検証サーバ証明書識別テーブル９０では、「12345/abcde」の認証局証明書識別子９１をデフォルトとしている。
【００６９】
検証サーバ１３の操作者は、予めＣＲＬ更新タイミングの設定を行う。具体的には、検証サーバ１３の操作者は、検証サーバ１３が対応する認証局ごとに、ＣＲＬを更新するタイミング（例えば一日一回ＣＲＬの更新を行う場合は「一日」）を、入出力部４０ｄを介して入力し、管理部４１がこのＣＲＬ更新タイミングを設定情報保持部４５へ登録する。
【００７０】
図７に、検証サーバ１３が実行するＣＲＬの更新処理のフローチャートを示す。失効情報管理部４２は、検証サーバ１３の操作者によって予め設定情報保持部４５に設定されたＣＲＬ更新タイミング（例えば１日）を経過すると（ステップ１００１）、通信部４０ｃを介してＣＲＬ取得要求を認証局１２へ送信する（ステップ１００２）。ＣＲＬ取得要求を受け付けた認証局１２は（ステップ１００３）、ＣＲＬに認証局１２の秘密鍵を用いて署名し、検証サーバ１３へ送信する（ステップ１００４）。このＣＲＬには、ＣＲＬを作成した時点の、認証局１２の名前（issuerName）、認証局１２の鍵情報（authorityKeyIdentifier）、認証局１２が発行した有効期間内の公開鍵証明書のうち、失効した公開鍵証明書のシリアルナンバー（userCertificate）、ＣＲＬの有効期間（ＣＲＬ作成日時、次回ＣＲＬ作成日時）等が記載されている。
【００７１】
検証サーバ１３の失効情報管理部４２は、認証局１２からＣＲＬを受信すると（ステップ１００５）、認証局証明書（認証局１２の公開鍵証明書）を用いて認証局の署名を確認した後、受信したＣＲＬが更新されたかどうかを確認する（ステップ１００６）。ＣＲＬには、認証局１２によるＣＲＬの作成日時が記載されているので、認証局１２から受信したＣＲＬの作成日時が、前回取得した認証局１２のＣＲＬの作成日時よりも新しくなっている場合、認証局１２のＣＲＬが更新されている。受信した認証局１２のＣＲＬが更新されていなければ、ステップ１００１へ進む。なお、認証局１２からはじめてＣＲＬを受信した場合には、ステップ１００７へ進む。
【００７２】
受信したＣＲＬが更新されている場合、失効情報管理部４２は、受信したＣＲＬに基づいて、失効情報テーブルの作成または更新を行い、失効情報テーブル８０を失効情報保持部４６へ格納する（ステップ１００７）。
【００７３】
図８に、失効情報テーブル８０の例を示す。失効情報テーブル８０には、認証局識別子８１に対応して、ＣＲＬの署名アルゴリズム（signatureAlgorithm）のオブジェクトＩＤ（ＯＩＤ）８２、ＣＲＬの有効期間（ＣＲＬ作成日時、次回ＣＲＬ作成日時）８３、失効した公開鍵証明書のシリアルナンバー（userCertificate）８４、および失効した公開鍵証明書のシリアルナンバー毎の失効日時８５と失効理由８６が格納される。
【００７４】
失効情報テーブル８０を次のように更新または作成する。失効情報管理部４２は、取得したＣＲＬに記述される発行者名（issuerName）および認証局鍵識別子（authorityKeyIdentifier）の値をキーにして、設定情報保持部４５に登録されている認証局証明書の中から、対応する認証局証明書を特定し、特定した認証局証明書を取得する。その認証局証明書から基準ハッシュアルゴリズムを用いて認証局識別子を求める。失効情報管理部４２は、求めた認証局識別子をキーにして、失効情報テーブル８０の認証局識別子８１欄から同じ認証局識別子を検索する。なお、同じ認証局識別子が存在しない場合には、新たな認証局１２のＣＲＬであると判断し、失効情報テーブル８０の認証局識別子８１欄へ、求めた認証局識別子を追加する。
【００７５】
このＣＲＬの署名アルゴリズム（signatureAlgorithm）及び有効期間（thisUpdate,nextUpdate）を、失効情報テーブル８０の検索した認証局識別子に対応する署名アルゴリズムのＯＩＤ８２欄及びＣＲＬ有効期間８３欄に各々記述または更新する。
【００７６】
ＣＲＬに記述される失効した証明書（revokedCertificates）の情報を失効情報テーブル８０へ、認証局識別子に対応付けて登録する。具体的には、ＣＲＬの失効した証明書（revokedCertificates）に記述されている、証明書のシリアルナンバー（userCertificate）を失効情報テーブル８０の失効した証明書のシリアルナンバー８４へ記述し、失効日時（revocationDate）を証明書失効日時８５へ記述し、失効理由（reasonCode）を証明書の失効理由８６へ記述する。なお、失効理由（reasonCode）は、その番号に対応する意味がRFC5280で規定されている。
【００７７】
ここで、たとえば、認証局識別子８１が「12345」の認証局１が、2006/9/30/24:00に鍵を更新し、更新前の古い認証局証明書（ＣＡ１＿ｏｌｄ証明書）に対応して認証局証明書識別子が「12345/aabce」であり、更新後の新しい認証局証明書（ＣＡ１＿ｎｅｗ証明書）に対応して認証局証明書識別子が「12345/abcde」であるとする。この場合、失効情報テーブル８０の失効した証明書のシリアルナンバー８４の欄にあるシリアルナンバー「3」及び「5」は鍵が更新される前に認証局１によって発行された公開鍵証明書のシリアルナンバーであり、シリアルナンバー「122」、「123」及び「200」は鍵が更新される後に認証局１によって発行された公開鍵証明書のシリアルナンバーであり、これらのシリアルナンバーは、鍵の更新の前後にかかわらず、現状の鍵(更新後の鍵)を用いている認証局証明書（ＣＡ１＿ｎｅｗ証明書）に対応したＣＲＬに含まれる。
【００７８】
以上のＣＲＬ更新処理は、検証サーバ１３が複数の認証局１２に対応する場合に、各認証局１２のＣＲＬ有効期間８３を参照して、ＣＲＬが新たに作成されたタイミングで実行される。
【００７９】
図１０及び図１１に、検証サーバ１３が実行する公開鍵証明書の検証処理のフローチャートを示す。端末装置１１の署名・証明書検証部２２は、他の端末装置１１からの電子文書に添付されていた公開鍵証明書(図２の説明時の他公開鍵証明書)が失効しているかどうかの確認のために、検証要求を作成し、通信部２０ｃを介して、検証サーバ１３へ送信する（ステップ２００１）。端末装置１１からの検証要求には、認証局１２の名前データと鍵データをそれぞれハッシュ計算した、認証局１２の名前情報（issuerNameHash）と認証局１２の鍵情報（issuerKeyHash）を含んでいる。
【００８０】
検証サーバ１３の検証処理部４３は検証要求を受信すると（ステップ２００２）、失効情報保持部４６に保持される認証局識別子テーブル６０と受信した検証要求を照合し（ステップ２００３）、対応するハッシュ値が存在するかどうかを確認する（ステップ２００４）。具体的には、検証要求に含まれる、検証対象証明書を特定する情報（CertID）のうち、ハッシュ値である認証局の名前情報（issuerNameHash）と認証局の鍵情報（issuerKeyHash）のペアが、認証局識別子テーブル６０にあるかを確認する。
【００８１】
検証要求に含まれるハッシュ値のペアが、認証局識別テーブル６０に存在しない場合（ステップ２００４）、この検証要求に対応する失効情報を持っていないので、検証処理部４３は、検証対象証明書の失効情報（CertStatus）を不明（unknown）とする検証結果データを作成する（ステップ２００５）。検証サーバ証明書識別テーブル９０からデフォルトの検証サーバ証明書ファイル名９３と署名アルゴリズム９４を取得し（ステップ２００６）、鍵保持部４８に保持されているサーバ証明書の鍵で検証結果に署名を付与して署名付き検証結果を作成し（ステップ２００７）、ステップ２１０７へ進む。
【００８２】
検証要求に含まれるハッシュ値のペアが、認証局識別テーブル６０に存在する場合（ステップ２００４）、検証処理部４３は、そのハッシュ値のペアに対応する、認証局証明書識別子を取得し（ステップ２００８）、認証局識別子を取得する（ステップ２００９）。
【００８３】
検証処理部４３は、検証要求と失効情報テーブル８０との照合を行う（ステップ２１０１）。具体的には、ステップ２００９で取得した認証局識別子をキーにして、失効情報テーブル８０の認証局識別子８１を検索し、取得した認証局識別子と同一の認証局識別子８１を特定する。次に、検証要求に含まれる検証対象証明書のシリアル番号（CertIDのserialNumber）と、特定された認証局識別子８１に対応する失効した証明書のシリアルナンバー８４を比較し、検証対象証明書のシリアル番号が、失効情報テーブル８０の失効した証明書のシリアルナンバー８４に記載されているかどうかを確認する（ステップ２１０１）。
【００８４】
検証要求に含まれる検証対象証明書のシリアル番号が失効情報テーブル８０に存在しない場合（ステップ２１０１）、検証処理部４３は、検証対象証明書の失効情報（CertStatus）を有効（good）とする検証結果データを作成し（ステップ２１０２）、ステップ２１０４に進む。
【００８５】
検証要求に含まれる検証対象証明書のシリアル番号が失効情報テーブル８０に存在する場合（ステップ２１０１）、検証処理部４３は、検証対象証明書の失効情報（CertStatus）を失効（revoked）とする検証結果データを作成する（ステップ２１０３）。
【００８６】
検証処理部４３は、検証要求と検証サーバ証明書識別テーブル９０との照合を行う。具体的には、ステップ２００８で取得した認証局証明書識別子をキーとして、検証サーバ証明書識別テーブル９０の認証局証明書識別子９１を検索し、取得した認証局証明書識別子と同一の認証局証明書識別子９１を特定する(ステップ２１０４)。検証処理部４３は、特定された認証局証明書識別子９１に対応する検証サーバ証明書ファイル名、署名アルゴリズムを取得する（ステップ２１０５）。検証処理部４３は、ステップ２１０５で取得した検証サーバ証明書ファイル名、署名アルゴリズムを利用し、鍵保持部４８に保持されている検証サーバ証明書の鍵で検証結果に署名を付与して署名付き検証結果を作成する（ステップ２１０６）。
【００８７】
検証処理部４３は、作成した検証結果データを、通信部４０ｃを介して、端末装置１１へ送信する（ステップ２１０７）。端末装置１１は検証サーバ１３から、検証要求に対応する検証結果データを受信し（ステップ２１０８）、検証対象証明書が失効しているかどうかを確認する。
【００８８】
以上の検証処理を、前述の例に対応させて認証局1が鍵を更新する前に発行したシリアルナンバー「5」を割り当てられた検証対象証明書と、鍵を更新した後に発行したシリアルナンバー「150」を割り当てられた検証対象証明書との具体例で説明する。
【００８９】
認証局1が鍵を更新する前に発行したシリアルナンバー「5」に関する検証要求に含まれる認証局の名前情報（issuerNameHash）と認証局の鍵情報（issuerKeyHash）のペアは「12345/aabce」であり、認証テーブル６０を参照すると、鍵を更新する前の古い認証局証明書（ＣＡ１＿ｏｌｄ証明書）に対応し、認証局証明書識別子６２は「12345/aabce」であり、認証局識別子６６は「12345」である。失効情報テーブル８０を参照すると、認証局識別子「12345」に対応して、検証要求に含まれる検証対象証明書のシリアルナンバー「5」が失効した証明書のシリアルナンバーとして存在するので、検証処理部４３は、検証対象証明書の失効情報（CertStatus）を失効（revoked）とする検証結果データを作成する。認証局証明書識別子「12345/aabce」をキーとして、検証サーバ証明書識別テーブル９０の認証局証明書識別子９１を検索し、対応する検証サーバ証明書ファイル名９３「/tmp/ser１＿old.cer」、署名アルゴリズム「ＣＲＬの署名アルゴリズムと同一」を取得する。検証処理部４３は取得した検証サーバ証明書ファイル名、及び失効情報テーブル８０の署名アルゴリズムのＯＩＤ８２で特定されるＣＲＬの署名アルゴリズムを利用し、鍵保持部４８に保持されている検証サーバ証明書の鍵で検証結果に署名を付与して署名付き検証結果を作成する。
【００９０】
認証局1が鍵を更新した後に発行したシリアルナンバー「150」に関する検証要求に含まれる認証局の名前情報（issuerNameHash）と認証局の鍵情報（issuerKeyHash）のペアは「12345/abcde」であり、認証テーブル６０を参照すると、鍵を更新した後の新しい認証局証明書（ＣＡ１＿ｎｅｗ証明書）に対応し、認証局証明書識別子６２は「12345/abcde」であり、認証局識別子６６は「12345」である。失効情報テーブル８０を参照すると、認証局識別子「12345」に対応して、検証要求に含まれる検証対象証明書のシリアルナンバー「150」は失効した証明書のシリアルナンバーとして存在しないので、検証処理部４３は、検証対象証明書の失効情報（CertStatus）を有効（good）とする検証結果データを作成する。認証局証明書識別子「12345/ abcde」をキーとして、検証サーバ証明書識別テーブル９０の認証局証明書識別子９１を検索し、対応する検証サーバ証明書ファイル名９３「/tmp/ser１＿new.cer」、署名アルゴリズム「認証局証明書の署名アルゴリズムと同一」を取得する。検証処理部４３は取得した検証サーバ証明書ファイル名、認証局証明書（ＣＡ１＿ｎｅｗ証明書）の署名アルゴリズムを利用し、鍵保持部４８に保持されている検証サーバ証明書の鍵で検証結果に署名を付与して署名付き検証結果を作成する。
【００９１】
以上の検証処理の例では、端末装置１１は認証局の名前情報（issuerNameHash）と認証局の鍵情報（issuerKeyHash）のペアを求めるために、ハッシュアルゴリズムとしてＳＨＡ−１を用いていることを前提に説明したが、端末装置１１がＳＨＡ−２５６やＳＨＡ−５１２のハッシュアルゴリズムを用いている場合は、認証テーブル６０を参照する際の対象とする行が変わるだけで、処理上の差異は生じない。
【００９２】
本実施形態によれば、検証サーバは、認証局が鍵を更新した場合でも、鍵の更新の前後に係らず認証局が発行した公開鍵証明書の有効性を検証できる。また、鍵の更新に係らず認証局を特定する認証局識別子を用いることにより、検証サーバは、認証局が複数の場合であっても、各認証局が発行した公開鍵証明書の有効性を検証できる。さらに公開鍵証明書の有効性を検証するための検証要求を送信する端末装置が用いるハッシュアルゴリズムが、端末装置によって変更されたとしても、検証サーバは、利用される可能性のある複数のハッシュアルゴリズムを持ち、その複数のハッシュアルゴリズムを用いたハッシュ値のペアを格納した認証局識別テーブルを設けることにより、認証局や認証局証明書を識別できる。
【図面の簡単な説明】
【００９３】
【図１】検証システムの構成を示す図である。
【図２】端末装置の構成を示す図である。
【図３】ＣＡ装置の構成を示す図である。
【図４】検証サーバの構成を示す図である。
【図５】端末装置、ＣＡ装置、検証サーバの各々のハードウェア構成例を示す図である。
【図６】認証局識別テーブルの例を示す図である。
【図７】検証サーバにおけるＣＲＬの更新処理のフローチャートである。
【図８】失効情報テーブルの例を示す図である。
【図９】検証サーバ証明書識別テーブルの例を示す図である。
【図１０】検証サーバにおける、公開鍵証明書の検証処理のフローチャートである。
【図１１】検証サーバにおける、公開鍵証明書の検証処理のフローチャートである。
【符号の説明】
【００９４】
１１：端末装置、１２：ＣＡ装置、１３：検証サーバ、１４：ネットワーク、２０ａ、３０ａ、４０ａ：処理部、２０ｂ、３０ｂ、４０ｂ：記憶部、２０ｃ、３０ｃ、４０ｃ：通信部、２０ｄ、３０ｄ、４０ｄ：入出力部、２１：署名付き文書作成部、２２：署名・証明書検証部、２３、３３、４４：制御部、２４：電子文書保持部、２５：鍵保持部、２６：検証対象保持部、３１：発行部、３２：管理部、３４：証明書ＤＢ、３５：発行先管理リスト保持部、３６：ＣＲＬ保持部、４１：管理部、４２：失効情報管理部、４３：検証処理部、４５：設定情報保持部、４６：失効情報保持部、４７：サーバ証明書保持部、４８鍵保持部、５０：内部通信線、５１：ＣＰＵ、５２：メモリ、５３：外部記憶装置、５４：読み取り装置、５５：通信装置、５６：入力装置、５７：出力装置、５９：可搬性を有する記憶媒体。
【図１】
0005329184.tif 000002
【図２】
0005329184.tif 000003
【図３】
0005329184.tif 000004
【図４】
0005329184.tif 000005
【図５】
0005329184.tif 000006
【図６】
0005329184.tif 000007
【図７】
0005329184.tif 000008
【図８】
0005329184.tif 000009
【図９】
0005329184.tif 000010
【図１０】
0005329184.tif 000011
【図１１】
0005329184.tif 000012