[Mageia-dev] PGP keys and package signing

[Michael Scherer]

Le lundi 31 janvier 2011 à 18:26 +0100, nicolas vigier a écrit :
> On Mon, 31 Jan 2011, Michael Scherer wrote:
> 
> > Le lundi 31 janvier 2011 à 16:03 +0100, nicolas vigier a écrit :
> > > On Sun, 30 Jan 2011, Motoko-chan wrote:

> > > >>   - In case we think the packages@ key may have been compromised, or is
> > > >>     too old, or we want to change it for any other reason, we revoke the
> > > >>     key, and/or revoke the signature from board@ so that it is no
> > > >>     longer accepted by urpmi. We create a new key, we sign it with
> > > >>     the board@ key and we can start to use this new key.
> > > > Sounds good. I'd almost suggest a new packages signing key for each new 
> > > > release that is valid for the supported life of the release plus one year. 
> > > > It's a bit more work, but would reduce the damage a key leak would cause. 
> > > > Unfortunately, this would bring back the problems of re-signing packages 
> > > > when they are turned into a release.
> > > 
> > > I think we should avoid keys with expiration date because :
> > >  - maybe we will want to extend supported life of the release
> > >  - some people may want to continue using the release after end of life
> > 
> > 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 ).
 
> > And people should be able to force a bypass of the system of course, but
> > they will be on their own ( ie, that's quite the definition of EOL ).
> > And this should be documented, and easy to do ( but warn people without
> > harrassing too much can be quite difficult ).
> > 
> > We can also say that we erase the keys once it is not planned to be used
> > anymore, so we would no longer care about protecting them ( ie, we say
> > the key is expired for good, and that's all ).
> 
> If we decide that a key won't be used anymore, and don't want to care
> about protecting it, I think we should revoke it (or its signature) as
> soon as possible, instead of waiting for it to expire.

Well, we can do both. Revoke it, and for those that still use it and
didn't update, let it expires.

> I think the only use of expiration date would be if one day all
> known keyservers are down and never come back (I think it's unlikely to
> happen, or we will also have other problems)

Yep, unlikely ( unless in Egypt )

Maybe this also mean we should have a SKS server too
( http://minskyprimus.net/sks/ ).

> , or we lose all private
> keys, so we can't revoke them or their signature. But if we lose all
> private keys, we will also have other problems (like not being able to
> sign a new key), so we should avoid it.

Usually, revokation certificates can be prepared in advance. ( in case
you lose the key, simply ). So this should also be done.

The point about losing all keys also mean we need to take backup in
accounts ( for example, encrypt them, bacula can do it client side ).
 
> > >  - 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 ?

-- 
Michael Scherer