Re: [Sks-devel] Verification of keys on upload and removal options

[Malte]

On Tuesday, March 29, 2016 7:52:38 AM CEST Robert J. Hansen wrote:
> > But they kind of do already, so I don't see the point here.
> 
> They don't.  Let's say a keyserver operator goes rogue and decides to
> drop 0xB44427C7 (my cert) from the keyserver network.  Great, ten
> minutes later it gets replaced during the next sync.  So the keyserver
> operator deletes it again.  Ten minutes later it comes back.  The
> keyserver operator sets up a cron job to delete it every ten minutes...
> and a week later other keyserver operators ask, "So why is it you're
> always missing this one certificate?"
> 
> I would be surprised if at least one keyserver operator today didn't do
> a second resync a minute after the first, just to make sure no
> certificates were getting dropped.

Sure. But I could modify the software to deliver "no data" for a list of key 
ids. I might even modify it so that it delivers everything as long as the 
requesting IP is in the list of peers.


> > If there is doubt in the trustworthiness of a keyserver (operator), other
> > keyservers can execute the same verification process, and if discrepancy
> > is
> > found, block deletion/all requests from the rogue keyserver until the
> > issue is resolved.
> 
> But that's not what you said.  What you said is, the individual
> keyserver operator gets to decide whether the removal criteria has been
> met.  Now you're saying, "well, other keyserver operators do, too, so
> other people get a say in it as well."
> 
> Make up your mind, draft a formal proposal, and try again.  :)

My mind is quite made up. What I wrote is also not contradicting. My first 
answer was concise for what happens if everyone is playing along nicely.

The question was for policy.

The rest is mitigation of rogue keyservers. And that's more a protocol/manual 
labor (removing peers from the list of peers) question if you ask me.


And it's all super hard, I get that and I'm not complaining. I just don't see 
the hurdles on the policy, but the protocol side.

Another place where we would have to put more effort into is who we are peering 
with. And I would totally welcome that as well.

Sincerely,

Malte

-- 
1BEA 8159 A070 2E53 0152  A59F 0CC5 76E9 703E 1DDC