(57)【要約】【課題】ローカルネットワークに接続された複数の複合機の一つにおいて、公開鍵証明書の検証する際に、自機において有効と判断できなかった場合に、他機の過去の検証結果を利用して有効性の判断をする。【解決手段】複数の複合機１４がローカルエリアネットワーク１２に接続している。複合機１４で公開鍵証明書を検証できなかった場合には、過去の検証結果が記憶されている検証結果共有サーバ１８に当該公開鍵証明書の検証結果を検索する。この検索結果に基づき、取得した公開鍵証明書の有効性を判断する。また、自機における検証の結果を検証結果共有サーバに記録させる。【選択図】図１
2005311812.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークと、
前記通信ネットワークに接続された複数の情報機器と、
前記通信ネットワークに接続され、前記情報機器が行った当該公開鍵証明書の検証結果を記憶する検証結果共有装置と、
を含む、ネットワークシステムであって、
前記情報機器は、
公開鍵証明書の検証を行う証明書検証手段と、
前記証明書検証手段による検証が失敗したときに、前記検証結果共有装置に記憶された検証結果から、当該公開鍵証明書の検証結果を検索する検証結果検索手段と、  
前記検索の結果取得した検証結果に基づき、当該公開鍵証明書の有効性を判定する判定手段と、
を有する、
ネットワークシステム。
【請求項２】
請求項１に記載のネットワークシステムにおいて、
前記検証結果共有装置は、前記検証結果を、この検証が行われた日時と共に記憶し、
前記判定手段は、前記検証が行われた日時を参照して公開鍵証明書の有効性の判定を行う、
ネットワークシステム。
【請求項３】
請求項１または２に記載のネットワークシステムにおいて、前記検証結果共有装置は、前記検証に失敗した場合には、この検証結果をその理由と共に記憶する、ネットワークシステム。
【請求項４】
複数の情報機器と、これらが接続された通信ネットワークを含むネットワークシステムであって、
前記通信ネットワークからアクセス可能に設けられ、前記情報機器が行った当該公開鍵証明書の検証結果を記憶する記憶装置を含み、
前記複数の情報機器は、自機において検証に失敗した公開鍵証明書について、他の記憶装置で検証に成功しているかを照会し、成功していれば当該公開鍵証明書を有効とする、ネットワークシステム。
【請求項５】
通信ネットワークに接続される公開鍵証明書の検証結果共有装置であって、
前記公開鍵証明書の認証局に対する検証結果を記憶する検証結果記憶手段と、
前記通信ネットワークに接続される情報機器からの公開鍵証明書の検証結果の照会を受ける照会受付手段と、
前記紹介を受けた公開鍵証明書の検証結果について、前記検証結果記憶手段に記憶された検証結果を前記情報機器に返信する返信手段と、
を有する、検証結果共有装置。
【請求項６】
請求項５に記載の検証結果共有装置であって、
さらに、公開鍵証明書を認証局に対して検証する検証手段を備え、
前記検証結果記憶手段は、前記検証手段による検証結果を記憶する、
検証結果共有装置。
【請求項７】
請求項５に記載の検証結果共有装置であって、
さらに、前記情報機器から公開鍵証明書の検証結果を受信する受信手段を備え、
前記検証結果記憶手段は、前記前記受信手段で受信した検証結果を記憶する、
検証結果共有装置。
【請求項８】
ネットワークに接続された情報機器であって、
公開鍵証明書を認証局に対して検証する検証手段と、
前記検証が失敗した場合、ネットワークに接続され公開鍵証明書の検証結果を記憶している検証結果共有装置に対して当該公開鍵証明書の検証結果の照会を行う照会手段と、
前記検証結果の照会に対する検証結果共有装置からの返信を受ける照会結果受信手段と、
前記受信した照会結果から当該公開鍵証明書の有効性の判定を行う判定手段と、
を有する情報機器。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続されたコンピュータおよびその周辺機器等の情報機器における電子証明書の取扱いに関し、特にその証明書の有効性の検証に関する。
【背景技術】
【０００２】
近年、複写機、プリンタ、スキャナ、ファクシミリなどを一体とした複合機が普及しており、さらに複合機は、ＬＡＮ（ローカルエリアネットワーク）に接続され、ネットワーク上で共用される場合も多い。このような複合機には、単にコンピュータの周辺機器としてだけでなく、独立した情報機器としても機能するものがある。
【０００３】
また、ネットワーク上の情報の信頼性を保証するため公開鍵基盤を利用した電子証明書が用いられている。電子証明書は、ある公開鍵証明書（以下単に証明書と記す）の署名を行う上位の証明書、さらにその証明書の上位の証明書というように、いくつかの証明書の連鎖が形成され、最上位の証明書は証明書の発行者自らが署名する自己署名証明書となる。この証明書の連鎖が構築でき、最上位の証明書まで達することができれば、最初の、すなわち最も下位の証明書の信頼性が保証される。
【０００４】
下記特許文献１には、認証局における証明書の掲載に関する技術が開示されている。また、特許文献２には、認証局において、過去に発行され、現在無効な証明書についても、無効となった日時、理由と共に記憶しておくことにより、過去にさかのぼった時点において有効性を判断する技術が開示されている。
【０００５】
【特許文献１】特開２００１−２６５２１６号公報
【特許文献２】特開２００１−５７５５２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
前述の複合機は、単独で複写機、ファクシミリ機などとして使用する機能し、またコンピュータ周辺機器としてコンピュータからのプリント指令によりプリントを行ったり、画像を読み込んでコンピュータに送ったりする。さらに、この複合機から単独で他の周辺機器にアクセスしたり、ＬＡＮを介してインターネットにアクセスして、様々な情報を取得したりする場合、取得した情報の信頼性の確保が問題となる。複合機は、プリントジョブなどの指令を取得する際など一時的に情報を記憶しておくことしか想定されておらず、常時記憶しておく内容は限られているため、記憶部の記憶容量はさほど大きなものではない。このため、電子証明書をその機器の内部メモリに大量に保存することができず、末端の証明書から最上位の証明書までの各段階での証明書を全て保存することはできない。また、メモリに余裕があったとしても、上位の証明書が必要になるたびに、この証明書を取得するのは、処理の負担が増加する。
【０００７】
ＬＡＮに、ＬＤＡＰ(Lightweight Directory Access Protocol)サーバを設けて、ＬＡＮ内部の証明書を記憶すれば、複合機等の周辺機器の記録容量が大きくなくても、このＬＤＡＰサーバに記憶された証明書を用いて証明書の検証を行うことができる。しかし、ＬＤＡＰサーバは、ＬＡＮ内部の人に関する証明書を保存するのみで、ＬＡＮ外部の人の証明書や、過去の証明書や秘密鍵を保持するものではない。
【課題を解決するための手段】
【０００８】
本発明のネットワークシステムは、通信ネットワークと、前記通信ネットワークに接続された複数の情報機器と、前記通信ネットワークに接続され、前記情報機器が行った当該証明書の検証結果を記憶する検証結果共有装置と、を含み、前記情報機器は、証明書の有効性を判断する際に、前記検証結果共有装置に記憶された検証結果から、当該証明書の検証結果を検索する検証結果検索手段と、前記検索の結果取得した検証結果に基づき、当該証明書の有効性を判定する判定手段と、を有する。
【０００９】
検証結果共有装置は、ある証明書について照会があった場合、この証明書が記憶されその検証が過去において成功しているかを提示する。つまり、情報機器は、自機が所有する証明書による検証に失敗したとき、ＬＡＮを介して他の情報機器において検証した結果を流用することができ、個々の情報機器に記憶する情報量を減少させ、また処理負担軽減を図ることができる。
【発明を実施するための最良の形態】
【００１０】
以下、本発明の実施形態を、図面に従って説明する。図１には、インターネット１０に接続した社内ＬＡＮなどのローカルネットワーク１２の概略構成が示されている。ローカルネットワーク１２には、複数の複合機１４が接続されている。複合機１４は、コピー機に、外部からの情報に基づき印刷を行うプリンタとしての機能と、画像情報を読取るスキャナとしての機能を兼ね備えた装置である。さらに、ファクシミリとしての機能を備えてもよい。さらにまた、この複合機１４は、単独で、ネットワークを介して情報の送受信を行う機能を有し、コンピュータなどの情報機器としても機能する。これらの複合機１４を遠隔管理するために、ローカルネットワーク１２には管理用にコンピュータ１６が接続され、さらに証明書と、これの検証結果を記憶する記憶装置として検証結果共有サーバ１８も接続されている。検証結果共有サーバ１８については後述する。ローカルネットワーク１２は、ファイアウォール２０を介してインターネット１０に接続している。
【００１１】
複合機１４は内部メモリ２２を備え、この内部メモリ２２は自機を証明する証明書とこの証明書に対応する秘密鍵を保持する。記憶容量に余裕がある場合には、前記証明書を発行した認証局の証明書や、さらに上位の認証局の証明書を記憶しておくこともできる。また、さらに余裕がある場合には、証明書の廃棄リストを保持してもよい。複合機１４が証明書を取得した場合、自機の内部メモリ２２に記憶されている証明書、破棄リストが十分そろえば、取得した証明書の有効性を検証することができる。
【００１２】
近年、インターネット上に証明書検証サーバが設けられ、これを利用することができる場合がある。複合機１４は、自機内で証明書の有効性を検証できなかった（検証に失敗した）場合、前記証明書検証サーバにこの証明書を送付し、証明書の検証結果を得ることもできる。
【００１３】
複合機１４は、上記のように自機で、また外部の検証サーバで検証した結果を、検証対象となった証明書および検証した日時、さらに検証に失敗した場合はその理由と共に、検証結果共有サーバ１８に送付する。検証結果共有サーバ１８は受け取った公開鍵証明書の実体から、当該証明書を特定するのに必要な属性情報として例えば発行者名、シリアル番号、検証失敗理由（成功していれば空とする）、検証日時を関連づけて記憶する。
【００１４】
以上のように、証明書が、ある複合機（例えば複合機１４-1）で検証されると、その結果が共有サーバ１８に記憶される。他の複合機（以下、複合機１４-2）が取得した証明書を検証することになった場合、複合機１４-2は、まず自機内に保持している上位の証明書により検証を試みる。検証に成功すれば検証結果を前記と同様に検証結果共有サーバ１８に送り、サーバ１８は、証明書と検証結果が対応付けできるように記憶する。複合機１４-2が自機において、有効性を検証できなかった場合には、複合機１４-2は検証結果共有サーバ１８に、当該証明書本体、またはこれを特定するための属性情報を送り、サーバ１８内に記憶されている証明書を検索する。この証明書が見付かれば、これに関連づけられている検証結果を参照して、有効性の判断を行うことができる。
【００１５】
先に簡単に説明したように、証明書は、最下位に位置するエンドユーザが使用するＥＥ（エンドエンティティ）証明書を、これの上位の証明書において署名し、この上位の証明書をさらに上位の証明書が署名するという連鎖が形成され、最上位は認証局が自己署名した証明書となる。このＥＥ証明書から最上位の認証局証明書までの連鎖が証明書パスであり、このパスを構成する全ての証明書が登録されている状態が、パスが構築できた状態である。
【００１６】
証明書は、図２に示すように、基本領域、拡張領域及び署名データ領域からなる構造を有する。
【００１７】
基本領域には、証明書バージョン（１，２，３のいずれか）、シリアル番号（不定長のバイト列）、署名アルゴリズム（発行者が当該証明書に署名した際のアルゴリズム）、有効期間開始日時（年月日時分秒）、有効期間終了日時（年月日時分秒）、発行者名（ディレクトリのツリー構造（DIT:Directory Information Tree）に即した書式）、主体者名：同前、の各情報が含まれる。
【００１８】
また、拡張領域には、機関鍵識別子（署名を検証する際に使用する公開鍵を厳密に識別するためのもので発行者が署名に用いた鍵を特定できる）、主体者鍵識別子（主体者の公開鍵を厳密に識別するためのもので、主体者が複数の証明書を所持している場合に、目的の証明証を一意に識別することを可能にする）、鍵使用（公開鍵の使用目的を示す。例えば、認証局証明書は、KeyCertSignビットがＯＮでなければならない）、証明書ポリシー（証明書の用途に応じて、証明書のポリシーが設定される。複数設定可能）、ポリシーマッピング（認証局証明書のポリシーから下位の証明書のポリシーへのポリシーのマッピングを示すことで、下位の証明書で設定されているポリシーを認証局証明書のポリシーと同等であるとして認めることを要求する）、ポリシー制約（ポリシーマッピングの制限とパス中の各証明書に許容可能なポリシー識別子を要求する機能がある）、主体者別名（基本領域の主体者名とは異なる形式で主体者を識別する場合に使う別名）、基本制約（認証局証明書である場合に、ＴＲＵＥにすべきパラメータと、証明書パスを構築する上で、その証明書以降に続くことを許可する認証局証明書の数の上限を規定するパス長制限を持っている）、名前制約（発行する証明書の名前の制限をする。許可サブツリーと除外サブツリーが有り、発行される証明書は、許可サブツリーに含まれていなければならず、除外サブツリーに含まれていてはならない）の各情報が含まれる。なお、拡張領域の各項目は、必ずしも全ての証明書に存在するとは限らず、存在する場合に、検査の対象となる。
【００１９】
図３に、最上位認証局の証明書と中間認証局証明書とＥＥ証明書からなる証明書パスの例が示されている。なお、図においては「認証局」を「ＣＡ」で表している。最上位認証局の証明書は、発行者名と主体者名は同一となる。逆に、これらが同一であることが最上位認証局の証明書を示し。また、機関識別子と主体者識別子も同一となり、その証明書の公開鍵を示している。その最上位認証局が自分の秘密鍵で次の認証局（中間認証局）の証明書を署名する。そのときの中間認証局の証明書の発行者名は、最上位認証局であり、主体者名は中間認証局となる。また、中間認証局の機関識別子は最上位認証局の公開鍵を示し、主体者鍵識別子は当該中間認証局の証明書の公開鍵を示す。同様に中間認証局はＥＥ証明書の署名を行う。以上の場合は中間認証局が一つの場合であるが、二つ以上、また全くなく、最上位認証局が直接ＥＥ証明書に署名を行う場合もある。
【００２０】
以上のような証明書パスを検証する場合、個々の証明書単体だけで判断できる情報と、上位証明書がないと判断できない情報がある。
【００２１】
単体で判断可能な情報とは、例えば以下のような例がある。なお、（必須項目ではない）とは、全ての証明書に必ず存在するとは限らない情報であることを示す。しかしながら、その情報が存在する場合には、ここに書かれた条件を満たさなければならない。
１．証明書バージョン。現状のバージョンは３であり、１と２はありうるが、０以下や４以上は存在しない。
２．有効期間開始日時と有効期間終了日時。現在時刻と比較すれば、その証明書が未だ使えないのか、有効期間内であるか、期限切れであるかが判断できる。
３．基本制約のｃＡ（必須項目ではない）。その証明書の主体者名が認証局であれば、基本制約にあるｃＡという部分がＴＲＵＥでなければならない。
４．鍵使用（必須項目ではない）。その証明書の主体者名が認証局であれば、鍵使用の、keyCertSignビットがＯＮでなければならない。
【００２２】
上位証明書がないと判断できない情報には、以下のような例がある。
１．発行者名。当該証明書の発行者名が、上位証明書の主体者名と一致しなければならない。
２．機関鍵識別子（必須項目ではない）。当該証明書の機関鍵識別子が、上位証明書の主体者鍵識別子と一致しなければならない。
３．署名データ。当該証明書の署名データは、当該証明書に記載された署名アルゴリズムと上位証明書の公開鍵を用いて検証に成功しなければならない。具体的には、次のように行う。まず、当該証明書に記載された署名アルゴリズムにしたがい、当該証明書の先頭から署名データの直前までのデータ全体のハッシュ値を計算する。次に、当該証明書の署名データを上位証明書の公開鍵を用いて、復号する。この復号された値と上記ハッシュ値が一致するとき、署名検証に成功したことになる。一致しない場合、署名検証に失敗したという。
【００２３】
その他、パスにかかわる証明書全部を検討しなければならない情報として、以下のようなものがある。
１．名前制約（必須項目ではない）。発行された証明書は、発行した上位証明書が規定する許可サブツリーに含まれていなければならないし、同時に、規定された除外サブツリーに含まれていてはならない。これは、直属の上位証明書だけの制約ではなく、最上位から最下位まで全てのＣＡ証明書を縛るものになる。
２．ポリシーマッピング（必須項目ではない）。上位の証明書のポリシーマッピングでissuerDomainPolicyに与えられたポリシーを、subjectDomainPolicyに与えられたポリシーと同等としなければならない。たとえば、上位の証明書にポリシーが３つあり、これらをＡ，Ｂ，Ｃとし、発行された側の証明書にポリシーが２つあり、Ｂ，Ｄと記載されているとする。上位の証明書のポリシーマッピングに、issuerDomainPolicy = Ａ, subjectDomainPolicy = D と書かれていれば、発行された側の証明書ではポリシーマッピング成功とみなす。もし、上位の証明書のポリシーマッピングに、issuerDomainPolicy = A, subjectDomainPolicy = Ｅとかかれていれば、発行された側ではポリシーマッピングを失敗とする。
３．基本制約のパス長制限（必須項目ではない）。この項目は、自分の証明書の下に連なることのできるＣＡ証明書の数の上限を規定するものである。もし、この値がゼロであると、その下には、エンドユーザ（認証局ではない）の証明書のみが許されることになる。また、ここの値は各認証局証明書の中にそれぞれ別々の値を記載するができる。たとえば、認証局証明書が３つ連なり、最後にエンドユーザ証明書が続くパスの場合を考える。最上位の認証局証明書のパス長制限が２、第１の中間認証局の証明書のパス長制限が１、第２の中間認証局の証明書のパス長制限が０であるものは、成功となる。同じ証明書パスにおいて、最上位の認証局証明書のパス長制限が０だった場合には、それだけで失敗となる。同じ証明書パスにおいて、最上位のＣＡ証明書のパス長制限が２、第１の中間認証局の証明書のパス長制限が０だった場合にも、それだけで失敗となる。なお、中間認証局の証明書のパス長制限の値が、それより上位の認証局証明書のパス長制限の値より大きいことは問題なく認められる。たとえば、最上位の認証局証明書のパス長制限が２で、第１の中間認証局の証明書のパス長制限が５であっても問題ない。
【００２４】
図４には、本実施形態の通信ネットワークにおいて、複合機１４が取得した証明書の検証に関する流れが示されている。まず、証明書を取得した複合機１４は、自機内で、当該証明書の有効性について検証を行う（Ｓ１００）。すなわち、検証対象の証明書と自機内に保持した他の証明書により証明書パスが構築できるかを検証する。これができなければ、すなわち上位の証明書が欠落していた場合には検証に失敗したと判断する（Ｓ１０２）。具体的には、前述したように「証明書単独で判断可能な情報」「上位証明書がないと判断できない情報」「パスに関わる証明書全てを検討しなければならない情報」「破棄リストに記載されていないか」について確認を行う。それぞれの判断すべき情報に問題がなく、また破棄リストになければ、取得した証明書を有効と判断する。
【００２５】
また、証明書パスが構築できなかった場合、当該取得した証明書について、検証結果共有サーバ１８内に過去に検証された結果が記憶されていないか照会し、検証結果共有サーバ１８はこれを受けて受け、検索する（Ｓ１０６）。この検索は、複合機１４から証明書の実体をサーバ１８に送って、これと同一の証明書を検索するようにしてもよく、また証明書内の証明書を特定するための属性情報を送って、これに基づき検索を行うようにしてもよい。この属性情報は、検証結果共有サーバ１８に検証結果を記憶する際に、証明書と関連づけるための属性情報である。検証結果があれば（Ｓ１０８）、検証結果共有サーバ１８は、この情報を複合機１４に送信する。複合機１４は、それが有効であったかを判断し（Ｓ１１０）、記憶されていた検証結果が有効であれば、この証明書が有効であると判断する（Ｓ１０４）。また、ステップＳ１１０で、記憶されている検証結果が無効であった場合、検証対象の証明書が無効であると判定する（Ｓ１１２）。なお、ステップＳ１１０における判定は、記憶されている検証結果が検証された日時と、検証対象となっている暗号化文書の作成日時を比較して有効性の判定を行うことが好ましい。すなわち、暗号化文書の作成日時が、記憶されていた検証結果の日時より前であれば、文書の作成時点において証明書パスが構築されていたことになるので、有効と判断できる。
【００２６】
ステップＳ１０８で検証結果が検証結果共有サーバ１８内になかった場合、複合機１４は、インターネット上で検証を試みる（Ｓ１１４）。成否を判断し（Ｓ１１６）、成功すれば有効（Ｓ１０４）、失敗すれば無効（Ｓ１１２）と判断する。最後に、ステップＳ１００で行った自機内での検証結果を検証結果共有サーバ１８に対し記憶する（Ｓ１１８）。
【００２７】
ステップＳ１１８で、検証結果共有サーバ１８に結果を記憶するときに、一つの証明書に対して検証結果が異なる場合、どちらの結果を優先させるかを以下に説明する。
【００２８】
ある証明書についてパス検証を実施しようとしたときに、自機では、当該証明書の上位証明書の全てが登録されていない場合、パス構築ができずに検証失敗となる。しかし、他機には必要な上位証明書が全て登録されている場合、その他機では、パス検証に成功している場合もある。この場合、図４のフローチャートに従い、当該証明書は有効と判断されるので、これを記憶させる。したがって、「有効」が優先される。
【００２９】
また、ある証明書についてパス検証に成功したのに、数日後、他機で検証に失敗したとする。失敗の理由が、パスの中のいずれかの証明書の期限切れであった場合、これはパス検証成功を優先させる。ただし、必要なら、期限切れとなった事実と期限切れが発見された日時を付記することも可能である。
【００３０】
また、ある証明書について自機上でパス検証を行ったところ、パスの構築ができたのに、たとえば、認証局証明書に基本制約項目が存在して、ｃＡがＦＡＬＳＥに設定されている場合や、名前制約で、認証局証明書が規定した許可サブツリーの中に、ＥＥ証明書の主体者名が含まれていない場合、また証明書ポリシーとそのマッピングで不一致が発生する場合など、パス検証に失敗する。たとえば名前制約の例の場合、パス検証において名前制約の検査を行わない実装がなされた複合機では、パス検証に成功することが考えられる。しかし、この場合、検証失敗の結果を優先する。
【００３１】
すなわち、同一の証明書について、基本制約、名前制約やポリシー関連の情報に関する理由によるパス検証失敗とパス検証成功の結果が存在する場合には、検証失敗を優先させる。
【００３２】
また、ある証明書について、ある時点でパス検証に成功しているものとする。次に数日後に、当該証明書を破棄することが記載された破棄リストが発行されたとする。この場合には、証明書は、検証成功を優先するが、破棄された日時を付記することが望ましい。一方、その証明書を用いて作成された暗号化データは、取り扱いが複雑になる。破棄リストに記載された以降に、当該証明書が使われて暗号化されたデータがあった場合、特に破棄リストに記載された破棄理由が鍵危殆や認証局危殆である場合には、上記暗号化や署名が不正になされた可能性があるので、それらデータは廃棄すべきである。暗号化データの扱いに関しては、そのデータの作成日時とパス検証成功日時、および、破棄リストの発行日時との関係に依存して優先される結果が異なることになる。
【００３３】
暗号化データの作成日＝2004年1月24日、パス検証成功日＝2004年2月1日、当該証明書破棄が記載された破棄リスト発行日＝2004年2月20日の場合、当該暗号化データは、有効とみなす。
【００３４】
パス検証成功日＝2004年1月24日、当該証明書破棄が記載された破棄リスト発行日＝2004年2月20日、暗号化データの作成日＝2004年2月24日の場合、当該暗号化データは、無効とみなす。
【００３５】
暗号化データの作成日時が、パス検証成功以降、当該証明書破棄が記載された破棄リスト発行以前の場合は、当該証明書が記載されていない破棄リスト発行日時が目安となる。
パス検証成功日＝2004年1月24日、暗号化データの作成日＝2004年2月1日、当該証明書の破棄が記載されていない破棄リスト発行日＝2004年2月20日、当該証明書破棄が記載された破棄リスト発行日＝2004年3月20日の場合、当該暗号化データは、有効とみなす。
【００３６】
パス検証成功日＝2004年1月24日、当該証明書の破棄が記載されていない破棄リスト発行日＝2004年１月25日、暗号化データの作成日＝2004年2月1日、当該証明書の破棄が記載されていない破棄リスト発行日＝2004年2月5日の場合、当該暗号化データは、無効とみなす。
【００３７】
すなわち、暗号化データが作成されてから、１度でも当該証明書の破棄が記載されていない破棄リストが発行されていれば、そのデータは有効とみなす。
【００３８】
以上の実施形態は、情報機器の機能を有する複合機について説明したが、これに限らずネットワークに接続されたコンピュータなどの情報機器が証明書の有効性の検証を行う場合にも適用できる。また、検証結果共有サーバがＬＡＮ内で共有される実施形態について説明したが、ＬＡＮの範囲を越え、インターネットを介して共有されるようにすることもできる。また、検証結果共有サーバ自身が照会を受けた証明書に関して、その有効性の検証を行うようにすることもできる。例えば、照会を受けた証明書についての検証結果が記憶されていない場合、サーバ自身が検証を行い、その検証結果について返信をするようにできる。
【図面の簡単な説明】
【００３９】
【図１】本実施形態のネットワークシステムの概略構成を示す図である。
【図２】証明書の構成を示す図である。
【図３】証明書パスの説明図である。
【図４】証明書の検証のフローを示すチャートである。
【符号の説明】
【００４０】
１２  ローカルネットワーク、１４  複合機、１８  検証結果共有サーバ、２２  内部メモリ。
【図１】
2005311812.tif 000003
【図２】
2005311812.tif 000004
【図３】
2005311812.tif 000005
【図４】
2005311812.tif 000006