-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2012-05-27 11:50, Giovanni Mascellani wrote:
> Ciao.
>
> Il 27/05/2012 11:23, Kristian Fiskerstrand ha scritto:
>> I too, agree, that this is something that should be considered.
>>
>> GnuPG is already doing its own cleaning up of the code for
>> similar reasons, something which was discussed back in April 2011
>> as well[0] (and reminded me about [1], I had nearly forgotten
>> about that) :)
>
> 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. For
> example, I think that many keys are not used anymore, were created
> some times ago by some random people that then lost interest in PGP
> and just left it, maybe without even revoking it. I'm an example of
> that: lots of keys with my name date back to when I didn't really
> understand how keys worked (I managed to revoke most of them, but
> for some I really lost the private key).
>
> The mechanism I thought to is that: each piece of information in
> SKS has associated an expiry date, which can be renewed simply by
> reuploading that thing. This expiry date is communicated between
> SKS together with the piece of information itself. When if expiry
> date is reached, the server is allowed to drop that information.
>
> This way people can easily retain the things they're interested
> into (simply reuploading them regularly), while things not
> interesting to anyone anymore fade out.
>
> I don't know what expiry time frame we could consider acceptable:
> probably anything between one month and one year would make sense.
>
> Did you ever think at something like that?
That has been discussed previously, and I am, at least personally very
much against it. There are good reasons to keep historical data on the
keyservers in order to increase security.
Especially in the case of revoked keys (consider the example where
user A generate a key, the key gets compromised by B, so A send out a
revocation certificate. If this is then later deleted, user B can
upload a non-revoked key and the messages are compromised)
The reason this differ from the e.g the PGP Corp auto-signature, is that
(i) It add a lot of bloat
(ii) removing the expired old signatures, in my mind, doesn't reduce
the security of the overall system
(iii) I question the usefulness of the auto-signing itself.
- --
- ----------------------------
Kristian Fiskerstrand
http://www.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Corruptissima re publica plurimæ leges
The greater the degeneration of the republic, the more of its laws
- ----------------------------
This email was digitally signed using the OpenPGP
standard. If you want to read more about this
The book: Sending Emails - The Safe Way: An
introduction to OpenPGP security is now
available in both Amazon Kindle and Paperback
format at
http://www.amazon.com/dp/B006RSG1S4/
- ----------------------------
Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJPwfv5AAoJEBbgz41rC5UIA88QAIAT1WefkvZZk0JMTianK5VG
9MUzu6i+jfuqWVK4aZo8Xh01JZHQfe3/2934HUhW9fv1fNoNt8S0zSMrEKaYzjur
8Li9qDmOPa+CRAwvSVPlsgd8sMnynwVZjYJCiQllubtweqiSOjrzqQAfekRrskwe
wCj2+LbjJL/nPRJVbTMcwwR+kF/mmRQypuycmsBQXySSjEMh0yl0BlYiW1bgSEDk
ZdtvuFNtZ1jPMmXdvRyvC515kUwkC0sfUrJhtkBq/RT/rmSVLzCBvMPXaxugmSew
lPeXe4MMw7DxFWHmOB4kXEMX/Toa/qTWuF7v1tEDL0iIGvH0WQUFUO+TTVXVtdTV
aJk1U+oUUv/shCrVavjxX3bvHT4ndUI6J38YSOCuIqFA5rS+p6ni8eWKWDEu4EdE
evSKDyUoiVNB/ZeRMxr7riVquf+9kG6L55GFka3yD/WDDH49RmJsVWuOW1OlG5Eb
cb0YOZjpakGbJo1bYJ7ZTckhd33WDuZYcaGwfCK3q/YavmXM2E5c8xkNRJ0A3Pwz
t1XYi3w5Y/j7QXUDkoJ4tduobgArRkJdswdrBEYHfHUg395rFDLgIae7VX4MZN0s
F/1IUW4a9hiAugh/MSEWBzY+vvYuEgR/3VCJ8BIaW/Ff3RWFASGoUD3zynxtrkQV
I0qlzkSdh0tHApSEOFee
=7mMy
-----END PGP SIGNATURE-----
_______________________________________________
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
