datekeys-doc/spec_v0.16/decisiones.md

Borrador v0.16: decisiones para el autor

7 de octubre de 2026. El borrador está en la rama v0.16 de datekeys-go (2c29625), en spec/DateKeys_Protocol_Specification_v0.16.md. Recoge la revisión de Astra de la v0.15, con la dirección acordada tras su segunda y su tercera respuesta: cinco hallazgos, todos comprobados contra el texto y el código. Todavía no hay código: SpecVersion sigue en 0.15, y el anexo que escribe la CLI es el de la v0.15.

Nota del 7-10 por la noche. El autor pidió implementarla («ponte con la implementación de la 0.16»), y se tomó como aprobación de las ocho decisiones con su recomendación. Está implementada en Go (7e3b810 a 3fd0e93), TypeScript (f79d8e2, 59d7607) y Dart (290d97e, 0609e9e), con los tres gates en verde. Falta cerrarla con su tag. La licencia quedó decidida: CC BY-ND 4.0, también en la cabecera del anexo (70d907b).

Si apruebas lo que sigue tal como está, basta con decir «apruebo el borrador». Después se implementa en Go, con sus vectores, y se lleva a TypeScript y a Dart. La versión se cierra con su tag cuando las tres pasen.

Lo que hace el borrador

1. El sello sin accuracy (§29.7, §29.11). Un sello válido solo acredita que es anterior a la fecha de apertura (S4) si su token lleva accuracy y t + precisión < round_time. Sin accuracy da S5, y S5 cambia de texto: «No acredita que se sellara antes de la fecha de apertura: ‹motivo›.» Hay tres motivos, que se comprueban en este orden:

   • «se selló después de esa fecha o demasiado cerca de ella»;
   • «el sello no dice la precisión que exige su política», si la política del token es la BTSP de ETSI (0.4.0.2023.1.1), que obliga a llevar accuracy;
   • «el sello no dice su precisión», en los demás casos.

   En F6, la línea de un firmante cuyo sello no lleva accuracy dice «sin acreditar que fuera antes de la fecha de apertura» y el motivo. El texto anterior de S5, «Sellado después de la fecha de apertura», era falso para un sello anterior a la fecha cuya precisión llegaba a ella.

2. La llave de palabras en el anexo (§79.7, nueva). El anexo trae la derivación entera: P, la sal, PBKDF2 con 600 000 iteraciones y dos vectores. La normalización va en dos niveles:

   • Sin tablas, exacta para el texto que dan las listas de DateKeys: ASCII; á, é, í, ó, ú, ü y ñ con sus mayúsculas; y las marcas de U+0300 a U+036F. Se quitan las marcas, cada letra con tilde pasa a su letra base, A a Z pasan a minúsculas y se parte por los espacios.
   • Completa para cualquier otro texto: NFD, quitar las marcas, minúscula simple y partir por los espacios. Usa UnicodeData.txt de Unicode 18.0.0, que el anexo nombra por su SHA-256 y su dirección en unicode.org.

   El segundo vector, «Ñandú», dos espacios, «PINGÜINO», un tabulador y «camión árbol Éter ola», da la misma llave que «nandu pinguino camion arbol eter ola» y que el mismo texto con las tildes escritas como marcas sueltas. La v0.16 renumera El contenido como 79.8 y Lo que el anexo no comprueba como 79.9.

3. El último bloque de age (79.5). «El último más corto» pasa a «el último puede ser más corto, o estar completo». Con 65 536 bytes de plaintext hay un solo bloque, completo y marcado como último. scripts/recovery ya lo hacía bien, pero ningún fixture lo comprobaba.

4. Las evidencias de la firma con certificado (§29.10, §62.1 reglas 21 y 22). El escritor SHOULD guardar:

   • la cadena de cada firmante, sin su raíz;
   • la de la autoridad de cada sello, sin su raíz;
   • las respuestas OCSP.

   Así se sustituye el «podar a un certificado por firmante» de la v0.15. Si algo no cabe, el escritor MUST decir qué deja fuera y SHOULD ofrecer exportarlo. Nunca deja fuera una firma, el certificado de un firmante ni su sello. §29.10 ya no promete la respuesta OCSP: promete lo que la cápsula conserva.

5. El JSON de drand, estricto (§47.1):

   • ningún objeto repite un nombre;
   • los nombres se comparan exactos tras decodificar sus escapes;
   • un sustituto suelto hace el JSON mal formado;
   • round es un entero sin signo de 1 a 2⁵³ − 1, sin fracción ni exponente.

   Lo demás es ERR_RELEASE_INVALID. Hoy las tres implementaciones leen como encoding/json de Go: el último de dos nombres repetidos gana, y ROUND vale como round. Comprobado: {"round":1000,"ROUND":1001,…} da la ronda 1001 en Go, y 1000 en un lector con JSON.parse o con el json de Python.

6. Erratas.

   • §1 junta en una línea la Release API, la Release Cache y el objeto release.
   • La lista de §74 acaba en punto.
   • §77 añade ETSI EN 319 421 y 319 422.
   • §79 nombra las interfaces de drand/kyber, que scripts/recovery también importa.
   • La cabecera ya no dice «prevista» de la implementación de referencia.

No cambia ningún formato. Cambian dos veredictos, el del sello sin accuracy y el de algunos JSON de drand, y §70 y §76 lo registran.

Decisiones

1. El sello sin accuracy acredita como S5, sin margen ni tabla de políticas. Es lo que pidió Astra: ningún margen fijo vale para toda TSA, y la precisión de una política solo la sabe quien la conoce. Una tabla de políticas con su precisión, para dar S4 a un sello sin accuracy, queda en §74 como trabajo futuro: habría que mantenerla en el spec y en las tres implementaciones.

   • Recomendación: aprobar.

2. Un motivo propio para un token BTSP sin accuracy. Cuesta comparar un OID, y dice algo útil: que la autoridad incumple su propia política, y no solo que el sello no basta. Las cláusulas están comprobadas en los textos de ETSI: EN 319 421 V1.3.1, §5.1 (1 s o mejor), §5.2 (el OID), TIS-7.7.1-01 (el perfil de EN 319 422) y TIS-7.7.2-03; y EN 319 422 V1.1.1, §5.2.2 («the accuracy field shall be present»).

   • Recomendación: aprobar.

3. El escritor MUST avisar de un sello sin accuracy (regla 19) y SHOULD ofrecer pedirlo a otra autoridad. No lo rechaza: el sello sigue probando que la firma existía en t. Hoy ningún escritor pide sellos, ni la CLI ni /create, así que la regla no cambia ningún código.

   • Recomendación: aprobar.

4. La receta sin tablas. Cubre las letras de las dos listas, el español y el inglés de la EFF, y cualquier ASCII. Una letra de fuera, como la ç catalana o la ß, ya necesita las tablas. Ampliarla a todo Latin-1 es posible, pero alarga el anexo con casos que las listas no dan.

   • Recomendación: aprobar como está.

5. Sin paquete de recuperación en el spec. Astra proponía nombrar en el anexo un paquete de recuperación por su versión, su SHA-256 y el SHA-256 de cada fichero. El borrador nombra solo UnicodeData.txt por su SHA-256. Sirve cualquier copia que lo cumpla, y unicode.org conserva todas sus versiones. Un paquete tiene dos problemas:

   • el anexo no puede dar el SHA-256 de un paquete que lo contiene;
   • necesita un sitio público donde alojarlo, y hoy no hay ninguno: el Gitea no es nuestro.

   Cuando haya sitio, el paquete puede llevar UnicodeData.txt, el código de scripts/recovery y las listas, y el anexo lo nombraría sin contenerse a sí mismo.

   • Recomendación: aprobar sin paquete, y añadirlo a §74 cuando haya sitio público.

6. Las evidencias, SHOULD guardar y MUST decir lo que falta. No es un MUST guardar las cadenas, porque pueden no caber ni en 64 KiB con varios firmantes. Los veredictos del lector no cambian: un certificado de más no decide nada. Ningún escritor firma hoy con certificados.

   • Recomendación: aprobar. La medida del área (§74, §75 punto 13) incluirá las cadenas sin la raíz.

7. La ronda del JSON de drand, de 1 a 2⁵³ − 1, como en el objeto release. La ronda 0 y las mayores pasan de ERR_ROUND_MISMATCH a ERR_RELEASE_INVALID. Así el JSON y el objeto tienen el mismo rango.

   • Recomendación: aprobar.

8. Los vectores de los sellos. En security_cms.json, once de los trece casos que dan S4 llevan un token sin accuracy, porque el generador no la escribe si es 0. Con la v0.16 darían S5, y algunos dejarían de probar lo que dicen. Por ejemplo, «an authority named with 50 spaces» prueba cómo se muestra el nombre de la autoridad, y S5 no lo muestra. La propuesta:

   • regenerar esos casos con una accuracy de 1 s, para que sigan en S4;
   • añadir los casos sin accuracy de §64: años antes de la fecha, de la política BTSP, después de la fecha y en alg 2;
   • añadir uno con una accuracy de 0 segundos.

   Los fixtures no cambian: format3_sealed y format3_signed_cms ya llevan accuracy.

   • Recomendación: aprobar.

Lo que queda para después

• La revisión externa. Su paquete sigue en la v0.15. Al cerrar la v0.16 se le añade este cambio, que responde a una revisión.
• La licencia del anexo. Decidida el 7-10: el spec es CC BY-ND 4.0, y la cabecera del anexo lo dice (70d907b).

Al aprobar

• SpecVersion 0.16, el SHA-256 en spec/README.md, el anexo regenerado con DATEKEYS_WRITE_ANNEX=1, el tag spec-v0.16 y main.
• En Go:
  • los veredictos y textos del sello;
  • el lector estricto del JSON de drand;
  • scripts/recovery con las palabras;
  • el fixture con un último bloque completo;
  • los vectores nuevos.
• TypeScript y Dart siguen a Go con los vectores sincronizados. En TypeScript, la guarda exige una prueba para cada fichero nuevo de testdata.