datekeys-doc/spec_v0.9/report.md

The v0.9 draft is written in `spec/DateKeys_Protocol_Specification_v0.9.md` (title "Borrador normativo v0.9", date 29 septiembre 2026) and in `spec/datekeys.cddl`. Nothing is committed. `spec/README.md`, testdata, Go and TS are untouched. The two Go tests that read the spec still pass, because they read the v0.8.2 file. The existing §76 text is byte-identical to v0.8.2.

I rechecked the design's numbers and the critics' claims before writing:
- **Padding:** every value recomputes exactly, and the stated properties hold for L from 0 to 300 000 and for 200 000 random L up to L_MAX.
- **Fixture lengths:** all 5 fixtures match the length formulas.
- **JS arithmetic:** 32-bit operators first give a wrong P at L = 2³² + 1, and in Node `Math.log2(2^49 − 1)` returns 49 instead of 48.
- **Recipients:** with a recipient whose bit 255 is set, both `filippo.io/age` 1.3.2 and `age-encryption` 0.3.1 encrypt a stanza that the identity cannot open. With the zero point (low order), both refuse to encrypt.

## Sections changed
- **Top of the document:** title, date, §1, §4 (goal 8), §5 (new non-goal), §15.
- **Format and header:** §22 (table mapping each format to its control version), §23, §24, §26, §27, §28.1.
- **Padding:** §29, new §29.1 «Relleno del payload», §30, §30.1.
- **Control and slots:** §31 (keys 6 and 7, the 103-byte control), §33, §36, §36.1, §37, §38, §39 (rewritten, defines «credencial» and «señuelo»), §40.
- **Privacy and limits:** §55.1, new §55.2 «Consideraciones de privacidad», §56, §57, §58, §58.1.
- **Writing:** §61, §62, new §62.1 «Reglas del escritor».
- **Reading and tests:** §63 steps 2, 4, 12, 13, 14, 16, 17 and 18, §64, §67, §68.
- **Precedence and compatibility:** §69.1 (layers 1 to 3, the cross-object paragraph, Alcance, 7 new examples), §70, §72.
- **Closing sections:** §73, §74 (with a new «Trabajo futuro» part), §75, new «Cambios normativos de la v0.9» at the end of §76 (13 numbered items, each with Cambio / Motivo / Caso / Tests), §77.
- **Unchanged:** §65, §66 and §69.
- **CDDL:** new header; `control = control-v1 / control-v2`; `payload-length`, `padding-scheme` and `max-payload-length`; the rule linking control version to format, and the 8-byte reading rule.

## Where I followed a critic over the design
1. **Relabel tests (both critics):** the `time_and_key` relabel cases offer the identity, not the `.dkk`. A `.dkk` carries a `capsule_digest`, and editing the VERSION byte breaks it, so those cases would fail earlier (step 9.a, `ERR_ACCESS_INVALID`). I qualified §26 and §70 the same way, added a §69.1 example for the `.dkk` case, and planned `spec:false` companion cases.
2. **Downgrade claim scoped (both):** §70 now says only a capsule whose control was not resealed never outputs its padding. Resealing by someone who knows `I_PAYLOAD` is described as a rewrite, not a downgrade.
3. **Format table, not "control version equals VERSION" (consistency):** §22 has the table and says a new padding code needs a new format. I dropped the clause «salvo que su registro diga otra cosa» from §72.
4. **Padding arithmetic (security):** rows above 2³² added to §29.1; a MUST NOT on 32-bit operations and `Math.clz32`; the float example is now 2⁴⁹ − 1, which is inside the range; a planned accept vector `48 0000000100000001`.
5. **Dummies (security):**
   - A dummy's private key is stated to be a full credential while it exists, with a note on how to generate and wipe it.
   - The permutation and which slots are dummies are MUST NOT stored or delivered.
   - The shuffle rule binds the written header order, unbiased (Fisher–Yates).
   - The indistinguishability argument now rests on age's recipient anonymity under the Diffie–Hellman assumption, not on the distribution of keys.
6. **Readers (both):** L and P MUST NOT drive memory or disk reservation; a MAY check of the `PAYLOAD_AGE` length at step 17, with the same code; §56 gets a MUST NOT for format 2.
7. **`I_PAYLOAD` reason (security):** the stated reason is now confidentiality (shared, content-derived or master-derived keys), not only the binding.
8. **§55.2 additions (security):**
   - a subsection on what format 2 makes impossible to check;
   - the quantum caveat;
   - whether a portable `.dkk` exists;
   - the fixed 256-byte bucket of `bloque256`;
   - what VERSION 1 and the choice of code reveal.
9. **Writers (consistency):** a writer MAY spool the source to learn L and MUST NOT guess it; "abortar" became "report the error, and the receiver MUST discard the output". The self-check also counts P and checks the `PAYLOAD_AGE` length (security).
10. **Smaller corrections:**
    - §62.1 fixture note (C = 127 for `time_only_extensions`);
    - «como mucho 256»;
    - format 1 «contiene (MUST, §33)»;
    - one definition of «credencial»;
    - §69.1 cross-object list now includes the control version;
    - §74 no longer contradicts itself (the CONTROL_CBOR schema stays open, L stays fixed-width);
    - the precedence case "padding 3 + unknown critical extension" is a step test, not a `cbor.json` vector;
    - forward references are marked "(por generar)" / "(por implementar)".

## Rules I added that were not in D1–D7 (please confirm)
- L_MAX = 2⁵³ − 2⁴⁶, with a reader rejection (`ERR_NON_CANONICAL_CBOR`).
- The MUST for a uniform, unbiased stanza order.
- The MAY to reject twist points (the Legendre check in §37). The security critic offered SHOULD or "the list is not exhaustive"; I wrote the latter plus a MAY.
- The official SDK SHOULD show the effective round time, and MAY compare it with the latest published round when online (§62.1 rule 2).
- The MAY check of the `PAYLOAD_AGE` length at step 17.
- The MUST NOT on presenting content before step 17 ends (§56).

## Open questions for the author
1. Is `bstr .size 8` for L acceptable, instead of a CBOR `uint` (which would leak L's width through the control length)?
2. Should readers report the format as SHOULD (as written) or MAY?
3. Keep goal 8 in §4 and the new non-goal in §5?
4. Any new format-1 test objects need a test-only builder, since conforming writers MUST NOT write format 1. Is that acceptable?
5. The `format2_` prefix for the planned fixture names.
6. Optional change, not written: a dummy could be a random valid public key (a canonical u that is not low order), so no private key ever exists. D1 fixes the mechanism, so this needs your approval.
7. Twist points: keep MAY, or make it SHOULD?

## Notes
- **README:** the design also proposed edits to `spec/README.md`; I left them out because the task forbids touching that file. It will need the v0.9 entry once `SpecVersion` becomes "0.9".
- **Effects on the TS phase 3 plan** (from the consistency critic, not written into the spec):
  - `R_ACCESS` must move from last place to the shuffle.
  - The "1 024 recipients" test becomes a rejection above 16.
  - `I_PAYLOAD` should be wiped after the new self-check, not right after sealing.