From 0a654871f3ca9d1efedb052bff7ce1afcc7c84f1 Mon Sep 17 00:00:00 2001 From: dev Date: Wed, 7 Oct 2026 00:20:31 +0200 Subject: [PATCH] Spec v0.15 draft: the decisions for the author Co-Authored-By: Claude Opus 5.5 --- HANDOFF.md | 2 +- README.md | 1 + spec_v0.15/decisiones.md | 60 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 62 insertions(+), 1 deletion(-) create mode 100644 spec_v0.15/decisiones.md diff --git a/HANDOFF.md b/HANDOFF.md index 61cc533..1fa5a6e 100644 --- a/HANDOFF.md +++ b/HANDOFF.md @@ -37,7 +37,7 @@ En el orden que recomendó la sesión del 6-10 y aceptó el autor: este HANDOFF, ### Protocolo 1. **La revisión externa.** El paquete está listo; lo que falta es del autor. Al recibir el informe, se abre la versión siguiente con sus hallazgos, el párrafo de idioma y precedencia del final del §1, las etiquetas del §76 que hoy llaman independientes a revisiones de IA, y el registro de la revisión (§75, punto 10). Todo eso lo aprobó el autor el 6-10; ver [revision_externa/precedence_and_language.md](revision_externa/precedence_and_language.md). -2. **La recuperación a largo plazo.** Es lo más grave que queda abierto: una cápsula a veinte años depende de que alguien conserve el release de su ronda. El §74 lo deja como trabajo futuro: un objeto de release, su fuente de archivo y el uso del reloj local en el paso 9.c. El diseño está en [diseno_recuperacion.md](diseno_recuperacion.md) (6-10), con ocho decisiones para el autor. +2. **La recuperación a largo plazo.** Es lo más grave que queda abierto: una cápsula a veinte años depende de que alguien conserve el release de su ronda. El §74 lo deja como trabajo futuro: un objeto de release, su fuente de archivo y el uso del reloj local en el paso 9.c. El diseño está en [diseno_recuperacion.md](diseno_recuperacion.md); el autor eligió la opción A y sus ocho recomendaciones (6-10). El borrador v0.15 está en la rama `v0.15` de Go (`b7402bd`), sin aprobar, con sus decisiones en [spec_v0.15/decisiones.md](spec_v0.15/decisiones.md). 3. **Medir el área de 32 KiB y cerrar el perfil CMS** (§74; §75, punto 13), con firmas reales con certificado de varios países y sellos de autoridades reales. Necesita firmas del autor o permiso para pedir sellos a una autoridad pública. 4. **Lo que el §74 aún llama provisional:** los esquemas de bytes de la cabecera, el control y la `.dkk`, los límites de los campos y los vectores definitivos del perfil. Conviene congelarlo con el informe de la revisión delante. 5. **El registro de perfiles firmado** (§71), que no existe. diff --git a/README.md b/README.md index dd52a3c..01b403c 100644 --- a/README.md +++ b/README.md @@ -50,6 +50,7 @@ Para retomar el trabajo, lee [HANDOFF.md](HANDOFF.md): el estado de cada repo, l | [spec_v0.14/](spec_v0.14/decisiones.md) | El borrador v0.14: las [decisiones para el autor](spec_v0.14/decisiones.md), con su recomendación | | [revision_externa/](revision_externa/NOTA_PARA_EL_AUTOR.md) | El paquete para una revisión criptográfica externa, en inglés, con una [nota para el autor](revision_externa/NOTA_PARA_EL_AUTOR.md) | | [diseno_recuperacion.md](diseno_recuperacion.md) | Diseño de la recuperación a largo plazo: el objeto de release `.dkr`, el reloj del paso 9.c, el archivo de releases y el anexo de recuperación, con las decisiones para el autor | +| [spec_v0.15/](spec_v0.15/decisiones.md) | El borrador v0.15, la recuperación a largo plazo: las [decisiones para el autor](spec_v0.15/decisiones.md) | | [spec_v0.9/](spec_v0.9/README.md) | Papeles de trabajo del borrador v0.9: diseño, revisiones y correcciones pendientes | | [spec_v0.10/](spec_v0.10/formato3_diseno.md) | Formato de cápsula 3 en diseño, en tres entregas: varios ficheros, firma de autor y sello de tiempo. El diseño, con sus revisiones incorporadas, la revisión de Fable y la revisión final del borrador del spec | | [spec_v0.11/](spec_v0.11/llave_palabras.md) | Papeles de trabajo de la v0.11, ya etiquetada. Contiene:
la [llave de palabras](spec_v0.11/llave_palabras.md);
la [consulta a Fable y Astra sobre el tamaño del área de firmas y sellos](spec_v0.11/area_firmas_para_revision.md) y [su propuesta](spec_v0.11/revision_fable_astra.md);
la [revisión del borrador](spec_v0.11/revision_borrador.md);
la [revisión de lo hecho en la sesión del 1 y 2 de octubre](spec_v0.11/revision_sesion_1_2_octubre.md), con los fallos pendientes de arreglar | diff --git a/spec_v0.15/decisiones.md b/spec_v0.15/decisiones.md new file mode 100644 index 0000000..3df8285 --- /dev/null +++ b/spec_v0.15/decisiones.md @@ -0,0 +1,60 @@ +# Borrador v0.15: decisiones para el autor + +*7 de octubre de 2026. El borrador está en la rama `v0.15` de `datekeys-go` (`b7402bd`), en `spec/DateKeys_Protocol_Specification_v0.15.md`. Es la recuperación a largo plazo del [diseño](../diseno_recuperacion.md), con la opción A y las ocho recomendaciones que aprobaste el 6-10. Lo hizo un agente Opus; la sesión revisó el paso 9.c en el código. `scripts/check.sh` pasa entero, con un script nuevo que abre dos fixtures siguiendo solo el anexo.* + +Si apruebas lo que sigue tal como está, basta con decir «apruebo el borrador». Al aprobarlo se cierra como la v0.14 y se lleva a TypeScript, a Dart y al paquete de la revisión externa. + +## Lo que hace el borrador + +1. **El objeto de release y el fichero `.dkr`** (§20, §47, §47.1 nueva, CDDL). Es un CBOR de 111 bytes: `{0: "datekeys-release", 1: 1, 2: chain_hash, 3: ronda, 4: firma}`. No lleva firma propia ni la marca de «verificado»: se comprueba contra el perfil fijado. Los lectores siguen aceptando el JSON de drand como entrada, pero un escritor nunca lo guarda. +2. **La cadena en el paso 10** (§51, §63). Primero las capas del objeto, después `chain_hash` (`ERR_PROFILE_MISMATCH`), la ronda y la firma. No hay códigos de error nuevos. +3. **El paso 9.c, opción B** (§49, §63). El reloj local solo cuenta antes de pedir a la red. Un release que el lector ya tiene, pegado, de un fichero o de un archivo local, no se compara con el reloj, y el lector MAY avisar de que el reloj va atrasado. +4. **La recuperación a largo plazo** (§50, §53, §62.1 reglas 26 a 28): + - el `.dkr` junto al `.dkc` es el camino principal, y también junto a una `.dkk` con localizador; + - el archivo de releases es un formato informativo, sin prometer dónde se aloja; + - el SDK SHOULD avisar al sellar, guardar el anexo y guardar el `.dkr` pasada la fecha. +5. **La Release API** (§45): su respuesta es el objeto de release; la forma HTTP es informativa. +6. **El §74:** salen los dos puntos de trabajo futuro que esto cubre, y entran la extensión `datekeys.release` de la `.dkk` y un archivo publicado. +7. **El anexo de recuperación** (§79 nueva, informativa, después del §78 para no renumerar el §77). Explica cómo abrir una cápsula `time_only` y una `time_and_key` sin el software de DateKeys: + - los parámetros de Quicknet; + - la trama; + - la verificación del release; + - el stanza tlock; + - cómo abrir un fichero `age` desde su file key; + - las capas X25519 con `age -d`; + - el contenido de cada formato. + + `scripts/recovery_check.sh` lo demuestra con código que no importa nada de DateKeys, ni tlock ni drand. + +## Lo que el agente decidió distinto del diseño, para que lo apruebes o no + +8. **Un límite de tamaño del objeto: de 1 a 1024 bytes**, con `ERR_NON_CANONICAL_CBOR`. Así el código de error no depende de cuánto lea un lector. La firma, de 1 a 96 bytes en el CDDL; otra longitud dentro de ese rango da `ERR_RELEASE_INVALID`. + - Recomendación: aprobar. +9. **Un JSON de drand mal formado da `ERR_RELEASE_INVALID` en el paso 10.** Solo es una entrada de quien llama y nunca se escribe. + - Recomendación: aprobar. +10. **Los fallos del archivo de releases dan `ERR_RELEASE_UNAVAILABLE` en el paso 9.** Una ronda que el archivo no tiene o no cubre, de otra cadena, o con otra longitud. Una ronda a ceros cuenta como ausente, no como firma que no verifica. + - Recomendación: aprobar. El formato del archivo es informativo y no tiene códigos propios. +11. **Lo que no hace la CLI de Go:** + - la opción de pedir a la red antes de la fecha aunque el reloj diga que no ha llegado, que el spec deja como MAY; + - guardar el anexo junto a las cápsulas y avisar del release al sellar, que son SHOULD del SDK. + + Lo demás sí: `decrypt -release FICHERO`, `decrypt -save-release` y la orden nueva `datekeys release`, que pide, verifica y guarda el `.dkr`. + - Recomendación: aprobar. Los SHOULD del SDK van con las recomendaciones de la v0.14 en los clientes, que siguen pendientes. + +## Lo que cambia en los vectores + +- **`vectors/release.json`, nuevo:** 36 objetos, 12 JSON de drand y 7 consultas a un archivo, cada uno con su resultado y el texto de Go. +- **`releases/`, nuevo:** los `.dkr` de las rondas 1000, 1001, 1004 y 2000, y un archivo de las rondas 1000 a 1004 con la 1002 y la 1003 a ceros. +- **`mutations.json`:** + - cada caso dice ahora si su release está en la mano (`supplied`) o viene de la red (`network`); + - «la ronda aún no ha llegado» pasa a abrir con un release en la mano, por la opción B; + - hay cuatro casos nuevos: ese mismo caso desde la red, un release de otra ronda desde la red, y dos objetos de otra cadena. + + Son 222 casos, 178 del §64. Ningún otro cambia de resultado. + +## Al aprobar + +- Como la v0.14: la fecha de la cabecera, `SpecVersion` 0.15, el SHA-256, el tag `spec-v0.15` y `main`. +- TypeScript y Dart siguen el borrador: el objeto, la fuente en la mano, el paso 9.c, los vectores nuevos y el campo `source` del corpus. La guarda de TypeScript exige una prueba para cada fichero nuevo de `testdata`. +- El paquete de la revisión externa se pone al día con los commits nuevos y con la recuperación ya resuelta. +- Sale una `0.4.0` de TypeScript.