Forum

Notifications
Clear all

Thoughts on the proposed standard for agent key interchange?

1 Posts
1 Users
0 Reactions
6 Views
(@maya_crypto)
Active Member
Joined: 2 months ago
Posts: 13
Topic starter   [#1861]

I've been reviewing the latest draft proposal for the NemoClaw Agent Key Interchange Format (AKIF). The core idea of a standardized, attestation-backed envelope for migrating agent keys between enclaves is solid, but I have some concerns about the cryptographic agility and lifecycle semantics.

The draft heavily relies on a specific set of algorithms for the outer envelope. For example, it mandates:
- `ECDH-SECP384R1-SHA384` for key agreement
- `AES-256-GCM` for encryption

While these are strong, the spec lacks a clear mechanism for deprecation or negotiation. In a long-lived agent scenario, we need provisions for algorithm rollover. Shouldn't the `akif_version` field be tied to a supported cipher suite registry?

My main questions revolve around the sealing process:

* **Key Provisioning:** The proposal suggests the sealing key is derived from the enclave's hardware identity (e.g., MRENCLAVE). What's the recommended path for deriving a *migration* sealing key that allows movement to a newer, but still attested, enclave platform? The `seal_policy` field seems to hint at this, but it's underspecified.

* **Sealed Storage Lifecycle:** The spec says the sealed blob is "opaque," but for audit purposes, we need at least a standard header. Consider something like:
```json
{
"akif_version": "1.0-draft",
"seal_policy": "migrate_if_attested",
"wrapping_key_id": "enclave_rsa_2048_sha256:0xabc123...",
"creation_timestamp": "2024-06-15T10:30:00Z"
}
```
This would be serialized and prepended before encryption.

* **Enclave Teardown:** The document is silent on what happens during a live migration or emergency termination. If an enclave is torn down mid-operation, are there recommendations for zeroizing the in-memory key material beyond relying on the TPM's volatile memory reset? Should the AKIF envelope include a flag marking keys as "ephemeral" vs. "persistent"?

I'm particularly interested in how this integrates with hardware roots of trust. Does the group envision the outer attestation evidence (like an Intel ECDSA quote) being bundled *inside* the AKIF envelope, or traveling alongside it as a separate but linked artifact? The binding between the two seems critical.



   
Quote