Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?

[Jeffrey Johnson]

On May 27, 2012, at 8:17 PM, John Marshall wrote:

> On 27/05/2012 22:39, Jeffrey Johnson wrote:
>> On May 27, 2012, at 6:15 AM, Robert J. Hansen wrote:
>>> 
>>>     "We never, never, never lose certificates."
>> 
>> And what is being discussed is filtering an expired signature, not
>> a public key, for one specific robo-signer.
>> 
>> Even if the filtering was solely limited to
>>      an "opt-in" user requested hkp:// extension narrowly limited to just 
>> 0xca57ad7c
>>      expired signatures
>> there starts to be a benefit to GPG users who otherwise are "cleaning"
>> imported signatures manually.
> 
> Users cleaning imported signatures *manually*?  GnuPG users, at least,
> can simply add the import-clean import-option to their gpg.conf.
> 
> What warrant do we have for applying any filtering at the servers at
> all? If the "problem" is one robo-signer, wouldn't it make sense to talk
> to its minders?
> 

Would make sense, but the drip, drip, drip robo-signing has been going
on for 7+ years. I originally thought  0xca57ad7c was a historical  "mistake"
that had to be lived with. Bu it seems that the same problem continues 
currently.

It would _NOT_ be hard or necessarily controversial to filter the expired
robo-signatures on retrieval through hkp:// … whether the gossip protocol
can be changed to accommodate "filtering" is a far harder implementation,
both because of "policy" as well as implementation. Adding a filter on retrieval
shouldn't be too hard (imho).

But if robo-signing with weekly, per-retrieval, re-signings and expiries
its still active .. well its time (imho) to consider the consequences: do the 
math.

Google 0xc5a7ad7c: to see the context: its not hard to find/see the issue.

hth

73 de Jeff