Certificado y Firma digital - Què és la FundacióBit...

Certificado y

Firma digitalFundamentos

Informació general del document.

Descripció.

Títol: Certificado y Firma digital. Fundamentos

Estat: Aprovat

Versió: 1.0

Autor/s: Daniel Boerner

Creat: 26/11/2013

Modificat 18/12/2013

Fitxer: firmaDigitalFBit.odt

Històric de modificacions.

Comentari: Autor/s: Data:

Font documental.

Contenido1. Función Hash..............................................................................................................................................................................................52. Código de Autenticación.............................................................................................................................................................................5

2.1. HMAC................................................................................................................................................................................................63. Cifrado Simétrico.........................................................................................................................................................................................64. Cifrado Asimétrico.......................................................................................................................................................................................7

4.1. Generación de claves........................................................................................................................................................................75. Envoltorio Digital.......................................................................................................................................................................................106. Firma Digital..............................................................................................................................................................................................107. Sello de Tiempo........................................................................................................................................................................................128. Certificado Digital......................................................................................................................................................................................14

8.1. PKI X.509.........................................................................................................................................................................................14Certificado digital X.509...................................................................................................................................................................15Autoridades......................................................................................................................................................................................15Usos.................................................................................................................................................................................................15Políticas de certificación...................................................................................................................................................................16Ejemplo de certificado digital X.509.................................................................................................................................................17Creación de un certificado digital.....................................................................................................................................................19Creación de un certificado digital autofirmado.................................................................................................................................20Revocación.......................................................................................................................................................................................22Validación.........................................................................................................................................................................................26Subject Key Identifier.......................................................................................................................................................................27Verificación.......................................................................................................................................................................................28

8.2. Archivos de certificados digitales....................................................................................................................................................30Operaciones sobre archivos con certificados digitales....................................................................................................................31

8.3. Huella digital....................................................................................................................................................................................329. Marco legal................................................................................................................................................................................................3210. Prácticas.................................................................................................................................................................................................34

10.1. PKI Simple.....................................................................................................................................................................................3410.2. PKI Avanzado................................................................................................................................................................................3510.3. PKI Experto....................................................................................................................................................................................3510.4. SSL. Autenticación cliente/servidor...............................................................................................................................................36

11. Firma avanzada.......................................................................................................................................................................................3712. CAdES.....................................................................................................................................................................................................38

12.1. Perfiles...........................................................................................................................................................................................38CAdES-BES: básica.........................................................................................................................................................................39CAdES-EPES: referencias a políticas de firma...............................................................................................................................40CAdES-T: sello de tiempo................................................................................................................................................................40CAdES-C: referencias a datos de validación...................................................................................................................................41CAdES-X Long: datos de validación................................................................................................................................................41CAdES-X Type 1: referencias a datos de validación y sello de tiempo sobre CAdES-C................................................................42CAdES-X Type 2: referencias a datos de validación y sello de tiempo sobre referencias a datos de validación..........................42CAdES-X Long Type 1: datos de validación y sello de tiempo sobre CadES-C.............................................................................43CAdES-X Long Type 2: datos de validación y sello de tiempo sobre referencias a datos de validación.......................................43CAdES-A: datos de validación y sello de tiempo sobre CAdES-C o sobre referencias a datos de validación, sellos de tiempo periódicos para validar la firma a largo plazo..................................................................................................................................44

13. XAdES.....................................................................................................................................................................................................4413.1. Forma canónica.............................................................................................................................................................................4513.2. Firma Digital XML..........................................................................................................................................................................45

Enveloping Signature.......................................................................................................................................................................46Enveloped Signature........................................................................................................................................................................46Detached Signature.........................................................................................................................................................................47Validación de una firma XML...........................................................................................................................................................48Ejemplo de una firma XML...............................................................................................................................................................48

13.3. Formas de firma digital XML avanzada.........................................................................................................................................50XAdES: básica.................................................................................................................................................................................51XAdES-T: sello de tiempo................................................................................................................................................................52XAdES-C: referencias a datos de validación (cadenas de certificados y listas de revocación).....................................................53XAdES-X: referencias a datos de validación y sello de tiempo sobre referencias a datos de validación y/o firma y otros sellos de tiempos.............................................................................................................................................................................................53

XAdES-X-L: datos de validación (cadenas de certificados y listas de revocación) y con referencias a datos de validación y sello de tiempo sobre referencias a datos de validación y/o firma y otros sellos de tiempos.................................................................55XAdES-A: datos de validación (cadenas de certificados y listas de revocación), referencias a datos de validación, sellos de tiempo periódicos para validar la firma a largo plazo, sello de tiempo sobre referencias a datos de validación y/o firma y otros sellos de tiempos..............................................................................................................................................................................55

14. PAdES.....................................................................................................................................................................................................5714.1. Perfiles PAdES..............................................................................................................................................................................57

PAdES Basic....................................................................................................................................................................................57PAdES Enhanced.............................................................................................................................................................................59PAdES Long Term............................................................................................................................................................................59PAdES XML......................................................................................................................................................................................60

15. @Firma...................................................................................................................................................................................................60

1. Función HashEl valor de una función hash es un número calculado a partir de un mensaje o documento. Básicamente, una función hash exhibe tres propiedades interesantes:

• no es posible recuperar el mensaje a partir del número

• para dos mensajes diferentes no se obtiene el mismo número

• la longitud de la representación del número calculado es independiente de la longitud del mensaje

Debido a estas propiedades, una función hash se utiliza para:

• indexar documentos

• comprobar la integridad de un documento

• almacenar contraseñas

Para su utilidad práctica, el algoritmo que implementa una función hash debe ser eficiente en cuanto al consumo de recursos: tiempo de procesador y uso de memoria.

Algoritmos que implementan una función hash son MD5 y SHA-1.

Ejemplos:

$ echo "hola mundo" | openssl dgst md5 (stdin)= 1e04bb3f9f396d3b71d93d326ebfc42d

$ echo "hola mundo" | openssl dgst sha1 (stdin)= f66b87fef5bf79850e957497ef2d529ce607b7ad

$ openssl dgst sha1 documento.txtSHA1(documento.txt)= 6d6aad4c5518695d6d6b9cb272aa14e18f2ca256

Una importante característica de las funciones hash es su calidad. Dado que el número de posibles valores de una función hash es finito y el número de mensajes es infinito, necesariamente se producen coincidencias entre los valores hash calculados para diferentes mensajes. Este hecho se conoce como colisión. Así, la calidad de una función hash se mide por la probabilidad de que se produzcan colisiones.

2. Código de AutenticaciónEl código de autenticación de un mensaje (MAC) es un número obtenido al cifrar el valor resultante de aplicar una función hash a un mensaje. De esta forma el receptor del mensaje puede verificar la INTEGRIDAD (el mensaje no ha sido modificado durante su transmisión) y la AUTENTICIDAD del origen del mensaje (todas aquellas partes que posean la clave).

No ofrece la propiedad de no repudio ya que cualquier parte (emisor o receptor) capaz de verificar un MAC puede también generar un MAC. Tampoco ofrece privacidad porque no se cifra el mensaje.

El emisor calcula el MAC de un mensaje y lo adjunta al mensaje. El receptor calcula mediante el mismo algoritmo y con la misma clave utilizada por el emisor un nuevo MAC a partir del mensaje y lo compara con el MAC recibido.

5 de 61

2.1. HMACUna implementación de un algoritmo MAC es HMAC (keyed-Hash Message Authentication Code) cuyo principio básico es:

MAC = h(k | h(k | M))

donde:

• h es una función hash

• k es la clave

• M es el mensaje

• | representa la concatenación de cadenas de caracteres

Ejemplos:

$ echo 'mi pedido' | openssl dgst hmac 'mi clave'(stdin)= 03852bdcf9d499605472785694112cbe78ab616d

$ echo 'mi pedido' | openssl dgst sha1 hmac 'mi clave'(stdin)= 03852bdcf9d499605472785694112cbe78ab616d

$ echo n '' | openssl dgst hmac ''(stdin)= fbdb1d1b18aa6c08324b7d64b71fb76370690e1d

$ perl MDigest::SHA e 'print Digest::SHA::hmac_sha1_hex("", ""), "\n";'

fbdb1d1b18aa6c08324b7d64b71fb76370690e1d

3. Cifrado SimétricoEn un sistema de cifrado simétrico se utiliza una única clave para cifrar y descifrar un mensaje o documento. El emisor utiliza una clave para cifrar un mensaje y el receptor del mensaje utiliza la misma clave para descifrar el mensaje.

El cifrado simétrico requiere un intercambio inicial de la clave entre el emisor y el receptor. Para ello se debe utilizar un canal de comunicación de confianza para ambos.

Mediante el cifrado simétrico se consigue INTEGRIDAD (el mensaje no ha sido modificado durante su transmisión), PRIVACIDAD (confidencialidad) y AUTENTICIDAD (se conoce el autor del mensaje).

En cuanto a la gestión de claves, el cifrado simétrico precisa una clave para cada par emisor/receptor lo cual complica la distribución de las claves.

Algoritmos de cifrado simétrico son: AES, Blowfish, DES, Triple-DES, etc...

Ejemplo de cifrado utilizando el algoritmo Blowfish:

$ openssl enc bf in document.in out document.bf k mypassword

$ openssl enc bf d in document.bf out document.out k mypassword

6 de 61

4. Cifrado AsimétricoA diferencia del cifrado simétrico, el cifrado asimétrico utiliza dos claves relacionadas matemáticamente entre sí. Un emisor puede cifrar el mensaje con una de las claves manteniéndola privada y publicar la otra clave para que el receptor pueda descifrar con ella el mensaje. Este procedimiento es reversible: el emisor puede utilizar cualquiera de sus dos claves para cifrar, utilizando entonces el receptor la otra clave del emisor para descifrar.

Alternativamente, el emisor puede utilizar una de las claves del receptor para cifrar, utilizando entonces el receptor su otra clave para descifrar el mensaje recibido. La utilización de una clave es complementaria a la utilización de la otra clave.

Para conseguir la PRIVACIDAD en una comunicación, el emisor utiliza habitualmente la clave pública del destinatario para cifrar el mensaje.

Actualmente, el algoritmo más popular que implementa el cifrado asimétrico es RSA:

c = me mod n m = c→

d mod n

donde:

• m es una representación númerica del mensaje sin cifrar (0 ≤ m < n)

• c es el mensaje cifrado (0 ≤ c < n)

• n se denomina módulo y resulta de multiplicar dos números primos, aleatorios y grandes, p y q

• e es un exponente que junto a n forman la clave pública. Típicamente e = 216

+1 = 65537

• d es la clave privada y se obtiene a partir de e y de la factorización p·q de n

En el contexto de RSA, la longitud de la clave es la longitud en bits del módulo. La seguridad del algoritmo RSA se basa en que actualmente no se sabe como obtener d en base al exponente e y sin conocer la factorización del módulo n. Y por supuesto, sin conocer d, tampoco se sabe como obtener la representación numérica m del mensaje original a partir del mensaje cifrado c.

Teóricamente, el cifrado asimétrico resuelve el problema del intercambio inicial de claves. En la práctica, sin embargo, se requiere además de un servicio de directorio para una eficaz distribución de claves.

La implementación del cifrado asimétrico consume mayor cantidad de recursos (tiempo de procesador y uso de memoria) con respecto a la implementación del cifrado simétrico.

4.1. Generación de clavesLas claves son números grandes y aleatorios. A continuación se muestra un ejemplo de generación de un par de claves para un cifrado asimétrico.

$ openssl genrsa out my.key 1024Generating RSA private key, 1024 bit long modulus..............++++++......++++++e is 65537 (0x10001)

Como resultado se obtiene:

$ openssl pkey in my.key text nooutPrivateKey: (1024 bit)modulus: 00:e1:8b:d9:44:dd:a2:41:4e:0d:8a:85:66:00:cb: 5d:8e:4d:e2:40:a7:a0:b7:41:5f:e3:93:72:f2:f3:

7 de 61

c3:6e:60:a5:b1:eb:87:53:1c:ba:bc:f9:fa:b7:d0: 14:0f:14:81:9c:5c:93:6f:36:ae:e6:0e:36:51:4f: a1:03:26:7a:17:2f:c9:0c:a7:a1:46:cb:2e:6a:d2: 9d:ff:20:20:19:79:de:52:97:0c:c5:ba:b8:cd:62: 2c:01:f1:3a:6a:a9:68:d5:31:eb:97:3c:3e:e0:d7: 8d:c9:8f:1d:6c:14:60:fc:e2:91:9c:a4:40:0a:24: a8:79:75:29:07:fc:7e:de:7fpublicExponent: 65537 (0x10001)privateExponent: 32:98:da:de:d6:11:86:30:ea:5c:be:dc:49:25:56: 11:8c:6b:4b:31:cf:9e:0c:ae:64:31:39:c2:42:e8: fe:a3:f3:c7:dc:1c:79:8a:a2:61:ae:7a:8e:2d:c1: b2:38:59:73:28:59:72:c3:83:ac:dc:57:57:1a:53: f6:8e:f5:28:3e:9c:f1:ef:b5:24:f0:23:c0:c3:ed: bf:cb:bf:f3:eb:be:af:ef:76:8f:ac:40:40:55:af: fd:da:76:1c:9f:39:12:6f:36:e1:28:43:cb:23:c1: 2e:9c:75:1c:c0:e0:b1:bb:a1:7e:41:64:e8:1a:47: 41:c9:b7:22:aa:4d:24:41prime1: 00:f5:19:14:9c:75:a5:ca:73:9b:f4:83:fe:b2:bf: 32:fc:e0:18:16:30:72:a7:1e:fc:85:93:ec:d2:6a: bc:5e:e6:e0:81:c8:8d:21:f3:62:4b:89:13:d4:f7: aa:62:c4:ce:54:35:d0:36:72:52:d5:d9:91:e0:ee: c1:1e:90:6d:11prime2: 00:eb:94:22:4f:5f:c9:2b:34:55:0d:fa:2d:1d:e0: 81:6e:49:48:4a:a1:11:2c:53:fb:2c:e5:31:87:a2: bc:ca:37:8a:53:b0:1c:1f:4b:0d:4d:a4:10:47:67: 3d:e1:6f:48:13:c9:91:cd:7b:a4:4e:b7:03:6c:17: cb:12:ba:d2:8fexponent1: 08:dd:fe:6b:e6:a9:b7:d8:54:e5:14:bd:6b:34:15: a1:26:6e:58:a7:2a:0e:b7:c5:45:03:e4:06:7c:cc: 11:d6:e2:7a:6f:8a:03:97:6d:8f:f4:06:9e:a6:d3: 28:3d:9c:85:59:69:0d:ff:36:d5:fb:c8:16:4e:2c: f8:71:1b:31exponent2: 00:b4:69:97:f5:0d:b8:34:5c:39:9f:20:af:18:a8: 6c:b7:17:6c:43:ab:22:49:be:6f:27:ac:c6:c7:c7: 3b:a9:e9:eb:07:b8:61:71:1d:bb:2c:70:ae:fe:df: f4:26:07:61:3d:b6:2a:f1:20:f5:6e:4a:fe:55:f3: ca:d3:a7:3b:c5coefficient: 00:e8:36:9f:4b:ec:fc:04:13:68:e4:fa:24:aa:6e: 33:a9:7c:b4:ec:d0:6d:47:dd:39:9c:29:fb:da:1d: 54:0a:a7:b8:44:5b:69:fb:01:48:1b:a1:ee:c1:13: ac:0c:02:5a:4b:62:ea:31:bf:6f:1e:68:d9:9a:6e: 35:9b:2c:e8:96

Multiplicando los dos números prime1 y prime2:

#!/usr/bin/perl w use strict; use Math::BigInt;

(my $prime1 = <<'PRIME1') =~ s/[:\s\n]+//g; 0x 00:f5:19:14:9c:75:a5:ca:73:9b:f4:83:fe:b2:bf: 32:fc:e0:18:16:30:72:a7:1e:fc:85:93:ec:d2:6a: bc:5e:e6:e0:81:c8:8d:21:f3:62:4b:89:13:d4:f7: aa:62:c4:ce:54:35:d0:36:72:52:d5:d9:91:e0:ee: c1:1e:90:6d:11 PRIME1

8 de 61

(my $prime2 = <<'PRIME2') =~ s/[:\s\n]+//g; 0x 00:eb:94:22:4f:5f:c9:2b:34:55:0d:fa:2d:1d:e0: 81:6e:49:48:4a:a1:11:2c:53:fb:2c:e5:31:87:a2: bc:ca:37:8a:53:b0:1c:1f:4b:0d:4d:a4:10:47:67: 3d:e1:6f:48:13:c9:91:cd:7b:a4:4e:b7:03:6c:17: cb:12:ba:d2:8f PRIME2

my $a = Math::BigInt>new(qq($prime1));

my $b = Math::BigInt>new(qq($prime2));

my $modulus = $a>bmul($b)>as_hex();

# pretty print $modulus =~ s/0x/00/; $modulus =~ s/(\w\w)/$1:/g; $modulus =~ s/((\w\w:){15})/$1\n/g; $modulus =~ s/:$//;

print $modulus, "\n";

se obtiene efectivamente el modulus cuya representación binaria contiene 1024 bits:

00:e1:8b:d9:44:dd:a2:41:4e:0d:8a:85:66:00:cb:5d:8e:4d:e2:40:a7:a0:b7:41:5f:e3:93:72:f2:f3:c3:6e:60:a5:b1:eb:87:53:1c:ba:bc:f9:fa:b7:d0:14:0f:14:81:9c:5c:93:6f:36:ae:e6:0e:36:51:4f:a1:03:26:7a:17:2f:c9:0c:a7:a1:46:cb:2e:6a:d2:9d:ff:20:20:19:79:de:52:97:0c:c5:ba:b8:cd:62:2c:01:f1:3a:6a:a9:68:d5:31:eb:97:3c:3e:e0:d7:8d:c9:8f:1d:6c:14:60:fc:e2:91:9c:a4:40:0a:24:a8:79:75:29:07:fc:7e:de:7f

Para obtener la clave privada:

$ openssl pkey in my.keyBEGIN PRIVATE KEYMIICeAIBADANBgkqhkiG9w0BAQEFAASCAmIwggJeAgEAAoGBAObJiSmXci/UmTtfEjiD0o0dw0CDNNITh1iwLDGWAtv1A+T2aAS3sY69dzd1yMJKFbe+Kqg6e2VzVuWOGAn2yyXsK/ibsxiZP9LP/a4oudpvpi0BT1FQAhpFw8SjjbuFaNQXhLfd7kmFiLReJQxcp/B/2dVfYxcosdRXy34cf0nnAgMBAAECgYEAiDCR4pteZN9edWzLAdK4o1HW8PD8cKPZkPqVecV+dnKGE81c4LvN6d/gxDebexvg6QctgQzR2LJRqzFI+khK5Dz1EXJ5bQsXNISm1EPzQAXArDq6Diy3JV/xNujYkC757KWbKIotoFXE5EWnCbOxv5fl9G01QZB7Jd97bUQMEqECQQD9VQ25VeUy4hp+yEmC1l4j1js5+nriE8R4wkw5wN5i2NIUCtQ+Lbej3BN2gi1yIV3Jez8Y7zNUa8qJI7TQ/k5/AkEA6Te0RuTtyVaWOmOaniJDsX7UfCjCa55ikbEUDIyVEM75c33R9FxZJMzuXKH2KKICPSuucRIaQYQZi0mWOQ2gmQJAZ1cAyC+/1WfigwFU62hi8p97fYUuB3ck2FX6Hj0M+qmT2NUqC0s+9DrcPaWQwFPYHE6ISLWa7L8j2ZmVMwPqJQJBAMJSjt0PfW5ovk4yli+zHzJzGnvFvpHLbBg3MxxtuvtBaiqoKNvyYri+JNJ8hU5AB5uOnRBL5CK4/kvH6erqBukCQQDM/Omx/+6VbRYBBy1IsLJct1DIquuOGdP2mpz030vCsxll9T2vMF17TboZTsxyE4gcvMXdcM7cm0WQzs37md/aEND PRIVATE KEY

Esta sección PEM, contiene el modulus, el publicExponent, el privateExponent, el número prime1, el número prime2, el exponent1, el exponent2 y el coefficient.

Para obtener la clave pública:

$ openssl pkey in my.key pubout9 de 61

BEGIN PUBLIC KEYMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDmyYkpl3Iv1Jk7XxI4g9KNHcNAgzTSE4dYsCwxlgLb9QPk9mgEt7GOvXc3dcjCShW3viqoOntlc1bljhgJ9ssl7Cv4m7MYmT/Sz/2uKLnab6YtAU9RUAIaRcPEo427hWjUF4S33e5JhYi0XiUMXKfwf9nVX2MXKLHUV8t+HH9J5wIDAQABEND PUBLIC KEY

Esta sección PEM, únicamente contiene el modulus y el publicExponent.

5. Envoltorio DigitalUn envoltorio digital (digital envelope) es una técnica combinada de utilización de claves de cifrado simétrico y claves de cifrado asimétrico. El emisor cifra el mensaje mediante una clave simétrica y a su vez cifra esta clave mediante la clave pública de cada receptor. Cada receptor utiliza su clave privada para obtener la clave simétrica con la cual descifra el mensaje recibido. De esta forma la clave simétrica puede ser la misma para todos lo receptores. En consecuencia el emisor solo necesita calcular un único mensaje cifrado.

Esta técnica explota la eficiencia del cifrado simétrico frente al cifrado asimétrico y delega el problema de distribución de claves a un sistema de claves públicas.

6. Firma DigitalUna firma digital se obtiene al cifrar con la clave privada de un sistema de cifrado asimétrico el resultado de una función hash aplicada al documento o mensaje que se pretende firmar.

La utilización de la clave privada del autor de la firma asegura su INTEGRIDAD, AUTENTICIDAD y la propiedad de NO REPUDIO: el emisor como único poseedor de la clave privada, no puede negar la generación de la firma.

Tomando el algoritmo RSA que implementa el cifrado asimétrico, se tiene para la firma:

s = hd mod n h = s→

e mod n

donde:

• h es un valor hash del mensaje a firmar

• s es la firma digital

• n se denomina módulo y resulta de multiplicar dos números primos, aleatorios y grandes, p y q

• e es un exponente que junto a n forman la clave pública. Típicamente e = 216

+1 = 65537

• d es la clave privada y se obtiene a partir de e y de la factorización p·q de n

10 de 61

El interesado en validar la firma, descifra el valor hash mediante la clave pública del autor de la firma y compara el resultado con un nuevo valor hash calculado sobre el documento o mensaje en cuestión.

Así pues, para validar la firma es necesario conocer la clave pública del firmante del mensaje, el algoritmo utilizado para el cifrado del resultado de la función hash y el algoritmo utilizado para la generación del valor hash.

Se podría prescindir de la función hash y cifrar directamente el mensaje con la clave privada. Sin embargo, el algoritmo RSA limita la longitud del mensaje a la longitud del módulo. Esta limitación se supera aplicando una función hash al mensaje y en lugar de cifrar el mensaje, se cifra el valor de la función hash.

Independientemente de esta característica y como ventaja adicional, se obtiene una mayor eficiencia al cifrar el valor hash ya que, en general y comparado con la longitud del mensaje, el valor hash suele ser de menor longitud.

La firma digital es un dato añadido al mensaje que se firma y NO garantiza la privacidad de la comunicación del mensaje.

Ejemplo 1:

Firmar:

$ openssl genrsa out my.key 1024$ openssl pkey in my.key pubout out pubkey.pem$ openssl dgst sha256 document.txt > hashA$ openssl rsautl sign in hashA inkey my.key out signature

Verificar:

$ openssl rsautl verify inkey pubkey.pem pubin in signature > hashB$ diff s hashA hashB Los archivos hashA y hashB son idénticos

Ejemplo 2:

Firmar:

$ openssl genrsa out my.key 1024$ openssl pkey in my.key pubout out pubkey.pem$ openssl dgst sha256 sign my.key out signature document.txt

Verificar:

11 de 61

$ openssl dgst sha256 verify pubkey.pem signature signature document.txt Verified OK

7. Sello de TiempoMediante un sello de tiempo (time-stamp) se pretende demostrar la existencia anterior a una determinada fecha y hora de un mensaje o documento.

El interesado calcula un hash del documento y lo envía como una petición a una tercera parte de confianza denominada Autoridad de Sellado de Tiempo (TSA). Esta obtiene un token de tiempo, adjunta el token al hash recibido, firma el resultado y lo envía como respuesta al interesado.

El interesado, después de verificar la firma de la TSA, comprueba su conformidad con la fecha y hora emitida y que el dato sellado por la TSA coincida con el hash del documento.

Este procedimiento presenta tres interesantes características:

• No se requiere exponer el documento

• El interesado no puede modificar el sello de tiempo

• El interesado no puede modificar el documento después del momento representado por el sello de tiempo

En base a la política que publica cada TSA para gestionar los sellos de tiempo, el interesado determinará la TSA que más le convenga.

La respuesta que emite la TSA es un archivo con una estructura especificada por PKCS#7.

Según RFC 3161, la TSA no está obligada a la identificación del interesado: las peticiones no incluyen información de identificación.

Ejemplo 1:

$ openssl ts query data documento.txt cert | tee documento.tsq | ./tsget h http://zeitstempel.dfn.de o documento.tsr

12 de 61

$ openssl ts query in documento.tsq textVersion: 1Hash Algorithm: sha1Message data: 0000 a5 88 af 65 88 86 93 c7b8 08 6a 7f 40 41 3f 0d ...e......j.@A?. 0010 c8 a4 77 71 ..wqPolicy OID: unspecifiedNonce: 0xF113D01AD11BB96BCertificate required: yesExtensions:

$ openssl ts reply in documento.tsr textStatus info:Status: Granted.Status description: Operation OkayFailure info: unspecified

TST info:Version: 1Policy OID: 1.3.6.1.4.1.22177.300.22.1Hash Algorithm: sha1Message data: 0000 a5 88 af 65 88 86 93 c7b8 08 6a 7f 40 41 3f 0d ...e......j.@A?. 0010 c8 a4 77 71 ..wqSerial number: 0x014274EA4940Time stamp: Nov 20 09:49:40 2013 GMTAccuracy: unspecifiedOrdering: noNonce: 0xF113D01AD11BB96BTSA: unspecifiedExtensions:

Ejemplo 2:

(ver con ASN.1 Decoder http://lapo.it/asn1js)

$ openssl pkcs7 inform DER in segell_acreditacio.tst textBEGIN PKCS7MIIKLAYJKoZIhvcNAQcCoIIKHTCCChkCAQMxCzAJBgUrDgMCGgUAMHAGCyqGSIb3DQEJEAEEoGEEXzBdAgEBBgtghVQBAwEBBAIBAjAhMAkGBSsOAwIaBQAEFKV2HugIxUd2cY5ML4MJFBNoUUnnAgQGTtEEGA8yMDEzMTExODEyMDQzNFowCQIBAYABAYEBAgIGAUJrGRIGoIIHWzCCB1cwggY/oAMCAQICAwUHnzANBgkqhkiG9w0BAQUFADBEMQswCQYDVQQGEwJFUzENMAsGA1UEChMETURFRjEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9NSU5JU0RFRi1FQy1XUEcwHhcNMTEwODE3MDk1NDA1WhcNMjEwODE3MDk1NDA1WjBlMQswCQYDVQQGEwJFUzENMAsGA1UECgwETURFRjEMMAoGA1UECwwDUEtJMRIwEAYDVQQFEwlTMjgzMzAwMkUxJTAjBgNVBAMMHFNlbGxvIGRlIHRpZW1wbyBUU0AgLSBAZmlybWEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5qDUzBp95YyOBNu35IdWJzQZEfQbX+LlF/NlUhy2mWllrZe7w2rITxd4MJR48XppnGdmVWkPpnSjGMfdX0+QzzS7h9hLPkFpOYU8wodp744jn3LbYi5j5Kzv4kLoJAQ9en/R/Y6T09hoDGOTvIbgVh6cq93ABJZPrxUH9n80RziPQZq36zQnBlKL3NhgHOCpIcjPuNC4njBAULo2xUZt+5SVjG8FqSQ6Ca8CvG6gi3jPausTPbfmRBCkTnUmMp33a6hrb4i2RwkCLnxL42/ACNVm+0fiKb5sNy92Fn4EaDMw3iMnqt6Yyrphsrmq2/IA38pV5HlzPZp6mvCD5IbvTAgMBAAGjggQvMIIEKzCB5gYDVR0RBIHeMIHbgRZzb3BvcnRlLmFmaXJtYTVAbXB0LmVzpIHAMIG9MR4wHAYJYIVUAQMFAgIBDA9zZWxsbyBkZSB0aWVtcG8xUDBOBglghVQBAwUCAgIMQU1pbmlzdGVyaW8gZGUgbGEgUG9sw610aWNhIFRlcnJpdG9yaWFsIHkgQWRtaW5pc3RyYWNpw7NuIFDDumJsaWNhMRgwFgYJYIVUAQMFAgIDDAlTMjgzMzAwMkUxLzAtBglghVQBAwUCAgUMIFRTQC0gQXV0b3JpZGFkIFNlbGxhZG8gZGUgdGllbXBvMIHEBgNVHRIEgbwwgbmBD2FncG1kQG9jLm1kZS5lc6SBpTCBojELMAkGA1UEBhMCRVMxDTALBgNVBAoMBE1ERUYxDDAKBgNVBAsMA1BLSTEmMCQGA1UEBwwdQXJ0dXJvIFNvcmlhIDI4OSAyODA3MSBNYWRyaWQxEjAQBgNVBAUTCVMyODAwMjMxSTEpMCcGA1UECwwgTWluaXN0ZXJpbyBkZSBEZWZlbnNhIGRl

13 de 61

http://lapo.it/asn1js

IEVzcGHDsWExDzANBgNVBAMMBlBLSURFRjAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDCDAdBgNVHQ4EFgQUex89EsdbbL4qPY4kdpqK84DTsyUwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vZXYwMS13cGcubWRlZi5lczo5MzA4MEQGA1UdIAQ9MDswOQYJYIVUAQEBAQMEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly9wa2kubWRlZi5lcy9jcHMvY3BzLmh0bTAfBgNVHSMEGDAWgBSr47khgFv6dg/HRtuwm4gLWrHKsjCCAYEGA1UdHwSCAXgwggF0MIIBcKCCAWygggFohoG2bGRhcDovLy9DTj1NSU5JU0RFRi1FQy1XUEcsQ049RUMtV1BHLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWV0LERDPW1kZSxEQz1lcz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGfWxkYXA6Ly9sZGFwLm1kZWYuZXMvY249TUlOSVNERUYtQ1JMLUVDLVdQRyxPVT1QS0ksTz1NREVGLEM9RVM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hi5odHRwOi8vcGtpLm1kZWYuZXMvY3JsL01JTklTREVGLUNSTC1FQy1XUEcuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAYGURzOt6/O0UOvGakW1Y4iBFT84ZeNByR17e1VsML1ZmIzl8QHv4yyhwCDPiD8U7k7EZApdV8TzPp0hE1pqyxb7UwFj7kGncEcA2TMJ9rMikho27SPk8lvj1McxbPxBBbsfWbGXZvx9/W1yt2l/ZCVboPSJ3I/FBTS3qFFUglR00uxTxpARTNLOzVgHlLkCtzvS+C7QZn6TGk7ESWUTeKXLg7DPC0/Fue8Ya0Pa45VDPEaVq8ucTNO6KT7JgBgNFZdPdbdxMHAoL+cK/W5iesxtgRu3FY8EyWmuMbFGx57xKpRsqQ+Noiz4xg3FCVWPQnTScjg7wNeNEuvuhNPdhvMYICNDCCAjACAQEwSzBEMQswCQYDVQQGEwJFUzENMAsGA1UEChMETURFRjEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9NSU5JU0RFRi1FQy1XUEcCAwUHnzAJBgUrDgMCGgUAoIG/MBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABBDAjBgkqhkiG9w0BCQQxFgQUa4xjBSoFZEE+UuUEGtO0D3GZC6cwfAYLKoZIhvcNAQkQAgwxbTBrMGkwZwQU9l4z1pdybfofLjtzQaae/NavzNAwTzBIpEYwRDELMAkGA1UEBhMCRVMxDTALBgNVBAoTBE1ERUYxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlOSVNERUYtRUMtV1BHAgMFB58wDQYJKoZIhvcNAQEBBQAEggEAMto4CADUc2nGBKjKUm2fBXpBeQ9grWA+p3mDXQKroIQaPf4ve0tmLCtCpOuCEdaCveBnAHXetsvRxgnGChwXRs24J6Ll3FTBj5zYzo6cSxHu3mtEBcD42RH7uk4tzOJNcFqn5o7jjiUDSdAD63DnNiGskDEfJ2Tf3/SjYnW6e9uAdLzBdTzbUNa3vtFKhZ616v14quvefiuzUFKtsii5oY9x2r+sczNe+WhgrPo2YRsweZmVcr/Vhnt/HkzildjQCnTSoFhhWyU2C1J4cDE76gtRdDSek3hHluQ3D1GzjYKovUQFMMtfW8NpMThmUGcuEGEgVcKUENI3qe7yg2tKog==END PKCS7

8. Certificado DigitalHasta aquí se han considerado las claves de un sistema de cifrado como monedas y billetes: el poseedor es el dueño legitimo de la clave. En un entorno globalmente interconectado no es posible conocer de una forma fiable la identidad de cada persona, entidad o sistema poseedor de una clave. Para demostrar la autenticidad de un mensaje y el no-repudio de una firma digital es necesario asociar las claves a personas, entidades o sistemas de una forma eficaz, fiable y legalmente válida. Esto se consigue mediante un certificado digital.

Un certificado digital relaciona una persona, entidad o sistema a una clave pública de un sistema de cifrado asimétrico.

Al igual que cada estado respalda la identidad de cada uno de sus ciudadanos mediante documentos de identidad expedidos por organismos oficiales, la asociación entre una clave pública y una persona, entidad o sistema es respaldada por una tercera parte denominada autoridad certificadora.

Se puede firmar con un certificado digital?

8.1. PKI X.509Además de reconocer la legitimidad de las claves también se debe facilitar la interoperabilidad entre sistemas que utilizan certificados digitales. Todo ello requiere regular la administración y gestión de certificados digitales estableciendo normas, recomendaciones y especificaciones.

El conjunto de normas, recomendaciones y especificaciones reconocido mundialmente se denomina X.509 que de

14 de 61

forma global, establece una infraestructura de clave pública (PKI).

Certificado digital X.509Básicamente, un certificado digital X.509 esta formado por un conjunto estructurado de atributos y valores:

• Subject: Persona o entidad asociada a la clave pública (Nombre Distinguido)

• Public Key: Clave pública

• Valid-From: Inicio del período de validez del certificado (Not Before)

• Valid-To: Fin del período de validez del certificado (Not After)

• Serial Number: Número de serie del certificado

• Issuer: Organismo o entidad que respalda el certificado (Nombre Distinguido)

• Signature: Firma digital del organismo o de la entidad que respalda el certificado

• Signature Algorithm: Algoritmo utilizado para crear la anterior firma digital

• Key-Usage: Atributo que indica el propósito de utilización de la clave pública, como por ejemplo cifrado, firma digital, firma de otros certificados, …

Autoridades

• Autoridad Certificadora (CA)

Organismo que crea, firma y registra certificados digitales. Los usuarios de la PKI reconocen este organismo como autoridad certificadora depositando su confianza en ella y aceptando sus reglas y procedimientos (políticas de certificación).

• Autoridad Registradora (RA)

Organismo subordinado a una CA que gestiona solicitudes de certificación y revocación. Puede aceptar o rechazar solicitudes. Comprueba la identidad y autenticación de usuarios solicitantes pero no firma certificados ni revocaciones de certificados.

UsosEn el momento de creación de un certificado digital X.509 se le asigna una serie de valores al atributo keyUsage según el propósito de utilización del certificado. De esta forma se limita el mal uso que pueda hacerse de él.

Según la especificación X.509, los posibles valores que puede tomar el atributo obligatorio keyUsage son:

• digitalSignature

• nonRepudiation

• keyEncipherment

• dataEncipherment

• keyAgreement15 de 61

• keyCertSign

• cRLSign

• encipherOnly

• decipherOnly

Para ampliar los usos posibles de un certificado digital, en una posterior revisión de la especificación X.509 se añadió el atributo opcional extendedKeyUsage. Los valores de este atributo deben ser consistentes con los valores asignados al atributo keyUsage:

• serverAuth (TLS WWW server authentication)

Debe ser consistente con los usos: digitalSignature, keyEncipherment o keyAgreement.

• clientAuth (TLS WWW client authentication)

Debe ser consistente con los usos: digitalSignature y/o keyAgreement.

• codeSigning (Signing of downloadable executable code)

Debe ser consistente con los usos: digitalSignature.

• emailProtection (Email protection)

Debe ser consistente con los usos: digitalSignature, nonRepudiation, y/o (keyEncipherment o keyAgreement).

• timeStamping (Binding the hash of an object to a time)

Debe ser consistente con los usos: digitalSignature y/o nonRepudiation.

• OCSPSigning (Signing OCSP responses)

Debe ser consistente con los usos: digitalSignature y/o nonRepudiation.

Políticas de certificaciónUna política de certificación determina un conjunto de reglas, procedimientos y condiciones al cual están sujetos los certificados emitidos por una determinada autoridad certificadora. Estas políticas pueden variar en función del uso o aplicación de cada certificado digital.

Las políticas de certificación abarcan aspectos tales como:

• procedimientos de renovación de certificados

• realización de cambios en certificados

• sistemas de archivo y copias de seguridad

• realización de auditorías

• medidas de seguridad implantadas

• períodos de ejecución de revocaciones

• publicación de listas de revocación

16 de 61

• algoritmos, parámetros y estándares utilizados

• generación de claves (quien y como)

• propiedad intelectual

• términos de privacidad

• responsabilidades y garantías

• ámbitos jurídicos

• tarifas y precios

• etc...

En la misma estructura de un certificado digital X.509 se encuentra un atributo denominado certificatePolicies cuyo valor hace referencia mediante un OID, a la política a la cual está sujeto el certificado.

Ejemplo de certificado digital X.509A continuación se muestra una representación de un certificado X.509 obtenida mediante

$ openssl x509 in PLATAFORMA.pem text

o bien

$ openssl x509 in PLATAFORMA.cer inform der text

Certificate: Data: Version: 3 (0x2) Serial Number: 37:93:8a:35:58:b4:2f:e9 Signature Algorithm: sha1WithRSAEncryption Issuer: C=ES, O=AC CAMERFIRMA S.A., L=MADRID (Ver en https://www.camerfirma.com/address), OU=AC CAMERFIRMA/serialNumber=A82743287, CN=AC CAMERFIRMA AAPP Validity Not Before: Nov 4 12:44:40 2010 GMT Not After : Nov 3 12:44:40 2013 GMT Subject: description=Qualified Certificate: AAPPSEPMSWKPSC, CN=PLATAFORMA INTEGRACION/serialNumber=G07896004, OU=sello electr\xF3nico, O=FUNDACI\xD3 IBIT, C=ES Subject Public Key Info: Public Key Algorithm: rsaEncryption PublicKey: (1024 bit) Modulus: 00:de:3b:fe:20:e6:1b:bc:b9:38:30:d3:2c:7b:ea: d4:d6:58:f7:73:6b:6e:e5:f0:4a:e8:f6:28:b4:a4: 7b:7f:53:f1:91:d6:41:90:dc:bf:5e:72:d2:b7:a3: 72:5b:bc:5e:06:a2:6b:65:a2:67:22:c4:38:1d:07: 13:10:43:76:1f:9d:03:ae:86:fe:f9:64:46:34:a5: 3b:9e:27:33:2d:6e:1b:64:8d:1d:27:58:56:f7:f6: db:1a:cc:4a:f3:c8:fb:61:09:00:33:71:de:13:79: 1b:9f:b3:fb:4c:66:f7:fc:80:c2:d8:39:88:7d:2f: 46:0e:ab:d7:b3:e2:f3:a9:c7 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE

17 de 61

X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, Email Protection X509v3 Subject Key Identifier: EA:41:E9:3B:F7:BC:6A:12:DD:A1:2A:5A:40:A5:8F:22:82:A7:A2:ED Authority Information Access: CA Issuers URI:http://www.camerfirma.com/certs/AC_CAMERFIRMA_AAPP.crt OCSP URI:http://ocsp.camerfirma.com X509v3 Authority Key Identifier: keyid:E5:46:50:E8:43:A0:B2:F7:1C:E4:B6:FF:D8:00:04:20:F7:1F:A4:0B DirName:/C=EU/O=AC Camerfirma SA CIF A82743287/OU=http://www.chambersign.org/CN=Chambers of Commerce Root serial:0D X509v3 CRL Distribution Points: Full Name: URI:http://crl.camerfirma.com/AC_CAMERFIRMA_AAPP.crl Full Name: URI:http://crl1.camerfirma.com/AC_CAMERFIRMA_AAPP.crl X509v3 Subject Alternative Name: DirName:/2.16.724.1.3.5.2.1.1=sello electr\xC3\xB3nico/2.16.724.1.3.5.2.1.2=FUNDACI\xC3\x93 IBIT/2.16.724.1.3.5.2.1.3=G07896004/2.16.724.1.3.5.2.1.5=PLATAFORMA INTEGRACION X509v3 Issuer Alternative Name: email:[email protected] X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.17326.1.3.3.2 CPS: https://policy.camerfirma.com User Notice: Explicit Text: Certificado reconocido de sello electrónico de Administración, órgano o entidad de derecho público, nivel Medio. Consulte condiciones de uso en https://policy.camerfirma.com qcStatements: 0.0......F..0......F..... Signature Algorithm: sha1WithRSAEncryption be:99:d4:dc:ac:c1:95:9a:4f:8b:0c:2e:cf:dc:6c:20:d9:ad: 7f:8f:da:a9:7e:67:4e:d9:ac:90:14:db:25:0a:3b:d9:19:90: f7:83:c6:e0:75:bb:b4:a1:b1:fa:fb:87:f0:33:15:5e:b0:9a: 74:32:86:69:92:d3:ab:04:ad:4b:aa:39:09:59:3e:2b:78:bf: 9d:5a:95:e7:2d:03:05:db:bf:5d:1c:9c:52:84:b7:71:13:58: 50:f9:af:c4:0e:64:e5:19:5b:ba:eb:b7:aa:c4:6c:7e:42:eb: bc:20:43:da:5e:17:f1:51:f5:e4:b9:1b:0b:87:38:5d:d6:96: 34:d2:64:9b:03:7e:1e:bf:b5:c1:72:a3:ed:04:4d:5d:57:5d: 8e:f6:e5:25:29:d9:0a:54:36:a9:71:d3:fc:f7:5c:c8:68:97: 24:41:4c:a3:e3:8f:82:0f:94:d1:45:5f:ea:3e:f0:bc:80:84: b4:a3:34:db:9a:04:ec:04:7f:e6:fe:39:77:e2:0a:3b:29:aa: 84:19:da:88:9d:e6:c6:3d:7d:d5:f5:a7:87:5a:a3:99:24:10: fe:5d:cf:3e:1c:d0:f4:c3:7d:6f:15:28:71:13:c2:9f:6a:7c: e6:2a:37:65:d5:0f:52:1f:56:72:f5:9a:d0:ed:6c:8f:4a:e8: d1:21:78:71BEGIN CERTIFICATEMIIHUjCCBjqgAwIBAgIIN5OKNVi0L+kwDQYJKoZIhvcNAQEFBQAwgbAxCzAJBgNVBAYTAkVTMRswGQYDVQQKExJBQyBDQU1FUkZJUk1BIFMuQS4xOzA5BgNVBAcTMk1BRFJJRCAoVmVyIGVuIGh0dHBzOi8vd3d3LmNhbWVyZmlybWEuY29tL2FkZHJlc3MpMRYwFAYDVQQLEw1BQyBDQU1FUkZJUk1BMRIwEAYDVQQFEwlBODI3NDMyODcxGzAZBgNVBAMTEkFDIENBTUVSRklSTUEgQUFQUDAeFw0xMDExMDQxMjQ0NDBaFw0xMzExMDMxMjQ0NDBaMIGqMTIwMAYDVQQNEylRdWFsaWZpZWQgQ2VydGlmaWNhdGU6IEFBUFAtU0VQLU0tU1ctS1BTQzEfMB0GA1UEAxMWUExBVEFGT1JNQSBJTlRFR1JBQ0lPTjESMBAGA1UEBRMJRzA3ODk2MDA0MRowGAYDVQQLFBFzZWxsbyBlbGVjdHLzbmljbzEWMBQGA1UEChQNRlVOREFDSdMgSUJJVDELMAkGA1UEBhMCRVMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN47/iDmG7y5ODDTLHvq1NZY93NrbuXwSuj2KLSke39T8ZHWQZDcv15y0rejclu8Xgaia2WiZyLEOB0HExBDdh+dA66G/vlkRjSlO54nMy1uG2SNHSdYVvf22xrMSvPI+2EJADNx3hN5G5+z+0xm9/yAwtg5iH0vRg6r17Pi86nHAgMBAAGjggP2MIID8jAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIE8DAd

18 de 61

BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOpB6Tv3vGoS3aEqWkCljyKCp6LtMHoGCCsGAQUFBwEBBG4wbDBCBggrBgEFBQcwAoY2aHR0cDovL3d3dy5jYW1lcmZpcm1hLmNvbS9jZXJ0cy9BQ19DQU1FUkZJUk1BX0FBUFAuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5jYW1lcmZpcm1hLmNvbTCBqwYDVR0jBIGjMIGggBTlRlDoQ6Cy9xzktv/YAAQg9x+kC6GBhKSBgTB/MQswCQYDVQQGEwJFVTEnMCUGA1UEChMeQUMgQ2FtZXJmaXJtYSBTQSBDSUYgQTgyNzQzMjg3MSMwIQYDVQQLExpodHRwOi8vd3d3LmNoYW1iZXJzaWduLm9yZzEiMCAGA1UEAxMZQ2hhbWJlcnMgb2YgQ29tbWVyY2UgUm9vdIIBDTB6BgNVHR8EczBxMDagNKAyhjBodHRwOi8vY3JsLmNhbWVyZmlybWEuY29tL0FDX0NBTUVSRklSTUFfQUFQUC5jcmwwN6A1oDOGMWh0dHA6Ly9jcmwxLmNhbWVyZmlybWEuY29tL0FDX0NBTUVSRklSTUFfQUFQUC5jcmwwgZQGA1UdEQSBjDCBiaSBhjCBgzEhMB8GCWCFVAEDBQIBAQwSc2VsbG8gZWxlY3Ryw7NuaWNvMR0wGwYJYIVUAQMFAgECDA5GVU5EQUNJw5MgSUJJVDEYMBYGCWCFVAEDBQIBAwwJRzA3ODk2MDA0MSUwIwYJYIVUAQMFAgEFDBZQTEFUQUZPUk1BIElOVEVHUkFDSU9OMCEGA1UdEgQaMBiBFnNvcG9ydGVAY2FtZXJmaXJtYS5jb20wggELBgNVHSAEggECMIH/MIH8BgwrBgEEAYGHLgEDAwIwgeswKQYIKwYBBQUHAgEWHWh0dHBzOi8vcG9saWN5LmNhbWVyZmlybWEuY29tMIG9BggrBgEFBQcCAjCBsBqBrUNlcnRpZmljYWRvIHJlY29ub2NpZG8gZGUgc2VsbG8gZWxlY3Ry825pY28gZGUgQWRtaW5pc3RyYWNp824sIPNyZ2FubyBvIGVudGlkYWQgZGUgZGVyZWNobyBw+mJsaWNvLCBuaXZlbCBNZWRpby4gQ29uc3VsdGUgY29uZGljaW9uZXMgZGUgdXNvIGVuIGh0dHBzOi8vcG9saWN5LmNhbWVyZmlybWEuY29tMCUGCCsGAQUFBwEDBBkwFzAIBgYEAI5GAQEwCwYGBACORgEDAgEPMA0GCSqGSIb3DQEBBQUAA4IBAQC+mdTcrMGVmk+LDC7P3Gwg2a1/j9qpfmdO2ayQFNslCjvZGZD3g8bgdbu0obH6+4fwMxVesJp0MoZpktOrBK1LqjkJWT4reL+dWpXnLQMF279dHJxShLdxE1hQ+a/EDmTlGVu667eqxGx+Quu8IEPaXhfxUfXkuRsLhzhd1pY00mSbA34ev7XBcqPtBE1dV12O9uUlKdkKVDapcdP891zIaJckQUyj44+CD5TRRV/qPvC8gIS0ozTbmgTsBH/m/jl34go7KaqEGdqInebGPX3V9aeHWqOZJBD+Xc8+HND0w31vFShxE8KfanzmKjdl1Q9SH1Zy9ZrQ7WyPSujRIXhxEND CERTIFICATE

Creación de un certificado digitalEl punto de partida para la obtención de un certificado digital es la disposición de un par de claves de cifrado asimétrico:

$ openssl genrsa out my.key 1024

Una vez obtenidas las claves, el interesado debe crear a partir de ellas una petición de firma de certificado CSR (Certificate Signing Request):

$ openssl req out my.csr key my.key new

$ openssl req in my.csr text verify nooutverify OKCertificate Request: Data: Version: 0 (0x0) Subject: C=EU, ST=Balears, L=Palma, O=Internet Widgits Pty Ltd, OU=OTAE, CN=ADMINISTRACION ELECTRONICA/[email protected] Subject Public Key Info: Public Key Algorithm: rsaEncryption PublicKey: (1024 bit) Modulus: 00:9d:4b:3d:79:d2:d1:df:59:f7:24:9c:b9:92:0d: 46:ae:c0:69:53:46:1e:0b:20:1c:84:b3:5b:3c:7e: 96:fa:25:91:27:98:13:63:0a:53:95:c2:75:fd:6c: c4:7c:47:1f:d5:85:63:7e:33:72:16:ed:40:d7:35: a6:1e:c7:02:aa:77:c7:bf:27:ab:c4:19:f6:9b:fc: 2f:6c:6d:58:cf:5b:61:eb:a7:15:40:56:b7:4c:9e:

19 de 61

c3:01:7b:3b:34:fc:d2:aa:d8:16:b5:94:7f:da:49: dc:94:59:8e:c7:38:ae:0a:50:27:38:16:00:de:2a: a6:30:f3:b8:4d:a4:1f:9b:f3 Exponent: 65537 (0x10001) Attributes: a0:00 Signature Algorithm: sha1WithRSAEncryption 31:bc:8f:0e:f9:e7:5e:52:75:ad:22:dc:5c:8b:12:4f:65:44: fe:fc:a6:0e:d8:e8:b2:e9:5c:3a:68:98:7e:a0:83:65:8c:b6: 05:84:bc:8c:ce:bb:13:85:0b:c9:18:ac:30:78:79:a3:f3:9c: a5:e0:44:e7:03:1f:25:2a:0b:b2:72:e5:e3:ef:f9:5f:e7:0d: 83:db:d3:82:33:b3:b7:33:0e:94:dc:5b:47:2d:47:26:df:3a: 50:b2:2a:46:b8:bf:df:28:9d:d9:74:42:9b:ad:2e:84:65:a5: 0b:1d:0a:0c:39:8e:23:cf:81:de:a6:b2:36:64:fa:57:83:8b: d8:da

Como se puede observar, se trata de una estructura de datos que contiene la clave pública generada por el interesado y la identidad en formato DN (Nombre Distinguido) del sujeto que se pretende asociar a la clave pública. Esta petición se firma con la clave privada asociada a la clave pública y se entrega a una autoridad certificadora (CA) o una autoridad de registro (RA).

Porque se firma la CSR?

Para emitir un certificado digital, la CA o RA necesita comprobar la identidad del sujeto (persona o entidad) que se pretende asociar a una clave pública. En el caso de una persona, esta comprobación se suele realizar de forma presencial y mediante un documento de identidad.

Una vez comprobada la identidad del sujeto, la CA obtiene de la CSR la clave pública y el DN del sujeto en cuestión. Con estos datos, la CA creará una nueva estructura de datos incorporando un número de serie propio de la CA y otros atributos en función de las necesidades del interesado: validez temporal, usos, etc... Finalmente, la CA firma la estructura de datos resultante y la entrega como un certificado digital al interesado.

Pueden existir diferentes certificados con la misma clave pública?

Pueden existir diferentes certificados con la misma clave pública y con diferentes Subject?

Pueden existir diferentes certificados con la misma clave pública y un mismo Subject?

Pueden existir diferentes certificados con la misma clave pública y un mismo Issuer?

Creación de un certificado digital autofirmadoUn certificado digital para el cual el sujeto asociado a la clave pública coincide con el organismo o entidad que respalda el certificado se denomina certificado digital autofirmado. En este caso desaparece la función principal de una autoridad certificadora: certificar la asociación entre una clave pública y una persona o entidad. Así, en lugar de confiar en una CA, el usuario del certificado confía en el creador del certificado.

Un certificado autofirmado ofrece PRIVACIDAD pero solo ofrece AUTENTICIDAD si se conoce el Subject del certificado o se confía en el creador del certificado. Por ello, la utilización de certificados autofirmados es apropiada en entornos de desarrollo, en conexiones SSL que solo requieren privacidad y en cadenas de certificación en cuyo caso actúan como certificados raíz.

Con respecto a esto último, se puede pensar que un certificado raíz siempre es un certificado autofirmado. En cambio, un certificado autofirmado no tiene porque ser un certificado raíz: cuando no se utiliza para firmar otros certificados.

Ejemplo:

20 de 61

$ openssl req x509 days 365 newkey rsa:2048 keyout private.key out certificado.crt nodes

$ openssl x509 in certificado.crt text noout Certificate: Data: Version: 3 (0x2) Serial Number: 8a:a3:3c:a0:86:ab:b3:46 Signature Algorithm: sha1WithRSAEncryption Issuer: C=EU, ST=Balears, L=Palma, O=Internet Widgits Pty Ltd, OU=OTAE, CN=ADMINISTRACION ELECTRONICA/[email protected] Validity Not Before: Nov 28 07:11:45 2013 GMT Not After : Nov 28 07:11:45 2014 GMT Subject: C=EU, ST=Balears, L=Palma, O=Internet Widgits Pty Ltd, OU=OTAE, CN=ADMINISTRACION ELECTRONICA/[email protected] Subject Public Key Info: Public Key Algorithm: rsaEncryption PublicKey: (2048 bit) Modulus: 00:92:e0:5a:44:32:00:5b:a6:35:b1:a6:ca:0b:25: 06:94:94:f6:99:92:d5:e3:c1:52:2f:f2:17:e3:7e: c1:a8:1a:e7:c5:8a:19:29:2b:2c:40:7b:c8:4c:be: c9:74:33:a4:45:d4:3b:9c:73:ca:90:8f:20:34:4a: ec:0e:ff:ef:7f:c7:78:8c:92:e0:35:2d:b3:23:fe: c3:d1:5e:68:89:fd:3a:62:81:35:e1:4e:55:ec:d4: 51:f6:21:f3:ab:07:0a:86:40:37:f1:5e:22:67:05: 29:01:a2:9d:56:94:21:4e:c0:63:56:4d:85:70:40: 28:b5:6f:fb:be:a2:41:b6:ca:a4:e4:d1:66:da:06: ef:a0:8f:63:cc:83:c8:a8:26:6e:b2:fa:f1:a2:7e: cb:42:36:ab:fd:ef:e4:af:01:f7:b9:b7:b7:a8:80: b3:0f:8a:f1:dd:78:fc:c5:4a:37:60:2c:bb:71:83: 78:60:eb:2f:b1:d8:c0:d9:ee:d0:b1:20:3c:6a:e3: 0f:96:ff:9d:6b:16:e7:46:f6:06:96:cc:03:96:7b: bd:58:96:e5:9d:98:4c:88:60:b6:3d:d6:c8:db:44: 35:e5:35:bb:e1:39:9a:dd:91:c0:cd:22:cc:9f:cc: 01:90:2f:95:cd:11:7b:b4:ba:80:f2:a0:62:06:ce: c8:e5 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 46:83:16:FF:99:44:11:74:58:6A:0B:E6:48:8C:04:7B:A8:53:9F:E8 X509v3 Authority Key Identifier: keyid:46:83:16:FF:99:44:11:74:58:6A:0B:E6:48:8C:04:7B:A8:53:9F:E8

X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha1WithRSAEncryption 70:7f:05:8c:eb:0b:19:e4:30:fe:50:84:ba:82:10:45:be:d3: 26:11:c0:66:1d:be:c5:08:2b:7c:d5:e2:42:12:68:e7:d3:d2: a7:a9:5a:8b:39:23:76:b7:ae:3c:0c:3f:9c:7f:de:02:3c:03: a2:52:f0:1c:da:17:37:d5:a8:74:c7:b6:57:4e:1f:56:89:97: 27:ec:b4:12:2a:5a:ce:c6:c9:3b:9f:94:f0:15:84:34:23:b6: 3f:e7:c1:92:b3:71:de:c9:f6:fa:25:12:d3:8a:9b:91:7e:c2: f9:9d:fa:75:45:b5:7e:08:89:07:98:8c:11:b1:3e:99:1f:d3: d9:7c:2a:22:4b:95:ee:9b:2b:04:61:4a:46:9d:e5:09:d8:d9: 57:ec:d5:53:14:de:cb:8a:94:9f:4e:a6:e5:6f:bf:4b:61:fc: c9:72:74:60:82:dd:50:60:5b:a4:17:a3:45:cf:71:d5:02:6c: 34:5a:85:55:ae:9c:40:bc:36:57:07:6e:cc:ac:e0:24:ad:46: 4c:14:c6:f6:47:77:e2:1e:50:9a:19:49:20:5d:79:52:60:8c: 9b:5c:95:31:ca:cf:de:7b:a3:e6:f6:7e:00:54:ac:41:52:85: ce:f2:03:f5:8d:1f:17:7d:86:ba:d4:f8:ce:91:ed:bf:80:29: 7a:fd:af:43

21 de 61

RevocaciónAdemás de criterios basados en los mismos atributos del certificado (período de validez, usos, etc...) un certificado puede ser invalidado por otros motivos: el compromiso de la clave privada asociada al certificado, el cese de actividad del Subject del certificado, etc...

Como ejemplo, un certificado puede estar revocado sin haber caducado o puede haber caducado sin estar revocado.

Forma parte de la validación de un certificado digital la comprobación de su estado de revocación. Para comprobar el estado de revocación de un certificado se utilizan dos mecanismos: listas de revocación o un protocolo en línea.

Lista de certificados revocados

Una lista de certificados revocados (CRL) es una lista de certificados digitales que son considerados no válidos por la autoridad certificadora (CA) que emitió los certificados contenidos en esta lista.

Esta lista la publica y firma periódicamente la misma CA que creó los certificados. Las listas de revocación se suelen distribuir según un modelo push (envío no solicitado por el cliente) o pull (envío solicitado por el cliente).

Para sincronizar con posibles validaciones de certificados, cada CRL especifica su fecha de publicación y la fecha de su próxima publicación.

Ejemplo:

$ wget http://crl.camerfirma.com/AC_CAMERFIRMA_AAPP.crl$ openssl crl inform der text noout in AC_CAMERFIRMA_AAPP.crlCertificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: md5WithRSAEncryption Issuer: /C=ES/O=AC CAMERFIRMA S.A./L=MADRID (Ver en https://www.camerfirma.com/address)/OU=AC CAMERFIRMA/serialNumber=A82743287/CN=AC CAMERFIRMA AAPP Last Update: Nov 25 10:56:10 2013 GMT Next Update: Nov 27 10:56:10 2013 GMT CRL extensions: X509v3 Authority Key Identifier: keyid:E5:46:50:E8:43:A0:B2:F7:1C:E4:B6:FF:D8:00:04:20:F7:1F:A4:0B DirName:/C=EU/O=AC Camerfirma SA CIF A82743287/OU=http://www.chambersign.org/CN=Chambers of Commerce Root serial:0D

X509v3 CRL Number: 3410Revoked Certificates: Serial Number: A71D0D37DF454B Revocation Date: Jul 26 10:57:00 2011 GMT CRL entry extensions: X509v3 CRL Reason Code: Cessation Of Operation Serial Number: 0369E6EC8DC8A99F Revocation Date: Jan 23 08:41:08 2012 GMT CRL entry extensions: X509v3 CRL Reason Code: Affiliation Changed Serial Number: FFAFA22F155E5F2D Revocation Date: Sep 19 11:57:06 2011 GMT CRL entry extensions: X509v3 CRL Reason Code: Unspecified Serial Number: FFB8E24406495F69 Revocation Date: Sep 23 06:11:01 2013 GMT CRL entry extensions: X509v3 CRL Reason Code:

22 de 61

Superseded Signature Algorithm: md5WithRSAEncryption 7e:e1:5b:b0:6c:dd:45:a6:ab:03:f2:37:5b:1e:2d:5c:32:fa: b6:96:74:23:a4:1c:3e:ca:2d:18:05:56:6c:c0:99:ca:ca:cb: fa:1f:1b:2b:cb:62:ea:ed:ec:1a:08:8c:a8:c2:42:8e:bd:be: ac:e5:bb:6f:32:d3:d0:b3:a4:e5:71:39:57:d0:36:9f:d2:dd: 78:92:9a:b6:fa:45:57:ad:cb:6e:4d:dd:fd:82:66:66:24:8a: ab:ca:35:54:f7:cc:0d:b1:02:2e:25:01:81:64:34:37:df:42: 34:14:5b:19:d5:49:0b:99:bf:f9:5c:1a:b1:c3:63:f2:d1:b4: 38:86:6f:ee:7c:17:c3:c7:9c:a7:1a:36:7f:3d:56:d7:46:0f: 6d:ca:f1:d0:c1:d5:d7:b1:41:fe:ae:1e:04:0d:84:e7:4a:48: 1d:2c:6f:91:81:1b:dc:a0:18:58:9e:61:43:8e:dd:0a:7a:61: 24:64:b7:ce:16:9c:fc:15:02:05:bd:62:c4:87:20:d8:8f:a9: 0d:a5:72:cf:01:89:c7:7e:4d:15:8a:13:b1:f9:67:70:48:49: 65:a7:5e:a6:ba:c9:3c:97:2e:ec:9c:65:6a:5a:fc:df:0b:56: 11:71:e6:4a:ea:18:a8:b7:36:b6:19:7d:7a:0d:cc:0c:83:e1: a2:62:d9:00

Protocolo de estado de certificado en línea

Una lista de certificados revocados presenta dos potenciales inconvenientes: la actualidad de la información y la cantidad de datos que contiene. Para mitigar estos inconvenientes se creó el protocolo OCSP (Online Certificate Status Protocol) que responde en tiempo real a peticiones puntuales sobre el estado de revocación de un determinado certificado digital. Los mensajes enviados mediante OCSP se transmiten típicamente sobre HTTP.

Si la autoridad certificadora soporta OCSP, los certificados emitidos por ella pueden contener un atributo denominado authorityInfoAccess el cual especificará el punto de acceso (URL) al servidor (responder) que atiende a las peticiones de estado de revocación. Las respuestas de un responder están firmadas por la CA que emitió el certificado en cuestión o por un responder delegado por la CA.

Obtener una respuesta OCSP requiere tiempo de conexión. Si se realizan o se validan firmas en modo batch y se precisa obtener datos de validación para cada firma, resulta más eficiente obtener una CRL en lugar de una respuesta OCSP por cada certificado.

Tres son las posibles respuestas OCSP sobre el estado de un certificado digital: good, revoked o unknown.

Las implementaciones de un responder OCSP suelen estar respaldadas por un proceso de generación de listas de revocación. Esto es, el responder genera las respuestas en base al contenido de una CRL. Así, una respuesta good no garantiza la existencia de un certificado digital (como requiere la legislación de algunos países para la validación de un certificado digital).

Ejemplo:

$ wget http://www.camerfirma.com/certs/AC_CAMERFIRMA_AAPP.crt$ openssl x509 inform der in AC_CAMERFIRMA_AAPP.crt out AC_CAMERFIRMA_AAPP.pem$ openssl ocsp issuer AC_CAMERFIRMA_AAPP.pem cert PLATAFORMA_INTEROPERABILIDAD.pem url http://ocsp.camerfirma.com/ noverify resp_text respout resp.derOCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: C = ES, O = AC Camerfirma SA, CN = OCSP Responder AC CAMERFIRMA AAPP, emailAddress = [email protected], serialNumber = A82743287 Produced At: Nov 25 11:43:17 2013 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: E8200C085A817BCEEACCC11FB40223527C8E5411 Issuer Key Hash: E54650E843A0B2F71CE4B6FFD8000420F71FA40B Serial Number: 37938A3558B42FE9 Cert Status: good This Update: Nov 25 11:43:17 2013 GMT

23 de 61

Response Extensions: OCSP Nonce: 041092443D21613A5187F26BB728CB5B9ED1 Signature Algorithm: sha1WithRSAEncryption 4d:36:a6:72:4f:b8:20:9f:94:f6:d5:14:38:15:94:cf:ce:9a: d6:53:64:ca:d0:51:7b:d4:4d:44:ab:63:e5:f1:ed:ee:af:9a: 9e:2e:7d:ef:a4:78:fe:32:55:c3:f3:a8:7a:6e:4a:2a:e7:d1: 8e:39:e3:d5:33:df:3f:2a:c5:f5:7d:0e:28:8d:4a:58:ad:7f: 43:4e:f0:35:6c:29:6f:e0:d5:24:76:08:9f:e5:4e:c2:d9:6e: 9c:4d:10:5e:63:e4:95:bf:77:a4:0a:1b:7c:03:0d:d3:f0:f1: 82:e0:02:01:e3:64:d9:40:c1:47:ed:61:6d:07:9c:87:46:31: e0:1d:ba:58:48:ec:f8:e7:1a:2d:33:69:90:e0:d6:8b:21:6e: 1a:c4:ce:0c:3b:86:a8:e7:d5:97:d7:6c:71:38:a5:81:60:23: 64:4b:8a:30:7e:0c:ab:d3:31:83:43:e5:55:d5:76:6f:4a:c2: e3:8c:50:a3:00:2b:8c:6b:a6:d8:55:c5:55:dd:ce:96:10:4b: a0:49:45:a1:76:78:15:74:35:8b:e6:ab:13:16:ba:97:61:0b: 4b:1d:bd:39:5f:29:7c:38:ba:fb:4a:4f:64:0a:9d:3c:e8:b6: 4a:38:f8:b1:6a:2e:0b:f5:a2:30:3f:4e:21:d0:65:d3:f9:e5: eb:e4:17:d1Certificate: Data: Version: 3 (0x2) Serial Number: 11:cc:bb:cc:bb:00:14:58 Signature Algorithm: sha1WithRSAEncryption Issuer: C=ES, O=AC CAMERFIRMA S.A., L=MADRID (Ver en https://www.camerfirma.com/address), OU=AC CAMERFIRMA/serialNumber=A82743287, CN=AC CAMERFIRMA AAPP Validity Not Before: Dec 5 10:07:14 2012 GMT Not After : Dec 5 10:07:14 2014 GMT Subject: C=ES, O=AC Camerfirma SA, CN=OCSP Responder AC CAMERFIRMA AAPP/[email protected]/serialNumber=A82743287 Subject Public Key Info: Public Key Algorithm: rsaEncryption PublicKey: (2048 bit) Modulus: 00:a8:39:b3:15:90:c0:9f:5b:c6:a2:6c:5b:0b:e0: 0f:e8:ef:e3:9a:e1:7e:9c:25:aa:83:e6:00:4e:76: ba:a0:0b:14:b4:56:9d:93:8d:8c:be:3f:3f:d3:36: 17:6d:d3:44:c5:b5:88:b1:85:05:8f:6d:45:8e:fc: 1c:cf:83:18:b1:d8:d8:75:c4:7d:db:c7:f1:a5:e6: df:1d:f7:f2:7f:e5:a5:35:23:18:1a:64:bf:6f:a5: c0:c8:28:ef:e5:c5:6d:dd:71:d2:f1:fa:41:7d:1b: 52:95:b5:2e:c8:2a:0c:36:67:c1:08:34:44:4f:76: e1:62:7c:65:70:e0:b8:d6:02:0f:6b:72:9d:90:77: 64:6d:a0:df:71:f2:cd:73:ba:61:ad:c0:be:b2:f7: 30:5a:ad:3f:b3:2b:ca:ff:d9:92:4e:71:c9:c5:4c: c0:bf:79:aa:af:70:87:b4:ef:f9:88:50:8d:f4:ba: 17:5a:81:3b:5b:a7:7b:f3:1c:ea:c8:4d:53:ae:80: cc:87:94:2b:76:95:b8:e9:0b:04:dc:c7:d4:c7:bb: 9b:dd:49:63:d9:f2:4a:d4:e4:f2:5b:ec:2c:46:8f: 17:b8:45:59:dd:3b:9a:ac:2a:37:06:70:26:d8:50: d4:79:a3:36:63:9e:d8:f1:0b:12:8d:6e:82:5c:bb: e9:cf Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment X509v3 Extended Key Usage: OCSP Signing X509v3 Subject Key Identifier: 55:BF:1D:62:97:B9:36:39:D0:75:B1:8E:DB:32:33:17:C9:C7:22:81

24 de 61

X509v3 Authority Key Identifier: keyid:E5:46:50:E8:43:A0:B2:F7:1C:E4:B6:FF:D8:00:04:20:F7:1F:A4:0B DirName:/C=EU/O=AC Camerfirma SA CIF A82743287/OU=http://www.chambersign.org/CN=Chambers of Commerce Root serial:0D

Authority Information Access: CA Issuers URI:http://www.camerfirma.com/certs/AC_CAMERFIRMA_AAPP.crt

X509v3 CRL Distribution Points:

Full Name: URI:http://crl.camerfirma.com/AC_CAMERFIRMA_AAPP.crl

Full Name: URI:http://crl1.camerfirma.com/AC_CAMERFIRMA_AAPP.crl

X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.17326.10.9.8 CPS: https://policy.camerfirma.com

Signature Algorithm: sha1WithRSAEncryption 83:de:a9:ed:d3:96:14:9a:e9:18:84:c8:ac:d6:5b:b1:0f:34: 5d:ec:6a:2e:74:30:f2:c6:c4:fc:7e:fa:3c:1e:84:ff:90:25: 10:3c:24:ce:ce:70:38:0a:3d:ba:1d:78:e9:f6:5d:54:60:35: 1d:9d:6a:72:32:15:57:ea:6f:89:74:f4:6e:ff:a5:81:9e:42: 95:f4:f8:b2:b1:2a:ad:81:16:8d:47:0a:3e:87:91:af:64:e9: b4:9f:e8:f4:c7:29:b4:74:b6:af:31:28:93:cd:11:37:c6:ec: f1:45:55:f0:20:46:ae:a0:bf:bf:4c:9e:aa:d0:c3:29:10:37: 5f:8d:e5:09:f5:d5:b4:4e:e6:88:72:a8:d7:68:6f:a6:b9:df: 17:3e:cd:2e:a3:d4:a4:94:b2:6f:ef:08:cb:1b:24:fc:f7:e5: de:4c:c2:b9:8b:24:0c:73:e0:4c:e5:4d:e0:e4:b1:51:63:7d: 66:f0:cd:62:5d:c4:14:4d:f5:06:62:71:6a:7b:d8:22:3f:e5: 5e:41:f4:b3:a4:8b:e7:29:c0:cc:ee:73:e9:49:82:27:be:46: 1d:90:10:30:16:9a:b4:61:32:e8:28:84:4a:92:12:55:c9:6a: 20:d5:2c:60:3d:df:db:41:73:be:12:b3:10:1f:a3:0f:22:b3: bf:60:f1:c4BEGIN CERTIFICATEMIIF3DCCBMSgAwIBAgIIEcy7zLsAFFgwDQYJKoZIhvcNAQEFBQAwgbAxCzAJBgNVBAYTAkVTMRswGQYDVQQKExJBQyBDQU1FUkZJUk1BIFMuQS4xOzA5BgNVBAcTMk1BRFJJRCAoVmVyIGVuIGh0dHBzOi8vd3d3LmNhbWVyZmlybWEuY29tL2FkZHJlc3MpMRYwFAYDVQQLEw1BQyBDQU1FUkZJUk1BMRIwEAYDVQQFEwlBODI3NDMyODcxGzAZBgNVBAMTEkFDIENBTUVSRklSTUEgQUFQUDAeFw0xMjEyMDUxMDA3MTRaFw0xNDEyMDUxMDA3MTRaMIGOMQswCQYDVQQGEwJFUzEZMBcGA1UEChMQQUMgQ2FtZXJmaXJtYSBTQTEsMCoGA1UEAxMjT0NTUCBSZXNwb25kZXIgLSBBQyBDQU1FUkZJUk1BIEFBUFAxIjAgBgkqhkiG9w0BCQEWE2luZm9AY2FtZXJmaXJtYS5jb20xEjAQBgNVBAUTCUE4Mjc0MzI4NzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKg5sxWQwJ9bxqJsWwvgD+jv45rhfpwlqoPmAE52uqALFLRWnZONjL4/P9M2F23TRMW1iLGFBY9tRY78HM+DGLHY2HXEfdvH8aXm3x338n/lpTUjGBpkv2+lwMgo7+XFbd1x0vH6QX0bUpW1LsgqDDZnwQg0RE924WJ8ZXDguNYCD2tynZB3ZG2g33HyzXO6Ya3AvrL3MFqtP7Mryv/Zkk5xycVMwL95qq9wh7Tv+YhQjfS6F1qBO1une/Mc6shNU66AzIeUK3aVuOkLBNzH1Me7m91JY9nyStTk8lvsLEaPF7hFWd07mqwqNwZwJthQ1HmjNmOe2PELEo1ugly76c8CAwEAAaOCAhgwggIUMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgXgMBMGA1UdJQQMMAoGCCsGAQUFBwMJMB0GA1UdDgQWBBRVvx1il7k2OdB1sY7bMjMXyccigTCBqwYDVR0jBIGjMIGggBTlRlDoQ6Cy9xzktv/YAAQg9x+kC6GBhKSBgTB/MQswCQYDVQQGEwJFVTEnMCUGA1UEChMeQUMgQ2FtZXJmaXJtYSBTQSBDSUYgQTgyNzQzMjg3MSMwIQYDVQQLExpodHRwOi8vd3d3LmNoYW1iZXJzaWduLm9yZzEiMCAGA1UEAxMZQ2hhbWJlcnMgb2YgQ29tbWVyY2UgUm9vdIIBDTBSBggrBgEFBQcBAQRGMEQwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuY2FtZXJmaXJtYS5jb20vY2VydHMvQUNfQ0FNRVJGSVJNQV9BQVBQLmNydDB6BgNVHR8EczBxMDagNKAyhjBodHRwOi8vY3JsLmNhbWVyZmlybWEuY29tL0FDX0NBTUVSRklSTUFfQUFQUC5jcmwwN6A1oDOGMWh0dHA6Ly9jcmwxLmNhbWVyZmlybWEuY29tL0FDX0NBTUVSRklSTUFfQUFQUC5jcmwwRQYDVR0gBD4wPDA6BgsrBgEEAYGHLgoJCDArMCkGCCsGAQUFBwIBFh1odHRwczovL3BvbGljeS5jYW1lcmZpcm1hLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEA

25 de 61

g96p7dOWFJrpGITIrNZbsQ80XexqLnQw8sbE/H76PB6E/5AlEDwkzs5wOAo9uh146fZdVGA1HZ1qcjIVV+pviXT0bv+lgZ5ClfT4srEqrYEWjUcKPoeRr2TptJ/o9McptHS2rzEok80RN8bs8UVV8CBGrqC/v0yeqtDDKRA3X43lCfXVtE7miHKo12hvprnfFz7NLqPUpJSyb+8Iyxsk/Pfl3kzCuYskDHPgTOVN4OSxUWN9ZvDNYl3EFE31BmJxanvYIj/lXkH0s6SL5ynAzO5z6UmCJ75GHZAQMBaatGEy6CiESpISVclqINUsYD3f20FzvhKzEB+jDyKzv2DxxA==END CERTIFICATEPLATAFORMA_INTEROPERABILIDAD.pem: good

This Update: Nov 25 11:43:17 2013 GMT

Para volver a explorar la respuesta:

$ openssl ocsp respin resp.der noverify text

ValidaciónLa validación de un certificado digital depende de los requisitos de cada aplicación. En general, un certificado digital es considerado valido cuando es posible construir y validar un camino de certificación.

• Camino de certificación

En su forma más simple, un camino de certificación es una secuencia de n certificados donde:

– para todo x en {1 ... n-1}, el Subject del certificado x es el Issuer del certificado x+1

– para x=1 se tiene el certificado raíz (autofirmado)

– para x=n se tiene el certificado del usuario o de la entidad

• Validación de un camino de certificación

En su forma más básica, un procedimiento de validación realiza las siguientes tareas de comprobación para cada certificado de un camino de certificación:

◦ uso válido del certificado

◦ estado de revocación del certificado

◦ período de validez del certificado

26 de 61

◦ el Issuer del certificado es el Subject del certificado anterior en el camino de certificación

◦ el certificado fue firmado con el certificado anterior en el camino de certificación

Para el primer certificado (raíz), se omite esta última tarea o se comprueba que el certificado está autofirmado.

El camino de validación puede acortarse en aquella entidad certificadora que resulte de confianza para ambas partes: la persona o entidad que presenta el certificado y la persona o entidad que comprueba el certificado.

Subject Key IdentifierEste atributo de un certificado X.509v3 se utiliza junto al atributo Authority Key Identifier para facilitar la construcción de caminos de certificación. El valor del atributo Subject Key Identifier se suele corresponder con el valor hash de la clave pública del mismo certificado. El valor del atributo Authority Key Identifier suele contener el valor hash de la clave pública del certificado anterior en el camino de certificación.

Ejemplo:

Utilizando pues como referencias los valores hash de las claves públicas, con tres certificados, tenemos el siguiente camino de certificación. Observar que el certificado raíz no contiene un valor para el atributo Authority Key Identifier o si lo contiene, este coincidirá con el valor del atributo Subject Key Identifier del mismo certificado (ver Creación de un certificado digital autofirmado).

• Certificado Usuario

◦ Subject Key Identifier: EA41E93BF7BC6A12DDA12A5A40A58F2282A7A2ED

◦ Authority Key Identifier: E54650E843A0B2F71CE4B6FFD8000420F71FA40B

• Certificado CA

◦ Subject Key Identifier: E54650E843A0B2F71CE4B6FFD8000420F71FA40B

◦ Authority Key Identifier: E394F5B14DE9DBA1295B578B4D760676E1D1A28A

• Certificado raíz

◦ Subject Key Identifier: E394F5B14DE9DBA1295B578B4D760676E1D1A28A

◦ Authority Key Identifier: -

Puede haber dos certificados diferentes con el mismo valor Authority Key Identifier?

Puede haber dos certificados diferentes con el mismo valor Subject Key Identifier?

27 de 61

A continuación se muestra la obtención del valor hash para el atributo Subject Key Identifier a partir de la clave pública de un certificado.

$ openssl rsa pubout in PLATAFORMA.pemwriting RSA keyBEGIN PUBLIC KEYMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeO/4g5hu8uTgw0yx76tTWWPdza27l8Ero9ii0pHt/U/GR1kGQ3L9ectK3o3JbvF4GomtlomcixDgdBxMQQ3YfnQOuhv75ZEY0pTueJzMtbhtkjR0nWFb39tsazErzyPthCQAzcd4TeRufs/tMZvf8gMLYOYh9L0YOq9ez4vOpxwIDAQABEND PUBLIC KEY

$ openssl x509 inform der in PLATAFORMA.cer text | grep A 1 'Subject Key Identifier' X509v3 Subject Key Identifier: EA:41:E9:3B:F7:BC:6A:12:DD:A1:2A:5A:40:A5:8F:22:82:A7:A2:ED

$ openssl rsa pubout in PLATAFORMA.pem | grep v e 'BEGIN' e 'END' | openssl asn1parsewriting RSA key 0:d=0 hl=3 l= 159 cons: SEQUENCE 3:d=1 hl=2 l= 13 cons: SEQUENCE 5:d=2 hl=2 l= 9 prim: OBJECT :rsaEncryption 16:d=2 hl=2 l= 0 prim: NULL 18:d=1 hl=3 l= 141 prim: BIT STRING

$ openssl rsa pubout in PLATAFORMA.pem | grep v e 'BEGIN' e 'END' | openssl asn1parse strparse 18 out key.derwriting RSA key 0:d=0 hl=3 l= 137 cons: SEQUENCE 3:d=1 hl=3 l= 129 prim: INTEGER :DE3BFE20E61BBCB93830D32C7BEAD4D658F7736B6EE5F04AE8F628B4A47B7F53F191D64190DCBF5E72D2B7A3725BBC5E06A26B65A26722C4381D07131043761F9D03AE86FEF9644634A53B9E27332D6E1B648D1D275856F7F6DB1ACC4AF3C8FB6109003371DE13791B9FB3FB4C66F7FC80C2D839887D2F460EABD7B3E2F3A9C7 135:d=1 hl=2 l= 3 prim: INTEGER :010001

$ openssl sha1 key.derSHA1(key.der)= ea41e93bf7bc6a12dda12a5a40a58f2282a7a2ed

VerificaciónSupongamos el siguiente camino de certificación compuesto por tres certificados (contenidos en dos archivos):

Archivo PLATAFORMA_CA.pem

BEGIN CERTIFICATEMIIEvTCCA6WgAwIBAgIBADANBgkqhkiG9w0BAQUFADB/MQswCQYDVQQGEwJFVTEnMCUGA1UEChMeQUMgQ2FtZXJmaXJtYSBTQSBDSUYgQTgyNzQzMjg3MSMwIQYDVQQLExpodHRwOi8vd3d3LmNoYW1iZXJzaWduLm9yZzEiMCAGA1UEAxMZQ2hhbWJlcnMgb2YgQ29tbWVyY2UgUm9vdDAeFw0wMzA5MzAxNjEzNDNaFw0zNzA5MzAxNjEzNDRaMH8xCzAJBgNVBAYTAkVVMScwJQYDVQQKEx5BQyBDYW1lcmZpcm1hIFNBIENJRiBBODI3NDMyODcxIzAhBgNVBAsTGmh0dHA6Ly93d3cuY2hhbWJlcnNpZ24ub3JnMSIwIAYDVQQDExlDaGFtYmVycyBvZiBDb21tZXJjZSBSb290MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAtzZV5aVdGDDg2olUkfzIx1L4L1DZ77F1c2VHfRtbunXF/KGIJPov7coISjlUxFF6tdpg6jg8gbLL8bvZkSM/SAFwdakFKq0fcfPJVD0dBmpAPrMMhe5cG3nCYsS4No41XQEMIwRHNaqbYE6gZj3LJgqcQKH0XZi/caulAGgq7YN6D6IUtdQis4CwPAxaUWktWBiP7Zme8a7ileb2R6jWDA+wWFjbw2Y3npuRVDM30pQcakjJyfKl2qUMI/cjDpwyVV5xnIQFUZot/eZOKjRa3spAN2cMVCFVd9oKDMyXroDclDZK9D7ONhMeU+SsTjoF7Nuucpw4i9A5O4kKPnf+dQIBA6OCAUQwggFAMBIGA1UdEwEB/wQIMAYBAf8CAQwwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL2NybC5j

28 de 61

aGFtYmVyc2lnbi5vcmcvY2hhbWJlcnNyb290LmNybDAdBgNVHQ4EFgQU45T1sU3p26EpW1eLTXYGduHRooowDgYDVR0PAQH/BAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIABzAnBgNVHREEIDAegRxjaGFtYmVyc3Jvb3RAY2hhbWJlcnNpZ24ub3JnMCcGA1UdEgQgMB6BHGNoYW1iZXJzcm9vdEBjaGFtYmVyc2lnbi5vcmcwWAYDVR0gBFEwTzBNBgsrBgEEAYGHLgoDATA+MDwGCCsGAQUFBwIBFjBodHRwOi8vY3BzLmNoYW1iZXJzaWduLm9yZy9jcHMvY2hhbWJlcnNyb290Lmh0bWwwDQYJKoZIhvcNAQEFBQADggEBAAxBl8IahsAifJ/7kPMa0QOx7xP5IV8EnNrJpY0nbJaHkb5BkAFyk+cefV/2icZdp0AJPaxJRUXcLo0waLIJuvvDL8y6C98/d3tGfToSJI6WjzwFCm/SlCgdbQzALogi1djPHRPH8EjX1wWnz8dHnjs8NMiAT9QUu/wNUPf6s+xCX6ndbcj0dc97wXImsQEcXCz9ek60AcUFV7nnPKoF2YjpB0ZBzu9Bga5Y34OirsrXdx/nADydb47kMgkdTXg0eDQ8lJsm7U9xxhl6vSAiSFr+S30Dt+dYvsYyTnQeaN2oaFuzPu5ifdmA6Ap1erfutGWaIZDgqtCYvDi1czyL+Nw=END CERTIFICATEBEGIN CERTIFICATEMIIGaTCCBVGgAwIBAgIBDTANBgkqhkiG9w0BAQUFADB/MQswCQYDVQQGEwJFVTEnMCUGA1UEChMeQUMgQ2FtZXJmaXJtYSBTQSBDSUYgQTgyNzQzMjg3MSMwIQYDVQQLExpodHRwOi8vd3d3LmNoYW1iZXJzaWduLm9yZzEiMCAGA1UEAxMZQ2hhbWJlcnMgb2YgQ29tbWVyY2UgUm9vdDAeFw0xMDAyMjMwODQ2MzdaFw0yMjAyMjAwODQ2MzdaMIGwMQswCQYDVQQGEwJFUzEbMBkGA1UEChMSQUMgQ0FNRVJGSVJNQSBTLkEuMTswOQYDVQQHEzJNQURSSUQgKFZlciBlbiBodHRwczovL3d3dy5jYW1lcmZpcm1hLmNvbS9hZGRyZXNzKTEWMBQGA1UECxMNQUMgQ0FNRVJGSVJNQTESMBAGA1UEBRMJQTgyNzQzMjg3MRswGQYDVQQDExJBQyBDQU1FUkZJUk1BIEFBUFAwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEIAoIBAQDcNq5DM3X0DUeai9Ks7lY6iimhIO3vifminrDdlCkoomMhFq7oE9Q6X5lko95+mpClRm/nD1XqBOTa04WAYyvcrGXRH0F6vEIp86ew3I8CLUtWdeG255m2xcCcSKOreGDdcd/z+UsgdauerhvbJG1CmbAr1oWlmVCvr9zN2Frn9NvkF/espf8TKkAAXH8za5yuC2i5mTXH6LWxTCm03kfrVJRpU329JdNRRIGjtgj+yTHqig50TDZ9Snu3yKn/s+KwqK9l+wUHIWqgOmEghrYTjzXCGEpPv2TyEAXOhszX3vzNwStgf8Slz9d4H1TfEsUh02bmXb7e8G5UuybNY0vNAgEDo4ICvjCCArowEgYDVR0TAQH/BAgwBgEB/wIBAjBuBgNVHR8EZzBlMDCgLqAshipodHRwOi8vY3JsLmNhbWVyZmlybWEuY29tL2NoYW1iZXJzcm9vdC5jcmwwMaAvoC2GK2h0dHA6Ly9jcmwxLmNhbWVyZmlybWEuY29tL2NoYW1iZXJzcm9vdC5jcmwwHQYDVR0OBBYEFOVGUOhDoLL3HOS2/9gABCD3H6QLMIGrBgNVHSMEgaMwgaCAFOOU9bFN6duhKVtXi012Bnbh0aKKoYGEpIGBMH8xCzAJBgNVBAYTAkVVMScwJQYDVQQKEx5BQyBDYW1lcmZpcm1hIFNBIENJRiBBODI3NDMyODcxIzAhBgNVBAsTGmh0dHA6Ly93d3cuY2hhbWJlcnNpZ24ub3JnMSIwIAYDVQQDExlDaGFtYmVycyBvZiBDb21tZXJjZSBSb290ggEAMHUGCCsGAQUFBwEBBGkwZzA9BggrBgEFBQcwAoYxaHR0cDovL3d3dy5jYW1lcmZpcm1hLmNvbS9jZXJ0cy9ST09ULUNIQU1CRVJTLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AuY2FtZXJmaXJtYS5jb20wDgYDVR0PAQH/BAQDAgEGMAkGA1UdEQQCMAAwJwYDVR0SBCAwHoEcY2hhbWJlcnNyb290QGNoYW1iZXJzaWduLm9yZzCBqwYDVR0gBIGjMIGgMIGdBgsrBgEEAYGHLgEDATCBjTApBggrBgEFBQcCARYdaHR0cHM6Ly9wb2xpY3kuY2FtZXJmaXJtYS5jb20wYAYIKwYBBQUHAgIwVBpSQ2VydGlmaWNhZG8gcmHtei4gQ29uc3VsdGUgbGFzIGNvbmRpY2lvbmVzIGRlIHVzbyBlbiBodHRwczovL3BvbGljeS5jYW1lcmZpcm1hLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEADuarT/NOdigXhtxzdHZQOjpbY8s/ED8oeSGCil8vypvYJhGLQ+NDrlI4wXOm/gPJ+fU3YUndDiL5Fli2Id4nch+b8pFes5MlXqSVPsEdi4jWYMh73x8bEDTGO+FnzxtgVW+/g5V9sYIJ3Ir9CtRVBoCj1Z4DUb35hFoBAxHJkj2G5aPoDFNZUCbkTvQKaUFh920JNaDxvjS/Kx+ICG8dsUHofYLZ6ZdC4lxIAtOIgXw5zAkdv757VSq57OTMW3pjNXwHjaOVzuyZe8jNNlW4dpefTN+udKyeoZEEklGgVs2w72Dw4D7ji2xAvhNieH+uwl8XMLVICk48tHn5NpLFng==END CERTIFICATE

Archivo PLATAFORMA_CER.pem

BEGIN CERTIFICATEMIIHUjCCBjqgAwIBAgIIN5OKNVi0L+kwDQYJKoZIhvcNAQEFBQAwgbAxCzAJBgNVBAYTAkVTMRswGQYDVQQKExJBQyBDQU1FUkZJUk1BIFMuQS4xOzA5BgNVBAcTMk1BRFJJRCAoVmVyIGVuIGh0dHBzOi8vd3d3LmNhbWVyZmlybWEuY29tL2FkZHJlc3MpMRYwFAYDVQQLEw1BQyBDQU1FUkZJUk1BMRIwEAYDVQQFEwlBODI3NDMyODcxGzAZBgNVBAMTEkFDIENBTUVSRklSTUEgQUFQUDAeFw0xMDExMDQxMjQ0NDBaFw0xMzExMDMxMjQ0NDBaMIGqMTIwMAYDVQQNEylRdWFsaWZpZWQgQ2VydGlmaWNhdGU6IEFBUFAtU0VQLU0tU1ctS1BTQzEfMB0GA1UEAxMWUExBVEFGT1JNQSBJTlRFR1JBQ0lPTjESMBAGA1UEBRMJRzA3ODk2MDA0MRowGAYDVQQLFBFzZWxsbyBlbGVjdHLzbmljbzEWMBQGA1UEChQNRlVOREFDSdMgSUJJVDELMAkGA1UEBhMCRVMwgZ8wDQYJKoZI

29 de 61

hvcNAQEBBQADgY0AMIGJAoGBAN47/iDmG7y5ODDTLHvq1NZY93NrbuXwSuj2KLSke39T8ZHWQZDcv15y0rejclu8Xgaia2WiZyLEOB0HExBDdh+dA66G/vlkRjSlO54nMy1uG2SNHSdYVvf22xrMSvPI+2EJADNx3hN5G5+z+0xm9/yAwtg5iH0vRg6r17Pi86nHAgMBAAGjggP2MIID8jAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOpB6Tv3vGoS3aEqWkCljyKCp6LtMHoGCCsGAQUFBwEBBG4wbDBCBggrBgEFBQcwAoY2aHR0cDovL3d3dy5jYW1lcmZpcm1hLmNvbS9jZXJ0cy9BQ19DQU1FUkZJUk1BX0FBUFAuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5jYW1lcmZpcm1hLmNvbTCBqwYDVR0jBIGjMIGggBTlRlDoQ6Cy9xzktv/YAAQg9x+kC6GBhKSBgTB/MQswCQYDVQQGEwJFVTEnMCUGA1UEChMeQUMgQ2FtZXJmaXJtYSBTQSBDSUYgQTgyNzQzMjg3MSMwIQYDVQQLExpodHRwOi8vd3d3LmNoYW1iZXJzaWduLm9yZzEiMCAGA1UEAxMZQ2hhbWJlcnMgb2YgQ29tbWVyY2UgUm9vdIIBDTB6BgNVHR8EczBxMDagNKAyhjBodHRwOi8vY3JsLmNhbWVyZmlybWEuY29tL0FDX0NBTUVSRklSTUFfQUFQUC5jcmwwN6A1oDOGMWh0dHA6Ly9jcmwxLmNhbWVyZmlybWEuY29tL0FDX0NBTUVSRklSTUFfQUFQUC5jcmwwgZQGA1UdEQSBjDCBiaSBhjCBgzEhMB8GCWCFVAEDBQIBAQwSc2VsbG8gZWxlY3Ryw7NuaWNvMR0wGwYJYIVUAQMFAgECDA5GVU5EQUNJw5MgSUJJVDEYMBYGCWCFVAEDBQIBAwwJRzA3ODk2MDA0MSUwIwYJYIVUAQMFAgEFDBZQTEFUQUZPUk1BIElOVEVHUkFDSU9OMCEGA1UdEgQaMBiBFnNvcG9ydGVAY2FtZXJmaXJtYS5jb20wggELBgNVHSAEggECMIH/MIH8BgwrBgEEAYGHLgEDAwIwgeswKQYIKwYBBQUHAgEWHWh0dHBzOi8vcG9saWN5LmNhbWVyZmlybWEuY29tMIG9BggrBgEFBQcCAjCBsBqBrUNlcnRpZmljYWRvIHJlY29ub2NpZG8gZGUgc2VsbG8gZWxlY3Ry825pY28gZGUgQWRtaW5pc3RyYWNp824sIPNyZ2FubyBvIGVudGlkYWQgZGUgZGVyZWNobyBw+mJsaWNvLCBuaXZlbCBNZWRpby4gQ29uc3VsdGUgY29uZGljaW9uZXMgZGUgdXNvIGVuIGh0dHBzOi8vcG9saWN5LmNhbWVyZmlybWEuY29tMCUGCCsGAQUFBwEDBBkwFzAIBgYEAI5GAQEwCwYGBACORgEDAgEPMA0GCSqGSIb3DQEBBQUAA4IBAQC+mdTcrMGVmk+LDC7P3Gwg2a1/j9qpfmdO2ayQFNslCjvZGZD3g8bgdbu0obH6+4fwMxVesJp0MoZpktOrBK1LqjkJWT4reL+dWpXnLQMF279dHJxShLdxE1hQ+a/EDmTlGVu667eqxGx+Quu8IEPaXhfxUfXkuRsLhzhd1pY00mSbA34ev7XBcqPtBE1dV12O9uUlKdkKVDapcdP891zIaJckQUyj44+CD5TRRV/qPvC8gIS0ozTbmgTsBH/m/jl34go7KaqEGdqInebGPX3V9aeHWqOZJBD+Xc8+HND0w31vFShxE8KfanzmKjdl1Q9SH1Zy9ZrQ7WyPSujRIXhxEND CERTIFICATE

Se trata de verificar el certificado contenido en PLATAFORMA_CER.pem con los certificados contenidos en PLATAFORMA_CA.pem:

$ openssl verify CAfile PLATAFORMA_CA.pem PLATAFORMA_CER.pem PLATAFORMA_CER.pem: description = Qualified Certificate: AAPPSEPMSWKPSC, CN = PLATAFORMA INTEGRACION, serialNumber = G07896004, OU = sello electr\C3\B3nico, O = FUNDACI\C3\93 IBIT, C = ES error 10 at 0 depth lookup:certificate has expired OK

Como ejercicio se propone modificar un carácter del archivo PLATAFORMA_CER.pem y volver a ejecutar el comando anterior.

8.2. Archivos de certificados digitalesLa estructura de datos que define a un certificado digital suele estar contenida en archivos. Estos archivos están estructurados o codificados de alguna de las siguientes formas:

• DER

Codificación binaria de la notación ASN.1 de un certificado digital.

• PEM

Codificación en Base64 de la codificación DER de un certificado digital.

• PKCS#12

Almacén de claves utilizado para contener claves privadas y certificados.

30 de 61

Operaciones sobre archivos con certificados digitalesConversión PEM (Base64) DER (binario):→

$ openssl x509 outform der in certificado.crt out certificado.cer

Conversión DER (binario) PEM (Base64):→

$ openssl x509 inform der in certificado.cer out certificado.crt

Importar PEM (Base64) PKCS#12 (almacén de claves):→

$ openssl pkcs12 export out certificado.p12 inkey private.key in certificate.crt certfile CACert.crt

Exportar PKCS#12 (almacén de claves) PEM (Base64):→

$ openssl pkcs12 in certificado.p12 out certificado.crt

Explorar certificados de usuario del almacén de claves:

$ openssl pkcs12 in certificado.p12 nokeys clcerts | openssl x509 noout text

Explorar certificados de CA del almacén de claves:

$ openssl pkcs12 in certificado.p12 nokeys cacerts | openssl x509 noout text

Exportar certificados (cadena) del almacén de claves:

$ openssl pkcs12 in certificado.p12 out certificado.crt nokeys

Exportar certificado (usuario) del almacén de claves:

$ openssl pkcs12 in certificado.p12 out certificado.crt nokeys clcerts

Exportar la clave privada del almacén de claves:

$ openssl pkcs12 in certificado.p12 out private.key nocerts

Cambiar la contraseña del almacén de claves:

$ openssl pkcs12 in certificado.p12 out temp.pem passin pass:'uno 1' passout pass:temppassword$ openssl pkcs12 export in temp.pem out certificado.p12 passin pass:temppassword passout pass:'dos 2'$ rm temp.pem

Generar un almacén de claves Java:

$ keytool genkey alias foo keystore proves.jks$ keytool delete alias foo keystore proves.jks$ keytool list v keystore proves.jks

Importar el contenido de un almacén PKCS#12 a un almacén Java:

$ keytool importkeystore srckeystore proves.p12 destkeystore proves.jks srcstoretype pkcs12 srcstorepass '???' deststorepass '¿¿¿¿'$ keytool list v keystore proves.jks

31 de 61

Cambiar el alias de un certificado en un almacén Java:

$ keytool changealias alias '1' destalias 'alias_nuevo' keypass '???' keystore proves.jks storepass '¿¿¿¿'$ keytool list v keystore proves.jks

8.3. Huella digitalLa huella digital, también denominada Thumbprint en Internet Explorer o Fingerprint en Mozilla Firefox, permite simplificar algunas tareas de gestión (automática) de certificados digitales. Una huella digital de un certificado digital es el valor obtenido mediante la aplicación de una función hash sobre el archivo que contiene el certificado digital. Se trata pues de una representación abreviada de un certificado digital. Con esta representación resulta más fácil indexar certificados digitales en un sistema de archivos o comprobar su autenticidad mediante determinados canales de comunicación como el teléfono.

Al tratarse de un valor calculado sobre un archivo, no forma parte de la propia estructura ASN.1 de un certificado digital X.509.

La huella digital se puede obtener de alguna de las siguientes formas:

$ openssl x509 sha1 in PLATAFORMA.pem noout fingerprintSHA1 Fingerprint=59:E3:69:59:7E:9D:01:22:31:FE:6D:BE:29:5B:A6:33:11:95:D4:94

$ openssl x509 md5 in PLATAFORMA.pem noout fingerprintMD5 Fingerprint=DC:D0:9E:F5:FA:05:2F:46:5B:76:8F:24:4E:D9:D7:9F

$ openssl sha1 PLATAFORMA.cerSHA1(PLATAFORMA.cer)= 59e369597e9d012231fe6dbe295ba6331195d494

Notar la relación entre este último ejemplo y el primero. En el primer ejemplo, el certificado está codificado en PEM (DER+Base64), mientras que en el último ejemplo está codificada en DER. Se concluye que la huella digital de un certificado coincide con el valor de una función hash (SHA1) aplicada al archivo que contiene la codificación DER del certificado.

9. Marco legalAdemás de una infraestructura de clave pública para facilitar la interoperabilidad, se requiere también un marco jurídico que regule legalmente los intereses, derechos, obligaciones y responsabilidades de las partes que intervienen en la creación y utilización de certificados y firmas digitales.

En base a la Directiva 1999/93/CE sobre un marco comunitario para la firma electrónica, se promulgó la Ley 59/2003 de 19 de diciembre, de firma electrónica (BOE número 304, 20/12/2003) que establece las regulaciones jurídicas para el reconocimiento de certificados y firmas digitales.

De forma resumida, la ley contempla aspectos tales como:

• El reconocimiento del DNI electrónico como dispositivo para crear firmas reconocidas.

• Obligaciones, responsabilidades y limitación de responsabilidades de los prestadores de servicios de certificación.

• Las competencias del Ministerio de Ciencia y Tecnología para la supervisión y control de las actividades de los prestadores de servicio de certificación.

• Criterios de extinción de la vigencia de los certificados.

32 de 61

• Procedimiento de cese de actividad de un prestador de servicios.

• Establecimiento de infracciones y sanciones a prestadores de servicios de certificación.

• Equivalencia internacional de certificados.

• Protección de datos personales.

Algunos detalles que la mencionada ley establece, son:

• Establecimiento de un seguro de responsabilidad civil de un mínimo de 3.000.000 Euros a prestadores de servicios de certificación.

• El periodo máximo de vigencia de un certificado digital es de cuatro años.

• La conservación durante al menos 15 años, de la información y documentación relacionada a un certificado con el objetivo de permitir la verificación de las firmas realizadas con el mismo.

• La obligatoriedad de informar en un certificado reconocido el DNI/CIF de la persona física/jurídica del certificado.

Como reflexión sobre la generación de la clave privada (datos de creación de firma), la ley establece lo siguiente:

Artículo 11. Concepto y contenido de los certificados reconocidos.

2. Los certificados reconocidos incluirán, al menos, los siguientes datos:

f) Los datos de verificación de firma que correspondan a los datos de creación de firma que se encuentren bajo el control del firmante.

Artículo 12. Obligaciones previas a la expedición de certificados reconocidos.

c) Asegurarse de que el firmante está en posesión de los datos de creación de firma correspondientes a los de verificación que constan en el certificado.

d) Garantizar la complementariedad de los datos de creación y verificación de firma, siempre que ambos sean generados por el prestador de servicios de certificación.

Artículo 18. Obligaciones de los prestadores de servicios de certificación que expidan certificados electrónicos.

a) No almacenar ni copiar los datos de creación de firma de la persona a la que hayan prestado sus servicios.

Artículo 19. Declaración de prácticas de certificación.

1. Todos los prestadores de servicios de certificación formularán una declaración de prácticas de certificación en la que detallarán, en el marco de esta ley y de sus disposiciones de desarrollo, las obligaciones que se comprometen a cumplir en relación con la gestión de los datos de creación y verificación de firma...

Artículo 20. Obligaciones de los prestadores de servicios de certificación que expidan certificados reconocidos.

e) Tomar medidas contra la falsificación de certificados y, en el caso de que el prestador de servicios de certificación genere datos de creación de firma, garantizar su confidencialidad durante el proceso de generación y su entrega por un procedimiento seguro al firmante.

33 de 61

Artículo 24. Dispositivos de creación de firma electrónica.

1. Los datos de creación de firma son los datos únicos, como códigos o claves criptográficas privadas, que el firmante utiliza para crear la firma electrónica.

Recordemos que la creación de un certificado digital se inicia con una CSR generada por el solicitante del certificado. PKI X.509 considera como una opción la generación de la clave privada por parte de una autoridad certificadora. En contraste, la legislación de algunos países prohíbe expresamente la generación de claves privadas por parte de autoridades de certificación.

10. PrácticasA continuación se proponen cuatro prácticas a realizar con la herramienta OpenSSL 1.0.1.

10.1. PKI SimpleEsta PKI consiste de una CA raíz y una CA firmante:

Se utilizará la CA firmante para firmar diferentes tipos de certificados de usuario.

http://pki-tutorial.readthedocs.org/en/latest/simple/index.html

34 de 61

http://pki-tutorial.readthedocs.org/en/latest/simple/index.html

10.2. PKI AvanzadoEsta PKI consiste de una CA raíz y tres CA's subordinadas:

Se utilizará las tres CA's firmantes para firmar diferentes tipos de certificados de usuario.

http://pki-tutorial.readthedocs.org/en/latest/advanced/index.html

10.3. PKI ExpertoEsta PKI consiste de una CA raíz, una CA intermedia y dos CA's firmantes:

35 de 61

http://pki-tutorial.readthedocs.org/en/latest/advanced/index.html

Además de firmar diferentes tipos de certificado de usuario, se considerarán políticas de certificación y la configuración de un responder OCSP.

http://pki-tutorial.readthedocs.org/en/latest/expert/index.html

10.4. SSL. Autenticación cliente/servidorTípicamente, una conexión SSL/TLS se implementa sobre el protocolo HTTP y pretende ofrecer AUTENTICIDAD de la identidad del servidor y/o del cliente, PRIVACIDAD de la sesión mediante la utilización combinada de cifrado asimétrico y simétrico, e INTEGRIDAD de cada transacción mediante la utilización de un MAC.

El funcionamiento simplificado de SSL es:

1. El cliente inicia una sesión HTTPS

2. El servidor responde con un certificado autofirmado o bien con una cadena de certificados que incluye su certificado

3. El cliente comprueba el certificado recibido:

◦ el período de validez y el uso de cada certificado recibido

◦ que el dominio del servidor coincida con el dominio especificado en el certificado del servidor (Subject DN CN FQDN)→ → →

◦ que el certificado raíz recibido es de confianza para el cliente

◦ etc...

4. El cliente genera una clave de cifrado simétrico y un MAC. Ambos son cifrados con la clave pública del servidor y enviados al servidor.

5. Para el resto de la sesión se utiliza la clave de cifrado simétrico para cifrar cada mensaje junto a su correspondiente MAC.

Aunque la autenticación del servidor es típica, es posible realizar también la autenticación del cliente. Para ello, el cliente envía un certificado autofirmado o una cadena de certificados que incluya su certificado y el servidor realiza las mismas comprobaciones mencionadas en el punto 3.

Opciones más avanzadas de SSL contemplan la generación de una nueva clave simétrica para cada transacción de una misma sesión, la negociación, durante el inicio de sesión, de procedimientos concretos de cifrado, etc...

De forma obligatoria, SSL requiere autenticación del servidor. Para que el cliente pueda validar el certificado del servidor, el cliente debe disponer del certificado raíz de su confianza y que forme parte del camino de certificación del servidor. Alternativamente el servidor puede enviar su camino completo de certificación (hasta un certificado de común confianza) o simplemente un certificado autofirmado.

De forma opcional, para la autenticación del cliente, para que el servidor pueda validar el certificado del cliente, el servidor debe disponer del certificado raíz de su confianza y que forme parte del camino de certificación del cliente. Alternativamente el cliente puede enviar su camino completo de certificación (hasta un certificado de común confianza) o un certificado autofirmado.

La primera parte de esta práctica consiste en simular una conexión SSL/TLS sin autenticación de cliente:

Se genera un par de claves:

$ openssl req newkey rsa:1024 x509 nodes keyout srv_key.pem new out srv_cert.pem

Se ejecuta un servidor SSL/TLS:

$ openssl s_server cert srv_cert.pem key srv_key.pem state debug

36 de 61

http://pki-tutorial.readthedocs.org/en/latest/expert/index.html

Se ejecuta un cliente SSL/TLS que conecta al servidor:

$ openssl s_client debug state

En esta segunda parte, se simulará una conexión SSL/TLS con autenticación de cliente:

Se genera un par de claves para el cliente:

$ openssl req newkey rsa:1024 x509 nodes keyout cl_key.pem new out cl_cert.pem

Se ejecuta un servidor SSL/TLS:

$ openssl s_server cert srv_cert.pem key srv_key.pem state debug Verify 1 CAfile cl_cert.pem

Se ejecuta un cliente SSL/TLS que conecta al servidor:

$ openssl s_client key cl_key.pem cert cl_cert.pem debug state

11. Firma avanzadaLo visto hasta aquí son funciones criptográficas, procedimientos de firma digital y sellado de tiempo, certificados digitales y una infraestructura de clave pública. Son conceptos importantes pero conviene reflexionar si son suficientes para afrontar necesidades reales.

Algunas cuestiones interesantes podrían ser:

• Que sucede con la validez de una firma digital cuando el certificado con la cual fue realizada haya caducado o haya sido revocado?

• Que sucede con la validez de una firma digital cuando los algoritmos o la longitud de claves criptográficas utilizadas para la firma hayan quedado obsoletas?

• Como podemos enmarcar los conceptos de cofirma y contrafirma en todo lo visto hasta ahora?

Aunque posiblemente puedan existir otras cuestiones que merezcan su atención, limitaremos este estudio a estas tres preguntas.

Asumiendo que se pretende una validez indefinida o a muy largo plazo, se pueden ignorar aspectos relacionados con una extensión concreta del periodo de tiempo de validez de una firma digital. Así, la validación a muy largo plazo de una firma se puede conseguir aplicando de forma recurrente sellos de tiempo: el primero se aplicará sobre la firma y de forma sucesiva, se aplicará al último sello de tiempo un nuevo sello de tiempo basado en el más reciente estado de la criptografía.

En cuanto a la aplicación de cofirmas y contrafirmas, se podría contemplar una determinada estructura de datos para poder registrar las relaciones entre las diferentes firmas y con respecto al objeto que se firma.

Cofirma

- firma paralela

- los firmantes están al mismo nivel organizativo

- NO existe un orden prefijado de las firmas

- firman el mismo objeto

37 de 61

Contrafirma

- firma secuencial

- los firmantes NO están al mismo nivel organizativo

- existe un orden prefijado de las firmas

- NO firman el mismo objeto

Resumiendo, se precisa una estructura para poder registrar sucesivos sellos de tiempo y un conjunto de firmas relacionadas de una u otra forma.

La especificación de esta estructura de datos debe permitir la interoperabilidad entre sistemas heterogéneos debiéndose publicar como norma, estándar o recomendación.

Así, tenemos CAdES, XAdES y PAdES.

12. CAdESPara prolongar la validez de una firma digital más allá del periodo de validez del certificado digital utilizado para la creación de la misma, CAdES (CMS Advanced Electronic Signatures) propone la utilización de los servicios ofrecidos por autoridades certificadoras, autoridades de sellos de tiempo, autoridades de registro, etc..., además de unos formatos de estructuras de datos necesarias para soportar la extensión del periodo de validez de las firmas digitales. Con ello también se pretende además evitar la invalidez de firmas digitales inherente a la obsolescencia de elementos criptográficos como las funciones hash y los algoritmos de cifrado.

Para permitir un proceso de validación de firma digital coherente y técnicamente consistente, además de formatos de estructura de datos, CAdES también introduce el concepto de política de firma digital.

Formalmente el formato de las estructuras de datos se especifican mediante ASN.1 y las políticas de firma se referencian mediante OIDs. Para la codificación de las estructuras de datos, CAdES recomienda su codificación en DER y para su transmisión, la codificación en Base64 del resultado de la codificación DER.

Las especificaciones de CAdES procuran satisfacer la directiva de la Unión Europea 1999/93/EC acerca de la creación de un marco comunitario para el reconocimiento legal de la firma electrónica por parte de sus estados miembros y determinar también la coherencia técnica de diferentes especificaciones de Firma Electrónica.

Así, el Instituto Europeo de Estándares de Telecomunicación (ETSI) formó un comité dedicado a la firma electrónica (ESI) el cual confecciona las especificaciones técnicas relacionadas con la firma electrónica avanzada. En este sentido, se ha publicado el documento ETSI TS 101 733 que la especifica a nivel Europeo y que en su versión V.1.7.4 equivale técnicamente a la especificación RFC 5126 publicada por la Internet Engineering Task Force (IETF).

Básicamente, las estructuras de datos especificadas por CAdES denominadas perfiles, están formadas por determinados atributos agrupados e incluidos en un envoltorio digital basado en la especificación CMS.

12.1. PerfilesActualmente, CAdES define dos perfiles básicos sin datos para la validación de la firma:

• CAdES-BES: básica

• CAdES-EPES: referencias a políticas de firma

38 de 61

y ocho perfiles extendidos con datos para la validación de la firma:

• CAdES-T: sello de tiempo

• CadES-C: referencias a datos de validación (cadenas de certificados y listas de revocación)

• CAdES-X Long: datos de validación (cadenas de certificados y listas de revocación)

• CAdES-X Type 1: referencias a datos de validación y sello de tiempo sobre CAdES-C

• CAdES-X Type 2: referencias a datos de validación y sello de tiempo sobre referencias a datos de validación

• CAdES-X Long Type 1: datos de validación y sello de tiempo sobre CAdES-C

• CAdES-X Long Type 2: datos de validación y sello de tiempo sobre referencias a datos de validación

• CAdES-A: datos de validación (cadenas de certificados y listas de revocación), sellos de tiempo periódicos para validar la firma a largo plazo y sello de tiempo sobre CAdES-C o sobre referencias a datos de validación

Los dos perfiles básicos se han definido principalmente para satisfacer requisitos legales y como se muestra a continuación, se encapsulan en perfiles extendidos para ofrecer prestaciones avanzadas encaminadas a la validez de larga duración de la firma electrónica.

Para que una firma electrónica sea reconocida conforme a la especificación CAdES, es suficiente que esta se ajuste a alguno de los perfiles CAdES-BES, CAdES-EPES, CAdES-T o CadES-C.

CAdES-BES: básica

El elemento Documento representa el documento o mensaje que se quiere firmar. Al igual que en CMS, puede ser de cualquier tipo pero se requiere que el formato de su presentación pueda ser especificado mediante MIME.

Además del documento a firmar los siguientes atributos forman parte de CAdES-BES:

• Atributos obligatorios abarcados por la firma: tipo del documento, valor hash del documento, etc...

• Atributos opcionales abarcados por la firma: momento de la firma, lugar de la firma, sello de tiempo del documento a firmar, etc...

• Atributos no abarcados por la firma: sello de tiempo de la firma, contrafirma, etc...

La presencia de atributos opcionales viene determinada por la política de firma utilizada.

CAdES-BES ofrece integridad y autenticación pero no incorpora referencias explicitas a políticas de firma y tampoco incorpora información suficiente para permitir la validación de la firma a largo plazo.

39 de 61

CAdES-EPES: referencias a políticas de firma

CAdES-EPES es similar a CAdES-BES exceptuando un nuevo atributo abarcado por la firma. Este atributo identifica mediante un OID la política de firma que debe ser utilizada para la creación y validación de la firma.

La política de firma referenciada debe ser accesible para cada validación de la firma.

CAdES-T: sello de tiempo

Si CAdES-EPES o CAdES-BES no contienen un atributo opcional correspondiente a un sello de tiempo, CAdES-T aporta un atributo no abarcado por la firma para incorporar un sello de tiempo. Este sello de tiempo hace referencia a la firma certificando su existencia anterior a un determinado momento. Para prevenir un posible repudio por parte del firmante, el sello de tiempo debe ser creado lo antes posible.

40 de 61

CAdES-C: referencias a datos de validación

CAdES-C añade a CAdES-T un atributo con referencias (valores hash) a caminos de certificación y listas de revocación (o respuestas OCSP) necesarios para poder verificar la firma. Este atributo no está abarcado por la firma. El sello de tiempo presente en el perfil CAdES-T debe ser creado con anterioridad a la caducidad o revocación de los certificados referenciados.

Disponer valores hash de determinados datos implica la posibilidad de acceder a los mismos para poder comprobar su integridad comparando tales valores hash. En otras palabras, para poder validar el valor hash, todos los elementos referenciados mediante este nuevo atributo deben ser accesibles en el momento de validar la firma.

CAdES-X Long: datos de validación

CAdES-X Long añade a CAdES-C un atributo con los datos de caminos de certificación y listas de revocación (o respuestas OCSP) necesarios para verificar la firma.

41 de 61

CAdES-X Type 1: referencias a datos de validación y sello de tiempo sobre CAdES-C

CAdES-X Type 1 abarca un perfil CAdES-C sobre el cual se calcula un atributo de sello de tiempo. Este sello de tiempo garantiza que las referencias (valores hash) a caminos de certificación y listas de revocación (o respuestas OCSP) existieron con anterioridad al momento especificado por el sello de tiempo. Adicionalmente asegura la integridad (que no fueron modificados a posteriori) de los datos que representan estas referencias.

CAdES-X Type 2: referencias a datos de validación y sello de tiempo sobre referencias a datos de validación

El perfil CAdES-X Type 2 agrupa un perfil CAdES-C y un atributo de sello de tiempo. Este sello de tiempo se calcula sobre las referencias (valores hash) a caminos de certificación y listas de revocación (o respuestas OCSP) incluidos en el perfil CAdES-C. Al igual que con el perfil CAdES-X Type 1, con ello se consigue demostrar la existencia anterior al momento especificado por el sello de tiempo y asegurar la integridad de los datos que representan estas referencias en el caso de que las claves de la autoridad certificadora se hayan comprometidas.

42 de 61

CAdES-X Long Type 1: datos de validación y sello de tiempo sobre CadES-C

CAdES-X Long Type 1 se asemeja a CAdES-X Type 1 pero incluye los datos de caminos de certificación y listas de revocación (o respuestas OCSP) necesarios para verificar la firma. De esta forma no es necesario recurrir a fuentes externas para poder validar la firma.

CAdES-X Long Type 2: datos de validación y sello de tiempo sobre referencias a datos de validación

43 de 61

CAdES-X Long Type 2 se asemeja a CAdES-X Type 2 pero incluye los datos de caminos de certificación y listas de revocación (o respuestas OCSP) necesarios para verificar la firma. De esta forma no es necesario recurrir a fuentes externas para poder validar la firma.

CAdES-A: datos de validación y sello de tiempo sobre CAdES-C o sobre referencias a datos de validación, sellos de tiempo periódicos para validar la firma a largo plazo

Finalmente, CAdES-A ofrece la posibilidad de añadir periódicamente sellos de tiempo para conseguir conservar la validez a largo plazo un documento firmado. Actualizando sucesivamente los elementos criptográficos utilizados para procesar el sello de tiempo se consigue superar la obsolescencia de los mismos y mantener la validez de la firma del documento. En otras palabras, una vez validada la firma, esta seguirá siendo valida a pesar de la caducidad del certificado del firmante o del compromiso de sus claves.

13. XAdESXML, como especificación de datos estructurados ampliamente aceptada, también ofrece la posibilidad de firmas digitales avanzadas. Al igual que CAdES, intenta satisfacer los requisitos de la directiva de la Unión Europea 1999/93/EC ajustándose a las especificaciones recogidas en el documento ETSI TS 101 733. Como CAdES, XAdES extiende conceptualmente CMS pero basándose en XML y XMLDSIG.

XAdES define dos tipos de propiedades que forman parte de la firma digital avanzada: aquellas que están incluidas en la propia firma y otras que no lo están pero que pueden estar firmadas por terceras partes (una propiedad contiene o referencia a un objeto representado mediante una estructura de datos).

Para objetos incluidos en la firma, el firmante debe tener acceso a los mismos en el momento de realizar la firma.

44 de 61

Objetos no incluidos en la firma son añadidos por el firmante o por terceros después de realizar la firma. Estos pueden estar firmados o no. Ejemplos de objetos no incluidos y firmados son sellos de tiempo, certificados, CRL, etc...

Antes de describir las diferentes formas de firma digital XML avanzada, se exponen dos conceptos importantes. La canonización como requisito fundamental para una firma digital XML y XMLDSIG como base de la firma digital XML avanzada.

13.1. Forma canónicaCon respecto a los saltos de línea, espacios en blanco, orden de los elementos y atributos, codificación de caracteres, etc..., un documento XML permite una multitud de representaciones manteniendo un mismo significado lógico. Para poder aplicar funciones hash o algoritmos de cifrado sobre un documento XML, es imprescindible disponer de una representación normalizada o estandarizada del mismo.

Cuando es posible representar de varias formas diferentes un conjunto (estructurado) de datos, puede resultar conveniente formatearlo de forma única, explícita y reproducible. El resultado de este proceso es una representación canónica del conjunto de datos, denominada también forma c14n (cANONICALIZATIOn).

Ejemplo:

Versión canónica:

<doc xmlns="http://example.com/default" xmlns:x="http://example.com/x"> <a a1="1" a2="2">123</a> <b xmlns:y="http://example.com/y" a3=""3"" y:a1="1" y:a2="2"></b></doc>

de:

<?xml version="1.0" encoding="UTF8"?><doc xmlns:x="http://example.com/x" xmlns="http://example.com/default"> <a a2="2" a1="1" >123</a> <b y:a1='1' xmlns="http://example.com/default" a3='"3"' xmlns:y='http://example.com/y' y:a2='2'/></doc>

Existen diversos métodos o algoritmos de canonización. Algunos de ellos, Canonical XML Version 1.1 (2008) y Canonical XML Version 2.0 (2013), están publicados por el mismo organismo que especifica XML, el World Wide Web Consortium (W3C).

13.2. Firma Digital XMLLa firma digital XML es una representación XML de una firma digital cuya especificación denominada XMLDSIG, es regulada por el W3C. Así, una firma digital XML es un documento XML o un conjunto de elementos (fragmento) XML.

XMLDSIG especifica la sintaxis y las reglas para procesar la creación y la representación de firmas digitales en una aplicación XML. Como CAdES, la especificación XMLDSIG permite la aplicación de una firma digital sobre cualquier contenido digital. Sin embargo, a diferencia de CAdES, en lugar utilizar ASN.1 para su descripción, XMLDSIG se describe de forma normalizada mediante un esquema XML o un DTD. Para referenciar elementos XML y objetos (algoritmos, funciones hash, etc...) que soportan a la firma digital, XMLDSIG utiliza espacios de nombre, URL, URN y URIs.

XMLDSIG utiliza también elementos especificados mediante RFCs de la IETF. Por ello hay ciertos valores descritos mediante ASN.1 y codificados en DER y Base64.

Estructura general de una firma XML:

45 de 61

<Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI? > <! referencia al objeto que se firma > (<Transforms>)? <DigestMethod> <DigestValue> <! valor de la función hash aplicada sobre el objeto a firmar > </Reference>)+ </SignedInfo> <SignatureValue> <! valor de la firma digital sobre el elemento SignedInfo > (<KeyInfo>)? <! objetos (certificado) necesario para validar la firma > (<Object ID?>)*</Signature>

En función de la relación entre la firma digital XML y el objeto que se firma, se especifican tres tipos de firmas XML. El objeto que se firma puede estar incluido en el fragmento de la firma, el objeto puede incluir la firma XML o bien, ninguno de los dos casos anteriores: el objeto es externo a la firma y no la incluye.

Enveloping SignatureSe calcula un hash del contenido del elemento Object hijo del elemento Signature. El valor de este hash está contenido en el elemento DigestValue el cual es hijo de un elemento Reference. Este último contiene un atributo que hace referencia al objeto sobre el cual se ha calculado la función hash. El elemento SignedInfo, hijo también del elemento Signature, entre otros elementos contiene el elemento Reference. Finalmente, el elemento SignatureValue, hermano de SignedInfo, contiene la firma calculada sobre el elemento SignedInfo.

<?xml version="1.0" encoding="UTF8"?><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/RECxmlc14n20010315"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsasha1"/> <ds:Reference URI="#obj"> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue/> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue/> <ds:Object Id="obj">Hello, World!</ds:Object> </ds:Signature>

Enveloped SignatureEn un elemento Reference se hace referencia al conjunto de elementos que forman el documento XML que contiene el elemento Signature. Mediante una transformación XPath especificada mediante un elemento Transform se calcula un subconjunto de elementos que excluye el elemento Signature. Sobre este subconjunto se aplica una función hash cuyo valor estará contenido en el elemento DigestValue el cual es hijo del elemento SignedInfo. Finalmente, el elemento SignatureValue, hermano de SignedInfo, contiene la firma calculada sobre el elemento SignedInfo.

<!DOCTYPE Envelope [ <!ENTITY ds "http://www.w3.org/2000/09/xmldsig#"> <!ENTITY c14n "http://www.w3.org/TR/2001/RECxmlc14n20010315">

46 de 61

<!ENTITY enveloped "http://www.w3.org/2000/09/xmldsig#envelopedsignature"> <!ENTITY xslt "http://www.w3.org/TR/1999/RECxslt19991116"> <!ENTITY digest "http://www.w3.org/2000/09/xmldsig#sha1">]><Letter> <Returnaddress>address</Returnaddress> <To>You</To> <Message>msg body</Message> <From> <ds:Signature xmlns:ds="&ds;"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm= "http://www.w3.org/TR/2001/RECxmlc14n20010315"/> <ds:SignatureMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#rsasha1"/> <ds:Reference URI=""> <ds:Transforms> <ds:Transform Algorithm="&enveloped;"> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="&digest;"/> <ds:DigestValue></ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue/> </ds:Signature> </From> <Attach>attachement</Attach></Letter>

Detached SignaturePara los dos tipos de firmas anteriores, el elemento SignedInfo contiene uno o varios elementos Reference cuyos atributos URI pueden referenciar objetos de datos externos a la firma XML y que representan el contenido que se firma. El objeto a firmar puede estar contenido en el mismo documento XML en el que se encuentra la firma (internally detached), en cuyo caso será hermano de Signature, o bien encontrarse en un recurso físicamente externo al documento XML (externally detached). En cualquier caso, el objeto a firmar se referencia mediante un elemento Reference que es padre de un elemento DigestValue. Este elemento contiene el valor hash del objeto a firmar y al igual que los dos casos anteriores, la firma se calcula sobre el elemento SignedInfo.

<?xml version="1.0" encoding="UTF8"?><internallydetached> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/RECxmlc14n20010315"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsasha1"/> <ds:Reference URI="#data"> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue/> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue/> </ds:Signature>

<document Id="data"> <title>title</title> <author>writer</author>

47 de 61

<date>today</date> <content> <para>First paragraph</para> <para>Second paragraph</para> </content> </document> </internallydetached>

En el siguiente ejemplo de firma externally detached, el objeto a firmar se encuentra en un servidor web y es referenciado mediante la URL http://www.w3.org/TR/xml-stylesheet

<?xml version="1.0" encoding="UTF8"?><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/RECxmlc14n20010315"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsasha1"/> <ds:Reference URI="http://www.w3.org/TR/xmlstylesheet"> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue/> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue/></ds:Signature>

Validación de una firma XMLLa validación de una firma XML se realiza en dos pasos: primero se validan (calcular y comparar los valores hash) las referencias contenidas en el elemento SignedInfo. Una vez validadas las referencias, se valida el valor de la propia firma, contenido en el elemento SignatureValue y calculada sobre el elemento SignedInfo.

Para facilitar su verificación, el creador de la firma especifica el método utilizado para la canonización del elemento SignedInfo. De esta forma, el verificador podrá aplicar el mismo método antes de calcular y comparar los valores hash.

Ejemplo de una firma XML<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/RECxmlc14n20010315" ></ds:CanonicalizationMethod> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsasha1" ></ds:SignatureMethod> <ds:Reference URI="#MsgBody"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/TR/2001/RECxmlc14n20010315#WithComments" ></ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" ></ds:DigestMethod> <ds:DigestValue>C16zUWdt5lnX1e+GRe6U4Y+Il94=</ds:DigestValue> </ds:Reference> </ds:SignedInfo>

48 de 61

<ds:SignatureValue>Pysy/UNRXSc0rZa02a8Uk1oNF/jVI9UMf2tRQ3v89ytDtZbRVn4h1DKzYxe0m/B8Mam+Pk0p3nc6YBXEUX22NcTCuj5oeChHr/2L7vNjQxYYy9liV0H4kURRyUcRiyQ1wqUGMgWlO1rtDnP6xNiedPMu89l86Q9TOzb3Tsi8Sng= </ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>MIIDwjCCAyugAwIBAgIEPN5pKTANBgkqhkiG9w0BAQUFADA2MQswCQYDVQQGEwJFUzENMAsGA1UEChMERk5NVDEYMBYGA1UECxMPRk5NVCBDbGFzZSAyIENBMB4XDTEyMDMyMTA5MTc0NFoXDTE2MDMyMTA5MTc0NFowga0xCzAJBgNVBAYTAkVTMQ0wCwYDVQQKEwRGTk1UMRgwFgYDVQQLEw9GTk1UIENsYXNlIDIgQ0ExETAPBgNVBAsTCFB1YmxpY29zMRIwEAYDVQQLEwk1MDAwNzAwMTUxTjBMBgNVBAMTRURFU0NSSVBDSU9OIFNJU1RSQS1TQVJBIC0gRU5USURBRCBBSlVOVEFNRU5UIERFIFBBTE1BIC0gQ0lGIFAwNzA0MDAwSTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAm4aBZJKNxVCmCgd6eb51ggGxIlrn3QZtUGuua2PyJdJ+W8Kljp2IAbO1y+0/SDvJZUqfCeoUqrD5wShxaNKoKKZzXdkH4FryC5Is7z9Yt2QkMwO80JjgfNjfgW66Rc8rbG+rpccIG7Cke/Uj47/mf+w8U7kwLWe+4D8qmfMiHWkCAwEAAaOCAWMwggFfMGcGA1UdEQRgMF6kXDBaMRgwFgYJKwYBBAGsZgEPEwlQMDcwNDAwMEkxIjAgBgkrBgEEAaxmAQ4TE0FKVU5UQU1FTlQgREUgUEFMTUExGjAYBgkrBgEEAaxmAQgTC1NJU1RSQS1TQVJBMAkGA1UdEwQCMAAwKwYDVR0QBCQwIoAPMjAxMjAzMjEwOTE3NDRagQ8yMDE2MDMyMTA5MTc0NFowCwYDVR0PBAQDAgWgMBEGCWCGSAGG+EIBAQQEAwIFoDAdBgNVHQ4EFgQUZpwux7NJR/YcYJV7jNham6LNOwYwHwYDVR0jBBgwFoAUQJp2RJd0B8SsFMsejU86RXww12EwXAYDVR0fBFUwUzBRoE+gTaRLMEkxCzAJBgNVBAYTAkVTMQ0wCwYDVQQKEwRGTk1UMRgwFgYDVQQLEw9GTk1UIENsYXNlIDIgQ0ExETAPBgNVBAMTCENSTDEwMDU0MA0GCSqGSIb3DQEBBQUAA4GBAGvpGj8UdVj4BKgFry2LASAOncDPHJQKWxC3k3vNCIgiGvCoTdEZhH9OFdTHsG+Z22yr7OrcCq1wmYm+oWJXi2cXcHxlS/PdgBie+YBjxcUwZdH1D1AsfkwN2Be20SI9q7XlV74I1+TbTobQqmMnoJ6XLK6fmqIwfCmoRxP9LyqQ </ds:X509Certificate> </ds:X509Data> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus>m4aBZJKNxVCmCgd6eb51ggGxIlrn3QZtUGuua2PyJdJ+W8Kljp2IAbO1y+0/SDvJZUqfCeoUqrD5wShxaNKoKKZzXdkH4FryC5Is7z9Yt2QkMwO80JjgfNjfgW66Rc8rbG+rpccIG7Cke/Uj47/mf+w8U7kwLWe+4D8qmfMiHWk= </ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue> </ds:KeyInfo> </ds:Signature> </soapenv:Header> <soapenv:Body Id="MsgBody"> <Respuesta xmlns="http://www.map.es/scsp/esquemas/V2/respuesta"> <Atributos> <IdPeticion>PINBAL0000001448</IdPeticion> <NumElementos>1</NumElementos> <TimeStamp>20130912T08:42:24.779+02:00</TimeStamp> <CodigoCertificado>SCDPPEAJU</CodigoCertificado> </Atributos> <Transmisiones> <TransmisionDatos> <DatosGenericos> <Emisor> <NifEmisor>S0711001H</NifEmisor> <NombreEmisor>CAIB</NombreEmisor> </Emisor> <Solicitante> <IdentificadorSolicitante>G07896004</IdentificadorSolicitante> <NombreSolicitante>Fundació BIT</NombreSolicitante> <Finalidad>CODSVDR_GBA_20121107#::##::#proves</Finalidad> <Consentimiento>Si</Consentimiento> <Funcionario> <NombreCompletoFuncionario>Javier Miguel</NombreCompletoFuncionario> <NifFuncionario>12345678Z</NifFuncionario>

49 de 61

</Funcionario> </Solicitante> <Titular> <TipoDocumentacion>DNI</TipoDocumentacion> <Documentacion>12345678Z</Documentacion> </Titular> <Transmision> <CodigoCertificado>SCDPPEAJU</CodigoCertificado> <IdSolicitud>PINBAL0000001448</IdSolicitud> <IdTransmision>PMI2013091209:15:49.128</IdTransmision> <FechaGeneracion>20130912T09:15:49.128</FechaGeneracion> </Transmision> </DatosGenericos> <DatosEspecificos xmlns="http://www.map.es/scsp/esquemas/datosespecificos"> <Estado> <CodigoEstado>0238</CodigoEstado> <LiteralError>Información no disponible.</LiteralError> </Estado> <Solicitud> <TipoSolicitud>LISTADOHABITANTES</TipoSolicitud> <Provincia> <Codigo>07</Codigo> </Provincia> <Municipio> <Codigo>040</Codigo> </Municipio> </Solicitud> </DatosEspecificos> </TransmisionDatos> </Transmisiones> </Respuesta> /soapenv:Body></soapenv:Envelope>

Si se guarda el contenido del elemento X509Certificate añadiendo en una línea aparte el prefijo

-----BEGIN CERTIFICATE----- y en otra linea aparte, el sufijo -----END CERTIFICATE----- es posible, con el siguiente comando, ver el certificado utilizado para la firma del mensaje SOAP:

$ openssl x509 in resposta.pem text

13.3. Formas de firma digital XML avanzadaXAdES define seis formas de estructuras XML para la firma digital avanzada.

• XAdES: básica

• XAdES-T: sello de tiempo

• XAdES-C: referencias a datos de validación (cadenas de certificados y listas de revocación)

• XAdES-X: referencias a datos de validación y sello de tiempo sobre referencias a datos de validación y/o firma y otros sellos de tiempos

• XAdES-X-L: datos de validación (cadenas de certificados y listas de revocación) y con referencias a datos de validación y sello de tiempo sobre referencias a datos de validación y/o firma y otros sellos de tiempos

50 de 61

</SignedDataObjectProperties> | | </SignedProperties> | | <UnsignedProperties> | | <UnsignedSignatureProperties> | (CounterSignature)* | </UnsignedSignatureProperties> | | </UnsignedProperties> | | </QualifyingProperties> | | </ds:Object> | | </ds:Signature> + | XAdES

Especial mención se merece el elemento CounterSignature. Este elemento permite realizar cofirmas o contrafirmas. Un elemento CounterSignature contiene un elemento Signature. De esta forma, cada cofirma podrá referenciar al elemento SignatureValue del elemento Signature principal que referencia al objeto o documento que se firma.

En cambio, una contrafirma referenciará al elemento SignatureValue del elemento Signature que representa a la firma anterior en la cadena de contrafirmas.

XAdES-T: sello de tiempoXAdES-T añade a XAdES una propiedad para contener el valor de un sello de tiempo calculado sobre el elemento SignatureValue de la firma principal.

Recordar que con ello se pretende probar que la firma se creó anterior a un determinado momento. Para minimizar una posibilidad de repudio, conviene minimizar la diferencia de tiempo entre la creación de la firma, registrado por el elemento SigningTime, y el sellado de la misma.

</UnsignedSignatureProperties> (CounterSignature)* (SignatureTimeStamp)+ </UnsignedSignatureProperties>

Como se puede ver, es posible incorporar más de un sello de tiempo, cada uno de los cuales pudiendo haber sido emitido por una TSA diferente.

52 de 61

XAdES-C: referencias a datos de validación (cadenas de certificados y listas de revocación)XAdES-C añade a XAdES-T propiedades para contener referencias (valores hash) a caminos de certificación y listas de revocación (o respuestas OCSP) necesarios para validar la firma.

</UnsignedSignatureProperties> (CounterSignature)* (SignatureTimeStamp)+ (CompleteCertificateRefs) (CompleteRevocationRefs) </UnsignedSignatureProperties>

Disponer valores hash de determinados datos implica la posibilidad de acceder a los mismos para poder comprobar su integridad comparando tales valores hash. En otras palabras, para poder validar el valor hash, todos los elementos referenciados mediante este nuevo atributo deben ser accesibles en el momento de validar la firma.

XAdES-X: referencias a datos de validación y sello de tiempo sobre referencias a datos de validación y/o firma y otros sellos de tiemposXAdES-X extiende a XAdES-C añadiendo una propiedad para contener un sello de tiempo sobre la firma, el conjunto de sellos de tiempo sobre la firma y las referencias a caminos de certificación y listas de revocación (o respuestas OCSP) o bien, una propiedad para contener un sello de tiempo únicamente sobre las referencias a caminos de certificación y listas de revocación (o respuestas OCSP).

El propósito de XAdES-X es mantener la validez de la firma en el caso de un compromiso de la clave utilizada para firmar algún certificado del camino de certificación, alguna lista de revocación o respuesta OCSP. Sellando en el tiempo certificados de CA o respuestas OCSP, se demuestra su validez anterior a la fecha en que la clave del correspondiente CA fue comprometida.

53 de 61

</UnsignedSignatureProperties> (CounterSignature) (SignatureTimeStamp) (CompleteCertificateRefs) (CompleteRevocationRefs) ((SigAndRefsTimeStamp)* | (RefsOnlyTimeStamp)*) </UnsignedSignatureProperties>

El elemento SigAndRefsTimeStamp contiene referencias (valores hash) sobre los elementos SignatureValue, SignatureTimeStamp, CompleteCertificateRefs y CompleteRevocationRefs y el sello de tiempo se calcula sobre la concatenación de los mismos.

El elemento RefsOnlyTimeStamp contiene referencias (valores hash) sobre los elementos CompleteCertificateRefs y CompleteRevocationRefs y el sello de tiempo se calcula sobre la concatenación de los mismos.

54 de 61

XAdES-X-L: datos de validación (cadenas de certificados y listas de revocación) y con referencias a datos de validación y sello de tiempo sobre referencias a datos de validación y/o firma y otros sellos de tiemposXAdES-X-L extiende XAdES-X incorporando los datos necesarios para realizar la validación: caminos de certificación, CRL's y respuestas OCSP.

</UnsignedSignatureProperties> (CounterSignature)* (SignatureTimeStamp)+ (CompleteCertificateRefs) (CompleteRevocationRefs) ((SigAndRefsTimeStamp)* | (RefsOnlyTimeStamp)*) (CertificatesValues) (RevocationValues) </UnsignedSignatureProperties>

XAdES-A: datos de validación (cadenas de certificados y listas de revocación), referencias a datos de validación, sellos de tiempo periódicos para validar la firma a largo plazo, sello de tiempo sobre referencias a datos de validación y/o firma y otros sellos de tiemposPara soportar la obsolescencia de los elementos criptográficos, XAdES-A añade la posibilidad de incorporar sucesivos sellos de tiempo calculados sobre XAdES-X-L. Cada nuevo sello de tiempo se realiza con el estado más reciente de las técnicas criptográficas conocidas.

55 de 61

| | | XAdESX | | | | XAdESXL | | XAdESA

14. PAdESEl estándar ISO-32000-1 (PDF 1.7) especifica un formato digital para representar documentos denominado PDF (Portable Document Format) que permite el intercambio y la visualización de documentos electrónicos independientemente del entorno en el cual fueron producidos o en el cual son impresos o visualizados.

PAdES es un conjunto de restricciones y extensiones a ISO-32000-1 permitiendo capacidades de firma avanzada sobre documentos PDF.

Las especificaciones de PAdES fueron publicadas en el año 2009 por el ETSI y se recogen en el documento ETSI TS 102 778. Se espera que estas especificaciones se incluyan en el nuevo estándar ISO-32000-2 (PDF 2.0).

Tomando como referencia CAdES, PAdES también define una serie de perfiles para especificar los conjuntos de atributos y estructuras de datos que soportan diferentes tipos de firma avanzada.

La especificación TS 102 778 de PAdES se estructura en cinco partes:

• Parte 1. Introducción al soporte de la firma digital en documentos PDF e introducción de los diferentes perfiles presentados en las demás partes de la especificación.

• Parte 2. Describe el perfil PAdES Basic el cual se basa en el estándar ISO-32000-1 para especificar la firma digital PDF.

• Parte 3. Describe el perfil PAdES Enhanced el cual recoge los tipos de firma BES (Basic Electronic Signature) y EPES (Explicit Policy Electronic Signature).

• Parte 4. Describe el perfil PAdES Long Term utilizado para validar firmas digitales a largo plazo.

• Parte 5. Describe el perfil PAdES XML el cual permite incluir contenido XAdES en documentos PDF.

14.1. Perfiles PAdESA continuación se describen las principales características de los diferentes perfiles PAdES.

PAdES BasicPAdES Basic define la firma PDF según la especificación ISO-32000-1. Un documento PDF contiene una serie de objetos uno de los cuales se denomina diccionario de firma. La firma está incluida en el diccionario de firma y contempla un rango de bytes sobre el mismo documento. Este rango cuya especificación forma parte del diccionario de firma cubre todo el documento excluyendo el valor mismo de la firma.

El diccionario de firma también contiene los certificados necesarios para validar la firma y puede contener además un sello de tiempo.

57 de 61

La especificación ISO-32000-1 contempla dos tipos de firma: una única firma de autor y una o varias firmas de revisores. Los revisores firman anotaciones, comentarios o valores de campos de formularios PDF que ellos añaden en sucesivas versiones del documento. De esta forma se soportan las contrafirmas. Las cofirmas no son soportadas.

Mediante una técnica denominada Modification Detection and Prevention (MDP), cada firmante puede especificar, en relación a su firma, que tipo de modificaciones (añadir comentarios o rellenar campos) se puede realizar sobre el documento (DocMDP) o que campos de formularios (FieldMDP) se pueden modificar después de aplicar su firma.

58 de 61

PAdES EnhancedEste perfil se basa en CadES-BES, CadES-EPES y opcionalmente en CAdES-T. De esta forma, se incluyen atributos que identifican mediante OIDs las políticas de firma que deben ser consideradas para la validación de la firma.

No se deben confundir estas políticas con el seed value. El seed value es una entrada en el diccionario de firma PDF que especifica ciertas condiciones que se deben dar a la hora de realizarse la firma. En cambio, las políticas de firma son reglas que deben cumplir el firmante y el verificador de la firma.

PAdES Long TermPara permitir Long Term Validation (LTV), la parte 4 de la especificación PAdES define una estructura de datos denominada Document Security Store (DSS). Esta estructura de datos se adjunta al documento PDF y contiene los certificados, CRL y respuestas OCSP asociados a la validación de cada firma del documento.

Para verificar las firmas del documento PDF más allá de la fecha de caducidad o revocación de los certificados utilizados para las firmas, es necesario sellar las firmas y los datos de validación contenidos en el DSS.

59 de 61

Para permitir la verificación de las firmas a largo plazo se aplicarán sucesivos sellos de tiempo. Al estar firmado, cada sello de tiempo (TS_1) tendrá asociados unos datos de validación. Con anterioridad a su caducidad o revocación y mientras sean accesibles, hay que recolectar estos datos de validación, incorporarlos en un nuevo DSS y aplicar un nuevo sello de tiempo (TS_2).

PAdES XMLUn documento PDF puede contener documentos o elementos XML. Este perfil contempla la firma de elementos XML, o bien en forma de XAdES o XFA. De forma simple, XFA son campos de formularios PDF representados mediante XML.

Cuando se realiza una firma de revisión sobre un documento se incluyen los posibles documentos XAdES. Por lo tanto hay que tener en cuenta, que la actualización posterior a la firma de revisión del documento XAdES para permitir la verificación de su firma a largo plazo, invalidaría la firma de revisión.

Por otro lado, mediante DocMDP aplicado a la firma de autor, es posible permitir la actualización de un documento XML contenido en un documento PDF.

15. @FirmaEl Ministerio de Hacienda y Administraciones Públicas pone a disposición una plataforma de validación y firma que ofrece servicios avanzados de firma, validación y certificación electrónica facilitando a los sistemas de información la comprobación de la validez de los certificados electrónicos en las transacciones telemáticas llevadas a cabo por los ciudadanos con la Administración, así como para la realización de firma electrónica.

Los principales servicios que ofrece son:

• Validación de certificados

• Validación de firmas

• Generación de firmas

• Sellado de tiempo

• Gestión y administración

60 de 61

Los servicios de @firma están disponibles de forma gratuita para aquellas Administraciones Públicas que lo soliciten. El servicio se proporciona a través de la red SARA (Intranet Administrativa), por lo que para poder utilizarlo es necesario estar conectado a dicha red.

Para más información:

http://administracionelectronica.gob.es/pae_Home/pae_Estrategias/Racionaliza_y_Comparte/elementos_comunes/Servicios_Comunes_Firma_Electronica/FAQ-AFIRMA.html

61 de 61



Certificado y Firma digital - Què és la FundacióBit...

Documents

Transcript of Certificado y Firma digital - Què és la FundacióBit...