Op maandag 31 januari 2011 20:12:24 schreef nicolas vigier: > On Mon, 31 Jan 2011, Michael Scherer wrote: > > Le lundi 31 janvier 2011 à 18:26 +0100, nicolas vigier a écrit : > > > On Mon, 31 Jan 2011, Michael Scherer wrote: > > > > We can 1) have a long enough expiration date ( but EOL + 1y seems > > > > quite enough IMHO ) > > > > 2) push unexpired keys before it is too late if needed ( I routinely > > > > push my key after extending the expiration date ). > > > > > > Pushing new unexpired keys also means we need to resign all old > > > packages if we want them to be installable. So that's not something we > > > want to do too often if it's not needed. > > > > Nope, I didn't say "new unexpired key", but just push the same key, with > > the expiration date extended. That should be painless IIRC ( at least, > > it is for me ). > > Oh, I misunderstood this as I imagined it was not possible to change > expiration date on a key as it would be difficult to check if the change > was done before expiration. But after checking, it is indeed possible, > and it is even possible to do it after the expiration date. > > So we can do it, but we should remember that it does not protect against > a key compromised after it has expired (as someone stealing the key > can change the expiration date even after it has expired). > > So the only use of expiration date I see is to check that the key was > updated from keyserver recently. Maybe we can set a short expiration > time (15 days ?), and have something in cron to update it a few days > before it expire ? > > > > > > - I don't think using expiration date reduce the damage of a > > > > > leaked > > > > > > > > > > key. If the key is leaked, we revoke it (or its signature) > > > > > immediatly on all key servers, which should be faster than > > > > > waiting for the key to expire. And replacing an expired key is > > > > > not more simple than replacing a revoked key. > > > > > > > > The problem is not leaking the key, it is about cryptographic attacks > > > > about older keys. > > > > > > > > If in 10 years, there is some technology that allows people to get > > > > our private key by bruteforce on the public one, if it is expired, > > > > attackers will not be able to use it even if they have it. Since the > > > > plan is to say "every key signed is valid", then we are potentially > > > > screwed if a old key is compromised offline. > > > > > > If in 10 years there is some technology to get our private key, then > > > it's still possible to revoke the key at that time. > > > > > > Instead of deciding > > > now that the key will expire in a few years, I would prefer that we > > > look at it in a few years to decide if we want to revoke it. > > > > Wouldn't it be too late ? > > Considering that it is possible to update expiration date even after it > has expired, this expiration date doesn't protect against some technology > that would allow people in the futur to bruteforce the private key.
what if there is no network access? keyservers are nice, but an isolated install should still be possible...
