視点を変えて署名のほうにはユーザIDが入っているのかというと、RFC 2440の5.2.2によるとV3では入れることができず、5.2.3によるとV4ではサブパケットを使って入れることができるようです。ちなみに、GnuPGではデフォルトでV3の署名を生成し、--openpgpをつけるとV4の署名を生成します。しかし、署名を--list-packetsで覗いてみると、V4で生成してもユーザIDのサブパケットは付けないようです。
署名を検証するときに--status-fd 2をつけてステータスを標準エラー出力に出してやると、
[GNUPG:] TRUST_FULLY
のようなステータス行で有効性を出力してくれますが、これもその鍵の結び付けられているユーザIDのうちもっとも高い有効性を返しているように見えます。署名にユーザIDが入っていず鍵IDしか入っていないのでこれは仕方がないのかもしれません。
結局のところ、このステータスラインは無視して、VALIDSIGステータスから鍵のフィンガープリントを取り出した上で、
gpg --list-key --with-colon --fixed-list-mode <フィンガープリント>
のようにしてユーザIDのリストを有効性込みで取得して、それを使うようにすれば良さそうな気がします。
すみません、忙しくてバグトラックのほうに返事を書く余裕がありませんが ここだけ。<br><フィンガープリント>ではなくて鍵IDで良いと思います。鍵サーバで確認できるのは鍵IDなので。（フィンガープリントはその鍵の確認のために使うものなので）<br><br>ユーザID個別に確認できるのなら、鍵は検証OKだけどユーザーIDの検証はNGかもしれないというような表示が有ればわかりやすいと思います。<br><br>それと、ソース表示の件 ありがとうございます。
鍵IDはフィンガープリントに比べると重複する可能性が高いですから、フィンガープリントが取得できる場面ではそちらを使ったほうが良いと思うのですがいかがでしょう。
公開鍵を持っていない相手からのPGP署名メールを受け取ったときのことも考慮願います。<br><br>署名ブロックの中にはフィンガープリントは無いはずなので公開鍵を持っていない場合はフィンガープリントは鍵そのもののキーではないため公開鍵サーバーから公開鍵を持ってこれないので役に立ちません。<br>一緒に鍵IDも表示されてQMAIL3からコピー＆ペーストできる仕組みになっていれば結構ですが、おそらく こういう場合は最初の「本当にこの鍵はユーザーIDの鍵として正しいのか？」という疑問に戻ってしまいます。
<フィンガープリント>と書いたのは検証に成功した場合に、その後--list-keyで検証に使用した鍵に結び付けられたユーザIDを取得する場合にフィンガープリントを使用するという意味なので、検証に失敗した場合には別の話ですね。<br><br>その場合には鍵IDをどこかに表示するようにした上で、その取得と有効性の評価はユーザ（とGnuPGのWeb of Trustの評価）に委ねられるということになるなると思います。