[Mageia-dev] PGP keys and package signing

Mon Jan 31 20:12:24 CET 2011

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