[Mageia-dev] PGP keys and package signing

[nicolas vigier]

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:
> >
> > > If possible, using a split key so that no single person can revoke a 
> > > signature or sign a key would be useful. This would prevent attacks where 
> > > an individual might be tricked into signing an attacker's key. It would 
> > > require multiple people to be tricked or have their systems compromised to 
> > > have that key compromised.
> > 
> > Yes, we could do something like that. Maybe each board member could have
> > a copy of the key, but encrypted with the key of all other board members,
> > so that it requires two people to access the key ? Or the people who
> > have the key don't know the passphrase, and the people who know the
> > passphrase don't have the key ?
> 
> Like : http://point-at-infinity.org/ssss ?
> 
> Too bad it doesn't seems to be much maintained :/

Interesting.

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

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

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

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