Definiciones empleadas en la Recomendación X.509.
Obtención de la clave pública.
Entorno con múltiples autoridades de certificación.
Gestión de claves y certificados.
Infraestructura de certificación.
Publicación de certificados en el Directorio.
Recuperación de certificados en ficheros.
Introducción.
La Norma ISO/IEC o grupo de Recomendaciones CCITT/ITU-T donde se describe el
Modelo de Referencia OSI, incluye en su Parte 2 una Arquitectura de Seguridad
(CCITT Rec. X.800(1991) | ISO 7498-2). Según esta arquitectura, para proteger
las comunicaciones entre distintas aplicaciones es necesario establecer los
siguientes servicios de seguridad:
La Recomendación X.509 define un entorno para la provisión de servicios de
autentificación entre distintas entidades, basados en la utilización del
Directorio como fuente de información para garantizar dicha autentificación.
Antes de comenzar el estudio de esta Recomendación debemos conocer algunos
conceptos importantes.
Se entiende el uso de la autentificación simple
en un entorno local, como vía de autentificación entre procesos pares,
por ejemplo, entre un DUA y un DSA o bien entre un DSA y otro DSA.
La autentificación simple se basa en el nombre distinguido (DN) de un usuario,
opcionalmente una clave y un acuerdo mutuo entre las dos partes implicadas.
Puede realizarse de tres formas:
La autentificación fuerte o ``strong'' hace uso de las propiedades de los sistemas
criptográficos de clave pública. En estos criptosistemas existen un par de claves,
una secreta y otra conocida públicamente, ambas asociadas a un usuario particular.
La clave pública X{p} puede emplearse por cualquier usuario para cifrar datos.
Unicamente X, la persona que posee la clave privada (X{s}), puede descifrar
el mensaje. Una propiedad importante de la criptografía asimétrica es la
imposibilidad, computacionalmente hablando, de deducir la clave privada a partir
de la pública.
Dos usuarios, A y B que desean comunicarse empleando criptografía de clave pública
deben disponer cada uno de un par de claves. La clave pública de A la denotamos como
A{p} y la clave privada como A{s}. En el caso del usuario B tenemos B{p} y
B{s}. Tanto A como B conocen las claves públicas de cada uno. A partir de este
momento ambos pueden intercambiar información secreta siguiendo estos pasos:
e = B{p}[x]
y envía la información cifrada (e) a B.
x = B{s}[e] = B{s}[B{p}[x]]
En principio no hemos dicho nada sobre un sistema criptográfico específico. Y esto
se debe a que puede emplearse cualquier sistema de criptografía pública.
Obviamente, tanto el emisor como el receptor de un mensaje cifrado deben utilizar
el mismo para facilitar la correcta codificación y decodificación del mensaje.
En este punto nos queda una duda, ¿cómo obtiene el usuario A la clave pública
del usuario B y viceversa? La respuesta es acudir a un repositorio para solicitar
la clave pública, y es en este punto donde el Directorio se hace especialmente
útil.
Para posibilitar un procedimiento de autentificación entre dos usuarios, cada uno
debe obtener la clave pública del otro de un lugar que les merezca confianza.
Este sistema se conoce como confianza en una tercera parte
(Trusted Third Party)
y en el mismo una autoridad de certificación (CA, Certificatio Authority)
corrobora que una clave pública es de una determinada entidad, emitiendo el
correspondiente certificado.
Un certificado es un documento emitido y firmado por una CA que asocia la identidad
de una entidad con su clave pública durante un período de tiempo. Un certificado
tiene estas propiedades:
Un certificado emitido por una autoridad de certificación es una colección de
información que incluye, entre otros datos, el nombre distinguido (DN) del usuario
y su clave pública, firmada por la CA. Podemos verlo de forma gráfica en la
Figura 2.
El proceso de firma digital primero aplica
una función hash de un sentido al certificado y posteriormente cifra el
resultado con la clave privada de la autoridad de certificación. Si un usuario
obtiene un certificado, deberá descifrar la firma de la autoridad de certificación,
para obtener el valor de la función hash. Este valor se compara con un nuevo hash
calculado a partir del certificado recibido, y si ambos coinciden, la clave pública
es diga de todo crédito.
Todo este proceso se muestra en la
Figura 3.
El formato
de un certificado para un usuario con nombre distinguido A e identificador
único UA, producido por la autoridad de certificación denominada CA, con
identificador único UCA, es el siguiente:
Algunas organizaciones pueden necesitar una mayor cantidad de información para
gestionar sus certificados. Con este objetivo se emplean las extensiones ISO,
permitiendo a la autoridad de certificación la inclusión de aquellos valores
que estime necesarios en los certificados y listas de revocación.
En esta estructura de autentificación fuerte hemos supuesto que los usuarios
A y B disponen de una par de claves, una pública (A{p}, B{p}) y otra privada
(A{s}, B{s}). Ambos confían en un tercer actor, la autoridad de certificación,
que firma con su clave privada (CA{s}) las claves públicas, generando los
certificados pertinentes. En este punto vemos la necesidad de alojar
los certificados de A (CA<<A>>) y B (CA<<B>>) así como de otras informaciones
de la autoridad de certificación en el Directorio. Se deduce que en el DIT deben
existir tres entradas: una correspondiente al usuario A, otra para el usuario B
y una tercera para la autoridad de certificación. En el caso de una entrada
asociada a una persona, debe pertenecer a la clase de objeto
strongAuthenticationUser e incluir el tipo de atributo
userCertificate:
En el caso de la autoridad de certificación, existirá en el DIT una entrada
de la clase certificationAuthority con los atributos
cACertificate,
certificateRevocationList y authorityRevocationList.
Un certificado puede perder su validez (antes de que caduque) porque se supone que
la clave privada del usuario ha sido comprometida, la CA no certifica al usuario o
porque la clave privada de la CA ha dejado de ser secreta.
Este hecho lo difunde
públicamente la autoridad de certificación mediante las listas de revocación de
certificados, cuya representación en notación ASN.1 es
A grandes rasgos una lista de certificados revocados incluye la CA que ha emitido
tal lista de revocación (issuer), la fecha de emisión de la lista (thisUpdate), cuando se cree
que volverá a emitir otra lista (nextUpdate) y una secuencia de items, donde cada
elemento se compone del número de serie del certificado (si recordamos, identificaba
claramente el certificado) y el instante en que ha dejado de tener validez (opcionalmente
es posible un tercer campo de extensiones). Por ejemplo, si el certificado de la
Figura 4 deja de ser válido, la CA emite
una lista donde uno de los items incluye el valor 26 (Serial Number del certificado).
La Recomendación X.509 especifica que cada CA debe mantener dos listas de
revocación, una para los certificados que ha emitido y revocado, así como
una segunda de certificados que no ha emitido, pero sabe que son revocados.
La primera lista se conoce como ``lista de certificados revocados''
(Certificate Revocation List, CRL) y la segunda se denomina ``lista de
revocación autorizada''(Authority Revocation List, ARL). Ambas listas corresponden
a los atributos certificateRevocationList y authorityRevocationList
anteriormente vistos.
Hasta ahora hemos supuesto una única autoridad de certificación, aunque la
realidad es disponer de una jerarquía de autoridades de certificación como
se aprecia en la Figura 5.
Si un usuario A desea obtener la clave pública del usuario B debe conseguir el
correspondiente certificado de la autoridad de certificación de B.
Para facilitar esta búsqueda, las entradas en el Directorio
asociadas a autoridades de certificación debe contener certificados de
dos tipos. Los primeros se denominan ``certificados directos'' (forward certificates)
generados por otras autoridades de certificación y firmados con la clave pública
de la CA en cuestión, y los segundos son ``certificados
inversos'' (reverse certificates), generados por la propia autoridad de certificación
y contienen las claves públicas de otras autoridades de certificación. Estos
certificados se alojan en atributos CrossCertificatePair dentro de objetos
pertenecientes a la clase certificationAuthority (entradas que representan
autoridades de certificación). El tipo de atributo
ASN.1 asociado a la especificación del atributo CrossCertificatePair es el
siguiente:
Los certificados directos e inverso posibilitan a los usuarios del Directorio la
creación de ``rutas de certificados'' (certification paths) de un punto a otro del DIT.
Los tipos de datos ASN.1 que pueden emplearse para representar rutas de
certificados son:
Dentro de la infraestructura de seguridad es de vital importancia que las claves
privadas sólo sean conocidas por su propietario. Como una clave privada es
algo difícil de recordar, debemos disponer de medios adecuados para transportar
y utilizar las claves. Una de las posibilidades es hacer uso de una ``tarjeta
inteligente'' (smartcard) donde guardar la clave privada, opcionalmente
la clave pública, el certificado del usuario y una copia de la clave pública de la
autoridad de certificación (la Recomendación no indica nada sobre el método a
utilizar para almacenar estos datos). La recuperación de esta
información implica introducir
un ``número de identificador personal'' (Personal Identification Number, PIN),
conocido exclusivamente por la persona propietaria de la tarjeta inteligente.
Respecto a la generación de la clave, son posibles tres situaciones:
Una vez generado el certificado, no se precisan medidas de seguridad especiales
en el proceso de traslado al Directorio.
Los certificados emitidos incluirán un límite de validez, pero es posible que
el usuario decida revocarlo antes de la fecha de caducidad, entonces:
Las primeras pruebas de inclusión de certificados en el Directorio comenzaron
con la anterior versión de Isode (IC-R3.1). Gracias a la ayuda de Javier Masa
(RedIRIS) fué posible incluir certificados. Para ello modificamos
el fichero oidtable.at, añadiendo un nuevo atributo:
El requisito necesario es que el certificado esté en formato DER. De este modo
un cliente web Netscape pueda recuperarlo sin problemas (ver
Figura 4).
La versión IC-R4 incluye una autoridad de certificación, pero al no disponer
de las librerías criptográficas no hubo posibilidad de probar esta herramienta.
Por ello continuamos con la autoridad de certificación Netscape Certificate Server.
Intentamos el mismo truco, simulando ficheros de sonido, sin éxito alguno. Además
los certificados se recuperaban directamente en binario vía LDAP. Estas dos
circunstancias obligaron a una nueva solución, donde debíamos modificar el fichero
oidtable.at, en concreto las líneas
Hasta ahora se ha indicado "el truco" para almacenar un certificado en el Directorio.
Pero todo esto se engloba dentro de una infraestructura de certificación.
Lo primero que debemos analizar es el proceso de generación de certificados. Como se
muestra en la Figura 6 disponemos de un
usuario que tiene un carnet inteligente (nos atenemos a lo que aconseja la Recomendación
X.509) y desea disponer de su correspondiente par de claves (privada y pública). Esta persona acude
a un lugar donde se comprueba su identidad (por ejemplo, en el caso de un alumno
podría ser la secretaría de su Escuela o Facultad). La entidad que comprueba si
esa persona es realmente quien dice ser se denomina Autoridad de Registro (en inglés
Registry Authority, RA). Este paso es importante para evitar suplantaciones y evitar
nombres distinguidos repetidos, como ya se comentó en la Recomendación X.509.
La RA envía las peticiones a la Autoridad de Certificación (en inglés Certification
Authority, CA) mediante un canal cifrado SSL. En teoría la CA se
encuentra off-line (es decir, podemos considerarla una máquina aislada de la red
que abre un puerto de comunicaciones en un instante dado y recibe las peticiones
almacenadas de las distintas RAs. Como se puede suponer, la comunicación es
unidireccional).
La CA genera el par de claves para el usuario, firma la clave pública del mismo,
generando el correspondiente certificado, que
deposita en el Directorio. El proceso para la clave privada se detalla en el
artículo "Experiencia piloto de certificación en la Universidad de Murcia" incluido
en el Boletín de RedIRIS nº 46-47.
En este punto, desde el punto de vista del Directorio, destacan tres objetos participantes
en esta infraestructura:
En el caso de la CA, el fichero LDIF es distinto:
El software "Netscape Certificate Server" genera los certificados y mediante LDAP
accede a nuestro servidor Isode IC-R4 para depositar los certificados de los
usuarios. El proceso es sencillo, en la parte de configuración "Certificate Service"
seleccionamos "Directory Server" y dentro de esta ventan se indica:
Esta parte puede mejorarse integrando SSL en Isode, o redireccionando puertos
en conexiones SSL. Estamos estudiando distintas posibilidades.
El proceso de carga de entradas en el Directorio incluye toda la información de
una persona, a excepción de su certificado, pues es competencia de la CA. Cuando
la autoridad de certificación publica el certificado sencillamente rellena el
atributo userCertificate que estaba vacío. Esto nos llevó a estudiar
la posibilidad de recuperar los certificados y almacenarlos en ficheros binarios
(por ejemplo si borramos accidentalmente la entrada debería publicarse otra vez el
certificado).
Los scripts que "capturan" certificados y los guardan en ficheros binarios se
encuentran explicado en la página "Recuperación de atributos
en formato ASN o BASE64".
Cuando se cumple alguna de las situaciones indicadas en la Recomendación X.509
el certificado es revocado por la CA. El proceso consiste en:
La autentificación, así como otros servicios de seguridad (control de acceso,
confidencialidad, no repudio e integridad) únicamente pueden
existir en el contexto de una política de seguridad previamente definida.
Definiciones empleadas en la Recomendación X.509.
Autentificación simple.
En el caso de Isode IC-R4.0, un ejemplo de ``autentificación simple sin protección''
sería:
dbind -call ``Internet=x500.um.es+17003'' -simple -user ``cn=DSA Manager, \
cn=jaguar, o=Universidad de Murcia, c=ES'' -password ``clave''
Las otros dos tipos de autentificación simple no se han podido probar al no disponer
de las librerías criptográficas.
Autentificación fuerte.
A su vez, B empleando los mismos pasos puede enviar datos cifrados al usuario A.
Obtención de la clave pública.
La CA firma digitalmente la clave pública de un usuario, su nombre y otra
información adicional haciendo uso de su clave privada. El certificado
puede verificarse con la clave pública de la autoridad de certificación.
CA<<A>> = CA{V,NS,AI,CA,UCA,A,UA,A{p},TA}
donde
Formalmente, el tipo de dato ASN.1 empleado para representar los certificados es:
Certificate ::= SIGNED { SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- if present, version must be v2 or v3
subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- if present, version must be v2 or v3
extensions [3] Extensions OPTIONAL
-- if present, version must be v3 -- }}
Version ::= INTEGER { v1(0), v2(1), v3(2) }
CertificateSerialNumber ::= INTEGER
AlgorithmIdentifier ::= SEQUENCE {
algorithm ALGORITHM.&id ({SupportedAlgorithms}),
parameters ALGORITHM.&Type ({SupportedAlgorithms}
{@algorithm}) OPTIONAL}
Validity ::= SEQUENCE {
notBefore UTCTime,
notAfter UTCTime }
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
Extensions ::= SEQUENCE OF Extension
Extension ::= SEQUENCE {
extnId EXTENSION.&id ({ExtensionSet}),
critical BOOLEAN DEFAULT FALSE,
extnValue OCTECT STRING }
En la práctica un certificado podría tener este aspecto:
Certificate:
Data:
Version: v3 (0x2)
Serial Number: 38 (0x26)
Signature Algorithm: PKCS #1 MD5 With RSA Encryption
Issuer: CN=CA de la Universidad de Murcia, O=Universidad de Murcia, C=ES
Validity:
Not Before: Thu Jul 1 13:16:36 1999
Not After: Sun Jun 25 13:16:36 2000
Subject: E=pepi@fcu.um.es, CN=PEPI GIL VALERA, UID=12345678, OU=Servicio de Informatica, OU=Servicios, O=Universidad de Murcia, C=ES
Subject Public Key Info:
Algorithm: PKCS #1 RSA Encryption
Public Key:
Modulus:
00:c5:0b:90:19:2b:36:a7:e4:f9:73:80:26:9d:db:0e:58:8a:
dd:b0:94:e7:15:f3:23:e8:e6:0f:15:35:2d:9a:6f:4e:b9:c6:
cd:cf:35:50:2a:bb:c6:21:ba:eb:db:ab:fd:6f:6f:71:54:3a:
71:ff:a7:b9:97:58:57:3b:4d:58:e9
Public Exponent: 65537 (0x10001)
Extensions:
Identifier: Certificate Type
Critical: no
Certified Usage:
SSL Client
Secure E-mail
Identifier: Authority Key Identifier
Critical: no
Key Identifier:
b4:d1:f9:9e:d6:61:ec:e4:f4:92:06:dc:74:b0:0c:a1:f9:61:
71:44
Signature:
Algorithm: PKCS #1 MD5 With RSA Encryption
Signature:
2f:d4:73:ef:94:bc:0f:9e:46:4c:3a:b4:20:69:56:cd:4e:53:d0:c1:18:
30:6d:fd:2f:92:9f:a2:7e:61:04:04:c3:93:43:38:d2:03:bb:85:e8:6a:
32:b6:47:74:12:bb:ec:82:8d:18:15:42:5a:41:ff:89:c2:94:c8:dd:69:
c9:e7:e7:eb:08:8b:f2:23:80:2f:1b:b4:c3:7f:d4:59:78:54:b4:cc:c4:
ab:b6:5f:6b:c2:18:8a:bb:89:af:f5:0a:68:86:7c:8e:6d:78:4f:7d:60:
b1:53:f9:ba:d9:01:37:e3:18:94:58:5c:67:8e:9d:95:d2:1b:49:0b:04:
31:cc
Si desde un cliente web Netscape recuperamos este certificado
podemos ver su contenido, como se muestra en la
Figura 4.
userCertificate ATTRIBUTE ::= {
WITH SYNTAX Certificate
ID id-at-userCertificate }
Cuando el usuario A desea una comunicación segura con B
accede al Directorio buscando el atributo userCertificate del usuario B. Después
del proceso descrito en la Figura 1 obtiene la clave pública
de B y puede iniciar la secuencia de autentificación descrita en el Apartado
anterior.
cACertificate ATTRIBUTE ::= {
WITH SYNTAX Certificate
ID id-at-cACertificate }
certificateRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
ID id-at-certificateRevocationList }
authorityRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
ID id-at-authorityRevocationList }
El atributo cACertificate contiene el certificado de la autoridad de certificación.
Sin embargo, los otros dos atributos se utilizan para la gestión de certificados
revocados, que vemos a continuación.
CertificateList ::= SIGNED { SEQUENCE {
version Version OPTIONAL,
-- if present, version must be v2 --
signature AlgorithmIdentifier,
issuer Name,
thisUpdate UTCTime,
nextUpdate UTCTime,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate UTCTime,
crlEntryExtensions Extensions OPTIONAL } OPTIONAL,
crlExtensions [0] Extensions OPTIONAL }}
Un certificado deja de ser válido en el momento que figura en una lista de
revocación. En contraste, los certificados caducados no aparecen en ninguna lista,
por tanto, cuando un certificado revocado supera su fecha de validez se elimina
de la lista de revocación de certificados.
Entorno con múltiples autoridades de certificación.
CrossCertificatePair ATTRIBUTE ::= {
WITH SYNTAX CertificatePair
ID id-at-CrossCertificatePair }
CertificatePair ::= SEQUENCE {
forward [0] Certificate OPTIONAL,
reverse [1] Certificate OPTIONAL,
-- at least one of the pair shall be present -- }
Veamos un ejemplo, siguiendo la Figura 5. Si nos fijamos en
la autoridad de certificación X, apreciamos un certificado directo (W<<X>>) y dos
certificados inversos (X<<W>>, X<<Z>>). Estos certificados se encuentran en
dos atributos CrossCertificatePair, uno de ellos contiene el par W<<X>>,X<<W>>
y el segundo únicamente X<<Z>>.
CertificationPath ::= SEQUENCE {
userCertificate Certificate,
theCACertificates SEQUENCE OF CertificatePair OPTIONAL }
CertificatePair ::= SEQUENCE {
forward [0] Certificate OPTIONAL,
reverse [1] Certificate OPTIONAL,
-- at least one of the pair shall be present -- }
Certificates ::= SEQUENCE {
userCertificate Certificate,
certificationPath ForwardCertificationPath OPTIONAL }
ForwardCertificationPath ::= SEQUENCE OF CrossCertificates
CrossCertificates ::= SET OF Certificate
La lista de certificados que precisa un usuario para obtener la clave pública de
otro usuario se conoce con el nombre de ruta de certificación (certification
path). Entonces la ruta de certificación de A a B sería:
X<<W>>,W<<V>>,V<<Y>>,Y<<Z>>,Z<<B>>
Sin embargo, en la práctica, la cantidad de información a recuperar del Directorio
para construir la ruta directa e inversa de certificación puede reducirse:
La Recomendación X.509 no indica nada sobre la distribución jerárquica de las
autoridades de certificación a lo largo del DIT. No obstante, en el RFC 1.422 se
define una jerarquía de autoridades de certificación, cuya raíz se denomina
Internet Policy Registration Authority (IPRA) y su DN sería
<OU=Internet PCA Registration Authority, o=Internet Society>.
Seguidamente estarían
las Policy Certification Authorities (PCAs), certificadas por la IPRA.
En los niveles inferiores existirían una serie
de Certification Autorities (CAs).
Gestión de claves y certificados.
Si recordamos, un certificado asocia la clave pública a un nombre distinguido (DN).
En consecuencia:
La producción de certificados debe realizarse ``offline'', así la clave privada de la
autoridad de certificación nunca será conocida. Tan solo un ataque directo a la
CA puede comprometer la clave privada de la misma.
Certificados en Isode IC-R3.
userCertificate;binary: attributeType.36.1 :Audio:file
Como se aprecia, estamos engañando al Directorio, indicándole como tipo de dato
un archivo de audio. Sin embargo, estamos almacenando un certificado en formato DER.
Todavía queda un segundo cambio en el fichero oidtable.oc, donde la línea
strongAuthenticationUser: standardObjectClass.15 : top : userCertificate
pasó a tener este formato
strongAuthenticationUser: standardObjectClass.15 : top : : userCertificate, userCertificate;binary
Veamos una entrada correspondiente a un fichero EDB donde alojamos un certificado:
cn=PEPI GIL VALERA
objectClass= top & person & organizationalPerson & strongAuthenticationUser & pilotObject & newPilotPerson & quipuObject
cn= PEPI GIL VALERA
sn= GIL VALERA
description= {T.61}Servicio de Inform\c2atica
businessCategory= Programadora
telephoneNumber= +34 968 364222
facsimileTelephoneNumber= +34 968 364151
userCertificate;binary={FILE}/usr/isode/etc/quipu-db/c=ES/UM/ou=Servicios/cpd-um/cn=PEPI GIL VALERA.userCertificate;binary
mail= pepi\40fcu.um.es
roomNumber= {T.61}Servicio de Inform\c2atica - Sala Iris
lastModifiedTime= 980903114116Z
lastModifiedBy= c=ES@o=Universidad de Murcia@cn=Quipu Manager
jpegPhoto={FILE}/usr/isode/etc/quipu-db/c=ES/UM/ou=Servicios/cpd-um/cn=PEPI GIL VALERA.jpegPhoto
Como vemos, un certificado se manipula (a la hora de incluirlo manualmente en
el fichero EDB) como si fuese una fotografía.
Certificados en Isode IC-R4.
userCertificate: attributeType.36 :Certificate
cACertificate: attributeType.37 :Certificate
pasaron a tener este aspecto:
userCertificate: attributeType.36 :file
cACertificate: attributeType.37 :file
Ahora el truco consiste en camuflar el certificado como un fichero.
Afortunadamente el proceso manual de introducción de certificados se automatizó gracias a la
posibilidad de carga de entradas empleando ficheros en formato LDIF.
dn: cn=PEPI GIL VALERA, ou=Servicio de Informatica, ou=Servicios, o=Universidad de Murcia, c=ES
objectclass: top
objectclass: person
objectclass: inetOrgPerson
objectclass: newPilotPerson
objectclass: organizationalPerson
cn: PEPI GIL VALERA
sn: GIL VALERA
telephonenumber: +34 968 364222
facsimileTelephoneNumber= +34 968 364151
uid: 77777777
rfc822Mailbox: prueba@fcu.um.es
roomNumber= {T.61}Servicio de Inform\c2atica - Sala Iris
description: {T.61}Servicio de Inform\c2atica
businessCategory: Programadora
usercertificate;binary:< file:/certificados/pepi.der
jpegPhoto:< file:/fotos/pepi.jpeg
Como en el caso anterior, la recuperación de certificados en formato DER es
cuestión de los clientes web Netscape (ver Figura 4).
Infraestructura de certificación.
Ya hemos visto lo necesario para la inclusión y recuperación de certificados de un
usuario. Por tanto pasemos a ver la entrada correspondientes a la autoridad de
registro, cuyo fichero LDIF es el siguiente:
dn: cn=RA, cn=jaguar, o=Universidad de Murcia, c=ES
objectclass: top
objectclass: person
objectclass: inetOrgPerson
objectclass: organizationalPerson
cn: RA
sn: RA
uid: 88888888
mail: ra@fcu.um.es
description: Autoridad de Registro
telephonenumber: +34 968 364222
userCertificate;binary:< file:/certificados/ra.der
Podemos apreciar que es análoga a cualquier entrada asociada a una persona.
dn: cn=CA de la Universidad de Murcia, o=Universidad de Murcia, c=ES
objectclass: top
objectclass: person
objectclass: AuthenticationUser
objectclass: certificationAuthority
cn: CA de la Universidad de Murcia
sn: Universidad de Murcia
telephonenumber: +34 968 364222
description: CA Piloto de la Universidad de Murcia
userCertificate;binary:< file:/certificados/ca.der
cACertificate;binary:< file:/certificados/ca.der
authorityRevocationList;binary:< file:/certificados/crl.der
certificateRevocationList;binary:< file:/certificados/crl.der
Si recordamos la Recomendación X.509, esta entrada pertenece a la clase
certificationAuthority e incluye los atributos
cACertificate (certificado de la CA en formato DER),
certificateRevocationList
y authorityRevocationList (listas de certificados revocados).
Publicación de certificados en el Directorio.
Según Isode en los accesos LDAP no es posible al autentificación fuerte,
siendo el mayor nivel de "seguridad" la autentificación simple. Esta circinstancia
adversa nos obligan a disponer la CA y el servidor Isode en un
segmento de red aislado para evitar cualquier intrusión, además la comunicación
es unidireccional entra la CA y el servidor Isode IC-R4.
Recuperación de certificados en
ficheros.
Revocación de certificados.
Una lista de certificados revocados contiene una serie de items, cada uno incluye
el número de serie del certificado (único para cada certificado. Una de las
tareas de la CA es llevar una anotación de los números de serie de los certificados
que ha emitido. Gracias a ella puede gestionar la emisión y revocación de certificados)
así como la fecha de revocación del certificado (instante en el que ha dejado de ser
válido).
Servicio de Informática de la Universidad de Murcia - http://www.um.es/si
Última actualización: 22/06/99
