wsc: keyless signing over an arbitrary digest, not only a WASM Module

[avrabe]

Reported from varve, which depends on wsc for DSSE and is evaluating keyless signing to remove long-lived realm root keys entirely.

The gap

Verification is already general. airgapped::AirgappedVerifier::verify_signature takes a 32-byte hash:

pub fn verify_signature(
    &self,
    signature: &KeylessSignature,
    module_hash: &[u8; 32],
) -> Result<VerificationResult, WSError>

Signing is not. KeylessSigner::sign_module(&self, module: Module) requires a WASM Module.

So a caller with bytes that are not a WASM module — varve signs a layer manifest, whose sha256 is exactly a 32-byte digest — can verify with wsc but cannot sign with it.

Ask

A signing entry point over a digest, mirroring what the verifier already accepts:

pub fn sign_digest(&self, digest: &[u8; 32]) -> Result<KeylessSignature, WSError>

sign_module then becomes sign_digest(hash_of(module)) plus the module-embedding step, so there is one keyless signing path rather than two.

Why this matters beyond varve

The airgapped/ module is, as far as I can tell, the only implementation of offline Sigstore keyless verification with a provisioned Trust Bundle in the Rust ecosystem — with real TUF support (tuf.rs, 471 lines, no stubs), a bundle grace period, and an explicit unreliable-time fallback for devices with no clock.

That is valuable to anything signing artifacts for air-gapped consumers, not just WASM. The Module requirement on the signing side is the only thing making it WASM-specific, and it is not load-bearing — the verifier already proves the design is hash-based underneath.

Context

varve is considering replacing its realm root (a long-lived ed25519 key that it can neither rotate nor revoke — both stated as permanent limits in its own threat model) with keyless identity signing. The blocker for that was always offline verification for air-gapped consumers, and wsc::airgapped solves it. This entry point is what stands between the two halves.

Recorded on the varve side as DD-025. Happy to contribute the patch if you would rather review than write it.

[avrabe]

One design detail on the signing entry point, which turned out to matter more than the signature itself.

Signing a bare 32-byte digest would lose a security property, not just change an argument type.

varve's DSSE usage authenticates the payload and its type, via PAE. Its own source states the property and tests it:

"The envelope authenticates both the payload bytes and the payload type (DSSE PAE), so a signed something-else cannot be replayed as a layer manifest"

varve signs several distinct document kinds with one root — layer manifests, line-status advisories, line indexes, release sums. If keyless signing is over SHA256(payload) with no type in the signed input, then a signed line-status advisory can be presented as a layer manifest and the signature verifies. That is a downgrade from where DSSE already is.

So the ask in the issue body would be better as:

/// Sign a DSSE PAE digest — i.e. SHA256(PAE(payload_type, payload)) —
/// so the payload TYPE is inside the signed input.
pub fn sign_pae_digest(&self, digest: &[u8; 32]) -> Result<KeylessSignature, WSError>;

The signature is identical; what changes is what the caller is expected to have hashed. A generic sign_digest invites hashing the wrong thing, and the result will verify perfectly — which is the worst kind of mistake to make available.

If wsc would rather take (payload_type, payload) and compute PAE itself, that is stronger still: it makes the misuse impossible rather than merely documented.

Context: varve DD-026 defers keyless for now (the trust bundle relocates the long-lived key rather than removing it), but this entry point is on the path regardless of that decision.