sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] unwanted tolerance of buggy keys


From: Clint Adams
Subject: Re: [Sks-devel] unwanted tolerance of buggy keys
Date: Tue, 31 Jul 2012 03:01:09 +0000
User-agent: Mutt/1.5.20 (2009-06-14)

On Mon, Jul 30, 2012 at 10:10:10PM -0400, Jeffrey Johnson wrote:
> 0x10 -> 0x13 on a subkey to my reading. Meanwhile, the
> whole issue of what other signatures might be applied to
> subkeys afaik: the usage of pubkey signatures (other than
> binding/revocation) is all a bit murky imho.

Section 5.2.1 indicates that 0x10, 0x11, 0x12, and 0x13
signatures are over a user ID packet and a public-key
packet.  Admittedly it doesn't mention user attribute
packets, but even if you don't trust that part, you
can't have user IDs or user attributes on a subkey
anyway.  So it doesn't make any sense to group
certification signatures with subkeys.

> I'm not sure SKS is the Right Place to enforce conformance
> (much like discussions about OpenPGP binding signatures).

It does merging and enforces a transferable key structure
already, right?  If it didn't do that it would be rather
unhelpful.

> If you do wish to enforce conformance, the proper place is
> when punbkeys are imported, not within distribution, based
> on previously voiced opinions.

That makes more sense to me too, but then don't you have
gossip problems?

> I doubt that there are many subkeys with 0x10 -> 0x13 signatures
> no matter what (but haven't looked).

There are enough that it's causing me irritation.  I don't
know why that is the case, but I do not believe it is solely
due to the bug that GnuPG compensates for by moving those
subkey signatures to what is often the wrong place when you
run gpg --edit-key.  (It says "gpg: moving a key signature to
the correct place" but has been caught lying.)

This one is quite broken:

http://sks.pkqs.net:11371/pks/lookup?op=get&search=0x89CD4B21607559E6

gpg moves 87 signatures when you --edit it.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]