datekeys-doc/spec_v0.10/revision_fable.md

Revisión de seguridad de Fable (30-09-2026)

Revisión externa del paquete formato3_para_revision.md, copiada tal como la pasó el autor.

He leído formato3_para_revision.md entero y contrastado algunas afirmaciones con el código. Mi opinión:

Veredicto

El formato está bien diseñado; el servicio de sellado aún no es revisable. La parte criptográfica (qué se firma, qué se sella, los compromisos) no le encuentro ataque. Los problemas están en los bordes: el origen del servicio, los caracteres invisibles y la vida del sello a décadas.

Comprobado por mí:

• Toda la aritmética de tamaños cuadra (22/128/175/281, 53, 45, 146, L = 573 → P = 768, L = 1637 → P = 1792).
• noble 2.4.0 usa la ecuación con cofactor siempre (edwards.js:659), así que el verificador propio es necesario, no un capricho.
• Go trae Unicode 15.0.0 y Node 24.9 el 16.0, como dice el documento.

Hallazgos, por gravedad

#	Gravedad	Problema	Arreglo
1	Mayor	Mismo origen (decisión 5). Hoy el sitio es estático y el CSP va en <meta>. Un documento servido bajo /seal/* no lleva CSP y corre en el origen que maneja plaintexts, .dkk y claves de autor	Origen aparte (seal.…), o cabeceras forzadas en el proxy: nosniff, octet-stream, CSP: sandbox
2	Mayor	Caracteres invisibles en rutas. R4 deja pasar U+206A–206F, y ZWJ/ZWNJ están permitidos: HFS+ los ignora al comparar, así que «a‌b» y «ab» colisionan. Los tags U+E0020–E007F permiten nombres visualmente idénticos	R4 por propiedad (Default_Ignorable_Code_Point) con lista blanca; la clave de R7 descarta lo permitido
3	Mayor	El sello no sobrevive a DateKeys. La auditoría depende de que el registro siga publicado dentro de décadas, y el perfil anual obliga a actualizar cada lector cada año	Fichero aparte con prueba de inclusión, checkpoint y .ots; raíz offline ahora, no «más adelante»
4	Mayor	Abuso frente a «sin registros». El registro solo crece y el POST es anónimo; limitar por IP exige guardar IPs	Definirlo: estado solo en memoria, o prueba de trabajo con SHA-256
5	Menor	El área depende de SECURITY_LEN. Un sello futuro de más de 512 bytes cambia L y delata su presencia por P	Área fija mayor, o longitud propia en la trama
6	Menor	Orden de rutas en TypeScript. Comparar strings ordena por UTF-16, no por bytes: U+FF5E y un emoji salen al revés que en Go	Vector en paths.json
7	Menor	Suplantación en la CLI. Una línea de comentario rellena de espacios salta de renglón y el falso veredicto aparece sin el prefijo │	Repetir los veredictos al final, o partir líneas en la CLI
8	Menor	A1 y el tráfico. La página no hace ninguna petición hoy; un POST delata el sello	Declararlo como fuga aceptada
9	Menor	Ambigüedades: si una firma ilegible invalida también el sello; R6b con «~1» a secas y qué cuenta como carácter; mtime negativa	Tabla de verdad, expresión regular, regla de omisión
10	Menor	control_commit y head_digest sin prefijo de dominio; el directorio .datekeys-* puede coincidir con una entrada	Prefijo; reservar ese nombre

Sobre el documento

• Las 28 objeciones son 24: la 12, 16, 18 y 24 repiten otras. Y varias no están «corregidas» sino aceptadas (2, 9, 23). Un revisor agradece la distinción.
• Faltan definiciones para alguien de fuera: «capa 2/3/4», las referencias a § del spec, el valor de L_MAX (2⁵³ − 2⁴⁶) y para qué sirve la sal del head.
• Hay tres ficheros con el mismo texto. para_revision es la suma exacta de los otros dos; cualquier corrección hay que hacerla dos veces.
• El sello sin perfil conocido no muestra nada. Mejor un texto que diga que hay un sello y que el lector es antiguo.

Recomendación

Separar en tres entregas, con el formato congelado desde la primera y security vacío:

1. Contenedor y rutas.
2. Firma y claves de autor.
3. Sello, cuando exista su documento propio («Servicio de sellado v1»), con custodia de clave, monitores y hosting.

Los hallazgos 1, 3 y 4 son del servicio, no del formato, y no deberían frenar lo demás. El 2 y el 6 sí conviene cerrarlos antes de escribir el texto del spec.

No he revisado aún a fondo el ZIP byte a byte ni he probado el comportamiento de HFS+ en una máquina; lo de HFS+ lo afirmo por la lista que usa git en core.protectHFS.