Strange Key ID problem. : subkey id is reported where primary key id should be reported as missing?

[ishikawa]

(I sent this to gnupg-bugs at gnu.org a week ago,
but nothing seems to happen, and
so am sending this out again after a slight modification,
and this time to gnupg-devel at gnupg.org. If you have seen
this twice, apologies.)

---

Strange key ID problems.

Hi, thank you for sharing this great tool with programming community and beyond.

Recently, I encountered this strange problem and
I wonder if this is caused by incompatibilities or bugs
in GNUPG.
(After writing this summary, I now think it is a bug, but am not sure
why this was not reported elsewhere. Yes, I tried searching in aim group
but could not find a similar report easily. [not that I am familiar with aim
group mail archive search feature, so I may have missed it.])

I encountered similar problems with this particular key in the last
few days under linux and windows  vist (cygwin), and so
the problem is not limited to a particular platform, it seems.

Background:

I obtained a signed tar ball of mozilla thunderbird mailer source.

http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/3.0b2/source/

In the above URL, you can find a bzipped tar ball and
a signature (.asc).

It is signed by a PGP (or GPG) key. It seems that it was signed
by GnuPG v1.4.1

thunderbird-3.0b2-source.tar.bz2.asc
The contents is shown below.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQBJpQExtXtUhBd4X+gRAn+GAJ9IDT++Y+Js54fyiSqxDZg3YtoMdQCeOvDh
kTD2CVzG2VKHJKSbv9qUgN4=
=2pFg
-----END PGP SIGNATURE-----


Initially, when I tried to verify the signature, I didn't have the
signature key and GPG (my version under linux is 1.4.9) complained
that the key is not found.

$ gpg --version
gpg (GnuPG) 1.4.9

The problem:

When GPG mentioned that it could not find the key, it printed
the missing signature key ID as 17785FE8

So I tried to obtain the key using gpg with arguments such as
--keyserver pgp.mit.edu -recv-keys 17785FE8
--keyserver pgp.nic.ad.jp -recv-keys 17785FE8
to no avail.
The key could not be found there.

Hmm, a problem, I thought.  After browsing web pages, I noticed that
the signature key has an e-mail address of the form "some-string-for
-release-ID at mozilla.org".
When I search the key using this string (--search-keys @mozilla.org),
GPG found several hits, and I chose the most recent key with so called
"release at mozilla.org" BUT WITH A DIFFERENT KEY ID (?), thinking it
would not hurt to have a new such key anyway for later use.

(Below I edited the messages slightly to remove Japanese characters.
I use Japanese locale.)

gpg --keyserver pgp.nic.ad.jp --search-keys @mozilla.org
    ....
(1)	Alexandro Colorado (Gmail) <acolorado at gmail.com>
	Alexandro Colorado (Mozilla Mexico) <jza at mozilla.org.mx>
	Alexandro Colorado (Grupo de usuarios Linux Tabasco) <jza at gultab.org>
	Alexandro Colorado (1 year OOoES individual signature) <jza at openoffice
	  1024 bit DSA key B1008E5E, created: 2008-11-24
(2)	L. David Baron <dbaron at dbaron.org>
	L. David Baron <dbaron at mozilla.com>
	L. David Baron <dbaron at mozilla.org>
	L. David Baron <ldavidbaron at gmail.com>
	L. David Baron <dbaron at post.harvard.edu>
	L. David Baron <dbaron at mozillafoundation.org>
	  1024 bit DSA key 2380E70A, created: 2007-12-25
(3)	Mozilla Software Releases <releases at mozilla.org> <===
	  1024 bit DSA key 812347DD, created: 2007-07-17
(4)	Mozilla Software Releases <releases at mozilla.org>
	  1024 bit DSA key 0E3606D9, created: 2005-09-29

	  ...

I chose (3) above. But note its key (ID?) is 812347DD.

Then, TO MY SURPRISE, when I ran gpg --verify again with this
key with a seemingly different ID, the verification succeeded!

To wit:

$ env LC_ALL=C LANG=C gpg --verify *.asc
gpg: Signature made Wed Feb 25 17:28:33 2009 JST using DSA key ID 17785FE8
gpg: Good signature from "Mozilla Software Releases <releases at mozilla.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 8D6F 1BA4 A340 4DDB 3F2F  D080 7447 4499 8123 47DD
     Subkey fingerprint: 3338 E6BA FF10 3B3D A6A9  E424 B57B 5484 1778 5FE8
ishikawa at ubi7f-w3:/extra/ishikawa/download/TB-3$

Note that thye key ID of the signature (printed on the first line)
is 17785FE8 as in the original state, but
now the signature succeeded.

But then I am very confused.

This key id was searched and could not be found in the server.
The server responded with a set of keys when I searched for
"@mozilla.org", and when I chose a key from the
found keys, it seemed to have a different key "812347DD".

What is going on here?

Is there an incompatibility between 1.4.1 and 1.4.9 regarding the
representation of key ID?
Or are keys 17785FE8 and 812347DD actually the same key with a
disguise?
I am perplexed here.

After writing all this, I realized the following.

But I am not sure if this is intended or not.
I think it is a bug somewhere.

When gpg (1.4.9) printed out 812347DD in the list of
found keys in response to my search request, it is not the key id, but
it seems to be the last hexadecimal digits of "PRIMARY key finger print".

Oh wait, the 17785FE8 printed as the missing key ID is the last digits of
"SUBKEY fingerprint" !?

If the key ID printed as missing is the SUBKEY fingerprint, and
the --recev-key and friends expect "PRIMARY key fingerprint", then
I don't think the search will ever succeed. Or will it?

(I just checked to see if --recv-keys 812347DD will succeed. It did!
It found the intended "release at mozilla.org" key and since the key has not
changed, nothing was done.)

I think we have a very serious usability problem here.
I don't know if this is the problem of 1.4.9 or the
signature and key created by 1.4.1 for this particular key.


TIA

PS: Previously, when I tried to verify signatures of various
open source archives and the signature keys were missing, the
IDs printed could be used to fetch the keys from PGP keyservers.
This is the first time the printed key ID could not be fetched, and
after the above steps, the validation could be done, but
quite in an unexpected manner.