RFC 3161: qué es una TSA y cómo funciona el sello de tiempo
Qué es RFC 3161 y cómo funciona una TSA: TimeStampReq, messageImprint, nonce, TimeStampToken, UTC, TSU y sellos de tiempo cualificados eIDAS
RFC 3161: qué es una TSA y cómo funciona un servicio de sello de tiempo
Cuando una aplicación necesita demostrar que unos datos ya existían en un momento determinado, una de las soluciones más utilizadas es solicitar un sello de tiempo electrónico a una TSA —Time-Stamping Authority—.
El estándar de referencia para realizar este intercambio es RFC 3161, que define el protocolo utilizado para solicitar y recibir tokens criptográficos de sellado de tiempo.
Su funcionamiento puede resumirse así:
documento o datos
↓
cálculo de hash
↓
TimeStampReq
↓
TSA
↓
TimeStampResp
↓
TimeStampToken
La TSA no necesita recibir necesariamente el documento original. El cliente calcula una huella criptográfica y solicita que esa huella quede vinculada a una referencia temporal.
RFC 3161 define cómo se realiza ese intercambio, qué información debe contener la petición, qué debe devolver la TSA y qué comprobaciones debe realizar posteriormente el cliente.
Pero existe una distinción fundamental:
RFC 3161 define un protocolo técnico de timestamping. No convierte automáticamente un servicio en un servicio cualificado conforme a eIDAS.
Para que un timestamp tenga la consideración de sello cualificado de tiempo electrónico deben cumplirse además los requisitos del Reglamento eIDAS y el servicio debe tener el correspondiente estatus cualificado.
En este artículo explicamos todo el proceso.
¿Qué es RFC 3161?
RFC 3161 —Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)— es un estándar publicado originalmente por la IETF en 2001 para definir un protocolo de sellado de tiempo basado en infraestructuras de clave pública.
El estándar define principalmente:
- el formato de una petición de timestamp;
- el formato de la respuesta;
- la estructura del TimeStampToken;
- requisitos básicos de una TSA;
- cómo identificar el certificado utilizado;
- cómo relacionar el timestamp con los datos originales;
- y qué verificaciones debe realizar el cliente.
RFC 3161 fue posteriormente actualizado por RFC 5816, especialmente para modernizar la identificación del certificado de firma del timestamp mediante ESSCertIDv2 y permitir algoritmos diferentes de SHA-1.
Aunque el protocolo tiene más de dos décadas, sigue siendo una pieza fundamental de las infraestructuras modernas de firma electrónica y conservación documental.
¿Qué problema resuelve RFC 3161?
Supongamos que tenemos un contrato electrónico.
Podemos calcular:
SHA-256(documento) = 8F7A...
Pero ese hash, por sí solo, no demuestra cuándo existía el documento.
Necesitamos vincularlo con una referencia temporal proporcionada por un tercero confiable.
El flujo sería:
documento
↓
SHA-256
↓
8F7A...
↓
TSA
↓
8F7A... existía en el instante T
La TSA genera una evidencia criptográfica que relaciona:
huella
fecha y hora
política
identificador
y protege el resultado criptográficamente.
¿Qué es una TSA?
TSA significa:
Time-Stamping Authority
o:
Autoridad de Sellado de Tiempo.
RFC 3161 describe la TSA como una entidad que genera tokens de timestamp destinados a acreditar que unos datos existían en un determinado momento.
En una arquitectura moderna de servicios de confianza conviene diferenciar varios conceptos.
TSA, TSP, QTSP y TSU: no son lo mismo
Estos términos aparecen frecuentemente juntos, pero tienen significados diferentes.
TSP — Trust Service Provider
Es un Prestador de Servicios de Confianza.
Puede ofrecer uno o varios servicios relacionados con confianza electrónica.
QTSP — Qualified Trust Service Provider
Es un Prestador Cualificado de Servicios de Confianza conforme al marco eIDAS.
La condición cualificada añade requisitos regulatorios, supervisión y reconocimiento oficial.
TSA — Time-Stamping Authority
Es la entidad responsable de proporcionar el servicio de sellado de tiempo.
ETSI define la TSA como el TSP que proporciona servicios de timestamping utilizando una o varias unidades de sellado temporal.
TSU — Time-Stamping Unit
Una Time-Stamping Unit es una unidad concreta de hardware y software utilizada por la TSA para generar timestamps.
ETSI la define, conceptualmente, como una unidad gestionada de forma conjunta que utiliza una única clave activa de firma de timestamp.
Por tanto:
TSP / QTSP
→ organización prestadora.
TSA
→ función responsable del servicio de timestamping.
TSU
→ unidad concreta que genera criptográficamente los tokens.
Una TSA puede gestionar más de una TSU.
Ejemplo práctico con edatalia
edatalia presta un servicio de sello de tiempo cualificado eIDAS.
En la Trusted List europea aparece, por ejemplo, el servicio:
EDATALIA QUALIFIED TSU02
clasificado como:
QTimestamp.
Esto ilustra perfectamente la diferencia entre las entidades:
EDATALIA DATA SOLUTIONS, S.L.
→ prestador.
servicio cualificado de sellado de tiempo
→ servicio de confianza.
EDATALIA QUALIFIED TSU02
→ unidad/identidad asociada a la generación de timestamps.
¿Cómo funciona un servicio RFC 3161?
Podemos dividir el proceso en seis fases.
1. La aplicación obtiene los datos que quiere sellar
Por ejemplo:
- documento PDF;
- contrato;
- firma electrónica;
- fichero;
- registro;
- evidencia digital.
2. Calcula una huella criptográfica
Por ejemplo:
SHA-256(datos)
3. Construye una TimeStampReq
La petición contiene principalmente la huella y el algoritmo utilizado.
4. Envía la petición a la TSA
La TSA recibe la solicitud.
5. La TSA genera un TimeStampToken
El token vincula la huella con la referencia temporal.
6. El cliente valida la respuesta
La aplicación debe verificar que:
- corresponde a su petición;
- el hash es correcto;
- el token está correctamente firmado;
- el certificado es válido;
- y la política utilizada es aceptable.
Solo entonces debería aceptar el timestamp.
La TSA no necesita recibir el documento original
Ésta es una de las características más interesantes del protocolo.
La petición contiene un:
messageImprint
formado por:
algoritmo hash
hash de los datos.
Por ejemplo:
hashAlgorithm = SHA-256
hashedMessage = A83F...
Por tanto, el esquema normal es:
documento
permanece en el sistema del cliente.
↓
hash(documento)
se envía a la TSA.
Esto reduce considerablemente la exposición del contenido.
La TSA puede acreditar temporalmente la huella sin necesitar conocer el documento original.
¿Qué es el messageImprint?
El messageImprint es uno de los elementos centrales de RFC 3161.
Contiene:
MessageImprint
├── hashAlgorithm
└── hashedMessage
hashAlgorithm
Identifica el algoritmo utilizado.
Por ejemplo:
SHA-256.
hashedMessage
Contiene el resultado de aplicar ese algoritmo a los datos.
Cuando posteriormente recibimos el timestamp, una de las comprobaciones fundamentales consiste en verificar:
¿El messageImprint contenido en la respuesta coincide exactamente con el que enviamos?
Si no coincide, el token debe rechazarse.
¿Por qué utilizar un hash?
Una función hash permite transformar un conjunto de datos de cualquier tamaño en una huella de longitud determinada.
Una propiedad fundamental es que una pequeña modificación del documento produce una huella diferente.
Por ejemplo:
Documento A
↓
SHA-256
↓
FA82...
Si modificamos una palabra:
Documento A modificado
↓
SHA-256
↓
91BC...
Cuando el timestamp está asociado a:
FA82...
no podemos utilizarlo para acreditar:
91BC....
Así se crea una vinculación entre la evidencia temporal y los datos concretos.
La elección del algoritmo hash es importante
RFC 3161 exige que la petición identifique el algoritmo utilizado para calcular el messageImprint.
La TSA debe poder reconocerlo y puede rechazar algoritmos considerados insuficientes o no soportados.
Esto es importante porque la seguridad de una evidencia temporal depende también de la resistencia criptográfica del algoritmo hash.
Por eso las implementaciones modernas deben utilizar algoritmos adecuados a las políticas criptográficas vigentes.
No basta con afirmar:
“utilizamos RFC 3161”.
También hay que analizar:
qué algoritmos se están utilizando.
¿Qué contiene una TimeStampReq?
La estructura de una petición RFC 3161 incluye estos campos principales:
TimeStampReq
├── version
├── messageImprint
├── reqPolicy opcional
├── nonce opcional
├── certReq
└── extensions opcional
Veamos los más importantes.
version
RFC 3161 define actualmente la versión:
v1
Es el identificador del formato de la solicitud.
messageImprint
Como hemos visto, contiene:
- algoritmo hash;
- huella de los datos.
Es el elemento esencial que vincula posteriormente el timestamp con los datos originales.
reqPolicy
La petición puede indicar una determinada:
TSA Policy
mediante un identificador OID.
Esto permite solicitar que el timestamp sea emitido conforme a una política determinada.
La política puede definir cuestiones como:
- condiciones de utilización;
- prácticas del servicio;
- algoritmos;
- garantías;
- características operativas.
Cuando el cliente solicita explícitamente una política, la TSA debe responder conforme a esa política o rechazar la solicitud.
nonce
nonce es un número generado por el cliente para relacionar de forma inequívoca petición y respuesta.
Por ejemplo:
nonce = 87234981234981
El cliente envía:
nonce X
y espera recibir:
nonce X.
Si recibe otro valor, la respuesta no corresponde correctamente a aquella petición.
Esto ayuda a proteger el protocolo frente a determinados problemas de repetición o asociación incorrecta de respuestas.
RFC 3161 establece que, cuando se incluye un nonce en la petición, debe aparecer el mismo valor en la respuesta.
¿Es obligatorio usar nonce?
RFC 3161 lo define como opcional.
Sin embargo, desde el punto de vista de una implementación robusta resulta muy útil para poder relacionar claramente la respuesta con la petición que la originó.
El cliente debe aplicar la política de seguridad correspondiente a su integración.
certReq
Otro campo interesante es:
certReq
Permite indicar si queremos que la respuesta incluya el certificado público correspondiente a la clave con la que la TSA ha firmado el timestamp.
Por ejemplo:
certReq = TRUE
puede facilitar que el cliente disponga del certificado necesario para comenzar la validación del token.
No obstante, incluir el certificado no significa que debamos confiar automáticamente en él.
Todavía debemos verificar:
- cadena;
- estado;
- política;
- confianza;
- y, cuando corresponda, Trusted List.
¿La petición RFC 3161 identifica al cliente?
No necesariamente.
La estructura básica TimeStampReq no está diseñada como un mecanismo de identificación del solicitante.
Si el servicio requiere:
- autenticación;
- autorización;
- control de consumo;
- facturación;
- limitación por cliente;
esas funciones pueden resolverse mediante mecanismos adicionales de transporte o autenticación.
Por ejemplo:
- TLS;
- credenciales;
- API gateway;
- certificados cliente;
- otros mecanismos definidos por el proveedor.
Por tanto:
RFC 3161 define el intercambio de timestamping, no todo el modelo comercial o de autenticación del servicio.
¿Qué devuelve la TSA?
La respuesta RFC 3161 tiene una estructura denominada:
TimeStampResp
que contiene básicamente:
TimeStampResp
├── status
└── timeStampToken
El resultado puede indicar que la solicitud:
- ha sido aceptada;
- ha sido aceptada con modificaciones;
- ha sido rechazada;
- o no puede procesarse por algún motivo.
Si la solicitud se acepta correctamente, la respuesta contiene el correspondiente:
TimeStampToken.
¿Por qué una TSA puede rechazar una solicitud?
RFC 3161 contempla distintos motivos.
Por ejemplo:
Algoritmo no admitido
La TSA no acepta el algoritmo hash utilizado.
Formato incorrecto
La petición no cumple la estructura esperada.
Política no admitida
El cliente ha solicitado una TSA Policy que el servicio no soporta.
Fuente temporal no disponible
El servicio no puede garantizar adecuadamente la información temporal.
Error interno
El servicio no puede completar la operación.
Una buena integración debe analizar correctamente el estado de la respuesta y no asumir que toda respuesta HTTP satisfactoria contiene un timestamp válido.
¿Qué es el TimeStampToken?
El TimeStampToken —TST— es el elemento criptográfico que constituye la evidencia temporal.
RFC 3161 lo construye utilizando CMS —Cryptographic Message Syntax—.
Dentro del token se encuentra una estructura:
TSTInfo.
Conceptualmente:
TimeStampToken
│
└── TSTInfo
├── version
├── policy
├── messageImprint
├── serialNumber
├── genTime
├── accuracy
├── ordering
├── nonce
└── tsa
No todos los campos son obligatorios, pero algunos resultan fundamentales para interpretar correctamente la evidencia.
policy
El token indica la política de timestamp conforme a la cual ha sido emitido.
El cliente debe poder determinar si esa política resulta adecuada para el uso que pretende realizar.
messageImprint
Debe coincidir con el incluido en la petición.
Ésta es una comprobación crítica.
Si solicitamos timestamp para:
A83F...
y la respuesta contiene:
993A...
la respuesta no protege los datos que pretendíamos sellar.
Debe rechazarse.
serialNumber
Cada TimeStampToken emitido por una TSA dispone de un número de serie.
RFC 3161 exige que sea único para cada token emitido por una determinada TSA.
Esto permite identificar de manera inequívoca cada evidencia temporal.
genTime
genTime indica el momento en el que la TSA ha generado el TimeStampToken.
RFC 3161 utiliza una representación temporal basada en:
UTC —Coordinated Universal Time—.
Esto evita depender de:
- zonas horarias locales;
- configuraciones regionales;
- horario de verano;
- hora del equipo cliente.
Por ejemplo:
20261030113527Z
La Z representa la referencia UTC.
¿Qué significa accuracy?
RFC 3161 contempla un campo opcional:
accuracy
que permite expresar la precisión asociada a la referencia temporal.
Puede indicar componentes como:
- segundos;
- milisegundos;
- microsegundos.
Esto permite interpretar un intervalo alrededor de genTime.
No debemos confundir:
resolución de la fecha
con
exactitud del servicio temporal.
La política y la documentación de la TSA son fundamentales para conocer las garantías concretas del servicio.
¿Qué es ordering?
El campo opcional ordering está relacionado con la posibilidad de establecer un orden entre tokens generados por la misma TSA.
Normalmente no es uno de los elementos con los que tendrá que trabajar directamente un integrador, pero forma parte de la semántica temporal definida por RFC 3161.
El nonce debe volver en la respuesta
Si el cliente incluyó un nonce en la solicitud:
nonce = 123456
la respuesta debe contener:
nonce = 123456
De lo contrario, debe rechazarse.
Esta comprobación permite relacionar el token recibido con la solicitud concreta.
El token está firmado criptográficamente por la TSA
No basta con que una estructura contenga:
genTime = ...
El TimeStampToken está protegido mediante la clave utilizada por la TSA.
El cliente debe validar esa protección criptográfica.
RFC 3161 establece además que la clave de firma utilizada por la TSA debe estar reservada específicamente para timestamping.
El certificado correspondiente utiliza el propósito de clave extendido:
id-kp-timeStamping
Esto permite diferenciar una clave utilizada para emitir timestamps de otros usos criptográficos.
¿Qué actualización introdujo RFC 5816?
RFC 3161 fue actualizado posteriormente por RFC 5816.
Uno de los motivos era eliminar la dependencia histórica de SHA-1 para identificar el certificado utilizado por la TSA.
RFC 5816 introdujo soporte para:
ESSCertIDv2
permitiendo utilizar algoritmos modernos para identificar el certificado firmante.
Por tanto, cuando hablamos actualmente de RFC 3161 debemos entenderlo junto con las actualizaciones posteriores aplicables.
¿Cómo debe validar el cliente la respuesta RFC 3161?
Solicitar un timestamp es solo la mitad del trabajo.
RFC 3161 establece que el cliente debe verificar la respuesta recibida.
Entre las comprobaciones principales están:
Estado de la respuesta
Determinar que la TSA ha aceptado correctamente la solicitud.
messageImprint
Debe coincidir exactamente con el solicitado.
Algoritmo hash
Debe coincidir con el utilizado en la petición.
nonce
Si se utilizó, debe ser idéntico.
Firma del TimeStampToken
Debe ser criptográficamente correcta.
Certificado de la TSA
Debe identificarse y validarse.
Estado del certificado
Debe comprobarse cuando corresponda.
Política
El cliente debe determinar si la TSA Policy utilizada es aceptable para su aplicación.
Por tanto, una integración correcta no debería ser:
POST TSA
↓
respuesta
↓
guardar
sino:
crear solicitud
↓
enviar
↓
recibir
↓
VALIDAR
↓
aceptar
↓
incorporar / conservar
¿Cómo validar posteriormente el timestamp?
Además de las comprobaciones RFC 3161, un sistema de validación moderno puede necesitar comprobar:
- cadena de certificación;
- autoridades intermedias;
- revocación;
- política;
- confianza;
- Trusted List;
- estado cualificado del servicio.
Puedes consultar el proceso completo en:
Cómo validar el sello de tiempo de un documento firmado
RFC 3161 no define necesariamente el transporte
Otro detalle importante para desarrolladores:
RFC 3161 define fundamentalmente la estructura y semántica de los mensajes de timestamping.
No impone un único mecanismo de transporte obligatorio.
El RFC original contempla distintos mecanismos y define tipos MIME como:
application/timestamp-query
para la petición,
y:
application/timestamp-reply
para la respuesta.
También define las extensiones tradicionales:
.tsq
para una Time Stamp Query,
y:
.tsr
para una Time Stamp Reply.
En integraciones actuales es habitual utilizar servicios sobre HTTP/HTTPS, pero:
HTTP no es lo que convierte al servicio en RFC 3161.
Lo relevante es el formato y procesamiento de la petición y respuesta conforme al protocolo.
RFC 3161 no es una API REST
También conviene diferenciar estos conceptos.
Una API REST suele trabajar con recursos, operaciones HTTP y frecuentemente representaciones como JSON.
RFC 3161 utiliza estructuras ASN.1 codificadas normalmente en DER.
Por tanto, una URL de una TSA puede aceptar peticiones HTTP, pero el contenido sigue siendo:
TimeStampReq RFC 3161
y la respuesta:
TimeStampResp RFC 3161.
No debemos interpretar automáticamente un endpoint HTTP como:
“API REST de timestamping”.
Son modelos diferentes.
¿Qué papel tiene UTC?
Para un servicio temporal resulta fundamental disponer de una fuente de tiempo confiable.
RFC 3161 expresa genTime utilizando UTC.
En el caso de los sellos cualificados de tiempo electrónico, eIDAS exige además que la referencia temporal esté basada en una fuente de tiempo precisa vinculada al Tiempo Universal Coordinado —UTC—.
Por tanto, UTC no es simplemente una decisión de formato.
Forma parte de la infraestructura de confianza temporal.
¿Qué exige eIDAS a un sello de tiempo cualificado?
eIDAS establece, entre otros requisitos, que un sello cualificado debe:
- vincular fecha y hora con los datos de forma que las modificaciones puedan detectarse;
- basarse en una fuente temporal precisa vinculada a UTC;
- estar protegido mediante los mecanismos criptográficos correspondientes del prestador cualificado.
Además, los sellos cualificados disfrutan de una presunción sobre:
- exactitud de la fecha y hora;
- integridad de los datos vinculados.
Y un sello cualificado emitido en un Estado miembro debe reconocerse como cualificado en los demás Estados miembros.
RFC 3161 y eIDAS son capas diferentes
Ésta es una de las ideas fundamentales del artículo.
Podemos representarlo así:
RFC 3161
Define:
cómo pedir y recibir el timestamp.
ETSI
Define requisitos técnicos, políticas y seguridad de los servicios de timestamping.
eIDAS
Define:
qué requisitos y efectos jurídicos tiene un servicio cualificado de sello de tiempo.
Por tanto:
RFC 3161
+
infraestructura TSA
+
requisitos ETSI
+
condición cualificada eIDAS
=
servicio cualificado de timestamping
No basta con implementar únicamente RFC 3161.
¿Cómo saber si una TSA es cualificada?
No debemos deducirlo únicamente de:
- la URL;
- el nombre de la empresa;
- el certificado;
- la utilización de HTTPS;
- la utilización de RFC 3161;
- una afirmación comercial.
Hay que comprobar el servicio concreto en la correspondiente:
Trusted List.
La Trusted List permite determinar:
- prestador;
- tipo de servicio;
- estado;
- periodo de vigencia;
- información asociada.
Puedes consultar las diferencias con más detalle en:
Marca de tiempo vs sello de tiempo cualificado: diferencias y cuándo utilizar cada uno
¿Qué significa QTimestamp?
Dentro de las Trusted Lists europeas encontramos el tipo de servicio:
QTimestamp
para identificar servicios de generación de sellos cualificados de tiempo.
Por ejemplo, el servicio de edatalia:
EDATALIA QUALIFIED TSU02
figura actualmente con:
Service type: QTimestamp
y estado:
Granted.
Esto aporta una comprobación externa y oficial de la condición cualificada del servicio.
RFC 3161 y PAdES
Una de las aplicaciones más importantes de RFC 3161 es la firma de documentos PDF.
En una firma PAdES podemos tener:
PAdES-B-B
↓
añadimos evidencia temporal
↓
PAdES-B-T.
La TSA proporciona el TimeStampToken.
Pero es el motor PAdES quien debe integrarlo correctamente dentro del PDF.
Por tanto:
la TSA no genera automáticamente PAdES-B-T.
La TSA genera la evidencia temporal que utiliza el sistema de firma.
En:
Cómo añadir un sello de tiempo a un PDF: PAdES-B-T y B-LT
explicamos todo este proceso.
RFC 3161 y PAdES-B-LT
Para generar B-LT necesitamos algo más que el timestamp.
Debemos incorporar material que permita validar posteriormente la firma:
- certificados;
- cadena;
- OCSP;
- CRL;
- otras evidencias necesarias.
Conceptualmente:
RFC 3161
↓
timestamp
↓
B-T
y posteriormente:
certificados + revocación
↓
B-LT.
Por tanto:
RFC 3161 ≠ PAdES-B-LT.
Es solamente uno de los componentes de la arquitectura.
RFC 3161 y PAdES-B-LTA
En estrategias de conservación todavía más prolongadas pueden utilizarse nuevos timestamps para proteger revisiones posteriores y material de validación.
Esto forma parte de la lógica de perfiles:
PAdES-B-LTA.
En nuestro artículo PAdES LTV y firma de larga duración analizamos la conservación de documentos firmados durante largos periodos.
¿Qué ocurre si la TSA recibe siempre el mismo hash?
Si solicitamos dos timestamps diferentes sobre exactamente los mismos datos, el messageImprint puede ser el mismo.
Pero los tokens serán diferentes porque pueden tener:
- número de serie diferente;
genTimediferente;- nonce diferente;
- información adicional diferente.
Por tanto:
mismo documento
no implica:
mismo TimeStampToken.
Cada emisión constituye una evidencia temporal propia.
¿Puede comprobarse un timestamp sin disponer del documento?
Podemos analizar criptográficamente la estructura del TimeStampToken sin disponer necesariamente del documento original.
Pero para comprobar que el timestamp realmente corresponde al documento necesitamos:
- disponer de los datos;
- calcular nuevamente el hash;
- compararlo con el
messageImprint.
Por tanto:
token válido
no significa automáticamente:
token correspondiente a este documento.
Debe comprobarse la vinculación.
¿Puede una TSA modificar el documento?
En el flujo RFC 3161 habitual, la TSA ni siquiera necesita recibir el documento.
Recibe su huella.
Por tanto, la incorporación del timestamp al PDF o al sistema documental se realiza normalmente en el lado del cliente o del motor de firma.
Esto permite separar claramente:
TSA
→ genera evidencia temporal.
aplicación
→ gestiona documento.
motor de firma
→ integra la evidencia.
Integración típica de una TSA en una aplicación
Una arquitectura empresarial puede ser:
APLICACIÓN
│
▼
DOCUMENTO
│
▼
HASH
│
▼
TimeStampReq
│
▼
TSA RFC 3161
│
▼
TimeStampResp
│
▼
VALIDACIÓN
│
▼
TimeStampToken
│
▼
PDF / ARCHIVO / EVIDENCIA
La aplicación debe gestionar además:
- autenticación con el servicio;
- reintentos;
- timeout;
- tratamiento de errores;
- validación;
- auditoría;
- almacenamiento.
Qué hacer si la TSA no está disponible
Una integración profesional debe definir qué ocurre cuando:
- la TSA no responde;
- la red falla;
- la fuente temporal no está disponible;
- el servicio devuelve rechazo;
- el algoritmo no es admitido.
Dependiendo del proceso podemos adoptar estrategias diferentes.
Proceso crítico
No finalizar la firma hasta obtener timestamp.
Proceso tolerante
Mantener el documento pendiente de timestamping.
Arquitectura de alta disponibilidad
Utilizar infraestructura redundante conforme a la política establecida.
Lo importante es que el comportamiento esté definido previamente.
No conviene descubrir durante una incidencia que nadie decidió si el timestamp era:
obligatorio
o
opcional.
¿Cuándo debe solicitarse el timestamp?
Cuando queremos aportar evidencia temporal a una firma, normalmente interesa obtenerla lo más cerca posible del momento de creación de la firma.
¿Por qué?
Porque un timestamp obtenido posteriormente demuestra:
que la firma ya existía en el momento del timestamp.
Pero no puede retroceder en el tiempo.
Por ejemplo:
firma declarada: 1 de enero.
timestamp: 1 de marzo.
El timestamp permite demostrar:
la firma existía el 1 de marzo.
No demuestra automáticamente:
existía ya el 1 de enero.
Esta diferencia es fundamental para conservación y validación.
RFC 3161 en Administración Pública y Justicia
Los servicios de timestamping se utilizan ampliamente en entornos donde la evidencia temporal tiene importancia.
Por ejemplo:
- Administración electrónica;
- expedientes;
- registros;
- contratación;
- documentos judiciales;
- conservación;
- firma PAdES.
En Justicia, la Guía CTEAJE contempla expresamente el sellado temporal en diversos procesos.
Puedes consultar:
CTEAJE y sello de tiempo en la Administración de Justicia
RFC 3161 en banca y seguros
También resulta especialmente útil en operaciones como:
- contratos;
- pólizas;
- préstamos;
- documentación KYC;
- operaciones bancarias;
- aceptación de condiciones;
- conservación documental.
En estos sectores, el timestamp puede aportar una referencia temporal independiente que complemente:
- firma;
- autenticación;
- integridad;
- validación;
- custodia.
RFC 3161 y privacidad documental
Una ventaja arquitectónica es que la TSA puede trabajar sobre el messageImprint.
Esto significa que una organización puede mantener dentro de su infraestructura:
- contratos;
- expedientes;
- información financiera;
- documentación sanitaria;
- documentos judiciales;
y enviar al servicio únicamente la huella necesaria para timestamping.
Esto reduce la cantidad de información que debe salir del sistema.
No obstante, la seguridad global sigue dependiendo de otros elementos:
- transporte;
- autenticación;
- gestión de claves;
- logs;
- configuración;
- políticas del servicio.
RFC 3161 no sustituye una arquitectura completa de seguridad.
Cómo integra edatalia el sellado de tiempo
edatalia presta un servicio cualificado de sello de tiempo utilizable mediante RFC 3161.
Una integración puede seguir este modelo:
aplicación cliente
↓
calcular hash
↓
generar TimeStampReq
↓
servicio TSA de edatalia
↓
recibir TimeStampResp
↓
validar TimeStampToken
↓
incorporar evidencia
El servicio puede utilizarse como componente dentro de arquitecturas de:
- firma electrónica;
- firma PAdES;
- conservación documental;
- Administración electrónica;
- banca;
- seguros;
- Justicia.
¿Qué debe hacer una aplicación después de recibir el token?
El proceso no termina al recibir una respuesta.
Una implementación robusta debería:
- comprobar el estado de la respuesta;
- verificar el
messageImprint; - comprobar el
noncesi se utilizó; - verificar la firma del token;
- validar el certificado de timestamping;
- comprobar la política;
- determinar la confianza aplicable;
- conservar el token;
- incorporarlo correctamente al documento o evidencia;
- comprobar posteriormente que la integración resultante es válida.
Esto resulta especialmente importante cuando el timestamp forma parte de:
- PAdES;
- conservación a largo plazo;
- procesos regulatorios.
Errores frecuentes al integrar RFC 3161
1. Enviar el documento completo innecesariamente
Normalmente el protocolo trabaja con su huella.
2. No validar la respuesta
Recibir un token no significa que debamos aceptarlo automáticamente.
3. No comprobar el messageImprint
Es imprescindible confirmar que el token corresponde a la petición.
4. Ignorar el nonce
Si se utiliza, debe comprobarse.
5. Confundir RFC 3161 con eIDAS
RFC 3161 es un protocolo. La cualificación es otra capa.
6. Considerar cualificada cualquier TSA
Debe comprobarse la Trusted List.
7. Pensar que HTTP 200 significa timestamp válido
La respuesta RFC 3161 tiene su propio estado y debe procesarse.
8. Confundir TSA y TSU
La TSA es responsable del servicio; las TSU son unidades concretas utilizadas para generarlo.
9. No comprobar el certificado de la TSA
El token está firmado y esa firma también debe validarse.
10. Añadir el timestamp demasiado tarde
Un timestamp posterior no reconstruye automáticamente evidencias temporales del pasado.
Preguntas frecuentes sobre RFC 3161 y TSA
¿Qué es RFC 3161?
Es un estándar de la IETF que define el protocolo para solicitar y recibir tokens criptográficos de sellado de tiempo.
¿Qué es una TSA?
Una Time-Stamping Authority es la entidad responsable de proporcionar un servicio de sellado de tiempo.
¿Qué es una TSU?
Una Time-Stamping Unit es la unidad de hardware y software utilizada por una TSA para generar timestamps con una determinada clave activa.
¿TSA y QTSP son lo mismo?
No necesariamente. Una TSA proporciona servicios de timestamping. Un QTSP es un prestador que ha obtenido la condición cualificada conforme a eIDAS.
¿Qué es un TimeStampToken?
Es el token criptográfico emitido por la TSA que vincula una huella con una referencia temporal y otros datos asociados.
¿Qué es TimeStampReq?
Es la estructura de petición definida por RFC 3161.
¿Qué es TimeStampResp?
Es la estructura de respuesta proporcionada por la TSA.
¿Qué es messageImprint?
Es la combinación del algoritmo hash y la huella de los datos que queremos sellar temporalmente.
¿La TSA recibe el documento completo?
No necesariamente. En el flujo RFC 3161 normal se envía el messageImprint, no el documento original.
¿Qué es nonce?
Es un valor generado por el cliente que puede utilizarse para relacionar inequívocamente petición y respuesta.
¿Qué es reqPolicy?
Permite solicitar que el token sea generado conforme a una determinada política de timestamp.
¿Qué es certReq?
Permite solicitar que la respuesta incluya el certificado asociado a la clave utilizada por la TSA.
¿Qué es genTime?
Es el instante en el que la TSA genera el TimeStampToken, expresado mediante una referencia temporal basada en UTC.
¿Qué es accuracy?
Es un campo opcional que permite expresar la precisión asociada al tiempo indicado por la TSA.
¿Qué es id-kp-timeStamping?
Es el propósito de clave extendido utilizado para identificar certificados destinados específicamente a timestamping.
¿Qué actualizó RFC 5816?
Actualizó RFC 3161 para permitir ESSCertIDv2 y facilitar el uso de algoritmos diferentes de SHA-1 para identificar el certificado firmante del token.
¿RFC 3161 utiliza HTTP?
Puede transportarse mediante HTTP/HTTPS en implementaciones modernas, pero RFC 3161 no impone un único mecanismo obligatorio de transporte.
¿RFC 3161 es una API REST?
No. Define estructuras ASN.1 de petición y respuesta. Puede utilizar HTTP como transporte sin convertirse por ello en una API REST.
¿RFC 3161 significa que el timestamp es cualificado?
No. RFC 3161 define el protocolo. La condición cualificada depende de los requisitos eIDAS y del estatus oficial del servicio.
¿Cómo saber si una TSA es cualificada?
Hay que comprobar el servicio concreto en la Trusted List oficial correspondiente.
¿Qué significa QTimestamp?
Es el tipo de servicio utilizado en las Trusted Lists europeas para identificar servicios cualificados de generación de sellos de tiempo.
¿Qué relación hay entre RFC 3161 y PAdES?
PAdES puede utilizar TimeStampTokens RFC 3161 para incorporar evidencias temporales a una firma PDF, por ejemplo en PAdES-B-T.
¿RFC 3161 genera PAdES-B-LT?
No. El timestamp es solo una parte. B-LT necesita además material de validación como certificados y evidencias de revocación.
¿edatalia ofrece un servicio RFC 3161?
Sí. edatalia presta un servicio cualificado de sellado de tiempo integrable mediante RFC 3161.
RFC 3161: una pieza sencilla dentro de una infraestructura compleja
La idea básica del protocolo es muy sencilla:
calcular una huella
↓
enviarla a una TSA
↓
recibir una evidencia temporal firmada
Pero detrás de ese proceso existen diferentes capas:
RFC 3161
→ protocolo.
TSA
→ servicio de timestamping.
TSU
→ unidad que genera los tokens.
ETSI
→ políticas y requisitos técnicos de los servicios de confianza.
eIDAS
→ marco jurídico y condición cualificada.
Trusted Lists
→ mecanismo oficial para comprobar el estado del servicio.
PAdES
→ utilización de esa evidencia dentro de documentos PDF firmados.
Por eso una integración profesional no debería limitarse a:
“mandamos un hash a una URL y recibimos una fecha”.
Debe poder responder:
¿qué datos hemos sellado?
¿qué TSA ha generado el token?
¿qué política utilizó?
¿es correcta su firma?
¿qué certificado se utilizó?
¿el servicio es cualificado?
¿podremos validar esta evidencia dentro de diez años?
RFC 3161 resuelve una pieza fundamental del problema: cómo obtener una prueba criptográfica de que unos datos ya existían en un determinado instante.
La robustez final dependerá de cómo integremos, validemos y conservemos esa evidencia durante todo el ciclo de vida del documento.
Sigue leyendo
¿Estás digitalizando tu proceso de firma?
Hablamos contigo y te enseñamos qué encaja en tu caso.