# ATTESTATION ENVELOPE-128 (AE-128) — The iqa Answer Carrier ## (Companion Draft v0.3 — Public Edition) Status: companion design draft — **public edition**, a non-normative working document. It specifies the AE-128 wire envelope implemented by the v1.3.1 packages (Python `iqa.envelope`, JS `@aicent/iqa/envelope`, Rust `iqa_org::envelope`) and cited by their READMEs (sections 2-6). The normative specification is the combined Internet-Draft (`draft-li-rttp-iqa-addressing`); this draft is a companion to the reference specifications, NOT part of the ISE submissions, and creates no IANA/ISE obligations. The implementation plan, provenance and change log are project-ledger material and are intentionally not part of this public edition. ## 0. Relationship to the RTTP pulse frame (prior art, read first) The rttp pillar already ships a 128-byte wire frame: **PulseHeader128**, specified in `SPEC/RTTP-FRAME-EXT-v1.2.6.md` (applies to RFC-002 §4.1 × §10; MAGIC = 0x52545450 "RTTP" at offset 0x00; ROUTE_SHARD at 0x36; bytes 0x00–0x65 frozen since v1.2.6; three reference implementations; 14 frame conformance vectors). That frame is the **question carrier** of the dual-pillar protocol. AE-128 is its **answer-side counterpart**: an iqa attestation envelope. The two artifacts are deliberately separate formats for deliberately separate channels — `rttp` names where, `iqa` states whether; on the wire, the pulse frame carries the intent, AE-128 carries the verdict. They do not parse each other and MUST NOT be conflated: - The pulse frame's frozen region (0x00–0x65) is untouched by this draft; AE-128 does not extend or reinterpret it. - Merging an HMAC-32 attestation into the pulse frame is impossible without breaking the freeze (its extension block is 26 bytes). - AE-128 cites `RTTP-FRAME-EXT-v1.2.6` as prior art for the fixed-width, big-endian, magic-anchored envelope pattern. ## 1. Purpose The two URI schemes answer *where* (rttp, CRI 27) and *whether* (iqa). AE-128 is the wire envelope that carries one question's answer: a fixed-width, transport-independent binary frame containing the subject's ROUTE_SHARD, the attestation verdict, and the cryptographic material needed to verify it offline. Three reasons, in order of weight: 1. **Canonical serialization.** HMAC verification is byte-exact; AE-128 makes the canonical byte layout explicit. 2. **Transport independence.** One frame fits one datagram (128 B << any MTU); no dereference machinery assumed (UDP, BLE, NFC, QR...). 3. **Zero-parser verification.** All fields at fixed offsets; a verifier needs only SHA-256/HMAC-SHA256 primitives — no CBOR decoder, no TLV walker, no schema. Relationship to CRI: CRI 27 compresses the *question*; AE-128 carries the *answer* (as does the pulse frame on the rttp side). Complementary, mirroring the dual-pillar structure itself. ## 2. Frame layout (128 octets, fixed) All multi-octet integers are unsigned, **big-endian (network byte order)**. Offsets are zero-based. ``` Offset Len Field Description 0 4 magic 0x49 0x51 0x41 0x45 ('IQAE' — IQA Envelope; scheme-anchored, mirroring the pulse frame's "RTTP" magic pattern) 4 1 version 0x01 (this draft) 5 1 algorithm 0x01 = HMAC-SHA256 · 0x00 invalid · others TBD 6 2 flags u16 BE · bit 0..15 unassigned · send as 0x0000 8 8 lease_expiry u64 BE Unix seconds · verdict valid until 16 16 intent_shard ROUTE_SHARD of the subject (I-D §4.4: SHA-256(ASCII(authority))[0:16]) 32 32 attestation HMAC-SHA256 (see §3 canonical rule) 64 8 organ exactly 8 octets of US-ASCII organ tag 72 8 nonce u64 BE · unique per verdict issued 80 1 standing verdict state · 0x00 Ghost · 0x01 Probation · 0x02 Radiant · 0x03 Genesis (the closed set of [IQA-SPEC] §11.1.1) 81 15 reserved MUST be all zeros 96 32 extension MUST be all zeros in version 1 (version bump, not TLV, governs evolution) ``` Total: **128 octets exactly.** A receiver MUST reject any frame whose length is not 128 or whose magic/version it does not know. Note: the intent_shard at offset 16 is the same 16-octet value the rttp pulse frame carries at ITS offset 0x36 — same derivation (I-D §4.4), different envelope. This overlap is by design (one subject, one derived address, two carriers) and is not a compatibility claim. ## 3. Canonical rule (HMAC coverage) The attestation field covers the **entire frame** with the attestation field itself zeroed: ``` attestation = HMAC-SHA256(key, frame[0:32] || 0x00*32 || frame[64:128]) ``` Design note: covering the full frame authenticates the organ tag, the nonce, and the standing byte as well: a rewrite of the named answerer, the verdict state, or a replayed frame with a swapped standing would not survive verification. Verification repeats the same computation and compares constant-time. ## 4. Verification procedure 1. Reject if length != 128, magic != 'IQAE', version != 1, algorithm != 0x01, standing not in {0x00, 0x01, 0x02, 0x03}, reserved != 0, extension != 0. 2. Reject if lease_expiry < now (verdict expired). 3. Copy the frame, zero bytes 32..63, compute HMAC-SHA256 with the organ's key material (carried by the verifier per [IQA-SPEC] §7 — no directory, no network call), constant-time compare. 4. Interpret the standing byte (offset 80) per the closed set of [IQA-SPEC] §11.1.1: ``` 0x00 Ghost · 0x01 Probation · 0x02 Radiant · 0x03 Genesis ``` ## 5. Security considerations - **Replay.** Mitigated by (a) lease_expiry and (b) nonce uniqueness per organ. Receivers SHOULD reject a repeated (organ, nonce) pair within one lease window. - **Standing integrity.** The standing byte is inside the HMAC coverage; flipping Ghost↔Radiant on a captured frame is detected by verification, not by policy. - **Algorithm agility.** The algorithm byte exists so HMAC-SHA256 can be replaced without a frame redesign. 0x01 is the only defined value of version 1. - **Why not CWT/EAT.** COSE/CWT and EAT solve portable attestation with a general parser stack. AE-128 trades expressiveness for fixed-offset determinism: a verifier with only SHA-256 can verify with zero dependencies. Where rich claims are needed, those formats remain the right tools. ## 6. Test vector AE128-VECTOR-1 All parameters documented; reproducible from this section alone. ``` authority = f3b2a1c4.pillar.example (the merged I-D's own example, §4.4) ROUTE_SHARD = SHA-256(ASCII(authority))[0:16] = 557c8154d3780cb78cc5fa1bd72b331c organ key = 32-byte US-ASCII test key: 'PLSF-TEST-ORG-KEY-00012345678901' (a 32-byte test label, not a name dependency) version = 0x01 algorithm = 0x01 standing = 0x02 (Radiant) flags = 0x0000 lease_expiry = 1798761600 (2027-01-01T00:00:00Z) organ = 'ORG-TEST' nonce = 0x0000000000000001 reserved/extension/attestation fields = zero before signing magic = 'IQAE' ``` Resulting frame (128 octets): ``` 0 49 51 41 45 01 01 00 00 00 00 00 00 6b 36 ec 80 |IQAE........k6..| 16 55 7c 81 54 d3 78 0c b7 8c c5 fa 1b d7 2b 33 1c |U|.T.x.......+3.| 32 4b d1 4b 6a e7 b0 09 04 98 62 94 a3 26 a0 f0 25 |K.Kj.....b..&..%| 48 58 47 18 4f f2 c9 18 55 39 d4 86 3e fb 84 59 6a |XG.O...U9..>..Yj| 64 4f 52 47 2d 54 45 53 54 00 00 00 00 00 00 00 01 |ORG-TEST........| 80 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 112 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| attestation (bytes 32..63) = 4bd14b6ae7b00904986294a326a0f0255847184ff2c9185539d4863efb84596a ``` Conformance: any implementation MUST reproduce this frame byte for byte from the parameters above, and MUST accept it after round-trip. --- *— end of the public edition (sections 0-6). The implementation plan, provenance and change log of this companion draft are project-ledger material.*