Google による OpenPGP 鍵配送の解決提案
Google が開発中の Chrome プラグイン End-To-End がついに GitHub に乗ったようだ。 さらに GitHub の Wiki では OpenPGP 鍵配送について提案がされている。
OpenPGP には既に鍵サーバが存在するのになぜわざわざそこに言及するのか。
鍵配送問題とは
暗号とは，ものすごく簡単に言うと，以下の式であらわされるものである。
\[ S' = F(S,K_1) \label{eq:enc} \] \[ S = F^{-1}(S',K_2) \label{eq:dec} \]
$S$ から $S'$ に変換する式 \eqref{eq:enc} を暗号化（encryption）
， $S'$ から $S$ に復元する式 \eqref{eq:dec} を復号（decryption）
と呼ぶ。
$S'$ から $S$ を推測できないのが特徴である。
また関数 $F$ および $F^{-1}$ のセットをアルゴリズム（algorithm）
と呼び，パラメータ $K_1$ および $K_2$ を鍵（key）
と呼ぶ。
つまり暗号には必ずアルゴリズムと鍵が存在する。
現代の暗号技術はアルゴリズムを公開し，秘密情報である鍵の強度で安全性を担保する。
問題はこの鍵が $S$ の送り手と受け手の両方に必要なことである。 つまり「鍵配送問題」とは，鍵を
- 正しい鍵を
- 正しい相手のみに
- 秘密裏（安全）に
運ぶ方法のことである。 これは長年の懸案になっていた。
1970年代に登場した公開鍵暗号（Public-Key Cryptography）
は，この「鍵配送問題」のうち2番目と3番目の問題を解消した。
しかし依然として1番目の問題が残っている。
（公開鍵暗号は先ほどの数式で $K_1$ および $K_2$ が異なる鍵で，かつ $K_1$（公開鍵; public key）から $K_2$（秘密鍵; secret key）が推測できないという特徴を持つものである。
復号できるのは秘密鍵を持っている人だけであると言えるので，公開鍵は秘密にする必要がないし第3者に渡っても問題ない（鍵を持っているという情報は第3者に伝わってしまうが）。
ちなみに電子署名はデータを秘密鍵で暗号化し公開鍵で復号する。
暗号化できるのは秘密鍵を持っている人だけなので，確かに鍵を持っている本人のデータだと保証できる。
あと公開鍵暗号には「鍵交換」と呼ばれるアルゴリズムがあるが，ここでは割愛する。
鍵交換は perfect forward secrecy で重要な役割を果たす。
そのうち OTR（Off-the-Recording） と絡めて説明できたらいいな）
1番目の問題を解消する方法はいくつか考えられる。 たとえば
- 直接本人から公開鍵を手渡してもらう（直接本人からもらうのだから正しい）
- 信頼できる相手（または安全な経路）を通じて公開鍵を入手する（鍵のすり替えやなりすましがないと言えるのなら正しい）
- 信頼できる第3者（third party）に公開鍵の正しさを保証してもらう（信頼できる人または組織・サービスが保証するのだから正しい）
といった方法がある。
実際にはこれらを組み合わせて運用する。
正しい公開鍵を配送する仕組みのことを公開鍵基盤（Public Key Infrastructure; PKI）
と呼ぶ。
PKI としての OpenPGP
PKI として最も有名なのは X.509 である。 X.509 と聞いてピンとこない人もいるかもしれないが， SSL/TLS が採用している PKI だと言えば分りやすいだろう。 あまりに有名すぎて（昔の私みたいに） PKI イコール X.509 だと思っている人もいるかもしれない。
X.509 は権威的な認証局（Certification Authority; CA）
をノードとしたピラミッド型の階層構造になっている。
ユーザは CA を信頼することで CA が信頼する公開鍵を信頼するのだが，ユーザ自身がそれを意識することはほとんどない。
たとえば Web ブラウザは既定で権威的 CA の証明書（公開鍵＋電子署名）を持っている
が，これの存在自体知らない人も多いだろう。 また何故これらの CA が信頼されているかわからない人も多いと思う。 正直に言って私も何故これらの CA が信頼されブラウザに組み込まれているのか知らない。
実際 CA が不備を突かれて攻撃を受け，なりすまされた証明書を発行したり CA 以下の全証明書が失効するという話は頻繁ではないが珍しいことではない。
（それ以前に CA の認証を受けない「オレオレ証明書」や権威的でない CA を独自に立てる「オレオレ CA」もいまだに多いようなのだが）
実は OpenPGP も PKI のひとつである。
Google は OpenPGP を hard concept to grasp for average users
などと言っているが， OpenPGP は全然難しくない。
OpenPGP をひと言でいうなら「信頼できるやつが保証する公開鍵は信頼できる」である。
これに近いのが「小切手の裏書」である。 小切手を第3者に譲渡する際は譲渡する人が小切手の裏に署名をする。 譲渡された人は裏書を見てその小切手が信頼できるかどうか判断するのだ。
（実際 OpenPGP を利用した補完通貨も過去に存在した。今はどうなってるやら）
OpenPGP もこれとほとんど同じ仕組みで信頼関係を構築している。
取得した公開鍵に電子署名と信用度（trust）
を設定する。
他の人は公開鍵に付随する他者の電子署名と信用度からその鍵の有効性（validity）
を判定するのである（判定基準は実装によって異なる）。
これを信用の輪（web of trust）
と呼ぶ。
X.509 と OpenPGP の違いを以下に示す。
| 特徴 | X.509 | OpenPGP |
|---|---|---|
| PKI の形態 | hierarchical PKI | trust-file PKI |
| 公開鍵の認証者 | 専門機関（CA） | 各ユーザ |
| 信頼点 | ルート CA | 利用者自身（面識） |
| 認証の連鎖構造 | ツリー型 | ユーザ中心型 |
| 認証者を認証する根拠 | 利用者による選択 | 利用者自身 |
| 証明書の破棄 | あり | 不完全 |
| コスト | 高い | 低い |
OpenPGPとPKI2.3節より）
OpenPGP 最大の弱点は， X.509 における CA のような PKI の機能（登録，監査，検索，破棄）を集約するノードがないため公開鍵の管理が煩雑になってしまう点にある。 この弱点を補うため，現在では PGP 鍵サーバが運用されている。 最近は SKS 鍵サーバが流行のようである。
- SKS Keyservers
- PGP KEYSERVER （JPNIC 内， PGP の時代からある老舗）
ただし現行の鍵サーバは登録された公開鍵に対して何も保証しない。 鍵サーバを通して取得した公開鍵を信頼するかどうかは，信用の輪の信用モデル（trust model）に則って，あくまでユーザ自身が行うからだ。
Google の考える鍵サーバ
前置きが長すぎた。 ここでようやく Google の登場である。 Google は次の2つの機能を含む鍵サーバを提案している。
- 鍵サーバに公開鍵を登録する際に（identity protocol （OAuth とか？）を使って）登録者と公開鍵を紐づける。また登録作業を自動化する。
Certificate Transparency（CT; RFC6962）
に似た仕組みを導入し，追記型の log を参照することで公開鍵の正当性を確認・監査する。
CT は X.509 用に考えられたサービスで CA と連携させることで公開鍵の登録手続きの透明化と確実な監査を実現する。
Google はこの仕組みによる鍵サーバを構築することにより「正しい鍵」を配送できると考えているようだ。
先ほど述べたように，現行の鍵サーバは公開鍵に対して何も保証しない。 OpenPGP のユーザは誰でもどんな鍵でも登録することができる（例えば2001年には Osama Bin Laden の公開鍵が話題になった。これが本物かどうかは確かめようがない）。 しかし Google の提案を実装すれば少なくとも登録者と公開鍵を紐づけることができる。 ただし，その対価として公開鍵は登録した鍵サーバに固定されてしまう。
（現行の鍵サーバは公開鍵をサーバ同士 peer-to-peer で同期させている。 つまり公開鍵の位置を不定にする。 例えば日本の PGP 鍵サーバで登録した公開鍵をドイツの SKS 鍵サーバで取得することができる。 どこで登録しどこから取得したかという記録は公開されない（サーバの記録には残ると思うけど）。 「位置を不定にする」というのはプライバシー上の重要な要素である）
また fake の公開鍵が存在することは悪いことだけではない（当事者同士がわかっていれば問題ない）。 ひとつのメールアドレスに対して複数の鍵を作って役割を分担し運用している場合もある。 登録されている公開鍵が有効かどうか一見して分からないのは Monitors（log の監査サーバのこと）の設計が煩雑にならないだろうか。 もっと踏み込んで言うなら Monitors の設計によってユーザの行動が規定されてしまうのはまずい気がする。
OpenPGP の弱点のひとつは，公開鍵の破棄（revoke）
プロセスが不完全なことである。
公開鍵を持っている全てのユーザに破棄を通知する手段がないため，破棄の事実を取りこぼす可能性が高い。
しかし Google の提案を実装すれば暗号化（または署名の検証）を行うたびに STH（Signed Tree Head）を取得・確認する必要があるため公開鍵の破棄を取りこぼす可能性が減る。
これは朗報である。
（もうひとつ。 鍵サーバは spam 業者にとっておいしいシステムである。 取得したメールアドレスを鍵サーバに問い合わせて公開鍵が取得できるのなら，そのメールアドレスは「生きている」可能性が高い。 現行の鍵サーバは検索機能が強力すぎて名前の一部でもマッチすれば結果を返してしまうため，さらにたちが悪い。 私が公開鍵を鍵サーバに登録するのを嫌うのはこのためである。 Google がこの問題をどう対処するのか（するつもりがあるのか）が見ものである）
今回の提案は，あくまで casual user が手軽に暗号化メールを使うためのものなので（そのために作業のほとんどを類型化・自動化する必要がある），プライバシーに関する要件は重視してないように見える。 つまり Google の End-To-End についても heavy な使い方は想定していないかもしれない。
もっともユーザ自身は casual use のつもりでも，他者からやってくる署名・暗号化メールには色んなのがあるからなぁ。 これに全て対応するのは大変と思われ。 日本人から見ると，まずは ISO-2022-JIS エンコーディングを正しく解釈できるかだなぁ（JPCERT/CC の電子署名付きメールを正しく処理できるかどうかが最初の関門）。 あと配送途中で quoted-printable に変換されたものもちゃんと元のエンコーディングに戻して処理できるかとか（ISO-2022-JIS エンコーディングは制御文字を含むので，配送途中で quoted-printable に変換されるというのはよくある）。 やぁ，みんな通った道だねい（笑）
（昔は MUA 間の互換性を取るために PGP/GnuPG で暗号化したメール・メッセージを検証するメーリングリストとかあったんだけど（私も拙作で随分お世話になった），今そういうのってないんだろうなぁ）
今回 Google が提案した鍵サーバは，現行のものを置き換えるのではなく，むしろ現行の alternative として併存していくような気がする。 たとえば Gmail アドレスは Google の鍵サーバに登録して，それ以外は SKS 鍵サーバに登録するか stand-alone で手元に保持っておくとか。 keybase.io みたいな実装例もあるし，いろいろ出てくるんだろうなぁ。
