Guia Desarrolladores Dnie

Instituto Nacional de Tecnologías de la Comunicación

GUÍA PARA DESARROLLADORES CON EL DNI ELECTRÓNICO

CENTRO DE RESPUESTA A INCIDENTES DE SEGURIDAD (INTECO-CERT)

Documento interno y confidencial propiedad de INTECO S.A.

1

OCTUBRE 2007

Instituto Nacional de Tecnologías de la Comunicación

ÍNDICE 1.

INTRODUCCIÓN

3

2.

DESCRIPCIÓN DEL USO DEL DNI ELECTRÓNICO

5

2.1.

Establecimiento de conexión Público/Entidad Privada

privada

con

Organismo 5

2.2.

Firma de Trámites Administrativos con DNI electrónico

7

3.

INFRAESTRUCTURA DE CERTIFICACIÓN DEL DNI ELECTRÓNICO8

4.

CERTIFICADOS DE USUARIO

9

4.1.

9

5.

6.

CAMPOS DEL CERTIFICADO

PAUTAS A SEGUIR PARA DESARROLLOS CON EL DNI-E

11

5.1.

ACCESO AL DNI ELECTRÓNICO

11

5.2.

ACCESO AL ALMACÉN DE CERTIFICADOS

11

5.3.

SELECCIÓN DEL (contentCOMMITMENT)

5.4.

DESCOMPOSICIÓN DEL SUBJETC

12

5.5.

OPERACIONES CRIPTOGRÁFICAS

13

5.6.

RESUMEN REALIZACIÓN FIRMA ELECTRÓNICA

13

5.7.

VERIFICACIÓN DE FIRMAS ELECTRÓNICAS

14

5.8.

RESUMEN VERIFICACIÓN OPERACIÓN CRIPTOGRÁFICA 15

REFERENCIAS

Documento interno y confidencial propiedad de INTECO S.A.

CERTIFICADO

DE

FIRMA 12

16

2

Instituto Nacional de Tecnologías de la Comunicación

1. INTRODUCCIÓN El objeto del presente documento es describir y especificar los conceptos técnicos básicos para el desarrollo de aplicaciones de firma electrónica que hagan uso del DNI electrónico, al cual se hará referencia desde ahora como DNI-e. En el documento se detallan aspectos relacionados con los usos del DNI-e, el perfil o estructura de los certificados electrónicos de identidad pública que almacena, de los usos concretos de cada uno de ellos, y de la forma de acceder a los mismos y verificarlos. Los usos válidos de los certificados electrónicos del DNI-e se recogen en la Declaración de Prácticas y Políticas de Certificación (OID: 2.16.724.1.2.2.2.1.0.6) de la Infraestructura de Clave Pública del DNI-e y son: •

Certificado de Autenticación: Garantizar electrónicamente la identidad del ciudadano al realizar una transacción telemática. El Certificado de Autenticación (Digital Signature) asegura que la comunicación electrónica se realiza con la persona que dice que es. El titular podrá a través de su certificado acreditar su identidad frente a cualquiera ya que se encuentra en posesión del certificado de identidad y de la clave privada asociada al mismo. El uso de este certificado no está habilitado en operaciones que requieran no repudio de origen, por tanto los terceros aceptantes y los prestadores de servicios no tendrán garantía del compromiso del titular del DNI con el contenido firmado. Su uso principal será para generar mensajes de autenticación (confirmación de la identidad) y de acceso seguro a sistemas informáticos (mediante establecimiento de canales privados y confidenciales con los prestadores de servicio). Este certificado puede ser utilizado también como medio de identificación para la realización de un registro que permita la expedición de certificados reconocidos por parte de entidades privadas, sin verse estas obligadas a realizar una fuerte inversión en el despliegue y mantenimiento de una infraestructura de registro.

•

Certificado de Firma: El propósito de este certificado es permitir al ciudadano firmar trámites o documentos. Este certificado (certificado cualificado según ETSI, la RFC3739 y la Directiva Europea 99/93/EC. y reconocido según la Ley de Firma Electrónica) permite sustituir la firma manuscrita por la electrónica en las relaciones del ciudadano con terceros (LFE 59/2003 artº 3.4 y 15.2). Es un certificado reconocido que funciona como dispositivo seguro de creación de firma electrónica, de acuerdo con el artículo 24.3, de la Ley 59/2003, de 19 de diciembre. Por este motivo, garantiza la identidad del ciudadano poseedor de la clave privada de identificación y firma, y permiten la generación de la “firma electrónica reconocida”; es decir, la firma electrónica avanzada que se basa en un certificado reconocido y que ha estado generada utilizando un dispositivo seguro, por lo cual, de acuerdo con lo que establece el artículo 3 de la Ley 59/2003, de 19 de diciembre, se equipara a la firma manuscrita a efectos legales, sin necesidad de cumplir ningún otro requerimiento adicional. Por lo anteriormente descrito, este certificado no deberá ser empleado para generar mensajes de autenticación (confirmación de la identidad) y de acceso

Documento interno y confidencial propiedad de INTECO S.A.

3

Instituto Nacional de Tecnologías de la Comunicación

seguro a sistemas informáticos (mediante establecimiento de canales privados y confidenciales con los prestadores de servicio).

Documento interno y confidencial propiedad de INTECO S.A.

4

Instituto Nacional de Tecnologías de la Comunicación

2. DESCRIPCIÓN DEL USO DEL DNI ELECTRÓNICO A titulo de ejemplo se van a describir dos de los escenarios más habituales de uso del DNI-e: •

Establecimiento de una conexión privada: se utiliza el certificado de autenticación para probar la identidad frente al organismo o entidad.

•

Firma de trámites administrativos: se utiliza el certificado de firma reconocida para firmar electrónicamente un trámite administrativo.

Se presupone que el ciudadano dispone de un DNI con capacidades electrónicas (criptográficas), que está conectando al organismo de forma remota a través de Internet y que dispone de una instalación local con un lector de tarjetas inteligentes compatible (PC/SC) y cuenta con el CSP o el PKCS#11 del DNI electrónico.

2.1.

ESTABLECIMIENTO DE CONEXIÓN PRIVADA ORGANISMO PÚBLICO/ENTIDAD PRIVADA

CON

El siguiente esquema de comunicaciones establece el protocolo a seguir para el establecimiento de un canal privado y autenticado entre el ciudadano y el Organismo Público o Entidad Privada. El canal establecido queda autenticado en ambos extremos por el uso de certificados que garantizan la identidad de las partes. 1. El Ciudadano hace petición de conexión segura autenticada 2. El Organismo o Entidad crea mensaje autenticado y envía al ciudadano 3. El Ciudadano verifica validez del certificado de servidor ofrecido 4. Se genera la clave de sesión y cifrado de la misma con la clave pública del Organismo o Entidad. 5. Se construye el mensaje de intercambio de claves. 6. El Ciudadano introduce el DNI-e en el lector y con el certificado electrónico de autenticación valida el mensaje de intercambio de claves. 7. Se establece el canal privado. 8. El Organismo o Entidad verifica mensaje de establecimiento de sesión. 9. El Organismo o Entidad comprueba en la Autoridad de Validación el estado de validez del certificado autenticación del ciudadano. 10.Se establece el canal seguro, se cierra túnel SSL. Tal y como queda reflejado en el esquema anterior, el proceso de autenticación entre ambas partes para el establecimiento de un canal seguro requiere del uso de: 1. Certificado de Organismo Público o Entidad Privada: Este certificado asociado al servidor del Organismo o Entidad garantiza que el ciudadano se está conectando a dicho Organismo y no a otro.

Documento interno y confidencial propiedad de INTECO S.A.

5

Instituto Nacional de Tecnologías de la Comunicación

2. Certificado de autenticación del ciudadano. El ciudadano para autenticarse frente al Organismo o Entidad dispone de un certificado con capacidad de autenticación. De esta forma el Organismo o Entidad podrá determinar la identidad del ciudadano para ofrecerle un servicio personalizado. Las partes implicadas para el establecimiento del canal privado son: •

DNI electrónico: Dispositivo de firma y autenticación segura en posesión del ciudadano que contendrá: 1. Conjunto de claves privadas al ciudadano. 2. Conjunto de certificados del ciudadano. 3. Elementos de seguridad para garantizar la integridad del documento frente a posibles alteraciones.

•

Ciudadano: Persona física titular del DNI electrónico.

•

Organismo Público o Entidad Privada: Proveedor de servicios.

•

Autoridad de Validación: Servicio informativo del estado de validez de los certificados del ciudadano.

El protocolo descrito en el esquema corresponde al establecimiento de una sesión SSL (Secure Socket Layer). La elección de este mecanismo viene determinada por que prácticamente el 100% de los servidores y clientes utilizados disponen de esta capacidad. Este protocolo permite el establecimiento de canales privados con los proveedores de servicios, organismos públicos u otros. Si bien, existen dos tipos de canales: 1.

Autenticación Servidor: En esta modalidad sólo el servidor requiere tener un certificado por lo que la identidad del cliente, será anónima.

2.

Autenticación Servidor-Cliente: Requiere que tanto el proveedor de servicios se autentique frente al cliente (ciudadano), como que el cliente se autentique frente al servidor. (Este es el ideal recomendado)

La diferencia real, en cuanto a usabilidad, estriba principalmente en que si el proveedor de servicios puede determinar con garantía la identidad del ciudadano estará en disposición de ofrecerle información personalizada. La utilización del certificado de Autenticación del DNI electrónico garantiza la identidad del ciudadano, y podrá ser utilizado por los proveedores de servicios para establecer reglas de acceso a la información en base a la identidad del mismo.

Documento interno y confidencial propiedad de INTECO S.A.

6

Instituto Nacional de Tecnologías de la Comunicación

2.2.

FIRMA DE TRÁMITES ELECTRÓNICO

ADMINISTRATIVOS

CON

DNI

El siguiente esquema establece el protocolo a seguir para la firma de formularios electrónicos, mediante el uso del DNI electrónico, cumpliendo con la normativa sujeta al uso de certificados reconocidos: 1. El Organismo o Entidad envía el formulario para el trámite administrativo 2. El Ciudadano cumplimenta el formulario y lo envía. 3. El Organismo o Entidad reconstruye el formulario y lo reenvía nuevamente al ciudadano en un formato que permita a éste verificar de forma completa lo qué está firmando. 4. El Ciudadano verifica que el trámite administrativo se corresponde exactamente con el cumplimentado 5. Se solicita al ciudadano la firma electrónica del formulario 6. El Ciudadano introduce su clave de acceso personal (PIN) para el acceso al certificado de Firma (contentCommitment). 7. El DNI-e firma electrónicamente el formulario. 8. El Ciudadano envía formulario firmado al Organismo o Entidad 9. El Organismo o Entidad verifica validez de la firma, para comprobar integridad formulario 10.El Organismo o Entidad comprueba en la Autoridad de Validación el estado de validez del certificado de Firma del ciudadano 11.Si es correcto se sigue el procedimiento.

Documento interno y confidencial propiedad de INTECO S.A.

7

Instituto Nacional de Tecnologías de la Comunicación

3. INFRAESTRUCTURA ELECTRÓNICO

DE

CERTIFICACIÓN

DEL

DNI

La Infraestructura de Certificación del DNI-e tiene una estructura jerárquica: existe una Autoridad de Certificación (AC) raíz que emite los certificados de las ACs intermedias que a su vez emiten los dos certificados almacenados en el propio DNI-e. La arquitectura general de la Infraestructura de Certificación del DNI-e es: AC Raíz

NIVEL 0

NIVEL 1

AC Subordinada 1

AC Subordinada N

ƒ

Certificado de Autenticación

ƒ

Certificado de Firma

En la siguiente tabla se recogen la longitud de las claves, la caducidad de los certificados y sus ‘usos de clave’ (keyusage) Certificado

Longitud Clave

Caducidad

KeyUsage

AC raíz

4096 bits

30 años

Key Certificate Signature, CRL Signature

AC Subordinada

4096 bits

15 años

Key Certificate Signature, CRL Signature

Autenticación

2048 bits

30 meses

digitalSignature

Firma

2048 bits

30 meses

contentCommitment

Documento interno y confidencial propiedad de INTECO S.A.

8

Instituto Nacional de Tecnologías de la Comunicación

4. CERTIFICADOS DE USUARIO Los dos certificados del DNI-e, como se ha expuesto anteriormente tienen propósitos y perfiles diferenciados: 1. Autenticación: se utiliza para firma un desafío y demostrar la identidad de su poseedor. 2. Firma: el “keyusage contentCommitment”, anteriormente conocido como “nonRepudiation”, indica que su propósito es firmar documentos electrónicamente mostrando un compromiso con su contenido y teniendo características de no repudio. Los certificados se representan utilizando ASN.1 (Sintaxis de Notación Abstracta nº 1), estando codificados en DER (Reglas de Codificación Distinguida) o BER (Reglas de Codificación Básicas), siendo DER un subconjunto de BER.

4.1.

CAMPOS DEL CERTIFICADO

A continuación se detallan los campos de los certificados y que más se utilizan en el desarrollo de aplicaciones con certificados digitales. •

Serial Number: Número de serie del certificado, se genera de forma aleatoria.

•

Signature Algoritm: Identificador de la función hash y el algoritmo de firma que la AC ha utilizado para firmar digitalmente el certificado. o

Inicialmente el algoritmo es sha1WithRSAEncryption cuyo OID es 1.2.840.113549.1.1.5.

o

En un futuro se pasará a sha256WithRSAEncryption cuyo OID es 1.2.840.113549.1.1.11.

•

Issuer Distinguished Name: Nombre distintivo (identificador que permite localizar información dentro de un directorio que cumple la recomendación X.500) de la AC que ha emitido el certificado.

•

Validity: Fechas de inicio y fin de la validez del certificado.

•

Subject: Nombre distintivo del usuario que posee la clave privada asociada a la clave publica contenida en el Subject Public Key Info.

•

Subject Public Key Info: Identificador del algoritmo criptográfico con el que se va a usar la clave pública así como la clave en si misma.

•

Subject Key Identifier (Extensión): Identificador de la clave pública del sujeto. Es un hash (SHA-1) sobre la clave pública del sujeto. OID: 2.5.29.14. No crítica.

•

Authority Key Identifier (Extensión): El valor de esta extensión identifica la clave pública que se va a utilizar para verificar la firma del certificado. Es un hash (SHA-1) sobre la clave pública de la AC emisora del certificado. OID: 2.5.29.35. No crítica.

Documento interno y confidencial propiedad de INTECO S.A.

9

Instituto Nacional de Tecnologías de la Comunicación

•

•

Key Usage (Extensión): Indica la utilidad de la clave pública (contenida en el certificado. OID: 2.5.29.15. Crítica. o

Certificado de Autenticación: es digitalSignature

o

Certificado de Firma: es contentCommitment

Authority Information Access (Extensión): Indica como acceder a la información de AC y a servicios del emisor del certificado. Pueden contener datos sobre servicios de validación y políticas de la AC. OID: 1.3.6.1.5.5.7.1.1. No crítica. Para el caso del DNI-e se incluyen dos valores: o

OCSP: Contiene la URL donde se encuentra el servidor OCSP Responder de la policía (http://ocsp.dnie.es). OID: 1.3.6.1.5.5.7.48.1.

o

CA: Contiene la URL de la que se puede descargar el certificado de la AC Raíz de la policía (http://www.dnie.es/certs/ACRaiz.crt). OID: 1.3.6.1.5.5.7.48.2.

Documento interno y confidencial propiedad de INTECO S.A.

10

Instituto Nacional de Tecnologías de la Comunicación

5. PAUTAS A SEGUIR PARA DESARROLLOS CON EL DNIE En el desarrollo de aplicaciones que empleen los certificados del DNI-e es necesario que las APIs empleadas sean compatibles con los diferentes elementos de los certificados, es decir, por ejemplo: •

Tratar con certificados de 4096 bits (AC Raíz)

•

Efectuar validaciones por protocolo OCSP dado que no se da acceso a las CRL.

•

Aunque actualmente los certificados están firmados con sha1withRSAEncryption, se ha de tener en cuenta que en un futuro se emitirán con sha256withRSAEncryption.

Como se señalaba en la introducción este documento da unas pautas genéricas para el desarrollo de aplicaciones pero no constituye una guía completa para el uso de certificados electrónicos en los diferentes sistemas operativos y entornos/lenguajes de desarrollo, por ello el desarrollador ha de ser consciente que ha de tener los conocimientos necesarios para el uso de certificados electrónicos en su entorno de desarrollo.

5.1.

ACCESO AL DNI ELECTRÓNICO

El primer punto que se plantea en el desarrollo de aplicaciones sobre el DNI-e es la forma de acceso a la tarjeta, en la actualidad existen dos formas de acceder a la misma: •

A través de CSP: con tecnología Microsoft en sistemas operativos de Microsoft.

•

A través de PKCS#11: en el resto de sistemas operativos que son capaces de trabajar con tarjetas inteligentes y en sistemas operativos Microsoft con otras tecnologías como por ejemplo Java.

La forma de trabajo de uno a otro presenta ciertas diferencias. Por ejemplo mientras que con el PKCS#11 será la aplicación la responsable de solicitar y presentar el PIN a la tarjeta para poder acceder a los objetos privados contenidos en la misma, con el CSP de Microsoft es éste el que se encarga de la solicitud del PIN cuando sea necesario acceder a uno de estos objetos. Este punto puede perfectamente entremezclarse con el siguiente dependiendo de con qué tecnología se desee trabajar.

5.2.

ACCESO AL ALMACÉN DE CERTIFICADOS

Como se ha mencionado en el punto anterior, esta fase depende en gran parte de la tecnología empleada para el desarrollo. A grandes rasgos lo primero que se hace es autenticarse contra la tarjeta, para posteriormente obtener todos los certificados almacenados en ella (es conveniente hacer notar que la clave privada asociada a los certificados nunca sale de la tarjeta, y cualquier operación que requiera de su uso tendrá lugar dentro la tarjeta) Documento interno y confidencial propiedad de INTECO S.A.

11

Instituto Nacional de Tecnologías de la Comunicación

Se deberán obtener todos los certificados contenidos en la tarjeta para, posteriormente, seleccionar el que se pretende utilizar en las operaciones criptográficas (por el ejemplo el de firma para realizar la firma electrónica de documentos). Como norma general (dependiendo de la tecnología empleada para realizar el desarrollo) al final de este punto se tendrá un almacén (por ejemplo un “keystore” en el caso de Java) con todos los certificados cuya clave privada este contenida en la tarjeta. Es importante esta aclaración ya que por ejemplo en este paso no se obtienen los certificados de las ACs subordinadas, certificados que a posteriori se necesitaran para poder verificar las operaciones criptográficas.

5.3.

SELECCIÓN DEL CERTIFICADO (contentCOMMITMENT)

DE

FIRMA

Existen dos certificados de usuario en el DNI-e, si no es posible extraer directamente el que se quiere utilizar se ha de crear un método capaz de hacerlo para ello se deberá poder obtener la extensión keyUsage del certificado para comprobar cual es el propósito del mismo. El keyUsage es una cadena de bits que toman valores 0 ó 1 para asignar los siguientes usos de la clave: •

bit 0: digitalSignature, para verificar firmas digitales.

•

bit 1: contentCommitment, para verificar firmas digitales dando servicio de no repudio.

•

bit 2: keyEncipherment, para cifrar otras claves (por ejemplo una clave secreta).

•

bit 3: dataEncipherment, para cifrar datos que no sean claves.

•

bit 4: keyAgreement, para servir como acuerdo entre ambas partes.

•

bit 5: keyCertSign, para verificar la firma digital de la Autoridad de Certificación en los certificados.

•

bit 6: cRLSign, para verificar la firma digital de la Autoridad de Certificación en las listas de revocación (CRLs).

•

bit 7: encipherOnly, si la clave se utiliza sólo para cifrar datos. Si éste bit está activo, el bit4 debería también estarlo.

•

bit 8: decipherOnly, si la clave se utiliza sólo para descifrar datos. Si éste bit está activo, el bit4 debería también estarlo.

5.4.

DESCOMPOSICIÓN DEL SUBJETC

Es muy habitual que se necesite cierta información de la identidad del usuario. Ésta se puede obtener del campo Subject, cuya estructura es la siguiente: •

Certificado de Firma: CN=APELLIDO1 APELLIDO2, NOMBRE (FIRMA) G=NOMBRE SN=APELLIDO1

Documento interno y confidencial propiedad de INTECO S.A.

12

Instituto Nacional de Tecnologías de la Comunicación

NÚMERO DE SERIE=DNI (con letra) C=ES •

Certificado de Autenticación CN=APELLIDO1 APELLIDO2, NOMBRE (AUTENTICACIÓN) G=NOMBRE SN=APELLIDO1 NÚMERO DE SERIE=DNI (con letra) C=ES

Este dato se recibirá como una cadena de la cual habrá que ir extrayendo los diferentes datos identificativos del usuario. Adicionalmente en el campo subjectDirectoryAttributes (OID 2.5.29.9) del certificado se encuentra la fecha de nacimiento, dateOfBirth (OID 1.3.6.5.5.7.9.1) la cual permitiría comprobar la mayoría de edad de la persona que se identifica o firma de ser necesario.

5.5.

OPERACIONES CRIPTOGRÁFICAS

Finalmente se han de realizar las operaciones criptográficas, por ejemplo la firma. Es posible que las herramientas básicas de desarrollo no den toda la capacidad de trabajo que se necesite para tratar los datos obtenidos con las operaciones criptográficas, ya que los datos se representan en formatos específicos como pueden ser los estándares PKCS#7, CMS o XAdES. En la actualidad en el mercado hay numerosos productos de libre distribución que se complementan con las API de desarrollo básicas dando funcionalidades adicionales para el tratamiento de datos firmados. Existe la posibilidad de que de los documentos firmados y de los certificados se deban obtener datos para crear estructuras de información más complejas, como puedan ser cadenas de certificados para verificar jerarquías. Como norma general las APIs de desarrollo mencionadas suelen proveer de los mecanismos oportunos para la obtención de estos certificados. En cualquier caso, es necesario que proporcionemos todos los certificados necesarios para realizar la verificación de las operaciones de firma.

5.6.

RESUMEN REALIZACIÓN FIRMA ELECTRÓNICA

De forma breve se recogen los pasos para realizar una firma electrónica: •

Acceso al DNI-e.

•

Obtención de los certificados contenidos en la tarjeta.

•

Selección del certificado de firma (keyUsage contentCommitment o información del Subject)

Documento interno y confidencial propiedad de INTECO S.A.

13

Instituto Nacional de Tecnologías de la Comunicación

•

Obtención de los datos a firmar.

•

Realizar la operación de Firma.

•

Agrupar datos para formar una estructura estándar.

•

5.7.

o

Indicar si se desea añadir el texto en claro en el documento firmado.

o

Incluir los certificados de las ACs subordinadas (serán necesarios para el proceso de verificación).

Generar la salida en formato estándar.

VERIFICACIÓN DE FIRMAS ELECTRÓNICAS

Normalmente, siempre que firma electrónicamente un conjunto de datos, es necesario realizar la verificación de la validez de dicha firma electrónica. En este punto se describirán los aspectos más importantes en la verificación de las firmas electrónicas y en el punto siguiente se mostrará un ejemplo de cómo verificar una operación criptográfica. Para poder verificar que una operación está realizada con un certificado de usuario del DNI-e válido, se debe estar en posesión de toda la cadena de certificación, es decir se deben tener tres certificados: el del usuario, el de su AC subordinada y el de la AC Raíz. Los certificados de usuario y de la AC subordinada están contenidos en la tarjeta. En la operación de firma, si se han seguido los puntos descritos anteriormente, estos dos certificados deberán estar incluidos en el resultado de la operación criptográfica (datos firmados) y de este resultado se toman, ya que no se suele disponer del DNI-e a la hora de verificar los datos resultantes de una operación criptográfica. Para obtener el certificado de la AC Raíz se debe ir al certificado de usuario, más concretamente al campo AC de la extensión AuthorityInformationAccess, que facilita la URL donde se puede descargar el certificado de la AC raíz. Si se opera habitualmente con el DNI-e se tendrá ya este certificado. El proceso a seguir cuando se está en posesión todos los certificados es (para cada uno de los certificados): •

Verificar que el certificado fue firmado usando la clave privada que corresponde a la clave pública de su emisor. Este paso no es necesario para el certificado de la CA raíz.

•

Verificar la validez del certificado, es decir, no ha caducado.

•

Realizar la validación OCSP.

Documento interno y confidencial propiedad de INTECO S.A.

14

Instituto Nacional de Tecnologías de la Comunicación

5.8.

RESUMEN VERIFICACIÓN OPERACIÓN CRIPTOGRÁFICA

De forma breve se van a enumerar los pasos para verificar una operación criptográfica, asociándolos con el ejemplo de verificación de una firma electrónica: •

Obtener el documento a verificar.

•

Comprobar si los datos a verificar contienen los datos originales, sino se deberán obtener.

•

Verificar que la firma esta hecha con el certificado de usuario.

•

Verificar la cadena de certificación, como se ha mencionado en el punto anterior.

Documento interno y confidencial propiedad de INTECO S.A.

15

Instituto Nacional de Tecnologías de la Comunicación

6. REFERENCIAS A continuación se enumeran distintas referencias a documentación utilizada para la elaboración del presente documento y otros documentos de referencia que completan la información aquí referida o que son de utilidad para el desarrollo de aplicaciones de firma electrónica. •

ISO/IEC 8824-1 ITU-T Recommendation X.680 | ISO/IEC 8824-1, “Information technology – Abstract Syntax Notation One (ASN.1): Specification of basic notation”, 1997

•

ISO/IEC 8825-1 ITU-T Recommendation X.690 | ISO/IEC 8825-1, “Information Technology – ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)”, 1997

•

ITU-T Recommendation X.509 | ISO/IEC 9594-8, "Information technology – Open Systems Interconnection - The Directory: Authentication framework", 2005

•

RFC 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

•

RFC 3852 Cryptographic Message Syntax (CMS)

•

ETSI TS 101 903 XML Advanced Electronic Signatures (XAdES).

•

ETSI TS 101 733 CMS Advanced Electronic Signatures (CAdES)

•

PKCS#7 RSA Laboratories Technical Note, “Cryptographic Message Syntax Standard”, 1993

Documento interno y confidencial propiedad de INTECO S.A.

16