OpenPGP，PKI，公開鍵サーバ，そして spam
「PGPよもやま掲示板」で公開鍵サーバへ公開鍵を登録する（主に spam に対しての）リスクについて投稿がありましたが， 非常に面白い論点だと思いますので， 私もこの場で少し意見を書いてみたいと思います。
まず最初に， そもそも OpenPGP ではどうして公開鍵サーバなるものが必要なのか簡単に説明します。
OpenPGP は PKI （Public Key Infrastructure: 公開鍵基盤）のひとつとして考えることができます。 PKI の機能としては大きく以下の3つが挙げられると思います。 （「OpenPGPとPKI」より抜粋）
- 利用者を登録し，公開鍵証明書を発行する
- 公開鍵が失効した場合には公開鍵証明書を破棄する
- 検証のために公開鍵証明書を保管する
OpenPGP では 1 と 2 （特に 2）の機能が弱く， ユーザが手作業で公開鍵の入手（あるいは更新）から検証までを行う必要があります。 この弱点を補うために期待されているのが公開鍵サーバです。 ただし OpenPGP は X.509 （巷で PKI という場合は X.509 を指すことが多いですが）のような hierarchical PKI とは異なり公開鍵サーバの利用は必須ではありません。 これは OpenPGP が公的機関や他の第三者機関が信頼できない状態であっても最低限機能することを目標に設計されているためです。
さて， ここからが本題です。
実は公開鍵サーバは OpenPGP 標準化以前の PGP v2 のころから存在しています。 そして現在でも基本的なインタフェースは変わっていません。 一方， spam クローラによるメールアドレス収集は大規模になる傾向にあり， 単純な Web 巡回のみならず Google などの検索サービスを利用した収集も行われているようです。 最初に紹介した投稿に続くスレッドでも（匿名ですが）公開鍵サーバを利用したメールアドレスの収集が報告されています。 実際にこの状況がどの程度脅威になっているのかについては公開鍵サーバ側でアクセス解析等を行って定量的に調査する必要がありますが， 脅威になり得ることは想像に難くないでしょう。
現在ネット上にある公開鍵サーバはたいていの場合 Web インタフェースを備えていています。 この Web サービスによる検索機能が結構強力で， 不完全な文字列でもそれなりに探し出してしまいます。 例えば pgp.nic.ad.jp で「arakawa」をキーに検索するとこれだけの候補が出力されます。 ただし， 検索機能に関しては実装によってまちまちのようで， 同じ日本国内の別実装である OpenPKSD.org ではメールアドレスが完全に一致しない限り候補を表示しません。
Web インタフェースを使った検索サービスを廃止するか機能を制限すれば spam クローラに狙われるリスクは減りますが， 連携している他のシステムに支障が出る可能性もあります。 提案する価値はあると思いますが。 また， 世界中にある公開鍵サーバは常に peer-to-peer で同期しているため， 検索機能の制限が甘い公開鍵サーバがひとつでもあるとそこを狙い撃ちにされる可能性もあります。 （やるならいっせいに変更する必要がある）
ところで， ユーザ ID にメールアドレスを含めないようにすることはできないのでしょうか。 RFC2440 5.11 章には
"By convention, it includes an RFC 822 mail name, but there are no restrictions on its content."
と書かれています。 微妙ですねぇ。 しかしメールアドレスを含まないユーザ ID が許容されるとしても運用としては困ったことになりそうです。 メールアドレスを含まないユーザ ID やダミーのメールアドレスを含むユーザ ID を許容してしまうと正しい公開鍵かどうか判断が難しくなります。 （公開鍵サーバには誰でもどんな公開鍵でも登録可能であること， そして公開鍵の検証を行うのはあくまでユーザ側であることに注意してください）
次善の策ではありますが spam クローラに狙われるリスクを避けるために公開鍵を分ける方法もあります。 公開鍵を分ける方法については IPA/ISEC の事例が参考になると思います。 この例でいう「ルート鍵」のみを公開鍵サーバに登録し， 実際の運用鍵は使用する状況に合わせてローカルで運用するなりネットで公開するなりするのです。 もちろん公開した鍵については spam クローラに狙われるリスクを避けられませんが， それ以外の公開鍵については回避できます。 これは複数のメールアドレスで複数の公開鍵を使い分けている場合にはよい方法だと思います。
PKI としての機能は大幅に制限されますが， 公開鍵サーバを利用しないという選択肢ももちろんあります。 この場合， 完全にローカルで運用できるのであれば何ら問題はないのですが， ネット上に公開する必要がある場合は公開する「場所」が問題になります。 公開する「場所」は（乗っ取りや Phishing のような詐称がないことが保証された）信頼できる場所であることが重要です。 一番手っ取り早いのは SSL で暗号化されたサイトに置くことでしょうか。 例えば IPA/ISEC では SSL で暗号化された「場所」に公開鍵を置いているようです。 しかし個人で運用しているサイト・ディレクトリでは SSL のような強力な手段を取れないこともあると思います。 この場合は， サイト・ディレクトリの信頼性リスクと spam クローラに狙われるリスクを比較して何らかの割り切りが必要になってくるかもしれません。
ちなみに現在の spam クローラは公開鍵をデコードしてメールアドレスを得るといった芸当はできないようですが， 処理としてはそれほど難しいわけではありません。 ひょっとしたら近い将来に公開鍵をデコードしてメールアドレスを得るクローラが出現するかもしれませんね。 （そのようなニーズが spam 発信者側にあればですが）
参考文献：