[Mageia-dev] PGP keys and package signing

Mon Jan 31 18:56:27 CET 2011

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