3.7 Comandos y gestión de registros (LDS2)

Los registros de viaje, los registros de visados y los certificados DEBEN almacenarse en el EF, en las respectivas aplicaciones, y tener una estructura lineal con registros de tamaño variable. Véanse las figuras 4 y 5.

Los registros dentro de cada EF DEBEN llevar como referencia un número de registro. Cada número de registro DEBE ser único y secuencial (el cero para referenciar el registro seleccionado queda fuera del alcance de este documento).

Dentro de cada EF que admite una estructura lineal, los números de registro DEBEN asignarse secuencialmente cuando se añaden por ejemplo según el orden de creación; el primer registro (número uno) es el registro que se creó primero.

DEBEN usarse los siguientes comandos [ISO/IEC 7816-4] para el acceso a los registros:

• APPEND RECORD Adición de registros de viaje, visados, certificados;

• READ RECORD(S) Lectura de uno o más registros de viaje, visados, certificados;

• SEARCH RECORD Búsqueda de uno o más registros de viaje, visados, certificados.

Nota.— Los acrónimos utilizados en esta subsección se definen en [ISO/IEC 7816-4].

3.7.1 Comando APPEND RECORD

El comando inicia la adición de un registro nuevo al final de una estructura lineal.

Tabla 8. Comando APPEND RECORD

Tabla 9. Respuesta APPEND RECORD

Tabla 10. Codificación de P2 en el comando APPEND RECORD

3.7.2 Comando READ RECORD

El comando devuelve el contenido completo o parcial de uno o más registros direccionados del ED seleccionado. Dependiendo del tamaño del registro y del contenido del campo Le, el campo de datos de la respuesta contiene uno de los elementos siguientes:

(El comando devuelve el contenido completo o parcial de uno o más registros direccionados del ED seleccionado. Dependiendo del tamaño del registro y del contenido del campo Le, el campo de datos de la respuesta incluye uno de los elementos siguientes:)

• la primera parte del registro direccionado;

• uno (o más) registros completos direccionados;

• uno (o más) registros completos direccionados seguidos de la primera parte del registro siguiente.

En [ISO/IEC 7816-4] figuran detalles y en el apéndice H figura un ejemplo de lectura de un registro de viaje.

En la figura 2 se ilustra el campo de datos de la respuesta. La comparación de Nr con la estructura TLV indica si el registro único (lectura de un registro) o el último registro (lectura de todos los registros) está incompleto, completo o rellenado.

Tabla 11. Comando READ RECORD

Tabla 12. Respuesta READ RECORD

Tabla 13. Codificación de P2 con el comando READ RECORD

Nota 1.— Otras combinaciones de bits quedan fuera del alcance de esta especificación. Si el campo Le solo contiene bytes puestos a ‘00’, entonces el comando debería leer completamente el registro individual solicitado o la secuencia de registros solicitada, dependiendo de los bits 3, 2 y 1 de P2 y dentro del límite de la longitud máxima admitida para el campo Le ampliado.

(Nota 1.— Otras combinaciones de bits quedan fuera del alcance de esta determinación. Si el campo Le solo incluye bytes puestos a ‘00’, entonces el comando debería leer completamente el registro individual solicitado o la secuencia de registros solicitada, dependiendo de los bits 3, 2 y 1 de P2 y dentro del límite de la longitud máxima admitida para el campo Le ampliado.)

Nota 2.— El comando READ RECORD con campos de longitud corta queda fuera del alcance de esta especificación.

Caso a — Completar la lectura de un registro (el campo Le solo contiene bytes puestos a ‘00’)

(Caso a — Completar la lectura de un registro (el campo Le solo incluye bytes puestos a ‘00’))

Caso b — Leer varios registros hasta el final del fichero (el campo Le solo contiene bytes puestos a ‘00’)

(Caso b — Leer varios registros hasta el final del fichero (el campo Le solo incluye bytes puestos a ‘00’))

Figura 2. Campos de datos de la respuesta

3.7.3 Comando SEARCH RECORD

El comando inicia una búsqueda en los registros almacenados dentro del EF respectivo. El campo de datos del comando contiene el DO’7F76’ de gestión de registros, que define la referencia del fichero, la configuración de búsqueda y la cadena de búsqueda (véase la tabla 17). El campo de datos de la respuesta devuelve el DO’7F76’ de gestión de registros, que contiene uno o más DO’02’ y el número de registro que corresponde a los criterios de búsqueda dentro del EF direccionado.

(El comando inicia una búsqueda en los registros almacenados dentro del EF respectivo. El campo de datos del comando incluye el DO’7F76’ de gestión de registros, que define la referencia del fichero, la configuración de búsqueda y la cadena de búsqueda (véase la tabla 17). El campo de datos de la respuesta devuelve el DO’7F76’ de gestión de registros, que incluye uno o más DO’02’ y el número de registro que corresponde a los criterios de búsqueda dentro del EF direccionado.)

En un EF que admite registros de tamaño variable con una estructura lineal, PUEDE que la búsqueda NO tenga en cuenta los registros con una ventana de búsqueda más corta que la cadena de búsqueda.

(En un EF que admite registros de tamaño diferente con una estructura lineal, PUEDE que la búsqueda NO tenga en cuenta los registros con una ventana de búsqueda más corta que la cadena de búsqueda.)

Tabla 14. Comando SEARCH RECORD

Tabla 15. Respuesta SEARCH RECORD

Nota.— El campo de datos de la respuesta puede estar ausente si no se encuentra correspondencia.

Tabla 16. Codificación de P2 para el comando SEARCH RECORD

Tabla 17. Plantilla de gestión de registros para una búsqueda mejorada en múltiples registros

Nota 1.— No se admite un DO desplazado vacío en la plantilla de la ventana de búsqueda.

Nota 2.— Si la plantilla de la ventana de búsqueda utiliza el valor ‘00’ para el número de bytes, la LDS2 de la microplaqueta del eMRTD DEBE buscar todos los bytes del desplazamiento en los registros.

Nota 3.— El comando SEARCH RECORD admite solo los DO especificados en la tabla 17. Esto implica que el comando SEARCH RECORD admite exactamente un DO referencia de fichero en el DO de la gestión de registros y exactamente una cadena de búsqueda en la plantilla de la cadena de búsqueda. El comando PUEDE no tener en cuenta DO adicionales o contestar con un código de error si se usan DO adicionales.

(Nota 3.— El comando SEARCH RECORD admite solo los DO (Data Object = Objeto de datos) descritos en la tabla 17. Esto conlleva que el comando SEARCH RECORD admite exactamente un DO referencia de fichero en el DO de la gestión de registros y exactamente una cadena de búsqueda en la plantilla de la cadena de búsqueda. El comando PUEDE no tener en cuenta DO adicionales o contestar con un código de error si se usan DO adicionales.)

3.8 Gestión de ficheros transparentes y otros (LDS2)

Los EF transparentes de datos biométricos adicionales los crea quien expide la LDS2 del eMRTD en el estado desactivado operacional (el mecanismo de creación queda fuera del alcance de esta especificación). En el estado desactivado, puede seleccionarse, escribirse, actualizarse y leerse el EF con las autorizaciones apropiadas.

Los siguientes comandos [ISO/IEC 7816-4] DEBEN usarse para escribir y leer los EF transparentes con datos biométricos adicionales:

(Los EF transparentes de datos biométricos adicionales los crea quien emite la LDS2 del eMRTD en el estado desactivado operacional (el mecanismo de creación queda fuera del alcance de esta determinación). En el estado desactivado, puede seleccionarse, escribirse, actualizarse y leerse el EF con las autorizaciones adecuadas.

Los siguientes comandos [ISO/IEC 7816-4] DEBEN usarse para escribir y leer los EF transparentes con datos biométricos adicionales:)

• UPDATE BINARY Escritura de los datos biométricos adicionales;

• READ BINARY Lectura de los datos biométricos adicionales.

El siguiente comando [ISO/IEC 7816-9] DEBE usarse para activar el EF transparente después de cumplir debidamente las condiciones de acceso de lectura y escritura de la LSD2:

(El siguiente comando [ISO/IEC 7816-9] DEBE usarse para activar el EF transparente después de cumplir debidamente los requisitos de acceso de lectura y escritura de la LSD2:)

• ACTIVATE Activación del EF de datos biométricos adicionales.

Nota.— Los acrónimos utilizados en esta subsección se definen en [ISO/IEC 7816-4].

En el estado activado, puede seleccionarse y leerse el EF con las autorizaciones apropiadas (relacionadas con el estado activado) y ninguna autorización de ningún tipo permite la escritura o adición del EF transparente.

(En el estado activado, puede seleccionarse y leerse el EF con las autorizaciones adecuadas (relacionadas con el estado activado) y ninguna autorización de ningún tipo admite la escritura o adición del EF transparente.)

El comando FILE AND MEMORY MANAGEMENT (FMM) DEBE usarse antes de la escritura para determinar si hay suficiente espacio de memoria disponible en el EF.

El IS DEBE usar la siguiente secuencia de escritura para el EF.Biometrics:

(El IS (Inspection System = Sistema de inspección) DEBE usar la siguiente secuencia de escritura para el EF.Biometrics:)

• El primer comando UPDATE BINARY (INS impar) DEBE contener los siguientes DO en el campo de datos:

(El primer comando UPDATE BINARY (INS impar) DEBE incluir los siguientes DO en el campo de datos:)

– El DO’54’, que contiene el ‘00’ desplazado;

– El DO’53’, que PUEDE contener el primer bloque de los datos que han de almacenarse. Este DO PUEDE estar vacío (‘53 00’); y

– El DO’C0’ propio, que indica el tamaño total del EF (tamaño de memoria para asignar), es opcional.

Nota 1.— La LDS2 del eMRTD PUEDE usar información del tamaño del EF en DO’C0’ para la asignación de la memoria interna (p. ej., para la asignación de memoria dinámica explícita). Si la LDS2 del eMRTD no admite el DO de información del tamaño del EF (p. ej., el expedidor ha asignado la memoria estáticamente, o la LDS2 del eMRTD admite una reasignación de memoria dinámica implícita del EF), entonces la LDS2 del eMRTD PUEDE no tener en cuenta el DO’C0’, proceder con la lectura del primer bloque del EF y devolver ‘9000’, o PUEDE devolver el error ‘6A80’ en el caso de un parámetro incorrecto en el campo de datos del comando.

(Nota 1.— La LDS2 del eMRTD PUEDE usar información del tamaño del EF en DO’C0’ para la asignación de la memoria interna (p. ej., para la asignación de memoria dinámica expresa). Si la LDS2 del eMRTD no admite el DO de información del tamaño del EF (p. ej., el emisor ha asignado la memoria permanentemente, o la LDS2 del eMRTD admite una reasignación de memoria dinámica tácita del EF), entonces la LDS2 del eMRTD PUEDE no tener en cuenta el DO’C0’, proceder con la lectura del primer bloque del EF y responder ‘9000’, o PUEDE devolver el error ‘6A80’ en el caso de un criterio incorrecto en el campo de datos del comando.)

Nota 2.— Si la LDS2 del eMRTD devuelve un error en respuesta a UPDATE BINARY con el DO’C0’ propio, entonces el IS DEBE enviar el comando estándar UPDATE BINARY (INS impar) conforme a [ISO/IEC 7816-4], con DO’54’ y DO’53’ de desplazamiento cero, sin el DO’C0’.

• Los comandos UPDATE BINARY (INS impar, sin DO’C0’) subsiguientes DEBERÍAN usar el desplazamiento n+1, donde n indica el número de bytes escritos hasta el momento en EF.Biometrics, i. e. el terminal DEBERÍA escribir secuencialmente los datos del EF sin que falte ni se superponga nada entre los dos comandos UPDATE BINARY consecutivos.

(Los comandos UPDATE BINARY (INS impar, sin DO’C0’) subsiguientes DEBERÍAN usar el desplazamiento n+1, donde n indica el número de bytes escritos hasta el momento en EF.Biometrics, es decir, el terminal DEBERÍA escribir secuencialmente los datos del EF sin que falte ni se superponga nada entre los dos comandos UPDATE BINARY seguidos.)

• El comando READ BINARY PUEDE usarse después de cualquier comando UPDATE BINARY para verificar los datos escritos en el EF.

(El comando READ BINARY PUEDE usarse después de cualquier comando UPDATE BINARY para comprobar los datos escritos en el EF.)

• El comando ACTIVATE DEBE finalizar la personalización de EF.Biometrics desactivando permanentemente la escritura en el EF.

3.8.1 Comando UPDATE BINARY

Un CI sin contacto que admite la aplicación de los datos biométricos adicionales DEBE admitir el comando UPDATE BINARY con el byte INS impar ‘D7’ de acuerdo con la tabla 18.

El valor del objeto de datos de desplazamiento BER-TLV del campo de datos del comando especifica el desplazamiento; el valor del objeto de datos discrecional BER-TLV del campo de datos del comando especifica cuáles son los datos que han de escribirse; el valor del objeto de datos del tamaño del fichero BER-TLV opcional del campo de datos del comando especifica el tamaño total del EF. Los campos de longitud de estos objetos de datos BER-TLV deberían codificarse de la forma más corta posible.

(El valor del objeto de datos de desplazamiento BER-TLV del campo de datos del comando concreta el desplazamiento; el valor del objeto de datos discrecional BER-TLV del campo de datos del comando concreta cuáles son los datos que han de escribirse; el valor del objeto de datos del tamaño del fichero BER-TLV opcional del campo de datos del comando concreta el tamaño total del EF. Los campos de longitud de estos objetos de datos BER-TLV deberían codificarse de la forma más corta posible.)

Cuando el campo de datos del comando UPDATE BINARY tiene un DO’C0’ propio, el bit 8 del byte CLA del comando APDU DEBE ponerse en 1 (CLA = ‘8C’).

Tabla 18. Comando UPDATE BINARY con INS impar

Tabla 19. Respuesta UPDATE BINARY

Si el IS no sigue la secuencia UPDATE BINARY especificada en la sección 3.8 (i. e. el primer UPDATE BINARY no empieza en el desplazamiento 0), la LDS2 de la microplaqueta del eMRTD PUEDE terminar el comando UPDATE BINARY con un error.

(Si el IS no sigue la secuencia UPDATE BINARY descrita en la sección 3.8 (es decir, el primer UPDATE BINARY no empieza en el desplazamiento 0), la LDS2 de la microplaqueta del eMRTD PUEDE terminar el comando UPDATE BINARY con un error.)

3.8.2 Comando ACTIVATE

El comando ACTIVATE inicia la transición del EF de datos biométricos adicionales seleccionado del estado desactivado al estado activado.

Tabla 20. Comando ACTIVATE

Tabla 21. Respuesta ACTIVATE

Después de la ejecución correcta de este comando, el EF.Biometrics actualmente seleccionado DEBE cambiarse al estado activado. En caso de que se produzca un error (SW distinto de ‘9000’), el EF.Biometrics actualmente seleccionado DEBE permanecer en estado desactivado.

Inmediatamente después de la ejecución correcta de este comando (SW1-SW2 = ‘9000’), la autorización efectiva exigida para realizar una acción en el EF.Biometrics DEBE ser la correspondiente al estado activado (con arreglo a la tabla 98). La autorización efectiva correspondiente al estado desactivado NO DEBE suponer ningún derecho de acceso al EF.Biometrics.

(Inmediatamente después de la ejecución correcta de este comando (SW1-SW2 = ‘9000’), la autorización efectiva exigida para realizar una acción en el EF.Biometrics DEBE ser la correspondiente al estado activado (de acuerdo con la tabla 98). La autorización efectiva correspondiente al estado desactivado NO DEBE conllevar ningún derecho de acceso al EF.Biometrics.)

3.8.3 Comando FILE AND MEMORY MANAGEMENT

El comando FILE AND MEMORY MANAGEMENT (FMM) inicia una consulta del tamaño de la memoria utilizada o libre del EF direccionado. Este comando se proporciona para la LDS2 del eMRTD como propio. Puede usarse para comprobar el espacio libre disponible del EF direccionado antes de escribir o añadir algo. Asimismo, puede usarse para conseguir el último número de registro añadido para la lectura. P1 indica el método para el direccionamiento de los EF; puede usarse el EF actual o el DO’51’ de referencia del fichero. P2 indica el contenido de la consulta. Se proporcionan el número total de bytes en el EF direccionado con una estructura transparente o de registro y el número de registros existentes o restantes para el EF del registro direccionado. El número total de bytes comprende los bytes disponibles en el EF sin ninguna información estructural. Este número excluye toda información estructural que pueda requerir la LDS2 de la microplaqueta del eMRTD. Para los registros restantes se da por supuesto que su tamaño es el máximo. Después de que el comando FMM se ejecute correctamente, el EF de referencia se convierte en el EF actual.

(El comando FILE AND MEMORY MANAGEMENT (FMM) inicia una consulta del tamaño de la memoria utilizada o libre del EF direccionado. Este comando se suministra para la LDS2 del eMRTD como propio. Puede usarse para comprobar el espacio libre disponible del EF direccionado antes de escribir o añadir algo. Asimismo, puede usarse para conseguir el último número de registro añadido para la lectura. P1 indica el método para el direccionamiento de los EF; puede usarse el EF actual o el DO’51’ de referencia del fichero. P2 indica el contenido de la consulta. Se facilitan el número total de bytes en el EF direccionado con una estructura transparente o de registro y el número de registros existentes o restantes para el EF del registro direccionado. El número total de bytes incluye los bytes disponibles en el EF sin ninguna información estructural. Este número excluye toda información estructural que pueda requerir la LDS2 de la microplaqueta del eMRTD. Para los registros restantes se da por supuesto que su tamaño es el máximo. Después de que el comando FMM se ejecute correctamente, el EF de referencia se convierte en el EF actual.)

Tabla 22. Comando FILE AND MEMORY MANAGEMENT (FMM)

P1 especifica el método de selección del EF. P2 contiene un mapa de bits que especifica qué información DEBE incluirse en la respuesta.

(P1 concreta el método de selección del EF. P2 incluye un mapa de bits que describe qué información DEBE incluirse en la respuesta.)

Tabla 23. Codificación de P1 en el comando FFM

Tabla 24. Codificación de P2 en el comando FFM

Tabla 25. Codificación del DO’51’ en el campo de datos del comando FMM

La respuesta para el comando FMM contiene un conjunto de DO que representan la información solicitada sobre el fichero y el tamaño de la memoria.

(La respuesta para el comando FMM incluye un conjunto de DO que representan la información solicitada sobre el fichero y el tamaño de la memoria.)

Tabla 26. Respuesta para el comando FMM

Tabla 27. Gestión de ficheros y memoria

Nota 1.— La LDS2 de la microplaqueta del eMRTD DEBE devolver solo los objetos de datos del DO del FMM que se soliciten por medio del P2.

Nota 2.— Los datos de respuesta del FMM son válidos únicamente para el EF especificado. Los datos de respuesta del FMM de diferentes EF pueden no ser independientes, p. ej., si diferentes EF comparten la memoria disponible. El IS debería tener esto en cuenta si combina datos de respuesta del FMM de diferentes EF.

(Nota 2.— Los datos de respuesta del FMM son válidos únicamente para el EF concretado. Los datos de respuesta del FMM de diferentes EF pueden no ser independientes, p. ej., si diferentes EF comparten la memoria disponible. El IS (Inspection System = Sistema de inspección) debería tener esto en cuenta si une datos de respuesta del FMM de diferentes EF.)

Nota 3.— Cuando se aplica la mensajería segura al comando FMM, DEBE usarse el DO’85’ de mensajería segura para encapsular los datos del comando cifrado.

(Nota 3.— Cuando se aplica la mensajería segura al comando FMM, DEBE usarse el DO’85’ de mensajería segura para separar los datos del comando cifrado.)

3.9 Especificaciones sobre estructuras de ficheros

La información en la LDS2 de un eMRTD se almacena en un sistema de ficheros definido en [ISO/IEC 7816-4]. El sistema de ficheros se organiza en forma jerárquica en ficheros especializados (DF) y ficheros elementales (EF). Los DF contienen EF u otros ficheros especializados. Un fichero maestro (MF) opcional puede estar en el origen del sistema de ficheros.

(La información en la LDS2 de un eMRTD se almacena en un sistema de ficheros definido en [ISO/IEC 7816-4]. El sistema de ficheros se organiza en forma jerárquica en ficheros especializados (DF = Dedicated File = Fichero especializado) y ficheros elementales (EF = Elementary File= Fichero elemental). Los DF incluyen EF u otros ficheros especializados. Un fichero maestro (MF = Master File = Fichero maestro) opcional puede estar en el origen del sistema de ficheros.)

Nota.— La necesidad de contar con un fichero maestro se determina por la elección de sistemas de operación, aplicaciones de la LDS1 o LDS2, y condiciones de acceso opcionales.

(Nota.— La necesidad de contar con un fichero maestro se determina por la elección de sistemas de operación, aplicaciones de la LDS1 o LDS2, y requisitos de acceso opcionales.)

3.9.1 Codificación de datos

Para los elementos de datos se permiten los tipos de codificación siguientes:

(Para los elementos de datos se admiten los tipos de codificación siguientes:)

A = Carácter alfabético [a-z, A-Z];

N = Carácter numérico [0-9];

S = Carácter especial [‘<’];

B = Datos binarios;

U = Caracteres UNICODE codificados en UTF-8.

Codificación en UTF-8 de los caracteres UNICODE:

• Para todo carácter igual o inferior a 127 (hex ‘7F’), la codificación en UTF-8 usa un byte que es el mismo que el valor ASCII;

• Para todo carácter igual o inferior a 2 047 (hex ‘07FF’), la codificación en UTF-8 usa dos bytes;

– el primer byte tiene dos bits de mayor peso fijados y el tercer bit despejado (i. e. hex ‘C2’ a ‘DF’);

(el primer byte tiene dos bits de mayor peso fijados y el tercer bit despejado (es decir, hex ‘C2’ a ‘DF’);)

– el segundo byte tiene el bit de mayor peso fijado y el segundo bit despejado (i. e. ‘80’ a ‘BF’);

(el segundo byte tiene el bit de mayor peso fijado y el segundo bit despejado (es decir, ‘80’ a ‘BF’);)

• Para todos los caracteres iguales o superiores a 2 048 y menores de 65 535 (hex ‘FFFF’), la codificación en UTF-8 usa tres bytes.

3.10 Selección de aplicación — DF

Los eMRTD APOYARÁN por lo menos una aplicación, como sigue:

(Los eMRTD ADMITIRÁN por lo menos una aplicación, como sigue:)

• La aplicación de la LDS1 para el eMRTD es OBLIGATORIA;

– la aplicación de la LDS1 para el eMRTD CONSISTIRÁ en los datos registrados por el Estado expedidor u organización expedidora, grupos de datos 1 a 16 conjuntamente con el objeto de seguridad de documento (EF.SOD);

(la aplicación de la LDS1 para el eMRTD CONSISTIRÁ en los datos registrados por el Estado emisor u organización emisora, grupos de datos 1 a 16 junto con el objeto de seguridad de documento (EF.SOD);)

– el objeto de seguridad de documento (EF.SOD) que se halla dentro de la aplicación de la LDS1 para el eMRTD consiste en las condensaciones que se definen en el Doc 9303-11 y en el Doc 9303-12 para los grupos de datos que se utilicen y se necesiten para validar la integridad de los datos creados por el expedidor y almacenados en la aplicación de la LDS1 para el eMRTD.

(el objeto de seguridad de documento (EF.SOD) que se halla dentro de la aplicación de la LDS1 para el eMRTD consiste en las condensaciones (hash) que se definen en el Doc 9303-11 y en el Doc 9303-12 para los grupos de datos que se utilicen y se necesiten para confirmar la invariabilidad de los datos creados por el emisor y almacenados en la aplicación de la LDS1 para el eMRTD.)

• La aplicación de la LDS1 del eMRTD PUEDE, opcionalmente, admitir las aplicaciones de la LDS2 adicionales descritas en el Doc 9303 como:

– aplicación de los registros de viaje;

La sección 5.1 de la Parte 10 del documento 9303 recoge:

5.1 Aplicación de registros de viaje (CONDICIONAL)

La aplicación de registros de viaje PUEDE ser implementada por un Estado expedidor o una organización expedidora. Si se ha invocado la aplicación de los registros de viaje opcional, SE EXIGE de forma condicional lo siguiente.

(La aplicación de registros de viaje PUEDE ser instalada por un Estado emisor o una organización emisora. Si se ha invocado la aplicación de los registros de viaje opcional, SE EXIGE de forma condicional lo siguiente.)

Figura 4. Estructura de los registros de viaje

Los registros de los viajes de entrada y salida se almacenan en dos ficheros elementales separados, EF.EntryRecords y EF.ExitRecords, en el DF para la aplicación de los registros de viaje, teniendo ambos una estructura lineal con registros de tamaño variable, con arreglo a [ISO/IEC 7816-4]. Los certificados de firmante del registro de viaje se almacenan en un fichero elemental separado EF.Certificates, que tiene una estructura lineal con registros de tamaño variable.

(Los registros de los viajes de entrada y salida se almacenan en dos ficheros elementales separados, EF.EntryRecords y EF.ExitRecords, en el DF para la aplicación de los registros de viaje, teniendo ambos una estructura lineal con registros de tamaño variable, de acuerdo con [ISO/IEC 7816-4]. Los certificados de firmante del registro de viaje se almacenan en un fichero elemental separado EF.Certificates, que tiene una estructura lineal con registros de tamaño variable.)

5.1.1 Selección de aplicación — DF

La aplicación de registros de viaje DEBE seleccionarse utilizando el identificador de la aplicación (AID) como nombre DF reservado. El AID DEBE constar del identificador de la aplicación registrado asignado por la ISO con arreglo a [ISO/IEC 7816-5], seguido por la extensión de identificador de aplicación de propiedad (PIX) de la aplicación de los registros de viaje:

(La aplicación de registros de viaje DEBE seleccionarse utilizando el identificador de la aplicación (AID) como nombre DF reservado. El AID DEBE incluir el identificador de la aplicación registrado asignado por la ISO de acuerdo con [ISO/IEC 7816-5], seguido por la extensión de identificador de aplicación de propiedad (PIX = Proprietary Identifier Extension = Extensión del identificador registrado/de propiedad) de la aplicación de los registros de viaje:)

• el identificador de la aplicación registrado es ‘A0 00 00 02 47’;

• la aplicación de los registros de viaje DEBE usar PIX = ‘20 01’; y

• el AID completo de la aplicación de los registros de viaje DEBE ser ‘A0 00 00 02 47 20 01’.

El CI DEBE rechazar la selección de esta aplicación si la autorización efectiva no garantiza derechos de acceso a ningún dato de una aplicación de la LDS2.

5.1.2 EF.Certificates (OBLIGATORIO)

Los certificados de firmante del registro de viaje se almacenan en un EF dentro del DF de la aplicación y tienen una estructura lineal con registros de tamaño variable. Está previsto que el IS utilice estos certificados para realizar una nueva validación fuera de línea de las firmas digitales para cada registro tanto en el fichero EF.ExitRecords como

en el EF.EntryRecords files.

(Los certificados de firmante del registro de viaje se almacenan en un EF (Elementary File = Fichero elemental) dentro del DF (Dedicated File = Fichero especializado) de la aplicación y tienen una estructura lineal con registros de tamaño variable. Está establecido que el IS (Inspection System = Sistema de inspección) utilice estos certificados para realizar una nueva comprobación fuera de línea de las firmas digitales para cada registro tanto en el fichero EF.ExitRecords como en el EF.EntryRecords files.)

Tabla 82. EF.Certificates

El registro del certificado contiene un solo objeto de datos del certificado X.509 del firmante de la LDS2-V. Un registro de certificado PUEDE constar como referencia en uno o más registros de viaje de entrada o salida.

(El registro del certificado incluye un solo objeto de datos del certificado X.509 del firmante de la LDS2-V. Un registro de certificado PUEDE constar como referencia en uno o más registros de viaje de entrada o salida.)

Tabla 83. Formato del registro EF.Certificates

Nota.— Los rótulos interindustriales especificados en esta tabla se usan en el contexto de la LDS, así que no es necesario un sistema de asignación de rótulos coexistentes.

El DO’5F3A’ DEBE contener un código de país de dos letras, conforme al Doc 9303, Parte 3 (misma codificación y valor que el countryName (nombre del país) que expide el X.509 en el certificado del sujeto, seguido por el número de serie del certificado.

(El DO’5F3A’ DEBE incluir un código de país de dos letras, conforme al Doc 9303, Parte 3 (misma codificación y valor que el countryName (nombre del país) que emite el X.509 en el certificado del sujeto, seguido por el número de serie del certificado.)

Cada certificado X.509 contiene un conjunto de elementos de datos codificados en ASN.1 ilustrados en la tabla 84. En la especificación de perfiles de certificado del Doc 9303-12 pueden encontrarse los requisitos detallados para el certificado X.509.

(Cada certificado X.509 incluye un conjunto de elementos de datos codificados en ASN.1 ilustrados en la tabla 84. En la descripción de perfiles de certificado del Doc 9303-12 pueden encontrarse los requisitos detallados para el certificado X.509.)

Tabla 84. Ejemplo de estructura del certificado X.509

Nota.— Esta tabla es un ejemplo que se presenta solo a título ilustrativo. Los registros de certificado se escriben en EF.Certificates, ubicado en el DF de la aplicación de los registros de viaje, usando el comando APPEND RECORD. Los registros de certificado pueden leerse de EF.Certificates utilizando el comando READ RECORD. Los registros de certificado NO DEBEN actualizarse ni borrarse. El número máximo de registros en EF.Certificates en el DF de la aplicación de los registros de viaje DEBE ser de 254.

(Nota.— Esta tabla es un ejemplo que se presenta solo a título ilustrativo. Los registros de certificado se escriben en EF.Certificates, situado en el DF de la aplicación de los registros de viaje, usando el comando APPEND RECORD. Los registros de certificado pueden leerse de EF.Certificates utilizando el comando READ RECORD. Los registros de certificado NO DEBEN actualizarse ni borrarse. El número máximo de registros en EF.Certificates en el DF de la aplicación de los registros de viaje DEBE ser de 254.)

5.1.3 EF.ExitRecords (OBLIGATORIO)

Los registros de salida DEBEN ser añadidos por un IS autorizado en el momento del embarque.

Tabla 85. EF.ExitRecords

En la tabla 86 se muestra el contenido de un registro de salida.

Nota.— Los rótulos interindustriales especificados en la tabla siguiente se usan en el contexto de la LDS, así que no es necesario un sistema de asignación de rótulos coexistentes:

(Nota.— Los rótulos interindustriales descritos en la tabla siguiente se usan en el ámbito de la LDS, así que no es necesario un sistema de asignación de rótulos coexistentes:)

Tabla 86. Formato de registro de entrada/salida

Nota 1.— A = carácter alfabético [a-z, A-Z], N = carácter numérico [0-9], S = carácter especial [‘<’], B= datos binarios, F = campo de longitud fija, Var = campo de longitud variable.

Nota 2.— Dado que es probable que los certificados de firmante de la LDS2-TS sean los mismos que en múltiples registros de viaje (p. ej., cuando se entra y sale de un país por el mismo aeropuerto con un solo firmante LDS2-TS), antes de escribir/añadir un nuevo certificado a EF.Certificates, el IS debería buscar en EF.Certificates una copia del mismo certificado y referenciar el existente. Esto reducirá el tamaño de EF.Certificates y hará posible que se hagan búsquedas más rápidas.

Nota 3.— La LDS2 del eMRTD no impone que un IS escriba los Entry Records solo en los EF.EntryRecords y no en los EF.ExitRecords, y viceversa.

Nota 4.— Código de tres letras del estado de embarque/desembarque con arreglo al Doc 9303-3.

(Nota 4.— Código de tres letras del estado de embarque/desembarque de acuerdo con el Doc 9303-3.)

El orden de los objetos de datos de un registro es fijo. El IS DEBE establecer el contenido del registro utilizando los objetos de datos en el orden especificado en la tabla.

Cada registro DEBE contener una firma digital (testigo de autenticación) calculada sobre el DO’73’, incluidos el rótulo 73 y la longitud. La firma es generada por el firmante de la LDS2-TS.

(Cada registro DEBE incluir una firma digital (testigo de autenticación) calculada sobre el DO’73’, incluidos el rótulo 73 y la longitud. La firma es creada por el firmante de la LDS2-TS.)

Los certificados de firmante de la LDS2-TS exigidos para verificar la firma del registro de viaje DEBEN almacenarse en EF.Certificates en el DF de la aplicación de los registros de viaje si todavía no está disponible en el mismo fichero.

(Los certificados de firmante de la LDS2-TS exigidos para comprobar la firma del registro de viaje DEBEN almacenarse en EF.Certificates en el DF de la aplicación de los registros de viaje si todavía no está disponible en el mismo fichero.)

Los registros de viaje se escriben (añaden) en el EF utilizando APPEND RECORD. Estos registros NO DEBEN alterarse (actualizarse) ni borrarse. El número máximo de registros permitidos en cada EF DEBE ser de 254.

(Los registros de viaje se escriben (añaden) en el EF utilizando APPEND RECORD. Estos registros NO DEBEN alterarse (actualizarse) ni borrarse. El número máximo de registros admitidos en cada EF DEBE ser de 254.)

5.1.4 EF.EntryRecords (OBLIGATORIO)

Los registros de entrada DEBEN ser añadidos por un IS autorizado en el momento del desembarque.

Tabla 87. EF.EntryRecords

La estructura del registro de entrada es idéntica a la estructura del registro de salida que se especifica en la tabla 86.

(sigue la sección 3 de la Parte 10 del documento 9303)

– aplicación de los registros de visados; y

En la sección 5.2 de la Parte 10 del documento 9303 se recoge:

5.2 Aplicación de los registros de visados (CONDICIONAL)

La aplicación de los registros de visados PUEDE ser implementada por un Estado expedidor o una organización expedidora. Si se ha invocado la aplicación de registros de visados opcional, SE EXIGE de forma condicional lo siguiente:

(La aplicación de los registros de visados PUEDE ser instalada por un Estado emisor o una organización emisora. Si se ha invocado la aplicación de registros de visados opcional, SE EXIGE de forma condicional lo siguiente:)

Figura 5. Estructura de los registros de visados

Los registros de visados se almacenan en el fichero elemental EF.VisaRecords en el DF de la aplicación de los registros de visados. El EF TENDRÁ una estructura lineal con registros de tamaño variable con arreglo a [ISO/IEC 7816-4]. Los certificados de firmante del registro de visados se almacenan en un fichero elemental separado EF.Certificates, que tiene una estructura lineal con registros de tamaño variable.

(Los registros de visados se almacenan en el fichero elemental EF.VisaRecords en el DF de la aplicación de los registros de visados. El EF TENDRÁ una estructura lineal con registros de tamaño variable de acuerdo con [ISO/IEC 7816-4]. Los certificados de firmante del registro de visados se almacenan en un fichero elemental separado EF.Certificates, que tiene una estructura lineal con registros de tamaño varaible.)

5.2.1 Selección de aplicación — DF

La aplicación de registros de visados DEBE seleccionarse utilizando el identificador de la aplicación (AID) como nombre DF reservado. El AID DEBE constar del identificador de la aplicación registrado asignado por la ISO con arreglo a [ISO/IEC 7816-5], seguido por la extensión de identificador de aplicación de propiedad (PIX) de la aplicación de registros de visados:

• el identificador de la aplicación registrado es ‘A0 00 00 02 47’;

• la aplicación de registros de visados DEBE usar PIX = ‘20 02’; y

• el AID completo de la aplicación de registros de visados DEBE ser ‘A0 00 00 02 47 20 02’.

El IC DEBE rechazar la selección de esta aplicación si la autorización efectiva no garantiza derechos de acceso a ningún dato de una aplicación de la LDS2.

5.2.2 EF.Certificates (OBLIGATORIO)

Los certificados de firmante del registro de visado se almacenan en EF.Certificates dentro del DF de la aplicación y tienen una estructura lineal con registros de tamaño variable. Está previsto que el IS utilice estos certificados para realizar una nueva validación fuera de línea de la firma digital para cada registro del EF.VisaRecords.

(Los certificados de firmante del registro de visado se almacenan en EF.Certificates dentro del DF de la aplicación y tienen una estructura lineal con registros de tamaño variable. Está establecido que el IS utilice estos certificados para realizar una nueva comprobación fuera de línea de la firma digital para cada registro del EF.VisaRecords.)

Tabla 88. EF.Certificates

El registro de certificado contiene un solo objeto de datos del certificado X.509 del firmante de la LDS2-TS. Un registro de certificado PUEDE constar como referencia en uno o más registros de visados.

(El registro de certificado incluye un solo objeto de datos del certificado X.509 del firmante de la LDS2-TS. Un registro de certificado PUEDE constar como referencia en uno o más registros de visados.)

La estructura del registro de certificado en la aplicación del visado es idéntica a la estructura del registro de certificado de la aplicación del registro de viaje que se especifica en la tabla 83.

Los registros de certificado se escriben en EF.Certificates, ubicado en el DF de la aplicación de registros de visados, usando el comando APPEND RECORD. Los registros de certificado pueden leerse de EF.Certificates utilizando el comando READ RECORD. Los registros de certificado NO DEBEN actualizarse ni borrarse. El número máximo de registros en EF.Certificates en el DF de la aplicación de registros de visados DEBE ser de 254.

(Los registros de certificado se escriben en EF.Certificates, situado en el DF de la aplicación de registros de visados, usando el comando APPEND RECORD. Los registros de certificado pueden leerse de EF.Certificates utilizando el comando READ RECORD. Los registros de certificado NO DEBEN actualizarse ni borrarse. El número máximo de registros en EF.Certificates en el DF de la aplicación de registros de visados DEBE ser de 254.)

5.2.3 EF.VisaRecords (OBLIGATORIO)

Los registros de visados DEBEN almacenarse en EF.VisaRecords, con una estructura lineal y registros de tamaño variable.

Tabla 89. EF.VisaRecords

Cada registro de visado DEBE contener una secuencia de objetos de datos BER-TLV (DO ‘5F28’ y DO’71’), seguida del DO testigo de autenticación (firma) y de un DO que contenga la referencia al certificado de firmante de la LDS2-V en EF.Certificates. DO’71’ contiene un conjunto de DO (campos), que se enumeran en la tabla que figura a continuación.

(Cada registro de visado DEBE incluir una secuencia de objetos de datos BER-TLV (DO ‘5F28’ y DO’71’), seguida del DO testigo de autenticación (firma) y de un DO que incluya la referencia al certificado de firmante de la LDS2-V en EF.Certificates. DO’71’ incluye un conjunto de DO (campos), que se enumeran en la tabla que figura a continuación.)

Nota.— Los rótulos interindustriales especificados en la tabla siguiente se usan en el contexto de la LDS, por lo que no es necesario un sistema de asignación de rótulos coexistentes.

(Nota.— Los rótulos interindustriales descritos en la tabla siguiente se usan en el contexto de la LDS, por lo que no es necesario un sistema de asignación de rótulos coexistentes.)

Tabla 90. Formato EF.VisaRecords

Nota 1.— A = carácter alfabético [a-z, A-Z], N = carácter numérico [0-9], S = carácter especial [‘<’], B= datos binarios, F = campo de longitud fija, Var = campo de longitud variable, Sp = espacio.

Nota 2.— Código de tres letras del Estado expedidor con arreglo al Doc 9303-3.

(Nota 2.— Código de tres letras del Estado emisor de acuerdo con el Doc 9303-3.)

Nota 3.— Si el DO’5F40’ opcional está presente, DEBE contener el identificador de dos bytes del EF dentro de la aplicación de datos biométricos adicionales que contiene los datos biométricos. Este DO solo puede usarse si la aplicación de los datos biométricos adicionales está presente en el eMRTD.

(Nota 3.— Si el DO’5F40’ opcional está presente, DEBE incluir el identificador de dos bytes del EF dentro de la aplicación de datos biométricos adicionales que incluye los datos biométricos. Este DO solo puede usarse si la aplicación de los datos biométricos adicionales está presente en el eMRTD.)

El orden de los objetos de datos de un registro es fijo. El IS DEBE establecer el contenido del registro utilizando los objetos de datos en el orden especificado en la tabla.

Cada registro de visado DEBE contener una firma digital (testigo de autenticación) calculada sobre el DO’71’, incluidos el rótulo 71 y la longitud. La firma es generada por el firmante LDS2-V.

(Cada registro de visado DEBE incluir una firma digital (testigo de autenticación) calculada sobre el DO’71’, incluidos el rótulo 71 y la longitud. La firma es creada por el firmante LDS2-V.)

Los certificados de firmante de la LDS2-V exigidos para verificar la firma del registro de visado se almacenan en un almacén de EF.Certificates separado ubicado en el DF de la aplicación de registros de visados.

(Los certificados de firmante de la LDS2-V exigidos para comprobar la firma del registro de visado se almacenan en un almacén de EF.Certificates separado situado en el DF de la aplicación de registros de visados.)

Cada registro de visado DEBE añadirse al EF.VisaRecords utilizando APPEND RECORD. Estos registros de visados NO DEBEN alterarse (actualizarse) ni borrarse. El número máximo de registros permitidos en EF.VisaRecords DEBE ser de 254.

(Cada registro de visado DEBE añadirse al EF.VisaRecords utilizando APPEND RECORD. Estos registros de visados NO DEBEN alterarse (actualizarse) ni borrarse. El número máximo de registros admitidos en EF.VisaRecords DEBE ser de 254.)

(sigue la sección 3 de la Parte 10 del documento 9303)

– aplicación de los datos biométricos adicionales.

La sección 5.3 de la Parte 10 del documento 9303 de la OACI recoge:

5.3 Aplicación de los datos biométricos adicionales (CONDICIONAL)

La aplicación de los datos biométricos adicionales PUEDE ser implementada por un Estado expedidor o una organización expedidora. Si se ha invocado la aplicación de los datos biométricos adicionales opcional, o se ha referenciado en algún de registro de visado, SE EXIGE de forma condicional lo siguiente.

(La aplicación de los datos biométricos adicionales PUEDE ser instalada por un Estado emisor o una organización emisora. Si se ha invocado la aplicación de los datos biométricos adicionales opcional, o se ha referenciado en algún de registro de visado, SE EXIGE de forma condicional lo siguiente.)

Figura 6. Estructura de la aplicación de los datos biométricos adicionales

5.3.1 Selección de aplicación — DF

La aplicación de los datos biométricos adicionales DEBE seleccionarse utilizando el identificador de la aplicación (AID) como nombre DF reservado. El AID DEBE constar del identificador de la aplicación registrado asignado por la ISO con arreglo a [ISO/IEC 7816-5], seguido por la extensión del identificador de aplicación de propiedad (PIX) de la aplicación de los datos biométricos adicionales:

• el identificador de la aplicación registrado es ‘A0 00 00 02 47’;

• la aplicación de los datos biométricos adicionales DEBE usar PIX = ‘20 03’; y

• el AID completo de la aplicación de los datos biométricos adicionales DEBE ser ‘A0 00 00 02 47 20 03’.

El CI DEBE rechazar la selección de esta aplicación si la autorización efectiva no garantiza derechos de acceso a ningún dato de una aplicación de la LDS2.

5.3.2 EF.Certificates (OBLIGATORIO)

Los certificados de firmante de los datos biométricos adicionales se almacenan en EF.Certificates dentro del DF de la aplicación y tienen una estructura lineal con registros de tamaño variable. Está previsto que el IS utilice estos certificados para realizar una nueva validación fuera de línea de la firma digital en el EF.Biometrics.

(Los certificados de firmante de los datos biométricos adicionales se almacenan en EF.Certificates dentro del DF de la aplicación y tienen una estructura lineal con registros de tamaño variable. Está establecido que el IS utilice estos certificados para realizar una nueva comprobación fuera de línea de la firma digital en el EF.Biometrics.)

Tabla 91. EF.Certificates

El registro de certificado contiene un solo objeto de datos del certificado X.509 del firmante de los datos biométricos adicionales. Un registro de certificado PUEDE constar como referencia en uno o más EF de datos biométricos adicionales.

(El registro de certificado incluye un solo objeto de datos del certificado X.509 del firmante de los datos biométricos adicionales. Un registro de certificado PUEDE constar como referencia en uno o más EF de datos biométricos adicionales.)

La estructura del registro de certificado en la aplicación de los datos biométricos adicionales es idéntica a la estructura del registro de certificado de la aplicación de los registros de viaje que se especifica en la tabla 83.

Los registros de certificado se escriben en EF.Certificates, ubicado en el DF de la aplicación de datos biométricos adicionales, usando el comando APPEND RECORD. Los registros de certificado pueden leerse de EF.Certificates utilizando el comando READ RECORD. Los registros de certificado NO DEBEN actualizarse ni borrarse. El número máximo de registros en EF.Certificates en el DF de la aplicación de las datos biométricos adicionales DEBE ser de 64.

(Los registros de certificado se escriben en EF.Certificates, situado en el DF de la aplicación de datos biométricos adicionales, usando el comando APPEND RECORD. Los registros de certificado pueden leerse de EF.Certificates utilizando el comando READ RECORD. Los registros de certificado NO DEBEN actualizarse ni borrarse. El número máximo de registros en EF.Certificates en el DF de la aplicación de las datos biométricos adicionales DEBE ser de 64.)

5.3.3 EF.Biometrics

Los datos biométricos adicionales DEBEN almacenarse en EF de la aplicación de datos biométricos adicionales y tener una estructura transparente conforme a [ISO/IEC 7816-4].

Cada EF de datos biométricos PUEDE vincularse a uno o más registros de EF.VisaRecords en la aplicación de registros de visados (u otros EF y aplicaciones) por medio del identificador EF de datos biométricos adicionales.

(Cada EF de datos biométricos PUEDE enlazarse a uno o más registros de EF.VisaRecords en la aplicación de registros de visados (u otros EF y aplicaciones) por medio del identificador EF de datos biométricos adicionales.)

Tabla 92. EF.Biometrics1 a EF.Biometrics64

Cada EF de datos biométricos adicionales DEBE contener un objeto de datos DO’7F2E’ en BER-TLV que encapsule tres objetos de datos: el objeto de datos biométricos DO’5F2E’, seguido de los DO’5F37’ y DO’5F38’ de testigo de autenticación (firma) que contienen la referencia a un certificado de firmante de los datos biométricos adicionales en EF.Certificates, como se muestra en la tabla que figura a continuación.

(Cada EF de datos biométricos adicionales DEBE incluir un objeto de datos DO’7F2E’ en BER-TLV que separe tres objetos de datos: el objeto de datos biométricos DO’5F2E’, seguido de los DO’5F37’ y DO’5F38’ de testigo de autenticación (firma) que incluyen la referencia a un certificado de firmante de los datos biométricos adicionales en EF.Certificates, como se muestra en la tabla que figura a continuación.)

El contenido del DO’5F2E’ depende del expedidor de los datos biométricos adicionales y queda fuera del alcance de esta especificación.

(El contenido del DO’5F2E’ depende del emisor de los datos biométricos adicionales y queda fuera del alcance de esta determinación.)

El mecanismo de creación del EF de datos biométricos adicionales queda fuera del alcance de esta especificación.

El expedidor DEBERÍA crear previamente varios EF de datos biométricos adicionales.

Nota.— Los rótulos interindustriales especificados en la tabla que figura a continuación se usan en el contexto de la LDS, por lo que no es necesario un sistema de asignación de rótulos coexistentes.

(Nota.— Los rótulos interindustriales descritos en la tabla que figura a continuación se usan en el contexto de la LDS, por lo que no es necesario un sistema de asignación de rótulos coexistentes.)

Tabla 93. Formato EF.Biometrics

Nota.— B = datos binarios, F = campo de longitud fija, V = campo de longitud variable

El orden de los objetos de datos de un EF es fijo.

Cada EF de datos biométricos adicionales DEBE contener una firma digital (testigo de autenticación) calculada sobre el DO’5F2E’, incluidos el rótulo y la longitud. La firma la genera el firmante de los datos biométricos adicionales.

(Cada EF de datos biométricos adicionales DEBE incluir una firma digital (testigo de autenticación) calculada sobre el DO’5F2E’, incluidos el rótulo y la longitud. La firma la crea el firmante de los datos biométricos adicionales.)

El certificado del firmante de las datos biométricos adicionales necesario para verificar la firma de las datos biométricos adicionales se almacena en un almacén de EF.Certificates separado ubicado en el DF de la aplicación de las datos biométricos adicionales.

(El certificado del firmante de las datos biométricos adicionales necesario para comprobar la firma de las datos biométricos adicionales se almacena en un almacén de EF.Certificates separado situado en el DF de la aplicación de las datos biométricos adicionales.)

Cada EF de datos biométricos adicionales DEBE escribirse utilizando el comando UPDATE BINARY.

El EF de datos biométricos adicionales NO DEBE alterarse (actualizarse) ni borrarse. El número máximo de EF de datos biométricos adicionales es de 64.

En la tabla 94 figuran todos los posibles nombres de EF de datos biométricos adicionales, identificadores EF e identificadores EF breves.

Tabla 94. Identificadores EF.Biometrics

(sigue la sección 3 de la Parte 10 del documento 9303)

Además, los Estados u organizaciones expedidores pueden añadir otras aplicaciones. La estructura de fichero HARÁ lugar a tales aplicaciones adicionales, pero los detalles concretos de las mismas caen fuera del alcance del Doc 9303.

Las aplicaciones de la LDS1 y LDS2 SE SELECCIONARÁN utilizando la identificación de aplicación (AID) como nombre DF reservado. La AID CONSISTIRÁ en el identificador de aplicación registrado asignado por la ISO con arreglo a [ISO/IEC 7816-5] y una extensión de identificador de aplicación de propiedad (PIX) según se especifica en este documento:

En el contexto de la aplicación de la LDS1 para el eMRTD se usan dos sistemas diferentes de asignación de rótulos para el rótulo de la clase de aplicación, según se define en el Doc 9303-10 (rótulo para LDS) y [ISO/IEC 7816-6] (rótulo interindustrial):

(En el ámbito de la aplicación de la LDS1 para el eMRTD se usan dos sistemas diferentes de asignación de rótulos para el rótulo de la clase de aplicación, como se define en el Doc 9303-10 (rótulo para LDS) y [ISO/IEC 7816-6] (rótulo interindustrial):)

• EF.ATR/INFO y EF.DIR usan el sistema de asignación de rótulos interindustriales;

• Los DF y sus EF usan el sistema de asignación de rótulos para LDS.

Los rótulos interindustriales especificados en este documento se usan en el contexto de la LDS, por lo que no es necesario un sistema de asignación de rótulos coexistentes.

(Los rótulos interindustriales descritos en este documento se usan en el contexto de la LDS, por lo que no es necesario un sistema de asignación de rótulos coexistentes.)

3.11 Ficheros elementales comunes (EF)

En el MF PUEDEN existir los siguientes EF comunes para las aplicaciones de la LDS1 y LDS2:

(En el MF (Master File = Fichero maestro) PUEDEN existir los siguientes EF (Elementary File =Fichero elemental) comunes para las aplicaciones de la LDS1 y LDS2:)

• EF.ATR/INFO;

• EF.DIR;

• EF.CardAccess; y

• EF.CardSecurity.

3.11.1 EF.ATR/INFO (CONDICIONAL)

EF.ATR/INFO es un EF transparente contenido en el fichero maestro y SE EXIGE en forma condicional si la aplicación de la LDS2 opcional está presente. Este EF es opcional si solo está presente la aplicación de la LDS1. El identificador EF breve al nivel del MF es ‘01’.

Tabla 28. EF.ATR/INFO

El contenido del EF.ATR/INFO puede recuperarse utilizando el comando SELECT seguido por el comando READ BINARY. El campo de datos de respuesta para el comando READ BINARY abarca el contenido del EF.ATR/INFO.

(El contenido del EF.ATR/INFO puede recuperarse utilizando el comando SELECT seguido por el comando READ BINARY. El campo de datos de respuesta para el comando READ BINARY incluye el contenido del EF.ATR/INFO.)

Tabla 29. Elementos de datos del EF.ATR/INFO para la LDS2

Nota 1.— Otros objetos de datos PUEDEN estar presentes en EF.ATR/INFO.

Nota 2.— EF.ATR/INFO usa el sistema de asignación de rótulos interindustriales definido en [ISO/IEC 7816-4].

3.11.2 EF.DIR (CONDICIONAL)

EF.DIR es un EF transparente contenido en el fichero maestro definido en [ISO/IEC 7816-4]. EF.DIR SE EXIGE en forma condicional si están presentes algunas aplicaciones de la LDS2 opcionales. Si están presentes algunas aplicaciones de la LDS2 opcionales, DEBE incluirse EF.DIR MUST en SecurityInfos presentes en EF.CardSecurity. Puede encontrarse una descripción completa de SecurityInfo para EF.DIR en el Doc 9303-11. El identificador EF breve en el MF es ‘1E’.

(EF.DIR es un EF transparente incluido en el fichero maestro definido en [ISO/IEC 7816-4]. EF.DIR SE EXIGE en forma condicional si están presentes algunas aplicaciones de la LDS2 opcionales. Si están presentes algunas aplicaciones de la LDS2 opcionales, DEBE incluirse EF.DIR MUST en SecurityInfos presentes en EF.CardSecurity. Puede encontrarse una descripción completa de SecurityInfo para EF.DIR en el Doc 9303-11.

El identificador EF breve en el MF es ‘1E’.)

Tabla 30. EF.DIR

SE RECOMIENDA que EF.DIR esté presente en el MF. EF.DIR DEBE estar presente si están presentes otras aplicaciones además de la aplicación de la LDS1 obligatoria e indicar las aplicaciones admitidas por el eMRTD. DEBE contener un conjunto de plantillas de aplicaciones que contengan un DO de identificador de aplicación en cualquier orden.

(SE RECOMIENDA que EF.DIR esté presente en el MF (Master File = Fichero maestro). EF.DIR DEBE estar presente si están presentes otras aplicaciones además de la aplicación de la LDS1 obligatoria e indicar las aplicaciones admitidas por el eMRTD. DEBE incluir un conjunto de plantillas de aplicaciones que incluyan un DO (Data Object = Objeto de datos) de identificador de aplicación en cualquier orden.)

Tabla 31. Formato EF.DIR

Nota.— EF.DIR usa el sistema de asignación de rótulos estándar definido en [ISO/IEC 7816-4].

3.11.3 EF.CardAccess (CONDICIONAL)

EF.CardAccess es un EF transparente contenido en el fichero maestro y SE EXIGE de forma condicional si se invoca el control de acceso PACE opcional definido en el Doc 9303-11. Puede encontrarse una descripción completa de SecurityInfo para el PACE en el Doc 9303-11.

El identificador EF breve en el MF es ‘1C.

Tabla 32. EF.CardAccess

El file CardAccess contenido en el fichero maestro SE EXIGE si la microplaqueta admite el PACE y CONTENDRÁ las siguientes SecurityInfos que se requieren para el PACE:

(El file CardAccess incluido en el fichero maestro SE EXIGE si la microplaqueta admite el PACE e INCLUIRÁ las siguientes SecurityInfos que se exigen para el PACE:)

• PACEInfo;

• PACEDomainParameterInfo

Tabla 33. Almacenamiento de EF.CardAccess en el IC

3.11.4 EF.CardSecurity (CONDICIONAL)

EF.CardSecurity es un EF transparente contenido en el fichero maestro y SE EXIGE de forma condicional si se invoca el PACE opcional con correspondencia de autenticación de microplaqueta según se define en el Doc 9303-11. Puede encontrarse una descripción completa de SecurityInfos para el PACE con correspondencia de autenticación de microplaqueta en el Doc 9303-11.

El identificador EF breve al nivel del MF es ‘1D’.

El EF.CardSecurity contenido en el MF SE EXIGE si:

(El EF.CardSecurity incluido en el MF SE EXIGE si:)

• el PACE con correspondencia de autenticación de microplaqueta es admitido por el IC;

• la autenticación del terminal en el MF es admitida por el IC; o

• la autenticación de la microplaqueta en el MF es admitida por el IC.

Y DEBE contener:

(Y DEBE incluir:)

• la ChipAuthenticationInfo requerida por la autenticación de la microplaqueta;

(la ChipAuthenticationInfo exigida por la autenticación de la microplaqueta;)

• la ChipAuthenticationPublicKeyInfo requerida por el PACE-CAM/autenticación de la microplaqueta;

(la ChipAuthenticationPublicKeyInfo exigida por el PACE (Password Authenticated Connection Establishment = Establecimiento de conexión autenticada por contraseña)-CAM (Chip Authentication Mapping = Correspondencia de autenticación de microplaqueta)/autenticación de la microplaqueta;)

• la TerminalAuthenticationInfo requerida por la autenticación del terminal;

(la TerminalAuthenticationInfo exigida por la autenticación del terminal;)

• las SecurityInfos contenidas en EF.CardAccess.

(las SecurityInfos incluidas en EF.CardAccess.)

El fichero EF.CardSecurity contenido en el fichero maestro SE EXIGE si el PACE con correspondencia de autenticación de microplaqueta es admitido por la microplaqueta del eMRTD y CONTENDRÁ las siguientes SecurityInfos:

(El fichero EF.CardSecurity incluido en el fichero maestro SE EXIGE si el PACE con correspondencia de autenticación de microplaqueta es admitido por la microplaqueta del eMRTD e INCLUIRÁ las siguientes SecurityInfos:)

• la ChipAuthenticationPublicKeyInfo requerida por el PACE-CAM;

(la ChipAuthenticationPublicKeyInfo exigida por el PACE-CAM;)

• las SecurityInfos contenidas en CardAccess.

(las SecurityInfos incluidas en CardAccess.)

Tabla 34. Almacenamiento de EF.CardSecurity en el IC

El archivo CardSecurity SE IMPLEMENTARÁ como SignedData con arreglo al [RFC 3369] con el tipo de contenido id- SecurityObject dentro del campo encapContentInfo. El firmante de documentos FIRMARÁ los objetos de seguridad. El certificado de firmante del documento DEBE incluirse en SignedData. El siguiente identificador de objetos SE UTILIZARÁ para identificar el tipo de contenido:

(El archivo CardSecurity SE INSTALARÁ como SignedData de acuerdo con el [RFC 3369] con el tipo de contenido id- SecurityObject dentro del campo encapContentInfo. El firmante de documentos FIRMARÁ los objetos de seguridad. El certificado de firmante del documento DEBE incluirse en SignedData. El siguiente identificador de objetos SE UTILIZARÁ para identificar el tipo de contenido:)

bsi-de OBJECT IDENTIFIER ::= {

itu-t(0) identified-organization(4) etsi(0)

reserved(127) etsi-identified-organization(0) 7

}

id-SecurityObject OBJECT IDENTIFIER ::= {

bsi-de applications(3) eID(2) 1

}

La estructura de datos SignedData se define de la siguiente manera:

SignedData ::= SEQUENCE{

version CMSVersion,

digestAlgorithms DigestAlgorithmIdentifiers,

encapContentInfo EncapsulatedContentInfo,

certificates [0] IMPLICIT CertificateSet OPTIONAL,

crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,

signerInfos SignerInfos

}

DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

EncapsulatedContentInfo ::= SEQUENCE {

eContentType ContentType,

eContent [0] EXPLICIT OCTET STRING OPTIONAL

}

ContentType ::= OBJECT IDENTIFIER

SignerInfos ::= SET OF SignerInfo

SignerInfo ::= SEQUENCE {

version CMSVersion,

sid SignerIdentifier,

digestAlgorithm DigestAlgorithmIdentifier,

signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,

signatureAlgoritm SignatureAlgorithmIdentifier,

signature SignatureValue,

unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL

}

SignerIdentifier ::= CHOICE {

issuerAndSerialNumber IssuerAndSerialNumber,

subjectKeyIdentifier [0] SubjectKeyIdentifier

}

SignatureValue ::= OCTET STRING

(sigue la sección 5 de la Parte 11 del Documento 9303)

• En caso negativo, el sistema de inspección DEBERÍA verificar que el KeyUsage del certificado de firmante de documentos está establecido en digitalSignature y que el certificado del firmante del documento no contiene ExtendedKeyUsage-Extension (véase el Doc 9303-12).

(En caso negativo, el sistema de inspección DEBERÍA comprobar que el KeyUsage del certificado de firmante de documentos está establecido en digitalSignature (firma digital) y que el certificado del firmante del documento no incluye ExtendedKeyUsage-Extension (véase el Doc 9303-12).)

2. El sistema de inspección o el funcionario inspector DEBERÍA verificar la coherencia de los códigos de país en:

• el campo Asunto y, si está presente, el SubjectAltName del certificado del firmante del documento;

• el campo Asunto y, si está presente, el SubjectAltName del punto de confianza (certificado CSCA);

• el Grupo de datos 1 leído del CI sin contacto; y

• la ZLM visual.

Además, el sistema de inspección o el funcionario inspector PUEDE comparar el contenido del Grupo de datos 1 con la ZLM visual (véanse los Docs 9303-12, 9303-10 y 9303-3, respectivamente).

3. El sistema de inspección DEBERÍA verificar que la fecha de expedición del eMRTD está incluida en el período de uso de la clave privada que figura en el certificado del firmante del documento (véase el Doc 9303-12).

La información biométrica puede utilizarse ahora para que ejecute la verificación de las características biométricas con la persona que presenta el eMRTD.

(La información biométrica puede utilizarse ahora para que ejecute la comprobación de las características biométricas con la persona que presenta el eMRTD.)

5.1.2 Proceso de inspección adicional para las aplicaciones LDS2

Los datos escritos después de la expedición del eMRTD no están protegidos por el objeto de seguridad del documento, que está firmado por el expedidor del documento. Para verificar la autenticidad de los datos escritos después de la expedición, el sistema de inspección DEBE realizar los siguientes pasos para cada objeto de datos escrito.

(Los datos escritos después de la emisión del eMRTD no están protegidos por el objeto de seguridad del documento, que está firmado por el emisor del documento. Para comprobar la autenticidad de los datos escritos después de la emisión, el sistema de inspección DEBE realizar los siguientes pasos para cada objeto de datos escrito.)

1. El sistema de inspección CONSTRUIRÁ y VALIDARÁ un trayecto de certificación desde un punto de confianza al certificado de firmante utilizado para firmar el objeto de datos con arreglo al Doc 9303-12. El sistema de inspección PUEDE usar ambos certificados, conocidos de antemano, y los certificados recuperados de la microplaqueta para construir el trayecto (véase el Doc 9303-10).

La sección 8 de la Parte 12 de documento 9303 recoge:

8. PROTOCOLO DEL SPOC

El punto de contacto único (SPOC) es la única interfaz expuesta por un Estado para las operaciones de gestión de claves con Estados extranjeros para la PKI de autorización LDS2. El protocolo del SPOC es el protocolo de gestión de claves para la realización de operaciones entre CVCA y DV de diferentes Estados. Aunque el protocolo del SPOC PUEDE utilizarse también para las comunicaciones internas entre una CVCA y los DV a escala nacional y entre un DV y el conjunto de terminales nacionales que gestiona, no se trata de un requisito. Para la gestión de claves a escala nacional pueden utilizarse otros protocolos de gestión de claves.

(El punto de contacto único (SPOC = Single Point Of Contact) es la única interfaz expuesta por un Estado para las operaciones de gestión de claves con Estados extranjeros para la PKI (Public Key Infrastructure = Infraestructura de clave pública) de autorización LDS2 (Logical Data Structure 2 = Estructura lógica de datos 2). El protocolo del SPOC es el protocolo de gestión de claves para la realización de operaciones entre CVCA (Country Verifying Certification Authority = Autoridad de certificación de verificación de país) y DV (Document Verifier = Verificador del documento) de diferentes Estados. Aunque el protocolo del SPOC PUEDE utilizarse también para las comunicaciones internas entre una CVCA y los DV a escala nacional y entre un DV y el conjunto de terminales nacionales que gestiona, no se trata de un requisito. Para la gestión de claves a escala nacional pueden utilizarse otros protocolos de gestión de claves.)

El protocolo del SPOC se utiliza para intercambiar claves y certificados, a fin de que:

• un DV pueda enviar una solicitud de certificación a la CVCA extranjera;

• una CVCA pueda enviar el certificado expedido al DV solicitante;

(una CVCA pueda enviar el certificado emitido al DV solicitante;)

• las CVCA y los DV puedan solicitar el conjunto de certificados válidos a una CVCA extranjera; y

• se puedan intercambiar mensajes generales entre los DV y las CVCA.

Dentro de un Estado:

• La CVCA UTILIZARÁ su SPOC nacional para aceptar las solicitudes de certificación extranjeras entrantes y para enviar los certificados resultantes o las notificaciones de fallo al solicitante;

• Los DV UTILIZARÁN su SPOC nacional para enviar las solicitudes de certificación a las CVCA extranjeras y para recibir los certificados resultantes o las notificaciones de fallo;

• El SPOC DEBE recopilar las solicitudes y respuestas de las CVCA y los DV nacionales y remitirlas al SPOC del Estado receptor; y

(El SPOC DEBE reunir las solicitudes y respuestas de las CVCA y los DV nacionales y enviarlas al SPOC del Estado receptor; y)

• El SPOC DEBE recopilar las solicitudes y respuestas de los SPOC de otros Estados y proporcionárselas a la CVCA/los DV nacionales correspondientes.

(El SPOC DEBE reunir las solicitudes y respuestas de los SPOC de otros Estados y facilitárselas a la CVCA/los DV nacionales correspondientes.)

La comunicación del servicio web del SPOC UTILIZARÁ HTTPS con autenticación TLS tanto del cliente como del servidor.

Nota.— Los SPOC son centros de comunicación entre las entidades de la PKI de autorización que, por lo tanto, deben estar disponible de manera ininterrumpida las 24 horas del día y ser accesibles para los SPOC extranjeros.

Cada SPOC se registra por separado con los demás SPOC de interés, proporcionando al menos la siguiente información:

(Cada SPOC se registra por separado con los demás SPOC de interés, suministrando al menos la siguiente información:)

• Estado del SPOC – el Estado para el que el SPOC proporciona la interfaz de comunicación;

(Estado del SPOC – el Estado para el que el SPOC suministra la interfaz de comunicación;)

• URL del SPOC – la URL del WSDL que describe la interfaz del SPOC y la ubicación del servicio; y

(URL del SPOC – la URL del WSDL que describe la interfaz del SPOC y la localización del servicio; y)

• certificado CA del SPOC – certificado (o certificados) utilizado para verificar los certificados de comunicación del SPOC.

(certificado CA (Certification Authority = Autoridad de certificación) del SPOC – certificado (o certificados) utilizado para comprobar los certificados de comunicación del SPOC.)

8.1 Estructuras relacionadas con el SPOC

Las estructuras siguientes están definidas para usarse en los mensajes del SPOC.

8.1.1 Estructura de solicitud de certificado

Las solicitudes de certificado son certificados reducidos verificables mediante tarjeta que pueden llevar una firma adicional. SE UTILIZARÁ el perfil de solicitud indicado en la tabla 17.

(Las solicitudes de certificado son certificados reducidos comprobables mediante tarjeta que pueden llevar una firma adicional. SE UTILIZARÁ el perfil de solicitud indicado en la tabla 17.)

Tabla 17. Perfil de solicitud de certificado CV

8.1.1.1 Identificador de perfil de certificado

La versión es 1, identificada por un valor de 0.

8.1.1.2 Referencia de la autoridad de certificación

La referencia de la autoridad de certificación DEBERÍA utilizarse para informar a la autoridad de certificación sobre la clave privada que se espera que el solicitante utilice para firmar el certificado. Si la referencia de la autoridad de certificación contenida en la solicitud se desvía de la referencia de la autoridad de certificación contenida en el certificado expedido (es decir, el certificado expedido está firmado por una clave privada que el solicitante no espera), el certificado correspondiente de la autoridad de certificación DEBERÍA proporcionarse también al solicitante como respuesta.

(La referencia de la autoridad de certificación DEBERÍA utilizarse para informar a la autoridad de certificación sobre la clave privada que se espera que el solicitante utilice para firmar el certificado. Si la referencia de la autoridad de certificación incluida en la solicitud se desvía de la referencia de la autoridad de certificación incluida en el certificado emitido (es decir, el certificado emitido está firmado por una clave privada que el solicitante no espera), el certificado correspondiente de la autoridad de certificación DEBERÍA facilitarse también al solicitante como respuesta.)

8.1.1.3 Clave pública

Las solicitudes de certificado DEBEN contener siempre parámetros de dominio.

(Las solicitudes de certificado DEBEN incluir siempre criterios de dominio.)

8.1.1.4 Referencia de la persona titular de certificado

La referencia de la persona titular de certificado se utiliza para identificar la clave pública contenida en la solicitud y el certificado resultante.

(La referencia de la persona titular de certificado se utiliza para identificar la clave pública incluida en la solicitud y el certificado resultante.)

8.1.1.5 Firma(s)

Una solicitud de certificado puede tener hasta dos firmas: una interna y otra externa:

Firma interna (SE EXIGE)

El cuerpo del certificado está autofirmado, es decir, que la firma interna DEBE ser verificable con la clave pública contenida en la solicitud de certificado. La firma SE CREARÁ sobre el cuerpo del certificado codificado (es decir, incluyendo la etiqueta y la longitud).

(El cuerpo del certificado está autofirmado, es decir, que la firma interna DEBE ser comprobable con la clave pública incluida en la solicitud de certificado. La firma SE CREARÁ sobre el cuerpo del certificado codificado (es decir, incluyendo la etiqueta y la longitud).)

Firma externa (CONDICIONAL)

• La firma es OPCIONAL si una entidad solicita el certificado inicial. En este caso, la solicitud PUEDE llevar una forma adicional de otra entidad de confianza de la autoridad de certificación receptora (p. ej., la CVCA nacional puede autenticar la solicitud de un DV enviada a una CVCA extranjera).

(La firma es OPCIONAL si una entidad solicita el certificado inicial. En este caso, la solicitud PUEDE incluir una firma adicional de otra entidad de confianza de la autoridad de certificación receptora (p. ej., la CVCA nacional puede autenticar la solicitud de un DV enviada a una CVCA extranjera).)

• La firma SE EXIGE si una entidad solicita un certificado sucesivo. En este caso, la solicitud DEBE llevar la firma adicional del solicitante utilizando un par de claves reciente registrado previamente en la autoridad de certificación receptora.

Si se utiliza la firma externa, SE UTILIZARÁ un objeto de datos de autenticación para anidar el certificado CV (solicitud), la referencia de la autoridad de certificación y la firma adicional. La referencia de la autoridad de certificación IDENTIFICARÁ la clave pública que se utilizará para verificar la firma adicional. La firma SE CREARÁ sobre la concatenación del certificado CV codificado y la referencia de la autoridad de certificación codificada (es decir, ambas incluyendo la etiqueta y la longitud).

(Si se utiliza la firma externa, SE UTILIZARÁ un objeto de datos de autenticación para alojar el certificado CV (solicitud), la referencia de la autoridad de certificación y la firma adicional. La referencia de la autoridad de certificación IDENTIFICARÁ la clave pública que se utilizará para comprobar la firma adicional. La firma SE CREARÁ sobre el enlace del certificado CV codificado y la referencia de la autoridad de certificación codificada (es decir, ambas incluyendo la etiqueta y la longitud).)