Marcas de tiempo y tiempo de confianza

Spec: RFC 3161 Spec: RFC 5816 Spec: ISO 32000-2, §12.8.5 Evidence: Standard-backed

De un vistazo

Una marca de tiempo no registra «cuándo se firmó esto». Demuestra algo más concreto y más sólido: que un dato concreto existía antes de un instante concreto, atestiguado por una parte que no es el firmante. En esa distinción reside todo el valor del tiempo de confianza, y a menudo se malinterpreta.

Por qué esto importa

La hora de firma incluida en una firma es la que declara el equipo del firmante. Un reloj puede estar mal por accidente o de forma intencionada. Si la única prueba de cuándo es la propia afirmación del firmante, este puede antedatar o posdatar un documento a voluntad. Un certificado revocado ayer puede presentarse como si hubiera firmado el año pasado. El «cuándo» no es un detalle. Decide si una firma realizada con un certificado ahora caducado o ahora revocado sigue contando. Y si el tiempo de confianza es erróneo, todo argumento de validez a largo plazo construido sobre él se derrumba.

La versión corta

La hora de firma declarada por el firmante es una afirmación, no una prueba. Es trivialmente falsificable.
Una marca de tiempo RFC 3161 es un token firmado por una autoridad de sellado de tiempo (TSA) que vincula un hash de los datos con la hora de la TSA.
Lo que demuestra es preciso: los datos existían antes de la hora declarada por la TSA. No el momento exacto de creación: una cota superior.
El token reproduce tu nonce y tu huella del mensaje, de modo que no puede ser una repetición ni referirse a datos distintos.
Una marca de tiempo de documento aplica el mismo mecanismo al PDF completo, anclando todo lo que hay debajo —la firma y su evidencia de validación incrustada— a un instante de confianza.

Cómo lo aborda NextPDF

NextPDF trata una marca de tiempo como algo que hay que verificar, no como algo que simplemente se obtiene. Solicitar un token es solo una parte menor del trabajo. La postura del motor es que un token sin verificar no es evidencia.

Cuando el motor añade una marca de tiempo a una firma, envía a la TSA un hash de los datos y un nonce aleatorio nuevo, nunca los propios datos. Después, el token devuelto se comprueba frente al conjunto completo de propiedades que lo hacen significativo: el estado de la autoridad es «granted», el nonce del token coincide con el enviado, la huella del mensaje del token coincide con el hash enviado, la propia firma criptográfica del token se verifica, el tipo de contenido del token es de marca de tiempo y la hora declarada cae dentro de una tolerancia aceptable. Cualquier divergencia es un fallo grave con un motivo tipado. No hay una vía de «se parece bastante». Una marca de tiempo de documento sigue la misma regla, aplicada al archivo completo en lugar de al valor de una sola firma.

Hash the data Only a digest of the signature value (or the whole PDF, for a document timestamp) is computed — never the data itself.
Send hash + nonce The digest and a fresh random nonce go to the Time-Stamp Authority.
TSA returns a token A signed token binds the digest to the TSA’s genTime and echoes the nonce.
Verify the token Status granted, nonce matches, message imprint matches, token signature verifies, time within tolerance.
Conclude an upper bound The data provably existed before the TSA’s stated time — attested by a party that is not the signer.

Cómo se obtiene una marca de tiempo de confianza y qué demuestra: se envía un hash más un nonce a la TSA, la TSA devuelve un token firmado que vincula ese hash con su hora, y el verificador confirma el vínculo antes de tratarlo como prueba de que los datos existían antes de esa hora.

Qué dice la evidencia

Evidence: Standard-backed La definición es precisa. Spec: ISO/IEC 18014-2, §3 define un servicio de sellado de tiempo como un servicio que aporta evidencia de que un dato existía antes de un determinado momento en el tiempo — una cota superior, no un instante de creación. Spec: ISO/IEC 18014-2, §7 define el contenido TSTInfo del token: una huella del mensaje (el hash de los datos), una hora de generación, un número de serie y un nonce opcional. Spec: ISO/IEC 18014-2, §6 enuncia la conclusión que un verificador puede extraer en caso de éxito: que el dato existía antes de la hora indicada en el token — nada más y nada menos.

Para PDF, Spec: ISO 32000-2, §12.8.5 especifica la marca de tiempo de documento: el rango de bytes cubre el archivo completo excluyendo el valor Contents, ese hash se envía a una autoridad de sellado de tiempo y el token RFC 3161 devuelto —según lo actualizado por Spec: RFC 5816 — se coloca en Contents. La misma disciplina de rango de bytes que una firma, aplicada al tiempo en lugar de a la identidad. Y Spec: RFC 6960, §4.4.4 explica por qué esto importa para la longevidad: el tiempo de confianza permite a un validador demostrar que una firma era fiable el día en que se produjo, incluso después de que el certificado caducara.

El motor de NextPDF envía un hash y un nonce, nunca los datos, y verifica el token devuelto frente al estado, el nonce, la huella del mensaje, la firma del token, el tipo de contenido y la tolerancia de tiempo antes de tratarlo como evidencia.

Ejemplo práctico

No se ensambla un token de marca de tiempo a mano. Lo que importa es la costura de confianza. Una TSA es algo que se configura y se protege, porque su hora pasa a formar parte de la evidencia.

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// Asking for any level at or above B-T requires a TSA.
$level = SignatureLevel::PAdES_B_T;
$level->requiresTimestamp(); // true → a Time-Stamp Authority must be supplied

// The TSA endpoint, its transport security, and its trust anchor are
// deployment-supplied. The engine sends a hash plus a fresh nonce — never the
// document — and verifies the returned token before the signature is accepted.
// A token that fails any check (status, nonce, imprint, signature, time)
// is a hard error, not a warning.

La costura que conviene observar es que el motor envía un hash, no el documento, de modo que la TSA nunca ve el contenido. Y verifica la respuesta. Una TSA que no se puede autenticar no es tiempo de confianza. Es solo otro reloj.

Concepto erróneo habitual

La trampa está en leer una marca de tiempo como «esto se firmó exactamente a las 14:32 de esta fecha». No es un cronómetro sobre el evento de firma. Demuestra que los datos existían no después de la hora de la TSA, que es una cota superior fijada por un tercero. La creación pudo darse en cualquier momento anterior a esa. Una segunda trampa es suponer que cualquier servidor de marcas de tiempo da tiempo de confianza. Un token cuya firma no se puede verificar, o cuya autoridad no es de confianza, no demuestra nada. Es un reloj que no hay motivo para creer. El tiempo de confianza procede de una TSA que se puede autenticar y de un token que se ha verificado, no del acto de pedir un número a un servidor.

Límites y fronteras

NextPDF construye la solicitud, envía solo un hash y verifica el token devuelto. No responde por la autoridad que hay detrás. La exactitud de la TSA, la validez de su propio certificado y su fiabilidad son propiedades del servicio y de la configuración del despliegue, no del motor. Una marca de tiempo vincula un hash con una hora. No dice nada sobre el significado de los datos, la identidad del firmante ni si el certificado del firmante era válido. Esas son comprobaciones independientes tratadas en Validar una firma correctamente. El motor no puede hacer fiable una TSA que no lo es. Esta página tampoco afirma ningún peso legal concreto para una marca de tiempo; eso depende del estado de la TSA y de la jurisdicción. Cómo se reutiliza el tiempo de confianza para mantener una firma verificable durante décadas se trata en Validación a largo plazo.

Disponibilidad del sellado de tiempo por nivel:

RFC 3161 timestamping (signature timestamp and document timestamp) — edition availability
Edition	Availability
Core	Not in this edition
Pro	PAdES B-T — una marca de tiempo RFC 3161 verificada sobre el valor de la firma, frente a una TSA proporcionada por el despliegue.
Enterprise	Añade la marca de tiempo de documento que utilizan B-LT y B-LTA para anclar la evidencia de validación incrustada y para impulsar el ciclo de renovación de archivo.

Documentos relacionados

Validación a largo plazo — cómo la marca de tiempo de documento sella la evidencia incrustada y se renueva con el tiempo.
Perfiles base de PAdES — dónde se sitúan la marca de tiempo de firma (B-T) y la marca de tiempo de documento (B-LTA) en la progresión de niveles.
Firmas cualificadas, explicadas — dónde encaja una marca de tiempo cualificada en el panorama de confianza de eIDAS.

Glosario

Marca de tiempo (RFC 3161) — un token firmado por una TSA que vincula un hash de datos con la hora de la TSA, demostrando que los datos existían antes de esa hora.
Autoridad de sellado de tiempo (TSA) — el servicio de confianza que emite los tokens de marca de tiempo.
TSTInfo — la estructura de contenido del token: huella del mensaje, hora de generación, número de serie y nonce opcional.
Huella del mensaje — el hash de los datos a los que se aplica la marca de tiempo, reproducido en el token.
Nonce — un valor aleatorio nuevo enviado con la solicitud y reproducido en el token, de modo que la respuesta no puede ser una repetición.
Marca de tiempo de documento — una marca de tiempo RFC 3161 sobre el PDF completo (según lo actualizado por RFC 5816), que ancla la firma y su evidencia a un instante de confianza.