Re: Secure APT Key Management

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Raphael Hertzog <hertzog@debian.org> writes:

> On Wed, 26 Jul 2006, Florian Weimer wrote:
>> * Martin Schulze:
>> 
>> > I'd really love to see this feature properly implemented.
>> 
>> The only approach which is known to work is static keys for stable
>> releases and stable security updates.  The keys can be stored off-line
>> or on-line, at the discretion of the respective teams.
>> 
>> So far, we have botched all yearly key rollovers, and there is zero
>> evidence that we'll get the first one that reallly matters right.
>> Unfortunately, the key rollover approach is generally assumed to be
>> required to achieve a decent level of security and strongly preferred
>> over the alternatives.  Needless to say, I very strongly disagree with
>> that position.
>
> Why don't we put two signatures ? One from a yearly key and one from a
> release key.
>
> Of course, both keys would probably be compromised at the same time (if a
> compromis arise), but at least the user has the choice to trust either a
> yearly key only or the release key only (and can thus decide to not have
> to handle the key rollover).
>
> Cheers,

Having the unstable key signed by the old-stable and stable keys
(which are kept offline, right?) would be a start.

But why not have a bunch of developers sign the key, the ftp-masters
for starters, as well. Any one key (or location) can be
compromised. Multiple keys are much harder to get.


My idea of a semi automatic key update is that apt-get fetches any new
key from the archive (from Release.key next to Release.gpg), checks
the signatures against its known keys, presents the user with a the
results (New key XYZ, 5 signatures known, Signaturees are: ...) and
ask if it should accept/reject the key into its keyring.

MfG
        Goswin