EL DELITO DE ESTAFA (X)

07/09/2026

8.2 Mensajes del protocolo del SPOC

En esta sección se especifican los mensajes utilizados en el protocolo del SPOC.

8.2.1 Mensaje de certificado de solicitud

Uso previsto:

El mensaje RequestCertificate es utilizado por un SPOC para solicitar la generación de un nuevo certificado para uno de sus DV a una CVCA extranjera.

(El mensaje RequestCertificate (certificado de solicitud) es utilizado por un SPOC para solicitar la creación de un nuevo certificado para uno de sus DV a una CVCA extranjera.)

Parámetros de entrada:

callerID: (obligatorio)

Este parámetro contiene el identificador del Estado originador de la solicitud. El valor SERÁ el código de país de dos letras que figura en el Doc 9303-3. El valor de callerID DEBE ser verificado por el SPOC receptor con el valor registrado desde el SPOC originador durante su registro.

(callerID: (obligatorio)

Este parámetro incluye el identificador del Estado originador de la solicitud. El valor SERÁ el código de país de dos letras que figura en el Doc 9303-3. El valor de callerID DEBE ser comprobado por el SPOC receptor con el valor registrado desde el SPOC originador durante su registro.)

messageID: (obligatorio)

Este parámetro contiene la identificación del mensaje y DEBE identificar el mensaje unívocamente dentro de todos los mensajes de ese emisor. Si se envía un mensaje de respuesta al emisor como resultado de este mensaje, el mensaje de respuesta contendrá el mismo messageID. Así, un mensaje de respuesta entrante puede asignarse al mensaje original correcto. La construcción y asignación del messageID puede ser decidida por el emisor y no es verificada por la parte receptora.

(messageID: (obligatorio)

Este parámetro incluye la identificación del mensaje y DEBE identificar el mensaje individualmente dentro de todos los mensajes de ese emisor. Si se envía un mensaje de respuesta al emisor como resultado de este mensaje, el mensaje de respuesta incluirá el mismo messageID. Así, un mensaje de respuesta entrante puede asignarse al mensaje original correcto. La construcción y asignación del messageID puede ser decidida por el emisor y no es comprobada por la parte receptora.)

certReq: (obligatorio)

Este parámetro contiene la solicitud de certificado propiamente dicha. DEBE construirse de conformidad con la sección 8.1.1. La codificación DEBE seguir las especificaciones que se indican en la sección 7.2.3.1.

(certReq: (obligatorio)

Este parámetro incluye la solicitud de certificado propiamente dicha. DEBE construirse de acuerdo con la sección 8.1.1. La codificación DEBE seguir las especificaciones que se indican en la sección 7.2.3.1.)

Parámetros de salida:

CertificateSeq: (condicional)

Este parámetro contendrá el resultado (uno o más certificados) después de que se procese el mensaje, si el mensaje ha sido procesado satisfactoriamente y de forma sincronizada por el receptor. SE EXIGE si los certificados deben enviarse con la respuesta. NO DEBE estar presente si los certificados no se enviarán con el mensaje.

(CertificateSeq: (condicional)

Este parámetro incluirá el resultado (uno o más certificados) después de que se procese el mensaje, si el mensaje ha sido procesado satisfactoriamente y de forma sincronizada por el receptor. SE EXIGE si los certificados deben enviarse con la respuesta. NO DEBE estar presente si los certificados no se enviarán con el mensaje.)

Códigos de retorno:

• ok_cert_available: El mensaje se ha procesado satisfactoriamente y de forma sincronizada. El parámetro de salida certificateSeq contiene uno o más certificados.

• ok_reception_ack: Se acusa recepción del mensaje. El mensaje aún no se ha verificado. El procesamiento del mensaje se realizará de forma asíncrona. El resultado del procesamiento se enviará a la URL registrada utilizando el mensaje SendCertificates.

(ok_reception_ack: Se acusa recepción del mensaje. El mensaje aún no se ha comprobado. El procesamiento del mensaje se realizará de forma descoordinada. El resultado del procesamiento se enviará a la URL registrada utilizando el mensaje SendCertificates.)

• failure_inner_signature: La verificación de la firma interna de la solicitud de certificado propiamente dicha ha fallado.

(failure_inner_signature: La comprobación de la firma interna de la solicitud de certificado propiamente dicha ha fallado.)

• failure_outer_signature: La verificación de la firma externa de la solicitud de certificado propiamente dicha ha fallado.

(failure_outer_signature: La comprobación de la firma externa de la solicitud de certificado propiamente dicha ha fallado.)

• failure_syntax: El mensaje no es correcto sintácticamente.

• failure_request_not_accepted: El mensaje se ha procesado correctamente pero la solicitud no ha sido aceptada.

• failure_request_syntax: La solicitud de certificado no es correcta (p. ej., sintaxis o formato de archivo)

• failure_expired: El certificado que debe utilizarse para verificar la firma externa de la solicitud ha caducado.

(failure_expired: El certificado que debe utilizarse para comprobar la firma externa de la solicitud ha caducado.)

• failure_domain_parameters: Los parámetros de dominio contenidos en la solicitud no coinciden con los parámetros de dominio del certificado CVCA previsto para firmar el certificado DV solicitado.

(failure_expired: El certificado que debe utilizarse para comprobar la firma externa de la solicitud ha caducado.)

• failure_internal_error: Error distinto de los anteriores.

Observaciones:

El cuerpo de la solicitud de certificado DEBERÍA contener una referencia de la autoridad de certificación (CAR) para informar a la CVCA de la clave privada que el solicitante espera que se utilice para firmar el certificado. Si la CAR de la solicitud difiere de la CAR del certificado expedido, también SE PROPORCIONARÁ en la respuesta el certificado correspondiente de la CVCA. En ese caso, y si el mensaje se procesa de forma sincrónica, el certificado CVCA DEBE formar parte del parámetro de salida certificateSeq. El certificado DV DEBE ser el primer certificado de la secuencia. Los certificados CVCA (raíz y/o de enlace) SE ORDENARÁN por fecha de entrada en vigor (ascendente) en la secuencia.

(El cuerpo de la solicitud de certificado DEBERÍA incluir una referencia de la autoridad de certificación (CAR = Certification Authority Reference) para informar a la CVCA de la clave privada que el solicitante espera que se utilice para firmar el certificado. Si la CAR de la solicitud difiere de la CAR del certificado emitido, también SE FACILITARÁ en la respuesta el certificado correspondiente de la CVCA. En ese caso, y si el mensaje se procesa de forma simultánea, el certificado CVCA DEBE formar parte del parámetro de salida certificateSeq. El certificado DV DEBE ser el primer certificado de la secuencia. Los certificados CVCA (raíz y/o de enlace) SE ORDENARÁN por fecha de entrada en vigor (ascendente) en la secuencia.)

8.2.2 Mensaje de envío de certificados

Uso previsto:

El mensaje SendCertificates es utilizado por un SPOC para enviar el nuevo certificado o cadena de certificados al SPOC solicitante. Este mensaje SE GENERARÁ en respuesta a:

(El mensaje SendCertificates es utilizado por un SPOC para enviar el nuevo certificado o cadena de certificados al SPOC solicitante. Este mensaje SE CREARÁ en respuesta a:)

• RequestCertificate: al procesar satisfactoriamente la solicitud asíncrona después de que se expida el certificado;

(RequestCertificate: al procesar satisfactoriamente la solicitud descoordinada después de que se emita el certificado;)

• GetCACertificates

Además, el mensaje DEBE utilizarse cuando se crea un nuevo certificado (CVCA raíz y de enlace) para enviar los certificados al SPOC extranjero registrado.

Parámetros de entrada:

callerID: (obligatorio)

(callerID: (obligatorio)

(Este parámetro incluye el identificador del Estado originador. El valor SERÁ el código de país de dos letras que figura en el Doc 9303-3. El valor de callerID DEBE ser comprobado por el SPOC receptor con el valor registrado desde el SPOC originador durante su registro.)

messageID: (condicional)

Cuando el mensaje se genera en respuesta a un mensaje de solicitud, el parámetro DEBE contener el mismo valor que el parámetro messageID del mensaje de solicitud. Cuando la generación del mensaje se haya desencadenado sin intervención externa (cambio de claves del certificado CVCA), el valor de statusInfo SERÁ new_cert_available_notification y el parámetro messageID PUEDE omitirse y SE IGNORARÁ cuando esté presente.

(messageID: (condicional)

Cuando el mensaje se crea en respuesta a un mensaje de solicitud, el parámetro DEBE incluir el mismo valor que el parámetro messageID del mensaje de solicitud. Cuando la creación del mensaje se haya realizado sin intervención externa (cambio de claves del certificado CVCA), el valor de statusInfo SERÁ new_cert_available_notification y el parámetro messageID PUEDE excluirse y SE IGNORARÁ cuando esté presente.)

statusInfo: (obligatorio)

Este parámetro contiene un código de estado sobre el resultado del procesamiento del mensaje correspondiente. Pueden darse los estados siguientes:

(statusInfo: (obligatorio)

Este parámetro incluye un código de estado sobre el resultado del procesamiento del mensaje correspondiente. Pueden darse los estados siguientes:)

• new_cert_available_notification: El SPOC originador desea notificar que el nuevo certificado (o certificados) CVCA está disponible sin que se haya solicitado.

• ok_cert_available: La solicitud se ha procesado satisfactoriamente. El parámetro de entrada certificateSeq contiene uno o más certificados.

(ok_cert_available: La solicitud se ha procesado satisfactoriamente. El parámetro de entrada certificateSeq incluye uno o más certificados.)

• failure_inner_signature: La verificación de la firma interna de la solicitud de certificado propiamente dicha ha fallado.

(failure_inner_signature: La comprobación de la firma interna de la solicitud de certificado propiamente dicha ha fallado.)

• failure_outer_signature: La verificación de la firma externa de la solicitud de certificado propiamente dicha ha fallado.

(failure_outer_signature: La comprobación de la firma externa de la solicitud de certificado propiamente dicha ha fallado.)

• failure_syntax: El mensaje correspondiente no es correcto sintácticamente.

• failure_request_not_accepted: El mensaje correspondiente se ha procesado correctamente pero la solicitud no ha sido aceptada.

• failure_certificate: Uno o varios de los certificados enviados no es correcto (sintaxis o firma).

• failure_internal_error: error distinto de certificateSeq (condicional).

Este parámetro SE EXIGE si los certificados deben enviarse con el mensaje. NO DEBE estar presente si los certificados no se enviarán con el mensaje. Los certificados DEBEN estar codificados en formato binario TLV DER, según se define en la sección 7.2.3.

Cuando el mensaje se genera en respuesta a un mensaje GetCACertificates, o porque hay un nuevo certificado, la secuencia CONTENDRÁ una lista de certificados CA. La lista DEBE estar ordenada. Los certificados CVCA (de enlace y/o de raíz) SE ORDENARÁN por fecha de entrada en vigor en la secuencia. Cuando la secuencia contenga certificados con diferentes parámetros de dominio, DEBE estar presente como mínimo un certificado con parámetros de dominio incluidos para cada variante de parámetros de dominio. SE INCLUIRÁN todos los certificados CA actuales.

(Cuando el mensaje se crea en respuesta a un mensaje GetCACertificates, o porque hay un nuevo certificado, la secuencia INCLUIRÁ una lista de certificados CA. La lista DEBE estar ordenada. Los certificados CVCA (de enlace y/o de raíz) SE ORDENARÁN por fecha de entrada en vigor en la secuencia. Cuando la secuencia incluya certificados con diferentes parámetros de dominio, DEBE estar presente como mínimo un certificado con parámetros de dominio incluidos para cada variante de parámetros de dominio. SE INCLUIRÁN todos los certificados CA actuales.)

Cuando el mensaje se genera en respuesta al mensaje RequestCertificate, el contenido de la secuencia es el mismo que el descrito para la respuesta sincrónica de RequestCertificate.

(Cuando el mensaje se crea en respuesta al mensaje RequestCertificate, el contenido de la secuencia es el mismo que el descrito para la respuesta simultánea de RequestCertificate.)

Parámetros de salida:

Ninguno

Códigos de retorno:

• ok_received_correctly: El mensaje se ha recibido correctamente.

• failure_syntax: El mensaje no es correcto sintácticamente.

• failure_messageID_unknown: El messageID contenido no coincide con un mensaje enviado anteriormente.

(failure_messageID_unknown: El messageID incluido no coincide con un mensaje enviado anteriormente.)

• failure_internal_error: Error distinto de los anteriores.

8.2.3 Mensaje de obtención de certificados CA

Uso previsto:

Este mensaje es enviado por un SPOC a un SPOC extranjero para obtener todos los certificados CVCA válidos (certificados de enlace y certificados autofirmados) de ese Estado.

Parámetros de entrada:

callerID: (obligatorio)

(callerID: (obligatorio)

messageID: (obligatorio)

Este parámetro contiene la identificación del mensaje. DEBE identificar el mensaje unívocamente dentro de todos los mensajes de ese emisor. Si se envía un mensaje de respuesta al emisor como resultado de este mensaje, el mensaje de respuesta contendrá el mismo messageID. Así, un mensaje de respuesta entrante puede asignarse al mensaje original correcto. La construcción y asignación del messageID puede ser decidida por el emisor.

(messageID: (obligatorio)

Este parámetro incluye la identificación del mensaje. DEBE identificar el mensaje individualmente dentro de todos los mensajes de ese emisor. Si se envía un mensaje de respuesta al emisor como resultado de este mensaje, el mensaje de respuesta incluirá el mismo messageID. Así, un mensaje de respuesta entrante puede asignarse al mensaje original correcto. La construcción y asignación del messageID puede ser decidida por el emisor.)

Parámetros de salida:

certificateSeq: (condicional)

(certificateSeq: (condicional)

Este parámetro incluirá el resultado (uno o más certificados) después de que se procese el mensaje, si el mensaje ha sido procesado satisfactoriamente y de forma coordinada por el receptor. SE EXIGE si los certificados deben enviarse con la respuesta. NO DEBE estar presente si los certificados no se enviarán con el mensaje.)

Códigos de retorno:

• ok_cert_available: El mensaje se ha procesado satisfactoriamente y de forma sincronizada. El parámetro de salida certificateSeq contiene uno o más certificados CA.

(ok_cert_available: El mensaje se ha procesado satisfactoriamente y de forma coordinada. El parámetro de salida certificateSeq incluye uno o más certificados CA.)

• failure_syntax: El mensaje no es correcto sintácticamente.

• failure_internal_error: Error distinto de los anteriores

Observaciones:

Si el mensaje se procesa satisfactoriamente y se acepta, la CVCA DEBE enviar todos los certificados CVCA válidos dentro de la respuesta, bien en el parámetro de salida certificateSeq (procesamiento síncrono) o en el mensaje de respuesta correspondiente SendCertificates (procesamiento asíncrono).

(Si el mensaje se procesa satisfactoriamente y se acepta, la CVCA DEBE enviar todos los certificados CVCA válidos dentro de la respuesta, bien en el parámetro de salida certificateSeq (procesamiento simultáneo) o en el mensaje de respuesta correspondiente SendCertificates (procesamiento diferido).)

8.2.4 Mensajes generales

Uso previsto:

Este mensaje es enviado por un SPOC a un SPOC extranjero para transmitir una notificación u otro mensaje de texto general de lectura por seres humanos.

Parámetros de entrada:

callerID: (obligatorio)

Este parámetro contiene el identificador del Estado originador. El valor SERÁ el código de país de dos letras que figura en el Doc 9303-3. El valor de callerID DEBE ser verificado por el SPOC receptor con el valor registrado desde el SPOC originador durante su registro, incluidas las características de seguridad del mensaje (el certificado de firma digital/certificado de cliente TLS está registrado para el Estado respectivo).

(callerID: (obligatorio)

Este parámetro incluye el identificador del Estado originador. El valor SERÁ el código de país de dos letras que figura en el Doc 9303-3. El valor de callerID DEBE ser comprobado por el SPOC receptor con el valor registrado desde el SPOC originador durante su registro, incluidas las características de seguridad del mensaje (el certificado de firma digital/certificado de cliente TLS está registrado para el Estado respectivo).

messageID: (obligatorio)

(messageID: (obligatorio)

subject: (obligatorio)

Este parámetro contiene el asunto del mensaje. El asunto DEBE describir brevemente el contenido del cuerpo del mensaje. El asunto DEBE estar escrito en inglés.

(subject: (obligatorio)

Este parámetro incluye el asunto del mensaje. El asunto DEBE describir brevemente el contenido del cuerpo del mensaje. El asunto DEBE estar escrito en inglés.)

body: (obligatorio)

Este parámetro contiene el cuerpo del mensaje. El cuerpo DEBE ser un texto claro de lectura por seres humanos y no estar concebido para un procesamiento automatizado directo. El cuerpo DEBE estar escrito en inglés.

(body: (obligatorio)

Este parámetro incluye el cuerpo del mensaje. El cuerpo DEBE ser un texto claro de lectura por seres humanos y no estar destinado a un procesamiento automatizado directo. El cuerpo DEBE estar escrito en inglés.)

Códigos de retorno:

• ok: El mensaje se ha aceptado para su entrega.

• failure_syntax: El mensaje no es correcto sintácticamente.

• failure_internal_error: Error distinto de los anteriores

8.3 Servicio web

La interfaz del servicio web es la interfaz para el intercambio rutinario de datos por cable entre SPOC. La interfaz UTILIZARÁ el protocolo [SOAP] sobre [HTTPS]. La interfaz del servicio web del SPOC SE AJUSTARÁ al WSDL especificado en la sección 8.3.3.

8.3.1 Uso del SOAP

Se utilizará el protocolo [SOAP] sobre [HTTPS] puro para implementar las interfaces del servicio web. NO DEBE utilizarse ninguna otra extensión SOAP (p. ej., WS-Addressing, WS-Security, WS-Secure Conversation, WS-Authorization, WS-Federation, WSAuthorization, WS-Policy, WS-Trust, WS-Privacy, WS-Test ni otras extensiones de WS).

NO DEBE utilizarse el tipo de nodo SOAP intermediario. Solo SE UTILIZARÁ una configuración directa del SPOC cliente al SPOC servidor.

El elemento de fallo de SOAP SE UTILIZARÁ únicamente cuando se produzca un error de procesamiento de la capa de transporte que no esté cubierto por esta especificación. Los errores en el ámbito de la aplicación SE COMUNICARÁN como respuestas SOAP normales utilizando el mecanismo de error descrito para cada mensaje.

SE RECOMIENDA que la interfaz del servicio web se implemente de conformidad con [WS-IBP] y [WSI-SSBP].

(SE RECOMIENDA que la interfaz del servicio web se instale de acuerdo con [WS-IBP] y [WSI-SSBP].)

La interfaz SOAP del SPOC DEBE ser conforme a las definiciones WSDL descritas en la sección 8.3.3.

(La interfaz SOAP del SPOC DEBE ser adecuada a las definiciones WSDL descritas en la sección 8.3.3.)

8.3.2 Consideraciones relativas a la seguridad

La comunicación del servicio web del SPOC UTILIZARÁ un canal seguro y autenticado. SE UTILIZARÁ SOAP sobre HTTPS. SE UTILIZARÁ TLS v1.2.

El cliente TLS REALIZARÁ las verificaciones siguientes:

(El cliente TLS REALIZARÁ las comprobaciones siguientes:)

• el certificado de servidor SE VALIDARÁ completamente de acuerdo con [RFC5280], incluido el estado de revocación;

(el certificado de servidor SE COMPROBARÁ completamente de acuerdo con [RFC5280], incluido el estado de revocación;)

• la extensión ExtKeyUsage del certificado de servidor DEBE estar presente y CONTENDRÁ los OID correspondientes al certificado de servidor TLS del SPOC que se indican en la sección 7.2.1; y

(la extensión ExtKeyUsage del certificado de servidor DEBE estar presente e INCLUIRÁ los OID correspondientes al certificado de servidor TLS del SPOC que se indican en la sección 7.2.1; y)

• el país del certificado de servidor SERÁ igual al valor del parámetro callerID. En caso de fallo, el cliente TLS DEBE cerrar la conexión.

El servidor TLS REALIZARÁ las verificaciones siguientes:

(El servidor TLS REALIZARÁ las comprobaciones siguientes:)

• el cliente DEBE autenticarse totalmente mediante un certificado;

• el certificado de cliente SE VALIDARÁ completamente de acuerdo con [RFC5280], incluido el estado de revocación;

(el certificado de cliente SE COMPROBARÁ completamente de acuerdo con [RFC5280], incluido el estado de revocación;)

• la extensión ExtKeyUsage del certificado de cliente DEBE estar presente y CONTENDRÁ los OID correspondientes al certificado de cliente TLS del SPOC que se indican en la sección 7.2.1; y

(la extensión ExtKeyUsage del certificado de cliente DEBE estar presente e INCLUIRÁ los OID correspondientes al certificado de cliente TLS del SPOC que se indican en la sección 7.2.1; y)

• el país del certificado de cliente DEBE corresponderse con el país previsto.

En caso de que alguna de las verificaciones falle, la solicitud SE RECHAZARÁ utilizando el código de respuesta HTTP 401 Unauthorized.

(En caso de que alguna de las comprobaciones falle, la solicitud SE RECHAZARÁ utilizando el código de respuesta HTTP 401 Unauthorized.)

En el ámbito de la negociación del protocolo de enlace TLS, el cliente ADMITIRÁ todos los conjuntos de cifrado TLS definidos en la sección 4.2.2. Tanto el servidor como el cliente ADMITIRÁN la autenticación basada en RSA y ECDSA. Está permitido que un servidor solicite y también que el cliente envíe un certificado de cliente de un tipo diferente al del servidor.

El uso del acuerdo de clave ECDHE_ECDSA en el protocolo de enlace TLS es conforme las adiciones definidas en [TLSECC], [TLS1.2] y [TLSEXT]. Tanto el cliente como el servidor ADMITIRÁN las extensiones de curvas elípticas apropiadas definidas en la especificación [TLSECC] en el ámbito del protocolo de enlace TLS. Las curvas elípticas y los formatos de puntos de curva elíptica admitidos se definen en la sección 5 de [TLSECC]. El uso de los conjuntos de cifrado TLS admitidos definidos en la sección 4.2.2 que utilizan la norma de cifrado avanzado (AES) para el cifrado DEBE ser conforme a la especificación [TLSAES].

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

4.2.2 Algoritmos criptográficos para el SPOC

En la tabla 3 se muestran los conjuntos de cifrado TLS que deben usarse para el protocolo del SPOC.

Tabla 3. Conjuntos de cifrado TLS

En el ámbito de la negociación del protocolo de enlace TLS, el cliente ADMITIRÁ todos los conjuntos de cifrado TLS definidos en la tabla 3. Tanto el servidor como el cliente ADMITIRÁN la autenticación basada en RSA y ECDSA. Está permitido que un servidor solicite y también que el cliente envíe un certificado de cliente de un tipo diferente al del servidor.

(En el ámbito de la negociación del protocolo de enlace TLS, el cliente ADMITIRÁ todos los conjuntos de cifrado TLS definidos en la tabla 3. Tanto el servidor como el cliente ADMITIRÁN la autenticación basada en RSA y ECDSA. Está admitido que un servidor solicite y también que el cliente envíe un certificado de cliente de un tipo diferente al del servidor.)

El uso de la negociación de claves ECDHE_ECDSA en el protocolo de enlace TLS es conforme a las adiciones definidas en [TLSECC], [TLS1.2] y [TLSEXT]. Tanto el cliente como el servidor ADMITIRÁN las extensiones de curvas elípticas apropiadas definidas en la especificación [TLSECC] en el ámbito del protocolo de enlace TLS. Las curvas elípticas y los formatos de puntos de curva elíptica admitidos se definen en la sección 5 de [TLSECC]. El uso de los conjuntos de cifrado TLS admitidos definidos en la tabla 3 que utilizan la norma de cifrado avanzado (AES) para el cifrado DEBE ser conforme a la especificación [TLSAES].

(El uso de la negociación de claves ECDHE_ECDSA en el protocolo de enlace TLS es adecuado a las adiciones definidas en [TLSECC], [TLS1.2] y [TLSEXT]. Tanto el cliente como el servidor ADMITIRÁN las extensiones de curvas elípticas adecuadas definidas en la determinación [TLSECC] en el ámbito del protocolo de enlace TLS. Las curvas elípticas y los modelos de puntos de curva elíptica admitidos se definen en la sección 5 de [TLSECC]. El uso de los conjuntos de cifrado TLS admitidos definidos en la tabla 3 que utilizan la norma de cifrado avanzado (AES) para el cifrado DEBE ser adecuado a la determinación [TLSAES].)

(sigue la sección 8 de la Parte 12 del documento 9303)

8.3.3 WSDL para la interfaz del servicio web del SPOC

La interfaz SOAP de SPOC DEBE ajustarse a las definiciones WSDL siguientes:

<?xml version=»1.0″ encoding=»UTF-8″?>

<wsdl:definitions

xmlns:wsdl=»http://schemas.xmlsoap.org/wsdl/»

xmlns:soap=»http://schemas.xmlsoap.org/wsdl/soap/

» xmlns:xs=»http://www.w3.org/2001/XMLSchema»

xmlns:SPOC=»http://namespaces.icao.int/lds2″

targetNamespace=»http://namespaces. icao.int/lds2″>

<wsdl:types>

<xs:schema xmlns=»http://namespaces.icao.int/lds2″

targetNamespace=»http://namespaces.»

elementFormDefault=»qualified» attributeFormDefault=»unqualified»>

<xs:element name=»certificateSequence»>

<xs:complexType>

<xs:sequence>

<xs:element name=»certificate« type=«xs:base64Binary» minOccurs=»1″

maxOccurs=»unbounded»/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name=»RequestCertificateRequest»>

<xs:complexType>

<xs:sequence>

<xs:element name=»callerID» type=»xs:string»/>

<xs:element name=»messageID» type=»xs:string»/>

<xs:element name=»certificateRequest» type=»xs:base64Binary»/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name=»RequestCertificateResponse»>

<xs:complexType>

<xs:sequence>

<xs:element ref=»certificateSequence» minOccurs=»0″ maxOccurs=»1″/>

<xs:element name=»result»>

<xs:simpleType>

<xs:restriction base=»xs:string»>

<xs:enumeration value=»ok_cert_available»/>

<xs:enumeration value=»ok_reception_ack»/>

<xs:enumeration value=»failure_inner_signature»/>

<xs:enumeration value=»failure_outer_signature»/>

<xs:enumeration value=»failure_syntax»/>

<xs:enumeration value=»failure_request_not_accepted»/>

<xs:enumeration value=»failure_request_syntax»/>

<xs:enumeration value=»failure_expired»/>

<xs:enumeration value=»failure_domain_parameters»/>

<xs:enumeration value=»failure_internal_error»/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name=»SendCertificatesRequest»>

<xs:complexType>

<xs:sequence>

<xs:element name=»callerID» type=»xs:string»/>

<xs:element name=»messageID» type=»xs:string» minOccurs=»0″ maxOccurs=»1″/>

<xs:element ref=»certificateSequence» minOccurs=»0″ maxOccurs=»1″/>

<xs:element name=»statusInfo»>

<xs:simpleType>

<xs:restriction base=»xs:string»>

<xs:enumeration value=»new_cert_available_notification»/>

<xs:enumeration value=»ok_cert_available»/>

<xs:enumeration value=»failure_inner_signature»/>

<xs:enumeration value=»failure_outer_signature»/>

<xs:enumeration value=»failure_syntax»/>

<xs:enumeration value=»failure_request_not_accepted»/>

<xs:enumeration value=»failure_certificate»/>

<xs:enumeration value=»failure_internal_error»/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name=»SendCertificatesResponse»>

<xs:complexType>

<xs:sequence>

<xs:element name=»result»>

<xs:simpleType>

<xs:restriction base=»xs:string»>

<xs:enumeration value=»ok_received_correctly»/>

<xs:enumeration value=»failure_syntax»/>

<xs:enumeration value=»failure_messageID_unknown»/>

<xs:enumeration value=»failure_internal_error»/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name=»GetCACertificatesRequest»>

<xs:complexType>

<xs:sequence>

<xs:element name=»callerID» type=»xs:string»/>

<xs:element name=»messageID» type=»xs:string»/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name=»GetCACertificatesResponse»>

<xs:complexType>

<xs:sequence>

<xs:element ref=»certificateSequence» minOccurs=»0″ maxOccurs=»1″/>

<xs:element name=»result»>

<xs:simpleType>

<xs:restriction base=»xs:string»>

<xs:enumeration value=»ok_cert_available»/>

<xs:enumeration value=»ok_reception_ack»/>

<xs:enumeration value=»failure_syntax»/>

<xs:enumeration value=»failure_internal_error»/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name=»GeneralMessageRequest»>

<xs:complexType>

<xs:sequence>

<xs:element name=»callerID» type=»xs:string»/>

<xs:element name=»messageID» type=»xs:string»/>

<xs:element name=»subject» type=»xs:string»/>

<xs:element name=»body» type=»xs:string»/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name=»GeneralMessageResponse»>

<xs:complexType>

<xs:sequence>

<xs:element name=»result»>

<xs:simpleType>

<xs:restriction base=»xs:string»>

<xs:enumeration value=»ok»/>

<xs:enumeration value=»failure_syntax»/>

<xs:enumeration value=»failure_internal_error»/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

</wsdl:types>

<wsdl:message name=»RequestCertificateRequest»>

<wsdl:part name=»RequestCertificateRequest» element=»SPOC:RequestCertificateRequest»/>

</wsdl:message>

<wsdl:message name=»RequestCertificateResponse»>

<wsdl:part name=»RequestCertificateResponse» element=»SPOC:RequestCertificateResponse»/>

</wsdl:message>

<wsdl:message name=»SendCertificatesRequest»>

<wsdl:part name=»SendCertificatesRequest» element=»SPOC:SendCertificatesRequest»/>

</wsdl:message>

<wsdl:message name=»SendCertificatesResponse»>

<wsdl:part name=»SendCertificatesResponse» element=»SPOC:SendCertificatesResponse»/>

</wsdl:message>

<wsdl:message name=»GetCACertificatesRequest»>

<wsdl:part name=»GetCACertificatesRequest» element=»SPOC:GetCACertificatesRequest»/>

</wsdl:message>

<wsdl:message name=»GetCACertificatesResponse»>

<wsdl:part name=»GetCACertificatesResponse» element=»SPOC:GetCACertificatesResponse»/>

</wsdl:message>

<wsdl:message name=»GeneralMessageRequest»>

<wsdl:part name=»GeneralMessageRequest» element=»SPOC:GeneralMessageRequest»/>

</wsdl:message>

<wsdl:message name=»GeneralMessageResponse»>

<wsdl:part name=»GeneralMessageResponse» element=»SPOC:GeneralMessageResponse»/>

</wsdl:message>

<wsdl:portType name=»SPOCPortType»>

<wsdl:operation name=»RequestCertificate»>

<wsdl:input message=»SPOC:RequestCertificateRequest»/>

<wsdl:output message=»SPOC:RequestCertificateResponse»/>

</wsdl:operation>

<wsdl:operation name=»SendCertificates»>

<wsdl:input message=»SPOC:SendCertificatesRequest»/>

<wsdl:output message=»SPOC:SendCertificatesResponse»/>

</wsdl:operation>

<wsdl:operation name=»GetCACertificates»>

<wsdl:input message=»SPOC:GetCACertificatesRequest»/>

<wsdl:output message=»SPOC:GetCACertificatesResponse»/>

</wsdl:operation>

<wsdl:operation name=»GeneralMessage»>

<wsdl:input message=»SPOC:GeneralMessageRequest»/>

<wsdl:output message=»SPOC:GeneralMessageResponse»/>

</wsdl:operation>

</wsdl:portType>

<wsdl:binding name=»SPOCSOAPBinding» type=»SPOC:SPOCPortType»>

<soap:binding style=»document» transport=»http://schemas.xmlsoap.org/soap/http»/>

<wsdl:operation name=»RequestCertificate»>

<soap:operation soapAction=»RequestCertificate»/>

<wsdl:input>

<soap:body parts=»RequestCertificateRequest» use=»literal»/>

</wsdl:input>

<wsdl:output>

<soap:body parts=»RequestCertificateResponse» use=»literal»/>

</wsdl:output>

</wsdl:operation>

<wsdl:operation name=»SendCertificates»>

<soap:operation soapAction=»SendCertificates»/>

<wsdl:input>

<soap:body parts=»SendCertificatesRequest» use=»literal»/>

</wsdl:input>

<wsdl:output>

<soap:body parts=»SendCertificatesResponse» use=»literal»/>

</wsdl:output>

</wsdl:operation>

<wsdl:operation name=»GetCACertificates»>

<soap:operation soapAction=»GetCACertificates»/>

<wsdl:input>

<soap:body parts=»GetCACertificatesRequest» use=»literal»/>

</wsdl:input>

<wsdl:output>

<soap:body parts=»GetCACertificatesResponse» use=»literal»/>

</wsdl:output>

</wsdl:operation>

<wsdl:operation name=»GeneralMessage»>

<soap:operation soapAction=»GeneralMessage»/>

<wsdl:input>

<soap:body parts=»GeneralMessageRequest» use=»literal»/>

</wsdl:input>

<wsdl:output>

<soap:body parts=»GeneralMessageResponse» use=»literal»/>

</wsdl:output>

</wsdl:operation>

</wsdl:binding>

<wsdl:service name=»SPOC»>

<wsdl:port name=»SPOCPort» binding=»SPOC:SPOCSOAPBinding»>

<soap:address location=»http://spoc-server/SPOC»/>

</wsdl:port>

</wsdl:service>

</wsdl:definitions>

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

El sistema de inspección UTILIZARÁ la clave pública verificada de firmante para verificar la firma del objeto de datos. (El sistema de inspección UTILIZARÁ la clave pública comprobada de firmante para comprobar la firma del objeto de datos.)

Nota.— Este procedimiento puede omitirse en el caso de los objetos de datos cuya autenticidad el Estado receptor o la organización receptora no consideran relevante para el proceso de inspección.

Y en la sección 8 de la Parte 11 del documento 9303 se recoge:

8. SISTEMA DE INSPECCIÓN

Para apoyar el funcionamiento requerido y las opciones definidas que pueden implantarse en los eMRTD que se ofrecerán, el sistema de inspección deberá satisfacer ciertas condiciones previas.

(Para apoyar el funcionamiento exigido y las opciones definidas que pueden instalarse en los eMRTD que se ofrecerán, el sistema de inspección deberá satisfacer ciertos requisitos previos.)

8.1 Control de acceso de base

Los sistemas de inspección que apoyen el control de acceso de base DEBEN satisfacer las siguientes condiciones previas:

(Los sistemas de inspección que apoyen el control de acceso de base DEBEN satisfacer los siguientes requisitos previos:)

El sistema de inspección está equipado con medios para adquirir la ZLM del documento físico a efectos de obtener las claves de acceso de base al documento (KEnc y KMAC) del eMRTD.

El soporte lógico del sistema de inspección apoya el protocolo descrito en la sección 4.3, en caso de que se ofrezca al sistema un eMRTD con control de acceso de base, incluyendo el cifrado del canal de comunicación con construcción segura de mensajes.

8.2 Establecimiento de conexión autenticada por contraseña

Los sistemas de inspección PACE DEBEN satisfacer las siguientes condiciones previas:

(Los sistemas de inspección PACE DEBEN satisfacer los siguientes requisitos previos:)

El sistema de inspección está equipado con medios para adquirir la ZLM o el CAN del documento físico.
El soporte lógico del sistema de inspección apoya el protocolo descrito en la sección 4.4, en el caso de que se ofrezca al sistema un eMRTD con PACE, incluyendo el cifrado del canal de comunicación con construcción segura de mensajes.

8.3 Autenticación pasiva

Para poder realizar la autenticación pasiva de los datos almacenados en el CI sin contacto del eMRTD, el sistema de inspección debe tener el conocimiento de la información de claves de los Estados expedidores u organizaciones expedidoras:

(Para poder realizar la autenticación pasiva de los datos almacenados en el CI sin contacto del eMRTD, el sistema de inspección debe tener el conocimiento de la información de claves de los Estados emisores u organizaciones emisoras:)

Para cada Estado emisor u organización emisora, el certificado de CA de firma de país o la información pertinente extraída del certificado se ALMACENARÁ en condiciones de seguridad en el sistema de inspección.

Alternativamente, para cada Estado expedidor u organización expedidora, los certificados del firmante del documento (CDS) o la información pertinente extraída de los certificados se ALMACENARÁ en condiciones de seguridad en el sistema de inspección.

Antes de utilizar una clave pública de CA de firma de país de un Estado expedidor u organización expedidora, el Estado receptor u organización receptora DEBE establecer confianza en esa clave.

(Antes de utilizar una clave pública de CA de firma de país de un Estado emisor u organización emisora, el Estado receptor u organización receptora DEBE establecer confianza en esa clave.)

Antes de utilizar un certificado del firmante del documento (CDS) para verificación de un SOD, el sistema de inspección VERIFICARÁ su firma digital, utilizando la clave pública de CA de firma de país.

(Antes de utilizar un certificado del firmante del documento (CDS) para comprobación de un SOD (Document Security Object = Objeto de seguridad de documento), el sistema de inspección COMPROBARÁ su firma digital, utilizando la clave pública de CA de firma de país.)

Además, los sistemas de inspección TENDRÁN acceso a la información de revocación verificada.

(Además, los sistemas de inspección TENDRÁN acceso a la información de revocación comprobada.)

8.4 Autenticación activa

El apoyo de autenticación activa en los sistemas de inspección es OPCIONAL.

Si el sistema de inspección apoya la autenticación active, se EXIGE que el sistema de inspección tenga capacidad de leer la ZLM visual.

Si el sistema de inspección apoya la autenticación activa, el soporte lógico del sistema de inspección APOYARÁ el protocolo de autenticación activa que se describe en la sección 6.1.

8.5 Autenticación de microplaqueta

El apoyo de autenticación de microplaqueta en los sistemas de inspección es OPCIONAL.

Si el sistema de inspección apoya la autenticación de microplaqueta, SE EXIGE que el sistema de inspección tenga capacidad de leer la ZLM visual.

Si el sistema de inspección apoya la autenticación de microplaqueta, el soporte lógico del sistema de inspección APOYARÁ el protocolo de autenticación de microplaqueta que se describe en la sección 6.2.

8.6 Autenticación del terminal

La admisión de la autenticación del terminal por los sistemas de inspección es OPCIONAL.

Si el sistema de inspección admite la autenticación del terminal, SE EXIGE que el sistema de inspección tenga capacidad para almacenar la clave privada del sistema de inspección en condiciones de seguridad. El sistema de inspección DEBE tener acceso a su DV a intervalos regulares para renovar el certificado de terminal.

Si el sistema de inspección admite la autenticación del terminal, el programa informático del sistema de inspección ADMITIRÁ el protocolo de autenticación del terminal descrito en la sección 7.1.

La sección 7 de la Parte 11 del documento 9303 recoge:

7. MECANISMOS DE CONTROL DE ACCESO ADICIONALES

Los datos personales almacenados en el CI sin contacto definidos como mínimo obligatorio para interfuncionamiento mundial son la ZLM y la imagen almacenada en forma digital del rostro del titular. Ambos elementos también pueden verse (leerse) visualmente después de abierto el eMRTD y presentado para inspección.

Además de la imagen facial almacenada en forma digital como principal característica biométrica para interfuncionamiento mundial, la OACI ha aprobado el uso de imágenes de dedos o iris almacenadas en forma digital además del rostro. Para uso nacional o bilateral, los Estados PUEDEN optar por almacenar plantillas o pueden optar por limitar el acceso a estos datos o cifrarlos, según decidan los propios Estados.

El acceso a estos datos personales más sensibles DEBERÍA ser más restringido. Esto puede lograrse de dos maneras: mediante la ampliación del control de acceso o el cifrado de los datos. En la sección 7.1 se define la autenticación del terminal como un mecanismo interoperable para el control de acceso ampliado. Si no se exige la interoperabilidad, pueden usarse otros mecanismos.

(El acceso a estos datos personales más sensibles DEBERÍA ser más restringido. Esto puede lograrse de dos maneras: mediante la ampliación del control de acceso o el cifrado de los datos. En la sección 7.1 se define la autenticación del terminal como un mecanismo compatible para el control de acceso ampliado. Si no se exige el interfuncionamiento, pueden usarse otros mecanismos.)

7.1 Autenticación del terminal

El mecanismo de autenticación del terminal es CONDICIONAL. Para las aplicaciones LDS2 se EXIGE la implementación. La autenticación del terminal PUEDE usarse para proteger las características biométricas secundarias en la aplicación eMRTD.

El protocolo de autenticación del terminal es un protocolo de dos pasos, interrogación-respuesta, que proporciona una autenticación unilateral explícita del terminal. Se basa en el control de acceso ampliado, según se especifica en [TR-03110]. Si el IC admite este protocolo, este DEBE admitir la autenticación de microplaqueta o PACE con correspondencia de autenticación de microplaqueta.

(El protocolo de autenticación del terminal es un protocolo de dos pasos, interrogación-respuesta, que facilita una autenticación unilateral explícita del terminal. Se basa en el control de acceso ampliado, según se especifica en [TR-03110]. Si el IC admite este protocolo, este DEBE admitir la autenticación de microplaqueta o PACE con correspondencia de autenticación de microplaqueta.)

Este protocolo permite que el IC verifique si el terminal está habilitado para acceder a datos sensibles. Como el terminal puede acceder luego a datos sensibles, toda comunicación ulterior DEBE protegerse adecuadamente. Así pues, la autenticación del terminal también autentica una clave pública efímera, elegida por el terminal, que se usa para la mensajería segura con autenticación de microplaqueta o PACE con correspondencia de autenticación de microplaqueta. El IC DEBE vincular los derechos de acceso del terminal a la mensajería segura establecida por la clave pública efímera

autenticada del terminal.

(Este protocolo permite que el IC compruebe si el terminal está habilitado para acceder a datos sensibles. Como el terminal puede acceder luego a datos sensibles, toda comunicación posterior DEBE protegerse adecuadamente. Así pues, la autenticación del terminal también autentica una clave pública efímera, elegida por el terminal, que se usa para la mensajería segura con autenticación de microplaqueta o PACE con correspondencia de autenticación de microplaqueta. El IC DEBE enlazar los derechos de acceso del terminal a la mensajería segura establecida por la clave pública efímera autenticada del terminal.)

El IC PUEDE apoyar la autenticación del terminal en el fichero maestro y/o la aplicación eMRTD. Si la autenticación del terminal se usa para proteger los grupos de datos de otras aplicaciones que no sean la aplicación eMRTD, el IC DEBE admitir la autenticación del terminal en el fichero maestro.

Nota.— Si se exige la compatibilidad con el control de acceso ampliado de la Unión Europea [TR-03110], el IC DEBE admitir la autenticación del terminal en la aplicación eMRTD.

7.1.2 Especificación del protocolo

Las siguientes etapas son ejecutadas por el terminal y el IC:

El terminal envía una cadena de certificado al IC. La cadena empieza con un certificado verificable cuya clave pública de la autoridad de certificación de verificación de país (CVCA) está almacenada en la microplaqueta y termina con el certificado de terminal.

El IC verifica los certificados y extrae la clave pública PKIFD del terminal.

El IC elige al azar un interrogante rIC y lo envía al terminal.
El terminal responde con la firma sIFD = Sign(SKIFD, IDIC||rIC||Comp(PKDH,IFD)).
El IC comprueba que Verify(PKIFD, sIFD, IDIC ||rIC||Comp(PKDH,IFD)) = verdadero.

Nota.— La clave PKDH,IFD se genera durante la autenticación de microplaqueta o PACE con correspondencia de autenticación de microplaqueta. Si se genera más de una clave (p. ej., la autenticación de microplaqueta se realiza después del PACE con correspondencia de autenticación de microplaqueta), DEBE usarse la clave más reciente.

(Nota.— La clave PKDH,IFD se crea durante la autenticación de microplaqueta o PACE con correspondencia de autenticación de microplaqueta. Si se crea más de una clave (p. ej., la autenticación de microplaqueta se realiza después del PACE con correspondencia de autenticación de microplaqueta), DEBE usarse la clave más reciente.)

En este protocolo, IDIC es un identificador del IC:

• Si se usa BAC, IDIC es el número de documento del eMRTD contenido en la ZLM, incluido el dígito de verificación.

(Si se usa BAC, IDIC es el número de documento del eMRTD incluido en la ZLM, incluido el dígito de comprobación.)

• Si se usa PACE, IDIC se calcula usando la clave pública efímera PACE, i.e. IDIC = Comp(PKDH,IC).

(Si se usa PACE, IDIC se calcula usando la clave pública efímera PACE, es decir IDIC = Comp(PKDH,IC).)

Nota.— Se EXIGE la ejecución correcta del protocolo PACE antes de que pueda realizarse la autenticación del terminal en el fichero maestro.

A continuación se muestra una versión simplificada:

Figura 4. Autenticación del terminal

7.1.3 Estado de seguridad

Si la autenticación del terminal se llevó a cabo correctamente, el IC OTORGARÁ acceso a datos sensibles almacenados con arreglo a la autorización efectiva del terminal autenticado. Si la autorización efectiva no otorga derechos de acceso a ningún dato de una aplicación LDS2, la selección de esta aplicación DEBE ser rechazada por el IC.

(Si la autenticación del terminal se llevó a cabo correctamente, el IC AUTORIZARÁ acceso a datos sensibles almacenados de acuerdo con la autorización efectiva del terminal autenticado. Si la autorización efectiva no atribuye derechos de acceso a ningún dato de una aplicación LDS2, la selección de esta aplicación DEBE ser rechazada por el IC.)

No obstante, el IC RESTRINGIRÁ los derechos de acceso del terminal a la mensajería segura establecida por la clave pública efímera autenticada, i. e. la clave pública efímera proporcionada por el terminal como parte de la autenticación de microplaqueta o PACE con correspondencia de autenticación de microplaqueta. El IC NO DEBE aceptar que se realice más de una ejecución de autenticación del terminal en la misma sesión (cf. Véase la definición de “sesión” en la sección 9.8.1 y la sección 9.8.3).

(Aun así, el IC LIMITARÁ los derechos de acceso del terminal a la mensajería segura establecida por la clave pública breve autenticada, es decir, la clave pública breve facilitada por el terminal como parte de la autenticación de microplaqueta o PACE con correspondencia de autenticación de microplaqueta. El IC NO DEBE aceptar que se realice más de una ejecución de autenticación del terminal en la misma sesión (cf. Véase la definición de “sesión” en la sección 9.8.1 y la sección 9.8.3).)

Nota 1.— Los derechos de acceso son válidos siempre que esté activa la mensajería segura establecida por las claves públicas efímeras autenticadas, así el estado de seguridad no se ve afectado por la selección de aplicaciones o su eliminación de la selección.

Nota 2.— La mensajería segura no se ve afectada por la autenticación del terminal. La microplaqueta del eMRTD RETENDRÁ los mensajes seguros aun cuando la autenticación del terminal falle (a menos que se produzca un error de la mensajería segura).

7.1.4 Especificaciones criptográficas

7.1.4.1 Autenticación del terminal con RSA

Para la autenticación del terminal con RSA, DEBEN usarse los siguientes algoritmos y formatos.

(Para la autenticación del terminal con RSA (Rivest, Shamir and Adleman), DEBEN usarse los siguientes algoritmos y modelos.)

7.1.4.1.1 Algoritmo de firma

Se USARÁ RSA [RFC-3447], [PKCS#1] según se especifica en la tabla 7.

Tabla 7. Identificadores de objeto para la autenticación del terminal con RSA

Los parámetros por defecto que han de usarse con RSA-PSS se definen de la siguiente manera:

• Algoritmo de condensación: El algoritmo de condensación se selecciona con arreglo a la tabla 7.

• Algoritmo de generación de máscaras: MGF1 [RFC-3447], [PKCS#1] mediante el uso del algoritmo de condensación seleccionado.

• Longitud del salt: longitud de octetos del resultado del algoritmo de condensación seleccionado.

• Indicador de fin: 0xBC

7.1.4.1.2 Formato de clave pública

Se USARÁ el formato TLV [ISO/IEC 7816-8] descrito en el Doc 9303-12.

• El identificador de objeto se TOMARÁ de la tabla 7.

• La longitud de bits del módulo SERÁ de 2 048 o 3 072.

• La longitud de bits del exponente SERÁ como mucho de 32.

7.1.4.1.3 Clave pública comprimida

La clave pública efímera comprimida Comp(PKDH,IFD) del terminal se define como la condensación SHA-1 del valor público DH, i. e. una cadena de octetos de longitud fija 20.

(La clave pública breve comprimida Comp(PKDH,IFD) del terminal se define como la condensación SHA-1 del valor público DH, es decir, una cadena de octetos de longitud fija 20.)

7.1.4.2 Autenticación del terminal con el ECDSA

Para la autenticación del terminal con el ECDSA, DEBEN usarse los siguientes algoritmos y formatos.

7.1.4.2.1 Algoritmo de firma

El ECDSA se usará con el formato de firma de texto plano [TR-03111] especificado en la tabla 8.

Tabla8. Identificadores de objeto para la autenticación del terminal con el ECDSA

7.1.4.2.2 Formato de clave pública

SE USARÁ el formato TLV [ISO/IEC 7816-8] descrito en el Doc 9303-12.

• El identificador de objeto SE TOMARÁ de la tabla 8.

• La longitud de bits de la curva SERÁ de 224, 256, 320, 384 o 512.

• Los parámetros de dominio SERÁN conformes al [TR-03111].

7.1.4.2.3 Compresión de clave pública

La clave pública efímera comprimida Comp(PKDH,IFD) del terminal se define como la coordenada x del punto público ECDH, i. e. una cadena de octetos de longitud fija ⌈log256p⌉.

(La clave pública breve comprimida Comp(PKDH,IFD) del terminal se define como la coordenada x del punto público ECDH, es decir, una cadena de octetos de longitud fija ⌈log256p⌉.)

7.1.4.3 Validación de la certificación

Para validar un certificado de terminal, el IC DEBE proporcionarse con una cadena de certificado que empieza en un punto de confianza almacenado en el IC. Esos puntos de confianza son claves públicas más o menos recientes de la CVCA del IC.

(Para comprobar un certificado de terminal, el IC (Integrated Circuit = Circuito integrado) DEBE facilitarse con una cadena de certificado que empieza en un punto de confianza almacenado en el IC. Esos puntos de confianza son claves públicas más o menos recientes de la CVCA del IC.)

7.1.4.3.1 Estado inicial del/de los punto(s) de confianza del IC

El/los punto(s) de confianza inicial(es) SE ALMACENARÁN en condiciones de seguridad en la memoria del IC en la producción de la fase de(pre)personalización.

El agente de (pre)personalización SE ENCARGARÁ DE:

• fijar la fecha corriente del IC en la fecha de la (pre)personalización; y

• personalizar la clave CVCA con la fecha efectiva más reciente como punto de confianza.

El agente de (pre)personalización PUEDE además personalizar la llave previa CVCA como punto de confianza.

(El agente de (pre)personalización PUEDE además personalizar la clave previa CVCA (Country Verifying Certification Authority = Autoridad de certificación de verificación de país) como punto de confianza.)

7.1.4.3.2 Certificados de enlace

Como el par de claves utilizado por la CVCA cambia con el tiempo, tienen que producirse certificados de enlace CVCA. Los certificados de enlace CVCA DEBEN firmarse con la clave CVCA previa, i. e. la clave CVCA con la fecha efectiva más reciente. Se EXIGE que el IC actualice internamente su(s) punto(s) de confianza con arreglo a los certificados de enlace válidos recibidos.

(Como el par de claves utilizado por la CVCA cambia con el tiempo, tienen que producirse certificados de enlace CVCA. Los certificados de enlace CVCA DEBEN firmarse con la clave CVCA previa, es decir, la clave CVCA con la fecha efectiva más reciente. Se EXIGE que el IC actualice internamente su(s) punto(s) de confianza de acuerdo con los certificados de enlace válidos recibidos.)

El IC DEBE ser capaz de almacenar hasta dos puntos de confianza.

Nota.— Debido a la programación de los certificados de enlace CVCA (véase el Doc 9303-12), como mucho es necesario almacenar dos puntos de confianza en el IC.

7.1.4.3.3 Fecha actual

El IC DEBE aceptar certificados de enlace CVCA caducados, pero NO DEBE aceptar certificados DV ni de terminal caducados. Para determinar si un certificado está caducado, el IC USARÁ su fecha actual.

(El IC DEBE aceptar certificados de enlace CVCA caducados, pero NO DEBE aceptar certificados DV (Document Verifier = Verificador del documento) ni de terminal caducados. Para determinar si un certificado está caducado, el IC USARÁ su fecha actual.)

Fecha actual : Si el IC no tiene un reloj interno, la fecha actual del IC SE APROXIMARÁ de la siguiente manera. El IC aproxima la fecha de forma autónoma utilizando la fecha efectiva del certificado más reciente, contenida en un certificado de enlace a la CVCA válido, un certificado DV o un certificado de terminal preciso.

(Fecha actual: Si el IC no tiene un reloj interno, la fecha actual del IC SE APROXIMARÁ de la siguiente manera. El IC aproxima la fecha de forma autónoma utilizando la fecha efectiva del certificado más reciente, incluida en un certificado de enlace a la CVCA válido, un certificado DV o un certificado de terminal preciso.)

Certificado de terminal preciso: Un certificado de terminal es preciso si el IC confía en la autoridad expedidora del verificador del documento (DV) para producir certificados de terminal con la fecha efectiva correcta del certificado. Los certificados de enlace CVCA, los certificados DV y los certificados de terminal expedidos por un DV nacional SERÁN CONSIDERADOS precisos por el IC. Otros certificados NO DEBEN considerarse exactos.

(Certificado de terminal preciso: Un certificado de terminal es preciso si el IC confía en la autoridad emisora del comprobador del documento (DV) para producir certificados de terminal con la fecha efectiva correcta del certificado. Los certificados de enlace CVCA, los certificados DV y los certificados de terminal emitidos por un DV nacional SERÁN CONSIDERADOS precisos por el IC. Otros certificados NO DEBEN considerarse exactos.)

Un terminal PUEDE enviar certificados de enlace CVCA, certificados DV y certificados de terminal a un IC para actualizar la fecha actual y el punto de confianza almacenado en el IC aun cuando no tenga intención o no sea capaz de seguir con la autenticación del terminal.

Nota.— El IC solo verifica que un certificado sea aparentemente reciente (i. e. con respecto a la fecha actual aproximada), a menos que el IC contenga un reloj interno.

(Nota.— El IC solo comprueba que un certificado sea aparentemente reciente (es decir, con respecto a la fecha actual aproximada), a menos que el IC tenga un reloj interno.)

7.1.4.3.4 Procedimiento de validación general

El procedimiento de validación del certificado consiste en tres etapas:

(El procedimiento de aprobación del certificado consiste en tres etapas:)

Verificación del certificado: La firma DEBE ser válida y, a menos que el certificado sea un certificado de enlace CVCA, el certificado NO DEBE estar caducado. Si falla la verificación, se INTERRUMPIRÁ el procedimiento.

Nota.— Solo puede darse el caso de que un certificado de enlace CVCA esté caducado si el IC tiene una fuente de tiempo que supere a la fecha actual aproximada descrita anteriormente.

Actualización del estado interno: La fecha actual DEBE estar actualizada, la clave pública y los atributos (incluidas las ampliaciones de certificados pertinentes) DEBEN ser importados, DEBEN activarse nuevos puntos de confianza y DEBEN desactivarse puntos de confianza caducados para la verificación de certificados DV.

Limpieza: La microplaqueta PROPORCIONARÁ como máximo dos puntos de confianza activados por aplicación. Si permanecen activados más de dos puntos de confianza para una aplicación después de la actualización del estado interno, se DESACTIVARÁ el punto de confianza con la fecha efectiva menos reciente.

La operación de actualizar la fecha actual y las operaciones de activar y desactivar un punto de confianza DEBEN implementarse como una operación atómica.

Activación de un punto de confianza: se AÑADIRÁ el nuevo punto de confianza a la lista de puntos de confianza.

Desactivación de un punto de confianza: Los puntos de confianza caducados NO DEBEN usarse para la verificación de los certificados DV. En el caso de los IC en los que la fecha actual pueda superar a la fecha de caducidad de un punto de confianza, p. ej., los IC que usan un reloj interno, los puntos de confianza caducados DEBEN seguir siendo utilizables para la verificación de los certificados de enlace CVCA. Los puntos de confianza desactivados PUEDEN borrarse después de importarse correctamente el certificado de enlace sucesivo.

(Desactivación de un punto de confianza: Los puntos de confianza caducados NO DEBEN usarse para la comprobación de los certificados DV. En el caso de los IC en los que la fecha actual pueda superar a la fecha de caducidad de un punto de confianza, p. ej., los IC que usan un reloj interno, los puntos de confianza caducados DEBEN seguir siendo utilizables para la comprobación de los certificados de enlace CVCA. Los puntos de confianza desactivados PUEDEN borrarse después de cargarse correctamente el certificado de enlace siguiente.)

7.1.4.3.5 Ejemplo de procedimiento de validación

El siguiente procedimiento de validación, proporcionado a modo de ejemplo, PUEDE usarse para validar una cadena de certificados. Para cada certificado recibido el IC ejecuta las etapas siguientes:

(El siguiente procedimiento de comprobación, facilitado a modo de ejemplo, PUEDE usarse para comprobar una cadena de certificados. Para cada certificado recibido el IC ejecuta las etapas siguientes:)

El IC verifica la firma del certificado. Si la firma es incorrecta, fracasa la verificación.

Si el certificado no es un certificado de enlace CVCA, su fecha de caducidad se compara con la fecha actual del IC. Si la fecha de caducidad precede a la fecha corriente, la verificación falla.

Se da por válido el certificado y se importan la clave pública y los atributos (incluidas las ampliaciones pertinentes del certificado) que contiene el certificado.

• Para la CVCA, el DV y los certificados de terminal precisos: La fecha efectiva del certificado se compara con la fecha actual del IC. Si la fecha actual precede a la fecha efectiva, la fecha corriente se actualiza a la fecha efectiva.

• Para los certificados de enlace CVCA: La nueva clave pública de la CVCA se añade a la lista de puntos de confianza almacenados en condiciones de seguridad en la memoria del IC. Y entonces se procede a activar el nuevo punto de confianza.

• Para los certificados DV y certificados de terminal: La nueva clave pública del DV o del terminal se importa temporalmente para la ulterior verificación del certificado o la autenticación del terminal, respectivamente.

Los puntos de confianza caducados que están almacenados en condiciones de seguridad en la memoria del IC se desactivan para la verificación de los certificados DV y pueden suprimirse de la lista de puntos de confianza.

7.1.4.3.6 Autorización efectiva

Cada certificado CONTENDRÁ una plantilla de autorización de la persona titular del certificado (véase el Doc 9303-12) y PUEDE contener ampliaciones de autorización (véase el Doc 9303-12, sección 7.2.2.6).

(Cada certificado INCLUIRÁ una plantilla de autorización de la persona titular del certificado (véase el Doc 9303-12) y PUEDE incluir ampliaciones de autorización (véase el Doc 9303-12, sección 7.2.2.6).)

• En la plantilla de autorización de la persona titular del certificado se identifica el tipo de terminal (esta especificación solo considera los sistemas de inspección, pero otras especificaciones pueden usar diferentes tipos de terminal).

(En la plantilla de autorización de la persona titular del certificado se identifica el tipo de terminal (esta especificación solo atiende a los sistemas de inspección, pero otras especificaciones pueden usar diferentes tipos de terminal).)

• La plantilla de autorización de la persona titular del certificado y las ampliaciones de autorización determinan la autorización relativa de la persona titular del certificado asignada por la autoridad que expide el certificado.

(La plantilla de autorización de la persona titular del certificado y las ampliaciones de autorización determinan la autorización relativa de la persona titular del certificado asignada por la autoridad que emite el certificado.)

Para determinar la autorización efectiva de la persona titular de un certificado, el IC DEBE calcular un operador booleano “Y” a nivel de bit de la autorización relativa contenida en el certificado de terminal, el certificado DV referenciado y el certificado de la CVCA referenciado.

El IC INTERPRETARÁ la autorización efectiva de la siguiente manera:

• La función efectiva es una CVCA:

Este certificado de enlace fue expedido por la CVCA nacional.

El IC DEBE actualizar su punto de confianza interno, i. e. la clave pública y la autorización efectiva.

El expedidor de certificado es una fuente fiable de tiempo y el IC DEBE actualizar su fecha actual usando la fecha efectiva del certificado.

El IC NO DEBE otorgar el acceso de la CVCA a los datos sensibles (i.e. DEBERÍA hacerse caso omiso de la autorización efectiva).

• La función efectiva es un DV:

El certificado fue expedido por la CVCA nacional para un DV autorizado. (El certificado fue emitido por la CVCA nacional para un DV autorizado.)

El expedidor de certificado es una fuente fiable de tiempo y el IC DEBE actualizar su fecha actual usando la fecha efectiva del certificado.

El IC NO DEBE otorgar un acceso DV a datos sensibles (i. e. DEBERÍA hacerse caso omiso de la autorización efectiva).

• La función efectiva es un terminal:

El certificado fue expedido por un DV nacional o extranjero.

Si el certificado es un certificado de terminal preciso (cf. sección 7.1.4.3.3), el expedidor es una fuente fiable de tiempo y el IC DEBE actualizar su fecha actual usando la fecha efectiva del certificado.

El IC DEBE otorgar el acceso del terminal autenticado a los datos sensibles con arreglo a la autorización efectiva.

Nota.— La plantilla de autorización de la persona titular del certificado y las ampliaciones de la autorización pueden contener bits no asignados a un derecho de acceso (bits RFU). El IC no DEBE tener en cuenta esos bits durante la evaluación de los derechos de acceso.

7.1.4.3.7 Importación de la clave pública

Las claves públicas importadas por el procedimiento de validación de certificado se almacenan permanente o temporalmente en el IC.

(Las claves públicas cargadas por el procedimiento de comprobación de certificado se almacenan permanente o temporalmente en el IC.)

El IC DEBERÍA rechazar la importación de una clave pública si ya conoce la referencia de la persona titular del certificado.

(El IC DEBERÍA rechazar la carga de una clave pública si ya conoce la referencia de la persona titular del certificado.)

Importación permanente: El IC IMPORTARÁ de forma permanente las llaves públicas contenidas en los certificados de enlace CVCA, que DEBERÁN almacenarse en condiciones de seguridad en la memoria del IC. Una llave pública importada de forma permanente y sus metadatos DEBERÁN CUMPLIR las siguientes condiciones:

(Importación permanente: El IC INSTALARÁ de forma permanente las llaves públicas incluidas en los certificados de enlace CVCA, que DEBERÁN almacenarse en condiciones de seguridad en la memoria del IC. Una llave pública instalada de forma permanente y sus metadatos DEBERÁN CUMPLIR los siguientes requisitos:)

• Una vez caducada PUEDE sobrescribirse con una clave pública importada posteriormente de forma permanente.

(Una vez caducada PUEDE sobrescribirse con una clave pública instalada posteriormente de forma permanente.)

• DEBE sobrescribirse con la clave pública importada posteriormente de forma permanente con la misma referencia de persona titular del certificado o DEBE rechazarse la importación.

(DEBE sobrescribirse con la clave pública instalada posteriormente de forma permanente con la misma referencia de persona titular del certificado o DEBE rechazarse la instalación.)

• NO DEBE sobrescribirse con una clave pública importada temporalmente.

(NO DEBE sobrescribirse con una clave pública instalada temporalmente.)

Activar y desactivar una clave pública importada de forma permanente DEBE ser una operación atómica.

(Activar y desactivar una clave pública instalada de forma permanente DEBE ser una operación atómica.)

Importación temporal: El IC IMPORTARÁ temporalmente las llaves públicas contenidas en los certificados DV y de terminal.

(Instalación temporal: El IC INSTALARÁ temporalmente las llaves públicas incluidas en los certificados DV y de terminal.)

Una clave pública importada temporalmente y sus metadatos DEBERÁN CUMPLIR las siguientes condiciones:

(Una clave pública instalada temporalmente y sus metadatos DEBERÁN CUMPLIR los siguientes requisitos:)

• NO SERÁ seleccionable ni utilizable si el IC ha sido inhabilitado.

• DEBE seguir siendo utilizable hasta que se complete correctamente la subsiguiente operación criptográfica (i. e. PSO:Verify certificate o External authenticate).

(DEBE seguir siendo utilizable hasta que se complete correctamente la siguiente operación criptográfica (es decir, PSO:Verify certificate o External authenticate).)

• PUEDE sobrescribirse con una clave pública temporalmente importada ulteriormente.

(PUEDE sobrescribirse con una clave pública temporalmente instalada posteriormente.)

Un terminal NO DEBE hacer uso de ninguna clave pública importada temporalmente, sino de la importada más recientemente.

(Un terminal NO DEBE hacer uso de ninguna clave pública instalada temporalmente, sino de la instalada más recientemente.)

Metadatos importados: Para cada clave pública importada de forma permanente o temporal, DEBEN almacenarse los siguientes datos adicionales contenidos en el certificado (véase el Doc 9303-12).

(Metadatos importados: Para cada clave pública instalada de forma permanente o temporal, DEBEN almacenarse los siguientes datos adicionales incluidos en el certificado (véase el Doc 9303-12).)

• referencia de la persona titular del certificado

• autorización de la persona titular del certificado (función efectiva y autorización efectiva)

• fecha efectiva del certificado

• fecha de caducidad del certificado

• ampliaciones del certificado (cuando proceda)

El cálculo de la función efectiva (CVCA, DV o terminal) y la autorización efectiva de la persona titular del certificado se describen en la sección 7.1.4.3.6.

Nota.— El formato de los datos almacenados depende del sistema operativo y queda fuera del alcance de esta especificación.

7.1.5 Unidades de datos del protocolo de aplicación

La siguiente secuencia de comandos SE USARÁ con la mensajería segura para implementar la autenticación del terminal:

(La siguiente secuencia de órdenes SE USARÁ con la mensajería segura para instalar la autenticación del terminal:)

• MSE:Set DST

• PSO:Verify Certificat

• MSE:Set AT

• Get Challenge

• External Authenticate

Los pasos 1 y 2 se repiten para cada certificado verificable mediante tarjeta (CV) que haya que verificar (certificados de enlace CVCA, certificado DV, certificado de terminal).

(Los pasos 1 y 2 se repiten para cada certificado comprobable mediante tarjeta (CV) que haya que comprobar (certificados de enlace CVCA, certificado DV, certificado de terminal).)

7.1.5.1 MSE:Set DST

El comando MSE:Set DST se usa para establecer la verificación de los certificados.

(El comando MSE:Set DST se usa para establecer la comprobación de los certificados.)

Nota.— Algunos sistemas de operación aceptan la selección de una clave no disponible y solo devuelven un error cuando la clave pública se usa para el fin seleccionado.

7.1.5.2 PSO:Verify Certificate

El comando PSO:Verify Certificate se usa para verificar e importar certificados.

(El comando PSO:Verify Certificate se usa para comprobar e instalar certificados.)

7.1.5.3 MSE:Set AT

El uso de MSE:Set AT para la autenticación del terminal se indica por medio de P1/P2 fijado en 0x81A4 (véase la tabla que figura a continuación):

Nota.— Algunos sistemas de operación aceptan la selección de una clave pública no disponible y devuelven un error solo cuando la clave se utiliza para el fin seleccionado.

7.1.5.4 Get Challenge

7.1.5.5 EXTERNAL AUTHENTICATE

7.2 Cifrado de características biométricas adicionales

La restricción del acceso a las características biométricas adicionales también PUEDE efectuarse mediante cifrado de las mismas. Para poder descifrar los datos cifrados, el sistema de inspección DEBE contar con una clave de descifrado. La definición del algoritmo de cifrado/descifrado y de las claves que han de utilizarse corresponden al Estado que las implemente y queda fuera del alcance de este documento.

(La limitación del acceso a las características biométricas adicionales también PUEDE efectuarse mediante cifrado de las mismas. Para poder descifrar los datos cifrados, el sistema de inspección DEBE contar con una clave de descifrado. La definición del algoritmo de cifrado/descifrado y de las claves que han de utilizarse corresponden al Estado que las instale y queda fuera del alcance de este documento.)

La implantación de la protección de las características biométricas adicionales depende de las especificaciones internas del Estado o de especificaciones convenidas bilateralmente entre Estados que comparten esta información.

(El establecimiento de la protección de las características biométricas adicionales depende de las especificaciones internas del Estado o de especificaciones acordadas bilateralmente entre Estados que comparten esta información.)

(sigue la sección 8 de la Parte 11 del documento 9303)

8.7 Descifrado de las características biométricas adicionales

La implantación de la protección de las características biométricas opcionales depende de las especificaciones internas del Estado o de especificaciones convenidas bilateralmente entre Estados que comparten esta información.

(El establecimiento de la protección de las características biométricas opcionales depende de las especificaciones internas del Estado o de especificaciones acordadas bilateralmente entre Estados que comparten esta información.)

Además, el Apéndice E de la Parte 11 del documento 9303 recoge un ejemplo elaborado de autenticación pasiva:

Apéndice E de la Parte 11

EJEMPLO ELABORADO: AUTENTICACIÓN PASIVA

(INFORMATIVO)

Etapa 1. Leer el objeto de seguridad de documento (SOD) [contiene opcionalmente el certificado del firmante del documento (CDS)] del CI sin contacto.

(Etapa 1. Leer el objeto de seguridad de documento (SOD) [incluye opcionalmente el certificado del firmante del documento (CDS)] del CI sin contacto.)

Etapa 2: Leer el firmante del documento (DS) del objeto de seguridad del documento (SOD).

Etapa 3: El sistema de inspección verifica SOD utilizando la clave pública del firmante del documento.

(Etapa 3: El sistema de inspección comprueba SOD utilizando la clave pública del firmante del documento.)

Etapa 4: El sistema de inspección verifica CDS utilizando la clave pública de CA de firma de país.

(Etapa 4: El sistema de inspección comprueba CDS utilizando la clave pública de CA de firma de país.)

Si ambas verificaciones en las Etapas 3 y 4 son correctas, esto asegura que el contenido de SOD es fiable y puede utilizarse en el proceso de inspección.

(Si ambas comprobaciones en las Etapas 3 y 4 son correctas, esto asegura que el contenido de SOD es fiable y puede utilizarse en el proceso de inspección.)

Etapa 5: Leer los grupos de datos de la LDS pertinentes.

(Etapa 5: Leer los grupos de datos de la LDS correspondientes.)

Etapa 6: Calcular las condensaciones de los grupos de datos pertinentes.

(Etapa 6: Calcular las condensaciones (hash) de los grupos de datos correspondientes.)

Etapa 7: Comparar las condensaciones calculadas con los valores de condensación correspondientes en la SOD.

Si los valores de condensación de la Etapa 7 son idénticos, esto asegura que el contenido de grupo de datos es auténtico y no ha sufrido cambios.

(sigue la sección 6 de la Parte 12 del documento 9303)

En la aplicación del eMRTD, se establece un punto de confianza separado para cada clave pública de una determinada CSCA. Para la clave pública inicial obtenida de una CSCA, la confianza DEBE establecerse mediante un mecanismo fuera de banda. Por ejemplo, si un certificado CSCA fue descargado de un servidor relacionado con la CSCA, podría utilizarse una comunicación fuera de banda (p. ej., teléfono o correo electrónico) para verificar que el certificado descargado es en verdad el certificado auténtico de dicha CSCA. Además, la parte que confía puede analizar las políticas, procedimientos y prácticas de la CSCA expedidora para determinar si son suficientemente seguros como para satisfacer los requisitos locales sobre uso de certificados. Una vez establecido el punto de confianza inicial para una determinada CSCA, el proceso podría simplificarse para claves subsiguientes en la misma CSCA. Si esa autoridad expide un certificado de enlace CSCA, entonces podría omitirse la comunicación fuera de banda con la autoridad para verificar la autenticidad de un nuevo certificado porque la clave pública con confianza ya establecida para esa misma CSCA se utiliza para verificar la firma en el certificado de enlace de dicha autoridad.

(En la aplicación del eMRTD, se establece un punto de confianza separado para cada clave pública de una determinada CSCA (Country Signing Certification Authority = Autoridad de certificación de firma de país). Para la clave pública inicial obtenida de una CSCA, la confianza DEBE establecerse mediante un mecanismo fuera de banda. Por ejemplo, si un certificado CSCA fue descargado de un servidor relacionado con la CSCA, podría utilizarse una comunicación fuera de banda (p. ej., teléfono o correo electrónico) para comprobar que el certificado descargado es en verdad el certificado auténtico de dicha CSCA. Además, la parte que confía puede analizar las políticas, procedimientos y prácticas de la CSCA emisora para determinar si son suficientemente seguros como para cumplir los requisitos locales sobre uso de certificados. Una vez establecido el punto de confianza inicial para una determinada CSCA, el proceso podría simplificarse para claves posteriores en la misma CSCA. Si esa autoridad emite un certificado de enlace CSCA, entonces podría eliminarse la comunicación fuera de banda con la autoridad para comprobar la autenticidad de un nuevo certificado porque la clave pública con confianza ya establecida para esa misma CSCA se utiliza para comprobar la firma en el certificado de enlace de dicha autoridad.)

La información sobre puntos de confianza puede almacenarse como copia “de confianza” en el propio certificado CSCA, o en algún otro formato fiable.

Dado que las firmas en los certificados expedidos por las CSCA deben ser verificables mucho después de que la CSCA haya actualizado su par de claves, un Estado receptor tendrá normalmente más de un punto de confianza para la misma CSCA en un momento dado. Si una CSCA ha experimentado un cambio de nombre, algunos de estos puntos de confianza contendrán el antiguo nombre de la CSCA y otros contendrán el nuevo nombre.

(Dado que las firmas en los certificados emitidos por las CSCA deben ser comprobables mucho después de que la CSCA haya actualizado su par de claves, un Estado receptor tendrá normalmente más de un punto de confianza para la misma CSCA en un momento dado. Si una CSCA ha efectuado un cambio de nombre, algunos de estos puntos de confianza incluirán el antiguo nombre de la CSCA y otros incluirán el nuevo nombre.)

6.1.2 Validación de certificados/CRL y verificación de las revocaciones

Como parte del proceso de verificar la autenticidad e integridad de los objetos de datos en la aplicación del eMRTD (p. ej., objetos de seguridad de documento, listas maestras, listas de desviaciones, etc.), el Estado receptor:

(Como parte del proceso de comprobar la autenticidad e invariabilidad de los objetos de datos en la aplicación del eMRTD (p. ej., objetos de seguridad de documento, listas maestras, listas de desviaciones, etc.), el Estado receptor:)

• valida el certificado utilizado para verificar la firma del objeto de datos (p. ej., certificado de firmante del documento, certificado de firmante de la lista maestra, certificado de firmante de la lista de desviaciones);

(aprueba el certificado utilizado para comprobar la firma del objeto de datos (p. ej., certificado de firmante del documento, certificado de firmante de la lista maestra, certificado de firmante de la lista de desviaciones);)

• valida la CRL que se utiliza para verificar el estado de revocación del certificado en cuestión; y

(aprueba la CRL (Certificate Revocation List = Lista de revocación de certificados) que se utiliza para comprobar el estado de revocación del certificado interesado; y)

• procesa la CRL para verificar el estado de revocación del certificado en cuestión.

(tramita la CRL para comprobar el estado de revocación del certificado interesado.)

Se dispone de ejemplos de algoritmos para estos procesos, como los especificados en [RFC 5280]. Los Estados receptores no tienen que implementar el algoritmo específico definido en RFC 5280, pero DEBEN proporcionar funciones equivalentes al comportamiento externo resultante de este procedimiento. Una implementación particular puede utilizar cualquier algoritmo siempre que este obtenga el resultado correcto.

(Se dispone de ejemplos de algoritmos para estos procesos, como los descritos en [RFC 5280]. Los Estados receptores no tienen que instalar el algoritmo concreto definido en RFC 5280, pero DEBEN suministrar funciones similares al comportamiento externo resultante de este procedimiento. Una instalación concreta puede utilizar cualquier algoritmo siempre que este obtenga el resultado correcto.)

En el apéndice D se proporciona orientación para los Estados receptores que optan por basar su algoritmo en el especificado en [RFC 5280].

(En el apéndice D se facilita orientación para los Estados receptores que optan por basar su algoritmo en el descrito [RFC 5280].)

El Apéndice D de la Parte 12 del documento 9303 recoge:

Apéndice D de la Parte 12

COMPATIBILIDAD DE VALIDACIÓN EN RFC 5280

(INFORMATIVO)

En este apéndice se proporciona orientación a los Estados receptores que deseen emplear sistemas que implementen la ruta de certificación de [RFC 5280] y sus algoritmos de validación de CRL.

(En este apéndice se facilita orientación a los Estados receptores que deseen utilizar sistemas que instalen la ruta de certificación de [RFC 5280] y sus algoritmos de comprobación de CRL.)

El modelo de confianza de la PKI del eMRTD es un subconjunto del abarcado por los procedimientos de validación definidos en [RFC 5280]. En la sección D.1 se identifica el subconjunto de etapas de la definición de [RFC 5280] requerido para la aplicación del eMRTD y se proporcionan las entradas necesarias y los valores y procesos de inicialización para la validación de la ruta de certificación, la validación de CRL y la verificación de revocación.

(El modelo de confianza de la PKI (Public Key Infrastructure = Infraestructura de clave pública) del eMRTD (Electronic Machine Readable Passport = Documento de viaje de lectura mecánica electrónico) es un subconjunto del abarcado por los procedimientos de comprobación definidos en [RFC 5280]. En la sección D.1 se identifica el subconjunto de etapas de la definición de [RFC 5280] exigido para la aplicación del eMRTD y se facilitan las entradas necesarias y los valores y procesos de inicialización para la comprobación de la ruta de certificación, la comprobación de CRL (Certificate Revocation List = Lista de revocación de certificados) y la comprobación de revocación.)

La sección D.2 abarca las etapas restantes de la definición de [RFC 5280] y no son pertinentes a la aplicación del eMRTD. Se proporcionan las entradas y valores de inicialización para la validación de ruta de certificación y de CRL. La orientación en esta sección se aplica en situaciones en que los mecanismos implementan los algoritmos [RFC 5280] completos, en vez de solamente el subconjunto que se describe en D.1.

(La sección D.2 abarca las etapas restantes de la definición de [RFC 5280] y no son pocedentes a la aplicación del eMRTD. Se facilitan las entradas y valores de inicialización para la comprobación de ruta de certificación y de CRL. La orientación en esta sección se aplica en situaciones en que los mecanismos ejecutan los algoritmos [RFC 5280] completos, en vez de solamente el subconjunto que se describe en D.1.)

En la sección D.3 se proporciona orientación para apoyar la extensión del procesamiento CRL basado en [RFC 5280] para abarcar la verificación de la revocación después de que una CSCA ha experimentado un cambio de nombre.

(En la sección D.3 se facilita orientación para apoyar la extensión del procesamiento CRL basado en [RFC 5280] para abarcar la comprobación de la revocación después de que una CSCA ha efectuado un cambio de nombre.)

D.1 ETAPAS PERTINENTES A LOS eMRTD

El procedimiento de validación de ruta de certificación de eMRTD definido aquí se basa en el procedimiento que se describe en [RFC 5280]. Los perfiles de certificado eMRTD restringen las rutas de certificación a un único certificado y prohíben el uso de muchas características opcionales que se emplean en otras aplicaciones, como la PKI de Internet definida en [RFC 5280]. Las etapas de validación de ruta relacionadas con estas características se omiten del procedimiento de validación de ruta de certificación para eMRTD.

(El procedimiento de comprobación de ruta de certificación de eMRTD definido aquí se basa en el procedimiento que se describe en [RFC 5280]. Los perfiles de certificado eMRTD limitan las rutas de certificación a un único certificado y prohíben el uso de muchas características opcionales que se utilizan en otras aplicaciones, como la PKI de Internet definida en [RFC 5280]. Las etapas de comprobación de ruta relacionadas con estas características se omiten del procedimiento de comprobación de ruta de certificación para eMRTD.)

D.1.1 Procedimiento de validación de la ruta de certificación

D.1.1.1 Entradas

En la [RFC 5280] se define un conjunto de nueve entradas para el algoritmo de validación de ruta. Solo las tres siguientes son pertinentes a la aplicación del eMRTD:

(En la [RFC 5280] se define un conjunto de nueve entradas para el algoritmo de comprobación de ruta. Solo las tres siguientes son procedentes para la aplicación del eMRTD:)

• ruta de certificación: un certificado único (p. ej., el certificado de firmante del documento);

• fecha/hora actuales; e

• información sobre punto de confianza, incluido:

o nombre del expedidor de confianza: si el punto de confianza está en forma de certificado CSCA, el nombre del expedidor de confianza es el valor del campo subject de dicho certificado;

(nombre del emisor de confianza: si el punto de confianza está en forma de certificado CSCA, el nombre del emisor de confianza es el valor del campo subject de dicho certificado;)

o algoritmo de clave pública de confianza: si el punto de confianza está en forma de certificado CSCA, el algoritmo de clave pública de confianza se toma del campo SubjectPublicKeyInfo de dicho certificado;

o clave pública de confianza: si el punto de confianza está en forma de certificado CSCA, la clave pública de confianza se toma del campo SubjectPublicKeyInfo de dicho certificado; y

o parámetros de clave pública de confianza: esta es una entrada opcional que se incluye solamente si el algoritmo de clave pública de confianza requiere parámetros. Si el punto de confianza está en forma de certificado CSCA, estos parámetros se toman del campo SubjectPublicKeyInfo de dicho certificado.

(parámetros de clave pública de confianza: esta es una entrada opcional que se incluye solamente si el algoritmo de clave pública de confianza exige parámetros. Si el punto de confianza está en forma de certificado CSCA, estos parámetros se toman del campo SubjectPublicKeyInfo de dicho certificado.)

Si una implementación requiere que se suministren las seis entradas adicionales, en D.2 figuran recomendaciones al respecto.

(Si una instalación necesita que se suministren las seis entradas adicionales, en D.2 figuran recomendaciones al respecto.

Puede haber varios puntos de confianza para la CSCA que expidió el certificado que se está validando. De estos puntos de confianza, el que DEBE utilizarse es el que contiene la clave pública que corresponde al valor de la extensión del identificador de clave de autoridad en el certificado que se está validando.

(Puede haber varios puntos de confianza para la CSCA que emitió el certificado que se está comprobando. De estos puntos de confianza, el que DEBE utilizarse es el que incluye la clave pública que corresponde al valor de la extensión del identificador de clave de autoridad en el certificado que se está comprobando.)

D.1.1.2 Inicialización

Hay once variables de Estado definidas en [RFC 5280]. Solo las cinco siguientes son pertinentes a la aplicación del eMRTD:

(Hay once variables de Estado definidas en [RFC 5280]. Solo las cinco siguientes son procedentes a la aplicación del eMRTD:)

• aplicación: max_path_length: inicializar a “0”;

• working_issuer_name: inicializar al valor del nombre del expedidor de confianza;

(working_issuer_name: inicializar al valor del nombre del emisor de confianza;)

• working_public_key_algorithm: inicializar al valor del algoritmo de clave pública de confianza;

• working_public_key: inicializar al valor de la clave pública de confianza; y

• working_public_key_parameters: inicializar al valor de los parámetros de clave pública de confianza.

Si una implementación requiere que se inicialicen las seis variables adicionales, en D.2 figuran recomendaciones al respecto.

(Si una instalación necesita que se inicialicen las seis variables adicionales, en D.2 figuran recomendaciones al respecto.)

D.1.1.3 Procesamiento de certificados

Las etapas de procesamiento de certificados eMRTD son un subconjunto de las definidas en [RFC 5280]. El resultado de procesamiento de un certificado eMRTD utilizando este procedimiento simplificado será coherente con el resultado de aplicar el algoritmo RFC 5280 completo. Si las entradas adicionales y variables de Estado se configuran como se describe en D.2:

a) Verificar la información de certificado básica. El certificado DEBE satisfacer cada uno de los siguientes aspectos:

(Comprobar la información de certificado básica. El certificado DEBE satisfacer cada uno de los siguientes aspectos:)

• la firma del certificado puede verificarse utilizando working_public_key_algorithm, working_public_key y working_public_key_parameters;

(la firma del certificado puede comprobarse utilizando working_public_key_algorithm, working_public_key y working_public_key_parameters;)

• el período de validez de certificado incluye la hora actual;

• en el momento actual, el certificado no está revocado (en 6.3 figura información detallada al respecto); y

• el nombre del expedidor de certificado es el working_issuer_name.

(el nombre del emisor de certificado es el working_issuer_name.)

b) Asignar el subjectPublicKey del certificado al working_public_key.

c) Si el campo subjectPublicKeyInfo del certificado contiene un campo de algoritmo con parámetros que no son nulos, asignar los parámetros a la variable working_public_key_parameters. Si el campo subjectPublicKeyInfo del certificado contiene un campo de algoritmo con parámetros nulos o se han omitido parámetros, comparar el algoritmo subjectPublicKey del certificado con el algoritmo working_public_key_algorithm. Si el algoritmo subjectPublicKey del certificado y el algoritmo working_public_key_algorithm son diferentes, poner nulo a los working_public_key_parameters.

(Si el campo subjectPublicKeyInfo del certificado incluye un campo de algoritmo con parámetros que no son nulos, asignar los parámetros a la variable working_public_key_parameters. Si el campo subjectPublicKeyInfo del certificado incluye un campo de algoritmo con parámetros nulos o se han eliminado parámetros, comparar el algoritmo subjectPublicKey del certificado con el algoritmo working_public_key_algorithm. Si el algoritmo subjectPublicKey del certificado y el algoritmo working_public_key_algorithm son diferentes, poner nulo a los working_public_key_parameters.)

d) Asignar el algoritmo subjectPublicKey de certificado a la variable working_public_key_algorithm.

e) Reconocer y procesar cualquier otra extensión crítica presente en el certificado.

f) Procesar cualquier otra extensión no crítica reconocida presente en el certificado.

Si alguna de las verificaciones en la etapa a) falla o si hay extensiones críticas no reconocidas en el certificado que no puedan procesarse, el procedimiento de validación de ruta también falla. De otra forma, el procedimiento tiene éxito.

(Si alguna de las comprobaciones en la etapa a) falla o si hay extensiones críticas no reconocidas en el certificado que no puedan procesarse, el procedimiento de comprobación de ruta también falla. De otra forma, el procedimiento tiene éxito.)

D.1.1.4 Salidas

Si la validación dela ruta tiene éxito, el procedimiento termina, devolviendo una indicación de éxito junto con working_public_key, working_public_key_algorithm y la working_public_key_parameters.

(Si la comprobación dela ruta tiene éxito, el procedimiento termina, devolviendo una indicación de éxito junto con working_public_key, working_public_key_algorithm y la working_public_key_parameters.)

Si la validación de la ruta falla, el procedimiento termina, devolviendo una indicación de falla y un motivo apropiado.

(Si la comprobación de la ruta falla, el procedimiento termina, devolviendo una indicación de fallo y un motivo adecuado.)

D.1.2 Validación y verificación de revocación de las CRL

El algoritmo de validación de CRL que figura en [REC 5280] abarca varios tipos de CRL incluyendo las delta CRL, las CRL particionadas, las CRL indirectas, etc. El perfil de CRL para la aplicación del eMRTD es muy restrictivo y prohíbe el uso de cualquiera de estas características. El uso de la extensión issuingDistributionPoint así como todas las extensiones normalizadas con entradas de CRL también se prohíbe. Como resultado, la validación y verificación de revocación de las CRL para la aplicación del eMRTD es relativamente sencilla.

(El algoritmo de aprobación de CRL que figura en [REC 5280] abarca varios tipos de CRL incluyendo las delta CRL, las CRL particionadas, las CRL indirectas, etc. El perfil de CRL para la aplicación del eMRTD es muy limitativo y prohíbe el uso de cualquiera de estas características. El uso de la extensión issuingDistributionPoint así como todas las extensiones normalizadas con entradas de CRL también se prohíbe. Como resultado, la aprobación y comprobación de revocación de las CRL para la aplicación del eMRTD es relativamente sencilla.)

D.1.2.1 Entradas

En [RFC 5280] se definen dos entradas para el algoritmo de validación de CRL. Solo la siguiente, entre ellas, es pertinente a la aplicación del eMRTD. Si una implementación requiere que se suministre la entrada adicional, en D.2 figura una recomendación al respecto.

(En [RFC 5280] se definen dos entradas para el algoritmo de comprobación de CRL. Solo la siguiente, entre ellas, es pertinente a la aplicación del eMRTD. Si una instalación requiere que se suministre la entrada adicional, en D.2 figura una recomendación al respecto.)

• certificate: número de serie y nombre del expedidor del certificado.

(certificate: número de serie y nombre del emisor del certificado.)

D.1.2.2 Inicialización

Hay tres variables del Estado que se definen en [RFC 5280]. Solo la siguiente, entre ellas, es pertinente a la aplicación del eMRTD. Si una implementación requiere que las dos variables adicionales sean inicializadas, en D.2 figuran recomendaciones para ello.

(Hay tres variables del Estado que se definen en [RFC 5280]. Solo la siguiente, entre ellas, es pertinente a la aplicación del eMRTD. Si una instalación requiere que las dos variables adicionales sean inicializadas, en D.2 figuran recomendaciones para ello.)

• cert_status: inicializar al valor UNREVOKED.

D.1.2.3 Procesamiento de la CRL

Todas las CRL en la aplicación del eMRTD son CRL completas que abarcan todos los certificados actuales expedidos por la CSCA que expidió la CRL. No hay CRL particionadas, delta o indirectas. Las etapas del algoritmo de procesamiento de las CRL para la aplicación del eMRTD son:

(Todas las CRL en la aplicación del eMRTD son CRL completas que abarcan todos los certificados actuales emitidos por la CSCA que emitió la CRL. No hay CRL particionadas, delta o indirectas. Las etapas del algoritmo de procesamiento de las CRL para la aplicación del eMRTD son:)

a) Obtener la CRL actual de la CSCA que expidió el certificado. Si no puede obtenerse dicha CRL, la variable cert_status variable se establece en UNDETERMINED y se detiene el procesamiento.

(Obtener la CRL actual de la CSCA que emitió el certificado. Si no puede obtenerse dicha CRL, la variable cert_status se establece en UNDETERMINED y se detiene el procesamiento.)

b) Verificar que el expedidor de la CRL es la misma CSCA que expidió el certificado en cuestión. Debido a que hay una única CSCA en cada país, y la aplicación del eMRTD es una aplicación cerrada donde los sistemas de inspección conservan una caché de CRL que es única para esta aplicación, alcanza con verificar que el nombre del país es el mismo en el campo de expedidor de la CRL y en el campo del expedidor del certificado.

(Comprobar que el emisor de la CRL es la misma CSCA que emitió el certificado en cuestión. Debido a que hay una única CSCA en cada país, y la aplicación del eMRTD es una aplicación cerrada donde los sistemas de inspección guardan una caché de CRL que es única para esta aplicación, alcanza con comprobar que el nombre del país es el mismo en el campo de emisor de la CRL y en el campo del emisor del certificado.)

• Si la CSCA no ha experimentado un cambio de nombre desde que se expidió el certificado, el campo de expedidor en la CRL y el campo de expedidor en el certificado serán idénticos.

(Si la CSCA no ha efectuado un cambio de nombre desde que se emitió el certificado, el campo de emisor en la CRL y el campo de emisor en el certificado serán idénticos.)

• Si la CSCA ha experimentado un cambio de nombre desde que el certificado fue expedido, el atributo país del nombre en el campo de expedidor de certificado y en el campo de expedidor de las CRL serán los mismos, pero algunos otros atributos pueden ser diferentes.

(Si la CSCA ha efectuado un cambio de nombre desde que el certificado fue emitido, el atributo país del nombre en el campo de emisor de certificado y en el campo de emisor de las CRL serán los mismos, pero algunos otros atributos pueden ser diferentes.)

• Si la parte que confía desea verificar que no ha ocurrido sustitución de algunas CRL que no son de eMRTD, tiene la opción de verificar que tiene puntos de confianza para ambos nombres de CSCA y que dichos puntos de confianza son para la misma CSCA. Si la CSCA ha experimentado un cambio de nombre y ha incluido en la CRL la extensión opcional issuerAltName, la parte que confía PUEDE opcionalmente verificar que el campo de expedidor en el certificado es idéntico a uno de los valores de esta extensión.

(Si la parte que confía desea comprobar que no ha habido sustitución de algunas CRL que no son de eMRTD, tiene la opción de comprobar que tiene puntos de confianza para ambos nombres de CSCA y que dichos puntos de confianza son para la misma CSCA. Si la CSCA ha efectuado un cambio de nombre y ha incluido en la CRL la extensión opcional issuerAltName, la parte que confía PUEDE opcionalmente comprobar que el campo de emisor en el certificado es idéntico a uno de los valores de esta extensión.)

Si el expedidor de la CRL no es la CSCA que expide el certificado, la variable cert_status se establece en UNDETERMINED, y el procesamiento se detiene.

(Si el emisor de la CRL no es la CSCA que emite el certificado, la variable cert_status se establece en UNDETERMINED, y el procesamiento se detiene.)

c) Validar la ruta de certificación para el expedidor de la CRL. Obsérvese que en la aplicación del eMRTD todas las CRL son expedidas por CSCA que son los puntos de confianza para las respectivas rutas. A diferencia del algoritmo de [RFC 5280], la aplicación del eMRTD NO requiere que el punto de confianza utilizado para validar la ruta de certificación de la CRL sea el mismo punto de confianza que se usó para validar el certificado de que se trata. No obstante, si los puntos de confianza son diferentes, ambos DEBEN ser puntos de confianza para la misma CSCA. A diferencia de la [RFC 5280], la aplicación del eMRTD tiene múltiples puntos de confianza para una determinada CSCA que son válidos al mismo tiempo. Si la ruta de certificación no puede validarse satisfactoriamente, la variable cert_status se establece en UNDETERMINED y el procesamiento se detiene.

(Comprobar la ruta de certificación para el emisor de la CRL. Obsérvese que en la aplicación del eMRTD todas las CRL son emitidas por CSCA que son los puntos de confianza para las respectivas rutas. A diferencia del algoritmo de [RFC 5280], la aplicación del eMRTD NO exige que el punto de confianza utilizado para comprobar la ruta de certificación de la CRL sea el mismo punto de confianza que se usó para comprobar el certificado de que se trata. Aun así, si los puntos de confianza son diferentes, ambos DEBEN ser puntos de confianza para la misma CSCA. A diferencia de la [RFC 5280], la aplicación del eMRTD tiene múltiples puntos de confianza para una determinada CSCA que son válidos al mismo tiempo. Si la ruta de certificación no puede aprobarse satisfactoriamente, la variable cert_status se establece en UNDETERMINED y el procesamiento se detiene.)

d) Verificar la firma en la CRL. Si la firma no puede verificarse satisfactoriamente, la variable cert_status se establece en UNDETERMINED y el procesamiento se detiene.

(Comprobar la firma en la CRL. Si la firma no puede comprobarse satisfactoriamente, la variable cert_status se establece en UNDETERMINED y el procesamiento se detiene.)

e) Buscar el certificado en la CRL. Si se encuentra una entrada que corresponde al expedidor de certificado y al número de serie, entonces la variable cert_status se establece en UNSPECIFIED.

(Buscar el certificado en la CRL. Si se encuentra una entrada que corresponde al emisor de certificado y al número de serie, entonces la variable cert_status se establece en UNSPECIFIED.)

D.1.2.4 Salida

Devolver el cert_status. Si las etapas a), b), c) o d) fallaron, el estado será UNDETERMINED. Si el certificado fue incluido en la CRL como revocado, el estado será UNSPECIFIED. Si la validación de la CRL tuvo éxito, pero el certificado no estaba incluido en la CRL, el estado será UNREVOKED.

(Devolver el cert_status. Si las etapas a), b), c) o d) fallaron, el estado será UNDETERMINED. Si el certificado fue incluido en la CRL como revocado, el estado será UNSPECIFIED. Si la aprobación de la CRL tuvo éxito, pero el certificado no estaba incluido en la CRL, el estado será UNREVOKED.)

D.2 ETAPAS NO REQUERIDAS POR eMRTD

D.2.1 Validación de la ruta de certificación

Los parámetros para entradas adicionales que no son pertinentes a la validación de eMRTD comprenden:

(Los parámetros para entradas adicionales que no son pertinentes a la comprobación de eMRTD incluyen:)

• inhibición de la correspondencia de política inicial: establecer en inhibir correspondencia de política;

• inhibición de cualquier política inicial: establecer en inhibir procesamiento del valor cualquier política;

• subárboles iniciales permitidos: establecer en permitir todos los subárboles;

• subárboles iniciales excluidos: establecer en no excluir subárboles;

• política inicial explícita: NO debería establecerse; y

• conjunto de política inicial de usuario: establecer en el valor especial “cualquier política”.

La inicialización de las variables del Estado que no son pertinentes a la aplicación del eMRTD comprenden:

(La inicialización de las variables del Estado que no son pertinentes a la aplicación del eMRTD incluyen:)

• permitted_subtrees (subárboles permitidos): inicializar a todos los subárboles permitidos;

• excluded_subtrees (subárboles excluidos): inicializar a no excluir subárboles;

• inhibit_any_policy (inhibición de cualquier política): si se establece la inhibición inicial de cualquier política, inicializar a “0”. De otra manera, establecer el valor 1 o cualquier valor mayor que ese;

• policy_mapping (correspondencia de política): inicializar a “0”;

• explicit_policy (política explícita): inicializar a “2”; y

• valid_policy_tree (árbol de política válido): inicializar el elemento valid_policy en “anyPolicy”, el elemento qualifier_set en vacío y el elemento expected_policy_set en “anyPolicy”

D.2.2 Validación de la CRL

Los parámetros para entradas adicionales que no son pertinentes a la validación de eMRTD comprenden:

(Los parámetros para entradas adicionales que no son pertinentes a la comprobación de eMRTD incluyen:)

• use-deltas: se establece para prohibir el uso de deltas.

La inicialización de las variables del Estado que no son pertinentes a la aplicación del eMRTD comprenden:

(La inicialización de las variables del Estado que no son pertinentes a la aplicación del eMRTD incluyen:)

• reasons_mask (enmascarar razones): inicializar en un conjunto vacío; y

• Interim_reasons_mask (enmascarar razones provisionales): inicializar al valor especial “all-reasons”.

D.3 MODIFICACIONES REQUERIDAS PARA PROCESAR LAS CRL

Los sistemas de validación de CRL que cumplen con el procedimiento de validación de CRL en [RFC 5280] no tienen por objeto apoyar entornos donde una CA ha experimentado un cambio de nombre, como el entorno de aplicación del eMRTD. Por consiguiente, estos sistemas requieren alguna modificación para tramitar este caso especial, como se describe a continuación:

(Los sistemas de comprobación de CRL que cumplen con el procedimiento de comprobación de CRL en [RFC 5280] no tienen por objeto apoyar entornos donde una CA ha efectuado un cambio de nombre, como el entorno de aplicación del eMRTD. Por consiguiente, estos sistemas exigen alguna modificación para tramitar este caso especial, como se describe a continuación:)

a) En la cláusula 6.3.3, etapa a) del procedimiento de validación de CRL en [RFC 5280], el nombre en el campo de punto de distribución de la extensión de punto de distribución de la CRL del certificado en cuestión se utiliza para actualizar la caché local con las CRL pertinentes. Para la aplicación del eMRTD, esta etapa tendría que modificarse y solo el atributo countryName del campo de punto de distribución debería utilizarse para identificar y obtener la CRL apropiada.

(a) En la cláusula 6.3.3, etapa a) del procedimiento de comprobación de CRL en [RFC 5280], el nombre en el campo de punto de distribución de la extensión de punto de distribución de la CRL del certificado en cuestión se utiliza para actualizar la caché local con las CRL pertinentes. Para la aplicación del eMRTD, esta etapa tendría que modificarse y solo el atributo countryName del campo de punto de distribución debería utilizarse para identificar y obtener la CRL apropiada.)

b) En la cláusula 6.3.3, etapa f) del procedimiento de validación de CRL en [RFC 5280], se establece el requisito de que el mismo punto de confianza se utilice para validar la ruta de certificación para el expedidor de CRL que se utilizó para validar el certificado de que se trata. Esto NO es un requisito para la aplicación del eMRTD porque se establecen puntos de confianza independientes para cada clave pública de la CSCA.

(b) En la cláusula 6.3.3, etapa f) del procedimiento de comprobación de CRL en [RFC 5280], se establece el requisito de que el mismo punto de confianza se utilice para comprobar la ruta de certificación para el emisor de CRL que se utilizó para comprobar el certificado de que se trata. Esto NO es un requisito para la aplicación del eMRTD porque se establecen puntos de confianza independientes para cada clave pública de la CSCA.)

El punto de confianza empleado para la validación del expedidor de la CRL será el punto de confianza para la clave pública CSCA que corresponda a la clave privada utilizada para firmar la CRL. El punto de confianza utilizado para validar la ruta de certificación para el certificado en cuestión puede corresponder a un par de claves CSCA anteriores.

(El punto de confianza empleado para la comprobación del emisor de la CRL será el punto de confianza para la clave pública CSCA que corresponda a la clave privada utilizada para firmar la CRL. El punto de confianza utilizado para comprobar la ruta de certificación para el certificado en cuestión puede corresponder a un par de claves CSCA anteriores.)

(sigue la sección 6 de la Parte 12 del documento 9303)

6.1.3 Autoridad de validación del código de barras

La autoridad de validación del código de barras valida un sello digital aplicando una política de validación. En el Doc 9303-13 especifican en detalle los criterios de validación y los algoritmos para generar un estado de validación.

(La autoridad de comprobación del código de barras aprueba un sello digital aplicando una política de comprobación. En el Doc 9303-13 especifican en detalle los criterios de aprobación y los algoritmos para crear un estado de aprobación.)

En la Parte 13 del documento 9303 se recoge:

2. CODIFICACIÓN DEL SELLO DIGITAL

Un sello digital visible es una estructura de datos con firma criptográfica que contiene elementos del documento, está codificado como código de barras bidimensional y va impreso en el documento. En esta sección se describe la codificación y la estructura del sello digital visible.

(Un sello digital visible es una estructura de datos con firma criptográfica que incluye elementos del documento, está codificado como código de barras bidimensional y va impreso en el documento. En esta sección se describe la codificación y la estructura del sello digital visible.)

2.1 Requisitos de formato e impresión de códigos de barras

En esta especificación se define la forma en que los datos se codifican en un flujo de bytes. SE UTILIZARÁN únicamente códigos de barras bidimensionales cuya simbología está especificada como norma ISO. Entre las simbologías de códigos de barras bidimensionales normalizadas conforme a la ISO están, por ejemplo, DataMatrix [ISO/IEC 16022], Códigos Aztec [ISO/IEC 24778], y Códigos QR [ISO/IEC 18004].

El código de barras DEBERÍA imprimirse de manera tal que el equipo de lectura (i.e., teléfonos inteligentes o escáner de venta al público) pueda decodificar fiablemente el código de barras, en particular, DEBERÍA considerarse [ISO/IEC 15415] para evaluar la calidad de la impresión. Los requisitos relativos a la calidad de impresión y escaneo resultantes dependen del documento; los detalles de cada escenario de aplicación PUEDEN especificarse en un perfil. Debido al hecho de que la calidad de la impresión y escaneo incide en la proporción de errores e influye en la solidez de la verificación del sello digital, estos requisitos de calidad DEBERÍAN garantizar que el código de barras que contiene el sello digital y todos los elementos obligatorios del documento pueda verificarse de manera confiable. Otro requisito importante es aquel relacionado con el contraste del símbolo del código de barras, porque el sello digital puede estar impreso en papel de seguridad con fondo en color (p. ej., verde).

(El código de barras DEBERÍA imprimirse de manera tal que el equipo de lectura (es decir, teléfonos inteligentes o escáner de venta al público) pueda decodificar fiablemente el código de barras, en concreto, DEBERÍA atenderse [ISO/IEC 15415] para evaluar la calidad de la impresión. Los requisitos relativos a la calidad de impresión y escaneo resultantes dependen del documento; los detalles de cada escenario de aplicación PUEDEN especificarse en un perfil. Debido al hecho de que la calidad de la impresión y escaneo influye en la proporción de errores e influye en la solidez de la comprobación del sello digital, estos requisitos de calidad DEBERÍAN garantizar que el código de barras que incluye el sello digital y todos los elementos obligatorios del documento pueda comprobarse de manera fiable. Otro requisito importante es aquel relacionado con el contraste del símbolo del código de barras, porque el sello digital puede estar impreso en papel de seguridad con fondo en color (p. ej., verde).)

Cuando se utilicen impresoras de inyección de tinta corrientes, se RECOMIENDA imprimir con un tamaño de módulo (tamaño de un bloque del código de barras bidimensional) de por lo menos 0,3386 mm de longitud lateral por módulo, lo que corresponde a 4 puntos por longitud lateral de módulo (i.e., 16 puntos por módulo) en una impresora de 300 dpi, u 8 puntos por módulo de longitud lateral (i.e., 64 puntos por módulo) en una impresora de 600 dpi. Cuando se utilicen impresoras de alta resolución o láser, PUEDEN aceptarse tamaños de impresión más pequeños. En relación con el emplazamiento del código de barras en el documento, véanse las partes pertinentes del Doc 9303.

(Cuando se utilicen impresoras de inyección de tinta corrientes, se RECOMIENDA imprimir con un tamaño de módulo (tamaño de un bloque del código de barras bidimensional) de por lo menos 0,3386 mm de longitud lateral por módulo, lo que corresponde a 4 puntos por longitud lateral de módulo (osea, 16 puntos por módulo) en una impresora de 300 dpi, u 8 puntos por módulo de longitud lateral (osea, 64 puntos por módulo) en una impresora de 600 dpi. Cuando se utilicen impresoras de alta resolución o láser, PUEDEN aceptarse tamaños de impresión más pequeños. En relación con la localización del código de barras en el documento, véanse las partes correspondientes del Doc 9303.)

El código de barras codificado consta de un encabezamiento (véase la sección 2.2, una zona de mensaje (véase la sección 2.3) y una zona de firma (véase la sección 2.4). En la Figura 1, se ilustra la estructura.

Figura 1. Estructura del sello digital

2.2 Encabezamiento

El encabezamiento contiene metadatos acerca del documento y la codificación, como el número de versión, y las fechas de expedición y de creación de la firma.

(El encabezamiento inlcuye metadatos acerca del documento y la codificación, como el número de versión, y las fechas de emisión y de creación de la firma.)

Esta especificación define dos versiones del encabezamiento, marcadas con el identificador de versión “3” y “4”, respectivamente. Las versiones difieren en la definición de la referencia de certificado (véase a continuación) y la codificación de longitud de los elementos del documento (véase la sección 2.3).

La longitud total del encabezamiento es 18 bytes para la versión 3 y variable para la versión 4. En la Tabla 1 figura una definición de encabezamiento.

(La longitud total del encabezamiento es 18 bytes para la versión 3 y cambiable para la versión 4. En la Tabla 1 figura una definición de encabezamiento.)

Tabla 1. Formato del encabezamiento

2.2.1 Identificador de firmante y Referencia de certificado

Debido al tamaño reducido del código de barras, es imposible almacenar en él los certificados que contienen la clave pública correspondiente a la firma. En consecuencia, el certificado DEBE adquirirse por una vía diferente. Para identificar inequívocamente el certificado y el firmante que es la entidad del certificado, y para vincular el certificado al código de barras, se almacena en el encabezamiento una cadena que contiene el identificador del firmante y una referencia al certificado. La cadena consta de:

(Debido al tamaño reducido del código de barras, es imposible almacenar en él los certificados que incluyen la clave pública correspondiente a la firma. En consecuencia, el certificado DEBE adquirirse por una vía diferente. Para identificar inequívocamente el certificado y el firmante que es la entidad del certificado, y para enlazar el certificado al código de barras, se almacena en el encabezamiento una cadena que incluye el identificador del firmante y una referencia al certificado. La cadena consta de:)

a) Identificador de firmante: Combinación del código de país de dos letras, conforme al Doc 9303-3, del país del firmante y dos caracteres alfanuméricos para identificar al firmante en el país en cuestión. El identificador de firmante DEBE ser exclusivo para un firmante de un país determinado.

b) Referencia de certificado:

1) Para la versión 3 del encabezamiento: cadena hexadecimal exactamente de cinco caracteres que DEBE identificar exclusivamente un certificado para un firmante determinado.

2) Para la versión 4 del encabezamiento: cadena hexadecimal que comprende la concatenación de:

(Para la versión 4 del encabezamiento: cadena hexadecimal que incluye la concatenación de:)

i) exactamente dos caracteres que denotan el número de los caracteres siguientes; y

(exactamente dos caracteres que indican el número de los caracteres siguientes; y)

ii) los caracteres que DEBEN identificar exclusivamente un certificado para un firmante determinado.

Nótese que para el uso específico de visados (véase el Doc 9303-7), el firmante es el firmante del visado.

La referencia de certificado 0 … 0 se reserva para fines de pruebas y NO DEBE utilizarse en la producción.

El identificador de firmante (código de barras) y la referencia de certificado DEBEN corresponder al nombre distinguido (DN) de la entidad y el número de serie, respectivamente, de un certificado de firmante. Por lo tanto, el certificado de firmante puede identificarse exclusivamente al decodificar el encabezamiento.

(El identificador de firmante (código de barras) y la referencia de certificado DEBEN corresponder al nombre distinguido (DN = Distinguished Name = Nombre distinguido) de la entidad y el número de serie, respectivamente, de un certificado de firmante. Por lo tanto, el certificado de firmante puede identificarse exclusivamente al decodificar el encabezamiento.)

2.2.2 Referencia de la definición de elementos del documento y categoría del tipo de documento

La combinación de la referencia de la definición de elementos del documento y la Categoría del tipo de documento identifica un conjunto específico de reglas, como esta especificación. En caso de usos futuros, puede reutilizarse el mismo formato de código de barras y encabezamiento, pero con referencia a diferentes definiciones de elementos (i.e., una referencia que define la lista de información incluida en el código de barras) o categorías del tipo de documento. Esto permite reutilizar las bases de códigos existentes, simplificar la implementación e incrementar la interoperabilidad.

(La combinación de la referencia de la definición de elementos del documento y la Categoría del tipo de documento identifica un conjunto concreto de reglas, como esta determinación. En caso de usos futuros, puede reutilizarse el mismo modelo de código de barras y encabezamiento, pero con referencia a diferentes definiciones de elementos (es decir, una referencia que define la lista de información incluida en el código de barras) o categorías del tipo de documento. Esto posibilita reutilizar las bases de códigos existentes, simplificar la instalación y aumentar el interfuncionamiento.)

Las referencias de la definición de elementos del documento y la categoría del tipo de documento para visados y documentos de viaje de emergencia se definen en el Doc 9303-7 y el Doc 9303-8, respectivamente.