Top Qs
Timeline
Chat
Perspective
X.500
Series of computer networking standards covering electronic directory services From Wikipedia, the free encyclopedia
Remove ads
X.500 is a series of computer networking standards covering electronic directory services. The X.500 series was developed by the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) and was first approved in 1988.[1] 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.
Remove ads
X.500 protocols
Summarize
Perspective
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.
Remove ads
Transport Protocols
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.
Remove ads
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 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.
Relationship to X.509v3 digital certificates
Summarize
Perspective
The current use of X.509v3 certificates loaded directly into web browsers (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.[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 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.[3]
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 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.[4]
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.[5] 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 (RFC 4398); newer specifications define DANE mechanisms, including TLSA for TLS[6] and SMIMEA for S/MIME.[7] In practice, many production healthcare exchanges rely on curated trust-anchor bundles and directory/HTTP services, with DNSSEC/DANE adoption varying by ecosystem.[8]
DNS is sometimes preferred for storing and distributing information as it is highly available,[9] and this can be applied to certificates and identities.
Namespace and governance considerations
The concept of DNS root name servers has been contentious within the Internet community, though the issue is largely resolved for DNS.[10] By contrast, the X.500 namespace has traditionally been viewed as starting with a national naming authority, mirroring ISO/ITU approaches with national representation.[11] Different countries therefore create their own unique X.500 services.
Security incidents and transparency efforts
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.[12] Similar techniques were used by Stuxnet to allow malicious software to impersonate trusted code – in that event, using stolen rather than forged certificates.[13] The aim of 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.[14]
A different attack affected Comodo, resulting in forged certificates targeting high-profile communications websites and necessitating urgent updates to major browsers.[15] 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.
Remove ads
List of X.500 series standards
Remove ads
Criticism
The authors of RFC 2693 – "SPKI Certificate Theory,"[16] 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."
Remove ads
See also
References
External links
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads