On Sun, Aug 18, 2024 at 06:57:42PM +0200, Roberto Sassu wrote: > From: Roberto Sassu <roberto.sa...@huawei.com> > > Support for PGP keys and signatures was proposed by David long time ago, > before the decision of using PKCS#7 for kernel modules signatures > verification was made. After that, there has been not enough interest to > support PGP too.
You might want to update the RFC/bis references to RFC9580, which was published last month and updates things. Also, I see support for v2 + v3 keys, and this doesn't seem like a good idea. There are cryptographic issues with fingerprints etc there and I can't think of a good reason you'd want the kernel to support them. The same could probably be said of DSA key support too. > Lately, when discussing a proposal of introducing fsverity signatures in > Fedora [1], developers expressed their preference on not having a separate > key for signing, which would complicate the management of the distribution. > They would be more in favor of using the same PGP key, currently used for > signing RPM headers, also for file-based signatures (not only fsverity, but > also IMA ones). > > Another envisioned use case would be to add the ability to appraise RPM > headers with their existing PGP signature, so that they can be used as an > authenticated source of reference values for appraising remaining > files [2]. > > To make these use cases possible, introduce support for PGP keys and > signatures in the kernel, and load provided PGP keys in the built-in > keyring, so that PGP signatures of RPM headers, fsverity digests, and IMA > digests can be verified from this trust anchor. > > In addition to the original version of the patch set, also introduce > support for signature verification of PGP keys, so that those keys can be > added to keyrings with a signature-based restriction (e.g. .ima). PGP keys > are searched with partial IDs, provided with signature subtype 16 (Issuer). > Search with full IDs could be supported with > draft-ietf-openpgp-rfc4880bis-10, by retrieving the information from > signature subtype 33 (Issuer Fingerprint). Due to the possibility of ID > collisions, the key_or_keyring restriction is not supported. J. -- If I throw a stick, will you leave?