3.2 La PKI de autorización
El Estado expedidor o la organización expedidora escribe la aplicación de la LDS2 en el CI sin contacto en el momento de la personalización.
(El Estado emisor o la organización emisora escribe la aplicación de la LDS2 en el CI sin contacto en el momento de la personalización.)
Antes de que otro Estado pueda escribir objetos LDS2 en ese CI sin contacto, DEBE obtener la debida autorización del Estado expedidor u organización expedidora. Cada objeto de datos LDS2 está firmado digitalmente por un firmante LDS2 en el Estado escritor y, posteriormente, escrito en el IC sin contacto por un terminal autorizado en ese Estado escritor. El proceso de dos pasos de firma por parte de un firmante y de escritura por parte de un terminal autorizado es parecido al concepto LDS1, en que el firmante del documento firma digitalmente los objetos de seguridad del documento, pero estos se escriben posteriormente en el CI sin contacto por medio del proceso de personalización, como se ilustra en la figura 1. La lectura posterior de los objetos LDS2 del IC sin contacto se realiza a través de los terminales autorizados para la lectura del tipo de objeto LDS2 en cuestión.
(Antes de que otro Estado pueda escribir objetos LDS2 en ese CI (Circuito integrado) sin contacto, DEBE obtener la debida autorización del Estado emisor u organización emisora. Cada objeto de datos LDS2 está firmado digitalmente por un firmante LDS2 en el Estado escritor y, posteriormente, escrito en el IC (Integrated Circuit = Circuito integrado) sin contacto por un terminal autorizado en ese Estado escritor. El proceso de dos pasos de firma por parte de un firmante y de escritura por parte de un terminal autorizado es parecido al concepto LDS1, en que el firmante del documento firma digitalmente los objetos de seguridad del documento, pero estos se escriben posteriormente en el CI sin contacto por medio del proceso de personalización, como se ilustra en la figura 1. La lectura posterior de los objetos LDS2 del IC sin contacto se realiza a través de los terminales autorizados para la lectura del tipo de objeto LDS2 que corresponda.)
Figura 1. Modelo de confianza y arquitectura de escritura LDS2
La PKI de autorización permite que el Estado expedidor u organización expedidora controle el acceso (lectura y escritura) a los datos LDS2 en el IC sin contacto de los eMRTD que expide.
(La PKI de autorización posibilita que el Estado emisor u organización emisora controle el acceso (lectura y escritura) a los datos LDS2 en el IC sin contacto de los eMRTD que emite.)
3.2.1 Autoridad de certificación de verificación de país
Cada Estado expedidor u organización expedidora que permite añadir datos LDS2 en sus eMRTD, DEBE establecer una única autoridad de certificación de verificación de país (CVCA). Esta CVCA es una autoridad de certificación (CA) que es el punto de confianza de la PKI de autorización de ese Estado expedidor u organización expedidora y abarca todas las aplicaciones LDS2. La CVCA puede ser una entidad autónoma o estar integrada en la CSCA de ese mismo Estado u organización. Sin embargo, incluso si comparten ubicación, la CVCA DEBE utilizar un par de claves distinto del de la CSCA. La CVCA determina los derechos de acceso que se concederán a todos los verificadores del documento (DV), extranjeros y nacionales, y expide los certificados que contienen las autorizaciones individuales a cada uno de esos DV.
(Cada Estado emisor u organización emisora que admite añadir datos LDS2 en sus eMRTD, DEBE establecer una única autoridad de certificación de verificación de país (CVCA = Country Verifying Certification Authority). Esta CVCA es una autoridad de certificación (CA = Certification Authority) que es el punto de confianza de la PKI de autorización de ese Estado emisor u organización emisora y abarca todas las aplicaciones LDS2. La CVCA puede ser una entidad autónoma o estar integrada en la CSCA de ese mismo Estado u organización. Sin embargo, incluso si comparten localización, la CVCA DEBE utilizar un par de claves distinto del de la CSCA. La CVCA determina los derechos de acceso que se atribuirán a todos los verificadores del documento (DV = Document Verifier), extranjeros y nacionales, y emite los certificados que incluyen las autorizaciones individuales a cada uno de esos DV.)
3.2.2 Verificador del documento
Un verificador del documento (DV) es una CA que, como parte de una dependencia institucional, gestiona un grupo de terminales (por ejemplo, los terminales manejados por la policía de fronteras de un Estado) y expide certificados de autorización para esos terminales. Un DV DEBE haber recibido ya un certificado de autorización de la CVCA responsable antes de poder expedir certificados asociados a sus terminales. Los certificados expedidos por un DV a los terminales PUEDEN contener la misma autorización, o un subconjunto de esta, que se ha concedido al DV. NO DEBEN contener ninguna autorización más allá de la concedida a la DV.
(Un verificador del documento (DV) es una CA que, como parte de una dependencia institucional, gestiona un grupo de terminales (por ejemplo, los terminales manejados por la policía de fronteras de un Estado) y emite certificados de autorización para esos terminales. Un DV DEBE haber recibido ya un certificado de autorización de la CVCA responsable antes de poder emitir certificados asociados a sus terminales. Los certificados emitidos por un DV a los terminales PUEDEN incluir la misma autorización, o un subgrupo de esta, que se ha atribuido al DV. NO DEBEN incluir ninguna autorización más allá de la atribuida a la DV.)
3.2.3 Terminal/sistema de inspección
En el contexto de la PKI de autorización, un terminal es la entidad que accede al IC sin contacto del eMRTD y escribe en él un objeto de datos LDS2 firmado digitalmente o lee un objeto de datos LDS2. El terminal DEBE disponer de un certificado de autorización expedido por la DV local que concede la autorización requerida. El terminal también se denomina “sistema de inspección».
(En el contexto de la PKI de autorización, un terminal es la entidad que accede al IC sin contacto del eMRTD y escribe en él un objeto de datos LDS2 firmado digitalmente o lee un objeto de datos LDS2. El terminal DEBE disponer de un certificado de autorización emitido por la DV local que atribuye la autorización exigida. El terminal también se denomina “sistema de inspección».)
3.2.4 Punto de contacto único (SPOC)
(3.2.4 Punto de contacto único (SPOC = Single Point Of Contact)
Cada Estado que participe en la PKI de autorización LDS2 DEBE establecer un solo SPOC. Este SPOC es la interfaz que se utiliza para todas las comunicaciones entre la CVCA de un Estado y los DV de otro Estado. Las solicitudes y respuestas de certificados se comunican entre los SPOC de cada Estado utilizando el protocolo del SPOC definido en la sección 8.
Figura 2. Modelo de confianza de la PKI de autorización
Figura 3. Función del SPOC
(sigue el apartado 4 de la Parte 10 del Documento 9303)
4.5.3 Ordenamiento de la LDS
(4.5.3 Ordenamiento de la LDS (Logical Data Structure = Estructura lógica de datos)
Para la interoperabilidad internacional solo SE UTILIZARÁ el plan de ordenamiento aleatorio.
(Para el interfuncionamiento internacional solo SE UTILIZARÁ el plan de ordenamiento impredecible.)
4.5.4 Capacidad de almacenamiento de datos del CI sin contacto
La capacidad de almacenamiento de datos del CI sin contacto queda a la discreción del Estado expedidor, pero SERÁ de un mínimo de 32 kB. Esta capacidad mínima es necesaria para almacenar la imagen facial obligatoria, los datos de la ZLM y los elementos necesarios para asegurar los datos. El almacenamiento de imágenes faciales adicionales, de huellas digitales y/o del iris puede exigir un aumento considerable de la capacidad de almacenamiento de datos. No hay un valor máximo especificado de la capacidad de datos del CI sin contacto.
(La capacidad de almacenamiento de datos del CI sin contacto queda a la elección del Estado emisor, pero SERÁ de un mínimo de 32 kB. Esta capacidad mínima es necesaria para almacenar la imagen facial obligatoria, los datos de la ZLM y los elementos necesarios para asegurar los datos. El almacenamiento de imágenes faciales adicionales, de huellas digitales y/o del iris puede exigir un aumento considerable de la capacidad de almacenamiento de datos. No hay un valor máximo determinado de la capacidad de datos del CI sin contacto.)
En caso de que la infraestructura PKI de un Estado no esté disponible para firmar los datos de la LDS1 para el eMRTD como parte de la personalización y no pueda postergarse la expedición del/de los documento(s), SE RECOMIENDA que el CI sin contacto de la LDS1 para el eMRTD se deje en blanco y se bloquee. La LDS1 para el El eMRTD DEBERÍA contener una aprobación adecuada al respecto. Se prevé que esto constituya una circunstancia excepcional.
(En caso de que la infraestructura PKI (Public Key Infrastructure = Infraestructura de Clave Pública) de un Estado no esté disponible para firmar los datos de la LDS1 para el eMRTD como parte de la personalización y no pueda retrasarse la puesta en circulación del/de los documento(s), SE RECOMIENDA que el CI sin contacto de la LDS1 para el eMRTD se deje en blanco y se bloquee. La LDS1 para el eMRTD DEBERÍA incluir una aprobación adecuada al respecto. Se prevé que esto represente una circunstancia excepcional.)
4.5.5 Almacenamiento de otros datos
Un Estado PUEDE utilizar la capacidad de almacenamiento del CI sin contacto en un eMRTD para ampliar la capacidad de datos de lectura mecánica de la LDS1 para el eMRTD más allá de la definida para la interoperabilidad mundial. Esto puede tener la finalidad de proporcionar acceso de lectura mecánica a información de documentos de identidad (p. ej., detalles del certificado de nacimiento), a elementos de confirmación de la identidad personal almacenada (elementos biométricos) y/o a detalles de verificación de la autenticidad del documento.
(Un Estado PUEDE utilizar la capacidad de almacenamiento del CI sin contacto en un eMRTD para ampliar la capacidad de datos de lectura mecánica de la LDS1 para el eMRTD más allá de la establecida para el interfuncionamiento mundial. Esto puede tener la finalidad de facilitar el acceso de lectura mecánica a información de documentos de identidad (p. ej., detalles del certificado de nacimiento), a elementos de confirmación de la identidad personal almacenada (elementos biométricos) y/o a detalles de comprobación de la autenticidad del documento.)
4.5.6 Norma internacional para la codificación biométrica
La norma ISO/IEC 39794 sustituyó a la norma [ISO/IEC 19794:2005] como norma internacional para la codificación biométrica. Se ha definido el siguiente calendario de transición:
• el 1/1/2026, una vez transcurrido el período de preparación de seis años iniciado el 1/1/2020, los sistemas de inspección DEBEN estar en condiciones de manejar los datos ISO/IEC 39794;
• entre 2026 y 2030 los Estados y organizaciones expedidores pueden emplear los formatos de datos especificados en ISO/IEC 19794-X:2005 o en ISO/IEC 39794-X durante un período de transición de cuatro años. Durante este período de transición, serán esenciales la interoperabilidad y las pruebas de conformidad; y
(entre 2026 y 2030 los Estados y organizaciones emisores pueden utilizar los formatos de datos descritos en ISO/IEC 19794-X:2005 o en ISO/IEC 39794-X durante un período de transición de cuatro años. Durante este período de transición, serán esenciales el interfuncionamiento y las pruebas de conformidad; y)
• del 1/1/2030 en adelante, los expedidores de pasaportes DEBEN emplear la ISO/IEC 39794-X para codificar los datos biométricos.
(del 1/1/2030 en adelante, los emisores de pasaportes DEBEN utilizar la ISO/IEC 39794-X para codificar los datos biométricos.)
El informe técnico ISO/IEC 39794-5 de la OACI, Perfil de aplicación para los eMRTDs1, proporciona orientación sobre la transición de la [ISO/IEC 19794:2005] a la ISO/IEC 39794.
(El informe técnico ISO/IEC 39794-5 de la OACI, Perfil de aplicación para los eMRTD1, facilita orientación sobre la transición de la [ISO/IEC 19794:2005] a la ISO/IEC 39794.)
El informe técnico ISO/IEC 39794-5 se ha redactado en inglés. Tiene el siguiente contenido:
1. Scope
Doc 9303 uses ISO/IEC 19794:2005 to encode biometrics. In the new edition of ICAO Doc 9303, it is planned to move from using the ISO/IEC 19794 series for encoding biometric reference data to using the ISO/IEC 39794 series for this purpose.
To meet new and emerging market demands and to avoid future compatibility issues,
ISO/IEC JTC 1/SC 37 developed the ISO/IEC 39794 series; the third generation of biometric data interchange formats, defining extensible biometric data interchange formats capable of including future extensions in a structured manner. Extensible specifications in ASN.1 (Abstract Syntax Notation One) and the Distinguished Encoding Rules of ASN.1 form the basis for encoding biometric data in binary tag-length-value formats. XML Schema Definitions form the basis for encoding biometric data in XML (Extensible Markup Language).The structure of the data format in this standard is not backward compatible with the previous generations. However, this new generation addresses, for the first time, a mechanism to maintain future extensions in a backwards and forwards compatible manner.
This technical report specifies an application profile for using [ISO/IEC 39794-1] and
[ISO/IEC 39794-5] for storing Facial Images in DG2 in eMRTDs. Finger Images and Iris
Images MUST be stored according to [ISO/IEC 39794-1], [ISO/IEC 39794-4] and [ISO/IEC 39794-6] in data group DG3 and DG4. This technical report does not specify an application profile for the storage of Fingerprint and Iris, and the original ISO/IEC documents [ISO/IEC 39794-1], [ISO/IEC 39794-4] and [ISO/IEC 39794-6] MUST be referenced for their storage.
1.1 Terminology
1.1.1 Technical report terminology
The key words “MUST”, “MUST NOT”, “SHALL”, “SHALL NOT”, “REQUIRED”, “SHOULD”,“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119].
MUST This word, or the terms “REQUIRED” or “SHALL”, means that the definition is an absolute requirement of the specification.
MUST NOT This phrase, or the phrase “SHALL NOT”, means that the definition is an absolute prohibition of the specification.
SHOULD This word, or the adjective “RECOMMENDED”, means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
SHOULD NOT This phrase, or the phrase “NOT RECOMMENDED” means that there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label.
MAY This word, or the adjective “OPTIONAL”, means that an item is truly optional. One user may choose to include the item because a particular application requires it or because the user feels that it enhances the application while another user may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides).
In case OPTIONAL features are implemented, they MUST be implemented as described in this Technical Report.
1.1.2 Terms and Definitions
Term Definition
ASN.1 Abstract Syntax Notation One
DG Data Group
eMRTD Electronic Machine Readable Travel Document
BIT Biometric Information Template
BDB Biometric Data Block
DO Data Object
XML Extensible Markup Language
2. Data Groups for Biometric Data of eMRTD
Logical Data Structure of eMRTDs is specified in Doc 9303-10, which includes DG2 for face (mandatory), DG3 for fingerprint (optional), and DG4 for iris (optional). Each Data Group contains biometric data encoded in accordance with the international standards in order to keep international interoperability.
All of the above DGs, DG2, DG3 and DG4, MUST use the Biometric Information Template (BIT) group template with nested BITs (see Doc 9303-10). The nested BIT structure contains biometric data which can be encoded using 1 of 2 types of standards, ISO/IEC 19794 series first edition or ISO/IEC 39794 series.
Biometric data encoded in ISO/IEC 19794 series first edition is stored in the data object identified by tag ’5F2E’. Biometric data encoded in ISO/IEC 39794 series is stored in the data object identified by tag ’7F2E’.
Table 1: Tagsfor biometric data
Biometric data encoded in the data object identified by tag ‘7F2E’ MUST use the data structure in the table below.
Table 2: Data Structure under DO’7F2E’
Table 3: Tagsfor DOs defined in ISO/IEC 39794
3. Encoding
3.1 Encoding Scheme
eMRTDs MUST encode the biometric references using the Tagged Binary Encoding Scheme which results from the application of ASN.1 Distinguished Encoding Rules (DER). EMRTDs MUST NOT use the XML Encoding Scheme.
ISO/IEC 39794 uses an extensible ASN.1 structure to encode the Biometric Data Block
(BDB) and may add additional elements in the future. An inspection system based on an old version of the format SHALL be able to read BDBs based on the new version of the format and SHALL ignore unknown data elements.
This technical report makes some changes to the ASN.1 modules defined in [ISO/IEC
39794-1] and [ISO/IEC 39794-5]. The normative Annex A contains the ASN.1 modules that comply to this technical report.
3.2 Group biometric data template
[ISO/IEC 39794-5] allows for each Face Image Block to contain one or more geometric representations of a human face.
For eMRTDs, each Face Image Block MUST contain only a single geometric representation of a human face. For encoding multiple instances, the Biometric Information Template Group Template MUST be used. This technical report specifies the requirements for only the first Facial Image stored in the Biometric Information Template Group Template.
4. Extensibility
[ISO/IEC 39794-1] defines the following types of extensibilities of the ASN.1 structure.
1. Addition of components to sequence types.
2. Addition of components to choice types.
3. Extension of an enumerated type with a new value
a. Extensible enumerated type with a fallback value
b. Extensible enumerated type without a fallback value
The application profile in this technical report modifies the structure of an Extensible
Enumerated type with fallback value.
4.1 Extensible Enumerated Types with a Fallback Value
According to [ISO/IEC 39794-1], for extensible enumerated types with a fallback value, decoders can use a fallback value that is defined in the original type instead of an unknown value. For this category of enumerations, the extension strategy incorporates a mandatory fallback value that has a type of the first version. In that way, if an unknown value is received by a version 1 decoder, that decoder is able to revert to the fallback value that it can decode.
This TR requires that the original type is always encoded using a fallback value, even if there is no extension.
An example of extensible enumerated types with a fallback value is shown below. Extensible enumerated types with a fallback value used in biometric data structures MUST use the structure as detailed in the example below, in particular:
• The enumerated value MUST be encoded inside the fallback value (see
AnnotationReasonCode and fallback in the example).
• The fallback MUST be encoded within the extension block (see
AnnotationReasonExtensionBlock in the example). Hence, a extensible
enumerated types with a fallback value is always encoded using a fallback value,
even if there are no extensions.
• Only one value, which is the extension block, MUST be provided in the choice (see AnnotationReason in the example).
• If extensions are defined in the future, then for additional values an ENUMERATED type MUST be specified (see AnnotationReasonCodeV2 and
AnnotationReasonCodeV3 in the example).
• These enumerated types MUST be added to the extension block and marked
OPTIONAL (see codeV2 and codeV3 in the example).
Example
Note: This example is taken from ISO/IEC 39794-1, Section 9.6.4.
AnnotationReason ::= CHOICE {
extensionBlock [1] AnnotationReasonExtensionBlock
}
AnnotationReasonExtensionBlock ::= SEQUENCE {
fallback [0] AnnotationReasonCode,
…,
[[2025: — Extension added in the year 2025 version
codeV2 [1] AnnotationReasonCodeV2 OPTIONAL
]],
[[2026: — Extension added in the year 2026 version
codeV3 [2] AnnotationReasonCodeV3 OPTIONAL
]]
}
AnnotationReasonCode ::= ENUMERATED {
unknown(0),
other(1),
amputated(2),
unableToPrint(3),
bandaged(4),
physicallyChallenged(5),
diseased(6)
}
AnnotationReasonCodeV2 ::= ENUMERATED {
— Additional code defined in the 2025 version
frostbit(7)
}
AnnotationReasonCodeV3 ::= ENUMERATED {
— Additional code defined in the 2026 version
skinGraft(8)
}
Binary data without extension:
Hexadecimal Value: A1 05 A1 03 80 01 03
Hierarchical structure:
[1] A1 (choice)
[1] A1 (extensionBlock)
[0] 80 03 (fallback – unable to print)
Binary data with extension:
Hexadecimal Value: A1 08 A1 06 80 01 03 81 01 07
Hierarchical structure:
[1] A1 (choice)
[1] A1 (extensionBlock)
[0] 80 03 (fallback – unable to print)
[1] 81 07 (codeV2 – frostbit)
5. Changes to Metadata Elements in Biometric Data of eMRTD
The values of metadata elements to capture and encoding of face images MUST follow ISO/IEC 39794-5 Annex D.1. except for the changes that are detailed in this section.
This section covers the changes made to the metadata elements in biometric data of
eMRTD.
The changes specified in this section apply only to the first Facial Image stored in the
Biometric Information Template Group Template.
5.1 Gender
The value of this element SHALL be one of the following:
• Other;
• Male;
• Female;
5.2 Image representation block
The Image representation block MUST be a 2D image representation block.
5.3 Image data format
The values allowed in this element are:
• Jpeg
• Jpeg2000 lossy
• Jpeg2000 lossless
All other values including ‘png’ SHALL NOT be used.
5.4 2D Face Image Kind
The value in this element MUST be ‘MRTD’. Other values are not allowed.
5.5 3D shape representation block
This element MUST NOT be used.
(sigue el apartado 4 de la Parte 10 del Documento 9303)
La estructura lógica de datos de los eMRTD incluye el DG2 para el rostro (obligatorio), el DG3 para la huella digittal (opcional) y el DG4 para el iris (opcional). Cada grupo de datos contiene datos biométricos codificados de acuerdo con las normas internacionales para mantener la interoperabilidad internacional.
(La estructura lógica de datos de los eMRTD incluye el DG2 (Data Group = Grupo de datos) para el rostro (obligatorio), el DG3 para la huella digital (opcional) y el DG4 para el iris (opcional). Cada grupo de datos incluye datos biométricos codificados de acuerdo con las normas internacionales para mantener el interfuncionamiento internacional.)
Todos los DG anteriores (DG2, DG3 y DG4) DEBEN utilizar la plantilla de grupo de plantillas de información biométrica (BIT) con BIT anidados (véase el Doc 9303, parte 10). La estructura de BIT anidados contiene datos biométricos que se pueden codificar utilizando uno de los dos tipos de normas, la serie ISO/IEC 19794, primera edición, o la serie ISO/IEC 39794.
(Todos los DG anteriores (DG2, DG3 y DG4) DEBEN utilizar la plantilla de grupo de plantillas de información biométrica (BIT = Biometric Information Template) con BIT alojados (véase el Doc 9303, parte 10). La estructura de BIT alojados incluye datos biométricos que se pueden codificar utilizando uno de los dos tipos de normas, la serie ISO/IEC 19794, primera edición, o la serie ISO/IEC 39794.)
Los datos biométricos codificados en la serie ISO/IEC 19794, primera edición, se almacenan en el objeto de datos identificado con el rótulo «5F2E». Los datos biométricos codificados en la serie ISO/IEC 39794 se almacenan en el objeto de datos identificado con el rótulo «7F2E».
Tabla 1: Rótulos para datos biométricos
Los datos biométricos codificados en el objeto de datos identificado con el rótulo «7F2E» DEBEN utilizar la estructura de datos de la tabla siguiente.
Tabla 2: Estructura de datos bajo DO «7F2E»
Tabla 1: Rótulos para DO definidos en ISO/IEC 39794
4.6 Ficheros elementales (EF) de la LDS1 para eMRTD
(4.6 Ficheros elementales (EF = Elementary File) de la LDS1 para eMRTD)
4.6.1 Información de presencia de encabezamiento y grupo de datos EF.COM (OBLIGATORIO)
El EF.COM está ubicado en la aplicación de la LDS1 para el eMRTD (identificador de fichero breve = 1E) y contiene información sobre la versión LDS, información sobre la versión de Unicode y una lista de los grupos de datos que están presentes en la aplicación. La aplicación de la LDS1 para el eMRTD DEBE tener solamente un fichero EF.COM que contenga la información común para la aplicación.
(El EF.COM está situado en la aplicación de la LDS1 para el eMRTD (identificador de fichero breve = 1E) e incluye información sobre la versión LDS (Logical Data Structure = Estructura lógica de datos), información sobre la versión de Unicode y una lista de los grupos de datos que están presentes en la aplicación. La aplicación de la LDS1 para el eMRTD DEBE tener solamente un fichero EF.COM que incluya la información común para la aplicación.)
Los elementos de datos que pueden figurar en esta plantilla son los siguientes:
Tabla 35. Rótulos normativos de EF.COM
Se INCLUIRÁ un encabezamiento y un mapa de presencia de grupos de datos. El encabezamiento CONTENDRÁ la información siguiente, que permite al Estado receptor u organización receptora aprobada ubicar y descodificar los diversos grupos de datos y elementos de datos contenidos dentro del bloque registrado por el Estado expedidor u organización expedidora.
(Se INCLUIRÁ un encabezamiento y un mapa de presencia de grupos de datos. El encabezamiento INCLUIRÁ la información siguiente, que posibilita al Estado receptor u organización receptora aprobada hallar y descodificar los diversos grupos de datos y elementos de datos incluidos dentro del bloque registrado por el Estado emisor u organización emisora.)
Se RECOMIENDA que los sistemas de inspección que dependen del EF.COM se modifiquen para utilizar el SOD descrito en la versión 1.8 de LDS tan pronto como sea posible.
4.6.1.1 Número de versión LDS
El número de versión LDS define la versión de formato de la LDS. El formato exacto que ha de utilizarse para almacenar este valor se define en la sección 4.6 del presente documento. El formato normalizado para un número de versión LDS es “aabb”, donde:
(El número de versión LDS define la versión de modelo de la LDS. El modelo exacto que ha de utilizarse para almacenar este valor se define en la sección 4.6 de este documento. El modelo unificado para un número de versión LDS es “aabb”, donde:)
• “aa” = número (01-99) que identifica la versión principal de la LDS (es decir, adiciones significativas a la LDS);
• “bb” = número (01-99) que identifica la versión menor de la LDS.
4.6.1.2 Número de versión UNICODE
El número de versión Unicode identifica el método de codificación utilizado cuando se registran caracteres alfabéticos, numéricos y especiales, incluso caracteres nacionales. El formato exacto que ha de emplearse para almacenar este valor se define en la sección 4.7.1 de este documento. El formato normalizado para un número de versión Unicode es “aabbcc”:
(El número de versión Unicode identifica el método de codificación utilizado cuando se registran caracteres alfabéticos, numéricos y especiales, incluso caracteres nacionales. El modelo exacto que ha de utilizarse para almacenar este valor se define en la sección 4.7.1 de este documento. El modelo unificado para un número de versión Unicode es “aabbcc”:)
• “aa” = número que identifica la versión principal de la especificación Unicode (es decir, adiciones significativas a la especificación) publicada como libro;
(“aa” = número que identifica la versión principal de la determinación Unicode (es decir, adiciones significativas a la determinación) publicada como libro;)
• “bb” = número que identifica la versión menor de la especificación Unicode (es decir, adiciones de caracteres o más cambios normativos significativos, publicados como informe técnico); y
(bb” = número que identifica la versión menor de la determinación Unicode (es decir, adiciones de caracteres o más cambios normativos significativos, publicados como informe técnico); y)
• “cc” = número que identifica la versión actualizada de la especificación Unicode (es decir, cualquier otro cambio a las partes normativas o informativas importantes de la especificación que podría modificar el comportamiento del programa. Estos cambios se reflejan en nuevos ficheros de bases de datos de caracteres Unicode y en una página de actualización). Por razones históricas, la numeración dentro de cada uno de los campos (es decir, a, b, c) no es necesariamente consecutiva.
(cc” = número que identifica la versión actualizada de la determinación Unicode (es decir, cualquier otro cambio a las partes normativas o informativas importantes de la determinación que podría modificar el comportamiento del programa. Estos cambios se reflejan en nuevos ficheros de bases de datos de caracteres Unicode y en una página de actualización). Por razones históricas, la numeración dentro de cada uno de los campos (es decir, a, b, c) no es necesariamente sucesiva.)
El conjunto de caracteres universal (UCS) DEBE cumplir la [ISO/IEC 10646].
(El conjunto de caracteres universal (UCS = Universal Character Set) DEBE cumplir la [ISO/IEC 10646].)
4.6.2 Objeto de seguridad del documento EF.SOD (OBLIGATORIO)
Además de los grupos de datos de LDS, el CI sin contacto contiene un objeto de seguridad de documento almacenado en EF.SOD. Este objeto es firmado digitalmente por el Estado expedidor y contiene valores de condensación del contenido de la LDS.
(Además de los grupos de datos de LDS, el CI sin contacto incluye un objeto de seguridad de documento almacenado en EF.SOD. Este objeto es firmado digitalmente por el Estado emisor e incluye valores de condensación del contenido de la LDS.)
Tabla 36. Rótulos EF.SOD
Se han desplegado dos versiones del objeto de seguridad del documento EF.SOD: Se trata de la versión EF.SOD V0 ya existente, que puede encontrarse en el apéndice D, y de la versión RECOMENDADA EF.SOD V1, que figura en esta sección. Solo SE EXIGE y permite una EF.SOD.
El Apéndice D de la Parte 10 del documento 9303 recoge:
Apéndice D de la Parte 10
OBJETO DE SEGURIDAD DEL DOCUMENTO EF.SOD
VERSIÓN V0 PARA LA LDS V1.7 (VERSIÓN ANTERIOR)
(INFORMATIVO)
El objeto de seguridad del documento V0 para la LDS v1.7 no contiene la información sobre la versión de la LDS y la versión Unicode:
(El objeto de seguridad del documento V0 para la LDS v1.7 no incluye la información sobre la versión de la LDS y la versión Unicode:)
LDSSecurityObject ::= SEQUENCE {
version LDSSecurityObjectVersion,
hashAlgorithm DigestAlgorithmIdentifier,
dataGroupHashValues SEQUENCE SIZE (2..ub-DataGroups) OF
DataGroupHash}
D.1 TIPO DE DATOS FIRMADOS PARA SOD V0
(D.1 TIPO DE DATOS FIRMADOS PARA SOD (Document Security Object = Objeto de seguridad de documento) V0
El objeto de seguridad del documento se implementa como tipo de datos firmados (SignedData), según se especifica en [RFC 3369]. Todos los objetos de seguridad SE PRODUCIRÁN en formato de regla de codificación distinguida (DER) para preservar la integridad de las firmas que contengan.
(El objeto de seguridad del documento se instala como tipo de datos firmados (SignedData), como se describe en [RFC 3369]. Todos los objetos de seguridad SE PRODUCIRÁN en tipo de regla de codificación distinguida (DER = Distinguished Encoding Rule) para proteger la invariabilidad de las firmas que incluyan.)
Nota 1.— m = OBLIGATORIO — el campo ESTARÁ presente.
Nota 2.— x = no utilizar — el campo NO DEBERÍA llenarse.
Nota 3.— o = opcional — el campo PUEDE estar presente.
Nota 4.— c = elección — el contenido del campo es una elección entre varias alternativas
Tabla D-1. Tipo de datos firmados para SOD V0
D.2 Objeto de seguridad deL documento de LA LDS DEL perfil ASN.1 PARA SOD V0
LDSSecurityObjectV0 {joint-iso-itu-t (2) international(23) icao(136) mrtd(1)
security(1) ldsSecurityObject(1)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
— Importaciones de RFC 3280 [PERFIL],
AlgorithmIdentifier FROM
PKIX1Explicit88 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) };
— Constantes
ub-DataGroups INTEGER ::= 16
— Object Identifiers
id-icao OBJECT IDENTIFIER::={joint-iso-itu-t(2) international(23) icao(136)}
id-icao-mrtd OBJECT IDENTIFIER ::= {id-icao 1}
id-icao-mrtd-security OBJECT IDENTIFIER ::= {id-icao-mrtd 1}
id-icao-mrtd-security-ldsSecurityObject OBJECT IDENTIFIER ::= {id-icao-mrtd-
security 1}
— Objeto de seguridad LDS
LDSSecurityObjectVersion ::= INTEGER {v0(0)}
DigestAlgorithmIdentifier ::= AlgorithmIdentifier
LDSSecurityObject ::= SEQUENCE {
version LDSSecurityObjectVersion,
hashAlgorithm DigestAlgorithmIdentifier,
dataGroupHashValues SEQUENCE SIZE (2..ub-DataGroups) OF
DataGroupHash }
DataGroupHash ::= SEQUENCE {
dataGroupNumber DataGroupNumber,
dataGroupHashValue OCTET STRING }
DataGroupNumber ::= INTEGER {
dataGroup1 (1),
dataGroup2 (2),
dataGroup3 (3),
dataGroup4 (4),
dataGroup5 (5),
dataGroup6 (6),
dataGroup7 (7),
dataGroup8 (8),
dataGroup9 (9),
dataGroup10 (10),
dataGroup11 (11),
dataGroup12 (12),
dataGroup13 (13),
dataGroup14 (14),
dataGroup15 (15),
dataGroup16 (16)}
END
Nota 1.— El campo dataGroupHashValue contiene la condensación calculada del contenido completo del EF de grupo de datos, especificado por dataGroupNumber.
(Nota 1.— El campo dataGroupHashValue incluye la condensación calculada del contenido completo del EF de grupo de datos, especificado por dataGroupNumber.)
Nota 2.— Los DigestAlgorithmIdentifiers DEBEN omitir los parámetros NULL, mientras que el SignatureAlgorithmIdentifier definido en RFC 3447) DEBE incluir NULL como parámetro si no hay parámetros presentes, incluso cuando se usen algoritmos SHA2 con arreglo a RFC 5754. El sistema de inspección DEBE aceptar el campo DigestAlgorithmIdentifiers con ambas condiciones, es decir, parámetros ausentes y parámetros NULL.
(Nota 2.— Los DigestAlgorithmIdentifiers DEBEN omitir los criterios NULL, mientras que el SignatureAlgorithmIdentifier definido en RFC 3447) DEBE incluir NULL como criterio si no hay criterios presentes, incluso cuando se usen algoritmos SHA2 de acuerdo con RFC 5754. El sistema de inspección DEBE aceptar el campo DigestAlgorithmIdentifiers con ambos requisitos, es decir, criterios ausentes y criterios NULL.)
(sigue la sección 4 de la Parte 10 del documento 9303)
4.6.2.1 Objeto de seguridad del documento EF.SOD V1 LDS v1.8
El objeto de seguridad del documento V1 para la LDS v1.8 se ha ampliado con un atributo firmado, que contiene la información sobre la versión de la LDS y la versión Unicode:
(El objeto de seguridad del documento V1 para la LDS v1.8 se ha ampliado con una particularidad firmada, que incluye la información sobre la versión de la LDS y la versión Unicode:)
LDSSecurityObject ::= SEQUENCE {
version LDSSecurityObjectVersion,
hashAlgorithm DigestAlgorithmIdentifier,
dataGroupHashValues SEQUENCE SIZE (2..ub-DataGroups) OF
DataGroupHash,
ldsVersionInfo LDSVersionInfo OPTIONAL
— Si está presente, la version DEBE ser V1
}
LDSVersionInfo ::= SEQUENCE {
ldsVersion PrintableString,
unicodeVersion PrintableString }
4.6.2.2 Tipo de datos firmados (SignedData Type) para SOD V1
El objeto de seguridad del documento se implementa como tipo SignedData, según se especifica en [RFC 3369], Cryptographic Message Syntax (CMS), agosto de 2002. Todos los objetos de seguridad DEBEN producirse en formato de regla de codificación distinguida (DER) para preservar la integridad de las firmas que contengan.
(El objeto de seguridad del documento se instala como tipo SignedData, como se describe en [RFC 3369], Cryptographic Message Syntax (CMS), agosto de 2002. Todos los objetos de seguridad DEBEN producirse en tipo de regla de codificación distinguida (DER) para proteger la invariabilidad de las firmas que incluyan.)
Nota 1.— m = EXIGIDO — el campo ESTARÁ presente.
Nota 2.— x= no utilizar — el campo NO DEBERÍA llenarse.
Nota 3.— o = opcional — el campo PUEDE estar presente.
Nota 4.— c = elección — el contenido del campo es una elección entre alternativas
Tabla 37. Tipo de datos firmados para SOD V1
4.6.2.3 ASN.1 Profile LDS Document Security Object for SOD V1
Este apartado se ha reproducido más arriba.
4.7 Elementos de datos que integran los grupos de datos 1 a 16
Los grupos de datos 1 (DG1) a 16 (DG16) consisten cada uno en varios elementos de datos obligatorios, opcionales y condicionales. Se SEGUIRÁ el orden especificado de los elementos de datos dentro del grupo de datos. Cada grupo de datos se ALMACENARÁ en un EF transparente. El direccionamiento de los EF SE HARÁ por identificador de EF breve, como se indica en la Tabla 38. Los EF TENDRÁN nombres de fichero conformes al número n, EF.DGn, donde n es el número del grupo de datos.
(Los grupos de datos 1 (DG1) a 16 (DG16) consisten cada uno en varios elementos de datos obligatorios, opcionales y condicionales. Se SEGUIRÁ el orden determinado de los elementos de datos dentro del grupo de datos. Cada grupo de datos se ALMACENARÁ en un EF (Elementary File = Fichero elemental) transparente. El direccionamiento de los EF SE HARÁ por identificador de EF breve, como se indica en la Tabla 38. Los EF TENDRÁN nombres de fichero adecuados al número n, EF.DGn, donde n es el número del grupo de datos.)
Tabla 38. Elementos de datos obligatorios y opcionales que se combinan
para formar la estructura de los grupos de datos 1 (DG1) a 16 (DG16)
4.7.1 GRUPO DE DATOS 1 — Información en la zona de lectura mecánica (OBLIGATORIO)
Los elementos de datos del Grupo de datos 1 (DG1) tienen por objeto reflejar el contenido completo de la zona de lectura mecánica (ZLM) independientemente de si esta contiene datos reales o caracteres de relleno. Los detalles sobre la implementación de la ZLM dependen del tipo de LDS1 DE LA eMRTD (formatos DV1, DV2 o DV3).
Este elemento de datos contiene la información de la ZLM EXIGIDA para el documento en la plantilla ‘61’. La plantilla contiene un objeto de datos, la ZLM en el objeto de datos ‘5F1F‘. El objeto de datos ZLM es un elemento de datos compuesto, idéntico a la información ZLM OCR-B impresa en el documento.
(Este elemento de datos incluye la información de la ZLM (Zona de Lectura Mecánica) EXIGIDA para el documento en la plantilla ‘61’. La plantilla incluye un objeto de datos, la ZLM en el objeto de datos ‘5F1F‘. El objeto de datos ZLM es un elemento de datos estructurado, idéntico a la información ZLM OCR-B (Optical Character Recognition font defined in ISO 1073-2 = Tipo de letra para reconocimiento óptico de caracteres definido en la ISO 1073-2) impresa en el documento.)
Tabla 39. Rótulos del grupo de datos 1
| Rótulo | L | Valor | ||
| ‘61’ | Var | |||
| Rótulo | L | Valor | ||
| ‘5F1F’ | Var | El objeto de datos ZLM es un elemento de datos compuesto. (EXIGIDO) (El elemento de datos incluye todos los campos obligatorios desde el tipo de documento hasta el dígito de comprobación estructurado.) | ||
4.7.1.1 GRUPO DE DATOS 1 – Datos de EF.DG1 para la LDS1 del eMRTD de tamaño DV1
En esta sección se describen los elementos de datos que pueden estar presentes en el grupo de datos 1 (DG1). Los requisitos sobre almacenamiento, ordenamiento y codificación del DG1 son exactamente los mismos que figuran en la ZLM impresa y se describen en las Partes 3 y 5 del Doc 9303-3. Los elementos de datos y sus formatos dentro de cada zona de grupo de datos para DV1 SERÁN los que se indican en la tabla siguiente:
(En esta sección se describen los elementos de datos que pueden estar presentes en el grupo de datos 1 (DG1). Los requisitos sobre almacenamiento, clasificación y codificación del DG1 son exactamente los mismos que figuran en la ZLM impresa y se describen en las Partes 3 y 5 del Doc 9303-3. Los elementos de datos y sus modelos dentro de cada zona de grupo de datos para DV1 SERÁN los que se indican en la tabla siguiente:)
Nota.— A = carácter alfabético [A-Z], N = carácter numérico [0-9], S = carácter especial [‘<’], F = campo de longitud fija.
Tabla 40. Elementos de datos para el formato DV1
| Elemento de dato | Opcional u OBLIGATORIO | Nombre del elemento de dato | Núm. de bytes | Fijo o variable | Tipo de codificación |
| 0 1 | M | Código de documento | 2 | F | A, S |
| 0 2 | M | Estado emisor u organización emisora | 3 | F | A, S |
| 0 3 | M | Número de documento (nueve caracteres más significativos) | 9 | F | A, N, S |
| Elemento de dato | Opcional u OBLIGATORIO | Nombre del elemento de dato | Núm. de bytes | Fijo o variable | Tipo de codificación |
| 0 4 | M | Dígito de comprobación — Número del documento o carácter de relleno (<) que indica que el número de documento supera los nueve caracteres | 1 | F | N, S |
| 0 5 | M | Datos opcionales o, en el caso de un número de documento que supere los nueve caracteres, caracteres menos significativos del número de documento más dígito de comprobación del número de documento más carácter de relleno | 15 | F | A, N, S |
| 0 6 | M | Fecha de nacimiento | 6 | F | N,S |
| 0 7 | M | Dígito de comprobación — Fecha de nacimiento | 1 | F | N |
| 0 8 | M | Sexo | 1 | F | A,S |
| 0 9 | M | Fecha de caducidad | 6 | F | N |
| 1 0 | M | Dígito de comprobación — Fecha de caducidad | 1 | F | N |
| 1 1 | M | Nacionalidad | 3 | F | A,S |
| 1 2 | M | Datos opcionales | 1 1 | F | A,N,S |
| 1 3 | M | Dígito de comprobación estructurado | 1 | F | N |
| 1 4 | M | Nombre del titular | 3 0 | F | A,N,S |
4.7.1.2 GRUPO DE DATOS 1 — Elementos de datos de EF.DG1 para eMRTD de tamaño DV2
En esta sección se describen los elementos de datos que pueden estar presentes en el grupo de datos 1 (DG1). Los requisitos de almacenamiento, ordenamiento y codificación del DG1 son exactamente los mismos que figuran en la ZLM impresa y se describen en las Partes 3 y 6 del Doc 9303. Los elementos de datos y su formato dentro de cada zona de grupo de datos para DV2 SERÁN los que se indican en la tabla siguiente:
(En esta sección se describen los elementos de datos que pueden estar presentes en el grupo de datos 1 (DG1). Los requisitos de almacenamiento, clasificación y codificación del DG1 son exactamente los mismos que figuran en la ZLM (Zona de Lectura Mecánica) impresa y se describen en las Partes 3 y 6 del Doc 9303. Los elementos de datos y su modelo dentro de cada zona de grupo de datos para DV2 SERÁN los que se indican en la tabla siguiente:)
Nota.— A = carácter alfabético [A-Z], N = carácter numérico [0-9], S = carácter especial [‘<’], F = campo de longitud fija.
Tabla 41. Elementos de datos para el formato DV2
Dato | Opcional u OBLIGATORIO | Nombre del elemento de dato | Núm. de bytes | Fijo o variable | Tipo de codificación |
| 0 1 | M | Número documento | 2 | F | A,S |
| 0 2 | M | Estado emisor u organización emisora | 3 | F | A,S |
| 0 3 | M | Nombre del titular | 3 1 | F | A, N, S |
| 0 4 | M | Número de documento (nueve caracteres principales) | 9 | F | A, N, S |
| 0 5 | M | Dígito de comprobación | 1 | F | N,S |
| 0 6 | M | Nacionalidad | 3 | F | A,S |
| 0 7 | M | Fecha de nacimiento | 6 | F | N,S |
| 0 8 | M | Dígito decomprobación | 1 | F | N |
| 0 9 | M | Sexo | 1 | F | A,S |
| 1 0 | M | Fecha de caducidad | 6 | F | N |
| 1 1 | M | Dígito de comprobación | 1 | F | N |
| 1 2 | M | Datos opcionales más carácter de relleno | 7 | F | A,N,S |
| 1 3 | M | Dígito de comprobación estructurado – ZLM línea 2 | 1 | F | N |
4.7.1.3 GRUPO DE DATOS 1 — Datos de EF.DG1 para la LDS1 de eMRTD de tamaño DV3
En esta sección se describen los elementos de datos que pueden estar presentes en el grupo de datos 1 (DG1). Los requisitos de almacenamiento, ordenamiento y codificación del DG1 son exactamente los mismos que figuran en la ZLM impresa y se describen en las Partes 3 y 4 del Doc 9303. Los elementos de datos y su formato dentro de cada zona de grupo de datos para DV3 SERÁN los que se indican en la tabla siguiente:
(En esta sección se describen los elementos de datos que pueden estar presentes en el grupo de datos 1 (DG1). Los requisitos de almacenamiento, clasificación y codificación del DG1 son exactamente los mismos que figuran en la ZLM (Zona de Lectura Mecánica) impresa y se describen en las Partes 3 y 4 del Doc 9303. Los elementos de datos y su modelo dentro de cada zona de grupo de datos para DV3 SERÁN los que se indican en la tabla siguiente:)
Nota.— A = carácter alfabético [A-Z], N = carácter numérico [0-9], S = carácter especial [‘<’], F = campo de longitud fija.
Tabla 42. Elementos de datos para el formato DV3
Dato | Opcional u OBLIGATORIO | Nombre del dato | Número de bytes | Fijo o variable | Tipo de codificación |
| 0 1 | M | Tipo de documento | 2 | F | A,S |
| 0 2 | M | Estado emisor u organización emisora | 3 | F | A,S |
| 0 3 | M | Nombre del titular | 3 9 | F | A, S |
| 0 4 | M | Número de documento | 9 | F | A, S |
| 0 5 | M | Dígito de comprobación— Núm. de documento | 1 | F | N,S |
| 0 6 | M | Nacionalidad | 3 | F | A,S |
| 0 7 | M | Fecha de nacimiento | 6 | F | N,S |
| 0 8 | M | Dígito decomprobación — Fecha de nacimiento | 1 | F | N |
| 0 9 | M | Sexo | 1 | F | A,S |
| 1 0 | M | Fecha de caducidad | 6 | F | N |
| 1 1 | M | Dígito de comprobación — Fecha de caducidad o válido hasta | 1 | F | N |
| 1 2 | M | Datos opcionales | 1 4 | F | A,N,S |
| 1 3 | M | Dígito de comprobación | 1 | F | N |
| 14 | M | Dígito de comprobación estructurado | 1 | F | N |
4.7.2 GRUPO DE DATOS 2 — Elementos de identificación codificados — Rostro (OBLIGATORIO)
El grupo de datos 2 (DG2) representa la característica biométrica de interfuncionamiento mundial para la confirmación mecánica de identidad con documentos de viaje de lectura mecánica, que CONSISTIRÁ en una imagen facial del titular como elemento de entrada a un sistema de reconocimiento del rostro. Si existe más de un registro, la primera entrada SERÁ la codificación de interfuncionamiento internacional más reciente.
Tabla 43. Rótulos del grupo de datos 2
4.7.2.1 Codificación biométrica del EF.DG2
El DG2 DEBE utilizar la plantilla de grupo de plantillas de información biométrica (BIT) con los BIT anidados que se especifican en [ISO/IEC 7816-11], para tener la posibilidad de almacenar múltiples plantillas biométricas, que se correspondan con el CBEFF. El subencabezamiento biométrico define el tipo de característica biométrica presente y la característica biométrica específica. La opción anidada de ISO/IEC [7816-11] ha de utilizarse siempre, incluso para codificaciones de una única plantilla biométrica. Este último caso se indica numerando con n = 1.
(El DG2 DEBE utilizar la plantilla de grupo de plantillas de información biométrica (BIT = Biometric Information Template) con los BIT alojados que se especifican en [ISO/IEC 7816-11], para tener la posibilidad de almacenar múltiples plantillas biométricas, que se correspondan con el CBEFF (Common Biometric Exchange Format Framework = Marco común de formatos de intercambio biométrico). El subencabezamiento biométrico define el tipo de característica biométrica presente y la característica biométrica concreta. La opción alojada de ISO/IEC [7816-11] ha de utilizarse siempre, incluso para codificaciones de una única plantilla biométrica. Este último caso se indica numerando con n = 1.)
Cada plantilla anidada tiene la estructura siguiente:
(Cada plantilla alojada tiene la estructura siguiente:)
Tabla 44. Grupo de datos 2 — Rótulos de codificación biométrica
Se utiliza el OID del CBEFF por defecto. El objeto de datos OID (rótulo ‘06’) especificado en la plantilla de información biométrica (BIT, rótulo ‘7F60’) especificado en [ISO/IEC 7816-11] no se incluye en esta estructura. Análogamente, la
autoridad de asignación de rótulos no se especifica en la estructura.
(Se utiliza el OID (Object Identifier = Identificador de objeto) del CBEFF preestablecido. El objeto de datos OID (rótulo ‘06’) especificado en la plantilla de información biométrica (BIT, rótulo ‘7F60’) descrito en [ISO/IEC 7816-11] no se incluye en esta estructura. Similarmente, la autoridad de asignación de rótulos no se incluye en la estructura.)
Para facilitar la interoperabilidad, la primera característica biométrica registrada en cada grupo de datos se CODIFICARÁ con arreglo a [ISO/IEC19794-5].
(Para facilitar el interfuncionamiento, la primera característica biométrica registrada en cada grupo de datos se CODIFICARÁ de acuerdo con [ISO/IEC19794-5].)
Nota.— ISO/IEC 39794 sustituirá a ISO/IEC 19794:2005 como norma internacional para la codificación biométrica. Véase la sección 4.5.6.
4.7.2.2 GRUPO DE DATOS 2 — Datos de EF.DG2
En esta sección se describen los datos que pueden estar presentes en el grupo de datos 2 (DG2). Los elementos de datos y su formato dentro del grupo de datos SERÁN los que se indican en las tablas siguientes:
Nota.— 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.
Tabla 45. Elementos de datos para DG2
4.7.3 GRUPO DE DATOS 3 — Elementos de identificación adicionales — Dedos (OPCIONAL)
La OACI reconoce que los Estados miembros pueden optar por utilizar la huella digital o el reconocimiento del iris como tecnologías biométricas adicionales para apoyar la confirmación mecánica de la identidad que SERÁN codificados como grupo de datos 3 (DG3).
Tabla 46. Rótulos del Grupo de datos 3
4.7.3.1 Codificación biométrica de EF.DG3
El DG3 DEBE utilizar la plantilla del grupo de plantilla de información biométrica (BIT) con BITS anidadas según se especifica en [ISO/IEC 7816-11], para tener la posibilidad de almacenar múltiples plantillas biométricas, que se correspondan con el CBEFF. El subencabezamiento biométrico define el tipo de característica biométrica presente y la característica biométrica específica. La opción anidada de [ISO/IEC 7816-11] DEBE utilizarse, incluso para codificaciones de una única plantilla biométrica. Este último caso se indica numerando con n = 1. El número de casos en DG3 puede ser ‘0…n’.
(El DG3 DEBE utilizar la plantilla de grupo de plantilla de información biométrica (BIT = Biometric Information Template) con BITS alojadas como se describe en [ISO/IEC 7816-11], para tener la posibilidad de almacenar múltiples plantillas biométricas, que se correspondan con el CBEFF (Common Biometric Exchange Format Framework = Marco común de formatos de intercambio biométrico). El subencabezamiento biométrico define el tipo de característica biométrica presente y la característica biométrica concreta. La opción alojada de ISO/IEC [7816-11] DEBE utilizarse, incluso para codificaciones de una única plantilla biométrica. Este último caso se indica numerando con n = 1. El número de casos en DG3 puede ser ‘0…n’.)
Cada plantilla anidada tiene la estructura siguiente:
(Cada plantilla alojada tiene la estructura siguiente:)
Tabla 47. Rótulos anidados del grupo de datos 3
Se utiliza el OID de CBEFF por defecto. El objeto de datos OID (rótulo ‘06’) en la plantilla de información biométrica (BIT, rótulo ‘7F60’) especificado en [ISO/IEC 7816-11] no se incluye en esta estructura. Análogamente, la autoridad de asignación de rótulo no se especifica en la estructura.
(Se utiliza el OID (Object Identifier = Identificador de objeto) de CBEFF preestablecido. El objeto de datos OID (rótulo ‘06’) en la plantilla de información biométrica (BIT, rótulo ‘7F60’) descrito en [ISO/IEC 7816-11] no se incluye en esta estructura. Similarmente, la autoridad de asignación de rótulos no se incluye en la estructura.)
Para facilitar la interoperabilidad, la primera característica biométrica registrada en cada grupo de datos SE CODIFICARÁ con arreglo a [ISO/IEC19794-4].
(Para facilitar el interfuncionamiento, la primera característica biométrica registrada en cada grupo de datos SE CODIFICARÁ de acuerdo con [ISO/IEC19794-4].)
Nota.— ISO/IEC 39794 sustituirá a ISO/IEC 19794:2005 como norma internacional para la codificación biométrica. Véase la sección 4.5.6.
4.7.3.2 GRUPO DE DATOS 3 — Datos de EF.DG3
En esta sección se describen los datos que pueden estar presentes en el Grupo de datos 3 (DG3). Los datos y su formato dentro del grupo de datos SERÁN los que se indican en la tabla siguiente:
Nota.— 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.
Tabla 48. Elementos de datos para DG3
4.7.3.2.1 Codificación del subtipo de característica biométrica
Los rótulos de la plantilla de encabezamiento biométrico y sus valores asignados son los mínimos que cada implementación ADMITIRÁ según se indica en la tabla siguiente. Cada plantilla de información biométrica individual tiene la estructura siguiente:
Tabla 49. Plan para la codificación de subcaracterísticas: CBEFF
4.7.3.2.2 Codificación de cero casos
Los Estados que no expiden LDS1 para eMRTD con huellas digitales NO DEBERÍAN rellenar el DG3. El DG3 de esta estructura tiene el inconveniente de que resultará en una condensación estática de DG3 en el SOD para todas las LDS1 de los eMRTD en que los datos biométricos no estén presentes ni introducidas en el momento de expedición de la LDS1del eMRTD, pero se haya declarado el DG3. Para fines de interoperabilidad, los Estados que incluyen huellas digitales en sus LDS1 del eMRTD DEBEN almacenar una plantilla del grupo de información biométrica vacía en los casos en que no se disponga de huella digital en el momento de la expedición de la LDS1 del eMRTD. El contador de la plantilla indica un valor de ‘00’ en este caso.
(Los Estados que no emiten LDS1 (Logical Data Structure = Estructura lógica de datos) para eMRTD (Electronic Machine Readable Travel Document = Documento de viaje de lectura mecánica electrónico) con huellas digitales NO DEBERÍAN rellenar el DG3. El DG3 de esta estructura tiene el inconveniente de que resultará en una condensación estática de DG3 en el SOD (Document Security Object = Objeto de seguridad de documento) para todas las LDS1 de los eMRTD en que los datos biométricos no estén presentes ni introducidas en el momento de puesta en circulación de la LDS1 del eMRTD, pero se haya declarado el DG3. Para fines de interfuncionamiento, los Estados que incluyen huellas digitales en sus LDS1 del eMRTD DEBEN almacenar una plantilla del grupo de información biométrica vacía en los casos en que no se disponga de huella digital en el momento de la puesta en circulación de la LDS1 del eMRTD. El contador de la plantilla indica un valor de ‘00’ en este caso.)
Se RECOMIENDA añadir el rótulo ‘53’ con un contenido definido por el expedidor (p. ej., un número aleatorio).
(Se RECOMIENDA añadir el rótulo ‘53’ con un contenido definido por el emisor (p. ej., un número impredecible).)
Tabla 50. Codificación de cero casos
4.7.3.2.3 Codificación de un caso
En los casos en que solo se disponga de una huella digital, DEBE codificarse el caso único de la manera siguiente (ejemplo para DG3 – huella digital):
Tabla 51. Codificación de un caso
Nota.— ISO/IEC 39794 sustituirá a ISO/IEC 19794:2005 como norma internacional para la codificación biométrica. Véase la sección 4.5.6.
4.7.3.2.4 Codificación de más de un caso
Para lograr la interoperabilidad, cada característica DEBE almacenarse en una plantilla de información biométrica individual. La posición de la característica DEBE especificarse dentro del subtipo de característica biométrica de CBEFF si se dispone de esa información. La tabla siguiente contiene un ejemplo elaborado para la codificación CBEFF de un elemento DG3 interoperable con dos imágenes de huellas digitales.
(Para lograr el interfuncionamiento, cada característica DEBE almacenarse en una plantilla de información biométrica individual. La posición de la característica DEBE describirse dentro del subtipo de característica biométrica de CBEFF si se dispone de esa información. La tabla siguiente incluye un ejemplo elaborado para la codificación CBEFF de un elemento DG3 interfuncionable con dos imágenes de huellas digitales.)
Tabla 52. Codificación de más de un caso
Nota.— ISO/IEC 39794 sustituirá a ISO/IEC 19794:2005 como norma internacional para la codificación biométrica. Véase la sección 4.5.6.
4.7.4 GRUPO DE DATOS 4 — Elementos de identificación adicionales — Iris (OPCIONAL)
La OACI reconoce que los Estados miembros pueden optar por utilizar el reconocimiento de iris como tecnología biométrica adicional para apoyar la confirmación mecánica de la identidad, que SE CODIFICARÁ como Grupo de datos 4
(DG4).
Tabla 53. Rótulos del Grupo de datos 4
4.7.4.1 Codificación biométrica de EF.DG4
El DG4 DEBE utilizar la plantilla de grupo de plantillas de información biométrica (BIT) con los BITS anidados que se especifican en [ISO/IEC 7816-11], para tener la posibilidad de almacenar múltiples plantillas biométricas que se correspondan con el CBEFF. El subencabezamiento biométrico define el tipo de característica biométrica presente y la característica biométrica específica. La opción anidada de ISO/IEC [7816-11] DEBE utilizarse, incluso para codificaciones de una única plantilla biométrica. Este último caso se indica numerando con n = 1. El número de casos en el DG4 puede ser ‘0…n’.
(El DG4 DEBE utilizar la plantilla de grupo de plantilla de información biométrica (BIT = Biometric Information Template) con los BITS alojados que se describen en [ISO/IEC 7816-11], para tener la posibilidad de almacenar múltiples plantillas biométricas que se correspondan con el CBEFF (Common Biometric Exchange Format Framework = Marco común de formatos de intercambio biométrico). El subencabezamiento biométrico define el tipo de característica biométrica presente y la característica biométrica concreta. La opción alojada de ISO/IEC [7816-11] DEBE utilizarse, incluso para codificaciones de una única plantilla biométrica. Este último caso se indica numerando con n = 1. El número de casos en DG4 puede ser ‘0…n’.)
Cada plantilla anidada tiene la estructura siguiente:
(Cada plantilla alojada tiene la estructura siguiente:)
Tabla 54. Rótulos anidados del Grupo de datos 4
Se utiliza el OID de CBEFF por defecto. El objeto de datos OID (Rótulo ‘06’) en la plantilla de información biométrica (BIT, rótulo ‘7F60’) especificado en [ISO/IEC 7816-11] no se incluye en esta estructura. Análogamente, la autoridad de asignación de rótulo no se especifica en la estructura.
(Se utiliza el OID (Object Identifier = Identificador de objeto) de CBEFF preestablecido. El objeto de datos OID (rótulo ‘06’) en la plantilla de información biométrica (BIT, rótulo ‘7F60’) descrito en [ISO/IEC 7816-11] no se incluye en esta estructura. Similarmente, la autoridad de asignación de rótulos no se incluye en la estructura.)
Para facilitar la interoperabilidad, la primera característica biométrica registrada en cada grupo de datos SE CODIFICARÁ con arreglo a [ISO/IEC19794-5].
(Para facilitar el interfuncionamiento, la primera característica biométrica registrada en cada grupo de datos SE CODIFICARÁ de acuerdo con [ISO/IEC19794-5].)
Nota.— ISO/IEC 39794 sustituirá a ISO/IEC 19794:2005 como norma internacional para la codificación biométrica. Véase la sección 4.5.6.
4.7.4.2 GRUPO DE DATOS 4 — Datos EF.DG4
En esta sección se describen los datos que pueden estar presentes en el Grupo de datos 4 (DG4). Los datos y su formato dentro del grupo de datos SERÁN los que se indican en la tabla siguiente:
Nota.— 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.
Tabla 55. Elementos de datos para DG4
4.7.4.2.1 Codificación del subtipo de datos biométricos
Los rótulos de la plantilla de encabezamiento biométrico y sus valores asignados son los mínimos que cada implementación ADMITIRÁ, como se indica en la tabla siguiente. Cada plantilla de información biométrica individual tiene la estructura siguiente:
Tabla 56. Plan para la codificación de subcaracterísticas: CBEFF
4.7.4.2.2 Codificación de cero casos
Los Estados que no expiden LDS1 de eMRTD con datos de iris NO DEBERÍAN rellenar el DG4. El DG4 de esta estructura presenta el inconveniente de que resultará en una condensación estática del DG4 en el SOD para todas las LDS1 de eMRTD donde los datos biométricos no están presentes y no se rellenan en el momento de expedición de la LDS1 del eMRTD pero se ha declarado el DG4. Para fines de interoperabilidad, los Estados que apoyan el reconocimiento de iris en sus LDS1 del eMRTD DEBEN almacenar una plantilla del grupo de información biométrica vacía en los casos en que no se disponga de datos de iris en el momento de expedición de la LDS! del eMRTD. En este caso, el contador de la plantilla indica un valor de ‘00’.
(Los Estados que no emiten LDS1 (Logical Data Structure = Estructura lógica de datos) de eMRTD (Electronic Machine Readable Travel Document = Documento de viaje de lectura mecánica electrónico) con datos de iris NO DEBERÍAN rellenar el DG4. El DG4 de esta estructura presenta el inconveniente de que resultará en una condensación estática del DG4 en el SOD (Document Security Object = Objeto de seguridad de documento) para todas las LDS1 de eMRTD donde los datos biométricos no están presentes y no se rellenan en el momento de puesta en circulación de la LDS1 del eMRTD pero se ha declarado el DG4. Para fines de interfuncionamiento, los Estados que apoyan el reconocimiento de iris en sus LDS1 del eMRTD DEBEN almacenar una plantilla del grupo de información biométrica vacía en los casos en que no se disponga de datos de iris en el momento de la puesta en circulación de la LDS1 del eMRTD. En este caso, el contador de la plantilla indica un valor de ‘00’.)
Se RECOMIENDA añadir el rótulo ‘53’ con contenido definido por el expedidor (p. ej., un número aleatorio).
Tabla 57. Codificación de cero casos
4.7.4.2.3 Codificación de un caso
En los casos en que solo se dispone de un iris, DEBE codificarse el caso único.
4.7.4.2.4 Codificación de más de un caso
Para lograr la interoperabilidad, cada característica DEBE almacenarse en una plantilla de información biométrica individual. La posición de la característica DEBE especificarse dentro del subtipo de característica biométrica CBEFF si se dispone de esa información.
(Para lograr el interfuncionamiento, cada característica DEBE almacenarse en una plantilla de información biométrica individual. La posición de la característica DEBE describirse dentro del subtipo de característica biométrica CBEFF si se dispone de esa información.)
4.7.5 GRUPO DE DATOS 5 — Retrato exhibido (OPCIONAL)
Los elementos de datos asignados al grupo de datos 5 (DG5) SERÁN los siguientes:
Tabla 58. Rótulos del grupo de datos 5
Se reconocen los siguientes propietarios de formato para el tipo de imagen exhibida especificado.
(Se reconocen los siguientes propietarios de modelo para el tipo de imagen mostrada concreto.)
Tabla 59. Formatos DG5
4.7.5.1 GRUPO DE DATOS 5 — Datos de EF.DG5 (Opcional)
En esta sección se describen los datos que pueden estar presentes en el Grupo de datos 5 (DG5). Los datos y su formato dentro del DG5 SERÁN los que se indican en la tabla siguiente:
Nota.— 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.
Tabla 60. Elementos de datos para DG5
Nota.— El dato 02 se REGISTRARÁ como se define en [ISO/IEC 10918], utilizando la opción JFIF o la [ISO/IEC 15444] utilizando el sistema de codificación de imágenes JPEG 2000.
4.7.6 GRUPO DE DATOS 6 — Reservado para uso futuro
Los elementos de datos asignados al grupo de datos 6 (DG6) SERÁN los siguientes:
Tabla 61. Rótulos del Grupo de datos 6
4.7.6.1 GRUPO DE DATOS 6 — Elementos de datos de EF.DG6
Los elementos de datos para el DG6 se reservan para uso futuro.
4.7.7 GRUPO DE DATOS 7 — Firma o marca habitual exhibida (OPCIONAL)
Los elementos de datos asignados al grupo de datos 7 (DG7) SERÁN los siguientes:
Tabla 62. Rótulos del Grupo de datos 7
Se reconocen los siguientes propietarios de formatos para el tipo de imagen exhibida especificado:
Tabla 63. Formatos de DG7
4.7.7.1 GRUPO DE DATOS 7 — Datos de EF.DG7 (OPCIONAL)
En esta sección se describen los datos que pueden estar presentes en el Grupo de datos 7 (DG7). Los datos y su formato dentro del DG7 SERÁN los que se indican en la tabla siguiente:
Nota.— 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.
Tabla 64. Elementos de datos para DG7
Nota.— El dato 02 SE CODIFICARÁ según se define en [ISO/IEC 10918], utilizando la opción JFIF, o en [ISO/IEC 15444] utilizando el sistema de codificación de imágenes JPEG 2000.
4.7.8 GRUPO DE DATOS 8 — Elemento datos (OPCIONAL)
Este grupo de datos no se ha definido aún. Hasta entonces, los datos están disponibles para uso patentado temporario. Estos datos podrían utilizar una estructura similar a la de plantillas biométricas, verificación mecánica de elementos de
seguridad y detalles codificados. Los datos que se combinan para formar el Grupo de datos 8 (DG8) SERÁN los siguientes:
(Este grupo de datos no se ha definido aún. Hasta entonces, los datos están disponibles para uso patentado temporal. Estos datos podrían utilizar una estructura similar a la de plantillas biométricas, comprobación mecánica de elementos de seguridad y detalles codificados. Los datos que se combinan para formar el Grupo de datos 8 (DG8) SERÁN los siguientes:)
Tabla 65. Rótulos del Grupo de datos 8
4.7.8.1 GRUPO DE DATOS 8 — Datos del EF.DG8
En esta sección se describen los datos que pueden estar presentes en el DG8. Los datos y su formato dentro del grupo de datos SERÁN los que se indican en la tabla siguiente:
Nota.— 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.
Tabla 66. Elementos de datos para DG8
4.7.9 GRUPO DE DATOS 9 — Elemento estructura (OPCIONAL)
Este grupo de datos no se ha definido aún. Hasta entonces, los datos están disponibles para uso patentado temporario. Estos datos podrían utilizar una estructura similar a la de plantilla biométrica. Los datos que se combinan para formar el Grupo de datos 9 (DG9) SERÁN los siguientes:
(Este grupo de datos no se ha definido aún. Hasta entonces, los datos están disponibles para uso patentado temporal. Estos datos podrían utilizar una estructura similar a la de plantilla biométrica. Los datos que se combinan para formar el Grupo de datos 8 (DG8) SERÁN los siguientes:)
Tabla 67 Rótulos del Grupo de datos 9
4.7.9.1 GRUPO DE DATOS 9 — Datos de EF.DG9
Los elementos de datos del DG9 y su formato dentro del grupo de datos SERÁN los que se indican en la tabla siguiente:
Nota.— 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.
Tabla 68. Datos para DG9
4.7.10 GRUPO DE DATOS 10 — Elemento substancia (OPCIONAL)
Este grupo de datos no se ha definido aún. Hasta entonces, los datos están disponibles para uso patentado temporario. Estos datos podrían utilizar una estructura similar a la de las plantillas biométricas. Los datos que se combinan para formar el Grupo de datos 10 (DG10) SERÁN los siguientes:
(Este grupo de datos no se ha definido aún. Hasta entonces, los datos están disponibles para uso patentado temporal. Estos datos podrían utilizar una estructura similar a la de las plantillas biométricas. Los datos que se combinan para formar el Grupo de datos 10 (DG10) SERÁN los siguientes:)
Tabla 69. Rótulos de Grupo de datos 10
4.7.10.1 GRUPO DE DATOS 10 — Datos de EF.DG10
En esta sección se describen los datos que pueden estar presentes en el DG10. Los datos y su formato dentro del grupo de datos SERÁN los que se indican en la tabla siguiente:
Nota.— 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.
Tabla 70. Elementos de datos para DG10
4.7.11 GRUPO DE DATOS 11 — Detalles personales adicionales (OPCIONAL)
Este grupo de datos se utiliza para detalles adicionales respecto al titular del documento. Dado que todos los datos del grupo son opcionales, se utiliza una lista de rótulos para definir los que están presentes. Los datos que se combinan para formar el Grupo de datos 11 (DG11) SERÁN los siguientes:
Nota.— Esta plantilla puede contener caracteres no latinos.
(Nota.— Esta plantilla puede incluir caracteres no latinos.)
Tabla 71. Rótulos del Grupo de datos 11
4.7.11.1 GRUPO DE DATOS 11 — Datos de EF.DG11
En esta sección se describen los datos que pueden estar presentes en el DG11. Los datos y su formato dentro del grupo de datos SERÁN los que se indican en la tabla siguiente:
Nota 1.— El DG11 se CODIFICARÁ según se define en [ISO/IEC 10918], utilizando la opción JFIF o en la [ISO/IEC 15444] utilizando el sistema de codificación de imágenes JPEG 2000.
Nota 2.— 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.
Tabla 72. Datos para DG11
Dato | Opcional u OBLIGATORIO | Nombre del dato | Núm. de bytes | Fijo o variable | Tipo de codificación | Requisitos de codificación |
| 0 1 | O | Nombre del titular (completo) | 99 Máx | Var | B | Caracteres de relleno (<) incluidos para ZLM. No se incluyen caracteres de relleno al final de la línea. No se permite abreviación. |
| 0 2 | O | Otros nombres | 99 Máx | Var | B | Caracteres de relleno (<) incluidos para ZLM. No se incluyen caracteres de relleno al final de la línea. No se permite abreviación. |
| 0 3 | O | Número personal | 99 Máx | Var | U | Texto libre. |
| 0 4 | O | Fecha de nacimiento completa | 8 | F | N | AAAAMMDD |
| 0 5 | O | Lugar de nacimiento | 99 Máx | Var | U | Texto libre. |
| 0 6 | O | Dirección | 99 Máx | Var | U | Texto libre. |
| 0 7 | O | Teléfono | 99 Máx | Var | N, S | Texto libre. Se recomienda la codificación de acuerdo con ITU-T E.164. |
| 0 8 | O | Profesión | 99 Máx | Var | U | Texto libre. |
| 0 9 | M, si se incluye el elemento de dato 08 | Título | 99 Máx | Var | U | Texto libre. |
| 1 0 | M, si se incluye el elemento de dato 09 | Resumen personal | 99 Máx | Var | U | Texto libre. |
| 1 1 | M, si se incluye el elemento de dato 10 | Prueba de ciudadanía | Var | B | Imagen del documento de ciudadanía formateado según [ISO/IEC 10918-1] | |
| 1 2 | O | Otros documentos de viaje válidos Número de documento de viaje | 99 Máx | Var | U | Texto libre, separado por <. |
| 1 3 | O | Información de custodia | 999 Máx | Var | U | Texto libre. |
Nota.— Si se desconoce el mes (MM) o el día (DD), la manera interfuncional de indicarlo en DG11 es poner los caracteres respectivos a ‘00’. Si se desconoce el siglo y el año (SSAA), la manera interfuncional de indicarlo en DG11 es poner los caracteres respectivos a ‘0000’. Las fechas asignadas por el expedidor DEBEN siempre utilizarse en forma coherente.
4.7.12 GRUPO DE DATOS 12 — Detalles del documento adicionales (OPCIONAL)
Este grupo de datos se utiliza para información adicional sobre el documento. Todos los datos de este grupo son opcionales.
Tabla 73. Rótulos del Grupo de datos 12
Se RECOMIENDA que los sistemas de inspección apoyen la codificación ASCII de 8 bytes y la BCD de fecha/hora.
4.7.12.1 GRUPO DE DATOS 12 — Datos de EF.DG12
En esta sección se describen los datos que pueden estar presentes en el Grupo de datos 12 (DG12). Los datos y su formato dentro del grupo de datos SERÁN los que se indican en la tabla siguiente:
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.— Los datos 07 y 08 SE CODIFICARÁN según se define en [ISO/IEC 10918], utilizando la opción JFIF o en la [ISO/IEC 15444] utilizando el sistema de codificación de imágenes JPEG 2000.
Tabla 74. Datos para DG12
4.7.13 GRUPO DE DATOS 13 — Detalles opcionales (OPCIONAL)
Los datos que se combinan para formar el Grupo de datos 13 (DG13) quedan a discreción del Estado expedidor u organización expedidora y SERÁN los siguientes:
(Los datos que se unen para formar el Grupo de datos 13 (DG13) quedan a elección del Estado emisor u organización emisora y SERÁN los siguientes:)
Tabla 75. Rótulos del Grupo de datos 13
4.7.14 GRUPO DE DATOS 14 — Opciones de seguridad (CONDICIONAL)
El grupo de datos 14 (DG14) contiene opciones de seguridad para mecanismos de seguridad adicionales. Para más detalles véase el Doc 9303-11. El fichero DG14 contenido en la aplicación del eMRTD se EXIGE si la autenticación de la microplaqueta o PACE-GM/-IM es admitido por la microplaqueta del eMRTD.
(El grupo de datos 14 (DG14) incluye opciones de seguridad para mecanismos de seguridad adicionales. Para más detalles véase el Doc 9303-11. El fichero DG14 incluido en la aplicación del eMRTD se EXIGE si la autenticación de la microplaqueta o PACE-GM/-IM es admitido por la microplaqueta del eMRTD.)
Tabla 76. Rótulos del gupo de datos 14
4.7.14.1 GRUPO DE DATOS 14 — Datos de EF.DG14
En esta sección se describen los datos que pueden estar presentes en el DG14. Los datos y su formato dentro del grupo de datos SERÁN los que se indican en la tabla siguiente:
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.
Tabla 77. Elementos de datos para DG14
4.7.14.2 GRUPO DE DATOS 14 — Datos de SecurityInfos
Los siguientes datos SecurityInfos de la estructura genérica de datos ASN.1 permiten varias formas de implantación de opciones de seguridad para datos biométricos secundarios. Por razones de interfuncionamiento, se RECOMIENDA que esta estructura de datos se proporcione por la microplaqueta eMRTD en el DG14 para indicar los protocolos de seguridad apoyados. La estructura de datos se especifica como sigue:
(Los siguientes datos SecurityInfos de la estructura genérica de datos ASN.1 posibilitan varias formas de instalación de opciones de seguridad para datos biométricos secundarios. Por razones de interfuncionamiento, se RECOMIENDA que esta estructura de datos se facilite por la microplaqueta eMRTD en el DG14 para indicar los protocolos de seguridad apoyados. La estructura de datos se describe como sigue:)
SecurityInfos : := SET of SecurityInfo
SecurityInfo : := SEQUENCE {
protocol OBJECT IDENTIFIER,
requiredData ANY DEFINED BY protocol,
optionalData ANY DEFINED BY protocol OPTIONAL
}
Los elementos contenidos en una estructura de datos SecurityInfo tienen el significado siguiente:
(Los elementos incluidos en una estructura de datos SecurityInfo tienen el significado siguiente:)
• El protocolo identificador de objeto identifica al protocolo apoyado;
• El elemento requiredData de tipo abierto contiene datos obligatorios específicos del protocolo;
(El elemento requiredData de tipo abierto incluye datos obligatorios propios del protocolo;)
• El elemento optionalData de tipo abierto contiene datos opcionales específicos del protocolo.
(El elemento optionalData de tipo abierto incluye datos opcionales propios del protocolo.)
4.7.15 GRUPO DE DATOS 15 — Información de clave pública de autenticación activa (CONDICIONAL)
Este Grupo de datos OPCIONAL contiene la clave pública de autenticación active y se EXIGE cuando se implanta la autenticación opcional de microplaqueta de autenticación activa como se describe en el Doc 9303-11.
(Este Grupo de datos OPCIONAL incluye la clave pública de autenticación activa y se EXIGE cuando se instala la autenticación opcional de microplaqueta de autenticación activa como se describe en el Doc 9303-11.)
Tabla 78. Rótulos del Grupo de datos 15
4.7.15.1 GRUPO DE DATOS 15 — Datos de EF.DG15
En esta sección se describen los datos que pueden estar presentes en el Grupo de datos 15 (DG15). Los datos y su formato dentro del grupo de datos SERÁN los que se indican en la tabla siguiente:
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.
Tabla 79. Datos para DG15
4.7.16 GRUPO DE DATOS 16 — Personas que han de notificarse (OPCIONAL)
Este grupo de datos contiene información de notificación de emergencia. Está codificado como serie de plantillas con la designación de Rótulo ‘Ax’. El grupo de datos 16 (DG16) (como todos los otros grupos de datos) no DEBERÍA actualizarse después de la expedición; el DG16 se representa mediante un valor de condensación en el SOD y el SOD solo se firma una vez en la expedición.
(Este grupo de datos incluye información de notificación de emergencia. Está codificado como serie de plantillas con la designación de Rótulo ‘Ax’. El grupo de datos 16 (DG16) (como todos los otros grupos de datos) no DEBERÍA actualizarse después de la emisión; el DG16 se representa mediante un valor de condensación en el SOD (Document Security Object = Objeto de seguridad de documento) y el SOD solo se firma una vez en la emisión.)
Tabla 80. Rótulos del Grupo de datos 16
4.7.16.1 GRUPO DE DATOS 16 — Elementos de datos de EF.DG16
En esta sección se describen los datos que pueden estar presentes en el DG16. Los datos y su formato dentro del grupo de datos SERÁN los que se indican en la tabla siguiente:
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.
Tabla 81. Datos para DG16
Dato | Opcional u OBLIGATORIO | Nombre del elemento del dato | Núm. de bytes | Fijo o variable | Tipo de codificación | Requisitos de codificación |
| 0 3 | M, si se incluye DG16 | Número de personas a notificar. Identificadores primarios y secundarios | Var | A, N, S | Caracteres de relleno (<) incluidos como en la ZLM. No se permite abreviación. | |
| 0 4 | M, si se incluye DG16 | Número telefónico de la persona que ha de notificarse | Var | N, S | Número telefónico en forma internacional (código de país y número local). Se recomienda la codificación de acuerdo con ITU-T E.164. | |
| 0 5 | M | Dirección de la persona que ha de notificarse | Var | U | Texto libre. |
(sigue el apartado 3 de la Parte 9 del Documento 9303)
Términos biométricos
Los términos siguientes se emplean en la identificación biométrica:
(Los términos siguientes se utilizan en la identificación biométrica:)
• “verificar” significa realizar un cotejo de uno a uno entre los datos biométricos ofrecidos obtenidos de la persona titular del eMRTD ahora y una plantilla biométrica creada cuando la persona titular fue inscrita en el sistema;
(“verificar” significa realizar una comparación de uno a uno entre los datos biométricos ofrecidos obtenidos de la persona titular del eMRTD ahora y una plantilla biométrica creada cuando la persona titular fue inscrita en el sistema;)
• “identificar” significa realizar una búsqueda de uno a uno entre los datos biométricos ofrecidos y un conjunto de plantillas que representan a todos los sujetos que han sido inscritos en el sistema.
La biometría puede utilizarse en la función de identificación para mejorar la calidad de la verificación de antecedentes realizada como parte del proceso de solicitud de pasaportes, visados u otros documentos de viaje y pueden utilizarse las características biométricas para establecer un cotejo positivo entre el documento de viaje y la persona que lo presenta.
(La biometría puede utilizarse en la función de identificación para mejorar la calidad de la comprobación de antecedentes realizada como parte del proceso de solicitud de pasaportes, visados u otros documentos de viaje y pueden utilizarse las características biométricas para establecer una comparación positiva entre el documento de viaje y la persona que lo presenta.)
Para los fines de esta parte, se aplican los términos y definiciones del vocabulario de biometría que figuran en la norma ISO/IEC 2382-37:2017.
3.2 Consideraciones fundamentales
Al especificar las aplicaciones biométricas para eMRTD, las consideraciones fundamentales son:
(Al describir las aplicaciones biométricas para eMRTD, las consideraciones fundamentales son:)
• Interfuncionamiento mundial — la necesidad crucial de especificar un sistema de empleo que se utilice en forma de interfuncionamiento universal;
(Interfuncionamiento mundial — la necesidad vital de concretar un sistema de uso que se utilice en forma de interfuncionamiento universal;)
• Uniformidad — la necesidad de minimizar mediante normas específicas, en la medida posible, las diferentes variaciones de solución que podrían introducir los Estados expedidores u organizaciones expedidoras;
(Uniformidad — la necesidad de minimizar mediante normas concretas, en la medida posible, las diferentes modificaciones de solución que podrían introducir los Estados emisores u organizaciones emisoras;)
• Fiabilidad técnica — la necesidad de proporcionar directrices y parámetros para asegurar que los Estados expedidores u organizaciones expedidoras introducen tecnologías que hayan demostrado brindar un elevado nivel de confianza desde el punto de vista de la confirmación de la identidad; y de que los Estados u organizaciones que lean datos codificados por otros Estados expedidores u organizaciones expedidoras puedan asegurarse de que los datos proporcionados son de calidad e integridad suficientes para permitir la verificación exacta en sus propios sistemas;
(Fiabilidad técnica — la necesidad de suministrar directrices y criterios para asegurar que los Estados emisores u organizaciones emisoras introducen tecnologías que hayan demostrado ofrecer un alto nivel de confianza desde el punto de vista de la confirmación de la identidad; y de que los Estados u organizaciones que lean datos codificados por otros Estados emisores u organizaciones emisooras puedan asegurarse de que los datos suministrados son de calidad e invariabilidad suficientes para posibilitar la comprobación exacta en sus propios sistemas;)
• Viabilidad — la necesidad de asegurar que las normas recomendadas pueden ponerse en práctica e implantarse por los Estados u organizaciones sin que tengan que introducir un conjunto de sistemas y equipos dispares a efectos de ajustarse a todas las posibles variaciones e interpretaciones de las normas;
(Viabilidad — la necesidad de asegurar que las normas recomendadas pueden ponerse en práctica e instalarse por los Estados u organizaciones sin que tengan que introducir un conjunto de sistemas y equipos diferentes con el fin de ajustarse a todas las posibles modificaciones e interpretaciones de las normas;)
• Durabilidad — el requisito de que los sistemas introducidos funcionarán durante la máxima vida útil recomendada de 10 años de un documento de viaje, y que las actualizaciones futuras serán compatibles retroactivamente.
(Durabilidad — el requisito de que los sistemas introducidos funcionarán durante la máxima vida útil recomendada de 10 años de un documento de viaje, y que las actualizaciones futuras serán compaginables con las anteriores.)
3.3 Procedimientos fundamentales con respecto a la biometría
Los componentes principales de un sistema biométrico son:
• Establecimiento de identidad — seguridad de que la identidad del inscrito se conoce sin dudas;
• Captación — adquisición de una muestra biométrica en bruto;
(Captación — obtención de una muestra biométrica sin tratar;)
• Extracción — conversión de los datos de la muestra biométrica en bruto a una forma intermedia;
(Extracción — transformación de los datos de la muestra biométrica sin tratar a una forma intermedia;)
• Creación de plantilla — conversión de los datos intermedios en plantilla;
(Creación de plantilla — transformación de los datos intermedios en plantilla;)
• Comparación — comparación con la información contenida en una plantilla de referencia almacenada.
(Comparación — comparación con la información incluida en una plantilla de referencia almacenada.)
Estos procesos involucran:
(Estos procesos conllevan:)
• El proceso de inscripción es la captura de una muestra biométrica en bruto. Se utiliza para cada nueva persona (posible titular de eMRTD) de la que se toman muestras de imágenes biométricas para almacenamiento. Este proceso de captación es la adquisición automática de la característica biométrica mediante un dispositivo de captación como un escáner de huellas digitales, un escáner fotográfico, una cámara para imágenes digitales de captación en vivo o una cámara de acercamiento del iris de captación en vivo. Cada dispositivo de captación requerirá ciertos criterios y procedimientos definidos para el proceso de captación — por ejemplo, una pose normalizada enfrentando directamente a la cámara para una captación del reconocimiento del rostro; las huellas digitales se captan en forma plana o por rodamiento; el iris se capta con los ojos completamente abiertos. La imagen resultante se comprime y luego se almacena para futura confirmación de identidad.
(El proceso de inscripción es la captura de una muestra biométrica sin tratar. Se utiliza para cada nueva persona (posible titular de eMRTD) de la que se toman muestras de imágenes biométricas para almacenamiento. Este proceso de captación es la obtención automática de la característica biométrica mediante un dispositivo de captación como un escáner de huellas digitales, un escáner fotográfico, una cámara para imágenes digitales de captación en vivo o una cámara de acercamiento del iris de captación en vivo. Cada dispositivo de captación exigirá ciertos criterios y procedimientos definidos para el proceso de captación — por ejemplo, una pose normalizada enfrentando directamente a la cámara para una captación del reconocimiento del rostro; las huellas digitales se captan en forma plana o por rodamiento; el iris se capta con los ojos completamente abiertos. La imagen resultante se comprime y luego se almacena para futura confirmación de identidad.)
• El proceso de creación de plantillas conserva las características biométricas distintivas y repetibles de la imagen biométrica captada y en general se efectúa con un algoritmo de soporte lógico patentado para extraer una plantilla de la imagen almacenada. Esto define la imagen en una forma que pueda compararse posteriormente con otra imagen de muestra captada en el momento en que se requiera la confirmación de identidad y una determinada medida de comparación. Inherente a este algoritmo es el control de calidad, por el cual, mediante cierto mecanismo, se establece la calidad de la muestra. Las normas de calidad deben ser lo más elevadas posibles dado que todas las verificaciones futuras dependen de la calidad de la imagen captada originalmente. Si la calidad no es aceptable, el proceso de captación debería repetirse.
(El proceso de creación de plantillas guarda las características biométricas diferenciadoras y repetibles de la imagen biométrica captada y en general se efectúa con un algoritmo de programa informático patentado para extraer una plantilla de la imagen almacenada. Esto define la imagen en una forma que pueda compararse posteriormente con otra imagen de muestra captada en el momento en que se necesite la confirmación de identidad y una determinada medida de comparación. Propio de este algoritmo es el control de calidad, por el cual, mediante cierto mecanismo, se establece la calidad de la muestra. Las normas de calidad deben ser lo más rigurosas posibles dado que todas las comprobaciones futuras dependen de la calidad de la imagen captada inicialmente. Si la calidad no es aceptable, el proceso de toma debería repetirse.)
• El proceso de identificación toma la plantilla obtenida de la nueva muestra y la compara con las plantillas almacenadas de los usuarios finales inscritos para determinar si el usuario final ha ingresado en el sistema anteriormente y, de ser así, si lo ha hecho con la misma identidad.
• El proceso de verificación toma las nuevas muestras de una persona titular de eMRTD y las compara con una plantilla obtenida de la imagen almacenada de dicho portador para determinar si éste presenta la misma identidad.
3.4 Aplicaciones para una solución biométrica
La aplicación fundamental de una solución biométrica es la verificación de la identidad para relacionar a una persona titular de eMRTD con el eMRTD del que es portador/a.
(La aplicación fundamental de una solución biométrica es la comprobación de la identidad para relacionar a una persona titular de eMRTD con el eMRTD del que es portador/a.)
Existen varias aplicaciones típicas para las características biométricas durante el proceso de inscripción en la solicitud de un eMRTD.
Los datos biométricos del usuario final generados en el proceso de inscripción pueden utilizarse en una búsqueda en una o más bases de datos biométricos (identificación) para determinar si el usuario final es conocido de algunos de los sistemas correspondientes (p. ej., titular de un eMRTD con identidad diferente, antecedentes delictivos, titular de un eMRTD de otro Estado u organización).
Cuando los/as usuarios/as finales recogen el eMRTD (o se presentan para alguna de las etapas del proceso de expedición después de la solicitud inicial y la captación de datos biométricos) sus datos biométricos pueden tomarse nuevamente y verificarse con respecto a los datos biométricos captados inicialmente.
(Cuando los/as usuarios/as finales recogen el eMRTD (o se presentan para alguna de las etapas del proceso de emisión después de la solicitud inicial y la captación de datos biométricos) sus datos biométricos pueden tomarse nuevamente y comprobarse con respecto a los datos biométricos tomados inicialmente.)
Las identidades del personal encargado de la inscripción pueden verificarse para confirmar que tienen autoridad para realizar las tareas asignadas. Esto puede incluir la autenticación biométrica para iniciar la firma digital de registros de auditoría en las diversas etapas del proceso de expedición, permitiendo realizar un enlace biométrico entre los miembros del personal y las actividades bajo su responsabilidad.
(Las identidades del personal encargado de la inscripción pueden comprobarse para confirmar que tienen autoridad para realizar las tareas asignadas. Esto puede incluir la autenticación biométrica para iniciar la firma digital de registros de auditoría en las diversas etapas del proceso de emisión, posibilitando realizar un enlace biométrico entre los miembros del personal y las actividades bajo su responsabilidad.)
Existen también varias aplicaciones típicas de la biometría en las fronteras.
Cada vez que un/a viajero/a (es decir, una persona titular de eMRTD) ingresa a un Estado o sale de un Estado, su identidad puede verificarse con respecto a la imagen creada cuando se expidió su documento de viaje. Esto asegurará que el portador de un documento es la persona legítima a la cual se ha expedido dicho documento y mejorará la eficacia de todo sistema de información anticipada sobre los pasajeros (API). El Estado expedidor u organización expedidora puede encontrar conveniente almacenar la plantilla o plantillas biométricas en el documento de viaje junto con la imagen, de modo que la identidad del viajero pueda verificarse en lugares del interior donde el sistema biométrico esté bajo el control del expedidor.
(Cada vez que un/a viajero/a (es decir, una persona titular de eMRTD) entra en un Estado o sale de un Estado, su identidad puede comprobarse con respecto a la imagen creada cuando se emitió su documento de viaje. Esto asegurará que el portador de un documento es la persona legítima a la cual se ha emitido dicho documento y mejorará la eficacia de todo sistema de información anticipada sobre los pasajeros (API). El Estado emisor u organización emisora puede encontrar conveniente almacenar la plantilla o plantillas biométricas en el documento de viaje junto con la imagen, de modo que la identidad del viajero pueda comprobarse en lugares del interior donde el sistema biométrico esté bajo el control del emisor.)
Verificación en ambos sentidos — Los datos actuales de la imagen biométrica captada de la persona que viaja y los datos biométricos de su documento de viaje (o de una base de datos central) pueden cotejarse (si corresponde construyendo plantillas biométricas de cada uno) para confirmar que el documento de viaje no ha sido alterado.
(Comprobación en ambos sentidos — Los datos actuales de la imagen biométrica captada de la persona que viaja y los datos biométricos de su documento de viaje (o de una base de datos central) pueden compararse (si corresponde construyendo plantillas biométricas de cada uno) para confirmar que el documento de viaje no ha sido modificado.)
Verificación en tres sentidos — Los datos actuales de la imagen biométrica captada de la persona que viaja, los datos biométricos de su documento de viaje y los datos biométricos almacenados en la base de datos central pueden cotejarse (si corresponde, construyendo plantillas biométricas de cada uno) para confirmar que el documento de viaje no ha sido alterado. Esta técnica compara a la persona con su eMRTD y con la base de datos que registra los datos ingresados en el eMRTD en el momento de su expedición.
(Comprobación en tres sentidos — Los datos actuales de la imagen biométrica captada de la persona que viaja, los datos biométricos de su documento de viaje y los datos biométricos almacenados en la base de datos central pueden compararse (si corresponde, construyendo plantillas biométricas de cada uno) para confirmar que el documento de viaje no ha sido modificado. Esta técnica compara a la persona con su eMRTD y con la base de datos que registra los datos incluidos en el eMRTD en el momento de su emisión.)
Verificación en cuatro sentidos — Una cuarta verificación confirmatoria, aunque no de carácter electrónico, consiste en cotejar visualmente los resultados de la verificación en tres sentidos con la fotografía digitalizada en la página de datos del eMRTD del viajero.
(Comprobación en cuatro sentidos — Una cuarta comprobación confirmatoria, aunque no de carácter electrónico, consiste en comparar visualmente los resultados de la comprobación en tres sentidos con la fotografía digitalizada en la página de datos del eMRTD del viajero.)
Además de las aplicaciones de inscripción y seguridad fronteriza de la biometría, manifestadas en los cotejos de uno a uno y de uno a varios, los Estados y organizaciones también deberían considerar y establecer sus propios criterios con respecto a:
(Además de las aplicaciones de inscripción y seguridad fronteriza de la biometría, manifestadas en las comparaciones de uno a uno y de uno a varios, los Estados y organizaciones también deberían valorar y establecer sus propios criterios con respecto a:)
• La exactitud de las funciones de cotejo biométrico del sistema. Los Estados expedidores u organizaciones expedidoras deben codificar una o más características biométricas del rostro, huellas digitales o iris en el eMRTD con arreglo a las especificaciones de la LDS. (También pueden almacenarse en una base de datos accesible al Estado receptor u organización receptora). Una vez recibida una imagen biométrica normalizada por la OACI, los Estados receptores u organizaciones receptoras deben escoger su propio soporte lógico de verificación biométrica y determinar sus propios umbrales de resultados biométricos para las proporciones de aceptación de la verificación de identidad y la identificación de impostores.
(La exactitud de las funciones de comparación biométrica del sistema. Los Estados emisores u organizaciones emisoras deben codificar una o más características biométricas del rostro, huellas digitales o iris en el eMRTD de acuerdo con las determinaciones de la LDS (Logical Data Structure = Estructura lógica de datos). (También pueden almacenarse en una base de datos accesible al Estado receptor u organización receptora). Una vez recibida una imagen biométrica normalizada por la OACI, los Estados receptores u organizaciones receptoras deben escoger su propio programa informático de comprobación biométrica y determinar sus propios márgenes de resultados biométricos para las proporciones de aceptación de la comprobación de identidad y la identificación de impostores.)
• El rendimiento (p. ej., viajeros por minuto) del sistema biométrico o del sistema de cruce de frontera en su totalidad.
• Adecuación de una determinada tecnología biométrica (rostro o dedo u ojo) a la aplicación de cruce de frontera.
3.5 Limitaciones de las soluciones biométricas
Se reconoce que la implantación de la mayoría de las tecnologías biométricas es susceptible de desarrollo ulterior. Considerando la rapidez de los cambios tecnológicos, toda especificación (incluyendo las de este volumen) debe tener en cuenta y reconocer que habrá cambios resultantes de las mejoras tecnológicas.
(Se reconoce que la instalación de la mayoría de las tecnologías biométricas es capaz de desarrollo posterior. Considerando la rapidez de los cambios tecnológicos, toda determinación (incluyendo las de este volumen) debe tener en cuenta y reconocer que habrá cambios resultantes de las mejoras tecnológicas.)
La información biométrica almacenada en los documentos de viaje se ajustará a todas las leyes nacionales de protección de datos o a las leyes de confidencialidad del Estado expedidor u organización expedidora.
(La información biométrica almacenada en los documentos de viaje se ajustará a todas las leyes nacionales de protección de datos o a las leyes de confidencialidad del Estado emisor u organización emisora.)