証明書検証

電子政府を使用して申請などを行うユーザーは、何らかの形でGPKIのブリ ッジ認証局と相互認証した認証局の証明書ユーザーになるべきだと考えられる。

しかし官職の署名の検証を行うのは、必ずしも証明書ユーザーとは限らない。

こうしたユーザー（企業や国民）の信頼点の扱いが明確でない。また、これに 関連して、国民等に信頼点をセキュアに配布するメカニズムがない。

(2) 認証局がユーザーに証明書検証手段を提供しているわけではないこと GPKIと相互認証を行う認証局は、信頼点を証明書ユーザーにセキュアに配 布できるかもしれないが、この信頼点を信頼する証明書ユーザーに証明書検証 を行う手段を提供しているわけではない。府省認証局は、府省毎に証明書検証 サーバーが用意されており、証明書検証の手段を提供していると言える。しか し、民間側などには、こういった証明書検証サーバーなどの仕組みが用意され ていない。これは、民間側の責任と捉えるべきと思われるかもしれないが、こ れは正しくない。問題は、電子政府としての証明書プロファイル以上の規約や フレームワークがないため電子政府全体として整合がとれた証明書検証が提供 できないことにある。

(3) GPKIに関連したプログラムの配布など

GPKIは、否認防止の署名のフレームワークとして機能している。GPKIの 相互運用性仕様書は、申請者の署名、官職の署名などを検証するための仕様を 提示している。しかし、これらの検証を行うプログラムの配布をセキュアに行 うための認証や、プログラム自体の検証のメカニズムは提供していない。現状 では、証明書ユーザーが、信頼点を保持していたとしても、GPKIに関連した プログラムをセキュアに配布するといったことには使用することは難しい。

2.5.3 証明書検証  

PKIにおいて、署名検証者が、署名文書など検証を行う場合、まず、署名者 の公開鍵が有効であるか調べる。これは、署名者の公開鍵が署名者に発行され た証明書に含まれることから、署名者の証明書を検証することになる。こうし た処理は、証明書検証と呼ばれている。

この証明書検証は、まず、署名検証者の信頼点から署名者側の証明書までの パスを構築する。そして次に、構築した認証パスの検証を行う。この認証パス の構築、認証パスの検証は、単純なモデルのPKIの場合は比較的簡単であるが、

広域な認証ドメインにおいて、高い保障レベルの検証を行うことは技術的にも 高度なものが要求される。

政府認証基盤 GPKIが採用しているブリッジモデルでは、GPKIのブリッジ 認証局が、新たな認証局と相互認証を行うことで、認証ドメインを拡大する。

このようなブリッジ認証局を中心とした信頼モデルは、認証ドメインを柔軟に 拡張していくことができる反面、高度な相互運用技術が要求される。ブリッジ モデルの場合、その信頼モデルの問題だけではなく、複数の異なるアーキテク チャのPKIを束ねることになる場合が多く、色々な意味でハイブリッドなアー キテクチャが要求される。例えば、商業登記認証局では、証明書失効検証に OCSP(Online Certificate Status Protocol)と呼ばれるメカニズムが採用され ており、他の認証局は、CRL(Certification Revocation List)と呼ばれるものが 使用されている。署名検証者は、このように、複数の証明書の失効検証のメカ ニズムを持つ必要がある。

エンドエンティティの証明書は、新たにブリッジ認証局と相互認証される認 証局からも発行されることになる。署名検証者は、このような新たな認証局が 発行するエンドエンティティ証明書の検証を要求される。こうした要求に対応 するため、GPKIのブリッジ認証局と相互認証する認証局は、政府認証基盤相 互運用性仕様書（GPKI相互運用性仕様書）に従い証明書を発行することによ り、異なるPKIドメインでの証明書検証を実現している。GPKI相互運用性仕 様書に記述されている認証パス構築、認証パス検証の仕様は、GPKIのアプリ ケーション共通の要求となる。

GPKI相互運用性仕様書に記述されているGPKIの証明書プロファイルや、

認証パス検証は、X.509や、RFC2459(RFC2459の最新版はRFC3280)に準拠 している。X.509やRFC2459は、非常に汎用的な仕様であるため、これらの 仕様を全て実装するころは極めて困難である。そのため、電子政府、及び、GPKI の中での相互運用を達成するための仕様としてX.509、RFC2459のサブセット の仕様をGPKI相互運用性仕様書の中で規定している。

GPKIのブリッジ認証局は、今後、LGPKI、公的個人認証基盤との相互認証 が予定されている。また、今後、海外との相互認証も行われるかもしれない。

こうした中、LGPKI、公的個人認証基盤などを取り込んだ、より広範囲なドメ インでの相互運用性を確保するためには、GPKI相互運用性仕様書に記述され た内容以上の証明書検証への要求があると考えられる。しかし、GPKI、LGPKI､ 公的個人認証基盤など電子政府全体の相互運用性を考慮した相互運用性仕様書 は、現在のところ存在しないと思われる。

GPKIの証明書検証における認証パス検証では、証明書ポリシーによる制御 を行っていることも重要である。認証パスの検証は、信頼点の公開鍵からの証 明書チェインの検証や、認証パスに含まれる証明書の失効のチェックだけが行 われていると思われがちであるがそれだけではない。GPKIの認証パス検証で は、認証パス中の証明書ポリシーのマッピングが行われ、また、署名検証者が、

受け入れポリシーの指定することにより、署名検証者の要求に応じた証明書ポ リシーの証明書のみが受け入れられる。

このように、証明書検証は、署名検証者にとって非常に大きな意味がある。

そのため、証明書検証を実行するソフトウェアの信頼性は非常に重要である。

証明書検証を実行するソフトウェアは、目的にあった認証パスの処理が行われ ることが重要になる。この処理に問題があると、例えば、保障レベルが高い証 明書のみを受け入れなければならない場面で、保障レベルが低い証明書を受け 入れてしまうといったことが生じる。

複雑な証明書検証の処理が要求されるブリッジモデルでは、証明書の検証を サーバーに依頼するようなモデルが考えられている。これは、単にパス構築、

パス検証などの処理が複雑で難しいという理由だけではない。検証するドメイ ンが広がることにより、パス構築、パス検証の仕様の変更などが考えられる。

こうした場合、クライアントのソフトウェアを入れ替えるといった影響を最小 限にするといった理由もある。実際、GPKIにおいても、こうした理由から GPKI証明書検証サーバーが用意されている。GPKIの証明書検証サーバーは、

府省毎に用意されており、府省の環境では、この証明書検証サーバーに証明書 の検証を委ねることができる。

証明書検証サーバーへの問い合わせプロトコルは、OCSPというプロトコル を独自拡張したものが使用されている。証明書検証サーバーからの応答には、

証明書検証サーバーの署名が付与されている。したがって署名検証者は、この 証明書検証サーバーからの応答に対する署名の検証を行う必要がある。証明書 検証サーバーは、府省のPKIドメイン内にある、すなわち、府省の署名検証者 と同じ信頼点を持っているため、比較的容易に検証ができるということになる。

電子政府の中で、証明書検証のメカニズムを確立していくことは、電子政府 の認証ドメインをシームレスに拡大していく上で非常に重要な意味を持つ。ま た、それだけに課題も多いと考えられる。

以下に、証明書検証に関して、今後の課題だと思われるものを列挙する。

(1) GPKIの証明書検証に関する、テスト環境、クライテイアが存在しないこ

と。

(2) 現在の証明書検証サーバーが、独自のサーバーアクセスプロトコルを採 用していること。

(3) 民間側での証明書検証（官の署名などに関する証明書検証）に問題が多 いこと   

(4) GPKIから更にLGPKI、公的個人認証基盤、海外との相互認証を見据え

た証明書検証の仕組みが必要なこと