そもそもPGPのユーザIDの意味について考えたのは、ユーザIDはメールアドレスとは無関係なので、ユーザIDとFromのメールアドレスを比較しても意味がないという指摘を頂いたためです。しかし、色々考えてみた結果、やはり意味があると考えています。
PGPがWeb of Trustの仕組みを用いてある鍵の有効性を評価したとき、評価されるのはその鍵が本当にそのユーザIDのものであるかどうかです。言い換えると、鍵IDとユーザIDの結びつきが評価されます。しかし、ある鍵があるユーザIDに結び付けられていることが確かだとしても、そのユーザIDがニックネームだったら、その人を知らない人は誰だかわかりませんし、そもそも同じニックネームを持つ人同士の区別が付きません。自分の知っているAさんだと思ったら、まったく別のAさんだったということもありえます。メールアドレスが含まれていれば、少なくともそのメールアドレスの所有者であることがわかりますし、基本的に重複する可能性もありません。
このとき、From（やSender）のメールアドレスと鍵に結び付けられたユーザIDのメールアドレスが異なるということは、Fromを信用してはいけないという意味において警告すべき事柄であると感じられます（S/MIMEのケースと同様）。
Web of Trustの仕組みを使わず、すべての通信相手の公開鍵に自分で署名をし、相手のことを直接知っている場合には、これらのことはあまり気にする必要はないでしょう。つまり、ユーザIDがニックネームであっても相手が実際誰なのかはわかるし、その人がそのメールアドレスを使っていることは良く知っているかもしれません。なんだったら鍵IDを見ただけで相手がわかるかもしれません。また、FromのメールアドレスとユーザIDのメールアドレスが異なったとしても、両方のメールアドレスを相手が使っていることを知っていれば気にしないかもしれません。しかし、自分の知らない（つまり自分で直接相手の公開鍵に署名をしていない）人の署名を検証する場合には、（有効であると評価された）ユーザIDにFromのメールアドレスが含まれていることは重要であると言えるのではないでしょうか。
１つ目、<br>私の表現が足りなかったのかも知れませんが「ユーザIDとFromのメールアドレスを比較しても意味がない」と言うわけではないです。<br>この話題の発端は、この状態で検証をエラーにするのはバグだというだけの話です。<br>経過を見ていると手数を掛けさせてしまっているのはわかりますが、ユーザIDとFromのメールアドレスが異なる場合にはなんらかの通知を行うという実装は他にない素晴らしいことだとは思います。（私個人的にはエラーにならなければ充分だと思いますが）<br><br>２つ目、<br>そもそも懸念となっている、他人のメールアドレスをユーザーIDとして登録した鍵を作って、そのメールアドレスに成り済ますようなバカげたことをするとは考えにくいと思います。そのユーザーIDとメールアドレスが一致している公開鍵を受け取った人が公開鍵を公開鍵サーバーにアップロードすれば「成り済まし」という悪事が公になるからです。そんな間抜けな成り済ましをする人が居るかどうか．．．
「有効性」は署名の内容から計算によって自動的に算出されるものです。鍵の発行者本人の署名（自己署名）がないのは問題外ですが，（自分を含めて）信頼できる人の署名がなければ unknown になります。逆に信頼できる誰かの鍵による署名があればその人の「信頼度」に従って有効性が決定されます。<br><br>要するに「有効性」というのは X.509 でいう「オレオレ証明書」ではないことを示すものです。これはただちに鍵が改竄されているかどうかを示すものではありませんが，信頼できる人が誰も署名してくれなくて自分自身もその鍵を信頼できないのなら unknown にならざるをえません。ユーザ ID はあとから追加することもあるのでこのような仕様になっているのかもしれませんが，仮に秘密鍵を持たない第三者が勝手にユーザ ID を追加したとしても自己署名で NG になる筈なので判断はそう難しくない筈です。問題ないと判断した上でユーザ ID に署名して信頼度を設定すればいい話だと思います。<br><br>ユーザ ID とメールアドレスの関係ですが，警告を出す程度なら S/MIME と同じようにメールアドレスをチェックする機能はありのような気がします。個人的にはユーザ ID にないメールアドレスを使って署名メールを送る人は信用しかねますが，その辺は人によるのかもしれません。<br><br>ちなみに「他人のメールアドレスをユーザーIDとして登録した鍵を作って」というのは実際にありえます。PGP の公開鍵サーバで「Osama Bin Laden」を探すと見事にヒットしますが，これが本人の鍵だとは誰も思わないでしょう。でもこの鍵を作った人は「Osama Bin Laden」名義で署名メールを送ることができ，受信した側も公開鍵サーバから鍵を取得して検証できるわけです。今までこういった事例がないのは単に PKI としての OpenPGP の知名度の低さ故であって，今後はどうなるか分かりません。<br><br>鍵の有効性については以下をご参考に：<br>http://pgp.iijlab.net/pgp/trust.html
> kiyoさん<br>確かに、ある（誰かから既に署名されている）鍵+ユーザIDに対して、故意に他人のメールアドレスを含んだユーザIDを追加するのは、身分証明書を見せながら嘘をつくようなものなので、かなり間抜けですね…<br><br>得られるものがかなり大きくて、法律的にPGPの署名が本人を特定するのに十分に有効でないと判断すればやる価値があるのかも知れませんけど。
>Spiegelさん<br>ある公開鍵に対して対応する秘密鍵を持っていない第三者がユーザIDを追加するという部分に関しては、おっしゃるように自己署名すらついていないので心配していません。秘密鍵を持っている人が、別のユーザIDを悪意を持って追加した場合の事を心配していました。これも、kiyoさんのご指摘のように杞憂かもしれません。<br><br>ご紹介のURLは読んでいたのですが、このページも含めて有効性を鍵に対して与えるものであるように読めてしまうページが多いのが気になります（このページに関しては、ちゃんと読めば違うとわかるのですが）。実際には、有効性は鍵+ユーザIDに対して、信用度は鍵（人）に対して与えるものであるのに、鍵に対して有効性を計算するように述べている説明が結構見られます。<br><br>実際、わたしも初めはPGPでは鍵自体に対して有効性を計算して（つまり、その鍵IDの鍵である事だけ検証して）、鍵IDとユーザIDの結びつきに関してはユーザが個別に管理するものなのかと思ってしまいました。
なるほど。私が問題設定の解釈を間違えていたようですね。すみません。<br><br>「有効性を鍵に対して与えるものであるように読めてしまう」というのはその通りだと思います。ユーザ ID に対して自己署名あるいは他者による署名を施すのは、そのことによって鍵と付属情報をリンクし鍵の完全性を担保するのが目的だからです。したがって複数あるユーザ ID のいずれかに正しい署名があればその鍵は有効であるとみなされます。<br><br>例えば snak さんの最初の例でいえば、確かに A1 はメールに署名していないかもしれませんが信頼している A2 の鍵による署名であることは確実にいえます。そこで最終的にどうやって署名したか（A1 と A2 が同一人物か、A2 が A1 を装って署名したか、あるいは A1 が A2 の鍵を盗んで署名したか）を特定するのは GnuPG の役目ではないように思えます。<br><br>署名が正しいことと秘密鍵が正当な所有者の下で正しく運用されていることは別個の問題だと思います。X.509 の証明書で CN にメールアドレスやドメイン名を書かせるのは、そのことによって使用されるドメインを限定する意味もあると思いますが、 OpenPGP にはそのような設計思想は無くどの局面でも使えてしまいます。その辺を GnuPG 側でもう少しフォローできればいいとは確かに思いますが。（まぁそのための show-uid-validity オプションなんでしょうけど）
納得いくようないかないような…X.509の世界に慣れているせいでしょうか。<br><br>例えば以下のような具体的なシナリオにおいて、PGP利用者はどのように判断するのでしょうか？<br><br>1. 会社の同僚のBobからメールが送られてきました。Fromのアドレスは、bob@mycompany.comです。mycompany.comは自分の会社のドメインで、Bobは誰かは知っていますし、そのメールアドレスがBobのものである事も知っています。そのメールで、Bobは緊急の用事で必要なのであるパスワードを教えて欲しいと言ってきました。<br><br>2. そのメールにはPGPで署名がされています。そこで、署名から鍵ID（#12345678）を取得して、それをキーにして鍵サーバから鍵を取得しました。その鍵を使ってGnuPGで署名を検証したところ検証に成功しました。GnuPGの出力を見ると、その鍵には、bob@mycompany.comとbob@example.orgというユーザIDが設定されていて、bob@mycompany.comがプライマリです。そして、その鍵の有効性はWeb of Trustの評価によって有効性が確認されています。<br><br>3. しかし、実はWeb of Trustの評価で有効とされたのは、bob@example.orgのユーザIDであって、bob@mycompany.comのユーザIDではありません。しかし、GnuPGの検証の出力を見ただけではどちらが有効と判断されたのかはわかりません（--verify-options show-uid-validityを付けていないので）。<br><br>4. この場合、このメールについてどう判断するのでしょうか？<br> a. bob@mycompany.comがユーザIDに含まれているので本当にBobから来た（bob@example.orgはおそらく個人アドレスであろう）<br> b. bob@mycompnay.comを引数にGnuPGでユーザIDのリストをshow-uid-validityオプションを使って調べて見たら、有効なのはbob@example.orgの方だけだとわかったので、そのメールアドレスの持ち主が、bob@mycompany.comを騙っているのかもしれない<br><br>5. メールが本当にBobから来たと判断した場合には、パスワードを返信して教えてあげることにします。そこで、GnuPGを使って暗号化して送ることにします。<br><br>6. ここで送るときに鍵の指定はどちらを使うのでしょうか？<br> a. ユーザID（bob@mycompany.com）<br> b. 鍵ID（#12345678）<br><br>7. ユーザIDで指定すると、GnuPGが、このユーザIDは有効性が確認されていないのでこの鍵が本当にそのユーザIDの鍵ではないかもしれない、と警告します。ここでの判断はどうなるのでしょうか？<br> a. 4でBobから来たものだと判断したのになぜ有効性が確認できないと言われるのかわからず混乱する<br> b. 確かに確認できないのでやめる<br> c. 4でBobの鍵は有効性を確認したはずだからこのまま進む<br><br>8. 逆に鍵IDで指定したら、何も警告がないまま暗号化され、返信することになります。つまり、そのメールをbob@example.orgの持ち主に盗み見される可能性があります。<br><br>（少なくとも今回の件で色々と調べるまでの）私の感覚では、全ての判断がaになると思うのです。つまり、4での判断と7での判断が食い違ってしまいます。ここで例えば、メールでの返信ではなく、メールに書かれている電話番号に電話をして留守番電話にパスワードを入れておいてくれと言われたら4の判断のまま騙されてしまいそうです。かといって、4の時に毎回ユーザIDごとの有効性を確認するかといわれるとそれは手間がかかりすぎであると感じます。<br><br>長々と書きましたが、このあたりがもやもやとしている理由なのです。
時々しか出てこなくてすみません。＆Spiegelさん 、こういうところもチェックされてるんですね、補足していただいてありがとうございます。<br><br><br>私なら、<br>まず当該のメールが送られてくる以前から公開鍵を持っていなかった場合は当該メールに「bob@example.orgに返信せよ」と有ったら疑います。<br>メールや留守電以外で本人を確認できるまでパスワードは教えない。そもそも確認できない状況下において仕事用のパスワードなど必要ないはず。（客先に居るなら客先に電話する）<br><br>本人だと判断できたのならば、暗号化時に選ぶ鍵はどちらでも構わない。<br><br>かな<br><br>ちなみに仕事とは無関係で大切な内容を送って欲しいというメールが来たら、Reply-To：で表示されたり指定したアドレスには送らずに無視します。アドレス帳や既受信メール中の本人からのメールアドレスに対して確認メールを送ります。確認できた後は上と同じ。<br><br>結局このケースではGnuPGから出される情報は使わないことになりますね。面白くないですね。（実運用でもPGP/GnuPGから出される情報はほとんど使っていません。実運用では検証に失敗したこともないし、鍵ＩＤとかフィンガープリントを確認するのは全くの最初だけでしたし、こういうことを気にするのは相互検証ＭＬや自分のＰＧＰ実験用ＭＬだけでの話でした）
一応念のためですが、bob@example.orgに返信せよとは書いてありません。返信先はbob@mycompany.comです。ただし、経路は安全ではないため、盗み見される可能性があります。ですから、上記の鍵で暗号化してbob@mycompany.comに返信すると、盗み見した人（秘密鍵を持っている人）が中身を見ることができます。また、確認のメールを送ったとしても、盗み見した人から元と同じように署名されたメールが返ってくる可能性があります。<br><br>「アドレス帳や既受信メール中の本人からのメールアドレスに対して確認メールを送ります。確認できた後は上と同じ。」というのはどうやって確認するのでしょうか？<br><br>kiyoさんの結論としては、PGPの署名は本人確認としてはあてにならないから、ユーザIDが何であったにしろ信用しないということでしょうか。
あっすみません。自己紹介が遅れましたね。実は WinCE 版のユーザです。最近は客先に常駐して作業環境も与えられているのであまり使いませんが。<br><br>上記の例についてですが、厳密に鍵や秘密情報を運用するなら<br><br>4-a. 署名は一応信用する。<br><br>6-a. しかし bob@mycompany.com のユーザ ID は信用度が unknown なので暗号化で警告が出る。<br><br>7-b. そこでいったんパスワードを送るのを諦め、サーバ上の公開鍵について（できれば本人に直接）確認を行う。確認がとれれば公開鍵に署名して暗号化メールを送る。確認がとれなければ送らない。<br><br>なんでしょうね。6-a でどのように確認するかが肝になるでしょう。本人への問い合わせが無理でも別のユーザ ID からは有効であることが分かっているので、その署名者を辿って（当然その人の公開鍵を持っていて署名を行っているはずです）確認する方法もあるかもしれません。自分の所属する会社の知っている人のメールアドレスによる暗号化で支障が出るのならその鍵を疑ってみるのがセオリーだと思います。<br><br>しかし「メールに書かれている電話番号に電話をして留守番電話にパスワードを入れておいてくれ」と言われたら（署名は信用しているだけに）私もその通りにしちゃいそうです。show-uid-validity の存在を知った今なら gpg.conf にオプションを追加して常に有効性をチェックする運用もできると思いますが、「運用でかわす」というのは（次善の策としてはありかもしれませんが）未然事故防止の観点からはよい方法とはいえないかもしれません。GnuPG のプロジェクトに言うのが早いんでしょうけど。
いや、このケースでは今回受け取ったメールから初めて鍵ID（#12345678）の公開鍵を手に入れると言うところが、確認できるまでは送らないという理由です。これ以前にbob@mycompany.comの公開鍵を持っていれば鍵ID（#12345678）を使用して暗号化して送ります。<br><br>「アドレス帳や既受信メール中の本人からのメールアドレスに対して確認メール」というのは一文字違い等の別人に届くような仕掛けを避けるためですが、上の状況では私はこれも送らないと思います。<br><br>ということで、ユーザーIDが何であっても”今回初めて手に入れる公開鍵”では別の方法で確認できないままでは信用しません。<br>私の考える暗号通信での使用で信用できる公開鍵とは、重要な通信を行う前にあらかじめ受け取るか公開鍵サーバからダウンロードしてフィンガープリントで確認済みであったものだけです。
> Spiegelさん<br>私の考えが的外れだったというわけではないことがわかって少し安心しました。私も、show-uid-validityはデフォルトで付いているべきだと感じます（もしくは、検証時の結果として、有効性が十分でないユーザIDは表示しないようにするとか）。
> kiyoさん<br>つまり、Web of Trustを使わずに常に自分で鍵（とユーザID）の有効性を評価するということですね（--trust-model directをつけて運用するということでしょうか）。<br><br>しかし、今回kiyoさんが言及しているのは暗号化する際の鍵の安全性についてだと思います。つまり、Bobから来たメールが本当にBobからきたものであっても偽者のBobから来たものであっても、本当のBobの鍵で暗号化して送れば本物のBob以外の人は復号できないから問題ないという判断だと思います。それとは別にメールが本当にBobから来たかどうかの判断はどうでしょうか？<br><br>先の例は、このことを述べるには適切でないかもしれないので、別の例をもうひとつ挙げてみます。<br><br>1. Bobは会社の同僚です。Bobの公開鍵は本人から直接受け取りフィンガープリントも紙でもらったので、それを確認したうえで鍵リングに追加し、その鍵とユーザID（ユーザIDにはBobの会社のメールアドレスであるbob@mycompany.comが含まれている）にローカル署名をしました。その鍵には他にもBobの個人アドレスと思われるユーザIDが付いていましたが、個人的にやり取りすることはないのでそちらのユーザIDにはローカル署名を付けませんでした。<br><br>2. bOBはネット上で知り合った人で面識はありません。bOBに暗号化したメールを送る機会があったので、bOBから安全な手段で公開鍵をもらいフィンガープリントを確認してローカル署名をしました。bOBのメールアドレスはbob@example.orgで、ユーザIDにもこのメールアドレスが含まれていました。他にユーザIDは含まれていませんでした。<br><br>3. 必要に応じてその他の人からも鍵をもらったり、鍵サーバからダウンロードしたりして鍵リングに追加しました。また、すでに持っている鍵に関しても時々鍵サーバをチェックして更新されていたらダウンロードして鍵リングにマージしました。<br><br>4. だいぶ月日がたってから、bob@mycompany.comからメールをもらいました。そこには仕事で必要なファイルが添付されていました。このファイルは実行形式のファイルです。安易に実行するとウィルスかもしれなくて危険ですが、幸いメールはPGPで署名がされていました。そこで、PGPで署名を検証しました。その結果をGnuPGは以下のように表示しました。<br> gpg: Signature made Fri Oct 14 10:36:49 2005 JST using DSA key ID 12345678<br> gpg: Good signature from "Bob <bob@mycompany.com>"<br> aka "Bob <bob@somedomain.com>"<br> ...<br> aka "Bob <bob@example.org><br><br>5. "Bob <bob@mycompany.com>"で署名されているので安全だと考え（その他のユーザIDは個人アドレスのものであると思われるけれども、昔のことなので個人アドレスは覚えていません）実行しました。そしてウィルスに感染しました。<br><br>6. bOBを探し出そうとしましたが、メールアドレスも変わっていて見つけることはできませんでした。<br><br>ここで悪かったのはどこでしょう？<br><br>a. 1でBobの鍵にローカル署名をしたこと<br>b. 2でbOBの鍵にローカル署名をしたこと<br>c. 3で鍵の更新を行ったこと<br>d. 4で検証したときにshow-uid-validityをつけてユーザIDごとの有効性を確認しなかったこと<br>e. 4で検証したときに鍵IDを見てBobの鍵ではなくbOBの鍵だと思い出せなかったこと<br>f. 4で検証したときに鍵IDから鍵のフィンガープリントを取り出して、フィンガープリントの確認をやり直さなかったこと<br>g. その他<br><br>ただし、メールで送られてきた実行ファイルなんていずれにしても実行しないというのはなしにしてください。仕事で必要なので（本物であれば）実行しなくてはいけなかったとします。Webからダウンロードした場合でも同様のことが起き得ますし。
私は --trust-model direct はつけてないですし、確認は最初だけです。そもそも このオプションは知らなかったので。<br><br>この例題ではexeを実行しますが、ウィルスに感染した場合の反省点は（g. その他）−賢いウィルスチェックソフトをインストールしていなかった、というところでしょうか。<br>すみません、今週は頭が悪くて例題の答えが思いつきません (^^;)<br><br>今のところNOD32が気に入っているのでメールは一番きついチェックにして使っているので通過したexeは無条件に実行しています。<br><br>こういうのをメーリングリストとかで実際にやってみたら面白そうですね。実際に受信するとイメージがつかめるかも知れません。<br><br><br>今までの２例のケースって、あんまり深く考えていないですね。ＰＧＰ署名は仕事関連では単なる否認防止のための本人検証になっていると思いますが、ＰＧＰの役割はほとんど暗号ですね。それで普通に使っているので使い方自体のレベルは低いのかも知れません。その低いレベルなりにQMAIL3でも使えるようになれば良いなと思ってバグレポートを出しただけなんです。<br>今回のようなケースでも、怪しいなと思えるような情報表示が出来ると良いですね。
なるほど。予期しない答えが出てきて面白いですね^^;。<br><br>色々と書いたり聞いたりしたおかげで多少はすっきりしました。そのあたりを踏まえて仕様をもう少し練りたいと思います。<br><br>色々とお付き合いいただいてありがとうございました。