Le lundi 31 janvier 2011 à 16:03 +0100, nicolas vigier a écrit : > On Sun, 30 Jan 2011, Motoko-chan wrote: > > > If possible, using a split key so that no single person can revoke a > > signature or sign a key would be useful. This would prevent attacks where > > an individual might be tricked into signing an attacker's key. It would > > require multiple people to be tricked or have their systems compromised to > > have that key compromised. > > Yes, we could do something like that. Maybe each board member could have > a copy of the key, but encrypted with the key of all other board members, > so that it requires two people to access the key ? Or the people who > have the key don't know the passphrase, and the people who know the > passphrase don't have the key ?
Like : http://point-at-infinity.org/ssss ? Too bad it doesn't seems to be much maintained :/ > >> - 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 ). 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 ). > - 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. -- Michael Scherer