Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932753AbbETP4r (ORCPT ); Wed, 20 May 2015 11:56:47 -0400 Received: from mail-la0-f51.google.com ([209.85.215.51]:36531 "EHLO mail-la0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932715AbbETP4n (ORCPT ); Wed, 20 May 2015 11:56:43 -0400 MIME-Version: 1.0 In-Reply-To: <31772.1432128969@warthog.procyon.org.uk> References: <20150515123513.16723.96340.stgit@warthog.procyon.org.uk> <555BD715.40202@kernel.org> <31772.1432128969@warthog.procyon.org.uk> From: Andy Lutomirski Date: Wed, 20 May 2015 08:56:21 -0700 Message-ID: Subject: Re: [PATCH 0/8] MODSIGN: Use PKCS#7 for module signatures [ver #4] To: David Howells Cc: Andy Lutomirski , Rusty Russell , Michal Marek , Matthew Garrett , keyrings@linux-nfs.org, Dmitry Kasatkin , Luis Rodriguez , "linux-kernel@vger.kernel.org" , Seth Forshee , LSM List , David Woodhouse Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2422 Lines: 49 On Wed, May 20, 2015 at 6:36 AM, David Howells wrote: > Andy Lutomirski wrote: > >> I think this is way more complicated than it has to be. Can't we look up >> certificates by their subjectPublicKeyInfo? > > I want to be able to handle an X.509 chain to a root key that we have in the > kernel. X.509 certs don't chain on subjectPublicKeyInfo unless that happens > to be what's in the SKID (which is a pretty indefinite standard in its own > right:-( ). So we need to be able to match on the two things I made available > anyway. PKCS#7 matches on one of them too, so that then just works. I see. PKCS#7 (and PKCS#6 and X.509 which it inherits from) is too dumb to identify the public key that signed a certificate, so you can't match on it. Sigh. That being said, are you actually planning on implementing X.509 chain validation correctly? ISTM you can't really do it usefully, as we don't even know what time it is when we run this code. What's the point of accepting certificate chains if there's no meaningful validation we can do? > >> Why is PKCS#7 better than whatever we're using now? > > It has a standard form[*]. It has standard ways to specify things such as the > key to use and the digest to use. It can carry multiple signatures from > different keys and can carry key chains (something that's more likely to be > useful for kexec or firmware, admittedly). It can be generated by extant > tools (though adding it onto a module needs a special tool). Given how much special stuff is needed (special tool to append it, probably weird or absent certificate chain validation, etc), this seems to me to be of questionable value. Would it make more sense to permit X.509 chains to be loaded into the keyring instead if we actually need that feature? IOW, let userspace (or early initramfs stuff) extend our keyring trust to intermediate certs that validly chain to already-trusted things? I think that a reasonable design goal would be that everything overcomplicated that's involved should be optional, and moving toward embedding PKCS#7 signatures in the modules themselves does the other direction? --Andy -- 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/