X.500

From Wikipedia, the free encyclopedia
Jump to: navigation, search

X.500 is a series of computer networking standards covering electronic directory services. The X.500 series was developed by ITU-T, formerly known as CCITT, and first approved in 1988.[1] The directory services were developed in order to support the requirements of X.400 electronic mail exchange and name lookup. ISO was a partner in developing the standards, incorporating them into the Open Systems Interconnection suite of protocols. ISO/IEC 9594 is the corresponding ISO identification.

Contents

X.500 protocols [edit]

The protocols defined by X.500 include

Because these protocols used the OSI networking stack, a number of alternatives to DAP were developed to allow Internet clients to access to 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.

X.500 data models [edit]

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 relationship of the X.500 Directory and X.509v3 digital certificates [edit]

The current use of X.509v3 certificates outside the Directory loaded directly into web browsers is problematic, but has been necessary for e-commerce to develop at all. 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.

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

The presentation layer given to users was that the DNS site name "www.foobar.com" was verified in a browser, therefore creating trust for users that they had reached the correct web site via HTTPS.

CA Certs are loaded into the browser statically, 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.

Thus the browser can verify the SSL cert of the website. The bound distinguished name is located in the subject fields of the certificate. X.509v3 can contain other extensions depending on the community of interest other than international domain names. For broad Internet use, RFC5280 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 being presented (and likely to trigger a browser warning) with a valid certificate which can only be bound to the DN or Distinguished Name which was designed to be looked up in a 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.

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. 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 has been "identity proofed" by ANSI, providing another layer of assurance regarding binding the certificate to the identity. If all components of the system are functional, then the resultant security assurance is at NIST 800-63 Level 3.

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 triggered a browser warning.

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.

List of X.500 series standards [edit]

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 [edit]

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."

"X.500 is too complex to support on desktops and over the Internet, so LDAP was created to provide this service 'for the rest of us'." [2]

External links [edit]

X.500 Products [edit]

References [edit]