[Mageia-dev] PGP keys and package signing

[Michael Scherer]

Le lundi 31 janvier 2011 à 20:12 +0100, nicolas vigier a écrit :
> On Mon, 31 Jan 2011, Michael Scherer wrote:
>
> > 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).

But we would notice it, I guess. That could be a good idea to check if
any of our old key do not appear on the keyring with a non expired
date :)

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

Or maybe we can keep the expiration date to indicate when the key should
not be used anymore ( ie, as a indication, nothing more, as we cannot
guarantee anything ), and once the expiration date occurs ( expiration
date set on our copy of the key ), we upload the revocation certificate
( with we == a cronjob , by checking the date of the key )

We could even use this on client side to indicate that a release is no
longer supported. ( ie, DRY principle ).

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

It is up to the tool to use or not the expiration. Ie, if we tell to
urpmi "do not trust expired key", we can as well say "keep a list of key
that have expired and never trust a key, even if it say the contrary".

But indeed, that doesn't sound very secure per se :/

-- 
Michael Scherer