X.500 es una serie de estándares de redes informáticas que cubren los servicios de directorio electrónico . La serie X.500 fue desarrollada por el Sector de Normalización de las Telecomunicaciones de la Unión Internacional de Telecomunicaciones (UIT-T). La UIT-T se conocía anteriormente como el Comité Consultivo para Telefonía y Telegrafía Internacional (CCITT). X.500 se aprobó por primera vez en 1988. [1] Los servicios de directorio se desarrollaron para dar soporte a los requisitos de intercambio de correo electrónico y búsqueda de nombres X.400 . La Organización Internacional de Normalización (ISO) y la Comisión Electrotécnica Internacional (CEI) fueron socios en el desarrollo de los estándares, incorporándolos al conjunto de protocolos de Interconexión de Sistemas Abiertos . ISO/IEC 9594 es la identificación ISO/IEC correspondiente.
Los protocolos definidos por X.500 incluyen:
* Estos protocolos suelen definirse de forma fragmentada en varias especificaciones y módulos ASN.1 . La columna "Especificación de definición" que aparece más arriba indica (subjetivamente) qué especificación contribuye de forma más específica a un protocolo.
Debido a que estos protocolos utilizaban la pila de redes OSI , se desarrollaron varias alternativas a DAP para permitir que los clientes de Internet accedieran al directorio X.500 utilizando la pila de redes TCP/IP . La alternativa más conocida a DAP es el Protocolo ligero de acceso a directorios ( LDAP ). Si bien DAP y los demás protocolos X.500 ahora pueden utilizar la pila de redes TCP/IP, LDAP sigue siendo un protocolo de acceso a directorios popular.
Los protocolos X.500 utilizan tradicionalmente la pila de redes OSI . Sin embargo, el Protocolo ligero de acceso a directorios ( LDAP ) utiliza TCP/IP para el transporte. En versiones posteriores de la Recomendación X.519 de la UIT, se introdujeron los protocolos de asignación directa a Internet (IDM) para permitir que las unidades de datos del protocolo X.500 (PDU) se transportaran a través de la pila TCP/IP. Este transporte implica el transporte ISO sobre TCP, así como un protocolo binario simple basado en registros para enmarcar datagramas de protocolo.
El concepto principal de X.500 es que existe un único árbol de información de directorio (DIT), una organización jerárquica de entradas que se distribuyen entre uno o más servidores, denominados agentes del sistema de directorio (DSA). Una entrada consta de un conjunto de atributos, cada uno de los cuales tiene uno o más valores. Cada entrada tiene un nombre distintivo único , formado mediante la combinación de su nombre distintivo relativo (RDN), uno o más atributos de la propia entrada y los RDN de cada una de las entradas superiores hasta la raíz del DIT. Como LDAP implementa un modelo de datos muy similar al de X.500, existe una descripción más detallada del modelo de datos en el artículo sobre LDAP .
X.520 y X.521 juntos proporcionan una definición de un conjunto de atributos y clases de objetos que se utilizarán para representar personas y organizaciones como entradas en el DIT. Son uno de los esquemas de páginas blancas más utilizados .
X.509 , la parte del estándar que proporciona un marco de autenticación, ahora también se usa ampliamente fuera de los protocolos de directorio X.500. Especifica un formato estándar para certificados de clave pública.
El uso actual de certificados X.509v3 fuera de la estructura de directorio cargados directamente en los navegadores web fue necesario para el desarrollo del comercio electrónico, ya que permitía comunicaciones seguras basadas en la web (SSL/TLS) que no requerían del directorio X.500 como fuente de certificados digitales, como se concibió originalmente en X.500 (1988). Se debe contrastar el papel de X.500 y X.509 para comprender su relación, ya que X.509 fue diseñado para ser el método de acceso seguro para actualizar X.500 antes de la WWW, pero cuando los navegadores web se hicieron populares, se necesitaba un método simple para cifrar las conexiones en la capa de transporte a los sitios web. Por lo tanto, los certificados raíz de confianza para las autoridades de certificación compatibles se cargaron previamente en áreas de almacenamiento de certificados en la computadora o dispositivo personal.
Se prevé una mayor seguridad mediante la implementación programada para 2011-2014 de la Estrategia Nacional de Estados Unidos para Identidades Confiables en el Ciberespacio , un proyecto de dos a tres años de duración destinado a proteger las identidades digitales en el ciberespacio. [2]
La implementación de comercio electrónico WWW de X.509v3 eludió pero no reemplazó el mecanismo de autenticación estándar ISO original de vinculación de nombres distinguidos en el Directorio X.500.
El usuario final puede agregar o quitar estos paquetes de certificados en su software, pero Microsoft y Mozilla los revisan para comprobar si siguen siendo confiables. Si surge un problema, como ocurrió con DigiNotar , los expertos en seguridad de navegadores pueden emitir una actualización para marcar una autoridad de certificación como no confiable, pero esto es una eliminación seria de esa CA de la "confianza en Internet". X.500 ofrece una manera de ver qué organización reclama un certificado raíz específico, fuera de ese paquete proporcionado. Esto puede funcionar como un "modelo de confianza de 4 esquinas" que agrega otra verificación para determinar si un certificado raíz ha sido comprometido. Las reglas que rigen la política de Federal Bridge para revocar certificados comprometidos están disponibles en www.idmanagement.gov.
El contraste de este enfoque integrado del navegador es que en X.500 o LDAP el atributo "caCertificate" se puede "vincular" a una entrada de directorio y verificar además del paquete de certificados precargado predeterminado del cual los usuarios finales normalmente nunca se dan cuenta a menos que aparezca un mensaje de advertencia de SSL.
Por ejemplo, un sitio web que utiliza SSL, normalmente el nombre del sitio DNS "www.foobar.com", se verifica en un navegador mediante el software que utiliza bibliotecas que verificarán si el certificado fue firmado por uno de los certificados raíz de confianza proporcionados al usuario.
De esta forma se crea confianza en los usuarios de que han llegado al sitio web correcto a través de HTTPS.
Sin embargo, también es posible realizar comprobaciones más rigurosas para indicar que se ha verificado algo más que el nombre de dominio. En contraste con X.500, el certificado es uno de los muchos atributos de una entrada, en la que la entrada podría contener cualquier cosa permitida por el esquema de directorio específico. Por lo tanto, X.500 almacena el certificado digital, pero es uno de los muchos atributos que podrían verificar potencialmente la organización, como la dirección física, un número de teléfono de contacto y un correo electrónico de contacto.
Los certificados CA o los certificados de autoridad de certificación se cargan en el navegador automáticamente (en el caso del mecanismo de actualización de Microsoft), o en las actualizaciones de nuevas versiones de los navegadores, y se le ofrecen al usuario opciones adicionales para importar, eliminar o desarrollar una relación de confianza individual con las autoridades de certificación cargadas y determinar cómo se comportará el navegador si los servidores de revocación OCSP no están disponibles.
Esto contrasta con el modelo de Directorio que asocia el atributo caCertificate con una autoridad de certificación listada.
De esta forma, el navegador puede verificar el certificado SSL del sitio web mediante el grupo cargado de certificados aceptados o se pueden buscar los certificados raíz en un directorio X.500 o LDAP (o mediante HTTP/S) e importarlos a la lista de autoridades de certificación confiables.
El nombre distintivo "vinculado" se encuentra en los campos de asunto del certificado que coinciden con la entrada del Directorio. X.509v3 puede contener otras extensiones, según la comunidad de interés, además de los nombres de dominio internacionales. Para un uso amplio en Internet, RFC-5280 PKIX describe un perfil para campos que pueden resultar útiles para aplicaciones como el correo electrónico cifrado.
Un usuario final que confía en la autenticidad de un certificado que se presenta en un navegador o correo electrónico no tiene una manera sencilla de comparar un certificado falsificado presentado (lo que quizás active una advertencia del navegador) con un certificado válido, sin tener también la oportunidad de validar el DN o nombre distinguido que fue diseñado para buscarse en un DIT X.500.
El certificado en sí es público y se considera infalsificable, por lo que se puede distribuir de cualquier manera, pero se produce una vinculación asociada a una identidad en el Directorio. La vinculación es lo que vincula el certificado a la identidad de quien afirma estar utilizando ese certificado. Por ejemplo, el software X.500 que ejecuta el Federal Bridge tiene certificados cruzados que permiten la confianza entre las autoridades de certificación.
La simple coincidencia homográfica de nombres de dominio ha dado lugar a ataques de phishing en los que un dominio puede parecer legítimo, pero no lo es.
Si un certificado X.509v3 está vinculado al nombre distinguido de una organización válida dentro del Directorio, entonces se puede realizar una verificación simple con respecto a la autenticidad del certificado mediante una comparación entre lo que se presenta al navegador y lo que está presente en el Directorio.
Existen algunas opciones para verificar a los notarios y ver si un certificado se ha visto recientemente y, por lo tanto, es más probable que se haya visto comprometido. [3] Si es probable que el certificado sea confiable y falla porque el nombre de dominio no coincide levemente, inicialmente fallará en el navegador, pero luego estará sujeto a la confianza del notario, que puede pasar por alto la advertencia del navegador.
Una entrada organizacional válida, como o=FoobarWidgets, también tendrá un OID alfanumérico asociado y ha sido "probada en cuanto a identidad" por ANSI, lo que proporciona otra capa de seguridad con respecto a la vinculación del certificado a la identidad.
Los últimos acontecimientos (2011) han indicado una amenaza de actores desconocidos en estados nacionales que han falsificado certificados. Esto se hizo con el fin de crear un ataque MITM contra activistas políticos en Siria que accedían a Facebook a través de la web. Esto normalmente habría activado una advertencia del navegador, pero no lo haría si el certificado MITM hubiera sido emitido por una autoridad de certificación válida en la que ya confiaba un navegador u otro software. Stuxnet utilizó ataques similares que permitían que el software suplantara código confiable. El objetivo de la transparencia de los certificados es permitir que un usuario final determine, mediante un procedimiento simple, si un certificado es de hecho válido. La comprobación con el paquete de certificados predeterminado puede no ser suficiente para hacer esto, y por lo tanto es conveniente una comprobación adicional. También se han presentado otras sugerencias para la transparencia de los certificados. [4]
Otro ataque se llevó a cabo contra Comodo, una autoridad de certificación, que dio como resultado certificados falsificados que estaban dirigidos a sitios web de comunicaciones de alto perfil. Esto requirió un parche de emergencia para los principales navegadores. Estos certificados en realidad fueron emitidos por una autoridad de certificación confiable y, por lo tanto, un usuario no habría recibido ninguna advertencia si hubiera accedido a un sitio web falso, a diferencia del incidente de Siria, donde el certificado fue falsificado de manera burda, incluyendo la sustitución de Alto Palo por Palo Alto y números de serie incorrectos.
Algunos proyectos diseñados para intercambiar PHI, información de salud protegida (que se considera altamente sensible a la HIPAA ) pueden obtener certificados X.509v3 a través de un registro de recursos DNS CERT o a través de LDAP a un directorio X.500[2008]. La cuestión de un enlace autoritativo se detalla en las RFC relacionadas con la precisión de la información DNS asegurada mediante la firma desde la raíz utilizando DNSSEC.
El concepto de servidores de nombres raíz ha sido una fuente de gran controversia en la comunidad de Internet, pero en el caso del DNS está prácticamente resuelto. Tradicionalmente se ha pensado que el espacio de nombres asociado con X.500 comienza con una autoridad de nombres nacional, lo que refleja el enfoque de la ISO/ITU para los sistemas globales con representación nacional. De este modo, los distintos países crearán sus propios servicios X.500 exclusivos. El USX500 se privatizó en 1998, cuando el gobierno de los EE. UU. ya no ofrecía registros X.500 o DNS fuera de las agencias gubernamentales conocidas.
El proyecto piloto X.500 ha estado en desarrollo en el espacio comercial, y la tecnología continúa estando presente en importantes instalaciones de millones de usuarios dentro de centros de datos corporativos y dentro del Gobierno de EE. UU. para acreditaciones.
Los autores de RFC 2693 (sobre SPKI ) señalan que "es poco probable que el plan X.500 original llegue a concretarse. Las colecciones de entradas de directorio... son consideradas valiosas o incluso confidenciales por quienes poseen las listas y no es probable que se divulguen al mundo en forma de un subárbol de directorio X.500" y que "la idea X.500 de un nombre distinguido (un nombre único y global que todos puedan usar al referirse a una entidad) tampoco es probable que se haga realidad".
Muchas aplicaciones OSI utilizan nombres distinguidos (DN) tal como se definen en el directorio OSI, comúnmente conocido como X.500 [CCI88]. Esta especificación supone familiaridad con X.500 y el concepto de nombre distinguido.
{{cite journal}}: Requiere citar revista |journal=( ayuda )