Documento Técnico DIVISIÓN INFORMÁTICA DESARROLLO DE SISTEMAS. Preparación del Reporte CRS para el envío a DGI

Transcripción

1 DIVISIÓN INFORMÁTICA DESARROLLO DE SISTEMAS Preparación del Reporte CRS para el envío a DGI

2 Índice 1. Objetivo Alcance Actores Involucrados Descripción General del Proceso Requisitos previos a la Preparación Diagrama de Dependencias entre Esquemas Descripción del Proceso Detallado Generación de ID Firma del Reporte XML Validación del Reporte XML firmado Compresión del Reporte Generación del archivo XML de envío Validación del archivo XML Cifrado del Archivo XML Bibliografía Página 2 de 20

3 1.Objetivo. El presente documento, describe los pasos necesarios para la preparación de los reportes que las Entidades Financieras (EF) deben enviar a la Dirección General Impositiva (DGI). Como resultado de este proceso, las EF obtendrán un archivo, que podrá ser enviado a la DGI por los siguientes medios: Upload web (a través de HTTP) Upload mediante el uso de Web Services SOAP. Para entender mejor el proceso de generación, se requiere conocimientos de los siguientes temas: PKI (Public Key Infraestructure) Firma electrónica avanzada en Uruguay XML y XSD XML-Signature XML-Encryption Fundamentos básicos de criptografía simétrica y asimétrica 2.Alcance. La DGI asume que la Entidad Financiera ya cuenta con el reporte XML generado, aunque no se encuentre preparado para el envío. Para la generación de dicho reporte, referirse a la cartilla Formato CRS-DGI. En el presente documento se presentan ejemplos utilizando Java, aunque la DGI se mantiene imparcial en cuanto a la tecnología que las EF quieran utilizar para la preparación del reporte. 3.Actores Involucrados. Desarrolladores, Arquitectos de Sistemas, Analistas de Negocio, Jefes de Proyecto Página 3 de 20

4 4.Descripción General del Proceso Luego de la generado el reporte XML, el mismo debe pasar por una serie de pasos, previos a su envío a la DGI, con los siguiente objetivos: Confidencialidad. Se busca mantener la más alta confidencialidad en la transmisión de la información a través de internet. Integridad. Evitar que la información enviada pueda ser alterada sin autorización. No Repudio. Garantizar que la información provenga realmente del origen que se indica, y no haya lugar al repudio. Mejorar la velocidad de transmisión. Mediante mecanismos de compresión de la información, se pretende enviar menos bytes a través de internet, y así ganar en velocidad. Esto es particularmente útil, ya que en muchos de los casos considerados, podemos recibir reportes de varios megabytes de información. Pasos generales: El reporte generado, debe ser firmado por la EF (utilizando firma electrónica avanzada), de manera de garantizar la integridad y el no repudio. Luego se pasará a comprimir el reporte, y previo a su envío, el mismo debe ser cifrado de manera de garantizar la confidencialidad de la información contenida en el mismo. Página 4 de 20

5 5.Requisitos previos a la Preparación. Es necesario que las EF, cuenten con los siguientes recursos, que les permitirá generar cada uno de los pasos que se describieron anteriormente: 1. Reporte XML La Entidad Financiera, ya debe contar con el reporte XML que es exigido por la DGI, por lo que se considera que el primer paso del diagrama Generación Reporte XML ya se cumplió. Referirse a la cartilla Formato CRS-DGI. 2. Esquema de Reporte XML firmado (Reporte_firmado.xsd) Este archivo XSD puede utilizarse, luego de la firma del Reporte XML, como forma de validación. Este archivo se corresponde con el archivo entregado con nombre CrsXML_v1.0-Domestico.xsd 3. Esquema para el Envío del Reporte (archivo.xsd) Es un archivo XSD, utilizado para generar el correspondiente XML para el envío del reporte. 4. Esquema para el Envío del Reporte cifrado (archivo_cifrado.xsd) Archivo XSD correspondiente al XML de envío cifrado. Este esquema sirve para validar el XML antes de ser enviado. 5. Clave pública de DGI La clave pública y el certificado que DGI, estarán disponibles en el Portal de Automático de Información Financiera. Intercambio 6. Certificado, Clave pública y privada de la EF Es importante que la EF cuente con un certificado X509v3 emitido por una Autoridad Certificadora Nacional y su correspondiente para de claves pública y privada. La DGI recomienda la utilización de dispositivos seguros de almacenamiento, Security Module: HSM) para evitar la posibilidad de hurto de la clave privada. (Hardware No se admiten Autoridades Certificadoras internacionales, ya que no están comprendidas en la PKI de Jurisdicción de la República Oriental del Uruguay. Actualmente, las Autoridades Certificadoras admisibles son: El Correo Uruguayo Abitab 7. Esquema para la firma XML Signature (xmldsig-core-schema.xsd) Este archivo es el esquema utilizado por el estándar XML-Signature para la firma de XMLs. Página 5 de 20

6 8. Esquema de cifrado XML-Encryption (xenc-schema.xsd) Este archivo es el esquema utilizado por el estándar XML-Encryption, para poder cifrar XMLs. Es referenciado por el punto 3 (esquema_cifrado.xsd). 6.Diagrama de Dependencias entre Esquemas La notación a b indica que a depende de b. En este esquema se ve claramente que el archivo.xsd no depende de ningún otro esquema. Página 6 de 20

7 7.Descripción del Proceso Detallado. En amarillo se marcan los recursos necesarios: El diagrama describe el proceso por el cual debe pasar el reporte XML, desde el momento en que se generó hasta el momento previo al envío. En amarillo se indican cada uno de los recursos necesarios y que son entradas a los procesos (burbujas en gris). Como resultado de cada proceso se genera una salida, que se indica con la flecha de salida de cada burbuja. Por ejemplo, el resultado de la burbuja Firmar Reporte XML es el reporte XML firmado. Página 7 de 20

8 8.Generación de ID Para cada reporte XML enviado a DGI, es necesario generar un identificador ID, que represente de forma única el envío. Cada ID debe seguir la nomenclatura siguiente: 1. Los dos primeros caracteres serán UY e identifican al país emisor de los datos. 2. Luego debe ir el año en el que se emitió el reporte, en formato AAAA. 3. Los siguientes caracteres será el código del país (formato de 2 caracteres ISO 3166) para el cual se emitió el reporte. 4. Luego deberá incluirse un punto. 5. Luego deberá incluirse el RUC (Registro Único de Contribuyente) de la Entidad Financiera que emite el reporte, en formato de 12 dígitos. En caso de contener menos dígitos, se le agregará un cero a la izquierda. 6. Luego deberá incluirse un punto. 7. Finalmente deberá incluirse un identificador único y numérico de 8 dígitos, que deberá completarse con ceros a la izquierda. Ejemplo: Ejemplos: UY2017FR UY2015AR Firma del Reporte XML El primero de los pasos luego de generado el reporte, es que la EF lo firme electrónicamente. El resultado de este proceso constituye una firma electrónica avanzada en la República Oriental del Uruguay, de acuerdo a lo establecido en la Ley Descripción del Proceso: Para la firma se utilizará el estándar XML Signature, utilizando SHA-2 (256 bits) como algoritmo de Digest y RSA como algoritmo asimétrico de cifrado, utilizando la clave privada de la EF. Página 8 de 20

9 El mecanismo que debe utilizarse para la firma con XML-Signature es el Enveloped, de manera que la firma se incluya como parte del XML del Reporte. Para mayor información referirse al documento del estándar XML Signature (ver referencia 2 de la Bibliografía). Página 9 de 20

10 Ejemplo de método Enveloped de un XML genérico: <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:reference> </ds:signedinfo> <ds:signaturevalue/> </ds:signature> </From> <Attach>attachement</Attach> </Letter> El algoritmo de canonización que se debe utilizar es el cual no se permite la inclusión de comentarios. Por más información ver referencia 7. La firma debe incluir el certificado de la EF que se utilizó para generarla. El mismo se incluye dentro del elemento KeyInfo X509Data, bajo X509Certificate. <ns2:signature>... <ns2:keyinfo> <ns2:x509data> <ns2:x509certificate> </ns2:x509certificate>.. </ns2:x509data> <ns2:/keyinfo> </ns2:signature> Página 10 de 20

11 El siguiente, constituye un ejemplo real de un reporte XML firmado: <ns2:signature> <ns2:signedinfo> <ns2:canonicalizationmethod Algorithm=" /> <ns2:signaturemethod Algorithm=" /> <ns2:reference URI=""> <ns2:transforms> <ns2:transform Algorithm=" /> <ns2:transform Algorithm=" /> </ns2:transforms> <ns2:digestmethod Algorithm=" /> <ns2:digestvalue>+vjr/5xaflrx3na/wknmayszyi8=</ns2:digestvalue> </ns2:reference> </ns2:signedinfo> <ns2:signaturevalue>olxb77doh90xl0p8ox/ekta8namxvkhqpaqy1+69tqjc+waudf0qhzyq2krpkfxscnkf7x1zu IOOZMVkDiqsgzgTWWdQ/u6PTjOdYTwM8+qJBV0RoycuxL4OEJvRrI4jd90N724YYO7ikLvsK9zd7P+7qQ71AwMOJad+TlThuQk= </ns2:signaturevalue> <ns2:keyinfo> <ns2:x509data> <ns2:x509certificate>miightccbawgawibagiqvfdtpcwzytpu08wwlik0gdanbgkqhkig9w0baqufadb6mqswcqyd VQQGEwJVWTErMCkGA1UECgwiQURNSU5JU1RSQUNJT04gTkFDSU9OQUwgREUgQ09SUkVPUzEfMB0GA1UECwwWU0VSVklDSU9TIEVM RUNUUk9OSUNPUzEdMBsGA1UEAwwUQ29ycmVvIFVydWd1YXlvIC0gQ0EwHhcNMTUwMjA1MTkzNDA4WhcNMTYwMjA1MTkzNDA4WjCB 9DEiMCAGCSqGSIb3DQEJARYTZ2Rvcm5lbGxAZGdpLmd1Yi51eTEeMBwGA1UECwwVU0VHVVJJREFEIElORk9STUFUSUNBMRgwFgYD VQQLDA9TT1BPUlRFIFRFQ05JQ08xHDAaBgNVBAsME1NPUE9SVEUgREUgU0lTVEVNQVMxHDAaBgNVBAoME0RHSS1SVUMgUFJVRUJB IENFREUxEzARBgNVBAgMCk1vbnRldmlkZW8xCzAJBgNVBAYTAlVZMRgwFgYDVQQFEw9SVUMyMTk5OTk4MzAwMTkxHDAaBgNVBAMM E0RHSS1SVUMgUFJVRUJBIENFREUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKM2xtDISeTUqx7MRUIhqXHgzwr1zhiTxZea IDSmCHBkSF3cmY6aGOw3Qy9y93am6xO3Jcpw98t46jo3tN9WqW7ijeIQtS4l96OeS/in6YmQbX3Br5ViO4xYIpdFQVmRQMmP9uKx bwpoegtu9ztj98z4qiziy8unpwfsvdixphphagmbaagjgggmmiibojbibgnvhreewzbzoeigcisgaqqbgjcuagognawysurfmjg3 OTM3MDYvQ0VSVElGSUNBRE8gUFJVRUJBIEdVSUxMRVJNTyBET1JORUxMRVOBE2dkb3JuZWxsQGRnaS5ndWIudXkwDAYDVR0TAQH/ BAIwADAOBgNVHQ8BAf8EBAMCA/gwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGCWCGSAGG+EIBAQQEAwIFoDAdBgNV HQ4EFgQUsTnSf0fgZKinG9HkjuyX+gqfxAcwHwYDVR0jBBgwFoAUJY/fQy+OaroLvkZcV1CTt1G+/NkwVAYDVR0gBE0wSzBJBgwr BgEEAYH1TwEBAQQwOTA3BggrBgEFBQcCARYraHR0cDovL3d3dy5jb3JyZW8uY29tLnV5L2NvcnJlb2NlcnQvY3BzLnBkZjAYBg0r BgEEAYH1TwEBAQQBBAcMBURpc2NvMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly93d3cuY29ycmVvLmNvbS51eS9Db3JyZW9DZXJ0 L2FuYy5jcmwwDQYJKoZIhvcNAQEFBQADggIBAAFHZL/xZiIRGNE61uZc5hDJI/UW4ob3aAGGBlJrn19JBmzaB2MpNsrP4d62QHWX gr1nvb3m5qcyhe4mvjvb5p2jgf01ryrmzi6a+nxjyunzhrqtydwn7meyfjawrjbxqamnbzqxbrkim+ub3fe6p92/bmsd7blvr6ro yrupchffhe0emqhgngn2isr3v6wh/fqpxz1hrhgn3neilcne/cavsp0vsiapvn4gckeq01zgopa/v0i69qps195rk40/bmcq/kdr wbbkqqtvu63r/zjdy+dibxnjnp1+tml4fuym7giwubrmwatqqpzjymjpno9bfjgfinaffuox5cpt6keme1du4l0k9itb2zv8fjt+ yjmtaradzhgbsu97wwxzvfy7etql9pxdofd4qvb82dzx3jgddu48ullzeee2lsriphxyypzuftdzmar27vsep9i/iwpeof5w2dkw Ig6RBeaEd3+wynoyJVasXcFtFwQinnu8xyBm62wCwYaJzupM7zB/KNdKOS3ABZehzExOG6Fi9+8OuraSQml8HRBh2/EgoikjjE5A UJ7bXFeODUMWd4GFAS4zDEn7ZAMDH7NkIGeQ4HX64yH+L9NOTpGaTg1WKFGIykyW3MrIDGfuVrCG+zenKMNrxU9KrqAKe4k/Edka g2xrcdnqjkocc3u2t6vw </ns2:x509certificate> <ns2:x509issuerserial> <ns2:x509issuername>cn=correo Uruguayo - CA, OU=SERVICIOS ELECTRONICOS, O=ADMINISTRACION NACIONAL DE CORREOS, C=UY </ns2:x509issuername> <ns2:x509serialnumber> </ns2:x509serialnumber> </ns2:x509issuerserial> </ns2:x509data> </ns2:keyinfo> </ns2:signature> <ds:signature xmlns:ds=" <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" /> <ds:signaturemethod Algorithm=" /> <ds:reference URI=""> <ds:transforms> Página 11 de 20

12 <ds:transform Algorithm=" /> <ds:transform Algorithm=" /> </ds:transforms> <ds:digestmethod Algorithm=" /> <ds:digestvalue>yqtqec6sywndlcazqayagwmgmzgd/2l8kvqc9isuc6u= </ds:digestvalue> </ds:reference> </ds:signedinfo> 4A <ds:signaturevalue>gccrsgyygictie35wdniicznphbz/cwcbskpkvmqwuwkin2uxco2gx9rx1k1msmxwdnfvlvwyw Dcqas+guuLPLeWESqghe8DvPPZMoWET/zmumb+a0lRhRCh7CfkOtqNSgrnreOHQkTG8/gxPhCohJ xe9dmcjwhx7jzrk7spuqbdbptpajqolyxfxwm3d385d633u2ewz+6w2njls6nqc6gi1t3sgduhlj ajxh9yud2zhl/lwu+v30fdcjlbs+kwutuwop+lzuh1jqdsmsqvhut66lg3lg6zrwvunt2hy8svuw NioWQu7dRk+hapz8TBY8Gnpd43OFm7dJRC1j+Q== </ds:signaturevalue> </ds:signature> 10.Validación del Reporte XML firmado. Luego de haberse firmado el reporte, se puede realizar la validación utilizando el Esquema (reporte_firmado.xsd). Página 12 de 20

13 11.Compresión del Reporte IMPORTANTE: Antes de entrar en detalle de cómo se debe generar la compresión, es importante aclarar que los algoritmos de compresión trabajan sobre una cadena de bytes y no sobre caracteres. Dado que el reporte es un XML y se representa mediante caracteres, previo a la etapa de compresión, es necesario convertir el reporte a su representación en bytes, Para la conversión de caracteres a bytes, se debe considerar la codificación UTF-8, de manera de incluir caracteres especiales y letras de otros alfabetos. La siguiente rutina en Java, muestra cómo obtener un array de bytes a partir de un reporte XML representado mediante una instancia de org.w3c.dom.document public InputStream getinputstream(document doc) throws Exception{ ByteArrayOutputStream outputstream = new ByteArrayOutputStream(); Source xmlsource = new DOMSource(doc); Result outputtarget = new StreamResult(outputStream); Transformer transformer = TransformerFactory.newInstance().newTransformer(); transformer.setoutputproperty(outputkeys.encoding, "UTF-8"); transformer.transform(xmlsource, outputtarget); InputStream is = new ByteArrayInputStream(outputStream.toByteArray()); return is; } Luego de la firma del reporte, realizaremos el proceso de compresión del mismos, utilizando el tipo de formato ZLIB definido en el RFC Este formato incluye, aparte del binario comprimido, la siguiente información método de compresión utilizado nivel de compresión (a mayor nivel mayor eficiencia) Existen muchos métodos de compresión, el más ampliamente utilizado y que se aplicará en este caso será el DEFLATE, definido en el RFC En Java 8, el siguiente ejemplo permite realizar la compresión utilizando el formato ZLIB y DEFLATE. private static byte[] comprimirarchivo(inputstream in) throws FileNotFoundException, IOException{ byte[] buffer = new byte[1024]; ByteArrayOutputStream bos = new ByteArrayOutputStream(); DeflaterOutputStream zos = new DeflaterOutputStream(bos); int len; while ((len = in.read(buffer)) > 0) { zos.write(buffer, 0, len); Página 13 de 20

14 } } in.close(); zos.close(); return bos.tobytearray(); En este caso puntual, se están utilizando valores por defecto para el nivel de compresión. Por más información referirse a la documentación Java. La clase java.util.zip.deflater se puede utilizar en conjunto con java.util.zip.deflateroutputstream, para definir los niveles de compresión, etc. Ejemplo: Deflater deflater = new Deflater(9,false); DeflaterOutputStream zos = new DeflaterOutputStream(bos,deflater); En este caso, se utiliza el nivel de compresión 9 para la compresión por parte de las EF. El segundo parámetro cuyo valor es false, corresponde al NOWRAP, que en caso del envío debe estar en false. (mayor información referirse a javadoc de java.util.zip.deflater). El resultado de este proceso DEBE ser entonces un estructura de datos binaria ZLIB. Página 14 de 20

15 12.Generación del archivo XML de envío. Luego de haber comprimido el archivo, se debe generar un nuevo XML para el envío del reporte. El XML resultante debe validarse contra el Esquema para el Envío de Reporte XSD (archivo.xsd), y será similar al siguiente: <?xml version="1.0" encoding="utf-8"?> <envioarchivo xmlns=" <id>uy2017fr </id> <contenido>uesdbbqacagi6koaaaaa</contenido> <envioarchivo> Valores que debe tomar cada elemento: id : es el identificador del reporte que se envía y que se explicó en el punto 8. (Generación de ID). contenido: es un campo del tipo base64binary, y debe contener el archivo resultante del paso anterior, codificado en base 64. Esta codificación permite enviar binarios como texto plano. 13.Validación del archivo XML Este, XML se valida contra el archivo.xsd siguiente: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:tns=" elementformdefault="qualified"> <complextype name="envioarchivotype"> <sequence> <element name="id" type="string"></element> <element name="contenido" type="base64binary"></element> </sequence> </complextype> <element name="envioarchivo" type="tns:envioarchivotype"></element> </schema> Página 15 de 20

16 14.Cifrado del Archivo XML Para el cifrado del archivo XML, sólo se considerará cifrar el elemento <contenido>, por lo cual el campo <id> queda sin cifrar. Se utilizará el estándar XML-Encryption, mediante el uso de algoritmo de cifrado simétrico AES (Advanced Encryption Standard) con clave de 256 bits generada aleatoriamente utilizando rutinas de generación segura. Por ejemplo, en Java 8, se pueden utilizar las siguientes librerías: KeyGenerator keygen = KeyGenerator.getInstance("AES"); keygen.init(256); SecretKey secretkey = keygen.generatekey(); return secretkey; Recordar que en el caso de Java, deben bajarse las siguiente Java Cryptography Extensions (JCE) Unlimited Strength Jurisdiction Policy Files, ya que por políticas de seguridad, no se puede cifrar con una clave de 256 bits. El sitio para bajar los archivos es: A su vez, la clave simétrica generada, será cifrada mediante algoritmo asimétrico RSA, utilizando la Clave Pública de DGI. La clave está autocontenida en el certificado de DGI. Para el cifrado asimétrico, deberá utilizarse el algoritmo rsa-oaep-mgf1p (RFC 2437 sección 7.1). Como resultado de la aplicación de este algoritmo, se generarán elemento de cifrado donde se indica: <xenc:encryptionmethod Algorithm= /> Página 16 de 20

17 El siguiente diagrama describe el proceso completo: Esqueleto del la parte del XML que es cifrada: Página 17 de 20

18 Descripción de sus elementos: El elemento KeyInfo, conteniendo la clave simétrica, que se encuentra cifrada mediante RSA. Observando detenidamente dentro de este elemento, se describe el método utilizado para el cifrado (en este caso debe ser algoritmo RSA). Luego se incluye otro elemento CipherData, que contiene la clave simétrica cifrada. El elemento CipherData, que está a continuación del elemento KeyInfo, contiene el reporte cifrado mediante AES-256 con la clave simétrica incluida en KeyInfo. Este elemento no debe confundirse con el elemento CipherData incluido en el tag KeyInfo. Este elemento debe contener a su vez, el elemento CipherValue, conteniendo propiamente el reporte cifrado. El estándar XML-Encryption provee la posibilidad de utilizar un elemento denominado CipherReference, en lugar de CipherValue, que permite hacer una referencia a un enlace que contiene el reporte cifrado, pero la DGI no permite esta alternativa. Ejemplo de un reporte cifrado: <?xml version="1.0" encoding="utf-8" standalone="no"?> <tns:envioarchivo xmlns:tns=" xmlns:xsi=" xsi:schemalocation=" archivo.xsd "> <tns:id>12232</tns:id> <tns:contenido> <xenc:encrypteddata xmlns:xenc=" Type=" <xenc:encryptionmethod Algorithm=" /> <ds:keyinfo xmlns:ds=" <xenc:encryptedkey> <xenc:encryptionmethod Algorithm=" /> <xenc:cipherdata> V <xenc:ciphervalue>nro/kgbvwlv1cp11c86p05ifxzgknwd2b1liz3jukwvie27hmffghub9mkbxyya9qvd6qrj2qgg 4oAfsG2/9NWP9Bo/EbY/zCOOeTEGLnquyKKZCDiyIbZspp7uyPbC1HctuzaN5VmvEZWakZGTymI8 fdlfbqwsubrw7t4weh9t1aetvdlyhfwzhxhaabcx4sya8n29i4x7aurbor5cckmawhd0vkl8pzlr bbs15fomndmsrcpau5f1wmvcyzqhv66io6cvsxvpx8w1l5ti77vy8j29zeg7y5wrjllvexdxqw+x BBJNQpdbMVYlFQFcBmF/Rzr+hjei01JXE6zACQ== </xenc:ciphervalue> </xenc:cipherdata> </xenc:encryptedkey> </ds:keyinfo> <xenc:cipherdata> <xenc:ciphervalue>tl20q5zr3gnftaw17jbngo/qpgocmzcnob4xvhpp2xk= </xenc:ciphervalue> </xenc:cipherdata> </xenc:encrypteddata> </tns:contenido> </tns:envioarchivo> Página 18 de 20

19 Luego de cifrado, el archivo XML resultante se podrá validar utilizando el archivo_cifrado.xsd, como garantía de que el archivo cumple con el formato exigido. El siguiente es el correspondiente archivo_cifrado.xsd: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:tns=" elementformdefault="qualified" xmlns:xenc=" xmlns:ds=" <import namespace=" schemalocation="xmldsig-core-schema.xsd"/> <import namespace=" schemalocation="xenc-schema.xsd"/> <complextype name="contenidotype"> <sequence> <element ref="xenc:encrypteddata"></element> </sequence> </complextype> <complextype name="envioarchivotype"> <sequence> <element name="id" type="string"></element> <element name="contenido" type="tns:contenidotype"></element> </sequence> </complextype> <element name="envioarchivo" type="tns:envioarchivotype"></element> </schema> Página 19 de 20

20 15.Referencias. Para la elaboración del presente estándar de documentación se tomaron como referencia los siguientes documentos: [1] [2] [3] Cartilla Formato CRS-DGI. [4] Archivo XSD para el envío (Archivo.xsd) [5] RFC [6] RFC [7] RFC [8] Página 20 de 20