Resumen

  • Wathīqa propone renovar una evidencia mediante una secuencia de firmas: cada eslabón protege la misma dirección de contenido y se compromete con el hash canónico del anterior.
  • El recibo de inclusión de un registro de transparencia sirve como evidencia autenticada de «no después de»; el ancla de una baliza de aleatoriedad pretende aportar «no antes de», pero el verificador actual no comprueba la prueba de la baliza.
  • Las comprobaciones del testigo solo se exigen cuando quien llama aporta el conjunto de claves confiables W. Si no lo hace, la validación obligatoria se limita al contenido, las firmas y los enlaces entre eslabones.
  • Es un Internet-Draft individual que aspira a Experimental, no una norma ni una decisión del IETF. El texto reconoce que su argumento de seguridad no ha recibido revisión criptográfica independiente.
  • Los operadores necesitan resultados distintos para la cadena criptográfica, el límite superior bajo una lista de testigos concreta, el límite inferior aún no verificado y la decisión local de aceptar o renovar.

La evidencia envejece antes que los bytes

Los documentos archivados no cambian, pero la valoración de sus algoritmos sí. Una firma que hoy resulta costosa de falsificar puede dejar de serlo. El problema de una renovación tardía es lógico: si el algoritmo anterior ya no era fiable cuando se añadió el nuevo eslabón, la firma reciente no puede determinar cuál de varias historias antiguas era auténtica.

El RFC 4998 aborda desde 2007 la renovación de registros de evidencia. Ordena obtener un nuevo sello antes de que se debiliten los algoritmos usados o pierdan validez los certificados de sellado. También admite que la información sobre debilidad, compromiso y vida útil procede de fuera del formato. Ninguna estructura ASN.1 puede decidir por sí sola el día en que un riesgo científico cruza el umbral de una organización.

El borrador Wathīqa añade agilidad de firmas a esa idea. Una dirección de contenido representa los datos preservados. El primer eslabón firma esa dirección; los siguientes vuelven a firmarla con un algoritmo declarado y enlazan el hash canónico del eslabón precedente. El texto cita ML-DSA y SLH-DSA, normalizados por FIPS 204 y FIPS 205. Son estándares de algoritmos, no un sello de seguridad para Wathīqa ni un calendario de migración.

Un «a más tardar» condicionado y un «no antes» declarado

Para acotar el tiempo, la propuesta combina dos pruebas con cometidos diferentes. La primera es un recibo de inclusión en un registro de transparencia. La firma del eslabón aparece como hoja de un árbol; un camino de Merkle la conecta con una cabecera firmada. Bajo una clave de registro aceptada, el recibo muestra que esa firma ya estaba incluida cuando se emitió la cabecera. Es evidencia de un máximo temporal. Los mecanismos de inclusión y consistencia remiten a las ideas del RFC 6962.

El segundo mecanismo mira en la dirección opuesta. Una salida pública e imprevisible de una baliza puede demostrar que un mensaje comprometido con ella no se construyó antes de que la salida existiera. La NIST Randomness Beacon 2.0 publica pulsos numerados, fechados, firmados y encadenados; la página de NIST aún describe esa versión como beta y en desarrollo.

Wathīqa guarda en cada eslabón datos de uno de esos pulsos. Sin embargo, la revisión 00 no verifica la firma ni la prueba del pulso. Comprueba una igualdad hash que mantiene unida el ancla al material de firma, pero esa igualdad no demuestra que la baliza emitiera el valor. La sección de seguridad señala que un adversario puede rellenar el ancla con metadatos arbitrarios y prohíbe tratarla como tiempo autenticado.

La distinción es más importante que la etiqueta «poscuántico». El eslabón puede estar firmado con un algoritmo moderno y contener, dentro de lo firmado, una afirmación temporal falsa. La firma protege la afirmación contra modificaciones posteriores; no transforma su fuente en una autoridad.

El parámetro W divide dos modos de validación

La prueba superior tampoco surge de la mera presencia del recibo. El algoritmo de verificación acepta opcionalmente W, un conjunto de claves públicas de testigos que la parte verificadora considera confiables. Solo cuando W está presente exige un recibo para cada eslabón, verifica la firma de la cabecera con una de esas claves y comprueba que los tiempos no retrocedan.

Si W no se proporciona, el proceso sigue comprobando la dirección del contenido, cada firma y cada enlace hash. El borrador permite aceptar cuando esos controles pasan. Por tanto, la misma palabra «aceptado» puede describir una cadena sin testigo temporal o una cadena cuyo límite superior se verificó bajo una lista determinada.

Esto no es una sutileza reservada a los implementadores. Un auditor podría recibir un icono verde sin saber si el cliente omitió W. Dos organizaciones podrían intercambiar el mismo archivo y creer que comparten la misma conclusión cuando en realidad usan listas de testigos distintas. Un registro de transparencia podría rotar su clave; una parte conservaría la sucesión y otra no. La portabilidad del documento no garantiza la portabilidad de la política que le da sentido.

La revisión 00 recomienda una sucesión de claves autorizada por cuórum, mantenida de forma append-only y fijada a un ancla duradera. Es una dirección plausible, no un régimen operativo completo. Quedan abiertas la composición del cuórum, la respuesta a una clave comprometida, la continuidad del operador y la detección de historias divergentes.

El estado institucional y la prueba de implementación

Según el Datatracker, el documento es un Internet-Draft individual sin flujo RFC. Lleva fecha de 3 de septiembre de 2026, pretende ser Experimental y caduca el 7 de marzo de 2027. El anuncio público del 5 de septiembre demuestra que la revisión 00 fue distribuida; no demuestra adopción por un grupo de trabajo ni consenso del IETF.

El autor afirma disponer de una implementación completa en Python y de verificadores en JavaScript y Rust que reproducen el mismo hash canónico mediante vectores compartidos. En el mismo texto reconoce que el argumento de seguridad no ha sido revisado de forma criptográfica e independiente. El borrador no enlaza un repositorio ni fija un commit, de modo que este artículo no pudo repetir esa comprobación.

También hay una discordancia que afecta al objeto que habría que implementar. La sección 4.3 llama versión 3 al perfil ASN.1 DER envuelto y remite el módulo detallado a un archivo Python externo que considera autoritativo hasta una revisión futura. El apéndice B habla de perfil DER versión 4, dice que las versiones 1 a 3 siguen siendo decodificables y que solo se emite la 4. El RFC 9169 mantiene los módulos ASN.1 de ERS en una referencia publicada, pero no resuelve esta divergencia de la extensión.

Es probable que se trate de una edición incompleta del primer borrador. No es evidencia de una vulnerabilidad ni de un fallo de código. Sí impide congelar una prueba de interoperabilidad: no queda claro qué versión exacta debe producirse, y el supuesto archivo autoritativo no está identificado. Los dos tipos MIME propuestos también figuran como pendientes de un trámite de IANA aún no iniciado.

Verificar la cadena no equivale a verificar el tiempo entero

La contribución real del borrador consiste en separar piezas que a menudo se resumen demasiado. La dirección del contenido responde si se conserva el mismo objeto. Las firmas responden si cada mensaje verifica bajo su clave. Los hashes de predecesores responden si se mantiene el orden declarado. Un recibo aceptado bajo W añade un límite superior. El ancla actual conserva material para un futuro límite inferior, pero todavía no lo autentica.

Fuera de esas piezas quedan las decisiones sobre la vida útil de los algoritmos, la autoridad que emite alertas, la lista de testigos, la gobernanza de sus rotaciones y el momento de renovar. Son decisiones legítimamente locales. Deben quedar asociadas al resultado para que una parte no venda su política como propiedad universal del registro.

El borrador no necesita prometer una certeza total. Le basta con hacer portable aquello que puede verificarse y declarar con precisión lo que depende del operador. Su propia advertencia sobre la baliza ya da el primer paso.