Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>main
parent
b037889158
commit
3c1934fad7
@ -0,0 +1,196 @@
|
||||
# Revisión de completitud del protocolo DateKeys v0.13
|
||||
|
||||
6 de octubre de 2026. Revisión interna asistida por IA, no una revisión externa. Actualiza la [del 29 de septiembre](REVISION_completitud_protocolo.md), hecha sobre la v0.8.2. Se contrasta con `spec/DateKeys_Protocol_Specification_v0.13.md` de `datekeys-go`, aprobada, con el tag `spec-v0.13`. Las secciones citadas (§) son las de la v0.13.
|
||||
|
||||
Contexto: hay tres implementaciones, Go (referencia), TypeScript (`datekeys-ts` 0.2.0) y Dart, y coinciden en los vectores compartidos de `datekeys-go/testdata`.
|
||||
|
||||
---
|
||||
|
||||
## 1. Veredicto en breve
|
||||
|
||||
Desde la v0.8.2 el protocolo ha crecido mucho y bien. De los ocho puntos de la revisión anterior, la firma y el lado del escritor están resueltos. El versionado y la lista de lo que no se garantiza, a medias. El riesgo del proveedor, la raíz de confianza, la recuperación a largo plazo y la revisión externa siguen igual: §74 los declara ahora trabajo futuro, lo que es honesto, pero no los cierra.
|
||||
|
||||
Lo nuevo está bien diseñado. Sus huecos son de medida (el área de 32 KiB, el perfil CMS) y de alcance del modelo de amenazas, no de criptografía.
|
||||
|
||||
---
|
||||
|
||||
## 2. Los ocho puntos de la revisión anterior
|
||||
|
||||
### 2.1 Versionado: qué se congela y cómo evoluciona
|
||||
|
||||
- **Pedía:** congelar el formato en bytes, una promesa de compatibilidad en §70, una regla de evolución, decidir `mlkem768x25519`, una tabla de estado en lugar de §74/§75 y quitar «prevista» de la cabecera.
|
||||
- **Ahora:**
|
||||
- §70 obliga a abrir todo objeto válido de los formatos 1, 2 y 3, cada uno con la semántica de su versión.
|
||||
- §22 y el cambio 1 de la v0.9 fijan la regla de evolución: un cambio de semántica exige un formato nuevo, y un lector anterior lo rechaza en el paso 2, sin red.
|
||||
- §74 da por cerrados la trama, los tres formatos, los 16 huecos, el relleno, el head, las rutas y las tablas de Unicode.
|
||||
- Pero §74 sigue dando por provisional el schema byte a byte de `PUBLIC_HEADER`, `CONTROL_CBOR` y `.dkk`, y los límites de campos.
|
||||
- El tipo de acceso post-cuántico pasa a trabajo futuro (§74), sin decidir.
|
||||
- §75 sigue siendo una lista sin estado ni evidencia, y la línea 8 sigue diciendo «Implementación de referencia prevista».
|
||||
- **Veredicto: en parte.** La compatibilidad hacia atrás y la regla de evolución están escritas y probadas. Falta congelar los schemas y decidir el acceso post-cuántico, que después de la v1.0 exigirá un formato nuevo.
|
||||
|
||||
### 2.2 El lado del escritor
|
||||
|
||||
- **Pedía:** una sección normativa de escritura con un orden que se pueda seguir, límites como MUST, `I_PAYLOAD` nueva de un CSPRNG, rechazar instantes pasados, autocomprobación, borrado y vectores de escritura.
|
||||
- **Ahora:**
|
||||
- §62.1 tiene 25 reglas.
|
||||
- La regla 7 resuelve el orden circular con un control provisional de la misma longitud.
|
||||
- La regla 5 pide la aleatoriedad de un CSPRNG y prohíbe reutilizar `I_PAYLOAD`.
|
||||
- Las reglas 11, 12 y 17 piden la autocomprobación (SHOULD) y la autodecodificación (MUST).
|
||||
- Los límites de §57 son MUST desde la v0.8.2.
|
||||
- Los fixtures se regeneran con semilla, y TypeScript y Dart escriben byte a byte como Go (HANDOFF).
|
||||
- **Veredicto: hecho.** Quedan dos matices:
|
||||
- la regla 2 solo rechaza un instante anterior al reloj local, y comparar con la última ronda publicada es MAY, así que con el reloj atrasado se puede sellar hacia una ronda ya publicada (la regla lo admite);
|
||||
- la autocomprobación no incluye una prueba tlock con un release conocido.
|
||||
|
||||
### 2.3 El riesgo del proveedor
|
||||
|
||||
- **Pedía:** reescribir §7.6, decir que una cápsula no tiene otra vía de apertura, unir §50 y §53, recomendar `time_and_key` para horizontes largos, dar estados a §71 y prometer que un perfil publicado no se retira.
|
||||
- **Ahora:**
|
||||
- §7.6 sigue siendo una sola frase.
|
||||
- §53 sigue hablando solo de *harvest now, decrypt later*.
|
||||
- §36.1 sigue presentando `time_and_key` como «una barrera adicional de acceso».
|
||||
- §71 sigue sin valores para «estado».
|
||||
- §74 lista «una nueva redacción del modelo de amenazas del proveedor (§7.6)» como trabajo futuro.
|
||||
- **Veredicto: pendiente.** Es el mayor riesgo real del sistema y sigue sin escribir. El cambio es de texto: no toca ningún formato.
|
||||
|
||||
### 2.4 Revisión externa y evidencia de independencia
|
||||
|
||||
- **Pedía:** una revisión criptográfica humana anotada en §76, etiquetar como interna la revisión hecha por agentes, un anexo de modelo de seguridad, una implementación hecha solo con el texto, la versión inglesa y una regla de precedencia entre el texto, el CDDL y `testdata/README.md`.
|
||||
- **Ahora:**
|
||||
- §75.10 sigue abierto.
|
||||
- §76 sigue llamando a las correcciones de la v0.8.2 «revisión formal e independiente».
|
||||
- Las revisiones de la v0.10 y la v0.11 son de Fable y Astra (`docs/spec_v0.10/revision_fable.md`, `docs/spec_v0.11/revision_fable_astra.md`). Los documentos no identifican a ningún revisor humano con nombre, alcance y fecha. No me consta qué es Astra.
|
||||
- Hay una tercera implementación, Dart, pero se hizo igual que la de TypeScript, con el código de Go a la vista. HANDOFF anota «Cosas de Go que Dart copia», incluidos textos de error equivocados.
|
||||
- No hay versión inglesa, ni anexo de modelo de seguridad, ni regla de precedencia.
|
||||
- **Veredicto: pendiente.** Tres implementaciones que coinciden prueban que el código es coherente, no que el texto baste para implementar.
|
||||
|
||||
### 2.5 Raíz de confianza y algoritmos de verificación
|
||||
|
||||
- **Pedía:** limitar §12.1 a `bls-unchained-g1-rfc9380`, escribir el mensaje de ronda, el DST, H3 y H4 con valores intermedios, citar RFC 9380 y ePrint 2023/189, y quitar «o una representación firmada equivalente» de §12.
|
||||
- **Ahora:**
|
||||
- El paso 11 de §63 escribe U ‖ V ‖ W, las fórmulas de sigma, `FK_TIME` y r, las etiquetas IBE-H2/H3/H4 y el orden de GT. §12.2 fija la codificación canónica de los puntos.
|
||||
- Pero el paso 10 sigue verificando «según el scheme de drand», sin el mensaje ni el DST.
|
||||
- H3 y H4 siguen siendo «las de drand/kyber», sin su iteración ni su máscara.
|
||||
- §12.1 sigue admitiendo tres schemes.
|
||||
- §12 conserva la «representación firmada equivalente».
|
||||
- §77 no cita RFC 9380 ni ePrint 2023/189.
|
||||
- **Veredicto: pendiente.** Lo escrito desde entonces es bueno, pero lo que pedía este punto no está. Sigue haciendo falta leer kyber para verificar un release.
|
||||
|
||||
### 2.6 Recuperación a largo plazo
|
||||
|
||||
- **Pedía:**
|
||||
- un objeto release canónico;
|
||||
- el release desde fichero como fuente en §49;
|
||||
- guardar el release junto a la cápsula;
|
||||
- no aplicar el paso 9.c a un release suministrado;
|
||||
- un anexo de recuperación sin software DateKeys;
|
||||
- un archivo de Quicknet.
|
||||
- **Ahora:**
|
||||
- §45 a §50 no cambian, y §47 sigue con `release_material` sin definir.
|
||||
- §74 lista como trabajo futuro «el formato de un objeto de release y de su fuente de archivo» y «el uso del reloj local en el paso 9.c».
|
||||
- No hay anexo de recuperación.
|
||||
- El localizador (§44.1) ayuda a encontrar el `.dkc`, no el release.
|
||||
- **Veredicto: pendiente.** Está reconocido, pero una cápsula a veinte años sigue dependiendo de que alguien sirva una ronda concreta, y el reloj local aún puede vetar un release válido.
|
||||
|
||||
### 2.7 Escribir lo que no garantiza
|
||||
|
||||
- **Pedía** cuatro cosas:
|
||||
- (a) decir que nadie puede comprobar antes de la fecha que la cápsula se abrirá;
|
||||
- (b) listar los metadatos visibles;
|
||||
- (c) contar con un cliente web malicioso;
|
||||
- (d) añadir no-objetivos: caducidad, condiciones por evento, cancelación.
|
||||
- **Ahora:**
|
||||
- (b) está muy bien resuelto: §55.2 enumera lo visible, lo oculto y lo que nunca se ve, con los formatos 2 y 3 ocultando la longitud exacta y el número de credenciales.
|
||||
- (a) no está en §5.
|
||||
- (c) no está: §7.1 y §59 no hablan del cliente web, de SRI ni de builds publicadas.
|
||||
- (d) no está en §5.
|
||||
- **Veredicto: en parte.** Lo más delicado es (a): en pujas o predicciones, un creador puede sellar una cápsula que no se abrirá, y el texto no lo dice.
|
||||
|
||||
### 2.8 Firma del creador y `.dkk` protegida
|
||||
|
||||
- **Pedía:** una firma con etiqueta de dominio que cubra el control, el payload y las extensiones, mutaciones de firma quitada y trasplantada, una `.dkk` protegida con contraseña y un valor de comprobación, y reservar el prefijo `datekeys.`.
|
||||
- **Ahora:**
|
||||
- La firma existe, y mejor de lo propuesto. Va en el área `security` del formato 3, cifrada hasta la fecha (§29.2, §55.2).
|
||||
- Cubre `control_commit`, `head_digest` (y con él cada fichero) y `signers_digest`, con prefijos de dominio (§29.8).
|
||||
- Admite Ed25519 estricto (§29.9) y CMS con certificados (§29.10), con un sello RFC 3161 (§29.11).
|
||||
- §29.10 y §36.1 dicen que se puede quitar tras la apertura.
|
||||
- La `.dkk`, en cambio, sigue siendo 32 bytes crudos sin MAC (§38, §55.1). No hay forma protegida ni valor de comprobación.
|
||||
- El prefijo `datekeys.` se usa (§72), pero no se reserva.
|
||||
- **Veredicto: en parte.** La firma está hecha. La `.dkk` sigue sin protección; la llave de palabras (§38.1) mitiga su pérdida, no su corrupción.
|
||||
|
||||
---
|
||||
|
||||
## 3. Huecos nuevos, por orden de importancia
|
||||
|
||||
### 3.1 El área de 32 KiB y el perfil CMS siguen sin medir
|
||||
|
||||
- **Estado:** §74 declara provisionales los 32 KiB del área y la tabla de algoritmos y el perfil del certificado de §29.10, «hasta probarlos con firmas y sellos reales de varios países». §75.13 lo hace requisito bloqueante. Según HANDOFF, la v0.12 se aprobó sin esa medida, y `datekeys-ts` 0.2.0 ya escribe cápsulas con ese área.
|
||||
- **Por qué importa:**
|
||||
- Si el área cambia, los lectores siguen abriendo (§29.2), pero P delata la versión del escritor (§55.2).
|
||||
- Si la tabla de algoritmos cambia, una firma con brainpool, que §29.10 reconoce en «algunas tarjetas europeas», da F5 («no verificable») en todos los lectores anteriores.
|
||||
- El lector CMS es la mayor superficie de análisis del protocolo: DER, X.509, RSA-PSS y ECDSA leídos campo a campo, con código propio en cada lenguaje. El cambio 4 de la v0.12 encontró unos 1 600 certificados con veredictos distintos entre Go y TypeScript.
|
||||
- **Qué falta:** medir con firmas CAdES y sellos reales, con el criterio que ya fija §74, y que la revisión externa cubra el lector CMS.
|
||||
|
||||
### 3.2 El modelo cuántico no cubre la firma ni el sello
|
||||
|
||||
- **Estado:** §7.7 y §53 hablan del timelock, y §55.2 de los recipients X25519. Ed25519, RSA y ECDSA (§29.9, §29.10) tampoco son post-cuánticos, igual que la firma de la TSA.
|
||||
- **Por qué importa:** en una cápsula a décadas, un adversario cuántico podría fabricar, tras la fecha, una firma y un sello anteriores a la ronda (S4), sobre todo en `time_only`, que cualquiera puede rehacer (§36.1). Los resellados de archivo (RFC 4998) quedan fuera de la cápsula (§29.11).
|
||||
- **Qué falta:** una frase en §7.7 y en §29.7 que limite lo que prueban F3, F6 y S4 en horizontes largos. No hace falta cambiar ningún formato.
|
||||
|
||||
### 3.3 La llave de palabras depende de palabras humanas sin un mínimo de entropía
|
||||
|
||||
- **Estado:** §38.1 exige 6 palabras y recomienda (SHOULD) contar solo las distintas de 3 o más caracteres, y unas al azar. La derivación es PBKDF2-HMAC-SHA256 con 600 000 iteraciones, con `capsule_id` en la sal. El propio texto avisa de que, tras la fecha, cualquiera con el `.dkc` puede probar palabras sin conexión.
|
||||
- **Por qué importa:** en `time_and_key`, la cápsula es tan fuerte como su credencial más débil. Seis palabras elegidas por una persona pueden tener poca entropía, y PBKDF2 no es costosa en memoria.
|
||||
- **Qué falta:** una decisión del autor:
|
||||
- una cota de entropía, o palabras generadas por defecto, como SHOULD del SDK oficial;
|
||||
- o decir en §38.1 que la llave de palabras no es adecuada para contenidos valiosos.
|
||||
|
||||
Cambiar de KDF exige una dependencia nueva, con la regla de aprobación del proyecto, o código propio.
|
||||
- La sal por cápsula está bien resuelta.
|
||||
|
||||
### 3.4 Tres formatos de lectura obligatoria para siempre
|
||||
|
||||
- **Estado:** §70 obliga a todo lector V1 a abrir los formatos 1, 2 y 3, con semánticas distintas, y §62.1 prohíbe escribir los dos primeros.
|
||||
- **Por qué importa:** cada formato suma casos a §64, §67 y §69.1, y la v1.0 es el último momento barato para decidir si los formatos 1 y 2 siguen siendo MUST o pasan a MAY. No sé si circulan cápsulas reales de esos formatos: los documentos no lo dicen.
|
||||
- **Qué falta:** una decisión del autor, no un cambio técnico.
|
||||
|
||||
### 3.5 El localizador y el sobre: bien, con dos notas
|
||||
|
||||
- **Bien resuelto (§44.1):** el resto del sobre no se distingue del azar, nadie lee el localizador antes de la fecha, las direcciones se leen sin decodificar, la IP se comprueba en cada conexión y los dos digests antes de usar nada. El cambio NAT64 de la v0.13 cuenta solo la IPv4 de dentro, así que una dirección sigue sin poder llevar a la red local.
|
||||
- **Nota 1:** el localizador no está autenticado frente a quien escribió la `.dkk` (§44.1, §72). El texto lo dice, y está bien así.
|
||||
- **Nota 2:** la disponibilidad del resto depende de un tercero durante años, como la del `.dkc`. §44.1 lo avisa como SHOULD del escritor. Sería útil enlazarlo con §50, porque es la misma dependencia de largo plazo.
|
||||
|
||||
### 3.6 La nota pública: bien
|
||||
|
||||
§24.1 la trata como texto del creador sin comprobar, con aviso obligatorio antes de la fecha y sin enlaces. La ata el paso 15 y una firma la cubre. Avisa del riesgo de identificar a alguien. No veo hueco.
|
||||
|
||||
### 3.7 Firma y sello: el diseño es sólido
|
||||
|
||||
Lo firmado no depende del área ni de L (§29.8), la lista de firmantes exigidos impide retirar cofirmantes sin rastro, los veredictos nunca deciden la apertura (§29.7) y §7.9 enumera la equivocación, la coacción y la clave robada. Solo quedan 3.1 y 3.2.
|
||||
|
||||
### 3.8 Orden y erratas del texto
|
||||
|
||||
- En §76, el bloque de la v0.13 va antes que el de la v0.12.
|
||||
- §76 se sigue titulando «Política de cambios del borrador v0.8.1».
|
||||
- La segunda lista de §74 termina en punto y coma.
|
||||
- §1 dice que el documento define la Release API y la Release Cache, que §45 a §47 apenas esbozan.
|
||||
|
||||
Son menores, pero un revisor externo las verá primero.
|
||||
|
||||
---
|
||||
|
||||
## 4. Las tres cosas siguientes antes de la v1.0
|
||||
|
||||
1. **Medir el área y cerrar el perfil CMS** (§74, §75.13): firmas CAdES de varios países, sellos de dos TSA cualificadas y respuestas OCSP reales.
|
||||
- Necesita: **una parte externa** (certificados y TSA reales), **un cambio del spec** si la medida mueve el área o la tabla, y **código** en las tres implementaciones.
|
||||
- El criterio de decisión ya está escrito en §74.
|
||||
2. **Una versión de texto que escriba lo que falta**, sin tocar formatos:
|
||||
- §7.6 y §71, con los estados de perfil;
|
||||
- §5, con la verificación previa imposible, el cliente web y los no-objetivos;
|
||||
- §7.7, con firma y sello;
|
||||
- el mensaje, el DST y H3/H4 en el paso 10 y el 11, con §12.1 limitado a un scheme;
|
||||
- el objeto release y el paso 9.c, o su paso explícito a un anexo informativo.
|
||||
- Necesita: **decisiones del autor** (un scheme, los estados de perfil, el destino de la Release API) y **un cambio del spec**. La raíz de confianza y el release exigen además **código** y vectores.
|
||||
3. **Revisión criptográfica externa humana** (§75.10), sobre el núcleo tlock, el formato 3 y el lector CMS, con revisor, alcance y fecha anotados en §76.
|
||||
- Antes conviene congelar los schemas de §74, corregir en §76 la etiqueta «revisión formal e independiente», declarar el idioma normativo y la precedencia entre texto, CDDL y `testdata/README.md`, y preparar la traducción al inglés.
|
||||
- Necesita: **una parte externa** y **decisiones del autor** (qué se congela y el idioma).
|
||||
Loading…
Reference in new issue