Resumen
- La firma de un sello de tiempo prueba una declaración delimitada sobre una huella, una hora, una política y una clave; no prueba que la autoridad cumpliera todos sus controles operativos.
- La RFC 3628 exigía detectar la pérdida de sincronización, parar la emisión, proteger una única clave activa por unidad, registrar operaciones y revelar incidentes. La ETSI EN 319 421 V1.3.1 conserva esa arquitectura.
- El recibo útil enlaza cada token con la versión de política y prácticas, la trazabilidad UTC(k), la historia de clave y reloj, el intervalo afectado y la decisión actual de confianza.
El minuto en que el servicio debe ponerse rojo
Una plataforma puede tolerar muchos errores sin perder de inmediato su autoridad. La autoridad de sellado de tiempo no puede tolerar uno concreto: seguir produciendo tiempo confiable cuando su reloj ha salido de la exactitud que promete. La RFC 3628 pedía que la desviación o el salto fueran detectados y prohibía emitir nuevos tokens una vez detectado el incumplimiento.
La ETSI EN 319 421 V1.3.1, adoptada en 2025, mantiene la misma cadena. La unidad debe proteger su reloj frente a cambios no detectados, conservar su calibración, detectar saltos o deriva, detener la emisión y no reanudarla hasta recuperarse. También debe registrar sincronizaciones normales y pérdidas de sincronización.
Por eso el indicador importante no es sólo “hora correcta ahora”. Hace falta saber la última calibración sana, el primer signo de desviación, el instante de detección, el momento en que cesó la emisión, el rango de series producido durante la incertidumbre y la evidencia que autorizó la vuelta. La recuperación sin ese intervalo repara el servicio y destruye la explicación.
Un token no contiene la sala de máquinas
La RFC 3161 define una respuesta rigurosa. messageImprint repite la huella pedida; el número de serie identifica de forma única el token para esa TSA; genTime declara cuándo lo creó; el campo de política identifica las reglas; el nonce, cuando existe en la petición, debe volver intacto. La firma liga el resultado a una clave y RFC 5816 actualiza la identificación del certificado con ESSCertIDv2.
Nada de eso introduce en el ASN.1 la topología de fuentes de tiempo, la calibración, el control dual de la clave, el registro de acceso físico o el acta de recuperación. El token puede ser perfectamente coherente consigo mismo y, aun así, carecer de evidencia accesible sobre la operación que lo produjo.
La proposición de RFC 3161 también es más pequeña de lo que suele venderse: el dato representado por la huella existía antes de un tiempo. No demuestra que fuera verdadero, que su autor fuera quien afirma ser, que la firma del documento naciera exactamente en genTime, que un trámite se recibiera antes de un plazo o que una aplicación aceptara la operación.
La exactitud impone otro límite. Sumarla y restarla de genTime produce un intervalo. Sin ordering=true, dos sellos sólo se pueden ordenar por sus horas si la distancia supera la suma de ambos márgenes. Una cifra temporal no es automáticamente una secuencia causal.
La política no ejecuta la práctica
La RFC 3628 es Informational y procede de una especificación ETSI de 2002. No debe presentarse como norma jurídica actual. Su distinción, sin embargo, sigue viva: la política declara qué debe cumplirse y la declaración de prácticas explica cómo una TSA concreta lo cumple.
El OID de política dentro del token es un nombre. No entrega la versión de prácticas aplicable, los procedimientos internos, el proveedor de tiempo, la ceremonia de claves o los límites de uso. La propia RFC permitía afirmar conformidad aportando evidencia bajo petición o mediante evaluación independiente. La conformidad se apoyaba en un expediente fuera del sello.
Tampoco desaparece la responsabilidad por contratar a terceros. La TSA puede externalizar componentes, incluso la generación, pero conserva la responsabilidad general y debe describir las prácticas relevantes. El contrato operativo forma parte del sistema de confianza aunque no cambie un bit del token.
UTC(k) es una relación medida
La hora tenía que ser trazable a un valor real distribuido por al menos un laboratorio UTC(k). Los institutos mantienen realizaciones locales en tiempo real; el BIPM calcula UTC y publica en Circular T las diferencias respecto de UTC(k). Esa publicación mensual es la fuente definitiva de trazabilidad.
UTCr ofrece información semanal para supervisión operativa. Su rapidez ayuda a gobernar un reloj antes de que llegue el resultado definitivo, pero el BIPM aclara que no sustituye ni a UTC ni a la trazabilidad de Circular T. Una señal temprana no debe ascender silenciosamente a prueba final.
La Z de genTime no identifica el laboratorio, la ruta de distribución, el desplazamiento medido, la incertidumbre, la edad de sincronización o el estado de holdover. Firmar la notación no firma la historia metrológica.
Incluso las referencias envejecen. La RFC 3628 citó TF.460-5; hoy esa versión está superada y TF.460-6 sigue vigente. La norma ETSI actual corrigió la dependencia. Una cadena de confianza necesita versiones, no nombres sin fecha.
La segunda intercalar es una prueba de transición
La política histórica exigía mantener la sincronización cuando se produjera una segunda intercalar notificada y registrar el instante exacto del cambio dentro de la exactitud declarada. La norma actual conserva esa obligación. El interés no está en debatir si habrá futuras segundas intercalares, sino en ver qué tipo de evidencia requiere un cambio conocido de escala.
Un reloj que parece correcto después no demuestra que el ajuste se aplicó en la ventana correcta ni que no se emitieron sellos ambiguos. El evento necesita anuncio recibido, versión de configuración, instante de aplicación, observación posterior y correspondencia con las series emitidas.
La transición revela un principio general: el estado final puede ser idéntico después de un cambio correcto y después de un error corregido. Sólo el registro del trayecto los distingue.
Una TSU, una clave activa
La RFC define la unidad de sellado como hardware y software administrados juntos con una sola clave activa de firma de sellos cada vez. Una TSA puede tener varias unidades identificables. La norma ETSI vigente conserva el límite de una clave y añade generación bajo control dual, dispositivo criptográfico seguro, finalidad exclusiva y rechazo cuando caduca la vida operativa de la clave privada.
Validar el certificado no prueba esos controles. El certificado enlaza una clave pública y una identidad; no acredita que no hubiera otra clave activa, que la copia de seguridad se protegiera, que el doble control se ejerciera o que la clave privada no hubiera rebasado su vencimiento interno.
La separación entre sellos cualificados y no cualificados es también operacional. La norma exige unidades, identidades de certificado y puntos de acceso diferenciados para ciertos servicios. Una misma infraestructura física puede alojarlos, pero su evidencia lógica no debe mezclarse.
Un aviso sin rango deja toda la historia en duda
Ante compromiso, sospecha de compromiso o pérdida de calibración, RFC 3628 pedía informar, suspender la emisión hasta recuperarse y facilitar datos que permitieran identificar los tokens afectados. ETSI mantiene el patrón. Los registros de clave, certificado y reloj proporcionan los bordes necesarios.
El comunicado “hemos resuelto un incidente” no basta. Debe poder asociarse a TSU, certificado, comienzo estimado, última observación sana, detección, parada, recuperación y rango de series o tiempo. La privacidad puede limitar lo publicado, pero no elimina la necesidad de una clasificación utilizable por quien confía.
Una pista de auditoría puede separar tokens auténticos de falsos retrodatados después de robar una clave. Dos autoridades pueden añadir independencia. Si comparten laboratorio, plataforma o detector, esa independencia debe demostrarse, no contarse por firmas.
La cualificación se decide fuera del token
El Reglamento (UE) nº 910/2014 concede a un sello cualificado presunción de exactitud de fecha y hora y de integridad de los datos ligados. El Reglamento de Ejecución (UE) 2025/1929 incorporó ETSI EN 319 421 V1.3.1 y EN 319 422 V1.1.1, con adaptaciones, como ruta de referencia para presumir conformidad.
Eso no convierte una extensión en juez de sí misma. ETSI indica que la declaración cualificada dentro del sello sólo señala una pretensión; la parte que confía debe usar la lista de confianza aplicable para establecer el estatus. El supervisor, la evaluación, la lista y su instante son otra capa de evidencia.
Las adaptaciones de 2025 añaden requisitos concretos de certificación criptográfica, formación, escaneo, pruebas de penetración, HTTPS y terminación. El token no incluye el informe trimestral ni la prueba anual. Cuanto más valor jurídico se derive del sello, menos aceptable resulta confundir el indicador con el expediente.
Verificar mañana exige más que guardar hoy
La RFC 3628 señalaba que un token válido puede dejar de ser verificable. Mientras vive el certificado de la TSU, se consulta su estado de revocación actual. Después, la CA puede dejar de garantizar esa información. Además, una función hash puede sufrir colisiones y una firma puede perder resistencia.
Su anexo C exige conocer que la clave no fue comprometida hasta la verificación, que el hash sigue siendo seguro y que la firma continúa fuera del alcance. Si no, hay que aplicar medidas de preservación, como un nuevo sello que proteja el anterior.
El expediente duradero combina bytes exactos, política y prácticas versionadas, certificados y estado, prueba UTC(k), ciclos de clave y reloj, incidentes, lista de confianza, evaluación algorítmica y preservaciones sucesivas. No centraliza la autoridad; mantiene separadas las afirmaciones que, juntas, justifican confiar.
Fuentes
- RFC 3628 — requisitos de política para autoridades de sellado de tiempo
- Texto plano de RFC 3628
- Información RFC Editor de RFC 3628
- Registro Datatracker de RFC 3628
- Búsqueda de erratas de RFC 3628
- RFC 3161 — protocolo de sellado de tiempo
- Información RFC Editor de RFC 3161
- Registro Datatracker de RFC 3161
- RFC 3161 con erratas incorporadas
- RFC 5816 — actualización ESSCertIDv2
- Información RFC Editor de RFC 5816
- Registro Datatracker de RFC 5816
- ETSI EN 319 421 V1.3.1
- ETSI EN 319 422 V1.1.1
- Circular T del BIPM
- Tiempo Universal Coordinado del BIPM
- UTC rápido del BIPM
- Recomendación UIT-R TF.460
- Recomendación UIT-R TF.536-2
- Reglamento (UE) nº 910/2014 consolidado
- Reglamento de Ejecución (UE) 2025/1929
- Lu Heng — Running Code Primary
- Lu Heng — Minimum Initial Specification
- Lu Heng — On Reality Layers
- Lu Heng — On Authority and Belief
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance