Per-component attestation for cFS WASM components: mission-specific signing policies

[avrabe]

Context

In a cFS-on-WASM architecture, each flight software app (Stored Command, Limit Checker, Scheduler, etc.) is an independent WASM component. Sigil's supply chain attestation becomes critical: each component needs independent signing and verification before deployment to safety-critical targets.

Proposal

Mission-Specific Signing Policies

# sigil-policy.toml
[mission]
name = "artemis-gateway"
classification = "class-a"

[policy]
# All components must have at least 2 signers
min_signers = 2

# Components must be signed by both developer and IV&V
required_roles = ["developer", "ivv"]

# Verification evidence must be attached
require_attestation = ["loom-verified", "synth-z3-validated", "meld-proof-checked"]

# Component-specific overrides
[policy.components."health-safety"]
# HS is safety-critical — require additional safety review
required_roles = ["developer", "ivv", "safety-reviewer"]
require_attestation = ["loom-verified", "synth-z3-validated", "meld-proof-checked", "stpa-reviewed"]

Attestation Chain

Each WASM component carries embedded attestations from the build pipeline:

1. Loom attestation: "This component was optimized with Z3-verified passes"
2. Meld attestation: "This component was fused with Rocq-proven merge correctness"
3. Synth attestation: "This component was compiled with Z3 translation validation"
4. Sigil signature: Developer + IV&V signatures on the final binary

Verification at Load Time

When Kiln loads a component (or Gale loads a Synth-compiled ELF):

1. Verify Sigil signatures against mission policy
2. Check attestation chain completeness
3. Reject components missing required verification evidence
4. Log verification results for mission audit trail

Connects to

• kiln#231: cFS reference architecture (components need signing)
• kiln#227: Executive Services (component loading with verification)

Priority

Medium — important for certification but can follow component development.

[avrabe]

Audit context — 2026-04-30

The 2026-04-30 14-perspective audit (audit/2026-04-30/findings.md) identified concrete blockers for this work. The cFS embedded systems engineer reviewer reports the verifier cannot compile against bare-metal targets today. Findings, with file:line:

M-1 (CRITICAL for this issue) — Verifier hard-depends on std

src/lib/src/signature/keyless/verification.rs:344,460 uses std::collections::BTreeMap, std::time::SystemTime, owned String/Vec with no feature-gated alloc-only equivalents. Crypto deps (ed25519_compact, x509_parser, rustls) all require std. Per the audit:

"On embedded systems without std (e.g., bare-metal cFS), this code will NOT compile."

This blocks delivery of issue #79.

M-2 — Build-timestamp fallback as time source

src/lib/src/signature/keyless/verification.rs:152-158 falls back to BUILD_TIMESTAMP when no TimeSource is configured. For flight software, build time is uncorrelated with verification moment — must require an explicit hardware-backed TimeSource (RTC, GPS, TPM clock).

M-3 — Non-deterministic latency on cert extraction

src/lib/src/signature/keyless/verification.rs:407-429 runs base64 decode + X509 DER parse on every verify. No caching, no precomputation. Latency varies with cert size — violates DO-178C Table A.4 bounded-latency for hard-realtime use.

M-4 — Allocation spike during PEM stripping

Same file, lines 414-417: .lines().collect::<String>() allocates intermediates the size of the cert. For a 16KB cert this is a heap spike. Need streaming parser for memory-constrained targets.

Acceptance suggestions for this issue

To deliver per-component cFS attestation, add to the existing acceptance:

• Feature-gate std/alloc: provide no_std core verifier (Ed25519 + bundle validity at minimum).
• Hard-fail when no explicit TimeSource is configured (no BUILD_TIMESTAMP fallback for flight code).
• Bound certificate-chain depth and parse with streaming PEM (no full-blob .lines().collect()).
• Document the supported subset of features for no_std builds — e.g. keyless-Sigstore likely stays std-only; Ed25519 traditional signing should work on bare metal.

The audit also flagged that cert pinning is warn-only today (C-4, separate issue) — for cFS this means even the keyless path that does compile is weaker than advertised. Resolution of cert pinning is a precondition for safety-critical deployment.

References: audit/2026-04-30/findings.md findings M-1, M-2, M-3, M-4.