What varve needs from wsc to go keyless at v1.0 — a consolidated ask, with what 0.11.0 already solved

[avrabe]

varve is deciding, for its v1.0 trust-root ceremony, whether to keep a file-based ed25519 root or move to keyless signing over wsc. This is the consolidated version of what that would require, replacing the scattered asks in #256–#260.

First: credit where it is due. #257 is closed and 0.11.0 changed the picture materially. I re-read the source today rather than trusting my earlier notes, and src/airgapped/verifier.rs is no longer the stub it was in 0.10.0 — 1241 lines performing certificate-chain validation to a bundle Fulcio root, leaf validity at Rekor's integrated_time with codeSigning EKU, mandatory Rekor SET verification, ECDSA P-256 over the digest via the SEC1 point in the SPKI BIT STRING, revocation and identity checks — and the Rekor body binding (#135 UCA-2) verified offline. The # Not verified offline doc block is exactly the right way to ship this: it names the Merkle inclusion gap and the SCT gap and explains why each is skipped rather than leaving a reader to discover it. A previous decision on our side (DD-026) partly rested on that verifier being a stub. That premise is now wrong and we are correcting it.

Why varve cares about the answer

varve distributes signed toolchain layers. Its current root is a long-lived ed25519 key that lives in CI and signs every deposit. We just documented (varve#110) that this key exists only as a write-only GitHub Actions secret: it cannot be backed up, cannot be moved to another repository, and cannot be recovered if lost — and varve has no rotation and no revocation, so losing it ends the realm.

Keyless is attractive to us for exactly one reason, and it is worth being precise about it: it takes the long-lived secret out of CI. We are not under the illusion that it removes long-lived keys. Your own doc comment is explicit:

The bundle is signed with a long-lived offline key. Devices verify the signature against a pre-provisioned public key before using.

That is fine. A bundle-signing key is used rarely, changes rarely, and can be held under a real ceremony — offline, split custody, paper backup, annual read test. A per-deposit CI key cannot. The question is not "keys or no keys", it is which key has to be online.

What we would need

1. Signing over an arbitrary 32-byte digest (#256) — the blocker

varve signs DSSE-wrapped layer manifests, which are JSON, not WASM modules. The verify side already looks digest-shaped (verify_signature(&self, signature: &KeylessSignature, module_hash: &[u8; 32], …)), which is encouraging. What we need is the signing half to accept a caller-supplied digest with no assumption that the bytes behind it are a component.

If the parameter genuinely is just "a 32-byte hash", renaming it away from module_hash in the public API would help — the name currently implies a constraint that may not exist, and we would rather not guess.

2. A cosign-bundle adapter (#260)

Every PulseEngine repo publishes a cosign-signed SHA256SUMS.txt, and varve already ingests releases on that basis. Being able to turn an existing cosign bundle into a KeylessSignature would let us verify what we already ingest through one code path instead of two.

3. The trust bundle's own distribution story

This is the part we most want your opinion on rather than a feature. If consumers must pin a bundle-verification key, then that key is the ceremony subject, and its rotation story is the one that matters. Specifically:

• Is there an intended path for rotating the bundle-signing key, or for a new bundle to be verified against the old one?
• Is SignedTrustBundle expected to be distributed in-band with artifacts, or provisioned out-of-band per device?
• src/airgapped/tuf.rs fetches trusted_root.json over HTTPS from a raw.githubusercontent URL and parses it. That is a fetch, not TUF — there is no root.json signature chain, no threshold, no snapshot/timestamp metadata verification. Is TUF metadata verification intended to land, or is the signed bundle deliberately the trust anchor instead? Either answer is workable; we just need to know which, because our documentation has to describe it honestly to people making custody decisions.

4. #258 — the air-gapped e2e test that cannot fail

Still open, and worth prioritising above the features above. A test that never calls verify_signature reports green whatever the verifier does, and the verifier is now substantial enough that a vacuous test around it is actively misleading. We hit this class often enough in our own repo to have a name for it; we would trust the 0.11.0 verifier considerably more with a negative control proving that test goes red.

5. #259 — one Rekor log embedded, two live

Relevant to us because a signature from the non-embedded log would fail to verify offline for reasons that look nothing like the actual cause.

Hardware, since it is adjacent

We noticed HardwareSigner with tpm2 / sgx / trustzone / secure_element backends, and that sigil ships a wsc-linux-x86_64-tpm2 binary. If the v1.0 answer turns out to be "a long-lived bundle key held properly" rather than "no long-lived key", a hardware-backed signer is the natural home for it.

There is no PKCS#11 backend, which is the usual route to a YubiKey. Is that a deliberate scope decision, or simply unbuilt? Not asking for it yet — asking whether to plan around it existing.

What we are not asking for

We are not asking wsc to solve varve's custody problem. We are asking for enough surface and enough honesty about the trust model to let us decide where our long-lived key should live, and to describe that decision truthfully to people who will pin it for years. The # Not verified offline block in verifier.rs is precisely the standard we are hoping to hold ourselves to.

Happy to take any of this as a PR rather than a request if it helps — say which.

[avrabe]

Follow-up on the hardware paragraph, after reading src/platform/tpm2.rs rather than judging by the module name — we have been burned by exactly that shortcut recently, so this is source-verified.

TPM2 cannot hold a long-lived signing root in 0.11.0, and the gap is one function.

fn load_key(&self, key_id: &str) -> Result<KeyHandle, WSError> {
    // TPM2 persistent keys would be loaded from NVRAM using handles in the
    // range 0x81000000-0x81FFFFFF. For now, we don't support persistent keys.
    ...
    Err(WSError::KeyNotFound("Loading persistent TPM keys not yet implemented. …"))
}

generate_key works and is real — generate_p256_key, a TPM handle, the public key cached in self.keys. But the handle lives in an in-process map for the lifetime of the Tpm2Provider, and load_key is Err. So a key can be created and used within one run and never reloaded in the next. For a signing root that is fatal: regenerating gives a different key, which for varve means a different realm root and every consumer stranded.

The rest of the backend looks ready for it — 693 lines, tss-esapi, TCTI selection, a simulator path for tests, get_public_key_bytes, verify_signature. The comment even lists the implementation steps (tr_from_tpm_public() from a persistent handle in 0x81000000–0x81FFFFFF). It reads like the one deliberately deferred piece rather than a design gap.

This is our highest-value ask on the hardware side, above PKCS#11. If persistent-key load/store lands, a TPM becomes a credible home for the offline key we discussed above.

One consequence worth flagging early, because it is ours to solve, not yours:

// Create P-256 key (Ed25519 support is rare in TPMs)

That is correct and it is the real obstacle for us. varve realm roots are ed25519 — a trust root is 64 hex characters of ed25519 public key, pinned by hand in every consumer's config. A TPM-held root would have to be P-256, which is a breaking change to varve's trust-root format affecting every pinned consumer.

That is not an argument against TPM. It is an argument for deciding it at the v1.0 ceremony rather than after: v1.0 is already the moment varve mints a new root and migrates consumers via a dual-signed release, so if the root's algorithm is ever going to change, that is the one moment it is cheap. Which means the question "will persistent TPM keys be available?" has a deadline on our side, and we would rather plan around a real answer than a hopeful one.

No pressure for a date — a "yes eventually / no, out of scope / PR welcome" is enough for us to plan.

[avrabe]

Correcting the framing of the two comments above: this reads like a customer filing requests, and sigil is not a vendor to us. We can build these. Concretely, in the order we would take them:

1. #258 — the air-gapped e2e test that cannot fail. Smallest, and the one that makes everything else believable. The 0.11.0 verifier is substantial enough that a test which never calls verify_signature is actively misleading about it. We would add the call plus a negative control — mutate the signature, the leaf cert, the SET, and the Rekor body binding in turn, and assert the test goes red for each. A gate admitted without a proof that it can fail is not a gate, and we have been finding that class in our own repo all month.

2. TPM persistent keys — load_key / evict. The comment in tpm2.rs already names the implementation (tr_from_tpm_public() against a persistent handle in 0x81000000–0x81FFFFFF), the TCTI plumbing exists, and there is a simulator path already in the file (with_simulator), so this is testable in CI without hardware. Bounded and Linux-only. This is the one that unblocks a hardware-held root for us.

3. #256 — signing over an arbitrary 32-byte digest. Possibly mostly an API-surface question: the verify side already takes module_hash: &[u8; 32], so if the signing side is equally digest-shaped, this may be a rename plus a documented contract rather than new logic. We would find out and send whichever it turns out to be.

4. #260 — the cosign-bundle adapter. Larger, and we would want your steer on the shape before writing it.

Two things we would want agreed before sending anything, because they are your calls and not ours:

• The trust-bundle rotation story (point 3 of the original comment). It shapes the API, and guessing it would waste both our time.
• Whether P-256 persistent TPM keys are in scope at all, or whether the intended hardware direction is secure_element / TrustZone and TPM is a demo path. The wsc-linux-x86_64-tpm2 release asset suggests the former, but we would rather ask than infer from a filename — inferring from names is exactly how we got a decision wrong recently.

Say which of 1–4 you want from us and in what order, or say "all of them, in that order" and we will start at the top. If you would rather keep any of it in-house, that is a fine answer too — knowing which pieces are ours to build is worth as much to us as the pieces themselves.