RFC 1309

Technical Overview of Directory Services Using the X.500 Protocol 🎀

okay bestie, paperwork first 💅 this is RFC 1309, an FYI (FYI 14 in the series ✨) from the Network Working Group, written by C. Weider (ANS), J. Reynolds (ISI), and S. Heker (JvNC). it's dated March 1992. the header doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFC 🦋

---

Status of this Memo 📋

this memo is here to provide info for the Internet community 🧚 it does not specify an Internet standard. distribution is unlimited, so share away 💜

Abstract ✨

so this doc is an overview of the X.500 standard, written for people who aren't familiar with the tech yet 🌸 it compares and contrasts directory services based on X.500 with several other directory services currently in use on the Internet. it also describes where the standard stands and gives references for more info on X.500 implementations and technical details 📚

the main goal is to show off the vast functionality of the X.500 protocol 👑 and how it can give you a global directory for humans to use, and how it can support other applications that would benefit from directory services, like main programs 💻

this FYI RFC is a product of the Directory Information Services (pilot) Infrastructure Working Group (DISI), a combined effort of the User Services and OSI Integration Areas of the Internet Engineering Task Force (IETF) 🫶

1. Introduction 🌈

so as industry, science, and tech sped up over the last century 🏭, it got more and more likely that someone far away was trying to solve the exact same problems you were, or that someone far away had vital info that could totally affect your research or business 🤯 the telecom industry blew up too, from telegraphs to telephones to computer networks 📞 that made it way easier to talk to literally anyone, PROVIDED THAT YOU KNOW HOW TO REACH THEM 📍

so along with all that telecom infrastructure came directory services 💜 in this paper we'll go through different models of directory services, what's limiting about the current ones, and some of the fixes the X.500 standard offers for those limits 🔥

2. Models of Directory Services 👑

2.1. The telephone company's directory services. 📞

a model a lot of people think of when they hear "Directory Services" is the directory service the local phone company runs 📖 the local phone company keeps an on-line list of people with phone service, along with their numbers and addresses. you get this info by calling Directory Assistance, giving the name and address of the person whose number you want, and waiting for the operator to search their database 🙈 it's also in a phone book the company publishes yearly on paper.

the phone companies can offer this because they administer the pool of phone numbers 💅 but it has limits. you can only find someone's number if you know their name and the city or location they live in 😭 if two or more people have listings under the same name in the same locality, there's no extra info to pick the right number 🤷‍♀️ the printed phone book can be as much as a year out of date, and the phone company's internal directory can be as much as two weeks out of date 💀 third problem: you have to call Directory Assistance in a given area code to get info for that area. you can't call one single number consistently 📵

for businesses that advertise in the Yellow Pages, there's some extra info stored for each business, but that info is unavailable through Directory Assistance, so you have to gather it from the phone book 📒

2.2. Some currently available directory services on the Internet. 🌐

the Internet is a huge mix of people, computers, and computer networks, with none of the hierarchy the phone system imposes on area codes and exchange prefixes 🕸️ so any directory service must be able to deal with the fact that the Internet is not structured. for example, the hosts foo.com and v2.foo.com may be on opposite sides of the world, and the .edu domain maps onto an enormous number of organizations, etc. 🌍 let's look at a few services on the Internet that do directory-type stuff 👀

2.2.1. The finger protocol. 👆

the finger protocol has been implemented for UNIX systems and a small number of other machines. it lets you "finger" a specific person or username on a host running the protocol 💅 you invoke it by typing something like "finger clw@mazatzal.merit.edu". the output format isn't specified by the protocol, but a certain set of info gets returned. here's an example from a UNIX finger operation:

      Login name: clw                   In real life: Chris Weider
      Directory: /usr/clw               Shell: /bin/csh
      On since Jul 25 09:43:42          4 hours 52 minutes Idle Time
      Plan:
      Home: 971-5581

the first three lines come from the UNIX operating system's info, and the line(s) after the "Plan:" line come from a file called .plan that each user modifies 📝 the limits of fingerd include:

• a) you have to already know which host to finger to find a specific person,
• b) since primarily UNIX machines run fingerd, people on other types of operating systems can't be located this way,
• c) fingerd is often disabled on UNIX systems for security purposes,
• d) if you want to be found on more than one system, you have to make sure all the .plan files are consistent, and
• e) there's no way to search the .plan files on a given host to (for example) find everyone on mazatzal.merit.edu who works on X.500.

so fingerd has limited usefulness as a piece of the Internet Directory 🥲

2.2.2. whois 🔍

the whois utility is available on a wide variety of systems 💕 and it works by querying a centralized database maintained at the DDN NIC. that database was for many years located at SRI International in Menlo Park, California, and it's now located at GSI. it contains a large amount of info about people and equipment used to build the Internet. SRI (and now GSI) collected the WHOIS database info as part of its role as the Network Information Center for the TCP/IP portion of the Internet 🗂️

whois is ubiquitous and has a super simple interface 😌 a typical whois query looks like:

   whois Reynolds

and returns info like:

      Reynolds, John F. (JFR22) 532JFR@DOM1.NWAC.SEA06.NAVY.MIL
                                           (702) 426-2604 (DSN) 830-2604
      Reynolds, John J. (JJR40) amsel-lg-pl-a@MONMOUTH-EMH3.ARMY.MIL
                                           (908) 532-3817 (DSN) 992-3817
      Reynolds, John W. (JWR46) EAAV-AP@SEOUL-EMH1.ARMY.MIL
                                           (DSN) 723-3358
      Reynolds, Joseph T. (JTR10)  JREYNOLDS@PAXRV-NES.NAVY.MIL
                                       011-63-47-885-3194 (DSN) 885-3194
      Reynolds, Joyce K. (JKR1) JKREY@ISI.EDU             (213) 822-1511
      Reynolds, Keith (KR35)    keithr@SCO.CO             (408) 425-7222
      Reynolds, Kenneth (KR94)                            (502) 454-2950
      Reynolds, Kevin A. (KR39)    REYNOLDS@DUGWAY-EMH1.ARMY.MIL
                                           (801) 831-5441 (DSN) 789-5441
      Reynolds, Lee B. (LBR9)   reynolds@TECHNET.NM.ORG   (505) 345-6555

a further lookup on Joyce Reynolds uses this command line:

   whois JKR1

and returns:

      Reynolds, Joyce K. (JKR1)               JKREY@ISI.EDU
         University of Southern California
         Information Sciences Institute
         4676 Admiralty Way
         Marina del Rey, CA 90292
         (310) 822-1511

         Record last updated on 07-Jan-91.

the whois database also has info about the Domain Name System (DNS), and some info about hosts, major regional networks, and large parts of the MILNET system 🧠

the WHOIS database is big and comprehensive enough to show a lot of the flaws of a large centralized database 🚩

• a) since the database is maintained on one machine, a processor bottleneck forces slow responses during peak querying times, even when many of those queries are unrelated,
• b) since the database is maintained on one machine, a storage bottleneck forces the database administrators to severely limit how much info can be kept on each entry, and
• c) all changes to the database have to be mailed to a "hostmaster" and then physically reentered into the database, which increases both the turnaround time and the chance of a transcription mistake 😭

2.2.3 The Domain Name System

Okay so the DNS 🌐 is how the Internet keeps track of which host name maps to which IP address. The basic setup is that every domain, like merit.edu or k-12.edu, gets registered with the NIC. When that happens, you name a primary nameserver and (maybe) some secondaries. Each of those nameservers must provide the host name to IP address mapping for every host in the domain, so the naming service is spread across lots of servers 🫶. You can also split a domain into subdomains, with a different nameserver for each one. Iconic 💅

A lot of people use the DNS without ever realizing it, since humans would way rather remember names than IP addresses. But you can totally query it yourself with the nslookup utility. Here's a sample session:

home.merit.edu(1): nslookup
Default Server:  merit.edu
Address:  35.42.1.42

> scanf.merit.edu
Server:  merit.edu
Address:  35.42.1.42

Name:   scanf.merit.edu
Address: 35.42.1.92

> 35.42.1.92
Server:  merit.edu
Address: 35.42.1.42

Name:  [35.42.1.92]
Address: 35.42.1.92

So yeah, you can explicitly figure out the address tied to a given host 🔍. Reverse name mapping works in the DNS too, like in this one:

home.merit.edu(2): traceroute ans.net
traceroute to ans.net (147.225.1.2), 30 hops max, 40 byte packets
  1 t3peer (35.1.1.33) 11 ms 5 ms 5 ms
  2 enss (35.1.1.1) 6 ms 6 ms 6 ms
        .................
  9 192.77.154.1 (192.77.154.1) 51 ms 43 ms 49 ms
 10 nis.ans.net (147.225.1.2) 53 ms 53 ms 46 ms

At each hop of that traceroute, the program tries a reverse lookup through the DNS and shows the results when it works 🦋.

Ngl, the DNS has been superlatively good at the job it was built for: keeping the namespace maintained in a distributed way and giving super fast lookups in that namespace 👑. But it has some limits, obviously. People have talked about putting other kinds of info in the DNS, but right now, if you want to find a specific person and you know where she works, you have to mix the DNS with finger just to make a stab at finding her 🙈. The DNS also has very limited search capabilities. That lack of search alone shows we can't build a rich Directory Service on top of the DNS 💀.

---

3: THE X.500 MODEL OF DIRECTORY SERVICE ✨

X.500 is a CCITT protocol built to make a distributed, global directory 🌍. Here's what it brings to the table:

• Decentralized Maintenance: Each site running X.500 is responsible ONLY for its own local part of the Directory, so updates and maintenance can happen instantly ⚡.
• Powerful Searching Capabilities: X.500 has powerful search facilities that let users build arbitrarily complex queries 🔎.
• Single Global Namespace: Like the DNS, X.500 gives users one homogeneous namespace. Its namespace is more flexible and expandable than the DNS's 🎀.
• Structured Information Framework: X.500 defines the information framework used in the directory and allows local extensions 🧚.
• Standards-Based Directory: Since X.500 can be used to build a standards-based directory, apps that need directory info (e-mail, automated resource locators, special-purpose directory tools) can reach a planet's worth of information in a uniform way, no matter where they're based or running 🌈.

3.1 Acronym City, or How X.500 Works 🏙️

The '88 version of the X.500 standard talks about 3 models needed to build the X.500 Directory Service: the Directory Model, the Information Model, and the Security Model. We're going to give a quick rundown of the Directory and Information Models, enough to show off how much X.500 can do 💅.

3.1.1 The Information Model

To explain this, we'll first look at how information is held in the Directory, then what types of information can be held there, and then how that information is arranged so you can pull out the pieces you want 🧐.

3.1.1.1 Entries

The main construct holding info in the Directory is the "entry" 📇. Each Directory entry has info about one object, like a person, a computer network, or an organization. Every entry is built from a collection of "attributes", and each attribute holds a single piece of info about the object. For a person, some attributes might be "surname", "telephonenumber", "postaladdress", etc. Each attribute also has an "attribute syntax", which describes the kind of data it holds, like photo data, a time code, or a string of letters and numbers. Let's look at part of an entry for a person:

  Entry for John Smith contains:

    attribute ---> surName=              Smith  <--- attribute value
             |---> telephoneNumber=   999-9999  <--- attribute value
             |---> title=              Janitor  <--- attribute value
                                ...

The attribute syntax for surName would be CaseIgnoreString, which tells X.500 that surName can hold any string and case doesn't matter. The attribute syntax for telephoneNumber would be TelephoneNumber, which says it can hold a string made of digits, dashes, parentheses, and a plus sign ☎️. The title attribute would also use CaseIgnoreString. A good database analogy for all this: think of a Directory entry as a database record, an attribute as a field in that record, and an attribute syntax as the field type (decimal number, string) 💖.

3.1.1.2 Object Classes

Right now we have no way of knowing what type of object a given entry represents. X.500 handles that with the concept of an "object class", plus an attribute named "objectClass" that every entry contains to say which object class(es) it belongs to 🏷️.

Each object class has a definition listing the mandatory attributes, which must be present, and the optional attributes, which may be present, in an entry of that class. An object class A can be a subclass of another class B. When it is, A inherits all of B's mandatory and optional attributes on top of its own 🧬.

The object classes in X.500 are arranged hierarchically by inheritance. The diagram below shows part of that hierarchy:

                      _____________
                     |             | "top" has one mandatory
                     | top         | attribute "objectClass",
                     |_____________| and nooptional attributes.
                      |     |    |
                      |     |    | every other object class is a
      ________________|     |    | subclass of "top"...
      |                     |   ...
______|________        _____|_______
|               |     |               |"organization" inherits one
| country       |     | organization  |mandatory attribute from
|_______________|     |_______________|"top", "objectClass"; adds one
                                      more mandatory attribute "O"
 "country" inherits one                   (for organization), and has
 mandatory attribute from "top",          many optional attributes. Any
 "objectClass", adds one more             subclass of "organization"
 mandatory attribute "c" (for             would inherit all of the
 country), and has two optional           mandatory and optional
 attributes, "description" and            attributes from "organization"
 "searchGuide". Any subclass of           including the attribute which
 "country" would inherit all of the       "organization" inherited
 mandatory and optional attributes        from "top".
 of the "country" class, including
 the attribute which "country"
 inherited from "top".

Figure 1.

Here's the big perk of object classes: it's really easy to make a new one that's just a slight tweak or extension of an earlier class 🙌. Say I already defined an object class for "person" with a person's name, phone number, address, and fax number. I can make an "Internet person" object class by defining it as a subclass of "person" with one extra optional attribute, "e-mail address". Then all my "person" attributes come along automatically through inheritance. There are other benefits too, but they're beyond the scope of this paper 🦄.

3.1.1.3 X.500's namespace.

X.500 organizes the namespace hierarchically in the Directory Information Base (DIB). Remember, this hierarchical organization is called the Directory Information Tree (DIT) 🌳. Each DIB entry sits in a certain location in the DIT. An entry with no children is a leaf entry, and an entry with children is a non-leaf node. Each DIT entry contains one or more attributes that together make up its Relative Distinguished Name (RDN). The tree also has a "root" entry, which has no attributes (a special case) and forms the base node of the DIT. The Distinguished Name of a specific entry is the sequence of RDNs of the entries on the path from the root to that entry. A diagram will help make this click 🧩:

Level of DIT              Root            RDN      Distinguished Name

root                       *             nothing        { }
                         / | \
country (other          /  |  \
things at this         /   |   \         c=us         {c=us}
level)           c=gb    c=us    c=ca
                        /  |  \
                       /   |   \
                      /    |    \
organization      o=SRI  o=Merit  o=DEC  o=Merit      {c=us, o=Merit}
(other things           /  |   \
at this level)         /   |    \
                      /    |     \
Third level          cn=Chris Weider     cn=Chris Weider {c=us, o=Merit,
                                                        cn=Chris Weider}

Figure 2: Building a DN from RDNs (adapted from a diagram in the X.500 (88) Blue Book)

Each entry in this tree has more attributes than shown here, but for each entry only one attribute has been used for its RDN. As noted above, any entry in the tree could use more than one attribute to build its RDN. X.500 also lets you use alias names. That means the entry {c=us, o=Merit, cn=Chris Weider} could also be found through an alias entry like {c=us, o=SRI, ou=FOX Project, cn=Drone 1}, which points to the first entry 🪞✨.

3.1.2. The Directory Model 🗂️

Okay bestie, now that we've seen what kinds of info can live in the Directory, let's look at how it stores all of that and how a Directory user actually gets to it 💖. There are two pieces to this model. First, there's the Directory User Agent (DUA), which accesses the Directory on behalf of a user. Then there's the Directory System Agent (DSA), which you can think of as holding a particular subset of the DIB. The DSA can also serve as an access point to the Directory for a DUA ✨.

Now here's the wild part 🤯. The entire DIB is spread across the worldwide collection of DSAs that make up the Directory. To keep that spreading invisible to the user, the DSAs use two techniques called "chaining" and "referral" 🦋. Explaining those would take up another page, so here's the short version: to each user, it looks like the entire global directory is sitting right on her desktop 🖥️🎀. (Obviously, if the info you want is on the other side of the planet, the desktop directory might feel a teeny bit slow for that request 🙈.)

---

3.2. The functionality of X.500

So what can X.500 actually do? To break it down, we need to split X.500's evolution into three stages 🌈: 1) the 1988 standard, 2) X.500 as implemented in QUIPU, and 3) the (proposed) 1992 standard. We'll go through some features from the 1988 standard, check how QUIPU implemented them, and peek at where the 1992 standard is headed 🧚. QUIPU gets the spotlight because a) it's widely used in the U.S. and European Directory Services Pilot projects, and b) it works well 💜. If you want a survey of other X.500 implementations plus a catalogue of DUAs, check out [Lang].

3.2.1. Functionality in X.500 (88)

Just by being distributed instead of living on one machine, the X.500 Directory gets some seriously good perks 😍. Two big ones:

• An enormously large potential namespace. Since the Directory isn't limited to a single machine, many hundreds of machines can be used to store Directory entries.
• The ability to allow local administration of local data. An organization or group can run a local DSA to master their own information, which helps keep the data across the whole Directory super accurate 🎯.

The X.500(88) standard also comes with a bunch of built-in features:

• Advanced searching capabilities. The Directory supports arbitrarily complex searches at an attribute level. Because the object classes a specific entry belongs to are kept in the objectClass attribute, you can also search for specific types of objects 🔍. So you could search the c=US subtree for anyone with a last name beginning with S who also has either a fax number in the (313) area code or an e-mail address ending in umich.edu. This feature also helps provide the basic functionality for a Yellow Pages service 📒.
• A uniform namespace with local extensibility. The Directory provides a uniform namespace, but local specialized directories can also be implemented. Locally defined extensions can include new object classes, new attributes, and new attribute types 🧩.
• Security issues. The X.500 (88) standards define two types of security for Directory data: Simple Authentication (which uses passwords) and Strong Authentication (which uses cryptographic keys) 🔐. Simple authentication has been widely implemented, while strong authentication has been less widely implemented. Each of these authentication techniques is invoked when a user or process attempts a Directory operation through a DUA.

There are also loads of local perks on top of the global ones 🏫. You can use your local DSA for company or campus wide directory services. For example, the University of Michigan is providing all of its campus directory services through X.500. DUAs are available for a wide range of platforms, including X-Windows systems and Macintoshes 💻.

3.2.2. Functionality added by QUIPU.

QUIPU went beyond the X.500 (88) standard and added these features:

• Access control lists. An access control list is a way to provide security for each attribute of an entry. For example, each attribute in a given entry can be permitted for detect, compare, read, and modify permissions based on the reader's membership in various groups. So you could specify that some info in a given entry is public, some can be read only by members of the organization, and some can only be modified by the owner of the entry 🛡️.
• Replication. Replication provides a method where frequently accessed information from a DSA other than the local one can be kept by the local DSA on a "slave" basis. Updates to the "slave" data are provided automatically by QUIPU from the "master" data residing on the foreign DSA. This gives alternate access points to that data, and it can make searches and retrievals faster, since there's much less overhead in the form of network transport 🚀.

---

3.3. Current limitations of the X.500 standard and implementations.

As flexible and forward-looking as X.500 is, it definitely wasn't designed to solve everyone's needs for all time 😬. X.500 is not a general purpose database, and it's not a Data Base Management System (DBMS) either. X.500 defines no standards for output formats, and it definitely doesn't have a report generation capability. The technical mechanisms for the Directory to contain information about itself aren't in place yet. That means new attributes and new attribute types are distributed rather slowly, by hand 🐢.

Searches can be slow for two reasons 🐌: a) searches across a widely distributed part of the namespace (c=US, for example) have a delay that's partly caused by network transmission times. That delay can get worse when implementations cache the partial search returns until everyone has reported back. And b) some implementations are just slow at searching anyway, which is very sensitive to things like processor speed and available swap space. Another implementation "problem" is a tradeoff with security for the Directory 🔒. Most implementations have an administrative limit on the amount of information that can be returned for a specific search. For example, if a search returns 1000 hits, 20 of those might be displayed, with the rest lost. So a person doing a large search might have to run a bunch of small searches instead. This was implemented because an organization might want to make it hard to "troll" for the organization's entire database 🎣.

Also, there is at the moment no clear consensus on the ideal shape of the DIT, or on the ideal structure of the object tree. This can make it hard to add to the current corpus of X.500 work, and the number of RFCs on various aspects of the X.500 deployment is growing monthly 📈.

Despite this, X.500 is very good at what it was designed to do, i.e., to provide primary directory services and "resource location" for a wide band of types of information 💖.

3.4. Things to be added in X.500 (92).

The 1988 version of the X.500 standard proved to be quite sufficient to start building a Directory Service 🏗️. However, many of the new functions implemented in QUIPU were necessary for the Directory to function in a reasonable manner. X.500 (92) will include formalized and standardized versions of those advances, including:

• A formalized replication procedure.
• Enhanced searching capacities.
• Formalization of access control mechanisms, including access control lists.

Each of these will make the Directory richer, but you don't have to wait for them! You can become part of the Directory today! 🥳🎉

---

4: WHAT X.500 CAN DO FOR YOU TODAY 🌸

4.1. Current applications of X.500

X.500 is filling Directory Services needs in a huge number of countries 🌍. As a directory to locate people, it's provided in the U.S. as the White Pages Pilot Project, run by PSI. In Europe, it's under the PARADISE Project as a series of nation-wide pilots. It's also used by the FOX Project in the United States to provide WHOIS services for people and networks, and to provide directories of objects as disparate as NIC Profiles and a pilot K-12 Educators directory. It's also being investigated for its ability to provide resource location facilities and to provide source location for WAIS servers. Honestly, in almost every area where you could imagine needing a directory service (especially distributed ones), X.500 is either already providing those services or being expanded to provide them 🙌.

In particular, X.500 was envisioned by its creators as providing directory services for electronic mail, specifically for X.400. It's being used this way today at the University of Michigan. Everyone at the University has a unified mail address, e.g. Chris.Weider@umich.edu. An X.500 server then reroutes that mail to the appropriate user's real mail address in a transparent fashion 📬. Similarly, Sprint is using X.500 to administrate the address space for its internal X.400 mail systems.

Those of us working on X.500 feel that its strengths lie in providing directory services for people and objects, and in providing primary resource location for a large number of online services 💜. We think X.500 is a major component (though not the only one) of a global Yellow Pages service 📒. We'd also love to encourage each of you to join your national pilot projects. The more coverage we can get, the easier it'll be for you to find the people you need to contact 🫶.

5. For Further Information 📚

For further information, the authors recommend the following documents:

Weider, C., and J. Reynolds, "Executive Introduction to Directory Services Using the X.500 Protocol", FYI 13, RFC 1308, ANS, ISI, March 1992.

Lang, R., and R. Wright, Editors, "A Catalog of Available X.500 Implementations", FYI 11, RFC 1292, SRI International, Lawrence Berkeley Laboratory, January 1992.

Barker, P., and S. Hardcastle-Kille, "The COSINE and Internet X.500 Schema", RFC 1274, University College London, November 1991.

Hardcastle-Kille, S., "Replication Requirements to provide an Internet Directory using X.500", RFC 1275, University College London, November 1991.

Hardcastle-Kille, S., "Replication and Distributed Operations extensions to provide an Internet Directory using X.500", RFC 1276, University College London, November 1991.

Hardcastle-Kille, S., "Encoding Network Addresses to support operation over non-OSI lower layers", RFC 1277, University College London, November 1991.

Hardcastle-Kille, S., " A string encoding of Presentation Address", RFC 1278, University College London, November 1991.

Hardcastle-Kille, S., "X.500 and Domains", RFC 1279, University College London, November 1991.

6. Security Considerations 🔐

Security issues are discussed in section 3. Go read that section, because that's where the security talk lives 💀.

7. Authors' Addresses ✨

okay bestie, these are the three authors and how to reach them 💌 Chris, Joyce, and Sergio, all listed exactly as the document has them 🫶

Chris Weider
Advanced Network and Services, Inc.
2901 Hubbard G-1
Ann Arbor, MI 48105-2437

Phone (313) 663-2482
E-mail: weider@ans.net


Joyce K. Reynolds
Information Sciences Institute
University of Southern California
4676 Admirality Way
Marina del Rey, CA 90292

Phone: (310) 822-1511
EMail: jkrey@isi.edu


Sergio Heker
JvNCnet
Princeton University
6 von Neumann Hall
Princeton, NJ 08544

Phone: (609) 258-2400
Email: heker@nisc.jvnc.net