Todas las CA raíz son autofirmadas. Lo que significa que nos sentimos obligados a confiar implícitamente en que CA se opera de manera responsable y segura. Esto no siempre es así ( Diginotar ).
Hay alternativas al método de la autoridad de certificación. Uno de estos es la web of trust , que se usa principalmente en PGP / GPG / OpenPGP implementaciones.
Hay situaciones que pueden surgir en las implementaciones de PKI donde necesitamos una PKI para "confiar" en otra. Esto se llama firma cruzada o certificación cruzada .
Uno de los componentes clave de una PKI es un servicio de directorio LDAP . Aquí es donde los certificados firmados y la información de revocación se publican para que estén disponibles públicamente. El directorio toma la forma de una estructura de árbol. Cada entrada en el árbol forma parte del nombre distinguido de la entrada (DName). Un ejemplo es CN = NRC, OU = IT, O = MyOrg, C = GB. En este DName, el elemento raíz es C, que es un país, seguido de O, para organización, OU, unidad de organización y CN, que es el nombre común. Cada elemento DName es una entrada en el árbol de directorios, que tiene una clase de objeto de esquema específica. La clase de objeto define los atributos obligatorios y opcionales para una entrada. El elemento CN suele estar representado en términos LDAP por la clase de objeto de esquema llamada inetorgperson, sin embargo, se han desarrollado tipos especializados para propósitos de PKI. El esquema LDAP completo para los objetos PKI se define aquí .
En esto se incluye la definición de la Clase de objetos de CA PKI. Esto incluye el atributo crossCertificatePair. El uso de este atributo, los certificados adicionales para la CA pueden ser emitidos por otra CA (como en su diagrama). Esto significa que, aunque el certificado de la CA central es autofirmado, para su certificación cruzada, su ancla de confianza es otra CA raíz. De hecho, si RootCA1 firma un certificado de certificación cruzada para RootCA2, entonces RootCA2 también puede firmar un certificado de certificación cruzada para RootCA1. De hecho, como ha especificado en su pregunta, es posible, a través de la certificación cruzada, tener la situación de anillo, donde RootCA1 firma RootCA2, RootCA2 firma RootCA3 y RootCA3 firma RootCA1. La validación de CA certificadas cruzadas requiere que el proceso de validación busque certificados certificados cruzados en la entrada LDAP para la CA, porque no hay ninguna referencia a estos en el certificado de CA raíz (el certificado "central" autofirmado), aunque debería haber una referencia a la entrada LDAP para la CA en la extensión Acceso a la información del sujeto .
Al tomar en cuenta la certificación cruzada, validación de la ruta del certificado puede convertirse en un proceso increíblemente complejo. Sin embargo, se han desarrollado servicios de software especializados que permiten a los usuarios "externalizar" el proceso complejo a autoridades de validación confiables. Estos servicios se denominan protocolo de estado de certificado en línea y protocolo de validación de certificados basado en servidor servidores. El Axway VA es un servidor que incluye OCSP y SCVP en uno y puede configurarse para proporcionar una validación completa de la ruta del certificado en entornos de CA con certificación cruzada.
