[Mageia-dev] PGP keys and package signing

Mon Jan 31 17:18:25 CET 2011

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
+
+