aladi – certificado de origen digital (cod)foros.aladi.org/gtah/prop-ar-cod-10-03-06.pdf ·...

ALADI – Certificado de Origen Digital (COD)Propuesta Argentina

Tema : Proyecto ALADI de Certificado de Origen Digital (COD)

Versión : 01.03

Estado : Preliminar

Fecha: 10-Marzo-2006

Propósito: Especificar la propuesta argentina para el proyecto general y la prueba piloto.

Alcance:Definición funcional del proceso, mecanismos de criptografía, características del certificado de origen digital, procedimientos aduaneros y consideraciones generales

Responsables: Grupo de Trabajo coordinado por la Cancillería Argentina

1 Indice

1 Indice ..................................................................................................................................... 1 2 Objetivo ................................................................................................................................. 3 3 Alcance .................................................................................................................................. 4 4 Definición Funcional .............................................................................................................. 4

4.1 Proceso Actual (Papel) ................................................................................................... 4 4.1.1 Gráfico 1 - Proceso Actual (Papel) ........................................................................... 5 4.1.2 Actores ..................................................................................................................... 5

4.1.2.1 Asociación Latinoamericana de Integración (ALADI) ......................................... 5 4.1.2.2 Autoridad Habilitante (AH) ................................................................................. 5 4.1.2.3 Entidad Habilitada (EH) ..................................................................................... 6 4.1.2.4 Firma Habilitada (FH) ......................................................................................... 6 4.1.2.5 Exportador (Expo) .............................................................................................. 6 4.1.2.6 Importador (Impo) .............................................................................................. 6 4.1.2.7 Aduana de exportación (Aduana Expo) ............................................................. 6 4.1.2.8 Aduana de importación (Aduana Impo) ............................................................. 6

4.1.3 Documentos ............................................................................................................. 6 4.1.3.1 Certificado de Origen (CO) ................................................................................ 7 4.1.3.2 Solicitud CO ....................................................................................................... 7 4.1.3.3 Declaración Jurada (DJ) .................................................................................... 7

4.1.4 Procesos ................................................................................................................... 7 4.1.4.1 Infraestructura .................................................................................................... 7 4.1.4.2 Operatoria .......................................................................................................... 8

4.1.5 Funcionalidad ........................................................................................................... 8 4.2 Proceso Propuesto (Digital) ............................................................................................ 8

4.2.1 Actores ..................................................................................................................... 9 4.2.2 Documentos ............................................................................................................. 9 4.2.3 Procesos ................................................................................................................. 11

4.2.3.1 Infraestructura .................................................................................................. 11 4.2.3.1.1 Gráfico 2 - Proceso Digital - Infraestructura .............................................. 11

4.2.3.2 Operatoria ........................................................................................................ 12 4.2.3.2.1 Gráfico 3 - Proceso Digital - Operatoria .................................................... 12

4.2.4 Funcionalidad ......................................................................................................... 15 4.2.4.1 ALADI ............................................................................................................... 15

Página 1 de 65


4.2.4.2 Autoridad Habilitante ........................................................................................ 15 4.2.4.3 Entidad Habilitada ............................................................................................ 16 4.2.4.4 Autoridad Certificante ...................................................................................... 16 4.2.4.5 Exportador ....................................................................................................... 16 4.2.4.6 Aduana de exportación .................................................................................... 17 4.2.4.7 Importador ........................................................................................................ 17 4.2.4.8 Aduana de importación .................................................................................... 17

5 Recomendaciones Tecnológicas ......................................................................................... 18 5.1 Perfil de certificados digitales ........................................................................................ 18 5.2 Certificate Revocation List (CRL) .................................................................................. 18 5.3 Procedimiento de validación – Verificación de Firmas Digitales ................................... 19 5.4 Firma digital de documentos XML ................................................................................. 19 5.5 Directorios ALADI – Publicación de certificados digitales ............................................. 20

5.5.1 Consulta y validación de certificados digitales ....................................................... 20 5.5.2 Propuesta de esquema para validación de los CODs ............................................ 22 5.5.3 Alta y baja de certificados digitales ........................................................................ 23

5.6 Anexo técnico ................................................................................................................ 23 5.6.1 Campos de los certificados digitales ...................................................................... 23

5.6.1.1 Versión (Version) ............................................................................................ 24 5.6.1.2 Número de Serie (Serial Number) ................................................................... 24 5.6.1.3 Algoritmo de Firma (Signature) ....................................................................... 24 5.6.1.4 Nombre Distintivo del Emisor (Issuer) ............................................................. 24 5.6.1.5 Validez (Desde, Hasta) (Validity (notBefore, notAfter)) .................................... 24 5.6.1.6 Nombre Distintivo del Suscriptor (Subject) ...................................................... 25 5.6.1.7 Clave Pública del Suscriptor (Subject Public Key Info) .................................... 26

5.6.2 Extensiones de un certificado digital ...................................................................... 26 5.6.2.1 Identificador de la Clave de la Autoridad Certificante (Authority Key Identifier) ..................................................................................................................................... 26 5.6.2.2 Identificador de la Clave del Suscriptor (Subject Key Identifier) ...................... 26 5.6.2.3 Uso de Claves (Key Usage) ............................................................................. 26

5.6.3 Formato de Listas de Certificados Revocados (CRLs) ........................................... 27 5.6.4 Campos de una CRL .............................................................................................. 27

5.6.4.1 Versión (Version) ............................................................................................. 28 5.6.4.2 Algoritmo de Firma (Signature) ........................................................................ 28 5.6.4.3 Nombre Distintivo del Emisor (Issuer) .............................................................. 28 5.6.4.4 Día y Hora de Vigencia (This Update) ............................................................. 28 5.6.4.5 Próxima Actualización (Next Update) .............................................................. 28 5.6.4.6 Certificados Revocados (Revoked Certificates) ............................................... 28

5.6.5 Extensiones de una CRL ........................................................................................ 29 5.6.5.1 Identificación de Clave de la Autoridad Certificante (Authority Key Identifier) . 29 5.6.5.2 Número de CRL (CRL Number) ....................................................................... 29 5.6.5.3 Indicador de Delta CRL (Delta CRL Indicator) ................................................. 29 5.6.5.4 Punto de Distribución del Emisor (Issuing Distribution Point) .......................... 29 5.6.5.5 CRL más Reciente – Punto de Distribución de la Delta CRL (Freshest CRL - Delta CRL Distribution Point) ....................................................................................... 29 5.6.5.6 Otras extensiones de CRLs ............................................................................. 29 5.6.5.7 Online Certificate Status Protocol (OCSP) ....................................................... 29

5.6.6 Algoritmos criptográficos ........................................................................................ 30 5.6.7 Validez de una firma digital .................................................................................... 30

5.6.7.1 Verificación de una firma digital ....................................................................... 31

Página 2 de 65


5.6.7.2 Validez del certificado digital ............................................................................ 31 5.6.7.3 Relacionar la firma y el certificado ................................................................... 31 5.6.7.4 Relacionar la firma y el estado de revocación del certificado .......................... 32 5.6.7.5 Información sobre Timestamp (sellado de tiempo) .......................................... 32

5.6.8 Estandares ETSI (European Telecommunications Standards Institute) ................ 32 5.6.9 TS 101 903: XML Advanced Electronic Signatures (XAdES) ................................ 33 5.6.10 Formatos de firma ............................................................................................... 33

5.6.10.1 Firma digital (BES o EPES) ........................................................................... 33 6 Características del Certificado de Origen Digital ................................................................. 34

6.1 Cobertura de los Acuerdos ALADI ................................................................................ 34 6.2 Datos de los Formularios (XML) ................................................................................... 35 6.3 Formato de los Formularios de cada Acuerdo (XSL) .................................................... 36 6.4 Especificación de los Archivos de Datos (XSD) ............................................................ 37 6.5 Ejemplos ....................................................................................................................... 38

7 Procedimientos Aduaneros .................................................................................................. 41 7.1 Proceso Propuesto para el Tratamiento del COD, en los Sistemas Aduaneros del País Importador ........................................................................................................................... 41

7.1.1 Diagrama ................................................................................................................ 41 7.1.2 Descripción ............................................................................................................. 42

8 Difusión ................................................................................................................................ 43 9 Glosario de Términos .......................................................................................................... 43 10 Bibliografía ......................................................................................................................... 43 11 Anexos ............................................................................................................................... 44

11.1 Anexo 1 – Planilla Consolidada con los datos utilizados por todos los acuerdos ALADI ............................................................................................................................................ 44 11.2 Anexo 2 - Ejemplo de Archivo de Datos Unico con Múltiples Formatos para cada Acuerdo. .............................................................................................................................. 45

11.2.1 CERTIFICADO DE ORIGEN DEL MERCOSUR .................................................. 45 11.2.2 XML - Schema con la definición del Archivo de Datos (Contenido del archivo CODv0.xsd) ..................................................................................................................... 47 11.2.3 Datos Típicos, de un Certificado de Origen Digital (Contenido del archivo Cod.xml) .......................................................................................................................... 54 11.2.4 Formato de la Plantilla, correspondiente al AAP CE Nº 18 – MERCOSUR, (contenido del archivo Cod.xslt) ...................................................................................... 56

12 Indice Alfabético ................................................................................................................ 63

2 Objetivo

Este documento tiene como objetivo describir funcionalmente el modelo de operatoria del Certificado de Origen Digital (COD) a ser presentado por la República Argentina en el marco de la Propuesta para la Digitalización de Certificados de Origen originada en el Ámbito de la ALADI.

A fin de aumentar la claridad de exposición esta presentación se ha organizado en tres etapas que describen:

• Proceso Actual

• Proceso Digital

Página 3 de 65


o Infraestructura

o Operatoria

En los tres casos se identifican:

• Actores

• Documentos

• Procesos

• Funcionalidad

3 Alcance

Los modelos descriptos, tanto el actual como el propuesto, son de aplicación dentro del marco del comercio exterior de los países miembros de la ALADI, pero no descartan su eventual aplicabilidad futura a otros países que operen con alguna modalidad de documentos electrónicos con firma digital.

4 Definición Funcional

4.1 Proceso Actual (Papel)

En el siguiente gráfico se representan las etapas de:

• Habilitación de Entidades y Firmas Habilitadas

• Publicación de nóminas de Entidades y Firmas Habilitadas

• Solicitud, emisión, envío, recepción y control de los Certificados de Origen

para los acuerdos vigentes dentro del marco de la ALADI.

Se realiza una descripción somera del proceso actual, solo a fin de servir como introducción para la posterior descripción del proceso propuesto, basado en el uso de documentos electrónicos con firma digital.

Una descripción completa del proceso actual puede obtenerse en el documento: Propuesta para la Digitalización de Certificados de Origen en el ámbito de la ALADI, citado en el Capítulo 10 - Bibliografía

4.1.1 Gráfico 1 - Proceso Actual (Papel)

Página 4 de 65


ALADI IEEHFH

ALADI – Certificado de Origen

EXPOIMPO

AduanaImpo

EnvíoEHFH

Envío FacturaEnvío DJ

Solicitud CO

EnvíoCO

EnvíoFH

EnvíoCO

EnvíoCO

ConsultaEHFH

Proceso Actual (Papel)

EH

FH

DelegaciónHabilitación

1

2

9

8

7

6

5

4

3

AHSC

4.1.2 Actores

En este proceso, basado en documentos soportados en papel con firma autógrafa de las autoridades intervinientes, participan los actores, cuyas funciones, consideradas en el marco del presente trabajo, se detallan a continuación:

4.1.2.1 Asociación Latinoamericana de Integración (ALADI)

Organismo responsable de la administración centralizada del proceso validación de los Certificados de Origen, la publicación de las nóminas de Autoridades Habilitantes, Firmas Habilitadas y Certificados Digitales para su utilización por parte de la totalidad de los actores intervinientes.

4.1.2.2 Autoridad Habilitante (AH)

Uno o más organismos oficiales, según la práctica de cada país, que habilitan y controlan a las Entidades Habilitadas (EH) que, en ese país, pueden emitir Certificados de Origen.

4.1.2.3 Entidad Habilitada (EH)

Página 5 de 65


Entidades públicas o privadas, autorizadas por la(s) Autoridad(es) Habilitante(s) en cada país para la emisión de Certificados de Origen.

Estas Entidades Habilitadas, a su vez autorizan a personas físicas (Firmas Habilitadas) para la firma autógrafa de los Certificados de Origen.

4.1.2.4 Firma Habilitada (FH)

Persona física autorizada por una Entidad Habilitada para la firma de Certificados de Origen.

4.1.2.5 Exportador (Expo)

Persona natural o jurídica dedicada a enviar productos nacionales o nacionalizados al exterior, legalmente, con el objeto que aquellos sean usados y consumidos en el extranjero.

4.1.2.6 Importador (Impo)

Persona natural o jurídica dedicada a recibir productos del exterior, legalmente, con el objeto que aquellos sean usados y consumidos en el país

4.1.2.7 Aduana de exportación (Aduana Expo)

Organismo oficial responsable del control del proceso de exportación, en el país origen de los bienes a ser exportados.

4.1.2.8 Aduana de importación (Aduana Impo)

Organismo oficial responsable del control del proceso de importación, en el país destino de los bienes a ser importados.

4.1.3 Documentos

4.1.3.1 Certificado de Origen (CO)

Documento oficialmente válido que acredita que las mercancías amparadas en él son originarias de un determinado país.

4.1.3.2 Solicitud CO

Página 6 de 65


Requerimiento efectuado por el exportador ante una Entidad Habilitada, de acuerdo a la normativa vigente en cada país, a fin de obtener un Certificado de Origen.

4.1.3.3 Declaración Jurada (DJ)

Presentación escrita efectuada por el exportador, ante una Entidad Habilitada, quedemuestre que la mercancía para la cual se solicita el Certificado de Origen,cumple con los requisitos exigidos por el régimen de origen invocado.

4.1.4 Procesos

Dividimos la descripción de la totalidad del procesamiento de los Certificados de Origen, en sus componentes de:

Infraestructura organizativa, común a la gestión de todos los certificados.

Operatoria particular de cada CO, que va desde su solicitud en el país origen de la mercadería, hasta su recepción o rechazo por parte de la Aduana de importación en el país de destino.

Los números de orden de cada proceso descrito a continuación hacen referencia a los números indicados en el Gráfico 1 Proceso Actual (Papel).

4.1.4.1 Infraestructura

La(s) Autoridad(es) Habilitante(s), en el caso de Argentina representada por la Secretaría de Comercio, habilita(n) a un conjunto de Entidades Habilitadas para que emitan Certificados de Origen.

Las Entidades Habilitadas autorizan a un conjunto de sus funcionarios para la firma de sus Certificados de Origen.

Las Entidades Habilitadas informan a la(s) respectiva(s) Autoridad(es) Habilitante(s), la nómina de funcionarios autorizados (Firmas Habilitadas), las respectivas altas, bajas y modificaciones, y los períodos de validez, con sus respectivas firmas autógrafas.

La(s) Autoridad(es) Habilitante(s), informan a la Secretaría General de ALADI, la relación de sus Entidades Habilitadas, la nómina de los funcionarios autorizados (Firmas Habilitadas) a firmar Certificados de Origen, las respectivas altas, bajas y modificaciones con sus respectivas firmas autógrafas, para que ésta los incorpore al registro que mantiene al respecto.

Este registro es puesto en conocimiento de las Representaciones Permanentes de los países miembros, que los comunican a su vez a sus respectivas autoridades nacionales.

Página 7 de 65


4.1.4.2 Operatoria

El Exportador solicita a alguna de las Entidades Habilitadas, la emisión de un Certificado de Origen, presentando la documentación de respaldo que requiere el acuerdo marco en que se tramita el CO.

Cumplidas las formalidades y controles pertinentes, la Entidad Habilitada emite al Exportador que lo ha solicitado el respectivo Certificado de Origen.

El Exportador envía, al Importador en el país destino de las mercaderías, complementariamente a la documentación usual en comercio exterior, el original del Certificado de Origen.

El importador, o su representante, presenta el original de Certificado de Origen a la Aduana del país importador, conjuntamente con la Declaración Aduanera de Importación, y el resto de la documentación requerida en cada caso.

La Aduana del país importador, consulta en los archivos de ALADI, la vigencia de las Entidades y Firmas Habilitadas, emisoras del respectivo Certificado de Origen para proceder a validación, aceptación o rechazo.

4.1.5 Funcionalidad

Dado que la totalidad de la documentación se soporta en papel, acompañado en algunos casos por sistemas de registro informático, la generación, recepción y control de documentos se efectúa por procesos manuales, mientras que la remisión se efectúa por correo postal, o por diversas formas de mensajería, tanto para los tramos nacionales como para los internacionales, con las demoras y limitaciones que ello supone.

4.2 Proceso Propuesto (Digital)

El proceso propuesto de utilización de Certificados de Origen Digitales, incorpora a la lógica del proceso actual (en papel) tres nuevos elementos:

Un nuevo actor, las Autoridades Certificantes, y sus Autoridades de Registro asociadas, quienes tienen a su cargo la elaboración y emisión de Certificados Digitales para los mismos actores que operan en el proceso actual.

Un nuevo soporte documental, el Documento Electrónico.

Una nueva modalidad de autenticación de los documentos electrónicos, la Firma Digital. Los principios funcionales del proceso propuesto, no difieren del proceso actual en papel, pero al incorporar el documento electrónico y la firma digital requieren de actores y mecanismos capaces de gestionarlos.

A fin de identificar en el gráfico los nuevos elementos, los textos aparecen representados en color rojo, letra itálica subrayada y las líneas en trazos punteados.

Página 8 de 65


4.2.1 Actores

En este proceso, basado en documentos electrónicos con firma digital, participan los mismos actores que en el proceso actual basado en documentos en papel

• Asociación Latinoamericana de Integración (ALADI)

• Autoridad Habilitante (AH)

• Entidad Habilitada (EH)

• Firma Habilitada (FH)

• Exportador (Expo)

• Importador (Impo)

• Aduana de exportación (Aduana Expo)

• Aduana de importación (Aduana Impo)

Con las funciones indicadas en el punto 4.1.2 - Actores, a los que se agregan las Autoridades Certificantes, responsables de la emisión de los Certificados Digitales utilizados por parte de todos los actores, sobre los documentos electrónicos gestionados.

De acuerdo a la legislación y práctica de cada país miembro las Autoridades Certificantes pueden pertenecer al ámbito público o privado, y tener o no Autoridad Certificante Raíz, lo que no condiciona el modelo propuesto.

El tipo de certificado propuesto se detalla en el Capítulo 5 - Recomendaciones Tecnológicas.

Es razonable proponer que las Autoridades Certificantes para los actores privados puedan pertenecer al ámbito privado, mientras que para los actores públicos pertenezcan al ámbito público, tal como se indica en el diagrama, aunque la jurisdicción de actuación de las mismas se define en el ámbito de cada país miembro.

4.2.2 Documentos

Conceptualmente los documentos gestionados directamente son los mismos que en el proceso actual en papel:

• Certificado de Origen (CO)

• Solicitud CO

• Declaración Jurada (DJ)

Página 9 de 65


con la misma definición indicada en el Punto 4.1.3 Documentos

Los documentos mencionados en este proceso tienen la particularidad de estar soportados en archivos electrónicos, cuyas características de contenido y formato están especificadas en el Capítulo 6 – Características del Certificado de Origen Digital.

Este conjunto de documentos se complementa con las notificaciones que contienen:

• Nóminas de Autoridades Certificantes

• Entidades y Firmas Habilitadas

• Certificados Digitales utilizados en la firma de los documentos involucrados

intercambiadas entre ALADI, Autoridades Habilitantes y Entidades Habilitadas a los fines de mantener actualizados, sus respectivos registros, y para su consulta por parte de los actores del comercio exterior y de las autoridades aduaneras.

La modalidad, tradicional o digital, de soporte y transmisión de estos documentos, no se especifica en el presente documento, aunque se recomienda para ellos también, la utilización de documentos electrónicos con firma digital.

Adicionalmente a estas consideraciones, es conveniente tener en cuenta las siguientes características del proceso y los archivos electrónicos que los implementan:Se prevén nuevos requerimientos de procesamiento automático y de control de la información que contienen los COD.

La definición de un formulario único facilitaría enormemente estas tareas.

Se ha avanzado en esta dirección analizando y documentando en una matriz, los contenidos de todos los CO existentes, con vistas a determinar cuales podrían formar parte del COD unificado, como se indica en el Punto 6 Características del Certificado de Origen Digital .

Un tema sensible a tener en cuenta es la calificación de cada dato, contenido en el COD, como público o privado, con vistas a su procesamiento diferencial a lo largo de todo el proceso.

Como formato de archivo para el COD se propone XML (eXtended Markup Lenguaje), considerando, entre otras razones como la legibilidad inmediata de su contenido por una persona lo que garantiza que no existen contenidos ocultos, la capacidad de discriminar, en la misma definición del documento, los campos obligatorios de los opcionales.

4.2.3 Procesos

Dividimos la descripción de la totalidad del procesamiento de los Certificados de Origen Digitales, en sus componentes de:

La infraestructura propuesta, necesaria para la gestión de la totalidad de los documentos electrónicos y sus firmas digitales.

Página 10 de 65


La operatoria propuesta, que implementa la gestión de cada Certificado de Origen Digital particular.

4.2.3.1Infraestructura

En el siguiente gráfico se representan las etapas de habilitación de Entidades y Firmas Habilitadas, la publicación de nóminas de Autoridades Certificantes, Entidades y Firmas Habilitadas y sus respectivos Certificados Digitales propuestos para los acuerdos vigentes dentro del marco de la ALADI.

4.2.3.1.1 Gráfico 2 - Proceso Digital - Infraestructura

CD

ALADI IEEHFH


EXPO

AC(Estatal)

ACAR

(Privados)

ACCD-EHCD-FH

CD

CD

EH

CD

Digital - InfraestructuraEnvío

ACCD-EHCD-FH

EnvíoAC

CD-EHCD-FH

FH

DelegaciónHabilitación

5

4

3

2

1

AHSC

CD

Los números de orden de cada proceso descrito a continuación hacen referencia a los números indicados en el Gráfico 2 - Proceso Digital – Infraestructura.

La(s) Autoridad(es) Habilitante(s), en el caso de Argentina representada por la Secretaría de Comercio, habilita(n) a un conjunto de Entidades Habilitadas para que emitan Certificados de Origen.

Las Entidades Habilitadas autorizan a un conjunto de sus funcionarios para la firma de sus Certificados de Origen y acuerdan con la Autoridad Certificante que elijan o les sea asignada por la legislación de su país de actuación, la emisión de Certificados Digitales para la firma

Página 11 de 65


de los documentos que emitan, en particular los Certificados de Origen Digital.

Las Entidades Habilitadas informan a la(s) respectiva(s) Autoridad(es) Habilitante(s), la nómina de Autoridades Certificantes asociadas, de funcionarios autorizados (Firmas Habilitadas) con sus respectivos Certificados Digitales y las respectivas altas, bajas y modificaciones con sus vigencias.

La Autoridad Habilitante acuerda con la Autoridad Certificante que elija o le sea asignada por la legislación de su país de actuación, la emisión de Certificados Digitales para la firma de los documentos que emita.

La(s) Autoridad(es) Habilitante(s), informan a la Secretaría General de ALADI, la relación de sus Entidades Habilitadas, la nómina de los funcionarios autorizados (Firmas Habilitadas), a firmar Certificados de Origen Digitales, con sus Certificados Digitales, las respectivas altas, bajas y modificaciones y vigencias, para que ésta los incorpore al registro que mantiene al respecto.

Adicionalmente informa las Autoridades Certificantes utilizadas en su propia actuación, junto con sus respectivos Certificados Digitales

Este registro es puesto, por la Secretaría General de ALADI, en conocimiento de las Representaciones Permanentes de los países miembros, que los comunican a su vez a sus respectivas autoridades nacionales.

4.2.3.2 Operatoria

En el siguiente gráfico se representan las etapas de Solicitud, Emisión, Envío, Recepción y Control de Certificados de Origen Digitales, propuestos para los acuerdos vigentes dentro del marco de la ALADI.

4.2.3.2.1 Gráfico 3 - Proceso Digital - Operatoria

Página 12 de 65


ALADI IEEHFH


EXPOIMPO

AduanaImpo

ACAR

(Privados )

ACCD-EHCD-FH

AduanaExpo

CD

ConsultaExistencia FH

ConsultaExistencia FH

(Opcional)

Consulta Revocados FHFirma Expo(Opcional)

Consulta Revocados FH

Envío CODFirma FH

e-mail Firma Expo

EnvioCOD

Firma FH

EHCD

Envío FacturaEnvío DJ

Solicitud CODFirma Expo

Digital - Operatoria

Consulta(solo Mercosur )

FHCD

EnvíoCOD

Firma FH

1

8

2

7

6

5

94

3

CD

Los números de orden de cada proceso descrito a continuación hacen referencia a los números indicados en el Gráfico 3 - Proceso Digital – Operatoria.

1. El Exportador solicita a alguna de las Entidades Habilitadas, por medios tradicionales o digitales, según el marco jurídico o las prácticas habituales en su ámbito de operación, la emisión de un Certificado de Origen Digital, presentando la documentación de respaldo que requiere el acuerdo marco en que se tramita el COD, típicamente Factura, Solicitud COD y Declaración Jurada Previa.

2. En el ámbito del MERCOSUR, y en virtud de los acuerdos y servicios habilitados para consultas a los sistema aduaneros, la Entidad Habilitada, está en condiciones de verificar los datos del COD con la información contenida en la respectivo declaración de exportación, tramitada por el Exportador ante la Aduana de Exportación.

3. Cumplidas las formalidades y controles pertinentes, la Entidad Habilitada emite al Exportador que lo ha solicitado, el respectivo Certificado de Origen Digital con las firmas digitales del exportador y de la Firma Habilitada.Para este proceso el exportador debe disponible un mecanismo para firmar digitalmente el COD.

4. El exportador envía al Importador, en el país destino de las mercaderías, complementando la documentación usual en comercio exterior, el Certificado de Origen Digital, que contiene en el archivo informático que lo soporta, la firma digital

Página 13 de 65


de la Firma Habilitada.

Como una medida adicional de control de autenticidad de este mensaje, y al mismo tiempo simplicidad operativa, se propone, en carácter opcional como parte de eventuales acuerdos entre Exportador e Importador, que el medio de transmisión del COD sea un email, firmado digitalmente por el Exportador, utilizando los certificados emitidos por las Autoridades Certificantes vigentes en su área de operación, típicamente las mismas que utilizan las Firmas Habilitadas.

5. El importador, una vez recibido el COD, tiene disponible la opción de consultar en el sitio de ALADI, la existencia y vigencia de la Entidad Habilitada, la Firma Habilitada, y los Certificados Digitales utilizados por la FH, la existencia y vigencia de la Autoridad Certificante emisora de esos CD. Adicionalmente, y en caso que el exportador hubiese firmado el envío del COD, tiene la opción de verificar, en la AC emisora del CD utilizado por el exportador, el estado de revocación del mismo.

Si el email que transportó el COD, hubiese sido firmado digitalmente, el Importador también tiene la opción de validar la AC emisora contra el sitio de ALADI.

6. El Importador tiene también la opción de consultar, contra las AC emisoras, el estado de revocación del todos los Certificados Digitales utilizados en la generación y transmisión del COD, es decir, los utilizados por la FH, en la firma del COD y los utilizados por el Exportador en la firma del email que lo transportó.

7. El importador, o su representante, efectuadas previamente las verificaciones que considere convenientes, envía el Certificado de Origen Digital firmado por la FH, a la Aduana ante la cual realiza la Declaración de Importación, conjuntamente con la Declaración Aduanera de Importación, y el resto de la documentación requerida en cada caso, de acuerdo al mecanismo de transmisión y recepción que en cada país se determine.

En el caso particular de la Aduana Argentina, la presentación del COD, se hace mediante un mecanismo de “upload” de archivos, denominado “Ventanilla Electrónica” habilitado a tal fin en la página web de la Administración Federal de Ingresos Públicos (AFIP) www.afip.gov.ar.

Adicionalmente al mecanismo de ingreso del COD, se prevé, en el ámbito del MERCOSUR, poner a disposición de los Importadores, o sus representantes autorizados, mecanismos de validación de los datos del COD, contra los datos existentes en la respectiva Declaración de Importación, los que estarán automatizados en la medida que las estructuras de datos del COD estén estandarizadas, según se detalla en el Capítulo 6 – Características del Certificado de Origen Digital.

8. La Aduana de importación, una vez recibido el COD, consulta en el sitio de ALADI, la existencia y vigencia de la Entidad Habilitada, de la Firma Habilitada, de los Certificados Digitales utilizados por la FH, y la existencia y vigencia de la Autoridad Certificante emisora de esos CD.

Página 14 de 65

http://www.afip.gov.ar/


9. Finalmente la Aduana de importación, consulta, la vigencia de los CD utilizados por Entidades y Firmas Habilitadas, emisoras del respectivo Certificado de Origen Digital, y eventualmente los CD utilizados por el Importador en el mecanismo de transmisión y recepción por parte de la Aduana de importación, contra las AC emisora de los mismos para proceder a su aceptación o rechazo.

4.2.4 Funcionalidad

A fin de hacer más eficientes los mecanismos de solicitud, emisión, transmisión, recepción y control de los COD es deseable establecer un conjunto de funcionalidades mínimas que debieran cumplir los servicios, infraestructura y aplicativos que gestionen estos procesos en cada uno de los organismos intervinientes.

Factores deseables comunes a todos los servicios mencionados son:

• Trazabilidad integral de las operaciones, aún cuando el proceso involucre diversos países

• Estandarización de la estructura de los COD, y su contenido de modo de permitir el procesamiento informático automatizado de esos datos por parte de los actores autorizados que así lo requieran.

• Capacidad para la visualización y verificación de los Certificados Digitales, y su aplicación a la firma de documentos electrónicos.

• Compatibilidad entre los Certificados Digitales emitidos en cada país miembro.

4.2.4.1 ALADI

• Almacenamiento, por los períodos que determine la normativa aplicable, de las nóminas de Autoridades Certificantes autorizadas a operar en el conjunto de los países miembros, Entidades Habilitadas, Firmas Habilitadas en cada país miembro, con sus respectivos Certificados Digitales emitidos, características y vigencias.

• Servicios informáticos que permitan:

• La actualización interactiva o mediante procesos automáticos, de la información mencionada en el punto 1, por parte de las Autoridades Habilitantes de cada país miembro.

• La consulta interactiva o mediante procesos automáticos, de la información mencionada en el punto 1, por parte de los Importadores y las Aduanas de importación de cada país miembro.

4.2.4.2 Autoridad Habilitante

• Almacenamiento, por los períodos que determine la normativa aplicable, de las nóminas de Autoridades Certificantes, Entidades Habilitadas y Firmas Habilitadas,

Página 15 de 65


autorizadas en su país, con registro de los Certificados Digitales emitidos, sus características y vigencias.


o La actualización interactiva o mediante procesos automáticos, de la información mencionada en el punto 1, por parte de las Entidades Habilitadas en su país.

o La carga interactiva o mediante procesos automáticos, en el sitio de ALADI, de las nóminas de Autoridades Certificantes, Entidades Habilitadas, Firmas Habilitadas en cada país miembro, con sus respectivos Certificados Digitales emitidos, características y vigencias.

4.2.4.3 Entidad Habilitada

• Almacenamiento, por los períodos que determine la normativa aplicable, de las nóminas de Autoridades Certificantes utilizadas, y Firmas Habilitadas, autorizadas en su país, Certificados de Origen Digitales emitidos, con registro de los Certificados Digitales utilizados, sus características y vigencias.

• Servicios informáticos que permitan

o La actualización interactiva o mediante procesos automáticos, de la información mencionada en el punto 1, en el sitio web de su respectiva Autoridad Habilitante.

o La carga interactiva o mediante procesos automáticos, por parte de los Exportadores de los documentos necesarios a la tramitación de la solicitud del COD.

o La gestión, por parte de los funcionarios autorizados (FH) de la revisión, firma digital y emisión, de los COD.

o En el ámbito del MERCOSUR, la interacción con los sistemas informáticos de la Aduana de exportación, a fin de validar los datos del COD con respecto a los datos de la correspondiente Declaración de Exportación.

4.2.4.4 Autoridad Certificante

• Servicios informáticos que permitan la consulta interactiva o mediante procesos automáticos, por parte de los receptores de CD, del estado de revocación de los mismos.

4.2.4.5 Exportador


Página 16 de 65


o La carga interactiva o mediante procesos automáticos, de los documentos necesarios a la tramitación de la solicitud del COD en la correspondiente Entidad Habilitada.

o La recepción, verificación de la autenticidad y validación del contenido de los COD recibidos de la EH y su transmisión al Importador en el país de destino de la mercadería, con la opción de utilizar mensajes firmados.

4.2.4.6 Aduana de exportación

• En el ámbito del MERCOSUR, servicios informáticos que permitan la consulta, interactiva o automática, por parte de la Entidad Habilitada a fin de que esta pueda validar los datos del COD con respecto a los datos de la correspondiente declaración de exportación.

4.2.4.7 Importador


o La consulta interactiva o mediante procesos automáticos, en el sitio web de ALADI, de las nóminas de Autoridades Certificantes, Entidades Habilitadas, Firmas Habilitadas, con los respectivos Certificados Digitales, vigentes en el país origen de la mercadería.

o La consulta interactiva o mediante procesos automáticos, en el sitio web de las AC emisoras de los CD utilizados en la firma de los COD y eventualmente en los mensajes que los transportaron, del estado de revocación de los mismos.

o La transmisión, a la Aduana de Importación, utilizando los mecanismos definidos por esta, de los COD recibidos del exportador.

o En el ámbito del MERCOSUR, la consulta, interactiva o automática, de los sistemas informáticos aduaneros a fin de validar los datos del COD con respecto a los datos de la correspondiente declaración de importación.

4.2.4.8 Aduana de importación


o La recepción, verificación de la autenticidad, y validación del contenido, de los COD recibidos del importador.

o La consulta interactiva o mediante procesos automáticos, en el sitio web de ALADI, de las nóminas de Autoridades Certificantes, Entidades Habilitadas, Firmas Habilitadas, con los respectivos Certificados Digitales, vigentes en el país origen de la mercadería.

o La consulta interactiva o mediante procesos automáticos, en el sitio web de las AC emisoras de los CD utilizados en la firma de los COD y eventualmente en

Página 17 de 65


los mensajes que los transportaron, del estado de revocación de los mismos.

o En el ámbito del MERCOSUR, la consulta, interactiva o automática, por parte del propio personal autorizado, o por parte del importador, a fin de validar los datos del COD con respecto a los datos de la correspondiente declaración de importación.

5 Recomendaciones Tecnológicas

A continuación se realizan las recomendaciones tecnológicas respecto de las características mínimas a las que deben suscribir los Certificados Digitales (CDs) que se utilizarán para realizar la firma digital de los Certificados de Origen Digitales (CODs) y otros documentos involucrados por parte de las Entidades Habilitadas y en concreto los poseedores de firmas habilitadas, tal como se ha hecho hasta el momento en el circuito tradicional de emisión y aprobación de los Certificados de Origen (COs).

5.1 Perfil de certificados digitales

Se sugiere que los certificados digitales que se utilizarán para que las Entidades Habilitadas y los poseedores de una firma habilitada que incorporen firma digital al COD cumplan con el standard internacional X.509 versión 3 de la International Telecommunication Union (ITU-T).La primera versión de dicho standard fue creado en 1988, es ampliamente utilizado y define que información debe contener un certificado digital y además cómo debe ser verificado el mismo en lo que respecta a su validez. La versión vigente contempla el formato del mismo, la definición acerca de su uso y datos que identifican a su poseedor.Debido a que el formato especificado por este standard se caracteriza por su gran flexibilidad, para definir el formato de certificado para la firma de los CODs se recomienda la definición de un perfil adecuado de los certificados. Es decir que debe especificarse que datos deben ser obligatorios, cuáles no serán permitidos y cuáles se recomiendan.Adicionalmente se sugiere el formato especificado en el documento RFC 3280 “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, el cual cumple con el Proyecto de Normativa de Licenciamiento de la República Argentina, en el marco de la Ley 25. 506, actualmente en proceso de aprobación

(Para una descripción detallada del formato recomendado, ver puntos 5.6.1 y 5.6.2)

5.2 Certificate Revocation List (CRL)

En la operación de algunos sistemas criptográficos como por ejemplo el que dará soporte tecnológico a la digitalización de los Certificados de Orígen y cuyos procedimientos operativos y técnicos trata este mismo documento, se conoce como “Certificate Revocation List – CRL” (Lista de Certificados Revocados, en castellano) a una lista de certificados digitales, los mismos que se utilizan para realizar la firma digital de un documento. La característica de esta lista es que en ella figuran aquellos certificados que han sido “revocados” (invalidados) y que se deben ser considerados como no confiables por aquellas personas y/o sistemas que verifiquen la validez de los mismos. Es decir, si se ha firmado digitalmente un documento digital -como puede ser el COD- y se desea verificar la validez de dicha firma digital, se debe verificar que el certificado utilizado

Página 18 de 65


para generarla no este incluido en una CRL, tomando en cuenta que la entrada a dicha lista haya sido en un momento anterior a la fecha y hora de firma. Se desprende inmediatamente de esta verificacion que el documento digital ha sido firmado por una persona (o sistema) cuyo certificado digital carece de validez al momento de la firma. Se entiende, por consiguiente, que el documento firmado con dicho certificado digital carecerá de validez.Así como la especificación del formato de los certificados digitales cuenta con gran cantidad de campos a tener en cuenta, con la CRL ocurre lo mismo. Por esta razón se hace necesario definir un perfil para las listas de certificados revocados. Es decir que debe especificarse que datos deben ser obligatorios, cuáles no serán permitidos y cuáles se recomiendan.El standard internacional X.509 del ITU-T también realiza recomendaciones acerca del formato sugerido para dichas listas. Se sugiere el formato especificado en el documento RFC 3280 “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.

5.3 Procedimiento de validación – Verificación de Firmas Digitales

Una vez que el firmante (Entidad Habilitada a través de la persona con firma) ha firmado digitalmente el documento -en este caso el COD-, el receptor del mismo realiza el procedimiento de verificación de la firma digital para determinar su validez y por consiguiente la validez del documento. Existen varias maneras de realizar dicha verificación. A los efectos de una recomendación, sugerimos referirse al documento “Procedures for Electronic Signature Verification” Workshop CWA 14171 Agreement de la European Commitee for Standardization, el cual describe los procedimientos para realizar la verificación de documentos firmados digitalmente.Dicho documento establece una guía sobre las recomendaciones de funcionalidad y seguridad para la verificación de la firma electrónica, para que la misma pueda ser considerada equivalente a una firma manuscrita y complementada con los datos adicionales que sean necesarios para verificar su validez en el tiempo. Las firmas digitales que posean esos datos adicionales se denominan “Enhanced Electronic Signatures”

Los requerimientos de verificación, y consecuentemente los datos asociados a una firma, varían en función del período de vida de una firma. En el caso de las firmas realizadas para certificados de origen nos vamos a encontrar frente a los siguientes casos:

1.- Firmas a corto plazo: firmas que deban ser verificadas dentro de un período de tiempo que no exceda la fecha de expiración del certificado del firmante.

2.- Firmas a largo plazo: firmas que se espera serán verificadas después de la fecha de expiración del certificado del firmante y, posiblemente, incluso después de la fecha de expiración del certificado del certificador que lo emitió.

(Para una descripción detallada de los procedimientos recomendados, ver punto 5.6.8).

5.4 Firma digital de documentos XML

En el foro ALADI se ha sugerido en forma bastante general, que el formato standard que se utilizará para representar la información de un COD y que luego será firmado digitalmente por los funcionarios autorizados con Firma Habilitada es el formato XML (eXtensible Markup

Página 19 de 65


Language). El mismo es un standard publicado en el World Wide Web Consortium (W3C) y especifica una manera muy flexible de contención de información con lineamientos de formato específicos. Una de las cuestiones más importantes que se tienen en cuenta para sugerir este formato es que el mismo es legible por cualquier persona sin recurrir al uso de un aplicativo especial al efecto.Un documento XML puede representar virtualmente cualquier tipo de información. En el caso que nos ocupa, recomendamos -tal como ya se ha recomendado algunos integrantes en el foro de ALADI- la utilización de este formato para representar la información que contendrá un COD.El ETSI (European Telecommunications Standards Institute) propone numerosos standards para la firma digital documentos. Dado que hay altas probabilidades que el documento que representará a un COD esté codificado en XML, recomendamos el standard TS 101 903 (XML Advanced Electronic Signature – XAdES) de dicho Instituto, por las siguientes razones:(Ver descripción detallada del standard procedimientos recomendados, punto 5.6.9).

5.5 Directorios ALADI – Publicación de certificados digitales

Esta sección describe como ALADI podría publicar la información correspondiente a los certificados digitales para poder realizar el circuito de verificación de los CODs (Certificados de Origen) y como cada país se va a comunicar con ALADI para informar sobre las altas y bajas de las firmas habilitadas de cada Entidad Habilitada.

5.5.1 Consulta y validación de certificados digitales

Los documentos que serán transferidos por internet utilizando mecanismos de correo electrónico o el medio que se determine adecuado, estarán firmados digitalmente y contarán con certificados digitales (CDs) que una vez recibidos se podrán verificar para asegurar la autenticidad y la integridad de dichos documentos. Se propone que ALADI informe sobre la existencia de dichos certificados, mediante listas enunciativas que serán actualizadas cada cierto tiempo.

En este contexto, se sugiere que ALADI brinde información sobre:Certificados digitales de las personas con firmas habilitadas por Entidad Habilitada

• Certificados digitales de las Autoridades Habilitantes

• Certificados digitales de las ACs confiables

Dicha información debe estar disponible para ser consultada en el sitio de ALADI, el cual será adecuado para la publicación de esta información, es decir que respetará las indicaciones mínimas de seguridad.

¿Cómo se verifican los certificados digitales contenidos en los documentos transferidos (por ejemplo los COD)? Los receptores de dichos documentos deben realizar esta tarea.

Página 20 de 65


Entendemos que ALADI prefiere evitar contener un repositorio de los certificados digitales de cada una de las figuras actuantes en cada uno de los países miembros, pues argumenta no poseer la infraestructura adecuada a dicho efecto.

Se propone que ALADI actúe como agente de centralización de consultas acerca de la validez de los certificados digitales. Toda entidad que desee consultar sobre la validez de un certificado digital, podrá recurrir a este servicio.

Para ello, deberá contar con una mínima infraestructura tecnológica para realizar las consultas mediante un sistema de delegación de las mismas, conocido como sistema OCSP. De esta manera, ALADI puede contestar sobre si un determinado certificado digital es “válido”, “inválido” o bien si la situación de dicho CD es “desconocida”, pues este servicio formulará dicha “pregunta” a las Autoridades Certificantes.

Para ello, se aclara que ALADI deberá contar con un certificado digital para firmar la respuesta relacionada con el estado del certificado por el que se ha consultado.

Además, toda consulta hacia ALADI enviada desde alguna entidad será reenviada (delegada) hacia las correspondientes Autoridades Certificantes. Esta delegación tomará la forma de “requerimiento” que de la misma manera, podrá estar firmado por ALADI. Ver mas adelante un esquema de dicho procedimiento.

Si bien, OCSP es otra opción para determinar el estado de revocación de un certificado digital X.509, sin utilizar CRLs (Listas de Revocación de Certificados), el mismo podría ser utilizado además para obtener información sobre si el certificado pertenece a una persona con firma habilitada o no.

Página 21 de 65


(Para una descripción detallada del standard OCSP, ver punto 5.6.6).

5.5.2 Propuesta de esquema para validación de los CODs

Se considera necesario que tanto el importador como los organismos/empresas intervinientes que así lo requieran tengan la posibilidad de realizar las validaciones necesarias del COD.Para ello se debería contar con una aplicación o bien con algún servicio donde las partes intervinientes puedan realizar la verificación del COD recibido.

Se proponen las siguientes soluciones:

ALADI podría brindar un servicio, a través del mismo servicio OCSP descripto en 6.1, donde se puedan realizar las verificaciones necesarias de los CD de las personas que han firmado los COD, en este caso se centraría toda la verificación en un solo punto.

Este servicio podría permitir básicamente la posibilidad de realizar un upload del archivo firmado (COD) y la aplicación debería realizar todas las verificaciones necesarias de manera de obtener la validez o no del COD.

Aquí, no solo tendríamos la verificación del certificado digital, sino una verificación completa: tanto del certificado digital del firmante, como la verificación del COD.

Contar con un aplicativo para distribuir a todos los terceros usuarios (importadores y/o Aduanas) intervinientes en el proyecto, para que los mismos puedan realizar la verificación necesaria de los CODs, desarrollando una aplicación verificadora de CODs en el marco del proyecto piloto.

Página 22 de 65


El siguiente gráfico ilustra los diferentes tipos de verificaciones que deben realizarse para obtener la validación del COD.

5.5.3 Alta y baja de certificados digitales

Cada país será responsable de informar a ALADI sobre las altas y bajas de los certificados digitales de aquellas personas con Firma Habilitada, de los certificados de las Entidades Habilitadas y de las Autoridades Certificantes ubicadas geográficamente dentro de su territorio (se está discutiendo si es necesario la información de estos últimos).

Para que dicha información pueda ser transferida en forma segura debe existir una comunicación confiable entre ALADI y los países intervinientes.Se propone que ALADI ofrezca una interfaz web donde los representantes de cada país se autentiquen en el sistema a través de un certificado digital y puedan informar sobre las altas y bajas de las FH y EH.

Cada país tendrá uno o más representantes dependiendo de como realice hoy en día esa comunicación, por ejemplo en el caso de Argentina, la Secretaría de Comercio es el organismo responsable de dar esa información a ALADI. En este caso, la Secretaría de Comercio (representante de Argentina) a través de su certificado digital se autenticará en el sistema web ofrecido por ALADI y realizará las altas y bajas correspondientes cada vez que lo desee.

ALADI también deberá contar con un certificado digital para realizar con seguridad las transacciones anteriores.

5.6 Anexo técnico

5.6.1 Campos de los certificados digitalesLos siguientes campos DEBEN encontrarse presentes en los certificados:Versión (version)Número de Serie (serialNumber)Algoritmo de Firma (signature)Nombre Distintivo del Emisor (issuer)Validez (Desde, Hasta) (validity (notBefore, notAfter))Nombre Distintivo del Suscriptor (subject)Clave Pública del Suscriptor (subjectPublicKeyInfo)NO DEBEN estar presentes los campos (debido a que corresponden a la versión 2 de la especificación X.509):Identificador único del Emisor (issuerUniqueID)Identificador único del Suscriptor (subjectUniqueID)

Página 23 de 65


5.6.1.1 Versión (Version)

El campo “version” describe la versión del certificado. DEBE tener el valor 2 (correspondiente a versión 3).

5.6.1.2 Número de Serie (Serial Number)

El campo “serialNumber” contiene un número asignado por el certificador a cada certificado. Este número DEBE ser único para cada certificado emitido por cada Autoridad Certificante del certificador.

5.6.1.3 Algoritmo de Firma (Signature)

El campo “signature” DEBE contener el identificador de objeto (OID) del algoritmo y, de ser necesarios, los parámetros asociados usados por el certificador para firmar el certificado. Este identificador DEBE ser alguno de los definidos en el [RFC3279].

5.6.1.4 Nombre Distintivo del Emisor (Issuer)

El campo “issuer” DEBE identificar a la organización responsable de la emisión del certificado (la cuál deberá ser comunicada por cada país a ALADI), mediante la utilización de un subconjunto de los siguientes atributos:Componente de dominio (OID 0.9.2342.19200300.100.1.25:domainComponent)Código de país (OID 2.5.4.6: countryName)Nombre de la organización (OID 2.5.4.10: organizationName)Nombre de la provincia (OID 2.5.4.8: stateOrProvinceName)Nombre de la localidad (OID 2.5.4.7: localityName)Número de serie (OID 2.5.4.5: serialNumber)Otros atributos pueden estar presentes, pero los mismos NO DEBEN ser necesarios para identificar a la organización emisora.Los contenidos y tipos de los atributos deben respetar las mismas pautas establecidas en el punto 1.2.6 para el campo “subject” para certificados de certificadores o proveedores de servicios de firma de digital.El atributo organizationName DEBE estar presente.El atributo “countryName” DEBE estar presente y DEBE representar el país en el cual se encuentra establecido el emisor. Este atributo DEBE estar codificado según el estándar [ISO3166].

5.6.1.5 Validez (Desde, Hasta) (Validity (notBefore, notAfter))

El período de la validez del certificado es el intervalo de tiempo durante el cual el suscriptor se encuentra habilitado para utilizarlo.El campo se representa como una secuencia de dos fechas:“notBefore”: fecha en que el período de validez del certificado comienza.“notAfter”: fecha en que el período de validez del certificado termina.El período de validez de un certificado es el período de tiempo de “notBefore” a “notAfter” inclusive.Un certificador NO DEBE emitir un certificado digital con vencimiento posterior al de su propio certificado.

Página 24 de 65


5.6.1.6 Nombre Distintivo del Suscriptor (Subject)

El campo “subject” identifica la entidad asociada a la clave pública guardada en el campo “subjectPublicKeyInfo”.DEBE contener un nombre distintivo del suscriptor. Dicho nombre DEBE ser único para cada suscriptor de certificado emitido por un certificador durante todo el tiempo de vida del mismo.La identidad del suscriptor DEBE quedar especificada utilizando un subconjunto de los siguientes atributos:Componente de Dominio (OID 0.9.2342.19200300.100.1.25: domainComponent)Código de país (OID 2.5.4.6: countryName)Nombre común (OID 2.5.4.3: commonName)Cargo o título (OID 2.5.4.12: title)Nombre de la organización (OID 2.5.4.10: organizationName)Nombre de la suborganización (OID 2.5.4.11: organizationalUnitName)Nombre de la provincia (OID 2.5.4.8: stateOrProvinceName)Nombre de la localidad (OID 2.5.4.7: localityName)Número de serie (OID 2.5.4.5: serialNumber)Otros atributos pueden estar presentes, pero los mismos NO DEBEN ser necesarios para identificar al suscriptor.El atributo “domainComponent” se define en el RFC 2247 “Using Domains in LDAP/X.500 Distinguished Names” [RFC2247], todos los demás atributos se definen en [RFC3280] y en [X.520].

Para los certificados de Personas Físicas:“commonName”: DEBE estar presente y DEBE corresponder con el nombre que figura en el documento de identidad del suscriptor (Documento Nacional del país de emisión, Pasaporte, ...)“serialNumber” (OID 2.5.4.5: Nro de serie): DEBE estar presente y DEBE contener el tipo y número de documento nacional del titular, expresado como texto y respetando el siguiente formato y codificación: [tipo de documento]“ ”[nro de documento]

“organizationalUnitName” y “organizationName”: en caso de existir serán utilizados para guardar la información relativa a la Organización a la cual el suscriptor se encuentra asociado, en el caso de esta aplicación podría ser una Entidad Habilitada del país (deben respetar los criterios definidos para los atributos “organizationName” y “organizationalUnitName” de personas Jurídicas Públicas o Privadas). El tipo de asociación entre el organismo y el suscriptor debe ser evaluado a partir de la Política de Certificación.“countryName”: DEBE estar presente y DEBE representar la nacionalidad de la persona física.

El atributo “title”, si está presente, DEBE ser utilizado para guardar la posición o función del suscriptor dentro de la organización especificada por los atributos presentes en el campo “subject”. La asociación entre el atributo “title”, el suscriptor y la organización debe ser definida en la correspondiente Política de Certificación.El atributo “countryName” DEBE estar codificado según el estándar [ISO3166].En caso de existir información no verificada incluida en el certificado DEBE informarse esta situación utilizando algún campo descriptivo del certificado. Para ello se RECOMIENDA el empleo del atributo “description” (OID 2.5.4.13: Descripción).Los tipos y longitudes correspondientes a cada atributo DEBEN respetar las definiciones establecidas en [RFC3280] Apéndice A, recomendándose la pauta establecida por este

Página 25 de 65


mismo RFC acerca de la utilización de la codificación UTF8String para los atributos de tipo DirectoryString.

5.6.1.7 Clave Pública del Suscriptor (Subject Public Key Info)

Este campo “subjectPublicKeyInfo” se utiliza para transportar la clave pública y para identificar el algoritmo con el cual se utiliza la clave. El identificador utilizado DEBE ser alguno de los definidos en [RFC3279].

5.6.2 Extensiones de un certificado digital

Las siguientes extensiones DEBEN encontrase presentes en todos los certificados:Restricciones Básicas (BasicConstraint)Uso de Claves (KeyUsage)Puntos de Distribución de la Lista de Certificados Revocados (CRLDistributionPoint)Políticas de Certificación (CertificatePolicies)La siguiente extensión DEBE estar presente en todos los certificados que no sean autofirmados:Identificador de la Clave de la Autoridad Certificante (AuthorityKeyIdentifier)La siguiente extensión DEBE estar presente en todos los certificados de Autoridad Certificante:Identificador de la Clave del Suscriptor (SubjectKeyIdentifier)La siguiente extensión DEBE estar presente en todos los certificados de personas jurídicas públicas o privadas que no identifiquen a un servicio o aplicación:Nombres Alternativos del Suscriptor (SubjectAlternativeName)Se RECOMIENDA la presencia de las siguientes extensiones en los certificados:Uso de Claves Extendido (ExtendedKeyUsage)Nombres Alternativos del Suscriptor (SubjectAlternativeName)

5.6.2.1 Identificador de la Clave de la Autoridad Certificante (Authority Key Identifier)

La extensión “authorityKeyIdentifier” proporciona un medio para identificar la clave pública correspondiente a la clave privada utilizada para firmar un certificado, por ejemplo en los casos en que el emisor tiene múltiples claves de firma.Esta extensión DEBE estar presente en todos los certificados que no sean autofirmados.Esta extensión NO DEBE ser marcada como crítica.

5.6.2.2 Identificador de la Clave del Suscriptor (Subject Key Identifier)

La extensión “subjectKeyIdentifier” proporciona un medio para identificar certificados que contienen una clave pública particular y facilita la construcción de rutas de certificación.Esta extensión DEBE estar presente en todos los certificados de Autoridad Certificante.Esta extensión NO DEBE ser marcada como crítica.

5.6.2.3 Uso de Claves (Key Usage)

La extensión “keyUsage” define el propósito (por ejemplo: cifrado, firma) de la clave contenida en el certificado. DEBE encontrarse presente.

Página 26 de 65


Para certificados de certificadores:

El bit “keyCertSign” DEBE tener valor 1El bit “crlSign” PUEDE tener valor 1El resto de bits DEBEN tener valor 0Para certificados de Proveedores de servicios de firma digital que emiten información de estado de certificados (por ej. CRLs, OCSP):

Si emiten CRLs el bit “crlSign” DEBE tener valor 1Si emiten respuestas OCSP el bit “nonRepudiation” DEBE tener valor 1El resto de bits DEBEN tener valor 0

Para certificados de otros Proveedores de servicios de firma digital:

El bit “nonRepudiation” DEBE tener valor 1El resto de bits DEBEN tener valor 0

Para certificados de Personas Físicas y Jurídicas:

El bit “nonRepudiation” DEBE tener valor 1El bit “digitalSignature” PUEDE tener valor 1 para propósitos de autenticación.Se RECOMIENDA que el resto de bits tengan valor 0

Esta extensión PUEDE ser marcada como crítica.

5.6.3 Formato de Listas de Certificados Revocados (CRLs)

El formato de las Listas de Certificados Revocados X.509 permite la utilización de una amplia variedad de opciones; por esta razón, se hace necesario definir un perfil para las listas de certificados revocados, especificando qué opciones deben aparecer de manera obligatoria, cuáles no está permitido usar y cuáles resulta recomendable incluir.

En lo referente a CRLs se sugiere el siguiente formato:

RFC 3280 “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile” [RFC3280]

Para aquellos casos en que no se hace una mención explícita sobre un tema en particular, se debe utilizar, en carácter de recomendación, lo establecido en el documento antes mencionado. Para una completa implementación de esta especificación se recomienda la consulta de los formatos y definiciones especificadas en este documento.

5.6.4 Campos de una CRL

Los siguientes campos DEBEN encontrarse presentes en todas las CRLs:

Versión (version)

Página 27 de 65


Algoritmo de Firma (signature)

Nombre Distintivo del Emisor (issuer)

Día y Hora de Vigencia (thisUpdate)

Próxima Actualización (nextUpdate)

Certificados Revocados (revokedCertificates) (sólo en caso de que existan certificados revocados)

5.6.4.1 Versión (Version)

El campo “version” describe la versión de la CRL. DEBE tener el valor 1 (correspondiente a Versión 2).

5.6.4.2 Algoritmo de Firma (Signature)

El campo “signature” DEBE contener el identificador de objeto (OID) del algoritmo y, de ser necesarios, los parámetros asociados usados por el certificador para firmar la CRL. Este identificador DEBE ser alguno de los definidos en [RFC3279].

5.6.4.3 Nombre Distintivo del Emisor (Issuer)

El campo “issuer” identifica a la entidad que firma y emite la CRL. Los contenidos y tipos de los atributos DEBEN respetar las pautas establecidas para el campo “issuer” de un certificado.

5.6.4.4 Día y Hora de Vigencia (This Update)

El campo “ThisUpdate” indica la fecha de emisión de la CRL. La fecha de revocación de un certificado de la lista no DEBE ser posterior a esta fecha. La CRL DEBE estar disponible para consulta inmediatamente después de emitida.

5.6.4.5 Próxima Actualización (Next Update)

El campo “NextUpdate” indica la fecha límite de emisión de la próxima CRL. Este campo DEBE estar presente en todas las CRL emitidas.

5.6.4.6 Certificados Revocados (Revoked Certificates)

El campo “RevokedCertificates” contiene la lista de certificados revocados indicados por su número de serie, también pueden incluirse extensiones específicas para cada elemento de esta lista.

Página 28 de 65


5.6.5 Extensiones de una CRL

5.6.5.1 Identificación de Clave de la Autoridad Certificante (Authority Key Identifier)

La extensión “AuthorityKeyIdentifier” proporciona un medio para identificar la clave pública que corresponde a la clave privada utilizada para firmar una CRL.Esta extensión DEBE estar presente en todas las listas de revocación de certificados.

5.6.5.2 Número de CRL (CRL Number)

La extensión “CRLNumber” contiene un número de secuencia creciente para una CRL y emisor dado. Esta extensión permite que los usuarios determinen fácilmente cuando una CRL particular reemplaza a otra CRL.Esta extensión DEBE estar incluida en todas las listas de revocación de certificados.

5.6.5.3 Indicador de Delta CRL (Delta CRL Indicator)

La extensión “DeltaCRLIndicator” permite indicar que una CRL es una CRL incremental o “delta CRL“.El certificador PUEDE utilizar “delta CRL”.De existir esta extensión DEBE ser crítica.

5.6.5.4 Punto de Distribución del Emisor (Issuing Distribution Point)

La extensión “IssuingDistributionPoint” identifica el punto de distribución y el alcance de una CRL particular. Indica, por ejemplo, si la CRL cubre la revocación de certificados del suscriptor solamente, certificados del certificador solamente, etc.De existir esta extensión DEBE ser crítica.

5.6.5.5 CRL más Reciente – Punto de Distribución de la Delta CRL (Freshest CRL - Delta CRL Distribution Point)

La extensión “FreshestCRL” indica dónde puede obtenerse la información de la “ CRL” de una CRL completa.Esta extensión NO DEBE ser utilizada en “delta CRL”.Esta extensión NO DEBE ser crítica.

5.6.5.6 Otras extensiones de CRLs

NO se RECOMIENDA la creación de nuevas extensiones mas allá de las definidas en [RFC3280].

5.6.5.7 Online Certificate Status Protocol (OCSP)

Página 29 de 65


Online Certificate Status Protocol (OCSP) es un método para determinar el estado de revocación de un certificado digital X.509 usando otros medios que no sean el uso de CRLs (Listas de Revocación de Certificados). Este protocolo se describe en el RFC 2560 y está en el registro de standards de Internet.

Los mensajes OCSP se codifican en ASN.1 y habitualmente se transmiten sobre el procolo HTTP. La naturaleza de las peticiones y respuestas de OCSP hace que a los servidores OCSP se les conozca como "OCSP responders".

OCSP fue creado para solventar ciertas deficiencias de las CRLs. Cuando se despliega una PKI (Infraestructura de Clave Pública), es preferible la validación de los certificados mediante OCSP sobre el uso de CRLs por varias razones:

OCSP puede proporcionar una información más adecuada y reciente del estado de revocación de un certificado.

OCSP elimina la necesidad de que los clientes tengan que obtener y procesar las CRLs, ahorrando de este modo tráfico de red y procesado por parte del cliente.

El contenido de las CRLs puede considerarse información sensible, analógamente a la lista de morosos de un banco.

OCSP soporta el encadenamiento de confianza de las peticiones OCSP entre los "responders". Esto permite que los clientes se comuniquen con un "responder" de confianza para lanzar una petición a una autoridad de certificación alternativa dentro de la misma PKI.

5.6.6 Algoritmos criptográficos

Los algoritmos utilizados DEBEN ser los especificados en RFC 3279 “Algorithms and Identifiers for the Certificate and Certificate Revocation List (CRL) Profile” [RFC3279].

Todos los certificados DEBEN respetar las siguientes longitudes mínimas de claves para los algoritmos de firma:

Para certificados de certificador o de información de estado de certificados: RSA 2048 bits, DSA 2048 bits o ECDSA 210 bits.

Para certificados utilizados en servicios relacionados con la firma digital (certificación de hora digital, almacenamiento seguro de documentos electrónicos, etc.): RSA 2048 bits, DSA 2048 bits o ECDSA 210 bits.

Para certificados de usuario (personas físicas o jurídicas): RSA 1024 bits, DSA 1024 bits o ECDSA 160 bits.

5.6.7 Validez de una firma digital

A continuación se describen conceptos a tener en cuenta al momento de implementar un procedimiento de validación de documentos firmados digitalmente.

Página 30 de 65


5.6.7.1 Verificación de una firma digital

El término verificación se utiliza cuando debe determinarse si una firma digital es o no válida.

Cuando un circuito de informacion requiere que los documentos digitales firmados sean almacenados a largo plazo, es necesario contar con información adicional que permita realizar la verificación de la firma. Entre esta información podemos considerar, fecha de firma del documento, certificado firmante, ruta de certificación del certificado firmante, informacion de estado de validez del certificado firmante, etc.

La recolección de los datos de asociados a una firma necesarios para verificar su validez puede ser realizada de varias maneras:los datos son agregados por el firmante del documento como parte del proceso de firma,los datos son agregados por el receptor del documento como parte del proceso de recepción y verificación inicial, o una combinación de los casos anteriores.

5.6.7.2 Validez del certificado digital

La validez del certificado puede depender de tres factores:1.- el compromiso de cualquiera de las claves privadas de firma a lo largo de la ruta de certificación, comenzando por el certificado del firmante hasta el de la autoridad que sea confiable para el verificador.2.- el debilitamiento de los algoritmos o longitudes de clave utilizados para solicitar las firmas (cualquiera dentro de la cadena de certificación), de manera que alguna de ellas pueda romperse en un corto tiempo.3.- cambios en la organización, por ejemplo, si el titular ya no pertenece a la misma.

Cuando es posible determinar que cualquiera de las claves ha sido comprometida, o que el algoritmo ya no es confiable, o que el certificado fue revocado por razones referidas a la organización, es necesario definir si el hecho que invalida el certificado ocurrió antes o después del momento de la firma.De ahí la necesidad de obtener del proveedor de servicios de certificación información sobre el momento de la firma, así como información sobre el estado de cada certificado relevante a efectos de la firma.

Los datos básicos que deben agregarse a una firma para que el verificador pueda determinar su validez a largo plazo son:

información sobre el momento en que se efectuó la firma, obtenida tan pronto como sea posible, para determinar si la firma fue emitida antes de la hora indicada en el COD.

información sobre el estado de los certificados que componen la cadena de certificación, que puedan ser capturados dentro de un período razonable de tiempo.

5.6.7.3 Relacionar la firma y el certificado

Página 31 de 65


Relacionar la firma con el certificado actualmente utilizado por el firmante previene su sustitución y por lo tanto protege de ataques tales como la asignación de la firma a un usuario diferente o a un rol diferente.Del mismo modo, agregar a las firmas los certificados del certificador emisor y de los certificadores de nivel jerárquico superior, puede contribuir a construir una cadena de certificación, que puede ser útil para identificar el estado de dichas CAs. Esta relación puede ser implementada insertando en la firma una referencia a dichos certificados o incluyendo explícitamente los mismos certificados. Debe notarse que una referencia única y unívoca al certificado del firmante es de vital importancia para la integridad de la firma.Esto evita posibles sustituciones de certificados por otros con diferentes semánticas, independientemente de si ellos existen al momento de la firma o son emitidos posteriormente, posiblemente con una clave de firma comprometida.Incluso cuando los diferentes certificados de firma se relacionan con diferentes datos de verificación, es útil especificar esta información, ya que contribuye a que el verificador identifique la corrección de los datos de verificación.

5.6.7.4 Relacionar la firma y el estado de revocación del certificado

Un certificador puede borrar la referencia a un certificado revocado de la CRL al expirar el mismo. En ese caso, si la verificación se produce luego de la expiración, no sería posible establecer si el certificado fue revocado cuando una firma fue emitida. Por eso es necesario incluir en las firmas que puedan perdurar luego de la expiración, una referencia a información sobre el estado del certificado al momento de la firma.De igual modo, dado que las claves utilizadas por los proveedores de información sobre el estado de los certificados para firmar dicha información pueden ser revocadas y expirarán en algún momento, es necesario incluir en la firma esta información completa y capturada cuando el estado de la clave de firma es válido aún, para prevenir ataques como la sustitución de una CRL archivada que solo fuera referenciada, pero no incluída, en una firma.También se puede guardar la respuesta a una consulta del estado de revocación vía protocolo OCSP.

5.6.7.5 Información sobre Timestamp (sellado de tiempo)

Si bien a futuro debe considerarse la posibilidad de utilizar servicio de Timestamp (sellado de tiempo), en esta primera etapa se sugiere que la fecha que cada Entidad Habilitada asigne al certificado de Origen sea considerada como la fecha de su emisión y firma.Esto se contemplará en el campo Signing Time de la firma digital.

5.6.8 Estandares ETSI (European Telecommunications Standards Institute)

Basado en los estándares y recomendaciones de los organismos precedentes, el ETSI, European Telecommunications Standards Institute, ha desarrollado numerosos estándares relacionados con PKI, cubriendo desde las especificaciones de políticas de certificación,

Página 32 de 65


tanto para Entidades de Certificación como para entidades proveedoras de servicios de time-stamping, hasta los formatos de las firmas digitales a utilizar.

Se propone la utilización del estandar TS 101 903 para firma el empleo de firma digital.

5.6.9 TS 101 903: XML Advanced Electronic Signatures (XAdES)

Define los formatos de firma XML que mantienen su validez por largos períodos de tiempo, aun cuando el certicado del firmante ha caducado.

ETSI también define los formatos de firma digital XML en las especificaciones técnicas TS 101 903 definiendo XadES.

Este estándar hace referencia a :

ETSI TS 101 733: "Electronic Signatures and Infrastructures (ESI); Electronic Signature Formats".

IETF RFC 3369 (obsoletes RFC 2630): "Cryptographic Message Syntax (CMS)".

5.6.10 Formatos de firma

La firma digital se puede aplicar sobre los siguientes elementos: el documento del firmante o un hash del mismo.una referencia indubitable al certificado del firmante elegido por este, por ejemplo, el mismo certificado o una referencia a este junto con un valor de hash del certificado.

5.6.10.1 Firma digital (BES o EPES)

El formato BES o EPES incluye la firma digital y otra información básica provista por el firmante. La firma cumple los requisitos para la firma digital avanzada según se define en la Directiva Europea. Provee autenticación básica y protección de integridad y puede ser creada sin servicios de sellado de tiempo. Sin embargo, sin la posibilidad de establecer la fecha y hora, la firma no protege contra el riesgo de que una firma digital, emitida cuando el certificado es válido, pierda su validez si el mismo es revocado posteriormente.

BES: firma digital básica, contiene el documento del firmante, una recopilación de los atributos obligatorios firmados, el valor de la firma digital calculado en el documento y en los atributos firmados, cuando existan. También puede contener una recopilación de atributos firmados adicionales y de atributos opcionales no firmados.

Página 33 de 65


Se propone comenzar con el formato básico de firma, BES, como ilustra la figura.

NOTA:

XML Advanced Electronic Signatures (XAdES), implementa este formato de firma.

Actualmente se están evaluando las librerías de código abierto openxades (http://www.openxades.org) para el manejo de firma y verificación de firmas XML, dichas librerías implementan XAdES.

6 Características del Certificado de Origen Digital

6.1 Cobertura de los Acuerdos ALADI

Este punto tiene como objetivo describir el modelo de COD unificado proporcionando las características de contenido y formato que permiten evaluar la factibilidad de su aplicación.

A efectos de definir los datos que contendrá el COD unificado se efectuó un análisis de los distintos formularios que en la actualidad son utilizados, teniendo en cuenta los distintos acuerdos suscriptos por la República Argentina con los países miembros de la ALADI. En tal sentido, se relevaron los datos contenidos en:

• Formulario tipo de la Asociación (Res Nº 252 art.14 Anexo 4)

• Formulario del AAP CE Nº 14 (ARGENTINA – BRASIL)

• Formulario del AAP CE Nº 18 (MERCOSUR)

• Formulario del AAP CE Nº 35 (MERCOSUR – BOLIVIA)

• Formulario del AAP CE Nº 36 (MERCOSUR – CHILE)

• Formulario del AAP CE Nº 59 (MERCOSUR – COLOMBIA- ECUADOR y VENEZUELA)

La matriz – “Propuesta de Certificado de Origen Digital” – incluida en el Anexo 1 muestra los datos que constituyen el COD unificado, definiéndose el campo XML, tipo de dato, Longitud y como se encuentran referenciados en los formularios originales los distintos campos que lo conforman. El formato de archivo para el COD se trabajo en XML (eXtended Markup Lenguaje).

Página 34 de 65

http://www.openxades.org/


6.2 Datos de los Formularios (XML)

Con el sólo y único objetivo de facilitar la comunicación entre todas las partes intervinientes y así minimizar posibles equívocos en las discusiones tendientes a definir un sistema que dentro de la ALADI permita la utilización del Certificado de Origen Digital (COD,) se consideró apropiado incluir el presente parágrafo que trata someramente tanto los conceptos de XML y XSL cuanto presenta esbozos del denominado "formulario único" y de alguna de las conclusiones resultantes.

Según la Recomendación REC-xml-19980210 de la W3C (World Wide Web Consortium) el Extensible Markup Language (XML) 1.0 o también lenguaje extensible de etiquetas (eXtensible Markup Lenguage) , es un meta-lenguaje que nos permite definir lenguajes de marcado adecuado a usos determinados, que puede ser servido, recibido y procesado en la Web.

Cabe señalar que XML no ha nacido sólo para su aplicación en Internet, sino que se propone como un lenguaje apropiado para el intercambio de información estructurada entre diferentes plataformas.

En nuestro caso, XML será el lenguaje que utilizaremos para intercambiar información en la digitalización de Certificados de Origen (COD).

Entre otros, los objetivos de diseño de XML son:

• XML debe ser directamente utilizable sobre Internet.

• XML debe soportar una amplia variedad de aplicaciones.

• Debe ser fácil la escritura de programas que procesen documentos XML.

• Los documentos XML deben ser legibles por humanos y razonablemente claros.

• El diseño de XML debe ser preparado rápidamente.

• El diseño de XML debe ser formal y conciso.

• Los documentos XML deben ser fácilmente creables.

• Facilitar el intercambio de información .

Como resulta obvio, el empleo de tecnología XML, al ser un estándar internacional y público, no nos ata a una plataforma o sistema de desarrollo concreto, y nos permite un acceso a la información más rápido y eficiente desde diversos dispositivos desde portátiles como un teléfono móvil o terminal PDA hasta nuestra PC de escritorio.

Página 35 de 65


6.3 Formato de los Formularios de cada Acuerdo (XSL)

XSL es un estandar de la organización W3C que presenta una forma de transformar documentos XML en otros e incluso a formatos que no son XML. La unión de XML y XSLT permite separar contenido y presentación, aumentando así la productividad.

Un mismo documento XML puede tener varias hojas de estilo XSL que lo muestren en diferentes formatos (HTML, PDF, PostScript, etc.)

Una hoja de estilo XSL es una serie de reglas que determina cómo va a ocurrir la transformación. Cada regla se compone de un patrón (pattern) y una acción o plantilla (template).

De este modo, cada regla afecta a uno o varios elementos del documento XML. El efecto de las reglas es recursivo, para que un elemento situado dentro de otro elemento puede ser también transformado. Las hojas de estilo tiene una regla raiz que, además de ser procesada, llama a las reglas adecuadas para los elementos hijos.

En el caso del COD resulta sumamente útil para emular visualmente el formulario soporte papel de cada acuerdo facilitando el proceso de transición de la operatoria manual hacia la digital.

XSL nos permite resolver problemas referidos a condicionalidades cuyo cumplimiento supone ciertos criterios de validación en otros.

Así, en aquellos acuerdos (v.gr.: ACE18) en los que en el campo de "Observaciones" deba consignarse alguna información específica (p. ej.: Insumos PAC) el XSL permite representar aquellos casos donde la condición debe ser cumplida.

De forma similar se procederá cuando en el antedicho campo "Observaciones” cualesquiera sea el acuerdo utilizado se deba consignar un "tercer operador".

Generalmente esto permite representar la necesidad de dar cumplimiento a una condición cuya aparición dependa de alguna circunstancia particular de la operación o del acuerdo.

Por otra parte el uso del XSL permite que la Entidad Emisora incorpore elementos visuales como su logotipo u otras formas graficas distintivas del formulario ya sea en pantalla o al momento de la impresión.

Los navegadores o browsers de uso diario para la navegación por Internet, son las herramientas mediante las cuales podemos visualizar los documentos XML.

Al respecto debe señalarse que estos deben incluir de algún modo un parser o analizador para XML y un motor que acepte las hojas de estilo (XSL)

El parser o analizador de XML es el programa que lee el documento XML y hace que los datos que contiene estén accesibles de una forma u otra. Esta funcionalidad está incluida en:

Internet Explorer 5.0 y 6.0 de Microsoft

Página 36 de 65


Derivados del desarrollo Mozilla.(Netscape 6, Mozilla, etc.)

Por ejemplo, con este código podría seleccionarse el Acuerdo sobre el que se trabaja .

<option><xsl:attribute name="value"><xsl:value-of select="@Acuerdo_Nombre"/></xsl:attribute><xsl:if test="$val=@Acuerdo_Nombre">

<xsl:attribute name="selected">selected</xsl:attribute></xsl:if><xsl:value-of select="@Acuerdo_Nombre"/></option>

Y una vez que se ha seleccionado el Acuerdo (Acuerdo_Nombre), podría ocurrir que una parte del formulario no sea procesado por el parser En este caso, si se ha seleccionado el Acuerdo ALADI, no se aplicará: la transformación sobre esa particular sección del documento.

<xsl:choose><xsl:when test="contains(..@Acuerdo_Nombre, "ALADI") or contains(..@Acuerdo_Nombre, "Venezuela")">DISPLAY: none</xsl:when></xsl:choose>

6.4 Especificación de los Archivos de Datos (XSD)

XSD (XML Schema Definition), es una recomendación del World Wide Web Consortium (W3C), y especifica como describir formalmente los elementos que componen un documento XML.

Esta descripción puede ser usada para verificar que cada ítem contenido en un documento adhiere a la descripción del elemento donde debe ser almacenado.

En general un esquema (schema) es una representación de las relaciones entre los atributos y los elementos de un documento XML. De esta manera podemos describir los elementos que integran el COD de manera estructurada, lo que permitirá al documento ser claramente legible a los usuarios .

El uso de XSD permite establecer restricciones al tamaño y formato de los datos, utilizando patronesPor ejemplo :

<xs:element name="Valor_FOB"><xs:simpleType>

<xs:restriction base="xs:decimal"><xs:pattern value="\[0-9]{16}\,\[0-9]{2}"/>

</xs:restriction></xs:simpleType>

</xs:element>

Página 37 de 65

http://searchWebServices.techtarget.com/sDefinition/0,,sid26_gci213331,00.html


En este caso, se restringe a que el campo Valor_FOB en el documento XML esté representado por 16 dígitos para la parte entera, un punto y luego dos lugares decimales.

La representación de los datos del COD puede agruparse de manera tal que queden claramente definidos a simple vista. Por ejemplo, para el detalle de los Productos o Mercaderías a certificar su origen :

6.5 Ejemplos

<xs:element name="Detalle_Producto" type="detalleRef"/><xs:complexType name="detalleRef">

<xs:sequence><xs:element name="Nro_Orden">

<xs:simpleType><xs:restriction base="xs:string">

<xs:maxLength value="4"/><xs:pattern value="\d{4}"/>


</xs:element><xs:element name="Cod_Naladisa_Ncm">


<xs:maxLength value="16"/></xs:restriction>

</xs:simpleType></xs:element><xs:element name="Denominacion">



</xs:simpleType></xs:element><xs:element name="Peso_Cantidad">

<xs:simpleType><xs:restriction base="xs:decimal">

<xs:pattern value="\[0-9]{16}\,\[0-9]{2}"/></xs:restriction>

</xs:simpleType></xs:element><xs:element name="Unidad_Medida">



</xs:simpleType>

Página 38 de 65

Numero de Orden será una cadena de caracteres de 4 dígitos de extensión


</xs:element><xs:element name="Valor_FOB">



</xs:simpleType></xs:element><xs:element name="Normas_Origen">



</xs:simpleType></xs:element>

</xs:sequence></xs:complexType>

El esquema general se vería así :

Página 39 de 65


Página 40 de 65


Los elementos referentes a la firma digital del COD no han sido detallados, al ser éste un tema sobre el que resta la definición del estándar a adoptar.

En el Anexo 2 se adjunta un conjunto de tres archivos electrónicos que implementan un ejemplo del mecanismo propuesto para operar con una definición única que contenga:

1. Todos los datos utilizaods por los acuerdos vigentes, contenidos en un archivo electrónico del COD, con:

a. La especificación de su esctructura, de acuerdo al XML - Schema contenido en el archivo CODv0.xsd.

b. Un ejemplo de datos típicos, de un Certificado de Origen Digital, en formato XML. contenidos en el archivo Cod.xml

2. Un ejemplo de formato de plantilla, obtenible a partir de los datos contenidos en el punto b, correspondiente al AAP CE Nº 18 – MERCOSUR, contenido en archivo Cod.xslt

Para una verificación práctica del mecanismo expuesto, se deben copiar a un mismo directorio los archivos Cod.xml y Cod.xslt, y abrir, el archivo Cod.xml con alguno de los exploradores (browsers) habituales, con lo cual se visualizará el Formulario AAP CE Nº 18 – MERCOSUR.

7 Procedimientos Aduaneros

7.1 Proceso Propuesto para el Tratamiento del COD, en los Sistemas Aduaneros del País Importador

7.1.1 Diagrama

Página 41 de 65


C O D(*) (1)

BANDEJA DEENTRADA

(2)

PROCESOSDE

VALIDACIÓN(3)

INTERACCIÓNCON OTROSSISTEMAS (5)

OTROSSISTEMAS

VALIDACIÓN DEDATOS CON LADESTINACIÓN

(VINCULACIÓN)(6)

BANDEJA DESALIDA

DESTINA-CIONES DE

IMPORTACIÓN

AUTENTICACIÓN

VINCU-LACIÓN (7)

INCORPORA-CIÓN AL SIM

RECEPCIÓNO RECHAZO

(4)

ACEPTACIÓNO RECHAZO

(5)

APLICACIÓNO RECHAZO

PROCESOS DECONTROL

MANUALES(APLICACIÓN

DEFINITIVA) (8)

7.1.2 Descripción

- Luego de la recepción del DOC emitido por las Entidades Habilitadas, el usuario (Importador o su Despachante de Aduana) lo enviará vía Internet a los sistemas de la aduana de su país, con carácter previo al momento de la oficialización de la destinación de las mercaderías.

- El documento electrónico enviado será recepcionado en la Bandeja de Entrada del Sistema Informático Aduanero (SIA) de cada Estado Parte. El proceso de envío y recepción será efectuado con los estándares tecnológicos y de seguridad que utilice el SIA.

- Recibido el documento electrónico, el SIA verificará la integridad del mismo acorde a pautas predeterminadas, enviando a la Bandeja de Salida la aceptación o rechazo del documento recibido.

- A través de la Bandeja de Salida, el Importador/Despachante recibirá del SIA un mensaje a fin de tomar conocimiento del rechazo o recepción por parte de la Aduana del documento enviado.

- El SIA interactúa mediante Servicios Web con los sistemas que contienen los COD emitidos vigentes a fin de verificar la autenticidad y consistencia de información del archivo recibido, para luego informar al Importador/Despachante por la Bandeja de Salida del SIA de la aceptación o rechazo del COD oportunamente enviado.

Aceptado el COD, el mismo queda en un repositorio del SIA a la espera de su vinculación con la Destinación de Importación a oficializarse en el SIA.

Una vez registrada la Destinación de Importación el SIA realizará una serie de controles mínimos destinados a verificar mínimamente la aplicación del COD a la destinación

Página 42 de 65


declarada. Realizada esta tarea, se vincularan mediante un proceso informático con los COD correspondiente disponibles en la Base de Datos local. El SIA informará al Importador/Despachante, mediante un mensaje de la aplicación o rechazo del COD.

Posteriormente se producirán los procesos de control manuales que determinarán la definitiva aplicación del COD, y de corresponder la liberación de la mercadería.

8 Difusión

En este Capítulo, a completar por la coordinación del proyecto, se detallarán los lineamientos generales del proceso de difusión informativa del proyecto en las comunidades de comercio exterior participantes e interesadas, a fin de obtener consenso y procedimientos homogéneos que faciliten su desarrollo y puesta en operación, tanto en la etapa de proyecto piloto como durante su implementación definitiva, con la indicación de los contactos responsables de recibir y distribuir, dentro del grupo de trabajo argentino, las observaciones recibidas de entidades no pertenecientes al mismo y de los grupos de trabajo de otros países.

Página 43 de 65


9 Glosario de Términos

Bandeja de Entrada: Repositorio donde se recepcionan los mensajes, documentos electrónicos, etc. enviados por los usuarios del sistema.

Bandeja de Salida: Repositorio donde el usuario accede a los mensajes, documentos electrónicos, etc. remitidos a él por la Administración del Sistema.

Certificados de Origen ALADI: Los emitidos en el ámbito de los Acuerdos suscritos al amparo del tratado de Montevideo 1980.

COD: Certificado de origen digital, emitido en formato digital, firmado electrónicamente, enviado a través de redes de transmisión de datos como Internet y almacenado en una base de datos.

Entidades Habilitadas: Todas las entidades autorizadas a emitir COD.

Repositorio: Base de datos que en la cual estarán almacenados todos los COD emitidos y vigentes.

SIA: Sistema informático aduanero de registro de las operaciones de Importación/Exportación en el país importador de la mercadería cuyo origen fue certificado a través del COD.

Servicios Web: Servicios ofrecidos para el intercambio de información transaccional entre sistemas, basados en estándares tecnológicos preestablecidos.

Usuario: Persona física o jurídica que utiliza los recursos informáticos de la Aduana

Página 44 de 65


10 Bibliografía

1. Propuesta para la Digitalización de Certificados de Origen en el ámbito de la ALADI obtenible en el sitio www.aladi.org

2. RFC 2527 - Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, disponible en el sitio www.ietf.org

3. RFC 3280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, disponible en el sitio www.ietf.org

4. RFC 3739 - Internet X.509 Public Key Infrastructure Qualified Certificates Profile, disponible en el sitio www.ietf.org

5. RFC 3279 - Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, disponible en el sitio www.ietf.org

6. RFC 3852 - Cryptographic Message Syntax (CMS), disponible en el sitio www.ietf.org

7. RFC 2560 - X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP , disponible en el sitio www.ietf.org

8. RFC 3161 - Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP), disponible en el sitio www.ietf.org

9. X.509 : Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks, disponible en http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509

10. TS 101 733 - Electronic Signature Formats, disponible en el sitio www.ietf.org. http://portal.etsi.org/esi/el-sign.asp.

11. TS 101 903 - XML Advanced Electronic Signatures (XAdES), disponible en el sitio http://portal.etsi.org/esi/el-sign.asp.

12. CWA 14171 - General guidelines for electronic signature verification, disponible en http://www.cenorm.be/cenorm/businessdomains/businessdomains/isss/cwa/electronic%2Bsignatures.asp

Página 45 de 65

http://portal.etsi.org/esi/el-sign.asp

http://www.cenorm.be/cenorm/businessdomains/businessdomains/isss/cwa/electronic%2Bsignatures.asp

http://www.cenorm.be/cenorm/businessdomains/businessdomains/isss/cwa/electronic%2Bsignatures.asp

http://portal.etsi.org/esi/el-sign.asp

http://www.ietf.org/

http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509

http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509












http://www.aladi.org/


11 Anexos

11.1 Anexo 1 – Planilla Consolidada con los datos utilizados por todos los acuerdos ALADI

La Planilla en la que se indica:

1. Los Datos incluidos en los diversos acuerdos ALADI, agrupados en :

a. Generales

b. Producto Exportado

c. Certificaciones de Origen

2. La Definición de la naturaleza de los Datos

a. Campo XML

b. Tipo de Dato

c. Longitud Formato

d. Campo contemplado en los Formularios de los Siguientes Certificados de Origen

e. Campo referenciado en el Formulario Original como:

f. Observaciones

y su relación a los archivos electrónicos incorporados, como ejemplo en el presente documento. puede encontrarse en el archivo :

ALADI-Certificado-Digital-Datos-Ver-Mar_06.xls

Incluido en la página.

11.2 Anexo 2 - Ejemplo de Archivo de Datos Unico con Múltiples Formatos para cada Acuerdo.

11.2.1 CERTIFICADO DE ORIGEN DEL MERCOSUR

1.PRODUCTOR FINAL 0 EXPORTADOR (NOMBRE ,DIRECCION ,PAIS)

IDENTIFICADOR DEL CERTIFICADO (NUMERO)

Página 46 de 65

http://200.40.42.222/gtah/ALADI-Certificado-Digital-Datos-Ver-Mar_06.xls


Acme Inc.Avda. Perez 1660 (C1440CQN) Buenos AIresArgentina

005828

2.IMPORTADOR(NOMBRE,DiIRECCION ,PAIS)

Rand CorporationDe las Mercedes 1234 AsuncionParaguay3.CONSIGNATARIO(NOMBRE PAIS)

Rexach CorporationArtigas 12 Asuncion Paraguay

NOMBRE DE LA ENTIDAD EMISORA DEL CERTIFICADO

Camara de Exportadores de la Republica ArgentinaAvda. Roque Saenz Pe#a 740 1er PisoCap. Fed.Buenos AiresArgentina

4.PUERTO O LUGAR DE EMBARQUE PREVISTO

Buenos Aires

5.PAIS DE DESTINO DE LAS MERCADERIAS

Paraguay6 MEDIO DE TRANSPORTE PREVISTO

Camion

7.FACTURA COMERCIAL

NUMERO 0099-00000051 FECHA 01 / 02 / 20068 N DE ORDEN

(A)9. CODIGOSNCM

10. DENOMINACION DE LAS MERCADERIAS

(B)11. PESO LIQUIDOO CANTIDAD

12. VALOR FOB EN(U$S)

0001 61115.93.00 De fibras sinteticas: Los demas: CALZAS PANTYMEDIAS, LEOTARDOS, MEDIAS, CALCETINES Y DEMAS ARTICULOS DE CALCETERIA, INCLUSO PARA VARICES DE PUNTO. - Media Futbol team sock - rojo

144.00 Pares 1390.24

N DE ORDEN13. NORMAS DE ORIGEN (C)0001 VIII PROTOCOLO ADICIONAL ANEXO I - CAPITULO III-ARTICULO 3-INCISO a)14. OBSERVACIONES

Operacion por cuenta y orden de SockTrader Rosario 120 Uruguay 00001 2006-03-01

CERTIFICADO DE ORIGEN

Página 47 de 65


15. DECLARACION DEL PRODUCTOR FINAL O DEL EXPORTADOR.DECLARAMOS QUE LAS MERCADERIAS MENCIONADAS EN EL PRESENTE FORMULARIO FUERON PRODUCIDAS EN URUGUAY Y ESTAN DE ACUERDO CON LAS CONDICIONES DE ORIGEN ESTABLECIDAS EN EL ACUERDO A.C.E. N 18

FECHA : 01 / 03 / 2006

SELLO Y FIRMA

16.CERTIFICACION DE LA ENTIDAD HABILITADA.CERTIFICAMOS LA VERACIDADA DE LA DECLARACION QUE ANTECEDE DE ACUERDO CON LA LEGISLACION VIGENTE.

FECHA : 01 / 03 / 2006

SELLO Y FIRMA

11.2.2 XML - Schema con la definición del Archivo de Datos (Contenido del archivo CODv0.xsd)

<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified" attributeFormDefault="unqualified">

<xs:element name="COD"><xs:complexType>

<xs:sequence><xs:element name="schemaLocation" default="Codv0.xsd">



</xs:simpleType></xs:element><xs:element ref="Acuerdo"/>

</xs:sequence><xs:attribute name="Name" type="xs:string" use="required"/>

</xs:complexType></xs:element><xs:element name="Acuerdo">

<xs:complexType><xs:sequence>

<xs:element name="Acuerdo_Nombre"><xs:simpleType>

<xs:restriction base="xs:string"><xs:maxLength value="256"/>


</xs:element><xs:element name="Certificado_Nro">

<xs:simpleType><xs:restriction base="xs:positiveInteger">

<xs:minInclusive value="1"/><xs:maxInclusive

value="9999999999999999"/></xs:restriction>

</xs:simpleType>

Página 48 de 65

http://200.40.42.222/gtah/codv0.xsd


</xs:element><xs:element name="Pais_Exportador" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Puerto_Embarque" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Pais_Destino" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Medio_Transporte" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Producidas_en" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Acuerdo_Acronimo" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Ciudad_Certificacion" minOccurs="0">




Página 49 de 65


<xs:element name="Fecha_Declaracion_Exp" minOccurs="0"><xs:simpleType>

<xs:restriction base="xs:date"/></xs:simpleType>

</xs:element> <xs:element name="Fecha_Certificacion_EH" minOccurs="0">

<xs:simpleType><xs:restriction base="xs:date"/>


<xs:element ref="Entidad_Habilitada"/><xs:element ref="Exportador"/><xs:element ref="Importador"/><xs:element ref="Consignatario"/><xs:element ref="Factura_Comercial" maxOccurs="unbounded"/><xs:element ref="Detalle_Producto" maxOccurs="unbounded"/><xs:element ref="Observaciones" maxOccurs="unbounded"/>


</xs:element><xs:element name="Entidad_Habilitada">


<xs:element name="Nombre_EH"><xs:simpleType>



</xs:element><xs:element name="Direccion_EH">



</xs:simpleType></xs:element><xs:element name="Localidad_EH">



</xs:simpleType></xs:element><xs:element name="Ciudad_EH">



Página 50 de 65


</xs:simpleType></xs:element><xs:element name="Pais_EH">





</xs:element><xs:element name="Exportador">


<xs:element name="Nombre_RazonSocial_Exp" minOccurs="0"><xs:simpleType>



</xs:element><xs:element name="Direccion_Exp" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Localidad_Exp" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Pais_Exp" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Fecha_Declaracion_Exp" minOccurs="0">




Página 51 de 65


</xs:element><xs:element name="Importador">


<xs:element name="Nombre_RazonSocial_Imp" minOccurs="0"><xs:simpleType>



</xs:element><xs:element name="Direccion_Imp" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Localidad_Imp" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Pais_Imp" minOccurs="0">





</xs:element><xs:element name="Consignatario">


<xs:element name="Nombre_Con" minOccurs="0"><xs:simpleType>



</xs:element><xs:element name="Pais_Con" minOccurs="0">



Página 52 de 65




</xs:element><xs:element name="Factura_Comercial">


<xs:element name="Factura_Comercial_Numero" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Factura_Comercial_Fecha" minOccurs="0">




</xs:element><xs:element name="Detalle_Producto" type="detalleRef"/><xs:complexType name="detalleRef">











</xs:simpleType></xs:element><xs:element name="Peso_Cantidad">

Página 53 de 65







</xs:simpleType></xs:element><xs:element name="Valor_FOB">







</xs:sequence></xs:complexType><xs:element name="Observaciones" type="detalleObs"/><xs:complexType name="detalleObs">

<xs:sequence><xs:element name="Observaciones_Desc">



</xs:simpleType></xs:element><xs:element name="Insumos_PAC">



</xs:simpleType></xs:element><xs:element name="Tercer_Operador_RazSoc">


<xs:maxLength value="64"/>

Página 54 de 65



</xs:element><xs:element name="Tercer_Operador_Domicilio">



</xs:simpleType></xs:element><xs:element name="Tercer_Operador_Pais">



</xs:simpleType></xs:element><xs:element name="Tercer_Operador_Factura_Nro">



</xs:simpleType></xs:element><xs:element name="Tercer_Operador_Factura_Fecha">




</xs:schema>

11.2.3 Datos Típicos, de un Certificado de Origen Digital (Contenido del archivo Cod.xml)

<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet type="text/xsl" href="Cod.xslt"?><COD Name="CodId" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="CODv0.xsd">

<schemaLocation>CodV0.xsd</schemaLocation><Acuerdo>

<Acuerdo_Nombre>CERTIFICADO DE ORIGEN DEL MERCOSUR</Acuerdo_Nombre>

<Certificado_Nro>005828</Certificado_Nro><Puerto_Embarque>Buenos Aires</Puerto_Embarque><Pais_Destino>Paraguay</Pais_Destino><Medio_Transporte>Camion</Medio_Transporte><Producidas_en>URUGUAY</Producidas_en>

Página 55 de 65

http://200.40.42.222/gtah/cod.xml


<Fecha_Declaracion_Exp>2006-03-01</Fecha_Declaracion_Exp><Fecha_Certificacion_EH>2006-03-01</Fecha_Certificacion_EH><Entidad_Habilitada>

<Nombre_EH>Camara de Exportadores de la Republica Argentina</Nombre_EH>

<Direccion_EH>Avda. Roque Saenz Pe#a 740 1er Piso</Direccion_EH><Localidad_EH>Cap. Fed.</Localidad_EH><Ciudad_EH>Buenos Aires</Ciudad_EH><Pais_EH>Argentina</Pais_EH>

</Entidad_Habilitada><Exportador>

<Nombre_RazonSocial_Exp>Acme Inc.</Nombre_RazonSocial_Exp><Direccion_Exp>Avda. Perez 1660 (C1440CQN) Buenos

AIres</Direccion_Exp><Pais_Exp>Argentina</Pais_Exp>

</Exportador><Importador>

<Nombre_RazonSocial_Imp> Rand Corporation</Nombre_RazonSocial_Imp>

<Direccion_Imp>De las Mercedes 1234 Asuncion</Direccion_Imp><Pais_Imp>Paraguay</Pais_Imp>

</Importador><Consignatario>

<Nombre_Con>Rexach Corporation</Nombre_Con><Pais_Con> Artigas 12 Asuncion Paraguay</Pais_Con>

</Consignatario><Factura_Comercial>

<Factura_Comercial_Numero>0099-00000051</Factura_Comercial_Numero>

<Factura_Comercial_Fecha>2006-02-01</Factura_Comercial_Fecha></Factura_Comercial><Detalle_Producto>

<Nro_Orden>0001</Nro_Orden><Cod_Naladisa_Ncm>61115.93.00</Cod_Naladisa_Ncm><Denominacion>De fibras sinteticas: Los demas: CALZAS

PANTYMEDIAS, LEOTARDOS, MEDIAS, CALCETINES Y DEMASARTICULOS DE CALCETERIA, INCLUSO PARA VARICES DE

PUNTO. - Media Futbol team sock - rojo

</Denominacion><Peso_Cantidad>144.00</Peso_Cantidad><Unidad_Medida>Pares</Unidad_Medida><Valor_FOB>1390.24</Valor_FOB><Normas_Origen>VIII PROTOCOLO ADICIONAL ANEXO I - CAPITULO

III-ARTICULO 3-INCISO a)</Normas_Origen></Detalle_Producto><Observaciones>

<Observaciones_Desc>Operacion por cuenta y orden de </Observaciones_Desc>

<Insumos_PAC/>

Página 56 de 65


<Tercer_Operador_RazSoc> SockTrader </Tercer_Operador_RazSoc><Tercer_Operador_Domicilio> Rosario 120

</Tercer_Operador_Domicilio><Tercer_Operador_Pais> Uruguay </Tercer_Operador_Pais><Tercer_Operador_Factura_Nro> 00001

</Tercer_Operador_Factura_Nro><Tercer_Operador_Factura_Fecha> 2006-03-01

</Tercer_Operador_Factura_Fecha></Observaciones>

</Acuerdo></COD>

11.2.4 Formato de la Plantilla, correspondiente al AAP CE Nº 18 – MERCOSUR, (contenido del archivo Cod.xslt)

<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified" attributeFormDefault="unqualified">

<xs:element name="COD"><xs:complexType>

<xs:sequence><xs:element name="schemaLocation" default="Codv0.xsd">



</xs:simpleType></xs:element><xs:element ref="Acuerdo"/>

</xs:sequence><xs:attribute name="Name" type="xs:string" use="required"/>

</xs:complexType></xs:element><xs:element name="Acuerdo">


<xs:element name="Acuerdo_Nombre"><xs:simpleType>



</xs:element><xs:element name="Certificado_Nro">

<xs:simpleType><xs:restriction base="xs:positiveInteger">

<xs:minInclusive value="1"/><xs:maxInclusive

value="9999999999999999"/>

Página 57 de 65

http://200.40.42.222/gtah/cod.xslt



</xs:element><xs:element name="Pais_Exportador" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Puerto_Embarque" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Pais_Destino" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Medio_Transporte" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Producidas_en" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Acuerdo_Acronimo" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Ciudad_Certificacion" minOccurs="0">



Página 58 de 65





<xs:element name="Fecha_Certificacion_EH" minOccurs="0"><xs:simpleType>

<xs:restriction base="xs:date"/></xs:simpleType>

</xs:element>

<xs:element ref="Entidad_Habilitada"/><xs:element ref="Exportador"/><xs:element ref="Importador"/><xs:element ref="Consignatario"/><xs:element ref="Factura_Comercial" maxOccurs="unbounded"/><xs:element ref="Detalle_Producto" maxOccurs="unbounded"/><xs:element ref="Observaciones" maxOccurs="unbounded"/>


</xs:element><xs:element name="Entidad_Habilitada">


<xs:element name="Nombre_EH"><xs:simpleType>



</xs:element><xs:element name="Direccion_EH">



</xs:simpleType></xs:element><xs:element name="Localidad_EH">



</xs:simpleType></xs:element><xs:element name="Ciudad_EH">


Página 59 de 65



</xs:simpleType></xs:element><xs:element name="Pais_EH">





</xs:element><xs:element name="Exportador">


<xs:element name="Nombre_RazonSocial_Exp" minOccurs="0"><xs:simpleType>



</xs:element><xs:element name="Direccion_Exp" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Localidad_Exp" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Pais_Exp" minOccurs="0">






Página 60 de 65



</xs:element><xs:element name="Importador">


<xs:element name="Nombre_RazonSocial_Imp" minOccurs="0"><xs:simpleType>



</xs:element><xs:element name="Direccion_Imp" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Localidad_Imp" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Pais_Imp" minOccurs="0">





</xs:element><xs:element name="Consignatario">


<xs:element name="Nombre_Con" minOccurs="0"><xs:simpleType>



</xs:element><xs:element name="Pais_Con" minOccurs="0">


Página 61 de 65





</xs:element><xs:element name="Factura_Comercial">


<xs:element name="Factura_Comercial_Numero" minOccurs="0">



</xs:simpleType></xs:element><xs:element name="Factura_Comercial_Fecha" minOccurs="0">




</xs:element><xs:element name="Detalle_Producto" type="detalleRef"/><xs:complexType name="detalleRef">











</xs:simpleType>

Página 62 de 65


</xs:element><xs:element name="Peso_Cantidad">






</xs:simpleType></xs:element><xs:element name="Valor_FOB">







</xs:sequence></xs:complexType><xs:element name="Observaciones" type="detalleObs"/><xs:complexType name="detalleObs">

<xs:sequence><xs:element name="Observaciones_Desc">



</xs:simpleType></xs:element><xs:element name="Insumos_PAC">



</xs:simpleType></xs:element><xs:element name="Tercer_Operador_RazSoc">

<xs:simpleType>

Página 63 de 65




</xs:element><xs:element name="Tercer_Operador_Domicilio">



</xs:simpleType></xs:element><xs:element name="Tercer_Operador_Pais">



</xs:simpleType></xs:element><xs:element name="Tercer_Operador_Factura_Nro">



</xs:simpleType></xs:element><xs:element name="Tercer_Operador_Factura_Fecha">




</xs:schema>

Página 64 de 65


12 Indice Alfabético

AActores · 4, 5, 9Aduana de exportación · 6, 9, 16, 17Aduana de importación · 6, 7, 9, 14, 15, 17Aduana Expo · 6Aduana Impo · 6AH · 5, 9ALADI · 1, 3, 4, 5, 7, 8, 9, 10, 11, 12, 14, 15, 16, 17, 19, 20,

21, 22, 23, 24, 44Asociación Latinoamericana de Integración · 5, 9Autoridad Certificante · 9, 12, 14, 16, 24, 26, 29Autoridad Habilitante · 5, 9, 12, 15, 16CCertificado de Origen · 1, 3, 7, 8, 10, 11, 13, 14, 15, 34certificados digitales · 18, 19, 20, 21, 23Certificados Revocados · 18, 26, 27, 28Certificate Revocation List · 18, 19, 27, 30, 44CO · 7, 8, 10COD · 1, 3, 10, 13, 14, 15, 16, 17, 18, 19, 20, 22, 23, 31CRL · 18, 19, 27, 28, 29, 30, 32, 44DDeclaración Jurada · 7, 10, 13Definición Funcional · 4DJ · 7, 10Documentos · 4, 6, 9, 10EEH · 6, 9, 17, 23Entidad Habilitada · 6, 7, 8, 9, 13, 14, 16, 17, 19, 20, 25, 32estado de revocación del certificado · 32Expo · 6, 9Exportador · 6, 8, 9, 13, 14, 16F

FH · 6, 9, 14, 16, 23Firma digital · 19, 33Firma Habilitada · 6, 9, 13, 14, 19, 23Funcionalidad · 4, 8, 15IImpo · 6, 9Importador · 6, 8, 9, 13, 14, 15, 17Infraestructura · 4, 7, 11, 12, 30MMERCOSUR · 13, 14, 16, 17, 18OOCSP · 21, 22, 27, 29, 30, 32, 44Online Certificate Status Protocol · 29, 30, 44Operatoria · 4, 7, 8, 12, 13PPerfil · 18Personas Físicas · 25, 27Proceso ·

Actual · 4, 5, 7Digital · 4, 11, 12, 13

Procesos · 4, 7, 11SSolicitud CO · 7TTimestamp · 32VValidez del certificado digital · 31Verificación de una firma digital · 31XXAdES · 20, 33, 34, 44XML Advanced Electronic Signatures · 33, 34, 44

Página 65 de 65

aladi – certificado de origen digital (cod)foros.aladi.org/gtah/prop-ar-cod-10-03-06.pdf ·...

Documents