[Mageia-dev] PGP keys and package signing

[Michael Scherer]

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 :/


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

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

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

-- 
Michael Scherer