[Mageia-dev] PGP keys and package signing

Mon Jan 31 20:42:44 CET 2011

Op maandag 31 januari 2011 20:12:24 schreef nicolas vigier:
+> On Mon, 31 Jan 2011, Michael Scherer wrote:
+> > Le lundi 31 janvier 2011 à 18:26 +0100, nicolas vigier a écrit :
+> > > On Mon, 31 Jan 2011, Michael Scherer wrote:
+> > > > 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 ).
+> 
+> Oh, I misunderstood this as I imagined it was not possible to change
+> expiration date on a key as it would be difficult to check if the change
+> was done before expiration. But after checking, it is indeed possible,
+> and it is even possible to do it after the expiration date.
+> 
+> So we can do it, but we should remember that it does not protect against
+> a key compromised after it has expired (as someone stealing the key
+> can change the expiration date even after it has expired).
+> 
+> So the only use of expiration date I see is to check that the key was
+> updated from keyserver recently. Maybe we can set a short expiration
+> time (15 days ?), and have something in cron to update it a few days
+> before it expire ?
+> 
+> > > > >  - 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 ?
+> 
+> Considering that it is possible to update expiration date even after it
+> has expired, this expiration date doesn't protect against some technology
+> that would allow people in the futur to bruteforce the private key.
+
+
+what if there is no network access? keyservers are nice, but an isolated 
+install should still be possible...
+