Open questions

Label 309 v1 is frozen. The wire format under metadata label 309, the canonical-CBOR encoding, the algorithm registries, the sealed-PoE envelope, and the signature construction are settled: a conformant v1 verifier reads every v1 record, and a conformant v1 producer emits records every v1 verifier accepts. This page is not about changing that. It is the register of what is confirmed in the standard today and what remains forward-looking — candidate cryptographic constructions reserved for a possible future revision, and the disciplined procedure for changing a cryptographic constant when one of them lands.

Nothing here is a product roadmap. Every entry is a protocol-level technical decision: an algorithm identifier, a derivation, a verifier policy, or a versioning rule. A reader implementing the standard needs the settled half to build a v1 implementation today, and the forward-looking half to build it so that a future post-quantum or RFC-only successor is an additive registry entry, never a rewrite.

Settled constructions

These are decided. They are stated plainly here because they are the load-bearing choices an implementer most often wants confirmed in one place; the linked pages carry the full construction.

The post-quantum KEM ships in v1

The hybrid KEM X-Wing (ML-KEM-768 composed with X25519) is registered under the identifier mlkem768x25519 in the enc.kem registry from the first release. It is not a future candidate: it lives in enc.scheme: 1 alongside the classical x25519 KEM, and the on-wire enc.kem field selects the per-slot KEM, slot shape, and key-encryption-key derivation per record.

X-Wing was chosen because its combiner — SHA3-256 over the ML-KEM shared secret, the X25519 shared secret, the X25519 ciphertext, the X25519 public key, and a fixed label — already binds the ciphertext and recipient public key into the 32-byte shared secret. That subsumes the transcript binding a length-prefixed HKDF salt would otherwise provide, which dissolves the parser-ambiguity that variable-length post-quantum public keys would create under an unprefixed salt layout. The per-slot KEK is therefore derived with an empty HKDF salt and a single fixed info string. Only the hybrid variant is exposed — pure ML-KEM is deliberately withheld so the X25519 leg preserves classical security if ML-KEM-768 is ever broken. See Sealed PoE and Algorithm registries.

Sealed content AAD binds the slot set

On the recipient-addressed (enc.slots) path, the content AEAD's additional authenticated data is nonce || slots_mac — the AEAD nonce concatenated with the slot-set commitment. This binds the encrypted content to the exact set of recipient slots that delivered the key, so a relay cannot splice a ciphertext onto a different slot set without the content AEAD failing. The passphrase (enc.passphrase) path uses empty AAD, because there the KDF salt already covers the binding. Full construction on Sealed PoE.

Confirmation depth is verifier policy

A record is anchored the moment its transaction is included, but a verifier deciding how much settlement to require before reporting a verdict applies a confirmation-depth threshold. Label 309 makes this a verifier policy, not a normative MUST. The standard defines the machine-readable surface — a pending verdict for shallow confirmation and a typed failure when a configured threshold is breached — while the threshold itself (RECOMMENDED ≥ 15 blocks) is a deployment-configured input, not a constant baked into the wire format. A verifier that requires deeper settlement for high-value claims is fully conformant. See Verification.

Ed25519 verification is strict

Record-level signatures MUST be verified under the strict rules of RFC 8032 §5.1.7, not under the more permissive ZIP-215 batch-verification tolerance. Strict verification rejects non-canonical encodings and small-order points that a tolerant verifier would accept, so two conformant verifiers always reach the same verdict on the same signature. Implementers must confirm their Ed25519 backend is in strict mode; some libraries default to the tolerant variant. See Signatures.

Canonical CBOR is the determinism contract

Every record is encoded as canonical CBOR per RFC 8949 §4.2.1: preferred integer forms, definite-length arrays and maps, bytewise-sorted map keys, no duplicate keys, no tags. Determinism is what lets a signature computed over the body by one implementation verify under another, and what lets two producers of the same logical record emit byte-identical bytes. This is non-negotiable across every conformant implementation and is the foundation of the cross-language parity contract.

Forward-looking candidates

The items below are candidates, not shipped constructions. None is a v1 defect; none is committed. They are recorded so that an implementation built today leaves room for them as additive registry entries, and so a future reviewer can see which evolutions the algorithm-agile design already anticipates.

An RFC-only content AEAD profile

The v1 sealed-PoE content layer uses XChaCha20-Poly1305. Its 24-byte random nonce is the safer operational default for stateless producers — a fresh random nonce never collides without state coordination. The trade-off is formal status: XChaCha20-Poly1305 is specified in an expired CFRG internet-draft, not an RFC.

If external review requires every content AEAD to be RFC-backed, a future enc.scheme: 2 construction can preserve the existing slots[] + slots_mac model but replace the content layer with RFC 8439 ChaCha20-Poly1305 in a chunked STREAM profile. Such a profile would pin chunk size, content-key derivation, per-chunk nonce construction, per-chunk AAD, and mandatory final-chunk authentication so truncation is detectable. It is a fallback profile, not a replacement: existing enc.scheme: 1 records remain valid, and the profile must not be implemented before a normative enc.scheme: 2 definition and its test vectors exist.

Reserved post-quantum signature algorithms

The KEM half of the post-quantum trajectory ships in v1 (above). The signature half is reserved but not yet implemented. Two families are candidates to slot into the existing signature registry once IETF COSE stabilises the post-quantum algorithm identifiers:

Because the signature algorithm is a named identifier in the COSE protected header, registering a successor is purely additive: existing Ed25519 records keep verifying, and a verifier that does not recognise a new signature algorithm reports an unsupported-algorithm signal rather than rejecting the content claim. An unrecognised signature never invalidates the underlying existence proof. See Signatures.

A potential v: 2 publication path

Individual additions — a new KEM, a new content AEAD, a new signature algorithm — are registry entries that do not change the top-level record schema. A KEM addition in particular is a registry entry under enc.scheme: 1, not a scheme bump; an enc.scheme bump is reserved for a cross-KEM construction change (a new slots_mac or content AEAD that applies to every KEM at once).

If enough record-schema-changing candidates accumulate, the cumulative change may warrant a top-level v: 2 record published alongside v1. Both versions would remain valid metadata schemas under label 309; a verifier selects on the v discriminator inside the record. The path-to-standardisation steps repeat for the new revision. This is the largest-scope evolution and is triggered only by accumulation — nothing here is scheduled.

Optional one-hop supersedence resolution

A record's optional supersedes field points at one earlier record by transaction hash. Resolving that pointer is optional for a verifier. A verifier that confirms supersedes is structurally a 32-byte hash but does not fetch the prior transaction is conformant, but it misses the chance to surface the supersedence chain. Guidance: a verifier MAY resolve one hop — re-query the transaction resolver for the referenced hash and report its existence and block time — without recursing further. One hop is sufficient; deeper traversal is the caller's responsibility, and supersedence never revokes the earlier record, which the chain keeps independently verifiable forever.

Migrating a cryptographic constant

Every settled construction above depends on named constants: algorithm identifiers, HKDF info strings, KDF salts, AEAD nonce lengths, domain-separation labels. Changing the meaning of any one of them is a wire-format break, and the standard prescribes exactly one disciplined path for it. The governing rule: use the smallest-scope change that resolves the issue, and never silently change the meaning of an existing constant under the same namespace.

The procedure is additive and backward-compatible — old records keep verifying under the constants they were published with — and proceeds by scope:

1. Version the namespace, not the value. A changed derivation increments the -vN suffix on every domain-separation string it touches: HKDF info strings (…-v1 → …-v2), HMAC message prefixes, salts, and labels. A new constant lives under the new suffix; the old constant stays valid under the old suffix. Older verifiers reject newer records cleanly at the discriminator instead of misinterpreting them.

2. Bump the discriminator that matches the blast radius. A change confined to one slot family is selected by enc.kem; a cross-KEM change to the content layer or slot-set commitment is an enc.scheme bump; a change to the record schema itself is a top-level v bump. Each discriminator localises the break to the smallest layer that actually changed.

3. Keep predecessors verifiable. Older record versions remain readable as frozen schemas. A verifier selects the construction by the record's own version discriminators, so a single implementation can verify v1 and a future successor side by side. No record ever stops verifying because a successor shipped.

Related pages

• Algorithm registries — the named identifiers whose namespaces version under a migration.
• Sealed PoE — the X-Wing hybrid KEM, the content AAD binding, and the enc.scheme / enc.kem discriminators.
• Signatures — strict Ed25519 verification and the signature registry the reserved post-quantum algorithms would join.