View source for X.500

{{Short description|Series of computer networking standards covering electronic directory services}}
'''X.500''' is a series of computer networking standards covering electronic [[directory service]]s.  The X.500 series was developed by the [[ITU-T|Telecommunication Standardization Sector of the International Telecommunication Union]] (ITU-T) and was first approved in 1988.<ref>[http://www.collectionscanada.gc.ca/iso/ill/document/ill_directory/X_500andLDAP.pdf X.500 and LDAP]collectionscanada.gc.ca {{Webarchive|url=https://web.archive.org/web/20210401105523/https://www.collectionscanada.gc.ca/iso/ill/document/ill_directory/X_500andLDAP.pdf |date=2021-04-01 }}</ref>  The directory services were developed to support requirements of [[X.400]] electronic mail exchange and name lookup. The [[International Organization for Standardization]] (ISO) and [[International Electrotechnical Commission]] (IEC) were partners in developing the standards, incorporating them into the [[Open Systems Interconnection]] suite of protocols.  '''ISO/IEC 9594''' is the corresponding ISO/IEC identification.

==X.500 protocols==
The protocols defined by X.500 include:
{| class="wikitable"
|+
!Protocol Name
!Description
!Defining Specification*
|-
|[[Directory Access Protocol]] (DAP)
|"Defines the exchange of requests and outcomes between a DUA and a DSA." 
This is how a client interacts with the directory system.
|ITU Recommendation X.511
|-
|Directory System Protocol (DSP)
|"Defines the exchange of requests and outcomes between two DSAs." 
This is how two directory servers interact with each other.
|ITU Recommendation X.518
|-
|Directory Information Shadowing Protocol (DISP)
|"Defines the exchange of replication information between two DSAs that have established shadowing agreements." 
This is how directory servers replicate information.
|ITU Recommendation X.525
|-
|Directory Operational Bindings Management Protocol (DOP)
|"Defines the exchange of administrative information between two DSAs to administer operational bindings between them." 
This is how directories manage agreements, such as those relating to replication, between each other.
|ITU Recommendation X.501
|-
|Certificate Authority Subscription Protocol (CASP)
|
|ITU Recommendation X.509
|-
|Authorization Validation Management Protocol (AVMP)
|
|ITU Recommendation X.509
|-
|Trust Broker Protocol (TBP)
|
|ITU Recommendation X.510
|}
<nowiki>*</nowiki> 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 [[Open Systems Interconnection|OSI]] networking stack, a number of alternatives to DAP were developed to allow Internet clients to access the X.500 Directory using the [[Internet protocol suite|TCP/IP]] networking stack.  The most well-known alternative to DAP is Lightweight Directory Access Protocol ([[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.

== Transport Protocols ==
The X.500 protocols traditionally use the [[Open Systems Interconnection|OSI]] networking stack. However, the Lightweight Directory Access Protocol ([[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.

==X.500 data models==
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 Agent]]s (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 [[Lightweight Directory Access Protocol|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.

==Relationship to X.509v3 digital certificates==

The current use of [[X.509|X.509v3]] certificates loaded directly into [[web browser]]s (as opposed to referenced in a directory structure) 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). 

X.509 was designed to be the secure access method for updating X.500 before the [[World Wide Web]], but then as web browsers became popular, there needed to be a simple method of encrypting connections on the [[transport layer]] to web servers. Hence, trusted [[root certificates]] for supported certificate authorities were pre-loaded into certificate storage areas on the communicating devices (e.g. personal computer, proxy, or web server).

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.<ref>{{Cite web|url=https://www.nist.gov/nstic|title=National Strategy for Trusted Identities in Cyberspace|accessdate=10 September 2023|archive-date=15 August 2016|archive-url=https://web.archive.org/web/20160815043145/http://www.nist.gov/nstic/|url-status=dead}}</ref>

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 browser and operating system vendors (such as [[Microsoft]] and [[Mozilla]]) in terms of their continued trustworthiness. Should a problem arise, such as what occurred with [[DigiNotar]], browser vendors 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.

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.{{Ref RFC|4523}}

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, because of [[digital signature|its signature]], 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.<ref>{{cite web |title=Modernize Federal Identities |url=https://www.idmanagement.gov/university/fpki/ |website=www.idmanagement.gov |language=en}}</ref>

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.<ref>{{Cite journal|last1=Wendlandt|first1=Dan|last2=Andersen|first2=David G.|last3=Perrig|first3=Adrian|date=June 2008|title=Perspectives: Improving SSH-style Host Authentication with Multi-Path Probing|url=https://www.usenix.org/legacy/events/usenix08/tech/full_papers/wendlandt/wendlandt.pdf|journal=Proceedings of the 2008 USENIX Annual Technical Conference|pages=321–334}}</ref> 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.

=== Certificate distribution via DNS and directories; sector-specific uses ===
Some deployments (for example, the US [[Direct Project]], which created standards for PKI in the healthcare industry) specify DNS-based publication of recipient [[S/MIME]] certificates, with options for DNS-based or LDAP-based discovery. Early profiles used the DNS CERT Resource Record ({{IETF RFC|4398}}); newer specifications define DANE mechanisms, including TLSA for TLS{{Ref RFC|6698}} and SMIMEA for S/MIME.{{Ref RFC|8162}} In practice, many production healthcare exchanges rely on curated trust-anchor bundles and directory/HTTP services, with [[DNSSEC]]/[[DNS-based Authentication of Named Entities|DANE]] adoption varying by ecosystem.<ref>{{cite web |author=Direct Trust |title=ANSI/DS 2019-01-100-2021: Applicability Statement for Secure Health Transport Version 1.3 |url=https://directtrust.org/standards/the-direct-standard/versions}}</ref>

DNS is sometimes preferred for storing and distributing information as it is [[High availability|highly available]],{{Ref RFC|6950}} and this can be applied to certificates and identities.

=== Namespace and governance considerations ===
The concept of DNS [[root name server]]s has been contentious within the Internet community, though the issue is largely resolved for DNS.<ref>{{cite report |author=ICANN Root Server System Advisory Committee |title=RSSAC 023v2: History of the Root Server System |url=https://www.icann.org/en/rssac/publications?publication-number=rssac%20023&publication-number=rssac%20023v2&page=1 |publisher=ICANN |access-date=4 October 2025}}</ref> By contrast, the X.500 namespace has traditionally been viewed as starting with a national naming authority, mirroring ISO/ITU approaches with national representation.<ref>See the standard itself, particularly the Directory Information Base and Directory Information Tree.</ref> Different countries therefore create their own unique X.500 services.

=== Security incidents and transparency efforts ===
{{See also|Digital signature forgery}}
Events in 2011 highlighted threats from unknown nation-state actors forging certificates. A man-in-the-middle attack against political activists in Syria accessing Facebook over the web would normally have triggered a browser warning (which many ordinary users would reflexively dismiss), but would not have done so had the MITM certificate been issued by a CA already trusted by the browser.<ref>{{cite web |last1=Eckersley |first1=Peter |title=A Syrian Man-In-The-Middle Attack against Facebook |url=https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook |website=Electronic Frontier Foundation |language=en |date=5 May 2011}}</ref> Similar techniques were used by Stuxnet to allow malicious software to impersonate trusted code – in that event, using stolen rather than forged certificates.<ref>{{cite web |url=https://www.welivesecurity.com/2010/07/19/win32stuxnet-signed-binaries/ |website=www.welivesecurity.com|title=Win32/Stuxnet Signed Binaries|date=19 July 2010|first=Pierre-Marc|last=((Bureau))}}</ref> The aim of [[Certificate Transparency|certificate transparency]] is to provide an end user with a simple procedure to determine whether a certificate is valid; checking only against the default bundle may be insufficient, hence the desire for an additional check. Other proposals for certificate transparency have also been advanced.<ref>{{cite web|url=http://www.certificate-transparency.org/|title=Certificate Transparency|website=www.certificate-transparency.org}}</ref>

A different attack affected Comodo, resulting in forged certificates targeting high-profile communications websites and necessitating urgent updates to major browsers.<ref>{{cite news |last1=Zetter |first1=Kim |title=Hack Obtains 9 Bogus Certificates for Prominent Websites; Traced to Iran |url=https://www.wired.com/2011/03/comodo-compromise/ |work=Wired}}</ref> In that case, the certificates were actually issued by a trusted CA, leaving end users with no warning if they visited a spoofed site – unlike the Syrian incident, where the certificate was crudely forged (substituting "Alto Palo" for "Palo Alto") and contained incorrect serial numbers.

==List of X.500 series standards==
{| class="wikitable"
|-
! ITU-T number
! [[ISO/IEC]] number
! Title of Standard
|-
| X.500
| [[ISO/IEC 9594-1]]
| The Directory: Overview of concepts, models and services
|-
| [[X.501]]
| [[ISO/IEC 9594-2]]
| The Directory: Models
|-
| [[X.509]]
| [[ISO/IEC 9594-8]]
| The Directory: [[Public-key]] and attribute certificate frameworks
|-
| [[X.511]]
| [[ISO/IEC 9594-3]]
| The Directory: Abstract service definition
|-
| [[X.518]]
| [[ISO/IEC 9594-4]]
| The Directory: Procedures for distributed operation
|-
| [[X.519]]
| [[ISO/IEC 9594-5]]
| The Directory: Protocol specifications
|-
| X.520
| [[ISO/IEC 9594-6]]
| The Directory: Selected attribute types
|-
| [[X.521]]
| [[ISO/IEC 9594-7]]
| The Directory: Selected object classes
|-
| [[X.525]]
| [[ISO/IEC 9594-9]]
| The Directory: Replication
|-
| [[X.530]]
| [[ISO/IEC 9594-10]]
| The Directory: Use of systems management for administration of the Directory
|}

==Criticism==
The authors of {{Sum RFC|2693|ref=yes|status=no}} 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."

==See also==
*[[ISO/IEC JTC 1/SC 6]]

==References==
{{Reflist}}

==External links==
*{{cite web|url=http://sec.cs.kent.ac.uk/x500book/|title=Understanding X.500 - The Directory|last=Chadwick|first=D W|date=1994|access-date=2017-12-06|archive-date=2017-11-28|archive-url=https://web.archive.org/web/20171128093203/http://sec.cs.kent.ac.uk/x500book/|url-status=dead}}
*{{webarchive |url=https://web.archive.org/web/20190104231951/http://www.x500standard.com/ |date=January 04, 2019 |title=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.}}

{{ISO standards}}

{{Authority control}}

[[Category:X.500| ]]
[[Category:ITU-T recommendations]]