¿Cómo demuestro que un documento existía en una fecha determinada?

El problema de las fechas propias

Toda fecha que usted pueda aportar sobre su propio documento la ha producido usted. La marca de tiempo del sistema de archivos, la columna «creado el» de su base de datos, la fecha impresa en la primera página, los metadatos del PDF: todas están bajo el control de la parte que quiere que se las crean.

No es una acusación, es la estructura del problema. Un auditor, una contraparte o un tribunal no pueden distinguir una fecha honesta de una conveniente cuando ambas proceden del mismo lugar. Las disputas de uso anterior, las fechas de efecto de los contratos, los plazos de preaviso, el inicio de los períodos de conservación y las reclamaciones de propiedad intelectual dependen de esto, y lo hacen años después.

Cómo lo resuelve un sello de tiempo de confianza

RFC 3161 describe un protocolo pequeño con una consecuencia grande.

1. Calcule el hash del documento. Una función hash criptográfica produce una huella de longitud fija. Cualquier cambio en el documento, aunque sea de un byte, produce una huella completamente distinta.
2. Envíe solo el hash. La solicitud va a una autoridad de sellado de tiempo, un tercero que opera un servicio de firma. El documento nunca sale de sus sistemas, así que esto sirve incluso para material que no puede compartir.
3. Reciba un token firmado. La autoridad devuelve un token con su hash y la hora, firmado con su propia clave.
4. Conserve el token junto al documento.

Lo que el token establece es preciso, y conviene decirlo con precisión: este contenido exacto existía a más tardar en ese momento, y no ha cambiado desde entonces. Es un límite unilateral. Demuestra que el documento no es más reciente que el sello. No demuestra que no sea más antiguo.

Para que siga funcionando dentro de diez años

Esta es la parte que la mayoría de las implementaciones omite, y falla en silencio.

Un token de sello de tiempo se verifica contra el certificado de la autoridad. Los certificados son válidos entre uno y tres años. Para verificar en 2035 un token emitido en 2026, un verificador estricto necesita tres cosas que hoy existen y entonces no: la cadena de certificados completa tal como era, el estado de revocación en el momento de la firma y un algoritmo que siga considerándose sólido.

Conserve por tanto el material de verificación junto al token, en el momento de crearlo. Volver a sellar periódicamente con un algoritmo actual, antes de que el anterior se debilite, prolonga la vida de toda la cadena. Ninguna de las dos cosas puede hacerse con efecto retroactivo.

Dónde encaja SealDoc

SealDoc solicita por defecto un sello de tiempo RFC 3161 para cada documento que procesa, mantiene una cadena de hashes SHA-384 y un registro de cadena de custodia, y entrega el resultado como archivo PDF/A-3B, con un paquete de prueba por documento a petición. A la autoridad de sellado solo se le envía el hash, de modo que el documento permanece dentro de infraestructura europea.