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 _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel