Resumen

  • Una respuesta Roughtime válida prueba la firma de una afirmación temporal acotada y la inclusión de la solicitud; no prueba que el reloj tuviera la hora correcta.
  • Un informe encadenado prueba el orden de las respuestas y que al menos un servidor se equivocó. La atribución, la aceptación del caso y la revocación siguen siendo decisiones separadas.

Hay tres servidores, tres firmas válidas y una secuencia que no puede existir tal como fue declarada. La evidencia elimina la explicación cómoda de que no hubo conflicto. Sin embargo, todavía permite varias explicaciones sobre quién lo causó.

Ese espacio entre contradicción y culpabilidad es el centro operativo de Roughtime revisión 19. El documento pertenece al grupo NTP, está destinado a publicación Experimental y figura en el proceso del RFC Editor, pero sigue siendo un Internet-Draft. La diferencia visible con la revisión 18 es principalmente editorial; no se atribuye a la revisión 19 una innovación normativa que no existe.

La firma autentica la afirmación

El cliente envía un nonce. El servidor incorpora la solicitud como hoja de un árbol de Merkle y firma una respuesta con MIDP, RADI y la raíz. Una clave temporal Ed25519 firma esa respuesta; la clave de largo plazo firma la delegación que contiene la clave temporal y los límites MINT y MAXT.

El cliente comprueba ambas firmas, la inclusión de su solicitud y que el punto medio esté dentro de la delegación. Superar esas pruebas produce una respuesta válida. El borrador aclara que válido no significa correcto: el servidor garantiza que firmó el valor dentro del intervalo (MIDP-RADI, MIDP+RADI). Una afirmación autenticada puede seguir describiendo mal la realidad.

La causalidad produce un expediente

El modo multiserver necesita una lista configurada con al menos tres servidores operativos administrados por partes distintas. El cliente los consulta en secuencia y repite el orden. Después del primer nonce aleatorio, cada solicitud enlaza la respuesta anterior con nueva aleatoriedad. La cadena impide reordenar las declaraciones sin romper la prueba.

Si las respuestas son válidas pero sus intervalos violan el orden causal, el borrador habla de malfeasance. El informe conserva las claves esperadas, los valores aleatorios, las solicitudes y las respuestas en el orden recibido. Puede demostrar que al menos un servidor dio una hora equivocada.

Pero una disyunción no es una identidad. Dos fuentes correlacionadas pueden coincidir y dejar aislada a la honesta. Por eso importan quién opera cada servidor, de dónde obtiene tiempo y quién controló la versión de la lista. La mayoría sólo es evidencia de independencia cuando esa independencia también está demostrada.

El veredicto vive fuera del paquete

Roughtime define formatos comunes para listas e informes, no la institución que admite servidores, acepta un reporte, atribuye responsabilidad, resuelve apelaciones o distribuye una revocación. Incluso la sugerencia de un foro de observadores humanos aparece como posibilidad, no como resultado automático. El propio borrador llama esenciales a la gestión de listas y a la adjudicación, aunque las deja fuera de alcance.

La base de datos operativa debe reflejar esa separación. Respuesta firmada, validez, par contradictorio, versión de lista, envío, revisión, atribución, revocación, propagación y reparación son estados distintos. Colapsarlos en «incidente confirmado» borra quién tomó la decisión con qué autoridad.

Tampoco basta con esperar a que expire una clave delegada. Si su secreto se compromete más tarde, puede usarse para firmar tiempos falsos retrodatados dentro del antiguo intervalo. La expiración limita la aceptación normal; no borra el riesgo histórico.

Roughtime puede ayudar a arrancar la validación de certificados o limitar mediciones NTP/PTP. No es sello de tiempo legal, orden total de transacciones, prueba de integridad del dispositivo ni recibo de trabajo real.