> 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

Hi Roberto,

Thanks for your detailed reply.

On Mon, Jan 17, 2022 at 4:21 PM Roberto Sassu <roberto.sassu@huawei.com> wrote:
> 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.

Hm, yea, I see your dilemma.

On the one hand, you recognize the problems with what currently
exists. On the other hand, you[r organization] hasn't made the
transition to something better. So, rather than putting in what might
be a lot of work to transition to something better (which includes
actually evaluating *what* the better thing would be), you'd prefer to
put in a smaller amount of work to make the current thing satisfy some
of your needs, even though you recognize its flaws. It seems like this
is one of those "short term" vs "long term" investment tradeoffs.

I don't have a whole lot _technical_ to say about long term vs short
term thinking, but it does strike me that PGP is one of these cases
where people have known about the flaws for decades, but the ecosystem
keeps being extended because people continue to go with the short term
solutions, one by one, and now they've wound up here, at the doorstep
of the kernel. Maybe if at some point somebody puts down the foot and
says, "the road of short term intentions stops here," there might
gradually be impetus toward looking into long term solutions, e.g.
viable PGP replacements? Just a thought.

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

Things in the kernel rarely disappear. At best, they become subtly
neglected, and then somebody gets bit by some security bug. At worst,
we're stuck maintaining a PGP implementation until the end of
eternity.


On the technical front, though, I had sort of the same thought as
Maciej: is there some way that you can unwrap the PGP data in
userspace, and re-encode it in ASN.1, and somehow magically account
for the various metadata included in the signatures? The devil here
might be in the details, and I'm not sure whether it's feasible. But
if it is, this would seem to be a much nicer solution. I'm not the
hugest fan of having an ASN.1 parser in the kernel either, but it's
_already_ there, and if you could somehow piggyback on top of it, that
means we'd be able to avoid importing this PGP implementation.

Concretely, it looks like the hardest part of this is the fact that
pgp_digest_signature seems to hash in some PGP-specific metadata, not
just the raw data. Am I reading that right, and that's the case? If
so, that might spell trouble. You also mentioned in that other thread
the possibility of using a new/custom PGP packet type for this? Is the
idea there that you'd come up with something that could be unwrapped
into an ASN.1-verifable blob, as a custom extension of PGP that
distros could then distribute?

Jason