Joey: Thanks for the Bcc.
On Sun, Jul 30, 2006 at 12:56:26PM +0200, Martin Schulze wrote:
> The way he envisions key management is that every Debian machine
> trusts the SPI CA. Debian should provide a webpage for downloading
> and verifying keys, protected by SSL/TLS. The use would require
I think a proper SSL key, trusted using the regular methods is
important, but I don't think it's reliable enough to be our primary/sole
verification method.
> 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.
> 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.
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)
* (if necessary releasing a new etch key if etch+1 hasn't been released
and etch's key is set to expire during the next point release)
* creating a new key for etch+1's lifetime prior to it's release
by at least one point release of etch, that will last for as long
as etch+1's expected lifetime
And having an annual key would be something like:
* including the 2006 key in apt in all suites (sarge, etch, unstable)
* creating the 2007 key in time to be included in the last sarge
point release in 2006, and first etch release in 2006
* creating the 2008 key in time to be included in the last etch
point release in 2007, and to propogate through to testing before
2008, etc
* repeat...
I suspect it would be worthwhile to issue DSAs for apt when the new keys are
ready as well.
Given the synchronisation with the (stable) release team and the
security team all the above implies, I think it's their call which of
these happens.
That leaves SSL as one of the possible means for introducing yourself
to the web of trust (oh, I trust SSL, and it says this initial
CD/signature/whatever is correct, therefore I'm happy!), as well as
signatures by ftpmasters or release managers, or fingerprints from books
or other trusted sites. Which is still very worth doing.
> The user can decide on their
> own to trust either a yearly key only or the release key only, and
> omit a key rollover.
Note that the online key (whether annual or synched to a release)
must be trusted for users of testing, unstable, experimental,
testing-proposed-updates, and potentially also security updates and
proposed-updates depending on the extra load the security team and SRM
group are prepared to take on.
The above mechanism can also be used for updating an off-line key used
to sign updates to stable -- when etch rN happens, it will be signed
by the off-line etch release key, and will contain an apt that includes
the off-line etch+1 release key.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature