Mailing List Archive: GnuPG: devel

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

Index | Next | Previous | View Threaded

wk at gnupg

Jun 29, 2009, 12:03 AM

Post #1 of 3 (561 views)
Permalink

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

On Mon, 29 Jun 2009 07:56, chiaki.ishikawa [at] ubin said:

> (After writing this summary, I now think it is a bug, but am not sure

Yes it is a bug. But not in GnupG but in tghe keyserver software.

> 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.

Both keyservers run old and non-OpenPGP compatible software - Do not use
them.

I tried this too (using gpg2 but that doesn't matter)

$ gpg2 --recv-key 17785FE8
gpg: requesting key 17785FE8 from hkp server keys.gnupg.net
gpg: key 812347DD: public key "Mozilla Software [...]
gpg: Total number processed: 1
gpg: imported: 1

So everything is fine. The key was taken from one of the SKS keyservers
to which keys.gnupg.net resolve. If you now look at the key:

$ gpg2 --list-key 17785FE8
pub 1024D/812347DD 2007-07-17 [expires: 2009-07-16]
uid Mozilla Software Releases <releases [at] mozilla>
sub 1024D/17785FE8 2007-07-17 [expires: 2009-07-16]
sub 2048g/1B0EC2E7 2007-07-17 [expires: 2009-07-16]

You will notice that 17785FE8 is a signing subkey. The old pks software
can't handle this and breaks the key.

We do have this problem for years now and at least the admins of
pgp.mit.edu don't care about it and keep on running this broken
software.

I am now considering whether we should detect
Server: pks_www/0.9.6
and reject this one as entirely broken. Maybe just a warning if
--expert is used.

Shalom-Salam,

Werner

--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

JPClizbe at tx

Jun 29, 2009, 12:59 AM

Post #2 of 3 (519 views)
Permalink

Re: Strange Key ID problem. : subkey id is reported where primary key id should be reported as missing? [In reply to]

Werner Koch wrote:
> On Mon, 29 Jun 2009 07:56, chiaki.ishikawa [at] ubin said:
>> (After writing this summary, I now think it is a bug, but am not sure
> Yes it is a bug. But not in GnupG but in the keyserver software.
>
>> 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.
>
> Both keyservers run old and non-OpenPGP compatible software - Do not use
> them.
>
> I tried this too (using gpg2 but that doesn't matter)
<snip>
>
> So everything is fine. The key was taken from one of the SKS keyservers
> to which keys.gnupg.net resolve. If you now look at the key:
>
<snip>

The key shows correctly on the SKS servers:
http://keyserver.gingerbear.net/pks/lookup?search=0x17785FE8&fingerprint=on&op=vindex

> We do have this problem for years now and at least the admins of
> pgp.mit.edu don't care about it and keep on running this broken
> software.

And we keep on giving the same advice over and over not to use this and
other broken PKS servers.

> I am now considering whether we should detect
> Server: pks_www/0.9.6
> and reject this one as entirely broken. Maybe just a warning if
> --expert is used.

No complaints here. Maybe it would push the PKS admins to upgrade.
I doubt anyone is interested in making the PKS code RFC compliant.

--
John P. Clizbe Inet:John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or
mailto:pgp-public-keys [at] gingerbear?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

Attachments:

signature.asc (0.66 KB)

chiaki.ishikawa at ubin

Jun 29, 2009, 4:08 AM

Post #3 of 3 (514 views)
Permalink

Re: Strange Key ID problem. : subkey id is reported where primary key id should be reported as missing? [In reply to]

Dear Werner Koch,

Thank you for your prompt feedback.

On (06/29/2009 04:03 PM), Werner Koch wrote:
> On Mon, 29 Jun 2009 07:56, chiaki.ishikawa [at] ubin said:
>
>> (After writing this summary, I now think it is a bug, but am not sure
>
> Yes it is a bug. But not in GnupG but in tghe keyserver software.
>

Oh, I didn't realize this.
It is very difficult to figure this out as this stands.

>> 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.
>
> Both keyservers run old and non-OpenPGP compatible software - Do not use
> them.
>
> I tried this too (using gpg2 but that doesn't matter)
>
> $ gpg2 --recv-key 17785FE8
> gpg: requesting key 17785FE8 from hkp server keys.gnupg.net
> gpg: key 812347DD: public key "Mozilla Software [...]
> gpg: Total number processed: 1
> gpg: imported: 1
>
> So everything is fine. The key was taken from one of the SKS keyservers
> to which keys.gnupg.net resolve. If you now look at the key:
>
> $ gpg2 --list-key 17785FE8
> pub 1024D/812347DD 2007-07-17 [expires: 2009-07-16]
> uid Mozilla Software Releases<releases [at] mozilla>
> sub 1024D/17785FE8 2007-07-17 [expires: 2009-07-16]
> sub 2048g/1B0EC2E7 2007-07-17 [expires: 2009-07-16]
>
> You will notice that 17785FE8 is a signing subkey. The old pks software
> can't handle this and breaks the key.
>
> We do have this problem for years now and at least the admins of
> pgp.mit.edu don't care about it and keep on running this broken
> software.
>
> I am now considering whether we should detect
> Server: pks_www/0.9.6
> and reject this one as entirely broken. Maybe just a warning if
> --expert is used.

I think that maybe it is a good idea to
have this rejection.
Then at least, the user of gpg will try to move to the
sites that run newer software.
(I wonder though why my setup didn't access keys.gnupg.net automatically.
Maybe the other PCs on which gpg worked to fetch such keys
were configured properly to access newer sites whereas the
said PCs in my post were configured lately with gpg and
so I had to type in keyserver names manually (I didn't have the
time to edit the configuration file. I just tried to verify the
archives on the fly.)

Also, such messages *may* encourage the admins of sites
that run old software to move on to the newer software when
a system upgrade is attempted. Just a chance.

So I am for such a change.

Thank you again for your explanation.

Sincerely,
Chiaki Ishikawa

> Shalom-Salam,
>
> Werner
>

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads