[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Secure APT Key Management

Andreas Barth <aba@not.so.argh.org> writes:

> * Goswin von Brederlow (brederlo@informatik.uni-tuebingen.de) [060906 13:52]:
>> Martin Schulze <joey@infodrom.org> writes:
>> > Andreas Barth wrote:
>> >> Hi,
>> >> 
>> >> I try to summarize the results of the discussion from start of August,
>> >> in hope that we can finish this off, and test-run this first for the
>> >> next stable point release. From the security team, some input on their
>> >> preference would be welcome.
>> >> 
>> >> 
>> >> The idea is to have different keys:
>> >> - One standard online-key for signing unstable; this key would be
>> >>   rotated e.g. yearly (or whatever the ftp-masters consider fit, I don't
>> >>   really mind).
>> >> - One release key per stable release; taken care offline by the stable
>> >>   release team.
>> >> - One security key per stable release; taken care somehow by the
>> >>   security team.
>> Sorry for not following the discussion closely but what happened to
>> having the current signing key(ring) in dists/suite/Release.key with
>> signatures by the ftp-master team (and/or security as appropriate)?
> How do you want to make the update on the end-user systems? Please
> remember that the updates need to be as easy as possible to them.
> This is not argueing against putting the keys somewhere onto the
> mirrors, but just as using that as rotation schema.

When you run "apt-get update" the Release.key file is fetched. For
each (new) key (or revocation certificate) in the file the sigantures
of the key is checked against the local keyring. A result report is
shown to the user and the user can then accept/reject the new key.

A new key can be signed by the old key on rollover, by the stable key,
by a couple ftp-masters and DDs. The more verifiable signatures the
key has the easier for the user to trust it. A certain number of
signatures should be required for the reult report to say "GOOD
KEY". Maybe further differentiated by the type of key. The signature
by the old unstable key is less trustworthy than the stable key and
that less than the ftp-master/DD keys.

The details don't matter so much. Important for now would be to have
the key signatures checked and ask the user what to do. A simple list
of 'signature checked / unknown / failed' would do.

> Cheers,
> Andi
> -- 
>   http://home.arcor.de/andreas-barth/


Reply to: