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 is consumed as a black box: the construction uses only its public interface — encapsulate, decapsulate, and the 32-byte shared secret — and makes no assumption about the combiner's internal hashing. Both KEMs derive the per-slot KEK under one labelled-hash salt shape, SHA-256(label || enc.nonce || <slot KEM material> || pub_R), computed over the slot's own wire bytes: on the hybrid path SHA-256("cardano-poe-xwing-kek-salt-v1" || enc.nonce || kem_ct || pub_R). Hashing to a fixed 32 bytes binds the envelope nonce, the ciphertext, and the recipient public key into the KEK while dissolving the parser ambiguity a variable-length post-quantum ciphertext would create under a bare-concatenation salt. 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.

The sealed key commitment binds the header and the hash claim

Both sealed paths commit the content-encryption key to a closed transcript, serialised with the same canonical-CBOR function the rest of the envelope uses, that pins the header fields and the item's plaintext-hash claim (hashes_hash). On the recipient-addressed (enc.slots) path the commitment is on chain: slots_mac is a CEK-keyed HMAC over a transcript carrying the scheme, path, AEAD and KEM identifiers, the nonce, the shuffled slot set, and hashes_hash — so a relay cannot splice a ciphertext onto a different slot set or a different hash claim without the on-chain MAC check failing, before any ciphertext fetch. The passphrase (enc.passphrase) path carries an equivalent commitment in a 32-byte header inside the ciphertext blob, over a transcript that adds the Argon2id salt and parameters — so tampering with the KDF inputs makes the commitment check fail. The content itself is then sealed in a segmented STREAM under a content key derived from the CEK; the per-chunk AAD is empty, because every header field is already bound to that key transitively. 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 transaction below the threshold is reported pending (the typed code INSUFFICIENT_CONFIRMATIONS), never failed, and may resolve to valid on retry — 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.

A reserved alternative content-AEAD profile

The v1 sealed-PoE content layer is chacha20-poly1305-stream64k — RFC 8439 ChaCha20-Poly1305 in the segmented STREAM layout — which is itself RFC-backed, so there is no open question about the current content cipher's formal status. What remains reserved is a path to a different content AEAD if a deployment context ever requires one. The identifier aes-256-gcm (NIST SP 800-38D) is reserved in the AEAD registry for that purpose and is not part of enc.scheme: 1: a record naming it follows the unknown-envelope rule today.

Introducing it would be a future enc.scheme: 2 construction that preserves the existing slots[] + slots_mac and passphrase-commitment models but swaps the content layer, pinning the new chunk size, content-key derivation, per-chunk nonce construction, per-chunk AAD, and final-chunk authentication for that cipher. 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 key-commitment transcript binding, and the enc.scheme / enc.kem discriminators.
• Signatures — strict Ed25519 verification and the signature registry the reserved post-quantum algorithms would join.