En Costa Rica, la “Política de Formatos Oficiales de los Documentos Electrónicos Firmados Digitalmente”, versión 1.0, indica en su punto 5, “Especificación de los Formatos Oficiales”, los formatos avanzados y configuración de niveles de los documentos firmados. Para el caso del formato PDF, indica que se basa en la norma técnica “ETSI TS 102 778”, indicado textualmente como “PAdES Long Term (PAdES LTV)”. Lo que hay entre paréntesis se refiere al perfil PAdES-LTV, que se especifica en la parte 4 de esa norma del ETSI (TS 102 778-4).

LTV puede resultar engañoso. Es un acrónimo que significa Long Term Validation o validación a largo plazo. Sin embargo, hay dos interpretaciones: la de los estándares del ETSI y la de Adobe. Y esto es un problema.

Quienes hayan utilizado Adobe Acrobat Reader DC para validar firmas digitales habrán visto en el panel de firmas el texto “Activada para LTV” o “No activada para LTV y expirará el xx/xx/xxxx”. De hecho, en las guías oficiales de validación en los sitios de mifirmadigital.co.cr o incluso en las de soportefirmadigital.com indican que este es el mecanismo para indicar si una firma tiene el nivel necesario, aunque discrepo y por esa razón escribo esta entrada de blog tratando de explicar por qué.

¿Qué es LTV, según Adobe?

No hay una definición oficial o documentada por parte de Adobe. Algunos empleados de esa empresa han indicado su opinión sobre qué entienden ellos por LTV para que su validador lo muestre. Una respuesta en StackOverflow sobre el significado de activación LTV detalla que lo que interpreta Adobe sobre activación LTV no solo no es lo mismo que PAdES-LTV sino que su validador Adobe Acrobat Reader DC puede interpretar documentos que cumplan perfectamente la especificación PAdES-LTV como que no están activados como LTV. No obstante, la herramienta Firmador hace uso de la librería implementación de referencia de la Unión Europea y en las pruebas realizadas con el validador de Adobe Acrobat Reader DC en sus últimas versiones, habría mejorado para ser más compatible con PAdES e incluso tiene un apartado algo escondido donde indica el nivel de firma PAdES Baseline, pero esto no se refleja en las guías de verificación de firma del país porque es un poco más complicado encontrarlo.

A su vez, validadores que no son de Adobe, como es el caso de la herramienta Firmador, pueden indicar que un documento no cumple con el nivel PAdES-LTV y sin embargo aparecer como “activada para LTV” en Adobe Acrobat Reader DC.

Si en Adobe Acrobat Reader DC se instalan los certificados intermedios en la lista de certificados confiados (tal y como sugiere la guía oficial de instalación de certificados para este programa), el documento puede mostrar para un documento PDF que su firma está activada para LTV, aunque el documento no contenga los certificados intermedios tal y como indica la especificación PAdES requerido para el nivel PAdES-LTV o también como lo menciona explícitamente la normativa nacional. Ni siquiera es necesario que el documento tenga un sello de tiempo a nivel firma, por lo que podría incluso ser un nivel tipo PAdES-B y aun así mostraría que está activada para LTV en Adobe Acrobat Reader DC. Si se instalara solamente el certificado raíz nacional y no los intermedios (como sería lo ideal) y se desconecta de Internet, la validación en Adobe Acrobat Reader DC probablemente fracasará, al no poder verificar CRL y OCSP en línea y también fallará al no poder descargar desde las URLs especificadas en la extensión Authority Information Access (AIA) los certificados intermedios faltantes. Los documentos firmados con la herramienta Firmador sí pueden validarse sin conexión a Internet, como otra demostración de que incluyen toda la información necesaria para su validación.

¿Qué es LTV, según ETSI? (PAdES-LTV)

PAdES-LTV es un nivel de perfil que está especificado en el el documento ETSI TS 102 778-4. De toda la norma, hay un punto especialmente importante que no contempla Adobe pero que sí está en el estándar y es necesario para cumplir con él. Sin embargo, pocos firmadores en el país realizan este procedimiento correctamente: el PDF firmado requiere que incluya al menos un sello de tiempo a nivel documento para cumplir con el nivel PAdES-LTV.

El sello de tiempo a nivel documento no es lo mismo que el sello de tiempo que llevan las firmas. Este sello cubre todo el documento, por lo que también cubre la información de revocación, para demostrar desde el momento que tiene el sello, la información no solo no se había modificado y por tanto que la información de validación de la firma (CRL y OCSP), sino que esta información existía así en ese momento, así como que los certificados eran vigentes y que todo ello era válido. Esto permite que aunque los certificados venzan, esta información siga siendo válida porque en su momento lo era. Esto está claramente especificado en la parte 4 de la norma, concretamente en el punto 4.2 párrafo b) y además indica en el anexo B que incluso en el nivel de perfil equivalente a CAdES-X-L debe llevar un sello de tiempo a nivel documento en los PDF.

Si un documento no incluye un sello de tiempo a nivel documento, cuando los certificados venzan, aunque la información fuera válida en su momento, el documento no podrá ampliar su nivel de firma a PAdES-LTV porque debería haberse añadido este sello de tiempo antes de que vencieran. No se resuelve intentando agregar este sello de tiempo cuando ya están vencidos. Un ejemplo práctico de este caso se puede comprobar con el validador de la herramienta Firmador y abriendo el documento PDF de la política de formatos oficiales. Aparecerá un error indicando que el estado de validación es indeterminado con el código de error interno “NO_POE”. PoE es Proof of Existence o prueba de existencia, que está especificado en nuevas normas técnicas de ETSI que indican formalmente qué significa el sello de tiempo a nivel documento y sus implicaciones. Lo que indica esta definición es que no hay manera de demostrar si los certificados intermedios eran válidos antes de que vencieran, en el hipotético caso de que pudiera comprometerse la seguridad y emitir nuevos certificados equivalentes para la infraestructura. En Costa Rica no hay una definición de validación basada en especificaciones técnicas que se publicaron después, aunque el documento de formato oficial indica claramente en el punto (5.2.2) un conjunto de atributos que son comunes a todos los perfiles AdES long term y que en el caso de Adobe en su validador de PDF puede indicar “activado para LTV” incluso aunque le falten los atributos de sello de tiempo, rutas de certificación e información de revocación dentro del documento.

Firmador, LTV y LTA

Los problemas con la confusión y acceso en aspectos de Firma Digital, más específicamente en documentos PDF, además de la falta de un software libre con código fuente de acceso público fueron las motivaciones por las que se creó la herramienta Firmador: disponer de una herramienta que firme y valide ajustándose lo mejor posible a los estándares y a la normativa de Costa Rica.

Tal y como indica la política de formato oficial del país, las implementaciones a medida pueden utilizar el perfil Baseline. Este perfil, especificado en la norma técnica TS 103 172 de ETSI, es bastante similar al anterior, aunque simplifica los niveles con ciertas equivalencias, por ejemplo el nivel B incorpora BES y EPES, el nivel X-L equivale a LT y el nivel A o LTV equivale LTA. Por este motivo, la herramienta validador puede mostrar PAdES-BASELINE-LTA en lugar de PAdES-LTV, ya que utiliza los nombres simplificados del nuevo estándar, aunque a efectos prácticos se trate prácticamente de lo mismo.

La Unión Europea financió la creación de una librería como implementación de referencia que permitiera firmar documentos llamada Digital Signature Services (no confundir con el estándar de la OASIS), que permite firmar con los formatos estándar XAdES, CAdES y PAdES, parte de los cuales son los estándares en Costa Rica, así como la validación, basada en nuevos estándares no contemplados por la normativa nacional hasta la fecha. Puesto que todo software puede contener errores, es conveniente utilizar siempre la versión más reciente de la librería. Por ejemplo, para la versión 5.4 de esta librería implementaron una opción para poder incluir sellos de tiempo de jerarquías no confiadas, ya que el servidor de la TSA del SINPE está firmado con la jerarquía de certificados nacional, entonces al agregar el nivel LT no se estaban incluyendo los certificados intermedios de la TSA y al realizar la validación LT sin conexión a Internet fallaba al no detectar los certificados intermedios que se utilizaban para el proceso de validación OCSP. También corrigen diversas vulnerabilidades, como las de tipo XXE.

Pueda o no gustar desarrollar en Java, que es con el lenguaje con el que se desarrolla esta implementación de referencia, es probablemente la mejor apuesta para trabajar con estos formatos, ya que simplifica enormemente el proceso de firma, requiriendo unas pocas líneas de código para firmar un documento, a diferencia de librerías como iText, con las que además se pueden agregar errores con facilidad con respecto a la especificación del formato.

Compatibilidad con las implementaciones

En el momento de escribir este artículo, el validador de documentos del Poder Judicial, bastante utilizado para presentar recursos en línea, no funciona correctamente cuando el documento incluye el sello de tiempo a nivel documento. Este problema se ha notificado al departamento correspondiente y se está a la espera de que se confirme una posible corrección.

Muchos firmadores no incluyen este sello de tiempo pero debería agregarse eventualmente por los motivos indicados. Si todavía son válidos, con la herramienta Firmador puede realizarse este procedimiento, no es necesario disponer de dispositivo de Firma Digital. Es conveniente que para un archivado longevo de documentos este proceso sea realizado por todas aquellas personas que almacenen documentos firmados.

La herramienta Firmador es capaz de firmar documentos sin conexión a Internet y agregar en otra ocasión todos los atributos necesarios sin intervención del firmante sino que lo puede hacer otra persona como puede ser quien reciba los documentos (receptor), tal y como indican los puntos 5.2.1 y 5.2.3 de la especificación del formato oficial de Costa Rica. Sin embargo, algunos validadores no reconocen bien la firma ampliada/extendida desde el nivel PAdES B-B a B-LTA posteriormente (lo que en el documento del formato oficial se refiere a “incluir los atributos” de niveles superiores), ya que agregar el sello de tiempo a la firma no se representa de la misma manera a como lo entienden los validadores de iText o el validador de Adobe, aunque este último sí reconocerá la inclusión de los atributos de la firma como “activada para LTV”.

Existen numerosos firmadores en el país que no agregan los atributos con los nombres adecuados y conforme al estándar, provocando que el validador que usa Firmador muestre la firma como PKCS7-T o similar en lugar de PAdES-T o superior. Aunque la firma básica sea válida en estos casos, no es conforme al estándar que rige. En estos casos en los que la firma no es conforme al estándar y no se resuelve extendiéndola, o en otros supuestos como de certificados vencidos y no extendida con sello de tiempo a nivel documento, la única solución pasa por eliminar la firma del documento y crear una nueva. Quizás en el caso en el que una especificación local relajara la exigencia sobre el formato de firma, un validador podría ser menos estricto por motivos de compatibilidad con documentos heredados de una herramienta que no se adaptó tan bien a los estándares en el pasado.

Conclusiones y recomendaciones

Es un hecho que debido a la evolución de las implementaciones del software y de los estándares se han ido acumulando dificultades en cómo deben firmarse los documentos de forma correcta y adaptada a los estándares. En los casos en que el software por ejemplo no indicaba si el LTV se refería al estándar PAdES y la falta de herramientas años atrás de mecanismos para validar si se estaba realizando correctamente causa estas asperezas, suponiendo que haya que realizar una mejora continua para actualizar los procesos que hagan uso de Firma Digital y tener conciencia de ello por parte de las personas encargadas en lo personal y en instituciones públicas y privadas.

El documento actual de la especificación del formato oficial está escrito cuidadosamente y de manera más sencilla posible para el entendimiento de personas no capacitadas técnicamente sobre cómo deben ser firmados los documentos, los tipos y especificaciones técnicas que deben cumplir y qué deben contener (atributos), así como lo más genérico posible para poder interpretarse en el futuro de forma compatible. Esto fue en 2013, cuando todavía en la Unión Europea no se había creado el estándar oficial eIDAS, que releva a las especificaciones previas, por ejemplo en el caso de PAdES las normas técnicas ETSI TS 102 778 (PAdES) y ETSI TS 103 172 (PAdES perfil baseline) se actualizan con el estándar europeo ETSI EN 319 142, publicado por primera vez en 2015 (donde se agrega el concepto de prueba de existencia). También apareció el primer estándar europeo para validar documentos AdES, el ETSI EN 319 102, basado en la norma técnica ETSI TS 119 102 que se sigue actualizando con enmiendas que posteriormente actualizarán el estándar.

Sería conveniente que ya que hoy en día se dispone de estándares y software de validación mejor regulado en la Unión Europea, actualizar la normativa costarricense para adoptar selectivamente lo que permita de forma equivalente para disponer de un mecanismo de validación más sólido. El software de implementación de referencia (Digital Signature Services) dispone de mecanismos ajustables para configurar de forma afinada qué puntos de la validación son requeridos u opcionales para poder configurarse de la forma más conveniente y adaptado a las necesidades nacionales.

Ejemplos de adaptación al sistema de validación ya existe en otros países fuera de la Unión Europea, como es el caso del Perú, que ya dispone de un sistema de validación nacional centralizado. Mientras no existan mecanismos precisos en Costa Rica, la herramienta Firmador utiliza los parámetros más predeterminados posibles (los utilizados en la Unión Europea) en el validador integrado, hasta que algún día, en caso de existir, pueda ajustarse a una normativa más precisa y local.

El motivo de regular la validación de forma más precisa permitiría disponer de mecanismos eficaces y más seguros para garantizar la seguridad y fiabilidad de los documentos firmados digitalmente, como es el caso de los documentos a largo plazo (el caso de los LTV aquí tratado), así como de cómo manejar la validación adecuadamente en la jerarquía nacional; por ejemplo si llega el caso en que nuevas autoridades de registro (RAs, certificados intermedios como el del BCCR) y se incorporasen al conjunto de jerarquías y documentos firmados bajo estas para validar. Sobre los aspectos de certificados intermedios y la forma de distribuirlos hay algunos aspectos que podrían mejorar también, pero eso será para otro artículo de blog.

La herramienta Firmador tiene previsto mejorar el reporte de validación de documentos para hacerlo más intuitivo y detallado. También está previsto este año publicar un validador web para quien quiera validar documentos sin necesidad de descargar software y que funcione en cualquier dispositivo que tenga conexión a Internet y un navegador web. Como en el caso de Firmador, se distribuirá como software libre, estando el código fuente del validador web para que cualquier persona pueda instalarlo en sus servidores y/o adaptarlo a sus necesidades.