Ningún sistema está exento de errores en su diseño, implementación y despliegue y en el caso de Costa Rica tampoco es una excepción. Este artículo presenta algunos aspectos técnicos que podrían mejorarse para que el conjunto del sistema nacional de Firma Digital, desde la raíz y pasando por las autoridades de registro y sus instaladores, resulte un poco más robusto.

Los certificados de la jerarquía deberían ofrecer servicio OCSP

Mencionado en un artículo anterior, pero relevante. Aunque esto podría suponer emitir nuevos certificados intermedios con esta característica, permitiría comprobar el estado de revocación de forma pronta y sin guardar información de CRLs si existe información de OCSP, ya que las CRL tienen un tamaño creciente.

Los mecanismos de comprobación de estado de revocación de la jerarquía deberían reducir el tiempo de nextUpdate

También mencionado en un artículo anterior, y corregible sin emitir nuevos certificados intermedios, permitiría comprobar el estado de revocación de todos los certificados intermedios sin tener que esperar hasta 3 meses, para tener información de revocación (Long Term) en los niveles AdES-LT. Sería sugerible que se actualizaran como mucho cada 24 horas para poder agregar la información LT al no disponer de OCSP para todos los intermedios.

El instalador de Firma Digital no debería instalar certificados intermedios

Solamente debería instalarse el certificado raíz nacional del MICITT. Los certificados intermedios, cuando se agregan como de confianza en el sistema, se pueden interpretar como anclaje de confianza y no terminar de comprobar la revocación de los intermedios. A su vez, los firmadores podrían no incluir todos los intermedios porque el primer anclaje de confianza sería suficiente, pero no son certificados raíz.

Los certificados intermedios se pueden obtener mediante la extensión AIA (descargables por Internet) para incrustarlos en el documento al usar firma avanzada al firmar o al validar, pero la mejor solución no requiere Internet y está explicada en el siguiente punto que ofrece una solución adecuada que de hecho actualmente ofrecen las tarjetas de firma europeas.

Las tarjetas de Firma Digital deberían incluir los certificados intermedios en el almacén de certificados del propio chip

De esta forma se ahorra consultas de descarga de certificados por extensión AIA, pudiendo incrustarse en el documento sin conexión a Internet.

El validador de Central Directo indica erróneamente que la fecha de firma corresponde con la del sello de tiempo que acompaña a la firma

Los sellos de tiempo a nivel firma son atributos no firmados y pueden quitarse y agregarse, permitiendo mostrar un sello de tiempo con una fecha posterior, ya que los servicios de sellos de tiempo los puede utilizar cualquier persona. Los sellos de tiempo se utilizan para indicar que el documento firmado existía en un momento determinado, que no es lo mismo que la firma de la persona se haya realizado en un momento determinado. En Estonia también han tenido problemas, en este caso en la ley, por interpretar incorrectamente esto. Más información en https://cybersec.ee/timesign/ y en este video demostrativo: https://www.youtube.com/watch?v=ysYouhl1Yx4

El instalador de Firma Digital debería volver a incluir el certificado raíz de la jerarquía SHA-1

Sin este certificado, que además todavía no ha vencido, no se puede validar la confianza (anclaje de confianza) de documentos firmados digitalmente antiguos. Aunque SHA-1 sea débil, no necesariamente los certificados hijos lo son, es más, podría haberse emitido uno SHA-2 intermedio nuevo y no tener que actualizar la CA raíz. Así están funcionando muchos certificados comerciales todavía hoy. Mediante firmas cruzadas podría haberse transicionado a una nueva CA raíz SHA-2 y preservar la anterior.

El validador de Central Directo debería dar como válidos documentos con certificados revocados si el certificado era válido en el momento de firmar

Actualización: Esta situación ya fue corregida en el validador del del BCCR.

Una de las razones de la existencia de la firma avanzada es poder garantizar que en el pasado, cuando se agregó la información de revocación (CRL y OCSP), en ese momento era válida. Hay que recordar que el sello de tiempo permite garantizar la fecha mínima de la existencia de una firma, y que las listas de revocación CRL y el estado de revocación OCSP están firmados digitalmente, donde agregando el sello de tiempo a nivel A o LTA (LTV) posterior a nivel documento garantizan que la fecha mínima de existencia de esos certificados era válida para todos los certificados involucrados.

Si posteriormente se revoca el certificado, aunque en el presente esté revocado, no implica que en el pasado no sea válido, solo no es válido desde el momento que se revoca, porque a la hora de firmar la información de revocación de firma avanzada indicará que no es válido para esos nuevos documentos. Es por esto que el validador de Central Directo del BCCR debería corregir su validador.

El firmador de BCCR / Central Directo debería firmar documentos PDF con el formato ETSI.CAdES.detached

Este formato es más estricto y específico que adbe.pkcs7.detached. La especificación PAdES exige el uso del mencionado.

La política de formato oficial podría actualizarse para incorporar normas técnicas de validación

Esto permitiría que no haya tantas diferencias entre las implementaciones de los validadores del país, que fallan al validar documentos firmados con firmadores que se supone que cumplen con normas recogidas en las propia política de formato oficial.

Las tarjetas de Firma Digital requieren un middleware privativo para funcionar

Esto dificulta la portabilidad a sistemas que no estén basados en arquitecturas Intel x86, ya que no se dispone de una librería compilada para ARM, MIPS, u otros. Esto obligaría a la comunidad a realizar su propio controlador por ingeniería inversa para lograr interoperabilidad con los applets que corren en el chip con otros sistemas operativos y procesadores. Todavía no se ha lanzado un firmador para Android mediante NFC o por lo menos mediante USB OTG o tipo C porque la mayoría de dispositivos móviles no llevan procesadores compatibles con arquitectura Intel x86.

Conclusión y recomendaciones adicionales

Estos son algunos puntos que ojalá se tengan en cuenta para la mejora continua de este importante servicio, que por su propia naturaleza compleja requieren revisión y actualización para cubrir nuevos hallazgos y refuerzos ya reflejados en normativas internacionales.

Cobra especial relevancia disponer de información técnica más precisa sobre el proceso de firma avanzada, información de revocación y sellos de tiempo especialmente para el correcto archivado longevo y garantizar su validación pasados los años, que probablemente en la actualidad no se esté realizando de la mejor forma posible en las instituciones dedicadas al almacenamiento a largo plazo de documentos digitales y evitar posteriores contingencias.

Documentar técnicamente un compendio de buenas prácticas y errores habituales mitigaría los riesgos asociados a que los validadores presenten inconsistencias a medio plazo. Mantener actualizada esta documentación con los cambios que requieran las nuevas normas nacionales e internacionales (nuevos cifrados, cómo aplicar nuevos sellos, migrar el respondedor OCSP para aceptar CertID con SHA-2 que hoy no cumple, etc.).