JP4055815B1

JP4055815B1 - 情報処理装置、制御プログラム、情報処理システム

Info

Publication number: JP4055815B1
Application number: JP2006299850A
Authority: JP
Inventors: 竜彦横濱
Original assignee: Fuji Xerox Co Ltd; Fujifilm Business Innovation Corp
Current assignee: Fujifilm Business Innovation Corp
Priority date: 2006-11-06
Filing date: 2006-11-06
Publication date: 2008-03-05
Anticipated expiration: 2026-11-06
Also published as: US20080109653A1; JP2008118412A

Abstract

【課題】公開鍵証明書の効力情報の提供サーバが行う仕様変更に対応するための技術を構築する。
【解決手段】クライアントでは、提供サーバに対して要求形式に従って公開鍵証明書の効力情報を問い合わせ（Ｓ１２〜Ｓ２２）、応答結果を取得する（Ｓ２４）。そして、応答結果に含まれる効力情報に基づいて、問い合わせた公開鍵証明書の効力確認を行う。また、予期される応答形式と応答結果とを比較し（Ｓ２６）、必要であれば要求形式の再設定を行う（Ｓ３２〜Ｓ３６）。再設定では、検証サーバから、採用可能な要求形式と応答形式の組合せを記した形式情報が取得され、設定したい応答形式に対応した要求形式が検索される。
【選択図】図４

Description

本発明は、情報処理装置、制御プログラム、または情報処理システムに関する。

公開鍵証明書の効力をオンライン検証（通信回線を通じた検証）する技術が実用化されている。オンライン検証には、典型的には、RFC（Request For Comment）2560に規定されているＯＣＳＰ（Online Certificate Status Protocol）の規格が用いられる。このＯＣＳＰでは、規格が厳密には定められておらず、実装する者は、ある程度自由に仕様を定めることができる。

下記非特許文献１には、現在のＯＣＳＰを軽量化した規格が提案されている。この文献には、例えば、検証結果を事前生成してもよい旨の記載や、Ｎｏｎｃｅと呼ばれる拡張設定に不整合があることを基準として、応答の有効性を判定してはならない旨の記載がある。また、下記特許文献１には、オンライン検証を行うサーバの動作仕様を変更して、失効の確認要求に対する応答速度を速める技術が開示されている。

特開２００２−２３０２０１号公報 PKIX Working Group著, 「Lightweight OCSP Profile for High Volume Environments」, 2006年7月, Internet Engineering Task Force, http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-06.txt

本発明の目的は、公開鍵証明書の効力情報の提供先が行う仕様変更に対応するための技術を構築することにある。

本発明の情報処理装置の一態様においては、公開鍵証明書の効力情報の提供先から情報提供を受けるための要求形式、及び対応する応答形式を設定する設定手段と、前記提供先に対して前記要求形式に従って公開鍵証明書の効力情報を問い合わせ、応答結果を取得する応答結果取得手段と、前記応答結果に含まれる効力情報に基づいて、問い合わせた公開鍵証明書の効力確認を行う効力確認手段と、前記応答結果と前記応答形式との比較に基づいて、前記要求形式または前記応答形式を再設定する再設定手段と、を備える。

本発明の情報処理装置の一態様においては、さらに、前記提供先が受け付け可能な要求形式と、この要求形式に対応して前記提供先が情報提供を行う応答形式との組合せ情報を、前記提供先に問い合わせて取得する、組合せ情報取得手段を備える。

本発明の情報処理装置の一態様においては、前記再設定手段は、前記比較の結果、前記応答結果が前記応答形式を満たさない場合に、前記組み合わせ情報に基づいて、前記要求形式または前記応答形式を再設定する。

本発明の情報処理装置の一態様においては、さらに、特定の応答形式に従った応答結果を取得するために必要な要求形式を、前記提供先に問い合わせて取得する要求形式取得手段を備えることを特徴とする情報処理装置。

本発明の情報処理装置の一態様においては、前記再設定手段は、前記比較の結果、前記応答結果が前記応答形式を満たさない場合に、前記要求形式の情報に基づいて、少なくとも前記要求形式を再設定する。

本発明の制御プログラムの一態様においては、公開鍵証明書の効力情報の提供先から情報提供を受けるための要求形式、及び対応する応答形式を設定する設定手段と、前記提供先に対して前記要求形式に従って公開鍵証明書の効力情報を問い合わせ、応答結果を取得する応答結果取得手段と、前記応答結果に含まれる効力情報に基づいて、問い合わせた公開鍵証明書の効力確認を行う効力確認手段と、前記応答結果と前記応答形式との比較に基づいて、前記要求形式または前記応答形式を再設定する再設定手段、としてコンピュータを機能させる。

本発明の情報処理システムの一態様においては、公開鍵証明書の効力情報の提供先から情報提供を受けるための要求形式、及び対応する応答形式を設定する設定手段と、前記提供先に対して前記要求形式に従って公開鍵証明書の効力情報を問い合わせ、応答結果を取得する応答結果取得手段と、前記応答結果に含まれる効力情報に基づいて、問い合わせた公開鍵証明書の効力確認を行う効力確認手段と、前記応答結果と前記応答形式との比較に基づいて、前記要求形式または前記応答形式を再設定する再設定手段と、を備える。

請求項１の本発明によれば、効力情報の提供先で採用されている要求形式や応答形式の仕様が変更された場合に、要求形式あるいは応答形式を変更することが可能となる。

請求項２の本発明によれば、提供先で採用されている要求形式と応答形式の組合せを把握することが可能となる。

請求項３の本発明によれば、提供先で採用されている要求形式と応答形式の組合せの中から、適当な組合せを選択することが可能となる。

請求項４の本発明によれば、所望の要求形式で応答結果を得るための要求形式を把握することが可能となる。

請求項５の本発明によれば、所望の要求形式で応答結果を得るための要求形式を設定することが可能となる。

請求項６の本発明によれば、効力情報の提供先で採用されている要求形式や応答形式の仕様が変更された場合に、要求形式あるいは応答形式を変更するプログラムが提供される。

請求項７の本発明によれば、効力情報の提供先で採用されている要求形式や応答形式の仕様が変更された場合に、要求形式あるいは応答形式を変更するシステムが提供される。

以下に本発明の実施の形態を例示する。

図１は、本実施の形態にかかる証明書検証システム１０のハードウエア（機器などの物理的実体）構成の概略を説明するブロック図である。証明書検証システム１０は、ＯＣＳＰの規格または独自の規格に基づいて、公開鍵証明書の効力確認をオンラインで行うためのシステムである。図示した証明書検証システム１０では、公開鍵証明書の効力を問い合わせるクライアント（問い合わせる側の装置）２０，４０と、公開鍵証明書の効力について回答する検証サーバ（回答する側の装置）６０とを含んでおり、これらは、インターネットや電話回線などのネットワーク（通信網）８０によって通信可能に接続されている。

クライアント２０は、ＰＣ（パーソナルコンピュータ）などの汎用的な情報処理装置によって構築されている。具体的には、クライアント２０には、通信路たるバス２２が設けられ、このバス２２に対し、半導体メモリや磁気ディスクなどからなるメモリ（記憶装置）２４、演算制御機能を備えたＣＰＵ（中央処理装置）２６、ネットワーク８０を通じて外部装置と通信を行うネットワークインタフェース２８、画像表示を行うディスプレイ３０、及びユーザ入力を受け付けるキーボード３２などが接続されている。クライアント２０では、メモリ２４にインストールされたプログラムによってＣＰＵ２６の動作が規定される。そして、この結果、図２に示すように、ＣＰＵ２６に様々な処理機能が構築されるとともに、各ハードウエア構成要素にもＣＰＵ２６の制御の下、各種の処理機能が構築される。なお、プログラムのインストールは、クライアント２０の製造段階で行われてもよいし、その後に記録媒体や、ネットワーク８０を介して行われてもよい。すなわち、プログラムは、ＣＤ−ＲＯＭなどの記録媒体や、Ｗｅｂサイトなどを通じて提供され、これらから送信される信号を読み込むことでインストールされてもよい。

クライアント４０は、各種の画像処理機能を備えた情報処理装置であり、画像処理装置と呼ぶこともできる。クライアント４０には、クライアント２０と同様に、バス４２が設けられ、バス４２には、メモリ４４、ＣＰＵ４６、及びネットワークインタフェース４８が接続されている。また、バス４２には、画面接触による入力機能を備えた表示装置であるタッチパネルディスプレイ５０、用紙の光学的読み取りを行って画像データを生成するスキャナ（読取装置）５２、画像データに基づいて用紙に印刷を行うプリンタ（印刷装置）５４が接続されている。クライアント４０では、スキャナ５２やプリンタ５４を単体で動作させることができる。また、クライアント４０では、スキャナ５２で生成した画像データをネットワークインタフェース４８を通じて電子メール送信あるいはＦＡＸ送信する機能、電子メール受信やＦＡＸ受信した画像データをプリンタ５４で印刷する機能、スキャナ５２とプリンタ５４を連動させたコピー機能などを備える。クライアント４０は、このような複合的な画像処理機能を有することから、複合機と呼ばれることもある。

検証サーバ６０は、高速な情報処理機能と大容量のデータ記憶機能を備えた情報処理装置である。検証サーバ６０には、クライアント２０と同様に、バス６２が設けられ、このバス６２に対しては、メモリ６４、ＣＰＵ６６、ネットワークインタフェース６８、ディスプレイ７０、及びキーボード７２が設けられている。また、バス６２には大容量の磁気ディスク７４が接続されている。

続いて、図２を用いて、証明書検証システム１０の機能構成について説明する。ただし、図２では、クライアント４０については図示を省略している。

クライアント２０には、制御部１０２、検証要求生成部１０４、応答形式解析部１０６、対応関係情報取得部１０７、形式設定部１０８、効力確認部１１１、証明書記憶部１１２、送信部１１４、形式記憶部１１６、公開鍵暗号処理部１２３、受信部１２４、及びセキュリティポリシ記憶部１２６の各機能要素が構築されている。

制御部１０２は、各機能要素を制御する役割を果たしている。検証要求生成部１０４は、公開鍵証明書の効力確認をするための要求データを生成する。要求データの生成にあたっては、形式記憶部１１６に記憶されている要求形式についてのデータが参照されたり、公開鍵暗号処理部１２３による電子署名の付与が行われたりする。応答形式解析部１０６は、形式記憶部１１６に記憶されている応答形式についてのデータと応答データが備える形式とを比較して、両者の相違点を検出する。なお、応答データには、検証サーバ６０による形式不備の指摘が含まれることがあり、応答形式解析部１０６は、この形式不備の指摘を抽出することもできる。

対応関係情報取得部１０７は、組合せ情報取得手段の例であり、検証サーバ６０から、検証サーバ６０で採用されている要求形式と応答形式の対応づけに関する情報を取得する。典型的には、対応関係情報取得部１０７は、検証サーバ６０で採用されている要求形式と応答形式の組合せの情報である「対応関係情報」を取得し、形式記憶部１１６に記憶させる。しかし、対応関係情報取得部１０７は、例えば、応答形式を特定して検証サーバ６０に問い合わせを行い、この応答形式に従った検証結果を取得するために必要な要求形式についての情報を取得することもできる。

形式設定部１０８は、設定手段及び再設定手段の例であり、ユーザ指示等に基づいて形式記憶部１１６における未設定の形式を設定する他、応答形式解析部１０６の解析結果に基づいて、形式記憶部１１６に記憶された形式を変更する。形式の変更は、典型的には、対応関係情報取得部１０７に情報取得を行わせ、その結果に基づいて行われる。対応関係情報取得部１０７が対応関係情報を取得する態様の場合には、形式設定部１０８は所望の応答形式に対応する要求形式を対応関係情報から検索する。また、特定の応答形式（例えば既に設定済みの応答形式）を採用したい場合に、対応関係情報取得部１０７に対し、その応答形式に対応する要求形式の情報を取得させてもよい。なお、応答形式解析部１０６によって、検証サーバ６０による形式不備の指摘が抽出された場合には、形式設定部１０８は、この形式不備を修正するように変更態様を決定する。

効力確認部１１１は、応答データに記載された検証結果に基づいて、公開鍵証明書の効力確認を行う。証明書記憶部１１２は、認証局によって発行された各種の公開鍵証明書を記憶する。送信部１１４は、検証要求生成部１０４で生成された要求データを検証サーバ６０に送信する。

形式記憶部１１６は、検証要求生成部１０４が要求データの生成時に参照する標準要求形式１１８と個別要求形式１１９とを記憶する。標準要求形式１１８は、通常の形式を採用する検証サーバ向けの要求データを生成する際に用いられる形式であり、クライアント２０の構築時などに設定される。また、個別要求形式１１９は、通常とは異なる形式を採用する検証サーバ向けの要求データを生成する際に用いられる形式であり、形式設定部１０８によって設定される。形式記憶部１１６は、さらに、応答形式解析部１０６が応答データの形式の比較に用いる標準応答形式１２０と個別応答形式１２１を記憶する。標準応答形式１２０は、通常の形式を採用する検証サーバから得られた応答データの比較に用いられる形式であり、クライアント２０の構築時などに設定される。また、個別応答形式１２１は、通常とは異なる形式を採用する検証サーバから得られた応答データの比較に用いられる形式であり、形式設定部１０８によって設定される。個別応答形式１２１は、しばしば、個別要求形式１１９と組み合わせて設定される。すなわち、個別要求形式１１９に基づいて要求データを生成・送信した場合に得られる応答データに対しては、対応する個別応答形式１２１を用いて形式の比較が行われることが多い。なお、ここでいう「形式」には、データに含めるべき項目や項目への記載事項などを定めた書式、データに対する署名・暗号化の有無や署名・暗号化のアルゴリズムを定めた暗号方式、データの送受信に使用する通信プロトコル（通信規約）を定めた通信方式などが含まれる。

形式記憶部１１６は、さらに、対応関係情報１２２を記憶することができる。対応関係情報１２２は、対応関係情報取得部１０７によって取得された情報であり、検証サーバ６０で採用可能な要求形式と応答形式の組合せが記された情報である。

公開鍵暗号処理部１２３は、公開鍵暗号方式に基づいて、送信する要求データに暗号化や署名を行ったり、受信した応答データの復号化や署名検証を行ったりする。これらの処理には、必要に応じて、証明書記憶部１１２に記憶された公開鍵証明書が用いられる。受信部１２４は、検証サーバ６０から応答データを受信する。また、セキュリティポリシ記憶部１２６は、クライアント２０に設定されたセキュリティポリシを記憶する。セキュリティポリシとは、安全対策について定めた基準をいう。セキュリティポリシの設定例としては、通信先や通信プロトコルのような通信についての制限を行う態様や、外部から取得したデータの実行や加工を制限する態様などを挙げることができる。

図２に示した検証サーバ６０には、要求解析部１３０，証明書状態ＤＢ（データベース）１３２、検証結果生成部１３４，１３６が構築されている。要求解析部１３０は、クライアント２０の送信部１１４から受信した要求データを解析する。解析では、要求データが所定の形式で構成されていることを前提として、検証対象となる公開鍵証明書の抽出などが行われる。証明書状態ＤＢ１３２は、この検証サーバ６０が担当する各公開鍵証明書の効力情報が格納されたデータベースである。

また、検証結果生成部１３４は、検証対象となる公開鍵証明書の効力情報を証明書状態ＤＢ１３２から取得して、応答データを生成する。検証結果生成部１３４には、対応関係情報１３５が記憶されている。対応関係情報１３５は、検証サーバ６０上において採用されている要求形式と応答形式の組合せを記した情報である。すなわち、対応関係情報１３５には、どのような要求形式からなる要求データを取得した場合に、どのような応答形式からなる応答データを生成するかという組合せが設定されている。検証結果生成部１３４は、この対応関係情報１３５に設定されている形式で応答結果を生成し、クライアント２０に送信する。対応関係情報で採用される仕様は、基本的には長期にわたって固定される。しかし、技術的理由や運用上の理由などによって、変更されてもよい。図においては、形式変更により検証結果生成部１３４に代えて、新たな対応関係情報１３７が設定された検証結果生成部１３６の構築が行われている。なお、対応関係情報の変更は、応答データを生成する応答形式の変更であってもよいし、受け付け可能な要求データの形式を定めた要求形式の変更であってもよい。

ここで、図３を用いて、対応関係情報の例を説明する。図３は、図２に示した検証サーバ６０が記憶する対応関係情報１３５，１３７や、クライアント２０が記憶する対応関係情報１２２の例を示す図である。図示した対応関係情報には、要求形式と応答形式の組合せがｎ個設定されている。具体的には、要求形式Ａ，Ｂ，．．．，Ｃに対してそれぞれ応答形式Ｘ，Ｙ，．．．，Ｚが設定されている。すなわち、要求形式Ａ，Ｂ，．．．，Ｃに従って生成された要求データに対しては、それぞれ、応答形式Ｘ，Ｙ，．．．，Ｚに従った応答データを生成すべき旨が設定されている。

続いて、図４のフローチャートを参照しながら、図２に示した証明書検証システム１０の動作について説明する。

クライアント２０では、証明書記憶部１１２に格納された公開鍵証明書を使用する際などに、公開鍵証明書が失効しているか否かを検証サーバ６０に問い合わせることがある。例えば、ユーザ指示に基づいて電子メールの暗号送信を行う場合には、暗号に用いる公開鍵証明書の効力について問い合わせが行われる。問い合わせにあたっては、検証要求生成部１０４は、公開鍵証明書の記載を読み取って、検証サーバ６０のＵＲＬ（ネットワーク上のアドレスなどネットワーク上の通信先を特定する情報）を取得する（Ｓ１０）。公開鍵証明書を発行する認証局では、その公開鍵証明書の最新の効力情報を提供するための検証サーバを設けることがあり、公開鍵証明書中には検証サーバのＵＲＬが示されている。なお、問い合わせる効力情報は、典型的には失効したか否か（有効か否か）を表す失効情報（有効情報）であるが、失効期限（有効期限）がいつかを表すような失効期限情報（有効期限情報）などであってもよい。

検証要求生成部１０４は、取得したＵＲＬに関連づけられた要求形式を形式記憶部１１６において検索する（Ｓ１２）。すなわち、形式記憶部１１６に記憶された個別要求形式１１９が、問い合わせ先となる検証サーバ用の要求形式か否かを調べる（Ｓ１４）。そして、この検証サーバ用の要求形式が存在する場合にはその要求形式を取得し（Ｓ１６）、存在しない場合には標準要求形式１１８を取得する（Ｓ１８）。検証要求生成部１０４では、取得した要求形式に基づいて、検証要求をするための要求データを生成する（Ｓ２０）。要求データの生成にあたっては、要求形式に定められている場合には、公開鍵暗号処理部１２３よる電子署名の付与が行われる。生成された要求データは、送信部１１４から検証サーバ６０に送信される（Ｓ２２）。

検証サーバ６０では、要求解析部１３０が、要求データを解析して、署名の検証、要求データの形式が受け入れられるものか否かの判定、及び、検証要求があった公開鍵証明書の特定などを行う。そして、要求データの形式が受け入れられるものである場合には、検証結果生成部１３４（あるいは１３６）は、証明書状態ＤＢ１３２から効力情報を取り出して応答データを生成し、クライアント２０に送信する。他方、要求データの形式が受け入れられないものである場合には、検証結果生成部１３４は、効力情報の代わりに、要求形式に不備がある旨を通知する応答データを生成して、クライアント２０に送信する。

クライアント２０では、受信部１２４が、検証サーバ６０から応答データを受信する（Ｓ２４）。受信した応答データに対しては、公開鍵暗号処理部１２３による署名検証が行われた後に、応答形式解析部１０６による解析が行われる（Ｓ２６）。解析では、まず、形式記憶部１１６から、要求データの生成に用いた要求形式に対応する応答形式が検索される。すなわち、標準要求形式１１８に基づいて要求データを生成した場合には、標準応答形式１２０が検索され、検証サーバに対応した個別要求形式１１９を用いた場合には、対応する個別応答形式１２１が検索される。続いて、要求データの形式が、検索された応答形式と比較される。

比較の結果、要求データの形式が応答形式と一致したり、許容範囲内で類似したりする場合には、応答データの形式は適合したものであると判断される。この比較結果に基づいて、さらに、応答データの信頼性が高いと評価することも可能である。他方、比較の結果、要求データの形式が応答形式と一致しなかったり、許容範囲を超えて非類似であったりする場合には、応答データの形式は不適合であると判断される。この場合には、例えば、別途署名検証に成功したことなどを根拠として、応答データ自体は信頼できるものと評価し、効力情報を信用するようにしてもよい。しかし、形式の不適合を重視して、応答データの信頼性に否定的な評価を与え、効力情報を受け入れないことも可能である。

応答データの形式が不適合であると判断される例としては、はじめて検証要求を行った先の検証サーバが独特な形式を採用している場合が挙げられる。この場合には、標準要求形式や標準応答形式では対応できず、応答データの形式が不適合であると判定される可能性がある。また、これまで対応できていた検証サーバにおいて形式の変更があった場合にも、応答データの形式が変更されてしまい、その結果応答データの形式が不適合であると判定される可能性がある。さらには、応答データに検証結果が含まれず、代わりに要求形式に不備がある旨が通知された場合にも、応答データの形式は不適合であると判定される。

応答形式解析部１０６では、これらの解析結果をもとに、要求形式の変更が必要か否かを判定する（Ｓ２８）。そして、要求形式の変更が必要でない場合には、効力確認部１１１が応答データに含まれる効力情報を抽出して処理を終了する（Ｓ３０）。ただし、応答形式解析部１０６では、要求形式の変更は必要ないが、応答形式の変更は必要であると判定することもある。その場合には、形式設定部１０８は、形式記憶部１１６の個別応答形式１２１に、検証サーバに対応した応答形式を生成する。なお、本来であれば要求形式の変更が必要であっても、変更すべき形式の候補がない場合や、元から存在しない場合には、形式の変更を行うことなく処理を終了する。

これに対し、要求形式の変更が必要であると判断された場合には、要求形式の変更が行われる。具体的には、対応関係情報取得部１０７が、検証サーバ６０から（変更後の）対応関係情報１３７を取得し、形式記憶部１１６に対応関係情報１２２として記憶させる（Ｓ３２）。そして、形式設定部１０８が、対応関係情報１２２を検索して、採用したい応答形式（例えば現行の応答形式）に対応する要求形式を見つけ出し、新しい要求形式として設定する（Ｓ３４）。形式設定部１０８では、必要に応じて、応答形式の変更も行う。そして、変更した要求形式や応答形式を、検証サーバのＵＲＬと関連づけて、形式記憶部１１６に記憶させる（Ｓ３６）。標準形式との差分だけを記憶させて、記憶量を低減させるようにしてもよい。クライアント２０では、変更後の形式に基づいて、ステップ２０以降の処理を繰り返す。

この過程を、図３に例示した対応関係情報に基づいて説明すれば次のようになる。まず、従来、要求形式Ａに基づく要求データで問い合わせたところ応答形式Ｙによる応答データが返ってきたとする。しかし、ある時、検証サーバにおいて、図３に例示した対応関係情報が採用されると、それ以降は、要求形式Ａに基づく要求データに対しては要求形式Ｘに基づく応答データが返されるようになる。そこで、クライアントでは、図３の対応関係情報を取得し、応答形式Ｙに基づく応答データを得るためには、いかなる要求形式を採用すべきか検索する。その結果、要求形式Ｂを採用すべきことが見出され、要求形式Ａから要求形式Ｂへの変更が行われる。対応関係情報を取得する代わりに、検証サーバに対し、応答形式Ｙに基づく応答データを得るためには、いかなる要求形式を採用すればよいかを直接問い合わせるようにしてもよい。

なお、対応関係情報において、一つの応答形式に対し複数の要求形式が設定されている場合も考えられる。この場合には、形式設定部１０８は、いずれの要求形式を採用するかを選択する必要がある。また、現行の応答形式が使用できなくなった場合にも、形式設定部１０８は、いずれの応答形式（そして要求形式）を採用するか選択する必要がある。この選択条件は様々に設定可能であり、例えば、ランダムに選択する条件や、対応関係情報における並び順に従って選択する条件を挙げることができる。また、セキュリティポリシ記憶部１２６を参照し、ここに記憶されたセキュリティポリシに反する形式変更を行わないように選択条件を設定してもよい。具体例としては、セキュリティポリシにおいて、送信時には必ず署名を付与するとの設定がなされている場合に、署名を付与しない応答形式を候補から除外する態様が挙げられる。

続いて、図５乃至図７を用いて、形式変更の例を説明する。

図５は、横軸を時間軸として、各時刻における要求データと応答データを模式的に示した図である。図においては、時刻ｔ０に、クライアント２０から検証サーバ６０に要求データ１５０が送信されている。要求データ１５０は、この時点でクライアント２０に設定されている要求形式に従って生成されており、効力確認を求める公開証明書を特定する項目１５２、その他の記載がなされる項目１５４、Ｎｏｎｃｅの設定がなされる項目１５６を含んでいる。このうち、項目１５２，１５４は必ず設けなければならない必須項目であり、項目１５６は、検証サーバ６０が許容している任意項目である。

検証サーバ６０は、この要求データ１５０を受け入れて、応答データ１６０を生成している。応答データ１６０には、項目１６２，１６４，１６６，１６８，１７０が設けられている。このうち、項目１６２〜１６６，１６８は必須項目であり、例えば項目１６４には公開鍵証明書の効力が「ｇｏｏｄ（有効）」である旨が記載され、項目１７０には応答データ１６０の改竄を防ぐための署名が付されている。他方、項目１６８は、要求データ１５０にＮｏｎｃｅの項目１５６があると設けられる任意項目であり、項目１５６のＮｏｎｃｅの値がそのままコピーされる。つまり、項目１６８は、要求データ１５０を受け付けた後に応答データが生成されたことの立証に用いられる項目である。

クライアント２０では、署名の検証を行って改竄がないことを確かめると、引き続いて応答形式の比較を行って、形式の適合性の判断を行う。図示した例では、クライアント２０は、Ｎｏｎｃｅの項目１５６を含む要求データを送信しているため、Ｎｏｎｃｅの項目１６８を含む応答データが返されたか否か（さらにはＮｏｎｃｅの値が送信したＮｏｎｃｅの値と一致するか否か）を確かめる。なお、形式の比較の精度は様々に設定することが可能であり、例えば、項目１６２〜項目１７０までの全ての項目が適切に含まれているか否か、言い換えれば、予期した応答形式からの逸脱あるいは変更がないかを詳細に比較してもよい。

検証サーバ６０の側では、応答データ１６０の生成は、クライアント２０からの要求を待ってＮｏｎｃｅを読み込んだ後で、リアルタイムで行わなければならない。このため、要求が集中すると、検証サーバ６０の負荷が増大するという問題が生じる。そこで、時刻ｔ１に、検証サーバ６０は、突如としてＮｏｎｃｅをサポートしないように仕様を変更している。つまり、要求データにＮｏｎｃｅの項目が含まれていても、応答データにはＮｏｎｃｅの項目を含まない（あるいは、固定値を与えたＮｏｎｃｅの項目を含める）ように仕様を変更している。これにより、検証サーバ６０では、クライアント２０から効力確認の要求がある前に、あらかじめ応答データを生成しておくことが可能となる。なお、このような仕様変更は、必ずしも架空の話ではなく、実際、著名な商用的ＯＣＳＰサーバにおいて過去に行われているものである。

その後、時刻ｔ２において、クライアント２０では、時刻ｔ０と同じ要求データ１５０を検証サーバ６０に送信している。これに対し、検証サーバ６０では、要求データ１５０におけるＮｏｎｃｅの項目１５６を無視して、応答データ１８０を生成している。すなわち、応答データ１８０には、項目１６２〜１６６，１７０が含まれるのみであり、Ｎｏｎｃｅの項目１６８は含まれていない。

クライアント２０では、応答データ１８０を受信した場合には、署名の検証には成功するものの、応答形式に適合していないと判定する。しかし、この場合に、クライアント２０では、直ちにユーザに指示を仰ぐことはせず、プログラミングされた設定に従って問題の解決を試みる。具体的には、クライアント２０は、まず、応答形式との比較に基づいて、応答データ１８０にはＮｏｎｃｅの項目１６８がないことを検出し、Ｎｏｎｃｅの項目１６８に関する要求形式の設定変更を試みる。具体的には、まず、時刻ｔ３に、検証サーバ６０から対応関係情報を取得する。そして、応答形式にＮｏｎｃｅの項目１６８を含むことのできる要求形式を検索する。図５の例では、しかし、応答形式にＮｏｎｃｅの項目１６８を含める要求形式が見つからない。そこで、クライアント２０では、Ｎｏｎｃｅの項目１６８を削除した応答形式を採用することに決定する。そして、対応関係情報から、その応答形式を得るための要求形式を検索する。その結果、要求形式にＮｏｎｃｅの項目１５６を含んでも含まなくてもよいことが明らかとなる。そこで、ここでは、不必要な項目を含まない設定であるＮｏｎｃｅの項目１５６を含まない要求形式が採用されている。

クライアント２０では、変更後の要求形式に従って、時刻ｔ４に、同じ公開鍵証明書の効力確認を行う要求データ１９０を送信している。要求データ１９０には、Ｎｏｎｃｅの項目１５６は含まれていない。したがって、検証サーバ６０ではＮｏｎｃｅの項目を無視するまでもなく、項目１６２〜１６６，１７０からなる応答データ２００を生成する。クライアント２０は、この応答データ２００に対しては、変更された応答形式、すなわちＮｏｎｃｅの項目が含まれていない応答形式を用いて形式の比較を行う。このため、応答データ２００の形式は応答形式と適合しているとの判断が下される。

なお、対応関係情報の取得を含む要求形式の再設定や、要求データの再送信は、前の応答データ１８０に対して形式の比較を行った直後に行うようにしてもよい。特に、前の応答データ１８０の信頼性に対して否定的な評価を行い、応答データ１８０に記された効力情報を採用しなかった場合には、信頼できる応答データの取得を急ぐ方がよいであろう。しかし、例えば、応答データ１８０の形式不適合があってもその信頼性を否定せず、署名検証の成功等を根拠として前の応答データ１８０に記された効力情報を採用する場合もありえる。この場合には、要求形式の再設定や要求データの再送信は、時刻ｔ２から比較的長い時間が経過した後に行うようにしてもよい。

図６は、図５と同様の図であり、横軸を時間軸として、各時刻における要求データと応答データを模式的に示している。図６の時刻ｔ０においては、クライアント２０は、要求データ２５０を検証サーバ６０に送信している。要求データ２５０は、証明書を特定する項目２５２と、その他の記載がなされる項目２５４とからなる。

検証サーバ６０は、この要求データ２５０を受け付けて、応答データ２６０を送信している。応答データ２６０は、項目２６２，２６４，２６６，２６８からなり、例えば項目２６４には公開鍵証明書の効力が「ｇｏｏｄ（有効）」である旨が記載され、項目２６８には応答データ２６０の改竄を防ぐための署名が付されている。要求データ２５０が備える形式は、クライアント２０が予期する応答形式である。

検証サーバ６０では、時刻ｔ１に、署名が付与された要求データしか受け付けないとの仕様変更を行っている。このため、その後の時刻ｔ２において、クライアント２０が要求データ２５０を送信すると、検証サーバ６０は、効力情報を含まない応答データ２７０を返信する。応答データ２７０は、「署名をつけてください」とのアドバイス情報を記した項目２７２と、署名がなされた項目２７４からなる。

クライアント２０では、応答データ２７０の解析を行い、応答データ２７０が、予期した応答形式とは異なる形式をもち、しかも効力情報を含まないことを検出する。しかし、クライアント２０では、「なんらかの理由により検証できませんでした」というエラーメッセージ表示などを行うのではなく、プログラミングに従ってエラーからの復帰を試みる。すなわち、クライアント２０は、時刻ｔ３において、項目２７２の記載に従って直ちに要求形式を変更し、変更後の要求形式に従って、署名の項目２８２が付された要求データ２８０を検証サーバ６０に送信する。そして、検証サーバ６０では、署名が付された要求データ２８０を受け付けて、時刻ｔ０と同じ項目２６２〜２６８からなる応答データ２９０を送信している。なお、時刻ｔ２に受信した応答データ２７０には効力情報が含まれていないため、通常は、応答形式の変更や再送信を行う時刻ｔ３は、時刻ｔ２の直後に設定される。

図７は、図５や図６と同様に、横軸を時間軸とする図である。ただし、この図では、要求データは示さず、応答データのみを示している。この例では、時刻ｔ０において検証サーバ６０からクライアント２０に対し、応答データ３００が送信されている。応答データ３００は、項目３０２，３０４，３０６，３０８からなり、項目３０４には公開鍵証明書の効力が「ｇｏｏｄ（有効）」である旨が記載され、項目３０８には応答データ３００の改竄を防ぐための署名が付されている。この署名は、ＭＤ５（Message Digest 5）というハッシュ関数を利用したアルゴリズムに従って生成されている。

検証サーバ６０は、時刻ｔ１に、ＭＤ５の代わりにＳＨＡ−２（Secure Hash Algorithm 2）というハッシュ関数を署名アルゴリズムで利用するように仕様を変更している。そして、その後の時刻ｔ２において、検証サーバ６０は、クライアント２０からの問い合わせに対し、応答データ３１０を送信している。応答データ３１０は、項目３０２，３０４，３０６，３１２からなる。すなわち、ＭＤ５による署名の項目３０８に代えて、ＳＨＡ−２による署名の項目３１２が設けられている点で、応答データ３１０は応答データ３００と異なっている。

クライアント２０では、この応答データ３１０の形式が、予期しないアルゴリズムからなる署名を含んでいることを検出する。そこで、時刻ｔ３において、検証サーバ６０から対応関係情報を取得し、従来と同様の応答データ３００を受信するための要求形式を探している。しかし、ここでは、そのような要求形式は見つからず、受け入れるべき応答形式を変更する必要性が生じている。このため、クライアント２０では、従来と同様の要求形式を採用することを考え、この場合に、応答形式がセキュリティポリシ記憶部１２６に設定されたセキュリティポリシを充足しているか否かを調べている。図示した例では、ＳＨＡ−２は受け入れ可能なハッシュ関数として規定されていることを想定しており、クライアント２０では、ＳＨＡ−２を含む応答データを正規の応答として認めるように応答形式を再設定する。なお、この例は、要求データを新たに送信しても同じ応答データ３１０が得られるため、応答データの再送信は必要なく、既に取得した応答データ３１０を単に受け入れるようにすればよい。

以上においては、証明書検証システム１０のクライアントとして、ＰＣ等の汎用的な情報処理装置からなるクライアント２０を例に挙げて説明を行った。しかし、通信機能と演算機能を持った情報処理装置であれば、一般に、証明書検証システム１０のクライアントになることが可能である。例えば、図１に示した画像処理装置たるクライアント４０も、クライアント２０と同様の機能が構築されれば、証明書検証システム１０のクライアントとして動作することができる。しかも、クライアント４０では、スキャナ５２やプリンタ５４と連携した一連の処理を行うことが可能となる。例えば、スキャナ５２で生成した画像データを暗号電子メールで送信するにあたって、画像データの生成、公開鍵証明書の効力確認、検証サーバの様式変更に対応した効力再確認、効力確認された公開鍵証明書による暗号化、及び電子メールの送信からなる一連の処理を、途中にユーザの指示を挟むことなく実行することが可能となる。

また、証明書検証システム１０のクライアントは、通信可能な複数のコンピュータハードウエアを用いた分散処理システムとして構築されてもよい。機能分散の一例としては、応答データに含まれた効力情報を解析して効力確認を行うコンピュータと、予期した応答形式と応答データの形式とを比較するコンピュータとを別々に構築する態様を挙げることができる。

なお、以上の説明においては、ある検証サーバからの応答データに形式の不適合が検出された場合には、この検証サーバを対象として、要求形式あるいは応答形式の設定を変更した。したがって、この検証サーバに対し、同じユーザが別の公開鍵証明書の効力確認を行ったり、別のユーザが同じまたは別の公開鍵証明書の効力確認要求を行ったりした場合にも、変更後の要求形式あるいは応答形式が採用される。

しかし、検証サーバが、効力確認要求を行ったユーザによって異なる応答を示すこともあり得る。一例としては、効力確認要求を行ったユーザの公開鍵証明書になんらかの不備があり、このユーザから行われた（一般には別の公開鍵証明書の効力確認をする）要求に対してのみ、検証サーバが通常とは異なる応答を示す態様を挙げることができる。このため、必ずしも、検証サーバ毎に要求形式あるいは応答形式を一律に変更する必要はないとも考えられる。

そこで、例えば、最初は、応答データの形式不適合が検出された場合にその要求を行ったユーザのみを対象として要求形式あるいは応答形式の再設定を行う。そして、所定の数（例えば、二人あるいは三人）のユーザに関しても同様の形式不適合が検出された段階で、全てのユーザを対象としてこの再設定結果を適用するという態様も有効であろう。また、あるユーザが自身について複数種類の公開鍵証明書を所有しており、そのうちの一つの公開鍵証明書を用いた検証確認要求に関して応答データの形式不適合が検出される場合もあり得る。この場合には、最初はこの公開鍵証明書のみを対象として要求形式あるいは応答形式の再設定を行い、所定の種類の公開鍵証明書に関しても同様の形式不適合が検出された段階で、全ての公開鍵証明書を対象としてこの再設定結果を適用するという態様も有効であろう。

証明書検証システムのハードウエア構成例を示すブロック図である。証明書検証システムの機能構成例を示すブロック図である。対応関係情報の例を示す図である。クライアントにおける処理の例を示すフローチャートである。要求データと応答データの対応関係の例を時系列で示した模式図である。要求データと応答データの対応関係の例を時系列で示した模式図である。応答データの例を時系列で示した模式図である。

符号の説明

１０証明書検証システム、２０，４０クライアント、２２，４２，６２バス、２４，４４，６４メモリ、２６，４６，６６ＣＰＵ、２８，４８，６８ネットワークインタフェース、３０，７０ディスプレイ、３２，７２キーボード、５０タッチパネルディスプレイ、５２スキャナ、５４プリンタ、６０検証サーバ、７４磁気ディスク、８０ネットワーク、１０２制御部、１０４検証要求生成部、１０６応答形式解析部、１０７対応関係情報取得部、１０８形式設定部、１１１効力確認部、１１２証明書記憶部、１１４送信部、１１６形式記憶部、１１８標準要求形式、１１９個別要求形式、１２０標準応答形式、１２１個別応答形式、１２２，１３５，１３７対応関係情報、１２３公開鍵暗号処理部、１２４受信部、１２６セキュリティポリシ記憶部、１３０要求解析部、１３２証明書状態ＤＢ、１３４，１３６検証結果生成部。

Claims

公開鍵証明書の効力情報の提供先から情報提供を受けるための要求形式、及び対応する応答形式を設定する設定手段と、
前記提供先に対して前記要求形式に従って公開鍵証明書の効力情報を問い合わせ、応答結果を取得する応答結果取得手段と、
前記応答結果に含まれる効力情報に基づいて、問い合わせた公開鍵証明書の効力確認を行う効力確認手段と、
前記応答結果と前記応答形式との比較に基づいて、前記要求形式または前記応答形式を再設定する再設定手段と、
を備えることを特徴とする情報処理装置。
請求項１に記載の情報処理装置において、
さらに、前記提供先が受け付け可能な要求形式と、この要求形式に対応して前記提供先が情報提供を行う応答形式との組合せ情報を、前記提供先に問い合わせて取得する、組合せ情報取得手段を備えることを特徴とする情報処理装置。
請求項２に記載の情報処理装置において、
前記再設定手段は、前記比較の結果、前記応答結果が前記応答形式を満たさない場合に、前記組み合わせ情報に基づいて、前記要求形式または前記応答形式を再設定することを特徴とする情報処理装置。
請求項１に記載の情報処理装置において、
さらに、特定の応答形式に従った応答結果を取得するために必要な要求形式の情報を、前記提供先に問い合わせて取得する要求形式情報取得手段を備えることを特徴とする情報処理装置。
請求項４に記載の情報処理装置において、
前記再設定手段は、前記比較の結果、前記応答結果が前記応答形式を満たさない場合に、前記要求形式の情報に基づいて、少なくとも前記要求形式を再設定することを特徴とする情報処理装置。
公開鍵証明書の効力情報の提供先から情報提供を受けるための要求形式、及び対応する応答形式を設定する設定手段と、
前記提供先に対して前記要求形式に従って公開鍵証明書の効力情報を問い合わせ、応答結果を取得する応答結果取得手段と、
前記応答結果に含まれる効力情報に基づいて、問い合わせた公開鍵証明書の効力確認を行う効力確認手段と、
前記応答結果と前記応答形式との比較に基づいて、前記要求形式または前記応答形式を再設定する再設定手段、
としてコンピュータを機能させることを特徴とする制御プログラム。
公開鍵証明書の効力情報の提供先から情報提供を受けるための要求形式、及び対応する応答形式を設定する設定手段と、
前記提供先に対して前記要求形式に従って公開鍵証明書の効力情報を問い合わせ、応答結果を取得する応答結果取得手段と、
前記応答結果に含まれる効力情報に基づいて、問い合わせた公開鍵証明書の効力確認を行う効力確認手段と、
前記応答結果と前記応答形式との比較に基づいて、前記要求形式または前記応答形式を再設定する再設定手段と、
を備えることを特徴とする情報処理システム。