X.500

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). El UIT-T se conocía anteriormente como el Comité Consultivo de Telefonía y Telegrafía Internacionales (CCITT). X.500 se aprobó por primera vez en 1988. Los servicios de directorio se desarrollaron para admitir los requisitos del intercambio de correo electrónico X.400 y la búsqueda de nombres. La Organización Internacional para la Estandarización (ISO) y la Comisión Electrotécnica Internacional (IEC) 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.

Protocolos X.500

Los protocolos definidos por X.500 incluyen:

* Estos protocolos normalmente se definen por partes a lo largo de múltiples especificaciones y módulos ASN.1. La "Especificación de definición" La columna anterior indica (subjetivamente) qué especificación contribuye más específicamente a un protocolo.

Debido a que estos protocolos usaban la pila de red OSI, se desarrollaron varias alternativas a DAP para permitir que los clientes de Internet accedieran al directorio X.500 usando la pila de red TCP/IP. La alternativa más conocida a DAP es el Protocolo ligero de acceso a directorios (LDAP). Mientras que DAP y los otros protocolos X.500 ahora pueden usar la pila de redes TCP/IP, LDAP sigue siendo un protocolo popular de acceso a directorios.

Protocolos de Transporte

Los protocolos X.500 tradicionalmente usan la pila de red 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 de Internet (IDM) para permitir que las unidades de datos del protocolo (PDU) X.500 se transporten 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.

Modelos de datos X.500

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 en uno o más servidores, denominados agentes del sistema de directorio (DSA). Una entrada consta de un conjunto de atributos, cada atributo con uno o más valores. Cada entrada tiene un Nombre Distinguido único, formado por la combinación de su Nombre Distinguido 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, hay 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 desplegados.

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 los certificados de clave pública.

La relación del Directorio X.500 y los certificados digitales X.509v3

El uso actual de certificados X.509v3 fuera de la estructura del directorio cargado directamente en los navegadores web era necesario para que se desarrollara el comercio electrónico al permitir comunicaciones seguras basadas en web (SSL/TLS) que no requerían el directorio X.500 como una 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 en el sentido de que X.509 fue diseñado para ser el método de acceso seguro para actualizar X.500 antes de WWW, pero cuando los navegadores web se hicieron populares, era necesario que hubiera un método simple de encriptación de conexiones en la capa de transporte a sitios web. Por lo tanto, los certificados raíz confiables para las autoridades de certificación admitidas se cargaron previamente en áreas de almacenamiento de certificados en la computadora o dispositivo personal.

Se prevé seguridad adicional 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 que protege las identidades digitales en el ciberespacio.

La implementación de comercio electrónico WWW de X.509v3 omitió pero no reemplazó el mecanismo de autenticación estándar ISO original de vincular nombres distinguidos en el directorio X.500.

El usuario final puede agregar o eliminar estos paquetes de certificados en su software, pero Microsoft y Mozilla los revisan en términos de su confiabilidad continua. En caso de que surja un problema, como lo que ocurrió con DigiNotar, los expertos en seguridad del navegador 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 de Internet". X.500 ofrece una forma de ver qué organización reclama un certificado raíz específico, fuera del paquete proporcionado. Esto puede funcionar como un "modelo de confianza de 4 esquinas" agregando otra verificación para determinar si un certificado raíz se ha visto 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 de paquete de navegador es que en X.500 o LDAP, el atributo "caCertificate" puede ser "atado" a una entrada de directorio y se comprueba además del paquete de certificados precargado predeterminado del que los usuarios finales normalmente nunca se han percatado a menos que haya aparecido un mensaje de advertencia de SSL.

Por ejemplo, un sitio web que utiliza SSL, normalmente el nombre del sitio DNS "www.foobar.com" es verificado en un navegador por el software que usa bibliotecas que verificarían si el certificado fue firmado por uno de los certificados raíz de confianza otorgados al usuario.

Por lo tanto, crear confianza para los usuarios de que habían llegado al sitio web correcto a través de HTTPS.

Sin embargo, también son posibles verificaciones más estrictas para indicar que se verificó más que el nombre de dominio. Para contrastar esto con X.500, el certificado es un atributo de muchos para 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 potencialmente podrían verificar 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 de 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 el usuario tiene más opciones para importar, eliminar o desarrolle una relación de confianza individual con las autoridades de certificación cargadas y determine 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 certificadora listada.

Así, el navegador puede verificar el certificado SSL del sitio web mediante el grupo cargado de certificados aceptados o los certificados raíz pueden buscarse en un directorio X.500 o LDAP (o a través de HTTP/S) e importarse al lista de autoridades de certificación de confianza.

El "atado" El nombre distinguido se encuentra en los campos de asunto del certificado que coincide 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 de Internet, RFC-5280 PKIX describe un perfil para campos que pueden ser útiles para aplicaciones como el correo electrónico cifrado.

Un usuario final que confía en la autenticidad de un certificado que se presenta a un navegador o correo electrónico no tiene una forma sencilla de comparar un certificado falsificado presentado (quizás lo que activa una advertencia del navegador) con un certificado válido, sin tener también la oportunidad para validar el DN o Nombre Distinguido que fue diseñado para ser buscado en un DIT X.500.

El certificado en sí es público y se considera infalsificable y, por lo tanto, puede distribuirse de cualquier manera, pero se produce un enlace asociado a una identidad en el Directorio. La vinculación es lo que vincula el certificado con la identidad que afirma estar usando ese certificado. Por ejemplo, el software X.500 que ejecuta 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 resultado en 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 con lo que se presenta al navegador. con lo que está presente en el Directorio.

Existen algunas opciones para consultar a los notarios para ver si un certificado se ha visto recientemente y, por lo tanto, es más probable que se haya visto comprometido. Si es probable que el certificado sea confiable y falla porque el nombre de dominio no coincide, inicialmente fallará en el navegador, pero luego estará sujeto a la confianza del notario, que luego puede pasar por alto la advertencia del navegador.

Una entrada organizativa válida, como o=FoobarWidgets, también tendrá un OID alfanumérico asociado y ha sido "identidad comprobada" por ANSI, proporcionando otra capa de seguridad con respecto a vincular el certificado a la identidad.

Eventos recientes (2011) han indicado una amenaza de actores desconocidos en estados nacionales que han falsificado certificados. Esto se hizo para crear un ataque MITM contra activistas políticos en Siria que acceden a Facebook a través de la web. Normalmente, esto habría activado una advertencia del navegador, pero no lo haría si el certificado MITM fuera emitido por una autoridad de certificación válida en la que ya confía un navegador u otro software. Stuxnet usó ataques similares que permitieron que el software se hiciera pasar por un código confiable. El objetivo de la transparencia del certificado es permitir que un usuario final determine, mediante un procedimiento simple, si un certificado es realmente válido. La verificación con el paquete predeterminado de certificados puede no ser suficiente para hacer esto y, por lo tanto, se desea una verificación adicional. También se han avanzado otras sugerencias para la transparencia de los certificados.

Se usó un ataque diferente contra Comodo, una autoridad de certificación, que resultó en 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 de confianza y, por lo tanto, un usuario no habría recibido ninguna advertencia si hubiera visitado un sitio web falso, en contraste con el incidente de Siria, donde el certificado fue falsificado de manera tosca, incluida 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 CERT DNS o a través de LDAP a un directorio X.500[2008]. El problema de un enlace autorizado se detalla en los RFC relacionados con la precisión de la información DNS asegurada mediante la firma desde la raíz mediante DNSSEC.

El concepto de servidores de nombres raíz ha sido una fuente de controversia importante en la comunidad de Internet, pero el DNS está resuelto en gran medida. Tradicionalmente, se ha pensado que el espacio de nombres asociado con X.500 comienza con una autoridad nacional de nombres, lo que refleja el enfoque de ISO/ITU para los sistemas globales con representación nacional. Así, diferentes países crearán sus propios servicios X.500 exclusivos. El X.500 de los EE. UU. se privatizó en 1998, cuando el gobierno de los EE. UU. ya no ofrecía el registro de 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 sigue estando presente en las principales instalaciones de millones de usuarios dentro de los centros de datos corporativos y dentro del gobierno de los EE. UU. para la acreditación.

Lista de estándares de la serie X.500

Crítica

Los autores de RFC 2693 (sobre SPKI) señalan que "Es poco probable que el plan X.500 original llegue a buen término. Las colecciones de entradas de directorio... son consideradas valiosas o incluso confidenciales por los propietarios de 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 globalmente único que todos podrían usar al referirse a una entidad) tampoco es probable que ocurra."