@ -88,7 +88,7 @@ El vector de GT (`vectors/tlock_ibe.json`) ya está cubierto en `App`. El paso 9
### 2.5 Sesiones del 29-09: v0.9 del spec y formato 2 en Go (retomar aquí)
**Estado al parar (30-09 de madrugada). Retomar por el formato 3, al final de esta sección:** contestar las cuatro decisiones pendientes y aplicar la revisión de Fable.
**Estado al parar (30-09 de madrugada). Retomar por el formato 3, al final de esta sección:** las cuatro decisiones están tomadas; queda aplicar al diseño la revisión de Fable y las decisiones, y empezar la entrega 1.
**Estado al cerrar la fase 3 (29-09 por la noche):**
- Pasos 1 a 5 hechos. El spec v0.9 está cerrado con el tag `spec-v0.9` (`7e2d83c`, en `main` de `datekeys-go`), y las dos implementaciones leen el formato 2: Go desde `f24a280`, que también lo escribe, y TypeScript desde `0118890`.
@ -209,12 +209,25 @@ El vector de GT (`vectors/tlock_ibe.json`) ya está cubierto en `App`. El paso 9
- **9.** Tabla de verdad firma/sello, expresión regular de R6b y regla para una mtime negativa.
- **10.** Prefijos de dominio en `control_commit` y `head_digest`, y el nombre `.datekeys-*` reservado.
- **El documento:** 24 objeciones en vez de 28, marcadas «corregida» o «aceptada»; un glosario (capas 2 a 4, L_MAX, la sal); un texto para un sello que el lector no sabe verificar; una sola fuente en vez de tres ficheros que repiten el texto.
- **Decisiones pendientes del autor**, con mi recomendación:
1. **Tres entregas,** con el formato congelado desde la primera y `security` vacío: primero contenedor y rutas, luego la firma, luego el sello. Recomendado: sí.
2. **Origen del servicio (hallazgo 1).** Recomendado: subdominio aparte, `seal.datekeys.com`, que solo sirve la API, con cabeceras `nosniff` y `CSP: sandbox` de todos modos; la CSP de `/create` lo añade a `connect-src`. La alternativa es el mismo origen con cabeceras forzadas por el proxy.
3. **Vida del sello a décadas (hallazgo 3).** Recomendado: el token lleva dentro la prueba de inclusión y el checkpoint firmado, y una raíz offline fijada desde ya certifica las claves anuales. Así el sello se verifica sin red para siempre, y la auditoría del anclaje queda como comprobación online opcional. Las alternativas son un fichero de prueba aparte (la opción de Fable) o depender del registro.
4. **Abuso sin guardar IP (hallazgo 4).** Recomendado: prueba de trabajo SHA-256 en cada petición, de un segundo en el navegador, sin estado. La alternativa es un límite por IP solo en memoria.
- **Siguiente:** con las respuestas, un flujo aplica los arreglos y las decisiones al diseño con revisión adversarial. Después se redacta el texto del spec v0.10 para que lo apruebe el autor, y siguen abiertas las preguntas de la sección 11 del diseño. Si se aceptan las tres entregas, la primera (contenedor y rutas) puede empezar sin esperar al servicio.
- **Decisiones del autor del 30-09 sobre la revisión:**
1. **Tres entregas,** con el formato congelado desde la primera y `security` presente pero vacío:
- 1: contenedor, varios ficheros y rutas;
- 2: firma y claves de autor;
- 3: el sello, cuando exista el documento «Servicio de sellado v1».
Las entregas 2 y 3 no cambian el formato: un lector anterior muestra «no soportado» y abre igual.
2. **Origen del servicio (hallazgo 1):** el autor no tiene preferencia, así que se toma la recomendación.
- Un subdominio aparte, `seal.datekeys.com`, que solo sirve la API y nunca HTML, con cabeceras `nosniff` y `CSP: sandbox` de todos modos.
- La CSP de `/create` añade ese origen a `connect-src`, solo en esa página.
- Es de la entrega 3 y se puede revisar entonces.
3. **Vida del sello (hallazgo 3):** la prueba va dentro de la cápsula.
- El token lleva la prueba de inclusión y el checkpoint firmado, y una raíz offline, fijada desde ya, certifica las claves anuales. Así el sello se verifica sin red para siempre, y la auditoría del anclaje queda como comprobación online opcional.
- Esto agranda el área de `security`: con el arreglo del hallazgo 5, la entrega 3 define una versión de `security` con un área fija mayor.
4. **Abuso (hallazgo 4):** prueba de trabajo SHA-256 en cada petición, de un segundo en el navegador, sin guardar estado sobre quién pide.
- **Siguiente:**
1. Un flujo aplica al diseño los arreglos de la revisión y estas decisiones, con revisión adversarial, y separa el documento en las tres entregas.
2. Se redacta el texto del spec v0.10 de la entrega 1 para que lo apruebe el autor.
3. Siguen abiertas las preguntas de la sección 11 del diseño; las de la entrega 1 hay que cerrarlas antes del texto.
**Conclusiones de la conversación, sin decisión pendiente:**
- El protocolo no contempla un sello de tiempo de creación (§5, §55.1). Si se quiere, lo recomendado es un sello RFC 3161 u OpenTimestamps sobre el SHA-256 del `.dkc` completo, guardado aparte.
