TrustMee Verification Library

wasm-verification-component is the TrustMee verifier host for Wasm verification components. It reads a TrustMee CMW input, extracts the TrustMee-profile EAT evidence, loads a stapled verification component when present, or resolves the matching component from an OCI repository and caches Wasm verification components locally.

Normative format documents:

• TRUSTMEE_EAT_PROFILE.md
• TRUSTMEE_CMW_COLLECTION_TYPE.md

Related projects

• TrustMee mainline is a modified Trustee implementation that integrates TrustMee as a verifier driver and uses this repository as its verification library.
• wasm-verification-components contains the Wasm verification components that this verifier host can execute.

Input model

The primary input is a CMW Collection that contains:

• exactly one TrustMee-profile EAT Evidence item
• zero or more endorsements
• optionally a stapled Wasm verification component as an endorsement

The TrustMee EAT payload carries:

• component_id
• evidence
• evidence_type

If the matching Wasm verification component is not stapled into the CMW, the host resolves it from:

• compiled-in placeholder OCI base: oci://registry.example.com/trustmee/verifier-components
• optional override: --component-repository-hint
• recommended deployment base: oci://ghcr.io/<github-owner>/trustmee-verifier-components

CLI usage

cargo run -p wasm-verification-component -- \
  --input <path-to-cmw-file> \
  --component-repository-hint <oci-base> \
  --component-trust-store <trust-store.json> \
  --cache-dir <cache-dir> \
  --compact

Component trust store

When --component-trust-store is provided, the library verifies embedded verifier-component signatures with wasmsign2 before executing the component.

Trust store JSON:

{
  "signers": [
    {
      "public_key": "-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----\n",
      "fuel": -1,
      "allow_network": true,
      "valid_until": "2026-12-31T23:59:59Z"
    }
  ]
}

Notes:

• public_key accepts PEM or OpenSSH text. Hex, base64, and base64url encodings of raw wasmsign2 key bytes are accepted too.
• fuel = -1 means unlimited Wasmtime fuel. Any other value must be a non-negative integer.
• valid_until must be an RFC3339 UTC timestamp.

Execution policy:

• CMW verification is restrictive by default.
• An unsigned component runs with 1_000_000_000 Wasmtime fuel and no outbound network access.
• A signed component must verify against exactly one trusted, unexpired signer entry. That entry decides the fuel limit and whether outbound network access is allowed.
• If a signature is present but invalid, expired, untrusted, or ambiguous, verification fails before the component is instantiated.
• Direct verify_bytes and verify_paths calls keep legacy behavior unless a trust store is explicitly supplied.

OCI package mapping

The TrustMee wire format stays digest-based. The host maps that digest onto wasm_pkg_client package coordinates at fetch time:

• repository base: oci://<registry>/<prefix...>/<namespace>/<package>
• Wasm package ref: <namespace>:<package>
• OCI namespace prefix: <prefix...>/ when extra path segments are present before the final two segments
• component version: component_id = component-<sha256> maps to package version 0.0.0-component.sha<sha256>

Examples:

• oci://ghcr.io/acme/trustmee-verifier-components
  • package: acme:trustmee-verifier-components
  • version for a component digest: 0.0.0-component.sha0123...
• oci://ghcr.io/webassembly/acme/trustmee-verifier-components
  • package: acme:trustmee-verifier-components
  • namespace prefix: webassembly/
• file:///tmp/local-registry/acme/trustmee-verifier-components
  • local backend root: /tmp/local-registry
  • package: acme:trustmee-verifier-components

Recommended registry

For public or shared verifier components, use GitHub Container Registry (ghcr.io):

• it is a standard OCI registry
• public packages can be pulled anonymously
• wasm-pkg-tools already documents GHCR-backed Wasm package layouts
• it fits the package mapping above without introducing TrustMee-specific registry requirements

For private internal deployments, use either private GHCR or a self-hosted OCI registry such as Harbor. The TrustMee client-side mapping stays the same.

Publishing components to GHCR

1. Choose a base such as oci://ghcr.io/<github-owner>/trustmee-verifier-components.
2. Build the Wasm component and compute its TrustMee component_id.
3. Convert that digest to the package version 0.0.0-component.sha<sha256>.
4. Publish the component to package <github-owner>:trustmee-verifier-components at that version.

The simplest flow uses wkg from wasm-pkg-tools.

Example config at ~/.config/wasm-pkg/config.toml:

[registry."ghcr.io"]
type = "oci"
[registry."ghcr.io".oci]
auth = { username = "<github-username>", password = "<github-pat-with-write:packages>" }

Example publish command:

wkg publish ./path/to/verifier_component.wasm \
  --package <github-owner>:trustmee-verifier-components@0.0.0-component.sha<sha256> \
  --registry ghcr.io

Notes:

• For private GHCR packages, readers need read:packages.
• In GitHub Actions, you can usually publish with GITHUB_TOKEN when the package is associated with the workflow repository.
• If you publish programmatically, use wasm_pkg_client::Client::publish_release_data or publish_release_file with the same package/version mapping shown above.

TrustMee CMW shape

JSON CMW records are encoded as:

{
  "__cmwc_t": "https://trustmee.invalid/cmw/verification-input",
  "evidence": [
    "application/eat-ucs+json; eat_profile=\"https://trustmee.invalid/eat/component-evidence\"",
    "<base64url(EAT JSON payload)>",
    4
  ],
  "verifier": [
    "application/wasm",
    "<base64url(wasm bytes)>",
    2
  ],
  "snp-collateral": [
    "application/vnd.trustmee.snp-collateral+cbor",
    "<base64url(CBOR collateral)>",
    2
  ]
}

The inner JSON EAT payload uses:

{
  "eat_profile": "https://trustmee.invalid/eat/component-evidence",
  "component_id": "component-<sha256-of-wasm-bytes>",
  "evidence_type": "application/octet-stream",
  "evidence": "<base64url(raw evidence bytes)>"
}

CBOR CMW input is accepted too. The integration tests cover both JSON and CBOR variants.

Sample artifacts

The test_data/ directory includes sample verification components and evidence files for local testing:

• test_data/tdx_verifier_component.wasm
• test_data/snp_verifier_component.wasm
• test_data/snp_verifier_host_crypto_component.wasm
• test_data/tdx_quote.bin
• test_data/snp_evidence.json

Signed sample assets are available under test_data/signature-demo/:

• test_data/signature-demo/snp_verifier_component.private.pem
• test_data/signature-demo/snp_verifier_component.public.pem
• test_data/signature-demo/snp_verifier_component.trust-store.json
• test_data/signature-demo/snp_verifier_component.signed.wasm

These files are for local testing only.

Manual SNP Signature Demo

Run the ready-made manual test script:

./scripts/test_snp_signature_manual.sh

The script checks:

• unsigned SNP component without a trust store succeeds
• signed SNP component with the sample trust store succeeds
• signed SNP component with an expired trust store fails
• signed SNP component without a trust store still succeeds in direct mode for compatibility

Tests

cargo test -p wasm-verification-component --test sample_library_usage -- --nocapture
cargo test -p wasm-verification-component --test cmw_input -- --nocapture