Skip to content

LIMITATIONS.md

Latest commit

 

History

History
30 lines (20 loc) · 8.76 KB

LIMITATIONS.md

File metadata and controls

30 lines (20 loc) · 8.76 KB
Raw

Limitations

cA2A is a pre-release profile in active design. This document states plainly what is built, what is stubbed, and what is out of scope, so no claim in the documentation runs ahead of the code. This is a deliberate discipline: proof, not promises.

What is built

  • The delegation credential model and the offline chain verifier skeleton: signature checks, scope attenuation (a child grant must be a provable subset of its parent), depth limits, and cross-chain replay rejection. The hardest of these semantics is reused from agent-manifest, where it is implemented and tested.
  • Configuration, error registry, and the CLI surface, including ca2a start, which builds a PeerNode from a config file and serves it over the reference transport.
  • A reference HTTP transport and the attestation handshake, in software mode. ca2a_runtime.transport.server and ca2a_runtime.transport.client (standard library only) run a live inbound A2A-profile call end to end: the caller fetches the callee's attested channel key, seals a payload to it, and sends a delegated task; the callee parses the A2A metadata with the adapter, runs verify + policy + enforce + open-sealed + provenance, and replies. ca2a_runtime.attestation gates the seal on a verified channel key. This is a reference transport, not part of the profile: the profile mandates no wire protocol (see Out of scope), and in software mode the peer key is accepted at assurance="none".

What is stubbed or not yet implemented

  • Hardware-attested live binding. The verifier seam in ca2a_runtime.attestation has now been driven off a real SEV-SNP quote on an Azure confidential VM: verify_offer returned assurance="hardware", a payload was sealed to a channel key a hardware-verified measurement vouches for, and both a measurement mismatch and a stale nonce were rejected. See docs/hardware-validation.md. Two gaps remain. First, the reference server/client still run in software mode by default (assurance="none"); the hardware path is a validated capability, not the default configuration. ca2a start inherits that: it refuses to start under provider: auto when no confidential-computing platform is detected, so a software-mode listener is always a config that names software-only, never a downgrade. Second, attestation on that run was one-directional: a follow-on cross-operator run (an Azure SEV-SNP peer calling a GCP Intel TDX peer, recorded in the same document) had the caller appraise the callee's real TDX quote before sealing, but the callee did not appraise the caller in return. The protocol is no longer one-directional -- a callee now issues a challenge and appraises the caller's offer before opening the sealed payload (docs/spec/mutual-attestation.md) -- but that is implemented and tested in software mode only, it is off by default, and making the protocol mutual does not make the recorded hardware run mutual. Mutual attestation on real silicon in both directions is still outstanding, it is still not simultaneous (the caller commits a sealed payload before the callee has appraised it), and both peers were driven by one operator's harness.

  • Sealed peer channel (hardware property). The channel is implemented: a payload is sealed to the peer's attested X25519 key (X25519 ECDH, HKDF-SHA256, ChaCha20-Poly1305), and only the holder of the peer's private key can open it. On a live call the handshake now gates the seal on a channel key the caller has appraised, but in software mode that appraisal is assurance="none". Until the seal is bound to a hardware-verified measurement (above), do not assume a payload is confined to a specific attested measurement. Adapter-decoded sealed_payload bytes are opaque ciphertext only.

  • Real hardware attestation. The SEV-SNP and Intel TDX verifiers now appraise genuine hardware evidence end to end: a real Azure CVM SEV-SNP report (VCEK chain to the AMD ARK-Milan root, ECDSA-P384 report signature, measurement binding) and a real GCP C3 DCAP v4 TDX quote (PCK chain to the Intel SGX Root CA, QE binding, quote signature, MRTD binding), both fail-closed and both rejecting a tampered copy. Runs are recorded in docs/hardware-validation.md. The TPM 2.0 verifier (AK chain to a caller-supplied vendor root, AK signature, magic/type, and the key-and-nonce binding) is implemented, and its cryptography is delegated to agent_manifest.verify_tpm_quote rather than being a third copy. Quote generation for SEV-SNP and TDX is now implemented, through the kernel configfs-TSM interface, but has not been run on real silicon: the collectors are exercised against a simulated configfs tree and synthetic reports only, so they are code that should work rather than a validated capability. Azure confidential VMs are explicitly out of scope for the SEV-SNP collector, since a paravisor-mediated guest cannot set REPORT_DATA and roots its channel key through the vTPM instead. This validates those verifiers, not a running attested peer: until the verifier seam in ca2a_runtime.attestation is driven off a live quote on a confidential VM, cA2A must not be described as attested across trust domains.

  • TPM collection works on hardware; chained verification does not, on every host. Measured on a real Azure Trusted Launch vTPM (Standard_D2s_v7, eastus2, 2026-08-01). What passed: TpmProvider.attest produced a genuine quote signed by the platform attestation key (RSASSA/SHA-256), the shipped certificate certifies the quoting key, parse_tpmt_signature unwrapped the real TPMT_SIGNATURE and the bare signature verified against the shipped key, a tampered attest blob was rejected, and the quote's extraData equalled the derived key-and-nonce binding. Collector and verifier also ran in one process, which the previous caveat here said was untested: building tpm2-pytss from source inside a venv resolves the conflict with agent-manifest's cryptography, so that tooling limitation is retired.

    What failed, and it is the important half: verify_tpm_report could not chain to a pinned root, reporting "AK chain root is not among the supplied trusted TPM roots". On that host the AK certificate at NV 0x01C101D0 is 994 bytes, is issued by CN=Global Virtual TPM CA - 03, and carries no AIA extension at all, so there are no intermediates to fetch and none stored elsewhere in NV. A different Azure host (Standard_D2s_v5, eastus, 2026-07-31) presented a 1596-byte certificate under Azure Cloud Virtual TPM CA - 11 with a walkable AIA chain reaching the root pinned in ca2a_verify/tpm_roots.py. Both observations are real: Azure runs more than one vTPM CA generation, so the shipped Azure root is not sufficient fleet-wide and a deployment must pin the hierarchy its own hosts actually present. Until then, treat the TPM tier as: evidence is genuine and its signature and binding are verifiable, but key provenance is host-dependent.

  • TPM evidence proves key provenance only where a chain reaches a pinnable root. A quote signed by the transient fallback key is a verifiable signature but carries no certificate chain, so it proves nothing about where the key lives, and verify_tpm_report rejects it. As above, a platform-provisioned certified attestation key is necessary but not sufficient: the chain must also be assemblable, which fails when the AK certificate carries no AIA. A GCP Shielded VM is weaker still (probed 2026-07-31: no EK certificate, no persistent handles, and get-shielded-identity returns a bare ekPub with no certificate). Client firmware TPM vendor roots are not yet published in a pinnable form. Separately, the TCG event log is 0 bytes on both Azure and GCP, so PCR values cannot be attributed to specific boot events on either cloud.

Out of scope

  • A normative or production A2A transport. cA2A is a profile on A2A, not a replacement for it, and mandates no wire protocol. A reference HTTP transport ships (ca2a_runtime.transport.server/client) so the peer path is runnable on ordinary compute, but it is a convenience, not part of the profile: any A2A server can drive the adapter and a PeerNode instead, and cA2A makes no claim about the reference transport's production hardening.
  • Agent identity issuance beyond delegation.
  • AI model governance beyond delegation and provenance.
  • Hardware TEE platform SDKs and firmware.

Dependencies on sibling projects

cA2A composes primitives from agent-manifest, cmcp, and trace-spec. Version skew across those repos can change cA2A behavior; pin compatible versions before relying on cross-repo guarantees.