RFC 1943
Building an X.500 Directory Service in the US
Building an X.500 Directory Service in the US 🎀
Okay bestie, here's the title block first 💖
- Network Working Group 🌸
- Author: B. Jennings, Sandia National Laboratory
- RFC number: 1943
- Category: Informational
- Date: May 1996
- Obsoletes / Updates: The title block doesn't list anything this RFC obsoletes or updates.
Status of this Memo 📜
Okay, the boring-but-important bit. This memo gives info to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited, so share it with everyone 💅
Abstract ✨
So this doc lays out what you need to run an X.500 Directory Service in the United States. It came out of the Integrated Directory Services Working Group in the Internet Engineering Task Force, and the goal is an electronic White Pages Directory Service inside an organization in the US that also connects to a wide-area Directory infrastructure. It's giving infrastructure goals 🧚
Getting a White Pages Directory Service to work inside an organization takes teamwork between the technical, legal and data management folks. It also helps a LOT if higher management is really committed to taking part in a wide-area Directory Service 🫶
The recommendations here come from real experience taking part in the Internet White Pages project, so they're not just theory 🔥
Table of Contents 🗂️
1.0 Introduction 2
1.1 Purpose of this Document 2
1.2 Introduction to Directory Services 2
2.0 The X.500 Protocol 4
2.1 Introduction 4
2.2 Directory Model 4
2.3 Information Model 5
2.4 Benefits and Uses for X.500 Directory Service 6
2.5 Other Applications of X.500 7
3.0 Legal Issues 8
3.1 Introduction 8
3.2 Purpose of the Directory 8
3.3 User Rights 9
3.4 Data Integrity 9
3.5 Protection of the Data 10
3.6 Conclusions 10
4.0 Infrastructure 11
4.1 Introduction 11
4.2 A Well Maintained Infrastructure 11
4.3 DUA Interfaces for End Users 12
5.0 Datamanagement & Pilot Projects 13
5.1 Simple Internet White Pages Service 13
5.2 InterNIC 13
5.3 ESnet 14
6.0 Recommendations 14
6.1 General 14
6.2 Getting Started 14
6.3 Who are the Customers 14
6.4 What are the Contents of the Directory 15
6.5 What are the Rights of the Individuals 15
6.6 Data Integrity 16
6.7 Data Security 16
6.8 Data Administration 17
6.9 Conclusion 17
7.0 References 18
8.0 Glossary 19
9.0 Security Considerations 22
10.0 Author's Address 221.0 Introduction 🦋
1.1 Purpose of this Document 💭
This doc is for anyone planning to build a directory service for an organization in the US. It walks through the technical, legal, and organizational sides of a directory service, and it describes the different options for organizations that want to run an X.500 Directory service. It also shows those options with examples from current X.500 service providers ✨
1.2 Introduction to Directory Services 🌈
Okay so an electronic directory server is basically a process that hands out a list of information over electronic access. The content can vary, but it should be clearly defined by what the directory is for. Info about people, organizations, services, and network hardware are just a few examples of what a directory service can serve up 🍓 The whole vibe of X.500 is making the directory intuitive and as easy to use as calling directory assistance. X.500 is an international standard that the International Organization for Standardization (IS) and the ITU-T (formerly CCITT) ratified in 1988 [1] 🎀
The Directory is meant to be a global service made up of independently operated, distributed Directory Service Agents (DSAs). Together they provide info in the form of a White Pages Phone Directory 📖
Email really benefits from a global electronic White Pages, since network users can look up addressing info in a way that feels natural. Hunting down names and addresses by hand, especially electronic addresses, can eat up a huge chunk of time 😭 A White Pages directory service lets people find their communication partners in a user-friendly way, using things like common name, surname, and organization to run searches at different levels.
To make global communication over computer networks work efficiently, a global electronic White Pages service is absolutely essential 🫶 That kind of directory could also hold telephone and fax numbers, postal addresses, and platform type, which helps translate documents between users on different systems. An electronic White Pages can also be super useful for local stuff, like replacing paper directories or improving personnel administration. An electronic directory is way easier to produce and way more up to date than paper ones, which are often out of date the second they're printed 💀
The Internet White Pages Project gives lots of US companies a chance to pilot X.500 in their organizations. It works as a globally distributed directory service, so organizations from all kinds of industries can make themselves known on the Internet and give access to their staff as they want main character energy for sure 👑
Some organizations, like ESnet, agreed to manage directory info for other organizations. ESnet keeps data at their site for all the national laboratories. They help organizations define their directory information tree (DIT) structure, and they give free access to the X.500 Directory through Gopher, WWW, DUAs, whois and finger 🧚
The InterNIC is another directory services provider on the Internet. As of [June 1995], they hold X.500 directory data for 52 organizations, and they give free access to that data through X.500 DUA, E-Mail, whois, Gopher and WWW 💖
If you want the most current list of X.500 providers, check out RFC 1632 - Catalog of Available X.500 Implementations [2] 📚
2.0 The X.500 Protocol 🧠
2.1 Introduction 🌸
This chapter has the basic technical info an organization needs to start deploying an X.500 Directory Service. It gives a quick intro to the X.500 protocol and all the cool stuff X.500 can do 💅
2.2 The Directory Model 🗺️
The X.500 Directory Model is a distributed collection of independent systems that work together to provide a logical database of information for a global Directory Service. Directory info about a particular organization is kept locally in a Directory System Agent (DSA). That info is structured according to specified standards, and sticking to those standards is what makes the distributed model possible 🔥 One organization can keep info about other organizations, and an organization can also run on its own, separate from the global model, as a stand-alone system. DSAs that operate within the global model can swap info with other DSAs using the X.500 protocol 🫶
DSAs that are interconnected form the Directory Information Tree (DIT). The DIT is a virtual hierarchical data structure. An X.500 pilot using QUIPU software introduced the idea of a "root" DSA that represents the world. Below the root are "countries," and below the countries are "organizations." Organizations can then define "organizational units" and/or "people." This DIT is the structure behind the White Pages X.500 services 🌳
Each DSA provides info for the global directory. Directories can figure out which place in that hierarchy holds a certain part of the directory. Each directory manages info through a defined set of attributes, arranged in a structure called the Directory Information Base (DIB) 🧩
A DSA is accessed through a Directory User Agent (DUA). A DUA talks to the Directory by communicating with one or more DSAs as needed to answer a specific query. A DUA can be an IP protocol like whois or finger, or a fancier application that gives GUI access to the DSA. People can use a DSA directly, or a computer application can automate the access 🤖
2.3 The Information Model 🪞
On top of the Directory Model, the X.500 standard also defines the information model used in the Directory Service. All info in the Directory is stored in "entries," and each entry belongs to at least one "object class." In the White Pages application of X.500, the object classes are country, organization, organizational unit and person 💜
The object classes an entry belongs to define the attributes associated with that entry. Some attributes are mandatory and others are optional. System administrators can define their own attributes and register them with regulating authorities, who then make those attributes available on a large scale 🌈
Every entry has a Relative Distinguished Name (RDN), which uniquely identifies the entry. An RDN is made up of the DIT information and the actual entry 🎯
The Directory runs under a set of rules known as the Directory schema. The schema defines correct use of attributes and keeps things consistent across the whole global Directory Service 🙈
Under the White Pages object class "Person," there are three mandatory attributes:
objectClass commonName surNameThese attributes, together with the DIT structure above, define the RDN 💅
An example of an entry under Sandia National Laboratory is shown here:
@c=US@o=Sandia National Laboratory@ou=Employees@cn=Barbara JenningsLook at that entry, it's so organized 🌈✨
root
/ \
/ \
c=US c=CA
/ \
/ \
o=Sandia National o=ESnet
Laboratory
/ \
/ \
ou=Employees ou=Guests
/ \
/ \
cn=Barbara Jennings cn=Paul Brooksokay so look at this tree 🌳 it's the DIT example: root at the top, then c=US and c=CA. Under US you've got o=Sandia National Laboratory and o=ESnet, and Sandia splits into ou=Employees and ou=Guests, with cn=Barbara Jennings and cn=Paul Brooks at the bottom. It's giving org chart, bestie 💅
Every organization gets to pick the DIT layout that fits them best ✨ and honestly the DIT usually ends up looking a LOT like the org itself, which is so iconic. The naming rules are what shape the tree, and those rules are what make each element's unique Relative Distinguished Name (RDN) 🎀. The DIT can also depend on whether the DSA info is kept in a flat file or a database, so this part is important 👀 If you go with a flat file and the tree gets too complex or intricate, searching through it takes longer 💀 so plan your DIT carefully! For recommended schema stuff on DIT structuring, check out RFC1274 [3] 📚
2.4 Benefits and Uses for X.500 Directory Service 🌸
The X.500 Directory is built for independently run segments that can scale all the way up to global distribution 🌍 For local use, the perks are:
- the distributed setup means an organization may split up managing a bunch of DSAs between different people and still keep the overall structure together 🧩;
- the service is super robust, so it can feed info to a wide range of applications 🔥 Global projects have to stick to one specific DIT, but independent X.500 setups may define their own unique DITs, object classes and attributes based on what they actually need 🦋;
- X.500 is way better than paper directories 📖➡️💻 because you can update and modify stuff interactively. That means a company can keep the most current info around with less cost and effort 💸;
- since X.500 is electronic, other electronic apps may interact with it without any human intervention 🤖.
The perks for global use are:
- the distributed nature of X.500 is perfect for huge global apps like the White Pages Directory, and maintenance can be done in a distributed way 🌐;
- X.500 has great searching from any level in the DIT. Add "User Friendly Naming" and searches become super intuitive 🥰;
- there are DUA interfaces for the White Pages service for all types of workstations 💻. For an overview of X.500 software, reference RFC1632 ✨;
- X.500 is an international standard, and using one ensures interoperability across the whole worldwide base 🌏💜.
2.5 Other Applications of X.500 🧚
Besides the White Pages, X.500 can be used as a source for any kind of info that needs a distributed storage base 🗂️
The University of Michigan is literally using X.500 for electronic mail routing 📬 Any mail coming to the university domain, umich.edu; gets expanded out to a local address stored in the rfc822Mailbox attribute 💌 They also run a standard X.500 name server that does name lookups for over 200,000 names 🤯 and they use the Lightweight Directory Access Protocol (LDAP) [11].
An implementation of the X.500 Standard directory service has been built into the Open Software Foundation (OSF) Distributed Computing Environment (DCE) 🖥️ This piece, called the Global Directory Service (GDS), gives distributed application clients a place to find their application servers. When other clients ask, the GDS hands back the unique network address for a particular DCE resource. Since it's based on an international standard, GDS can offer access to resources among users and organizations worldwide 🌎 And this scalable service works in DCE environments of every size, from very small to very large 📈
Lookup services can be plugged into all sorts of apps 🔍 Cambridge University in Great Britain put the X.500 directory service into an employee locator app. Using badge sensors at strategic spots, the app can figure out where an employee is on campus, and as someone moves around, the sensors register their location in an X.500 Directory 👀 very main character energy.
Digital Signature Service (DSS) and Privacy Enhanced Mail (PEM) work on the principle of a directory key server, which generates and hands users "public" codes that match previously registered "private" codes 🔐 Only the recipient can decipher messages sent this way. The X.509 [4] standard for key certificates fits right into the structure of the X.500 Directory Service, no cap 💖
3.0 Legal Issues ⚖️
3.1 Introduction
Okay, so legally speaking, the United States doesn't have any specific rules yet for info provided through an electronic directory service 🙈 Lots of groups tied to the Internet noticed the privacy and data integrity issues and wrote up directives to address them. Two of the big areas they cover are the rights of people listed in the directory, and the responsibility admins have to guarantee that the data is correct 💅
Registries holding info about an individual are basically freely transferred and unregulated in the US, unless the data provider is an agency or a holder of sensitive info as defined by federal legislation. That can also differ for each state 🗺️ An agency is defined as any executive department, military department, Government corporation, Government controlled corporation, or other establishment in the executive branch of the Government (including the Executive Office of the President), or any independent regulatory agency. Sensitive data can be financial records, medical records, and certain legal documents. As mentioned, each state has its own legislation on sensitive or private data. Registered people have very little recourse to control their listed info, short of filing a lawsuit against the info provider 😭
If you're transferring data across country lines, it's important to remember that other countries may have their own laws regulating data 🌍 Before requesting list info from those countries, an administrator should review the applicable legislation and have some mechanism in place for how the data will be handled once it crosses the border 🛂 Policy Statements for some countries have been written up and are provided through Code of Conduct papers 📝
3.2 Purpose of the Directory 🎯
The operational intent, including the presentation data, the list registrants and the access rights, has to be clearly defined and stated. Right away this gives you the skeleton of the DIT, and eventually a statement like this may provide a basis that legally justifies the directory 💜
All data presented must be defined in the purpose 🧾 For example, say a directory is only for professional addressing info. An entry would include name, postal address, office telephone, facsimile number, electronic mail address and company name. Private address info, like a home address or home phone, would be prohibited, and so would any other info not directly related to addressing 🙅♀️
3.3 User Rights 🎀
The North American Directory Forum (NADF) published a document that lays out the User Bill of Rights [5] 📜 It defines an individual's rights when it comes to the public release of personal or private info. Among other things, the user has the right to be notified when their info gets included in a data registry, and the right to examine it and have incorrect info changed 🥹
This paper was written specifically for the North American Directory Forum, and it recommends complying with US or Canadian laws that regulate privacy and access info 🇺🇸🇨🇦
Even though current US legislation doesn't cover all the suggestions in this document, the controller of the data is responsible for respecting individuals' rights 🫶 These recommended rules can be seen as respect for the individual, and a considerate controller will follow these guidelines within any boundaries they're mandated to follow ✨
3.4 Data Integrity 🔎
An information provider is responsible for guaranteeing the data they make available to users 💅 A data source's integrity depends heavily on how accurate and timely its contents are. Interoperable data sources need to agree on these factors too. How well a provider can guarantee the validity of the data it presents reflects on how valid the provider is overall 😌 RFC 1355 [6] suggests that a data source publish accuracy statements describing the process the individual NIC will use to keep the database accurate 📋
In the European community, it's a legal requirement that the information provider guarantee accurate data 🇪🇺
The controller of the info needs to be certain of the primary source of the data 🕵️♀️ When possible, the controller should set up routines of random checks to validate the registry data for correctness 🎲
3.5 Data Security 🔐
A Directory Service with non-authenticated access from the Internet is really hard to protect from unauthorized use 😬 Each organization defines what counts as unauthorized use within its directory purpose statement. A typical misuse is when someone tries to duplicate the directory for unauthorized purposes 👀 Other security measures include Access Control Lists (ACLs), limits on the number of entries returned to a query, and time to search flags. Keep in mind that these controls affect the legitimate user just as much as the user they're meant to block 🚧
⚠️ An alternative that may help protect against misuse is to create and display an attribute with each entry stating non-approved usage. This feature also gives evidence of restricted use if a legal case is ever needed to stop unauthorized access.
Again, the responsibility falls on the data provider or the implementor of the directory service 🛡️ Astute programmers will create or use existing tools to protect against data destruction, falsification, and misuse 💪
3.6 Conclusions 👑
User Rights, Data Integrity and Protection of data shouldn't be treated as just a way to follow legal rulings. They should be the intention of a good data source 💖 A successful Directory Service has to understand the requirements of the people listed in it, as well as the requirements of the directory users 🫶
Generally speaking, at the very least, the following conditions should be observed 📝
- Define the purpose of the Directory.
- Initially inform all registrants of their inclusion in a Directory.
- Prevent the use of data beyond the stated purpose.
- Limit the attributes associated to an entry within boundaries of the purpose.
- Work towards a suitable level of security.
- Develop a mechanism to correct or remove faulty data or information that should not be in the Directory.
4.0 Infrastructure 🏗️
4.1 Introduction 🧱
okay so the White Pages Project, currently run by Performance Systems International (PSI), gives sites a reliable QUIPU infrastructure 🧚 if they want to run their own X.500 directory 💖 It started way back in 1989 as the NYSERNet White Pages Pilot Project, and it was the first production-quality field test of OSI technology running on top of the TCP/IP suite of protocols [7] ✨ bestie, that's iconic. This pilot X.500 Directory was basically a real-time testbed for all the administrative and usage issues that pop up 🔥 Today more than 30 countries take part in this globally distributed project, with over 1 million entries 🌍 The White Pages pilot is one of 37 other pilots working together to provide information in the Nameflow-PARADISE directory, which is a European project 🌈 slay
Initially the software was public domain, QUIPU X.500 [8] 💅 This "shareware" application, combined with the administrative services PSI provided free of charge, let a truly distributed X.500 Directory Service actually operate 🫶
Given the Internet rules of operation, the lack of US regulations, the suggestions of the North American Directory Forum and the Internet Engineering Task Force (IETF), the complications that come with multi-distributed data as a service can be overwhelming 😭 PSI took on that challenge to provide such a service, and it continues to ensure operations today 👑
4.2 A Well Maintained Infrastructure 🎀
This distributed information service is a cohesive effort from all of the participating organizations 🫶 The ISO Development Environment (ISODE) implementation of the OSI Directory gave everyone the attributes and uniformity to make that teamwork happen ✨
The primary DSA for the PSI Project is named Alpaca 🦙 It runs on a Sun Sparc 10 with 120 megabytes of memory, and this host is the Master for the DSAs of 117 organizations under c=US 👑 Alpaca has redundancy from two sources: Fruit Bat, operated by PSI, and Pied Tamarin, operated by the InterNIC. Slave updates are sent to this host every night from the individual DSAs 🌙
The data presentation is hierarchical and emulates the common white pages telephone book 📖 The info includes, at minimum, a common name, voice phone listing, and electronic mail addressing. Each entry has a uniqueness attached to it: the relative distinguished name, which is made up of the entire directory information tree. The DITs can vary slightly, but each one must contain an organization and a person 💜 How the directory is used and how the organization is actually structured both shape the overall DIT structure. Here's the list of commonly used attributes 👇
commonName physicalDeliveryOfficeName stateOrProvinceName
description photo streetAddress
userid postOfficeBox surname
favouriteDrink postalAddress telephoneNumber
title rfc822Mailbox facsimileTelephoneNumber4.3 DUA Interfaces for End Users 📱
There are a bunch of user interfaces on the market today that give Directory User Agent access to the X.500 Directory 🔍 Standard protocols such as fred, whois, whois++, and finger are used widely 🧚 Interfaces are also available through World-wide Web browsers and electronic mail 💌
Vendors providing DUAs include ISODE Consortium, NeXor, and Control Data Corporation ✨ These applications work together with the vendor-provided DSAs.
Historically, DUA interfaces were hard to implement and needed the entire OSI stack 😩 Putting one of these on a PC or Apple platform took skillful programming, and the executables for those platforms were usually very large 💀 The IETF has since defined and standardized the Lightweight Directory Access Protocol (LDAP) [11] 🌸 It's a protocol for accessing on-line Directory services that offers comparable functionality to the Directory Access Protocol (DAP). It runs directly over TCP and is used by nearly all X.500 clients. LDAP doesn't have the overhead of the various OSI layers, and it runs on top of TCP/IP ✨ no notes
The functionality varies by specific DUA 🎀 Each one offers access to the X.500 Directory. Most offer the ability to make modifications to entries, and there are a few that offer Kerberos authentication 🔐
More info on LDAP clients for specific platforms is on the University of Michigan WWW server: http://www.umich.edu/~rsug/ldap.
Another interface that has been tested and recommended for users by our Dutch (Surfnet) colleagues is Directory Enquiry (DE) 💜 It was originally developed by University College London for the Paradise project in Europe, and the engineers at Surfnet selected DE as the best interface for "dumb" terminals 🖥️ They also translated the interface into Dutch for their local users [12] 🧡
Ideally, users should be able to reach X.500 directly from their electronic mail applications 📬 Vendors (other than the ones mentioned above) have been slow to bring the X.500 Standards into their electronic mail applications 🐢
5.0 Datamanagement & Pilot Projects 🦋
5.1 Simple Internet White Pages Service 📇
A wide variety of directory service retrieval protocols has popped up since the original Internet White Pages started in 1989 🕰️ To make sure decentralized implementations can interoperate with other providers, the IETF Integrated Directory Services Working Group is working on a draft that focuses on the common information and operational modeling issues that all Internet White Pages Services (IWPS) must conform to 🧠
Utilizing current information servers, the conceptual model covers naming, schema, and query and response issues for a narrowly defined subset of directory services 💡 The goal is to establish a simple set of information objects, paired with a basic set of process requirements, that will form a basis which can lead to ubiquitous IWPS 🌈 With that goal in mind, it will be easier to provide a consistent User view of the various directory services 👀
5.2 InterNIC 🌐
The InterNIC [9] is a collaborative project of two organizations working together to offer the Internet community a full scope of network information services 🤝 Established in January 1993 by the National Science Foundation, the InterNIC provides registration services and directory and database services to the Internet.
(Internet a global network of more than 13,000 computers networks, connecting over 1.7 million computers and used by an estimated 13 million people.)
In keeping up with the exponential growth of the Internet, the InterNIC provides a guide to navigate the maze of available resources 🗺️
InterNIC provides two types of services: directory and database services, and registration services 📋 AT&T provides the directory and database services, acting as the pointer to numerous resources on the network offering X.500 to help users easily locate other users and organizations on the Internet 🧭
5.3 ESnet ⚡
The Energy Sciences Network [10] is a nationwide computer data communications network whose primary purpose is to support multiple program, open scientific research 🔬 As part of this support, ESnet offers networking services including information access and retrieval, directory services, group communications series, remote file access services, and infrastructure services 📡 As an early member of the White-Pages Pilot Project, ESnet continues to be part of the worldwide distributed directory service based on the ISO/OSI X.500 standard 🫧 There are over nineteen ESnet organizations represented in the directory, comprising over 120,000 entries, and ESnet provides access to seven other sites via the X.500 DSAs 💜
6.0 Recommendations 📝
6.1 General 🧁
The X.500 Directory technology is available through several options 💼 Vendors can provide consultation for schema design, as well as supply, install, and support the software that performs the required operations. For smaller organizations, or companies that don't want to administer their own DSA, there are providers who will maintain the DSAs remotely and provide this service to the Internet 🛠️ Those with network and management expertise can either operate independently or join one of several white pages directory projects. Careful consideration must be given to the initial investment and the required maintenance process 💰
6.2 Getting Started 🚀
Successful initialization of a directory service requires a systematic approach 🗂️ The complexity of offering this type of service becomes more apparent as implementation progresses 😅 Several aspects must be considered as this service becomes a cooperative effort among the technical, administrative, organizational, and legal disciplines. Procedures must be defined and agreed to at the initial phase of implementing an X.500 Directory service [13]. The following are issues that should be addressed in these procedures 📌
6.3 Who are the Customers? 🛍️
Defining the customer and the customer requirements will determine the scope of service to offer 🎯 What is the primary purpose for the directory service? A company may find it desirable to do away with a paper directory while simultaneously providing the current directory information. The directory may be for internal use only or expanded to any users with Internet access. Will the customer use the directory for e-mail address only, or is other locational information such as postal address and telephone number a requirement? 📮
The directory may provide information to electronic customers, such as distributed computing applications, as well 🤖 In this case, the data must be provided in machine readable format 💻
Will the customers extend across country boundaries? 🌏 Information may be considered private by one country and not by another. It is necessary to be aware of the legalities and restrictions for the locality using the data.
Some countries have published a Code of Conduct with the IETF, explicitly stating the legal restrictions on directory and list data. Check the archives to determine if the country with whom information will be shared has presented such information. 👀
6.4 What are the contents of the Directory? 📇
The information presented in the directory is tightly coupled with the purpose 🎯 If the purpose is to provide addressing information for individuals, then customary information would include: Name, address, phone, e-mail address, facsimile number, pager, etc. If the use of the directory is to facilitate electronic mail routing, then the destination mail address needs to be included for each user. No other information should be presented in the directory if it is not directly related to the purpose 🙅♀️
If the directory is internal only, it may be desirable to include the registrant's title as well. Remember that information available on the Internet is generally open to anyone who wants to access it 👀 Individuals wishing to target a specific market may access directories to create customer mailing lists 📬
The structure or schema of the X.500 Directory must be an initial consideration 🧩 Will the hierarchy follow the company structure, or is a different approach more practical? How many entries will there be in the directory: five or 50,000? A complex hierarchy for thousands of users may affect the efficiency of queries 🐌
6.5 What are the rights of the individuals? ⚖️
The directory's subjects shall have well defined rights, bestie 💅 Those rights might come from company policy, legal restrictions, and what the directory is ultimately used for. For a basic Internet White Pages Service, those rights may include:
- the option of inclusion in the directory
- the right of access to the information
- the right to have inaccurate entries corrected
An employee's terms and conditions may affect these rights 🎀 Joining any organization means you inevitably agree to give up some personal privacy and accept certain restrictions 🙈
Every organization should develop and publish the "rights" that list registrants can expect 📜✨
6.6. Data Integrity 🧩
The info that goes in the directory can come from all kinds of places 🍓 Demographic details may come from the human resources department, and email addresses may come from the computer network department. To guarantee data integrity, it is advised that the data be identified and maintained as corporate information 🫶
How fresh the data needs to be is different for each DSA 🦋 Updates might be needed as often as once a day or as rarely as once a month, but updates must be provided on a regular basis. If the data is time sensitive, include an attribute that shows the most recent maintenance date ⏰
A regular check for data accuracy should be part of the directory administration 💖 Faulty information may put an organization in breach of data protection laws and possibly make the company look unreliable 😭
6.7. Data Security 🔐
Securing networked information resources is inherently complex 🌈 Attempts must be made to preserve the security of the data. That can include access control lists (ACLs), limiting the number of responses allowed to queries, or controlling internal and external access to the directory 👑
The 1993 recommendations added a complex access control model that is designed to tightly restrict what users can access in the Directory 🔒 Local protection is configured by the implementor. A secure X.500 Directory should provide tools to protect against destruction, falsification, and loss of data ✨
There is not a tool yet that protects against the misuse of data 💀
There are flags and limits that can be set from within the application, and they act somewhat as a barrier against unwanted use. The catch is that any restrictions will also affect legitimate users 🥺 One suggestion is to post a notice of illegitimate use within each entry. That only serves as a deterrent, and as an asset should legal action be required 📝
Again, caution must be taken when data moves across country and state borders. In the US, data regulations differ from state to state 🗺️
6.8. Data Administration 🗂️
The X.500 Directory service is decentralized, so each organization has complete control over its data 🏰 As part of a global service, though, the operation of the DSA must be monitored and maintained in a consistent manner 🔍 Authorization must be given to the local manager of the information, and in some cases, the subjects in the directory may also have modification privileges 🙌
Once the service is running, guaranteed operation cannot be overstated 🚨 Maintaining the local Directory will be an integral part of normal administrative procedures within the organization, and it must be defined and agreed upon in the initial stages of development 📋
6.9. Conclusion 🎀
Setting up a Directory service within an organization takes a great deal of cooperative effort 🤝 It is essential to get commitment from the integral parties of the organization at the start. That includes the technical, legal, and data management components 💜 Executive level commitment makes it much easier to get the cooperation needed ⭐
Operational procedures must be clearly defined, because inclusion in a globally distributed service has wide visibility 🌍 Adherence to these procedures must be maintained to the highest degree possible. Misinformation may result in unintentional legal violations, and unreliable access or data can adversely affect a company's reputation 😬
An X.500 Directory can be extremely useful for an organization if it operates as designed 🧚 It may serve as the "hub" of information routing and the basis for several everyday activities. A successful service will be one of the most important communication tools in the computer network environment 🔥 For people to make use of the service, they must be able to rely on consistent and accurate information 💅✨
References 📚
- CCITT Blue Book, Volume VIII - Fascicle VIII.8, November 1988.
- RFC 1632; A Revised Catalog of Available X.500 Implementations. A. Getchell; ESnet, S. Sataluri; AT&T.
- RFC 1274; The COSINE and Internet X.500 Schema. P. Barker & S. Kille.
- CCITT Blue Book, Volume VIII - Fascicle VIII - Rec. X.509, November 1988.
- RFC 1295; User Bill of Rights for entries and listing in the Public Directory. Networking Working Group; IETF, January 1992.
- STD 35, RFC 1355; Privacy and Accuracy Issues in Network Information Center Databases. Curran, Marine, August 1992.
- RFC 1006, ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC 1006 extension. Y. Pouffary, June 1995.
- Colin Robbins, NEXOR Ltd., Nottingham, London. c.robbins@nexor.co.uk
- InterNIC; Collaborative effort of AT&T and Network Solutions; info@internic.net
- ESnet; Managed and funded by the US Department of Energys Energy Research Office in Scientific Computing (DOE/ER/OSC).
- RFC 1777; Lightweight Directory Access Protocol, W. Yeong, T. Howes, S. Kille, March 1995.
- Building a Directory Service, Final Report test phase SURFnet X.500 pilot project, June 1995.
- The X.500 Directory Services: a discussion of the concerns raised by the existence of a global Directory, Julia M. Hill, Vol.2/No.1 Electronic Networking, Spring 1992.
- Directory Services and Privacy Issues, E. Jeunik and E. Huizer.
- The Little Black Book; Mail Bonding with OSI Directory Services, Marshall T. Rose, Simon & Schuster Company, 1992.
- NYSERNet White Pages Pilot Project: Status Report; NYSERNet Technical Report #89-12-31-1, Marshall T. Rose, December 1989.
- RFC 1798, Connection-less Lightweight Directory Access Protocol, A. Young, June 1995.
- RFC 1781; Using the OSI Directory to Achieve User Friendly Naming, S. Kille, March 1995.
- draft-ietf-pds-iwps-design-spec-01.txt, Tony Genovese; Microsoft, Work in Progress, July 1995.
- draft-ietf-ids-privacy-00.txt, B. Jennings; Sandia National Laboratories, S. Sataluri; AT&T, Work in Progress, November 1994.
Glossary ✨
okay bestie, the glossary is basically your X.500 and friends cheat sheet 📚 every term gets its own little definition, so let's go 💅
- ACL: Access Control List 🔐 a mechanism to restrict access to data stored in an X.500 Directory Service. no cap, this is the bouncer of the directory 🚪
- Attribute: a collection of attributes that belongs to an entry in the Directory Service, and holds information about that entry 🧾
c=: countryName 🌍 an object class definition that specifies a country. when it's used as part of the directory name, it tells you which country the named object is physically located in. it's giving geography class 🗺️cn=: commonName 🪪 an attribute that defines the common name for individuals in a directory. in 1988 standards it can be up to 64 characters, so pls don't write a novel 📖💀- CCITT: The International Telegraph and Telephone Consultative Committee 📡
- DAP: Directory Access Protocol 🤝 the protocol between a DUA and a DSA, iconic duo 👯♀️
- DIB: Directory Information Base 🗃️ a collection of information objects in the Directory
- DIT: Directory Information Tree 🌳 the hierarchy of the distributed database that makes up an X.500 service. literally a family tree for data 🧬
- DSA: Directory System Agent 🏛️ an application that offers the Directory service. this is the database for the Directory, the main character of the whole show 👑
- DUA: Directory User Agent 🙋♀️ an application that facilitates User access to a DSA
- E-Mail: Electronic Mail 💌
- Entry: a Directory Service contains entries on people, organizations, countries, etc. entries belong to a certain class, and the info on entries is stored in attributes 🎀
- ESnet: Energy Sciences Network 🔌 a nationwide computer data communications network
- GUI: Graphical User Interface 🖱️✨
- IETF: Internet Engineering Task Force 🌐 an internationally represented task force charged with solving the short-term needs of the Internet 🦋
- Internet: a collection of connected networks, international, running the Internet suite of protocols 🌈
- InterNIC: Directory of Directories 📒 a collaborative project between AT&T and Network Solutions, Inc. the directory-of-directories energy is immaculate 🫶
- IP: Internet Protocol 📦 the network protocol offering a conectionless-mode network service in the Internet suite of protocols. it just sends the packets and vibes 🕊️
- ISODE: ISO Development Environment 🧪 a research tool developed to study the upper layers of OSI and to deploy network applications according to the ISO OSI standards and ITU X series of recommendations. science experiment era 🔬
- ITU: International Telecommunication Union 🏢 formerly the CCITT, so it's basically the glow-up version 💖
- LDAP: Lightweight Directory Access Protocol 🪶 an Internet Standard for a lightweight version of DAP running over TCP/IP. the slimmed down, more chill sibling 🧚
- Object Class: entries in a Directory Service belong to an Object Class to indicate their type and characteristics, e.g. Object Class "person" 🧍♀️
- OSI: Open Standards Interconnection 🤓 an international standardization program, facilitated by ISO and ITU to develop standards for data networking
o=: organization 🏢 an attribute defining the company or organization that the person works forou=: organizational unit 🗂️ an attribute found under organization. it denotes the department, division, or other such sub-unit of the organization that the person works in. main character of the org chart 💼- PEM: Privacy Enhanced Mail 🔏 an Internet Standard for sending secure Electronic mail. secure texting but make it official 🔒
- PSI: Performance Systems International, Inc. 🛰️ operator of the Internet White Pages Project
- QUIPU: X.500 Directory implementation developed by Colin Robbins while at the University College of London 🧶 the implementation with the cutest name 🥹
- RDN: Relative Distinguished Name 🏷️ a unique identifier for each list subject, defined by the hierarchy of the DSA
- RFC: Request For Comments 📝 Internet series publications. yes, this is the series we're reading right now, iykyk 🫣
sn=: surname 💫 an attribute defining the surname of the person in the directory- TCP/IP: Transmission Control Protocol and Internet Protocol 🧵 two internet protocols, the dynamic duo of the internet 👯
- White-Pages: electronic directory, accessible via the Internet suite of protocols 📇
- Whois: an Internet standard protocol 🔎
- Whois++: an Internet Directory Services protocol 🕵️♀️ a possible alternative for X.500 WPS
- White Pages Service: a Directory Service that contains information on people and organizations 📖🌸
- X.500: a series of recommendations as defined by the ITU that specify a Directory Services protocol 🧠 the big boss of this whole topic 👑
9.0 Security Considerations 🔐
okay so this part is short but it's SUPER important, so listen up 🫵
Security issues are not discussed in this memo. 😬 no security stuff is covered here, so don't go looking for it in this doc and assume you're safe, bestie 🙈
Author's Address 🎀
Barbara Jennings
Sandia National Laboratories
Scientific Computing Systems
P.O. Box 5800
M/S 0807
Albuquerque, NM 87106
USA
Phone: 505-845-8554
Fax: 505-844-2067
EMail: jennings@sandia.govand that's the whole doc, bestie 🦋✨ thanks for reading with me 🫶💖
📦 where this page comes from
- ietf: rfc1943 1996-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms