Cómo añadir un sello de tiempo a un PDF: PAdES-B-T y B-LT
Cómo añadir un sello de tiempo a un PDF y generar PAdES-B-T o B-LT: TSA, RFC 3161, OCSP, CRL, DSS y conservación de firmas digitales
Cómo añadir un sello de tiempo a un PDF: PAdES-B-T y B-LT
Añadir un sello de tiempo a un PDF permite incorporar una evidencia temporal independiente que demuestra que determinados datos ya existían en una fecha y hora concretas.
Cuando el PDF contiene una firma electrónica, esta evidencia temporal puede formar parte de los perfiles PAdES definidos por ETSI para facilitar la validación y conservación de las firmas.
Pero existe una diferencia importante entre:
- añadir simplemente un timestamp a un PDF;
- generar una firma PAdES-B-T;
- y preparar el documento como PAdES-B-LT.
No son exactamente la misma operación.
De forma simplificada:
PAdES-B-B
firma básica
↓
PAdES-B-T
firma + evidencia temporal confiable
↓
PAdES-B-LT
firma + evidencia temporal + material necesario para validarla posteriormente
↓
PAdES-B-LTA
protección adicional para conservación durante periodos prolongados.
En este artículo explicamos cómo funciona técnicamente este proceso, qué información se incorpora al PDF y qué papel desempeñan la TSA, OCSP, CRL y los certificados.
¿Qué significa añadir un sello de tiempo a un PDF?
Un sello de tiempo electrónico vincula unos datos con una fecha y una hora.
Normalmente el proceso no consiste en enviar el documento completo al servidor de tiempo.
La aplicación calcula una huella criptográfica y utiliza esa huella para solicitar un token a una Autoridad de Sellado de Tiempo —TSA—.
Conceptualmente:
datos que queremos sellar
↓
función hash
↓
message imprint
↓
TSA
↓
fecha y hora
↓
TimeStampToken
↓
incorporación de la evidencia al documento
El protocolo más utilizado para este intercambio es RFC 3161.
Puedes profundizar en su funcionamiento en nuestra guía RFC 3161: qué es una TSA y cómo funciona un servicio de sello de tiempo.
La TSA normalmente no necesita recibir el PDF completo
Este detalle es importante desde el punto de vista de arquitectura y privacidad.
RFC 3161 trabaja sobre un message imprint, es decir, una huella criptográfica de los datos que deben quedar temporalmente protegidos.
La TSA recibe esa huella y genera el token correspondiente.
Por tanto, en una arquitectura habitual:
PDF / firma
permanece en el sistema del cliente.
↓
se calcula su huella correspondiente.
↓
la huella se envía a la TSA.
La TSA puede aportar evidencia temporal sin necesidad de conocer el contenido del documento.
PAdES-B-B: el punto de partida
Antes de hablar de timestamp debemos entender el nivel básico.
PAdES-B-B constituye el nivel base de los perfiles PAdES Baseline.
Contiene la firma electrónica y los atributos necesarios para generarla conforme al perfil.
Conceptualmente:
firma criptográfica
↓
PAdES-B-B
La firma permite comprobar fundamentalmente:
- integridad del contenido firmado;
- firma criptográfica;
- certificado utilizado;
- información asociada a la firma.
Pero todavía falta una evidencia temporal independiente que permita demostrar que la firma ya existía en un momento determinado.
Ahí aparece PAdES-B-T.
¿Qué es PAdES-B-T?
ETSI define PAdES-B-T como el nivel que incorpora, para una firma existente, un token confiable que demuestra que la propia firma existía en una determinada fecha y hora.
La idea es:
PAdES-B-B
evidencia temporal confiable
↓
PAdES-B-T
La T hace referencia precisamente a la dimensión temporal.
Esto resulta especialmente importante porque la fecha incluida por el propio software de firma no proporciona necesariamente una evidencia temporal independiente.
La fecha de firma y el sello de tiempo no son lo mismo
Un PDF puede mostrar:
Fecha de firma: 30/10/2026 10:35
pero esa fecha puede proceder del reloj del ordenador.
Un timestamp generado por una TSA introduce una referencia temporal externa.
Por eso debemos distinguir:
Signing Time
→ fecha declarada por el sistema o incluida como atributo de firma.
Timestamp
→ evidencia proporcionada por una Autoridad de Sellado de Tiempo.
La segunda aporta mayores garantías sobre la existencia de la firma en un instante concreto.
¿Cómo se genera un PAdES-B-T?
El flujo puede simplificarse en cinco pasos.
1. Se genera la firma electrónica
El sistema prepara el documento y realiza la operación criptográfica utilizando el certificado y la clave privada correspondiente.
Tenemos inicialmente:
PDF + firma
2. Se calcula la huella que debe proteger el timestamp
El software prepara el messageImprint correspondiente a la evidencia que debe ser sellada.
En un PAdES-B-T, la evidencia temporal está asociada a la propia firma.
3. Se consulta la TSA
El sistema envía una petición de timestamp, habitualmente mediante RFC 3161.
messageImprint
↓
TSA
4. La TSA devuelve un TimeStampToken
El token contiene, entre otros elementos:
- huella protegida;
- instante temporal;
- identificador del token;
- información criptográfica;
- firma o sello del servicio de timestamping.
5. El token se incorpora correctamente a la firma PAdES
El software de firma incorpora la evidencia temporal conforme al perfil PAdES.
El resultado puede ser:
PAdES-B-T.
Añadir un timestamp cualquiera no convierte automáticamente el PDF en PAdES-B-T
Ésta es una de las precisiones más importantes.
Podríamos tener un PDF y añadirle algún tipo de evidencia temporal independiente.
Eso no significa automáticamente que la firma existente haya pasado a ser:
PAdES-B-T
Para utilizar correctamente esa denominación deben cumplirse los requisitos del perfil ETSI.
Por tanto:
PDF + timestamp
no equivale necesariamente a:
PAdES-B-T.
La evidencia temporal debe incorporarse y relacionarse con la firma conforme a la estructura definida por PAdES.
¿PAdES-B-T requiere un sello de tiempo cualificado?
No necesariamente desde el punto de vista estrictamente técnico del perfil.
ETSI habla de una evidencia temporal confiable.
Por tanto, debemos diferenciar:
PAdES-B-T
Es un nivel técnico del formato de firma.
Sello de tiempo cualificado
Es una categoría de servicio de confianza regulada por eIDAS.
Pueden utilizarse conjuntamente, y en muchos procesos tiene mucho sentido hacerlo, pero no son conceptos equivalentes.
Un documento puede cumplir técnicamente un perfil PAdES-B-T sin que ello permita afirmar automáticamente:
“el timestamp es cualificado”.
La cualificación debe comprobarse sobre el servicio utilizado y su correspondiente Trusted List.
En marca de tiempo vs sello de tiempo cualificado explicamos esta diferencia con detalle.
¿Qué aporta un sello de tiempo cualificado?
Cuando se utiliza un sello cualificado de tiempo electrónico, eIDAS reconoce una presunción de:
- exactitud de la fecha y hora indicadas;
- integridad de los datos vinculados.
Además, un servicio cualificado debe poder identificarse como tal dentro de la correspondiente Trusted List.
edatalia presta un servicio de sello de tiempo cualificado eIDAS integrable mediante RFC 3161.
Por tanto, una arquitectura puede combinar:
PAdES-B-T
como formato técnico,
con
QTimestamp eIDAS
como nivel del servicio de confianza utilizado.
¿Por qué PAdES-B-T no es suficiente para la validación a largo plazo?
Supongamos que firmamos un documento hoy.
Añadimos un timestamp.
Tenemos una evidencia temporal que demuestra que la firma ya existía en ese momento.
Pero dentro de diez años querremos validar también:
- el certificado del firmante;
- la cadena de certificación;
- el estado de revocación;
- el certificado de la TSA;
- las autoridades intermedias.
¿Seguirán disponibles todos esos servicios?
Quizá no.
Por ejemplo, la URL OCSP que hoy utilizamos podría no estar disponible dentro de diez años.
Por eso debemos conservar también el material de validación.
Éste es el objetivo de PAdES-B-LT.
¿Qué es PAdES-B-LT?
ETSI define PAdES-B-LT como el nivel destinado a incorporar dentro del documento todo el material requerido para validar la firma.
Su objetivo es mejorar la disponibilidad a largo plazo de esas evidencias.
Conceptualmente:
PAdES-B-T
certificados
información de revocación
material de validación
↓
PAdES-B-LT
Por tanto, B-LT va bastante más allá de añadir un timestamp.
Qué información puede incorporar PAdES-B-LT
Entre el material necesario para una validación futura pueden encontrarse:
Certificado del firmante
Permite identificar el certificado utilizado en la firma.
Certificados de la cadena
Permiten reconstruir la cadena de certificación.
Respuestas OCSP
Proporcionan información sobre el estado de determinados certificados.
CRL
Las listas de revocación pueden aportar también información necesaria para validar certificados.
Certificados de otros servicios implicados
Por ejemplo, los certificados necesarios para validar el propio timestamp.
La finalidad es reducir la dependencia futura de servicios externos.
El Document Security Store —DSS—
PAdES dispone de una estructura especialmente importante para almacenar material de validación dentro del PDF:
Document Security Store —DSS—.
ETSI contempla el DSS como una extensión del PDF que puede almacenar elementos como:
- certificados;
- respuestas OCSP;
- CRL.
Conceptualmente:
PDF
│
├── contenido
├── firma
├── timestamp
│
└── DSS
├── certificados
├── OCSP
└── CRL
De esta forma el propio PDF puede transportar información que de otro modo habría que obtener nuevamente desde Internet en cada validación.
¿Qué es VRI?
Dentro de estas estructuras puede aparecer también el concepto:
Validation Related Information —VRI—.
Su función consiste en relacionar determinada información de validación con una firma concreta del documento.
Esto es especialmente útil cuando un PDF contiene:
- varias firmas;
- varios certificados;
- diferentes respuestas OCSP;
- varias cadenas de certificación.
En lugar de almacenar simplemente un conjunto de evidencias sin contexto, el sistema puede relacionarlas con las firmas a las que corresponden.
Un PDF puede contener varias firmas
Imaginemos:
firma del cliente
↓
firma del apoderado
↓
sello de la empresa
↓
timestamp
Cada elemento puede necesitar distintos certificados y evidencias de validación.
Por eso una implementación PAdES de larga duración debe gestionar correctamente:
- cada firma;
- su cadena;
- su timestamp;
- su estado de revocación;
- las evidencias relacionadas.
No basta con almacenar:
“un OCSP dentro del PDF”.
Hay que saber qué evidencia valida qué elemento.
Cómo pasar conceptualmente de PAdES-B-T a PAdES-B-LT
El flujo habitual es:
1. Validar la firma
Antes de incorporar material de larga duración debemos determinar que la firma puede validarse.
Se analiza:
- integridad;
- algoritmo;
- certificado;
- cadena;
- política;
- revocación.
2. Validar el timestamp
Se comprueba también la evidencia temporal.
En nuestra guía cómo validar el sello de tiempo de un documento firmado explicamos estas comprobaciones.
3. Obtener la cadena de certificados
Se recopilan los certificados necesarios para futuras validaciones.
4. Obtener información de revocación
Mediante:
- OCSP;
- CRL;
según corresponda.
5. Incorporar el material al PDF
La información se introduce utilizando las estructuras previstas para la validación de larga duración.
6. Verificar el resultado
Finalmente se comprueba que el documento contiene el material necesario para poder validar posteriormente la firma.
El resultado puede alcanzar:
PAdES-B-LT.
Validar antes de completar
Es importante no invertir el orden.
El flujo correcto no debería ser simplemente:
recibir PDF
↓
meter OCSP
↓
decir que es B-LT.
Primero hay que validar.
Después podemos recopilar y conservar las evidencias.
Por tanto:
VALIDAR
↓
RECOPILAR EVIDENCIAS
↓
INCORPORAR
↓
VERIFICAR RESULTADO.
Este proceso puede automatizarse mediante servicios como los descritos en nuestra guía sobre validación automática de firmas digitales mediante API REST.
¿Puede convertirse una firma PAdES-B-B existente en B-T?
ETSI contempla precisamente B-T como la incorporación de una evidencia temporal confiable a una firma existente.
Por tanto, técnicamente puede existir un proceso de augmentación de una firma.
Sin embargo, hay una cuestión temporal fundamental.
Supongamos:
firma realizada el 1 de enero
y añadimos timestamp:
1 de febrero.
El nuevo timestamp puede demostrar que la firma ya existía el 1 de febrero.
Pero no demuestra automáticamente que existiera el 1 de enero.
Esto significa que:
un timestamp añadido posteriormente no viaja hacia atrás en el tiempo.
Por eso, cuando la evidencia temporal es importante, resulta recomendable obtenerla lo antes posible después de la creación de la firma.
¿Puede convertirse posteriormente B-T en B-LT?
Sí, siempre que sea posible recopilar el material de validación necesario.
Por ejemplo:
PAdES-B-T
↓
consultar certificado
↓
construir cadena
↓
obtener OCSP / CRL
↓
incorporar material
↓
PAdES-B-LT
Pero cuanto más tiempo dejemos pasar, más difícil puede resultar obtener algunas evidencias.
Los servicios pueden dejar de estar disponibles.
Los certificados pueden haber expirado.
La información histórica de revocación puede ser más difícil de reconstruir.
Por ello:
es preferible recopilar las evidencias cuando todavía están disponibles.
¿Puede convertirse cualquier firma antigua en PAdES-B-LT?
No necesariamente.
Éste es otro punto importante.
Supongamos que tenemos una firma antigua cuyo certificado está caducado.
No existe timestamp confiable.
No conservamos una respuesta OCSP del momento de firma.
Y ya no podemos reconstruir con suficiente certeza cuál era el estado del certificado.
Añadir hoy un timestamp no recrea mágicamente las evidencias que no conservamos entonces.
Podemos demostrar:
“este documento ya existía hoy”.
Pero no necesariamente:
“podemos acreditar técnicamente cuál era la situación exacta del certificado diez años atrás”.
Por eso una buena estrategia de conservación comienza cerca del momento de la firma, no cuando aparecen los problemas.
¿Qué ocurre si el certificado ya ha caducado?
La caducidad posterior no significa automáticamente que una firma realizada previamente fuese inválida.
El problema consiste en disponer de evidencias que permitan demostrar:
- cuándo existía la firma;
- si el certificado estaba vigente;
- si estaba revocado;
- cuál era su cadena de confianza.
PAdES-B-LT está orientado precisamente a conservar material que permita realizar esas comprobaciones posteriormente.
¿Y si el certificado fue revocado?
Aquí debemos analizar también el momento de la revocación.
Supongamos:
firma: 1 de junio
timestamp: 1 de junio
revocación: 15 de junio
La evidencia temporal puede resultar fundamental para demostrar que la firma ya existía antes de la revocación.
Pero si:
revocación: 1 de mayo
y:
firma: 1 de junio
el timestamp no soluciona el problema.
Por eso:
timestamp
y
estado de revocación
son evidencias complementarias.
¿Cómo se modifica un PDF sin invalidar la firma existente?
PDF dispone de un mecanismo denominado actualización incremental.
Conceptualmente, una nueva revisión puede añadirse al final del archivo sin reescribir necesariamente el contenido de la revisión anterior.
Esto permite incorporar determinadas evidencias posteriores como:
- información de validación;
- DSS;
- VRI;
- document timestamps;
manteniendo intactos los bytes protegidos por las firmas anteriores.
Esta característica del formato PDF es fundamental para las estrategias PAdES de larga duración.
Añadir evidencias no significa volver a firmar en nombre del usuario
Cuando añadimos:
- OCSP;
- certificados;
- timestamp;
- información DSS;
no estamos sustituyendo la firma original.
Tampoco estamos:
“firmando otra vez como el usuario”.
Estamos augmentando el documento con evidencias adicionales que ayudan a validar la firma original.
Esta distinción es importante tanto técnica como jurídicamente.
Signature timestamp y document timestamp no son exactamente lo mismo
Dentro de PAdES existen distintos usos del sellado temporal.
Signature timestamp
Está asociado específicamente a una firma y permite aportar evidencia sobre la existencia de esa firma.
Es el concepto fundamental de PAdES-B-T.
Document timestamp
Protege una revisión del documento y puede utilizarse para extender la protección temporal del conjunto.
Los document timestamps tienen especial importancia en estrategias de archivo y en perfiles como PAdES-B-LTA.
Por tanto:
no todo timestamp presente en un PDF cumple exactamente la misma función.
De B-LT a B-LTA
B-LT conserva material de validación.
Pero todavía existe otro problema:
¿qué ocurre cuando dentro de muchos años también envejecen las propias evidencias que hemos almacenado?
Por ejemplo:
- el algoritmo utilizado por la TSA puede quedar obsoleto;
- el certificado del timestamp puede expirar;
- los algoritmos criptográficos pueden debilitarse.
Aquí aparece:
PAdES-B-LTA.
ETSI lo orienta a mantener a largo plazo tanto la disponibilidad como la integridad del material de validación mediante nuevas evidencias temporales.
Conceptualmente:
B-LT
↓
document timestamp
↓
B-LTA
↓
nueva evidencia cuando sea necesario
↓
preservación prolongada.
PAdES-B-LTA no significa “válido para siempre”
No existe una tecnología que permita firmar un documento hoy y olvidarse de él indefinidamente.
Los algoritmos evolucionan.
Los certificados caducan.
Los estándares cambian.
Por eso la conservación a muy largo plazo puede necesitar:
- monitorización;
- nuevas validaciones;
- nuevos sellos temporales;
- algoritmos más robustos;
- nuevas evidencias.
PAdES-B-LTA debe entenderse como una estrategia de preservación, no como una garantía matemática eterna.
Cómo añadir un timestamp a un PDF en una aplicación
Desde el punto de vista de un integrador, podemos simplificar el proceso:
1. Obtener o generar el PDF
↓
2. Crear la firma electrónica
↓
3. Calcular el messageImprint correspondiente
↓
4. Enviar petición RFC 3161 a la TSA
↓
5. Recibir TimeStampToken
↓
6. Validar la respuesta de la TSA
↓
7. Incorporar el timestamp conforme a PAdES
↓
8. Obtener certificados + OCSP/CRL
↓
9. Incorporar material de validación
↓
10. Validar el PDF resultante
Hasta el paso 7 estamos trabajando fundamentalmente hacia:
PAdES-B-T.
Al completar correctamente el material de validación llegamos conceptualmente a:
PAdES-B-LT.
La respuesta de la TSA también debe validarse
Solicitar un timestamp no es suficiente.
RFC 3161 contempla que el cliente compruebe la respuesta recibida.
Entre otras cosas debemos verificar:
- que el
messageImprintcoincide; - que el token es criptográficamente correcto;
- que corresponde a la petición;
- el certificado utilizado;
- el instante temporal;
- la confianza aplicable al servicio.
Por tanto:
solicitar timestamp
↓
recibir token
↓
validar token
↓
incorporar token.
No deberíamos almacenar ciegamente cualquier respuesta recibida de una TSA.
¿Cómo saber si el timestamp es cualificado?
Hay que analizar el servicio que lo emitió.
No basta con que:
- utilice RFC 3161;
- el certificado sea válido;
- la TSA sea conocida;
- el token tenga una fecha correcta.
Para determinar la condición cualificada debemos comprobar el servicio concreto dentro de la correspondiente Trusted List.
Esto es especialmente importante si una aplicación necesita distinguir entre:
timestamp electrónico
y
timestamp cualificado eIDAS.
¿Quién debe generar PAdES-B-T: la TSA o la aplicación?
La TSA no convierte por sí sola el PDF en PAdES-B-T.
Su función es proporcionar la evidencia temporal.
La construcción correcta del perfil PAdES corresponde al software o servicio encargado de gestionar la firma.
Podemos separar responsabilidades:
TSA
Genera el TimeStampToken.
Motor de firma PAdES
Integra correctamente ese token dentro de la firma.
Validador
Comprueba posteriormente firma, timestamp, certificados y evidencias.
Servicio OCSP / CRL
Proporciona información sobre el estado de los certificados.
Esta separación arquitectónica evita atribuir al servicio TSA funciones que realmente corresponden al motor de firma.
¿Quién genera PAdES-B-LT?
De nuevo, no es la TSA por sí sola.
Para generar B-LT necesitamos combinar:
firma
timestamp
validación de certificados
cadena
OCSP / CRL
estructuras PAdES de validación.
Por tanto, B-LT requiere normalmente coordinación entre distintos componentes.
Arquitectura típica
Una arquitectura empresarial podría ser:
Aplicación
↓
Motor de firma
↓
certificado / HSM
↓
TSA
↓
motor de validación
↓
OCSP / CRL / Trusted Lists
↓
PDF PAdES-B-LT
Cada organización puede implementar estos componentes de distintas formas:
- internamente;
- mediante servicios cloud;
- mediante APIs;
- mediante infraestructuras híbridas.
Cómo encaja el servicio de sello de tiempo de edatalia
edatalia presta un servicio de sello de tiempo cualificado eIDAS basado en RFC 3161 que puede utilizarse como componente de una arquitectura de firma electrónica.
El servicio TSA proporciona el token temporal.
A partir de ahí, el sistema de firma puede incorporarlo al PDF dentro de perfiles PAdES.
edatalia dispone además de componentes relacionados con:
- firma electrónica;
- PAdES;
- validación de certificados;
- comprobación de firmas;
- conservación de evidencias.
La arquitectura concreta debe definirse según:
- tipo de firma;
- nivel PAdES requerido;
- volumen;
- política de certificados;
- requisitos regulatorios;
- conservación prevista.
¿Hay que enviar el PDF a edatalia para obtener un timestamp?
En un flujo RFC 3161 estándar, la TSA trabaja sobre el messageImprint contenido en la petición.
Esto permite que la aplicación mantenga el documento en su propia infraestructura y envíe únicamente la huella necesaria para generar el timestamp.
Esta característica resulta especialmente interesante para:
- Administraciones Públicas;
- Justicia;
- banca;
- sanidad;
- aseguradoras;
- documentos confidenciales.
El servicio de timestamp no necesita necesariamente actuar como repositorio documental.
PAdES-B-T en Administración Pública y Justicia
Los documentos administrativos y judiciales pueden tener periodos de conservación largos.
El timestamp puede resultar especialmente útil para aportar una referencia temporal independiente.
En el caso de Justicia, la Guía CTEAJE contempla expresamente el sellado temporal en diferentes escenarios relacionados con:
- firmas PDF;
- firma biométrica;
- validación;
- conservación a largo plazo.
Lo analizamos en CTEAJE y sello de tiempo en la Administración de Justicia.
Y para los procesos de preservación:
CTEAJE y PAdES-LT/LTA: conservación de firmas a largo plazo.
Errores frecuentes al añadir un sello de tiempo a un PDF
1. Pensar que cualquier timestamp significa PAdES-B-T
No. Debe incorporarse conforme al perfil correspondiente.
2. Pensar que PAdES-B-T significa timestamp cualificado
No necesariamente. El perfil técnico PAdES y la cualificación eIDAS son conceptos diferentes.
3. Pensar que B-T equivale a B-LT
No.
B-T aporta evidencia temporal.
B-LT añade además material para validar posteriormente la firma.
4. Añadir el timestamp demasiado tarde
Un timestamp actual no demuestra automáticamente que la firma existiera en la fecha declarada años atrás.
5. No validar el token recibido
La respuesta de la TSA debe comprobarse antes de incorporarla.
6. Olvidarse de OCSP y CRL
Timestamp y revocación responden a preguntas diferentes.
7. Confiar únicamente en servicios online futuros
Una URL OCSP disponible hoy puede no existir dentro de diez años.
8. Creer que B-LTA elimina cualquier mantenimiento futuro
La preservación criptográfica puede requerir nuevas evidencias con el paso del tiempo.
Preguntas frecuentes sobre PAdES-B-T y B-LT
¿Cómo añadir un sello de tiempo a un PDF?
La aplicación calcula la huella correspondiente, solicita un TimeStampToken a una TSA —habitualmente mediante RFC 3161—, valida la respuesta y la incorpora correctamente al documento.
¿Qué es PAdES-B-T?
Es el nivel PAdES Baseline que añade una evidencia temporal confiable que permite demostrar que una firma existente ya existía en una determinada fecha y hora.
¿Qué significa la T de PAdES-B-T?
Hace referencia a la incorporación de una evidencia temporal o trusted time token.
¿Un PDF con timestamp es automáticamente PAdES-B-T?
No. La evidencia debe estar incorporada conforme a los requisitos del perfil PAdES.
¿PAdES-B-T necesita un timestamp cualificado?
No necesariamente para cumplir técnicamente el perfil. La condición de timestamp cualificado es una característica adicional del servicio utilizado conforme a eIDAS.
¿Qué es PAdES-B-LT?
Es el nivel PAdES que incorpora dentro del documento el material necesario para validar posteriormente la firma, facilitando la disponibilidad a largo plazo de esas evidencias.
¿Qué diferencia hay entre B-T y B-LT?
B-T añade evidencia temporal. B-LT añade además certificados y material de validación como OCSP o CRL.
¿Qué es DSS?
El Document Security Store es una estructura de PDF utilizada para almacenar información necesaria para la validación de las firmas, como certificados, OCSP y CRL.
¿Qué es VRI?
Validation Related Information permite relacionar material de validación con firmas concretas dentro del documento.
¿Puede añadirse un timestamp después de haber firmado?
Sí, mediante procesos compatibles de augmentación. Pero un timestamp obtenido posteriormente demuestra que la firma ya existía en ese momento posterior, no necesariamente en la fecha originalmente declarada.
¿Puede pasar una firma B-B a B-T?
Sí, técnicamente puede augmentarse con una evidencia temporal conforme al perfil.
¿Puede pasar B-T a B-LT?
Sí, cuando es posible recopilar e incorporar correctamente todo el material de validación necesario.
¿Puede convertirse cualquier firma antigua en B-LT?
No necesariamente. Si faltan evidencias históricas y ya no es posible recuperarlas, un timestamp actual no puede reconstruir automáticamente el estado que tenía el certificado años atrás.
¿Un certificado caducado invalida una firma?
No automáticamente. Lo importante es poder determinar cuál era el estado del certificado en el momento relevante.
¿Un timestamp sustituye a OCSP?
No. El timestamp aporta evidencia temporal y OCSP aporta información sobre el estado del certificado.
¿Qué es PAdES-B-LTA?
Es un nivel orientado a preservar durante periodos todavía más prolongados la disponibilidad e integridad del material de validación mediante nuevas evidencias temporales.
¿Cuál es la diferencia entre signature timestamp y document timestamp?
El signature timestamp aporta evidencia temporal específicamente sobre una firma. El document timestamp protege una determinada revisión del documento y tiene especial importancia en estrategias de preservación y B-LTA.
¿La TSA recibe el PDF completo?
En un flujo RFC 3161 estándar, la TSA recibe fundamentalmente el messageImprint o huella correspondiente a los datos que deben sellarse, no necesariamente el documento completo.
¿edatalia ofrece sello de tiempo cualificado?
Sí. edatalia presta un servicio cualificado de sellado de tiempo integrable mediante RFC 3161 y utilizable dentro de arquitecturas de firma PAdES.
Añadir un timestamp es solo el primer paso hacia la larga duración
El proceso puede resumirse así:
PAdES-B-B
resuelve la firma básica.
↓
PAdES-B-T
añade evidencia sobre cuándo existía la firma.
↓
PAdES-B-LT
incorpora también el material necesario para validarla posteriormente.
↓
PAdES-B-LTA
permite continuar reforzando la conservación de esas evidencias.
Por eso la pregunta:
¿Cómo añado un sello de tiempo a un PDF?
tiene una segunda pregunta mucho más importante:
¿Para qué necesito ese sello de tiempo?
Si simplemente queremos una evidencia temporal, el objetivo puede centrarse en B-T.
Si el documento debe seguir pudiendo validarse años después, debemos pensar también en:
- certificados;
- cadena de confianza;
- OCSP;
- CRL;
- DSS;
- validación;
- y estrategias de conservación.
El timestamp no es el final del proceso.
Es el primer gran paso desde una firma básica hacia un documento preparado para mantener sus evidencias durante todo su ciclo de vida.
Sigue leyendo
¿Estás digitalizando tu proceso de firma?
Hablamos contigo y te enseñamos qué encaja en tu caso.