Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753708AbbETOEt (ORCPT ); Wed, 20 May 2015 10:04:49 -0400 Received: from mail-oi0-f51.google.com ([209.85.218.51]:32773 "EHLO mail-oi0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753482AbbETOEq (ORCPT ); Wed, 20 May 2015 10:04:46 -0400 Date: Wed, 20 May 2015 09:04:26 -0500 From: Seth Forshee To: "Luis R. Rodriguez" Cc: linux-security-module@vger.kernel.org, james.l.morris@oracle.com, serge@hallyn.com, linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, David Howells , Kyle McMartin , David Woodhouse , Greg Kroah-Hartman , Joey Lee , Rusty Russell , zohar@linux.vnet.ibm.com, mricon@kernel.org Subject: Re: [RFD] linux-firmware key arrangement for firmware signing Message-ID: <20150520140426.GB126473@ubuntu-hedt> References: <20150519200232.GM23057@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150519200232.GM23057@wotan.suse.de> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1203 Lines: 24 On Tue, May 19, 2015 at 10:02:32PM +0200, Luis R. Rodriguez wrote: > This begs the question on how we'd manage keys for firmware signing on > linux-firmare. Since the keys are x509 keys we need a CA. Based on some initial > discussions it would seem we'd need the Linux Foundation to create a key, this > would be embedded in the kernel and that key would be used to sign Kyle's key. > Kyle would in turn use his key for signing linux-firmware files. David, Kyle, > did I summarize this correctly ? I raised the question of key revocation when we discussed this on irc, but it wasn't answered to my satisfaction. If a key signed by the kernel-embedded key is compromised, how can that key be revoked so that it is no longer trusted? Someone mentioned UEFI blacklists, which I don't know much about, but not all systems have UEFI. The only reliable option that comes to mind for me is an in-kernel blacklist of keys which should no longer be trusted. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/