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

[Ari Trachtenberg]

The problem with the second plan is that the potential number of differences
between hosts could grow quite large, degrading performance.

The easiest solution would be to auto-expire keys after a fixed time
(a good strategy anyway from a security perspective).

Best,
        -Ari

On May 30, 2012, at 7:55 PM, Yaron Minsky wrote:

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

---
Ari Trachtenberg                   Assoc. Prof., Assoc. Grad. coChair, ECE
address@hidden                    http://people.bu.edu/trachten