Summary: Secure APT Key Management
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
Reply to: