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

[Jeffrey Johnson]

On 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 easiest solution would be to auto-expire keys after a fixed time
> (a good strategy anyway from a security perspective).
> 

Its the expired robo-signatures on existing pubkeys, not
the pubkeys, that need filtering. There is also a need to
delete pubkeys

Is there a solution that can filter out specific expired
signatures on pub keys that can be gossip'd efficiently?

AFAIK additional certification signatures are accumulated
and the pubkeys are then re-distributed and re-merged.

How should one block distributing a specific pubkey's expired signatures
on all existing pubkeys efficiently?

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