datekeys-doc/spec_v0.9/review.md

• spec/DateKeys_Protocol_Specification_v0.9.md:955 (and §76 item 4, :2934). The claim about 32-bit arithmetic is false, and the vectors would not catch the fault. The text says 32-bit operations "dan la P correcta hasta L = 2³² − 1". I checked this in Node against a BigInt Padmé:

  • With JavaScript's signed bitwise operators, P is first wrong at L = 2 113 929 217: they give 2 113 929 472 instead of 2 147 483 648.
  • With >>> 0, P is first wrong at L = 4 227 858 433: 4 227 858 688 instead of 4 294 967 296.

  The vector table (:968–984) has no row in that range. Row 2³² − 1 passes only by coincidence. So a TS writer using 32-bit operations would pass every planned vector and still produce capsules of about 2–4 GB that correct readers reject at step 17, after the date. Fix: change the claim to "dan una P incorrecta desde L = 2 113 929 217 con los operadores con signo, y desde L = 4 227 858 433 con >>> 0". Add two rows to the table and to padding.json:

  L	P código 1	P código 2	PAYLOAD_AGE 1 / 2
  2 113 929 217	2 113 929 472	2 147 483 648	2 114 445 768 / 2 148 008 120
  4 227 858 433	4 227 858 688	4 294 967 296	4 228 891 080 / 4 296 016 056

  In §76 item 4, change "da la P correcta en todas las filas … hasta 2³² − 1" to match.

• spec/DateKeys_Protocol_Specification_v0.9.md:1773 (§56). The new MUST NOT conflicts with streaming readers. It says a reader "MUST NOT entregar … los L primeros bytes … antes de que el paso 17 termine". This goes beyond D3, which only keeps the commit at step 18. It forbids the streaming Open(dst) design of the reference implementation (capsule/open.go:85-88: dst may hold partial plaintext, which is discarded on error). It also contradicts step 17's "lector en streaming" and the SHOULD earlier in §56. Fix: "MUST NOT presentar como válidos …; un lector que escribe el contenido en streaming MUST NOT escribir el relleno y MUST señalar el error del paso 17 para que se descarte lo escrito (§56)". Or keep the MUST NOT and list it among the rules added outside D1–D7 for the author to confirm.

• spec/DateKeys_Protocol_Specification_v0.9.md:2363 (§64). Two format-2 mutations cannot be reproduced as written.

  • "INNER_ACCESS_AGE con 15/17 stanzas" changes SEALED_CONTROL_LEN by ±98. Only the CONTROL mutations are said to recalculate the PRELUDE. Without that, these cases fail at step 5 or 6 with ERR_INTEGRITY, not at step 12.
  • "16 stanzas, dos para un mismo recipient" (:2347) does not say which identity is offered.
  • "Las de time_and_key ofrecen la identity" is justified only by "el byte editado". But any change to the .dkc breaks capsule_digest.

  Fix:

  • "las que cambian la longitud de SEALED_CONTROL, también las de 15 y 17 stanzas, recalculan el PRELUDE y header_binding";
  • ":2347 → «…, y la identity de ese recipient»";
  • "todas las de time_and_key ofrecen la identity: cualquier cambio del .dkc rompe el capsule_digest de la .dkk".

• spec/README.md:1-17. The README is now out of date. It lists only v0.8.2 and describes datekeys.cddl as "the CBOR schemas of the specification as implemented". The CDDL now holds the v0.9 draft (control-v2), which nothing implements. The task lists this file as one to edit. Fix: add a v0.9 working-draft entry, and describe datekeys.cddl as the v0.9 draft, with the v0.8.2 schemas at tag spec-v0.8.2.

• spec/DateKeys_Protocol_Specification_v0.9.md:2918 (§76 item 1, Motivo). The reason given is inaccurate. With control version 2, a v0.8.2 reader fails at step 14, layer 2, with ERR_UNSUPPORTED_VERSION for that version. It never reaches keys 6 and 7; they would matter only if the control had stayed at version 1. Fix: "…y fallaría allí, tras la petición de red, por la versión 2 de su control (o, si el control conservara la versión 1, por las claves 6 y 7, desconocidas en su mapa cerrado)".

• spec/DateKeys_Protocol_Specification_v0.9.md:986 (§29.1). The sentence about the rows above 2³² is false for L_MAX and contradicts §76 item 4. It says "en ellas Padme supera a bloque256". In the L_MAX row, Padmé equals bloque256 (both are L_MAX), and §76 item 4 says so. Fix: "en ellas, salvo L_MAX, Padme supera a bloque256".

• spec/DateKeys_Protocol_Specification_v0.9.md:954. S does not change. The text says the Node Math.log2 error changes "E, S y lastBits". I checked every failing L: E moves from 48–51 to 49–52, and bitlen is 6 in all cases, so S stays 6. Fix: "no cambia P ni S, pero sí E y lastBits".

• spec/DateKeys_Protocol_Specification_v0.9.md:654 (§22). "no detectaría" is inaccurate. A v0.9 reader does detect an unknown padding code, at step 14 with ERR_NON_CANONICAL_CBOR, but only after the network request. Fix: "que un lector anterior solo detectaría después de pedir el release".

• spec/DateKeys_Protocol_Specification_v0.9.md:1314 (§39) against :2427 and :2430 (§67). §39 has no exception for vectors. §39 says which slots are dummies MUST NOT be stored or delivered. The official vectors record which stanza each credential opens, which reveals the dummies. Fix: add to §39 "salvo en los vectores oficiales de prueba (§67)".

• spec/DateKeys_Protocol_Specification_v0.9.md:2557 (§70). The writing rule binds every implementation. "MUST escribir el formato 2" also binds read-only implementations and the test-only builders of format-1 fixtures (the writer's open question 4). Fix: "una implementación que escribe cápsulas MUST escribir el formato 2 …; solo un generador de vectores de prueba MAY escribir el formato 1".

• spec/DateKeys_Protocol_Specification_v0.9.md:2954 (§76 item 8). Wrong step numbers. In v0.8.2, SEALED_CONTROL is built at steps 9–10 of §61 and at steps 9–11 of §62. Fix: "(pasos 9 y 10 de §61, 9 a 11 de §62)".

• spec/DateKeys_Protocol_Specification_v0.9.md:650 (§22). Wrong section reference. The .dkk schema version is in §41; §40 is its framing. Fix: "(§24, §41)".

• spec/DateKeys_Protocol_Specification_v0.9.md:1749 (§55.2). Wrong section reference. Relays are §48; §46 is the Release Queue. Fix: "(§45, §48)".

• spec/DateKeys_Protocol_Specification_v0.9.md:1279 (§37). The claim is too strong. "Un lector no puede detectar ninguno de los dos casos" is not strictly true for low order: a reader could try the few low-order encodings with a zero shared secret. Fix: "Las reglas de §63 no detectan ninguno de los dos casos".

• spec/DateKeys_Protocol_Specification_v0.9.md:1743 (§55.2). Missing exception. "En formato 2 nadie puede saber cuántas partes…" should except the writer. Fix: "nadie salvo el escritor".

• spec/DateKeys_Protocol_Specification_v0.9.md:2037 (§62.1 rule 7). Wording. "así que esa longitud se conoce antes de calcular header_binding" reads as a description, but it is a requirement. Fix: "así que esa longitud debe conocerse antes…".

• spec/DateKeys_Protocol_Specification_v0.9.md:2047 (§62.1 rule 11). Forward reference. c(P) is used before the note at :2052 defines it. Fix: write 16·max(1, ⌈P / 65536⌉), or add "(nota de abajo)".

• spec/DateKeys_Protocol_Specification_v0.9.md:1989 (§62 step 8). Missing check. Step 8 lacks the "Más de 64 MiB → error (§57)" that §61 step 6 has. Fix: add it.

• spec/DateKeys_Protocol_Specification_v0.9.md:2077 (§63 step 4). Formatting. The line is 104 characters long inside the step block, where the other lines wrap at about 72. Fix: rewrap.

• spec/DateKeys_Protocol_Specification_v0.9.md:2970 (§76 item 11). Inconsistent marking. "capsule.TestEncryptRejectsInvalidOptions, ampliado," lacks the "(por implementar)" that the other extended tests carry. Fix: add it.

• spec/DateKeys_Protocol_Specification_v0.9.md:2336-2361 and §76 (:2987). No reject cases for the shape of payload_length. The test lists have no case for a payload_length of 7 or 9 bytes, or encoded as a CBOR uint, all of which should be ERR_NON_CANONICAL_CBOR at step 14. Fix: add them to §64, or to the new format-2 cbor.json vectors listed in §76.

• spec/datekeys.cddl:114-115. Field names missing from the comments. The key 6 and key 7 comments do not name the fields as the text does (payload_length, padding). Fix: "; payload_length, L, …" and "; padding, the padding code …".

Checked and found correct:

• Decisions: D1–D7 are all present and match the approved decisions. The out-of-scope items appear only under Trabajo futuro in §74.
• §76: the existing text is byte-identical to v0.8.2. §65, §66 and §69 are unchanged.
• Version 1: behaviour is unchanged, except for the acknowledged change to objects relabelled to VERSION 2.
• Numbers: all padding vectors, L_MAX, the 103-byte control, the length formulas and the fixture lengths (446, 482, 646, 842, 78 216, 200) recompute.
• Test data: the "1 825 cases, byte 4 → a7, 05, e8, 20" claim, the fixture stages 16→18, and the existence of the cited tests and mutations all match the repository.
• Precedence and CDDL: every new example in §69.1 is consistent with §63 and the layers. The CDDL matches the text.