X.500

Last updated

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). ITU-T was formerly known as the Consultative Committee for International Telephony and Telegraphy (CCITT). X.500 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.

Contents

X.500 protocols

The protocols defined by X.500 include:

Protocol NameDescriptionDefining 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

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

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.

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.

The relationship of the X.500 Directory and X.509v3 digital 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.

List of X.500 series standards

ITU-T number ISO/IEC numberTitle 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 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."

See also

Related Research Articles

Active Directory (AD) is a directory service developed by Microsoft for Windows domain networks. Windows Server operating systems include it as a set of processes and services. Originally, only centralized domain management used Active Directory. However, it ultimately became an umbrella title for various directory-based identity-related services.

The Domain Name System (DNS) is a hierarchical and distributed naming system for computers, services, and other resources in the Internet or other Internet Protocol (IP) networks. It associates various information with domain names assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. The Domain Name System has been an essential component of the functionality of the Internet since 1985.

The Lightweight Directory Access Protocol is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. Directory services play an important role in developing intranet and Internet applications by allowing the sharing of information about users, systems, networks, services, and applications throughout the network. As examples, directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate email directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number.

<span class="mw-page-title-main">Proxy server</span> Computer server that makes and receives requests on behalf of a user

In computer networking, a proxy server is a server application that acts as an intermediary between a client requesting a resource and the server providing that resource. It improves privacy, security, and performance in the process.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

<span class="mw-page-title-main">Public key infrastructure</span> System that can issue, distribute and verify digital certificates

A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption. The purpose of a PKI is to facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, internet banking and confidential email. It is required for activities where simple passwords are an inadequate authentication method and more rigorous proof is required to confirm the identity of the parties involved in the communication and to validate the information being transferred.

In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key. The certificate includes information about the key, information about the identity of its owner, and the digital signature of an entity that has verified the certificate's contents. If the signature is valid, and the software examining the certificate trusts the issuer, then it can use that key to communicate securely with the certificate's subject. In email encryption, code signing, and e-signature systems, a certificate's subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.

In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.

<span class="mw-page-title-main">Root certificate</span> Certificate identifying a root authority

In cryptography and computer security, a root certificate is a public key certificate that identifies a root certificate authority (CA). Root certificates are self-signed and form the basis of an X.509-based public key infrastructure (PKI). Either it has matched Authority Key Identifier with Subject Key Identifier, in some cases there is no Authority Key identifier, then Issuer string should match with Subject string. For instance, the PKIs supporting HTTPS for secure web browsing and electronic signature schemes depend on a set of root certificates.

In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.

In computing, a directory service or name service maps the names of network resources to their respective network addresses. It is a shared information infrastructure for locating, managing, administering and organizing everyday items and network resources, which can include volumes, folders, files, printers, users, groups, devices, telephone numbers and other objects. A directory service is a critical component of a network operating system. A directory server or name server is a server which provides such a service. Each resource on the network is considered an object by the directory server. Information about a particular resource is stored as a collection of attributes associated with that resource or object.

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

The ISODE software, more formally the ISO Development Environment, was an implementation of the OSI upper layer protocols, from transport layer to application layer, which was used in the Internet research community to experiment with implementation and deployment of OSI during the late 1980s and early 1990s.

A directory information tree (DIT) is data represented in a hierarchical tree-like structure consisting of the Distinguished Names (DNs) of directory service entries.

<span class="mw-page-title-main">Extended Validation Certificate</span> Certificate for HTTPS websites and software

An Extended Validation Certificate (EV) is a certificate conforming to X.509 that proves the legal entity of the owner and is signed by a certificate authority key that can issue EV certificates. EV certificates can be used in the same manner as any other X.509 certificates, including securing web communications with HTTPS and signing software and documents. Unlike domain-validated certificates and organization-validation certificates, EV certificates can be issued only by a subset of certificate authorities (CAs) and require verification of the requesting entity's legal identity before certificate issuance.

The Online Certificate Status Protocol (OCSP) stapling, formally known as the TLS Certificate Status Request extension, is a standard for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing Online Certificate Status Protocol (OCSP) responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance.

PKI Resource Query Protocol (PRQP) is an Internet protocol used for obtaining information about services associated with an X.509 Certificate Authority. It is described by RFC 7030 published on October 23, 2013. PRQP aims to improve Interoperability and Usabilities issues among PKIs, helping finding services and data repositories associated with a CA. Messages communicated via PRQP are encoded in ASN.1 and are usually communicated over HTTP.

<span class="mw-page-title-main">DigiCert</span> Internet security company

DigiCert, Inc. is a global digital security company and a provider of digital trust headquartered in Lehi, Utah, with over a dozen global offices in various countries including: Australia, Belgium, Bermuda, Ireland, Japan, India, Germany, France, Netherlands, South Africa, Switzerland and United Kingdom. As a certificate authority (CA) and trusted third party, DigiCert provides the public key infrastructure (PKI) and validation required for issuing digital certificates or TLS/SSL certificates. These certificates are used to verify and authenticate the identities of organizations and domains and to protect the privacy and data integrity of users’ digital interactions with web browsers, email clients, documents, software programs, apps, networks and connected IoT devices.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

<span class="mw-page-title-main">Domain-validated certificate</span>

A domain validated certificate (DV) is an X.509 public key certificate typically used for Transport Layer Security (TLS) where the domain name of the applicant is validated by proving some control over a DNS domain. Domain validated certificates were first distributed by GeoTrust in 2002 before becoming a widely accepted method.

References

  1. ↑ http://www.collectionscanada.gc.ca/iso/ill/document/ill_directory/X_500andLDAP.pdf [ bare URL PDF ]
  2. ↑ "National Strategy for Trusted Identities in Cyberspace".
  3. ↑ Wendlandt, Dan; Andersen, David G.; Perrig, Adrian (June 2008). "Perspectives: Improving SSH-style Host Authentication with Multi-Path Probing" (PDF). Proceedings of the 2008 USENIX Annual Technical Conference: 321–334.
  4. ↑ "Certificate Transparency". www.certificate-transparency.org.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.