File Hierarchy for the Verification of OS Artifacts

[dvzrv]

OpenPGP is widely adopted by most Linux distributions, as it offers a decentralized system for artifact verification.

To make use of OpenPGP, most distributions establish a PGPKI (aka. Web of Trust (WoT)), in which trust is delegated from a signature, over the signer's certificate to the certificates of a few central entities, that serve as trust anchors. This is mostly established via "third-party certifications".
The collection of certificates used for data signatures (sometimes in distinct roles) is distributed by many Linux distributions in bundled form, as OpenPGP keyrings.

As of writing, no standardized location for OpenPGP keyrings exists, leaving tools to either do guesswork (related mkosi issue) or rely on proprietary and stateful keystore formats (e.g. GnuPG) and a per-application location.

I am currently working towards a simple specification, that encodes metadata required by programs such as package managers, or general purpose verification tools (e.g. "which distribution?", "in what version?", "for which purpose?", "who is certifying?") in a common directory structure.
This would offer a simple, stateless and standardized interface allowing distributions (or anyone really) to verify their own artifacts or those of others.

[bluca]

This requires buy-in from the main package managers in order to be useful - let's say apt, dnf, zypper, pacman?

[dvzrv]

This requires buy-in from the main package managers in order to be useful - let's say apt, dnf, zypper, pacman?

Yes, that would be the ideal outcome for the package management use-case.

My idea is to design this flexible enough, so that it can be used also for other purposes: The verification of installation media, virtual machine images, etc. (basically any artifact a distribution may produce and issue an OpenPGP signature for).

[dvzrv]

While working on #134 we have tried to incorporate semantics for Sigstore as well.
However, even after consulting with experts it was not clear whether the technology could be properly modeled in the given hierarchy.
This is in large part due to the complexity of the what sigstore covers, but also due to our missing expertise and understanding of the technology.
Sigstore puts a strong focus on the use of identity providers and short-lived certificates for the signing of artifacts.
In such an environment probably only the storing of trust anchors may be useful/feasible.
There appears to be the notion of local "trust bundles", which may offer longer-lived certificates used as artifact verifiers, but their use is not clear to us (yet).

We have therefore opted to remove the technology section on sigstore and instead invite experts such as @SantiagoTorres to help refine the following bullet point list into a text (if possible).
This way we may add something for sigstore in the context of #134 or in a follow-up PR.

#### Sigstore

---

**NOTE**: This technology is in draft mode.
Before implementing a sigstore VOA backend, this section needs to be specified further to describe dedicated semantics.

---

- [hierarchical trust] model for signature validation
- Technology name: `sigstore`

NOTES/TODO:

- check certificate extensions?
- check OIDC provider (which mail is used, who claims to own it?)
- root of trust (TUF root or certificate)
- downloading the certificates e.g. for transparency logs does not make sense, as they are short-lived
- download artifact + certificate (which is signed by root of trust) and signature (which may be PKCS#7 or other technology) as certificates used for signing are usually very short-lived
- signatures are often x509 (https://blog.sigstore.dev/celebrating-1-000-000-entries-in-rekor-1950b7c150df/)

[dvzrv]

For posterity:

During Image-based Linux summit 2024 this topic has been discussed and a request has been made to make this file hierarchy more generic, so that it can work with more technologies than just OpenPGP.

The PR in #134 is the accumulation of several months of work to achieve just that.
Several security researchers and developers reviewed the text before the pull request and I would like to again extend my gratitude for giving it a read and providing improvement suggestions early on!