連載の第2回目（「電子証明書と認証局」）において、「証明書の廃棄」について簡単に述べた。この部分は実際にPKIに接する人々にとって誤解が多い部分であり、ここでもう一度「証明書の有効性」についてクローズアップしていきたい。
証明書のステータス
まず、証明書の「状態」について説明しよう。証明書は、大きく分けて「有効」と「無効（有効ではない）」状態が存在する。さらに、「無効」状態には「有効期限切れ」「廃棄（失効）状態」「一時停止（失効）状態」の3つのステータスがある。証明書（あるいはその鍵による署名データ）を受け取った側はその証明書が自分の信頼する認証局から発行されているかどうか、ということと同時にその証明書が「有効」な状態にあるかどうかを確認しなければならない。
クレジットカードの場合に例えて考えてみよう。
通常、クレジットカードを顧客が提示した場合、加盟店は当然のことながら自分の店が加盟しているクレジットカード会社から発行されたものかどうかを確認する。さらに、そのカードの有効期限が切れていないかどうかを確認する。有効期限はカードに書かれているので、それを見れば判断できる。そして次にクレジットカード会社に照会をかける。ここで、支払いの遅延があったりカードの紛失・盗難が届けられていたりすれば、そのカードを利用することはできないということになる。
電子証明書の場合もこれとまったく同じである。先ほど述べたように、証明書（あるいはその鍵による署名データ）を受け取ったら、
- その証明書が自分が信頼する認証局から発行されているか
- 有効期限は切れていないか
- 廃棄または一時停止状態にないか
を確認しなければならない。
では、証明書の無効状態についてもう少し詳細に見てみよう。
●証明書の有効期間切れ
先に書いたように、証明書にはその証明書の有効期間が書かれている。具体的には「notBefore」として有効期間の開始日が、「notAfter」として有効期間の終了日が書かれている。証明書をハンドリングするアプリケーションは、この領域を見て有効期間内かどうかを判断することになる。
証明書の有効期間は、例えばWindowsのアプリケーションからは画面1のような形で確認できる。また、IEの場合、SSLで接続する先のサーバの証明書が有効期間切れだった場合、画面2のような警告が表示されるようになっている。
●証明書の廃棄（失効）
まず、証明書が廃棄される要因について考えてみよう。
証明書が廃棄される要因については以下のようなものが考えられる。
- 加入者の鍵の紛失・盗難
- 証明書記載内容の変更
- 証明書を利用するサービスからの脱退
通常、証明書の発行を受けた者（加入者）は、上記のような事象が発生した場合には直ちに認証局に届け出なければならない。届け出を受けた認証局は、該当する証明書の廃棄作業を行う。
この場合、廃棄の届け出をしたのが証明書の持ち主本人であることを確認しなければならない。何者かが業務を妨害するために本人になりすまして廃棄要求を行っている可能性があるからだ。ただ、鍵が盗難された場合などは緊急性を要するケースもあるので、本人確認がされるまでは下記の「一時停止」のステータスにしておくようなこともありうる。
また、加入者側から届けるのではなく、認証局側が証明書の廃棄を行うことを決定するケースがある。主に次のような要因によるものだ。
- 認証局の鍵の危殆化
- 加入者の義務違反
- 証明書の誤発行
いずれにしても認証局は証明書の廃棄オペレーションを行い、その結果として後述するCRLに廃棄された証明書の情報が追加されることになる。
●証明書の一時停止（失効）
証明書には一時停止（Suspended）というステータスがある。これはどのような場合に使用されるのだろうか。一般的には、以下のようなものが一時停止の要因となる。
- 加入者の鍵の紛失・盗難の恐れがある
- 加入者からの失効要求があったが、本人確認や正規の手続きに時間がかかる
- ある程度の期間証明書を使用しないことがはっきりしている（例えば、社員証用証明書を長期休暇等で利用しない場合）
1番目の要因は、主に証明書再発行にかかる時間やコストを考慮したものだと考えればよいだろう。例えば、ICカードが見当たらないという状態だが、紛失したかどうか分からない。ただ、ICカードなので再発行するのにコストがかかる、というような場合には、ICカードが紛失・盗難されたのか、あるいは単に家に置き忘れただけなのかがはっきりするまで一時停止状態にしておく、というようなケースだ。
証明書の一時停止の場合も、廃棄の場合と同様に認証局でオペレーションを行い、CRLに「一時停止」というステータスで証明書の情報が追加される。
証明書の有効期間の設定
さて、話を証明書の有効期間に戻そう。
実際に証明書を発行してもらう加入者や、認証局を運営する側から見た場合、証明書の有効期間は「長ければ長いほどよい」ものだろう。加入者側から見れば有効期限切れに伴う証明書の更新の手続きが必要になるし、認証局を運用する側も定期的に証明書の更新の処理を行わなければならない。いっそ、有効期限なんてなければよいのに、と思われる方も多いのではないだろうか。証明書に有効期間を設定する一番大きな要因は、「暗号技術や鍵の強度」が、永久に確保されるものではない、というものだ。このように、有効期間を決める際にポイントとなるものが幾つかある。それについて見ていくことにしよう。
●鍵の強度
上記で述べたように、現在安全だといわれている鍵の長さでも、いつかは安全ではなくなる日がくる。問題は何をもって「安全」とするかだろう。各アルゴリズムとその鍵長について、どのくらいコストをかければどのくらいの期間で解読可能か、というようなデータが出ていたりする。例えば、国家予算並みのコストをかければＸ年で解読可能、というようなものだ。ここで、PKIによって守られるものにどのくらいの価値があるのか、ということを考える必要がある。例えば、100万円程度の価値の情報を得るために国家予算並みのコストをかけるものはいないだろう。このように情報の価値を考慮して、鍵の長さや有効期間を決定する必要がある。
●証明書の内容
証明書に記載されている内容が変更されたら、基本的には証明書を廃棄して再発行する必要がある。例えば社員証用の証明書に部署名を入れたときのことを考えてみよう。もし証明書の有効期間を5年に設定してしまうと、異動が多く発生する毎年4月に多くの証明書を廃棄し、再発行しなければならなくなってしまう。運用を考えるとこれはかなりの負担になるし、また後述するようにCRLのボリュームも大きくなってしまい、それをハンドリングするアプリケーションに大きな負担を強いることにもなりかねない。やはり、このようなケースでは証明書の有効期間は1年間とするのが妥当であろう。このように、証明書の内容に変更が起こる可能性や要因も考慮して有効期間を決めなければならない。
●付帯する契約などの期間
例えば、あるサービスに付随する形で証明書を発行している場合、そのサービスに関する契約が別途存在することが多い。もしこの契約が1年ごとに更新されるようなものだった場合、そのサービスに使用される証明書の有効期間はそれに合わせておくべきだろう。
●認証局の証明書の有効期間
もう1つ考慮しなければいけない大きな要因は、認証局の証明書の有効期間だ。以前にも述べたように、認証局自身も証明書を持っており、その証明書にも有効期間が存在する。通常、認証局は自身の証明書の有効期限を越えるような証明書を発行することはできない。逆に、認証局の証明書の有効期間を決定するためには、その認証局が発行する証明書にどのくらいの有効期間を設定しなければならないのかを慎重に検討する必要がある。
証明書廃棄リスト（CRL）
ここで、証明書廃棄リスト（Certificate Revocation List：CRLCRL）について見てみることにしよう。まず、証明書廃棄リストとは「有効期限を迎えていないにもかかわらず無効となった証明書のリスト」である。ここで重要なのは、有効期限を越えてしまった証明書の情報はCRLには入らない、ということだ。何かの要因で廃棄された証明書の情報がCRLに記載されたとしても、その証明書が有効期限を迎えた時点でCRLからは除外されることになる。
CRLの内容は証明書と同じくX.509で規定されている。主に図1のようなものだと考えればよいだろう。さらに、CRL全体に対してそのCRLを発行した認証局の署名がなされている。
画面3 CRLの内容を確認したところ。ダイアログの名称が「証明書失効リスト（CRL）」となっているが（Revocationの訳し方が違う）、本文中では「証明書廃棄リスト」で統一している（画面をクリックすると拡大表示します）
では、実際にCRLのチェックはどのように行われるのだろうか？ まず、CRLは認証局から一定周期で発行される（図2）。CRLを検証したいアプリケーションは以下のいずれかの方法でCRLを自分の環境にダウンロードする。
- LDAPまたはX.500での取得（ディレクトリサーバにCRLが格納されている場合）
- HTTPでのダウンロード（Webサーバ上にCRLが格納されている場合）
- FTPでのダウンロード（FTPサーバ上にCRLが格納されている場合≫）
このほか、認証局がメールなどに添付して配布するという方法もあるが、あまり現実的ではないだろう。
自分の環境にCRLをダウンロードしたアプリケーションは、取得した証明書の情報がないかどうか、CRLをサーチする。ここで問題点が2つある。
- CRLをダウンロードするタイミング
- CRLをサーチする時間
アプリケーションが証明書廃棄の確認を行う必要があるとき（つまり、署名付きトランザクションデータを受け取ったとき）に、毎回CRLをダウンロードするというのは、（アプリケーションの性質にもよるが）現実的ではないだろう。ネットワークのトラフィックも問題だし、CRLの検証自体にかかる時間が大きくなってしまう。CRLのサイズが大きくなれば問題はさらに大きくなる。
CRLには「次回CRLを発行するのは何月何日の何時何分の予定です」という情報が入っている。通常、認証局側は12時間に1回程度の周期でCRLを発行し、アプリケーション側は自分の環境にダウンロードしてあるCRLの「次回発行予定日時」をチェックして、それを過ぎていたら新しいCRLをダウンロードするような形で実装することになる。このとき、あまり発行周期を短くしてしまうとCRLのダウンロードが頻発することになってしまい、あまり長くすると廃棄がされてからCRLに反映されるまでのタイムラグが長くなってしまう。このタイムラグが長ければ長いほど、例えば盗まれた鍵を使用して不正が行われるリスクが高くなってしまうということになる。
次の問題がCRLをサーチする時間だ。CRLによる証明書の有効性の検証は、「バッチ的な」処理といわざるを得ない。アプリケーションは、自分の環境にダウンロードしてあるCRLを頭からサーチして、検証したい証明書の情報が存在するかどうかを確認する。CRLのサイズが大きくなればなるほどこのサーチにかかる時間が多くなってしまう。オンライントランザクションを処理するようなアプリケーションの場合、これが大きな問題になる可能性が高い。
●デルタ（差分）CRL
このような問題を解決しようとする1つの考え方が「デルタ（差分）CRL」というものだ。簡単にいうと、すべてのCRL（これをベースCRLという）を週に1回程度発行し、あとはこのベースCRLとの差分のCRLのみを発行する。これによってアプリケーションがダウンロードしなければならないCRLのサイズを小さくすることができる。ただし、検証するためにはベースCRLと差分CRLを合わせたものをサーチしなければならず、また一定間隔でファイルをダウンロードしなければならないという点は基本的には変わらない。
●CRLの置き場所
先にも書いたように、CRLは、
- ディレクトリサーバ
- Webサーバ
- ファイル（FTP）サーバ
などに置かれるのが一般的である。
証明書には、CRLの置いてある場所を示すための領域がある。CRL配布点（CRL Distribution Point）がそれだ（画面5）。これにより、アプリケーション側がCRLの場所を固定的に持つ必要がなくなるばかりでなく、CRLをある単位で分割し、それぞれ異なる場所に置くことが可能になる。例えば、複数のサービス向けに証明書を発行している認証局の場合、そのサービスごとにCRLを分割し、異なる場所に置くとともに、それぞれの証明書のCRL配布点にその置き場所を示しておく（図3）。各サービスのアプリケーションは、自分と関係のないサービス用の証明書の廃棄情報まで含んだCRLをダウンロードしたりサーチしたりしなくてもよくなるのだ。
OCSPレスポンダ
ここまで見てきたように、CRLを使用した証明書の検証は、オンライントランザクションにおけるモデル、特にクライアントサイドで証明書の検証を行わなければならない場合には、あまり向いていないといわざるを得ない。それに対応しようとしているのが、OCSP（Online Certificate Status Protocol）というプロトコルと、それを実装したOCSPレスポンダである。CRLを使用した証明書検証がバッチ的であるのに対し、この仕組みはまさにオンラインの世界で証明書の検証を行う仕組みだ。
では、OCSPを使用した証明書の検証の仕組みを見ていくことにしよう（図4）。
OCSPレスポンダといわれるサーバは、まずCRLを自分の中に取り込んでおく。証明書の有効性を検証するアプリケーションは、その証明書のシリアル番号をOCSPのプロトコルに載せた形でOCSPレスポンダに送る。すると、それに対するレスポンスとしてその証明書が廃棄されているかどうかをアプリケーション側に返してくれるのである。その際、OCSPレスポンダがボトルネックになってしまっては意味がないので、通常はCRLのサーチを高速化するような仕組みが実装されている。これにより、アプリケーション側に証明書を取り込む必要がないし、アプリケーションが自分でCRLをサーチする必要もない。さらに、CRLはOCSPレスポンダのみが入手すればよいので、OCSPレスポンダがCRLを入手する経路のみをうまく設計してやるだけで、CRLのやりとりにかかわる通信のオーバーヘッドを考慮する必要がなくなり、結果としてCRLの発行周期も短くできるのである。
●OCSPレスポンダの問題点
いいことづくめのようなOCSPレスポンダであるが、問題点がないわけではない。
最近では、「証明書パスにおける検証（Path validation）」にどのように対応するか？ という問題が論点になっている。「証明書パス」とは何だろうか。連載の第2回目（「電子証明書と認証局」）で、認証局の階層構造について説明した。認証局をさらに認証する上位の認証局が存在するということだ。このように認証局が階層化されていると、エンドユーザーの証明書の検証とそれを発行した認証局の証明書の検証、さらに上位の認証局の証明書の検証……というように、異なるOCSPレスポンダに対してアプリケーションが幾つもの問い合わせを投げなければならなくなってしまう（図5）。同じことが、相互認証（認証局と認証局がお互いに認証しあうことによって、信頼の幅を大きくすること）の場合でも発生する。
このような制御をアプリケーション側に強いるのは問題ではないかという議論があり、現在ではOCSPの拡張としてDPV（Delegated Path Validation）やDPD（Delegated Path Discovery）といった方法、SCVP（Simple Certificate Validation Protocol）という新たなプロトコルが考案され、インターネット上でドラフトとなっている。
●どのような方法をとるべきか？
ここまで述べてきたように、証明書の廃棄情報を検証するための仕組みは現在のところこれといって決め手がないのが現状だ。今後も、新たな仕組みが標準化される可能性は十分にある。ただ、PKIのモデルによってはCRLのハンドリングで十分な場合も多くあるだろうし、Path validationを必要としない場合も多いであろう。要は、自分たちがとろうとしているPKIのモデルに何が一番適しているかを検討し、選択していくのが賢明だといえるのではないだろうか。
Copyright © ITmedia, Inc. All Rights Reserved.