X.500

The protocols defined by X.500 include:

* These protocols are typically defined piecemeal throughout multiple specifications and ASN.1 modules. The "Defining Specification" column above indicates (subjectively) which specification contributes most specifically to a protocol.

Because these protocols used the OSI networking stack, a number of alternatives to DAP were developed to allow Internet clients to access the X.500 Directory using the TCP/IP networking stack. The most well-known alternative to DAP is Lightweight Directory Access Protocol (LDAP). While DAP and the other X.500 protocols can now use the TCP/IP networking stack, LDAP remains a popular directory access protocol.

The X.500 protocols traditionally use the OSI networking stack. However, the Lightweight Directory Access Protocol (LDAP) uses TCP/IP for transport. In later versions of the ITU Recommendation X.519, the Internet Directly-Mapped (IDM) protocols were introduced to allow X.500 protocol data units (PDUs) to be transported over the TCP/IP stack. This transport involves ISO Transport over TCP as well as a simple record-based binary protocol to frame protocol datagrams.

The primary concept of X.500 is that there is a single Directory Information Tree (DIT), a hierarchical organization of entries which are distributed across one or more servers, called Directory System Agents (DSA). An entry consists of a set of attributes, each attribute with one or more values. Each entry has a unique Distinguished Name, formed by combining its Relative Distinguished Name (RDN), one or more attributes of the entry itself, and the RDNs of each of the superior entries up to the root of the DIT. As LDAP implements a very similar data model to that of X.500, there is further description of the data model in the article on LDAP.

X.520 and X.521 together provide a definition of a set of attributes and object classes to be used for representing people and organizations as entries in the DIT. They are one of the most widely deployed white pages schema.

X.509, the portion of the standard providing for an authentication framework, is now also widely used outside of the X.500 directory protocols. It specifies a standard format for public-key certificates.

The current use of X.509v3 certificates outside the Directory structure loaded directly into web browsers was necessary for e-commerce to develop by allowing for secure web based (SSL/TLS) communications which did not require the X.500 directory as a source of digital certificates as originally conceived in X.500 (1988). One should contrast the role of X.500 and X.509 to understand their relationship in that X.509 was designed to be the secure access method for updating X.500 before the WWW, but when web browsers became popular there needed to be a simple method of encrypting connections on the transport layer to web sites. Hence the trusted root certificates for supported certificate authorities were pre loaded into certificate storage areas on the personal computer or device.

Added security is envisaged by the scheduled 2011-2014 implementation of the US National Strategy for Trusted Identities in Cyberspace, a two- to three-year project protecting digital identities in cyberspace.[2]

The WWW e-commerce implementation of X.509v3 bypassed but did not replace the original ISO standard authentication mechanism of binding distinguished names in the X.500 Directory.

These packages of certificates can be added or removed by the end user in their software, but are reviewed by Microsoft and Mozilla in terms of their continued trustworthiness. Should a problem arise, such as what occurred with DigiNotar, browser security experts can issue an update to mark a certificate authority as untrusted, but this is a serious removal effectively of that CA from "internet trust". X.500 offers a way to view which organization claims a specific root certificate, outside of that provided bundle. This can function as a "4 corner model of trust" adding another check to determine if a root certificate has been compromised. Rules governing the Federal Bridge policy for revoking compromised certificates are available at www.idmanagement.gov.

The contrast of this browser bundled approach is that in X.500 or LDAP the attribute "caCertificate" can be "bound" to a directory entry and checked in addition to the default pre-loaded bundle of certificates of which end users typically have never noticed unless an SSL warning message has appeared.

For example, a web site using SSL, typically the DNS site name "www.foobar.com" is verified in a browser by the software using libraries that would check to see if the certificate was signed by one of the trusted root certificates given to the user.

Therefore, creating trust for users that they had reached the correct web site via HTTPS.

However, stronger checks are also possible, to indicate that more than the domain name was verified. To contrast this with X.500, the certificate is one attribute of many for an entry, in which the entry could contain anything allowable by the specific Directory schema. Thus X.500 does store the digital certificate, but it is one of many attributes that could potentially verify the organization, such as physical address, a contact telephone number and an email contact.

CA Certs or certificate authority certs are loaded into the browser automatically (in the case of Microsoft's update mechanism), or in new version updates of browsers, and the user is given further choices to import, delete, or develop an individual trust relationship with the loaded Certificate Authorities and determine how the browser will behave if OCSP revocation servers are unreachable.

This is in contrast with the Directory model which associates the attribute caCertificate with a listed certificate authority.

Thus the browser can verify the SSL cert of the website by means of the loaded group of accepted certificates or the root certificates can be looked up in an X.500 or LDAP Directory (or via HTTP/S) and imported into the list of trusted certificate authorities.

The "bound" distinguished name is located in the subject fields of the certificate which matches the Directory entry. X.509v3 can contain other extensions depending on the community of interest other than international domain names. For broad Internet use, RFC-5280 PKIX describes a profile for fields that may be useful for applications such as encrypted email.

An end user who relies on the authenticity of a certificate being presented to a browser or email has no simple way to compare a forged certificate presented (perhaps which triggers a browser warning) with a valid certificate, without also being given the opportunity to validate the DN or Distinguished Name which was designed to be looked up in an X.500 DIT.

The certificate itself is public and considered to be unforgeable and can therefore be distributed in any manner, but an associated binding to an identity occurs in the Directory. Binding is what links the certificate to the identity who claims to be using that certificate. For example, the X.500 software that runs the Federal Bridge has cross certificates that enable trust between certificate authorities.

Simple homographic matching of domain names has resulted in phishing attacks where a domain can appear to be legitimate, but is not.

If a X.509v3 certificate is bound to a valid organization's distinguished name within the Directory, then a simple check can be made in regards to the authenticity of the certificate by a comparison with what is presented to the browser with what is present in the Directory.

Some options do exist to check notaries to see if a certificate has only recently been seen, and therefore more likely to have been compromised.[3] If the cert is likely to be trusted and is failing because the domain name is a slight mismatch, it will then initially fail in the browser, but then be subjected to the notary trust, which can then bypass the browser warning.

A valid organizational entry, such as o=FoobarWidgets, will also have an associated alphanumeric OID, and it has been "identity proofed" by ANSI, providing another layer of assurance regarding binding the certificate to the identity.

Recent events (2011) have indicated a threat from unknown actors in nation states who have forged certificates. This was done in order to create a MITM attack against political activists in Syria accessing Facebook over the web. This would have normally triggered a browser warning, but would not if the MITM certificate was issued by a valid certificate authority already trusted by a browser or other software. Similar attacks were used by Stuxnet which allowed software to impersonate trusted code. The point of certificate transparency is to allow an end user to determine, using a simple procedure if a certificate is in fact valid. Checking against the default bundle of certificates may not be enough to do this, and therefore an additional check is desired. Other suggestions for certificate transparency have also been advanced.[4]

A different attack was used against Comodo, a certificate authority, that resulted in forged certificates that were directed at high-profile communications websites. This necessitated an emergency patch to major browsers. These certificates were actually issued from a trusted Certificate Authority, and therefore a user would have had no warning if they had gone to a faked website, in contrast with the Syria incident, where the certificate was crudely forged, including substituting Alto Palo, for Palo Alto. and incorrect serial numbers.

Some projects designed to exchange PHI, protected Health Information (which is considered to be highly HIPAA sensitive) may obtain X.509v3 certs via a CERT DNS resource record, or via LDAP to a X.500[2008] Directory. The issue of an authoritative bind then is detailed in RFCs related to the accuracy of the DNS information secured by signing from the root using DNSSEC.

The concept of root name servers has been a source of major contention in the Internet community, but for DNS is largely resolved. The name space associated with X.500 has traditionally been thought to start with a national naming authority, which mirrors the ISO/ITU approach to global systems with national representation. Thus different countries will create their own unique X.500 services. The U.S. X.500 was privatized in 1998, when the U.S. Government no longer offered X.500 or DNS registration outside of known government agencies.

The X.500 pilot project has been in development in the commercial space, and the technology continues to be present in major installations of millions of users within corporate data centers, and within the U.S. Government for credentialing.

The authors of RFC 2693 (concerning SPKI) note that "The original X.500 plan is unlikely ever to come to fruition. Collections of directory entries... are considered valuable or even confidential by those owning the lists and are not likely to be released to the world in the form of an X.500 directory sub-tree." and that "The X.500 idea of a distinguished name (a single, globally unique name that everyone could use when referring to an entity) is also not likely to occur."

• ISO/IEC JTC 1/SC 6

• Hardcastle-Kille, S. (1993). "RFC1485: A String Representation of Distinguished Names". doi:10.17487/RFC1485. Retrieved 2021-02-10. Many OSI Applications make use of Distinguished Names (DN) as defined in the OSI Directory, commonly known as X.500 [CCI88]. This specification assumes familiarity with X.500, and the concept of Distinguished Name. {{cite journal}}: Cite journal requires |journal= (help)
• Chadwick, D W (1994). "Understanding X.500 - The Directory". Retrieved 2017-12-06.
• X500Standard.com – The X.500 community site that is both a guide to the X.500 Standard and a repository for existing and new work being carried out on the standard. at the Wayback Machine (archived January 4, 2019)