RE: [PATCH 00/14] KEYS: Add support for PGP keys and signatures

[Roberto Sassu <roberto.sassu@huawei.com>]

> From: Jason A. Donenfeld [mailto:Jason@zx2c4.com]
> Sent: Monday, January 17, 2022 3:35 PM
> 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.

Hi Jason

thanks a lot for the additional information. They could
make people more aware of the risks so that they transition
to more secure schemes.

The problem is that I don't see that transition coming soon.
Transition from PGP to another scheme would require Linux
distribution vendors to do an huge amount of work. It could
probably take years before that transition occurs.

More specifically, the first task would be to modify how
RPMs are signed (and thus how they are verified). The second
task would be to have a different way to certify the public key.
Lastly, Linux distribution vendors would have to change their
building infrastructure to use the new certified key, a new
version of the rpm package manager which takes as input
the new key, produces a different type of signature and embeds
it in the RPM header.

In this discussion:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JE2HGLJMLEKUJW3YBP6MQJWP43CSTC57/

people were concerned about the lifecycle of the secondary
key used for fsverity signatures. Likely, completely replacing
the key infrastructure would raise even bigger concerns.

The aim of this patch set is to make some security features
available in a short time, by significantly reducing the burden
of Linux distribution vendors for managing those security
features. I mentioned fsverity, but my primary use case would
be for DIGLIM (extract reference values for file digests from
RPM headers and use them for IMA measurement or appraisal).

The main advantage of this patch set, at least for DIGLIM, is
that it completely removes the need of changing the building
infrastructure. To show the DIGLIM benefits, I retrofitted two
already released Linux distributions (Fedora 34 and openSUSE
Leap 15.3) with DIGLIM and the necessary changes in IMA, so
that they prevent the execution of binaries and shared libraries
which were not released by the distribution (the mechanism is
completely configurable by the user to trust his binaries,
if he wishes to). If you are interested, here is the link of the
demo I developed:

https://lore.kernel.org/linux-integrity/48cd737c504d45208377daa27d625531@huawei.com/

If in the future the transition from PGP to another scheme
occurs, support for PGP keys and signatures can be still
deprecated.

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua

> If you're looking for a simple signature mechanism to replace the use of
> X.509 and all of that infrastructure, may I suggest just coming up with
> something simple using ed25519, similar to signify or minisign? Very
> minimal code in the kernel, in userspace, and very few moving parts to
> break.
> 
> Jason