Protocolo de sellado de tiempo del IETF: huella y token

Qué es el hash digital, cómo se estructura un TimeStampToken según el RFC 3161 y por qué el estándar sigue vigente años después de su publicación en 2001

Detrás de cada sello de tiempo hay un protocolo que fija qué se envía, qué se devuelve y cómo se firma. Conocerlo ayuda a entender por qué basta con la huella del documento.

Su papel en la prueba de fechas se resume en la guía para dar fecha cierta.

Takeaways - Puntos clave del artículo

• Origen del estándar: El RFC 3161 lo publicó el IETF en agosto de 2001 como protocolo de sellado de tiempo de la infraestructura de clave pública X.509.
• Solo la huella: La solicitud incluye la huella del documento y el algoritmo con que se calculó, no el documento en sí (RFC 3161).
• Número único: Según el RFC 3161, la autoridad incluye en cada sello un entero único y lo firma con una clave reservada a ese fin.
• Hora en UTC: El campo genTime recoge el instante en que se creó el sello, expresado en Tiempo Universal Coordinado.
• Sello cualificado: En la UE, el sello que cumple el artículo 42 de eIDAS disfruta de presunción de exactitud de fecha, hora e integridad (art. 41.2).

¿Qué es el hash digital?

Es un código de longitud fija que una función matemática calcula a partir del contenido de un archivo. Cambia por completo si se altera un solo bit del documento, y no permite reconstruir el contenido a partir de él.

Por eso funciona como huella: basta con comparar el hash calculado hoy con el que recoge el sello. La diferencia con la fecha que guarda el sistema se explica en los metadatos frente a la huella.

¿Cómo se estructura un TimeStampToken según el RFC 3161?

Es una estructura firmada por la autoridad de sellado que contiene, entre otros, estos campos:

• policy: la política con que se emitió.
• messageImprint: el hash del documento y su algoritmo.
• serialNumber: un número único para cada sello.
• genTime: la fecha y hora de creación, en UTC.
• tsa: de forma opcional, el nombre de la autoridad.

Puede incluir también la precisión de la hora (accuracy) y el valor aleatorio de la solicitud (nonce). Quién lo firma se explica en la autoridad que firma los sellos.

El sello de tiempo de Fecha Cierta Online se descarga en PDF, TSR o TSD: el TSR contiene únicamente el sello, sin el documento. Las diferencias se comparan en los tres formatos del sello.

¿Por qué el RFC 3161 sigue siendo válido años después de su publicación en 2001?

Porque resuelve un problema que no ha cambiado: fijar en el tiempo una huella sin revelar el documento. El algoritmo de hash viaja identificado en cada sello, así que el estándar admite funciones más robustas cuando aparecen.

En la UE, el sello cualificado debe cumplir además el artículo 42 de eIDAS, como basarse en una hora vinculada al UTC. Qué ocurre cuando caduca el certificado de una firma sellada se explica en la caducidad de un certificado sellado.

Conclusión

El RFC 3161 define cómo se pide y se entrega un sello de tiempo: la huella del documento viaja a la autoridad, que devuelve un token firmado con la hora UTC. Esa estructura permite verificar el sello sin revelar el contenido.

Para aplicar un sello cualificado sobre la huella de un archivo está el sello sobre la huella de CartaSinSobre.