@ -56,8 +56,8 @@ La recuperación a largo plazo quedó hecha con la v0.15, y las palabras al azar
### Protocolo
### Protocolo
0. **La revisión de Astra de la v0.15 (7-10), para la v0.16.** Cinco hallazgos, todos comprobados y aceptados; la v0.15 no cambia. Tras su segunda respuesta, la dirección es:
0. **La revisión de Astra de la v0.15 (7-10), para la v0.16.** Cinco hallazgos, todos comprobados y aceptados; la v0.15 no cambia. Tras su segunda respuesta, la dirección es:
- **Sello sin `accuracy`** (§29.11): S4 solo con una cota de precisión conocida, la del token o la de una política de TSA que el lector tenga identificada (p. ej. una tabla de OID de políticas con su cota, que habría que fijar y mantener en el spec); sin ella el sello verifica pero no acredita anterioridad. Se descarta el margen fijo que propuso Claude: ningún margen finito es conservador para toda TSA. S5 pasa a «No acredita que se sellara antes de la fecha de apertura».
- **Sello sin `accuracy`** (§29.11): S4 solo con una cota de precisión conocida; sin ella el sello verifica pero no acredita anterioridad, y S5 pasa a «No acredita que se sellara antes de la fecha de apertura», con el motivo. Se descarta el margen fijo que propuso Claude: ningún margen finito es conservador para toda TSA. Astra comprobó la política BTSP de ETSI EN 319 421 V1.3.1 (OID `0.4.0.2023.1.1`, §5.2; cota de un segundo, §5.1 y TIS-7.7.2-03), pero TIS-7.7.1-01 exige el perfil de EN 319 422, cuyo §5.2.2 obliga a llevar `accuracy`: un token BTSP sin ella incumple su perfil y da S5, «falta la precisión que exige su perfil»; aceptarlo con un segundo sería una tolerancia de DateKeys que habría que documentar y probar. Un OID declara conformidad, no la certifica. La propuesta de Claude: S4 solo con `accuracy` presente y válida, y un registro de políticas con cota fuera del token que hoy estaría vacío, así que basta con decir que una versión posterior podrá registrarlas. Hay que comprobar las cláusulas citadas al redactar.
- **Anexo y llave de palabras** (§79.6): el anexo incluirá la derivación de §38.1 (normalización, PBKDF2 con su sal y sus rondas, vector), con una receta exacta para un subconjunto explícito y comprobado (los alfabetos de las listas de DateKeys) y, para el resto, las tablas de Unicode 18.0.0 conservadas junto a la documentación (quizá un paquete de recuperación publicado una vez, con su SHA-256). `scripts/recovery` abrirá con palabras, con casos que ejerciten la normalización.
- **Anexo y llave de palabras** (§79.6): el anexo incluirá la derivación de §38.1 (normalización, PBKDF2 con su sal y sus rondas, vector), con una receta exacta para un subconjunto explícito y comprobado (los alfabetos de las listas de DateKeys) y, para el resto, las tablas de Unicode 18.0.0 en un paquete de recuperación publicado una vez (el spec, esos datos, los vectores y `scripts/recovery`), no junto a cada cápsula: el anexo nombra su versión, su SHA-256 y el de cada fichero, para recuperarlo de cualquier copia y comprobar que es el esperado. `scripts/recovery` abrirá con palabras, con casos que ejerciten la normalización.
- **Último bloque de `age`** (§79.5): «el último puede ser más corto», y un vector con un último bloque completo. `scripts/recovery` ya lo hace bien.
- **Último bloque de `age`** (§79.5): «el último puede ser más corto», y un vector con un último bloque completo. `scripts/recovery` ya lo hace bien.
- **Evidencias de la firma con certificado** (§29.10, regla 21): guardar la cadena sin la raíz y las respuestas OCSP cuando quepan; si no caben, el escritor dice qué deja fuera, también de la TSA y de los intermedios, y permite exportarlo; §29.10 promete solo lo conservado. Ligado a la medida del área (punto 3).
- **Evidencias de la firma con certificado** (§29.10, regla 21): guardar la cadena sin la raíz y las respuestas OCSP cuando quepan; si no caben, el escritor dice qué deja fuera, también de la TSA y de los intermedios, y permite exportarlo; §29.10 promete solo lo conservado. Ligado a la medida del área (punto 3).
- **JSON de drand** (§47.1): regla estricta, con vectores: nombres exactos tras decodificar sus escapes (`"\u0072ound"` es `round`), un nombre repetido es `ERR_RELEASE_INVALID`, la ronda un entero sin fracción ni exponente. Hoy Go y TypeScript leen como `encoding/json`: el último gana y los nombres no distinguen mayúsculas.
- **JSON de drand** (§47.1): regla estricta, con vectores: nombres exactos tras decodificar sus escapes (`"\u0072ound"` es `round`), un nombre repetido es `ERR_RELEASE_INVALID`, la ronda un entero sin fracción ni exponente. Hoy Go y TypeScript leen como `encoding/json`: el último gana y los nombres no distinguen mayúsculas.
