Re: [Sks-devel] Re: Broken reconciliation

[Yaron M. Minsky]

Actually, there's another possibility, which is that the offending keys
can simply be removed from the keyserver, using "sks drop <hash>". 
There are only a handful of examples of such keys currently, I think
(less than 10), so that should fix it.  Peter, can you generate a list
of which servers you think are affected?

Yaron

On Sun, 2004-04-11 at 00:19, Yaron M. Minsky wrote:
> Alright.  Here's the deal, as far as I can tell.  It looks like the key
> in question does not conform to the PGP standard.  In particular, it is
> a V3 key, and yet it has subkeys.  That's not actually allowed, and SKS
> knows it and rejects it accordingly.
> 
> And yet, somehow, one of the keyservers has already accepted this key. 
> Maybe the test wasn't implemented right in some previous version. 
> Anyway, that's why there is a persistent difference between the
> keyservers.  One system tries to add the key, but the add fails.  
> 
> There are two possible solutions:
> 
> 1) rely on the database cleaner ("sks cleandb").  I need to look to see
> whether it would fix it as it stands, or whether a modification to that
> would be needed.  Thus, the offending key would be thrown out on any
> keyserver that ran the cleaner.  The keyservers with good versions of
> the key would end up distributing those, and all would be well.
> 
> 2) Make the SKS key parsing rules more lenient, allowing V3 keys to have
> subkeys, like V4 keys.
> 
> Any thoughts on which of these options is preferable?
> 
> y
> 
> On Fri, 2004-03-26 at 06:40, Peter Palfrader wrote:
> > On Thu, 25 Mar 2004, Yaron M. Minsky wrote:
> > 
> > > I haven't been following the discussion about the broken keys as closely
> > > as I should have, but I'll try to make up for it now.  Let me tell you
> > > what I have gathered and what thoughts I have about it.
> > 
> > > Do you have any insights?  Maybe you could email me the list of missing
> > > hashes, and I can try to look into the question of where the differences
> > > came from.
> > 
> > It seems to have to do mostly with v3 keys with subkeys.
> > 
> > On keyserver.noreply.org I have the following hash in diff-<ks-old>:
> > F77745FECCE6A3C8D0CB717504A7761F
> > 
> > When you look at ks-old, you will find a v3 key with subkeys:
> > http://keyserver-old.noreply.org:11371/pks/lookup?op=hget&search=F77745FECCE6A3C8D0CB717504A7761F
> > 
> > Pasting that output into gpg, gives:
> > pub  1024R/7BC93C61 2000-03-10 Andreas Ferber <address@hidden>
> > sub  1024D/CFC240FF 2000-07-04 
> > sub  1024g/D1C63397 2000-07-04 
> > 
> > Now if you search for the keyid on the servers, both keyserver and
> > ks-old will tell you they only have 0x7BC93C61, but without any subkeys,
> > and claim its hash is: FA10EE7EF298F6EDE3E58C963D479F92
> > 
> > Both servers have the same key under FA10EE7EF298F6EDE3E58C963D479F92.
> > 
> > F77745FECCE6A3C8D0CB717504A7761F does not only appear on ks-old, it also
> > appears on pyxis.cns.ualberta.ca, and the second instance of SKS on
> > keyserver.noreply.org.
> > 
> > 
> > 
> > 
> > 
> > Another example is 21CD2A0C412A5E822E9B0CC429B4D5BB.  It appears on
> > pyxis.cns.ualberta.ca, pgp.hpc.unm.edu, the other sks on
> > keyserver.noreply.org (available at :21371 btw), ks-old, and 5 more
> > keyservers.
> > 
> > Pasting the output of
> > http://keyserver-old.noreply.org:11371/pks/lookup?op=hget&search=21CD2A0C412A5E822E9B0CC429B4D5BB
> > into gpg yields:
> > pub  1024R/81DFF155 1997-12-01 Ewald Beekman <address@hidden>
> > uid                            Ewald H. Beekman <address@hidden>
> > uid                            Ewald Beekman <address@hidden>
> > sub  1024D/05816A41 2000-05-30
> > 
> > 
> > http://keyserver.noreply.org:11371/pks/lookup?search=E.H.Beekman%40amc.uva.nl&fingerprint=on&hash=on&op=index
> > http://keyserver.noreply.org:11371/pks/lookup?search=0x81DFF155&fingerprint=on&hash=on&op=index
> > both give a 'key not found'
> > 
> > http://pgp.hpc.unm.edu:11371/pks/lookup?search=E.H.Beekman%40amc.uva.nl&fingerprint=on&hash=on&op=index
> > http://keyserver-old.noreply.org:11371/pks/lookup?search=0x81DFF155&fingerprint=on&hash=on&op=index
> > both give an empty reply, only showing the column heads, nothing else:
> > | $ lynx -dump 
> > 'http://keyserver-old.noreply.org:11371/pks/lookup?search=0x81DFF155&fingerprint=on&hash=on&op=index'
> > | 
> > |                         Search results for '0x81dff155'
> > | 
> > | Type bits/keyID    Date       User ID
> > | $ 
> > 
> > 
> > So v3 keys with subkeys appear to be in the recon database, but cannot
> > be synced via gossip.  I think they might come from merges, (fast)build.
> > 
> > 
> > Peter
-- 
|--------/            Yaron M. Minsky              \--------|
|--------\ http://www.cs.cornell.edu/home/yminsky/ /--------|

Open PGP --- KeyID B1FFD916
Fingerprint: 5BF6 83E1 0CE3 1043 95D8 F8D5 9F12 B3A9 B1FF D916