Le lundi 31 janvier 2011 à 18:26 +0100, nicolas vigier a écrit : > On Mon, 31 Jan 2011, Michael Scherer wrote: > > > Le lundi 31 janvier 2011 à 16:03 +0100, nicolas vigier a écrit : > > > On Sun, 30 Jan 2011, Motoko-chan wrote:
> > > >> - In case we think the packages@ key may have been compromised, or is > > > >> too old, or we want to change it for any other reason, we revoke > > > >> the > > > >> key, and/or revoke the signature from board@ so that it is no > > > >> longer accepted by urpmi. We create a new key, we sign it with > > > >> the board@ key and we can start to use this new key. > > > > Sounds good. I'd almost suggest a new packages signing key for each new > > > > release that is valid for the supported life of the release plus one > > > > year. > > > > It's a bit more work, but would reduce the damage a key leak would > > > > cause. > > > > Unfortunately, this would bring back the problems of re-signing > > > > packages > > > > when they are turned into a release. > > > > > > I think we should avoid keys with expiration date because : > > > - maybe we will want to extend supported life of the release > > > - some people may want to continue using the release after end of life > > > > 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 ). > > And people should be able to force a bypass of the system of course, but > > they will be on their own ( ie, that's quite the definition of EOL ). > > And this should be documented, and easy to do ( but warn people without > > harrassing too much can be quite difficult ). > > > > We can also say that we erase the keys once it is not planned to be used > > anymore, so we would no longer care about protecting them ( ie, we say > > the key is expired for good, and that's all ). > > If we decide that a key won't be used anymore, and don't want to care > about protecting it, I think we should revoke it (or its signature) as > soon as possible, instead of waiting for it to expire. Well, we can do both. Revoke it, and for those that still use it and didn't update, let it expires. > I think the only use of expiration date would be if one day all > known keyservers are down and never come back (I think it's unlikely to > happen, or we will also have other problems) Yep, unlikely ( unless in Egypt ) Maybe this also mean we should have a SKS server too ( http://minskyprimus.net/sks/ ). > , or we lose all private > keys, so we can't revoke them or their signature. But if we lose all > private keys, we will also have other problems (like not being able to > sign a new key), so we should avoid it. Usually, revokation certificates can be prepared in advance. ( in case you lose the key, simply ). So this should also be done. The point about losing all keys also mean we need to take backup in accounts ( for example, encrypt them, bacula can do it client side ). > > > - 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 ? -- Michael Scherer
