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

[Jeffrey Johnson]

When I was first implementing SKS retrieval, I verified about
4M recently updated keys,

While checking  expired signature behavior, it was very easy
to spot 0xca57ad7c showing up repeatedly, often enough
to imprint the fingerprint sufficiently that I actually looked
(and decided to never again verify any signature from a
robo-signer).

I'm somewhat surprised to see that the robo-signer is _STILL_
active with recent signatures here
        
http://keyserver.kjsl.org:11371/pks/lookup?search=0xd5920e937cc1e39b&op=vindex

Is there really a need to carry around every expired signature forever
from a robo-signer?

I'm not complaining mind you: I easily see the need to carry around
historical information forever even after expiry.

But the drip, drip, drip is bothersome bloat: eventually some of these
robo-signed pubkeys are going to achieve 10MB or more in size.

Is it perhaps time to start considering an end-of-life drop-dead point
for robo-signed pubkeys and also undertake active filtering?

If not, well, that's fine too: I'll increase the size of the buffer used
for HKP to accommodate the bloatiness.

How widespread is this behavior?

I sure hope there is some known security purpose for resigning
weekly. Its not too hard to imagine that daily or even hourly
re-signings might be undertaken, leading to Yet More Accelerated Bloat.

Should/could some of the expired signatures be actively filtered (and archived)
instead of being carried in SKS key servers forever? Yes a policy change
like this would be controversial and difficult to deploy.

73 de Jeff