Módulo de firmas XML. Esta obra está bajo una licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 Unported. Módulo de firmas XML

Transcripción

1 Módulo de firmas XML Esta obra está bajo una licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 Unported. Módulo de firmas XML Página 1 de 66

2 Índice 1 Introducción Objetivos Formatos de firma soportados Matriz de formatos soportados por el módulo Uso de los parámetros de funcionamiento Parámetros de funcionamiento XML Digital Signature (XMLDSig) XMLDSig Detached XMLDSig Enveloping XMLDSig Enveloped Co-Firmas en XMLDSig Contrafirmas en XMLDSig XML Advanced Digital Signature (XAdES) Factura Electrónica Open Document Format (ODF) Office Open XML (OOXML) Información sobre el módulo Compatibilidad Situación del nodo de firma en XAdES Enveloped Metadatos adicionales en las firmas XAdES Cadena de certificación en firmas XMLdSig y XAdES Firmas de contenido binario en XMLDSig y XAdES Firma de hojas de estilo en XMLDSig y XAdES Notas importantes sobre la firma de hojas de estilo XML Transformaciones XML Incidencias conocidas Mensajes extraños en consola Diferencias en las firmas generadas respecto a versiones anteriores del cliente y sus módulos Ejemplos de Estructuras XML generadas por el módulo XMLDSig Detached Interno Explícito / Implícito Enveloping Explícito / Implícito Enveloped Co-Firmas Contrafirmas XAdES Detached Interno Explícito / Implícito Enveloping Explícito / Implícito Enveloped Co-Firmas Contrafirmas Distintas versiones de XAdES Información de utilidad Glosario de términos Creative Commons Módulo de firmas XML Página 2 de 66

3 1 Introducción El Cliente de Firma es una herramienta de Firma Electrónica que funciona en forma de Applet de Java integrado en una página Web mediante JavaScript. El Cliente hace uso de los certificados digitales X.509 y de las claves privadas asociadas a los mismos que estén instalados en el repositorio o almacén de claves y certificados (keystore) del navegador web (Internet Explorer, Mozilla, Firefox) o el sistema operativo así como de los que estén en dispositivos (tarjetas inteligentes, dispositivos USB) configurados en el mismo (el caso de los DNI-e). El Cliente de Firma, como su nombre indica, es una aplicación que se ejecuta en cliente (en el ordenador del usuario, no en el servidor Web). Esto es así para evitar que la clave privada asociada a un certificado tenga que salir del contenedor del usuario (tarjeta, dispositivo USB o navegador) ubicado en su PC. De hecho, nunca llega a salir del navegador, el Cliente le envía los datos a firmar y éste los devuelve firmados. El Cliente de Firma contiene las interfaces y componentes web necesarios para la realización de los siguientes procesos (además de otros auxiliares como cálculos de hash, lectura de ficheros, etc ): Firma de formularios Web (siendo tarea del integrador el crear la lógica JavaScript para ello). Firma de datos y ficheros. Multifirma masiva de datos y ficheros. Cofirma (CoSignature) Multifirma al mismo nivel. Contrafirma (CounterSignature) Multifirma en cascada. Como complemento al cliente de firma, se encuentra un cliente de cifrado que nos permite realizar las funciones de encriptación y desencriptación de datos atendiendo a diferentes algoritmos y configuraciones. Además permite la generación de sobres digitales. Módulo de firmas XML Página 3 de 66

4 2 Objetivos El objetivo del presente documento es reflejar las capacidades del en cuanto a firmas electrónicas basadas en formatos XML (Extensible Markup Language), las peculiaridades de este relativas a estos formatos, sus opciones de configuración y su compatibilidad. Módulo de firmas XML Página 4 de 66

5 3 Formatos de firma soportados 3.1 Matriz de formatos soportados por el módulo Firma XMLDSig Cofirma Contrafirma Firma XAdES Cofirma Contrafirma Factura-e Firma Leyenda: Detached Enveloping Interna Externa Implícito Explícito Implícito Explícito Implícito Explícito Soportado y acorde a estándar Soportado No soportado No contemplado en el estándar Enveloped Implícito Dentro de la normativa XAdES, la versión actual del módulo soporta únicamente las variante básica, conocida como XAdES BES y la acorde a política de firma, EPES, no soportándose ninguna otra (X, XL, etc.): Variante BES EPES T C X XL A Adicionalmente, el módulo es capaz de hacer firmas XML según la normativa Open Document Format (ODF) acorde con la implementación de OpenOffice.org 3.2 y superiores. Si bien las firmas OpenOffice.org 3.0 y 3.1 no son compatibles con las firmas LibreOffice / OpenOffice.org 3.2 y superiores (por defecto estas últimas en el es posible forzar la generación de firmas en el formato OpenOffice.org 3.0/3.1. Consulte la documentación JavaDoc de la clase es.gob.afirma.signers.odf.aoodfsigner para mayor información sobre los parámetros adicionales en este sentido. Debemos recordar que los documentos ODF están basados en XML, y sus firmas digitales son una variante de XMLDSig. La matriz de compatibilidad (siguiendo la misma leyenda que la matriz anterior), es la siguiente: Módulo de firmas XML Página 5 de 66

6 Firmas Cofirma Contrafirma OpenOffice.org / En el caso de las cofirmas sobre documentos ODF, estas deben tratarse como la aplicación de varias firmas al mismo documento a un mismo nivel jerárquico, en lo que también puede llamarse multifirma de un documento. Otra variante de firmas XML soportada por el Cliente es OOXML, formato de documentos ofimáticos de Microsoft Office 2007, 2008 for Mac, 2010 (x86 y x64) y 2011 for Mac. La matriz de compatibilidad (siguiendo la misma leyenda que la matriz anterior), es la siguiente: Firmas Cofirma Contrafirma Microsoft Office En el caso de las cofirmas sobre documentos OOXML, estas deben tratarse como la aplicación de varias firmas al mismo documento a un mismo nivel jerárquico, en lo que también puede llamarse multifirma de un documento. Módulo de firmas XML Página 6 de 66

7 3.2 Uso de los parámetros de funcionamiento Los formatos de firma XML (XAdES, XMLDSig, Factura-e, ODF y OOXML) está únicamente disponible en las construcciones Media y Completa del cliente de firma. Para realizar una firma en este formato sólo es necesario su configuración como formato de firma mediante el método del Applet cliente: setsignatureformat(string format) Puede llamarse a esta función desde las páginas Web que integren el cliente por medio de la sentencia JavaScript: clientefirma.setsignatureformat(string format) Esto configurará el cliente de firma para realizar alguna de las firmas XML (consultar el apartado Parámetros de funcionamiento, para conocer las referencias concretas para cada uno de los formatos), siendo necesario también completar la configuración del cliente que se considere necesaria (algoritmo de firma, modo, tratamiento de errores, ), establecer los datos que se desean firmar y ordenar el proceso de firma. Esta y el resto de funciones del cliente están documentadas en el JavaDoc del Applet y el manual del integrador del Remítase a estos documentos para más información. 3.3 Parámetros de funcionamiento Cadenas de identificación de formato (varias alternativas insensibles a mayúsculas y minúsculas por cada formato, por flexibilidad de uso): XAdES Detached Interna ο "XAdES Detached" / "XAdES_Detached" / "XADES" / "XADES-BES" XAdES Enveloped ο "XAdES Enveloped" / "XAdES_Enveloped" XAdES Enveloping ο "XAdES Enveloping" / "XAdES_Enveloping" XMLDSig Detached Interna ο "XMLDSig Detached" / XMLDSig Enveloped "XMLDSig_Detached" ο "XMLDSig Enveloped" / "XMLDSign Enveloped" / "XMLDSig_Enveloped" / "XMLDSig_Enveloped" XMLDSig Enveloping ο "XMLDSig Enveloping" / "XMLDSign Enveloping" / "XMLDSig_Enveloping" / "XMLDSign_Enveloping" Factura-e Módulo de firmas XML Página 7 de 66

8 ο "FacturaE" / "Factura-e" / "Factura Electronica" / "Factura Electrónica" / "Factura" ODF ο "ODF" / "ODT" / "ODP" / "ODS" / "OpenOffice" / "OpenOffice.org" OOXML ο "OOXML" / "OOXML (Office Open XML)" / "DOCX" / "PPTX" / "XLSX" Cadenas de identificación del modo de firma (insensibles a mayúsculas y minúsculas): Explícita (no aplica a las contrafirmas) ο Implícita ο "Explicit" "Implicit" Ficheros de entrada XMLDSig y XAdES, Enveloping y Detached, Implícitas y Explícitas ο Binarios (*.*) y XML (*.xml) XMLDSig y XAdES, Enveloped ο ODF ο XML (*.xml) ODF (*.odt, *.ods, *.odp) OOXML ο Ficheros de salida XAdES ο OOXML (*.docx, *.pptx, *.xlsx) Fichero de firma avanzada (*.xsig) XMLDSig ο ODF ο Fichero de firma (*.xsig) ODF (*.odt, *.ods, *.odp) OOXML ο OOXML(*.docx, *.pptx, *.xlsx) Módulo de firmas XML Página 8 de 66

9 NOTAS IMPORTANTES: Los algoritmos de huella digital MD2 y MD5 no están soportados en ninguno de los formatos y variantes de firma aportados por este módulo, por motivos de obsolescencia. Esta es una limitación impuesta por los estándares y normativas afectadas. En las operaciones de firma, las algoritmos de huella digital SHA-256, SHA-384 y SHA-512 no están soportados en ningún sistema basado en CAPI (Windows + Internet Explorer) con versiones de Java que sufran el error ( ni, aun sobre sistemas diferentes a CAPI, en los entornos de ejecución de Java anteriores a la versión 1.6u18. El algoritmo de huella digital SHA-224 no está soportado, y no se soportará en un futuro. No se soportan firmas XML sin realizar huellas digitales, por no estar contemplada esta posibilidad en ninguna normativa ni estándar. No se soporta la firma en más de una fase en ningún formato o variante de firma realizado por este módulo. Ciertos entornos de ejecución de Java (Java 1.6 anteriores a la versión 1.6.0_10) están afectados por un error ( que impide la realización de firmas de documentos ODF. Es necesario un Java 6 en versión superior a la 1.6.0_10 para realizar firmas ODF. Este error no se da en Java 5, por lo que sus usuarios no necesitan actualizar (aunque siempre se recomienda la actualización a Java 1.6.0_25). Módulo de firmas XML Página 9 de 66

10 3.4 XML Digital Signature (XMLDSig) XMLDSig Detached La firma XML en modo Detached permite tener una firma de forma separada e independiente del contenido firmado, pudiendo relacionar firma con contenido firmado mediante una referencia de tipo URI. Este tipo de firmas es útil cuando no se puede modificar el contenido original pero se desea constatar su autenticidad, procedencia, etc. Un uso común de este formato es en la descarga de ficheros, pudiendo poner a disposición del internauta, junto al contenido a descargar, un pequeño fichero de firma para verificar la integridad del primero. Un ejemplo de este tipo de firmas sería la siguiente estructura (resumida) XML: <?xml version="1.0" encoding="utf-8"?> <ds:signature xmlns:ds=" <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" <ds:signaturemethod Algorithm=" <ds:reference URI=" <ds:digestmethod Algorithm=" <ds:digestvalue/> </ds:signedinfo> <ds:signaturevalue/> </ds:signature> En este ejemplo, los datos firmados se encuentran en un servidor Web accesible públicamente: y se referencia como tal, conformando lo que se denomina Externally Detached o Detached Externa. Las firmas Externally Detached NO están soportadas actualmente por el Cuando se desea firmar un contenido con un formato Detached, pero se quiere eliminar la dependencia de la disponibilidad externa del contenido firmado, es posible crear una estructura XML que contenga los propios contenidos y la firma, pero cada uno en una subestructura independiente, manteniendo así el concepto de Detached (firma y contenido firmado no se interrelacionan directamente). Para adecuarse al estándar los nodos de firma y contenido debe encontrarse en el mismo nivel dentro del XML. Módulo de firmas XML Página 10 de 66

11 Un ejemplo de estructura XML sería: <?xml version="1.0" encoding="utf-8"?> <internally-detached> <ds:signature xmlns:ds=" <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" <ds:signaturemethod Algorithm=" <ds:reference URI="#data"> <ds:digestmethod Algorithm=" <ds:digestvalue/> </ds:signedinfo> <ds:signaturevalue/> </ds:signature> <document Id="data"> <title>title</title> <author>writer</author> <date>today</date> <content> <para>first paragraph</para> <para>second paragraph</para> </content> </document> </internally-detached> En este caso, la estructura internally-detached contiene dos subestructuras, la firma ( Signature ) y el propio contenido firmado ( document ). La forma de relacionar ambos es, como ocurría en el primer ejemplo, con una URI, solo que en este caso es interna al documento XML, referenciando el identificador de la subestructura del contenido firmado ( data ). A esta variante de firma Detached se la conoce como Internally Detached, o Detached Interna. 1 1 Ejemplos y nomenclatura de XMLDSig Detached 2009 Microsoft Corporation Módulo de firmas XML Página 11 de 66

12 Para unificar las superestructuras creadas dentro de un formato Detached Interno, el construye siempre el siguiente esqueleto XML: <CONTENT Id= id Encoding= codificacion MimeType= MimeType Algorithm= > <! CONTENIDO FIRMADO --> </CONTENT> Es decir, el contenido a firmar, ya sea XML o no-xml, se encapsula dentro de una etiqueta XML llamada CONTENT, en la que se indica la codificación del contenido (UTF-8, Base64, etc.), el tipo de contenido (imagen JPEG, texto, XML, etc.) y el algoritmo utilizado para calcular la huella digital de este (por ejemplo, SHA-1). Como la superestructura es XML, si el contenido también es XML la inserción es directa (como en el primer ejemplo de Detached Interna, pero si no es XML se codifica en Base64 antes de insertarse, resultando una estructura con una forma similar a la siguiente: <CONTENT Id= id Encoding= Base64 MimeType= application/octect-stream Algorithm= > SFGJKASGFJKASEGUYFGEYGEYRGADFJKASGDFSUYFGAUYEGWEYJGDFYKGYKGWJKEGYFWYJ </CONTENT> La larga cadena de caracteres sería una codificación Base64 del original interpretado en su forma binaria pura. Como la variante Detached Interna almacena dentro de la superestructura XML el contenido firmado, la firma de un contenido de gran tamaño generaría igualmente un fichero de firma de gran tamaño, aspecto claramente no deseable (especialmente en un formato Detached ), por lo que este módulo introduce una sub-variante llamada Detached Interna Explícita (quedando la anteriormente descrita como Detached Interna Implícita. En esta sub-variante, se sustituyen los datos firmados (ya sean binarios o XML) dentro de la superestructura XML que los contenía tanto a ellos como a la firma por su huella digital calculada mediante el algoritmo SHA-1, y codificada en Base64. Es importante reseñar aquí que la sub-variante Detached Interna Explícita no está respaldada directamente por el estándar XML Digital Signature (aunque su estructura interna cumple con el formato). Adicionalmente, esta variante explícita no es de aplicación para las contrafirmas. Debido a que las firmas Detached Internas, tanto explícita como implícita, comparten la misma estructura y no es posible distinguirlas, el cliente marcará las firmas explícitas con el MimeType no estándar hash/sha1, independientemente de que se especifique el MimeType de los datos. En caso de generar la firma explícita indicando directamente al el hash que debe firmar en lugar de los datos, este debe proporcionarse siempre calculado con el algoritmo SHA1. La importancia de recalcar este punto reside en que un validador de firmas XMLDSig estándar dará siempre por buena la firma Detached Explícita, pero no la validará contra el contenido original, por lo que debemos asegurarnos o que se soporta ésta sub-variante o que la validación se realiza contra la huella digital del contenido firmado y luego se compara esta huella digital con una obtenida directamente de este último. Módulo de firmas XML Página 12 de 66

13 3.4.2 XMLDSig Enveloping Otra variante de firma es la Enveloping, en la que la estructura XML de firma es la única en el documento de firma, y esta contiene internamente el contenido firmado (en un nodo propio). Un posible ejemplo de este tipo de firma podría ser: <?xml version="1.0" encoding="utf-8"?> <ds:signature xmlns:ds=" <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" <ds:signaturemethod Algorithm=" <ds:reference URI="#obj"> <ds:digestmethod Algorithm=" <ds:digestvalue/> </ds:signedinfo> <ds:signaturevalue/> <ds:object Id="obj">SFGJKASGFJKASEGUYFGEYGEYRGADFJKASGDFSUYFG=</ds:Object> </ds:signature> En este caso, los datos firmados se encuentran en el nodo Object referenciados internamente al XML mediante el identificador obj. 2 Al igual que ocurría con el formato Detached, si los datos no son XML, no es posible insertarlos directamente dentro de una estructura XML, por lo que se codifican previamente en Base64. Al contener el resultado de la firma los datos firmados empotrados internamente, esta formato sufre el mismo problema que la variante Detached Interna (Implícita), por lo que también se ha optado por incluir una sub-variante denominada Enveloping Explícita (definiendo la Enveloping como Enveloping Implícita ), en la que de nuevo se sustituyen los datos originalmente firmados por su huella digital calculada mediante el algoritmo SHA-1. Es importante reseñar aquí que la sub-variante Enveloping Explícita no está respaldada directamente por el estándar XML Digital Signature (aunque su estructura interna cumple con el formato). Adicionalmente, esta variante explícita no es de aplicación para las contrafirmas. La importancia de recalcar este punto reside en que un validador de firmas XMLDSig estándar dará siempre por buena la firma Enveloping Explícita, pero no la validará contra el contenido original, por lo que debemos asegurarnos o que se soporta esta sub-variante o que la validación se realiza contra la huella digital del contenido firmado y luego se compara esta huella digital con una obtenida directamente de este último. 2 Ejemplos de XMLDSig Enveloping 2009 Microsoft Corporation Módulo de firmas XML Página 13 de 66

14 Debido a que las firmas Enveloping explícita e implícita comparten la misma estructura y no es posible distinguirlas, el cliente marcará las firmas explícitas con el MimeType no estándar hash/sha1, independientemente de que se especifique el MimeType de los datos. En caso de generar la firma explícita indicando directamente al el hash que debe firmar en lugar de los datos, se firmará este hash y se establecerá como MimeType el valor hash/sha1. Módulo de firmas XML Página 14 de 66

15 3.4.3 XMLDSig Enveloped Este formato de firma XMLDSig está pensado para que un contenido XML pueda auto-contener su propia firma digital, insertándola en un nodo propio interno, por lo que, al contrario que en los formatos anteriores, no es posible firmar contenido que no sea XML. Un ejemplo simple del resultado de una firma Enveloped podría ser el siguiente: <!DOCTYPE Envelope [ <!ENTITY ds " <!ENTITY c14n " <!ENTITY enveloped " <!ENTITY xslt " <!ENTITY digest " ]> <Letter> <Return-address>address</Return-address> <To>You</To> <Message>msg body</message> <From> <ds:signature xmlns:ds="&ds;"> <ds:signedinfo> <ds:canonicalizationmethod Algorithm= " <ds:signaturemethod Algorithm= " <ds:reference URI=""> <ds:transforms> <ds:transform Algorithm="&enveloped;"> </ds:transform> </ds:transforms> <ds:digestmethod Algorithm="&digest;"/> <ds:digestvalue></ds:digestvalue> </ds:signedinfo> <ds:signaturevalue/> </ds:signature> </From> <Attach>attachement</Attach> </Letter> En este caso, el documento original ( Letter ), contiene internamente la estructura de firma digital ( Signature ). 3 Una peculiaridad de la estructura generada es que esta referenciada mediante una URI vacía ( URI= ), lo cual indica que la firma aplica a la totalidad del documento original. 3 Ejemplos de XMLDSig Enveloped 2009 Microsoft Corporation Módulo de firmas XML Página 15 de 66

16 Aunque en este caso el módulo no ha definido sub-variantes, para mantener una coherencia en la nomenclatura, ha denominado a este formato Enveloped Implícita Co-Firmas en XMLDSig Cuando un mismo documento es firmado (en una misma jerarquía de firma) por varios firmantes, de produce una operación de co-firma. A nivel interno, una co-firma no es más que una sucesión de objetos o estructuras XML de tipo Signature (como los que figuran en los ejemplos anteriores) que se refieren a los mismos datos. Las co-firmas XMLDSig pueden aplicarse a todos los formatos y variantes del estándar. El módulo de firmas XML del permite co-firmas en todas las variantes y subvariantes soportadas de XMLDSig. Cofirmas Enveloping Una firma XML enveloping exige que los datos firmados estén contenidos en un nodo XML dentro de la propia firma. Cuando se solicita una cofirma XML enveloping al se generará un nodo raíz <AFIRMA> que contendrá todas las firmas generadas. Cada una de las firmas contendrá su propio nodo de datos, por lo que este tipo de firmas puede crecer rápidamente en tamaño. Se recomienda utilizar las firmas Internally Detached cuando se quieran realizar múltiples firmas sobre los mismos datos y que estos contenidos en la firma. Este comportamiento aplica tanto a XMLDSig como a su variante XAdES. Cofirmas cruzadas entre XMLDSig y XAdES Las cofirmas de un documento dan como resultado dos firmas sobre este mismo documento que se encuentran a un mismo nivel, es decir, que ninguna envuelve a la otra ni una prevalece sobre la otra. A nivel de formato interno, esto quiere decir que cuando cofirmamos un documento ya firmado previamente, esta firma previa no se modifica. Si tenemos en cuenta que XAdES es en realidad un subconjunto de XMLDSig, el resultado de una cofirma XAdES sobre un documento firmado previamente con XMLDSig (o viceversa), son dos firmas independientes, una en XAdES y otra en XMLDSig. Dado que todas las firmas XAdES son XMLDSig pero no todas las firmas XMLDSig son XAdES, el resultado global de la firma se adecúa al estándar más amplio, XMLDSig en este caso. Módulo de firmas XML Página 16 de 66

17 3.4.5 Contrafirmas en XMLDSig Una contrafirma es un tipo de multi-firma (varios firmantes en un único documento), en el que las firmas de los firmantes no están a un mismo nivel, sino que siguen una jerarquía de firmas, donde un firmante asume la firma de otro firmante previo, formándose en el proceso un árbol de firmas (o firmantes). Un ejemplo de uso de este tipo de multi-firmas podríamos encontrarlo en una revisión en cadena de un documento: 1. El autor del documento firma el original. 1. El documento pasa al gerente de ventas, el cual firma sobre la firma del autor 1. El documento pasa al director de ventas, el cual asume el buen trabajo de su gerente y firma sobre su firma. 2. El documento pasa, también desde el propio autor, al gerente de calidad, el cual firma sobre la firma del autor. 1. El documento pasa al director de calidad, el cual asume el buen trabajo de su gerente y firma sobre su firma. 2. El documento pasa al director general, el cual firma las firmas de sus directores, asumiendo igualmente su trabajo. Adicionalmente, es posible combinar co-firmas con contrafirmas, pudiendo tener así árboles de firma complejos, incluso con varios nodos raíz. La especificación del estándar XMLDSig no define la forma de contrafirmar un documento, aunque deja abierta la posibilidad de realizar contrafirmas. No obstante, la especificación XAdES [ETSI TS V1.3.2 ( )] especifica un formato de contrafirma retro-compatible con el formato XMLDSig mediante referencias de tipo CountersignedSignature ( El módulo de firmas XML del implementa las contrafirmas según este método, pero es importante resaltar que, dado que la normativa XMLDSig no adopta este formato de contrafirmas directamente (sino que se define en la normativa XAdES), las contrafirmas XMLDSig creadas mediante el pueden no reconocerse en algunas plataformas de validación de firmas. Módulo de firmas XML Página 17 de 66

18 3.5 XML Advanced Digital Signature (XAdES) Las firmas XAdES son una evolución de las firmas XMLDSig a la que añaden ciertas extensiones y en la que se concretan con más definición algunas operaciones, como las contrafirmas. El formato XAdES admite múltiples variantes, con distintas aplicaciones (desde sellos de tiempo hasta archivo longevo). La actual versión del módulo de firmas XML del soporta únicamente la versiones básica (BES), de aplicación general no especializada y la acorde a política de firma (EPES). Variantes XAdES BES EPES T C X XL A La tabla anterior muestra las variantes de XAdES existentes, estando marcadas únicamente las básica (BES) y acorde a política de firma (EPES) en verde, como indicativo de soporte por el módulo. Dado que XAdES es una extensión retro-compatible con XMLDSig, los formatos soportados son los mismos que en este segundo, aunque encontrando las siguientes diferencias y aspectos a recalcar: Las contrafirmas se realizan mediante un atributo especialmente especificado por XAdES ( CounterSignature ), por lo que, al contrario que en XMLDSig, sí están plenamente respaldadas por el estándar. Al igual que ocurría con XMLDSig, todas las sub-variantes explícitas no están directamente respaldadas por el estándar. Adicionalmente, es importante comentar que los atributos específicos XAdES implementados por el módulo de firmas XML son (además de los relativos a las políticas de firma): SigningTime SigningCerticate IssuerSerial SignedDataObjectProperties Módulo de firmas XML Página 18 de 66

19 3.6 Factura Electrónica La firma en formato de factura electrónica es en realidad una firma XAdES Enveloped particular. La firma de facturas se realizan de acuerdo a la versión 3.1 del esquema de factura electrónica. Detalles a tener en cuenta del formato de firma de factura son: Los datos de entrada deben ser una factura electrónica conforme a las normas FacturaE. No contempla las operaciones de cofirma ni contrafirma. Las firmas son siempre implícitas, por lo que no se atenderá a la configuración de modo del cliente. No es necesario configurar la política de firma de factura electrónica. La política se establece automáticamente cuando se utiliza este formato. Los parámetros configurables de la firma son: signatureproductioncity: Ciudad desde la que se realiza la firma. signatureproductionprovince: Provincia desde la que se realiza la firma. signatureproductionpostalcode: Código postal desde el que se realiza la firma. signatureproductioncountry: País desde el que se realiza la firma. Puedes configurarse estos parámetros mediante el método: addextraparam(string param, String value); Puede llamarse a esta función desde las páginas Web que integren el cliente por medio de la sentencia JavaScript: clientefirma.addextraparam(string param, String value) Módulo de firmas XML Página 19 de 66

20 3.7 Open Document Format (ODF) ODF, la normativa de documentos ofimáticos implementada por OpenOffice.org, implementa para sus firmas digitales una variante específica de XMLDSig. El módulo es capaz de realizar las firmas según esta variante, resultando en documentos firmados reconocidos por los productos OpenOffice.org 3.2 y 3.3. Por problemas de evolución del propio formato ODF, las firmas generadas en la configuración por defecto del Cliente no son válidas en el formato ODF generado por OpenOffice.org 3.0 / 3.1. No se soportan firmas electrónicas en formato OpenOffice.org 2.x, por considerarse obsoleto. La compatibilidad en cuanto a tipo de documento es la siguiente: Impress (Presentaciones) OpenOffice.org 3.2 / 3.3 Calc (Hojas de Writer (Textos) Cálculo) Se soportan documentos Impress, Calc y Writer. Detalles a tener en cuenta del formato de firma ODF son: No contempla la operación de contrafirma Las firmas son siempre implícitas, por lo que no se atenderá a la configuración de modo del cliente. El único algoritmo de firma soportado por el formato es SHA1withRSA, por lo que no se atenderá a la configuración del cliente. NOTAS IMPORTANTES: El formato ODF ha introducido en los últimos años numerosas variantes incompatibles entre sí. Las firmas generadas con OpenOffice.org 3.3 y 3.2 y LibreOffice no son reconocidas por versiones anteriores, y las firmas generadas por OpenOffice.org 3.0 y 3.1 no son reconocidas por versiones anteriores y son reconocidas como incompletas por versiones posteriores. Por estas inconsistencias en la evolución del formato (completamente ajenas al no puede garantizarse un correcto funcionamiento en versiones futuras de OpenOffice.org o LibreOffice. Existe la posibilidad de generar con el Cliente firmas compatibles con OpenOffice.org 3.0 y 3.1 (que serán reconocidas como incompletas por OpenOffice.org 3.2 y 3.3) mediante el siguiente parámetro adicional que debe ser proporcionado al módulo de firma (consulte el Manual del Integrador para más información sobre paso de parámetros adicionales a los módulos de firma): - useopenoffice31mode con el valor true Módulo de firmas XML Página 20 de 66

21 3.8 Office Open XML (OOXML) OOXML, la normativa de documentos ofimáticos implementada por Microsoft Office, implementa para sus firmas digitales una variante específica de XMLDSig. El módulo es capaz de realizar las firmas según esta variante, resultando en documentos firmados reconocidos por los productos Office 2007, 2008 for Mac, 2010 y 2011 for Mac, no previéndose que existan problemas de compatibilidad en futuras versiones. La compatibilidad en cuanto a tipo de documento es la siguiente: PowerPoint (Presentaciones) Office 2007/2008/2010/2011 Excel (Hojas de Cálculo) Word (Textos) Se soportan documentos Word, Excel y PowerPoint. Detalles a tener en cuenta del formato de firma OOXML son: No contempla la operación de contrafirma. Las firmas son siempre implícitas, por lo que no se atenderá a la configuración de modo del cliente. ADVERTENCIA: La herramienta de validación VALIDe, en su versión actual, no soporta la validación de firmas OOXML. Es posible comprobar la validez de estas firmas abriendo el documento con Microsoft Office 2007 o superior. Módulo de firmas XML Página 21 de 66

22 4 Información sobre el módulo 4.1 Compatibilidad El módulo de firmas XML del es compatible con la versión 3 y superiores del cliente, en todas las plataformas, sistemas operativos, arquitecturas y versiones de entorno de ejecución de Java soportadas por este. Las firmas ODF que genera el módulo en la configuración por defecto del Cliente son interpretadas correctamente solo por OpenOffice.org 3.2 y superiores, consulte el apartado Open Document Format (ODF) para más información. 4.2 Situación del nodo de firma en XAdES Enveloped Por defecto, el sitúa la firma electrónica en su nodo Signature directamente como hijo de la raíz del XML. No obstante, hay situaciones en las que puede interesar situar este nodo de firma en una situación arbitraria del XML. Para ello, puede usarse el parámetro adicional insertenvelopedsignatureonnodebyxpath, en el que, mediante una expresión XPath v1, podemos indicar el nodo en el que queremos se inserte la firma (el nodo Signature pasará a ser el primer hijo de este). Si la expresión XPath resolviese varios nodos, se usará el primero de ellos. Por ejemplo, en el siguiente XML: <?xml version="1.0" encoding="utf 8"?> <bookstore> <book category="cooking"> <title lang="en">everyday Italian</title> <author>giada De Laurentiis</author> <year>2005</year> <price>30.00</price> </book> <book category="children"> <title lang="en">harry Potter</title> <author>j K. Rowling</author> <year>2005</year> <price>29.99</price> </book> </bookstore> Si indicamos el parámetro con este valor: insertenvelopedsignatureonnodebyxpath = /bookstore/book[1]/title La firma se insertara como nodo hijo del título del primer libro: <?xml version="1.0" encoding="utf 8"?> Módulo de firmas XML Página 22 de 66

23 <bookstore> <book category="cooking"> <title lang="en"> Everyday Italian <ds:signature xmlns:ds=" Id="S1"> </ds:signature> </title> <author>giada De Laurentiis</author> <year>2005</year> <price>30.00</price> </book> <book category="children"> <title lang="en">harry Potter</title> <author>j K. Rowling</author> <year>2005</year> <price>29.99</price> </book> </bookstore> 4.3 Metadatos adicionales en las firmas XAdES las firmas XAdES pueden contener opcionalmente una serie de metadatos acerca de la firma, el firmante y el propio proceso de firma. es posible establecer estos metadatos mediante el uso de parámetros adicionales. Los parámetros adicionales admitidos en este sentido son: signerclaimedroles ο Cargos atribuidos para el firmante. Deben separarse los cargos con el carácter (y este no puede estar en el propio texto de ningún cargo). signatureproductioncity ο Ciudad en la que se realiza la firma. signatureproductionprovince ο Provincia en la que se realiza la firma. signatureproductionpostalcode ο Código postal en el que se realiza la firma signatureproductioncountry ο País en el que se realiza la firma commitmenttypeindications ο Número de commitment type indications que se van a especificar. Estas son, las finalidades especificadas para la firma que se va a generar. commitmenttypeindicationnindentifier Módulo de firmas XML Página 23 de 66

24 ο ο Identificador de la finalidad número n (que va desde 0 hasta el valor menos 1 indicado en la propiedad anterior) que se le asigna a la firma. Los valores posibles que puede tomar y el significado de cada uno son: - 1: La firma constituye Prueba de origen. - 2: La firma constituye Prueba de recepción. - 3: La firma constituye Prueba de entrega. - 4: La firma constituye Prueba de envío. - 5: La firma constituye Prueba de aprobación. - 6: La firma constituye Prueba de creación. commitmenttypeindicationndescription ο Descripción libre de la finalidad número n. Este atributo es opcional. Las nombres de las propiedades deben escribirse tal y como figuran, respetando mayúsculas y minúsculas. Para más información sobre el establecimiento de parámetros adicionales consulte con el Manual del Integrador. Para el establecimiento programático desde Java de parámetros adicionales consulte con el JavaDoc. 4.4 Cadena de certificación en firmas XMLdSig y XAdES Desde la versión 3.3 del en las firmas XAdES se incluye, por defecto, la cadena de certificación completa del certificado firmante. Este comportamiento, aunque es el recomendado por el estándar, genera firmas XAdES no compatibles con versión anteriores a la 5.5 de la En la versión del se agrega el parámetro includeonlysignningcertificate con el que es posible configurar este comportamiento. Para obligar al a que sólo incluya el certificado del firmante en las firmas, cofirmas y contrafirmas generadas es necesario configurar este parámetro con el valor true. Para configurar este comportamiento estableceremos el valor del parámetro mediante el método addextraparam(string, String). addextraparam( includeonlysignningcertificate, true ); Este parámetro afecta tanto a las firmas XMLdSig como XAdES. 4.5 Firmas de contenido binario en XMLDSig y XAdES Cuando se indica al Cliente que se desea firmar datos binarios y estos se facilitan efectivamente en formato binario, el cliente los transforma a Base64 antes de firmarlos, de forma que estos puedan ser insertados en el XML. Módulo de firmas XML Página 24 de 66

25 La normativa ( indica que siempre que sobre los datos originales se realice una transformación de este tipo, esta debe declararse en la referencia de la firma XML mediante el algoritmo Declarando esta transformación, la huella digital firmada corresponderá con el original binario, y no con su versión codificada en Base64. No obstante, el cliente incorpora ciertas peculiaridades en la aplicación de esta norma: Únicamente se declaran trasformaciones Base64 en las firmas XAdES y XMLDSig. OOXML y ODF no necesitan estas transformaciones nunca. Únicamente se declaran transformaciones Base64 de forma automática si es el cliente el que realiza la transformación de binario a Base64. Si los datos se proporcionan ya en Base64 (la transformación se ha realizado externamente), es el integrador quien debe asegurarse de que, si desea que se declare esta transformación, se añade de forma manual. Deshabilitación de las transformaciones Base64 Por si se produjesen problemas de compatibilidad con otros sistemas no compatibles con la normativa XMLDSig / XAdES en cuanto a transformaciones Base64, el cliente establece un mecanismo de desactivación de esta característica mediante el siguiente método del Applet (que es posible invocar vía JavaScript): ClienteFirma.addExtraParam(String paramname, String paramvalue), y el uso concrerto: clientefirma.addextraparam( avoidbase64transforms, true ); Una vez deshabilitada la declaración de las transformaciones Base64, estas se dejarán de añadir hasta que se reinicie el Applet o se vuelvan a habilitar mediante la llamada complementaria: clientefirma.addextraparam( avoidbase64transforms, false ); Puede encontrar más información sobre el método addextraparam en la documentación JavaDoc. Módulo de firmas XML Página 25 de 66

26 4.6 Firma de hojas de estilo en XMLDSig y XAdES La normativa XMLDSig (punto 8.1.3) indica que si un XML declara una hoja de estilo, esta debe ser firmada junto al XML para que la firma asocie a este último con su visualización, respetando el concepto lo que se ve es lo que se firma. Dado que las hojas de estilo pueden declararse de distintas formas, el cliente adopta distintas estrategias para cada forma de declaración y según la variante de firma. Las formas de declarar una hoja de estilo y la forma de firmar el XML en ese caso por el Cliente son las siguientes: La hoja de estilo está empotrada dentro del XML, y se declara con una referencia local (el valor del atributo href de la declaración del XSL es un nombre de identificador de nodo XML precedido por # ). o En este caso no es necesaria ninguna estrategia adicional, pues al ser parte la hoja de estilo del XML, siempre que se firma uno, se firma también el otro. Esto aplica a la totalidad de las firmas XML. La hoja de estilo está accesible remotamente por protocolo HTTP o HTTPS (el valor del atributo href es una URL válida con esquema http o https). o En este caso se añade una referencia a la firma que apunta a la hoja de estilo mediante la misma URL (una referencia Externally Detached). Esto aplica a la totalidad de las firmas XML). Se referencia a la hoja de estilo mediante una referencia relativa local. o En este caso, dado que las referencias relativas locales se pierden al firmar (el Applet no sabe en qué directorio o carpeta estaba el XML para localizar el XSL, y no puede asumir dónde se guardará la firma generada), las hojas de estilo no se firman. Módulo de firmas XML Página 26 de 66

27 4.6.1 Notas importantes sobre la firma de hojas de estilo XML Desactivación y activación de firma de las hojas de estilo El Cliente NO firma por defecto aquellas hojas de estilo que encuentra ya que estas pueden hacer referencia a recursos locales del usuario o recursos remotos no accesibles, pero permite modificar este comportamiento mediante el método del Applet (que es posible invocar vía JavaScript): clientefirma.addextraparam(string paramname, String paramvalue), y el siguiente uso: Desactivar firma de hoja de estilo: clientefirma.addextraparam( ignorestylesheets, true ); Activar firma de hoja de estilo: clientefirma.addextraparam( ignorestylesheets, false ); Una vez deshabilitada o habilitada la firma de hojas de estilo, se mantendrá ese comportamiento hasta que se reinicie el Applet o se vuelva a cambiar mediante la llamada complementaria. Puede encontrar más información sobre el método addextraparam en la documentación JavaDoc. Hojas de estilo anidadas Las hojas de estilo XSL pueden referenciar a su vez a otras hojas de estilo mediante las clausulas <xsl:include> y <xsl:import>. Mediante estas etiquetas, se puede construir una cadena de ficheros de definición de estilos en forma de árbol, donde unas referencian a otras tanto de forma remota como local, en modo relativo o absoluto. En la actualidad, el no sigue la cadena de referencias para firmar la totalidad de los ficheros que definen el estilo del XML, sino que opera únicamente sobre el primer fichero referenciado por el XML en el atributo href de la etiqueta xml-stylesheet. Intente en la medida de lo posible evitar el uso de <xsl:include> y <xsl:import> en hojas de estilo, y valore la posibilidad de incluir clausulas en su aplicación reflejando esta limitación. Módulo de firmas XML Página 27 de 66

28 4.6.2 Transformaciones XML Los formatos de firma XAdES y XMLdSig permiten la configuración de transformaciones XML personalizadas. Estas transformaciones se aplican a un XML de datos antes de firmarlo, de tal forma que no se firma el XML original, sino el transformado. Las transformaciones quedan declaradas en la firma para que quede constancia de ellas y sea posible validar la firma por medio del XML de datos original. La declaración de transformaciones XML para la firma es útil para la ejecución de firmas con un formato específico. Por ejemplo, la especificación de factura electrónica establece que no se debe firmar el XML de datos al completo, sino partes específicas del mismo. Se permite la declaración de distintos tipos de transformaciones, algunos de los cuales tienen subtipos. La lógica de una transformación se especifica mediante un cuerpo, salvo en casos concretos en los que la lógica está predefinida por el tipo de transformación (caso de las transformaciones Base64 y Enveloped). Los tipos de transformaciones soportados son: Transformación XPATH: Tipo: Subtipos: No tiene subtipos. Cuerpo: Especificado mediante sentencias de tipo XPATH. Transformación XPATH2: Tipo: Subtipos: - subtract: Operación de substracción. - intersect: Operación de intersección. - union: Operación de unión. Cuerpo: Especificado mediante sentencias de tipo XPATH2. Transformación BASE64 (esta transformación ya se establece por defecto cuando se firman datos binarios, por lo que no se recomienda su uso de forma independiente). Requiere que los datos proporcionados estén en Base64 y que se indique so codificación mediante el parámetro encoding=base64 : Tipo: Subtipos: No tiene subtipos. Cuerpo: No tiene cuerpo. Módulo de firmas XML Página 28 de 66

29 Transformación ENVELOPED (esta transformación ya se establece por defecto en los formatos de firma enveloped, por lo que no se recomienda su uso de forma independiente): Tipo: Subtipos: No tiene subtipos. Cuerpo: No tiene cuerpo. No es posible especificar transformaciones complejas que incluyan varias sentencias. En su lugar, puede declararse una sucesión de transformaciones simples que produzcan el mismo resultado. Cada una de las transformaciones se aplicará de forma ordenada sobre el resultado de la anterior. Las transformaciones personalizadas se declaran a través del método: addxmltransform(string tipo, String subtipo, String cuerpo) Este método puede utilizarse sucesivas veces para establecer varias transformaciones que se apliquen ordenadamente. Para eliminar todas las transformaciones declaradas se utiliza el método: resetxmltransforms() Módulo de firmas XML Página 29 de 66

30 4.6.3 Uso de estructuras Manifest en firmas XAdES Es posible crear firmas XAdES en las que, siguiendo el punto 2.3 de la especificación XMLDSig ( las referencias XML no se firmen directamente, sino que se firme una estructura de tipo Manifest que a su vez contenga las referencias a firmar. De esta forma, tal y como indica la normativa, la resolución de las referencias incluidas dentro de una estructura Manifest es una responsabilidad del validador, y de cara a la propia firma no se resuelven para calcular las huellas digitales (lo que permite hacer firmas XML explícitas). Consulte la especificación XMLDSig para mayor información. Para crear firmas XAdES con estructuras Manifest debe especificarse el siguiente parámetro adicional: usemanifest=true Un ejemplo muy simplificado de la estructura de una firma con Manifest sería: <ds:signature Id="Signature-02553"> <ds:signedinfo> <ds:reference Id="Reference-894bfd39 " Type=" URI="#Manifest-36e2de7b"> </ds:signedinfo> <ds:object Id="ManifestObject-ffd54e53"> <ds:manifest Id="Manifest-36e2de7b"> <ds:reference Id="Reference-894bfd39" URI="myscheme://path/file"> <ds:digestmethod Algorithm=" <ds:digestvalue> </ds:digestvalue> </ds:manifest> </ds:object> </ds:signature> En este ejemplo el contenido firmado es myscheme://path/file, pero al firmar no se ha intentado acceder a ese fichero, y se ha dado por buena la huella digital indicada. Módulo de firmas XML Página 30 de 66

31 4.7 Incidencias conocidas Mensajes extraños en consola El cliente, al firmar ficheros no-xml en modalidades implícitas o al firmar cualquier tipo de fichero (XML o no) en modalidades explícitas puede escribir el siguiente mensaje en consola: [Fatal Error] :1:1: Content is not allowed in prolog. Este mensaje debe ignorarse, ya que no se genera desde la aplicación, sino desde las clases de Sun Microsystems / Apache destinadas a identificar si el contenido del fichero es XML o no. No es posible ocultar este mensaje o evitar que se escriba en la consola. 4.8 Diferencias en las firmas generadas respecto a versiones anteriores del cliente y sus módulos En la versión 3.2 del Cliente y anteriores se incluía en la firma únicamente el certificado del firmantes, mientras que en la versión 3.3 y superiores, por defecto, se incluye toda la cadena de certificación. Para conservar el comportamiento anterior es necesario configurar el parámetro extra de firma includeonlysignningcertificate al valor true. En las contrafirmas, la versión anterior del cliente identificaba las firmas según el IssuerName del certificado firmante. Si firma el documento dentro de una misma organización es muy probable que el IssuerName sea el mismo para todos los firmantes (normalmente, el certificado lo habrá emitido la misma autoridad de certificación para los empleados de una determinada organización), por lo que resultaba imposible discernir entre los firmantes. Cuando se recibe un documento ya firmado, para aceptar ese documento y firma, lo importante es conocer quién ha firmado ese documento, por lo que es aconsejable que se identifiquen según el SubjectName o el CommonName de su certificado. Las versiones v.2.x y v3.0 del nunca declaraban (en ningún formato XML) transformaciones Base64 cuando realizaba estas conversiones. La versión actual (ver puntos anteriores) declara estas transformaciones (aspecto requerido por las normativas) para las firmas XAdES y XMLDSig. Si se firma un XML que declara una hoja de estilo XSL en modo Enveloped, las versiones del cliente v2.x y 3.0 eliminaban la declaración de la hoja de estilo, mientras que el v3.1 mantiene esta declaración. Las versiones del cliente v.2.x y v3.0 no firmaban hojas de estilo asociadas a un XML, mientras que la versión actual sí las firma. Módulo de firmas XML Página 31 de 66

32 5 Ejemplos de Estructuras XML generadas por el módulo 5.1 XMLDSig Detached Interno Explícito / Implícito <?xml version="1.0" encoding="utf-8"?> <AFIRMA> <CONTENT Encoding="..." Id="ID-CONTENT" MimeType="...">...</CONTENT> <ds:signature xmlns:ds=" Id="ID-Signature"> <ds:signedinfo> <ds:canonicalizationmethod <ds:signaturemethod Algorithm=" /> <ds:reference Id="ID-Reference" URI="#ID-CONTENT"> <ds:transforms> <ds:transform </ds:transforms> <ds:digestvalue>...</ds:digestvalue> <ds:reference URI="#ID-KeyInfo"> <ds:transforms> <ds:transform </ds:transforms> <ds:digestvalue>...</ds:digestvalue> </ds:signedinfo> <ds:signaturevalue Id="ID-SignatureValue">...</ds:SignatureValue> <ds:keyinfo Id="2e9ff06f-a4cf-48f1-b670-b0dcdec56331-KeyInfo"> <ds:keyvalue> <ds:rsakeyvalue><ds:modulus>...</ds:modulus><ds:exponent>...</ds:exponent></ds:rsakeyvalue> </ds:keyvalue> <ds:x509data><ds:x509certificate>...</ds:x509certificate></ds:x509data> </ds:keyinfo> </ds:signature> Módulo de firmas XML Página 32 de 66