Summary

  • RFC 9529 publishes fixed EDHOC inputs, messages, transcript hashes, intermediate keys, exporters, OSCORE parameters and invalid examples so implementations can compare exact results.
  • A complete vector match establishes reproducibility for that computation path; it does not prove fresh randomness, private-key custody, exhaustive validation, credential authority, side-channel resistance or a live application outcome.
  • Decision-grade assurance joins five separate receipts: vector reproduction, negative-input coverage, entropy and key handling, credential and policy authority, and the observed session result.

The continuous-integration report was immaculate. message_1, TH_2, PRK_3e2m, CIPHERTEXT_3, PRK_exporter and the final OSCORE secret all matched the reference bytes. The product dashboard converted that chain into one verdict: EDHOC verified.

On the device, however, the ephemeral private key repeated after every reboot.

This opening is an illustration, not a reported product incident. Its point is the authority of the test. RFC 9529 publishes annotated traces of Ephemeral Diffie-Hellman Over COSE so an implementer can compare inputs, outputs and intermediate calculations. Two independent implementations verified the traces. That is valuable running evidence. It can locate the exact stage at which two implementations disagree.

It cannot certify a property that the fixed trace never varied.

The trace makes a long computation inspectable

EDHOC is designed for constrained devices, but the evidence chain is not small. A session joins method and cipher-suite selection, connection identifiers, ephemeral Diffie-Hellman material, credentials, transcript hashes, MAC or signature inputs, authenticated encryption, exporter derivation and, commonly, OSCORE parameters.

RFC 9529 exposes that chain twice. The first trace authenticates both endpoints with signatures. It identifies X.509 credentials by x5t, uses X25519 for ephemeral-ephemeral key exchange and EdDSA for authentication. The second uses static-DH authentication, identifies CBOR Claims Set credentials by kid, uses P-256 and exercises cipher-suite negotiation through an error followed by a second message_1.

The document does not stop at the three main messages. It prints the inputs to TH_2, TH_3 and TH_4; intermediate pseudorandom keys; the plaintext, ciphertext and associated-data construction; PRK_out; PRK_exporter; OSCORE Master Secret and Master Salt; and the results after KeyUpdate. When one byte differs, an engineering team can move backward from the first divergent value instead of arguing about a final “failed” light.

That is what a reference trace is authorised to say: given these inputs, this specified calculation produces these bytes.

Fixed private keys are a feature of the test

Reproducibility requires fixed inputs. RFC 9529 therefore publishes the endpoints' private and public keys where the calculation needs them. Its security section is blunt: keys printed in the examples cannot be considered secret and must not be used.

The apparent contradiction is the design. A test vector needs known secrets so anyone can reproduce the same Diffie-Hellman and authentication results. A deployment needs secret keys whose creation, storage, use and destruction are controlled. The same bytes cannot perform both jobs.

Passing the vector consequently says nothing about whether a device's random-number generator is healthy, whether two boots produce independent ephemeral keys, whether a private key can be extracted, whether memory is cleared after use or whether a hardware boundary actually enforced the claimed operation. Those are different measurements with different evidence owners.

An assurance programme that stores only “RFC 9529 passed” collapses the laboratory input into the operating state. The better record keeps the vector identifier and implementation build beside a separate entropy-health result, key-generation provenance, key-custody record and reboot or concurrency test.

Transcript equality has a precise scope

The transcript hashes are powerful join points. TH_2 commits to the responder's ephemeral public key and the hash of message_1. Later transcript hashes join the earlier transcript with authenticated plaintext and credentials. Derived keys and ciphertexts depend on that history. A mismatch can expose a wrong CBOR sequence, omitted credential, incorrect suite, erroneous KDF context or different byte encoding.

But equality with a published transcript is not a live peer identity. The trace supplies the credential and key. A real session must obtain or resolve a credential, validate it under the correct rules, establish its relationship to a device or operator and decide what that principal may do. A cryptographic check can succeed while a local identity mapping or authorisation decision is wrong.

Nor is transcript equality an application receipt. RFC 9529 derives OSCORE material for fixed inputs. That does not prove an application message was later accepted, replay state was enforced, a sensor reading was fresh or an actuator performed the requested action. The exporter output is upstream evidence for those events, not a substitute for them.

Invalid examples are probes, not a complete attack surface

Section 4 is particularly useful because it publishes messages an implementation should not compose and must or may reject under EDHOC, CBOR, COSE and NIST rules. The examples include a CBOR array where a sequence is required, extra wrappers around connection identifiers or credential identifiers, the wrong element count, a text string where an ephemeral key needs a byte string and non-deterministic encodings.

The cryptographic cases go further: a key of the wrong length, an x-coordinate outside the field, a value that is not a curve point, a low-order Curve25519 point, a MAC that is too short and an elliptic-curve encoding with a missing leading zero.

The document also states the limit. This is a small set of examples; similar invalidities can occur in other fields and messages. Rejecting every published invalid vector does not prove that a parser is safe for every nesting depth, length, state transition or adversarial sequence. It is evidence of named checks. Fuzzing, property tests, differential testing, resource-limit tests and code review cover other parts of the surface.

The distinction matters to procurement. “Rejects RFC 9529 invalid traces” is auditable. “Robust against malformed EDHOC” is much broader and needs broader evidence.

Deterministic CBOR is part of the cryptographic state

Some disagreements that look cryptographic are really encoding disagreements. RFC 9529 distinguishes raw byte strings from their CBOR encodings and warns that sequences and arrays contain CBOR-encoded elements. Its invalid examples reject unnecessarily long integer forms and indefinite-length arrays where deterministic encoding is required.

This is not cosmetic serialisation. Transcript hashes, signature inputs, MAC contexts and KDF inputs operate on bytes. Two data structures that a debugger renders as the same values can create different cryptographic state if their encodings differ.

A useful conformance record therefore retains more than decoded fields. It preserves the raw message bytes, the deterministic-encoding decision, the first divergent intermediate value and the exact suite and credential form. Logging only a parsed object can erase the evidence needed to explain the failure.

Interoperability is real evidence, with a boundary

RFC 9529 says the traces were verified by two independent implementations and acknowledges contributors to test-vector verification and interoperability testing. Independent agreement reduces the chance that one implementation's private convention was mistaken for the protocol. It is stronger than one codebase testing itself.

It is still agreement on selected examples. It does not establish support for every registered suite, method, credential type, External Authorization Data item or error. The IANA EDHOC registry describes an evolving protocol namespace. A registry entry says a value has an assigned meaning under a procedure. It does not say a product implements it, enables it safely or should accept it in a particular deployment.

This is a recurring infrastructure mistake: turn a portable minimum into a maximum claim. The standard and trace create a common floor. Vendors and operators still own implementation breadth, enabled policy, lifecycle support and observable failure behaviour.

Build assurance as joined receipts

The first receipt is vector reproduction. Record the exact RFC 9529 trace, implementation version, platform, compiler and whether each intermediate value matched. Do not compress a hundred comparisons into a badge before retaining where the first difference occurred.

The second is negative-input coverage. Record which published invalid traces were rejected, at which parser or cryptographic check, and what additional generated or mutated cases were exercised. A rejection without a stable failure class can still hide inconsistent state handling.

The third covers entropy and key custody. Measure continuous and startup health where applicable, test for repeated ephemeral public keys across boots and concurrent sessions, document the source of private material and verify zeroisation or isolation claims separately.

The fourth covers credentials and authority. Record how x5t or kid was resolved, which trust anchor and validation rules applied, which operational principal the credential represented, what method and suite policy allowed, and what action that principal was authorised to request.

The fifth is the running outcome: peer state, session identifier, replay decision, exporter use, OSCORE context creation, protected application message and observed effect. This is the evidence that the system did something, not merely that it could reproduce a derivation.

Heng Lu's reality-layer discipline is practical here. A specification is not an implementation. A matching computation is not fresh key generation. A verified credential is not an authorised operation. A derived secret is not an application outcome. Joining those layers preserves causality; collapsing them produces confidence without control.

What the sources do not establish

The closed sources do not identify a vendor whose deployed EDHOC device repeated keys or misused RFC 9529. They provide no adoption count, fleet failure rate, side-channel result or universal certification claim. The opening scenario remains illustrative.

Nor does the article diminish the trace. The reason RFC 9529 is strategically useful is that it makes a normally opaque key exchange inspectable at many boundaries. Its authority grows when those boundaries are named correctly. A reference vector can prove that a calculation was reproduced. The rest of the deployment still has to produce its own receipts.

Sources