From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CE28E40D for ; Tue, 28 Jul 2015 19:31:52 +0000 (UTC) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0A54618D for ; Tue, 28 Jul 2015 19:31:51 +0000 (UTC) Received: by lbbzr7 with SMTP id zr7so81629332lbb.1 for ; Tue, 28 Jul 2015 12:31:50 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1438111168.26913.189.camel@infradead.org> References: <20436.1438090619@warthog.procyon.org.uk> <1438096213.5441.147.camel@HansenPartnership.com> <1438097471.5441.152.camel@HansenPartnership.com> <1438099839.5441.165.camel@HansenPartnership.com> <1438100102.26913.183.camel@infradead.org> <30361.1438101879@warthog.procyon.org.uk> <1438111168.26913.189.camel@infradead.org> From: Andy Lutomirski Date: Tue, 28 Jul 2015 12:31:30 -0700 Message-ID: To: David Woodhouse Content-Type: text/plain; charset=UTF-8 Cc: James Bottomley , Luis Rodriguez , "ksummit-discuss@lists.linuxfoundation.org" , Kyle McMartin Subject: Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, Jul 28, 2015 at 12:19 PM, David Woodhouse wrote: > On Tue, 2015-07-28 at 10:03 -0700, Andy Lutomirski wrote: >> >> This will require that we take any firmware vendor's key and rewrap it >> somehow into a new X.509 blob with a key usage constraint. > > There are established ways of handling those constraints as external > objects (see how NSS does it in its trust tokens, and thus p11-kit > -trust does too). Wow, I thought X.509 was bad. Now we get PKCS#11, too? Ick. I have no problem whatsoever with having the userspace tooling support PKCS#11 tokens. I think the kernel should try to minimize the extent to which is depends on X.509 on the kernel side. If we're going to load keys into the kernel (at compile time, from UEFI, whatever), let's just *tell* the kernel, in plain English or C, what those keys are for, rather than trying to parse X.509 constraints. I'll point out that the Internet tried to use X.509 name constraints to allow CAs to be constrained to subsets of the DNS space, and it *still* doesn't work. Heck, with the X.509 variant, if Megasoft has an existing key signed by SketchyTrust, and we want to trust SketchyTrust to sign firmware for SketchyUSB devices (and to delegate to Megasoft using the *existing* key), are we supposed to enforce transitive constraints? Where are they rooted? I think this way lies madness. Let's just throw SketchyTrust's key in the "SketchyUSB only" pile and be done with it rather than fiddling with OpenSSL to re-wrap SketchyTrust's self-signed (?). If I'm the unaffiliated author of a driver for a SketchyTrust device, I want to throw the cert into my driver and be done with it. The kernel should *figure out on its own* that the cert is associated with my driver and my driver only and can't sign for my GPU. I really don't want to muck with the X.509 blob, because I'm going to get it wrong. [1] If we start rewrapping root keys and shoving the X.509 blobs into drivers, who signs those blobs? We can't self-sign them because we don't have the private key, and we don't really want a completely pointless "kernel" key that exists solely for the purpose of producing well-formed X.509 certs, and we probably don't want to use ill-formed unsigned X.509 certs as our root. So what's the point of using X.509 at all for this purpose? --Andy