El pasado mes de marzo de 2008, Albalia Interactiva participó en las primeras pruebas remotas de interoperabilidad de ETSI (Remote XAdES Interoperability event on the XAdES Plugtest Portal) con su producto BackTrust, lo que ya comenté en este blog.
Tras el verano tuvo lugar el segundo “ETSI remote plugtest” sobre firma electrónica XAdES, en el que también participó Albalia. Empezó el día 8 de Septiembre de 2008, y terminó el 17 del mismo mes.
Ha contado con 21 participantes de los más diversos países, tales como Japón, Hungría, Rumania, Macao, Francia, Alemania, Austria, Estonia, Belgica y España.
Los primeros «plugtest» fueron presenciales y se celebraron en Noviembre del 2003 y en mayo de 2004. Los participantes viajaron a la sede de ETSI en Francia en donde colaboraron probando mutuamente sus soluciones y desarrollando código sobre la marcha para ir cubriendo los problemas detectados.
En la primera edición presencial se citaron en Sophia Antipolis tan sólo 5 participantes. En la segunda el número de participantes ascendió a 11.
Después de éste evento hubo un parón hasta que en Marzo del 2008 se realizó el tercero (primero en la versión remota, que permite que los participantes trabajen desde sus oficinas y se coordinen con llamadas internacionales y chats) con la lista más amplia de participantes, que en este caso alcanzó el número de 28. Albalia Interactiva participó por vez primera, poniendo a prueba su herramienta BackTrust. El siguiente Plugtest (quinto de la serie, tercero en la versión remota) se va a realizar en Febrero del 2009, y en este caso va a permitir probar tanto las modalidades de firma XAdES como CAdES.
Un Plugtest de este tipo sirve indirectamente para que los distintos participantes pongan a prueba sus herramientas de firma XAdES. Los organizadores generan una serie de documentos firmados (materiales criptográficos) y despliegan servicios online de PKI para conseguir los perfiles de firma de los participantes, servicios de CRLs, de OCSPs, y dictan una serie de tipos de firma, (en este caso todas detached), que van desde XAdES BES a XAdES A, con bastantes variantes.
Los participantes deben realizar las distintas firmas y validar las de los demás usuarios, de tal modo que cualquier firma de un participante pueda ser validada por los demás.
En ambos Plugtest la suite de productos BackTrust de Albalia Interactiva ha realizado una buena participación, con firmas electrónicas verificadas por bastantes de los participantes, y demostrando su capacidad de verificar las firmas de la mayor parte de los participantes.
Uno de los objetivos del Plugtest, es el de conseguir un estándar claro y conciso de los formatos de firmas electrónicas XAdES, de tal forma que todo el mundo pueda realizar y verificar firmas de la misma forma y no existan incongruencias ni distintas interpretaciones del estandar. Para ello todos los participantes pueden comentar posibles cambios, dudas y ampliaciones del estándar, se discute sobre cada una de las cuestiones que surgen durante la duración del Plugtest, y se dan soluciones a dichas cuestiones si se llega a un consenso, o se deja la cuestión para el siguiente congreso de XAdES en el que pueda fundamentarse el debate y la solución.
Todo es electrónico 
Pingback: Firma electrónica en zEnterprise EC12 « Todo es electrónico
Pingback: Caixa Galicia, caso de éxito « Todo es electrónico
Pingback: Diseño y planificación de una infraestructura de clave pública (PKI) « Todo es electrónico
Pingback: Crypto Express3 en zEnterprise « Todo es electrónico
Pingback: zBackTrust en Caixa Galicia « Todo es electrónico
Pingback: 10 años de Linux en System z. Madrid, 26 de Mayo « Todo es electrónico
Pingback: Caixa Galicia impulsa la tecnología financiera « Todo es electrónico
Pingback: Estándares de firma electrónica « Todo es electrónico
Pingback: Albalia es Advanced Partner de IBM « Todo es electrónico
Pingback: Características de zBackTrust « Todo es electrónico
Pingback: XAdES/CAdES ETSI Plugtest « Todo es electrónico
Estimado Julián,
Con validación me refiero a la validación de las firmas, no de los certificados (aunque la validación de la firma incluya la validación de los certificados que se hayan empleado).
Varias CAs incluyen servicios de validación de firmas, que más allá de validar un certificado en sí, comprueban y validan toda una firma PKCS7 o XADES, devolviendo un token de validación que incluye el OK o «fail», los tokens OCSP, así como un sello de tiempo vinculado al acto de verificación de la firma.
¿Qué significa ésto? Pues que la propia CA que expide el certificado responde de la validez de dicha firma generada, lo que genera mayor confianza a los usuarios no expertos.
Insisto en que una cosa es que a la hora de emplear un certificado se compruebe su validez, otra cosa es aplicar un sello de tiempo sobre una firma y otra mejor aún es lo que comento aquí, que la CA emita un «certificado» de validez de una firma generada.
Ésto último en particular lo lleva a cabo tanto @Firma, como PSIS, como la ACCV. Con estas entidades está integrada nuestra solución de gestión digital, Firmadoc BPM. Realmente nos quita un peso de encima considerable en multitud de debates sobre confianza, que se suelen convertir en tecno-charlas.
Ramiro,
Creo que estamos hablando de diferentes tipos de interoperabilidad.
En este caso se trata de que los desarrolladores participantes generan diferentes tipos de firmas (ya sabes que tenemos las variantes BES, EPES, ES-T. ES-C, ES-X, ES-X-L, ES-A y varias subvariantes) sobre un material criptográfico predefinido y comprueban las firmas generadas por todos los demás participantes. Se trata de cerciorarse de que uno mismo «firma bien» y de que comprueba correctamente las firmas de otros.
En general, siempre que se pueda, debería obtenerse la respuesta OCSP del propio PSC en los tipos de firma que incluyen validación. Sin embargo, a veces, los certificados no codifican correctamente la fuente OCSP o no está disponible (porque el PSC solo utiliza CRL´s). En ese caso es muy práctico contar son servidores de validación «universales», como @firma en la administración pública, PSIS en el caso de las administraciones catalanas o Certiver o EADTrust para el sector privado.
Me parece muy interesante, no obstante, en el ámbito de las Administraciones Públicas, y en concreto en los Entes Locales, y en pro de la proliferación de de soluciones de e-admin, lo más apropiado es que quien valide las firmas generadas por el aplicativo (tengan el formato que tengan) sean las propias entidades de certificación, emitiendo el correspondiente token de validación que ofrece mayor seguridad subjetiva que cualquier «claim» de que una solución sea muy, muy interoperable.
A fecha de hoy, aún están haciendo esfuerzos en adaptar sus sistemas para validar firmas XADES-X-L.
Tengamos en cuenta que en España hay más de 8000 entes locales territoriales, cada uno con sus dudas e inquietudes particulaes, y lo deseable es que la confianza esté consolidada institucionalmente. Por ejemplo, nadie se plantea la validez del formato facturae (aunque a nivel internacional la versión 3.1 y anteriores sean documentos obscuros).