How do you verify cosign signatures inside an air-gapped enclave that cannot reach Fulcio or Rekor?

## Signing needs the network; verifying does not have to An air-gapped estate — say a mirror of OS packages pulled into a classified enclave — cannot talk to a public certificate authority, an identity provider or a transparency log. That rules out *signing* inside the enclave with the keyless flow, because every step of it is a network exchange. It does not rule out *verifying*, because verification is arithmetic over material you can carry in. ### Do the signing on the connected side Packages are signed where the build runs, outside the gap. Signing each with `--bundle` produces one file per artifact carrying the signature, the signing certificate and the transparency-log entry, rather than three loose strings that someone will lose while moving media across the boundary. Artifact and bundle then cross together, and the import process treats a package without a bundle as a package that cannot be admitted. ### Cache the trust root before you need it The second half is the root of trust: the certificate authority's root and intermediate certificates, and the public key of the transparency log. cosign fetches these from a signed trust-root repository and caches them locally; `cosign initialize` is the command that populates or refreshes that cache, and it accepts a mirror, which is how you feed it from a copy staged inside the enclave rather than from the public internet. This material is signed and time-bounded — that is deliberate, because it is how a compromised or stale root is prevented from being trusted forever. The practical consequence for an air gap is a chore with a deadline: someone must periodically refresh the trust root on the connected side, move it across, and re-initialise inside, or verification will one day start failing on artifacts that are perfectly good. Discovering that on the day the metadata expires, during a deployment, is the classic way this bites. ### What verification then actually does With bundle and cached root present, cosign can complete every check locally: the certificate chains to the cached root; the identity and issuer in the certificate match the ones you pass; the signature is valid over the artifact's digest; the log entry in the bundle is consistent and signed by the key you cached. No call leaves the enclave. Note that this only works because the bundle carried the log entry — a bare signature and certificate would force a lookup you cannot make. ### The threat this closes The interesting adversary here is not an anonymous outsider — there is no route in — but a compromised operator of the mirror, or someone on the enclave's own network who can write to the package repository. They can replace an RPM with a modified one. What they cannot do is produce a bundle that verifies against the expected signing identity, because obtaining a certificate for that identity requires the very network exchange the enclave forbids. So the control works precisely because signing is hard to do inside; the asset protected is the integrity and availability of a controlled estate that has no external help if it is subverted. Two design rules follow. First, verify at the point of use — at install, or before a service loads the file — not only once at import, because import-time verification protects only the boundary and says nothing about what happened to the repository afterwards. Second, fail closed on missing material: a deleted bundle must block the install, never be read as "nothing to verify". ### The alternatives, and when they are better If artifacts genuinely originate *inside* the enclave, keyless signing is not available to them at all and you have two options: run a private Sigstore deployment within the enclave, which gives you the same shape at the cost of operating a CA, an identity provider and a log; or sign with a key pair, accepting the key-management burden that keyless was invented to remove. Neither is wrong — the choice turns on how many artifacts originate inside and whether you can operate the services responsibly.