Last week I started a discussion[1] to find out the current status of key management in Secure APT which is a release goal for etch and said to be included in the next release of Debian. I don't find the situation terribly promising, though, but here's a summary, so we may come to a solution some day.
1. http://lists.debian.org/debian-release/2006/07/msg00192.html Does one of the proposals below meet the requirements of ftpmasters? If not, what would be their preferred implementation? Secure APT will cause a lot of trouble if key management is troublesome and bound to fail right after the release of etch, when the next key rollover is due to happen, or one year later. Goswin von Brederlow asked[2] ftpmasters to store the public signing keys next to the signed file to have a standardised place where keys for any apt-getable archive can be found. 2. http://lists.debian.org/debian-release/2006/07/msg00193.html Martin Krafft pointed out[3] that there is too much danger of man in the middle or DNS-poisoning attacks for automatic upgrades over the network of keys to be trusted automatically, unless Debian starts using SSL. 3. http://lists.debian.org/debian-release/2006/07/msg00194.html 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 easy-to-use tools to install these keys, and proper error messages from APT that will make it obvious what to do. Florian Weimer stated[4] that the only approach known to work is static keys for stable releases and stable security updates. The keys can be stored off-line or on-line, at the discretion of the respective teams. He pointed out that we have botched all yearly key rollovers, and that there is zero evidence that we'll get the first one that reallly matters right. 4. http://lists.debian.org/debian-release/2006/07/msg00201.html Joey Hess added[5] that the last date at which key management can be added/included in the installer will be the final build of d-i initrds, which is going to happen on Wednesday, October 18th, 2006. However, I believe that this would be way too late in terms of code maturity and proper tests. 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. The user can decide on their own to trust either a yearly key only or the release key only, and omit a key rollover. The release key could also be stored offline which will reduce[7] the likelihood of being compromised. 6. http://lists.debian.org/debian-release/2006/07/msg00212.html 7. http://lists.debian.org/debian-release/2006/07/msg00221.html Regards, Joey -- Let's call it an accidental feature. -- Larry Wall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
