Here's my quick sense of what the reasonable solutions are:
- Add a key-deletion authority, as Gabor suggested. These deletion
certificates would be gossiped around, and would lead to deletion of keys.
The deletion certificates would stick around for a long time, but they'd
be small, so the cost would be low. One coud have them auto-expire at a
specified time out, so that you eventually can GC them.
- Have SKS have a local key-deletion file. Keys listed in the key
deletion file would be excluded from the local set, but would probably be
kept in the Ptree, so that they don't show up as a difference when
reconciling. People can work together to distribute key-deletion files
from a trusted source, but it's at the discretion of the manager of any
individual key server.
The second one seems more likely to work as a social matter, since building
an agreed, trusted authority is tricky.
(To say the obvious, I don't have the time to work on implementing either
approach. But I'm happy to have others do so. Something like this was
part of my original plans for SKS, but it never got done.)
y
On Sun, May 27, 2012 at 6:15 AM, Robert J. Hansen <r...@sixdemonbag.org>wrote:
> On 5/27/12 5:50 AM, Giovanni Mascellani wrote:
> > I'm just a newbie here, but actually I'd like to see the same concept
> > applied in a more general way: I think there is much garbage in the
> > keyservers, even behind the PGP robo-signer.
>
> The problem here is this violates one of the principle design features
> of the keyserver network:
>
> "We never, never, never lose certificates."
>
> It is preferable for a keyserver to outright go down than it is for even
> one certificate to be lost. If a certificate is lost then a malicious
> actor could re-upload another key with the same short ID (a very easy
> thing to do), and that could facilitate all different kinds of attacks
> on people who don't properly validity-check certificates before using them.
>
> If the keyserver goes down then everyone knows in short order there's a
> problem. If a certificate is lost and silently replaced it might be a
> long time before being discovered. (Discovery is more likely if the
> keyserver is synchronizing with others, but there are a lot of
> standalone servers.)
>
> Further, expired certificates are still useful. I have some emails more
> than five years old that are still relevant and useful. If a
> certificate gets removed just because it expires, how am I to check the
> signature on those messages in order to ensure they haven't been
> tampered with? If the expired certificate remains on the servers,
> though, I can download it, validity-check it, and be confident in the
> integrity of my message.
>
> The same logic applies to revoked certificates: they're still useful for
> the same reasons.
>
> The keyservers never, never, never lose certificates. That's a design
> goal and one that the SKS maintainers believe is a good one. I agree
> with them, and want to see this design goal maintained in all future
> development.
>
> That said, welcome to the community, and please understand that although
> I think your idea is awful I'm honestly happy to see you here. :) The
> mailing list is a place where ideas come into violent collision, but we
> try to be reasonable human beings to each other. Welcome!
>
> _______________________________________________
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
_______________________________________________
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
