Re: Summary: Secure APT Key Management
* Anthony Towns (aj@azure.humbug.org.au) [060730 15:10]:
> On Sun, Jul 30, 2006 at 12:56:26PM +0200, Martin Schulze wrote:
> > Florian Weimer stated[4] that the only approach known to work is
> > static keys for stable releases and stable security updates.
>
> For stable updates, an off-site key would be possible, and I suspect is
> solely up to the discretion of the stable release managers.
>
> For security updates, it's also possible, but a little bit more hassle;
> so likewise at the discretion of the security team, I guess. That has
> the added problem that the security team is a little larger than the
> stable release team, and sharing a key can be awkward.
Hm, how about using two keys per stable release: One for the stable
releases (which is only changed in case of compromises of that key), one
for security updates. By that way, if the stable key is compromised, we
could replace it by using the security key, and the other way round also
(which would however mean an extra stable point release, but well). (Ah,
looking down, I can see you had similar ideas.)
Of course, all Release-files could be signed as well with the unstable
key.
> > 5. http://lists.debian.org/debian-release/2006/07/msg00202.html
> > Rapha?l Hertzog suggested[2] to use two signatures, one from a yearly
> > key and one from a stable release key.
>
> From the discussion previously, it seemed that the way keys would be updated
> usually was by:
>
> (1) someone has a working system
> (2) they apt-get update, verified by key N
> (3) they apt-get dist-upgrade to a new apt, which automatically sets
> key N+1 as a trusted key
> (4) apt-get update, verified by key N+1
>
> That means there needs to be an overlap between when the new key is added
> to the distro (both for propogation to testing and included in a stable
> point release) and the old key is used for signing packages.
Well, I think we have the additional requirement that the key installed
from the Etch r0 installer CD can be used to install any point release,
and even upgrade directly to etch+1 (however, we *could* deprecate that
in the release notes for etch+1, and require people to dist-upgrade to
the last etch point release, but I dislike that).
> So having a "release" key would be something like:
>
> * create a new key now that will work for etch's lifetime
> (assuming etch+1 releases 18 months after etch in July 2008,
> and gets security support for a further 12 months, that's from
> 2006-12-01 -> 2009-06-30)
Why is it necessary to set a life time on the key at all? One could just
make the key live long enough, sign the Releases-file for etch+1 by the
etch key, and deliver a new key with etch+1 that also contains the
revokation key for the etch key.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
Reply to: