Secure APT Key Management

[Andreas Barth <aba@not.so.argh.org>]

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.

Apt in stable recognizes as valid:
- The current stable key
- The previous stable key
- The unstable key

Stable Releases is signed off by:
- The current stable key
- The previous stable key
- The unstable key (perhaps also by the previous/next near to a
  rollover)

Security Releases is signed off by:
- The current security key
- The previous security key
- The unstable key (perhaps also by the previous/next near to a
  rollover)


Stable release keys (and perhaps also security keys, depending on the
security team) don't have expiry dates, but are expired with publishing
a revocation certificate with stable+2 (as we still need the key for
stable+1 for upgrades).



So, if someone upgrades e.g. from sarge to etch (just using them as
names now, ignoring that sarge doesn't contain such an apt):

Client runs sarge - authoritative are woody, sarge, expired old sid key
Client gets etch-Release.gpg from mirror (signed off by sarge, etch, sid)
Client verifies etch-Release.gpg with sarge key
Client installs new packages - now authoritative sarge, etch, sid keys
  (and installation contained a revokation for the woody key).


In case the point release key is compromised, the key can be exchanged
by using the security key. In case the security key is compromised, the
key can be exchanged by using the point release key (which is a bit more
difficult if we don't do it with a point release but only on
security.d.o, as security.d.o changes Release quite often - but well, we
can do it for a few days probably, and then we probably need to do a
small point release soon).




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