The trust chain

Everything the estate signs traces back to one key set, minted in a single offline ceremony. Two keys own the firmware and stay in offline escrow. Three sign what the pipeline builds and live in CI as masked, protected variables. Every public half is published at /keys/, so a cairn-signed image, UKI or kernel module can be checked against a fingerprint fetched out of band.

Trust arrives as signed payloads

None of the three certificates signs another. Each is self-signed, so trust does not flow down an issuer chain the way web PKI does. It flows through the UEFI authenticated-variable payloads the ceremony builds. The firmware trusts the Platform Key because an operator enrolled it, trusts the Key Exchange Key because the Platform Key signed the payload carrying it, and trusts cairn’s signing certificate because the Key Exchange Key signed the payload carrying the firmware signature database (db). sb-ceremony-auth.sh builds all three and states their exact contents.

The base image carries those same payloads, so an install copies them to the ESP and systemd-boot enrolls them from Setup Mode (the Containerfile, D19). A payload holds public certificates only, and it rides inside the sealed digest like everything else in the image.

What the firmware runs before the OS exists

Under Secure Boot the firmware checks every EFI binary it executes against the signature database, and that includes option ROMs. A GPU’s pre-boot graphics driver and a BMC’s video code both run during POST, before any bootloader. Device vendors have those ROMs signed through Microsoft, so the binaries chain to Microsoft’s UEFI CA. A database holding only cairn’s certificate would stop that vendor code loading.

So the database holds cairn’s signing certificate alongside the Microsoft and Windows CAs, both generations, because binaries shipping today still chain to the 2011 generation. sb-vendor-certs-fetch.sh checks that against real binaries instead of assuming it, and the 2011 set leaves once nothing on the boot path still chains to it.

Kernel modules land in the platform keyring

cairn ships no shim, so a module signer has one route into the kernel: Fedora’s platform-keyring fallback. The certificate’s shape decides where it lands, not its subject. A CA certificate without the keyCertSign bit fails Fedora’s machine-keyring gate and resolves in %:.platform, the one path this estate has measured (D29). A working signer and a broken one carry the identical subject, so the landing keyring is the only thing that tells them apart, and the pipeline’s sealed boot gate asserts it by Subject Key Identifier (assert-sealed.sh).

Images are signed with our own key

The estate signs promoted image digests with its own cosign key instead of a keyless transparency-log identity, because containers/image cannot verify GitLab’s keyless identities at pull time. A CI token puts a URI in the certificate’s subject alternative name, and the sigstoreSigned matcher checks a literal subject email (the evidence lane’s record). An own-key signature is one the container runtime verifies at the pull, against the published fingerprint. The tradeoff is the transparency log and the identity rotation that keyless signing would have brought. The same ceremony mints the key, and both signing and attestation are opt-in per repo at promotion: the evidence lane turns them on.

Checking it from outside

/keys/ publishes every public half with its SHA-256 fingerprint and the one command that reproduces it from the downloaded file.