7.1 La PKI del eMRTD
Los Estados expedidores u organizaciones expedidoras DEBEN expedir certificados y CRL que se ajusten a los perfiles especificados a continuación. Todos los certificados y CRL DEBEN producirse en formato de regla de codificación distinguida (DER) para conservar la integridad de las firmas en ellos. Los perfiles para certificados CSCA y DS que se incluyeron en la sexta edición de estas especificaciones difieren en algunos aspectos de los perfiles actuales. Los sistemas de inspección DEBEN ser capaces de tramitar certificados que se expidieron con arreglo a esos perfiles anteriores (véase el apéndice C), así como con los perfiles actuales.
(Los Estados emisores u organizaciones emisoras DEBEN emitir certificados y CRL (Certificate Revocation List = Lista de revocación de certificados) que se ajusten a los perfiles concretados a continuación. Todos los certificados y CRL DEBEN producirse en formato de regla de codificación distinguida (DER = Distinguished Encoding Rule) para conservar la exactitud de las firmas en ellos. Los perfiles para certificados CSCA y DS (Document Signer = Firmante del documento) que se incluyeron en la sexta edición de estas determinaciones se diferencian en algunos aspectos de los perfiles actuales. Los sistemas de inspección DEBEN ser capaces de tramitar certificados que se emitieron de acuerdo con esos perfiles anteriores (véase el apéndice C), así como con los perfiles actuales.)
El Apéndice C de la Parte 12 del documento 9303 recoge:
Apéndice C de la Parte 12
PERFILES DE CERTIFICADO ANTERIORES
(INFORMATIVO)
Los perfiles de certificado de este apéndice se especificaron en la sexta edición del Doc 9303 de la OACI. Aunque las CSCA DEBEN expedir certificados que cumplan con los actuales perfiles según se especifica en la sección 7, los perfiles anteriores se incluyen aquí con fines de información solamente, dado que los certificados expedidos con arreglo a los perfiles anteriores estarán en circulación y serán procesados por los sistemas de inspección durante varios años más.
(Los perfiles de certificado de este apéndice se describieron en la sexta edición del Doc 9303 de la OACI. Aunque las CSCA DEBEN emitir certificados que cumplan con los actuales perfiles según se describe en la sección 7, los perfiles anteriores se incluyen aquí con fines de información solamente, dado que los certificados emitidos de acuerdo con los perfiles anteriores estarán en circulación y serán procesados por los sistemas de inspección durante varios años más.)
Tabla C-1. Cuerpo del certificado
Tabla C-2. Extensiones
(sigue la sección 7 de la Parte 12 del documento 9303)
Estos perfiles se basan en el requisito de que cada Estado expedidor u organización o entidad expedidora CREARÁ una CSCA única para la firma de todos los eMRTD que se ajusten al Doc 9303.
(Estos perfiles se basan en el requisito de que cada Estado emisor u organización o entidad emisora CREARÁ una CSCA única para la firma de todos los eMRTD que se ajusten al Doc 9303.)
Los perfiles de certificado se definen en la sección 7.1 para los siguientes tipos de certificados:
• CA de firma de país;
(CA (Certification Authority = Autoridad de certificación) de firma de país;
• firmante del documento;
• firmante de la lista maestra CSCA;
• firmante de la lista de desviaciones; y
• comunicaciones, aunque no se necesita estrictamente en la actualidad, ya que se trata de una futura etapa de prueba. Estos certificados pueden utilizarse para acceder al PKD o para comunicaciones LDAP/EMAIL/HTTP entre Estados. Se recomienda que estos certificados sean expedidos por la CSCA.
(comunicaciones, aunque no se necesita obligatoriamente en la actualidad, ya que se trata de una futura etapa de prueba. Estos certificados pueden utilizarse para acceder al PKD o para comunicaciones LDAP/EMAIL/HTTP entre Estados. Se recomienda que estos certificados sean emitidos por la CSCA.)
En la sección 3 se definen los objetos CA de firma de país, firmante del documento y firmante de la lista maestra CSCA.
El perfil de CRL se define en la sección 4.
Los perfiles emplean la terminología siguiente para los requisitos de presencia de cada una de los componentes o extensiones:
(Los perfiles utilizan la terminología siguiente para los requisitos de presencia de cada uno de los componentes o extensiones:)
m obligatorio — el campo DEBE estar presente;
x no utilizar — el campo NO DEBE estar presente;
o opcional — el campo PUEDE estar presente.
c condicional — el campo PODRÍA estar presente en determinadas condiciones.
Los perfiles emplean la terminología siguiente para los requisitos de criticidad de las extensiones que pueden o deben incluirse:
(Los perfiles utilizan la terminología siguiente para los requisitos de criticidad de las extensiones que pueden o deben incluirse:)
c crítico — las aplicaciones receptoras DEBEN poder procesar esta extensión;
nc no críticos — las aplicaciones receptoras que no comprendan esta extensión PUEDEN ignorarla.
Algunos de los requisitos identificados en estos perfiles son heredados de los perfiles de base de referencia (p. ej., RFC 5280). Para facilitar su consulta, el texto pertinente del perfil de base que abarca el requisito específico se reproduce en una tabla en el apéndice B.
El Apéndice B de la Parte 12 del documento 9303 recoge:
Apéndice B de la Parte 12
TEXTO DE REFERENCIA PARA PERFILES DE CERTIFICADO Y CRL
(INFORMATIVO)
Los perfiles de certificado y CRL que se definen en la sección 7 se basan en definiciones y requisitos de perfiles básicos especificados en los documentos de referencia. En las tablas siguientes se reproducen breves extractos de algunas secciones pertinentes de dichos documentos de referencia (en el momento de redactarse este apéndice). Estos extractos se proporcionan para ayudar al lector o lectora a comprender los antecedentes en algunos de los requisitos especificados en los perfiles de certificado eMRTD y CRL. No están previstos para basarse en ellos en vez de en los documentos de referencia. En todos los casos, para obtener la especificación completa del componente/extensión de referencia y para obtener la especificación más actual, DEBEN utilizarse los documentos de referencia propiamente dichos.
(Los perfiles de certificado y CRL (Certificate Revocation List = Lista de revocación de certificados) que se definen en la sección 7 se basan en definiciones y requisitos de perfiles básicos descritos en los documentos de referencia. En las tablas siguientes se reproducen breves extractos de algunas secciones relevantes de dichos documentos de referencia (en el momento de redactarse este apéndice). Estos extractos se facilitan para ayudar al lector o lectora a comprender los antecedentes en algunos de los requisitos descritos en los perfiles de certificado eMRTD (Electronic Machine Readable Travel Document = Documento de viaje de lectura mecánica electrónico) y CRL. No están establecidos para basarse en ellos en vez de en los documentos de referencia. En todos los casos, para obtener la determinación completa del componente/extensión de referencia y para obtener la determinación más actual, DEBEN utilizarse los documentos de referencia propiamente dichos.)
Tabla B-1. Campos y extensiones de certificado
| Componente/Extensión | Referencia | Extractos pertinentes |
| Certificate | RFC 5280 – 4.1.1 | |
| TBSCertificate | RFC 5280 – 4.1.1.1 | |
| signatureAlgorithm | RFC 5280 – 4.1.1.2 | |
| signatureValue | RFC 5280 – 4.1.1.3 | |
| TBSCertificate | RFC 5280 – 4.1.2 | |
| version | RFC 5280 – 4.1.2.1 | Cuando se utilicen extensiones, según se establece en este perfil, la versión DEBE ser 3 (el valor es 2). |
| serialNumber | RFC 5280 – 4.1.2.2 | El número de serie DEBE ser un entero positivo asignado por la CA (Autoridad de Certificación) a cada certificado. DEBE ser único para cada certificado emitido por una CA determinada (es decir, el nombre y el número de serie del emisor identifican un certificado único). Las CA DEBEN obligar que el serialNumber (número de serie) sea un entero no negativo. Dado los requisitos de uniformidad mencionados anteriormente, puede anticiparse que los números de serie incluyan enteros largos. Los usuarios de certificados DEBEN poder tramitar valores serialNumber de hasta 20 octetos. Las CA conformes NO DEBEN utilizar valores de serialNumber con longitudes mayores de 20 octetos. |
Tabla B-2. Campos y extensiones de CRL
(sigue la sección 7 de la Parte 12 del Documento 9303)
7.1.1 Perfiles de certificado
En la tabla 5 se definen los requisitos de perfil comunes a todos los certificados para los campos del cuerpo del certificado. En la tabla 6 se definen los requisitos para las extensiones de certificado.
Tabla 5. Perfil de campos del certificado
Tabla 6. Perfil de extensiones del certificado
Nota 1.— Por definición, la extensión solo puede aparecer en certificados CA intermedios (certificados expedidos por una CA a otra CA). Los certificados CA intermedios no se utilizan en la PKI del eMRTD. Por consiguiente, esta extensión está prohibida en los certificados eMRTD.
Nota 2.— La extensión de CRL más reciente se utiliza para indicar una CRL delta. Las CRL delta no se admiten en la PKI del eMRTD. Por consiguiente, esta extensión está prohibida.
Nota 3.— Hay dos extensiones Internet privadas (Authority Information Access y Subject Information Access) que se definen en RFC 5280 y se utilizan para indicar información sobre el expedidor o el sujeto de un certificado. Estas extensiones no se requieren en la PKI del eMRTD. No obstante, dado que no inciden en la interoperabilidad y no son críticas, pueden incluirse en forma opcional en los certificados eMRTD.
Nota 4.— La extensión de tipo de certificado Netscape puede utilizarse para limitar las finalidades para las cuales puede utilizarse un certificado. Las extensiones extKeyUsage y basicConstraints son ahora las extensiones estándar para esos fines y se utilizan en la aplicación del eMRTD. Debido al posible conflicto entre valores en las extensiones estándar y en la extensión propia Netscape, se prohíbe esta última.
7.1.1.1 Requisitos relativos a los campos Expedidor y Sujeto
Los campos Expedidor y Sujeto son comunes a todos los certificados, pero en los certificados de firmante LDS2 se aplican restricciones específicas.
(Los campos Expedidor y Sujeto son comunes a todos los certificados, pero en los certificados de firmante LDS2 se aplican limitaciones concretas.)
7.1.1.1.1 Requisitos generales
SE EXIGEN las siguientes convenciones de nombres y direcciones para los campos Issuer y Subject.
• countryName. DEBE estar presente. Este valor contiene un código de país que DEBE seguir el formato de código de país de dos letras especificado en el Doc 9303-3.
• commonName. DEBE estar presente.
También PUEDEN incluirse otros atributos a discreción del Estado expedidor u organización expedidora.
(También PUEDEN incluirse otras particularidades a elección del Estado emisor u organización emisora.)
7.1.1.1.2 Requisitos relativos a los certificados de firmante LDS2
Los certificados de firmante LDS2 DEBEN cumplir con el perfil de certificado de firmante del documento definido anteriormente, con las excepciones definidas en 7.1.2.
7.1.1.2 Requisitos relativos a los nombres alternativos de Expedidor y Sujeto
Debido a que las funciones servidas por nombres alternativos en la aplicación del eMRTD son específicas de esta aplicación y diferentes de las definidas para la PKI Internet en [RFC 5280], los valores en la extensión de nombres alternativos de sujeto de los certificados eMRTD no identifican por lo general en forma clara el sujeto del certificado.
(Debido a que las funciones efectuadas por nombres alternos en la aplicación del eMRTD son específicas de esta aplicación y diferentes de las definidas para la PKI Internet en [RFC 5280], los valores en la extensión de nombres alternos de sujeto de los certificados eMRTD no identifican por lo general en forma clara el sujeto del certificado.)
En la aplicación del eMRTD, los nombres alternativos sirven las dos funciones siguientes.
(En la aplicación del eMRTD, los nombres alternos efectúan las dos funciones siguientes.)
La primera función es proporcionar información de contacto para el sujeto o el expedidor del certificado. Para ese fin DEBERÍA incluir por lo menos uno de los siguientes:
(La primera función es suministrar información de contacto para el sujeto o el emisor del certificado. Para ese fin DEBERÍA incluir por lo menos uno de los siguientes:
• rfc822Name;
• dNSName; o
• uniformResourceIdentifier
La segunda función consiste en proporcionar una cadena de directorio integrada por códigos de país asignados por la OACI. Para este fin, los certificados expedidos utilizando este perfil DEBEN incluir además un nombre de directorio que se construye como sigue:
(La segunda función consiste en suministrar una cadena de directorio formada por códigos de país asignados por la OACI. Para este fin, los certificados emitidos utilizando este perfil DEBEN incluir además un nombre de directorio que se forma como sigue:)
• localityName que contiene el código de país de la OACI como aparece en la ZLM; y
(localityName que incluye el código de país de la OACI como figura en la ZLM; y)
• si este código de país no define unívocamente el Estado expedidor u organización expedidora, el atributo stateOrProvinceName SE UTILIZARÁ para indicar el código de tres letras asignado por la OACI para el Estado expedidor u organización expedidora.
(si este código de país no define inequívocamente el Estado emisor u organización emisora, la particularidad stateOrProvinceName SE UTILIZARÁ para indicar el código de tres letras asignado por la OACI para el Estado emisor u organización emisora.)
• No se permiten otros atributos.
(No se admiten otros atributos.)
En los certificados raíz autofirmados CSCA, las extensiones IssuerAltName y SubjectAltName DEBEN ser idénticas. En los certificados de enlace CSCA, los valores PUEDEN ser diferentes. Por ejemplo, si ha ocurrido un cambio en el rfc822Name de la CSCA inmediatamente antes de la expedición del certificado de enlace CSCA, la extensión IssuerAltName contendría el rfc822Name antiguo y la extensión SubjectAltName contendría el nuevo rfc822Name. Todo certificado de enlace CSCA subsiguiente contendría el nuevo rfc822Name en ambas extensiones.
(En los certificados raíz autofirmados CSCA, las extensiones IssuerAltName y SubjectAltName DEBEN ser idénticas. En los certificados de enlace CSCA, los valores PUEDEN ser diferentes. Por ejemplo, si ha ocurrido un cambio en el rfc822Name de la CSCA inmediatamente antes de la emisión del certificado de enlace CSCA, la extensión IssuerAltName incluiría el rfc822Name antiguo y la extensión SubjectAltName incluiría el nuevo rfc822Name. Todo certificado de enlace CSCA posterior incluiría el nuevo rfc822Name en ambas extensiones.)
7.1.1.3 Requisitos relativos a la extensión de uso de clave ampliado
El identificador de objeto (OID) que debe incluirse en la extensión extendedKeyUsage para los certificados de firmante de la lista maestra es 2.23.136.1.1.3.
El identificador de objeto (OID) que debe incluirse en la extensión extendedKeyUsage para los certificados de firmante de la lista de desviaciones es 2.23.136.1.1.8.
Para los certificados de comunicación, el valor de esta extensión depende del protocolo de comunicación que se utilice (véase RFC 5280, sección 4.2.1.12).
7.1.1.4 Requisitos relativos a la extensión de puntos de distribución de la CRL
Las CSCA pueden publicar sus CRL en varios lugares, incluyendo el PKD, su propio sitio web, etc.
Para las CRL que se publiquen en lugares distintos del PKD (p. ej., sitio web o servidor LDAP local), los valores que han de incluirse en esta extensión son controlados por la CSCA que expide los certificados y las CRL en cuestión.
(Para las CRL que se publiquen en lugares distintos del PKD (p. ej., sitio web o servidor LDAP local), los valores que han de incluirse en esta extensión son controlados por la CSCA que emite los certificados y las CRL respectivas.)
Para las CRL presentadas al PKD, los participantes en este directorio PUEDEN incluir dos valores URL para su CRL utilizando la plantilla siguiente (sustitúyase “CountryCode” por el código de tres letras de Estado expedidor u organización expedidora asignado por la OACI). Si este código de país no identifica unívocamente al Estado expedidor u organización expedidora, se creará la anotación adjuntando el símbolo “_” al código de país de tres letras en la ZLM, y luego el código de tres letras asignado por la OACI al Estado expedidor u organización expedidora que identifique unívocamente dicho Estado u organización:
(Para las CRL (Certificate Revocation List = Lista de revocación de certificados) presentadas al PKD (Public Key Directory = Directorio de claves públicas), los participantes en este directorio PUEDEN incluir dos valores URL para su CRL utilizando la plantilla siguiente (sustitúyase “CountryCode” por el código de tres letras de Estado emisor u organización emisora asignado por la OACI). Si este código de país no identifica inequívocamente al Estado emisor u organización emisora, se creará la anotación adjuntando el símbolo “_” al código de país de tres letras en la ZLM (Zona de Lectura Mecánica), y luego el código de tres letras asignado por la OACI al Estado emisor u organización emisora que identifique inequívocamente dicho Estado u organización:)
https://pkddownload1.icao.int/CRLs/CountryCode.crl
https://pkddownload2.icao.int/CRLs/CountryCode.crl
Esta es una extensión obligatoria y la verificación del estado de revocación es una parte obligatoria del procedimiento de validación. Por consiguiente, DEBE rellenarse por lo menos un valor:
(Esta es una extensión obligatoria y la comprobación del estado de revocación es una parte obligatoria del procedimiento de aprobación. Por consiguiente, DEBE rellenarse por lo menos un valor:)
• Los valores del PKD pueden ser los únicos valores en la extensión;
• Puede haber valores adicionales (p. ej., una CSCA puede también optar por publicar sus CRL en un sitio web e incluir una referencia a esa fuente); o
• La CSCA también puede optar por influir solo un único valor (p. ej., una referencia a su sitio web como fuente), incluso si también presenta sus CRL al PKD.
(La CSCA también puede optar por incluir solo un único valor (p. ej., una referencia a su sitio web como fuente), incluso si también presenta sus CRL al PKD.)
En los siguientes ejemplos se ilustran los valores del PKD que se rellenarían en los certificados expedidos por la autoridad expedidora en los casos de Singapur y Hong Kong:
(En los siguientes ejemplos se ilustran los valores del PKD que se rellenarían en los certificados emitidos por la autoridad emisora en los casos de Singapur y Hong Kong:)
Ejemplo PKD en el caso de Singapur:
https://pkddownload1.icao.int/CRLs/SGP.crl
https://pkddownload2.icao.int/CRLs/SGP.crl
Ejemplo PKD en el caso de Hong Kong:
https://pkddownload1.icao.int/CRLs/CHN_HKG.crl
https://pkddownload2.icao.int/CRLs/CHN_HKG.crl
7.1.1.5 Extensión de cambio de nombre
Cuando tiene lugar una renovación de clave CSCA, DEBE expedirse un certificado que enlace la clave pública antigua con la nueva clave pública para proporcionar una transición segura a las partes que confían. En general, esto se logra mediante la expedición de un certificado autoexpedido donde los campos issuer y subject son idénticos pero la clave utilizada para verificar la firma representa el antiguo par de claves y la clave pública certificada representa el nuevo par de claves.
(Cuando tiene lugar una renovación de clave CSCA, DEBE emitirse un certificado que enlace la clave pública antigua con la nueva clave pública para facilitar una transición segura a las partes que confían. En general, esto se logra mediante la emisión de un certificado autoemitido donde los campos issuer y subject son idénticos pero la clave utilizada para comprobar la firma representa el antiguo par de claves y la clave pública certificada representa el nuevo par de claves.)
SE RECOMIENDA que las CSCA no cambien su nombre distinguido (DN) innecesariamente dado que ello tiene consecuencias adversas para las partes que confían (deben conservar tanto el antiguo nombre como el nuevo como CSCA válidas para el mismo Estado expedidor u organización expedidora hasta que todos los eMRP firmados con el nombre antiguo hayan caducado). No obstante, si es necesario efectuar un cambio de nombre, este DEBE comunicarse a las partes que confían mediante la expedición de un certificado de enlace CSCA donde el campo issuer contiene el nombre antiguo y el campo subject contiene el nuevo nombre. Este certificado de enlace CSCA también contiene una renovación de clave donde la clave utilizada para verificar la firma representa el antiguo para de claves y la clave pública certificada representa el nuevo par de claves. Los certificados que contienen un cambio de nombre de CSCA y una renovación de clave para dicha CSCA DEBEN incluir la extensión NameChange para identificar ese tipo de certificado. Esto no tiene consecuencias para PathLengthConstraint; el valor sigue siendo ‘0’.
(SE RECOMIENDA que las CSCA ( Country Signing Certification Authority = Autoridad de certificación de firma de país) no cambien su nombre distinguido (DN = Distinguished Name) innecesariamente dado que ello tiene consecuencias perjudiciales para las partes que confían (deben conservar tanto el antiguo nombre como el nuevo como CSCA válidas para el mismo Estado emisor u organización emisora hasta que todos los eMRP (Electronic Machine Readable Passport = Pasaporte de lectura mecánica electrónico) firmados con el nombre antiguo hayan caducado). Aun así, si es necesario efectuar un cambio de nombre, este DEBE comunicarse a las partes que confían mediante la emisión de un certificado de enlace CSCA donde el campo issuer incluye el nombre antiguo y el campo subject incluye el nuevo nombre. Este certificado de enlace CSCA también incluye una renovación de clave donde la clave utilizada para comprobar la firma representa el antiguo para de claves y la clave pública certificada representa el nuevo par de claves. Los certificados que incluyen un cambio de nombre de CSCA y una renovación de clave para dicha CSCA DEBEN incluir la extensión NameChange para identificar ese tipo de certificado. Esto no tiene consecuencias para PathLengthConstraint; el valor sigue siendo ‘0’.)
Además, la extensión NameChange también PUEDE incluirse en el nuevo certificado autofirmado CSCA creado tras el cambio del DN de la CSCA. En un certificado raíz CSCA autofirmado de ese tipo, tanto el campo issuer como el subject contienen el nuevo DN. A diferencia del certificado de enlace autofirmado CSCA que contienen el DN antiguo y el nuevo de la CSCA, la inclusión de la extensión NameChange en un certificado raíz autofirmado CSCA indica simplemente que ha ocurrido un cambio de nombre y no enlaza el DN antiguo con el nuevo.
(Además, la extensión NameChange también PUEDE incluirse en el nuevo certificado autofirmado CSCA creado tras el cambio del DN de la CSCA. En un certificado raíz CSCA autofirmado de ese tipo, tanto el campo issuer como el subject incluyen el nuevo DN. A diferencia del certificado de enlace autofirmado CSCA que incluyen el DN antiguo y el nuevo de la CSCA, la inclusión de la extensión NameChange en un certificado raíz autofirmado CSCA indica simplemente que ha ocurrido un cambio de nombre y no enlaza el DN antiguo con el nuevo.)
Una CSCA NO DEBE volver a utilizar los números de serie del certificado. Cada certificado expedido por una CSCA, independientemente de si la autoridad ha experimentado un cambio de nombre o no, DEBE ser único.
(Una CSCA NO DEBE volver a utilizar los números de serie del certificado. Cada certificado emitido por una CSCA, independientemente de si la autoridad ha efectuado un cambio de nombre o no, DEBE ser único.)
Sintaxis ASN.1 para la extensión de cambio de nombre
nameChange EXTENSION ::= {
SYNTAX NULL
IDENTIFIED BY id-icao-mrtd-security-extensions-nameChange}
id-icao-mrtd-security-extensions OBJECT IDENTIFIER ::= {id-icao-
mrtd-security 6}
id-icao-mrtd-security-extensions-nameChange OBJECT IDENTIFIER ::=
{id-icao-
mrtd-security-extensions 1}
7.1.1.6 Extensión de tipo de documento
La extensión DocumentType DEBE utilizarse para indicar los tipos de documento, como aparecen en la ZLM, que el correspondiente firmante del documento está autorizado a producir. Esta extensión siempre DEBE establecerse como no crítica.
(La extensión DocumentType DEBE utilizarse para indicar los tipos de documento, como figuran en la ZLM (Zona de Lectura Mecánica), que el correspondiente firmante del documento está autorizado a producir. Esta extensión siempre DEBE establecerse como no crítica.)
Sintaxis ASN.1 para la extensión de lista de tipo de documento:
documentTypeList EXTENSION ::= {
SYNTAX DocumentTypeListSyntax
IDENTIFIED BY id-icao-mrtd-security-extensions-documentTypeList}
DocumentTypeListSyntax : := SEQUENCE {
version DocumentTypeListVersion,
docTypeList SET OF DocumentType }
DocumentTypeListVersion : := INTEGER {v0(0)}
— Document Type as contained in MRZ, e.g. “P” or “ID” where a
— single letter denotes all document types starting with that letter
DocumentType : := PrintableString(SIZE(1..2))
id-icao-mrtd-security-extensions-documentTypeList OBJECT
IDENTIFIER : := {id-icao-mrtd-security-extensions 2}
7.1.2 Perfil de certificado de firmante LDS2
Los certificados de firmante LDS2 DEBEN cumplir con el perfil de certificado de firmante del documento definido en 7.1.1, con las excepciones siguientes:
Campo Sujeto:
El campo de sujeto de los certificados de firmante LDS2 DEBE rellenarse como sigue:
• countryName: DEBE estar presente. Este valor contiene un código de país que DEBE seguir el formato de código de país de dos letras especificado en el Doc 9303-3.
(countryName: DEBE estar presente. Este valor incluye un código de país que DEBE seguir el formato de código de país de dos letras detallado en el Doc 9303-3.)
• commonName: DEBE estar presente. El valor de este atributo NO DEBE superar la longitud de 9 caracteres.
• NO DEBEN incluirse otros atributos.
Extensiones de certificado:
Los certificados de firmante LDS2 DEBEN contener las extensiones de certificado que se indican en la tabla 7. NO DEBEN incluirse todas las demás extensiones de certificado.
(Los certificados de firmante LDS2 DEBEN incluir las extensiones de certificado que se indican en la tabla 7. NO DEBEN incluirse todas las demás extensiones de certificado.)
Tabla 7. Extensiones de certificado obligatorias para LDS2
Nota 1.— La extensión EKU de cada certificado de firmante LDS2 DEBE rellenarse como se indica a continuación. Obsérvese que puede autorizarse que un único firmante LDS2 firme varios tipos de objetos de datos LDS2. En ese caso, la extensión EKU contendría todos los OID pertinentes para ese firmante:
(Nota 1.— La extensión EKU de cada certificado de firmante LDS2 DEBE rellenarse como se indica a continuación. Obsérvese que puede autorizarse que un único firmante LDS2 firme varios tipos de objetos de datos LDS2. En ese caso, la extensión EKU incluiría todos los (OID Object Identifier = Identificador de objeto) relevantes para ese firmante:)
id-icao-mrtd-security-lds2 OBJECT IDENTIFIER ::= {id-icao-mrtd- security 9}
id-icao-lds2Signer OBJECT IDENTIFIER : := {id-icao-mrtd-
security-lds2 8}
• LDS2 Travel Stamp Signer (LDS2-TS) certificates
id-icao-tsSigner OBJECT IDENTIFIER ::= { id-icao- lds2Signer 1}
• LDS2 Visa Signer (LDS2-V) certificates:
id-icao-vSigner OBJECT IDENTIFIER ::= { id-icao- lds2Signer 2}
• LDS2 Biometrics Signer (LDS2-B) certificates:
id-icao-bSigner OBJECT IDENTIFIER ::= { id-icao- lds2Signer 3}
Nota 2.— Los certificados de firmante LDS2 deben cumplir con las restricciones de tamaño impuestas por EF.Certificates que se indican en el Doc 9303-10.
(Nota 2.— Los certificados de firmante LDS2 deben cumplir con las limitaciones de tamaño impuestas por EF.Certificates que se indican en el Doc 9303-10.)
A pesar de que en estos certificados no se incluye la extensión de puntos de distribución de la CRL, es obligatorio que se compruebe el estado de revocación de cada certificado como parte del proceso habitual de validación. La CRL expedida por la CSCA que expidió el certificado en cuestión es la CRL utilizada para verificar su estado de revocación.
(A pesar de que en estos certificados no se incluye la extensión de puntos de distribución de la CRL, es obligatorio que se compruebe el estado de revocación de cada certificado como parte del proceso habitual de aprobación. La CRL emitida por la CSCA que emitió el certificado respectivo es la CRL utilizada para comprobar su estado de revocación.)
7.1.3 Perfil de certificado de firmante del código de barras
Los certificados de firmante del código de barras DEBEN cumplir con el perfil de certificado de firmante LDS2. Dado que los certificados de firmante del código de barras tienen una función distinta a la de los certificados LDS2, su perfil se desvía en algunos aspectos. En concreto, hay requisitos específicos para el subjectDN del certificado de firmante del código de barras y el número de serie (véase el Doc 9303-13).
(Los certificados de firmante del código de barras DEBEN cumplir con el perfil de certificado de firmante LDS2. Dado que los certificados de firmante del código de barras tienen una función distinta a la de los certificados LDS2, su perfil se separa en algunos aspectos. En concreto, hay requisitos determinados para el subjectDN del certificado de firmante del código de barras y el número de serie (véase el Doc 9303-13).)
Campo Sujeto:
El campo de sujeto de los certificados de firmante del código de barras DEBE rellenarse como sigue:
• commonName: DEBE estar presente. DEBE constar de dos caracteres en mayúsculas, en formato printableString, que definan unívocamente al firmante del código de barras de un país, y DEBE coincidir con las letras 3 y 4 del identificador de firmante en el código de barras, como se especifica en el Doc 9303-13.
(commonName: DEBE estar presente. DEBE constar de dos caracteres en mayúsculas, en formato printableString, que definan inequívocamente al firmante del código de barras de un país, y DEBE coincidir con las letras 3 y 4 del identificador de firmante en el código de barras, como se especifica en el Doc 9303-13.)
• countryName: DEBE constar del código de país de dos letras (véase el Doc 9303-3) del firmante del código de barras, en mayúsculas y en formato printableString, y DEBE coincidir con las letras 1 y 2 del identificador de firmante en el código de barras, como se especifica en el Doc 9303-13.
• NO DEBEN incluirse otros atributos.
Extensiones de certificado:
Los certificados de firmante del código de barras DEBEN contener las extensiones de certificado que se indican en la tabla 8. NO DEBEN incluirse todas las demás extensiones de certificado.
(Los certificados de firmante del código de barras DEBEN incluir las extensiones de certificado que se indican en la tabla 8. NO DEBEN incluirse todas las demás extensiones de certificado.)
Tabla 8. Extensiones permitidas para certificados de firmante del código de barras
Nota 1.— La extensión EKU de cada certificado de firmante del código de barras DEBE rellenarse como se indica a continuación.
id-icao-mrtd-security-vds OBJECT IDENTIFIER ::= {id-icao-mrtd-security 11}
id-icao-vdsSigner OBJECT IDENTIFIER ::= {id-icao-mrtd-security-vds 1}
7.1.4 Perfil de CRL
7.1.4 Perfil de CRL (Certificate Revocation List = Lista de revocación de certificados)
En la tabla 9 se definen los requisitos de perfil de CRL para los campos en el cuerpo de la CRL. En la tabla 10 se definen los requisitos de perfil de la CRL para las extensiones de CRL y CRL Entry.
Tabla 9. Perfil de campos de la CRL
Tabla 10. Perfil de extensiones de CRL y de entrada de CRL
Nota 1.— Si una CSCA ha experimentado un cambio de nombre, esta extensión PUEDE incluirse en las CRL expedidas después de dicho cambio de nombre. Si están presentes, los valores de esta extensión DEBEN ser idénticos al campo issuer de los certificados expedidos por la CSCA con el nombre anterior. Una vez que todos los certificados expedidos con un nombre de CSCA anterior al expirado, el nombre de la CSCA puede excluirse de las CRL subsiguientes. No se exige que los sistemas de inspección procesen esta extensión. Dado que en el Doc 9303 de la OACI se exige una única CSCA por país, el componente countryName del campo de expedidor es suficiente para identificar unívocamente la CSCA. La clave pública más reciente de dicha CSCA se utiliza para verificar la firma de la CRL. Dado que una CSCA expide una única CRL, esta CRL abarca todos los certificados expedidos con ese countryName. Además de esa verificación obligatoria, también PUEDE realizarse una verificación opcional de que el campo issuer del certificado es igual al campo issuer de la CRL o uno de los valores de la extensión issuerAltName de la CRL.
(Nota 1.— Si una CSCA ha efectuado un cambio de nombre, esta extensión PUEDE incluirse en las CRL emitidas después de dicho cambio de nombre. Si están presentes, los valores de esta extensión DEBEN ser idénticos al campo issuer de los certificados emitidos por la CSCA con el nombre anterior. Una vez que todos los certificados emitidos con un nombre de CSCA anterior han caducado, el nombre de la CSCA puede excluirse de las CRL posteriores. No se exige que los sistemas de inspección procesen esta extensión. Dado que en el Doc 9303 de la OACI se exige una única CSCA por país, el componente countryName del campo de emisor es suficiente para identificar inequívocamente la CSCA. La clave pública más reciente de dicha CSCA se utiliza para comprobar la firma de la CRL. Dado que una CSCA emite una única CRL, esta CRL abarca todos los certificados emitidos con ese countryName. Además de esa comprobación obligatoria, también PUEDE realizarse una comprobación opcional de que el campo issuer del certificado es igual al campo issuer de la CRL o uno de los valores de la extensión issuerAltName de la CRL.)
Nota 2.— Es posible que la CRL contenga otra información sobre revocación, por ejemplo, relativa a certificados de operador del sistema o autoridad de registro.
(Nota 2.— Es posible que la CRL incluya otra información sobre revocación, por ejemplo, relativa a certificados de operador del sistema o autoridad de registro.)
7.2 La PKI de autorización
La PKI de autorización incluye certificados X.509 para el SPOC y certificados verificables mediante tarjeta para la CVCA, el DV y los terminales. En esta sección se especifican los perfiles de certificado SPOC, CVCA, DV e IS. Se ofrece una visión general de los objetos de datos contenidos en los certificados verificables mediante tarjeta, así como la codificación de dichos objetos.
(La PKI de autorización incluye certificados X.509 para el SPOC (Single Point Of Contact = Punto de contacto único) y certificados comprobables mediante tarjeta para la CVCA (Country Verifying Certification Authority = Autoridad de certificación de verificación de país), el DV (Document Verifier = Verificador del documento) y los terminales. En esta sección se especifican los perfiles de certificado SPOC, CVCA, DV e IS (Inspection System = Sistema de inspección). Se ofrece una visión general de los objetos de datos incluidos en los certificados comprobables mediante tarjeta, así como la codificación de dichos objetos.)
7.2.1 Perfil de certificado SPOC
Se puede utilizar una configuración de CA separada para expedir directamente certificados SPOC con las siguientes restricciones al perfil de certificado CA autofirmado:
(Se puede utilizar una configuración de CA (Certification Authority = Autoridad de certificación) separada para emitir directamente certificados SPOC con las siguientes limitaciones al perfil de certificado CA autofirmado:)
• El certificado CA DEBE ser conforme a [RFC 5280];
(El certificado CA DEBE ser ajustado a [RFC 5280];)
• Los algoritmos SHA-224, SHA-256, SHA-384 y SHA-512 son los únicos algoritmos de condensación permitidos; y
• countryName DEBE estar presente en el campo Sujeto.
Los certificados SPOC (cliente y servidor) LDS2 DEBEN cumplir con el perfil de certificado de comunicación definido en la sección 7.1, con las restricciones siguientes.
(Los certificados SPOC (cliente y servidor) LDS2 DEBEN cumplir con el perfil de certificado de comunicación definido en la sección 7.1, con las limitaciones siguientes.)
Campo Expedidor:
(Campo Emisor:)
Los certificados SPOC son expedidos por la CSCA o por una CA independiente creada específicamente para expedir certificados SPOC.
(Los certificados SPOC son emitidos por la CSCA o por una CA independiente creada específicamente para emitir certificados SPOC.)
Campo Sujeto:
En el caso de los certificados SPOC LDS2, el campo Sujeto DEBE rellenarse como sigue:
• countryName: DEBE estar presente. Este valor contiene un código de país que DEBE seguir el formato de código de país de dos letras especificado en el Doc 9303-3.
(countryName: DEBE estar presente. Este valor incluye un código de país que DEBE seguir el modelo de código de país de dos letras descrito en el Doc 9303-3.)
• commonName: DEBE estar presente. En el caso de los certificados de cliente TLS del SPOC, el valor DEBERÍA ser “SPOC TLS client”. En el caso de los certificados de servidor TLS del SPOC, el valor DEBERÍA SER “SPOC TLS server”.
• También PUEDEN incluirse otros atributos a discreción del Estado expedidor u organización expedidora.
(También PUEDEN incluirse otras particularidades a elección del Estado emisor u organización emisora.)
Extensiones de uso de clave
En el caso de los certificados SPOC, el valor (o valores) depende del conjunto de cifrado utilizado.
Extensiones de nombres alternativos de sujeto
(Extensiones de nombres opcionales de sujeto)
Además de los valores indicados en el perfil de certificado de comunicación, los certificados de servidor TLS del SPOC también DEBEN contener un valor dNSName que es la parte principal de la URL del SPOC.
(Además de los valores indicados en el perfil de certificado de comunicación, los certificados de servidor TLS del SPOC también DEBEN incluir un valor dNSName que es la parte principal de la URL del SPOC.)
Extensiones de uso de clave ampliado
En el caso de los certificados de cliente y servidor del SPOC, DEBE incluirse el valor pertinente que se indica a continuación.
• Certificados de cliente SPOC: El OID es 2.23.136.1.1.10.1;
• Certificados de servidor SPOC: El OID es 2.23.136.1.1.10.2.
Extensiones de puntos de distribución de la CRL
Esta extensión es obligatoria en los certificados de cliente y servidor del SPOC.
7.2.2 Perfiles de certificado CVCA, DV y de terminal
Los certificados de enlace CVCA, certificados DV y certificados de terminal son validados por el CI. Debido a las restricciones computacionales de esos chips, los certificados DEBEN estar tener un formato verificable mediante tarjeta (certificados CV).
(Los certificados de enlace CVCA, certificados DV y certificados de terminal son aprobados por el CI (Circuito Integrado). Debido a las limitaciones computacionales de esos chips, los certificados DEBEN tener una estructura comprobable mediante tarjeta (certificados CV = card-verifiable).)
SE UTILIZARÁN el formato y perfil de certificado indicados en la tabla 11. En el Doc 9303-11 figura información detallada sobre los valores de codificación.
Tabla 11. Perfil de certificado CV
7.2.2.1 Identificador del perfil de certificado
El identificador del perfil de certificado indica la versión del perfil. SE UTILIZARÁ la versión 1, que se identifica con el valor de 0.
7.2.2.2 Referencia de la autoridad de certificación y referencia de la persona titular de certificado
Cada certificado CV DEBE contener dos referencias de clave pública (una referencia de la persona titular de certificado y una referencia de la autoridad de certificación).
(Cada certificado CV DEBE incluir dos referencias de clave pública (una referencia de la persona titular de certificado y una referencia de la autoridad de certificación).)
La referencia de la autoridad de certificación es una referencia a la clave pública (externa) de la autoridad de certificación (CVCA o DV) que SE UTILIZARÁ para verificar la firma del certificado.
(La referencia de la autoridad de certificación es una referencia a la clave pública (externa) de la autoridad de certificación (CVCA o DV) que SE UTILIZARÁ para comprobar la firma del certificado.)
La referencia de la persona titular de certificado es un identificador de la clave pública proporcionada en el certificado que SE UTILIZARÁ para hacer referencia a esta clave pública.
(La referencia de la persona titular de certificado es un identificador de la clave pública suministrada en el certificado que SE UTILIZARÁ para hacer referencia a esta clave pública.)
Nota.— En consecuencia, la referencia de la autoridad de certificación contenida en un certificado DEBE ser igual a la referencia de la persona titular de certificado que figura en el certificado correspondiente de la autoridad de certificación expedidora.
(Nota.— En consecuencia, la referencia de la autoridad de certificación incluida en un certificado DEBE ser igual a la referencia de la persona titular de certificado que figura en el certificado correspondiente de la autoridad de certificación emisora.)
La referencia de la persona titular de certificado DEBE constar de los elementos concatenados siguientes: Código de país, secuencia mnemónica de la persona titular y número de secuencia. Estos elementos DEBEN elegirse de conformidad con la tabla 12 y las normas siguientes:
(La referencia de la persona titular de certificado DEBE constar de los elementos enlazados siguientes: Código de país, secuencia mnemónica de la persona titular y número de secuencia. Estos elementos DEBEN elegirse de acuerdo con la tabla 12 y las normas siguientes:)
a) Código de país:
• El código de país SERÁ el código de dos letras que figura en el Doc 9303- 3 del país de la persona titular de certificado.
b) Secuencia mnemónica de la persona titular:
• La secuencia mnemónica de la persona titular SE ASIGNARÁ como un identificador único de la siguiente manera:
– la secuencia mnemónica de la persona titular de una CVCA DEBE ser asignada por la propia CVCA;
– la secuencia mnemónica de la persona titular de un DV DEBE ser asignada por la CVCA nacional; y
– la secuencia mnemónica de la persona titular de un IS DEBE ser asignada por el DV supervisor.
c) Número de secuencia:
• El número de secuencia DEBE ser asignado por la persona titular de certificado;
• El número de secuencia DEBE ser numérico o alfanumérico;
– Un número de secuencia numérico CONSTARÁ de los caracteres “0…9”.
– Un número de secuencia alfanumérico CONSTARÁ de los caracteres “0…9” y “A…Z”.
• El número de secuencia DEBE empezar con el código de país de dos letras que figura en el Doc 9303-3 de la autoridad de certificación, los otros tres caracteres SE ASIGNARÁN como un número de secuencia alfanumérico; y
• El número de secuencia PUEDE restablecerse si se agotan todos los números de secuencia disponibles.
Tabla 12. Referencia de la persona titular de certificado
7.2.2.3 Clave pública
Este campo contiene la clave pública que se está certificando.
(Este campo incluye la clave pública que se está certificando.)
Los certificados autofirmados CSCA DEBEN contener parámetros de dominio. Los certificados de enlace CVCA PUEDEN contener parámetros de dominio, salvo en el caso de que dichos parámetros hayan cambiado. En ese caso, los certificados de enlace DEBEN contener los nuevos parámetros de dominio.
(Los certificados autofirmados CSCA DEBEN incluir criterios de dominio. Los certificados de enlace CVCA PUEDEN incluir criterios de dominio, salvo en el caso de que dichos criterios hayan cambiado. En ese caso, los certificados de enlace DEBEN incluir los nuevos criterios de dominio.)
Los certificados DV y de terminal NO DEBEN contener parámetros de dominio. Los parámetros de dominio de las claves públicas de DV y terminal SE HEREDARÁN de la clave pública CVCA respectiva.
(Los certificados DV y de terminal NO DEBEN incluir criterios de dominio. Los criterios de dominio de las claves públicas de DV y terminal SE HEREDARÁN de la clave pública CVCA respectiva.)
7.2.2.4 Plantilla de autorización de la persona titular de certificado
La función y la autorización de la persona titular de certificado SE CODIFICARÁN en la plantilla de autorización de la persona titular del certificado. Esta plantilla es una secuencia que consta de los objetos de datos siguientes:
a) un identificador de objeto que especifica el tipo de terminal y el formato de la plantilla; y
(a) un identificador de objeto que describe el tipo de terminal y el modelo de la plantilla; y)
b) un objeto de datos discrecionales que codifica la autorización relativa, es decir, la función y autorización de la persona titular del certificado con respecto a la autoridad de certificación.
(un objeto de datos opcionales que codifica la autorización relativa, es decir, la función y autorización de la persona titular del certificado con respecto a la autoridad de certificación.)
Los valores específicos se definen en el Doc 9303-10.
7.2.2.5 Fecha de entrada en vigor del certificado y fecha de caducidad del certificado
La combinación de estas dos fechas indica el período de validez del certificado. La fecha de entrada en vigor del certificado DEBE ser la fecha en que se genera. La fecha de caducidad del certificado es la fecha tras la cual caduca.
7.2.2.6 Extensiones de certificado (extensiones de autorización)
Las extensiones de autorización PUEDEN incluirse en los certificados CVCA, DV y de terminal. Estas extensiones transmiten autorizaciones adicionales a las de la plantilla de autorización de la persona titular de certificado.
Una extensión de autorización es una secuencia de plantillas de datos discrecionales, donde cada plantilla de datos discrecionales DEBE contener una secuencia de los objetos de datos siguientes, que también se muestran en la tabla 13:
(Una extensión de autorización es una secuencia de plantillas de datos opcionales, donde cada plantilla de datos opcionales DEBE incluir una secuencia de los objetos de datos siguientes, que también se muestran en la tabla 13:)
a) un identificador de objeto que especifica el contenido y el formato de la extensión; y
(un identificador de objeto que describe el contenido y la estructura de la extensión; y)
b) un objeto de datos específico del contexto que contiene la autorización codificada.
(un objeto de datos específico del contexto que incluye la autorización codificada.)
Tabla 13. Extensiones de certificado
Nota.— El procedimiento de validación de certificados que se describe en el Doc 9303-11 no tiene en cuenta las extensiones de certificado. Por lo tanto, las extensiones son atributos no críticos y el CI NO DEBE rechazar certificados debido a extensiones desconocidas.
(Nota.— El procedimiento de aprobación de certificados que se describe en el Doc 9303-11 no tiene en cuenta las extensiones de certificado. Por lo tanto, las extensiones son particularidades no críticas y el CI (Circuito Integrado) NO DEBE rechazar certificados debido a extensiones desconocidas.)
7.2.2.7 Firma
La firma del certificado SE CREARÁ sobre el cuerpo del certificado codificado (es decir, incluyendo la etiqueta y la longitud).
La referencia de la autoridad de certificación IDENTIFICARÁ la clave pública que se utilizará para verificar la firma.
(La referencia de la autoridad de certificación IDENTIFICARÁ la clave pública que se utilizará para comprobar la firma.)
7.2.3 Objetos de datos
En la tabla 14 se presenta un resumen de las etiquetas, longitudes y valores de los objetos de datos utilizados en los certificados CVCA, DV y de terminal.
Tabla 14. Resumen de los objetos de datos (clasificados por etiqueta)
| Nombre | Etiqueta | Long. | Valor | Comentario |
| Identificador de objeto | 0x06 | V | Identificador de objeto | – |
| Referencia de la autoridad de certificación | 0x42 | 16V | Cadena de caracteres | Identifica la clave pública de la autoridad de certificación emisora de un certificado. |
| Plantilla de datos opcionales | 0x53 | V | Cadena de octetos | Incluye datos opcionales. |
| Referencia de la persona titular de certificado | 0x5F20 | 16V | Cadena de caracteres | Asocia la clave pública incluida en un certificado con un identificador. |
| Nombre | Etiqueta | Long. | Valor | Comentario |
| Fecha de caducidad del certificado | 0x5F24 | 6F | Fecha | La fecha tras la cual caduca el certificado. |
| Fecha de entrada en vigor del certificado | 0x5F25 | 6F | Fecha | La fecha en que se crea el certificado. |
| Identificador del perfil de certificado | 0x5F29 | 1F | Entero sin signo | Versión del certificado y formato de solicitud de certificado. |
| Firma | 0x5F37 | V | Cadena de octetos | Firma digital producida por un algoritmo criptográfico asimétrico. |
| Extensiones de certificado | 0x65 | V | Secuencia | Aloja extensiones de certificado. |
| Autenticación | 0x67 | V | Secuencia | Incluye objetos de datos relacionados con la autenticación. |
| Plantilla de datos opcionales | 0x73 | V | Secuencia | Aloja objetos de datos opcionales. |
| Certificado CV | 0x7F21 | V | Secuencia | Aloja el cuerpo del certificado y la firma. |
| Clave pública | 0x7F49 | V | Secuencia | Aloja el valor de la clave pública y los criterios de dominio |
| Plantilla de autorización de la persona titular de certificado | 0x7F4C | V | Secuencia | Codifica la función de la persona titular de certificado (es decir, CVCA, DV, terminal) y asigna derechos de acceso de lectura/escritura. |
| Cuerpo del certificado | 0x7F4E | V | Secuencia | Aloja objetos de datos del cuerpo del certificado. |
7.2.3.1 Codificación de valores
Los tipos de valores básicos utilizados en esta especificación son los siguientes: enteros (sin signo), puntos de curva elíptica, fechas, cadenas de caracteres, cadenas de octetos, identificadores de objeto y secuencias.
(Los tipos de valores básicos utilizados en esta determinación son los siguientes: enteros (sin signo), puntos de curva elíptica, fechas, cadenas de caracteres, cadenas de octetos, identificadores de objeto y secuencias.)
7.2.3.1.1 Enteros sin signo
Todos los enteros utilizados en esta especificación son enteros sin signo. Un entero sin signo SE CONVERTIRÁ en una cadena de octetos utilizando la representación binaria del entero en formato big-endian. SE UTILIZARÁ el número mínimo de octetos, es decir, los octetos iniciales de valor 0x00 NO DEBEN utilizarse.
(Todos los enteros utilizados en esta determinación son enteros sin signo. Un entero sin signo SE CONVERTIRÁ en una cadena de octetos utilizando la representación binaria del entero en tipo big-endian. SE UTILIZARÁ el número mínimo de octetos, es decir, los octetos iniciales de valor 0x00 NO DEBEN utilizarse.)
Nota.— En cambio, el ENTERO tipo ASN.1 es siempre un entero con signo
7.2.3.1.2 Puntos de curva elíptica
La conversión de los puntos de curva elíptica en cadenas de octetos se especifica en [TR-03111]. SE UTILIZARÁ el formato sin comprimir.
(La transformación de los puntos de curva elíptica en cadenas de octetos se describe en [TR-03111]. SE UTILIZARÁ el modelo sin comprimir.)
7.2.3.1.3 Fechas
Una fecha se codifica en 6 dígitos “d1…d6” con el formato AAMMDD, utilizando la zona horaria GMT. Se convierte en una cadena de octetos “o1…o6” codificando cada dígito dj en un octeto oj como decimal codificado en binario (BCD) desempaquetado (1 ≤ j ≤ 6).
(Una fecha se codifica en 6 dígitos “d1…d6” con el tipo AAMMDD, utilizando la zona horaria GMT. Se transforma en una cadena de octetos “o1…o6” codificando cada dígito dj en un octeto oj como decimal codificado en binario (BCD) desempaquetado (1 ≤ j ≤ 6).)
El año AA está codificado en dos dígitos y debe interpretarse como 20AA, es decir, que el año está en el intervalo de 2000 a 2099.
7.2.3.1.4 Cadenas de caracteres
Una cadena de caracteres “c1…cn” es una concatenación de n caracteres cj con 1 ≤ j ≤ n. SE CONVERTIRÁ en una cadena de octetos “o1…on” convirtiendo cada carácter cj en un octeto oj utilizando el conjunto de caracteres ISO/IEC 8859-1.
(Una cadena de caracteres “c1…cn” es una sucesión de n caracteres cj con 1 ≤ j ≤ n. SE CONVERTIRÁ en una cadena de octetos “o1…on” convirtiendo cada carácter cj en un octeto oj utilizando el conjunto de caracteres ISO/IEC 8859-1.)
Los códigos de caracteres 0x00-0x1F y 0x7F-0x9F no están asignados y NO DEBEN utilizarse. La conversión de un octeto a un carácter no asignado DARÁ error.
(Los códigos de caracteres 0x00-0x1F y 0x7F-0x9F no están asignados y NO DEBEN utilizarse. La transformación de un octeto a un carácter no asignado DARÁ error.)
7.2.3.1.5 Cadenas de octetos
Una cadena de octetos “o1…on” es una concatenación de n octetos oj con 1 ≤ j ≤ n. Cada octeto oj consta de 8 bits.
(Una cadena de octetos “o1…on” es una sucesión de n octetos oj con 1 ≤ j ≤ n. Cada octeto oj consta de 8 bits.)
7.2.3.1.6 Identificadores de objetos
Un identificador de objeto “i1.i2…in” se codifica como una lista ordenada de n enteros sin signo ij con 1 ≤ j ≤ n. SE CONVERTIRÁ en una cadena de octetos “o1…on−1” mediante el procedimiento siguiente:
1) Los dos primeros enteros i1 e i2 se empaquetan en un único entero i que posteriormente se convierte en la cadena de octetos o1. El valor se calcula como sigue:
i=i1⋅40+i2
2) Los enteros restantes ij se convierten directamente en cadenas de octetos oj-1 con 3 ≤ j ≤ n.
En [X.690] figuran más detalles sobre la codificación.
Nota.— Los enteros sin signo se codifican como cadenas de octetos utilizando el formato big-endian, como se describe en el Doc 9303-11, pero solo se utilizan los bits 1-7 de cada octeto. El bit 8 (el de más a la izquierda) establecido en uno se utiliza para indicar que este octeto no es el último de la cadena.
7.2.3.1.7 Secuencias
Una secuencia “D1…Dn” es una lista ordenada de n objetos de datos Dj con 1 ≤ j ≤ n. La secuencia SE CONVERTIRÁ en una lista concatenada de cadenas de octetos“O1…On” mediante la codificación DER de cada objeto de datos Dj en una cadena de octetos Oj.
(Una secuencia “D1…Dn” es una lista ordenada de n objetos de datos Dj con 1 ≤ j ≤ n. La secuencia SE CONVERTIRÁ en una lista enlazada de cadenas de octetos“O1…On” mediante la codificación DER (Distinguished Encoding Rule = Regla de codificación distinguida) de cada objeto de datos Dj en una cadena de octetos Oj.)
7.2.3.2 Codificación de objetos de datos de clave pública
Un objeto de datos de clave pública contiene una secuencia de un identificador de objeto y varios objetos de datos específicos del contexto:
(Un objeto de datos de clave pública incluye una secuencia de un identificador de objeto y varios objetos de datos específicos del contexto:)
• El identificador de objeto es específico de la aplicación y se refiere no solo al formato de la clave pública (es decir, los objetos de datos específicos del contexto) sino también a su uso.
(El identificador de objeto es específico de la aplicación y se refiere no solo al tipo de la clave pública (es decir, los objetos de datos concretos del contexto) sino también a su uso.)
• Los objetos de datos específicos del contexto están definidos por el identificador de objeto y contienen el valor de la clave pública y los parámetros de dominio.
(Los objetos de datos concretos del contexto están definidos por el identificador de objeto e incluyen el valor de la clave pública y los criterios de dominio.)
A continuación se describe el formato de los objetos de datos de clave pública utilizados en esta especificación.
7.2.3.2.1 Claves públicas RSA
Los objetos de datos contenidos en una clave pública RSA se muestran en la tabla 15. El orden de los objetos de datos es fijo.
(Los objetos de datos incluidos en una clave pública RSA (Rivest, Shamir and Adleman) se muestran en la tabla 15. El orden de los objetos de datos es fijo.)
Tabla 15. Clave pública RSA
7.2.3.2.2 Claves públicas de curva elíptica
Los objetos de datos contenidos en una clave pública EC se muestran en la tabla 16. El orden de los objetos de datos es fijo, los parámetros de dominio CONDICIONALES DEBEN estar todos presentes, salvo el cofactor, o todos ausentes, como se define a continuación:
(Los objetos de datos incluidos en una clave pública EC (Elliptic Curve = Curva Elíptica) se muestran en la tabla 16. El orden de los objetos de datos es fijo, los criterios de dominio CONDICIONALES DEBEN estar todos presentes, salvo el cofactor, o todos ausentes, como se define a continuación:)
• Los certificados autofirmados CVCA DEBEN contener parámetros de dominio;
(Los certificados autofirmados CVCA DEBEN incluir criterios de dominio;)
• Los certificados de enlace CVCA PUEDEN contener parámetros de dominio;
(Los certificados de enlace CVCA PUEDEN incluir criterios de dominio;)
• Los certificados DV y de terminal NO DEBEN contener parámetros de dominio. Los parámetros de dominio de las claves públicas de DV y terminal SE HEREDARÁN de la clave pública CVCA respectiva; y
(Los certificados DV y de terminal NO DEBEN incluir criterios de dominio. Los criterios de dominio de las claves públicas de DV y terminal SE HEREDARÁN de la clave pública CVCA respectiva; y)
• Las solicitudes de certificado DEBEN contener siempre parámetros de dominio.
(Las solicitudes de certificado DEBEN incluir siempre criterios de dominio.)
Tabla 16. Clave pública EC
(sigue el apartado 3 de la Parte 12 del documento 9303)
En el caso de los participantes en el PKD, el expedidor de certificado también DEBE enviar cada certificado CSCA (CCSCA) al PKD [para fines de validación de certificados de firmante del documento (CDS)].
(En el caso de los participantes en el PKD (Public Key Directory, el emisor de certificado también DEBE enviar cada certificado CSCA (CCSCA = Country Signing Certification Authority =Autoridad de certificación de firma de país) al PKD [para fines de aprobación de certificados de firmante del documento (CDS = Document Signer Certificate)].)
Las CRL DEBEN expedirse con carácter periódico según se especifica en la sección 4.
(Las CRL DEBEN emitirse con carácter periódico como se especifica en la sección 4.)
3.1.2 Firmantes del documento
SE RECOMIENDA que los pares de claves de firmante del documento (KPuDS, KPrDS) se generen y almacenen en una infraestructura altamente protegida.
(SE RECOMIENDA que los pares de claves de firmante del documento (KPuDS, KPrDS) se creen y almacenen en una infraestructura altamente protegida.)
La clave privada de firmante del documento (KPrDS) se utiliza para firmar los objetos de seguridad del documento (SOD).
Los certificados de firmante del documento (CDS) se utilizan para validar los objetos de seguridad de documento (SOD).
(Los certificados de firmante del documento (CDS) se utilizan para aprobar los objetos de seguridad de documento (SOD).)
Cada certificado de firmante del documento (CDS) DEBE cumplir con el perfil de certificado definido en la sección 7 y DEBE almacenarse en el CI sin contacto de cada eMRTD que fue firmado con la correspondiente clave privada DS (véase información detallada en el Doc 9303-10). Esto asegura que el Estado receptor tiene acceso al certificado de firmante del documento pertinente a cada eMRTD.
(Cada certificado de firmante del documento (CDS) DEBE cumplir con el perfil de certificado definido en la sección 7 y DEBE almacenarse en el CI (Circuito Integrado) sin contacto de cada eMRTD (Electronic Machine Readable Travel Document = Documento de viaje de lectura mecánica electrónico) que fue firmado con la correspondiente clave privada DS (Document Signer = Firmante del documento)(véase información detallada en el Doc 9303-10). Esto asegura que el Estado receptor tiene acceso al certificado de firmante del documento correspondiente a cada eMRTD.)
El expedidor de certificado también DEBERÍA enviar a la OACI los certificados de firmante del documento de los participantes en el PKD para su publicación en el Directorio de Clave Pública (PKD) de la OACI.
(El emisor de certificado también DEBERÍA enviar a la OACI los certificados de firmante del documento de los participantes en el PKD para su publicación en el Directorio de Clave Pública (PKD) de la OACI.)
3.1.3 Firmantes LDS2
Un firmante LDS2 firma digitalmente objetos de datos LDS2 de uno o más tipos.
Cuando sea necesario referirse a un firmante LDS2 como aquel que firma un tipo de objeto de datos LDS2 en concreto, se denominará de la siguiente manera:
• firmante LDS2-TS – firma los sellos de viaje LDS2;
(firmante LDS2-TS (Travel Stamps)– firma los sellos de viaje LDS2)
• firmante LDS2-V – firma los visados electrónicos LDS2; y
(firmante LDS2-V (Visas) – firma los visados electrónicos LDS2; y)
• firmante LDS2-B – firma la biometría adicional LDS2.
(firmante LDS2-B (Biometrics) – firma la biometría adicional LDS2)
SE RECOMIENDA que cada Estado no tenga más de un firmante LDS2-TS, un firmante LDS2-V y un firmante LDS2-B. Un firmante LDS2 también puede combinar algunas de estas funciones o todas ellas.
Si se requiere una mayor diferenciación, como el lugar en que se añadió el sello de viaje, la funcionaria o funcionario concreto que autorizó a una persona viajera, la funcionaria o funcionario que concedió un visado o el lugar en el que se añadieron datos biométricos adicionales, puede incluirse en un campo propio dentro del propio objeto de datos LDS2 correspondiente.
(Si se necesita una mayor diferenciación, como el lugar en que se añadió el sello de viaje, la funcionaria o funcionario concreto que autorizó a una persona viajera, la funcionaria o funcionario que adjudicó un visado o el lugar en el que se añadieron datos biométricos adicionales, puede incluirse en un campo propio dentro del propio objeto de datos LDS2 correspondiente.)
3.1.4 Firmantes del código de barras
SE RECOMIENDA que los pares de claves de firmante del código de barras (KPuBCS, KPrBCS) se generen y almacenen en una infraestructura altamente protegida.
(SE RECOMIENDA que los pares de claves de firmante del código de barras (KPuBCS, KPrBCS) se creen y almacenen en una infraestructura altamente protegida.)
La clave privada del firmante del código de barras (KPrBCS) se utiliza para firmar los datos (encabezado y mensaje) codificados en el código de barras. La firma también se almacena en el código de barras.
Los certificados de firmante del código de barras (CBCS) se utilizan para validar los datos (encabezado y mensaje) codificados en el código de barras.
(Los certificados de firmante del código de barras (CBCS) se utilizan para aprobar los datos (encabezado y mensaje) codificados en el código de barras.)
Cada certificado de firmante del código de barras (CBCS) DEBE cumplir con el perfil de certificado definido en la sección 7. Los certificados de firmante del código de barras no figuran en el propio sello digital. Por lo tanto, un país que expide documentos protegidos por sellos digitales DEBE publicar todos sus certificados de firmante del código de barras. El canal principal de distribución de los certificados de firmante del código de barras es el PKD/bilateral. Hay también canales secundarios que utilizan otras vías, como la publicación en un sitio web.
(Cada certificado de firmante del código de barras (CBCS) DEBE cumplir con el perfil de certificado definido en la sección 7. Los certificados de firmante del código de barras no figuran en el propio sello digital. Por lo tanto, un país que emite documentos protegidos por sellos digitales DEBE publicar todos sus certificados de firmante del código de barras. El canal principal de distribución de los certificados de firmante del código de barras es el PKD/bilateral. Hay también canales secundarios que utilizan otras vías, como la publicación en un sitio web.)
El expedidor de certificado también DEBERÍA enviar a la OACI los certificados de firmante del código de barras de los participantes en el PKD para su publicación en el Directorio de Clave Pública (PKD) de la OACI.
(El emisor de certificado también DEBERÍA enviar a la OACI los certificados de firmante del código de barras de los participantes en el PKD para su publicación en el Directorio de Clave Pública (PKD = Public Key Directory) de la OACI.)
El firmante del visado (VS) y el firmante del documento de viaje de emergencia son casos especiales del firmante del código de barras.
3.1.5 Sistema de inspección
Los sistemas de inspección ejecutan la autenticación pasiva para asegurar la integridad y autenticidad de los datos almacenados en el CI sin contacto del eMRTD. Como parte de ese proceso, los sistemas de inspección DEBEN ejecutar la validación de ruta de certificación como se indica en la sección 6.
(Los sistemas de inspección ejecutan la autenticación pasiva para asegurar la invariabilidad y autenticidad de los datos almacenados en el CI sin contacto del eMRTD. Como parte de ese proceso, los sistemas de inspección DEBEN ejecutar la aprobación de ruta de certificación como se indica en la sección 6.)
3.1.6 Firmante de la lista maestra
La clave privada del firmante de la lista maestra se utiliza para firmar las listas maestras de CSCA.
Los certificados de firmantes de la lista maestra se utilizan para validar las listas maestras de CSCA.
(Los certificados de firmantes de la lista maestra se utilizan para aprobar las listas maestras de CSCA.)
3.1.7 Firmante de la lista de desviaciones
La clave privada del firmante de la lista de desviaciones se utiliza para firmar las listas de desviaciones.
Los certificados de firmante de la lista de desviaciones se utilizan para validar las listas de desviaciones.
(Los certificados de firmante de la lista de desviaciones se utilizan para aprobar las listas de desviaciones.)