logo-IRIS
  
> Inicio
> Sitemap
> Contacto
> Buscador
  

   Archivo JT   
   Archivo GT   
   Solicitud de ponencias   


Logotipo de la Universidad de Navarra



< Conferencias < Jornadas Técnicas < JT2001 < JT2001

JT2001 - Una implementación de una infraestructura de certificación basada en PKIX adaptada a entidades finales no personales
viernes, 26 de octubre, sesión IX

JT2001

Eduardo Jacob

(Universidad del País Vasco / Euskal Herriko Unibertsitatea)

RESUMEN

En el desarrollo realizado, se busca más la posterior integración de sistemas que utilicen los servicios de la PKI que ofrecer un interfaz para usuario humano. Para esto se ha utilizado el modelo propuesto en PKIX.

Para descentralizar la tarea de registro (y favorecer y abaratar la comprobación de la identidad del usuario durante la misma) se van a articular varias RAs en torno a una CA encargada únicamente de certificar automáticamente las solicitudes que le van a enviar a modo de agentes proxy las RA. En la CA, por tanto, únicamente se comprobará que la solicitud recibida ha sido cursada por una RA de confianza del sistema (delegando en ella la responsabilidad de comprobar la identidad del usuario).

Las operaciones a llevar a cabo para emitir los certificados pasan a automatizarse, ya no van a requerir la aprobación de ningún operador humano. Para ello la única interacción "humana" se va a realizar en el momento del registro inicial del usuario (EE). En ese momento el operador de RA, tras comprobar según la política de seguridad de la RA descrita en su CPS la identidad del usuario, va a rellenar todos los campos del futuro certificado con sus datos y va a almacenar una entrada con los mismos en la BD de la RA. Durante ese proceso el servidor de RA (un demonio programado en C en una plataforma Linux) va a generar un ID y un password que el operador va a entregar fuera de banda al usuario.

Esos datos son lo único que necesita el cliente para posteriormente realizar una solicitud de certificado (mediante el protocolo CMP/CRMF) a la RA. Ésta, tras comprobar ID/passwd, va a recoger una pre-solicitud almacenada en la BD, generada a medida del usuario en el proceso de registro (con todos los campos cumplimentados), la va a rellenar con la clave pública que le ha mandado el usuario y la va a reenviar a la CA, encargada finalmente de expedir el certificado, devolverlo a la RA y publicarlo en el servicio de directorio. Este esquema libera al usuario final de cualquier cuestión relacionada con los campos de la solicitud, qué información incluir en el DN y demás problemática de los certificados, puesto que la rellena el operador durante el registro, y el usuario sólo utiliza ese ID/passwd, facilitando en extremo la operación de registro, la más problemática en este tipo de tecnologías.

Otro aspecto a destacar es el correspondiente a la flexibilidad del formato de los certificados a expedir, en cuanto a los campos y extensiones tanto estándar como propietarias (NS y MS principalmente).

El sistema además va a ofrecer servicios de validación, mediante la utilización del protocolo OCSP. Para ello las RAs van a adoptar el papel de respondedores OCSP autorizados con un comportamiento similar a los servidores DNS que no son autoridad de un dominio. De este modo, las EEs van a consultar el estado de un determinado certificado a la RA que conocen (generalmente porque la utilizaron para su registro). Se ha implementado una caché en memoria para mejorar el rendimiento del sistema. Si no se encuentra la respuesta en la caché, se consultará a la BD interna y en última instancia a la CA, que es la que dispone de información actualizada en todo momento (puesto que es la encargada de las revocaciones/expediciones).

El sistema está implementado en C sobre Linux, utilizando cryptlib. Se comentarán estas experiencias y futuros desarrollos.

RedIRIS © 1994-2007
^