[Mageia-dev] PGP keys and package signing

Mon Jan 31 18:26:46 CET 2011

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:
+> >
+> > > 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 :/
+
+Interesting.
+
+> > >>   - 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.
+
+> 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.
+
+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), 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.
+
+> >  - 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.
+
+