公開鍵基盤
公開鍵証明書を発行する際、主に2つの作業を行う。1つ目は新しく証明書を発行してほしいエンティティ(以下、「加入者」)の本人確認などの登録手続きで、2つ目は加入者に実際に公開鍵証明書を発行することである。
この2つの手続きをいずれも認証局が行う運用形態もあるが、2つの手続きを別の機関で運用する運用形態もあり、この場合登録手続きを行う機関を登録局(RA、Registration Authority)、証明書発行手続きを行う機関を発行局(IA、Issuing Authority)という。
ただし「発行局」という言葉は実際にはあまり使われていず、発行局のことを「認証局」と呼ぶことが多い。本稿でも、以下では発行局を認証局と呼ぶことにする。
証明書の発行手順は以下のとおりである。まず加入者は自身が用いる公開鍵・秘密鍵ペアの生成と登録局における本人確認とを行う。
次に加入者は登録局に証明書の発行申請を行い、登録局は認証局に証明書の発行を依頼する。認証局は申請書を確認したあと証明書を発行し、登録局経由で証明書を加入者に配布する。
認証局はPKIの他の利用者が加入者の証明書を見つけやすいよう、(もしリポジトリがあれば)加入者の証明書をリポジトリに公開する。
上では加入者が自分で鍵ペアの生成するケースを説明したが、企業が全新入社員を加入者として一括登録するようなケースでは登録局である企業の側が全員分の鍵ペアを生成して各加入者に鍵ペアを配布する事も有り得る。この場合登録局が加入者に証明書を配布する際、一緒に秘密鍵も配布する。
本人確認と公開鍵の検証を行ったら、リストに印を付ける。
列をずらし、別の人と5、6の作業を繰り返し、これを全員に対して行う。
キーサインパーティーが終わったら、印を付けた相手の公開鍵をキーサーバーからダウンロードする。
公開鍵の指紋がリストに記載されているものと同一であることを確認し、自分の秘密鍵で相手の公開鍵に署名し、相手に送付する。
署名付きの公開鍵を受け取ったら、自分の鍵束に署名付きの鍵を取り込み、キーサーバーにアップロードする。
注意点として、公開鍵への署名を施す場合に念入りに本人確認を行うことである。インターネット上に配布されている公開鍵に対する安易な署名など、本人確認をせずに署名を行った場合、鍵の持ち主を特定することができず Web of Trust そのものの信頼性が著しく損なわれることになる。
また、未署名の公開鍵によるソフトウェアへの署名は、署名の意味をなさないことについても注意が必要である。
認証局同士の信頼関係のモデルを信頼モデルという。様々な組織が様々な信頼モデルに基づいて認証局を運用しているが、代表的な信頼モデルとして以下のものがある。
単独モデルは1つの認証局が全てのユーザに証明書を発行するモデルであり、企業内の認証局などユーザ数が小規模な場合に用いられる。
階層型モデルは複数の認証局がツリー型の階層構造をなすモデルであり、WebモデルはWebブラウザなどのクライアントアプリケーションに予め認証局の一覧を埋め込むモデルである。
メッシュモデルは階層構造を持たない認証局が相互に認証しあうモデルであり、異なる運用ポリシー(=CPとCPSの記載内容)を持つ「CAドメイン」の間を横断して接続する際に使われる。メッシュモデルでは異なるCAドメインにある認証局同士が相互に認証しあう相互認証でつながりあう。相互認証で用いられる証明書を相互認証証明書という。
ブリッジCAモデルは認証局同士がブリッジCAという認証局を通して接続するモデルである。メッシュモデルと同じく異なるCAドメイン間を結びつけるときに用いるが、各認証局が相互に認証しあうメッシュモデルと違い、各認証局は1つのブリッジCAとのみ相互認証する。これにより認証局1↔ブリッジCA↔認証局2というブリッジCAを媒介とした信頼関係が形成される。認証局の数が多い場合、認証局同士が直接相互認証するメッシュモデルでは相互認証の数が膨大になるが、ブリッジCAモデルではブリッジCAを媒介としたスター型のトポロジーの相互認証が形成されるのみなので、認証パスの数を減らすことができるという利点がある。