[Mageia-dev] PGP keys and package signing

[Maarten Vanraes]

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