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
signature.asc
Description: Digital signature