RFC 1430

A Strategic Plan for Deploying an Internet X.500 Directory Service

📅 published February 1993, from ietf

A Strategic Plan for Deploying an Internet X.500 Directory Service 🎀

Okay bestie, this one is RFC 1430 💖 from the Network Working Group, dated February 1993. Here's the title block tea ☕

  • Authors: S. Hardcastle-Kille (ISODE Consortium), E. Huizer (SURFnet bv), V. Cerf (Corporation for National Research Initiatives), R. Hobby (University of California, Davis), and S. Kent (Bolt, Beranek and Newman) 👑
  • Category: it provides information for the Internet community and does not specify an Internet standard 🧚
  • Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🙈

Status of this Memo 📜

This memo provides information for the Internet community, and it does not specify an Internet standard. Distribution of this memo is unlimited 🌸

Abstract ✨

There are a bunch of reasons why a new Internet Directory Service is needed, and this doc lays out an overall strategy for deploying a Directory Service on the Internet, based on the OSI X.500 Directory Service 🦋 It then gets into more detail about the first steps that need to be taken to hit these goals, and how work already being done by Internet Engineering Task Force Working Groups (IETF WGs) is moving toward the same goals 💅

Table of Contents 🗂️

   1.    REQUIREMENTS                                                  2
   2.    SUMMARY OF SOLUTION                                           3
   3.    INFORMATION FRAMEWORK                                         3
   3.1   The Technical Model                                           3
   3.2   Extending the Technical Model                                 4
   3.3   The Operational Model                                         5
   4.    NAME ASSIGNMENT                                               5
   5.    DIRECTORY INFRASTRUCTURE                                      6
   5.1   Short Term Requirements                                       7
   5.2   Medium Term Requirements                                      9
   5.3   Long Term Requirements                                        9
   6.    DATAMANAGEMENT                                                9
   6.1   Legal Issues                                                 10
   7.    TECHNICAL ISSUES                                             10
   7.1   Schema                                                       11
   7.2   Use on the Internet                                          11
   7.3   Replication of Knowledge and Data                            12
   7.4   Presentation of Directory Names                              13
   7.5   DSA Naming and MD Structure                                  13
   8.    SECURITY                                                     13
   8.1   Directory Provision of Authentication                        14
   8.2   Directory Security                                           15
   9.    RELATION TO DNS                                              16
   10.   EXTERNAL CONNECTIONS                                         16
   11.   REFERENCES                                                   17
   12.   Security Considerations                                      19
   13.   Authors' Addresses                                           20

1. REQUIREMENTS 💖

There is serious interest in setting up a new Directory Service on the Internet 👀 In the short term, people are pushing for two new services:

  • White Pages lookup of users 📇
  • Support for X.509 Authentication for a range of applications, especially Privacy Enhanced mail [Lin89] 🔐

In the medium term, there are likely to be lots of requirements for Directory Services, including:

  • General resource lookup, for info ranging from committee structures to bibliographic data 📚
  • Support for managing the Internet infrastructure, and folding configuration info into the higher level directory 🛠️
  • Support for applications on the Internet. For example:
    • Electronic distribution lists 💌
    • Capability info on advanced user agents 🤖
    • Location of files and archive services 🗄️
  • Support for Mail Handling Systems, whether they're RFC-822 based or X.400 based (IETF MHS-DS WG), e.g.:
    • Support for routing 🛣️
    • Info on user agent capabilities, which is essential for using Multimedia mail like MIME (Multipurpose Internet Mail Extensions) 🎶

For the longer term, more sophisticated uses of X.500 are possible, stretching it into a useful and fast yellow pages service 🧡

2. SUMMARY OF SOLUTION 🌈

In principle, the current Internet Domain Name System (DNS) could handle many of these functions, with the right extensions 🤔 However, it's suggested that a higher level of directory service is needed. The plan is to set up an Internet Directory Service based on X.500, which gives the functionality these services need and leaves room for future extension 🦄 That extension could happen by tracking the evolution of the OSI Standard, by work specific to the Internet, or, most likely, a mix of both 🫶

By deploying X.500 in some form on the Internet, we can build a truly global and universal Directory Service that gives Internet users fast access to all kinds of data 🌍 The X.500 Directory Service here could be anything from a simple white pages service (info on people and services) to coupling various existing databases and information repositories in a universal way 🧩

Right now, several different but cooperating X.500 Directory Services pilots are running on the Internet, and they form an important base for experimenting with this new service 🧪 Starting with these pilots, the X.500 products hitting the market today, and sufficient funding for the central services described in this paper, an operational X.500 Directory Service can be deployed 🚀

The final goal of this strategy is to deploy a fully operational Directory Service on the Internet, providing the functions mentioned in the previous section 🏁✨

3. INFORMATION FRAMEWORK 🧠

The most critical part of the Directory Service is establishing an Internet Information Framework 🎯 Building a sophisticated distributed directory with a coherent information framework takes a lot of effort to map data onto that framework. This is operational work, and it far outweighs the technical effort of setting up servers and user agents 😭

3.1. The Technical Model 💜

By choosing the X.500 model as the basis for the information framework, the Internet gets to be part of a (future) global information framework 🌐 The key aspects of this model are:

  • A hierarchical navigational system that couples distributed databases (of various kinds), which lets the organization or person responsible for the data manage it 🗝️
  • Each object in this information structure (called the Directory Information Tree, DIT) is represented as an entry 🌳
  • Objects are typed by an "object class", which permits multiple inheritance 🧬
  • An object is described by a set of attributes 🏷️
  • Each attribute is typed, and attribute types are hierarchical 📐
  • Each attribute type has an associated attribute syntax, which may be generic or shared with other attributes (e.g., Integer Syntax; Distinguished name Syntax). This allows for simple attributes (e.g., strings or bitmaps) or complex ones with detailed structures 🎀
  • Each entry has an unambiguous and unique global name 💎
  • Alternate hierarchies can be built by using aliases or pointers of distinguished name syntax 🪞

This framework can represent basic objects like users within organizations, and it's also super extensible, so it works for a whole range of other applications 🌸

3.2. Extending the Technical Model 🦋

In the longer term, the model could be extended to handle a number of other requirements that an Internet Directory Service could potentially need to meet 👀 Possible extensions include:

  • Support for ordered attributes (needed by some applications, such as message storage) 📬
  • Extensions that unify it with management information associated with SNMP (Simple Network Management Protocol) [CFSD90] or other management protocols 🔧
  • Handling non-hierarchical data better for searching and retrieval, while still keeping the basic hierarchy for management purposes. This is basically building a general purpose resource location service on top of the basic infrastructure 🔍 It'll need work on the information model, not just the access protocols 🧠

It's worth noting that although X.500 may not be the ultimate solution for information retrieval, it has great potential for solving a lot of information service problems 💅

3.3. The Operational Model 🏗️

Making the Directory Service with a coherent information framework truly operational takes a lot of effort 😮‍💨 The most likely operational model is one where larger organizations on the Internet maintain their part of the DIT on their own DSA (Directory System Agent). Smaller organizations will "rent" DSA space from regional networks or other service providers 🏠 Together these DSAs will form the Internet Directory Service Infrastructure 🌈 To couple the various parts of the DIT that live on these Internet DSAs, a special DSA holding the Root for the naming hierarchy within the DIT has to be set up and maintained 👑

The following tasks can be foreseen:

  • Defining the naming hierarchy; See section 4. 🗺️
  • Creating the Directory Infrastructure; See section 5. 🧱
  • Getting the Data into the directory; and 📥
  • Managing the data in the Directory. See section 6. 🫧

4. NAME ASSIGNMENT ✨

Okay so before we can deploy the Internet Directory Service, we need to figure out how the naming hierarchy is going to be structured 💅. The basic model is a simple monolithic "database" holding all of the Internet's information infrastructure, with the namespace split along geographic boundaries. But this may not be the definite model that ends up being the most appropriate for the Internet 🦋. Different models may evolve depending on the needs of the Internet and the applications used on it (like, some parts of the DIT may be assigned at the root for the Internet). Below that, you can envision several loosely coupled namespaces, each with their own area of applicability 🌈. This should be handled as a part of the general operation of a directory service. An example would be assigning a representation of the Domain Namespace under the root of the DIT. This is further discussed in [BHK91a].

However, the core DIT information will be nationally assigned 🇺🇳. The parts of the DIT below country level will be managed differently in each country. In many countries, registration authorities will be set up according to the OSI Standard [ISO]. In some countries, this has been done by the national ISO member body representative (for example, in the UK by BSI) 💖.

The lower parts of the hierarchy will generally be delegated to organizations that control Name Assignment in that part of the tree 🌸. There's no reason to mandate how this hierarchy gets assigned, although it's appropriate to give guidelines. Proposed solutions for assigning namespace are given in [BHK92].

In North America, there's an alternative approach being developed by the North American Directory Forum (NADF), which leverages existing registration mechanisms [For91] 🍓. It's not yet clear what form a final North American Directory Service will take. Similar initiatives are expected in other places, such as Europe. For the Internet, the Internet Society (ISOC) has been suggested as a possible Naming Authority 👑.

A discussion of the main issues involved in representing the Real World in the Directory Service is part of the work undertaken by the IETF OSI DS Working Group 🧚.

So the core of the Internet Directory will come to be a country-based structure, with different national naming schemes below the countries 🌍. It's clearly desirable that the Internet Directory Service follows any evolving national and international hierarchies. However, this should not be allowed to cause undue delay ⏰. The strategy proposed is to proceed with name assignment as needed, establish interim registration authorities where necessary, and take practical steps to align with emerging national authorities wherever possible 🫶.

It is suggested that the Internet Directory Service does two things:

First, each national part of the Internet DIT namespace should be delegated to an appropriate organization, which will usually be in the country in question. Second, the delegated organization should assign names for that country as part of the Internet Directory Service. This should be done in a manner that is appropriately aligned with any emerging local or national service, but does not unduly delay the deployment of the Internet Directory Service 💅. For most countries, this will be a natural evolution of the early directory piloting, where operators of pilots have acted as interim name registration authorities 🎀.

5. DIRECTORY INFRASTRUCTURE ✨

To provide access to the Internet Directory Service, an infrastructure has to be built 🏗️. The technical components of an X.500 infrastructure are clear: DSAs (that hold the actual data) and DUAs (that allow users and applications to access the data). But a lot more is needed to deploy an Internet Directory Service, ngl 😭.

The Integrated Directory Services (IDS) Working Group of the IETF is playing a key role in solving most of the issues related to building an appropriate infrastructure 👑.

Many of the issues cited in this section have come up out of interim pilots that have been established on the Internet 🦋:

PSI White Pages Pilot 🌸 This is a pilot service that is operating X.500 on the Internet. In many ways, it's operating as an Internet-wide pilot.

FOX 💜 Fielding Operational X.500, a project to explore the development and interoperability of X.500 implementations.

Paradise (Piloting A ReseArch DIrectory Service in Europe) 🧚 This project has been providing the necessary glue to hold the various national activities together [Par91].

5.1. Short Term Requirements

  • Central Operations. There is a need for a number of operations to be managed as a service for the whole Internet. These services are:
    • A root DSA; containing the top-level of the DIT, has to be provided. Currently, this root DSA is managed by the Paradise project. 👑
    • Name assignment; Inserting names into the Directory, this has been discussed in section 4. This could be done in conjunction with the appropriate Registration Authority or by the Registration Authority. In most cases it is likely to be the former, and mechanisms will need to be set up to allow organizations to get their names installed into the directory, either directly or through the registration authority 📝.
    • Knowledge management; i.e., the information on "which DSA holds what part of the DIT, and how can that DSA be accessed". DSAs will be established by Organizations. There will be a need to centrally coordinate the management of the knowledge information associated with these DSAs. This is likely to be coupled to the name assignment 🔗.
    • Knowledge and Data replication; For the Directory to perform well, knowledge and data high up in the DIT must be significantly replicated. A service must be provided to make replicated information available to DSAs that need it 🍓.

It is suggested that for the time being, Paradise should be used as the initial basis for handling the top-level of the DIT and for providing the central services. However, the services mentioned above need to be provided at a national level for every participating country in the Internet Directory Service. Whenever an organization starts a new country branch of the DIT in the Internet Directory Service, the central operations will have to help out to make sure these services are properly installed at a national level 🫶.

  • An effective service will need sufficient implementations, in order to give full coverage across different hardware and software platforms, and to demonstrate openness. The recent Directory Information Services (pilot) Infrastructure Working Group's (DISI) Survey of Directory Implementations suggests there won't be a problem here. It provides a list of available X.500 implementations and their capabilities [LW91] ✨.
  • An executive summary, necessary to convince the management of computer centers to invest manpower in setting up an X.500 Directory Service. This is provided by DISI [WR92] 💼.
  • Due to the possibly different and fairly independent structured namespaces that can be envisaged in the DIT for different purposes, DUAs will have to be "tuned intelligently" for the applications they are used for 🎯.
  • To give users easy access to the Internet Directory Service, even from low-powered workstations, a lightweight protocol has to be developed over TCP/IP 🦋. Two private protocols that do this have already been developed: the Michigan DIXIE protocol [HSB91] and the PSI Directory Assistance Service [Ros91]. The IETF OSI Directory Services Working Group (OSI-DS WG) is currently working on a standard lightweight protocol called LDAP 🌈.
  • Although the Internet Directory Service does not have to make any mandatory requirements about the use of lower layers, it is noted that the use of STD 35, RFC 1006 to allow use of OSI applications on top of TCP/IP is essential for deployment in the Internet. Other stacks, like the ones using CLNS, CONS and X.25(80), will probably also be deployed in parts of the Internet. DSAs with different stacks will be linked through either application level relays (chaining) or Transport Service bridges 🧩.
  • There are multiple issues that are not dealt with (properly) in the X.500 standard, and thus prevent the building of an Internet Directory Service. Intermediate solutions for these issues have to be established in an "open" way. The results will have to be deployed, as well as fed back into the relevant standard committees. The IETF OSI-DS WG deals with these issues. Section 7 describes several of these issues 🤓.
  • Site support. The IETF IDS WG is looking at providing the necessary documentation to help with the provision of support for Directory users at participating sites 📚.

5.2. Medium Term Requirements

  • Enhanced performance is necessary to allow for real global usage 🚀.
  • The schema has to be extended to allow for various kinds of data, e.g.,:
    • NIC data;
    • Resource location;
  • Support for Internet Message Handling services (RFC-822, MIME and X.400). This work is already undertaken by the IETF MHS-DS WG 💌.

5.3. Long Term Requirements

  • To make sure X.500 evolves into an operational service, it is essential to track its evolution and feed back into the evolution process 🔮.
  • Interface existing RDBMS into the Directory Service 🗄️.
  • To increase the performance of the directory, and thereby make it useful for an even wider range of applications (e.g., policy based routing), a lightweight protocol for access and system usage is needed 💖.

6. DATAMANAGEMENT ✨

okay bestie, the whole Directory Infrastructure is giving "cute but doomed" if there's no proper datamanagement for the data sitting in the DIT 💀 so procedures need to be set up to make sure there's a certain Level of Quality for all of it 🫶

because of how X.500 is built, the management of the data is spread out over lots of different sources 🌸 which is honestly iconic, since the data gets looked after by whoever actually owns it 💅 BUT it also means it's basically impossible to write down one single procedure for datamanagement 🙈

For the Internet Directory Service, guidelines will have to be developed (by the IETF IDS WG) 📝 to help organizations that are just starting to deploy X.500 figure out how to manage data in their own part of the DIT. The guidelines should describe a minimum level of quality that has to be supplied to make the service operational. The IETF OSI-DS WG is going to kick off a pilot on Quality of Service parameters in the Directory, which will be super useful ✨

Pilot datamanagement projects will have to happen too 🦋 (for example, existing databases should be connected to the Internet Directory Service). Any tools built for this should be made available to the Internet community for possible future use 🧚

Most countries connected to the Internet have some kind of law about how data on people can and can't be made available ⚖️ These laws cover privacy and registration issues, and they differ from country to country 🌍 It is suggested that each of the national organizations within the Internet that manages the Internet Directory Services master for that country does some research into how the laws in that country apply to data made public through use of X.500 🔍

In the meantime, a general "User Bill of Rights" should be established to show what proper use of the Internet Directory Service looks like 📜 This "Bill of Rights" could be drafted by the IETF IDS WG. As a starting point, the NADF "User Bill of Rights" [For92] can be used 🫶

7. TECHNICAL ISSUES

okay this section is the tech tea ☕ The IETF has set up the OSI-DS WG, and the major job of this group at the start is building a technical framework for deploying a Directory Service on the Internet, using the X.500 protocols and services [CCI88b]. This section walks through the work the group has already done, which has been focused (kind of implicitly) on the technical infrastructure needed to deploy the Internet Directory service 💖

The OSI Directory Standards don't have enough specifics yet to actually build the Internet Directory Service 😭 Full openness and interoperability are a key goal, so we may need Internet-specific agreements, at least until the ISO standards are more complete 🧩 This section points out the areas where the standards don't cover enough, and lists the RFCs that were written to fix those problems 📚

The work is being limited to (reasonably well) understood issues.

That means that while we'll try to solve a wider range of problems, not every potential requirement will necessarily get met 🥲

The technical work is done in conjunction with the RARE WG on Network Application Support WG (formerly RARE WG3). The IETF WGs and the RARE WG share a common technical mailing list 📬 It's meant to lead to a common European and North American technical approach 🌈

7.1. Schema

A Directory needs to be used inside an Information Framework 🗂️ The standard directory gives a number of attributes and object classes so basic operation works 💅 It's certain that the Internet community will have requirements for extra attributes and object classes, so there's a need to set up a mechanism to register that information 📝

Pilots in the European RARE Community and the US PSI White Pages Pilot based their information framework on the THORN and RARE Naming Architecture 🌸 This architecture should be used for the Internet Directory Service, together with COSINE based services in Europe. A revised version of the Naming Architecture, with a mechanism for registration of new attributes and object classes, has been released as RFC 1274 [BHK91a] 🎀

7.2. Use on the Internet

It is a recognized policy on the Internet to deploy OSI Applications over non-OSI lower layers (such as STD 35, RFC 1006) [RC87] 🧚 This policy lets OSI Applications get deployed before an OSI lower layer infrastructure exists. So the Internet Directory Service will decouple deployment of the OSI Directory from deployment of the OSI lower layers 🦋 Because the Internet Directory service will extend into the far corners of the Internet namespace, where the underlying tech isn't always TCP/IP 🌍, the Internet Directory Service will not make any mandatory requirements about use of lower layers. When configuring the Internet Directory Services, variations in the lower layers must be considered. The following options are possible:

  • Operation on top of TCP/IP using a lightweight protocol.
  • Operation over TCP/IP using STD 35, RFC 1006. This is a practical requirement of deployment at very many Internet sites, and is the basis of the existing services. It is highly recommended that all participating DSAs support this stack.
  • Use of OSI Network Service (Connection Oriented or Connectionless).
  • X.25(80) will probably not be used in the core infrastructure of the Internet Directory Service, but is the basis of some European activities. It may be needed later to interconnect with US commercial systems not on the Internet. There will be a practical need to interwork with DSAs which only support this stack.

This approach has the following implications:

  1. There is a need to represent TCP/IP addresses within OSI Network Addresses. This is specified in RFC 1277 [HK91a].
  2. It will be desirable to have a uniform method to present Network Addresses of this style. Therefore, a string representation of presentation addresses is specified in RFC 1278 [HK91d].
  3. This approach leads to the situation where not all DSAs can communicate directly due to the different choice of lower layers. This is already a practical result of many European sites operating DSAs over X.25. When the Internet Directory Service is deployed, the issue of which DSAs operate which stacks must be considered in order to achieve a coherent service. In particular, there may be a need to require DSAs that serve parts higher up in the DIT to serve multiple stacks. This will be tackled as an operational issue.
  4. There may be a requirement to extend the distributed operations, so that there is no requirement for full connectivity (i.e., each DSA supports each stack). A solution to this problem, by defining "relay DSAs", is specified in RFC 1276 [HK91b].

7.3. Replication of Knowledge and Data

There are a number of requirements on replication, both of data (the actual information on objects in the directory) and knowledge (the information on where to find what data 🗺️), which must be met before an Internet Directory can be deployed 😤 The 1988 standard cannot be used as is, because it doesn't deal with replication or caching, and that leads to serious performance problems 🐢 There is a partial solution in the 1992 version of the standard, but there are no products implementing it available yet 💀 These issues are discussed in more detail in RFC 1275 [HK91c].

As it took too long for 1992 implementations to arrive and help the already fast-growing pilot that urgently needed a solution, an option was chosen to use a simple interim approach as defined in RFC 1276 🏃‍♀️ It will be clearly emphasized that this is an interim approach, which will be phased out as soon as the appropriate standards are available and stable implementations are deployed 🫡 The interim approach is based on the approach used in the QUIPU Implementation, and it is widely deployed in the existing pilots ✨

7.4. Presentation of Directory Names

The standard doesn't specify a means to present directory names to the user. This is seen as a serious deficiency, and a standard for presenting directory names is required 🙃 For Distinguished Names, a string representation is defined in [HK92a]. However, since the distinguished name isn't very friendly for the user, a more user-oriented specification of a standard format for representing names, and procedures to resolve them, was chosen on the Internet, and is specified in [HK92b] 💅

7.5. DSA Naming and MD Structure

There are some critical issues related to naming of DSAs and the structure of Directory Management Domains 🚨 The main issues are:

  • It is hard to achieve very high replication of knowledge information, since it is spread really widely 🕸️;
  • There is a need to give DSAs more reasonable names, which will contain an indication of the role of the DSA; this is necessary for DSAs high up the DIT 🏷️;
  • There is too much DIT clutter in the current pilots 🧹;
  • There is no real concept of a DMD (Directory Management Domain) authority 👑.

These will be significant as the directory increases in size by orders of magnitude 📈 The IETF OSI-DS WG is working to develop a solution in this area 🫶

8. SECURITY 🔐✨

okay bestie, the Directory is lowkey THE key piece of security in a distributed system, especially when public-key cryptography is in the mix 🔑💖 It can act as a repository for authentication info, and that info is literally the foundation for OSI Authentication Services (e.g., X.400) and non-OSI Services (e.g., privacy-enhanced mail, PEM) 💌. It can also use this and other stored authentication information to offer a whole range of security Services that the Directory system uses itself 🫶.

8.1. Directory Provision of Authentication 🎀

The directory will be used to provide X.509 strong authentication 🪪. This places minimal requirements on the directory, which is the good news 🙌 But to use this infrastructure, users of authentication services have to be able to access the directory 📂. In practice, this kind of authentication can only be deployed on a limited scale without a directory, so this provision is critical for apps like Privacy Enhanced Mail [Lin93] 💌. The PEM folks are looking at issues around deploying Certification Authorities, but that discussion isn't duplicated here 👀.

PEM defines a key management architecture based on public-key certificates, in support of the message encipherment and authentication procedures defined in [Lin93] 🗝️. The PEM certificate management design [Ken93] makes use of the authentication framework defined by X.509. In this framework, as PEM adopts it, a "certification authority" representing an organization applies a digital signature to a bundle of data: a user's public component, various info that identifies the user, and the identity of the organization whose signature is affixed. This creates a binding between these user credentials, the user's public component, and the organization that vouches for this binding 🤝. The resulting signed data item is called a certificate 📜. The organization identified as the certifying authority for the certificate is the "issuer" of that certificate. The format of the certificate is defined in X.509.

In signing the certificate, the certification authority vouches for the user's identification, in the context specified by the identity of the issuer 🧾. Lots of different organizations can issue certificates, including corporate, educational, professional, or governmental entities 🏢🎓. These issuers may operate under different certification policies, so not all certificates are equally credible (i.e., some certificates may be more trustworthy as accurate identifiers of users, organizations, mailing lists, etc) 🤔. The PEM certificate management design allows for this diversity of certification policies, while ensuring that any certificate can be traced unambiguously to the policy under which it was issued 🔍.

The digital signature is affixed on behalf of that organization, and it's in a form that every member of the privacy-enhanced electronic mail community can recognize 👑. This means any PEM certificate can be universally verified, because the PEM certification design is a singly rooted tree in which the Internet Society acts as the root 🌳. Once generated, certificates can be stored in directory servers, transmitted via unsecure message exchanges, or distributed via any other means that make them easily accessible to message originators, without regard for the security of the transmission medium 📬.

8.2. Directory Security 🛡️

A number of security services are possible with the directory 💅:

Peer Authentication at Bind

Authentication (one or two way) between DUA/DSA and DSA/DSA, established during the bind operation. This may be provided using simple passwords (not recommended), one-way hashed passwords (more secure), or public key cryptography (most secure). The various authentication options are specified in X.500(88), but most existent implementations implement only simple password authentication 😭.

Per-operation Authentication and Integrity

This is usually used to identify the DUA originating an operation to the Directory (e.g., to authenticate prior to data modification) 🔏. It may also be used to verify the identity of the DSA which provided data in a response to the user. In both examples, the integrity of the data is also ensured through the use of digital signatures ✍️. This is specified in X.500(88), but not yet widely implemented ⏳.

Single Entry Access Control

This is used to control which users (DUAs) can access and modify data within an entry 🚪. This is specified in X.500(92), and most DSA implementations provide this function ✅.

Multiple Entry Access Control

This is used to control search and list operations, in order to allow location of information by searching, but to deter "trawling" of information and organizational structure 🕵️. Usually, these access controls are limited in their ability to prevent trawling, because of the conflicting goal of allowing a certain level of legitimate browsing in support of "white pages" functionality 📖.

Service Authorization

This allows DSAs to control service in a data independent manner, based on peer authentication. For example, one might prevent students from making non-local queries, while permitting such queries by faculty and staff 🎓.

Security Policy

This term encompasses the security goals for which data access control, service authorization, and authentication mechanisms are used to implement 🎯. For example, a local security policy might require that all directory database modifications employ strong authentication and originate from a computer at a known (local) location 💻.

Data Confidentiality

The directory does not include explicit features to protect the confidentiality of data while in transit (e.g., between a DUA and DSA or between DSAs). Instead, it is assured that lower layer security protocols or other local security facilities will be employed to provide this security service 🔒. Ongoing work on adaptation of the Network Layer Security Protocol (NLSP) is a candidate for provision of this security service with directories ⭐.

There is no specification of any Internet-wide security policy for directories, nor are there currently any security mechanisms required of all directories 🙅 Deployment of a directory could be based on a variety of policies:

  • Read only system, containing only public data and restricted to local modification.
  • Use of X.509 authentication, and private access control mechanisms (this will not allow open access control management, but this is not seen as a fundamental problem).

It will be important to understand if global Internet requirements for minimum essential directory security mechanisms will be required to promote widespread use of directories 🤔. We recommend that an informational RFC be written to analyze this issue, with an operational policy guidelines or applicability statement RFC to follow 📝.

9. RELATION TO DNS 🌐

It is important to establish the relationship between the proposed Internet Directory and the existing Domain Name System 💫. An Experimental Protocol RFC (RFC 1279) proposes a mapping of DNS information onto the Directory 🗺️. Experiments should be conducted in this area [HK91e] 🧪.

10. EXTERNAL CONNECTIONS 🤝

It will be important for this activity to maintain suitable external liaisons. In particular to:

Other Directory Services and Directory Pilots

To ensure a service which is coherent with other groups building X.500 services, e.g.,:

  • Paradise
  • NADF
  • FOX
  • PSI White Pages

Standards Bodies

To feed back experience gained from this activity, so that the next round of standards meets as many of the Internet requirements as possible, e.g.,:

  • CCITT/ISO
  • RARE WG-NAS
  • EWOS/OIW
  • ETSI

11. REFERENCES ✨

okay bestie, here's the reading list 📚💅 every one of these shows up somewhere above, so it's all legit

  • [BHK91a] Barker, P., and S. Hardcastle-Kille, "The COSINE and Internet X.500 Schema", RFC 1274, Department of Computer Science, University College London, November 1991.
  • [BHK92] Barker, P., and S. Hardcastle-Kille, "Naming Guidelines for Directory Pilots", RFC 1384, Department of Computer Science, University College London, ISODE Consortium, January 1993.
  • [CCI88a] The Directory --- authentication framework, December 1988. CCITT Recommendation X.509.
  • [CCI88b] The Directory --- overview of concepts, models and services, December 1988. CCITT X.500 Series Recommendations.
  • [CCI90] The Directory --- part 9 --- replication, October 1990. ISO/IEC CD 9594-9 Ottawa output.
  • [CFSD90] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990.
  • [For91] The North American Directory Forum, "A Naming Scheme for C=US", RFC 1255, NADF, September 1991. Also NADF-175. (See also RFC 1417.)
  • [For92] The North American directory Forum, "User Bill of Rights for Entries and Listing in the Public Directory", RFC 1295, NADF, January 1992. (See also RFC 1417.)
  • [HK91a] Hardcastle-Kille, S., "Encoding network addresses to support operation over non-OSI lower layers", RFC 1277, Department of Computer Science, University College London, November 1991.
  • [HK91b] Hardcastle-Kille, S., "Replication and distributed operations extensions to provide an internet directory using X.500", RFC 1276, Department of Computer Science, University College London, November 1991.
  • [HK91c] Hardcastle-Kille, S., "Replication requirement to provide an internet directory using X.500", RFC 1275, Department of Computer Science, University College London, November 1991.
  • [HK91d] Hardcastle-Kille, S., "A string encoding of presentation address", RFC 1278, Department of Computer Science, University College London, November 1991.
  • [HK91e] Hardcastle-Kille, S., "X.500 and domains", RFC 1279, Department of Computer Science, University College London, November 1991.
  • [HK92a] Hardcastle-Kille, S., "A string representation of Distinguished Names", Department of Computer Science, University College London, Work in Progress.
  • [HK92b] Hardcastle-Kille, S., "Using the OSI directory to achieve user friendly naming", Department of Computer Science, University College London, Work in Progress.
  • [HSB91] Howes, R., Smith, M., and B. Beecher, "DIXIE Protocol Specification", RFC 1249, University of Michigan, July 1991.
  • [ISO] Procedures for the operation of OSI registration authorities --- part 1: general procedures. ISO/IEC 9834-1.
  • [Ken93] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II - Certificate-based Key Management, RFC 1422, BBN, February 1993.
  • [Kil88] Kille, S., "The QUIPU Directory Service", In IFIP WG 6.5 Conference on Message Handling Systems and Distributed Applications, pages 173--186. North Holland Publishing, October 1988.
  • [Kil89] Kille, S., "The THORN and RARE Naming Architecture", Technical report, Department of Computer Science, University College London, June 1989. THORN Report UCL-64 (version 2).
  • [Lin93] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I - Message Encryption and Authentication Procedures", RFC 1421, February 1993.
  • [LW91] Lang, R., and R. Wright, "A Catalog of Available X.500 Implementations", FYI 11, RFC 1292, SRI International, Lawrence Berkeley Laboratory, January 1992.
  • [Lyn91] Lynch, C., "The Z39.50 information retrieval protocol: An overview and status report", Computer Communication Review, 21(1):58--70, January 1991.
  • [Par91] Paradise International Report, Cosine. Paradise project, Department of Computer Science, University College London. November 1991.
  • [RC87] Rose, M., and D. Cass, "ISO Transport Services on top of the TCP", STD 35, RFC 1006, Northrop Corporation Technology Center, May 1987.
  • [Ros91] Rose, M., "Directory Assistance Service", RFC 1202, Performance Systems International, February 1991.
  • [WR92] Weider, C., and J. Reynolds, "Executive Introduction to Directory Services Using the X.500 Protocol", FYI 13, RFC 1308, ANS, ISI, March 1992.

12. Security Considerations 🔐

ooh, the security section, serious business 😭 the actual security issues are discussed over in Section 8, so go check that out, babe.

Security issues are discussed in Section 8.

13. Authors' Addresses 🦋

and finally, the people who made this happen 🫶 here's how to reach each of them

Steve Hardcastle-Kille 💜

Steve Hardcastle-Kille
ISODE Consortium
PO box 505
SW11 1DX London
England
Phone: +44-71-223-4062
EMail: S.Kille@isode.com

Erik Huizer 🌸

Erik Huizer
SURFnet bv
PO box 19035
3501 DA Utrecht
The Netherlands
Phone: +31-30 310290
Email: Erik.Huizer@SURFnet.nl

Vinton Cerf 🎀

Vinton Cerf
Corporation for National Research Initiatives
1895 Preston White Drive, Suite 100
Reston, VA 22091
Phone: (703) 620-8990
EMail: vcerf@cnri.reston.va.us

Russ Hobby 🍓

Russ Hobby
University of California, Davis
Computing Services
Surge II Room 1400
Davis, CA 95616
Phone: (916) 752-0236
EMail: rdhobby@ucdavis.edu

Steve Kent 🧚

Steve Kent
Bolt, Beranek, and Newman
50 Moulton Street
Cambridge, MA 02138
Phone: (617) 873-3988
EMail: skent@bbn.com
📦 where this page comes from