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

[Yaron Minsky]

On Wed, May 30, 2012 at 9:22 PM, Ari Trachtenberg <address@hidden> wrote:

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

The deleted keys would be considered as present from the point of view of the reconciliation algorithm, so I'm not sure it would truly degrade performance.  The only issue is, what do you do if the first time you learn of a key is from someone who deleted it?  That said, I think there is a reasonable heuristic one could use here: don't add the key for awhile, seeing if you're going to encounter someone in the reconciliation who actually has the key.  And if you don't, eventually learn it as an "unknown" key, and add it to your Ptree.

That said, GC'ing the deletions is an issue, but it's just the keyid you need to keep, so it's not so bad.  

 

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