Protocolo de consulta de recursos PKI

Para proporcionar referencias a datos publicados, una CA podría usar las extensiones Acceso a Información de Autoridad (AIA) y Acceso a Información del Sujeto (SIA), como se detalla en la RFC 3280. La primera proporciona información sobre el emisor del certificado, mientras que la segunda contiene información (dentro de los certificados de CA) sobre los servicios ofrecidos. La extensión Acceso a Información del Sujeto puede incluir una URI que apunta a repositorios de certificados y servicios de sellado de tiempo. Por lo tanto, esta extensión permite acceder a servicios mediante varios protocolos diferentes (por ejemplo , HTTP , FTP , LDAP o SMTP ). 

Aunque se fomenta su uso, las extensiones AIA y SIA aún no están ampliamente implementadas. Esto se debe principalmente a dos razones. La primera es la falta de compatibilidad con dichas extensiones en los clientes disponibles. La segunda es que las extensiones son estáticas, es decir, no se pueden modificar. De hecho, para modificar o añadir nuevas extensiones, y así notificar a los usuarios y las aplicaciones sobre los nuevos servicios o su eliminación, es necesario volver a emitir el certificado.

Esto no sería factible para los certificados de Entidades Finales (EE), salvo durante la reemisión periódica, pero sí lo sería para el certificado de la CA. La CA podría conservar la misma clave pública y nombre, y simplemente añadir nuevos valores a la extensión AIA del nuevo certificado. Si los usuarios obtienen el certificado de la CA con regularidad, en lugar de almacenarlo en caché, esto les permitiría familiarizarse con los nuevos servicios. Si bien esto es posible, casi todos los clientes disponibles no buscan los certificados de las CA si ya están almacenados en su base de datos local.

En cualquier caso, dado que las URL tienden a cambiar con frecuencia, mientras que los certificados permanecen vigentes durante periodos más prolongados, la experiencia sugiere que estas extensiones invariablemente apuntan a URL que ya no existen. Además, considerando que la entidad que emite los certificados y la que gestiona los servicios pueden no ser la misma, es inviable que la CA emisora ​​vuelva a emitir todos sus certificados si cambia la URL de un servidor. Por lo tanto, no es recomendable depender del uso de las extensiones AIA o SIA para la búsqueda de servicios y repositorios disponibles.

Se considera que la técnica de registro SRV o registro de servicio DNS proporciona punteros a servidores directamente en el DNS (RFC 1035). Tal como se define en el RFC 2782, la introducción de este tipo de registro permite a los administradores realizar operaciones bastante similares a las necesarias para resolver el problema de las direcciones PRQP, es decir, un servicio de descubrimiento PKI fácilmente configurable.

La idea básica es que el cliente consulte el DNS para obtener un registro SRV específico. Por ejemplo, si un cliente LDAP compatible con SRV desea descubrir un servidor LDAP para un dominio determinado, realiza una consulta DNS para _ldap._tcp.example.com (donde _tcp indica que el cliente solicita un servidor LDAP con TCP habilitado ). El registro devuelto contiene información sobre la prioridad, el peso, el puerto y el destino del servicio en ese dominio.

El problema en la adopción de este mecanismo radica en que, en las PKI (a diferencia de DNS), generalmente no existe un requisito fijo para el espacio de nombres utilizado. En la mayoría de los casos, no hay correspondencia entre la estructura DNS y los datos contenidos en los certificados. La única excepción se da cuando se utilizan los atributos del Componente de Dominio (DC) en el Asunto del certificado .

Los atributos DC se utilizan para especificar los componentes de dominio de un nombre DNS; por ejemplo, el nombre de dominio example.com podría representarse utilizando el formato dc=com, dc=example . Si el campo de asunto de la CA utilizara dicho formato, el campo Emisor permitiría a las aplicaciones cliente realizar consultas DNS para el dominio proporcionado, donde se podría almacenar la información sobre repositorios y servicios.

Sin embargo, actualmente la práctica es muy diferente. De hecho, resulta extremadamente difícil para un cliente vincular certificados digitales a registros DNS, ya que el formato DC no está ampliamente adoptado por las autoridades de certificación existentes. Por ejemplo, solo un certificado del almacén de certificados de IE7/Outlook utiliza los componentes de dominio para establecer una vinculación entre el certificado y un dominio de Internet.