As per Relevance of the word strategy, we have this rfc below:
Network Working Group S. Hardcastle-
Request for Comments: 1430 ISODE-
E.
SURFnet
V.
Corporation for National Research
R.
University of California,
S.
Bolt, Beranek and
February 1993
A Strategic Plan for Deploying
Internet X.500 Directory
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
There are a number of reasons why a new Internet Directory Service
required. This document describes an overall strategy for
a Directory Service on the Internet, based on the OSI X.500
Service. It then describes in more detail the initial steps
need to be taken in order to achieve these goals, and how
already undertaken by Internet Engineering Task Force Working
(IETF WGs) is working towards these goals
Table of
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
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 1]
RFC 1430 X.500 Strategy February 1993
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.
There is substantial interest in establishing a new Directory
on the Internet. In the short term, there is pressure to
two new services
- White Pages lookup of users
- Support for X.509 Authentication for a range of applications
particular for Privacy Enhanced mail [Lin89].
In the medium term, there are likely to be many requirements
Directory Services, including
- General resource lookup, for information ranging from
structures to bibliographic data
- Support of management of the Internet infrastructure,
integration of configuration information into the higher
directory
- Support of applications on the Internet. For example
o Electronic distribution lists
o Capability information on advanced user agents
o Location of files and archive services
- Support for Mail Handling Systems; Be they RFC-822 based or X.400
based (IETF MHS-DS WG), e.g.,:
o Support for routing
o Info on User agent capabilities; essential for a usage
Multimedia mail like MIME (Multipurpose Internet
Extensions).
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 2]
RFC 1430 X.500 Strategy February 1993
For the longer term, more sophisticated usages of X.500 are
extending it into a useful and fast yellow pages service
2. SUMMARY OF
In principle, the current Internet Domain Name System (DNS) could
used for many of these functions, with appropriate extensions
However, it is suggested that a higher level of directory service
needed. It is proposed to establish an Internet Directory
based on X.500. This provides appropriate functionality for
services envisaged and gives flexibility for future extension.
extension could be achieved either by tracking the evolution of
OSI Standard or by work specific to the Internet. In practice, it
likely to be a mixture of both
By deploying X.500 in some form on the Internet, a truly global
universal Directory Service can be built that will provide
users with fast access to all kinds of data. The X.500
Service in this case may range from a simple white pages
(information on people and services) to coupling various
databases and information repositories in a universal way
Currently, several different but cooperating X.500 Directory
pilots are taking place on the Internet. These pilots form
important base for experimenting with this new service. Starting
these pilots, with the X.500 products arriving on the market today
and given sufficient funding for the central services described
this paper an operational X.500 Directory Service can be deployed
The final goal of the strategy described in this paper is to deploy
fully operational Directory Service on the Internet, providing
functions mentioned in the previous section
3. INFORMATION
The most critical aspect of the Directory Service is to establish
Internet Information Framework. When establishing a
distributed directory with a coherent information framework,
involves substantial effort to map data onto this framework.
effort is an operational effort and far outweighs the
effort of establishing servers and user agents
3.1 The Technical
By choosing the X.500 model as a basis for the information framework
it will also be part of a (future) global information framework.
key aspects of this model are
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 3]
RFC 1430 X.500 Strategy February 1993
- A hierarchical navigational system that couples
databases (of various kinds), which allows for management of
data by the organization/person responsible for the data
- Each object in this information structure (called the
Information Tree, DIT) is represented as an entry
- Objects are typed by an "object class", which permits
inheritance
- An object is described by a set of attributes
- Each attribute is typed. Attribute types are hierarchical
- Each attribute type has an associated attribute syntax, which
be generic or shared with other attributes (e.g., Integer Syntax
Distinguished name Syntax); This allows for representation
simple attributes (e.g., strings or bitmaps) or complex ones
detailed structures
- Each entry has an unambiguous and unique global name
- Alternate hierarchies may be built by use of aliases or pointers
distinguished name syntax
This framework allows for representation of basic objects such
users within organizations. It is also highly extensible, and so
be used for a range of other applications
3.2 Extending the Technical
In the longer term, the model could be extended to deal with a
of other requirements which potentially must be met by an
Directory Service. Possible extensions include
- Support of ordered attributes (needed by some applications such
message storage);
- Extensions to allow unification with management information
associated with SNMP (Simple Network Management Protocol) [CFSD90]
or other management protocols
- Handling of non-hierarchical data in a better manner for
and retrieval, whilst retaining the basic hierarchy for
purposes. This is essentially building a general purpose
location service on top of the basic infrastructure. It will
work on the information model, and not just the access protocols
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 4]
RFC 1430 X.500 Strategy February 1993
It is noted that although X.500 may not provide the ultimate
to information retrieval, it has good potential for solving a lot
information service related problems
3.3 The Operational
To make the Directory Service with a coherent information
really operational requires a lot of effort. The most
operational model is one where larger organizations on the
maintain their part of the DIT on their own DSA (Directory
Agent). Smaller organizations will "rent" DSA space from
networks or other service providers. Together these DSAs will
the Internet Directory Service Infrastructure. To couple the
parts of the DIT that are contained on these Internet DSAs, a
DSA containing the Root for the naming hierarchy within the DIT
to be established 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;
- Managing the data in the Directory. See section 6.
4. NAME
In order to deploy the Internet Directory Service, it is important
define how the naming hierarchy will be structured. Although
basic model suggests a simple monolithic "database" containing all
the Internet's information infrastructure, with a namespace
along geographic boundaries, this may not be the definite model
turns out to be the most appropriate to the Internet.
models may evolve according to the needs of the Internet and
applications used on the Internet (i.e., some parts of the DIT may
assigned at the root for the Internet). Below this one can
several loosely coupled namespaces each with their own area
applicability. This should be handled as a part of the
operation of a directory service. An example of this might
assignment of a representation of the Domain Namespace under the
of the DIT. This is further discussed in [BHK91a].
However, the core DIT information will be nationally assigned.
parts of the DIT below country level will be managed differently
each country. In many countries, registration authorities will
established according to the OSI Standard [ISO]. This has been
in some countries by the national ISO member body representative (
example in the UK by BSI).
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 5]
RFC 1430 X.500 Strategy February 1993
The lower parts of the hierarchy will, in general, be delegated
organizations who will have control over Name Assignment in that
of the tree. There is no reason to mandate how to assign
hierarchy, although it is appropriate to give guidelines.
solutions to assignment of namespace are given in [BHK92].
In North America, there is an alternative approach being developed
the North American Directory Forum (NADF), which leverages
registration mechanisms [For91]. It is not yet clear what form
final North American Directory Service will take. It is expected
similar initiatives will be taken in other places, such as Europe
For the Internet, the Internet Society (ISOC) has been suggested as
possible Naming Authority
A discussion of the main issues involved with representing the
World in the Directory Service is part of the work undertaken by
IETF OSI DS Working Group
The core of the Internet Directory will therefore come to exist of
country based structure with different national naming schemes
the countries. It is clearly desirable that the Internet
Service follows any evolving national and international hierarchies
However, this should not be allowed to cause undue delay.
strategy proposed is to proceed with name assignment as needed,
to establish interim registration authorities where necessary,
practical steps to be aligned with emerging national
wherever possible
It is suggested that the Internet Directory Service does two things
First, each national part of the Internet DIT namespace should
delegated to an appropriate organization, which will usually be
the country of question. Second, the delegated organization
assign names for that country as part of the Internet
Service. This should be done in a manner which is
aligned with any emerging local or national service, but does
unduly delay the deployment of the Internet Directory Service.
most countries, this will fit in as a natural evolution of the
directory piloting, where operators of pilots have acted as
name registration authorities
5. DIRECTORY
To provide access to the Internet Directory Service,
infrastructure has to be built. Although the technical components
an X.500 infrastructure are clear: DSAs (that hold the actual data
and DUAs (that allow users and applications to access the data),
lot more is needed for deployment of an Internet Directory Service
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 6]
RFC 1430 X.500 Strategy February 1993
The Integrated Directory Services (IDS) Working Group of the IETF
playing a key role in solving most of the issues that are related
the building of an appropriate infrastructure
Many of the issues cited in this section have come forward out
interim pilots that have been established on the Internet
PSI White Pages
This is a pilot service which is operating X.500 on the Internet
In many ways it is operating as an Internet wide pilot
Fielding Operational X.500, a project to explore the
and interoperability of X.500 implementations
Paradise (Piloting A ReseArch DIrectory Service in Europe
This project has been providing the necessary glue to hold
various national activities together [Par91].
5.1 Short Term
- Central Operations. There is a need for a number of
to be managed as a service for the whole Internet. These
are
o A root DSA; containing the top-level of the DIT, has to
provided. Currently, this root DSA is managed by the
project
o Name assignment; Inserting names into the Directory, this
been discussed in section 4. This could be done in
with the appropriate Registration Authority or by
Registration Authority. In most cases it is likely to be
former, and mechanisms will need to be set up to
organizations to get their names installed into the directory
either direct or through the registration authority
o Knowledge management; i.e., the information on "which DSA
what part of the DIT, and how can that DSA be accessed".
will be established by Organizations. There will be a need
centrally coordinate the management of the knowledge
associated with these DSAs. This is likely to be coupled to
name assignment
o Knowledge and Data replication; For the Directory to
well, knowledge and data high up in the DIT must
significantly replicated. A service must be provided to
replicated information available to DSAs that need it
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 7]
RFC 1430 X.500 Strategy February 1993
It is suggested that for the time being, Paradise should be
as the initial basis for handling the top-level of the DIT and
provision of the central services. However, the services
above need to be provided at a national level for
participating country in the Internet Directory Service.
an organization starts a new country branch of the DIT in
Internet Directory Service the central operations will have
help out to make sure that these services will be
installed on a national level
- An effective service will need to have sufficient implementations
in order to give full coverage over different hardware and
platforms, and to demonstrate openness. The recent
Information Services (pilot) Infrastructure Working Group's (DISI
Survey of Directory Implementations suggests that there will not
a problem here. This provides a list of available X.500
implementations and their capabilities [LW91].
- An executive summary, necessary to convince the management
computer centers to invest manpower into setting up a X.500
Directory Service. This is provided by DISI [WR92].
- Due to the possible different and rather independent
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 allow users easy access to the Internet Directory Service
from low powered workstations, a lightweight protocol has to
developed over TCP/IP. Already two private protocols that do
have been developed: The Michigan DIXIE protocol [HSB91] and the
Directory Assistance Service [Ros91]. The IETF OSI
Services Working Group (OSI-DS WG) is currently working on
standard lightweight protocol called LDAP
- Although the Internet Directory Service does not have to make
mandatory requirements about the use of lower layers, it is
that the use of STD 35, RFC 1006 to allow use of OSI applications
top of TCP/IP is essential for deployment in the Internet.
stacks like the ones using CLNS, CONS and X.25(80) will
also be deployed in parts of the Internet. DSAs with
stacks will be linked through use of either application level
(chaining) or Transport Service bridges
- There are multiple issues that are not dealt with (properly) in
X.500 standard and thus prevent the building of an
Directory service. Intermediate solutions for these issues have
be established in an "open" way. The results will have to
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 8]
RFC 1430 X.500 Strategy February 1993
deployed as well as to be fed back into the relevant
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
documentation to help with the provision of support for
users at participating sites
5.2 Medium Term
- Enhanced performance is necessary to allow for a real global usage
- The schema has to be extended to allow for various kinds of data
e.g.,:
o NIC data
o Resource location
- Support for Internet Message Handling services (RFC-822, MIME
X.400). This work is already undertaken by the IETF MHS-DS WG
5.3 Long Term
- To make sure that X.500 evolves into an operational service, it
essential to track its evolution, and to feed back into
evolution process
- Interface existing RDBMS into the Directory Service
- To increase the performance of the directory, and thereby making
useful for an even wider range of applications (e.g., policy
routing), a lightweight protocol for access and system usage
needed
6.
The whole of the Directory Infrastructure won't stand much
without proper datamanagement of the data contained within the DIT
Procedures need to be established to assure a certain Level
Quality of the data contained in the DIT
Due to the very nature of X.500, the management of the data
distributed over various sources. This has the obvious advantage
the data will be maintained by the owner of the data. It
however, make it quite impossible to describe one single
for datamanagement
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 9]
RFC 1430 X.500 Strategy February 1993
For the Internet Directory Service, guidelines will have to
developed (by the IETF IDS WG), to help organizations that start
deployment of X.500 on how to manage data in their part of the DIT
The guidelines should describe a minimum level of quality that has
be supplied to make the service operational. The IETF OSI-DS WG
initiate a pilot on Quality of Service parameters in the Directory
that will be of use
Pilot datamanagement projects will have to be done (e.g.,
databases should be connected to the Internet Directory Service).
Tools that are developed to achieve this should be made available
the Internet community for possible future use
6.1 Legal
Most countries connected to the Internet have some sort of law
dictates how data on people can and cannot be made available.
laws deal with privacy and registration issues, and will differ
country to country. It is suggested that each of the
organizations within the Internet that manages the Internet
Services master for that country, undertake some research as to
applicability of laws within that country on data made public
use of X.500.
In the mean time, a general "User Bill of Rights" should
established to indicate what the proper use of the Internet
Service is. This "Bill of Rights" could be drafted by the IETF
WG. As a basis, the NADF "User Bill of Rights" [For92] can be used
7. TECHNICAL
The IETF has established the OSI-DS WG. The major component of
initial work of this group is to establish a technical framework
deploying a Directory Service on the Internet, making use of
X.500 protocols and services [CCI88b]. This section describes
work already done by this working group, which has been
focused on the technical infrastructure needed to deploy the
Directory service
The OSI Directory Standards do not yet contain sufficient
to enable the Internet Directory Service to be built. Full
and interoperability are a key goal, so we may need Internet
agreements, at least until the ISO standards are more complete.
section notes areas where the standards do not have
coverage, and indicates the RFCs which have been written to
these problems
The work is being limited to (reasonably well) understood issues
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 10]
RFC 1430 X.500 Strategy February 1993
This means that whilst we will attempt to solve a wider range
problems, not all potential requirements will necessarily be met
The technical work is done in conjunction with the RARE WG on
Application Support WG (formerly RARE WG3). The IETF WGs and the
WG have a common technical mailing list. It is intended that
will lead to a common European and North American technical approach
7.1
A Directory needs to be used in the context of an
Framework. The standard directory provides a number of a
and object classes to enable basic operation. It is certain that
Internet community will have requirements for additional
and object classes. There is a need to establish a mechanism
register such information
Pilots in the European RARE Community and the US PSI White
Pilot have based their information framework on the THORN and
Naming Architecture. This architecture should be used for
Internet Directory Service, in conjunction with COSINE based
in Europe. A revised version of the Naming Architecture, with
mechanism for registration of new attributes and object classes,
been released as RFC 1274 [BHK91a].
7.2 Use on the
It is a recognized policy on the Internet to deploy OSI
over non-OSI lower layers (such as STD 35, RFC 1006) [RC87].
policy allows deployment of OSI Applications before an OSI
layer infrastructure has been deployed. Thus, the Internet
Service will decouple deployment of the OSI Directory from
of the OSI lower layers. As the Internet Directory service
extend into the far corners of the Internet namespace, where
underlying technology is not always TCP/IP, the Internet
Service will not make any mandatory requirements about use of
layers. When configuring the Internet Directory Services,
in the lower layers must be considered. The following options
possible
- Operation on top of TCP/IP using a lightweight protocol
- Operation over TCP/IP using STD 35, RFC 1006. This is a
requirement of deployment at very many Internet sites, and is
basis of the existing services. It is highly recommended that
participating DSAs support this stack
- Use of OSI Network Service (Connection Oriented or Connectionless).
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 11]
RFC 1430 X.500 Strategy February 1993
- X.25(80) will probably not be used in the core infrastructure
the Internet Directory Service, but is the basis of some
activities. It may be needed later to interconnect with
commercial systems not on the Internet. There will be a
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
Addresses. This is specified in RFC 1277 [HK91a].
2. It will be desirable to have a uniform method to present
Addresses of this style. Therefore, a string representation
presentation addresses is specified in RFC 1278 [HK91d].
3. This approach leads to the situation where not all DSAs
communicate directly due the different choice of lower layers
This is already a practical result of many European sites
DSAs over X.25. When the Internet Directory Service is deployed
the issue of which DSAs operate which stacks must be considered
order to achieve a coherent service. In particular, there may be
need to require DSAs that serve parts higher up in the DIT to
multiple stacks. This will be tackled as an operational issue
4. There may be a requirement to extend the distributed operations,
that there is no requirement for full connectivity (i.e., each
supports each stack). A solution to this problem, by
"relay DSAs" is specified in RFC 1276 [HK91b].
7.3 Replication of Knowledge and
There are a number of requirements on replication, both of data (
actual information on objects in the directory) and knowledge (
information on where do I find what data) information, which must
met before an Internet Directory can be deployed. The 1988
cannot be used as is, because it does not deal with replication
caching. This leads to serious problems with performance. There is
partial solution available in the 1992 version of the standard
however there are no products available yet that implement
solution. These issues are discussed in more detail in RFC 1275
[HK91c].
As it took too long for 1992 implementations to arrive to be of
help to the already rapidly growing pilot that urgently needed
solution, an option was chosen to use a simple interim approach
defined in RFC 1276. It will be clearly emphasized that this is
interim approach, which will be phased out as soon as the
standards are available and stable implementations are deployed.
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 12]
RFC 1430 X.500 Strategy February 1993
interim approach is based on the approach used in the
Implementation and it is widely deployed in the existing pilots
7.4 Presentation of Directory
The standard does not specify a means to present directory names
the user. This is seen as a serious deficiency, and a standard
presenting directory names is required. For Distinguished Names,
string representation is defined in [HK92a]. However, as
distinguished name is not very friendly for the user, a more
oriented specification of a standard format for representing names
and procedures to resolve them is chosen on the Internet, and
specified in [HK92b].
7.5 DSA Naming and MD
There are some critical issues related to naming of DSAs and
structure of Directory Management Domains. The main issues are
- It is hard to achieve very high replication of
information as this is very widely spread
- There is a need to give DSAs more reasonable names, which
contain an indication on the role of the DSA; This is necessary
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
orders of magnitude. The IETF OSI-DS WG is working to develop
solution in this area
8.
A Directory can be an important component in the overall provision
security in a distributed system environment, especially
public-key cryptographic technology is employed. The directory
serve as a repository for authentication information, which, in turn
forms the basis of a number of OSI Authentication Services (e.g.,
X.400) and non-OSI Services (e.g., privacy-enhanced mail, PEM).
directory may also use this and other stored
information to provide a wide range of security Services used by
Directory system itself
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 13]
RFC 1430 X.500 Strategy February 1993
8.1 Directory Provision of
The directory will be used to provide X.509 strong authentication
This places minimal requirements on the directory. To use
infrastructure, users of authentication services must have access
the directory. In practice, this type of authentication can
deployed only on a limited scale without use of a directory, and
this provision is critical for applications such as Privacy
Mail [Lin93]. The PEM development is considering issues relating
deploying Certification Authorities, and this discussion is
duplicated here
PEM defines a key management architecture based on the use
public-key certificates, in support of the message encipherment
authentication procedures defined in [Lin93]. The PEM
management design [Ken93] makes use of the authentication
defined by X.509. In this framework, as adopted by PEM,
"certification authority" representing an organization applies
digital signature to a collection of data consisting of a user'
public component, various information that serves to identify
user, and the identity of the organization whose signature
affixed. This establishes a binding between these user credentials
the user's public component and the organization which vouches
this binding. The resulting, signed, data item is called
certificate. The organization identified as the certifying
for the certificate is the "issuer" of that certificate. The
of the certificate is defined in X.509.
In signing the certificate, the certification authority vouches
the user's identification, in the context specified by the
of the issuer. Various types of organization may issue certificates
including corporate, educational, professional, or
entities. Moreover, these issuers may operate under
certification policies, so that not all certificates may be
credible (i.e., some certificates may be more trustworthy as
identifiers of users, organizations, mailing lists, etc). The
certificate management design allows for this diversity
certification policies, while ensuring that any certificate can
traced unambiguously to the policy under which it was issued
The digital signature is affixed on behalf of that organization
is in a form which can be recognized by all members of the privacy
enhanced electronic mail community. This ability to
verify any PEM certificate results because the PEM
design is a singly rooted tree, in which the Internet Society acts
the root. Once generated, certificates can be stored in
servers, transmitted via unsecure message exchanges, or
via any other means that make certificates easily accessible
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 14]
RFC 1430 X.500 Strategy February 1993
message originators, without regard for the security of
transmission medium
8.2 Directory
A number of security services are possible with the directory
Peer Authentication at
Authentication (one or two way) between DUA/DSA and DSA/DSA
established during the bind operation. This authentication may
provided using simple passwords (not recommended), one-way
passwords (more secure), or via public key cryptography (
secure). The various authentication options are specified
X.500(88), but most existent implementations implement only
password authentication
Per-operation Authentication and
This is usually used to identify the DUA originating an
to the Directory (e.g., to authenticate prior to
modification). It may also be used to verify the identity of
DSA which provided data in a response to the user. In
examples, the integrity of the data also is ensured through
use of digital signatures. This is specified in X.500(88), but
yet widely implemented
Single Entry Access
This is used to control which users (DUAs) can access and
data within an entry. This is specified in X.500(92) and most
implementations provide this function
Multiple Entry Access
This is used to control search and list operations, in order
allow location of information by searching, but to
"trawling" of information and organizational structure. Usually
these access controls are limited in their ability to
trawling because of the conflicting goal of allowing a
level of legitimate browsing in support of "white pages
functionality
Service
This allows DSAs to control service in a data independent manner
based on peer authentication. For example, one might
students from making non-local queries, while permitting
queries by faculty and staff
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 15]
RFC 1430 X.500 Strategy February 1993
Security
This term encompasses the security goals for which data
control, service authorization, and authentication mechanisms
used to implement. For example, a local security policy
require that all directory database modifications employ
authentication and originate from a computer at a known (local
location
Data
The directory does not include explicit features to protect
confidentiality of data while in transit (e.g., between a DUA
DSA or between DSAs). Instead, it is assured that lower
security protocols or other local security facilities will
employed to provide this security service. Ongoing work
adaptation of the Network Layer Security Protocol (NLSP) is
candidate for provision of this security service with directories
There is no specification of any Internet-wide security policy
directories, nor are there currently any security mechanisms
of all directories. Deployment of a directory could be based on
variety of policies
- Read only system, containing only public data and restricted
local modification
- Use of X.509 authentication, and private access control
(this will not allow open access control management, but this is
seen as a fundamental problem).
It will be important to understand if global Internet
for minimum essential directory security mechanisms will be
to promote widespread use of directories. We recommend that
informational RFC be written to analyze this issue, with
operational policy guidelines or applicability statement RFC
follow
9. RELATION TO
It is important to establish the relationship between the
Internet Directory, and the existing Domain Name System.
Experimental Protocol RFC (RFC 1279) proposes a mapping of
information onto the Directory. Experiments should be conducted
this area [HK91e].
10. EXTERNAL
It will be important for this activity to maintain suitable
liaisons. In particular to
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 16]
RFC 1430 X.500 Strategy February 1993
Other Directory Services and Directory
To ensure a service which is coherent with other groups
X.500 services. e.g.,:
-
-
-
- PSI White
Standards
To feed back experience gained from this activity, so that
next round of standards meets as many of the Internet
as possible. e.g.,:
- CCITT/
- RARE WG-
- EWOS/
-
11.
[BHK91a] Barker, P., and S. Hardcastle-Kille, "The COSINE
Internet X.500 Schema", RFC 1274, Department of
Science, University College London, November 1991.
[BHK92] Barker, P., and S. Hardcastle-Kille, "Naming Guidelines
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, "
Simple Network Management Protocol", STD 15, RFC 1157,
SNMP Research, Performance Systems International,
Laboratory for Computer Science, May 1990.
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 17]
RFC 1430 X.500 Strategy February 1993
[For91] The North American Directory Forum, "A Naming
for C=US", RFC 1255, NADF, September 1991.
Also NADF-175. (See also RFC 1417.)
[For92] The North American directory Forum, "User Bill of
for Entries and Listing in the Public Directory", RFC 1295,
NADF, January 1992. (See also RFC 1417.)
[HK91a] Hardcastle-Kille, S., "Encoding network addresses
support operation over non-OSI lower layers", RFC 1277,
Department of Computer Science, University College London
November 1991.
[HK91b] Hardcastle-Kille, S., "Replication and
operations extensions to provide an internet
using X.500", RFC 1276, Department of Computer Science
University College London, November 1991.
[HK91c] Hardcastle-Kille, S., "Replication requirement
provide an internet directory using X.500", RFC 1275,
Department of Computer Science, University
London, November 1991.
[HK91d] Hardcastle-Kille, S., "A string encoding of
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
London, November 1991.
[HK92a] Hardcastle-Kille, S., "A string representation
Distinguished Names", Department of Computer Science
University College London, Work in Progress
[HK92b] Hardcastle-Kille, S., "Using the OSI directory to
user friendly naming", Department of Computer Science
University College London, Work in Progress
[HSB91] Howes, R., Smith, M., and B. Beecher, "DIXIE
Specification", RFC 1249, University of Michigan
July 1991.
[ISO] Procedures for the operation of OSI
authorities --- part 1: general procedures. ISO/IEC 9834-1.
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 18]
RFC 1430 X.500 Strategy February 1993
[Ken93] Kent, S., "Privacy Enhancement for Internet
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
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
Mail: Part I - Message Encryption and
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:
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
top of the TCP", STD 35, RFC 1006, Northrop
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
Directory Services Using the X.500 Protocol", FYI 13,
RFC 1308, ANS, ISI, March 1992.
12. Security
Security issues are discussed in Section 8.
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 19]
RFC 1430 X.500 Strategy February 1993
13. Authors'
Steve Hardcastle-
ISODE
PO box 505
SW11 1DX
Phone: +44-71-223-4062
EMail: S.Kille@isode.
Erik
SURFnet
PO box 19035
3501 DA
The
Phone: +31-30 310290
Email: Erik.Huizer@SURFnet.
Vinton
Corporation for National Research
1895 Preston White Drive, Suite 100
Reston, VA 22091
Phone: (703) 620-8990
EMail: vcerf@cnri.reston.va.
Russ
University of California,
Computing
Surge II Room 1400
Davis, CA 95616
Phone: (916) 752-0236
EMail: rdhobby@ucdavis.
Steve
Bolt, Beranek, and
50 Moulton
Cambridge, MA 02138
Phone: (617) 873-3988
EMail: skent@bbn.
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
