[Mageia-dev] PGP keys and package signing

Mon Jan 31 20:37:07 CET 2011

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