7 Network Working Group S. Hardcastle-Kille
8 Request for Comments: 1430 ISODE-Consortium
12 Corporation for National Research Initiatives
14 University of California, Davis
16 Bolt, Beranek and Newman
20 A Strategic Plan for Deploying an
21 Internet X.500 Directory Service
25 This memo provides information for the Internet community. It does
26 not specify an Internet standard. Distribution of this memo is
31 There are a number of reasons why a new Internet Directory Service is
32 required. This document describes an overall strategy for deploying
33 a Directory Service on the Internet, based on the OSI X.500 Directory
34 Service. It then describes in more detail the initial steps which
35 need to be taken in order to achieve these goals, and how work
36 already undertaken by Internet Engineering Task Force Working Groups
37 (IETF WGs) is working towards these goals.
42 2. SUMMARY OF SOLUTION 3
43 3. INFORMATION FRAMEWORK 3
44 3.1 The Technical Model 3
45 3.2 Extending the Technical Model 4
46 3.3 The Operational Model 5
48 5. DIRECTORY INFRASTRUCTURE 6
49 5.1 Short Term Requirements 7
50 5.2 Medium Term Requirements 9
51 5.3 Long Term Requirements 9
54 7. TECHNICAL ISSUES 10
58 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 1]
60 RFC 1430 X.500 Strategy February 1993
64 7.2 Use on the Internet 11
65 7.3 Replication of Knowledge and Data 12
66 7.4 Presentation of Directory Names 13
67 7.5 DSA Naming and MD Structure 13
69 8.1 Directory Provision of Authentication 14
70 8.2 Directory Security 15
72 10. EXTERNAL CONNECTIONS 16
74 12. Security Considerations 19
75 13. Authors' Addresses 20
79 There is substantial interest in establishing a new Directory Service
80 on the Internet. In the short term, there is pressure to establish
83 - White Pages lookup of users;
85 - Support for X.509 Authentication for a range of applications in
86 particular for Privacy Enhanced mail [Lin89].
88 In the medium term, there are likely to be many requirements for
89 Directory Services, including:
91 - General resource lookup, for information ranging from committee
92 structures to bibliographic data;
94 - Support of management of the Internet infrastructure, and
95 integration of configuration information into the higher level
98 - Support of applications on the Internet. For example:
100 o Electronic distribution lists;
101 o Capability information on advanced user agents;
102 o Location of files and archive services.
104 - Support for Mail Handling Systems; Be they RFC-822 based or X.400
105 based (IETF MHS-DS WG), e.g.,:
107 o Support for routing;
108 o Info on User agent capabilities; essential for a usage of
109 Multimedia mail like MIME (Multipurpose Internet Mail
114 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 2]
116 RFC 1430 X.500 Strategy February 1993
119 For the longer term, more sophisticated usages of X.500 are possible
120 extending it into a useful and fast yellow pages service.
122 2. SUMMARY OF SOLUTION
124 In principle, the current Internet Domain Name System (DNS) could be
125 used for many of these functions, with appropriate extensions.
126 However, it is suggested that a higher level of directory service is
127 needed. It is proposed to establish an Internet Directory Service
128 based on X.500. This provides appropriate functionality for the
129 services envisaged and gives flexibility for future extension. This
130 extension could be achieved either by tracking the evolution of the
131 OSI Standard or by work specific to the Internet. In practice, it is
132 likely to be a mixture of both.
134 By deploying X.500 in some form on the Internet, a truly global and
135 universal Directory Service can be built that will provide Internet
136 users with fast access to all kinds of data. The X.500 Directory
137 Service in this case may range from a simple white pages service
138 (information on people and services) to coupling various existing
139 databases and information repositories in a universal way.
141 Currently, several different but cooperating X.500 Directory Services
142 pilots are taking place on the Internet. These pilots form an
143 important base for experimenting with this new service. Starting with
144 these pilots, with the X.500 products arriving on the market today,
145 and given sufficient funding for the central services described in
146 this paper an operational X.500 Directory Service can be deployed.
148 The final goal of the strategy described in this paper is to deploy a
149 fully operational Directory Service on the Internet, providing the
150 functions mentioned in the previous section.
152 3. INFORMATION FRAMEWORK
154 The most critical aspect of the Directory Service is to establish an
155 Internet Information Framework. When establishing a sophisticated
156 distributed directory with a coherent information framework, it
157 involves substantial effort to map data onto this framework. This
158 effort is an operational effort and far outweighs the technical
159 effort of establishing servers and user agents.
161 3.1 The Technical Model
163 By choosing the X.500 model as a basis for the information framework,
164 it will also be part of a (future) global information framework. The
165 key aspects of this model are:
170 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 3]
172 RFC 1430 X.500 Strategy February 1993
175 - A hierarchical navigational system that couples distributed
176 databases (of various kinds), which allows for management of the
177 data by the organization/person responsible for the data;
179 - Each object in this information structure (called the Directory
180 Information Tree, DIT) is represented as an entry;
182 - Objects are typed by an "object class", which permits multiple
185 - An object is described by a set of attributes;
187 - Each attribute is typed. Attribute types are hierarchical;
189 - Each attribute type has an associated attribute syntax, which may
190 be generic or shared with other attributes (e.g., Integer Syntax;
191 Distinguished name Syntax); This allows for representation of
192 simple attributes (e.g., strings or bitmaps) or complex ones with
195 - Each entry has an unambiguous and unique global name;
197 - Alternate hierarchies may be built by use of aliases or pointers of
198 distinguished name syntax.
200 This framework allows for representation of basic objects such as
201 users within organizations. It is also highly extensible, and so can
202 be used for a range of other applications.
204 3.2 Extending the Technical Model
206 In the longer term, the model could be extended to deal with a number
207 of other requirements which potentially must be met by an Internet
208 Directory Service. Possible extensions include:
210 - Support of ordered attributes (needed by some applications such as
213 - Extensions to allow unification with management information,
214 associated with SNMP (Simple Network Management Protocol) [CFSD90]
215 or other management protocols;
217 - Handling of non-hierarchical data in a better manner for searching
218 and retrieval, whilst retaining the basic hierarchy for management
219 purposes. This is essentially building a general purpose resource
220 location service on top of the basic infrastructure. It will need
221 work on the information model, and not just the access protocols.
226 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 4]
228 RFC 1430 X.500 Strategy February 1993
231 It is noted that although X.500 may not provide the ultimate solution
232 to information retrieval, it has good potential for solving a lot of
233 information service related problems.
235 3.3 The Operational Model
237 To make the Directory Service with a coherent information framework
238 really operational requires a lot of effort. The most probable
239 operational model is one where larger organizations on the Internet
240 maintain their part of the DIT on their own DSA (Directory System
241 Agent). Smaller organizations will "rent" DSA space from regional
242 networks or other service providers. Together these DSAs will form
243 the Internet Directory Service Infrastructure. To couple the various
244 parts of the DIT that are contained on these Internet DSAs, a special
245 DSA containing the Root for the naming hierarchy within the DIT has
246 to be established and maintained.
248 The following tasks can be foreseen:
250 - Defining the naming hierarchy; See section 4.
251 - Creating the Directory Infrastructure; See section 5.
252 - Getting the Data into the directory; and
253 - Managing the data in the Directory. See section 6.
257 In order to deploy the Internet Directory Service, it is important to
258 define how the naming hierarchy will be structured. Although the
259 basic model suggests a simple monolithic "database" containing all of
260 the Internet's information infrastructure, with a namespace divided
261 along geographic boundaries, this may not be the definite model that
262 turns out to be the most appropriate to the Internet. Different
263 models may evolve according to the needs of the Internet and the
264 applications used on the Internet (i.e., some parts of the DIT may be
265 assigned at the root for the Internet). Below this one can envisage
266 several loosely coupled namespaces each with their own area of
267 applicability. This should be handled as a part of the general
268 operation of a directory service. An example of this might be
269 assignment of a representation of the Domain Namespace under the root
270 of the DIT. This is further discussed in [BHK91a].
272 However, the core DIT information will be nationally assigned. The
273 parts of the DIT below country level will be managed differently in
274 each country. In many countries, registration authorities will be
275 established according to the OSI Standard [ISO]. This has been done
276 in some countries by the national ISO member body representative (for
277 example in the UK by BSI).
282 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 5]
284 RFC 1430 X.500 Strategy February 1993
287 The lower parts of the hierarchy will, in general, be delegated to
288 organizations who will have control over Name Assignment in that part
289 of the tree. There is no reason to mandate how to assign this
290 hierarchy, although it is appropriate to give guidelines. Proposed
291 solutions to assignment of namespace are given in [BHK92].
293 In North America, there is an alternative approach being developed by
294 the North American Directory Forum (NADF), which leverages existing
295 registration mechanisms [For91]. It is not yet clear what form a
296 final North American Directory Service will take. It is expected that
297 similar initiatives will be taken in other places, such as Europe.
298 For the Internet, the Internet Society (ISOC) has been suggested as a
299 possible Naming Authority.
301 A discussion of the main issues involved with representing the Real
302 World in the Directory Service is part of the work undertaken by the
303 IETF OSI DS Working Group.
305 The core of the Internet Directory will therefore come to exist of a
306 country based structure with different national naming schemes below
307 the countries. It is clearly desirable that the Internet Directory
308 Service follows any evolving national and international hierarchies.
309 However, this should not be allowed to cause undue delay. The
310 strategy proposed is to proceed with name assignment as needed, and
311 to establish interim registration authorities where necessary, taking
312 practical steps to be aligned with emerging national authorities
315 It is suggested that the Internet Directory Service does two things:
317 First, each national part of the Internet DIT namespace should be
318 delegated to an appropriate organization, which will usually be in
319 the country of question. Second, the delegated organization should
320 assign names for that country as part of the Internet Directory
321 Service. This should be done in a manner which is appropriately
322 aligned with any emerging local or national service, but does not
323 unduly delay the deployment of the Internet Directory Service. For
324 most countries, this will fit in as a natural evolution of the early
325 directory piloting, where operators of pilots have acted as interim
326 name registration authorities.
328 5. DIRECTORY INFRASTRUCTURE
330 To provide access to the Internet Directory Service, an
331 infrastructure has to be built. Although the technical components of
332 an X.500 infrastructure are clear: DSAs (that hold the actual data)
333 and DUAs (that allow users and applications to access the data), a
334 lot more is needed for deployment of an Internet Directory Service.
338 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 6]
340 RFC 1430 X.500 Strategy February 1993
343 The Integrated Directory Services (IDS) Working Group of the IETF is
344 playing a key role in solving most of the issues that are related to
345 the building of an appropriate infrastructure.
347 Many of the issues cited in this section have come forward out of
348 interim pilots that have been established on the Internet:
350 PSI White Pages Pilot
351 This is a pilot service which is operating X.500 on the Internet.
352 In many ways it is operating as an Internet wide pilot.
355 Fielding Operational X.500, a project to explore the development
356 and interoperability of X.500 implementations.
358 Paradise (Piloting A ReseArch DIrectory Service in Europe)
359 This project has been providing the necessary glue to hold the
360 various national activities together [Par91].
362 5.1 Short Term Requirements
364 - Central Operations. There is a need for a number of operations
365 to be managed as a service for the whole Internet. These services
368 o A root DSA; containing the top-level of the DIT, has to be
369 provided. Currently, this root DSA is managed by the Paradise
372 o Name assignment; Inserting names into the Directory, this has
373 been discussed in section 4. This could be done in conjunction
374 with the appropriate Registration Authority or by the
375 Registration Authority. In most cases it is likely to be the
376 former, and mechanisms will need to be set up to allow
377 organizations to get their names installed into the directory,
378 either direct or through the registration authority.
380 o Knowledge management; i.e., the information on "which DSA holds
381 what part of the DIT, and how can that DSA be accessed". DSAs
382 will be established by Organizations. There will be a need to
383 centrally coordinate the management of the knowledge information
384 associated with these DSAs. This is likely to be coupled to the
387 o Knowledge and Data replication; For the Directory to perform
388 well, knowledge and data high up in the DIT must be
389 significantly replicated. A service must be provided to make
390 replicated information available to DSAs that need it.
394 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 7]
396 RFC 1430 X.500 Strategy February 1993
399 It is suggested that for the time being, Paradise should be used
400 as the initial basis for handling the top-level of the DIT and for
401 provision of the central services. However, the services mentioned
402 above need to be provided at a national level for every
403 participating country in the Internet Directory Service. Whenever
404 an organization starts a new country branch of the DIT in the
405 Internet Directory Service the central operations will have to
406 help out to make sure that these services will be properly
407 installed on a national level.
409 - An effective service will need to have sufficient implementations,
410 in order to give full coverage over different hardware and software
411 platforms, and to demonstrate openness. The recent Directory
412 Information Services (pilot) Infrastructure Working Group's (DISI)
413 Survey of Directory Implementations suggests that there will not be
414 a problem here. This provides a list of available X.500
415 implementations and their capabilities [LW91].
417 - An executive summary, necessary to convince the management of
418 computer centers to invest manpower into setting up a X.500
419 Directory Service. This is provided by DISI [WR92].
421 - Due to the possible different and rather independent structured
422 namespaces that can be envisaged in the DIT for different purposes,
423 DUAs will have to be "tuned intelligently" for the applications that
426 - To allow users easy access to the Internet Directory Service even
427 from low powered workstations, a lightweight protocol has to be
428 developed over TCP/IP. Already two private protocols that do this
429 have been developed: The Michigan DIXIE protocol [HSB91] and the PSI
430 Directory Assistance Service [Ros91]. The IETF OSI Directory
431 Services Working Group (OSI-DS WG) is currently working on a
432 standard lightweight protocol called LDAP.
434 - Although the Internet Directory Service does not have to make any
435 mandatory requirements about the use of lower layers, it is noted
436 that the use of STD 35, RFC 1006 to allow use of OSI applications on
437 top of TCP/IP is essential for deployment in the Internet. Other
438 stacks like the ones using CLNS, CONS and X.25(80) will probably
439 also be deployed in parts of the Internet. DSAs with different
440 stacks will be linked through use of either application level relays
441 (chaining) or Transport Service bridges.
443 - There are multiple issues that are not dealt with (properly) in the
444 X.500 standard and thus prevent the building of an Internet
445 Directory service. Intermediate solutions for these issues have to
446 be established in an "open" way. The results will have to be
450 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 8]
452 RFC 1430 X.500 Strategy February 1993
455 deployed as well as to be fed back into the relevant standard
456 committees. The IETF OSI-DS WG deals with these issues. Section 7
457 describes several of these issues.
459 - Site support. The IETF IDS WG is looking at providing the necessary
460 documentation to help with the provision of support for Directory
461 users at participating sites.
463 5.2 Medium Term Requirements
465 - Enhanced performance is necessary to allow for a real global usage;
467 - The schema has to be extended to allow for various kinds of data,
473 - Support for Internet Message Handling services (RFC-822, MIME and
474 X.400). This work is already undertaken by the IETF MHS-DS WG.
476 5.3 Long Term Requirements
478 - To make sure that X.500 evolves into an operational service, it is
479 essential to track its evolution, and to feed back into the
482 - Interface existing RDBMS into the Directory Service.
484 - To increase the performance of the directory, and thereby making it
485 useful for an even wider range of applications (e.g., policy based
486 routing), a lightweight protocol for access and system usage is
491 The whole of the Directory Infrastructure won't stand much chance
492 without proper datamanagement of the data contained within the DIT.
493 Procedures need to be established to assure a certain Level of
494 Quality of the data contained in the DIT.
496 Due to the very nature of X.500, the management of the data is
497 distributed over various sources. This has the obvious advantage that
498 the data will be maintained by the owner of the data. It does
499 however, make it quite impossible to describe one single procedure
506 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 9]
508 RFC 1430 X.500 Strategy February 1993
511 For the Internet Directory Service, guidelines will have to be
512 developed (by the IETF IDS WG), to help organizations that start with
513 deployment of X.500 on how to manage data in their part of the DIT.
514 The guidelines should describe a minimum level of quality that has to
515 be supplied to make the service operational. The IETF OSI-DS WG will
516 initiate a pilot on Quality of Service parameters in the Directory,
519 Pilot datamanagement projects will have to be done (e.g., existing
520 databases should be connected to the Internet Directory Service).
521 Tools that are developed to achieve this should be made available to
522 the Internet community for possible future use.
526 Most countries connected to the Internet have some sort of law that
527 dictates how data on people can and cannot be made available. These
528 laws deal with privacy and registration issues, and will differ from
529 country to country. It is suggested that each of the national
530 organizations within the Internet that manages the Internet Directory
531 Services master for that country, undertake some research as to the
532 applicability of laws within that country on data made public through
535 In the mean time, a general "User Bill of Rights" should be
536 established to indicate what the proper use of the Internet Directory
537 Service is. This "Bill of Rights" could be drafted by the IETF IDS
538 WG. As a basis, the NADF "User Bill of Rights" [For92] can be used.
542 The IETF has established the OSI-DS WG. The major component of the
543 initial work of this group is to establish a technical framework for
544 deploying a Directory Service on the Internet, making use of the
545 X.500 protocols and services [CCI88b]. This section describes the
546 work already done by this working group, which has been implicitly
547 focused on the technical infrastructure needed to deploy the Internet
550 The OSI Directory Standards do not yet contain sufficient specifics
551 to enable the Internet Directory Service to be built. Full openness
552 and interoperability are a key goal, so we may need Internet specific
553 agreements, at least until the ISO standards are more complete. This
554 section notes areas where the standards do not have sufficient
555 coverage, and indicates the RFCs which have been written to overcome
558 The work is being limited to (reasonably well) understood issues.
562 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 10]
564 RFC 1430 X.500 Strategy February 1993
567 This means that whilst we will attempt to solve a wider range of
568 problems, not all potential requirements will necessarily be met.
570 The technical work is done in conjunction with the RARE WG on Network
571 Application Support WG (formerly RARE WG3). The IETF WGs and the RARE
572 WG have a common technical mailing list. It is intended that this
573 will lead to a common European and North American technical approach.
577 A Directory needs to be used in the context of an Information
578 Framework. The standard directory provides a number of a attributes
579 and object classes to enable basic operation. It is certain that the
580 Internet community will have requirements for additional attributes
581 and object classes. There is a need to establish a mechanism to
582 register such information.
584 Pilots in the European RARE Community and the US PSI White Pages
585 Pilot have based their information framework on the THORN and RARE
586 Naming Architecture. This architecture should be used for the
587 Internet Directory Service, in conjunction with COSINE based services
588 in Europe. A revised version of the Naming Architecture, with a
589 mechanism for registration of new attributes and object classes, has
590 been released as RFC 1274 [BHK91a].
592 7.2 Use on the Internet
594 It is a recognized policy on the Internet to deploy OSI Applications
595 over non-OSI lower layers (such as STD 35, RFC 1006) [RC87]. This
596 policy allows deployment of OSI Applications before an OSI lower
597 layer infrastructure has been deployed. Thus, the Internet Directory
598 Service will decouple deployment of the OSI Directory from deployment
599 of the OSI lower layers. As the Internet Directory service will
600 extend into the far corners of the Internet namespace, where the
601 underlying technology is not always TCP/IP, the Internet Directory
602 Service will not make any mandatory requirements about use of lower
603 layers. When configuring the Internet Directory Services, variations
604 in the lower layers must be considered. The following options are
607 - Operation on top of TCP/IP using a lightweight protocol.
609 - Operation over TCP/IP using STD 35, RFC 1006. This is a practical
610 requirement of deployment at very many Internet sites, and is the
611 basis of the existing services. It is highly recommended that all
612 participating DSAs support this stack.
614 - Use of OSI Network Service (Connection Oriented or Connectionless).
618 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 11]
620 RFC 1430 X.500 Strategy February 1993
623 - X.25(80) will probably not be used in the core infrastructure of
624 the Internet Directory Service, but is the basis of some European
625 activities. It may be needed later to interconnect with US
626 commercial systems not on the Internet. There will be a practical
627 need to interwork with DSAs which only support this stack.
629 This approach has the following implications:
631 1. There is a need to represent TCP/IP addresses within OSI Network
632 Addresses. This is specified in RFC 1277 [HK91a].
634 2. It will be desirable to have a uniform method to present Network
635 Addresses of this style. Therefore, a string representation of
636 presentation addresses is specified in RFC 1278 [HK91d].
638 3. This approach leads to the situation where not all DSAs can
639 communicate directly due the different choice of lower layers.
640 This is already a practical result of many European sites operating
641 DSAs over X.25. When the Internet Directory Service is deployed,
642 the issue of which DSAs operate which stacks must be considered in
643 order to achieve a coherent service. In particular, there may be a
644 need to require DSAs that serve parts higher up in the DIT to serve
645 multiple stacks. This will be tackled as an operational issue.
647 4. There may be a requirement to extend the distributed operations, so
648 that there is no requirement for full connectivity (i.e., each DSA
649 supports each stack). A solution to this problem, by defining
650 "relay DSAs" is specified in RFC 1276 [HK91b].
652 7.3 Replication of Knowledge and Data
654 There are a number of requirements on replication, both of data (the
655 actual information on objects in the directory) and knowledge (the
656 information on where do I find what data) information, which must be
657 met before an Internet Directory can be deployed. The 1988 standard
658 cannot be used as is, because it does not deal with replication or
659 caching. This leads to serious problems with performance. There is a
660 partial solution available in the 1992 version of the standard,
661 however there are no products available yet that implement this
662 solution. These issues are discussed in more detail in RFC 1275
665 As it took too long for 1992 implementations to arrive to be of any
666 help to the already rapidly growing pilot that urgently needed a
667 solution, an option was chosen to use a simple interim approach as
668 defined in RFC 1276. It will be clearly emphasized that this is an
669 interim approach, which will be phased out as soon as the appropriate
670 standards are available and stable implementations are deployed. The
674 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 12]
676 RFC 1430 X.500 Strategy February 1993
679 interim approach is based on the approach used in the QUIPU
680 Implementation and it is widely deployed in the existing pilots.
682 7.4 Presentation of Directory Names
684 The standard does not specify a means to present directory names to
685 the user. This is seen as a serious deficiency, and a standard for
686 presenting directory names is required. For Distinguished Names, a
687 string representation is defined in [HK92a]. However, as the
688 distinguished name is not very friendly for the user, a more user
689 oriented specification of a standard format for representing names,
690 and procedures to resolve them is chosen on the Internet, and is
691 specified in [HK92b].
693 7.5 DSA Naming and MD Structure
695 There are some critical issues related to naming of DSAs and the
696 structure of Directory Management Domains. The main issues are:
698 - It is hard to achieve very high replication of knowledge
699 information as this is very widely spread;
701 - There is a need to give DSAs more reasonable names, which will
702 contain an indication on the role of the DSA; This is necessary for
703 DSAs high up the DIT.
705 - There is too much DIT clutter in the current pilots;
707 - There is no real concept of a DMD (Directory Management Domain)
710 These will be significant as the directory increases in size by
711 orders of magnitude. The IETF OSI-DS WG is working to develop a
712 solution in this area.
716 A Directory can be an important component in the overall provision of
717 security in a distributed system environment, especially when
718 public-key cryptographic technology is employed. The directory can
719 serve as a repository for authentication information, which, in turn,
720 forms the basis of a number of OSI Authentication Services (e.g.,
721 X.400) and non-OSI Services (e.g., privacy-enhanced mail, PEM). The
722 directory may also use this and other stored authentication
723 information to provide a wide range of security Services used by the
724 Directory system itself.
730 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 13]
732 RFC 1430 X.500 Strategy February 1993
735 8.1 Directory Provision of Authentication
737 The directory will be used to provide X.509 strong authentication.
738 This places minimal requirements on the directory. To use this
739 infrastructure, users of authentication services must have access to
740 the directory. In practice, this type of authentication can be
741 deployed only on a limited scale without use of a directory, and so
742 this provision is critical for applications such as Privacy Enhanced
743 Mail [Lin93]. The PEM development is considering issues relating to
744 deploying Certification Authorities, and this discussion is not
747 PEM defines a key management architecture based on the use of
748 public-key certificates, in support of the message encipherment and
749 authentication procedures defined in [Lin93]. The PEM certificate
750 management design [Ken93] makes use of the authentication framework
751 defined by X.509. In this framework, as adopted by PEM, a
752 "certification authority" representing an organization applies a
753 digital signature to a collection of data consisting of a user's
754 public component, various information that serves to identify the
755 user, and the identity of the organization whose signature is
756 affixed. This establishes a binding between these user credentials,
757 the user's public component and the organization which vouches for
758 this binding. The resulting, signed, data item is called a
759 certificate. The organization identified as the certifying authority
760 for the certificate is the "issuer" of that certificate. The format
761 of the certificate is defined in X.509.
763 In signing the certificate, the certification authority vouches for
764 the user's identification, in the context specified by the identity
765 of the issuer. Various types of organization may issue certificates,
766 including corporate, educational, professional, or governmental
767 entities. Moreover, these issuers may operate under different
768 certification policies, so that not all certificates may be equally
769 credible (i.e., some certificates may be more trustworthy as accurate
770 identifiers of users, organizations, mailing lists, etc). The PEM
771 certificate management design allows for this diversity of
772 certification policies, while ensuring that any certificate can be
773 traced unambiguously to the policy under which it was issued.
775 The digital signature is affixed on behalf of that organization and
776 is in a form which can be recognized by all members of the privacy-
777 enhanced electronic mail community. This ability to universally
778 verify any PEM certificate results because the PEM certification
779 design is a singly rooted tree, in which the Internet Society acts as
780 the root. Once generated, certificates can be stored in directory
781 servers, transmitted via unsecure message exchanges, or distributed
782 via any other means that make certificates easily accessible to
786 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 14]
788 RFC 1430 X.500 Strategy February 1993
791 message originators, without regard for the security of the
794 8.2 Directory Security
796 A number of security services are possible with the directory:
798 Peer Authentication at Bind
799 Authentication (one or two way) between DUA/DSA and DSA/DSA,
800 established during the bind operation. This authentication may be
801 provided using simple passwords (not recommended), one-way hashed
802 passwords (more secure), or via public key cryptography (most
803 secure). The various authentication options are specified in
804 X.500(88), but most existent implementations implement only simple
805 password authentication.
807 Per-operation Authentication and Integrity
808 This is usually used to identify the DUA originating an operation
809 to the Directory (e.g., to authenticate prior to data
810 modification). It may also be used to verify the identity of the
811 DSA which provided data in a response to the user. In both
812 examples, the integrity of the data also is ensured through the
813 use of digital signatures. This is specified in X.500(88), but not
814 yet widely implemented.
816 Single Entry Access Control
817 This is used to control which users (DUAs) can access and modify
818 data within an entry. This is specified in X.500(92) and most DSA
819 implementations provide this function.
821 Multiple Entry Access Control
822 This is used to control search and list operations, in order to
823 allow location of information by searching, but to deter
824 "trawling" of information and organizational structure. Usually,
825 these access controls are limited in their ability to prevent
826 trawling because of the conflicting goal of allowing a certain
827 level of legitimate browsing in support of "white pages"
830 Service Authorization
831 This allows DSAs to control service in a data independent manner,
832 based on peer authentication. For example, one might prevent
833 students from making non-local queries, while permitting such
834 queries by faculty and staff.
842 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 15]
844 RFC 1430 X.500 Strategy February 1993
848 This term encompasses the security goals for which data access
849 control, service authorization, and authentication mechanisms are
850 used to implement. For example, a local security policy might
851 require that all directory database modifications employ strong
852 authentication and originate from a computer at a known (local)
856 The directory does not include explicit features to protect the
857 confidentiality of data while in transit (e.g., between a DUA and
858 DSA or between DSAs). Instead, it is assured that lower layer
859 security protocols or other local security facilities will be
860 employed to provide this security service. Ongoing work on
861 adaptation of the Network Layer Security Protocol (NLSP) is a
862 candidate for provision of this security service with directories.
864 There is no specification of any Internet-wide security policy for
865 directories, nor are there currently any security mechanisms required
866 of all directories. Deployment of a directory could be based on a
869 - Read only system, containing only public data and restricted to
872 - Use of X.509 authentication, and private access control mechanisms
873 (this will not allow open access control management, but this is not
874 seen as a fundamental problem).
876 It will be important to understand if global Internet requirements
877 for minimum essential directory security mechanisms will be required
878 to promote widespread use of directories. We recommend that an
879 informational RFC be written to analyze this issue, with an
880 operational policy guidelines or applicability statement RFC to
885 It is important to establish the relationship between the proposed
886 Internet Directory, and the existing Domain Name System. An
887 Experimental Protocol RFC (RFC 1279) proposes a mapping of DNS
888 information onto the Directory. Experiments should be conducted in
891 10. EXTERNAL CONNECTIONS
893 It will be important for this activity to maintain suitable external
894 liaisons. In particular to:
898 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 16]
900 RFC 1430 X.500 Strategy February 1993
903 Other Directory Services and Directory Pilots
905 To ensure a service which is coherent with other groups building
906 X.500 services. e.g.,:
915 To feed back experience gained from this activity, so that the
916 next round of standards meets as many of the Internet requirements
927 [BHK91a] Barker, P., and S. Hardcastle-Kille, "The COSINE and
928 Internet X.500 Schema", RFC 1274, Department of Computer
929 Science, University College London, November 1991.
931 [BHK92] Barker, P., and S. Hardcastle-Kille, "Naming Guidelines for
932 Directory Pilots", RFC 1384, Department of Computer Science,
933 University College London, ISODE Consortium, January 1993.
935 [CCI88a] The Directory --- authentication framework, December 1988.
936 CCITT Recommendation X.509.
938 [CCI88b] The Directory --- overview of concepts, models and services,
939 December 1988. CCITT X.500 Series Recommendations.
941 [CCI90] The Directory --- part 9 --- replication, October 1990.
942 ISO/IEC CD 9594-9 Ottawa output.
944 [CFSD90] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A
945 Simple Network Management Protocol", STD 15, RFC 1157,
946 SNMP Research, Performance Systems International, MIT
947 Laboratory for Computer Science, May 1990.
954 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 17]
956 RFC 1430 X.500 Strategy February 1993
959 [For91] The North American Directory Forum, "A Naming Scheme
960 for C=US", RFC 1255, NADF, September 1991.
961 Also NADF-175. (See also RFC 1417.)
963 [For92] The North American directory Forum, "User Bill of Rights
964 for Entries and Listing in the Public Directory", RFC 1295,
965 NADF, January 1992. (See also RFC 1417.)
967 [HK91a] Hardcastle-Kille, S., "Encoding network addresses to
968 support operation over non-OSI lower layers", RFC 1277,
969 Department of Computer Science, University College London,
972 [HK91b] Hardcastle-Kille, S., "Replication and distributed
973 operations extensions to provide an internet directory
974 using X.500", RFC 1276, Department of Computer Science,
975 University College London, November 1991.
977 [HK91c] Hardcastle-Kille, S., "Replication requirement to
978 provide an internet directory using X.500", RFC 1275,
979 Department of Computer Science, University College
980 London, November 1991.
982 [HK91d] Hardcastle-Kille, S., "A string encoding of presentation
983 address", RFC 1278, Department of Computer Science,
984 University College London, November 1991.
986 [HK91e] Hardcastle-Kille, S., "X.500 and domains", RFC 1279,
987 Department of Computer Science, University College
988 London, November 1991.
990 [HK92a] Hardcastle-Kille, S., "A string representation of
991 Distinguished Names", Department of Computer Science,
992 University College London, Work in Progress.
994 [HK92b] Hardcastle-Kille, S., "Using the OSI directory to achieve
995 user friendly naming", Department of Computer Science,
996 University College London, Work in Progress.
998 [HSB91] Howes, R., Smith, M., and B. Beecher, "DIXIE Protocol
999 Specification", RFC 1249, University of Michigan,
1002 [ISO] Procedures for the operation of OSI registration
1003 authorities --- part 1: general procedures. ISO/IEC 9834-1.
1010 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 18]
1012 RFC 1430 X.500 Strategy February 1993
1015 [Ken93] Kent, S., "Privacy Enhancement for Internet Electronic
1016 Mail: Part II - Certificate-based Key Management, RFC 1422,
1019 [Kil88] Kille, S., "The QUIPU Directory Service", In IFIP WG 6.5
1020 Conference on Message Handling Systems and Distributed
1021 Applications, pages 173--186. North Holland Publishing,
1024 [Kil89] Kille, S., "The THORN and RARE Naming Architecture",
1025 Technical report, Department of Computer Science,
1026 University College London, June 1989. THORN Report UCL-64
1029 [Lin93] Linn, J., "Privacy Enhancement for Internet Electronic
1030 Mail: Part I - Message Encryption and Authentication
1031 Procedures", RFC 1421, February 1993.
1033 [LW91] Lang, R., and R. Wright, "A Catalog of Available X.500
1034 Implementations", FYI 11, RFC 1292, SRI International,
1035 Lawrence Berkeley Laboratory, January 1992.
1037 [Lyn91] Lynch, C., "The Z39.50 information retrieval protocol: An
1038 overview and status report", Computer Communication Review,
1039 21(1):58--70, January 1991.
1041 [Par91] Paradise International Report, Cosine. Paradise project,
1042 Department of Computer Science, University College London.
1045 [RC87] Rose, M., and D. Cass, "ISO Transport Services on
1046 top of the TCP", STD 35, RFC 1006, Northrop Corporation
1047 Technology Center, May 1987.
1049 [Ros91] Rose, M., "Directory Assistance Service", RFC 1202,
1050 Performance Systems International, February 1991.
1052 [WR92] Weider, C., and J. Reynolds, "Executive Introduction to
1053 Directory Services Using the X.500 Protocol", FYI 13,
1054 RFC 1308, ANS, ISI, March 1992.
1056 12. Security Considerations
1058 Security issues are discussed in Section 8.
1066 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 19]
1068 RFC 1430 X.500 Strategy February 1993
1071 13. Authors' Addresses
1073 Steve Hardcastle-Kille
1078 Phone: +44-71-223-4062
1079 EMail: S.Kille@isode.com
1087 Phone: +31-30 310290
1088 Email: Erik.Huizer@SURFnet.nl
1092 Corporation for National Research Initiatives
1093 1895 Preston White Drive, Suite 100
1095 Phone: (703) 620-8990
1096 EMail: vcerf@cnri.reston.va.us
1100 University of California, Davis
1104 Phone: (916) 752-0236
1105 EMail: rdhobby@ucdavis.edu
1109 Bolt, Beranek, and Newman
1112 Phone: (617) 873-3988
1113 EMail: skent@bbn.com
1122 Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 20]