On Tue, Jul 31, 2012 at 02:28:28PM -0700, Steve Langasek wrote: >On Tue, Jul 31, 2012 at 02:40:25PM -0600, Paul Wise wrote: > >> One thing I don't think anyone has discussed yet is how key >> transitions will work, if a distro-specific key is compromised, is the >> OS able to update the SB keys? > >Any OS will be able to push signed updates to the DB and DBX variables, >adding new trusted keys or revoking keys / individual binaries. However, >the only signed updates that will be accepted by the firmware are those >signed by keys already trusted /by the firmware/ (i.e., those present in the >kEK). This means that in general, if you have a compromised key or >compromised binary, you need to go back to the CA (i.e., whoever is >providing a trust path back to KEK for you) and ask them to issue a >revocation.
Ah, right. I'd missed that part of the spec and I wasn't clear how revocation is meant to work. ... >FWIW the UEFI working group seems to consider it an oversight that only one >signature is allowed per binary, and work is afoot to correct this. But as >with other issues, it's probably too late to make a difference for the first >iteration of hardware. ACK. :-( -- Steve McIntyre, Cambridge, UK. st...@einval.com "C++ ate my sanity" -- Jon Rabone -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120804153338.gk32...@einval.com
