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: Jeffrey Johnson
Subject: Re: [Sks-devel] unwanted tolerance of buggy keys
Date: Mon, 30 Jul 2012 23:10:57 -0400

On Jul 30, 2012, at 11:01 PM, Clint Adams <address@hidden> wrote:

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

Doesn't mention == not forbidden

(at least if you are citing a "standard" like RFC-4880 imho)

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

Depends on how the implementation is done. The only
chance of avoiding gossip (and down rev version gossip
issues) is to enforce policy when the pubkey is imported
or exported.

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

Irritation perfectly understood and I'm more than willing
to believe that gnupg (and other implementations) have
corner cases that may need to be avoided.

But at least let's get the reason -- pragmatism -- correct
instead of mis-reading the RFC-4880 standard.

> This one is quite broken:
> 
> http://sks.pkqs.net:11371/pks/lookup?op=get&search=0x89CD4B21607559E6
> 
> gpg moves 87 signatures when you --edit it.
> 

I'm perfectly willing to believe that there are
b0rken keys in SKS: I did verify all signatures on
2 months of SKS updates (about ~4M signatures)
and saw many many types of *ahem* quirky issues.

73 de Jeff
> _______________________________________________
> Sks-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/sks-devel




reply via email to

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