Stable Implementation Agreements for Open Systems Interconnection Protocols: Part 11 - Directory Services Protocols Output from the March 1994 Open Systems Environment Implementors' Workshop (OIW) SIG Chair: Kenneth J. Rossen, SHL Systemhouse SIG Editor: Michael Ransom, NIST Part 11 - Directory Services Protocols March 1994 (Stable) Foreword This part of the Stable Implementation Agreements was prepared by the Directory Services Special Interest Group (DSSIG)of the Open systems Environment Implementors' Workshop (OIW). See Part 1 - Workshop Policies and Procedures of the "Draft Working Implementation Agreements Document" for the charter. Text in this part has been approved by the Plenary of the above mentioned Workshop. This part replaces the previously existing chapter on Directory Services Protocol. Future changes and additions to this version of these Implementor Agreements will be published as change pages. Deleted and replaced text will be shown as strikeout. New and replacement text will be shown as shaded. ii Part 11 - Directory Services Protocols March 1994 (Stable) Table of Contents Part 11 - Directory Services Protocols . . . . . . . . . . . 1 0 Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 References . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Normative References . . . . . . . . . . . . . . . . 4 2.1.1 Base Edition of the Directory Standard . . 4 2.1.2 Extended Edition of the Directory Standard 5 2.2 Informative References . . . . . . . . . . . . . . . 6 3 Status . . . . . . . . . . . . . . . . . . . . . . . . . 6 4 Use of the Directory . . . . . . . . . . . . . . . . . . 6 5 Directory ASEs and Application Contexts . . . . . . . . . 7 6 Schema . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1 Support of Structures and Naming Rules . . . . . . . 8 6.2 Support of Object Classes and Subclasses . . . . . . 9 6.3 Support of Attribute Types . . . . . . . . . . . . . 9 6.4 Support of Attribute Syntaxes . . . . . . . . . . . 9 6.5 Naming Contexts . . . . . . . . . . . . . . . . . . 10 6.6 Common Profiles . . . . . . . . . . . . . . . . . . 10 6.6.1 OIW Directory Common Application Directory Profile . . . . . . . . . . . . . . . . . . 10 6.6.1.1 Standard Application Specific Attributes and Attribute Sets . . . . . . . . . . . . 10 6.6.1.2 Standard Application Specific Object Classes . . . . . . . . . . . . . . . . . . 10 6.6.2 OIW Directory Strong Authentication Directory Profile . . . . . . . . . . . . . 11 6.6.2.1 Other Profiles Supported . . . . . . . . . 11 6.6.2.2 Standard Application Specific Object Classes . . . . . . . . . . . . . . . . . . 11 6.7 Restrictions on Object Class Definitions . . . . . . 11 7 Pragmatic Constraints . . . . . . . . . . . . . . . . . . 12 7.1 General Constraints . . . . . . . . . . . . . . . . 12 7.1.1 Character Sets . . . . . . . . . . . . . . 12 7.1.2 DSP APDU Size . . . . . . . . . . . . . . . 12 7.1.3 Service Control (SC) Considerations . . . . 12 7.1.4 Priority Service Control . . . . . . . . . 13 7.2 Constraints on Operations . . . . . . . . . . . . . 14 7.2.1 Filters . . . . . . . . . . . . . . . . . . 14 iii Part 11 - Directory Services Protocols March 1994 (Stable) 7.2.2 Errors . . . . . . . . . . . . . . . . . . 15 7.2.3 Error Reporting - Detection of Search Loop 15 7.3 Constraints Relevant to Specific Attribute Types . . 15 8 Conformance . . . . . . . . . . . . . . . . . . . . . . . 16 8.1 DUA Conformance . . . . . . . . . . . . . . . . . . 16 8.2 DSA Conformance . . . . . . . . . . . . . . . . . . 17 8.3 DSA Conformance Classes . . . . . . . . . . . . . . 17 8.3.1 Conformance Class 0 - Centralized DSA . . . 18 8.3.2 Conformance Class 1 - Distributed DSA . . . 18 8.4 Authentication Conformance . . . . . . . . . . . . . 18 8.5 Directory Service Conformance . . . . . . . . . . . 20 8.5.1 Service Conformance . . . . . . . . . . . . 20 8.5.1.1 r: required . . . . . . . . . . . . . . . . 20 8.5.1.2 n: not required . . . . . . . . . . . . . . 20 8.5.2 Protocol Conformance . . . . . . . . . . . 21 8.5.2.1 M: mandatory . . . . . . . . . . . . . . . 21 8.5.2.2 G: generate . . . . . . . . . . . . . . . . 21 8.5.2.3 S: support . . . . . . . . . . . . . . . . 21 8.5.2.4 O: optional . . . . . . . . . . . . . . . . 21 8.6 The Directory Access Profile . . . . . . . . . . . . 22 8.7 The Directory System Profile . . . . . . . . . . . . 23 8.8 Digital Signature Protocol Conformance Profile . . . 23 8.9 Strong Authentication Protocol Conformance Profile . 23 8.10 Subtree Specification Classes . . . . . . . . . . . 23 8.11 Replication Conformance . . . . . . . . . . . . . . 24 8.11.1 Shadowing Roles . . . . . . . . . . . . . . 24 8.11.2 Minimum Shadowing Requirements . . . . . . 24 8.11.3 Support for Unit of Replication . . . . . . 24 8.12 Recommended Practices for Shadowing . . . . . . . . 26 8.12.1 APDU Size . . . . . . . . . . . . . . . . . 26 8.12.2 Duplicate Shadow Agreements . . . . . . . . 26 8.12.3 Consistency Between Supplier and Consumer Information . . . . . . . . . . . . . . . . 26 8.12.4 Management of Shadowing Agreements Without DOP . . . . . . . . . . . . . . . . . . . . 27 9 Distributed Operations . . . . . . . . . . . . . . . . . 27 9.1 Static Requirements . . . . . . . . . . . . . . . . 27 9.1.1 Reference Types . . . . . . . . . . . . . . 27 9.1.2 Superior References and Root Contexts . . . 28 9.1.2.1 First-Level DSAs . . . . . . . . . . . . . 28 9.1.2.2 Return-Cross-References . . . . . . . . . . 28 9.1.3 Support of Application Contexts . . . . . . 28 9.1.4 DSA-level Security . . . . . . . . . . . . 28 9.1.5 Aliases . . . . . . . . . . . . . . . . . . 29 9.1.6 Authentication for DSA Bind . . . . . . . . 29 9.1.7 Authentication of User Whose Entry Is Held by Another DSA . . . . . . . . . . . . . . 29 9.2 Dynamic Requirements . . . . . . . . . . . . . . . . 29 iv Part 11 - Directory Services Protocols March 1994 (Stable) 9.2.1 Detection of Search Loop . . . . . . . . . 29 9.2.2 Generation of Trace Information . . . . . . 29 9.2.3 Integrity of Operation Arguments . . . . . 30 9.2.4 Referrals and Chaining . . . . . . . . . . 30 10 Underlying Services . . . . . . . . . . . . . . . . . . . 30 10.1 ROSE . . . . . . . . . . . . . . . . . . . . . . . . 30 10.2 Session . . . . . . . . . . . . . . . . . . . . . . 31 10.3 ACSE . . . . . . . . . . . . . . . . . . . . . . . . 31 11 Access Control . . . . . . . . . . . . . . . . . . . . . 31 12 Test Considerations . . . . . . . . . . . . . . . . . . . 31 12.1 Major Elements of Architecture . . . . . . . . . . . 31 12.2 Search Operation . . . . . . . . . . . . . . . . . . 33 13 Errors . . . . . . . . . . . . . . . . . . . . . . . . . 33 13.1 Permanent vs. Temporary Service Errors . . . . . . . 33 13.2 Guidelines for Error Handling . . . . . . . . . . . 33 13.2.1 Introduction . . . . . . . . . . . . . . . 34 13.2.2 Symptoms . . . . . . . . . . . . . . . . . 34 13.2.3 Situations . . . . . . . . . . . . . . . . 34 13.2.4 Error Actions . . . . . . . . . . . . . . . 34 13.2.5 Reporting . . . . . . . . . . . . . . . . . 35 14 Specific Authentication Schemes . . . . . . . . . . . . . 36 14.1 Specific Strong Authentication Schemes . . . . . . . 36 14.1.1 ElGamal . . . . . . . . . . . . . . . . . . 36 14.1.2 One-Way Hash Functions . . . . . . . . . . 36 1 4 . 1 . 2 . 1 SQUARE-MOD-N Algorithm . . . . . . . . . . 37 1 4 . 1 . 2 . 2 MD2 Algorithm . . . . . . . . . . . . . . . 37 1 4 . 1 . 2 . 3 Use of One-Way Hash Functions in Forming Signatures . . . . . . . . . . . . . . . . 37 14.1.3 ASN.1 for Strong Authentication Algorithms 37 14.2 Protected Simple Authentication . . . . . . . . . . 42 14.3 Simple Authentication . . . . . . . . . . . . . . . 42 Annex A (normative) Maintenance of Attribute Syntaxes . . . . . . . . . . . . . . 116 A.1 Introduction . . . . . . . . . . . . . . . . . . . . 116 A.2 General Rules . . . . . . . . . . . . . . . . . . . 116 A.3 Checking Algorithms . . . . . . . . . . . . . . . . 116 A.3.1 distinguishedNameSyntax . . . . . . . . . . 117 A.3.2 integerSyntax . . . . . . . . . . . . . . . 117 A.3.3 telephoneNumberSyntax . . . . . . . . . . . 117 A.3.4 countryName . . . . . . . . . . . . . . . . 117 v Part 11 - Directory Services Protocols March 1994 (Stable) A.3.5 preferredDeliveryMethod . . . . . . . . . . 117 A.3.6 presentationAddress . . . . . . . . . . . . 117 A.4 Matching Algorithms . . . . . . . . . . . . . . . . 117 A.4.1 UTCTimeSyntax . . . . . . . . . . . . . . . 118 A.4.2 distinguishedNameSyntax . . . . . . . . . . 118 A.4.3 caseIgnoreListSyntax . . . . . . . . . . . 118 Annex B (informative) Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Annex C (informative) Requirements for Distributed Operations . . . . . . . . . . . 122 C.1 General Requirements . . . . . . . . . . . . . . . . 122 C.2 Protocol Support . . . . . . . . . . . . . . . . . . 122 C.2.1 Usage of ChainingArguments . . . . . . . . 122 C.2.2 Usage of ChainingResults . . . . . . . . . 123 Annex D (informative) Guidelines for Applications Using the Directory . . . . . . . 124 D.1 Tutorial . . . . . . . . . . . . . . . . . . . . . . 124 D.1.1 Overview . . . . . . . . . . . . . . . . . 124 D.1.2 Use of the Directory Schema . . . . . . . . 124 D.1.2.1 Use of Existing Object Classes . . . . . . 124 D.1.2.2 Kinds of Object Classes . . . . . . . . . . 124 D.1.2.3 Use of Unregistered Object Classes . . . . 125 D.1.2.4 Side Effects of Creating Unregistered Object Classes . . . . . . . . . . . . . . 127 D.2 Creation of New Object Classes . . . . . . . . . . . 128 D.2.1 Creation of New Subclasses . . . . . . . . 128 D.2.2 Creation of New Attributes . . . . . . . . 129 D.3 DIT Structure Rules . . . . . . . . . . . . . . . . 129 D.4 Use of AETITLE . . . . . . . . . . . . . . . . . . . 129 Annex E (informative) Template for an Application Specific Profile for Use of the Directory . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Annex F (informative) Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 132 vi Part 11 - Directory Services Protocols March 1994 (Stable) List of Figures Figure 1 - Centralized directory model . . . . . . . . . . . 2 Figure 2 - Distributed directory model . . . . . . . . . . . 3 Figure 3 - Logical DSA application environment . . . . . . . 14 Figure 4 - Three ways of creating two object classes . . . . 127 vii Part 11 - Directory Services Protocols March 1994 (Stable) List of Tables Table 1 - Pragmatic constraints for selected attributes . . . 43 Table 2 - Directory access service support . . . . . . . . . 48 Table 3 - DAP protocol support . . . . . . . . . . . . . . . 50 Table 4 - Directory system service support . . . . . . . . . 62 Table 5 - DSP protocol support . . . . . . . . . . . . . . . 64 Table 6 - DAP Support for Digital Signature Protocol Conformance Profile. . . . . . . . . . . . . . . . . . . 80 Table 7 - DSP support for digital signature protocol conformance profile . . . . . . . . . . . . . . . . . . 81 Table 8 - DAP support for strong authentication protocol conformance profile . . . . . . . . . . . . . . . . . . 82 Table 9 - DSP support for strong authentication protocol conformance profile . . . . . . . . . . . . . . . . . . 83 Table 10 - Error symptoms . . . . . . . . . . . . . . . . . . 84 Table 11 - Error situations . . . . . . . . . . . . . . . . . 91 Table 12 - Notation used to describe error actions. . . . . . 92 Table 13 - Error actions . . . . . . . . . . . . . . . . . . 95 Table 14 - Simple credential fields and protected simple authentication . . . . . . . . . . . . . . . . . . . . . 115 viii Part 11 - Directory Services Protocols 0 Introduction Editor's Note - the text in this Implementation Agreement will be significantly reorganized in 1994 due to the alignment and submission by Regional Workshops of International Standardized Profiles ISO/IEC pdISP 10615 and 10616. The text in tese pdiSPs, in some cases containing technical changes, will replace substantial segments of the text in this Agreement. In addition, text addressing the forthcoming 1993 edition of the Directory Documents, currently interspersed among sections of this Agreement, will be moved to a new Agreement appearing in Part 28 of this document and expanded. Please refer to the aligned part of the Working Agreements Document for the most recent results of these realignments. In the interim, where ISP text conflicts with the text of this Agreement, the ISP text is considered to have precedence. This is an Implementation Agreement developed by the Implementor's Workshop sponsored by the National Institute of Standards and Technology to promote the useful exchange of data between devices manufactured by different vendors. This agreement is based on and employs protocols developed in accord with the OSI Reference Model. While this agreement introduces no new protocols, it eliminates ambiguities in interpretations. This is an Implementation Agreement for the OSI Directory based on the ISO and CCITT documents cited in clause 2 of this part(hereafter referenced as Directory Documents). Where technical differences between the ISO and CCITT texts of these documents exist (e.g., Transport Requirements) the ISO texts are given precedence. The Directory User Agents (DUAs) and Directory System Agents (DSAs) provide access to The Directory on behalf of humans and applications such as Message Handling and File Transfer, Access, and Management. See clause 1 for more information on the model used in the Directory. This document covers the Directory Access Protocol (DAP), the Directory System Protocol(DSP), and the Directory Information Shadowing Protocol (DISP) defined in the Directory Documents. A good working knowledge of the Directory Documents is assumed by this chapter. All terminology and abbreviations used but not defined in this text may be found in those documents. 1 Part 11 - Directory Services Protocols March 1994 (Stable) 1 Scope Centralized and distributed directories can both be accommodated in this Agreement by the appropriate choice of protocols and pragmatic constraints from those specified. Figure 1 illustrates a centralized directory and figure 2 illustrates a distributed directory. This agreement does not cover interaction between co-located entities, such as a co-resident DUA and DSA. It also does not specify the interface between a user (person or application) and a DUA.Bilateral agreements between a DUA and DSA or DSA and DSA may be implemented in addition to the requirements stated in this document. Conformance to this agreement requires the ability to interact without the use of bilateral agreements other than those required in the Directory Documents. The logical structure of the Directory Information Base (DIB) is described in the Directory Documents. The manner in which a local portion of the DIB is organized and accessed by its DSA is not in the scope of this agreement. +--------------------------------------------------------------+ | | | | | | | The Directory | | +------------+ | | +----------+ +----------+ | | | | | USER |<---->| DUA |<--------- ->| | | | +----------+ +----------+ | | | | | DSA | | | +----------+ +----------+ | | | | | USER |<---->| DUA |<--------- ->| | | | +----------+ +----------+ +------------+ | | | | | | | +--------------------------------------------------------------+ Figure 1 - Centralized directory model 2 Part 11 - Directory Services Protocols March 1994 (Stable) +---------------------------------------------------------------+ | | | +--------+ | | | User | | | +---+----+ | | +---+----+ | | | DUA | | | +---+----+ | | | | | | | +------+ +------+ The Directory| | | | User +-+ DUA | +---+----+ | | +------+ +------+ | DSA | | | +--------+ | | +--------+ +--------+ | | | DSA | | DSA | | | +--------+ +--------+ | | +------+ +------+ +--------+ +-----+ +------+| | | User +-+ DUA | | DSA | | DUA +-+ User || | +------+ +------+ +--------+ +-----+ +------+| | | | | +---------------------------------------------------------------+ Figure 2 - Distributed directory model 3 Part 11 - Directory Services Protocols March 1994 (Stable) 2 References 2.1 Normative References 2.1.1 Base Edition of the Directory Standard ISO/IEC 9594-1:1990(E),Information Technology - Open Systems Interconnection - The Directory - Part 1: Overview of Concepts, Models, and Services. ISO/IEC 9594-2:1990(E),Information Technology - Open Systems Interconnection - The Directory - Part 2: Models. ISO/IEC 9594-3:1990(E),Information Technology - Open Systems Interconnection - The Directory - Part 3: Abstract Service Definition. ISO/IEC 9594-4:1990(E),Information Technology - Open Systems Interconnection - The Directory - Part 4: Procedures for Distributed Operation. ISO/IEC 9594-5:1990(E),Information Technology - Open Systems Interconnection - The Directory - Part 5: Protocol Specifications. ISO/IEC 9594-6:1990(E),Information Technology - Open Systems Interconnection - The Directory - Part 6: Selected Attribute Types. ISO/IEC 9594-7:1990(E),Information Technology - Open Systems Interconnection - The Directory - Part 7: Selected Object Classes. ISO/IEC 9594-8:1990(E),Information Technology - Open Systems Interconnection - The Directory - Part 8: Authentication Framework. CCITT Recommendation X.500:1988,The Directory - Overview of concepts, Models and Services. CCITT Recommendation X.501:1988,The Directory - Models. CCITT Recommendation X.509:1988,The Directory - Authentication Framework. CCITT Recommendation X.511:1988,The Directory - Abstract Service 4 Part 11 - Directory Services Protocols March 1994 (Stable) Definition. CCITT Recommendation X.518:1988,The Directory - Procedures for Distributed Operations. CCITT Recommendation X.519:1988,The Directory - Protocol Specifications. CCITT Recommendation X.520:1988,The Directory - Selected Attribute Types. CCITT Recommendation X.521:1988,The Directory - Selected Object Classes. 2.1.2 Extended Edition of the Directory Standard The following references represent a forthcoming edition of the OSI Directory standard. Alignment to that edition within these agreements is only where explicitly indicated within particular subclauses. ISO/IEC 9594-1 / DAM-1.2 for Replication, Schema, and Access Control. ISO/IEC 9594-2 / DAM-1.3 for Access Control. ISO/IEC 9594-2 / DAM-2.2 for Schema. ISO/IEC 9594-2 / DAM-3.2 for Replication. ISO/IEC 9594-3 / DAM-1.3 for Access Control. ISO/IEC 9594-3 / DAM-2.2 for Replication, Schema, and Enhanced Search. ISO/IEC 9594-4 / DAM-1.3 for Access Control. ISO/IEC 9594-4 / DAM-2.2 for Replication, Schema, and Enhanced Search. ISO/IEC 9594-5 / DAM-1.2 for Replication. ISO/IEC 9594-6 / DAM-1.2 for Schema. ISO/IEC 9594-7 / DAM-1.2 for Schema. ISO/IEC 9594-8 / DAM-1.2 for Access Control. ISO/IEC 9594-9 / DIS for Replication. 5 Part 11 - Directory Services Protocols March 1994 (Stable) 2.2 Informative References Directory Implementors' Guide, Version 7, November 1992. 3 Status This version was completed in December 1992. 4 Use of the Directory Given the rapid multiplication and expansion of OSI applications, telecommunication systems and services, there is growing need for users of OSI applications, as well as the applications themselves, to communicate with each other. In order to facilitate their communications, a Directory protocol, as referenced in these agreements, has been tailored to meet their respective needs. In one instance, The Directory will be used as a service to provide humans, in an on-line fashion, rapid and easy retrieval of information useful for determining what telecommunications services are available, and/or how to access, and address their correspondents. Further, service providers offering such a Public Directory may also use this service internally with other various telecommunications services (e.g., MHS) for the proper addressing of calls or messages. Likewise, this does not preclude the usage of these agreements to similarly generate a privately operated Directory that supports both human and application information exchanges. In another instance, The Directory, will be used as a service by computer applications without direct human involvement. One important service is to provide Presentation Address resolution for named objects, on behalf of OSI applications. The Directory may be used by applications to search for objects (i.e., Application Entities), without direct human involvement, by the use of the "search" or "list" operations. To support the many possible usages, The Directory is a general purpose system. It is capable of storing data of many different forms as attributes within entries, and is also capable of supporting simple or complex hierarchical structures, with variations in structure possibly occurring between one part of The Directory and another. Compliant DSA implementations should safeguard this generality, where possible, by placing the minimum of restrictions in 6 Part 11 - Directory Services Protocols March 1994 (Stable) "hard-wired" form. 5 Directory ASEs and Application Contexts This clause highlights the ASEs (Application Service Elements) and Application Contexts defined in the Directory Documents and of concern in these Agreements. The functionality of the Directory AEs (DUAs and DSAs) is defined by a set of ASEs, each Directory ASE specifying a set of Directory operations. The interaction between these AEs is described in terms of their use of ASEs. This specific combination of a set of ASEs and the rules for their usage defines an application context. The following ASEs are described in the Directory Documents: a) Read ASE f) Chained Modify ASE b) Chained ASE g) Operational Binding Management ASE c) Search ASE h) Shadow Supplier ASE d) Chained Search i) Shadow Consumer ASE ASE e) Modify ASE ROSE and ACSE also form part of the Directory Application Contexts. The following Application Contexts (ACs) are described in the Directory Document: a) Directory Access Application e) Shadow Consumer AC Initiated AC b) Directory System AC f) Reliable Shadow Supplier Initated AC c) Directory Operational g) Reliable Shadow Consumer Binding Management AC Initated AC d) Shadow Supplier Initiated AC 7 Part 11 - Directory Services Protocols March 1994 (Stable) 6 Schema There are seven (7) major topics that relate to schema. 6.1 Support of Structures and Naming Rules DSAs shall be capable of supporting (subject to refinements laid down in these Agreements) the structure and naming rules defined in the Directory Documents, Part 7, Annex B. Part 7, Annex B of the Directory Documents provides a framework for the basic use of the Directory in terms of the objects defined in Part 7. It does not, however, form part of the standard and,in any case, permits structures and practices which may be undesirable.The guidelines below provide tighter control within the Annex B framework. It is recommended that only an entry subordinate to Root or Country may use a StateOrProvinceName AVA 8 Part 11 - Directory Services Protocols March 1994 (Stable) as an RDN. 6.2 Support of Object Classes and Subclasses The DSAs shall be able to support all superclasses of the supported object classes (e.g., Top, Person). Use of an object class in this profile or the standard (or a subclass derived from one or more of these object classes)is recommended wherever the semantics are appropriate for the application.The derivation of a new object class as an immediate subclass of Top should be avoided. For example, to represent printers in the Directory, one can derive a subclass of Device. An entry of a particular object class may contain any optional attribute listed for it in the Directory Documents; a conformant DSA shall be able to support all these optional attributes. In addition, a DSA may permit any locally registered attribute, or a subset of these, by providing the local extension facilities permitted by unregistered object classes (viz. Directory Documents, Part 2, clause 9.4.1 (a) and Note). 6.3 Support of Attribute Types DSAs shall be able to support the storage and use of attribute type information, as defined in the Directory Documents, Part 6, including their use in naming and access to entries; they shall also support the definition of new attribute types, making use of pre-existing attribute syntaxes. DSAs shall support the encoding, decoding, and matching of all the attributes in the Naming Prefixes of every naming context they hold (ref Directory Documents, Part 4, clause 9). These attributes may include attributes that are not permitted to appear in entries in those naming contexts. 6.4 Support of Attribute Syntaxes Suggested methods for the interpretation of selected Attribute Syntaxes are defined in annex A. 9 Part 11 - Directory Services Protocols March 1994 (Stable) 6.5 Naming Contexts The root of a naming context shall not be an alias entry. 6.6 Common Profiles This subclause identifies profiles that are commonly useful for various applications while an application-specific profile(s) is identified by the application. 6.6.1 OIW Directory Common Application Directory Profile 6.6.1.1 Standard Application Specific Attributes and Attribute Sets The attributes and attribute sets in the Directory Document, Part 6, associated with the object classes listed below are required. 6.6.1.2 Standard Application Specific Object Classes DSAs shall be able to support storage and use of the object classes below, as defined in the Directory Documents, Part 7, and these object classes are expected to be useful for a range of applications. The following object classes are mandated by the standard: a) Top; b) DSA; c) Alias. The following object classes are expected to be generally useful in the creation of the upper portion of the DIT: a) Country; b) Locality; c) Application Process; d) Organization; e) OrganizationalUnit. 10 Part 11 - Directory Services Protocols March 1994 (Stable) The following object classes are expected to be generally useful in the creation of DIT leaf entries: a) Alias; b) ApplicationProcess; c) ApplicationEntity; d) DSA; e) Device; f) Group of Names; g) OrganizationalPerson; h) OrganizationalRole; i) ResidentialPerson. 6.6.2 OIW Directory Strong Authentication Directory Profile 6.6.2.1 Other Profiles Supported This profile is used in conjunction with the OIW Directory Common Application Directory Profile. 6.6.2.2 Standard Application Specific Object Classes The following object classes are expected to be generally useful for applications to support strong authentication: a) Strong Authentication User; b) Certification Authority. 6.7 Restrictions on Object Class Definitions An object class may not be defined as a subclass of itself, as the chain of superclasses of such an object class would be a closed loop, isolated from all other object classes, specifically Top. Such isolation is clearly illegal. 11 Part 11 - Directory Services Protocols March 1994 (Stable) 7 Pragmatic Constraints This clause describes pragmatic constraints to which a conformant implementation shall adhere in addition to those specified in the Directory Documents. The pragmatic constraints can be divided into two major areas. The first includes those aspects of pragmatic constraints which apply to scope of service (see 7.1 and 7.2). The second includes those aspects of pragmatic constraints which are specific to particular attribute types (see 7.3). 7.1 General Constraints 7.1.1 Character Sets It is a requirement to support all character sets and other name forms defined in the Directory Documents, Part 6. Those character sets include: a) T.61; b) PrintableString; c) NumericString. 7.1.2 DSP APDU Size In the process of chaining requests it is possible that a chaining DSA may receive, invoke or return APDUs that exceed its capacity. It is a minimum requirement that invoke APDUs and return result APDUs shall be accepted unless they exceed 2**18 - 1 (i.e., 262,143) octets in size;in this case they may be discarded and an "unwillingToPerform" error reporting service shall be used. 7.1.3 Service Control (SC) Considerations This agreement recognizes that DUAs may automatically supply defaults for any SC parameter. The choice of default values selected (if any) is seen to be a matter of local policy and consumer needs. 12 Part 11 - Directory Services Protocols March 1994 (Stable) 7.1.4 Priority Service Control Priority is specified as a service control argument in the Directory Documents. The following statements represent a clarification of the semantics that may be used by a DSA in interpreting and operating on this parameter. The logical model in figure 3 may be considered as an example by DSAs that implement this Service Control. In figure 3, note that: a) the DSA maintains three logical queues corresponding to the three priority levels; b) the DSA Scheduler is separate and distinct from any scheduling function provided by the underlying operating system or control program services; c) the DSA Scheduler presents jobs to the Underlying Operating Services for execution and always presents jobs of a higher priority before those of a lower priority; d) the DSA Scheduler will not preempt a request once it has been passed to the underlying operating system service. 13 Part 11 - Directory Services Protocols March 1994 (Stable) +-----------------------------------------------------------+ | +-------------+ | | +--------------+ | | | | +--->| High +----> | \/ | | | +--------------+ | +--------------+ | | | +--------------+ | | DSA | | | +--->| Medium +----> | | Scheduler | | | | +--------------+ | +------+-------+ | | | +--------------+ | | | | +--->| Low +----> | \/ | | | +--------------+ | +--------------+ | | +---+----------------+ | Underlying OS| | | | Underlying | | Services | | | | Protocol Services | +--------------+ | | +--------------------+ | +-----------------------------------------------------------+ Figure 3 - Logical DSA application environment 7.2 Constraints on Operations There are no overall constraints upon service arguments or results except those implied in 7.1.2 of this document. 7.2.1 Filters It is required that DSAs, at a minimum, support 8 nested "Filter" parameters, and a total limit of 32 Filter Items.If these limits are exceeded, the recipient of that Search Argument may return the Service Problem "unwillingToPerform." 14 Part 11 - Directory Services Protocols March 1994 (Stable) 7.2.2 Errors There are no constraints upon any Error service except the APDU size limit as defined in 7.1.2. 7.2.3 Error Reporting - Detection of Search Loop A search operation may encounter a looping situation when the search encompasses "whole-subtree," and an alias is encountered which is a superior to some other subtree that has been encountered during the search. DSAs should be able to detect this situation. One possible method is by: a) Maintaining a list of the base objects of searches initiated as a consequence of Step 5 of Part 4, clause 18.7.2.2.1 of the Directory Documents (this may require an analysis of the TraceInformation field); b) Determining whether a new base object is superior to any base object on this list. A new base object which would cause a loop in this way should be discarded (i.e., should not cause a new search), but no error should be reported by an error-reporting service. The circumstances should be logged so that it may be reported to an appropriate Administrative Authority for rectification. 7.3 Constraints Relevant to Specific Attribute Types Table 1 gives pragmatic constraints associated with selected attribute types specified in the Directory Documents; many of these constraints also appear and are the same in the CCITT version of the Directory Documents. Each constraint in table 1 is given in terms of a length constraint. The length constraint for a given attribute value is the number of units which a sending entity shall not exceed and which a receiving entity shall accept and process. A sending entity need not be capable of sending attribute values as large as the length constraints. Note that in table 1 the length constraint for strings is expressed as the number of allowable characters. In addition to the constraints given in table 1, the following constraints apply to alphabets and integer values: 15 Part 11 - Directory Services Protocols March 1994 (Stable) a) Alphabets: T.61 Strings used as attribute values shall only encode graphic characters and spaces. They shall not contain formatting characters (such as subscript) or other control characters; b) Integer Values: DSAs shall be required to "pass through" encoded integer attribute values of arbitrary length (e.g., when chaining a Directory operation). No Directory component (i.e., DUA or DSA) shall be deemed non-conformant if it encodes integer attribute values of arbitrary length. Components of the Directory are required to support (for storage and processing), as a minimum, integer attribute values encoded in 4 octets. 8 Conformance The following subclauses will describe various aspects of Directory conformance. It should be noted that conformance to the various ASEs and conformance to the Authentication Framework are viewed as separate issues and are presented in that context. 8.1 DUA Conformance Conformance requirements for DUAs are adequately specified in the Directory Documents, Part 5, clause 9.1 and the Directory Access Profile (see 8.6). It should be noted that the DUA conformance is based on DAP Protocol and not the User Interface. Not all options available in the standard need to be made available to the user of the DUA. It is recognized that DUAs will be widely differing in nature: a) Some are intended to support human users, some application users; b) Particular DUAs may not support particular operations because the application that they support has no requirement; others will be general purpose, and will support all operations; c) Some DUAs will have a fixed view of the Directory content and structure, reflecting the usage of The Directory by a particular application; others will have a more flexible view which can be adapted to new usages; d) Some DUAs will provide automatic referral services with automatic establishment and release of associations; others 16 Part 11 - Directory Services Protocols March 1994 (Stable) will place the burden on the user; e) Some DUAs will provide a variety of authentication means; others will support no authentication; f) Some DUAs will handle operations synchronously; others will have the capability of maintaining several identifiable dialogues with The Directory at one time. In the next subclause, different types of DSAs are discussed. The DUA is independent of the type of DSA it is communicating with and does not need to know what type of DSA it is communicating with. 8.2 DSA Conformance Basic conformance requirements for a DSA are defined in the Directory Documents, Part 5, clause 9.2. Some of the terms used to describe DSA conformance are summarized below: a) Centralized: A centralized DSA is defined as one that contains its entire relevant DIT; it follows that it will not make use of the DSP or generate referral responses. Since this model only contains a single DSA it is not subject to DSA interworking issues and will always provide a consistent level of service and results. A centralized DSA shall be fully "protocol" conformant to the DAP; b) Cooperating: In a distributed directory, responsibility for various portions of the DIT may be "distributed" among multiple DSAs. On a per operation basis we define a DSA to be holding when it is responsible for the fragment of the DIB in which a given entry will appear if it exists; we define a DSA to be propagating when it is unable to complete the name resolution process. All DSAs shall be capable of acting as a holder and a propagator. 8.3 DSA Conformance Classes A DSA implementation shall satisfy the conformance requirements as defined in the Directory Documents, Part 5, subclause 9.2,and shall support the "Versions" argument of "Bind." Per the conformance clause of the Directory Documents, a DSA shall conform to the abstract syntax of the attribute types for which conformance is claimed. These attribute types shall include those required by 6.3 of this Implementor's Agreement. 17 Part 11 - Directory Services Protocols March 1994 (Stable) Additionally, an implementation conformant to these agreements shall state which of the following conformance classes it implements: 8.3.1 Conformance Class 0 - Centralized DSA A DSA conformant to this class only supports the DirectoryAccessAC. As the performance of Search and List operations can consume significant resources, the policies of some centralized DSAs may be such that these operations will not be performed. For these cases, the reply to requests for such operations would be a Service Error with the "unwillingToPerform" Service Problem. 8.3.2 Conformance Class 1 - Distributed DSA A DSA implementation conformant to this class shall implement all the operations in the ASEs that are part of the Application context for which it claims conformance. It shall support the DirectoryAccessAC and it may optionally support the DirectorySystemAC. DSAs conformant to these Agreements shall support the OIW Directory Common Application Directory Profile. In addition, DSAs may optionally conform to the OIW Directory Strong Authentication Directory Profile. Future versions of these Agreements may allow additional possibilities for minimal profile conformance. 8.4 Authentication Conformance A Directory System may choose to implement various levels of authentication (Directory Documents, Part 8). We define the following levels of authentication in the DS: a) No authentication at all; (None); b) Simple Uncorroborated: identification without verification; c) Simple Uncorroborated authentication with verification: verified identification without a password; d) Simple Corroborated authentication: verified identification with a password; intended to make masquerading difficult; 18 Part 11 - Directory Services Protocols March 1994 (Stable) e) Strong authentication: identification with verification using cryptographic techniques intended to make masquerading, in practical terms, nearly impossible. The "Authentication Framework" document describes the specific goal of each authentication level; listed below are several practical uses of the various levels.1 Simple Uncorroborated authentication may be desired to maintain access statistics or in a private network where the initiator is implicitly trusted and there is no need to incur the additional overhead of more sophisticated authentication methods. Simple Corroborated authentication may be necessary in situations where strong authentication is not practical, (i.e., international connection, no knowledge of algorithms in use, etc.). Strong authentication will be required for secure environments. A DSA that implements Simple Corroborated authentication will check the user password by means of a compare operation on the user's entry. If no user password is supplied (Simple Uncorroborated authentication) the DSA will validate the presence of the entry for the user, by a read operation or otherwise. The authentication will fail if the password is incorrect or if the user's entry does not exist. A DSA that implements Simple Uncorroborated authentication without verification will accept simple credentials without validating them. Implementations claiming conformance shall, as a minimum, implement None and Simple Uncorroborated authentication without verification. 1It is the case that some DSAs containing public information may not require authentication. 19 Part 11 - Directory Services Protocols March 1994 (Stable) 8.5 Directory Service Conformance The following subclauses will describe various aspects of Directory conformance. Conformance to the Authentication Framework is viewed as a separate issue from conformance to the rest of the Directory document and is presented in that context. Directory Profiles are broken into two subclauses. Service support specifies the level of support for operations and errors. Protocol support specifies the protocol elements required for implementations which claim conformance to specified operations. 8.5.1 Service Conformance To specify the support for operations and errors, two classifications are used as follows. 8.5.1.1 r: required The operation shall be implemented and the respective error shall be handled for conformance to these agreements. For DUAs, required means: a) or ARGUMENT parameters, create the DAP protocol elements to convey the service request to the DSA; b) for RESULT and ERROR parameters, accept the DAP protocol elements. For DSAs, required means: a) for ARGUMENT parameters, accept the protocol elements when received and create the protocol elements when acting as a requesting DSA; b) for RESULT and ERROR parameters, be able to convey all possible results when responding in either the DAP or DSP protocols and when receiving results, perform additional processing as defined for cooperating DSAs. 8.5.1.2 n: not required It is left to implementations as to whether the operation or error is implemented or not. 20 Part 11 - Directory Services Protocols March 1994 (Stable) 8.5.2 Protocol Conformance To specify the support for protocol elements, four classifications are used as follows. 8.5.2.1 M: mandatory Generation of element is a mandatory static conformance requirement (i.e., a conformant implementation shall be capable of generating the element). Generation of element is a mandatory dynamic conformance requirement (i.e., the element shall be present in all instances of communication which use the element). The terms static conformance and dynamic conformance are defined in ISO 9646-1, "OSI Conformance Testing Methodology and Framework, Part 1: General Concepts." 8.5.2.2 G: generate Generation of element is a mandatory static conformance requirement. Generation of element is a conditional dynamic conformance requirement; the condition is: Where a DSA is a propagating DSA, it shall be capable of generating the protocol element as received in related APDUs received from other DSAs. Where the DSA is a holding DSA, it shall be capable of creating all possible values of a protocol element unless otherwise noted in the "comments" line. 8.5.2.3 S: support When receiving protocol elements, implementations of these agreements shall be capable of accepting these elements without error. Actions specified in the Directory documents and in these agreements shall be taken. 8.5.2.4 O: optional When generating protocol elements: a) Generation of element is an optional static conformance requirement. If the implementor claims support for the 21 Part 11 - Directory Services Protocols March 1994 (Stable) corresponding Directory capability, then the implementation shall be capable of generating the element; b) Generation of element is an optional dynamic conformance requirement. If the implementor claims support for the corresponding Directory capability, then the element shall be present in instances of communication which use the element (except where defaults allow otherwise). When receiving protocol elements, implementations of these agreements shall be capable of accepting these elements without error. However, actions specified in the base standard and in these agreements may be taken but are not required. Where protocol elements are nested, the classification of the nested protocol elements is of relevance only when the immediately containing protocol element is generated. The classification of the protocol elements at the highest level is relative with respect to support of the operation. Also note that in table 3, some rows contain two support classifications in the DSA column. In such cases, the support classification in parentheses applies to centralized DSA's only. When there is only one support classification given, it applies equally to centralized and non-centralized DSA's. 8.6 The Directory Access Profile This agreement requires implementations of the DUA to provide access to the Directory Services as defined in the DUA column in table 2. For the services in table 2 which are supported, these agreements further require DUAs to support the protocol elements as defined in the DUA column in table 3 (parts 1 - 7). These agreements require implementations of the DSA to support the Directory Services as defined in the DSA column in table 2. These agreements further require DSAs to support the protocol elements as defined in the DSA column in table 3. Table 3 is listed in seven parts. Note that the requirements for a centralized DSA and a cooperating DSA are different. 22 Part 11 - Directory Services Protocols March 1994 (Stable) 8.7 The Directory System Profile These agreements require implementations of distributed DSAs which provide DSP to support the responder role for services as defined in table 4. Further, these agreements require DSAs to support the protocol elements as specified in table 5. Table 5 is listed in nine parts. DSAs are required to support the requestor role for all the services as defined in table 4 if conforming to the chained mode of interaction. 8.8 Digital Signature Protocol Conformance Profile Table 6 and table 7 provide information on the digital signature protocol conformance profile. Note that elements in CommonArguments and CommonResults SecurityParameters that are not specified in table 6 and table 7 are covered in the Directory Service Protocol Support (table 5) and Directory Access Protocol Support (table 3). 8.9 Strong Authentication Protocol Conformance Profile Table 8 and table 9 provide information on the strong authentication protocol conformance profile. 8.10 Subtree Specification Classes NOTE - This subclause contains agreements on the forthcoming edition of the OSI Directory standard, and is based on the DAM/DIS Directory documents referenced in 2.1 of these agreements. This profile defines three classes of refinement that may occur in subtree specifications. These classes may be used in describing units of replication for use by DISP or in describing DACDs for use by Basic Access Control: Class 0 (Complete Subtree): A subtree definition in which only the base component is specified; Class 1 (Chop Subtree): A subtree definition in which only the base and chop components are specified; Class 2 (Refined Subtree): A subtree definition in which the base, chop, and specification-filter components are 23 Part 11 - Directory Services Protocols March 1994 (Stable) specified. 8.11 Replication Conformance NOTE - This subclause contains agreements on the forthcoming edition of the OSI Directory standard, and is based on the DAM/DIS Directory Documents referenced in 2.1 of these agreements. A DSA implementing DISP shall conform to the basic conformance requirements for a DSA as defined in the Directory Documents, part 5, clause 9.2. However, it is not required for such a DSA to be either centralized or distributed as defined by 8.3 of this implementation agreement. 8.11.1 Shadowing Roles All DSAs implementing DISP shall be capable of acting both as a shadow supplier and as a shadow consumer as defined in the Directory Documents, part 9, clause 3, and as such shall meet conformance requirements stated in part 5, 9.3 and 9.4. 8.11.2 Minimum Shadowing Requirements Additionally, conformance to this profile requires a minimum as listed below: a) support for both the directoryShadowConsumerAC application context and the directoryShadowSupplierAC application context; b) support for an updateMode whose mode choice includes a specification of schedulingParameters; c) support for schedulingParameters specifications which specify a periodic strategy. 8.11.3 Support for Unit of Replication This profile defines three classes regarding the level of refinement to be supported by a DSA in the definition of a unit of replication. The provider of a conforming implementation shall state which of the following Unit of Replication Conformance Classes the implementation supports: a) Class 0 (Basic UnitOfReplication): A DSA conforming to 24 Part 11 - Directory Services Protocols March 1994 (Stable) this class shall be capable of shadowing a Unit of Replication with the following characteristics: 1) the area includes a class 0 subtree as defined in 8.10 of these agreements; 2) the area includes a specified knowledgeType (e.g., master, copy, or both). b) Class 1 (Intermediate UnitOfReplication): A DSA conforming to this class shall fully support the Basic UnitOfReplication and, in addition, shall be capable of shadowing a unit of replication with the following characteristics: 1) the area includes a class 1 subtree as defined in 8.10 of these agreements; 2) the knowledge includes the extendedKnowledge element with value TRUE. c) Class 2 - (Maximal UnitOfReplication): a DSA conforming to this class shall fully support the Intermediate UnitofReplication and, in addition, shall be capable of shadowing a unit of replication whose specification uses AttributeSelection (including selection on class). Furthermore, a DSA conforming to this class shall be capable of supporting overlapping replicated areas as described in the Directory Documents, part 9, 9.2.5. NOTES 1 No replication conformance class requires (nor precludes) support for a class 2 subtree specification. 2 Filtering using a specification-filter in the definition of a subtree allows filtering on class when specifying which entries are to be part of the subtree. 3 AttributeSelection is used in shadowing to determine which attributes of the entries in a subtree will be shadowed. ClassAttributeSelection allows choosing specific attributes or all attributes in an class. A list of classes for shadowing can be devised using a sequence of class and classAttributes. 25 Part 11 - Directory Services Protocols March 1994 (Stable) 8.12 Recommended Practices for Shadowing NOTE - This subclause contains agreements on the forthcoming edition of the OSI Directory standard, and is based on the DAM/DIS Directory Documents referenced in 2.1 of these agreements. 8.12.1 APDU Size In shadowing, updates for an entire Unit of Replication are carred in one APDU. Since the size of such an APDU is application-specific, no pragmatic constraint has been specified in the Directory Documents or Implementation Agreements. Some examples of APDU size implementors can expect would be useful. For instance, an entry size of 2000 octets and a Unit of Replication consisting of 2000 entries would result in a APDU of 4 Megabytes. It is recommended that DSA implementations be capable of supporting an APDU of at least this size. This example does not reflect entries which include large attributes, such as photographic images. 8.12.2 Duplicate Shadow Agreements Administrators should not allow duplicate shadow agreements between DSAs. Duplicate shadow agreements are those which include the same consumer, supplier, and Unit of Replication. 8.12.3 Consistency Between Supplier and Consumer Information After an updateShadow operation, the standard does not guarantee consistency between the resulting shadowed information in the consumer DSA and the information in the replicated area in the supplier DSA, since changes may be made during assembly of the APDU containing the shadowed information. If consistency between the supplier and consumer information is required, the contents of the replicated area in the supplier DSA must not be modified while the APDU is being assembled. However, the shadowed information must be internally consistent. For example, while the shadowed information is being assembled, changing a distinguished name within the replicated area could lead to internal inconsistency. 26 Part 11 - Directory Services Protocols March 1994 (Stable) 8.12.4 Management of Shadowing Agreements Without DOP F o r D S A s n o t s u p p o r t i n g t h e directoryOperationalBindingManagementAC as defined in the Directory Documents, part 5, management of shadowing agreements is by out-of-band means. The results of procedures followed by such DSAs must be the same as if the DSAs had managed the same agreements using the procedure for operational binding management outlined in 8.2 of the Directory Documents, part 9. For example, when shadowing DSAs arrange to modify the parameters of an existing shadowing agreement, they must revise the AgreementID so that its version component is incremented. 9 Distributed Operations 9.1 Static Requirements 9.1.1 Reference Types This Functional Standard requires conforming implementations to be able to hold and use reference types as summarised below (and clarified in 9.1.2): REFERENCE TYPES HOLDING AND NOTES USING CAPABILITY Superior see note Non-first-level DSAs shall hold precisely one single superior reference. A First-Level DSA does not hold any superior reference Subordinate Mandatory Non-specific Optional Subordinate Cross-reference Mandatory 27 Part 11 - Directory Services Protocols March 1994 (Stable) 9.1.2 Superior References and Root Contexts 9.1.2.1 First-Level DSAs A DSA conformant to this Functional Standard acting as a first level DSA shall be able to hold and use the root context and, in addition, shall hold as master (i.e., have administrative authority for) at least one naming context immediately subordinate to the root of the DIT. A DSA conforming to this Functional Standard is not, however, required to have the capability of being a first level DSA. NOTE - The root context never contains any non-specific subordinate references and first level DSAs should not hold such references in respect of the root context to avod circular references. 9.1.2.2 Return-Cross-References The support of the "return-cross-references" facility, either as requester or as supplier, as defined in the Directory Documents, clause 10.4., is optional. 9.1.3 Support of Application Contexts All DSAs compliant with this Functional Standard shall support the DirectoryAccessAC or DirectorySystemAC or both. If a DSA supports DirectorySystemAC, then it must be able to accept a chained request and must be able to generate a referral. The generation of chained requests is optional. See Table 4. Editor's Note - Table 4, referenced in the above paragraph, is located in the current stable agreements. 9.1.4 DSA-level Security As a consequence of security policy, a DSA may: a) refuse associations from any or particular DSAs; b) refuse invokes on existing associations in which case a SecurityError or ServiceError is returned. 28 Part 11 - Directory Services Protocols March 1994 (Stable) 9.1.5 Aliases DSAs shall be able to carry out name resolution and search continuation for an alias whose dereference points to an entry held outside the DSA (as well as those held inside the DSA). 9.1.6 Authentication for DSA Bind In the case of simple authentication, if any of the DSAs listed in the trace information is untrusted, the originating user identified by the originator field in the chaining argument should be treated as unauthenticated. Editor's Note - Use of traceInformation in making security decisions will be a subject of continued discussion and contributions. 9.1.7 Authentication of User Whose Entry Is Held by Another DSA If a DSA is to be able to carry out simple authentication of a user whose entry is potentially held by some other DSA, the DSA must be able to invoke DSA "compare" and "read" operations to complete authentication by reference to other DSAs. All such DSAs shall support the DirectorySystemAC. 9.2 Dynamic Requirements 9.2.1 Detection of Search Loop Refer to 7.2.3 of these Agreements. 9.2.2 Generation of Trace Information A TraceInformation value carries forward a record of the DSAs which have been involved in the performance of an operation. It is used to detect the existence of, or avoid, loops which might arise from inconsistent knowledge or from the presence of alias loops in the DIT. Each DSA which is propagating an operation to another, adds a new item to the trace information. If the propagation of a Search operation involves the creation of a new Search (Directory Documents, clause 18.7.2.2.2), the trace information shall not be re-set, but the full trace information for the overall Search operation to the point where the new Search was generated shall be included in the new Search. 29 Part 11 - Directory Services Protocols March 1994 (Stable) There is no arbitrary limit on the size of TraceInformation other than that imposed by the maximum APDU size limit. 9.2.3 Integrity of Operation Arguments Any abstract service operation arguments that are signed must be passed unchanged to the presentation layer. This does not constrain the hoice of transfer syntax used by the presentation layer. 9.2.4 Referrals and Chaining It is recommended that a DSA which has chained a request act upon any referrals which it receives, rather than returning them to the requestor if the "prefer-chaining" service control is present, unless prevented from doing so byadministrative limitations or service policies. However, if a DSA which is carrying out a List or a Search operation receives a set of unexplored Continuation References, it shall never pursue these if the result was signed (but was not collated by the DSA with other results), since this will result in duplication. If the result was unsigned, it may act on them (removing them from the consolidated result), or it may pass them back to the Invoker of the operation. The DSA can act on the references and remove them if correlated. If a DSA is unable to establish an association with a remote DSA for the purpose of chaining an operation, then it should return a DSA referral or continuation reference as appropriate. 10 Underlying Services This section specifies requirements over and above those given in the Directory Documents. 10.1 ROSE It should be noted that support of "abandon" implies support of operation class 2. 30 Part 11 - Directory Services Protocols March 1994 (Stable) 10.2 Session All directory implementations are required to support Session Version 2. 10.3 ACSE The A-ABORT service is required by association-accepting DSAs to escape unwanted associations, which, under the ROSE protocol, they cannot release. In all other cases (association-initiating DSAs and DUAs) it may be preferable (though not required) to escape associations using UNBIND rather than abort. The aborting DUA or DSA may optionally use the user information field of the A-ABORT. Such information, however, is only meaningful for diagnostic purposes and its use is not covered by these Agreements. 11 Access Control Guidelines relating to access control for the base edition of the Directory standard can be found in Annex F of the Directory Documents, Part 2. Specifications for access control in the extended edition of the Directory standard are found in DAM-1.3 to ISO/IEC 9594-2, DAM-1.3 to ISO/IEC 9594-3, and DAM-1.3 to ISO/IEC 9594-4. 12 Test Considerations This clause outlines some items that implementors may wish to consider in terms of testing expectations; additionally, future conformance testers may wish to consider these items when developing tests. 12.1 Major Elements of Architecture One important aspect of testing is to confirm the correct behavior of DSAs and DUAs with respect to major elements of the directory architecture. Such major elements include: a) Conformance Statement; b) Distinguished names (e.g., name resolution, equivalence of various forms); 31 Part 11 - Directory Services Protocols March 1994 (Stable) c) Entries and Attributes (e.g., accessibility by operations, compliance with rules); d) Handling of distributed operations (e.g., naming contexts and knowledge); e) Schemas: 1) Structure rules (e.g., storage and maintenance of structure and of naming rules); 2) Object classes and sub-classes (e.g., storage and extension of rules for object attributes); 3) Attribute types (e.g., storage and maintenance of syntax classes and rules for multi or single valued attributes); 4) Attribute syntax (e.g., maintenance and support for attribute value testing and matching, to specification for a defined set of attribute types); f) Operations: 1) all operations; 2) correct function; 3) correct result; 4) correct responses; g) Aliases (e.g.,correct resolution, error responses); h) Authentication and Access Control (e.g., limitation of modify access); i) ROSE (e.g., correct handling of invokes, results, rejects, and invoke ids); j) ACSE (e.g., association establishment / refusal for invalid application contexts,etc.). 32 Part 11 - Directory Services Protocols March 1994 (Stable) 12.2 Search Operation Testing of support for filter items should be reasonable. It is not expected that DSAs will be able to handle worst case testing in this area. 13 Errors This clause provides clarification of the semantics of various operation errors and implementation guidelines on their usage. 13.1 Permanent vs. Temporary Service Errors This subclause provides some clarification regarding the usage of the Service Errors busy, unavailable, and unwillingToPerform. The error busy is particularly transient. It is returned when one or more of The Directory's internal resources are being used to their capacity and, hence, the requested operation cannot, for the moment, be performed. The Directory should be able to recover from this type of resource depletion after a short while. The error unavailable is also temporary but somewhat less transient. It indicates that The Directory (or some part of it)is currently unavailable and may continue to be unavailable for a reasonably long period of time. For example, this error is returned when a given DSA is functionally disabled, or when a specific part of the DIB is undergoing reconfiguration. The error unwillingToPerform has a permanent connotation. It indicates that The Directory cannot perform the requested operation because it would require resources beyond its capacity. For example, this error may be returned by a DSA if satisfying a request would result in the generation of an APDU in excess of 2**18 - 1 octets. 13.2 Guidelines for Error Handling NOTE - The error handling tables include symptoms and situations for the DISP as defined in the forthcoming edition of the OSI Directory standard. 33 Part 11 - Directory Services Protocols March 1994 (Stable) 13.2.1 Introduction This subclause provides a recommended mapping of error situations which may be encountered to ROSE Rejects or to the errors provided in the DAP, DSP, and DISP protocols of the Directory Documents. The Directory Documents are not adequately definitive about the handling of errors. In this document, more explicit guidelines are given. Error situations are defined by: a) Symptom (i.e.,the manner in which the error was detected); b) Situation (i.e., the circumstance or phase during which the error was detected. For each possible situation, the error-handling procedure needs to be defined). 13.2.2 Symptoms Table 10 describes a set of symptoms; the set is not necessarily exhaustive. Each is identified by a title which is used later in describing error actions. The title used for each symptom is not intended to imply any particular usage in a particular implementation. 13.2.3 Situations Table 11 identifies recognized situations within which particular symptoms may give rise to distinct error actions. 13.2.4 Error Actions Table 13 summarizes specific error actions for each possible combination of symptom and situation. Symptoms are described in 13.2.2 and situations are described in 13.2.3. Each entry in table 13 corresponds to the symptom in the left-most column and the situation given in the column header. Each entry may specify: a) a specific error action. The error action is described using the notation shown in table 12; b) a specific error action and a relevant note. The note 34 Part 11 - Directory Services Protocols March 1994 (Stable) will be indicated by a number enclosed in parentheses. The notes can be found at the end of table 13; c) only a relevant note; d) a blank (which indicates the corresponding combination of symptom and situation is not meaningful in the context of these Agreements). The entries in table 13 which specify a specific error action will do so using the notation shown in table 12. 13.2.5 Reporting In addition to the use of error-reporting services, DSAs should implement logging services to assist in management of the Directory. The list below describes classes of error which should be logged.Note that the list is not necessarily complete: a) Errors indicating attempted breaches of security; b) Errors indicating local software or hardware malfunction; c) Errors indicating malfunction or other unacceptable behavior on the part of the invoker of an operation; d) Errors indicating loss of chaining service by another DSA; e) Error conditions that would be difficult to diagnose with the level of detail supplied over the protocol; f) Aborts and other exceptional communications events. The form and accessibility of any such logs is for further study. 35 Part 11 - Directory Services Protocols March 1994 (Stable) 14 Specific Authentication Schemes This clause identifies authentiction algorithms for use in Directory authentication. Informative text and ASN.1 definitions describing these algorithms appears in part 12 (Security). Use of algorithms other than those cited in this clause or described in the Directory Documents is by bilateral agreement. 14.1 Specific Strong Authentication Schemes This subclause cites one alternative to the RSA digital signature scheme, the "ElGamal" digital signature scheme. Future contributions may result in other alternatives being added to this subclause. Implementors may choose to provide digital signature capability based on RSA, ElGamal, or some other scheme appropriate for use in the OSI Directory environment. It should be noted that RSA and ElGamal are governed by U.S.A. patent law. 14.1.1 ElGamal The ElGamal digital signature scheme was originally described by Taher ElGamal in [ELGA85]. Part 12 (Security) of these agreements contains details on the use of ElGamal, including an informative description of the scheme using the notation described in part 8 of the Directory Documents and known constraints on algorithm parameters. 14.1.2 One-Way Hash Functions This subclause cites alternative one-way hash functions for use in Strong and Protected Simple Authentication. The Security SIG continues to investigate the security of additional one-way hash functions, and the Directory Services SIG will consider the applicability of these hash functions to Directory authentication. A recent development in this area is the citation by the Security SIG of RSA MD4. In another recent development, the two-pass application of the SNEFRU algorithm was announced by Ralph Merkle to have been broken. Future study of MD4 and other contributions may result in other additions to this subclause. 36 Part 11 - Directory Services Protocols March 1994 (Stable) At the present time, implementors may choose to provide one-way hash functionality based on MD2 or some other scheme aplpropriate for use in the OSI Directory environment. 14.1.2.1 SQUARE-MOD-N Algorithm Recent research regarding the square-mod-n one-way hash function described in Annex D of the Directory Documents, Part 8, has revealed that the function is not secure. Its use, therefore, is discouraged. 14.1.2.2 MD2 Algorithm MD2 is a one-way hash function and is described in [RFC1115]. 14.1.2.3 Use of One-Way Hash Functions in Forming Signatures MD2 may be used to form digital signatures in conjunction with RSA or ElGamal. 14.1.3 ASN.1 for Strong Authentication Algorithms This subclause defines object identifiers assigned to authentication algorithms. The definitions take the form of the ASN.1 module, "OIWAlgorithmObjectIdentifiers." 37 Part 11 - Directory Services Protocols March 1994 (Stable) 38 Part 11 - Directory Services Protocols March 1994 (Stable) 39 Part 11 - Directory Services Protocols March 1994 (Stable) +---------------------------------------------------------------- ------------+ | OIWAlgorithmObjectIdentifiers {iso(1) identified-organization(3) | | oiw(14) dssig(7) oIWAlgorithmObjectIdentifiers(1)} | | DEFINITIONS ::= | | BEGIN | | | | EXPORTS | | md2, md2WithRSA, elGamal, md2WithElGamal; | | | | IMPORTS | | authenticationFramework | | FROM UsefulDefinitions {joint-iso-ccitt ds(5) modules(1) | | usefulDefinitions(0)} | | ALGORITHM | | FROM AuthenticationFramework authenticationFramework; | | | | -- categories of object identifiers | | | | algorithm OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) | | oiw(14) dssig(7) algorithm(2)} | | | | encriptionAlgorithm OBJECT IDENTIFIER ::= {algorithm 1} | | | | hashAlgorthm OBJECT IDENTIFIER ::= {algorithm 2} | | | 40 Part 11 - Directory Services Protocols March 1994 (Stable) | signatureAlgorithm OBJECT IDENTIFIER ::= {algorithm 3} | | | | -- algorithms | | | | md2 ALGORITHM | | PARAMETER NULL | | ::= {hashAlgorithm 1} | | | | md2WithRsa ALGORITHM | | PARAMETER NULL | | ::= {signatureAlgorithm 1} | | | | elGamal ALGORITHM | | PARAMETER NULL | | ::= {encryptionAlgorithm 1} | | | | | | md2WithElGamal ALGORITHM | | PARAMETER NULL | | ::= {signatureAlgorithm 2} | | | | END -- of Algorithm Object Identifier Definitions | +---------------------------------------------------------------- ------------+ 41 Part 11 - Directory Services Protocols March 1994 (Stable) 14.2 Protected Simple Authentication Protecting the user's distinguished name and password provides greater degrees of security than where passwords are not protected. The procedure for achieving this protection, referred to as protected simple authentication, is outlined in the Directory Documents, Part 8, clause 5.3. The approach by which protected identifying information may be generated is outlined in the Directory Documents,Part 8, clause 5.4. For the purpose of these agreements, f1 and f2 as specified in the Directory Documents, Part 8, clause 5.4 are identical MD2 one-way functions. The algorithms for implementation of the MD2 one-way function are described in [RFC1115] (see D.3). Note that the use of MD2 maybe subject to licensing agreement. Use of other algorithms for other one-way functions is by bilateral agreement. User A generates Protected2 as specified in the Directory Documents, Part 8, clause 5.4. Authenticator2 is then conveyed to B in the form of Simple Credentials. Table 14 shows the relationship between SimpleCredentialfields and the elements of protected simple authentication as shown in figure 2 of the Directory Documents, Part 8. 14.3 Simple Authentication There are two major classes of authentication supported by the Directory (i.e., simple and strong authentication). Simple authentication is based on a password being passed between the two associated entities (e.g., between a Directory User and a DUA, or between two DSAs). In the case of interaction between a Directory User and a DUA, the password is compared in some way with the password attribute in the user's entry in the Directory. In the case of interaction between two DSAs, this cannot be done since the DSA object class, as defined in the Directory Documents (Part 7, clause 6.14) does not contain a password attribute. To facilitate simple authentication between DSAs,it is recommended that a DSA have local access to a list of one or more known DSAs, with a copy of each known DSA's password. Maintenance of that information is done through the use of bilateral agreements between DSA administrators. 42 Part 11 - Directory Services Protocols March 1994 (Stable) Table 1 - Pragmatic constraints for selected attributes Primar Attribute Content Constraints y Notes Type Source Aliased Distinguis Note 3 Object Name hed Name Business T.61 or ub-business CCITT Category Printable - category X.520 String 128 Common Name T.61 or ub-common- CCITT Printable name 64 X.520 String Country Printable 2 ISO Name String 3166 Description T.61 or ub-descript CCITT About 1 Printable ion 1024 X.520 screen String full Destination Printable ub-destinat CCITT Indicator String ion- X.520 indicator 128 Facsimile Facsimile ub-telephon CCITT Optionally Telephone Telephone e-number 32 X.520 includes Number Number G3 non-basic pa- rameters (Upper bounds ffs) Internation Numeric ub-isdn-add CCITT E.164 al ISDN String ress 16 X.520 Internat'l Number ISDN Number Knowledge T.61 or 1024 OIW About 1 Information Printable screen String full Locality T.61 or ub-locality CCITT Name Printable -name 128 X.520 String Member Distinguis Note 3 hed Name Object Object 256 octets OIW Class Identifier 43 Part 11 - Directory Services Protocols March 1994 (Stable) Primar Attribute Content Constraints y Notes Type Source Organizatio T.61 or ub-organiza CCITT n Name Printable tion-name X.520 String 64 Organizatio T.61 or ub-organiza CCITT nal Unit Printable tional- X.520 Name String unit- name 64 Owner Distinguis Note 3 hed Name Physical T.61 or ub-physical CCITT Delivery Printable -office-nam X.520 OfficeName String e 128 44 Part 11 - Directory Services Protocols March 1994 (Stable) Table 1 - Pragmatic constraints for selected attributes (continued) Primar Attribute Content Constraints y Notes Type Source Post Office T.61 or ub-post-off CCITT Box Printable ice-box 40 X.520 String Postal Postal ub-postal-l CCITT UPU Address Address ine6 X.520 ub-postal-s tring30 Postal Code T.61 or ub-postal-c CCITT Printable ode 40 X.520 String Presentatio Presentati 224 octets NIST Note n Address on Address 2(page ?), ISO 7498.3 & X.200 Registered Postal ub-postal-l CCITT Address Address ine6 X.520 ub-postal-s tring30 Role Distinguis Note 3 Occupant hed Name Search_Guid Guide 256 OIW e See Also Distinguis Note 3 hed Name (page ?) Serial Printable ub-serial-n CCITT Number String umber 64 X.520 State or T.61 or ub-state-na CCITT Province Printable me 128 X.520 Name String Street T.61 or ub-street-a CCITT Address Printable ddress 128 X.520 String Supported Object 256 OIW Application Identifier Context Surname T.61 or ub-surname CCITT Printable 64 X.520 String 45 Part 11 - Directory Services Protocols March 1994 (Stable) Primar Attribute Content Constraints y Notes Type Source Telephone Printable ub-telephon CCITT E.123 Number String e-number 32 X.520 Table 1 - Pragmatic constraints for selected attributes (concluded) Primar Attribute Content Constraints y Notes Type Source Teletex Teletex ub-teletex- CCITT Optionally Terminal Terminal terminal-id X.520 includes Identifier Identifier 1024 Teletex non-basic parameters (upper bound ffs) Telex Telex ub-telex-nu CCITT Contains Number Number mber14 X.520 sequence ub-country- of telex code4 number, ub-answerba country ck 8 code, and answerback Title T.61 or ub-title 64 CCITT Printable X.520 String User Octet ub-user-pas CCITT Allow long Password String sword 128 X.520 pass- words generated by machine X.121 Numeric ub-x121-add CCITT X.121 Address String ress 15 X.520 46 Part 11 - Directory Services Protocols March 1994 (Stable) Primar Attribute Content Constraints y Notes Type Source NOTES 1 The pragmatic constraints of these parameters are defined in other standards. We will accommodate these values in our pragmatic constraints. 2 Presentation address is composed of "X" NSAP addresses, and three selectors, (20X + 32 + 16 + 16), e.g., if X= 1, this would be 84. These numbers are based on the most recent implementors' agreements. With 8 NSAP addresses this value is 224. 3 Pragmatic constraints are only applied to the individual components of Distinguished Name as defined in the Directory Documents, Part 2. Not all components of a DN will necessarily be understood by an implementation. 4 Implementors should be aware that constraints on Postal Address may not be sufficient for some markets. 47 Part 11 - Directory Services Protocols March 1994 (Stable) Table 2 - Directory access service support Support Classification Operations and Comments DUA DSA Errors -- BIND and UNBIND -- DirectoryBind r r DirectoryUnbind r r -- OPERATIONS -- -- READ OPERATIONS-- Read n r Compare n r Abandon n r (note 2) -- SEARCH OPERATIONS -- List n r (note 1) Search n r (note 1) -- MODIFY OPERATIONS -- AddEntry n r RemoveEntry n r ModifyEntry n r ModifyRDN n r -- ERRORS -- Abandoned (note 4)r AbandonedFailed (note 4)r AttributeError (note 4)r NameError (note 4)r Referral (note 4) r(note 3) 48 Part 11 - Directory Services Protocols March 1994 (Stable) Table 2 - Directory access service support (concluded) Support Classification Operations and Comments DUA DSA Errors SecurityError (note 4) r ServiceError (note 4) r UpdateError (note 4) 4 NOTES 1 As performance of Search and List operations can consume significant resources, the policies of some centralized DSAs may be that such operations will not be performed. For these cases, the reply to the requests for such operations would be ServiceError with the "unwillingToPerform" Service Problem. 2 Reference Directory Documents, Part 3, clause 9.3.6 3 Centralized DSAs would not generate referrals. 4 See EntryInformationSelection information under Common Data Types (table 3, Part 6) 49 Part 11 - Directory Services Protocols March 1994 (Stable) Table 3 - DAP protocol support Support Classification Protocol Element Comments DUA DSA - BIND and UNBIND - DirectoryBind M S DirectoryBindArgumen t credentials O S simple O S name G S validity O O password G S strong O O See Strong Authentication Protocol Conformance Profile for requirements when strong authentication is supported. O O externalProcedure versions O S Supported value: v1988 S G DirectoryBindResult credentials O G Shall be the same CHOICE as in DirectoryBindArgume nt. simple O G name S G validity O O password O O 50 Part 11 - Directory Services Protocols March 1994 (Stable) strong O O See Strong Authentication Protocol Conformance Profile for requirements when strong authentication is supported. O O externalProcedure versions S O Supported value: v1988 51 Part 11 - Directory Services Protocols March 1994 (Stable) Table 3 - DAP protocol support (continued) Support Classification Protocol Element Comments DUA DSA S G DirectoryBindError versions S O Supported value: v1988 ServiceProblem S G Supported value: unavailable S G Supported values: SecurityProblem inappropriateAuthen tication, invalidCredentials DirectoryUnbind The DirectoryUnbind has no arguments. - OPERATIONS, ARGUMENTS AND RESULTS - - READ OPERATIONS - Read ReadArgument M S object M S selection O S See note 2 CommonArguments O S ReadResult S G entry S M CommonResults S G Compare CompareArgument M S object M S purported M S O S CommonArguments CompareResult S G 52 Part 11 - Directory Services Protocols March 1994 (Stable) Table 3 - DAP protocol support (continued) Support Classification Protocol Element Comments DUA DSA S G DistinguishedName matched S M fromEntry S G commonResults S G Abandon AbandonArgument M S invokeId M S AbandonResult S G - SEARCH OPERATIONS - List ListArgument M S object M S CommonArguments O S ListResult S G listInfo S G S G DistinguishedName subordinates S M S M For the case where Rel.DistinguishedNam subordinates is e empty set, RDN is absent. aliasEntry S G fromEntry S G S G partialOutcomeQualif ier CommonResults S G S G(O) UncorrelatedListInfo 53 Part 11 - Directory Services Protocols March 1994 (Stable) Table 3 - DAP protocol support (continued) Support Classification Protocol Element Comments DUA DSA ListResult S G See note 1 for additional information related to the DSA support classification. Search SearchArgument M S baseObject M S subset O S filter O S searchAliases O S selection O S O S CommonArguments SearchResult S G searchinfo S G S G DistinguishedName entries S M S G partialOutcomeQualif ier S G CommonResults S G (O) uncorrelatedSearchin fo SearchResult S G S G partialOutcomeQualif ier limitProblem S G unexplored S G S O unavailableCriticalE xt 54 Part 11 - Directory Services Protocols March 1994 (Stable) - MODIFY OPERATIONS - AddEntry AddEntryArgument M S Table 3 - DAP protocol support (continued) Support Classification Protocol Element Comments DUA DSA object M S entry M S CommonArgument O S AddEntryResult S G RemoveEntry M S RemoveEntryArgument object M S O S CommonArguments S G RemoveEntryResult ModifyEntry M S ModifyEntryArgument object M S changes M S At least one entry modification must be supported. addAttribute O S O S removeAttribute addValues O S removeValues O S O S CommonArguments S G ModifyEntryResult ModifyRDN M S ModifyRDNArgument 55 Part 11 - Directory Services Protocols March 1994 (Stable) object M S newRDN M S deleteOldRDN O S O G CommonArguments Table 3 - DAP protocol support (continued) Support Classification Protocol Element Comments DUA DSA ModifyRDNResult S G - ERRORS AND PARAMETERS - Abandoned AbandonFailed problem S M operation S M AttributeError object S M problems S M Min. 1 error(See Directory Documents, Part 3, subclause 12.4.2.2) type S M value S G NameError problem S M matched S M Referral candidate S G SecurityError problem S M ServiceError problem S M UpdateError problem S M 56 Part 11 - Directory Services Protocols March 1994 (Stable) Table 3 - DAP protocol support (continued) Support Classification Protocol Element Comments DUA DSA ModifyRDNResult S G - ERRORS AND PARAMETERS - Abandoned AbandonFailed problem S M operation S M AttributeError object S M problems S M Min. 1 error(See Directory Documents, Part 3, subclause 12.4.2.2) type S M value S G NameError problem S M matched S M Referral candidate S G SecurityError problem S M ServiceError problem S M UpdateError problem S M 57 Part 11 - Directory Services Protocols March 1994 (Stable) Table 3 - DAP protocol support (continued) Support Classification Protocol Element Comments DUA DSA - COMMON ARGUMENTS / RESULTS - CommonArguments ServiceControls O S O S See subclause 8.8. SecurityParameters O S certification-path name O S time O S random O S target O S requestor O S O S (O) OperationProgress M S nameResolutionPhase O S nextRDNToBeResolved aliasedRDNs O S (O) extensions O S identifier M S critical O S item M S CommonResults O G (O) See subclause 8.8. SecurityParameters O G certification-path name O G time O G random O G target O G 58 Part 11 - Directory Services Protocols March 1994 (Stable) Table 3 - DAP protocol support (continued) Support Classification Protocol Element Comments DUA DSA performer O G (O) O G aliasDereferenced - COMMON DATA TYPES - ServiceControls options O S priority O S timeLimit O S sizeLimit O S scopeOfReferral O S EntryInformationSele ction attributeTypes O S allAttributes O S Must support at least one of the CHOICE. select O S infoTypes O S EntryInformation S M DistinguishedName fromEntry S G SET OF CHOICE S G AttributeType S G Attribute S G Filter Must support at least one of the CHOICE. item O S and O S or O S 59 Part 11 - Directory Services Protocols March 1994 (Stable) Table 3 - DAP protocol support (continued) Support Classification Protocol Element Comments DUA DSA not O S FilterItem equality O S substrings O S type M S strings M S initial O S Must support at least one of the CHOICE. any O S final O S greaterOrEqual O S lessOrEqual O S present O S O S approximateMatch SecurityParameters O O See subclause 8.8. O S certification-path name O S time O S random O S target O S ContinuationReferenc e targetObject O M aliasedRDNs O G O M OperationProgress O M nameResolutionPhase O G nextRDNToBeResolved 60 Part 11 - Directory Services Protocols March 1994 (Stable) Table 3 - DAP protocol support (concluded) Support Classification Protocol Element Comments DUA DSA rdnsResolved O G AccessPoint O M AccessPoint Name O M O M PresentationAddress pSelector O G sSelector O G tSelector O G nAddress O M NOTES 1 As performance of Search and List operations can consume significant resources, the policies of some centralized DSAs may be that such operations will not be performed. For these cases, the reply to the requests for such operations would be ServiceError with the "unwillingToPerform" Service Problem. 2 See EntryInformationSelection information under Common Data Types (table 3, part 6) 61 Part 11 - Directory Services Protocols March 1994 (Stable) Table 4 - Directory system service support Support Classification Operations and Comments Request Response Errors - BIND and UNBIND - DSABind n(notes r 1,2) DSAUnbind n(notes r 1,2) - OPERATIONS - - CHAINED READ OPERATIONS - ChainedRead n(notes r 1,2) ChainedCompare n(notes r 1,2) chainedAbandon n(note r 1) - CHAINED SEARCH OPERATIONS - ChainedList n (note r 1) ChainedSearch n (note r 1) - CHAINED MODIFY OPERATIONS - n (note r ChainedAddEntry 1) n (note r ChainedRemoveEntry 1) ChainedEntry n (note r 1) n (note r ChainedModifyRDN 1) - ERRORS - Abandoned n(note r 1) Abandonfailed n(note r 1) 62 Part 11 - Directory Services Protocols March 1994 (Stable) AttributeError n(note r 1) NameError n(note r 1) DSARefferal n(note r 1) SecurityError n(note r 1) SeviceError n(note r 1) UpdateError n(note r 1) NOTES 1 Necessary when supporting the chained mode of interaction. 2 Some of these operations may be necessary to support distributed authentication. This requirement is distinct from support for chained mode of interaction. 63 Part 11 - Directory Services Protocols March 1994 (Stable) Table 5 - DSP protocol support Support Classification Protocol Element Comments Request Response - BIND and UNBIND - DSABind M S DirectoryBindArgume nt credentials G S simple G S name G S validity O O password G S strong O O See Strong Authentication Protocol Conformance Profile for requirements when strong authentication is supported. O O externalProcedure versions G S Supported value: v1988 DSABindResult S G credentials S G Shall be the same CHOICE as in DirectoryBindArg ument. simple S G name S G validity O O password S G 64 Part 11 - Directory Services Protocols March 1994 (Stable) strong O O See Strong Authentication Protocol Conformance Profile for requirements when strong authentication is supported. O O externalProcedure versions S G Supported value: v1988 S G DirectoryBindError versions S G Supported value: v1988 ServiceProblem S G Supported values: busy and unavailable. S G Supported SecurityProblem values: inappropriate Authentication, invalidCredentia ls. DSAUnbind The DSAUnbind has no arguments. 65 Part 11 - Directory Services Protocols March 1994 (Stable) Table 5 - DSP protocol support (continued) Support Classification Protocol Element Comments Request Response - OPERATIONS, ARGUMENTS AND RESULTS - - CHAINED READ OPERATIONS - ChainedRead M S ChainingArgument ReadArgument M S object M S selection G S G S CommonArguments S M ChainingResult ReadResult S M entry S M S G CommonResults ChainedCompare M S ChainingArgument M S CompareArgument object M S purported M S G S CommonArguments ChainingResult S M CompareResult S M S G DistinguishedName matched S M fromEntry S G CommonResults S G ChainedAbandon 66 Part 11 - Directory Services Protocols March 1994 (Stable) M S AbandonArgument invokeId M S AbandonResult S G - OPERATIONS, ARGUMENTS AND RESULTS - - CHAINED SEARCH OPERATIONS - ChainedList M S ChainingArguments 67 Part 11 - Directory Services Protocols March 1994 (Stable) Table 5 - DSP protocol support (continued) Support Classification Protocol Element Comments Request Response ListArgument M S object M D G S CommonArguments ChainingResults S M ListResult S M listInfo S G S G DistinguishedName S M subordinates S M Rel.DistinguishedNa me S G aliasEntry fromEntry S G S G partialOutcomeQuali fier S G CommonResults S G uncorrelatedListInf o ListResult S G ChainedSearch SearchArgument M S baseObject M S sugset G S filter G S searchAliases G S selection G S G S CommonArguments S M ChainingResults 68 Part 11 - Directory Services Protocols March 1994 (Stable) SearchResult S M Searchinfo S M S G DistinguishedName entries S M S G partialOutcomeQuali fier S G CommonResults S G uncorrelatedSearchi nfo S G SearchResult S G partialOutcomeQuali fier limitProblem S G 69 Part 11 - Directory Services Protocols March 1994 (Stable) Table 5 - DSP protocol support (continued) Support Classification Protocol Element Comments Request Response unexplored S G S G unavailableCritical Ext - CHAINED MODIFY OPERATIONS - ChainedAddEntry M S ChainingArguments M S AddEntryArgument object M S entry M S G S CommonArguments S M ChainingResults S M AddEntryResults ChainedRemoveEntry M S ChainingArguments M S RemoveEntryArgument object M S G S CommonArguments S M ChainingResults S M RemoveEntryResult ChainedModifyEntry M S ChainingArguments M S ModifyEntryArgument 70 Part 11 - Directory Services Protocols March 1994 (Stable) object M S changes M S G S addAttribute G S removeAttribute addValues G S G S removeValues G S CommonArguments S M ChainingResults S M ModifyEntryResult ChainedModifyRDN M S ChainingArguments M S ModifyRDNArgument object M S 71 Part 11 - Directory Services Protocols March 1994 (Stable) Table 5 - DSP protocol support (continued) Support Classification Protocol Element Comments Request Response newRDN M S deleteOldRDN G S G S CommonArguments S M ChainingResults S M ModifyRDNResult - ERRORS and PARAMETERS - Abandoned AbandonFailed problem S M operation S M AttributeError Min.1 error (see Directory Documents, part 3, subclause 12.4.2.2) object S M problems S M problem S M type S M value S G NameError problem S M matched S M DSARefferal S M ContinuationReferen ce contextPrefix S G SecurityError problem S M ServiceError S G For Directory operations 72 Part 11 - Directory Services Protocols March 1994 (Stable) problem S M UpdateError S G problem S M - COMMON ARGUMENTS / RESULTS - CommonArguments G S ServiceControls O S see subclause SecurityParameters 8.8. 73 Part 11 - Directory Services Protocols March 1994 (Stable) Table 5 - DSP protocol support (continued) Support Classification Protocol Element Comments Request Response requestor G S G S OperationProgress M S nameResolutionPhase G S nextRDNToBeResolved aliasedRDNs G S extensions G S identifier M S critical G S item M S CommonResults S O See subclause SecurityParameters 8.8. requestor S G S G aliasDereferenced - COMMON DATA TYPES - ServiceControls options G S priority G S timeLimit G S sizeLimit G S G S scopeOfReferral EntryInformationSel ection attributeTypes G S allAttributes G S select G S infoTypes G S EntryInformation 74 Part 11 - Directory Services Protocols March 1994 (Stable) S M DistinguishedName fromEntry S G SET OF CHOICE S G AttributeType S G Attribute S G Filter item G S and G S or G S not G S 75 Part 11 - Directory Services Protocols March 1994 (Stable) Table 5 - DSP protocol support (continued) Support Classification Protocol Element Comments Request Response FilterItem equality G S substrings G S type G S strings G S initial G S any G S final G S greaterOrEqual G S lessOrEqual G S present G S G S approximateMatch - COMMON DATA TYPES FOR DISTRIBUTED OPERATION - ChainingArguments originator G S targetObject G S G S operationProgress M S nameResolutionPhase G S nextRDNToBeResolved M S traceInformation G S aliasDereferenced aliasedRDNs G S G S See Directory returnCrossRefs Documents, Part 4, subclause 10.4.1 referenceType G S 76 Part 11 - Directory Services Protocols March 1994 (Stable) DomainInfo O O timeLimit G S O S See note 1 SecurityParameters regarding the support classification for Request. Also see subclause 8.8 ChainingResults Info O O crossReferences S G 77 Part 11 - Directory Services Protocols March 1994 (Stable) Table 5 - DSP protocol support (continued) Support Classification Protocol Element Comments Request Response S O See note 1 SecurityParameters regarding the support classification for Response. Also see subclause 8.8 CrossReference contextPrefix S M See Directory Documents, Part 4, subclause 12.4.2.2 accessPoint S M TraceInformation TraceItem M S TraceItem dsa M S targetObject G S M S operationProgress M S nameResolutionPhase G S nextRDNToBeResolved ContinuationReferen ce targetObject S M aliasedRDNs S G S M operationProgress S M nameResolutionPhase S G nextRDNToBeResolved rdnsResolved S G referenceType S G AccessPoint S M 78 Part 11 - Directory Services Protocols March 1994 (Stable) AccessPoint Name S M S M PresentationAddress pSelector S G sSelector S G Table 5 - DSP protocol support (concluded) Support Classification Protocol Element Comments Request Response tSelector S G nAddress S M NOTES 1 The support classification is G when supporting the chained mode of interaction. 2 Some of these operations may be necessary to support distributed authentication. This requirement is distinct from support for chained mode of interaction. 79 Part 11 - Directory Services Protocols March 1994 (Stable) Table 6 - DAP Support for Digital Signature Protocol Conformance Profile. Support Classification Protocol Element Comments DUA DSA - COMMON ARGUMENTS / RESULTS - CommonArguments SecurityParameters G S certification-path name G S time G S random G S target G S requestor G S CommonResults S G SecurityParameters performer S G 80 Part 11 - Directory Services Protocols March 1994 (Stable) Table 7 - DSP support for digital signature protocol conformance profile Support Classification Protocol Element Comments DUA DSA - COMMON ARGUMENTS / RESULTS - CommonArguments SecurityParameters G S certification-path name G S time G S random G S target G S requestor G S CommonResults G S SecurityParameters performer O G 81 Part 11 - Directory Services Protocols March 1994 (Stable) Table 8 - DAP support for strong authentication protocol conformance profile Support Classification Protocol Element Comments DUA DSA M S DirectoryBindArgume nt credentials G S simple G S name G S validity G S password G S strong G S certification-path G S bind-token O O externalProcedure versions O S S G DirectoryBindResult credentials S G simple S G name S G validity S G password S G strong S G S G certification-path S G bind-token O O externalProcedure versions S O 82 Part 11 - Directory Services Protocols March 1994 (Stable) Table 9 - DSP support for strong authentication protocol conformance profile Support Classification Protocol Element Comments DUA DSA M S DirectoryBindArgume nt credentials G S simple G S name G S validity G S password G S strong G S certification-path G S bind-token O O externalProcedure versions O S S G DirectoryBindResult credentials S G simple S G name S G validity S G password S G strong S G S G certification-path S G bind-token O O externalProcedure versions S O 83 Part 11 - Directory Services Protocols March 1994 (Stable) Table 10 - Error symptoms Symptom Description E_ACCESS The initiator has insufficient access rights to carry out this operation. E_ADMIN_LIMIT The Directory has reached some limit set by an administrative authority, and no partial results are available to return to the user. E_ALIAS_DEREF One of three situations exists: 1 An alias has been encountered while a previous alias was being dereferenced, or 2 a name contained an alias plus one or more additional RDNs when the dontDereferenceAliases service control was being used, or 3 the name, supplied in an operation that precludes alias dereferencing, contained an alias plus one or more additional RDNs. E_ALIAS_LOOP During a whole-subtree search operation, an alias has been encountered which would lead to a loop (i.e., the alias points to an entry which is superior to entries which have already been evaluated in carrying out the search). E_ALIAS_PROBLEM An alias has been encountered, but the entry to which it points does not exist. E_ARG_BOUNDS The argument does not comply with pragmatic constraints (defined locally or by functional standards). 84 Part 11 - Directory Services Protocols March 1994 (Stable) Table 10 - Error symptoms (continued) Symptom Description E_ARG_SYNTAX An operation argument either has incorrect ASN.1 encoding or correct ASN.1 encoding, but does not comply to the syntax as defined in the Directory Documents. NOTES 1 Within BindArgument, additional elements are permitted, to allow future extensions, and do not create an error situation. 2 Errors within attribute values are not included in this codification (see E_ATT_SYNTAX). E_ARG_VIOL An operation argument has correct syntax, but it violates additional rules and constraints levied by the Directory Documents (e.g., use of a Priority integer value whose meaning is undefined). NOTES 1 Within a Relative Distinguished Name, having two AVAs of the same attribute type is an error which is covered by E_DN, and not by E_ARG_VIOL. 2 Errors within attribute values are not included in this codification (see E_ATT_SYNTAX). E_ATT_BOUNDS An attribute value does not comply with bounds specified either by the Directory Documents or by functional standards. E_ATT_OR_VALUE_EXI Within an entry, an attribute or STS attribute value already exists, causing an error situation. 85 Part 11 - Directory Services Protocols March 1994 (Stable) E_ATT_SYNTAX An attribute value either has incorrect ASN.1 encoding or it has correct ASN.1 encoding but does not comply with the ASN.1 encoding defined by the attribute type. E_ATT_VALUE An attribute value, although of correct ASN.1 encoding, and conformant with the syntax defined for the attribute type, is not compliant with other rules (e.g., a non-ISO 3166 country name encoding). E_ACCESS The initiator has insufficient access rights to carry out this operation. E_AUTHENTICATION The authentication offered does not match that required by the object being authenticated. 86 Part 11 - Directory Services Protocols March 1994 (Stable) Table 10 - Error symptoms (continued) Symptom Description E_BUSY The DSA is unable to handle this operation at this time (but it may be able to do so after a short while). E_CANT_CONSTRUCT The update to be transmitted exceeds a local size limit. E_CANT_INCORPORATE The update received exceeds a local APDU size limit. E_CHAIN The DSA needs to use chaining to carry out this operation, but is prohibited from doing so by Service Controls. E_CREDENTIALS The credentials offered do not match those of the object with which authentication is taking place. E_DBE An inconsistency has been detected in the DSA's data base, which may be localized to a particular entry or set of entries. E_DIT_STRUCTURE An attempt was made via an add operation to place an entry in the DIB whose object class would violate the DIT structure rules. E_DN A DN contains an RDN with two AVAs of the same attribute type. E_DSA A DSA to which chaining is taking place is unable to respond. E_ENTRY_EXISTS An entry of the given name already exists, causing an error. E_EXTENSION A DSA was unable to satisfy a request because one or more critical extensions were not available. E_ILLEGAL_ROOT_OBJ Root's DN has been supplied as the object of a Read, Compare, AddEntry, RemoveEntry, ModifyEntry, ModifyRDN, or as the Base Object of a single level search. E_ILLEGAL_ROOT_VAL Root's DN has been supplied illegally as an attribute value (e.g., as an Aliased Object Name). E_INACTIVE_AGREEME The specified is not currently active. NT 87 Part 11 - Directory Services Protocols March 1994 (Stable) E_INVALID_AGREEMEN A valid agreement does not exist with T the DSA. E_LOOP A loop has been detected in the knowledge information within the system. E_MATCH The attribute specified does not support the required matching capability. E_MISSED_PREVIOUS The value received in lastUpdate or is not consistent with the time the recipient DSA understands was the time of the last update. E_MISSING_AVA When creating, or after modifying, an entry, an AVA in the entry's RDN is not represented within the entry's set of attributes. E_MISSING_OBJECT_C When creating an entry, the entry does LASS not possess an object class. E_MORE_CURR_UPD_RC A consumer DSA processing supplier- D initiated updates determines that the update the supplier is attempting to send is older than one the consumer has already received. E_MULTI_DSA The operation is an update operation which affects other DSAs. E_NAMING_VIOLATION The name of the new or modified entry is incompatible with its object class. E_NO_AGMT_W_THIS_D The receiving DSA has no agreements in SA place with the sending DSA. Table 10 - Error symptoms (continued) Symptom Description E_NON_LEAF_OPERATI The operation being attempted is ON illegal except on a leaf. E_NONNAMING_ATTRIB In either an add or ModifyRDN UTE operation, an attribute is included in the last RDN that is not a valid naming attribute according to the DIT structure rules. E_NOT_SINGLE_VALUE An attribute, registered as D single-valued, has been found with more than one value. 88 Part 11 - Directory Services Protocols March 1994 (Stable) E_NO_SUCH_ATT The specified attribute has not been found. E_NO_SUCH_OBJECT The specified entry has not been found. E_NO_SUCH_VALUE The specified attribute value has not been found. E_OBJECT_CLASS_MOD An (illegal) attempt has been made to alter or remove an object class attribute. E_OBJECT_CLASS_VIO There is a schema violation (e.g., L missing mandatory attribute, or non-allowed attribute present). E_PREVIOUSLY_COORD A supplier DSA, while processing consumer-initated updates, has received a coordinateShadowUpdate referring to a shadow agreement for which a previous coordinateShadowUpdate has already been received and is still outstanding. E_PREVIOUSLY_SOLIC A supplier DSA, while processing ITED consumer-initated updates, has received a requestShadowUpdate referring to a shadow agreement for which a previous requestShadowUpdate has already been received and is still outstanding. E_REFERENCE An erroneous reference has been detected (e.g., DSA cannot handle name even as far as the number of RDNs that have already been resolved). E_SCOPE No referrals were available within the requested scope. E_SYSTEM_PERM A serious and permanent software or system error has been detected which prevents completion of the operation. E_SYSTEM_TEMP A serious but temporary software or system error has been detected which prevents completion of the operation. E_TIMEOUT The operation has not completed within the allotted time. E_TIMESTAMP_MISMAT An unrecoverable timestamp mismatch has CH been detected. 89 Part 11 - Directory Services Protocols March 1994 (Stable) Table 10 - Error symptoms (continued) Symptom Description E_UNABLE_TO_COMPLE The DSA is unable to complete this TE operation, or others like it (this applies particularly to search). E_UNABLE_TO_PROCEE The DSA cannot satisfy the operation D after receiving it on the basis of a valid non-specific subordinate reference. E_UNCOORDINATED A consumer DSA, while processing supplier-initated updates, has received an updateShadow request for which there is no outstanding coordinateShadowUpdate. E_TOO_MANY_UPDATES Supplier DSA determines that there are too many updates for incremental refresh and that a full update is required. E_UNDEFINED_ATT An unregistered attribute has been encountered. E_UNRELIABLE_DATA A DSA has detected internal data inconsistencies. E_UNSOLICITED A consumer DSA, while processing consumer-initated updates, has received an updateShadow for which there is no outstanding requestShadowUpdate. E_UNSUPPORTED_OC The object class of the entry is not supported as a valid object class for entries within this DSA. E_UNSUPPORTED_STRA The refresh strategy selected is not T supported by this DSA. E_UNUSABLE_DATA A consumer DSA has decided that the received data is completely unusable due to error. E_VERSION An unexpected version has been found in Bind. E_ZERO_VALUES An attribute has been found (e.g., as a result of a modify-entry operation) with no values. 90 Part 11 - Directory Services Protocols March 1994 (Stable) Table 11 - Error situations Situation Description ABANDON An Abandon operation is being carried out. ADD-ENTRY The entry is being generated. ADD-ENTRY-NAME-RESOLU During an add entry operation, name TION resolution has been successfully accomplished on the superior object, and is not being carried out to determine whether the new entry already exists. BIND-LOCAL A bind is being attempted; either the entry named is (or should be) within a local naming context, or name resolution is being carried out on the part of the name that is known locally. BIND-REMOTE A bind is being attempted, and the entry named is not within a local naming context; remote validation of credentials is being carried out. COMPARE A Compare operation is being carried out on the entry. COORDINATE-SHADOW- The shadow consumer has received a UPDATE coordinateShadowUpdate from the supplier DSA and is evaluating its contents. LIST A List operation is being carried out on the entry. MODIFY-ENTRY The entry is being modified. MODIFY-RDN The RDN is being modified. NAME-RESOLUTION Name resolution is being carried out. READ The entry is being read. REMOVE-ENTRY The entry is being removed. REQUEST-SHADOW-UPDATE The supplier DSA is processing a RequestShadowUpdate received from a consumer. REQUEST-SHADOW- The consumer DSA has received a reply UPDATE-RESULT to a request for update. SEARCH-ENTRY A Search operation is being carried out; the required entry information is being evaluated or acted upon. 91 Part 11 - Directory Services Protocols March 1994 (Stable) SEARCH-FILTER A Search operation is being carried out; the filter is being evaluated or acted upon. TRACE-EVALUATION The trace element is being evaluated for loops. UPDATE-SHADOW The consumer DSA has received an UpdateShadow from the supplier and is trying to incorporate the updated information. Table 12 - Notation used to describe error actions. Error Action Meaning Notation Rej A reject operation is generated, with problem mistyped-argument. Ab() qualifier may take on values codified as follows: CA - Cannot abandon NSO - No such operation TL - Too late A( Attribute Error is generated. The qualifier ) may take on values codified as follows: AVE - Attribute or value already exists CV - Constraint violation IAS - Invalid attribute syntax IM - Inappropriate matching NSA - No such attribute UAT - Undefined attribute type N( NameError is generated. The qualifier may ) take on values codified as follows: ADP - Alias dereferencing problem AP - Alias problem IAS - Invalid attribute syntax NSO - No such object 92 Part 11 - Directory Services Protocols March 1994 (Stable) SH() may take on values codified as follows: IAID - Invalid Agreement ID IA - Inactive Agreement IIR - Invalid information received IS - Invalid Sequencing US - Unsupported strategy MP - Missed previous FUR - Full update required UWP - Unwilling to perform UT - Unsuitable timing UAR - Update already received SC() may take on values codified as follows: IA - Inappropriate authentication IAR - Insufficient access rights IC - Invalid credentials IS - Invalid signature NI - No information PR - Protection required 93 Part 11 - Directory Services Protocols March 1994 (Stable) Table 12 - Notation used to describe error actions. (concluded) Error Action Meaning Notation S( Service Error is generated. The qualifier ) may take on values codified as follows: ALE - Administrative limit exceeded B - Busy CR - Chaining required DE - Dit Error IR - Invalid reference LD - Loop detected OOS - Out of Scope TLE - Time limit exceeded UA - Unavailable UAP - Unable to proceed UCE - Unavailable critical extension UWP - Unwilling to perform U( Update Error is generated. The qualifier ) may take on values codified as follows: AMD - Affects multiple DSAEAE - Entry already exist NAN - Not allowed on non-leaf NAR - Not allowed on RDN NV - Naming violation OCV - Object class violation OMP - Object class modification prohibited 94 Part 11 - Directory Services Protocols March 1994 (Stable) Table 13 - Error actions Situation (See Table 11) Symptom Bind- Name- Add-En (See Table 10) Bin Remote try- Modify d- - Resol Name- Add-E - Loc Resolu ution Resolu ntry Entry al tion tion E_ACCESS SC(IA SC(IAR SC(IA SC(IAR R) ) R) )(14) (14) (14) (14) E_ADMIN_LIMIT S(U S(UA) S(ALE S(ALE) S(ALE S(ALE) A) ) ) E_ALIAS_DEREF S(I S(IC) N(ADP C) ) E_ALIAS_LOOP E_ALIAS_PROBLEM S(I S(IC) N(AP) C) E_ARG_BOUNDS (8) (7) S(UWP S(UWP) S(UWP S(UWP) ) (12) ) (12) (12) (12) E_ARG_SYNTAX (1) (1) Rej Rej Rej Rej E_ARG_VIOL (1) (1) Rej Rej Rej Rej E_ATT_BOUNDS SC( (7) N(IAS N(IAS) A(CV) A(CV) IC) ) (15, (15, 16) 16) E_ATT_OR_VALUE_E A(AVE A(AVE) XISTS ) E_ATT_SYNTAX SC( (7) N(IAS N(IAS) A(IAS A(IAS) IC) ) (15, ) (15, 16) 16) E_ATT_VALUE SC( (7) N(IAS N(IAS) A(IAS A(IAS) IC) ) (15, ) (15, 16) 16) E_AUTHENTICATION SC( SC(IA) IA) E_BUSY S(U S(UA) S(B) S(B) S(B) S(B) A) E_CANT_CONSTRUCT 95 Part 11 - Directory Services Protocols March 1994 (Stable) E_CANT_INCORPORA TE E_CHAIN S(CR) E_CREDENTIALS SC( SC(IC) IC) E_DBE S(U S(UA) S(DE) S(DE) S(DE) S(DE) A) E_DIT_STRUCTURE U(NV) E_DN SC( SC(IC) N(NSO C(NV) IC) ) E_DSA S(UA) S(UA) S(UA) 96 Part 11 - Directory Services Protocols March 1994 (Stable) Table 13 - Error actions (continued) Symptom Situation (See Table 11) (See Table 10) Bind- Name- Add-En Bin Remote Resolu try- Modify d- - tion Name- Add-E - Loc Resolu Resolu ntry Entry al tion tion E_ENTRY_EXISTS U(EAE) E_EXTENSION S(UWP) S(UCE) S(UCE S(UCE) ) E_ILLEGAL_ROOT_O SC( SC(IC) N(NSO) N(NSO N(NSO) BJ IC) ) E_ILLEGAL_ROOT_V SC( (7) N(IAS) N(IAS) A(IAS A(IAS) AL IC) (15, (15, ) 16) 16) E_INACTIVE_AGREE MENT E_INVALID_AGREEM ENT E_LOOP S(UA) S(LD) E_MATCH SC( SC(IC) A(IM) A(IM) A(IM) IC) E_MISSED_PREVIOU S E_MISSING_AVA U(NAR U(NAR) ) E_MISSING_OBJECT U(OCV U(OMP) _CLASS ) E_MORE_CURR_UPD_ RCD E_MULTI_DSA U(AMD) E_NAMING_VIOLATI U(NV) ON E_NO_AGMT_W_THIS _DSA E_NO_ENTRIES_IN_ ST E_NON_LEAF_OPERA TION E_NONNAMING_ATTR U(NV) IBUTE 97 Part 11 - Directory Services Protocols March 1994 (Stable) E_NOT_SINGLE_VAL A(CV) A(CV) UED E_NO_SUCH_ATT A(NSA) E_NO_SUCH_OBJECT SC( SC(IC) N(NSO) IC) E_NO_SUCH_VALUE A(NSA) E_OBJECT_CLASS_M U(OMP) OD E_OBJECT_CLASS_V U(OCV U(OCV) IOL ) E_OUTSIDE_UOR 98 Part 11 - Directory Services Protocols March 1994 (Stable) Table 13 - Error actions (continued) Symptom Situation (See Table 11) (See Table 10) Bind- Name- Add-En Bin Remote Resolu try- Modify d- - tion Name- Add-E - Loc Resolu Resolu ntry Entry al tion tion E_PREVIOUSLY_COO RD E_REFERENCE S(UA) S(IR) (17) E_SCOPE S(OOS) E_PREVIOUSLY_SOL ICITED E_SYSTEM_PERM S(U S(UWP) S(UWP) S(UWP S(UWP) A) ) E_SYSTEM_TEMP S(U S(UA) S(UA) S(UA) S(UA) A) E_TIMEOUT S(U (9) S(TLE) S(TLE) S(TLE S(TLE) A) ) E_TIMESTAMP_MISM ATCH E_TOO_MANY_UPDAT ES E_UNABLE_TO_COMP LETE E_UNABLE_TO_PROC (2) (2) EED E_UNCOORDINATED E_UNDEFINED_ATT SC( (3) U(NV) A(UAT A(UAT) IC) ) E_UNRELIABLE_DAT A E_UNSOLICITED E_UNSUPPORTED_OC U(OCV ) E_UNSUPPORTED_ST RAT E_UNUSABLE_DATA 99 Part 11 - Directory Services Protocols March 1994 (Stable) E_VERSION S(U A) E_ZERO_VALUES A(CV) A(CV) 100 Part 11 - Directory Services Protocols March 1994 (Stable) Table 13 - Error actions (continued) Situation (See Table 11) Symptom (See Table Trace 10) Modify- Remove- Read Compar - RDN Entry e Evalu - ation E_ACCESS SC(IAR) SC(IAR) SC(IAR) SC(IAR (14) (14) (14) )(14) E_ADMIN_LIMIT S(ALE) S(ALE) S(ALE) E_ALIAS_DEREF E_ALIAS_LOOP E_ALIAS_PROBLEM E_ARG_BOUNDS S(UWP)( S(UWP)( S(UWP) 12) 12) (12) E_ARG_SYNTAX Rej Rej Rej Rej Rej E_ARG_VIOL Rej Rej Rej Rej Rej E_ATT_BOUNDS N(IAS) A(CV) (7) E_ATT_OR_VALUE_EXI STS E_ATT_SYNTAX N(IAS) A(IAS) (7) E_ATT_VALUE N(IAS) A(IAS) (7) E_AUTHENTICATION E_BUSY S(B) S(B) S(B) S(B) E_CANT_CONSTRUCT E_CANT_INCORPORATE E_CHAIN E_CREDENTIALS E_DBE S(DE) S(DE) S(DE) S(DE) E_DIT_STRUCTURE E_DN A(CV) A(IAS) E_DSA 101 Part 11 - Directory Services Protocols March 1994 (Stable) Table 13 - Error actions (continued) Situation (See Table 11) Symptom (See Trace Table 10) Modify- Remove- Read Compar - RDN Entry e Evalu ation E_ENTRY_EXISTS U(EAE) E_EXTENSION S(UCE) S(UCE) S(UCE) S(UCE) E_ILLEGAL_ROOT_O N(NSO) N(NSO) N(NSO) N(NSO) BJ E_ILLEGAL_ROOT_V N(IAS) A(IAS) (7) AL E_INACTIVE_AGREE MENT E_INVALID_AGREEM ENT E_LOOP E_MATCH A(IM) A(IM) (7) E_MISSED_PREVIOU S E_MISSING_AVA E_MISSING_OBJECT _CLASS E_MORE_CURR_UPD_ RCD E_MULTI_DSA U(AMD) U(AMD) E_NAMING_VIOLATI U(NV) ON E_NO_AGMT_W_THIS _DSA E_NO_ENTRIES_IN_ ST E_NON_LEAF_OPERA U(NAN) U(NAN) TION E_NONNAMING_ATTR IBUTE E_NOT_SINGLE_VAL A(CV) UED E_NO_SUCH_ATT A(NSA)( A(NSA) 4) (4) 102 Part 11 - Directory Services Protocols March 1994 (Stable) E_NO_SUCH_OBJECT E_NO_SUCH_VALUE E_OBJECT_CLASS_M OD E_OBJECT_CLASS_V U(OCV) IOL E_OUTSIDE_UOR 103 Part 11 - Directory Services Protocols March 1994 (Stable) Table 13 - Error actions (continued) Situation (See Table 11) Symptom (See Trace Table 10) Modify- Remove- Read Compar - RDN Entry e Evalu ation E_PREVIOUSLY_COO RD E_REFERENCE E_SCOPE E_PREVIOUSLY_SOL ICITED E_SYSTEM_PERM S(UWP) S(UWP) S(UWP) S(UWP) S(UWP ) E_SYSTEM_TEMP S(UA) S(UA) S(UA) S(UA) S(UA) E_TIMEOUT S(TLE) S(TLE) S(TLE) S(TLE) E_TIMESTAMP_MISM ATCH E_TOO_MANY_UPDAT ES E_UNABLE_TO_COMP LETE E_UNABLE_TO_PROC EED E_UNCOORDINATED E_UNDEFINED_ATT A(UAT) A(NSA)( A(NSA) (7) 4) E_UNRELIABLE_DAT A E_UNSOLICITED E_UNSUPPORTED_OC E_UNSUPPORTED_ST RAT E_UNUSABLE_DATA E_VERSION E_ZERO_VALUES (11) 104 Part 11 - Directory Services Protocols March 1994 (Stable) Table 13 - Error actions (continued) Situation (See Table 11) Symptom (See List Search Search Abandon Table 10) (Filter (Filter) Entry ) E_ACCESS SC(IAR) SC(IAR)(1 SC(IAR)( (14) 4) 14) E_ADMIN_LIMIT S(ALE)( S(ALE)(13 S(ALE)(1 13) ) 3) E_ALIAS_DEREF (5) E_ALIAS_LOOP (5) E_ALIAS_PROBLEM (5) E_ARG_BOUNDS S(UWP)( S(UWP)(12 S(UWP)(1 12) ) 2) E_ARG_SYNTAX Rej Rej Rej Rej E_ARG_VIOL Rej Rej Rej E_ATT_BOUNDS A(CV) E_ATT_OR_VALUE_EX ISTS E_ATT_SYNTAX A(IAS) E_ATT_VALUE A(IAS) E_AUTHENTICATION E_BUSY S(B) S(B) S(B) E_CANT_CONSTRUCT E_CANT_INCORPORAT E E_CHAIN E_CREDENTIALS E_DBE S(DE) S(DE) S(DE) E_DIT_STRUCTURE E_DN A(IAS) E_DSA (5) 105 Part 11 - Directory Services Protocols March 1994 (Stable) Table 13 - Error actions (continued) Situation (See Table 11) Symptom (See Table List Search Search Abandon 10) (Filte (Filter) Entry r) E_ENTRY_EXISTS E_EXTENSION S(UCE) S(UCE)(13 S(UCE)(1 (13) ) 3) E_ILLEGAL_ROOT_OBJ (10) E_ILLEGAL_ROOT_VAL A(IAS) E_INACTIVE_AGREEME NT E_INVALID_AGREEMEN T E_LOOP (5) E_MATCH A(IM) E_MISSED_PREVIOUS E_MISSING_AVA E_MISSING_OBJECT_C LASS E_MORE_CURR_UPD_RC D E_MULTI_DSA E_NAMING_VIOLATION E_NO_AGMT_W_THIS_D SA E_NO_ENTRIES_IN_ST E_NON_LEAF_OPERATI ON E_NONNAMING_ATTRIB UTE E_NOT_SINGLE_VALUE D E_NO_SUCH_ATT E_NO_SUCH_OBJECT E_NO_SUCH_VALUE E_OBJECT_CLASS_MOD E_OBJECT_CLASS_VIO L 106 Part 11 - Directory Services Protocols March 1994 (Stable) E_OUTSIDE_UOR 107 Part 11 - Directory Services Protocols March 1994 (Stable) Table 13 - Error actions (continued) Situation (See Table 11) Symptom (See Table List Search Search Abandon 10) (Filte (Filter) Entry r) E_PREVIOUSLY_COORD E_REFERENCE E_SCOPE E_PREVIOUSLY_SOLIC ITED E_SYSTEM_PERM S(UWP) S(UWP) S(UWP) Ab(CA) E_SYSTEM_TEMP S(UA) S(UA) S(UA) Ab(CA) E_TIMEOUT S(TLE) S(TLE)(13 S(TLE)(1 (13) ) 3) E_TIMESTAMP_MISMAT CH E_TOO_MANY_UPDATES E_UNABLE_TO_COMPLE (B) S(B) S(B) Ab(CA) TE E_UNABLE_TO_PROCEE D E_UNCOORDINATED E_UNDEFINED_ATT (6) (6) E_UNRELIABLE_DATA E_UNSOLICITED E_UNSUPPORTED_OC E_UNSUPPORTED_STRA T E_UNUSABLE_DATA E_VERSION E_ZERO_VALUES 108 Part 11 - Directory Services Protocols March 1994 (Stable) Table 13 - Error actions (continued) Situation (See Table 11) Symptom (See Coordina Update Request Table 10) te Shadow Shadow Shadow Update Update E_ACCESS E_ADMIN_LIMIT E_ALIAS_DEREF E_ALIAS_LOOP E_ALIAS_PROBLEM E_ARG_BOUNDS E_ARG_SYNTAX E_ARG_VIOL E_ATT_BOUNDS E_ATT_OR_VALUE_EX ISTS E_ATT_SYNTAX E_ATT_VALUE E_AUTHENTICATION E_BUSY SH(UT) SH(UT) SH(UT) E_CANT_CONSTRUCT SH(UWP) E_CANT_INCORPORAT SH(UWP) E E_CHAIN E_CREDENTIALS E_DBE E_DIT_STRUCTURE E_DN E_DSA 109 Part 11 - Directory Services Protocols March 1994 (Stable) Table 13 - Error actions (continued) Situation (See Table 11) Symptom (See Table Coordina Update Request 10) te Shadow Shadow Shadow Update Update E_ENTRY_EXISTS E_EXTENSION E_ILLEGAL_ROOT_OBJ E_ILLEGAL_ROOT_VAL E_INACTIVE_AGREEME SH(IA) SH(IA) SH(IA) NT E_INVALID_AGREEMEN SH(IAID) SH(IAID) SH(IAID T ) E_LOOP E_MATCH E_MISSED_PREVIOUS SH(MP) SH(MP) E_MISSING_AVA E_MISSING_OBJECT_C LASS E_MORE_CURR_UPD_RC SH(UAR) D E_MULTI_DSA E_NAMING_VIOLATION E_NO_AGMT_W_THIS_D SH(IAID) SH(IAID) SH(IAID SA ) E_NO_ENTRIES_IN_ST SH(NI) E_NON_LEAF_OPERATI ON E_NONNAMING_ATTRIB UTE E_NOT_SINGLE_VALUE D E_NO_SUCH_ATT SH(IIR) E_NO_SUCH_OBJECT SH(IIR) E_NO_SUCH_VALUE E_OBJECT_CLASS_MOD E_OBJECT_CLASS_VIO L 110 Part 11 - Directory Services Protocols March 1994 (Stable) E_OUTSIDE_UOR SH(IIR) 111 Part 11 - Directory Services Protocols March 1994 (Stable) Table 13 - Error actions (continued) Situation (See Table 11) Symptom (See Table Coordina Update Request 10) te Shadow Shadow Shadow Update Update E_PREVIOUSLY_COORD SH(IS) E_REFERENCE E_SCOPE E_PREVIOUSLY_SOLIC SH(IS) ITED E_SYSTEM_PERM SH(UWP) SH(UWP) SH(UWP) E_SYSTEM_TEMP SH(UT) SH(UT) E_TIMEOUT E_TIMESTAMP_MISMAT SH(FUR) SH(FUR) CH E_TOO_MANY_UPDATES SH(FUR) E_UNABLE_TO_COMPLE TE E_UNABLE_TO_PROCEE D E_UNCOORDINATED SH(IS) E_UNDEFINED_ATT E_UNRELIABLE_DATA SH(FUR) E_UNSOLICITED SH(IS) E_UNSUPPORTED_OC E_UNSUPPORTED_STRA SH(US) SH(US) T E_UNUSABLE_DATA SH(IIR) E_VERSION E_ZERO_VALUES 112 Part 11 - Directory Services Protocols March 1994 (Stable) Table 13 - Notes (continued) 113 Part 11 - Directory Services Protocols March 1994 (Stable) NOTES 1 Use A-U-ABORT. Note, however, that extra elements are permitted here. 2 An "unable-to-proceed" error becomes SC(IC) for bind and N(NSO) for operations if no DSA contacted can located the object. 3 An undefined attributed encountered during name resolution is only an error- N(NSO) - if the entry is identified as local. See also Note 10 below. 4 The A(NSA) condition is reserved in the case of "read" for the situation when no attribute of the specific list provided can be returned (for reasons that include security errors). 5 Any failure to propagate a search causes abandonment of that part of the search. 6 Undefined attributes are regarded as not matched or found, but cause no errors in search. 7 This error, if detected, should be ignored; processing continues. 8 This error would occur as a result of a bind argument with a name containing too many RDNs for the DSA. Use either S(UA) or S(IC). 9 DSAs should use the time-limit service control with local timeout to limit the remote validation of credentials; if the operation fails as a result, S(UA) is used. 10 For a single-entry search, N(NSO) may be used. 11 Either the whole attribute should be removed, or the deleteOldRDNflag should be ignored. 12 Wherever S(UWP) appears in the above tables beside EARGBOUNDS, a ROSE "Rej" is also admissible. 13 The error is returned when there are no partial results, otherwise a partialOutcomeQualifier with the appropriate limitProblem is returned (cf Directory Documents, Part 3, item g of clause 12.8.2,and Part 3, 114 Part 11 - Directory Services Protocols March 1994 (Stable) Table 13 - Notes (concluded) NOTES 14 If a DSA generates a chained operation on the basis of a cross reference and receives a serviceError with the problem of invalidReference in response, then it is recommended that the invalid cross reference be removed to eliminate repeated errors. Note that attempting to resolve the correct reference via the returnCrossRefs mechanism should be regarded as nonreliable due to the optional nature of returnCrossRefs. The resolution of an invalidReference due to a superior or subordinate reference is a local administrative issue. Table 14 - Simple credential fields and protected simple authentication Equivalent Notation in Simple Credential Directory Field Documents, Part 8, figure 2 name A time1 tA 1 time2 tA 2 random1 qA 1 random2 qA 2 password protected2 115 Part 11 - Directory Services Protocols March 1994 (Stable) Annex A (normative) Maintenance of Attribute Syntaxes A.1 Introduction The attribute types defined in the Directory Documents, Part 6, and listed in table 1 have requirements, in DSAs which support them, for underlying algorithms that: a) check attribute values for syntactical correctness and compliance with pragmatic constraints; b) match attribute values (comparing for equality, for matching substrings, and for relative ordering). A.2 General Rules A DSA may receive a legitimately encoded attribute or AVA that is unsupported by the DSA. If the DSA is not required to act on it, or to store it within an entry, it may handle it by passing it on without error. Such attributes may also be used in search filter-item definitions: in this case, no error is reported, but the filter-item shall be deemed to be undefined for all entries in the DSA. This rule applies to occurrences of attributes in both operation arguments and results. Conversely, a DSA must return a suitable error if an operation requires it to act on or store an attribute or AVA of type unsupported by the DSA. This constraint applies even for AVAs that are contained in attributes that take names as values, since the DSA will be unable correctly to match the attribute values without this attribute information. A.3 Checking Algorithms The subclauses below give additional checks (beyond those directly implied by the Directory Documents) which shall be applied to attributes before they are stored in the DSA. 116 Part 11 - Directory Services Protocols March 1994 (Stable) A.3.1 distinguishedNameSyntax Each component AVA must be checked, unregistered attribute types comprising an error; check also that no two AVAs in the same RDN have the same attribute type. A.3.2 integerSyntax Local implementations may apply local limitations. A.3.3 telephoneNumberSyntax The value of policing further rules is for further study (this applies also to telexNumber, teletexTerminalIdentifier, facsimileTelephoneNumber, G3FacsimileNonBasicParameters, x121Address, and iSDNAddress). A.3.4 countryName The value must be checked for compliance with ISO 3166: 1981 (E/F). (Note that from time to time further codes may be allocated.) A.3.5 preferredDeliveryMethod The values of the integer elements should not be restricted. A.3.6 presentationAddress No further checks should be applied. A.4 Matching Algorithms Matching algorithms are conveniently defined in terms of a two-step process: a) Take the checked reference value, and the value to be matched, and, if necessary, reduce them to a canonical (i.e., standard) form (normalization) appropriate to each attribute syntax. b) Carry out the comparison in the specified way (e.g., equality, substrings or ordering) using the appropriate rules for the value - character string, integer, boolean, 117 Part 11 - Directory Services Protocols March 1994 (Stable) etc. Note that the lexical ordering of character strings (when supported) may be subject to local rules. IMPORTANT NOTE: The combination of normalization and comparison may be replaced, in a particular implementation, by equivalent procedures. Additional notes on normalization are given below. A.4.1 UTCTimeSyntax If the "seconds" field is absent, it shall be inserted, and set to "00", and the form converted to the "Z" form.Note. The normalization strategy does not match times where the stored form omits the seconds field, and the compared form contains it, e.g., 8804261919Z 880426191926Z (It might have been expected that these two forms,which coincide in time to within a few seconds, would be considered identical.) A.4.2 distinguishedNameSyntax For each attribute value, carry out normalization in accordance with the normalization rules defined for the type (if registered); values corresponding to unregistered attribute types are left unchanged at this stage. A.4.3 caseIgnoreListSyntax To facilitate matching, particularly for substrings, normalization may be considered in terms of a representation which replaces the separate ASN.1 elements by a single string with a delimiter. 118 Part 11 - Directory Services Protocols March 1994 (Stable) Annex B (informative) Glossary The following abbreviations may be useful; not all are used within these agreements. ACL Access Control List ACSE Association Control Service Element ADDMD Administration Directory Management Domain AETitle Application Entity Title APDU Application Protocol Data Unit ASE Application Service Element ASN.1 Abstract Syntax Notation - 1 AVA Attribute Value Assertion BRM Basic Reference Model CA Certification Authority CCITT The International Telegraph and Telephone Consultative Committee CEN Committee for European Normalization CENELEC Committee for European Normalization Electronique CEPT Committee of European Posts and Telephones COS Corporation for Open Systems DAP Directory Access Protocol DIB Directory Information Base DIT Directory Information Tree DMD Directory Management Domains DSA Directory System Agent DSP Directory System Protocol 119 Part 11 - Directory Services Protocols March 1994 (Stable) DUA Directory User Agent EWOS European Workshop for Open Systems FTAM File Transfer, Access & Management INTAP Interoperability Technical Association for Information Processing, Japan ISDN Integrated Services Digital Network ISO/IEC International Organization for Standardization KT Knowledge Tree LL Lower layers of OSI model (layers 1-4) MAP Manufacturing Automation Protocol MHS Message Handling Systems NIST National Institute of Standards and Technology NSAP Network Services Access Point OSI Open Systems Interconnection PKCS Public Key Crypto System POSI Promotion for Open System Interconnection PRDMD Private Directory Management Domain PSAP Presentation Service Access Point RDN Relative Distinguished Name ROSE Remote Operations Service Element SSAP Session Service Access Point SIG Special Interest Group SPAG Standards Promotion & Application Group TOP Technical and Office Protocols TSAP Transport Service Access Point UL Upper layers of OSI model (layers 5-7) 120 Part 11 - Directory Services Protocols March 1994 (Stable) UPU Universal Postal Union 121 Part 11 - Directory Services Protocols March 1994 (Stable) Annex C (informative) Requirements for Distributed Operations The following material is included for tutorial purposes, and does not represent material additional to the Directory Documents. It is also not intended as a complete statement of requirements (the Distributed Operations part of the Directory Documents should be referred to for a complete treatment). C.1 General Requirements DSAs supporting distributed operations and claiming support of chaining must fully support DSP, as defined by the Directory Documents. DSAs supporting distributed operations must always be able to accept incoming DSP associations and invocations. DSAs claiming support of chaining must support: a) Loop detection b) Loop avoidance In passing on operations (when chaining or multi-casting), the original DAP-supplied invocation must be passed on without change of content. In particular, there must be no alteration in anyway of any primitive content. The support of a facility for returning cross-references (Directory Documents, Part 4, clause 10.4.1) is optional. To ensure that traceInformation can be analyzed properly, DSAs shall only possess names that are compliant with the recommendations of the Directory Documents, Part 7 (including Annex B). C.2 Protocol Support C.2.1 Usage of ChainingArguments When using ChainingArguments:2 a) originator need not be used if requestor in 2In this subclause, the names of protocol elements (within ChainingArguments) are italicized. 122 Part 11 - Directory Services Protocols March 1994 (Stable) CommonArguments is used; b) targetObject shall not be used unless the target object differs from object/base object (if it is present, object/base object are ignored for purposes of name resolution); c) operationProgress, traceInformation, aliasDereferenced, aliasedRDNs, referenceType, and timeLimit shall be generated, accepted, and used in accordance with the Directory Documents; d) returnCrossReferences and info may optionally be generated, and shall always be accepted. C.2.2 Usage of ChainingResults When using ChainingResults:3 crossReferences and info may optionally be generated, and shall always be accepted. 3In this subclause, the names of protocol elements (within ChainingResults) are italicized. 123 Part 11 - Directory Services Protocols March 1994 (Stable) Annex D (informative) Guidelines for Applications Using the Directory D.1 Tutorial D.1.1 Overview Applications may have a requirement for Directory functionality. This tutorial provides assistance to those groups intending to specify Directory usage for a specific application (e.g., Message Handling Systems). D.1.2 Use of the Directory Schema D.1.2.1 Use of Existing Object Classes Applications wishing to use the Directory should have determined within a standard, Implementor's Agreements, or on a propriety basis, the relevant Directory schema for their objects. Consider the following two examples: a) Network management applications may with to define a SMAE object class; b) File transfer applications may with to define a File Store object class. Groups should examine relevant standards to determine if application- specific object classes or attributes have been already defined before considering any additional definition. These object classes and attributes may be found in a variety of places including a specific application standard (e.g., [Recommendation CCITT '88 X.402 | ISO 10021-2] and the Directory Documents.). Standardized object classes and attributes should be strongly considered before additional schema elements are created. D.1.2.2 Kinds of Object Classes There are effectively two kinds of object classes permitted within the Directory Documents: structural and auxiliary. The terms structural and auxiliary are used here for convenience when referring to particular kinds of object classes. The terms 124 Part 11 - Directory Services Protocols March 1994 (Stable) themselves are not defined in the Directory Documents. Structural object classes have associated DIT structure rules (which control naming). Entries of this object class type are intended to be instantiated in Directory entries. A structural object class provides information on the base mandatory and optional content of a DIT entry. An auxiliary object class provides information to enhance the mandatory and optional contents of entries. It is always used in conjunction with a structural object class. The object class hierarchy is formed as a result of the definition of structural object classes, and the addition of auxiliary object classes. For example, all object classes in the Directory Documents, Part 7, are structural except for strong Authentication User and certification Authority. These two object classes should be considered auxiliary and used in conjunction with other, structural object classes. D.1.2.3 Use of Unregistered Object Classes The Directory Documents, Part 2, clause 9.4.1 provides a "special" form of object class called "unregistered." An unregistered object class is not assigned an object identifier. One of the uses for unregistered object classes is to provide a means of creating a single Directory entry which logically represents a variety of object classes.Uses for unregistered object classes include: a) Locally adding attributes to a predefined superclass; b) Locally making optional attribute types in a predefined superclass mandatory; c) Creating an object class derived from multiple superclasses, without needless proliferation of registered object classes. For example, it may be advantageous to provide an entry which represents a person who is both a MHS and a FTAM user. Unregistered object classes may best be illustrated by example. Consider an entry which represents a collection of company entries for Fizzy Company whose users have MHS O/R addresses. Using the guidelines above, the Fizzy Company defines an unregistered object class using the structural object class 125 Part 11 - Directory Services Protocols March 1994 (Stable) organizationalPerson from the Directory Documents, Part 7, and the auxiliary object class mhs-user from the MHS standards [Recommendation X.402 j ISO 10021-2] as follows: fizzyCompanyPerson ::= OBJECT-CLASS SUBCLASS OF organizationalPerson, mhs-user MUST CONTAIN {} MAY CONTAIN {} Note that no object identifier is assigned. Also note that since there are not MUST or MAY CONTAIN's in the fizzyCompanyPerson Object Class, the last two lines of the object class assignment (i.e., "MUST CONTAIN MAY CONTAIN") are optional. As with the registered form of object classes, an unregistered object class always inherits all the attributes in any of its superclasses. There is no mechanism defined whereby a subclass may selectively inherit attributes from its superclasses. An unregistered object class always appears as a leaf in the Object Class tree. (i.e., An unregistered object class may not be a superclass of some other object class). Using unregistered object classes in conjunction with multiple inheritance is useful as shown by figure 4 in which three ways of creating the same two object classes are shown. Either three, four, or five registered object classes are used. Examples (a) and (c) in figure 4 are both better ways of defining the object classes than that in example (b), even though example (c) needs to use one more registered object class than example(b). This is because the multiple inheritance technique, used in examples (a) and (c), enables a Directory User searching the Directory to easily create a filter to find all entries that contain mhs-user attributes, based on a value in the object class attribute (Each Directory entry contains a list of the object identifiers of the object classes it has inherited from, so the filter would just have to find all entries that held the object identifier value of mhs-user). 126 Part 11 - Directory Services Protocols March 1994 (Stable) +---------------------------+---------------------+-------------- -------+ | per mhs ae | per ae | per mhs ae | | \ / \ / | | | | \ / \ / | | mhs-per[ur] mhs-ae[ur] | mhs-per mhs-ae | mhs-per mhs-ae | +---------------------------+---------------------+-------------- -------+ | Example a | Example b | Example c | +---------------------------+---------------------+-------------- -------+ | [ur] = unregistered | | per = person | | mhs = mhs-user | | ae = applicationEntity | +---------------------------------------------------------------- -------+ Figure 4 - Three ways of creating two object classes Example (a), which uses three registered object classes, is better than example (c), which uses five, because registering the extra two object classes does not provide any advantage over not registering them, and the first method avoids needless proliferation of registered object classes. D.1.2.4 Side Effects of Creating Unregistered Object Classes This subclause discusses two side effects of creating unregistered object classes. a) When an unregistered object class is defined from a single superclass, there is no means available to distinguish between the two. Within the local scope for which the unregistered class is defined, all relevant entries are considered to belong to the unregistered class. The following is an example of this problem: An object class of oC1(reg) has attribute type at1 mandatory and at2 optional. An unregistered form of this, oC1(unreg)is created, which makes at2 mandatory. When an Add Entry operation is received with both attributes present, the 127 Part 11 - Directory Services Protocols March 1994 (Stable) entry could belong to either form of oC1; it is indeterminate. After the entry is added a Modify Entry operation is received which requests the removal of attribute type at2. It is not clear if this operation should succeed, or whether an object class violation should be reported. If the attribute may be removed, then the entry belonged to the oC1(reg) object class and the unregistered form never existed, otherwise if the attribute may not be removed, then the entry belonged to oC1(unreg) and the registered form no longer exists. b) More than one unregistered object class cannot be defined from the same superclass(es) for use within the same local scope, as there is no means available to distinguish the classes from one another. D.2 Creation of New Object Classes If no appropriate object class is available, a new object class may be defined. This should only be done if no standardized object classes and attributes can fulfill the requirements. D.2.1 Creation of New Subclasses Generally, an application-specific object class is defined as a subclass of a pre-existing Directory object class. These object classes are specified in the Directory Documents, Part 7. The subclass may be structural or auxiliary. Optional attributes of the superclass may be made mandatory. New attributes may also be added. For example, MHS has used the Directory structural object class applicationEntity to derive the object class for their MHS-specific application entity MTAs. If absolutely no relevant object class is available, an object class may be defined as a subclass of the basic object class called "Top." If no appropriate object class is available, a new object class may be defined. This should only be undertaken if no standardized object class can fulfill the requirements. When defining new object classes the object-class macro, as defined in the Directory Documents, Part 2, clause 9.4.6, should be used. If new subclasses are defined, suggested or required name forms may also be specified in text. 128 Part 11 - Directory Services Protocols March 1994 (Stable) D.2.2 Creation of New Attributes If no appropriate attributes are available, a new attribute type may be defined. This should only be undertaken if no standardized attributes can fulfill the requirements. When defining new attributes the attribute macro, as defined in the Directory Documents, Part 2, clause 9.5.3, should be used. D.3 DIT Structure Rules Applications may desire to provide guidance on DIT structure rules and naming. As with object classes, standardized or suggested structure (including naming) rules from the Directory Documents part 7, Annex B and application-specific standards should be consulted before providing new structure rules. Annex B in the Directory Documents, Part 7, provides guidelines on how to specify this information. Structure rules associated with superclasses should be adopted wherever suitable. D.4 Use of AETITLE Applications wishing to make use of the AETitle field to access applicationEntity objects in the Directory are referred to Amendment 1 to ISO8650 for guidance on the purpose and appropriate useage of the AETitle field. In particular, implementors should be aware that: a) AETitle should be used to uniquely distinguish individual application entities. It is inappropriate for applications to define a fixed AETitle to apply to all its instantiations; b) The Directory does not perform name resolution on an object identifier (e.g., AETitle name form 2). The Directory does not support lookup based on OID, and AETitle name form 2 does not constitute a Directory Distinguished Name. 129 Part 11 - Directory Services Protocols March 1994 (Stable) Annex E (informative) Template for an Application Specific Profile for Use of the Directory The template defined below should be used by OIW SIGs intending to specify Directory usage. Such application specific profiles shall be contained in application specific chapters of the OIW agreements. The information under each heading should be filled in (the text under each heading provides guidance on the meaning of the heading and should not be included in the profile). a) PROFILE TITLE Application specific profiles are named in the following way: OIW DIRECTORY PROFILE (e.g., OIW DIRECTORY STRONG AUTHENTICATION DIRECTORY PROFILE ) b) OTHER PROFILES SUPPORTED Other OIW Directory profiles which are to be used by this specific application are listed here. Attributes, attribute sets, object classes and structure rules that are referenced in these profiles need not be enumerated below. c) STANDARD APPLICATION SPECIFIC ATTRIBUTES AND ATTRIBUTE SETS Any attributes supported from the relevant standards. For example, the MHS SIG might include mhs-or-address here. d) STANDARD APPLICATION SPECIFIC OBJECT CLASSES Any object classes supported from the relevant standards. For example, the MHS SIG might include mhs-user here. e) OIW APPLICATION SPECIFIC ATTRIBUTES AND ATTRIBUTE SETS This, optional, component of this profile allows for the specification of OIW application specific attributes and attribute sets. This section of this template should be used rarely and with consideration that no standard profile or attribute/attribute set exists which can be used. f) OIW APPLICATION SPECIFIC OBJECT CLASSES 130 Part 11 - Directory Services Protocols March 1994 (Stable) This, optional, component of this profile allows for the specification of OIW application specific object classes. This section of this template should be used rarely and with consideration that no standard profile or object class exists which can be used. g) STRUCTURE RULES Guidance for DIT structural rules, provided only when structure rules associated with superclasses are not adopted. The Directory Documents, Part 7, Annex B provide an example and guideline to use in specifying this information. 131 Part 11 - Directory Services Protocols March 1994 (Stable) Annex F (informative) Bibliography [ELGA85] ElGamal T., "A Public Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms," IEEE Transactions on Information Theory, vol. IT-31, No. 4, July 1985. [DIFF76] Diffie W., Hellman M., "New Directions in Cryptography," IEEE Transactions on Information Theory, vol. IT-22, Nov. 1976 [COPP86] Coppersmith, D., Odlyzko, A., Schroeppel, R., "Discrete Logarithms inGF (p)," Algorithmica, vol. 1, 1986. [McCl79] McClellan, J., Rader, C., Number Theory in Digital Signal Processing, Prentice-Hall, 1979. [PATT87] Patterson, W., Mathematical Cryptology for Computer Scientists and Mathematicians, Rowman & Littlefield, 1987. [ODLY] Odlyzko, A., "On the Complexity of Computing Discrete Logarithms and FactoringIntegers," to appear in Fundamental Problems in Communication and Computation, B. Gopinath and T.Loven, Eds., New York, NY: Springer. [ODLY84] Odlyzko, A., "Discrete Logarithms in Finite Fields and Their Cryptographic Significance," in Advances in Cryptology, Proceedings of EUROCRYPT 84. New York, NY:Springer-Verlag, pp. 224-314. [ELGA85b] ElGamal, T., "A Subexponential-time Algorithm for Computing Discrete Logarithms over GF (p2)," IEEE Transactions on Information Theory, vol. IT-31, July 1985. [SIER88] Sierpinski, W., Elementary Theory of Numbers, North-Holland 1988. [RFC1115] Linn, J., Privacy Enhancement for Internet Electronic Mail: Part III - Algorithms, Modes, and Identifiers, RFC-1115, August 1989, IAB Privacy Task Force. 132