
chiaki.ishikawa at ubin
Jun 28, 2009, 10:56 PM
Post #1 of 1
(393 views)
Permalink
|
|
Strange Key ID problem. : subkey id is reported where primary key id should be reported as missing?
|
|
(I sent this to gnupg-bugs [at] gnu 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 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". 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" 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> Alexandro Colorado (Mozilla Mexico) <jza [at] mozilla> Alexandro Colorado (Grupo de usuarios Linux Tabasco) <jza [at] gultab> Alexandro Colorado (1 year OOoES individual signature) <jza [at] openoffic 1024 bit DSA key B1008E5E, created: 2008-11-24 (2) L. David Baron <dbaron [at] dbaron> L. David Baron <dbaron [at] mozilla> L. David Baron <dbaron [at] mozilla> L. David Baron <ldavidbaron [at] gmail> L. David Baron <dbaron [at] post> L. David Baron <dbaron [at] mozillafoundation> 1024 bit DSA key 2380E70A, created: 2007-12-25 (3) Mozilla Software Releases <releases [at] mozilla> <=== 1024 bit DSA key 812347DD, created: 2007-07-17 (4) Mozilla Software Releases <releases [at] mozilla> 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>" 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-w:/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" 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. _______________________________________________ Gnupg-devel mailing list Gnupg-devel [at] gnupg http://lists.gnupg.org/mailman/listinfo/gnupg-devel
|