Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp782952pxb; Fri, 21 Jan 2022 03:14:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJxbwv4yXbdCLlDtLd8ehrneb+k4UPnMO88YKhpHhTKqRFpH/RdXHbAafUa7j9O7uS9bWzFS X-Received: by 2002:a05:6a00:1681:b0:4a8:2462:ba0a with SMTP id k1-20020a056a00168100b004a82462ba0amr3203481pfc.75.1642763683517; Fri, 21 Jan 2022 03:14:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642763683; cv=none; d=google.com; s=arc-20160816; b=T+l7632rpfezgyh/FBY+/w4VVMuKqBd1/w+b5gMIGgGxccsUcV/TWQUsNqWsr+RZ+s lZhj78lt7EwKB8vyufLLLP43ra3fyF/eJsqyszz1w4Cp1jnnppwOJ4c1YbiJwoTka9Dh UmlUim3SfV8jWVQr3+idBy+UHyzOxt4MpoDdU8e3aWQQAn6ZVRvCKmmkD87IRv3ydWqy DG+/q7HV7zb70OU+oZHDvPbfCeQFTIlk+oRRLnX2E9DbtIs3AApWcKXKdufrXq1Bmcn9 /dZ3lu7rJXtUEl8ePVKOAo5dQW868Mvg3odACvfDDcoaBCxeI0p5iAMc1R4vdxsTqFKK FjBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=5MwgvCE4c+uQsxsd42Ju3dhKUjRboDaW6Lk9kl51ZcE=; b=X924D8QP+FP0Yt0eqs89rtnOGIbzUGG2um/if5NZSXAHPleDeT9B1cCo/DCXVzgwTs gBCaYbfMozH/282FySI2R6y977g7DyF84LRqu1q/rVvwHgAQDbmuKaBa1YA8fXD/9vey eyRqgWNi3zulC/tWMHtCpu5BECeESykgZHfdXDduzgs9qTUiAiWcKWVRTk/CQwz858+6 Xd5V6ubRLmq8oLXhjtbBm4Ex0ewRUQb/MEer6UNDWcb9Z5MYc12tWTu3wfQID+caPP1x /6sAy72swhKCQ8ZyCf/DNyfCOnrwzRpsVZFBzOQJhHEqbPB5IRtovwb8uBqKBWLfluyW u9Gw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ukveCzfp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 30si6230997pgo.862.2022.01.21.03.14.31; Fri, 21 Jan 2022 03:14:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ukveCzfp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350166AbiARXDk (ORCPT + 99 others); Tue, 18 Jan 2022 18:03:40 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:47748 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238025AbiARXDi (ORCPT ); Tue, 18 Jan 2022 18:03:38 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5E0AD612D3; Tue, 18 Jan 2022 23:03:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52C0FC340E0; Tue, 18 Jan 2022 23:03:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1642547017; bh=JwxY2h9tn3QE+WRRLQPNM+uQ68EejJ4xhgjUAq77hWY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ukveCzfprxQ8zpV7fQKoIcvoTWtVmd0L9ll7H6IeS2o3YDXLINBG4IVQACbTsgckj VOaDmm8ZlFqcwB9G1T4+orQSuAAlXBiwf4eTGA4XDmy3EpSr6ztf0omxs0Nehl9C8n UgfM55ECiqtgi0kv/orpwrsXyzbVw5ZMzxSh3PW4be1CQ+IGRKFuOw+VJVrDkXlWbk zzRYGUDlOcR4yPvkn6vRg2de85Takv9uNol9sxPQSj77osrWelTazrv7CIN0H9VlmT A7SxM8N/lkcAavSDt0fhpYBwoqXbqUjFGADZ34jxSAetjaWsrNzXe7ltqj+k5fcLrJ B7xomrIy3KdQg== Date: Tue, 18 Jan 2022 15:03:35 -0800 From: Eric Biggers To: Antony Vennard Cc: James Bottomley , "Jason A. Donenfeld" , Roberto Sassu , dhowells@redhat.com, dwmw2@infradead.org, herbert@gondor.apana.org.au, davem@davemloft.net, keyrings@vger.kernel.org, linux-crypto@vger.kernel.org, linux-integrity@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-kernel@vger.kernel.org, zohar@linux.ibm.com Subject: Re: [PATCH 00/14] KEYS: Add support for PGP keys and signatures Message-ID: References: <20220111180318.591029-1-roberto.sassu@huawei.com> <079f10b9-060b-3a36-2224-fa1b483cbad5@vennard.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <079f10b9-060b-3a36-2224-fa1b483cbad5@vennard.ch> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 18, 2022 at 09:50:21PM +0100, Antony Vennard wrote: > > Hi All, > > On 17/01/2022 16:02, James Bottomley wrote: > > On Mon, 2022-01-17 at 15:34 +0100, Jason A. Donenfeld wrote: > > > Hi, > > > > > > While it looks like you put a lot of work into this patchset, I think > > > the general idea of adding PGP *to the kernel* is a pretty daunting > > > proposition. The general consensus in the crypto engineering world is > > > that PGP ought to be on its way out. We definitely don't want to > > > perpetuate this project-on-life-support into the permanence of kernel > > > code. Some quick Google searches will reveal a litany of blog posts > > > to the tune of, "why oh why are people still using this?" Here's one > > > from 2019: > > > https://latacora.micro.blog/2019/07/16/the-pgp-problem.html . I > > > think these are arguments to take seriously. And even if you disagree > > > with some parts, you may want to consider whether the remaining parts > > > warrant a bit of pause before adding this to the kernel and > > > perpetuating PGP's design further. > > So while I understand why this is being proposed and clearly effort has gone > into it, I also think it is not the right approach. It seems this proposal > is to include a full PGP packet parser and verification logic in the kernel > as an equivalent to allow PGP signatures to be submitted via > FS_IOC_ENABLE_VERITY: > > "FS_IOC_ENABLE_VERITY accepts a pointer to a PKCS#7 formatted detached > signature in DER format of the file’s fs-verity digest." > It's worth noting that if fs-verity built-in signatures are used, a trusted userspace program is still required to determine and enforce the policy of which files are required to be signed. The kernel only handles the actual signature verification. This was basically a proof-of-concept which reused the kernel's module signature verification code (which happens to use PKCS#7). I'd encourage new users to either go all-in on a userspace solution, using a trusted userspace program to verify signatures of fs-verity file digests; *or* go all-in on an in-kernel solution, using the IMA support for fs-verity which Mimi Zohar is working on. A userspace solution could use a simple signature format, using a modern algorithm such as Ed25519. IMA uses a simple signature format too, though it uses a complex format (X.509) for public keys. - Eric