information technology — open systems interconnection...

Information technology —

Open Systems Interconnection —

The Directory: Models

Recommendation X.501

ISO/IEC 9594-2

ISO/IEC 9594-2 : 1993(E)

ii ITU-T Rec. X.501 (1993 E)

Contents

Foreword ........................................................................................................................................................ iv

Introduction ...................................................................................................................................................... v

SECTION 1: GENERAL 11 Scope ..................................................................................................................................................... 1

2 Normative references ............................................................................................................................ 2

3 Definitions ............................................................................................................................................. 3

4 Abbreviations ........................................................................................................................................ 4

5 Conventions .......................................................................................................................................... 4

SECTION 2: OVERVIEW OF THE DIRECTORY MODELS 56 Directory Models .................................................................................................................................. 5

SECTION 3: MODEL OF DIRECTORY USER INFORMATION 87 Directory Information Base .................................................................................................................. 8

8 Directory Entries ................................................................................................................................. 10

9 Names .................................................................................................................................................. 17

SECTION 4: DIRECTORY ADMINISTRATIVE MODEL 1910 Directory Administrative Authority model ......................................................................................... 19

SECTION 5: MODEL OF DIRECTORY ADMINISTRATIVE AND OPERATIONALINFORMATION 2411 Model of Directory Administrative and Operational Information ...................................................... 24

SECTION 6: THE DIRECTORY SCHEMA 3112 Directory Schema ................................................................................................................................ 31

13 Directory System Schema ................................................................................................................... 43

14 Directory schema administration ........................................................................................................ 46

SECTION 7: SECURITY 5215 Security model .................................................................................................................................... 52

16 Basic Access Control .......................................................................................................................... 54

SECTION 8: DSA MODELS 6617 DSA Models ........................................................................................................................................ 66

SECTION 9: DSA INFORMATION MODEL 6918 Knowledge .......................................................................................................................................... 69

19 Basic Elements of the DSA Information Model ................................................................................. 73

20 Representation of DSA Information ................................................................................................... 77

SECTION 10: DSA OPERATIONAL FRAMEWORK 85

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) iii

21 Overview ............................................................................................................................................. 85

22 Operational bindings ........................................................................................................................... 86

23 Operational binding specification and management ........................................................................... 89

24 Operations for operational binding management................................................................................ 93

Annex A — Object identifier usage............................................................................................................. 100

Annex B — Information Framework in ASN.1........................................................................................... 103

Annex C — SubSchema Administration Schema in ASN.1 ....................................................................... 109

Annex D — Basic Access Control in ASN.1 .............................................................................................. 113

Annex E — DSA Operational Attribute Types in ASN.1 ........................................................................... 116

Annex F — Operational Binding Management in ASN.1 ........................................................................... 119

Annex G — The Mathematics of Trees ....................................................................................................... 123

Annex H — Name Design Criteria .............................................................................................................. 124

Annex J— Examples of various aspects of schema..................................................................................... 126

Annex K — Overview of Basic Access Control Permissions ..................................................................... 129

Annex L — Example of Basic Access Control ........................................................................................... 133

Annex M — DSE Type Combinations ........................................................................................................ 151

Annex N — Modelling of knowledge ......................................................................................................... 153

Annex P — Alphabetical index of definitions ............................................................................................. 158

ISO/IEC 9594-2 : 1993(E)

iv ITU-T Rec. X.501 (1993 E)

ForewordISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)form the specialized system for worldwide standardization. National bodies that are members of ISO or IECparticipate in the development of International Standards through technical committees established by the respectiveorganization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate infields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISOand IEC, also take part in the work.

In the field of information technology ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.Publication as an International Standard requires approval by at least 75% of the national bodies casting a vote.

International Standard ISO/IEC 9594-2 was prepared by Joint Technical committee ISO/IEC JTC 1, Informationtechnology , Subcommittee SC21, Information retrieval, transfer and management for open systems interconnection(OSI), in collaboration with ITU-T. The identical text is published as ITU-T Recommendation X.501.

This second edition technically revises and enhances, but does not replace, the first edition of ISO/IEC 9594.Implementations may still claim conformance to the first edition.

This second edition of ISO/IEC 9594 specifies version 1 of the Directory service and protocols. The first edition alsospecifies version 1. Differences between the service and between the protocols defined in the two editions areaccommodated using the rules of extensibility defined in part 5 of this edition.

ISO/IEC 9594 consists of the following parts, under the general title Information technology — Open systemsInterconnection — The Directory :

— Part 1: Overview of concepts, models, and services

— Part 2: Models

— Part 3: Abstract service definition

— Part 4: Procedures for distributed operation

— Part 5: Protocol specifications

— Part 6: Selected attribute types

— Part 7: Selected object classes

— Part 8: Authentication framework

— Part 9: Replication

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) v

IntroductionThis Recommendation | International Standard, together with the other Recommendation | International Standards,has been produced to facilitate the interconnection of information processing systems to provide directory services.A set of such systems, together with the directory information which they hold, can be viewed as an integratedwhole, called the Directory . The information held by the Directory, collectively known as the Directory InformationBase (DIB), is typically used to facilitate communication between, with or about objects such as application entities,people, terminals and distribution lists.

The Directory plays a significant role in Open Systems Interconnection, whose aim is to allow, with a minimum oftechnical agreement outside of the interconnection standards themselves, the interconnection of informationprocessing systems:

— from different manufacturers;

— under different managements;

— of different levels of complexity; and

— of different ages.

This Recommendation | International Standard provides a number of different models for the Directory as aframework for the other Recommendations in the ITU-T X.500 series | parts of ISO/IEC 9594. The models are theoverall (functional) model; the administrative authority model, generic Directory Information Models providingDirectory User and Administrative User views on Directory information, generic DSA and DSA informationmodels, an Operational Framework and a security model.

The generic Directory Information Models describe, for example, how information about objects is grouped to formDirectory entries for those objects and how that information provides names for objects.

The generic DSA and DSA information models and the Operational Framework provide support for Directorydistribution.

This Recommendation | International Standard provides a specialization of the generic Directory InformationModels to support Directory Schema administration.

This second edition technically revises and enhances, but does not replace, the first edition of this Recommendation |International Standard. Implementations may still claim conformance to the first edition.

This second edition specifies version 1 of the Directory service and protocols. The first edition also specifies version1. Differences between the services and between the protocols defined in the two editions are accommodated usingthe rules of extensibility defined in this edition of X.519 | ISO/IEC 9594-5.

Annex A, which is an integral part of this Recommendation | International Standard, summarizes the usage ofASN.1 object identifiers in the ITU-T X.500 series Recommendations | ISO/IEC 9594.

Annex B, which is an integral part of this Recommendation | International Standard, provides the ASN.1 modulewhich contains all of the definitions associated with the information framework.

Annex C, which is an integral part of this Recommendation | International Standard, provides the subschemaadministration schema in ASN.1.

Annex D, which is an integral part of this Recommendation | International Standard, provides the ASN.1 module forBasic Access Control.

Annex E, which is an integral part of this Recommendation | International Standard, provides the ASN.1 modulewhich contains all the definitions associated with DSA operational attribute types.

Annex F, which is an integral part of this Recommendation | International Standard, provides the ASN.1 modulewhich contains all the definitions associated with operational binding management operations.

Annex G, which is not an integral part of this Recommendation | International Standard, summarizes themathematical terminology associated with tree structures.

ISO/IEC 9594-2 : 1993(E)

vi ITU-T Rec. X.501 (1993 E)

Annex H, which is not an integral part of this Recommendation | International Standard, describes some criteria thatcan be considered in designing names.

Annex J, which is not an integral part of this Recommendation | International Standard, provides some examples ofvarious aspects of Schema.

Annex K, which is not an integral part of this Recommendation | International Standard, provides an overview of thesemantics associated with Basic Access Control permissions.

Annex L, which is not an integral part of this Recommendation | International Standard, provides an extendedexample of the use of Basic Access Control.

Annex M, which is not an integral part of this Recommendation | International Standard, describes some DSA–specific entry combinations.

Annex N, which is not an integral part of this Recommendation | International Standard, provides a framework forthe modelling of knowledge.

Annex P, which is not an integral part of this Recommendation | International Standard, lists alphabetically the termsdefined in this document.

Annex R, which is not an integral part of this Recommendation | International Standard, lists the amendments anddefect reports that have been incorporated to form this edition of this Recommendation | International Standard.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 1

INTERNATIONAL STANDARD

ITU-T RECOMMENDATION

Information technology — Open Systems Interconnection —The Directory — Part 2: Models

SECTION 1: GENERAL

1 ScopeThe models defined in this Recommendation | International Standard provide a conceptual and terminologicalframework for the other ITU-T X.500 series Recommendations | parts of ISO/IEC 9594 which define variousaspects of the Directory.

The functional and administrative authority models define ways in which the Directory can be distributed, bothfunctionally and administratively. Generic DSA and DSA information models and an Operational Framework arealso provided to support Directory distribution.

The generic Directory Information Models describe the logical structure of the DIB from the perspective ofDirectory and Administrative Users. In these models, the fact that the Directory is distributed, rather thancentralized, is not visible.

This Recommendation | International Standard provides a specialization of the generic Directory InformationModels to support Directory Schema administration.

The other ITU-T Recommendations in the X.500 series | parts of ISO/IEC 9594 make use of the concepts defined inthis Recommendation | International Standard to define specializations of the generic information and DSA modelsto provide specific information, DSA and operational models supporting particular directory capabilities (e.g.Replication):

a) the service provided by the Directory is described (in ITU-T Rec. X.511 | ISO/IEC 9594-3) in terms of theconcepts of the information framework: this allows the service provided to be somewhat independent of thephysical distribution of the DIB;

b) the distributed operation of the Directory is specified (in ITU-T Rec. X.518 | ISO/IEC 9594-4) so as toprovide that service, and therefore maintain that logical information structure, given that the DIB is in facthighly distributed;

c) replication capabilities offered by the component parts of the Directory to improve overall Directoryperformance are specified (in ITU-T Rec. X.525 | ISO/IEC 9594-9).

The security model establishes a framework for the specification of access control mechanisms. It provides amechanism for identifying the access control scheme in effect in a particular portion of the DIT, and it defines twoflexible, specific access control schemes which are suitable for a wide variety of applications and styles of use. Thesecurity model is concerned solely with control of access to the Directory information, not control of access to theDSA application -entity holding the information.

DSA models establish a framework for the specification of the operation of the components of the Directory.Specifically:

a) the Directory functional model describes how the Directory is manifested as a set of one or morecomponents, each being a DSA;

b) the Directory distribution model describes the principals according to which the DIB entries and entry-copies may be distributed among DSAs;

ISO/IEC 9594-2 : 1993(E)

2 ITU-T Rec. X.501 (1993 E)

c) the DSA information model describes the structure of the Directory user and operational information heldin a DSA;

d) the DSA operational framework describes the means by which the definition of specific forms ofcooperation between DSAs to achieve particular objectives (e.g. shadowing) is structured.

2 Normative referencesThe following Recommendations and International Standards contain provisions which, through reference in thistext, constitute provisions of this Recommendation | International Standard part. At the time of publication, theeditions indicated were valid. All Recommendations and Standards are subject to revision, and parties to agreementsbased on this Recommendation | International Standard are encouraged to investigate the possibility of applying themost recent editions of the Recommendations and Standards listed below. Members of IEC and ISO maintainregisters of currently valid International Standards. The Telecommunication Standardization Bureau of the ITUmaintains a list of currently valid ITU-T Recommendations.

2.1 Identical Recommendations | International Standards

— ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1993, Information technology — Open SystemsInterconnection — The Directory: Overview of Concepts, Models and Services.

— ITU-T Recommendation X.511 (1993) | ISO/IEC 9594-3:1993, Information technology — Open SystemsInterconnection — The Directory: Abstract Service Definition.

— ITU-T Recommendation X.518 (1993) | ISO/IEC 9594-4:1993, Information technology — Open SystemsInterconnection — The Directory: Procedures for Distributed Operation.

— ITU-T Recommendation X.519 (1993) | ISO/IEC 9594-5:1993, Information technology — Open SystemsInterconnection —The Directory: Protocol Specifications.

— ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1993, Information technology — Open SystemsInterconnection —The Directory: Selected Attribute Types.

— ITU-T Recommendation X.521 (1993) | ISO/IEC 9594-7:1993, Information technology — Open SystemsInterconnection —The Directory: Selected Object Classes.

— ITU-T Recommendation X.509 (1993) | ISO/IEC 9594-8:1993, Information technology — Open SystemsInterconnection — The Directory: Authentication Framework.

— ITU-T Recommendation X.525 (1993) | ISO/IEC 9594-9:1993, Information technology — The Directory:Replication.

— ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1994, Information technology — Open SystemsInterconnection — Abstract Syntax Notation One (ASN.1): Specification of basic notation.

— ITU-T Recommendation X.681 (1994) | ISO/IEC 8824-2:1994, Information technology — Open SystemsInterconnection — Abstract Syntax Notation One (ASN.1): Information object specification.

— ITU-T Recommendation X.682 (1994) | ISO/IEC 8824-3:1994, Information technology — Open SystemsInterconnection — Abstract Syntax Notation One (ASN.1): Constraint specification.

— ITU-T Recommendation X.683 (1994) | ISO/IEC 8824-4:1994, Information technology — Open SystemsInterconnection — Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications.

— ITU-T Recommendation X.811 (1994) | ISO/IEC 10181-1: 1993, Information Processing Systems — OpenSystems Interconnection — Security Frameworks in Open Systems — Part 1: Overview.

— ITU-T Recommendation X.812 (1994) | ISO/IEC 10181-2: 1993, Information Processing Systems — OpenSystems Interconnection — Security Frameworks in Open Systems — Part 2: Authentication .

— ITU-T Recommendation X.813 (1994) | ISO/IEC 10181-3: 1993, Information Processing Systems — OpenSystems Interconnection — Security Frameworks in Open Systems — Part 3: Access Control .

2.2 Paired Recommendations | International Standards equivalent in technical content

— CCITT Recommendation X.200 (1988) Reference Model of Open Systems Interconnection for CCITTApplications .

ISO 7498:1984, Information Processing Systems — Open Systems Interconnection — Basic ReferenceModel .

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 3

— CCITT Recommendation X.800 (1991), Security Architecture for Open Systems Interconnection for CCITTApplications.

— ISO 7498-2:1987, Information Processing Systems — Open Systems Interconnection — Basic ReferenceModel — Part 2: Security Architecture .

3 DefinitionsFor the purposes of this ITU-T Recommendation | International Standard, the following definitions apply.

3.1 OSI Reference Model Definitions

The following terms are defined in CCITT Rec. X.200 | ISO 7498:

a) application-context .

b) application-entity;

c) application-process;

3.2 Basic directory definitions

The following terms are defined in ITU-T Rec. X.500 | ISO/IEC 9594-1 :

a) Directory ;

b) Directory Access Protocol;

c) Directory Information Base;

d) Directory Operational Binding Protocol ;

e) Directory System Protocol ;

f) (Directory) user.

3.3 Distributed operation definitions


a) access point;

b) hierarchical operational binding ;

c) name resolution ;

d) non-specific hierarchical operational binding;

e) relevant hierarchical operational binding .

3.4 Replication definitions


a) cache-copy ;

b) consumer reference;

c) entry-copy ;

d) master DSA;

e) primary shadowing;

f) replicated area;

g) replication ;

h) secondary shadowing ;

i) shadow consumer ;

j) shadow supplier ;

k) Shadowed DSA-Specific Entry ;

l) shadowing;

ISO/IEC 9594-2 : 1993(E)

4 ITU-T Rec. X.501 (1993 E)

m) supplier reference.

The definitions of terms defined in this Recommendation | International Standard are included at the beginning ofindividual clauses, as appropriate. An index of these terms is provided in Annex P for easy reference.

4 AbbreviationsACDF Access Control Decision Function

ACI Access Control Information

ACIA Access Control Inner Area

ACSA Access Control Specific Area

ADDMD Administration Directory Management Domain

ASN.1 Abstract Syntax Notation 1

AVA attribute value assertion

BER (ASN.1) Basic Encoding Rules

DACD Directory Access Control Domain

DAP Directory Access Protocol

DIB Directory Information Base

DISP Directory Information Shadow Protocol

DIT Directory Information Tree

DMD Directory Management Domain

DMO Domain Management Organization

DOP Directory Operational Binding Management Protocol

DSA Directory System Agent

DSE DSA-Specific Entry

DSP Directory System Protocol

DUA Directory User Agent

HOB Hierarchical Operational Binding

NHOB Non-specific Hierarchical Operational Binding

NSSR Non-Specific Subordinate Reference

PRDMD Private Directory Management Domain

RHOB Relevant Hierarchical Operational Binding (i.e. either a HOB or NHOB, as appropriate)

RDN Relative Distinguished Name

SDSE Shadowed DSE

5 ConventionsWith minor exceptions this Directory Specification has been prepared according to the “Presentation of ITU-TS/ISO/IEC common text” guidelines in the Guide for ITU-TS and ISO/IEC JTC 1 Cooperation, March 1993.

The term “Directory Specification” (as in “this Directory Specification”) shall be taken to mean ITU-T Rec. X.501 |ISO/IEC 9594-2. The term “Directory Specifications” shall be taken to mean the X.500 series of Recommendationsand all parts of ISO/IEC 9594.

This Directory Specification uses the term “1988 edition systems” to refer to systems conforming to the previous(1988) edition of the Directory Specifications, i.e., the 1988 edition of the series of ITU-T X.500 Recommendationsand the ISO/IEC 9594:1990 edition. Systems conforming to the current Directory Specifications are referred to as“1993 edition systems”.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 5

SECTION 2: OVERVIEW OF THE DIRECTORY MODELS

6 Directory Models6.1 Definitions

For the purposes of this Directory Specification, the following definitions apply.

— Administrative Authority : an agent of the Domain Management Organization concerned with variousaspects of Directory administration. The term administrative authority (in lower case) refers to the powervested in an Administrative Authority by the Domain Management Organization to execute policy.

— Administration Directory Management Domain (ADDMD): A DMD which is managed by anAdministration.

Note — The term Administration denotes a public telecommunications administration or other organization offeringpublic telecommunications services.

— Directory administrative and operational information : information used by the Directory for administrativeand operational purposes.

— DIT Domain: That part of the global DIT held by the DSAs forming a DMD.

— Directory Management Domain (DMD): A set of one or more DSAs and zero or more DUAs managed by asingle organization.

— Domain Management Organization : an organization that manages a DMD (and the associated DITDomain).

— Directory user information: information of interest to users and their applications.

— Directory System Agent (DSA): An OSI application process which is part of the Directory.

— (Directory) user: The end user of the Directory, i.e., the entity or person which accesses the Directory.

— Directory User Agent (DUA): An OSI application process which represents a user in accessing theDirectory.

Note — DUAs may also provide a range of local facilities to assist users compose queries and interpret theresponses.

— Private Directory Management Domain (PRDMD): A DMD which is managed by an organization otherthan an Administration.

6.2 The Directory and its Users

The Directory is a repository of information. This repository is known as the Directory Information Base (DIB).Directory services provided to users are concerned with various kinds of access to this information.

The services provided by the Directory are defined in ITU-T Rec. X.511 | ISO/IEC 9594-3.

A Directory user (e.g., a person or an application-process) obtains Directory services by accessing the Directory.More precisely, a Directory User Agent (DUA) actually accesses the Directory and interacts with it to obtain theservice on behalf of a particular user. The Directory provides one or more access points at which such accesses cantake place. These concepts are illustrated in Figure 1.

A DUA is manifested as an application-process. In any instance of communication each DUA represents preciselyone directory user.

The Directory is manifested as a set of one or more application-processes known as Directory System Agents(DSAs) , each of which provides one or more of the access points. For a more detailed description of DSAs see 17.2.

Notes

1 Some open systems may provide a centralized DUA function retrieving information for the actual users (application-processes, persons, etc.). This is transparent to the Directory.

2 The DUA functions and a DSA can be within the same open system, and it is an implementation choice whether to makeone or more DUAs visible within the OSI Environment as application-entities.

ISO/IEC 9594-2 : 1993(E)

6 ITU-T Rec. X.501 (1993 E)

3 A DUA may exhibit local behavior and structure which is outside the scope of envisaged Directory Specifications Forexample, a DUA which represents a human directory user may provide a range of local facilities to assist its user to composequeries and interpret the responses.

DUADirectoryuser

TheDirectory

Access Point

Figure 1 — Access to the Directory

6.3 Directory and DSA Information Models

6.3.1 Generic Models

Directory information may be classified as either:

- user information, placed in the Directory by, or on behalf of, users; and subsequently administered by, or onbehalf of, users. Section 3 provides a model of this information, or;

- administrative and operational information, held by the Directory to meet various administrative andoperational requirements. Section 5 provides a model of this information. Also provided in Section 5 is aspecification of the relationship between the user, administrative and operational information models.

These models, presenting views of the DIB from different perspectives, are referred to as the generic DirectoryInformation Models.

Directory information models describe how the Directory as a whole represents information. The composition of theDirectory as a set of potentially cooperating DSAs is abstracted from the model. The DSA information model, on theother hand, is especially concerned with DSAs and the information that must be held by DSAs in order that the setof DSAs comprising the Directory may together realize the Directory information model. The DSA InformationModel is provided in clauses 18 through 20.

The DSA information model is a generic model describing the information held by DSAs and the relationshipbetween this information and the DIB and DIT.

Some, but not all, of the information represented by the DSA information model is accessible via the Directoryabstract service. Therefore, administration of all of the information described in these Directory Specifications is notpossible via the Directory abstract service. It is envisioned that administration of DSA information will initially be alocal matter, but that eventually some generic system management service will be employed to provide access to allof the information described in the DSA information model.

6.3.2 Specific Information Models

Subsequent to the development of generic models for the Directory as a whole and for its components, specificinformation models are required for the standardisation of particular aspects of the operation of the Directory and itscomponents.

The generic Directory Information Models establish a framework for the following specific information models:

— an access control information model;

— a subschema information model;

— a collective attribute information model.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 7

The generic DSA Information Model in turn establishes a framework for the following specific information models:

— a model for a DSA’s distribution knowledge;

— a model for a DSA’s replication knowledge.

6.4 Directory Administrative Authority Model

A Directory Management Domain (DMD) is a set of one or more DSAs and zero or more DUAs managed by asingle organization.

That part of the global DIT held by (the DSAs forming) a DMD is referred to as a DIT Domain . There is a one toone correspondence between DMDs and DIT Domains. The term DMD is used when referring to the management ofthe functional components of the Directory. The term DIT Domain is used when referring to the management ofDirectory Information. Two important points regarding this terminology are:

— A DIT Domain consists of one or more disjoint subtrees of the DIT (see 10.5). A DIT Domain shall notcontain the root of the global DIT.

— The term DMD may also be used as a general term when both aspects of management are consideredtogether.

An organization that manages a DMD (and the associated DIT Domain) is referred to as a Domain ManagementOrganization (DMO).

Note — A DMO may be an Administration (i.e., a public telecommunications administration or other organization offeringpublic telecommunications services) in which case the managed DMD is said to be an Administration DMD (ADDMD);otherwise it is a Private DMD (PRDMD). It should be recognized that the provision of support for private directory systemsby ITU-TS members falls within the framework of national regulations. Thus, the technical possibilities described may ormay not be offered by an Administration which provides directory services. The internal operation and configuration ofprivate DMDs is not within the scope of envisaged Directory Specifications.

Figure 2 illustrates the relationship between a DMO, DMD and DIT Domain.

DIT Domain

DUA

DUA

DSA

DSA

DSA

DMD

Domain Management Organization

Manages Manages

Figure 2 — Directory Management.

Management of a DUA by a DMO implies an ongoing responsibility for service to that DUA, e.g., maintenance, orin some cases ownership, by the DMO. The DMO may or may not elect to make use of the Directory Specificationsto govern any interactions among DUAs and DSAs which are wholly within the DMD.

An agent of a DMO concerned with various aspects of Directory administration is referred to as an AdministrativeAuthority . The term administrative authority (in lower case) refers to the power vested in an AdministrativeAuthority by a DMO to execute policy.

Note — A Directory Administrative Authority Model is specified in Section 4.

ISO/IEC 9594-2 : 1993(E)

8 ITU-T Rec. X.501 (1993 E)

SECTION 3: MODEL OF DIRECTORY USER INFORMATION

7 Directory Information Base7.1 Definitions


— alias entry : an entry of the class “alias” containing information used to provide an alternative name for anobject or alias entry.

— direct superclass: relative to a subclass – an object class from which the subclass is directly derived.

— Directory Information Base (DIB) : the complete set of information to which the Directory provides access,and which includes all of the pieces of information which can be read or manipulated using the operationsof the Directory.

— Directory Information Tree (DIT) : the DIB considered as a tree, whose vertices (other than the root) are theDirectory entries.

Note - The term DIT is used instead of DIB only in contexts where the tree structure of the information is relevant.

— (Directory) entry : a named collection of information within the DIB. The DIB is composed of entries;

— immediate superior (noun): relative to a particular entry or object (it shall be clear from the context whichis intended), the immediately superior entry or object.

— immediately superior

(entry ): relative to a particular entry - an entry which is at the initial vertex of an arc in the DIT whose finalvertex is that of the particular entry;

(object): relative to a particular object - an object whose object entry is the immediate superior of any of theentries (object or alias) for the second object.

— object (of interest): anything in some ‘world’, generally the world of telecommunications and informationprocessing or some part thereof, which is identifiable (can be named), and which it is of interest to holdinformation on in the DIB.

— object class: an identified family of objects (or conceivable objects) which share certain characteristics.

— object entry : an entry which is the primary collection of information in the DIB about an object, and whichcan therefore be said to represent that object in the DIB.

— subclass: relative to one or more superclasses – an object class derived from one or more superclasses. Themembers of the subclass share all the characteristics of the super classes and additional characteristicspossessed by none of the members of those superclasses.

— subordinate : the converse of superior.

— superclass: relative to a subclass – a direct superclass, or superclass to an object class that is a directsuperclass (recursively).

— superior: (applying to entry or object) immediately superior, or superior to one which is immediatelysuperior (recursively).

7.2 Objects

The purpose of the Directory is to hold, and provide access to, information about objects of interest (objects) whichexist in some ‘world’. An object can be anything in that world which is identifiable (can be named).

Notes

1 The ‘world’ is generally that of telecommunications and information processing or some part thereof.

2 The objects known to the Directory may not correspond exactly with the set of ‘real’ things in the world. For example, areal-world person may be regarded as two different objects, a business person and a residential person, as far as theDirectory is concerned. The mapping is not defined in this Directory Specification, but is a matter for the users and providersof the Directory in the context of their applications.

An object class is an identified family of objects, or conceivable objects, which share certain characteristics. Everyobject belongs to at least one class. An object class may be a subclass of other object classes, in which case the

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 9

members of the former class, the subclass, are also considered to be members of the latter classes, the superclasses.There may be subclasses of subclasses, etc., to an arbitrary depth.

7.3 Directory Entries

The DIB is composed of (Directory) entries . An entry is a named collection of information.

There are three kinds of entries:

- object entries : representing the primary collection of information in the DIB about a particular object. Forany particular object there is precisely one object entry. The object entry is said to represent the object;

- alias entries: used to provide alternative names for object entries;

- subentries: representing a collection of information in the DIB used to meet administrative and operationalrequirements of the Directory. Subentries are discussed in Section 5.

A user view of the structure of directory entries is depicted in Figure 3 and described in Section 8.2.

Each entry contains an indication of the object classes, and their superclasses, to which the entry belongs.

Some object entries are specially designated for the purpose of Directory administration. These entries are termedadministrative entries. The Directory user is not normally aware of this, and views these entries in the same way asother object entries.

7.4 The Directory Information Tree (DIT)

In order to satisfy requirements for the distribution and management of a very large DIB, and to ensure that entriescan be unambiguously named and rapidly found, a flat structure is not likely to be feasible. Accordingly, thehierarchical relationship commonly found among objects (e.g., a person works for a department, which belongs to anorganization, which is headquartered in a country) can be exploited, by the arrangement of the entries into a tree,known as the Directory Information Tree (DIT).

Note — An introduction to the concepts and terminology of tree structures can be found in Annex G.

The component parts of the DIT have the following interpretations:

a) the vertices are the entries. Object entries may be either leaf or non-leaf vertices, whereas alias entries arealways leaf vertices. The root is not an entry as such, but can, where convenient to do so (e.g., in thedefinitions of (b) and (c) below), be viewed as a null object entry (see (d) below);

b) the arcs define the relationship between vertices (and hence entries). An arc from vertex A to vertex Bmeans that the entry at A is the immediately superior entry (immediate superior) of the entry at B, andconversely, that the entry at B is an immediately subordinate entry (immediate subordinate) of the entry atA. The superior entries (superiors) of a particular entry are its immediate superior together with itssuperiors (recursively). The subordinate entries (subordinates) of a particular entry are its immediatesubordinates together with their subordinates (recursively);

c) the object represented by an entry is, or is closely associated with, the naming authority (see clause 8) forits subordinates;

d) the root represents the highest level of naming authority for the DIB.

A superior/subordinate relationship between objects can be derived from that between object entries. An object is animmediately superior object (immediate superior) of another object if and only if the object entry for the first objectis the immediate superior of any of the object entries for the second object. The terms immediately subordinateobject, immediate subordinate , superior and subordinate (applied to objects) have their analogous meanings.

Permitted superior/subordinate relationships among objects are governed by the DIT structure definitions (see 12.3).

The Directory maintains, in addition to information concerning Directory entries, additional information regardingcollections of Directory entries. Such collections may be subtrees (of the DIT) or subtree refinements (when not atrue tree structure). See Clause 11.

ISO/IEC 9594-2 : 1993(E)

10 ITU-T Rec. X.501 (1993 E)

8 Directory Entries8.1 Definitions


— attribute: information of a particular type. Entries are composed of attributes.

— user attribute: an attribute representing user information.

— attribute hierarchy : the aspect of an attribute that permits a user attribute type to be derived from a moregeneric user attribute type. The relationship of the two attribute type definitions (which mandates certainbehaviour of attributes corresponding to these attribute types) is thus hierarchical.

— attribute subtype (subtype): an attribute type A is related to another attribute type B by the fact that either Ahas been derived from B, in which case A is a direct subtype of B, or A has been derived from an attributetype which is a subtype of B, in which case A is an indirect subtype of B.

— attribute supertype (supertype): an attribute type B is related to another attribute type A by the fact thateither A has been derived from B, in which case B is a direct supertype of A, or A has been derived from anattribute type which is a subtype of B, in which case B is an indirect supertype of A.

— attribute type : that component of an attribute which indicates the class of information given by thatattribute.

— attribute value : a particular instance of the class of information indicated by an attribute type.

— attribute value assertion : a proposition, which may be true, false, or undefined, according to the specifiedmatching rules for the type, concerning the presence in an entry of an attribute value of a particular type.

— auxiliary object class: an object class which is descriptive of entries or classes of entries and is not used forthe structural specification of the DIT.

— collective attribute: a user attribute whose values are the same for each member of an entry collection.

— direct attribute reference : reference (in the Directory and DSA abstract service) to one or more attributevalues using the identifier of their attribute type.

— distinguished value: an attribute value in an entry which has been designated to appear in the relativedistinguished name of the entry.

— entry collection: a collection of entries belonging to an explicitly specified subtree or subtree refinement ofthe DIT.

— indirect attribute reference: reference (in the Directory and DSA abstract service) to one or more attributevalues using the identifier of a supertype of their attribute type.

— matching rule: a rule, forming part of the Directory Schema, which allows entries to be selected by makinga particular statement (a matching rule assertion) concerning their attribute values;

— matching rule assertion: a proposition, which may be true, false or undefined, concerning the presence inan entry of attribute values meeting the criteria defined by the matching rule.

— operational attribute: an attribute representing operational and/or administrative information.

— structural object class : an object class used for the structural specification of the DIT.

— Structural Object Class of an entry: With respect to a particular entry, the single structural object class usedto determine the DIT Content Rule and DIT Structure Rule applying to the entry. This object class isindicated by the structuralObjectClass operational attribute. This object class is the most subordinateobject class of the entry’s structural object class superclass chain.

8.2 Overall Structure

As depicted in Figure 3, an entry consists of a set of attributes .

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 11

Attribute Attribute Attribute

ENTRY

Attribute Type

AttributeValue(s)

ATTRIBUTE

DistinguishedAttributeValue

AttributeValue

AttributeValue

ATTRIBUTE VALUE(S)

• • •

• • •

Figure 3 — Structure of an Entry

Each attribute provides a piece of information about, or describes a particular characteristic of, the object to whichthe entry corresponds.

Note — Examples of attributes which might be present in an entry include naming information such as the object’s personalname, and addressing information, such as its telephone number.

An attribute consists of an attribute type , which identifies the class of information given by an attribute, and thecorresponding attribute values, which are the particular instances of that class appearing in the entry.

Attribute ::= SEQUENCE {type AttributeType ( { SupportedAttributes } ),values SET SIZE (1 .. MAX) OF AttributeValue ( { SupportedAttributes}{@type})}

Note — Attribute types and attribute values are described in clauses 8.4. and 8.5 respectively.

An attribute may be designated as single valued or multi-valued. The Directory shall ensure that single valuedattributes have only one value.

8.3 Object Classes

Object classes are used in the Directory for a number of purposes:

— describing and categorising objects and the entries that correspond to these objects;

— where appropriate, controlling the operation of the Directory;

— regulating, in conjunction with DIT structure rule specifications, the position of entries in the DIT;

— regulating, in conjunction with DIT content rule specifications, the attributes that are contained in entries;

— identifying classes of entry that are to be associated with a particular policy by the appropriateadministrative authority.

Some object classes will be internationally standardized. Others will be defined by national administrativeauthorities and/or private organizations. This implies that a number of separate authorities will be responsible fordefining object classes and unambiguously identifying them. This is accomplished by identifying each object classwith an object identifier when the object class is defined. A notation for this purpose is provided in 12.3.3.

Note — An administrative authority may use object classes other than the useful object classes defined and registered in theDirectory Specifications. An administrative authority may itself specify and register object classes, for example tosupplement those defined in the Directory Specifications

ISO/IEC 9594-2 : 1993(E)

12 ITU-T Rec. X.501 (1993 E)

An object class (a subclass) may be derived from an object class (its direct superclass) which is itself derived froman even more generic object class. For structural object classes, this process stops at the most generic object class,top . An ordered set of superclasses up to the most superior object class of an object class is its superclass chain.

An object class may be derived from two or more direct superclasses (superclasses not part of the same superclasschain). This feature of subclassing is termed multiple inheritance.

The specification of an object class identifies whether an attribute is mandatory or optional; this specification alsoapplies to its subclasses. The subclass may be said to inherit the mandatory and optional attribute specification of itssuperclass. The specification of a subclass may indicate that an optional attribute of the superclass is mandatory inthe subclass.

There are three kinds of object class:

— Abstract Object Classes;

— Structural Object Classes; and

— Auxiliary Object Classes.

Each object class is of precisely one of these kinds, and remains of this kind in whatever situation it is encounteredwithin the Directory. The definition of each object class must specify what kind of object that it is.

All entries shall be a member of the object class top and at least one other object class.

8.3.1 Abstract Object Classes

An abstract object class is used to derive other object classes, providing the common characteristics of such objectclasses. An entry shall not belong only to abstract object classes.

top is an abstract object class used as a superclass of all structural object classes.

8.3.2 Structural Object Classes

An object class defined for use in the structural specification of the DIT is termed a structural object class.Structural object classes are used in the definition of the structure of the names of the objects for compliant entries.

An object or alias entry is characterised by precisely one structural object class superclass chain which has a singlestructural object class as the most subordinate object class. This structural object class is referred to as the structuralobject class of the entry .

Structural object classes are related to associated entries:

— an entry conforming to a structural object class shall represent the real-world object constrained by theobject class;

— DIT structure rules only refer to structural object classes; the structural object class of an entry is used tospecify the position of the entry in the DIT;

— the structural object class of an entry is used, along with an associated DIT content rule, to control thecontent of an entry.

The structural object class of an entry shall not be changed.

8.3.3 Auxiliary Object Classes

Specific applications using the Directory will frequently find it useful to specify an auxiliary object class which maybe used in the construction of entries of several types. For example, message handling systems make use of theauxiliary class MHS User (CCITT Rec. X.402 | ISO/IEC 10021-2) to specify a package of mandatory and optionalmessage handling attributes for entry types whose structural object class is variable, e.g. Organizational Person orResidential Person.

In certain environments, there is a need to be able to add to or remove from the list of attributes permitted in an entryof a particular, perhaps standardized, class (or classes).

This requirement may be met by the definition and use of an auxiliary object class having semantics, known andmaintained within a local community, which change from time to time as needed.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 13

This requirement may also be met using the facilities of DIT content rule definitions to dynamically (i.e. withoutregistration) allow the addition or exclusion of attributes from entries at particular points in the DIT (see 12.3.3).

Auxiliary object classes are descriptive of entries or classes of entries.

Therefore, besides being a member of the structural object class, an entry may be optionally a member of one ormore auxiliary object classes.

An entry’s auxiliary object classes may change over time.

Note — The unregistered object class facility, available in the 1988 edition of these Directory Specifications to support therequirements discussed in this clause, is now deprecated in favour of the use of DIT content rules.

8.3.4 Object Class Definition and the 1988 Edition of this Directory Specification

Object classes defined using the terminology of the 1988 edition of this Directory Specification will not be classifiedas one of structural, auxiliary or abstract.

Alias object classes specified using the terminology of the 1988 edition of this Directory Specification may beconsidered to be specified as either abstract, auxiliary or structural object classes and deployed in a subschemaaccordingly.

8.4 Attribute Types

Some attribute types will be internationally standardized. Other attribute types will be defined by nationaladministrative authorities and private organizations. This implies that a number of separate authorities will beresponsible for defining types and unambiguously identifying them. This is accomplished by identifying eachattribute type with an object identifier when the type is defined. Using the notation of the ATTRIBUTE informationobject class defined in 12.4.6, an attribute type is defined as:

AttributeType ::= ATTRIBUTE.&id

All attributes in an entry shall be of distinct attribute types.

There are a number of attribute types which the Directory knows about and uses for its own purposes. They include:

a) objectClass — An attribute of this type appears in every entry, and indicates the object classes andsuperclasses to which the object belongs.

b) aliasedEntryName — An attribute of this type appears in every alias entry, and holds the name (see 8.5) ofof the entry which the alias entry references.

These attributes are defined in 12.4.6.

The types of user attributes which shall or which may appear within an object or alias entry are governed by rulesapplying to the indicated object classes as well as by the DIT content rule for that entry (see 12.7). The types ofattributes which may appear in a subentry are governed by the rules of the system schema.

Some Directory entries may contain special attributes not normally visible to the Directory User. These attributes arecalled operational attributes and are used to meet the administrative and operational requirements of the Directory.Operational attributes are discussed in more detail in Section 5.

8.5 Attribute Values

Defining an attribute also involves specifying the syntax, and hence data type, to which every value in suchattributes shall conform. Using the notation of the ATTRIBUTE information object class defined in clause 12.4.6, anattribute value is defined as:

AttributeValue ::= ATTRIBUTE.&Type

At most one of the values of an attribute may be designated as a distinguished value, in which case the attributevalue appears in the relative distinguished name (see 9.3) of the entry.

ISO/IEC 9594-2 : 1993(E)

14 ITU-T Rec. X.501 (1993 E)

8.6 Attribute Type Hierarchies

When defining an attribute type, the characteristics of some more generic attribute type may optionally be employedas the basis of the definition. The new attribute type is a direct subtype of the more generic attribute type, thesupertype , from which it is derived.

Attribute hierarchies allow access to the DIB with varying degrees of granularity. This is achieved by allowing thevalue components of attributes to be accessed by using either their specific attribute type identifier (a directreference to the attribute) or by the identifier of a more generic attribute type identifier (an indirect reference).

Semantically related attributes may be placed in a hierarchical relationship, the more specialized being placedsubordinate to the more generalized. Searching for, or retrieving attributes and their values is made easier by quotingthe more generalized attribute type; a filter item so specified is evaluated for the more specialized types as well asfor the quoted type.

Where subordinate specialized types are selected to be returned as part of a search result these types shall bereturned if available. Where the more general types are selected to be returned as part of a search result both thegeneral and the specialized types shall be returned, if available. An attribute value shall always be returned as avalue of its own attribute type.

For an entry to contain a value of an attribute type belonging to an attribute hierarchy, that type must be explicitlyincluded either in the definition of an object class to which the entry belongs, or because the DIT content ruleapplicable to that entry permits it.

All of the attribute types in an attribute hierarchy are treated as distinct and unrelated types for the purpose ofadministration of the entry and for user modification of entry content.

An attribute value stored in a Directory object or alias entry is of precisely one attribute type. The type is indicatedwhen the value is originally added to the entry.

8.7 Matching Rules

8.7.1 Overview

Of paramount importance to the Directory is the ability to be able to select a set of entries from the DIB based onassertions concerning attribute values held by these entries.

A matching rule allows entries to be selected by making a particular assertion concerning their attribute values.

The most primitive type of assertion is the attribute value assertion. More complex assertions may be supportedusing matching rule assertions. A matching rule assertion is a proposition, which may be true, false or undefined,concerning the presence in an entry of attribute values meeting the criteria defined by the matching rule.

An attribute value or matching rule assertion is evaluated based on the matching rule associated with the assertion.

A matching rule is defined through the specification of:

— the range of attribute syntaxes supported by the rule;

— the specific types of matches supported by the rule;

— the syntax required to express an assertion of each specific type of match;

— rules for deriving a value of the assertion syntax from a value of the attribute syntax, if required.

Note — No restrictions are placed on the matching rules that may be defined to support a particular application. However,rules defined to support one particular application may not be widely supported by DUAs and DSAs. Wherever possible thematching rules defined in ITU-T Rec. X.520 | ISO/IEC 9594-6 should be used in preference to the specification of new ones.

Sometimes there will be a one to one correspondence between a matching rule and the types of matches supported.For example, the Directory Abstract Service supports a presence matching rule to detect the presence of an attributein an entry.

Sometimes there will be a many to many correspondence between a rule and the types of matches supported. Forexample, the Directory Abstract Service supports a generic ordering rule allowing greater than or equal and less thanor equal types of matches.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 15

8.7.2 Attribute Value Assertions

An attribute value assertion (AVA) is a proposition, which may be true, false, or undefined, according to thespecified matching rules for the type, concerning the presence in an entry of an attribute value of a particular type. Itinvolves an attribute type and an attribute value:

AttributeValueAssertion := SEQUENCE {type AttributeType (SupportedAttributes),assertion AssertionValue (SupportedAttributes{@type})}

AssertionValue ::= ATTRIBUTE.&equality-match.&AssertionType

The syntax of the assertion component of an AVA is determined by the equality matching rule defined for theattribute type, and may be different from the syntax of the attribute itself.

An AVA is:

a) undefined, if any of the following hold:

1) the attribute type is unknown,

2) the attribute type has no equality matching rule,

3) the value does not conform to the data type indicated by the syntax of the assertion of the attribute’sequality matching rule;

Note — 2) and 3) normally indicate a faulty AVA; 1) however, may occur as a local situation (e.g., a particular DSAhas not been configured with support for that particular attribute type).

b) true, if the entry contains an attribute of that type, one of whose values matches that value;

c) false, otherwise.

8.7.3 Built-in Matching Rule Assertions

A number of categories of related matching rules, whose semantics are generally understood and applicable tovalues of many different types of attributes, are understood by the Directory:

— Present;

— Equality;

— Substrings;

— Ordering;

— Approximate match.

Syntax for asserting certain types of matches associated with these categories of matching rules has been built intothe Directory Abstract Service:

— a present syntax for the present rule;

— an equality syntax for equality rules;

— greaterOrEqual and lessOrEqual syntaxes for ordering rules;

— initial, any and final syntaxes for substrings rules;

— an approximateMatch syntax for approximate matching rules.

The present syntax may be used for any attribute of any type. The present match tests for the presence of any valueof a particular type.

Specific equality, substrings and ordering matching rules may be associated with an attribute type when it is defined.These specific rules are used when evaluating assertions of the equality, ordering and substrings rules made usingthe syntax built-in to the Directory Abstract Service. If specific rules are not provided, then assertions madeconcerning these attributes are undefined.

The approximateMatch syntax supports an approximate matching rule whose definition is a local matter to a DSA.

ISO/IEC 9594-2 : 1993(E)

16 ITU-T Rec. X.501 (1993 E)

8.7.4 Matching Rule Requirements

In order for the Directory to behave in a consistent and well defined manner, it is necessary that certain restrictionsbe placed upon the matching rules that shall be used in conjunction with the syntax that has been built into theDirectory Abstract Service.

For an equality matching rule in which the syntax of the assertion is different from the attribute syntax to which thematching rule applies, rules for deriving a value of the syntax of the assertion from a value of the attribute syntaxshall be supplied.

Equality matching rules for attributes used for naming shall be transitive, commutative and have an assertion syntaxidentical to the attribute syntax.

A transitive matching rule is characterized by the fact that if a value a matches a value b; and if that value b matchesa third value c; then value a must necessarily match value c using the rule.

A commutative matching rule is characterized by the fact that if a value a matches a value b then that value b mustnecessarily match the value a. The attribute presentationAddress is an example of an attribute supporting anattribute syntax whose matching rule is not commutative.

With respect to a specific attribute type, the equality and ordering rules (if both present) must always be related in atleast the following respect: two values are equal using the equality relation if and only if they are equal using theordering relation. In addition, the ordering relation must be well-ordered; that is, for all x, y and z for which xprecedes y and y precedes z according to the relation, then x must precede z.

Note — These requirements imply that when ordering is defined, it also defines equality.

With respect to a specific attribute type, the equality and substrings rule (if both present) must always be related in atleast the following respect: for all x and y that match according to the equality relation, then for all values z of thesubstring relation, the result of evaluating the assertion against the value x must equal the result of evaluating theassertion against the value y. That is, two values that are indistinguishable using the equality relation must also beindistinguishable using the substrings relation.

8.7.5 Object Identifier and Distinguished Name equality matching rules

There are a number of equality matching rules used to evaluate attribute value assertions which the Directory knowsabout and uses for its own purposes. They include:

— objectIdentifierMatch. This rule is used to match attributes with ObjectIdentifier syntax.

— distinguishedNameMatch . This rule is used to match attributes with DistinguishedName syntax.

8.8 Entry Collections

8.8.1 Overview

A collection of object and alias entries may have certain common characteristics (e.g. certain attributes that have thesame value for each entry of the collection) because of some common characteristic or shared relationship of thecorresponding objects. Such a grouping of entries is termed an entry collection.

Entry collections may contain object and alias entries that are related by their position in the DIT. These collectionsare specified as subtrees or subtree refinements as described in Section 5.

An entry may belong to several entry collections subject to administrative limitations imposed in Section 5.

8.8.2 Collective Attributes

When user attributes are shared by the entries of an entry collection, they are termed collective attributes

It is also permissible that the same collective attribute be independently associated with two or more of thesecollections. In such cases the entry’s collective attribute has multiple values. Collective attributes shall, therefore,always be specified as multi-valued.

Although they appear to users of the Directory interrogation operations as entry attributes, collective attributes aretreated differently from entry attributes in the Directory information model. This difference is manifested to users of

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 17

the Directory modification operations in that collective attributes cannot be administered (i.e. modified) via theentries in which they appear but must be administered via the their associated subentries.

Note — The independent sources of these values is not manifested to the users of the Directory interrogation operations.

For a collective attribute to appear in an entry, the presence of that attribute type must be permitted according to theDIT content rule governing the entry.

Entries may specifically exclude a particular collective attribute. This is achieved through the use of thecollectiveExclusions attribute, described in 11.7 and defined in 13.6.

9 Names9.1 Definitions

For the purposes of this Directory Specification, the following definitions apply:

— alias, alias name: an alternative name for an object, provided by the use of alias entries;

— (alias) dereferencing: the process of converting an object’s alias name to its distinguished name;

— distinguished name (of an entry): the name of an entry which is formed from the sequence of the RDNs ofthe entry and each of its superior entries. Every object entry, alias entry and subentry has precisely onedistinguished name;

— (directory) name : a construct that singles out a particular object from all other objects. A name shall beunambiguous (that is, denote just one object), however it need not be unique (that is, be the only namewhich unambiguously denotes the object);

— (entry) name: a construct that singles out a particular entry from all other entries;

— purported name: a construct which is syntactically a name, but which has not (yet) been shown to be a validname;

— naming authority: an authority responsible for the allocation of names in some region of the DIT.

— relative distinguished name (RDN): a set of one or more attribute type and value pairs, each of whichmatches a distinct distinguished attribute value of the entry.

9.2 Names in General

A (directory) name is a construct that identifies a particular object from among the set of all objects. A name shall beunambiguous, that is, denotes just one object. However, a name need not be unique, that is, be the only name thatunambiguously denotes the object. A (directory) name also identifies an entry. This entry is either an object entrythat represents the object or an alias entry which contains information that helps the Directory to locate the entry thatrepresents the object.

Note –The set of names of an object thus comprises the set of alias names for the object, together with the distinguishedname of the object.

An object can be assigned a distinguished name without being represented by an entry in the Directory, but thisname is then the name its object entry would have had were it represented in the Directory.

Syntactically, each name for an object or entry is an ordered sequence of relative distinguished names (see 9.3).

Name ::= CHOICE { - - only one possibility for now - - rdnSequence RDNSequence }

RDNSequence ::= SEQUENCE OFRelativeDistinguishedName

DistinguishedName ::= RDNSequence

Note — Names which are formed in other ways than as described herein are a possible future extension.

Each initial subsequence of the name of an object is also the name of an object. The sequence of objects soidentified, starting with the root and ending with the object being named, is such that each is the immediate superiorof that which follows it in the sequence.

ISO/IEC 9594-2 : 1993(E)

18 ITU-T Rec. X.501 (1993 E)

A purported name is a construct which is syntactically a name, but which has not (yet) been shown to be a validname.

9.3 Relative Distinguished Names

Each object and entry has a relative distinguished name (RDN). An RDN of an object or alias entry consists of a setof attribute type and value pairs, each of which matches, using the equality matching rule, a distinct distinguishedattribute value of the entry.

Note — The equality matching rule can be used because for naming attributes, the attribute syntax and the assertion syntaxof the equality matching rule are the same.

RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCEtype ({AttributeType}),value ({AttributeValue ({SupportedAttributes}{@type})}

The set contains exactly one attribute type and value pair for each distinguished value in the entry; no two attributetype and value pairs can thus refer to the same attribute.

The RDNs of all of the entries with a particular immediate superior are distinct. It is the responsibility of the relevantnaming authority for an entry to ensure that this is so by appropriately assigning distinguished attribute values.

Note — Frequently, an entry will contain a single distinguished value (and the RDN will thus comprise a single type andvalue pair); however, under certain circumstances (in order to differentiate), additional values (and hence attribute type andvalue pairs) may be used.

A single value instance of any appropriate attribute type may form part of the RDN, depending on the nature of theobject class denoted. Allocation of RDNs is considered an administrative undertaking that may or may not requiresome negotiation between involved organizations or administrations. This Directory Specification does not providesuch a negotiation mechanism, and makes no assumption as to how it is performed. The RDN may be modified ifnecessary by complete replacement.

Notes

1 RDNs are intended to be long-lived so that the users of the Directory can store the distinguished names of objects (e.g.,in the Directory itself) without concerns for their obsolescence. Thus RDNs should be changed cautiously.

2 Changing the RDN of a non-leaf entry automatically changes the corresponding RDN of subordinate entries.

9.4 Distinguished Names

The distinguished name of a given object is defined as that name which consists of the sequence of the RDNs of theentry which represents the object and those of all of its superior entries (in descending order). Because of the one toone correspondence between objects and object entries, the distinguished name of an object is the distinguishedname of the object entry.

Notes

1 It is preferable that the distinguished names of objects which humans have to deal with be user-friendly.

2 ISO 7498-3 defines the concept of a primitive name. A distinguished name can be used as a primitive name for the objectit identifies because: (a) it is unambiguous, (b) it is unique, and (c) the semantics of its internal structure (a sequence ofRDNs) need not (but of course may) be understood by the user of the Directory.

3 Because only the object entry and its superiors are involved, distinguished names of objects can never involve aliasentries.

Alias entries also have distinguished names; however, this name cannot be the distinguished name of an object.When this distinction needs to be made, the complete term “distinguished name of an alias entry” is used. Thedistinguished name of an alias entry is defined, as for the distinguished name of an object entry, to be the sequenceof RDNs of the alias entry and those of all of its superior entries (in descending order).

It also proves convenient to define the ‘distinguished name’ of the root, although this can never be the distinguishedname of an object. The distinguished name of the root is defined to be the null sequence.

An example which illustrates the concepts of RDN and distinguished name appears in Figure 4.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 19

ROOT

(OU=Sales,L=Ipswich)

Countries

Organizations

Organizational Units

People

{ }

C=GB {C=GB}

O=Telecom {C=GB, O=Telecom}

{C=GB, O=Telecom,(OU=Sales, L=Ipswich)}

CN=Smith{C=GB, O=Telecom,(OU=Sales, L=Ipswich),CN=Smith}

RDN Distinguished Name

Figure 4 — Determination of Distinguished Names

9.5 Alias Names

An alias, or an alias name , for an object is a an alternative name for an object or object entry which is provided bythe use of alias entries.

Each alias entry contains, within the aliasedEntryName attribute, a name of some object. The distinguished name ofthe alias entry is thus also a name for this object .

Note - The name within the aliasedEntryName is said to be pointed to by the alias. It does not have to be thedistinguished name of any entry.

The conversion of an alias name to an object name is termed (alias) dereferencing and comprises the systematicreplacement of alias names, where found within a purported name, by the value of the correspondingaliasedEntryName attribute. The process may require the examination of more than one alias entry.

Any particular entry in the DIT may have zero or more alias names. It therefore follows that several alias entriesmay point to the same entry. An alias entry may point to an entry that is not a leaf entry and may point to anotheralias entry.

An alias entry shall have no subordinates, so that an alias entry is always a leaf entry.

Every alias entry shall belong to the alias object class which is defined in 12.3.3.

SECTION 4: DIRECTORY ADMINISTRATIVE MODEL

10 Directory Administrative Authority model10.1 Definitions


— administrative area : a subtree of the DIT considered from the perspective of administration.

— administrative entry : an entry located at an administrative point.

— administrative point : the root vertex of an administrative area.

— administrative user: a representative of an Administrative Authority. The full definition of theadministrative user concept is outside the scope of this Directory Specification.

— autonomous administrative area : a subtree of the DIT whose entries are all administered by the sameAdministrative Authority. Autonomous administrative areas are non-overlapping.

ISO/IEC 9594-2 : 1993(E)

20 ITU-T Rec. X.501 (1993 E)

— DIT Domain Administrative Authority : an Administrative Authority in its role as the entity havingresponsibility for the administration of a part of the DIT.

— DIT Domain policy : an expression of the general goals and acceptable procedures for a DIT Domain.

— DMD Administrative Authority: an Administrative Authority in its role as the entity responsible for theadministration of a DMD.

— DMD policy : a policy governing the operation of the DSAs in a DMD.

— DMO policy: a policy defined by a DMO, expressed in terms of DMD and DIT Domain policies.

— inner administrative area : a specific administrative area whose scope is wholly contained within the scopeof another specific administrative area of the same type.

— policy: an expression by an Administrative Authority of general goals and acceptable procedures.

— policy attribute: a generic term for any Directory operational attribute which expresses policy.

— policy objec t: an entity with which a policy is concerned.

— policy procedure: a rule defining how a set of policy objects should be considered and what actions shouldbe taken as a result of this consideration.

— policy parameter : A policy procedure is characterised by certain policy parameters which are subject toconfiguration (i.e. choice) by an Administrative Authority.

— specific administrative area: a subset (in the form of a subtree) of an autonomous administrative areadefined for a particular aspect of administration: access control, subschema or entry collectionadministration. When defined, specific administrative areas of a particular kind partition an autonomousadministrative area

— specific administrative point: the root vertex of a specific administrative area.

10.2 Overview

A fundamental objective of the Directory information model is to consider well-defined collections of entries so thatthey may be administered consistently as a unit. This clause clarifies the nature and scope of the authoritiesresponsible for that administration and the means by which their authority is exercised.

The concept of policy, defined in 10.3, provides the mechanism by which Administrative Authorities exercisecontrol of the Directory.

Some aspects of the Directory Administrative Model are supported by the Model of Directory Administrative andOperational Information (see clause 11). This is to allow the modeling of information required for the regulation ofDirectory user information and for other administrative purposes.

Other aspects of the Directory Administrative Model require support for the distribution of administrative andoperational information among the component parts of the Directory, i.e. DSAs. Clauses 18 through 20 describes aDSA Information Model to support these requirements.

10.3 Policy

A policy is an expression by an Administrative Authority, acting as an agent of the DMO, of general goals andacceptable procedures. A policy is defined in terms of rules that are to be enforced (by the Directory, if appropriate)and in terms of aspects within which an administrative user has some degree of freedom of action and specificresponsibilities.

An Administrative Authority expresses DMO policy in terms of:

— DIT Domain Policy;

— DMD Policy.

These policies may be expressed as policy attributes. A model of DIT policies is defined in 10.6.

Note — Clause 13 defines the system schema necessary to support the administration of collective attributes. Clause 14defines a framework for supporting subschema administration policies. Clause 16 defines a framework supporting accesscontrol policies.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 21

DMD policies relate specifically to DSAs as components of the distributed Directory. These DMD policies aredescribed in 10.7 which defines a model for DSA administration.

Finally there are policies which relate to external matters (such as bilateral agreements between DMOs) and aretherefore not further described here.

A policy object is an entity with which a policy is concerned (e.g. a subschema administrative area is a policyobject).

A policy procedure is a rule defining how a set of policy objects should be considered and what actions should betaken (and under what circumstances) as a result of this consideration (e.g. clause 14 defines subschemaadministration policy procedures).

A policy procedure is characterised by certain policy parameters which are subject to configuration (i.e. choice) byan Administrative Authority.

Operational attributes are used to represent policy parameters. The values of such an attribute form an expression ofsome or all of the policy parameter it represents.

10.4 Specific administrative authorities

The administration of a DIT Domain involves the execution of four functions related to different aspects ofadministration:

— naming administration;

— subschema administration;

— security administration;

— collective attribute administration.

A specific Administrative Authority is an Administrative Authority in its role as the entity responsible for one ofthese specific aspects of DIT Domain policy.

The term Naming Authority (see clause 9 of this Directory Specification) identifies the role of the AdministrativeAuthority as it pertains to the allocation of names and administration of the structure of these names. A role of theSubschema Authority is to implement these naming structures in the subschema.

The term Subschema Authority identifies the role of the Administrative Authority as it pertains to the establishment,administration and execution of the subschema policy controlling the naming and content of entries in a DITDomain. Clause 14 describes Directory support of Subschema Administration.

The term Security Authority (see ITU-T Rec. X.509 | ISO/IEC 9594-8) identifies the role of the AdministrativeAuthority as it pertains to the establishment, administration and execution of a security policy governing thebehaviour of the Directory with respect to entries in a DIT Domain.

The term Collective Attribute Authority identifies the role of the Administrative Authority as it pertains to theestablishment and administration of collective attributes (see clause 11.7) in a DIT Domain.

10.5 Administrative areas and administrative points

10.5.1 Autonomous administrative areas

Each entry in the DIT is administered by precisely one Administrative Authority (which may operate in differentroles). An autonomous administrative area is a subtree of the DIT whose entries are all administered by the sameAdministrative Authority.

The DIT Domain may be partitioned into one or more non-overlapping autonomous administrative areas.

The set of one or more autonomous administrative areas for which a DMO has administrative authority is its DITDomain. This is represented in Figure 5.

ISO/IEC 9594-2 : 1993(E)

22 ITU-T Rec. X.501 (1993 E)

DomainDIT

AAAAAutonomousArea (AA)

Figure 5 — A DIT Domain

10.5.2 Specific administrative areas

In the same way that an Administrative Authority may operate in a specific role, entries in an administrative areamay be considered in terms of a specific administrative function. When viewed in this context an administrative areais termed a specific administrative area . There are three kinds of specific administrative area:

— subschema administrative areas;

— access control administrative areas;

— collective-attribute administrative areas.

An autonomous administrative area may be considered as implicitly defining a single specific administrative area foreach specific aspect of administration. In this case there is a precise correspondence between each such specificadministrative area and the autonomous administrative area.

Alternatively, for each specific aspect of administration, the autonomous administrative area may be partitioned intonon-overlapping specific administrative areas.

If so partitioned for a particular aspect of administration, each entry of the autonomous administrative area iscontained in one and only one specific administrative area of that aspect.

A specific Administrative Authority is responsible for each specific administrative area. If, for a particularadministrative aspect, an autonomous administrative area is not partitioned, a specific Administrative Authority isresponsible for that administrative aspect for the entire autonomous administrative area.

10.5.3 Inner administrative areas

For the purpose of security or collective attribute administration, inner (administrative) areas within these kinds ofspecific administrative areas may be defined:

a) to represent a limited form of delegation; or

b) for administrative or operational convenience (e.g. where the administrative point of a subtree is in a DSAother than the one holding the entries within the subtree, that subtree may be designated as an inner area toallow administration via the local DSA).

An inner administrative area may be nested within another inner administrative area.

Inner areas represent areas of limited autonomy. Entries in inner areas are administered by the specificAdministrative Authorities of the specific administrative areas within which they are contained, and also by theAdministrative Authorities of the inner areas within which they are contained. The former authorities have overallcontrol of the policies regulating these entries while the latter authorities have (limited) control over those aspects ofpolicy delegated to them by the former.

The rules for nested inner areas, should they be permitted, must be defined as part of the definition of the specificadministrative aspect within which they are contained.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 23

10.5.4 Administrative points

The specification of the extent of an autonomous administrative area is implicit and consists of the identification of apoint in the DIT (the root of the autonomous administrative area’s subtree), an autonomous administrative point ,from which the administrative area proceeds downwards until another autonomous administrative point isencountered, at which another autonomous area begins.

Note — The immediate subordinates of the root of the DIT are autonomous administrative points.

Where an autonomous administrative area is not partitioned for a specific aspect of administration, then theadministrative area for that aspect coincides with the autonomous administrative area. In this case, the autonomousadministrative point is also the specific administrative point for this aspect of administration.

Where an autonomous administrative area is partitioned for a specific aspect of administration, then the specificationof the extent of each specific administrative area consists of the identification of the root of the specificadministrative area’s subtree, a specific administrative point, from which the specific administrative area proceedsdownwards until another specific administrative point (of the same administrative aspect) is encountered, at whichanother specific administrative area begins.

Specific administrative areas are always bounded by the autonomous administrative area they partition.

A particular administrative point may be the root of an autonomous administrative area and may be the root of oneor more specific administrative areas.

The specification of the extent of an inner administrative area (within a specific administrative area) consists of theidentification of the root of the inner administrative area’s subtree, an inner administrative point . An inneradministrative area is bounded by the specific administrative area within which it is defined.

An administrative point corresponding to the root of an autonomous administrative area represents a DIT Domain(and DSA) boundary. That is, its immediate superior in the DIT must be under the administrative authority ofanother DMD.

Note — This implies that a DMO cannot arbitrarily partition a DIT Domain into autonomous administrative areas.

An administrative point is represented in the Directory information model by an entry holding anadministrativeRole attribute. The values of this attribute identify the type of administrative point. This attribute isdefined in 13.3.

Clauses 18 through 20 describes how administrative areas are mapped onto DSAs and the DSA information model.

Figure 6 depicts an autonomous administrative area which has been partitioned into two specific administrative areasfor a specific aspect of administration (e.g. access control). In one specific administrative area, a nested inneradministrative area has been created (e.g. because the subtree is to be held in a different DSA from the remainder ofthe specific administrative area).

Figure 6 uses the abbreviations AAP (autonomous administrative point), SAP (specific administrative point) andIAP (inner administrative point).

SAP

AdministrativePoint (AAP & SAP)

Specific Administrative

Area

IAP Specific Administrative

Area

Autonomous Administrative

Area

AdministrativeInner

Area

Figure 6 — Administrative Points and Areas

ISO/IEC 9594-2 : 1993(E)

24 ITU-T Rec. X.501 (1993 E)

10.5.5 Administrative entries

An entry located at an administrative point is an administrative entry. Administrative entries may have specialentries, called subentries , as immediate subordinates. The administrative entry and its associated subentries are usedto control the entries encompassed by the associated administrative area.

Where inner administrative areas are used, the scopes of these areas may overlap.

Therefore, for each specific aspect of administrative authority, a definition is required of the method of combinationof administrative information when it is possible for entries to be included in more than one subtree or subtreerefinement associated with an inner area defined for that aspect.

Note — It is not necessary for an administrative point to represent each specific aspect of administrative authority. Forexample, there might be an administrative point, subordinate to the root of the autonomous administrative area, which isused for access control purposes only.

10.6 DIT Domain policies

A DIT Domain policy has the following components: DIT policy objects, DIT policy procedures, and DIT policyparameters.

An operational attribute that represents a DIT policy parameter is termed a DIT policy attribute (e.g. subschemaadministration operational attributes defined in clause 13 are DIT Domain policy attributes).

For a particular DSA, the possible values of a policy parameter may not correspond to distinct, realisable courses ofaction for that component. This may be the case, for example, when the DSA lacks the technical capability toperform all aspects of the policy procedure (e.g. implement a particular access control scheme). To be well-defined,a policy procedure must take such circumstances into account as part of its definition.

Specific DIT Domain policy objects and attributes are defined in clause 14 to support subschema administration.

10.7 DMD policies

A DMD policy is a policy that pertains to the operation of one or more of the DSAs in the DMD. A DMD policymay apply either to all the DSAs in the DMD in a uniform manner, to a subset of the DSAs in the DMD, or it mayapply to one specific DSA.

One sort of DMD policy is to restrict or otherwise control the Directory and DSA abstract service provided by oneor more DSAs.

Examples of such restrictions are:

1) Limiting the basic service provided to Directory (i.e. non-administrative) users to interrogation operationsonly, in accordance with CCITT Rec. F.500.

2) Limiting the service provided to users accessing the DSA indirectly, via chaining, including distinctionsbased on whether the user request traversed a trusted path.

3) Limitations on requests accepted from users accessing the DSA directly when chaining is required to DSAsin the DMD known to be subject to limitations of the kind indicated in the previous point.

SECTION 5: MODEL OF DIRECTORY ADMINISTRATIVE ANDOPERATIONAL INFORMATION

11 Model of Directory Administrative and Operational Information11.1 Definitions


— base: the root vertex of the subtree or subtree refinement produced by the evaluation of a subtreespecification.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 25

— chop: a set of assertions concerning the names of the subordinates of a base.

— Directory operational attribute: an operational attribute defined and visible in the Directory Administrativeand Operational information model.

— Directory system schema : the set of rules and constraints concerning operational attributes and subentries.

— entry : a Directory entry or extended Directory entry, depending on the context (either users and theirapplications or administration and operation of the Directory) in which the term is used.

— subentry: a special sort of entry, known by the Directory, used to hold information associated with a subtreeor subtree refinement.

— subtree: a collection of object and alias entries situated at the vertices of a tree. The prefix “sub”emphasizes that the base (or root) vertex of this tree is usually subordinate to the root of the DIT.

— subtree refinement : an explicitly specified subset of the entries in a subtree, where the entries are notlocated at the vertices of a single subtree

— subtree specification : the explicit specification of a subtree or subtree refinement. A subtree specificationconsists of zero or more of the specification elements base, chop and specification filter. The definition istermed explicit (in contrast to that of an administrative area) because the portion of the DIT subordinate tothe base that is included in the subtree or subtree refinement is explicitly specified.

11.2 Overview

From an administrative perspective, user information held in the DIB is supplemented by administrative andoperational information represented by:

– operational attributes, which represent information used to control the operation of the Directory (e.g.access control information) or used by the Directory to represent some aspect of its operation (e.g. timestamp information); and

– subentries, which associate the values of a set of attributes (e.g. collective attributes) with entries within thescope of the subentry. The scope of a subentry is a subtree or subtree refinement.

This information, illustrated in Figure 7, may be placed in the Directory by administrative authorities or by DSAs,and is used by the Directory in the course of its operation.

ADMINISTRATIVE ENTRY

UserAttributes

Operational Attributes

AdministrativePoint (AP)

SUBENTRY

UserAttributes


SUBENTRY

AdministrativeArea (AA)

AP

UserAttributes


ENTRY

Figure 7 — Model of Directory Administrative and Operational Information.

Two mechanisms in the Directory abstract service that have been added in this edition of the DirectorySpecifications that relate to this view of Directory information are:

– EntryInformationSelection has been extended to permit the selection of operational attributes in an entry,and

– the subentries service control has been added to permit the list and search operations to apply either toobject and alias entries or to subentries.

ISO/IEC 9594-2 : 1993(E)

26 ITU-T Rec. X.501 (1993 E)

Access to operational information, as for user information, may be limited by an access control mechanism.

Entries are made visible to Directory users via the Directory abstract service, but their relationships to the DSAs thatultimately hold them are not. The DSA information model, described in clauses 21 through 24, expresses themapping of these entries onto the information repositories of DSAs.

11.3 Subtrees

11.3.1 Overview

A subtree is a collection of object and alias entries situated at the vertices of a tree. Subtrees do not containsubentries. The prefix “sub”, in subtree, emphasizes that the base (or root) vertex of this tree is usually subordinateto the root of the DIT.

A subtree begins at some vertex and extends to some identifiable lower boundary, possibly extending to leaves. Asubtree is always defined within a context which implicitly bounds the subtree. For example, the vertex and lowerboundaries of a subtree defining a replicated area are bounded by a naming context. Similarly, the scope of a subtreedefining a specific administrative area is limited to the context of an enclosing autonomous administrative area.

11.3.2 Subtree specification

Subtree specification is the definition of a subset of the entries below a specified vertex which forms the base of thesubtree or subtree refinement.

The vertex and/or the lower boundary of the subtree may be implicitly specified, in which case they are determinedby the context within which the subtree is used.

The vertex and/or the lower boundary may be explicitly specified using the mechanism specified in this clause. Thismechanism may also be used to specify subtree refinements which are not true tree structures.

Note — The topological concept of a (sub)tree is useful in considering such specifications, although a particularspecification may determine a collection of entries that are not located at the vertices of a single (sub)tree. The term subtreerefinement is preferred when the entries of the collection are not so located.

Specification of a subtree consists of three optional elements of specification which identify the base of the subtree,and then reduce the collection of subordinate entries. These elements of specification are:

a) base: the root vertex of the subtree or subtree refinement produced by the evaluation of a subtreespecification;

b) chop: a set of assertions concerning the names of the subordinate entries; and

c) specification filter: a proper subset of the assertive capability of a filter applied to the subordinates.

The specification of a subtree or subtree refinement may be represented by the following ASN.1 type:

SubtreeSpecification ::= SEQUENCE {base [0] LocalName DEFAULT { },

COMPONENTS OF ChopSpecification,specificationFilter [4] Refinement OPTIONAL }

-- empty sequence specifies whole administrative area

The three components of this sequence correspond to the three specification elements identified above.

Where a value of SubtreeSpecification identifies a collection of entries that are located at the vertices of a singlesubtree, the collection is termed a subtree, otherwise the collection is termed a subtree refinement.

The SubtreeSpecification type provides a general purpose mechanism for the specification of subtrees and subtreerefinements. Any particular use of this mechanism defines the specific semantics of precisely what is specified andmay impose limitations or constraints on the components of SubtreeSpecification.

When each of the components of SubtreeSpecification is absent (i.e. a value of type SubtreeSpecification whichis an empty sequence, {}), the subtree so specified is implicitly determined by the context within which theSubtreeSpecification is used.

These terms are illustrated in Figure 8, for the case where subtrees are deployed within the context of administrativeareas.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 27

RefinementSubtree

AP

SubtreeNameLocal

AdministrativePoint (AP)

AA

AdministrativeArea (AA)

Figure 8 — Specification of Subtrees and Subtree Refinementswithin the context of administrative areas

11.3.3 Base

The base component of SubtreeSpecification represents the root vertex of the subtree or subtree refinement. Thismay be an entry which is subordinate to the root vertex of the identified scope or may be the root vertex of theidentified scope itself (the default).

The relative name of the root vertex of the subtree with respect to the root vertex of the identified scope is a value oftype LocalName:

LocalName ::= RDNSequence

Note that the root vertex of the identified scope and the root vertex of the subtree coincide when LocalName isomitted from SubtreeSpecification.

11.3.4 ChopSpecification

The ChopSpecification component consists of a set of assertions concerning the names of the subordinates of abase. It consists of a value of type ChopSpecification :

ChopSpecification ::= SEQUENCE {specificExclusions [1] SET OF CHOICE {

chopBefore [0] LocalName,chopAfter [1] LocalName } OPTIONAL,

minimum [2] BaseDistance DEFAULT 0,maximum [3] BaseDistance OPTIONAL}

This type is intended to permit the specification of a tree structure (or subset thereof) starting at the base by twomethods, specific exclusions and base distance.

11.3.4.1 Specific Exclusions

The specificExclusions component has two forms, chopBefore and chopAfter, which may be used individually orin combination.

The chopBefore component defines a list of exclusions, each in terms of some limit point which is to be excluded,along with its subordinates, from the subtree or subtree refinement. The limit points are the entries identified by aLocalName, relative to the base .

The chopAfter component defines a list of exclusions, each in terms of some limit point whose subordinates are tobe excluded from the subtree or subtree refinement. The limit points are the entries identified by a LocalName,relative to the base .

ISO/IEC 9594-2 : 1993(E)

28 ITU-T Rec. X.501 (1993 E)

11.3.4.2 Minimum and Maximum

These components allow exclusion of all entries that are superior to entries that are minimum RDN arcs below thebase as well as entries which are subordinate to entries that are maximum RDN arcs below the base. These distancesare expressed by values of the type BaseDistance:

BaseDistance ::= INTEGER (0 .. MAX)

A value of minimum equal to zero (the default), corresponds to the base. An absent maximum component indicatesthat no lower limit should be imposed on the subtree or subtree refinement.

11.3.5 Specification Filter

The specificationFilter component consists of a proper subset of the assertive capability of a filter (see ITU-T Rec.X.511 | ISO/IEC 9594-3) applied to the subordinates of a base. Only entries for which the filter evaluates to true areincluded in the resulting subtree refinement. It consists of a value of type Refinement :

Refinement ::= CHOICE {item [0] OBJECT-CLASS.&id,and [1] SET OF Refinement ,or [2] SET OF Refinement,not [3] Refinement }

A Refinement evaluates to TRUE as if it were a filter making an equality assertion regarding values of the attributetype objectClass only.

11.4 Operational attributes

There are three varieties of operational attribute: Directory operational attributes, DSA-shared operational attributes,and DSA-specific operational attributes.

Directory operational attributes occur in the Directory information model and are used to represent controlinformation (e.g. access control information) or other information provided by the Directory (e.g. an indication ofwhether an entry is a leaf or non-leaf entry).

DSA-shared operational attributes occur only in the DSA Information Model, and are not visible at all in theDirectory Information Models.

DSA-specific operational attributes occur only in the DSA Information Model, and are not visible at all in theDirectory Information Models.

Note — These are described in clauses 19 through 20 of this Directory Specification.

The definition and use of each operational attribute is a matter for specification in the appropriate DirectorySpecification.

11.5 Entries

11.5.1 Overview

From an administrative perspective, user information held in an entry may be supplemented by administrative andoperational information represented by operational attributes.

The Directory uses the object class attribute and DIT content rules applicable to an entry to control the userattributes required and permitted in the entry. The operational attributes of an entry are governed by the Directorysystem schema (see clause 13) applicable to the entry.

11.5.2 Access to operational attributes

Although not normally visible, the directory operational attributes within entries may be made visible to authorized(e.g. administrative) users of the directory abstract service. Certain operational attributes (e.g. entryACI, ormodifyTimestamp) might also be available to ordinary users.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 29

11.6 Subentries

11.6.1 Overview

A subentry is a special kind of entry immediately subordinate to an administrative point. It contains attributes thatpertain to a subtree (or subtree refinement) associated with its administrative point. The subentries and theiradministrative point are part of the same naming context (see clause 17).

A single subentry may serve all or several aspects of administrative authority. Alternatively, a specific aspect ofadministrative authority may be handled through one or more of its own subentries. At most one subentry ispermitted for a subschema administrative authority. Access control and collective attribute authorities may haveseveral subentries.

A subentry is not considered in list and search operations unless the subentries service control is included in therequest.

A subentry shall not have subordinates.

The structure of a subentry corresponding to an administrative point is depicted in Figure 9.

UserAttributes


ADMINISTRATIVE ENTRY

Subentry Subentry

Subtree

AttributeSpecificationRDN

SubentryAttribute Attribute…

Attribute

SUBENTRY

AttributeClass

Object

Figure 9 — Structure of a Subentry

A subentry consists of:

— A commonName attribute, specified in ITU-T Rec. X.521 | ISO/IEC 9594-6 which contains the RDN ofthe subentry;

— A subtreeSpecification attribute, specified in clause 13 of this Directory Specification;

— An objectClass attribute, specified in clause 12 of this Directory Specification, which indicates thepurpose(s) of the subentry in the operation of the Directory;

— Other attributes, depending on the values of the objectClass attribute.

Subentries may also contain operational attributes with appropriate semantics (see 11.6.4).

11.6.2 Subentry RDN attribute

The commonName attribute used as the subtree identifier serves to distinguish the various subentries that may bedefined as immediate subordinates of a specific administrative entry.

Note — The value of this attribute might be selected to serve as a mnemonic to representatives of the AdministrativeAuthority.

ISO/IEC 9594-2 : 1993(E)

30 ITU-T Rec. X.501 (1993 E)

11.6.3 Subtree Specification attribute

The subtreeSpecification attribute defines the collection of entries within the administrative area with which thesubtree is concerned.

11.6.4 Use of the Object Class attribute

The content of a subentry is regulated by the values of the subentry’s objectClass attribute.

The objectClass attribute of all subentries shall contain the value subentry . The subentry object class is astructural object class, defined in clause 13, used to include the commonName, subtreeSpecification andobjectClass attributes in all subentries.

In order to regulate the remaining attributes, the other values of the objectClass attribute, representing the auxiliaryobject classes allowed for the subentry, shall be used.

The definition of the semantics of one of these values includes an identification and specification of zero or moreattribute types that must or may appear in the subentry when the objectClass attribute assumes the value. Thedefinition of the semantics of a value for the objectClass attribute shall include:

— an indication of whether an entry may be included in more than one subtree or subtree refinementassociated with the particular purpose (e.g. it may not be permitted in the case of subschema, but may bepermitted for access control); and if so,

— the effects of the combination of associated subentry attributes, if any.

A subentry of a particular object class may only be subordinate to an administrative entry if the administrativeRoleattribute permits that class of subentry as a subordinate.

As for object and alias entries, information held in a subentry may be supplemented by administrative andoperational information represented by operational attributes. For example, a subentry is permitted to contain entryACI, provided only that this ACI is permitted by and consistent with the value of the accessControlSchemeattribute of the corresponding access control specific point. Similarly, a subentry may contain a modifyTimestamp .

11.6.5 Other subentry attributes

The remaining attributes within a subentry depend on the values of the objectClass attribute. For example, asubschema attribute may only be placed in a subentry if its objectClass attribute has subschema as one of itsvalues.

11.7 Information model for collective attributes

An autonomous administrative area may be designated as a collective attribute specific administrative area in orderto deploy and administer collective attributes. This shall be indicated by the presence of the value id-ar-collectiveAttributeSpecificArea in the associated administrative entry’s administrativeRole attribute (in additionto the presence of the value autonomousArea , and possibly other values).

Such an autonomous administrative area may be partitioned in order to deploy and administer collective attributes inthe specific partitions. In this case, the administrative entries for each of the collective attribute specificadministrative areas are indicated by the presence of the value id-at-collectiveAttributeSpecificArea in theseentries’ administrativeRole attributes.

If such an autonomous administrative area is not partitioned, there is a single specific administrative area forcollective attributes encompassing the entire autonomous administrative area.

Additionally, a specific administrative area defined for the purpose of collective attribute administration may befurther divided into nested inner areas for the same purpose. The administrativeRole attribute of the administrativeentries for each such inner administrative area shall indicate this by the presence of the value id-ar-collectiveAttributeInnerArea.

An entry collection and its associated collective attributes are represented in the Directory information model by asubentry, termed a collective attribute subentry , whose objectClass attribute has the value id-sc-collectiveAttributeSubentry, as defined in clause 13. A subentry of this class may be the immediate subordinate of

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 31

an administrative entry whose a d m i n i s t r a t i v e R o l e attribute contains the value id-ar-collectiveAttributeSpecificArea or id-ar-collectiveAttributeInnerArea .

Where there are different entry collections within a given collective attribute area, each must have its own subentry.

The entry collection itself is defined by the value of the subtreeSpecification operational attribute of the subentry.This value defines the scope of the collective attribute subentry. The user attributes of the subentry are the collectiveattributes of the entry collection.

Note — Because subtree refinement is based on object class, the association of collective attributes with object entries canbe done in a manner that naturally extends the schema for these entries. For example, the organizationalPerson entries of anorganization might be extended with a set of collective attributes appropriate for all persons affiliated with the organizationby the creation of a subentry whose associated subtree is refined to include only organizationalPerson entries and whichcontains the organization’s set of collective attributes. Additionally, a DIT Content Rule for such entries would need to bedefined to allow collective attributes to become visible in the entries.

Collective attribute types and non-collective attribute types differ semantically. An attribute type capable ofexpressing collective semantics must be designated as a collective attribute type at the time of its definition.

Note — Merging procedures employed by the Directory in the case of independent sources of values of a collective attributetype are described in ITU-T Rec. X.511 | ISO/IEC 9594-3.

Collective attributes may be excluded from appearing in a particular entry through use of the collectiveExclusionsattribute defined in clause 13.

SECTION 6: THE DIRECTORY SCHEMA

12 Directory Schema12.1 Definitions


— Attribute Syntax : The ASN.1 data type used to represent values of an attribute.

— Directory Schema: The set of rules and constraints concerning DIT structure, DIT content, object classesand attribute types, syntaxes and matching rules which characterize the DIB. The Directory Schema ismanifested as a set of non-overlapping subschemas each governing entries of an autonomous administrativearea (or a subschema specific partition thereof). The Directory schema is concerned only with DirectoryUser Information.

— (Directory) Subschema: The set of rules and constraints concerning DIT structure, DIT content, objectclasses and attribute types, syntaxes and matching rules which characterize the DIB entries within anautonomous administrative area (or a subschema specific partition thereof).

— DIT Content Rule : A rule governing the content of entries of a particular structural object class. It specifiesthe auxiliary object classes and additional attribute types permitted to appear, or excluded from appearing,in entries of the indicated structural object class.

— DIT Structure Rule: A rule governing the structure of the DIT by specifying a permitted superior tosubordinate entry relationship. A structure rule relates a name form, and therefore a structural object class,to superior structure rules. This permits entries of the structural object class identified by the name form toexist in the DIT as subordinates to entries governed by the indicated superior structure rules.

— Governing Structure Rule (of an entry) : With respect to a particular entry, the single DIT structure rule thatapplies to the entry. This rule is indicated by the governingStructureRule operational attribute.

— Name Form: A name form specifies a permissible RDN for entries of a particular structural object class. Aname form identifies a named object class and one or more attribute types to be used for naming (i.e. for theRDN). Name forms are primitive pieces of specification used in the definition of DIT structure rules.

Note — Name forms are registered and have global scope. DIT structure rules are not registered and have the scopeof the administrative area with which they are associated.

ISO/IEC 9594-2 : 1993(E)

32 ITU-T Rec. X.501 (1993 E)

— Superior Structure Rule: With respect to a particular entry, the DIT structure rule governing the entry’ssuperior.

12.2 Overview

The Directory Schema is a set of definitions and constraints concerning the structure of the DIT, the possible waysentries are named, the information that can be held in an entry, the attributes used to represent that information andtheir organization into hierarchies to facilitate search and retrieval of the information and the ways in which valuesof attributes may be matched in attribute value and matching rule assertions.

Note — The schema enables the Directory system to, for example:

— prevent the creation of subordinate entries of the wrong object-class (e.g., a country as a subordinate of aperson);

— prevent the addition of attribute-types to an entry inappropriate to the object-class (e.g., a serial number to aperson’s entry);

— prevent the addition of an attribute value of a syntax not matching that defined for the attribute-type (e.g., aprintable string to a bit string).

Formally, the Directory Schema comprises a set of:

a) Name Form definitions that define primitive naming relations for structural object classes;

b) DIT Structure Rule definitions that define the names that entries may have and the ways in which the theentries may be related to one another in the DIT;

c) DIT Content Rule definitions that extend the specification of allowable attributes for entries beyond thoseindicated by the structural object classes of the entries;

d) Object Class definitions that define the basic set of mandatory and optional attributes that shall be present,and may be present, respectively, in an entry of a given class, and which indicate the kind of object classthat is being defined (see 7.3 of this Directory Specification);

e) Attribute Type definitions that identify the object identifier by which an attribute is known, its syntax,associated matching rules, whether it is an operational attribute and if so its type, whether it is a collectiveattribute, whether it is permitted to have multiple values and whether or not it is derived from anotherattribute type;

f) Matching Rule definitions that define matching rules.

Figure 10 illustrates the relationships between schema and subschema definitions on the one side, and the DIT,directory entries, attributes, and attribute values on the other.

DirectorySchema

DirectorySchema

SubschemaDIT Structure Rule

Object Class

Attribute Types

ASN.1 typeMatching Rule

DirectoryInformation Tree

SubschemaAdministrative

Areas

Entries

Attributes

Values

rules for

rules for

rules for

rules for

rules for

uses

uses

use

use

DIT Content Rule

belong to

belong to

belong to

belong to

Name Form

Figure 10 — Overview of Directory Schema

Figure 10 is interpreted as follows:

— the items listed vertically on the left represent elements of schema;

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 33

— the items listed vertically on the right represent instances of corresponding schema items, instantiatedaccording to the rules defined by these schema items,

— the relationship between items of schema is illustrated by the “uses” relationship;

— the relationship between instances of different aspects of schema is illustrated using the “belong to”relationship.

The Directory Schema is distributed, like the DIB itself. It is manifested as a set of non-overlapping subschemaseach governing entries of an autonomous administrative area (or a subschema specific partition thereof). Asubschema administrative authority establishes the rules and constraints constituting the subschema.

The subschema administrative authority may elect to use individual elements of the Directory Schema having globalscope which are defined in these Directory Specifications: name forms, object classes and attributes (types andmatching rules). It may also choose to define alternatives to these elements more appropriate to its own environmentor it may choose some intermediate approach, using both standardised and proprietary schema elements.

The subschema administrative authority defines those schema elements whose scope is limited to the subschema:DIT structure and content rules. In addition, the subschema administrative authority may also specify whichmatching rules are applicable to which attribute types.

The Directory Schema is concerned only with directory user information. Although some support for thespecification of operational information is provided in the notation defined in this clause, the regulation of DirectoryAdministrative and Operational Information is the concern of the Directory System Schema.

Note — The Directory System Schema is described in clause 13.

12.3 Object class definition

The definition of an object class involves:

a) indicating which classes this object class is to be a subclass of;

b) indicating what kind of object class is being defined;

c) listing the mandatory attribute types that an entry of the object class shall contain in addition to themandatory attribute types of all its superclasses;

d) listing the optional attribute types that an entry of the object class may contain in addition to the optionalattributes of all its superclasses.

e) assigning an object identifier for the object class;

Note — Collective attributes shall not appear in the attribute types of an object class definition.

12.3.1 Subclassing

There are restrictions on subclassing, namely:

— only abstract object classes shall be superclasses of other abstract object classes.

There is one special object class, of which every structural object class is a subclass. This object class is called top .top is an abstract object class.

12.3.2 The object class attribute

Every entry shall contain an attribute of type objectClass to identify the object classes and superclasses to which theentry belongs. The definition of this attribute is given in 12.4.6 This attribute is multi-valued.

There shall be one value of the objectClass attribute for the entry’s structural object class and a value for each of itssuperclasses. top may be omitted.

An entry’s structural object classes shall not be changed. The initial values of the objectClass attribute are providedby the user when the entry is created.

Where auxiliary object classes are used, an entry may contain values of the objectClass attribute for the auxiliaryobject classes and their superclasses allowed by a DIT content rule. If a value for an allowed auxiliary object class ispresent, then values for the superclasses of the auxiliary object class shall also be present.

ISO/IEC 9594-2 : 1993(E)

34 ITU-T Rec. X.501 (1993 E)

Where the objectClass attribute contains an object identifier value for an auxiliary object class, then the entry shallcontain the mandatory attributes indicated by that object class.

Notes

1 The requirement that the objectClass attribute be present in every entry is reflected in the definition of top.

2 Because an object class is considered to belong to all its superclasses, each member of the chain of superclasses up to topis represented by a value in the objectClass attribute (and any value in the chain may be matched by a filter).

3 Access Control restrictions may be placed on modification of the objectClass attribute.

In conjunction with the applicable DIT content rules, the Directory enforces the defined object class for every entryin the DIB. Any attempt to modify an entry that would violate the entry’s object class definition that is not explicitlyallowed by the entry’s DIT content rule shall fail.

Note — in particular, the Directory will ordinarily prevent:

a) attribute types absent from an entry’s structural object class definition and not permitted by the entry’s DITcontent rule being added to an entry of that object class;

b) an entry being created with one or more absent mandatory attribute types for an object class of the entry;

c) a mandatory attribute type for the object class of the entry being deleted.

12.3.3 Object class specification

Object classes may be defined as values of the OBJECT-CLASS information object class:

OBJECT-CLASS ::= CLASS {&Superclasses OBJECT-CLASS OPTIONAL,&kind ObjectClassKind DEFAULT structural,&MandatoryAttributes ATTRIBUTE OPTIONAL,&OptionalAttributes ATTRIBUTE OPTIONAL,&id OBJECT IDENTIFIER UNIQUE }

WITH SYNTAX {[ SUBCLASS OF &Superclasses ][ KIND &kind][ MUST CONTAIN &MandatoryAttributes ][ MAY CONTAIN &OptionalAttributes ]ID &id }

ObjectClassKind ::= ENUMERATED {abstract (0),structural (1),auxiliary (2) }

For an object class which is defined using this information object class:

a) &Superclasses is the set of object classes which are its direct superclasses;

b) &kind is its kind;

c) &MandatoryAttributes is the set of attributes which entries of that class must contain;

d) &OptionalAttributes is the set of attributes which entries of that class may contain, except that if anattribute appears in both the mandatory and optional sets, it shall be considered mandatory;

e) &id is the object identifier assigned to it.

The object classes previously mentioned ( top and alias) are defined below:

top OBJECT-CLASS ::= {KIND abstractMUST CONTAIN { objectClass }ID id-oc-top }

alias OBJECT-CLASS ::= {SUBCLASS OF { top }MUST CONTAIN { aliasedEntryName }ID id-oc-alias }

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 35

Note — The object class alias does not specify appropriate attribute types for the RDN of an alias entry. AdministrativeAuthorities may specify subclasses of the class alias which specify useful attribute types for RDNs of alias entries.

12.4 Attribute type definition

The definition of an attribute type involves:

a) optionally indicating that the attribute type is a subtype of a previously defined attribute type, its directsupertype;

b) specifying the attribute syntax for the attribute type;

c) optionally indicating the equality, ordering and/or substring matching rule(s) for the attribute type;

d) indicating whether an attribute of this type shall have only one or may have more than one value;

e) indicating whether the attribute type is operational or user;

f) optionally indicating that a user attribute type is collective;

g) optionally indicating that an operational attribute is not user modifiable;

h) for operational attributes, indicating the application;

i) assigning an object identifier to the attribute type.

12.4.1 Operational attributes

Some operational attributes are under direct user control. In other cases the operational attribute’s values arecontrolled by the Directory. In the latter case, the definition of the operational attribute shall indicate that no usermodifications to the attribute values are permitted.

The specification of an operational attribute type shall indicate its application, which shall be one of the following:

— Directory operational attribute (e.g. access control attributes);

— DSA-shared operational attribute (e.g. a master-access-point attribute);

— DSA-specific operational attribute (e.g. a copy-status attribute).

12.4.2 Attribute hierarchies

An attribute hierarchy shall contain either user attributes or operational attributes but not both. It follows that a userattribute shall not be derived from an operational attribute and that an operational attribute shall not be derived froma user attribute.

An operational attribute that is a subtype of another operational attribute shall have the same application as itssupertype.

If an attribute type is not a subtype of another attribute type, the attribute syntax and matching rules (if applicable)shall be specified in the attribute type definition. Specifying an attribute syntax shall be done by directly specifyingthe ASN.1 data type.

If an attribute type is a subtype of an indicated type, the definition need not specify an attribute syntax, in which caseits attribute syntax is that of its direct supertype. If the attribute syntax is indicated and the attribute has a directsupertype, the indicated syntax must be compatible with the supertype’s syntax, i.e. every possible value satisfyingthe attribute’s syntax must also satisfy the supertype’s syntax.

If an attribute type is a subtype of another attribute type, the matching rules applicable to the supertype areapplicable to the subtype, unless extended or modified in the definition of the subtype. A matching rule defined for asupertype may not be removed when defining a subtype.

12.4.3 Collective attributes

An operational attribute shall not be defined to be collective.

A user attribute may be defined to be collective. This indicates that the same attribute values will appear in theentries of an entry collection subject to the use of the collectiveExclusions attribute.

Collective attributes shall be multi-valued.

ISO/IEC 9594-2 : 1993(E)

36 ITU-T Rec. X.501 (1993 E)

12.4.4 Attribute syntax

If an equality matching rule is specified for the attribute type, the Directory shall ensure that the correct attributesyntax is used for every value of this attribute type.

12.4.5 Matching rules

Equality, ordering and substrings matching rules may be indicated in the attribute type definition. The samematching rule may be used for one or more of these types of matches if the semantics of the rule allows for morethan one of these different types of matches.

Note — This fact must be reflected in the definition of the indicated matching rule.

If no equality matching rule is indicated, the Directory:

a) treats values of this attribute as having type ANY , i.e. the Directory may not check that those valuesconform with the data type or any other rule indicated for the attribute;

b) does not permit the attribute to be used for naming;

c) does not allow individual values of multi-valued attributes to be added or removed;

d) does not perform comparisons of values of the attribute;

e) will not attempt to evaluate AVAs using values of such an attribute type.

If an equality matching rule is indicated, the Directory:

a) treats values of this attribute as having the type defined in the &Type field in the attribute’s definition (orthat of the attribute from which the attribute is derived);

b) will use the indicated equality matching rule for the purpose of evaluating attribute value assertionsconcerning the attribute;

c) will only match a presented value of a suitable data type as specified in the attribute type definition.

Note — This clause applies equally to an attribute whose equality matching rule uses an assertion syntax different from thesyntax of the attribute type.

If no ordering matching rule is indicated the Directory shall treat any assertion of an ordering match using the syntaxprovided by the Directory Abstract Service as undefined.

If no substrings matching rule is indicated the Directory shall treat any assertion of an substring match using thesyntax provided by the Directory Abstract Service as undefined.

An attribute type shall only specify matching rules whose definition apply to the attribute’s attribute syntax.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 37

12.4.6 Attribute definition

Attributes may be defined as values of the ATTRIBUTE information object class:

ATTRIBUTE ::= CLASS {&derivation ATTRIBUTE OPTIONAL,&Type OPTIONAL, -- either &Type or &derivation required --&equality-match MATCHING-RULE OPTIONAL,&ordering-match MATCHING-RULE OPTIONAL,&substrings-match MATCHING-RULE OPTIONAL,&single-valued BOOLEAN DEFAULT FALSE,&collective BOOLEAN DEFAULT FALSE,-- operational extensions --&no-user-modification BOOLEAN DEFAULT FALSE,&usage AttributeUsage DEFAULT userApplications,&id OBJECT IDENTIFIER UNIQUE }

WITH SYNTAX {[ SUBTYPE OF &derivation ][ WITH SYNTAX &Type ][ EQUALITY MATCHING RULE &equality-match ][ ORDERING MATCHING RULE &ordering-match ][ SUBSTRINGS MATCHING RULE &substrings-match ][ SINGLE VALUE &single-valued ][ COLLECTIVE &collective ][ NO USER MODIFICATION &no-user-modification ][ USAGE &usage ]ID &id }

AttributeUsage ::= ENUMERATED {userApplications (0),directoryOperation (1),distributedOperation (2),dSAOperation (3) }

For an attribute which is defined using this information object class:

a) &derivation is the attribute, if any, of which it is a subtype;

b) &Type is its attribute syntax. This shall be an ASN.1 type;

c) &equality-match is its equality matching rule (if any);

d) &ordering-match is its ordering matching rule (if any);

e) &substrings-match is its substrings matching rule (if any);

f) &single-valued is TRUE if it is single valued, and false otherwise;

g) &collective is TRUE if it is a collective attribute, and false otherwise;

h) &no-user-modification is TRUE if it is an operational attribute which cannot be modified by the user.

i) &usage indicates the operational usage of the attribute. userApplications means it is a user attribute,directoryOperation , distributedOperation , and dSAOperation mean it is a directory, distributed, or DSA-operational attribute respectively.

j) &id is the object identifier assigned to it.

The attribute types defined in the 1988 edition of this Directory Specification which are known to and used by theDirectory for its own purposes are defined as follows:

objectClass ATTRIBUTE ::= {WITH SYNTAX OBJECT IDENTIFIEREQUALITY MATCHING RULE objectIdentifierMatchID id-at-objectClass }

ISO/IEC 9594-2 : 1993(E)

38 ITU-T Rec. X.501 (1993 E)

aliasedEntryName ATTRIBUTE ::= {WITH SYNTAX DistinguishedNameEQUALITY MATCHING RULE distinguishedNameMatchSINGLE VALUE TRUEID id-at-aliasedEntryName }

Note — The matching rules referred to in these definitions are themselves defined in 12.5.2.

The objectClass and aliasedEntryName attributes are defined as user attributes even though they are used forDirectory operations and semantically should be defined as operational. This is because these attributes were definedas user attributes before the operational attribute concept and must remain as user attributes to facilitate interworkingbetween systems implementing different editions of this Directory Specification.

12.5 Matching rule definition

12.5.1 Overview

The definition of a matching rule involves:

a) defining the syntax of an assertion of the matching rule;

b) specifying the different types of matches supported by the rule;

c) defining the appropriate rules for evaluating a presented assertion with respect to target attribute values heldin the DIB;

d) assigning an object identifier to the matching rule.

A matching rule shall be used to evaluate attribute value assertions of attributes indicating the rule as their equalitymatching rule. The syntax used in the attribute value assertion (i.e. the assertion component of the attribute valueassertion) is the matching rule’s assertion syntax.

A matching rule may apply to many different types of attributes with different attribute syntaxes.

The definition of a matching rule shall include a specification of the syntax of an assertion of the matching rule andthe way in which values of this syntax are used to perform a match. This does not require a full specification of theattribute syntax to which the matching rule may apply. A definition of a matching rule for use with attributes withdifferent ASN.1 syntaxes shall specify how matches shall be performed.

The applicability of defined matching rules to the attributes contained in a subschema specification (over and abovethe matching rules used in the definition of these attribute types) is indicated through the subschema specificationoperational attribute matchingRuleUse , defined in 14.7.7.

12.5.2 Matching rule definition

Matching rules may be defined as values of the MATCHING-RULE information object class:

MATCHING-RULE ::= CLASS {&AssertionType OPTIONAL,&id OBJECT IDENTIFIER UNIQUE }

WITH SYNTAX {[ SYNTAX &AssertionType ]ID &id}

For a matching rule which is defined using this information object class:

a) &AssertionType is the syntax for an assertion using this matching rule; if it is omitted, the assertion syntaxis the same syntax as that of the attribute the rule is applied to;

b) &id is the object identifier assigned to it.

The objectIdentifierMatch matching rule is defined as follows:

objectIdentifierMatch MATCHING-RULE ::= {SYNTAX OBJECT IDENTIFIERID id-mr-objectIdentifierMatch }

A presented value of type object identifier matches a target value of type object identifier if and only if they bothhave the same number of integral components and each integral component of the first is equal to the corresponding

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 39

component of the second. This matching rule is inherent in the definition of the ASN.1 type object identifier.objectIdentifierMatch is an equality matching rule.

The distinguishedNameMatch is defined as follows:

distinguishedNameMatch MATCHING-RULE ::= {SYNTAX DistinguishedNameID id-mr-distinguishedNameMatch }

A presented distinguished name value matches a target distinguished name value if and only if all of the followingare true:

a) the number of RDNs in each is the same;

b) corresponding RDNs have the same number of AVAs;

c) corresponding AVAs (i.e. those in corresponding RDNs and with identical attribute types) have attributevalues which match for equality (in such a match, the attribute values take the same roles - i.e. as presentedor target value - as the distinguished name which contains them in the overall match).

distinguishedNameMatch is an equality matching rule.

12.6 DIT structure definition

12.6.1 Overview

A fundamental aspect of the Directory schema is the specification of where an entry of a particular class may beplaced in the DIT and how it should be named, considering:

— the hierarchical relationship of entries in the DIT (DIT structure rules);

— the attribute or attributes used to form the RDN of the entry (name forms).

12.6.2 Name form definition

The definition of a name form involves:

a) specifying the named object class;

b) indicating the mandatory attributes to be used for the RDNs for entries of this object class where this nameform applies;

c) indicating the optional attributes if any that may be used for the RDNs for entries of this object class wherethis name form applies;

d) assigning an object identifier for the name form;.

If different sets of naming attributes are required for entries of a given structural object class, then a name form mustbe specified for each distinct set of attributes to be used for naming.

Only structural object classes are used in name forms.

For entries of a particular structural object class to exist in a portion of the DIB, at least one name form for thatobject class shall be contained in the applicable part of the schema. The schema contains additional name forms asrequired.

The RDN attribute (or attributes) need not be chosen from the list of permitted attributes of the structural object classas specified in its structural or alias object class definition.

Note — Naming attributes are governed by DIT content rules in the same way as other attributes.

A name form is only a primitive element of the full specification required to constrain the form of the DIT to thatrequired by the administrative and naming authorities that determine the naming policies of a given region of theDIT. The remaining aspects of the specification of DIT structure are discussed in 12.6.5.

12.6.3 Name form specification

Name forms may be defined as values of the NAME-FORM information object class:

ISO/IEC 9594-2 : 1993(E)

40 ITU-T Rec. X.501 (1993 E)

NAME-FORM ::= CLASS {&namedObjectClass OBJECT-CLASS,&MandatoryAttributes ATTRIBUTE,&OptionalAttributes ATTRIBUTE OPTIONAL,&id OBJECT IDENTIFIER UNIQUE }

WITH SYNTAX {NAMES &namedObjectClassWITH ATTRIBUTES &MandatoryAttributes[ AND OPTIONALLY &OptionalAttributes ]ID &id }

For a name form which is defined using this information object class:

a) &namedObjectClass is the structural object class it names;

b) &MandatoryAttributes is the set of attributes which must be present in the RDN of the entry it governs;

c) &OptionalAttributes is the set of attributes which may be present in the RDN of the entry it governs;

d) &id is the object identifier assigned to it.

All attribute types in the mandatory and optional lists shall be different.

12.6.4 The structural object class of an entry

Some subschema specifications will include name forms for no more than one structural object class per structuralobject class superclass chain represented in the subschema.

Some subschema specifications may include name forms for more than one structural object class per structuralobject class superclass chain represented in the subschema.

In either case, with respect to a particular entry, only the most subordinate structural object class in the structuralsuperclass chain present in the entry’s objectClass attribute determines the DIT content rule and DIT structure ruleapplying to the entry. This class is referred to as the structural object class of the entry and is indicated by thestructuralObjectClass operational attribute.

12.6.5 DIT structure rule definition

A DIT structure rule is a specification provided by the subschema administrative authority which the Directory usesto control the placement and naming of entries within the scope of the subschema. Each object and alias entry isgoverned by a single DIT structure rule. A subschema governing a subtree of the DIT will typically contain severalDIT structure rules permitting several types of entries within the subtree.

A DIT structure rule definition includes:

a) an integer identifier which is unique within the scope of the subschema;

b) an indication of the name form for entries governed by the DIT structure rule;

c) the set of allowed superior structure rules, if required.

The set of DIT structure rules for a subschema specify the forms of distinguished names for entries governed by thesubschema.

A DIT structure rule allows entries in a given subschema to subscribe to a particular name form. The form of the lastRDN component of an entry’s DistinguishedName is determined by the name form of the DIT structure rulegoverning the entry.

The namedObjectClass component of the name form (the name form’s object class) corresponds to the structuralobject class of the entry.

A DIT structure rule shall only permit entries belonging to the structural object class identified by its associatedname form. It does not permit entries belonging to any of the subclasses of the structural object class.

With respect to a particular entry, the DIT structure rule governing the entry is termed the entry’s governingstructure rule . This rule may be identified by examining the entry’s governingStructureRule attribute.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 41

With respect to a particular entry, the DIT structure rule governing the entry’s superior is termed the entry’s superiorstructure rule .

An entry may only exist in the DIT as a subordinate to another entry (the superior) if a DIT structure rule exists inthe governing subschema which:

— indicates a name form for the structural object class of the entry, and;

— either includes the entry’s superior structure rule as a possible superior structure rule or does not specify asuperior structure rule, in which case the entry must be a subschema administrative point.

12.6.6 DIT structure rule specification

The abstract syntax of a DIT structure rule is expressed by the following ASN.1 type:

DITStructureRule ::= SEQUENCE {ruleIdentifier RuleIdentifier ,

-- must be unique within the scope of the subschemanameForm NAME-FORM.&id,superiorStructureRules SET OF RuleIdentifier OPTIONAL }

RuleIdentifier ::= INTEGER

The correspondence between the parts of the definition, as listed in 12.6.5, and the various components of the ASN.1type defined above, is as follows:

a) the ruleIdentifier component identifies the DIT structure rule uniquely within a subschema;

b) the nameForm component of the DIT structure rule specifies the name form for entries governed by theDIT structure rule;

c) the superiorStructureRules component identifies permitted superior structure rules for entries governedby the rule. If this component is omitted, then the DIT structure rule applies to an autonomousadministrative point.

The STRUCTURE-RULE information object class is provided to facilitate the documentation of DIT structure rules:

STRUCTURE-RULE ::= CLASS {&nameForm NAME-FORM,&SuperiorStructureRules STRUCTURE-RULE OPTIONAL,&id RuleIdentifier UNIQUE }

WITH SYNTAX {[ NAME FORM &nameForm ][ SUPERIOR RULES &SuperiorStructureRules ]ID &ruleIdentifier }

12.7 DIT content rule definition

12.7.1 Overview

A DIT content rule specifies the permissible content of entries of a particular structural object class via theidentification of an optional set of auxiliary object classes, mandatory, optional and precluded attributes. Collectiveattributes shall be included in DIT Content rules if they are to be permitted in an entry.

A DIT content rule definition includes:

a) an indication of the structural object class to which it applies;

b) optionally, an indication of the auxiliary object classes allowed for entries governed by the rule;

c) optionally, an indication of the mandatory attributes, over and above those called for by the structural andauxiliary object classes, required for entries governed by the DIT content rule;

d) optionally, an indication of the optional attributes, over and above those called for by the structural andauxiliary object classes, permitted for entries governed by the DIT content rule;

e) optionally, an indication of optional attribute(s) from the entry’s structural and auxiliary object classeswhich are precluded from appearing in entries governed by the rule.

For any valid subschema specification, there is at most one DIT content rule for each structural object class.

ISO/IEC 9594-2 : 1993(E)

42 ITU-T Rec. X.501 (1993 E)

Every entry in the DIT is governed by at most one DIT content rule. This rule may be identified by examining thevalue of the entry’s structuralObjectClass attribute.

If no DIT content rule is present for a structural object class, then entries of that class shall contain only theattributes permitted by the structural object class definition.

The DIT content rules of superclasses of the structural object class for an entry do not apply to that entry.

As a DIT content rule is associated with a structural object class, it follows that all entries of the same structuralobject class will have the same DIT content rule regardless of the DIT structure rule governing their location in theDIT.

An entry governed by a DIT content rule may, in addition to the structural object class of the DIT structure rule, beassociated with a subset of the auxiliary object classes identified by the DIT content rule. This association isreflected in the entry’s objectClass attribute.

An entry’s content must be consistent with the object classes indicated by its objectClass attribute in the followingway:

— mandatory attributes of object classes indicated by the objectClass attribute shall always be present in theentry;

— optional attributes (not indicated as additional optional or mandatory in the DIT content rule)of auxiliaryobject classes indicated by the DIT content rule may only be present if the objectClass attribute indicatesthese auxiliary object classes.

Mandatory attributes associated with the structural or indicated auxiliary object classes shall not be precluded in aDIT content rule.

12.7.2 DIT content rule specification

The abstract syntax of a DIT content rule is expressed by the following ASN.1 type:

DITContentRule ::= SEQUENCE {structuralObjectClass OBJECT-CLASS.&id,auxiliaries SET OF OBJECT-CLASS.&id OPTIONAL,mandatory [1] SET OF ATTRIBUTE.&id OPTIONAL,optional [2] SET OF ATTRIBUTE.&id OPTIONAL,precluded [3] SET OF ATTRIBUTE.&id OPTIONAL }

The correspondence between the parts of the definition, as listed in clause 12.7.1, and the various components of theASN.1 type defined above, is as follows:

a) the structuralObjectClass component identifies the structural object class to which the DIT content ruleapplies;

b) the auxiliaries component identifies the auxiliary object classes allowed for an entry to which the DITcontent rule applies;

c) the mandatory component specifies user attribute types which an entry to which the DIT content ruleapplies shall contain in addition to those which it shall contain according to its structural and auxiliaryobject classes.

d) the optional components specify user attribute types which an entry to which the DIT content rule appliesmay contain in addition to those which it may contain according to its structural and auxiliary objectclasses.

e) the precluded component specifies a subset of the optional user attribute types of the structural andauxiliary object classes which are precluded from an entry to which the DIT content rule applies.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 43

The CONTENT-RULE information object class is provided to facilitate the documentation of DIT content rules:

CONTENT-RULE ::= CLASS {&structuralClass OBJECT-CLASS.&id UNIQUE,&Auxiliaries OBJECT-CLASS OPTIONAL,&Mandatory ATTRIBUTE OPTIONAL,&Optional ATTRIBUTE OPTIONAL,&Precluded ATTRIBUTE OPTIONAL }

WITH SYNTAX {STRUCTURAL OBJECT-CLASS &structuralClass[ AUXILIARY OBJECT-CLASSES &Auxiliaries ][ MUST CONTAIN &Mandatory ][ MAY CONTAIN &Optional ][ MUST NOT CONTAIN &Precluded ] }

13 Directory System Schema13.1 Overview

The Directory System Schema is a set of definitions and constraints concerning the information that the Directoryitself needs to know in order to operate correctly. This information is specified in terms of subentries and operationalattributes.

Note — The system schema enables the directory system to, for example:

— prevent the association of subentries of the wrong type with administrative entries (e.g. the creation of a subschemasubentry subordinate to an administrative entry defined only as a security administrative entry.);

— prevent the addition of inappropriate operational attributes to an entry or subentry (e.g., a subschema operationalattribute to a person’s entry).

Formally, the Directory System Schema comprises a set of:

a) Object class definitions that define the attributes that shall or may be present in a subentry of a given class;

b) Operational Attribute Type definitions that specify the characteristics of operational attributes known andused by the Directory.

The complete definition of an operational attribute includes a specification of the way in which the Directory usesand (if appropriate) provides or manages, the attribute in the course of its operation.

The Directory System Schema is distributed, like the DIB itself. Each Administrative Authority establishes the partof the system schema that will apply for those portions of the DIB administered by the authority.

The Directory System Schema defined in this Directory Specification is an integral part of the Directory Systemitself. Each DSA participating in a directory system requires a full knowledge of the system schema established byits Administrative Authority. The system schema for an Administrative Area may be defined by the AdministrativeAuthority using the notation defined in clause 13 of this Directory Specification.

The Directory System Schema is not regulated by DIT structure or content rules. When an element of systemschema is defined, a specification of how it is used and where it appears in the DIT is provided.

Certain aspects of the directory system schema are specified in the following subclauses.

The directory system schema required to support directory distribution is specified in clauses 21 thorugh 24 of thisDirectory Specification.

13.2 System schema supporting the administrative and operational information model

Although subentry and subentryNameForm are specified using the notation of clause 12, subentries are notregulated by DIT structure or DIT content rules.

ISO/IEC 9594-2 : 1993(E)

44 ITU-T Rec. X.501 (1993 E)

13.2.1 The Subentry object class

The subentry object class is a structural object class and is defined as follows:

subentry OBJECT-CLASS ::= {SUBCLASS OF { top }KIND structuralMUST CONTAIN { commonName | subtreeSpecification }ID id-sc-subentry }

13.2.2 The Subentry name form

The subentryNameForm name form allows entries of class subentry to be named using the commonNameattribute:

subentryNameForm NAME-FORM ::= {NAMES subentryWITH ATTRIBUTES { commonName }ID id-nf-subentryNameForm}

No other name form shall be used for subentries.

13.2.3 The Subtree Specification operational attribute

The subtreeSpecification operational attribute, whose semantics are specified in clause 10, is defined as follows:

subtreeSpecification ATTRIBUTE ::= {WITH SYNTAX SubtreeSpecificationSINGLE VALUE TRUEUSAGE directoryOperationID id-oa-subtreeSpecification }

This attribute is present in all subentries.

13.3 System schema supporting the administrative model

The Administrative Model defined in clause 10 requires that administrative entries contain an administrativeRoleattribute to indicate that the associated administrative area is concerned with one or more administrative roles.

The administrativeRole operational attribute is specified as follows:

administrativeRole ATTRIBUTE ::= {WITH SYNTAX OBJECT-CLASS.&idEQUALITY MATCHING RULE objectIdentifierMatchUSAGE directoryOperationID id-oa-administrativeRole }

The values of this attribute defined by this standard are:

id-ar-autonomousAreaid-ar-accessControlSpecificAreaid-ar-accessControlInnerAreaid-ar-subschemaAdminSpecificAreaid-ar-collectiveAttributeSpecificAreaid-ar-collectiveAttributeInnerArea

The semantics of these values are defined in clause 11.

The administrativeRole operational attribute is also used to regulate the subentries permitted to be subordinate to anadministrative entry. A subentry not of a class permitted by the administrativeRole attribute may not be subordinateto the administrative entry.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 45

13.4 System schema supporting general administrative and operational requirements

13.4.1 Timestamps

The createTimestamp indicates the time that an entry was created:

createTimestamp ATTRIBUTE ::= {WITH SYNTAX GeneralizedTime

-- as per clause 34.3 b) or c) of CCITT Rec. X.208 | ISO/IEC 8824-1EQUALITY MATCHING RULE generalizedTimeMatchORDERING MATCHING RULE generalizedTimeOrderingMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE directoryOperationID id-oa-createTimestamp }

The modifyTimeStamp indicates the time that an entry was last modified:

modifyTimestamp ATTRIBUTE ::= {WITH SYNTAX GeneralizedTime

-- as per clause 34.3 b) or c) of CCITT Rec. X.208 | ISO/IEC 8824-1EQUALITY MATCHING RULE generalizedTimeMatchORDERING MATCHING RULE generalizedTimeOrderingMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE directoryOperationID id-oa-modifyTimestamp }

The generalizedTimeMatch and generalizedTimeOrderingMatch matching rules are defined in ITU-T Rec. X.521 |ISO/IEC 9594-6.

13.4.2 Entry Modifier operational attributes

The creatorsName operational attribute indicates the distinguished name of the Directory user that created an entry:

creatorsName ATTRIBUTE ::= {WITH SYNTAX DistinguishedNameEQUALITY MATCHING RULE distinguishedNameMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE directoryOperationID id-oa-creatorsName }

The modifiersName operational attribute indicates the distinguished name of the Directory user that last modifiedthe entry:

modifiersName ATTRIBUTE ::= {WITH SYNTAX DistinguishedNameEQUALITY MATCHING RULE distinguishedNameMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE directoryOperationID id-oa-modifiersName }

13.5 System schema supporting access control

13.5.1 Access control subentries

If a subentry contains prescriptive access control information, then its objectClass attribute shall contain the valueaccessControlSubentry:

accessControlSubentry OBJECT-CLASS ::= {KIND auxiliaryID id-sc-accessControlSubentry }

A subentry of this object class shall contain precisely one prescriptive ACI attribute of a type consistent with thevalue of the id-sc-accessControlScheme attribute of the corresponding access control specific point.

ISO/IEC 9594-2 : 1993(E)

46 ITU-T Rec. X.501 (1993 E)

13.6 System schema supporting the collective attribute model

Subentries supporting collective attribute specific or inner administrative areas are defined as follows:

collectiveAttributeSubentry OBJECT-CLASS ::= {KIND auxiliaryID id-sc-collectiveAttributeSubentry }

A subentry of this object class shall contain at least one collective attribute.

Collective attributes contained within a subentry of this object class are conceptually available for interrogation andfiltering at every entry within the scope of the subentry’s subtreeSpecification attribute, but are administered viathe subentry.

The collectiveExclusions operational attribute allows particular collective attributes to be excluded from an entry:

collectiveExclusions ATTRIBUTE ::= {WITH SYNTAX OBJECT IDENTIFIEREQUALITY MATCHING RULE objectIdentifierMatchUSAGE directoryOperationID id-oa-collectiveExclusions }

This attribute is optional for every entry.

The OBJECT IDENTIFIER value id-oa-excludeAllCollectiveAttributes may be used, by its presence as a value ofthe collectiveExclusions attribute, to exclude all collective attributes from an entry.

13.7 Maintenance of system schema

It is the responsibility of DSAs to maintain consistency of subentries and operational attributes with the systemschema. Inconsistency between various aspects of system schema, and between system schema and subentries andoperational attributes, shall not occur.

The Directory executes entry addition and modification procedures whenever a new subentry is added to the DIT oran existing subentry is modified. The Directory shall determine whether the proposed operation would violate thesystem schema; if it does the modification shall fail.

In particular, the Directory ensures that subentries added to the DIT are consistent with the values of theadministrativeRole attribute, that the attributes within the subentry are consistent with the values of the subentry’sobjectClass attribute.

The value of the administrativeRole attribute may be modified to permit classes of subentries to be subordinate tothe administrative entry that are not yet present. The value of the administrativeRole attribute shall not be modifiedso as to cause existing subentries to become inconsistent.

The Directory also ensures, where the values of operational attributes are provided by the Directory, that they arecorrect.

14 Directory schema administration14.1 Overview

The overall administration of the directory schema of the global DIT is realized through independent administrationof the subschemas of the autonomous administrative areas of the DIT Domains that constitute the global DIT.

Coordination of the administration of the directory schema at boundaries between DIT Domains is a subject forbilateral agreement between DMOs and is beyond the scope of this Directory Specification.

The subschema administrative capabilities defined in this clause for the purpose of managing a DIT domain include:

1) creation, deletion and modification of subschema subentries;

2) support of the publication mechanism for the purpose of permitting DSAs to include schema information inoperational binding protocol exchanges and DUAs to retrieve subschema information via DAP;

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 47

3) subschema regulation for the purpose of ensuring that any modify operations will be performed inaccordance with the applicable subschema specification.

14.2 Policy objects

A subschema policy object may be one of the following:

— a subschema administrative area;

— an object or alias entry within a subschema administrative area;

— a user attribute of such an object or alias entry.

An autonomous administrative area may be designated as a subschema specific administrative area in order toadminister the subschema. This shall be indicated by the presence of the value i d - o a-subschemaAdminSpecificArea in the associated administrative entry’s administrativeRole attribute (in addition tothe presence of the value id-oa-autonomousArea, and possibly other values).

Such an autonomous administrative area may be partitioned in order to deploy and administer the subschema of thespecific partitions. In this case, the administrative entries for each of the subschema specific administrative areas areindicated by the presence of the value id-oa-subschemaAdminSpecificArea in these entries’ administrativeRoleattributes.

14.3 Policy parameters

Subschema policy parameters are used to express the policies of the subschema Administrative Authority. Theseparameters, and the operational attributes used to represent them, are:

— a DIT structure parameter: used to define the structure of the subschema administrative area and to storeinformation about obsolete DIT structure rules which some entries may have identified as their governingDIT structure rule. This parameter is represented by the dITStructureRules and nameForms operationalattributes;

— a DIT content parameter: used to define the type of content of object and alias entries contained within thesubschema administrative area and to store information about obsolete DIT content rules which theDirectory may have used in determining the content of some entries. This parameter is represented by thedITContentRules , objectClasses and attributeTypes operational attributes;

— a matching capability parameter: used to define the matching capabilities supported by matching rules asapplied to the attributes types defined in a subschema administrative area. This parameter is represented bythe matchingRules and matchingRuleUse operational attributes.

A single subschema subentry is used by the subschema authority to administer the subschema for the subschemaadministrative area. For this purpose the subschema subentry contains the operational attributes representing thepolicy parameters used to express subschema policies.

The subschema subentry is specified as follows:

subschema OBJECT-CLASS ::= {KIND auxiliaryMAY CONTAIN {

dITStructureRules |nameForms |dITContentRules |objectClasses |attributeTypes |matchingRules |matchingRuleUse }

ID id-sc-subschema }

The operational attributes of the subschema subentry are defined in 14.7.

14.4 Policy procedures

There are two policy procedures associated with subschema administration:

— a subschema modification procedure;

— an entry modification procedure.

ISO/IEC 9594-2 : 1993(E)

48 ITU-T Rec. X.501 (1993 E)

14.5 Subschema modification procedures

A subschema authority may administer a subschema in a dynamic fashion, including making restrictive subschemamodifications. This may be accomplished by modifying the values of the subschema operational attributes, usingDirectory modify operations, effectively changing the subschema which is in force in the subschema administrativearea

Before the subschema authority extends the DIT structure or DIT content rules by adding a new rule, or by addingan auxiliary object class, or a mandatory or an optional attribute to an existing rule, the referenced schemainformation shall be described in the appropriate attribute in the subschema subentry. Name forms, object classes,attribute types and matching rules that are referenced (directly or indirectly) by a dITStructureRule ,dITContentRule or by a matchingRuleUse attribute shall not be removed from the subschema subentry.

The definition of information objects such as object classes, attribute types, matching rules and name forms whichhave been registered (i.e. assigned a name of type object identifier) are static and cannot be modified. Changes to thesemantics of such information objects requires the assignment of new object identifiers.

DIT structure and DIT content rules may be active or obsolete. Only active rules are used to regulate the the DIT.The identification and preservation of obsolete rules is an administrative convenience allowing location (andpossibly repair) of entries added under old rules that have since changed.

This obsolete mechanism shall be used where restrictive changes are made to DIT structure or DIT content rulescreating inconsistencies in the DIB, otherwise the appropriate active rule may be modified directly. The Directorypermits deletion of obsolete rules at any time.

Note— The obsolete mechanism provided in subschema operational attributes ensures that all entries with obsolete schema canbe identified and repaired before the obsolete subschema operational attribute is deleted.

It is the responsibility of the Subschema Administrative Authority to maintain consistency of entries with the activesubschema by means of the Directory abstract service, or by other local means. This may be done at the convenienceof the Subschema Administrative Authority. It is not defined when such an adjustment of inconsistent entries shouldbe done. However, deletion of obsolete rules prior to the location and repair of inconsistent entries will make thistask more difficult.

14.6 Entry addition and modification procedures

The Directory executes entry addition and modification procedures whenever a new entry is added to the DIT or anexisting entry is modified. The Directory must determine whether the proposed operation would violate a subschemapolicy.

In particular, the Directory shall ensure that entries added to the DIT are consistent with appropriate active DITstructure and DIT content rules.

The Directory shall allow interrogation of entries which are inconsistent with their active rules.

The Directory enforces active rules when requested to modify the DIB. If an entry is inconsistent with its active rule,a request to modify the entry shall be permitted if it repairs an existing inconsistency, or does not introduce a newinconsistency. A request which introduces a new inconsistency shall fail.

For any valid entry in a valid subschema administrative area, there can be only one most subordinate structuralobject class in the structural object class superclass chain. When an entry is added to the DIT, the Directorydetermines this most subordinate structural object class from the objectClass attribute values provided andpermanently associates it with the entry via the entry’s structuralObjectClass attribute.

When an entry is created, values of the objectClass attribute shall be provided so that the content of the entry isconsistent with the DIT content rule governing the entry. In particular, where a value of the objectClass attributeidentifies a particular object class having superclasses other than top , then values for all of these superclasses mustalso be provided. Otherwise the Directory operation creating the entry shall fail.

Directory users may subsequently add or delete values of the objectClass attribute for the auxiliary object classes ofan entry. The content of an entry shall remain consistent with the DIT content rule governing the entry following achange to the values of the objectClass attribute. In particular, where a value of the objectClass attribute identifiesa particular object class having superclasses other than top is added or deleted, then values for all of these

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 49

superclasses must also be added or deleted, except where such superclasses are also present in the superclass chainsassociated with other values not being added or deleted respectively.

14.7 Subschema policy attributes

The following subclauses specify the subschema policy operational attributes. These attributes are:

— present in the subschema subentry. The values of these attributes are administered via Directory modifyoperations using the distinguished name of the subschema subentry;

— available for interrogation in all entries governed by the subschema.

The ASN.1 parameterized type DirectoryString { ub-schema } , used in the following definitions, is defined in ITU-T Rec. X.521 | ISO/IEC 9594-6.

The integerFirstComponentMatch and objectIdentifierFirstComponentMatch equality matching rules are alsodefined in ITU-T Rec. X.521 | ISO/IEC 9594-6.

For management purposes, a number of human readable name components and a description component areoptionally allowed as components of a number of the subschema policy operational attributes defined in thefollowing clauses.

A number of subschema policy operational attributes defined in the following clauses contain an obsoletecomponent. This component is used to indicate whether the definition is active or obsolete in the subschemaadministrative area.

14.7.1 DIT Structure Rules operational attribute

The dITStructureRules operational attribute defines the DIT structure rules which are in force within a subschema:

dITStructureRules ATTRIBUTE ::= {WITH SYNTAX DITStructureRuleDescriptionEQUALITY MATCHING RULE integerFirstComponentMatchUSAGE directoryOperationID id-soa-dITStructureRule }

DITStructureRuleDescription ::= SEQUENCE {COMPONENTS OF DITStructureRule,name [1] SET OF DirectoryString { ub-schema } OPTIONAL,description DirectoryString { ub-schema } OPTIONAL,obsolete BOOLEAN DEFAULT FALSE }

The dITStructureRules operational attribute is multi-valued; each value defines one DIT structure rule.

The components of dITStructureRule have the same semantics as the corresponding ASN.1 definition in 12.6.6.

14.7.2 DIT Content Rules operational attribute

The dITContentRules operational attribute defines the DIT content rules which are in force within a subschema.Each value of the operational attribute is tagged by the object identifier of the structural object class to which itpertains:

dITContentRules ATTRIBUTE ::= {WITH SYNTAX DITContentRuleDescriptionEQUALITY MATCHING RULE objectIdentifierFirstComponentMatchUSAGE directoryOperationID id-soa-dITContentRules }

DITContentRuleDescription ::= SEQUENCE {COMPONENTS OF DITContentRule,name [4] SET OF DirectoryString { ub-schema } OPTIONAL,description DirectoryString { ub-schema }OPTIONAL,obsolete BOOLEAN DEFAULT FALSE}

The dITContentRules operational attribute is multi-valued; each value defines one DIT content rule.

The components of dITContentRule have the same semantics as the corresponding ASN.1 definition in 12.7.2.

ISO/IEC 9594-2 : 1993(E)

50 ITU-T Rec. X.501 (1993 E)

14.7.3 Matching Rules operational attribute

The matchingRules operational attribute specifies the matching rules used within a subschema:

matchingRules ATTRIBUTE ::= {WITH SYNTAX MatchingRuleDescriptionEQUALITY MATCHING RULE objectIdentifierFirstComponentMatchUSAGE directoryOperationID id-soa-matchingRules }

MatchingRuleDescription ::= SEQUENCE {identifier MATCHING-RULE.&id,name SET OF DirectoryString { ub-schema } OPTIONAL,description DirectoryString { ub-schema } OPTIONAL,obsolete BOOLEAN DEFAULT FALSE,information [0] DirectoryString { ub-schema } }

-- describes the ASN.1 syntax

The identifier component of a value of the matchingRules attribute is the object identifier identifying the matchingrule.

The information component contains the ASN.1 definition of the attribute syntaxes to which the matching ruleapplies, and a natural language description of the algorithms associated with the rule.

The matchingRules operational attribute is multi-valued; each value describes one matching rule.

14.7.4 Attribute Types operational attribute

The attributeTypes operational attribute specifies the attribute types used within a subschema:

attributeTypes ATTRIBUTE ::= {WITH SYNTAX AttributeTypeDescriptionEQUALITY MATCHING RULE objectIdentifierFirstComponentMatchUSAGE directoryOperationID id-soa-attributeTypes }

AttributeTypeDescription ::= SEQUENCE {identifier ATTRIBUTE.&id,name SET OF DirectoryString { ub-schema } OPTIONAL,description DirectoryString { ub-schema } OPTIONAL,obsolete BOOLEAN DEFAULT FALSE,information [0] AttributeTypeInformation }

The identifier component of a value of the attributeTypes attribute is the object identifier identifying the attributetype.

The attributeTypes operational attribute is multi-valued; each value describes one attribute type:

AttributeTypeInformation ::= SEQUENCE {derivation [0] ATTRIBUTE.&id OPTIONAL,equalityMatch [1] MATCHING-RULE.&id OPTIONAL,orderingMatch [2] MATCHING-RULE.&id OPTIONAL,substringsMatch [3] MATCHING-RULE.&id OPTIONAL,attributeSyntax [4] DirectoryString { ub-schema } OPTIONAL,multi-valued [5] BOOLEAN DEFAULT TRUE,collective [6] BOOLEAN DEFAULT FALSE,userModifiable [7] BOOLEAN DEFAULT TRUE,application AttributeUsage OPTIONAL }

The derivation , equalityMatch , attributeSyntax, multi-valued , collective and application components have thesame semantic as the equivalent pieces of notation introduced by the corresponding information object class.

Note — The data type of the type reference is identified by a text string. Identifying the data type in a machine processableform is for further study.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 51

14.7.5 Object Classes operational attribute

The objectClasses operational attribute specifies the object classes used within a subschema.

objectClasses ATTRIBUTE ::= {WITH SYNTAX ObjectClassDescriptionEQUALITY MATCHING RULE objectIdentifierFirstComponentMatchUSAGE directoryOperationID id-soa-objectClasses }

ObjectClassDescription ::= SEQUENCE {identifier OBJECT-CLASS.&id,name SET OF DirectoryString { ub-schema } OPTIONAL,description DirectoryString { ub-schema } OPTIONAL,obsolete BOOLEAN DEFAULT FALSE,information [0] ObjectClassInformation }

The identifier component of a value of the objectClasses attribute is the object identifier identifying the objectclass.

The objectClasses operational attribute is multi-valued; each value describes one object class:

ObjectClassInformation ::= SEQUENCE {subclassOf SET OF OBJECT-CLASS.&id OPTIONAL,kind ObjectClassKind DEFAULT structural,mandatories [3] SET OF ATTRIBUTE.&id OPTIONAL,optionals [4] SET OF ATTRIBUTE.&id OPTIONAL }

The subclassOf, kind , mandatories and optionals components have the same semantics as the correspondingpieces of notation introduced by the corresponding information object class.

14.7.6 Name Forms operational attribute

The nameForms operational attribute specifies the name forms used within a subschema.

nameForms ATTRIBUTE ::= {WITH SYNTAX NameFormDescriptionEQUALITY MATCHING RULE objectIdentifierFirstComponentMatchUSAGE directoryOperationID id-soa-nameForms }

NameFormDescription ::= SEQUENCE {identifier NAME-FORM.&id,name SET OF DirectoryString { ub-schema } OPTIONAL,description DirectoryString { ub-schema } OPTIONAL,obsolete BOOLEAN DEFAULT FALSE,information [0] NameFormInformation }

The identifier component of a value of the nameForms attribute is the object identifier identifying the object class.

The nameForms operational attribute is multi-valued; each value describes one name form :

NameFormInformation ::= SEQUENCE {subordinate OBJECT-CLASS.&id,namingMandatories SET OF ATTRIBUTE.&id,namingOptionals SET OF ATTRIBUTE.&id OPTIONAL }

The subordinate , mandatoryNamingAttributes and optionalNamingAttributes components have the samesemantics as the corresponding pieces of notation introduced by the corresponding information object class.

14.7.7 Matching Rule Use operational attribute

The matchingRuleUse operational attribute is used to indicate the attribute types to which a matching rule appliesin a subschema:

matchingRuleUse ATTRIBUTE ::= {WITH SYNTAX MatchingRuleUseDescriptionEQUALITY MATCHING RULE objectIdentifierFirstComponentMatchUSAGE directoryOperationID id-soa-matchingRuleUse }

ISO/IEC 9594-2 : 1993(E)

52 ITU-T Rec. X.501 (1993 E)

MatchingRuleUseDescription ::= SEQUENCE {identifier MATCHING-RULE.&id,name SET OF DirectoryString { ub-schema } OPTIONAL,description DirectoryString { ub-schema } OPTIONAL,obsolete BOOLEAN DEFAULT FALSE,information [0] SET OF ATTRIBUTE.&id }

The identifier component of a value of the matchingRulesUse attribute is the object identifier identifying thematching rule.

The information component of a value identifies the set of attribute types to which the matching rule applies.

14.7.8 Structural Object Class operational attribute

Every entry in the DIT has a structuralObjectClass operational attribute which indicates the structural object classof the entry:

structuralObjectClass ATTRIBUTE ::= {WITH SYNTAX OBJECT IDENTIFIEREQUALITY MATCHING RULE objectIdentifierMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE directoryOperationID id-soa-structuralObjectClass }

14.7.9 Governing Structure Rule operational attribute

Every entry in the DIT has a governingStructureRule operational attribute which indicates the governing structurerule of the entry:

governingStructureRule ATTRIBUTE ::= {WITH SYNTAX INTEGEREQUALITY MATCHING RULE integerMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE directoryOperationID id-soa-governingStructureRule }

SECTION 7: SECURITY

15 Security model15.1 Definitions

This Directory Specification makes use of the following terms defined in CCITT Rec. X.200 and ISO/IEC 7498-2:

— access control;

— authentication;

— security policy.

The following terms are defined in this Directory Specification:

— access control scheme: The means by which access to Directory information and potentially to access rightsthemselves may be controlled;

— protected item : An element of Directory information to which access can be separately controlled. Theprotected items of the Directory are entries, attributes, attribute values, and names.

15.2 Security policies

The Directory exists in an environment where various administrative authorities control access to their portion ofthe DIB. Such access is generally in conformance with some administration controlled security policy (see ITU-TRec. X.509 | ISO/IEC 9594-8).

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 53

Two aspects or components of the security policy which effect access to the Directory are the authenticationprocedures and the access control scheme.

Note — Clause 16 defines two access control schemes known as Basic Access Control and Simplified AccessControl. These schemes may be used in conjunction with local administrative controls; however, since localadministrative policy has no standardized representation, it cannot be communicated in shadowed information.

15.2.1 Authentication procedures and mechanisms

Authentication procedures and mechanisms in the context of the Directory include the methods to verify andpropagate where necessary:

— the identity of DSAs and Directory users;

— the identity of the origin of information received at an access point.

Note — The administrative authority may stipulate different provisions for the authentication of administrative users ascompared to provisions for the authentication of non-administrative users.

General-use authentication procedures are defined in ITU-T Rec. X.509 | ISO/IEC 9594-8 and can be used inconjunction with the access control schemes defined in this Directory Specification to enforce security policy.

Notes

1 Future editions of the Directory Specifications may define other access control schemes.

2 Local administrative policy may stipulate that authentication taking place in certain other DSAs (e.g., DSAs in otherDMDs) is to be disregarded.

In general, there will be a mapping function from the authenticated identity (e.g., human user identity asauthenticated by an authentication exchange) to the access control identity (e.g., the distinguished name of an entry,together with an optional unique identifier, representing the user). This mapping does not fall within the scope ofthis Directory Specification. However, a particular security policy may state that the authenticated identity and theaccess control identity are the same.

15.2.2 Access control scheme

The definition of an access control scheme in the context of the Directory includes methods to:

— specify access control information (ACI);

— enforce access rights defined by that access control information;

— maintain access control information.

The enforcement of access rights applies to controlling access to:

— Directory information related to names;

— Directory user information;

— Directory operational information including access control information.

Administrative authorities may make use of all or parts of any standardized access control scheme in implementingtheir security policies, or may freely define their own schemes at their discretion.

However, administrative authorities may stipulate separate provisions for the protection of some or all of theDirectory operational information. Administrative authorities are not required to provide ordinary users with themeans to detect provisions for the protection of operational information.

Note — Administrative policy may grant or deny any form of access to particular attributes (e.g., operational attributes)irrespective of access controls which may otherwise apply.

The Directory provides a means for the access control scheme in force in a particular portion of the DIB to beidentified through the use of the operational attribute accessControlScheme. The scope of such a scheme isdefined by an Access Control Specific Area (ACSA), which is a specific administrative area that is theresponsibility of the corresponding Security Authority. This attribute is placed in the Administrative Entry for thecorresponding Administrative Point. Only administrative entries for Access Control Specific Points are allowed tocontain an accessControlScheme attribute.

ISO/IEC 9594-2 : 1993(E)

54 ITU-T Rec. X.501 (1993 E)

Note — If this operational attribute is missing with respect to access to a given entry, then the DSA shall behave as for a1988 edition DSA (i.e., it is a local matter to determine an access control mechanism and its effect on operations, results, anderrors).

accessControlScheme ATTRIBUTE ::= {WITH SYNTAX OBJECT IDENTIFIEREQUALITY MATCHING RULE objectIdentifierMatchSINGLE VALUE TRUEUSAGE directoryOperationID id-aca-accessControlScheme }

Any subentry or entry in an ACSA is permitted to contain entry ACI if and only if such ACI is permitted andconsistent with the value of the accessControlScheme attribute of the corresponding ACSA.

16 Basic Access Control16.1 Scope and application

This clause defines one specific access control scheme (of possibly many) for the Directory. The access controlscheme defined herein is identified with the accessControlScheme operational attribute by giving it the valuebasic-access-control . 15.2.2 describes which entries contain the accessControlScheme operational attribute.

Note — Another access control scheme known as “Simplified Access Control”.is specified in 16.9. It is defined as a subsetof the Basic Access Control scheme scheme. When Simplified Access Control is used, the accessControlSchemeoperational attribute shall have the value simplified-access-control.

The scheme defined here is only concerned with providing means of controlling access to the Directory informationwithin the DIB (potentially including tree structure and access control information). It does not address controllingaccess for the purpose of communication with a DSA application-entity. Control of access to information means theprevention of unauthorized detection, disclosure, or modification of that information.

16.2 Basic Access Control model

The Basic Access Control model for the Directory defines, for every Directory operation, one or more points atwhich access control decisions take place. Each access control decision involves:

— that element of Directory information being accessed, called the protected item;

— the user requesting the operation, called the requestor;

— a particular right necessary to complete a portion of the operation, called the permission ;

— one or more operational attributes that collectively contain the security policy governing access to that item,called ACI items .

Thus, the basic access control model defines:

— the protected items;

— the user classes;

— the permission categories required to perform each Directory operation;

— the scope of application and syntax of ACI items;

— the basic algorithm, called the Access Control Decision Function (ACDF), used to decide whether aparticular requestor has a particular permission by virtue of applicable ACI items.

16.2.1 Protected items

A protected item is an element of Directory information to which access can be separately controlled. The protecteditems of the Directory are entries, attributes, attribute values, and names. For convenience in specifying accesscontrol policies, Basic Access Control provides the means to identify collections of related items, such as attributesin an entry or all attribute values of a given attribute, and to specify a common protection for them.

16.2.2 Access control permissions and their scope

Access is controlled by granting or denying permissions. The permission categories are described in 16.2.3 and16.2.4.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 55

The scope of access controls can be a single entry or a collection of entries that are logically related by being withinthe scope of a subentry for a particular administrative point.

Permission categories are generally independent. Since all Directory entries have a relative position within the DIT,access to user and operational information always involves some form of access to DIT related information. Thus,there are two main forms of access control decision associated with a Directory operation: access to entries as namedobjects (referred to as entry access); and access to attributes containing user and operational information (referred toas attribute access ). For many Directory operations, both forms of permission are required. In addition, whereapplicable, separate permissions control the name or error type returned. Some important aspects of permissionscategories, forms of access, and access control decision making are as follows:

a) to perform Directory operations on entire entries (e.g., read an entry or add an entry), it is usually necessaryfor permission to be granted with respect to the attributes and values contained within that entry.Exceptions are permissions controlling entry renaming and removal: in neither case is attribute or attributevalue permissions taken into account;

b) to perform Directory operations that require access to attributes or attribute values, it is necessary to haveentry access permission to the entry or entries that contain those attributes or values;

Note — The removal of an entry or of an attribute does not require access to the contents of the entry or of theattribute;

c) the decision whether or not to permit entry access is strictly determined by the position of the entry in theDIT, in terms of its distinguished name, and is independent of how the Directory locates that entry;

d) a design principle of Basic Access Control is that access may be allowed only when there is an explicitlyprovided grant present in the access control information used by the Directory to make the access controldecision. Granting one form of access (e.g., entry access) never automatically or implicitly grants the otherform (e.g., attribute access). In order to administer meaningful Directory access control policies, it is thususually necessary to explicitly set access policy for both forms of access

Notes

1 Certain combinations of grants or denials are illogical, but it is the responsibility of users, rather than theDirectory, to ensure that such combinations are absent.

2 Consistent with the above design principle, granting or denying permissions for an attribute value does notautomatically control access to the related attribute. Moreover, in order to access an attribute value(s) in the course ofa Directory interrogation operation, a user must be granted access to both the attribute type and its value(s);

e) the only default access decision provided in the model is to deny access in the absence of explicit accesscontrol information that grants access;

f) a denial specified in access control information always overrides a grant, all other factors being equal;

g) a particular DSA may not have the access control information governing the Directory data it caches.Security Administrators should be aware that a DSA with the capability of caching may pose a significantsecurity risk to other DSAs, in that it may reveal information to unauthorized users;

h) for the purposes of interrogation, collective attributes that are associated with an entry are protectedprecisely as if they were attributes part of the entry.

Note — For the purposes of modification, collective attributes are associated with the subentry that holds them, notwith entries within the scope of the subentry. Modify–related access controls are therefore not relevant to collectiveattributes, except when they apply to the collective attribute and its values within the subentry.

16.2.3 Permission categories for entry access

The permission categories used to control entry access are Read , Browse , Add , Remove, Modify , Rename,DiscloseOnError, Export, and Import and ReturnDN. Their use is described in more detail in ITU-T Rec. X.511 |ISO/IEC 9594-3. Annex K of this Directory Specification provides an overview of their meaning in generalsituations. This clause introduces the categories by briefly indicating the intent associated with the granting of each.The actual influence of a particular granted permission on access control decisions must, however, be understood inthe full context of the ACDF and access control decision points for each Directory operation.

a) Read , if granted, permits read access for Directory operations which specifically name an entry (i.e., asopposed to the List and Search operations) and provides visibility to the information contained in the entryto which it applies;

b) Browse , if granted, permits entries to be accessed using Directory operations which do not explicitlyprovide the name of the entry;

ISO/IEC 9594-2 : 1993(E)

56 ITU-T Rec. X.501 (1993 E)

c) Add, if granted, permits creation of an entry in the DIT subject to controls on all attributes and attributevalues to be placed in the new entry at time of creation;

Notes

1 In order to add an entry, permission must also be granted to add at least the mandatory attributes and their values.

2 There is no specific “add subordinate permission”. Permission to add an entry is controlled usingprescriptiveACI operational attributes as described in clause 16.3;

d) Remove , if granted, permits the entry to be removed from the DIT regardless of controls on attributes orattribute values within the entry;

e) Modify, if granted, permits the information contained within an entry to be modified.

Note — In order to modify information contained within an entry other than the distinguished name attribute values,appropriate attribute and value permissions must also be granted;

f) Granting Rename is necessary for an entry to be renamed with a new RDN, taking into account theconsequential changes to the distinguished names of subordinate entries, if any; if the name of the superioris unchanged, the grant is sufficient;

Note — In order to rename an entry, there are no prerequisite permissions to contained attributes or values, includingthe RDN attributes; this is true even when the operation causes new attribute values to be added or removed as aresult of the changes of RDN;

g) DiscloseOnError, if granted, permits the name of an entry to be disclosed in an error (or empty) result;

h) Export, if granted, permits an entry and its subordinates (if any) to be exported; that is, removed from thecurrent location and placed in a new location subject to the granting of suitable permissions at thedestination. If the last RDN is changed, Rename is also required at the current location.

Note — In order to export an entry or its subordinates, there are no prerequisite permissions to contained attributes orvalues, including the RDN attributes; this is true even when the operation causes attribute values to be added orremoved as a result of the changes of RDN;

i) Import, if granted, permits an entry and its subordinates, if any, to be imported; that is, removed from someother location and placed at the location to which the permission applies (subject to the granting of suitablepermissions at the source location).

Note — In order to import an entry or its subordinates, there are no prerequisite permissions to contained attributesor values, including the RDN attributes; this is true even when the operation causes attribute values to be added orremoved as a result of the changes of RDN;

j) ReturnDN, if granted, allows the distinguished name of the entry to be disclosed in an operation result.

16.2.4 Permission categories for attribute and attribute value access

The permission categories used to control attribute and attribute value access are Compare, Read, FilterMatch , Add,Remove , and DiscloseOnError . They are described in more detail in ITU-T Rec. X.511 | ISO/IEC 9594-3. Annex Kof this Directory Specification provides an overview of their meaning in general situations. This clause introducesthe categories by briefly indicating the intent associated with the granting of each. The actual influence of aparticular granted permission on access control decisions must, however, be understood in the full context of theACDF and access control decision points for each Directory operation.

a) Compare, if granted, permits attributes and values to be used in a compare operation;

b) Read , if granted, permits attributes and values to be returned as entry information in a read or search accessoperation;

c) FilterMatch, if granted, permits evaluation of a filter within a search criterion ;

d) Add, if granted for an attribute, permits adding an attribute subject to being able to add all specifiedattribute values. If granted for an attribute value, it permits adding a value to an existing attribute;

e) Remove , if granted for an attribute, permits removing an attribute complete with all of its values. If grantedfor an attribute value, it permits the attribute value to be removed from an existing attribute;

f) DiscloseOnError, if granted for an attribute, permits the presence of the attribute to be disclosed by anattribute or security error. If granted for an attribute value, it permits the presence of the attribute value tobe disclosed by an attribute or security error.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 57

16.3 Access control administrative areas

The DIT is partitioned into subtrees termed autonomous administrative areas, each of which is under theadministrative authority of a single Domain Management Organization. It may be further partitioned into subtreestermed specific administrative areas for the purposes of specific aspects of administration; alternatively, the wholeof an autonomous administrative area may comprise a single specific administrative area. Each such specificadministrative area is the responsibility of a corresponding specific administrative authority. A particularadministrative area may be shared by several specific administrative authorities. See clause 10.

16.3.1 Access control areas and Directory Access Control Domains

In the case of access control, the specific administrative authority is a Security Authority, and the specificadministrative area is termed an Access Control Specific Area (ACSA). The root of the ACSA is termed an AccessControl Specific Point. Each Access Control Specific Point is represented in the DIT by an Administrative Entrywhich includes access-control-specific-area as a value of its administrativeRole operational attribute; it has(potentially) one or more subentries which contain access control information. Similarly, each Access Control InnerPoint is represented in the DIT by an Administrative Entry which contains access-control-inner-area as a value ofits administrativeRole operational attribute; it also has (potentially) one or more subentries which contain accesscontrol information. Each such administrative entry which has a subentry containing prescriptive ACI informationhas basic-access-control, simplified-access-control, or other relevant value as a value of itsaccessControlScheme operational attribute. Each subentry that is an Access Control Specific Point and whichcontains access control information, has accessControlSubentry as a value of its object-class attribute. Anadministrative entry and its subentries may hold operational attributes (such as access control information) whichrelate, respectively, to the administrative point (and possibly its subentries) and to collections of entries (within theadministrative area) defined by the subentry subtreeSpecification.

The accessControlScheme attribute shall be present if and only if the holding administrative entry is an accesscontrol specific entry. An administrative entry can never be both an access control specific and an access controlinner entry; corresponding values can therefore never be present simultaneously in the administrativeRole attribute.

The scope of a subentry that contains access control information, as defined by its subtreeSpecification (whichmay include subtree refinements), is termed a Directory Access Control Domain (DACD).

Note — A DACD can contain zero entries, and can encompass entries that have not yet been added to the DIT.

The Security Authority may permit an Access Control Specific Area to be partitioned into subtrees termed inner(administrative) areas. Each such inner area is termed an Access Control Inner Area (ACIA) with access-control-inner-area as the value of the administrativeRole operational attribute. Each subentry of the correspondingadministrative point that contains prescriptive ACI has, as before, an accessControlSubentry value within itsobject class attribute.

The scope (subtreeSpecification ) specified in a subentry within an ACIA is also a DACD and contains entriesinside the associated Access Control Inner Area.

ACIAs allow a degree of delegation of access control authority within the ACSA. The authority for the ACSA stillretains authority within the ACIA since the ACI in the subentries of the ACSA’s administrative point apply as wellas the ACI in the subentries of the relevant ACIAs (clause 16.6 explains how the ACSA controls authority).

In summary, in evaluating access controls, the type of access control scheme (e.g., Basic Access Control) isindicated by the accessControlScheme attribute value of the relevant access control specific entry; the role of eachrelevant administrative entry within the ACSA is indicated by its administrativeRole attribute values; the presenceof prescriptive access control in a particular subentry is indicated by an accessControlSubentry value in its objectclass attribute.

Subentries, like other entries, can hold an entryACI attribute for protection of its own contents.

16.3.2 Associating controls with administrative areas

Access to a given entry is (potentially) controlled by the totality of superior access control administrative points(both inner and specific) up to and including the first non-inner access control administrative point or AutonomousAdministrative Point encountered moving up the DIT from the entry towards the root. Access Control SpecificPoints superior to this access control administrative point have no effect on access control to the given entry.

ISO/IEC 9594-2 : 1993(E)

58 ITU-T Rec. X.501 (1993 E)

Note — An Autonomous Administrative Point is considered implicitly to be an Access Control Specific Point for thepurpose of this description, even if it is not associated with any prescriptive controls.

Some important points regarding the association between access controls and administrative areas are:

a) access controls for Directory information may apply to only selected entries, or may have scope extendingthroughout portions of the DIB that are logically related by a common security policy and a commonAccess Control administration;

b) access control may be imposed on entries within ACSAs or within ACIAs by placing prescriptiveACIattributes (see clause 16.5) within one or more subentries of the corresponding Access ControlAdministrative Entry, with scope defined by an appropriate subtreeSpecification .

Note — prescriptiveACI attributes are not collective attributes. There are a number of significant differencesbetween prescriptiveACI and collective attributes:

— although a prescriptiveACI attribute may affect access control decisions for each entry within the scope ofthe subentry that holds it, the prescriptiveACI attribute is not considered to supply accessible information toany such entry or to be in any sense a part of such an entry;

— prescriptiveACI attributes are associated with the access control aspects of administration, and areassociated with Access Control Specific and Inner Points, not with entry-collection administrative points;

— The purpose of a prescriptiveACI attribute is to express a policy that influences across a defined set ofentries, while the purpose of a collective attribute is to provide information that associates a user–accessibleset of attributes within a defined set of entries;

— prescriptiveACI attributes represent policy information that will, in general, not be widely accessible byordinary users. Administrative users who need to access prescriptiveACI information can access them asoperational attributes within subentries;

c) a prescriptiveACI operational attribute contains ACIItems (see clause 16.4.1) common to all entries withinthe scope of the subentry, i.e., DACD, in which the prescriptiveACI occurs. A DACD normally containsentries inside the associated Access Control Specific Area (but can contain no entries at all);

d) although particular ACIItems may specify attributes or values as protected items, ACIItems are logicallyassociated with entries. The particular set of ACIItems associated with an entry is a combination of:

— ACIItems that apply to that particular entry, specified as values of the entryACI operational attribute,if present (see clause 16.5.2);

— ACIItems from prescriptiveACI operational attributes applicable to the entry by virtue of beingplaced in subentries of administrative entries whose scope includes the particular entry (see clause16.5.1);

e) each entry (controlled by entryACI and/or prescriptiveACI) necessarily falls within one and only oneACSA. Each such entry may also fall within one or more ACIAs nested inside the ACSA containing theentry. The prescriptiveACI that potentially affects the outcome of access control decisions for a givenentry are located within subentries (of the administrative entry) for the ACSA and for each ACIAcontaining the entry. Other subentries cannot affect access control decisions regarding that entry;

f) if an entry is within the scope of more than one DACD, the complete set of ACIItems that may potentiallyaffect access control decisions regarding that entry includes all prescriptiveACI item attributes of thoseDACDs, in addition to any entryACI attributes in the entry itself. An example is shown in Figure 11. Theeffective access control at entry E1 is a combination of the prescriptiveACI for DACD1, DACD2,DACD3, and entryACI (if present) in entry E1. The effective access control at entry E2 is a combinationof the prescriptiveACI for DACD1 and DACD3, and entryACI (if present) in entry E2.

Note — Protection of access control information is described in 16.6.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 59

DACD-3

E1

E2

DACD-1

DACD-2

Figure 11 — Effective Access Control using DACDs

g) the subtreeSpecification attribute in each subentry defines a collection of entries within an administrativearea. Since a subtreeSpecification may define a subtree refinement, DACDs may arbitrarily overlap withinthe intersection of their respective administrative areas. For simplicity, Figure 11 does not showadministrative points, subentries, or administrative areas; however, it may be considered as three DACDs inthe same ACSA with each DACD corresponding to a single subentry of the administrative point for thatACSA (and there are no ACIAs). Alternatively, Figure 11 may be considered in the context of a singleACSA containing a single ACIA where DACD1 is congruent to the ACSA and DACD3 is congruent to theACIA (DACD1 and DACD2 would correspond to subentries of the ACSA administrative point andDACD3 would correspond to a subentry of the ACIA administrative point). An administrative area iscongruent to a DACD when the collection of entries in the DACD is the same as the collection of entries inthe implicitly defined subtree corresponding to the administrative area. See the example in Annex L forfigures depicting the relationship between administrative entries, administrative areas, subentries, andDACDs.

16.4 Representation of Access Control Information

16.4.1 ASN.1 for Access Control Information

Access Control Information is represented as a set of ACIItems, where each ACIItem grants or denies permissionsin regard to certain specified users and protected items.

In ASN.1 the information is expressed as:

ACIItem ::= SEQUENCE {identificationTag DirectoryString { ub-tag },precedence Precedence,authenticationLevel AuthenticationLevel,itemOrUserFirst CHOICE {

itemFirst [0] SEQUENCE {protectedItems ProtectedItems,itemPermissions SET OF ItemPermission },

userFirst [1] SEQUENCE {userClasses UserClasses,userPermissions SET OF UserPermission }}}

Precedence ::= INTEGER (0..255)

ISO/IEC 9594-2 : 1993(E)

60 ITU-T Rec. X.501 (1993 E)

ProtectedItems ::= SEQUENCE {entry [0] NULL OPTIONAL,allUserAttributeTypes [1] NULL OPTIONAL,attributeType [2] SET OF AttributeType OPTIONAL,allAttributeValues [3] SET OF AttributeType OPTIONAL,allUserAttributeTypesAndValues [4] NULL OPTIONAL,attributeValue [5] SET OF AttributeTypeAndValue OPTIONAL,selfValue [6] SET OF AttributeType OPTIONAL }

UserClasses ::= SEQUENCE {allUsers [0] NULL OPTIONAL,thisEntry [1] NULL OPTIONAL,name [2] SET OF NameAndOptionalUID OPTIONAL,userGroup [3] SET OF NameAndOptionalUID OPTIONAL,

-- dn component must be the name of an-- entry of GroupOfUniqueNames

subtree [4] SET OF SubtreeSpecification OPTIONAL}

ItemPermission ::= SEQUENCE {precedence Precedence OPTIONAL,

-- defaults to precedence in ACIItem --userClasses UserClasses,grantsAndDenials GrantsAndDenials }

UserPermission ::= SEQUENCE {precedence Precedence OPTIONAL,

-- defaults to precedence in ACIItemprotectedItems ProtectedItems,grantsAndDenials GrantsAndDenials }

AuthenticationLevel ::= CHOICE {basicLevels SEQUENCE {

level ENUMERATED { none (0), simple (1), strong (2) },localQualifier INTEGER OPTIONAL},

other EXTERNAL }

GrantsAndDenials ::= BIT STRING {-- permissions that may be used in conjunction with-- with any component of ProtectedItemsgrantAdd (0),denyAdd (1),grantDiscloseOnError (2),denyDiscloseOnError (3),grantRead (4),denyRead (5),grantRemove (6),denyRemove (7),-- permissions that may be used only in conjunction-- with the entry componentgrantBrowse (8),denyBrowse (9),grantExport (10),denyExport (11),grantImport (12),denyImport (13),grantModify (14),denyModify (15),grantRename (16),denyRename (17),grantReturnDN (18),denyReturnDN (19),-- permissions that may be used in conjunction-- with any component, except entry, of ProtectedItemsgrantCompare (20),denyCompare (21),grantFilterMatch (22),denyFilterMatch (23) }

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 61

16.4.2 Description of ACIItem Parameters

16.4.2.1 IdentificationTag

identificationTag is used to identify a particular ACIItem . This is used to discriminate among individualACIItems for the purposes of protection, management, and administration.

16.4.2.2 Precedence

Precedence is used to control the relative order in which ACIItems are considered during the course of making anaccess control decision in accordance with clause 16.8. ACIItems having higher precedence values may prevailover others with lower precedence values, other factors being equal. Precedence values are integers and arecompared as such.

Precedence can be used by a superior authority within the Security Authority to permit partial delegation of accesscontrol policy setting within an ACSA. This can be achieved by the superior authority setting a general policy at ahigh precedence and authorizing users representing the subordinate authority (e.g., associated with an ACIA) tocreate and modify ACI with a lower precedence, in order to tailor the general policy for specific purposes. Thepartial delegation thus requires the means for the superior authority to limit the maximum precedence which thesubordinate authority can assign to ACI under its control.

Basic Access Control does not specify or describe how to limit the maximum precedence that can be used by asubordinate authority. This must be done by local means.

16.4.2.3 AuthenticationLevel

AuthenticationLevel defines the minimum requestor authentication level required for this ACIItem. It has twoforms:

— basicLevels which indicates the level of authentication, optionally qualified by positive or negative integerlocalQualifier ;

— other – an externally defined measure.

When basicLevels is used, an AuthenticationLevel consisting of a level and optional localQualifier shall beassigned to the requestor by the DSA according to local policy. For a requestor’s authentication level to exceed aminimum requirement, the requestor’s level must meet or exceed that specified in the ACIItem , and in addition therequestor’s localQualifier must be arithmetically greater than or equal to that of the ACIItem . Strong authenticationof the requestor is considered to exceed a requirement for simple or no authentication, and simple authenticationexceeds a requirement for no authentication. For access control purposes, the “simple” authentication level requiresa password; the case of identification only, with no password supplied, is considered “none”. If a localQualifier isnot specified in the ACIItem , then the requestor need not have a corresponding value (if such a value is present it isignored).

When other is used, an appropriate AuthenticationLevel shall be assigned to the requestor by the DSA accordingto local policy. The form of this AuthenticationLevel and the method by which it is compared with theAuthenticationLevel in the ACI is a local matter.

Notes

1 An authentication level associated with an explicit denial indicates the minimum level to which a requestor must beauthenticated in order not to be denied access. For example, an ACIItem that denies access to a particular user class andrequires strong authentication will deny access to all requestors who cannot prove, by means of a strongly authenticatedidentity, that they are not in that user class.

2 The DSA may base authentication level on factors other than values received in protocol exchanges.

16.4.2.4 itemFirst and userFirst Parameters

Each ACIItem contains a choice of itemFirst or userFirst . The choice allows grouping of permissions dependingon whether they are most conveniently grouped by user classes or by protected items. itemFirst and userFirst areequivalent in the sense that they capture the same access control information; however they organize thatinformation differently. The choice between them is based on administrative convenience. The parameters used initemFirst or userFirst are described below.

a) ProtectedItems define the items to which the specified access controls apply. It is defined as a set selectedfrom the following:

ISO/IEC 9594-2 : 1993(E)

62 ITU-T Rec. X.501 (1993 E)

— entry means the entry contents as a whole and does not necessarily include the information in theentry;

— allUserAttributeTypes means all user attribute type information associated with the entry, but notvalues associated with those attributes;

— allUserAttributeTypesAndValues means all user attribute information associated with the entry,including all values of all user attributes;

— attributeType means attribute type information pertaining to specific attributes but not valuesassociated with the type;

— allAttributeValues means all attribute value information pertaining to specific attributes;

— attributeValue means a specific value of specific attributes;

— selfValue means the attribute value assertion corresponding to the current requestor. The protecteditem selfValue applies only when the access controls are to be applied with respect to a specificauthenticated user. It can only apply in the specific case where the attribute specified is ofDistinguishedName or uniqueMember syntax and the attribute value within the specified attributematches the distinguished name of the originator of the operation.

Note — allUserAttributeTypes and allUserAttributeTypesAndValues do not include operational attributes, whichshould be specified on a per attribute basis, using attributeType , allAttributeValues or attributeValue.

b) UserClasses defines a set of zero or more users the permissions apply to. The set of users is selected fromthe following:

— allUsers means every directory user (with possible requirements for authenticationLlevel );

— thisEntry means the user with the same distinguished name as the entry being accessed;

— name is the user with the specified distinguished name (with an optional unique identifier);

— userGroup is the set of users who are members of the groupOfUniqueNames entry, identified by thespecified distinguished name (with an optional unique identifier). Members of a group of unique namesare treated as individual object names, and not as the names of other groups of unique names. Howgroup membership is determined; is described in 16.4.2.5.

— subtree is the set of users whose distinguished names fall within the definition of the (unrefined)subtree.

c) SubtreeSpecification is used to specify a subtree relative to the root entry named in base. The baserepresents the distinguished name of the root of subtree. The subtree extends to the leaves of the DIT unlessotherwise specified in chop . The use of a specificationFilter component is not permitted; if present, it shallbe ignored.

Note — SubtreeSpecification does not allow subtree refinement because a refinement might require a DSA to use adistributed operation in order to determine if a given user is in a particular user class. Basic Access Control isdesigned to avoid remote operations in the course of making an access control decision. Membership in a subtreewhose definition includes only base and chop can be evaluated locally, whereas membership in a subtree definitionusing specificationFilter can only be evaluated by obtaining information from the user’s entry which is potentiallyin another DSA.

d) ItemPermission contains a collection of users and their permissions with respect to ProtectedItems withinan itemFirst specification. The permissions are specified in grantsAndDenials as discussed in item f) ofthis subclause. Each of the permissions specified in grantsAndDenials is considered to have theprecedence level specified in precedence for the purpose of evaluating access control information asdiscussed in clause 16.8. If precedence is omitted within ItemPermission then precedence is taken fromthe precedence specified for the ACIItem (see 16.4.2.2.).

e) UserPermission contains a collection of protected items and the associated permissions with respect touserClasses within a userFirst specification. The protected items are specified in protectedItems asdiscussed in clause 16.4.5. The associated permissions are specified in grantsAndDenials as discussed initem f) of this subclause. Each of the permissions specified in grantsAndDenials is considered to have theprecedence level specified in precedence for the purpose of evaluating access control information asdiscussed in clause 16.8. If precedence is omitted within UserPermission, the precedence is taken fromthe precedence specified for the ACIItem (see 16.4.2.2.).

f) GrantsAndDenials specify the access rights that are granted or denied in the ACIItem specification. Theprecise semantics of these permissions with respect to each protected item is discussed in ITU-T Rec.X.511 | ISO/IEC 9594-3.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 63

g) UniqueIdentifier may be used by the authentication mechanism to distinguish between instances ofdistinguished name reuse. The value of the unique identifier is assigned by the authentication authorityaccording to its policy and is provided by the authenticating DSA. If this field is present, then for anaccessing user to match the name user class of an ACIItem that grants permissions, in addition to therequirement that the user’s distinguished name match the specified distinguished name, the authenticationof the user must yield an associated unique identifier, and that value must match for equality with thespecified value.

Note — When authentication is based on supplied SecurityParameters, the unique identifier associated with theuser may be taken from the subjectUniqueIdentifier field of the sender’s Certificate in the optionalCertificationPath .

16.4.2.5 Determining group membership

Determining whether a given requestor is a group member requires checking two criteria. Also, the determinationmay be constrained if the group definition is not known locally. The criteria for membership and the treatment ofnon–local groups are discussed below.

a) A DSA is not required to perform a remote operation to determine whether the requestor belongs to aparticular group for the purposes of Basic Access Control. If membership in the group cannot be evaluated,the DSA shall assume that the requestor does not belong to the group if the ACI item grants the permissionsought, and does belong to the group if it denies the permission sought.

Notes

1 Access control administrators must beware of basing access controls on membership of non-locally availablegroups or groups which are available only through replication (and which may, therefore, be out of date).

2 For performance reasons it is usually impractical to retrieve group membership from remote DSAs as part of theevaluation of access controls. However, in certain circumstances it may be practical, and a DSA is permitted, forexample, to perform remote operations to obtain or refresh a local copy of a group entry or use the Compareoperation to check membership prior to applying this clause.

b) In order to determine whether the requestor is a member of a userGroup user class, the following criteriaapply:

— The entry named by the userGroup specification must be an instance of the object classgroupOfNames or groupOfUniqueNames .

— The name of the requestor must be a value of the member or uniqueMember attribute of that entry.

Note — Values of the member or uniqueMember attribute that do not match the name of the requestor are ignored,even if they represent the names of groups of which the originator could be found to be a member. Hence, nestedgroups are not supported when evaluating access controls.

16.5 The ACI operational attributes

Access control information is stored in the Directory as an operational attribute of entries and subentries. Theoperational attribute is multi-valued, which allows ACI to be represented as a set of ACIItems (defined in 16.4).

16.5.1 Prescriptive access control information

A Prescriptive ACI attribute is defined as an operational attributes of a subentry. It contains access controlinformation applicable to entries within that subentry’s scope:

prescriptiveACI ATTRIBUTE ::= {WITH SYNTAX ACIItemEQUALITY MATCHING RULE directoryStringFirstComponentMatchUSAGE directoryOperationID id-aca-prescriptiveACI }

16.5.2 Entry access control information

An Entry ACI attribute is defined as operational attributes of an entry. It contains access control informationapplicable to the entry in which it appears, and that entry’s contents:

entryACI ATTRIBUTE ::= {WITH SYNTAX ACIItemEQUALITY MATCHING RULE directoryStringFirstComponentMatchUSAGE directoryOperationID id-aca-entryACI }

ISO/IEC 9594-2 : 1993(E)

64 ITU-T Rec. X.501 (1993 E)

16.5.3 SubentryACI

Subentry ACI attributes are defined as operational attributes of administrative entries, and provide access controlinformation that applies to each of the subentries of the corresponding administrative point. Prescriptive ACI withinthe subentries of a particular administrative point never applies to the same or any other subentry of thatadministrative point, but can be applicable to the subentries of subordinate administrative points. Subentry ACIattributes are contained only in administrative points and do not affect any element of the DIT other thanimmediately subordinate subentries.

In evaluating access control for a specific subentry, the ACI that must be considered is:

— The entryACI within the subentry itself (if any);

— The subentryACI within the associated administrative entry (if any);

— prescriptiveACI associated with other relevant administrative points within the same access controlspecific area (if any).

subentryACI ATTRIBUTE ::= {WITH SYNTAX ACIItemEQUALITY MATCHING RULE directoryStringFirstComponentMatchUSAGE directoryOperationID id-aca-subentryACI }

16.6 Protecting the ACI

ACI operational attributes may be subjected to the same protection mechanisms as ordinary attributes. Someimportant related points are:

a) The identificationTag provides an identifier for each ACIItem. This tag can be used to remove a specificACIItem value, or to protect it by prescriptive or entry ACI.

Note — Directory rules ensure that only one ACIItem per access control attribute possesses any specificidentificationTag value.

b) The creation of subentries for an Administrative Entry may be access controlled by means of thesubentryACI operational attribute in the Administrative Entry.

Note — The right to create prescriptive access controls may also be governed directly by security policy; thisprovision is required to create access controls in new autonomous administrative areas.

16.7 Access control and Directory operations

Each Directory operation involves making a series of access control decisions on the various protected items thatthe operation accesses.

For some operations (e.g., Modify operations), each such access control decision must grant access for the operationto succeed; if access is denied to any protected item, the whole operation fails. For other operations, protected itemsto which access is denied are simply omitted from the operation result and processing continues.

If the requested access is denied, further access control decisions may be needed to determine if the user hasDiscloseOnError permissions to the protected item. Only if DiscloseOnError permission is granted may theDirectory respond with an error that reveals the existence of the protected item; in all other cases the Directory actsso as to conceal the existence of the protected item.

The access control requirements for each operation, i.e., the protected items and the access permission required toaccess each protected item, are specified in ITU-T Rec. X.511 | ISO/IEC 9594-3.

The algorithm by which any particular access control decision is made is specified in 16.8.

16.8 Access Control Decision Function

This clause specifies how an access control decision is made for any particular protected item. It provides aconceptual description of the Access Control Decision Function (ACDF) for basic-access-control. It describes howACI items are processed in order to decide whether to grant or deny a particular requestor a specified permission toa given protected item.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 65

16.8.1 Inputs and outputs

For each invocation of the ACDF, the inputs are

a) the requestor’s Distinguished Name (as defined in 7.3 of ITU-T Rec. X.511 | ISO/IEC 9594-3), uniqueidentifier, and authentication level, or as many of these as are available;

b) the protected item (an entry, an attribute, or an attribute value) being considered at the current decisionpoint for which the ACDF was invoked;

c) the requested permission category specified for the current decision point;

d) the ACI items associated with the entry containing (or which is) the protected item. Protected items aredescribed in 16.4.2.4. The scope of influence for ACI items within a prescriptiveACI attribute is describedin 16.3.2 and 16.5.1. The scope of influence for ACI items within an entryACI attribute is described in16.3.2 and 16.5.2. The scope of influence for ACI items within a subentryACI attribute is described in16.5.3.

The output is a decision to grant or deny access to the protected item.

In any particular instance of making an access control decision, the outcome shall be the same as if the steps 16.8.2through 16.8.4 were performed:

16.8.2 Tuples

For each ACI value in the ACI items of 16.8.1.d), expand the value into a set of tuples , one tuple for each elementof the itemPermissions and userPermissions sets. Collect all tuples from all ACI values into a single set. Eachtuple contains the following items.

( userClasses, authenticationLevel, protectedItems, grantsAndDenials, precedence )

For any tuple whose grantsAndDenials specify both grants and denials, replace the tuple with two tuples — onespecifying only grants and the other specifying only denials.

16.8.3 Discarding non-relevant tuples

Perform the following steps to discard all non–relevant tuples:

1) Discard all tuples that do not include the requestor in the tuple’s userClass (16.4.2.4 b) as follows:

— For tuples that grant access discard all tuples that do not include the requestor’s identity in the tuples’suserClasses element taking into account uniqueIdentifier elements if relevant. Where a tuplespecifies a uniqueIdentifier , a matching value must be present in the requestor’s identity if the tuple isnot to be discarded. Discard tuples that specify an authentication level higher than that associated withthe requestor in accordance with 16.4.2.3.

— For tuples that deny access, retain all tuples that include the requestor in the tuple’s userClasseselement, taking into account uniqueIdentifier elements if relevant. Also retain all tuples that denyaccess and which specify an authentication level higher than that associated with the requestor inaccordance with 16.4.2.3. All other tuples that deny access are discarded.

Note — The second requirement in the second bullet above (i.e., to retain any tuple that denies access and alsospecifies an authentication level higher than that associated with the requestor) reflects the fact that the requestor hasnot adequately proved non–membership in the user class for which the denial is specified.

2) Discard all tuples that do not include the protected item in protectedItems (16.4.2.4 a).

3) Discard all tuples that do not include the requested permission as one of the set bits in grantsAndDenials(16.4.1, 16.4.2.4 f).

Note — The order in which discarding of non–relevant tuples is performed does not change the output of the ACDF.

16.8.4 Selecting highest precedence, most specific tuples

Perform the following steps to select those tuples of highest precedence and specificity:

1) Discard all tuples having a precedence less than the highest remaining precedence.

2) If more than one tuple remains, choose the tuples with the most specific user class : If there are any tuplesmatching the requestor with UserClasses element name or thisEntry , discard all other tuples. Otherwise if

ISO/IEC 9594-2 : 1993(E)

66 ITU-T Rec. X.501 (1993 E)

there are any tuples matching UserGroup , discard all other tuples. Otherwise if there are any tuplesmatching subtree, discard all other tuples.

3) If more than one tuple remains, choose the tuples with the most specific protected item: If the protecteditem is an attribute and there are tuples that specify the attribute type explicitly, discard all other tuples. Ifthe protected item is an attribute value, and there are tuples that specify the attribute value explicitly,discard all other tuples.

Grant access if and only if one or more tuples remain and all grant access. Otherwise deny access.

16.9 Simplified Access Control

16.9.1 Introduction

This clause describes the functionality of an access control scheme, known as Simplified Access Control, that isdesigned to provide a subset of functionality found in Basic Access Control.

16.9.2 Definition of Simplified Access Control functionality

The functionality of Simplified Access Control is defined as follows:

a) access control decisions shall be made only on the basis of ACIItem values of prescriptiveACI andsubentryACI operational attributes.

Note — entryACI , if present, shall not be used to make access control decisions;

b) access control specific administrative areas shall be supported. Access control inner administrative areasshall not be used. Particular access decisions shall be made on the basis of ACIItem values obtained from asingle Administrative Point, or from subentries of that Administrative Point.

Note — Values of prescriptiveACI attributes appearing in subentries of Administrative Points containing no id-ar -accessControlSpecificArea Administrative Role attribute value shall not be used to make access control decisions;

c) all other provisions shall be as defined for basic access control.

SECTION 8: DSA MODELS

17 DSA ModelsThis clause is concerned with general models describing various aspects of the components comprising theDirectory, Directory System Agents (DSAs). Subsequent clauses treat additional DSA models.

17.1 Definitions


— context prefix: The sequence of RDNs leading from the Root of the DIT to the initial vertex of a namingcontext; corresponds to the distinguished name of that vertex.

— DIB fragment: The portion of the DIB that is held by one master DSA, comprising one or more namingcontexts.

— naming context: A subtree of entries held in a single master DSA.

17.2 Directory Functional Model

The Directory is manifested as a set of one or more application-processes known as Directory System Agents(DSAs) , each of which provides zero, one, or more of the access points. This is illustrated in Figure 12 Where theDirectory is composed of more than one DSA, it is said to be distributed. The procedures for the operation of theDirectory when it is distributed are specified in ITU-T Rec. X.518 | ISO/IEC 9594-4.

Note — A DSA will likely exhibit local behavior and structure which is outside the scope of envisaged DirectorySpecifications. For example, a DSA which is responsible for holding some or all of the information in the DIB will normallydo so by means of a database, the interface to which is a local matter.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 67

The Directory

DSA

DSA

DSA

DSA

Figure 12 — The Directory Provided by Multiple DSAs

A particular pair of application-processes which need to interact in the provision of directory services (either a DUAand a DSA, or two DSAs) may be located in different open systems. Such an interaction is carried out by means ofOSI Directory protocols, as specified in ITU-T Rec. X.519 | ISO/IEC 9594-5.

Clause 17 specifies the models that are used as the basis for specifying the distributed aspects of the Directory. Aframework for the specification of operational models concerned with particular aspects of the operation of thecomponents of the Directory, DSAs, is provided in clauses 21 through 24.

17.3 Directory Distribution Model

This clause defines the principles according to which the DIB can be distributed.

Each entry within the DIB is administered by one, and only one, DSA’s Administrator who is said to haveadministrative authority for that entry. Maintenance and management of an entry shall take place in a DSAadministered by the administrative authority for the entry. This DSA is the master DSA for the entry.

Each master DSA within the Directory holds a fragment of the DIB. The DIB fragment held by a master DSA isdescribed in terms of the DIT and comprises one or more naming contexts. A naming context is a subtree of the DIT,all entries of which have a common administrative authority and are held in the same master DSA. A namingcontext starts at a vertex of the DIT (other than the root) and extends downwards to leaf and/or non-leaf vertices.Such vertices constitute the border of the naming context. The superior of the starting vertex of a naming context isnot held in that master DSA. Subordinates of the non-leaf vertices belonging to the border denote the start of furthernaming contexts.

Notes

1 The DIT is therefore partitioned into disjoint naming contexts, each under the administrative authority of a single masterDSA.

2 A naming context in itself is not an administrative area having an administrative point or an explicit subtreespecification, but it may coincide with an administrative area.

It is possible for a master DSA’s administrator to have administrative authority for several disjoint naming contexts.For every naming context for which a master DSA has administrative authority, it shall logically hold the sequenceof RDNs which lead from the root of the DIT to the initial vertex of the subtree comprising the naming context. Thissequence of RDNs is called the context prefix of the naming context.

A master DSA’s administrator may delegate administrative authority for any immediate subordinates of any entryheld locally to another master DSA. A master DSA that delegated authority is called a superior DSA and the contextthat holds the superior entry of one for which the administrative authority was delegated, is called the superiornaming context. Delegation of administrative authority begins with the root and proceeds downwards in the DIT;that is, it can only occur from an entry to its subordinates.

ISO/IEC 9594-2 : 1993(E)

68 ITU-T Rec. X.501 (1993 E)

Figure 13 illustrates a hypothetical DIT logically partitioned into five naming contexts (named A, B, C, D and E),which are physically distributed over three DSAs (DSA1, DSA2, and DSA3).

From the example it can be seen that the naming contexts held by particular master DSAs may be configured so as tomeet a wide range of operational requirements. Certain master DSAs may be configured to hold those entries thatrepresent higher level naming domains within some logical part(s) of the DIB, the organizational structure of a largecompany say, but not necessarily all the subordinate entries. Alternatively, master DSAs may be configured to holdonly those naming contexts representing primarily leaf entries.

From the above definitions, the limiting case for a naming context can be either a single entry or the whole of theDIT.

Whilst the logical to physical mapping of the DIT onto master DSAs is potentially arbitrary, the task of informationlocation and management is simplified if the master DSAs are configured to hold a small number of namingcontexts.

Root

C=VVC=WW

O=ABC

OU=G

CN=l CN=m CN=n

OU=H

OU=I

O=DEF

OU=J OU=K

CN=o CN=p CN=q

DSA1

DSA2

DSA3

DIB object entry

DIB alias entry

Context CContext A Context B

Context E

Context D

Figure 13 — Hypothetical DIT

DSAs may hold entry-copies as well as entries. Shadowed entries, the only sort of entry-copy considered in theDirectory Specifications, are maintained by means of the shadowing service described in ITU-T Rec. X.525 |ISO/IEC 9594-9. In addition to this standardized sort of replicated information, two additional non-standardizedsorts of entry-copy may be encountered in the Directory.

— Copies of an entry may be stored in other DSA(s) through bilateral agreement.

— Copies of an entry may be acquired by storing (locally and dynamically) a cache-copy of an entry whichresults from a request.

Note – The means by which these copies are maintained and managed is not defined in these Directory specifications. Dueto more precise handling of features like access control, it is recommended that the shadow service be used instead of usingcached copies.

A DSA holding an entry-copy is a shadow DSA for that entry. A shadow DSA may hold a copy of a naming contextor a portion thereof. The specification of the portion of a naming context that is shadowed is termed a unit ofreplication .

As described in 9.2 of ITU-T Rec. X.525 | ISO/IEC 9594-9, a unit or replication is defined within the Directoryinformation model, and a specification mechanism is provided. The shadowing mechanism in the Directory is basedon the definition of the subset of the DIT that will be shadowed. This subset is called unit of replication . The unit ofreplication comprises a three-part specification which defines the scope of the portion of the DIT to be replicated,

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 69

the attributes to be replicated within that scope, and the requirements for subordinate knowledge. The unit ofreplication also implicitly causes the shadowed information to include policy information in the form of operationalattributes held in entries and subentries (e.g., access control information) which is to be used to correctly performDirectory operations. The prefix information to be included begins at an autonomous administrative point andextends to the replication base entry.

The originator of a Directory request is informed (via fromEntry) as to whether information returned in response toa request is from an entry-copy or not. A service control, dontUseCopy , is defined which allows the user to prohibitthe use of entry-copies to satisfy the request (although copy information may be used in name resolution.).

In order for a DUA to begin processing a request it shall hold some information, specifically the presentationaddress, about at least one DSA that it can contact initially. How it acquires and holds this information is a localmatter.

During the process of modification of entries it is possible that the Directory may become inconsistent. This will beparticularly likely if modification involves aliases or aliased objects which may be in different DSAs. Theinconsistency shall be corrected by specific administrator action, for example to delete aliases if the correspondingaliased objects have been deleted. The Directory continues to operate during this period of inconsistency.

SECTION 9: DSA INFORMATION MODEL

18 Knowledge18.1 Definitions


— category : A characteristic of a knowledge reference that qualifies it as identifying a master or a shadowDSA .

— commonly usable: A characteristic of a replicated area that permits general distribution of the access pointof the DSA holding it; a commonly usable replicated area is normally a complete shadow copy of a namingcontext.

— cross reference: A knowledge reference containing information about a DSA that holds an entry or entry-copy. This is used for optimization. The entry need have no superior or subordinate relationship to anyentry in the DSA holding the cross reference.

— immediate superior reference: A knowledge reference containing information about a DSA that holds thenaming context (or a commonly usable replicated area derived from it) that is immediately superior to oneheld by the DSA for which the knowledge reference is relevant.

— knowledge (information): DSA operational information held by a DSA that it uses to locate remote entry orentry-copy information.

— knowledge reference : Knowledge which associates, either directly or indirectly, a DIT entry or entry copywith the DSA in which it is located.

— master knowledge: Knowledge of the master DSA for a naming context.

— non-specific subordinate reference: A knowledge reference containing information about a DSA that holdsone or more unspecified subordinate entries or entry-copies.

— reference path: A continuous sequence of knowledge references.

— shadow knowledge: Knowledge of one or more shadow DSAs for a naming context (if the knowledge isspecific) or contexts (if nonspecific).

— subordinate reference: A knowledge reference containing information about a DSA that holds a specificsubordinate entry or entry-copy.

— superior reference: a knowledge reference containing information about a DSA considered capable ofresolving (i.e., finding any entry within) the whole of the DIT.

ISO/IEC 9594-2 : 1993(E)

70 ITU-T Rec. X.501 (1993 E)

18.2 Introduction

The DIB is distributed across a large number of master DSAs, each holding and having administrative authority for aDIB fragment. The principles governing this distribution are specified in 17.3 of this Directory Specification.

In addition, these and other DSAs may hold copies of portions of the DIB.

It is a requirement of the Directory that, for particular modes of user interaction, the distribution of the directory berendered transparent, thereby giving the effect that the whole of the DIB appears to be within each and every DSA.

In order to support this operational requirement, it is necessary that each DSA be able to gain access to theinformation held in the DIB associated with any name (i.e any object’s distinguished or alias names). If the DSAdoes not itself hold an object entry or object entry-copy associated with the name, it must be able to interact with aDSA that does, either directly or indirectly by means of direct and/or indirect interactions with other DSAs.

When the Directory user indicates that entry-copy information shall not be used to satisfy his request, the DSAservicing the request must be able to gain access, directly or indirectly, to the master DSA holding the entryinformation associated with the name supplied in the user’s request.

This clause defines knowledge as that DSA operational information required to achieve these technical objectives.Subsequent clauses specify the representation of knowledge in the context of a general DSA information model.

Note – The preceding statements represent technical objectives of the Directory. Realization of these technical objectivesdepends on other matters (e.g. policy matters) in addition to a consistent configuration of knowledge in DSAs. clauses 21through 24 of this Directory Specification establishes a framework to address some of these matters.

Annex N contains an illustration of the modelling of knowledge. The illustration is based on the hypothetical DITgiven in Figure 13.

18.3 Knowledge References

Knowledge is that operational information held by a DSA that represents a partial description of the distribution ofentry and entry-copy information held in other DSAs. Knowledge is used by a DSA to determine an appropriateDSA to contact when a request received from a DUA or another DSA cannot be satisfied with locally heldinformation.

Knowledge consists of knowledge references. A knowledge reference associates, either directly or indirectly, thename of a Directory entry with a DSA holding the entry or a copy of the entry.

18.3.1 Knowledge Categories

There are two categories of knowledge reference, master knowledge references and shadow knowledge references.

Master knowledge is knowledge of the access point of the master DSA for a naming context.

Shadow knowledge is knowledge of DSAs holding replicated Directory information; it may be distributed by shadowsuppliers to shadow consumers by means of the replication procedures described in ITU-T Rec. X.525 | ISO/IEC9594-9. Shadow knowledge is knowledge of the access point of a set of one or more shadow DSAs for a replicatedarea (a naming context or a portion thereof).

A DSA that is the object of shadow knowledge shall hold a commonly usable replicated area. One form of replicatedarea that is commonly usable is a complete shadow copy of a naming context. An incomplete shadow copy of anaming context held by a DSA may be commonly usable if it is sufficiently complete to satisfy the interrogationrequests that users commonly make to the DSA. It is the responsibility of the administrative authority who causesshadow knowledge of a DSA holding an incomplete copy of a naming context to be distributed that the replicatedarea be commonly usable.

A given DSA may hold both master and shadow knowledge, the latter involving multiple shadow DSAs, regarding aparticular naming context. The specific knowledge used in the processing of a request received from a DUA oranother DSA, e.g. in the name resolution process, is determined by a DSA-specific selection procedure whereby theDSA computes, based on any nonstandardized criteria deemed appropriate by the administrative authority, an accesspoint of a DSA capable of progressing the request.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 71

Note – The Directory Specifications do not constrain how master and shadow knowledge is used by DSAs (other thanindirectly through constraints on DSA behavior, for example, the dontUseCopy and copyShallDo service controls asspecified in ITU-T Rec. X.511 | ISO/IEC 9594-3).

18.3.2 Knowledge Reference Types

The knowledge possessed by a DSA is defined in terms of a set of one or more knowledge references where eachreference associates, either directly or indirectly, entries (or entry copies) of the DIB with the DSA which hold thoseentries (or entry copies).

A DSA may hold the following types of knowledge reference:

— a superior reference,

— immediate superior references,

— subordinate references,

— non-specific subordinate references, and

— cross references.

A knowledge reference of a particular type shall be either a master or shadow knowledge reference.

In addition, a DSA that participates in shadowing as a shadow supplier and/or consumer may hold one or more ofthe following types of knowledge reference:

— supplier references, and

— consumer references.

These knowledge reference types are described below.

18.3.2.1 Superior Reference

A superior reference consists of

— the Access Point of a DSA.

Each non-first level DSA (see 18.5) maintains precisely one superior reference. The superior reference shall formpart of a reference path to the root. Unless some method outside the standard is employed to ensure this, for examplewithin a DMD, this shall be accomplished by referring to a DSA which holds a naming context or replicated areawhose context prefix has fewer RDNs than the context prefix with fewest RDNs held by the DSA holding thereference.

18.3.2.2 Immediate Superior References

An immediate superior reference consists of

— the context prefix of a naming context that is immediately superior to one held (as entries or entry-copies)by the DSA holding the reference;

— the Access Point of the DSA holding that naming context (as entries or entry-copies).

Immediate superior references are an optional reference type that only occur when there is a hierarchical operationalbinding to the referenced DSA (see clause 24 in ITU-T Rec. X.518 | ISO/IEC 9594-4). In the absence of suchexplicit operational bindings, an immediate superior naming context may be referenced by means of a crossreference.

18.3.2.3 Subordinate References

A subordinate reference consists of

— a context prefix corresponding to a naming context immediately subordinate to one held (as entries orentry-copies) by the DSA holding the reference;

— the Access Point of the DSA holding that naming context (as entries or entry copies).

All naming contexts immediately subordinate to naming contexts held by a master DSA shall be represented bysubordinate references (or non-specific subordinate references as described in 18.3.2.4).

ISO/IEC 9594-2 : 1993(E)

72 ITU-T Rec. X.501 (1993 E)

In the case where a DSA holds entry-copies, the subordinate naming contexts may or may not be represented,depending on the shadowing agreement in effect.

18.3.2.4 Non-Specific Subordinate References

A non-specific subordinate reference consists of

— the Access Points of a DSA that holds the entries (or entry copies) of one or more immediately subordinateNaming Contexts.

This type of reference is optional, to allow for the case in which a DSA is known to contain some subordinate entries(or entry-copies) but the specific RDNs of those entries (or entry-copies) is not known.

For each naming context that it holds, a master DSA may hold zero or more non-specific subordinate references.DSAs accessed via a non-specific reference shall be able to resolve the request directly (either success or failure). Inthe event of failure, a serviceError reporting a problem of unableToProceed is returned to the requestor.

In the case where a DSA holds entry-copies, the non-specific subordinate references may or may not be represented,depending on the shadowing agreement in effect.

18.3.2.5 Cross References

A cross reference consists of

— a Context Prefix;

— the Access Point of a DSA which holds the entries or entry-copies for that naming context.

This type of reference is optional and serves to optimize Name Resolution. A DSA may hold any number (includingzero) of cross references.

18.3.2.6 Supplier References

A supplier reference held by a shadow consumer DSA consists of

— the context prefix of the naming context from which the replicated area received from the shadow supplieris derived;

— the identifier of the shadowing agreement that the shadow consumer has established with a shadowsupplier;

— the Access Point of the shadow supplier DSA;

— an indication of whether the shadow supplier of the replicated area is or is not the master; and

— optionally, the access point of the master DSA if the supplier is not the master.

18.3.2.7 Consumer References

A consumer reference held by a shadow supplier DSA consists of

— the context prefix of a naming context from which the replicated area provided by the shadow supplier isderived;

— the identifier of the shadowing agreement that the shadow supplier has established with a consumer; and

— the Access Point of the shadow consumer DSA.

18.4 Minimum Knowledge

It is a property of the Directory that each entry can be accessed independently of where a request is generated.

It is also a property of the Directory that, to achieve adequate levels of performance and availability, some requestscan be satisfied using a copy of an entry, while other requests may only be satisfied using the entry itself (i.e., theinformation held at the master DSA for the entry).

To realize these location independence properties of the Directory, each DSA must maintain a minimum quantity ofknowledge which depends on the particular configuration of the DSA.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 73

The objective of these minimum requirements is to permit the distributed name resolution process to establish areference path, as a continuous sequence of master knowledge references, to all naming contexts within theDirectory.

Beyond these minimum requirements, additional knowledge may be employed to establish other reference paths tocopies of naming contexts. Cross reference knowledge (master and shadow) may be employed to establish optimizedreference paths to naming contexts and copies of naming contexts.

The minimum knowledge requirements for DSAs are specified in 18.4.1 – 18.4.4.

18.4.1 Superior Knowledge

Each DSA that is not a first level DSA shall maintain a single superior reference.

18.4.2 Subordinate Knowledge

A DSA that is the master DSA of a naming context shall maintain subordinate or non-specific subordinate referencesof category master knowledge to each master DSA holding (as master) an immediately subordinate naming context.

18.4.3 Supplier Knowledge

For each shadow supplier DSA that supplies it with a replicated area, a shadow consumer DSA shall maintain asupplier reference. If the shadow consumer’s subordinate knowledge for the copy of the naming context isincomplete, it shall use its supplier reference to establish a reference path to subordinate information. This procedureis described in clause 18 of ITU-T Rec. X.518 | ISO/IEC 9594-4.

18.4.4 Consumer Knowledge

For each shadow consumer DSA that it supplies with a replicated area, a shadow supplier DSA shall maintain aconsumer reference.

18.5 First Level DSAs

The DSA referenced by a superior reference assumes the burden of establishing a reference path to all of the DITthat is unknown to the referring DSA. A DSA referenced by other DSAs may itself maintain a superior reference.This recursive superior referral process stops at a set of first level DSAs upon whom the ultimate responsibility forthe establishment of reference paths falls.

A first level DSA is characterized as follows:

a) it does not hold a superior reference;

b) it may hold one or more naming contexts immediately subordinate to the root of the DIT (as master orshadow DSA for the naming context); and

c) it holds a subordinate reference (of category master and/or shadow) for each naming context immediatelysubordinate to the root of the DIT that it does not itself hold.

The administrative authorities for first level DSAs are jointly responsible for the administration of the immediatesubordinates of the root of the DIT. The procedures governing this joint administration are determined bymultilateral agreements which are outside the scope of the Directory Specifications.

To limit the quantity of interrogation requests that might be directed to a master first level DSA (i.e. a DSA that is amaster for a naming context immediately subordinate to the root of the DIT), it is possible to establish shadow firstlevel DSAs for that master first level DSA. Such shadow DSAs hold copies of the entries and subordinate referencesimmediately subordinate to the root held in its master (or supplier) first level DSA. They therefore may serve as thesuperior reference for non-first level DSAs.

19 Basic Elements of the DSA Information Model19.1 Definitions

19.1.1 DSA information tree: the set of all DSEs held by a DSA when viewed from the perspective of their names.

ISO/IEC 9594-2 : 1993(E)

74 ITU-T Rec. X.501 (1993 E)

19.1.2 DSA-shared attribute : an operational attribute in the DSA information model associated with a particularname whose value or values, if held by several DSAs, are identical (except during periods of transientinconsistency).

19.1.3 DSA-specific attribute : an operational attribute in the DSA information model associated with a particularname whose value or values, if held by several DSAs, need not be identical.

19.1.4 DSA-specific entry (DSE): the information held by a DSA that is associated with a particular name; theDSE may (but need not) contain the information associated with the corresponding Directory entry.

19.1.5 DSE type: an indication of the particular purpose of a DSE; a DSE may serve multiple purposes and thushave multiple types.

19.2 Introduction

The Directory information model describes how the Directory as a whole represents information about objectshaving a distinguished name and optionally alias names. In its description of the DIT, entries and attributes, thecomposition of the Directory as a set of potentially cooperating DSAs is abstracted from the model.

The DSA information model, on the other hand, is especially concerned with DSAs and the information that must beheld by DSAs in order that the set of DSAs comprising the Directory may together realize the Directory informationmodel. It is concerned with:

— how Directory information (object and alias entries and subentries) is mapped onto DSAs;

— how copies of Directory information may be held by DSAs;

— the operational information required by DSAs to perform name resolution and operation evaluation; and

— the operational information required by DSAs to engage in shadowing and to use shadowed information.

The purpose for modelling a representation of DSA operational information such as knowledge is to establish thegeneral framework for management access to DSA operational information.

19.3 DSA-Specific Entries and their Names

In the DSA information model, the information repositories holding the information associated with a particularname are termed DSA-Specific Entries (DSEs). Directory entries exist in the DSA information model only asinformation elements from which DSEs may be composed. Operational attributes specific to the DSA informationmodel comprise the other variety of information element from which DSEs may be composed.

If a DSA holds any information concerning a name directly (i.e., information held in a repository identified by thename), it is said to know or have knowledge of that name.

For each name known by a DSA, all the information held by the DSA directly associated with the name other thanthe name itself is represented by one DSE. This latter information (i.e., the RDN and its relationship to the DIT) isnot represented explicitly as attributes in the DSA information model; the set of names known by a DSA constitutean implicit fabric on which the associated DSEs can be considered to be attached.

Note – One consequence of the way the DSA information model handles names is that, for DSEs that are not of type entry,alias or subentry, the AVA(s) expressing the RDN of the DSE is not modelled as held in (an) attribute(s).

The set of all names known by a DSA, together with the information associated with each name, when viewed fromthe perspective of these names, is termed the DSA information tree for that DSA. A DSA information tree isdepicted in Figure 14.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 75

Entry Directory DSA-Shared

AttributesDSA-Specific

Attributes

AP

Point (AP)Administrative

(e.g. for subordinate references)DSE

DSA-Shared Attributes

DSA-Specific Attributes

DSE

Subentry Directory

Subentry

DSE


root DSEroot

DSA-SharedAttributes


③

②

①

④

Figure 14 – A DSA Information Tree

The minimum information that a DSA may associate with a name, and thus know the name, consists of anexpression of the purpose for which the name is known (i.e. the role played by the name in the operation of the DSAknowing it). This purpose is represented in the DSA information model by the DSA-specific attribute, dseType.

In addition, a DSE may hold other information associated with the name such as an entry or entry-copy, DSA-sharedattributes and DSA-specific attributes.

A DSE may represent a Directory entry directly, a portion of an entry or no Directory information. The informationheld in a DSE varies, depending on its type or purpose. In general, the following sorts of DSEs may occur in DSAs.

— A DSE directly representing a Directory entry contains the user and operational attributes corresponding tothat Directory entry (as depicted in DSE ≠ in Figure 14). The DSE may also contain DSA-shared and DSA-specific attributes.

— A DSE representing a portion of an entry (as a result of shadowing) contains some of the user andoperational attributes corresponding to the Directory entry, DSA-specific attributes and may also containDSA-shared attributes.

— A subentry DSE representing, for example prescriptive ACI or collective attributes, contains the relevantuser and operational attributes corresponding to a Directory subentry (as depicted in DSE Æ in Figure 14).The DSE may also contain DSA-shared and DSA-specific attributes.

— A DSE representing no Directory entry information contains only DSA-shared and/or DSA specificattributes (as depicted in DSEs ¨ and Ø in Figure 14). For example, a DSE representing a subordinatereference may have a DSA-shared attribute that indicates the master access point and a DSA-specificattribute to indicate that the DSE is a subordinate reference.

Note – The DSE is a conceptual entity which facilitates the specification and modelling of information components in aconsistent and convenient way. Although DSEs are said to “hold” or “store” information, this is not intended to impose anyparticular constraints or data structure on implementations.

19.4 Basic Elements

A DSE is comprised of three basic elements, the DSE type, some number of DSA operational attributes (the DSEtype is one of these) and optionally an entry or entry-copy.

19.4.1 DSA Operational Attributes

Two varieties of operational attribute occur in the DSA information model that do not correspond to information inDirectory entries. Those are DSA-shared and DSA-specific attributes.

ISO/IEC 9594-2 : 1993(E)

76 ITU-T Rec. X.501 (1993 E)

A DSA-shared attribute is an operational attribute in the DSA information model associated with a particular namewhose value or values, if held by several DSAs, are identical (except during periods of transient inconsistency). ADSA may hold a shadow-copy of a DSA-shared attribute.

A DSA-specific attribute is an operational attribute in the DSA information model associated with a particular namewhose value or values, if held by several DSAs, need not be identical. A DSA-specific attribute representsoperational information that is specific to the functioning of the DSA holding it. A DSA cannot hold a shadow-copyof a DSA-specific attribute.

Note – While a shadow-supplier DSA may provide a shadow-consumer DSA with a DSA-specific attribute, this isconceptually not a shadow-copy of information held by the supplier but, rather, information produced by the supplier for theconsumer which the consumer may then use and modify.

19.4.2 DSE Types

The type of a DSE, represented in the DSA information model by the DSA-specific operational attribute dseType,indicates the particular purpose (or role) of a DSE. This purpose is indicated by the named bits of the single value ofthe dseType attribute. As a DSE may serve several purposes, several named bits of the dseType attribute may beset to represent these purposes. A number of combinations of named bits that are likely to occur are specified inAnnex M.

The phrase “a DSE of type x” is used in the Directory Specifications to indicate that the named bit x of the DSE’sdseType attribute has been set. For a DSE of type x, other named bits may or may not be set, as required. Thealternate phrase “the DSE type includes x” may also be used.

The syntactic specification of the dseType operational attribute may be expressed using the attribute notation asfollows:

dseType ATTRIBUTE ::= {WITH SYNTAX DSETypeEQUALITY MATCHING RULE bitStringMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE dSAOperationID id-doa-dseType }

This DSA-specific operational attribute is managed by the DSA itself.

The ASN.1 type that represents the syntax of the possible values of the dseType attribute is DSEType . Its definitionis:

DSEType ::= BIT STRING {root (0), --root DSE --glue (1), -- represents knowledge of a name only --cp (2), -- context prefix --entry (3), -- object entry --alias (4), -- alias entry --subr (5), -- subordinate reference --nssr (6), -- non-specific subordinate reference --supr (7), -- superior reference --xr (8), -- cross reference --admPoint (9), -- administrative point --subentry (10), -- subentry --shadow (11), -- shadow copy --immSupr (13), -- immediate superior reference --rhob (14), -- rhob information --sa (15)} -- subordinate reference to alias entry --

The values of DSEType are:

a) root: The root DSE contains DSA-specific attributes, used by the DSA, that characterize that DSA as awhole. The name corresponding to the root DSE is the degenerate name consisting of a sequence of zeroRDNs.

Note – Information that characterizes a DSA that is to be made available via the Directory abstract service iscontained in the DSA’s entry. A DSA may, but need not, hold its own entry or a copy of its own entry.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 77

b) glue: A glue DSE represents knowledge of a name only. A DSA holding a context prefix DSE or a crossreference DSE may hold glue DSEs to represent the names of the superiors of the context prefix or crossreference DSE if no other operational information (e.g., knowledge) is associated with those names. This isillustrated in Figure 14. A DSE of type glue shall not have any other DSEType bit set.

c) cp: The DSE representing the context prefix of a naming context.

d) entry: A DSE that holds an object entry.

e) alias: A DSE that holds an alias entry.

f) subr: A DSE that holds a specific knowledge attribute to represent a subordinate reference.

g) nssr: A DSE that holds a non-specific knowledge attribute to represent a non-specific subordinatereference.

h) supr: A DSE that holds a specific knowledge attribute to represent the DSAs superior reference.

i) xr: A DSE that holds a specific knowledge attribute to represent a cross reference.

j) admPoint: A DSE corresponding to an administrative point.

k) subentry: A DSE that holds a subentry.

l) shadow : A DSE that holds a shadow-copy of an entry (or part of an entry) or other information (e.g.knowledge) received from a shadow-supplier; this named bit is set by the shadow consumer.

m) immSupr: A DSE that holds a specific knowledge attribute to represent a immediate superior reference.

n) rhob: A DSE that holds administrative point and subentry information received from a superior DSA in aRelevant Hierarchical Operational Binding (i.e., in either a Hierarchical Operational Binding or a Non-specific Hierarchical Binding as described in clauses 24 and 25 of ITU-T Rec. X.518 | ISO/IEC 9594-4).

o) sa: A qualifier of a subr DSE indicating that the subordinate naming context entry is an alias.

The use of this operational attribute to represent aspects of the DSA information model is described in clause 19 ofthis Directory Specification.

20 Representation of DSA InformationThis clause treats the representation of DSA information. It describes the representation of DSA operationalinformation (knowledge), Directory user information and Directory operational information.

20.1 Representation of Directory User and Operational Information

This clause specifies the representation of Directory user and Directory operational information in the DSAinformation model.

20.1.1 Object Entry

An object entry is represented by a DSE of type entry which contains the user and Directory operational attributesassociated with the Directory entry. The name of the DSE is the name of the object entry (i.e. the object’sdistinguished name).

If the DSE holds a copy of the entry, the DSE type includes shadow .

20.1.2 Alias Entry

An alias entry is represented by a DSE of type alias which contains the attributes associated with the alias entry (i.e.the RDN attributes and the aliased object name attribute). The name of the DSE is the name of the alias entry.

If the DSE holds a copy of the alias entry, the DSE type includes shadow.

20.1.3 Administrative Point

An administrative point is represented by a DSE of type admPoint which contains the attributes associated with theadministrative point. The name of the DSE is the name of the administrative point.

If the DSE represents an entry, the DSE type includes entry . If the DSE holds a copy of the administrative pointinformation, the DSE type includes shadow.

ISO/IEC 9594-2 : 1993(E)

78 ITU-T Rec. X.501 (1993 E)

20.1.4 Subentry

A subentry is represented by a DSE of type subentry which contains the operational and user information associatedwith the subentry. The name of the DSE is the name of the subentry.

If the DSE holds a copy of the subentry, the DSE type is subentry and shadow.

20.2 Representation of Knowledge References

A knowledge reference consists of a DSE of an appropriate type which holds a correspondingly appropriate DSAoperational attribute and which is identified by a name bearing a defined relationship to the naming context held bythe referenced DSA.

20.2.1 Knowledge Attribute Types

DSA operational attributes are defined in the DSA information model to express a DSA’s:

— knowledge of its own access point,

— superior knowledge,

— specific knowledge (its subordinate references),

— non-specific knowledge (its non-specific subordinate references)

— knowledge of its supplier(s), optionally including the master, if it is a shadow consumer,

— knowledge of its consumer(s) if it is a shadow supplier, and

— knowledge of secondary shadows, if it is a shadow supplier.

Object Identifier values are assigned in Annex E for these operational attributes.

20.2.1.1 My Access Point

The myAccessPoint operational attribute type is used by a DSA to represent its own access point. It is a DSA-specific attribute. All DSAs shall hold this attribute in their root DSE. It is single valued and managed by the DSAitself.

myAccessPoint ATTRIBUTE ::= {WITH SYNTAX AccessPointEQUALITY MATCHING RULE accessPointMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE dSAOperationID id-doa-myAccessPoint }

The ASN.1 type AccessPoint is defined in ITU-T Rec. X.518 | ISO/IEC 9594-4. Its ASN.1 specification isreproduced here for the convenience of the reader.

AccessPoint ::= SET {ae-title [0] Name,address [1] PresentationAddressprotocolInformation [2] SET OF ProtocolInformation OPTIONAL }

How a DSA obtains the information held in myAccessPoint is not described in the Directory Specifications.

The myAccessPoint attribute type is held in a DSE of type root.

The information held in myAccessPoint may be employed in the DOP when establishing or modifying anoperational binding.

20.2.1.2 Superior Knowledge

The superiorKnowledge operational attribute type is used by a non-first level DSA to represent its superiorreference. It is a DSA-specific attribute. All non-first level DSAs shall hold this attribute in their root DSE. It issingle valued and managed by the DSA itself.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 79

superiorKnowledge ATTRIBUTE ::= {WITH SYNTAX AccessPointEQUALITY MATCHING RULE accessPointMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE dSAOperationID id-doa-superiorKnowledge }

A DSA may acquire the information held in superiorKnowledge by means not described in the DirectorySpecifications. It might also construct it from its immediate superior references, e.g., from its immediate superiorreference whose context prefix has the least number of RDNs in its name.

The superiorKnowledge attribute type is held in a DSE of type root.

The information held in superiorKnowledge may be employed by a DSA when constructing a continuationreference returned in a DAP or DSP referral or when performing chaining.

20.2.1.3 Specific Knowledge

Specific knowledge consists of the access points for the master DSA of a naming context and/or shadow DSAs forthat naming context. It is specific because the context prefix of the naming context is known and associated with theaccess point information. Specific knowledge is represented by the specificKnowledge operational attribute type. Itis a DSA-shared attribute, is single valued, and managed by the DSA itself.

specificKnowledge ATTRIBUTE ::= {WITH SYNTAX MasterAndShadowAccessPointsEQUALITY MATCHING RULE masterAndShadowAccessPointsMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE distributedOperationID id-doa-specificKnowledge }

The ASN.1 type MasterAndShadowAccessPoints is defined in ITU-T Rec. X.518 | ISO/IEC 9594-4. Its ASN.1specification is reproduced here for the convenience of the reader.

MasterAndShadowAccessPoints ::= SET OF MasterOrShadowAccessPoint

MasterOrShadowAccessPoint ::= SET {COMPONENTS OF AccessPoint,category [3] ENUMERATED {

master (0),shadow (1) } DEFAULT master }

A DSA may acquire the information held in specificKnowledge by means not described in the DirectorySpecifications. In the case of a cross reference (DSE of type xr), it might also construct it from information receivedin the crossReference component of ChainingResults of a DSP reply. In the case of a subordinate reference (DSEof type subr), it might construct it from information received in the DOP when establishing or modifying a HOB.

The specificKnowledge attribute type is held in a DSE of type subr, immSupr , or xr . It is used by a DSA torepresent subordinate, immediate superior and cross references.

The information held in specificKnowledge may be employed by a DSA when constructing a continuationreference returned in a DAP or DSP referral (or when performing chaining) and when constructing Shadowed DSASpecific Entries (SDSEs) of type subr , immSupr , or xr provided in the DISP.

20.2.1.4 Non Specific Knowledge

Non-specific knowledge consists of the access points for the master DSA of one or more naming contexts and/orshadow DSAs for the same one or more naming contexts. It is non-specific because the context prefixes of thenaming context(s) is (are) not known. The immediate superior of the naming context(s) is known, however, and theaccess point information is associated with its name. Non-specific knowledge is represented by thenonSpecificKnowledge operational attribute type. It is a DSA-shared attribute, is multiple valued and managed bythe DSA itself.

ISO/IEC 9594-2 : 1993(E)

80 ITU-T Rec. X.501 (1993 E)

nonSpecificKnowledge ATTRIBUTE ::= {WITH SYNTAX MasterAndShadowAccessPointsEQUALITY MATCHING RULE masterAndShadowAccessPointsMatchNO USER MODIFICATION TRUEUSAGE distributedOperationID id-doa-nonSpecificKnowledge }

The MasterAndShadowAccessPoints value consists of an access point for a master DSA holding one or moresubordinate naming contexts, and zero or more access points of DSAs holding shadows of some or all of thesenaming contexts.

A DSA may acquire the information held in nonSpecificKnowledge by means not described in the DirectorySpecifications. In the case of a non-specific subordinate reference (DSE of type nssr), it might also construct it frominformation received in the DOP when establishing or modifying a NHOB.

The nonSpecificKnowledge attribute type is held in a DSE of type nssr. It is used to represent non-specificsubordinate references.

The information held in nonSpecificKnowledge may be employed by a DSA when constructing a continuationreference returned in a DAP or DSP referral (or when performing chaining) and when constructing SDSEs of typenssr provided in the DISP.

20.2.1.5 Supplier Knowledge

The supplier knowledge of a shadow consumer DSA consists of the access point(s) and shadowing agreementidentifier(s) for its supplier(s) of a copy (or copies) of a replicated area. Optionally, if the supplier is not the masterof the naming context from which a replicated area is derived, the access point of the master may be included insupplier knowledge. Supplier knowledge is represented by the supplierKnowledge operational attribute type. It isDSA-specific, multiple valued and managed by the DSA itself.

The ASN.1 syntax for a value of supplierKnowledge is SupplierInformation. A value of this attribute is composedof a shadow supplier DSA’s access point and the agreement ID of the shadowing agreement between the supplierDSA and the consumer DSA holding the DSA-specific attribute (expressed as a value of the typeSupplierOrConsumer ), an indication of whether the supplier of the replicated area is or is not the master of thenaming context from which it is derived, and, if not, optionally, the access point of the master DSA.

SupplierOrConsumer ::= SET {COMPONENTS OF AccessPoint, -- supplier or consumer --agreementID [3] OperationalBindingID }

SupplierInformation ::= SET {COMPONENTS OF SupplierOrConsumer, -- supplier --supplier-is-master [4] BOOLEAN DEFAULT TRUE,non-supplying-master [5] AccessPoint OPTIONAL }

supplierKnowledge ATTRIBUTE ::= {WITH SYNTAX SupplierInformationEQUALITY MATCHING RULE supplierOrConsumerInformationMatchNO USER MODIFICATION TRUEUSAGE dSAOperationID id-doa-supplierKnowledge }

A DSA may acquire the information held in supplierKnowledge by means not described in the DirectorySpecifications. A shadow consumer DSA might also construct it from information received in the DOP whenestablishing or modifying a shadowing agreement.

The supplierKnowledge attribute type is held in a DSE of type cp . It is used to represent one or more supplierreferences. All shadow consumer DSAs shall hold a value of this attribute for each shadowing agreement theyengage in as a consumer.

The information held in supplierKnowledge may be employed by a DSA when constructing a continuationreference returned in a DAP or DSP referral. The agreementID component (its type, OperationalBindingID, isdefined in 23.2) of supplierKnowledge is required in the operations of the DOP for managing a shadowingagreement and in all the DISP operations.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 81

20.2.1.6 Consumer Knowledge

The consumer knowledge of a shadow supplier DSA consists of the access point(s) and shadowing agreementidentifier(s) for the consumer(s) of a copy (or copies) of a naming context provided to them by the supplier.Consumer knowledge is represented by the consumerKnowledge operational attribute type. It is DSA-specific,multiple valued and managed by the DSA itself.

The ASN.1 syntax for a value of consumerKnowledge is ConsumerInformation (which has the same syntax asSupplierOrConsumer , but refers to a consumer access point).

ConsumerInformation ::= SupplierOrConsumer -- consumer --

consumerKnowledge ATTRIBUTE ::= {WITH SYNTAX ConsumerInformationEQUALITY MATCHING RULE supplierOrConsumerInformationMatchNO USER MODIFICATION TRUEUSAGE dSAOperationID id-doa-consumerKnowledge }

A DSA may acquire the information held in consumerKnowledge by means not described in the DirectorySpecifications. A shadow supplier DSA might also construct it from information received in the DOP whenestablishing or modifying shadowing agreements.

The consumerKnowledge attribute type is held in a DSE of type cp . It is used to represent one or more consumerreferences. All shadow supplier DSAs shall hold a value of this attribute for each shadowing agreement they engagein as a supplier.

The agreementID component of consumerKnowledge is required in the operations of the DOP for managing ashadowing agreement and in all the DISP operations.

20.2.1.7 Secondary Shadow Knowledge

Secondary shadow knowledge consists of information a supplier DSA (e.g. a master DSA) may choose to maintainregarding consumer DSAs that are engaged in secondary shadowing from its perspective. Secondary shadowknowledge is represented by the secondaryShadows operational attribute type. It is DSA-specific, multiple valuedand managed by the DSA itself. The ASN.1 syntax for a value of secondaryShadows is SupplierAndConsumers.It consists of the access point of a shadow supplier and a list of its direct consumers.

SupplierAndConsumers ::= SET {COMPONENTS OF AccessPoint, -- supplier --consumers [3] SET OF AccessPoint }

secondaryShadows ATTRIBUTE ::= {WITH SYNTAX SupplierAndConsumersEQUALITY MATCHING RULE supplierAndConsumersMatchNO USER MODIFICATION TRUEUSAGE dSAOperationID id-doa-secondaryShadows }

The consumers component of SuppliersAndConsumers contains only access points of DSAs that hold commonlyusable copies of a replicated area.

A supplier DSA may obtain the information required to construct values of this attribute from a consumer DSA byfollowing the procedure described in 21.1.1 of ITU-T Rec. X.518 | ISO/IEC 9594-8.

The secondaryShadows attribute type is held in a DSE of type cp.

Support for secondary shadow knowledge is optional.

20.2.1.8 Matching Rules

Four equality matching rules for the preceding knowledge attributes are specified below. They apply to attributeswith syntaxes of types AccessPoint , MasterAndShadowAccessPoints, SupplierInformation,ConsumerInformation and SuppliersAndConsumers .

ISO/IEC 9594-2 : 1993(E)

82 ITU-T Rec. X.501 (1993 E)

20.2.1.8.1 Access Point Match

The Access Point Match rule is specified as

accessPointMatch MATCHING-RULE ::= {SYNTAX NameID id-kmr-accessPointMatch }

The accessPointMatch matching rule applies to attribute values of type AccessPoint. A value of the assertionsyntax is derived from a value of the attribute syntax by using the value of the [0] context specific tag (Name)component. Two values are considered to match for equality if the Name component of each match using thematching procedure for DistinguishedName values.

20.2.1.8.2 Master And Shadow Access Points Match

The Master and Shadow Access Point Match equality matching rule is specified as

masterAndShadowAccessPointsMatch MATCHING-RULE ::= {SYNTAX SET OF NameID id-kmr-masterShadowMatch }

The masterAndShadowAccessPointsMatch matching rule applies to attributes of typeMasterAndShadowAccessPoints. A value of the assertion syntax is derived from a value of the attribute syntax byremoving the category and address components of each SET in the SET OF MasterOrShadowAccessPoints. Twosuch values are considered to match for equality if both values have the same number of SET OF elements, and,after ordering the SET OF elements of each in any convenient fashion, the ae-title component of each pair of SETOF elements matches using the matching procedure for distinguishedNameMatch .

20.2.1.8.3 Supplier or Consumer Information Match

The Supplier or Consumer Information Match rule is specified as

supplierOrConsumerInformationMatch MATCHING-RULE ::= {SYNTAX SET {

ae-title [0] Name,agreement-identifier [2] INTEGER }

ID id-kmr-supplierConsumerMatch }

The supplierOrConsumerInformationMatch matching rule applies to attribute values of type SupplierInformationor ConsumerInformation (and other attributes having values compatible with SupplierInformation orConsumerInformation ). A value of the assertion syntax is derived from a value of the attribute syntax by selectingthe SET components with tags that match the SET components of the assertion syntax. Two such values areconsidered to match for equality if the ae-title component of each (after removing the explicit [0] tag information)matches using the matching procedure for DistinguishedName values and the identifier component contained in theagreement component of each (after removing the explicit [2] and SEQUENCE tag information) matches using thematching procedure for INTEGER values.

20.2.1.8.4 Suppliers And Consumers Match

The Supplier and Consumers Match rule is specified as

supplierAndConsumersMatch MATCHING-RULE ::= {SYNTAX NameID id-kmr-supplierConsumersMatch }

The Supplier and Consumers Match rule applies to attribute values of type SupplierAndConsumers (and otherattributes having values compatible with SupplierAndConsumers ). Two such values are considered to match forequality if the ae-title component of each (after removing the explicit [0] tag information) matches using thematching procedure for DistinguishedName values.

20.2.2 Knowledge Reference Types

This clause specifies the representation of knowledge in the DSA information model.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 83

20.2.2.1 Self Reference

A self reference represents a DSA’s knowledge of its own access point. It is represented by a value of the attributemyAccessPoint held in the DSA’s root DSE, a DSE of type root .

20.2.2.2 Superior Reference

A superior reference is represented by a DSE of type supr and root which contains a superiorKnowledge attribute.

20.2.2.3 Immediate Superior Reference

An immediate superior reference is represented by a DSE of type immSupr which contains a specificKnowledgeattribute. The name of the DSE holding the attribute corresponds to the context prefix of the naming context held bythe referenced superior DSA.

Since a specificKnowledge attribute value may contain access points of several DSAs, it may therefore representseveral immediate superior references, at most one of category master and zero or more of category shadow.

If the DSE holding the immediate superior reference is received from a shadow supplier, the DSE type includesshadow.

20.2.2.4 Subordinate Reference

A subordinate reference is represented by a DSE of type subr which contains a specificKnowledge attribute. Thename of the DSE holding the attribute corresponds to the context prefix of the relevant naming context held by thereferenced subordinate DSA.

Since a specificKnowledge attribute value may contain access points of several DSAs, it may therefore representseveral subordinate references, at most one of category master and zero or more of category shadow.

If the DSE holding the subordinate reference is shadowed information, received from a shadow supplier, the DSEtype includes shadow.

The DSE may also include immSupr in a DSA holding two naming contexts, one superior to the other, which areseparated by a third single-entry naming context held in another DSA. An example of this situation is depicted inAnnex N.

20.2.2.5 Non-Specific Subordinate Reference

A non-specific subordinate reference is represented by a DSE of type nssr (and entry normally) which contains anonSpecificKnowledge attribute. The name of the DSE holding the attribute corresponds to the name formed byeliminating the final RDN of the context prefixes of the naming context held by the referenced subordinate DSAs.

Since a nonSpecificKnowledge attribute value may contain access points of several DSAs, it may thereforerepresent several non-specific subordinate references, at most one of category master and zero or more of categoryshadow. Each nonSpecificKnowledge attribute value represents a related set of non-specific subordinate references— the DSAs of category shadow hold one or more replicated areas derived from the naming context(s) held by theDSA of category master .

If the DSE holding the non-specific subordinate reference is shadowed information, received from a shadowsupplier, the DSE type includes shadow.

The DSE includes shadow in the situation of a shadow DSA when the DSE corresponds to an entry for which themaster DSA has non-specific subordinate knowledge and for which only the nonSpecificKnowledge attribute forthe non-specific subordinate reference is shadowed.

The DSE includes cp and shadow in the situation of a shadow DSA whose replicated area does not include thecontext prefix entry and the master DSA for the naming context has non-specific subordinate knowledge for thecontext prefix.

The DSE includes admPoint and shadow in the situation of a shadow DSA when the DSE corresponds to anadministrative point, the entry information for the administrative point is not shadowed, and the master DSA for thenaming context has non-specific subordinate knowledge for the administrative point.

ISO/IEC 9594-2 : 1993(E)

84 ITU-T Rec. X.501 (1993 E)

When the administrative point coincides with a context prefix in the preceding two cases, the DSE may includeadmPoint , cp and shadow.

20.2.2.6 Cross Reference

A cross reference is represented by a DSE of type xr which contains a specificKnowledge attribute. The name ofthe DSE holding the attribute corresponds to the context prefix of the naming context held by the referenced DSA.

Since a specificKnowledge attribute value may contain access points of several DSAs, it may therefore representseveral cross references, at most one of category master and zero or more of category shadow.

20.2.2.7 Supplier Reference

A supplier reference is represented by a DSE of type cp which contains a supplierKnowledge attribute. The nameof the DSE holding the attribute corresponds to the context prefix of the shadowed naming context.

Since a supplierKnowledge attribute may have several values, it may represent several supplier references. Eachattribute value represents one supplier reference.

20.2.2.8 Consumer Reference

A consumer reference is represented by a DSE of type cp which contains a consumerKnowledge attribute. Thename of the DSE holding the attribute corresponds to the context prefix of the shadowed naming context.

Since a consumerKnowledge attribute may have several values, it may represent several consumer references.Each attribute value represents one consumer reference.

20.3 Representation of Names and Naming Contexts

20.3.1 Names and Glue DSEs

As described in 19.3, the minimum information that a DSA may associate with a name is the purpose for which itholds the name, represented by a DSE holding a value of the attribute dseType. When a DSE contains only such aminimal information, its DSE type shall be glue. In this case the DSE shall not hold an entry or subentry (or ashadow-copy of an entry or subentry) or a DSA-shared attribute.

Glue DSEs arise in the DSA information model to represent names that are known by a DSA as a consequence ofholding information associated with other names. For example, consider the cross reference depicted in Figure 14.The DSA holding this cross reference also “knows” (in the sense described in 19.3) the names that are superior tothe context prefix name associated with the cross reference. When no other information is associated with suchsuperior names, they are represented in the DSA information model by glue DSEs.

20.3.2 Naming Contexts

A naming context consists of a context prefix, a subtree of zero or more entries subordinate to the context prefix (theroot of the subtree), and, if there are naming contexts subordinate to it, subordinate and/or non-specific subordinatereferences sufficient to constitute full subordinate knowledge.

A context prefix is represented by a DSE of type cp . If the context prefix corresponds to an entry, the DSE typeincludes entry . If it corresponds to an alias, the DSE type includes alias. If the context prefix corresponds to anadministrative point, the DSE type includes admPoint .

The subtree of entries and subentries subordinate to the context prefix is represented by DSEs as described in 20.1 to20.4 of this Directory Specification.

The representation of the subordinate knowledge of the naming context is represented by DSEs as described in20.2.2 of this Directory Specification.

A replicated area (a shadow copy of all or part of a naming context) is represented as above except that the DSE typeincludes shadow in each DSE for which user or operational attributes are received from the shadow supplier. In thecase of incomplete replicated areas, DSEs of type glue may occur to represent a bridge between the separate piecesof the shadowed information. No user or operational attributes are associated with these (or any) glue DSEs.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 85

20.3.3 Example

Figure 15 illustrates an example of the mapping of a portion of the DIT (that corresponding to a naming context)onto the information tree of a DSA. In addition to the naming context information itself, the DSA’s root DSEcontaining its superior reference (this is not the DSA information tree for a first level DSA), a glue DSE and a DSErepresenting a reference (either a cross reference or an immediate superior reference) to an immediately superiornaming context are also depicted.

entry

othersubordinates

alias

object

entry

attributeknowledge

root + supr

glue

cp + entry

entry

DSE

xr (or immSupr)

entry

subr

entry + nssr

entry alias

object/alias

DIT Subtree corresponding toa Naming Context

DSA Information Tree for theNaming Context

Figure 15 - DSEs for a Naming Context

SECTION 10: DSA OPERATIONAL FRAMEWORK

21 Overview21.1 Definitions

21.1.1 directory operational framework: provides the framework from which specific operational modelsconcerned with particular aspects (e.g. shadowing or creating a naming context) of the operation of the componentsof the Directory (DSAs) may be derived by application of the framework. It factors out common elements which arepresent in all interactions between Directory components.

21.1.2 operational binding: a mutual understanding between two DSAs that, once established, expresses their“agreement” subsequently to engage in some sort of interaction.

21.1.3 operational binding type: a particular type of operational binding specified for some distinct purpose, thatexpresses the “agreement” of two DSAs to engage in specific types of interaction (e.g. shadowing).

21.1.4 operational binding instance: an operational binding of a specific type between two DSAs.

21.1.5 operational binding establishment: the process of establishing an operational binding instance.

21.1.6 operational binding modification : the process of modifying an operational binding instance.

21.1.7 operational binding termination : the process of terminating an operational binding instance.

ISO/IEC 9594-2 : 1993(E)

86 ITU-T Rec. X.501 (1993 E)

21.1.8 operational binding management : the process of establishing, terminating or modifying an instance of anoperational binding. This management may be achieved via information exchanges defined by DirectorySpecifications, via exchanges defined in other Specifications, or by other means.

21.1.9 cooperative state: with respect to a second DSA, the state of a DSA for which an operational bindinginstance has been established and has not been terminated.

21.1.10 non-cooperative state: with respect to a second DSA, the state of a DSA prior to the establishment or afterthe termination of an operational binding instance.

21.2 Introduction

The Directory Specifications define application protocol information exchanges and associated DSA procedures thatdefine the distributed operation of the Directory. Clauses 21 through 24 define a DSA operational framework whichmodels certain common elements in these information exchanges and procedures.

Two DSAs interact in a cooperative manner because, in addition to their technical capacity to exchange informationand perform procedures associated with these exchanges, each has been configured to accept certain interactionswith the other.

These clauses are concerned with the expression of a common framework for the specification of the structure of theelements of the cooperation between two DSAs.

One objective of this framework is that it be sufficiently general to account for all of the forms of DSA cooperationto be defined in this and future editions of the Directory Specifications. The framework is used within the DirectorySpecifications to define shadowing and hierarchical operational binding types.

22 Operational bindings22.1 General

This clause is concerned with the definition of a general framework, the DSA operational framework, within whichthe specification of the nature of the cooperative interactions of components of the Directory (DSAs) may bestructured in order to achieve a commonly agreed objective.

The general framework factors out common features which characterizes all interactions between DSAs. Byapplying the DSA operational framework to specific aspects of cooperative interaction between DSAs, the resultingspecifications will be both concise and consistent so that the overall number of mechanisms a DSA must supportwill be reduced.

The mutual understanding between two DSAs that, once established, expresses their “agreement” subsequently toengage in some sort of interaction is termed an operational binding. Two DSAs may share as many operationalbinding instances of a specific type as are required.

The DSA operational framework provides a common approach to the definition of an operational binding type . Anoperational binding type is a particular type of operational binding specified for some distinct purpose, thatexpresses the “agreement” of two DSAs to engage in specific types of interaction (e.g. shadowing). This interactionallows operations from a well defined set to be invoked by one or the other party to the agreement.

Two particular DSAs that have reached such an “agreement” share an operational binding instance of a specificoperational binding type. They are said to be in the cooperative state of that instance of an operational binding type.

Prior to the establishment or after the termination of an operational binding instance, two DSAs are said to be in thenon-cooperative state .

Operational binding management is the process of establishing, terminating or modifying an instance of anoperational binding. This management may be achieved via information exchanges defined by DirectorySpecifications, via exchanges defined in other Specifications, or by other means.

These general concepts are depicted in Figure 16.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 87

DSAB

DSAA

operational binding

agreement operations

initiation

Figure 16– An operational binding

22.2 Application of the operational framework

The application of the DSA operational framework to define an operational binding type is concerned with thefollowing basic elements:

a) two DSAs;

b) an “agreement” of the service that one DSA will provide to another DSA

c) a set of one or more operations, together with the accompanying procedures a DSA shall follow, throughwhich the service can be realized;

d) a specification of the DSA interactions needed to manage the agreement.

The relationship of these basic elements is expressed by an operational binding. An operational binding comprisesthe set of these basic elements that are involved to represent the abstract agreement in technical terms. It representsthe environment, governed by an “agreement”, in which one DSA provides a defined service to the other (and viceversa).

22.2.1 Two DSAs

The DSA operational framework provides a structure within which the interaction of one DSA with another and theprocedures they consequently execute may be specified.

The two DSAs may each play an identical role in the operational binding, in which case both DSAs may manage theoperational binding, both DSAs may invoke the same operations on each other, and both DSAs are constrained tofollow the same set of procedures. This is termed a symmetric operational binding.

Alternatively, each DSA may play a different role in the operational binding, so that different sets of operations andprocedures apply to each DSA. Either or both of the DSAs may be involved in managing the operational binding.This is termed an asymmetric operational binding.

22.2.2 The agreement

An “agreement” is a mutual understanding reached between the administrative authorities of two DSAs about aservice that shall be provided by one DSA to the other (and/or vice versa). The “agreement” is initially negotiated bythe administrative authorities of the DSAs by means outside of the scope of the Directory Specifications.

Parameters of this “agreement” can be formalized by the recording in a DSA of an ASN.1 data type for use in aprotocol exchange in the management of the operational binding. In this way both DSAs reach a mutualunderstanding of the service that each is providing to the other.

22.2.3 Operations

Operations are the basic medium that DSAs use to interact. A pair of DSAs will pass on one or more operationsbetween themselves, in order to provide the agreed to service.

ISO/IEC 9594-2 : 1993(E)

88 ITU-T Rec. X.501 (1993 E)

Whilst a DSA may be technically capable of supporting a large number of operations, it may only be willing tocooperate with another DSA in the processing of a small number of these operations, or in the processing ofoperations that only have particular values set for certain parameters.

The definition of an operational binding type requires the enumeration of the operations that can be exchanged. Italso allows restrictions to be placed on the values of parameters defined within the operations.

22.2.4 Management of the agreement

The framework provides generic operations for managing an instance of an operational binding. These operationsprovide for the establishment, modification and termination of an operational binding.

The application of the framework to the specification of a particular operational binding type, requires the initiatorof each of the three management operations to be specified and also requires the procedures to be defined for each ofestablishment, modification and termination. Whenever a management operation is applied to an operational bindingof the specified type, the DSA shall follow the corresponding procedure.

22.3 States of cooperation

The generic operational model defines two states of cooperation, as governed by an instance of a particularoperational binding type, between two DSAs as seen by one DSA with respect to the other DSA and three transitionsbetween these states. Each identified instance of an operational binding type shared by two DSAs has its own statesof cooperation. The states of cooperation are:

a) non-cooperative state: a particular identified instance of an operational binding type has not beenestablished or has been terminated between the two DSAs. The interaction between the two DSAs (withrespect to the identified instance of an operational binding type) is not defined. A DSA contacted byanother with whom it is in a non-cooperative state may, for example, refuse to engage in any interaction atall, or it may be prepared to service the request.

b) cooperative state: there is an instance of an operational binding of the type in question between the twoDSAs. Their cooperative behavior is governed by the definition of the operational binding type and itsspecific parameters and associated procedures.

The transitions between these two states of cooperation may be invoked in two ways: by standardized protocolinteractions or by other means.

The interactions between two DSAs to manage an instance of an operational binding (e.g. to establish and terminatea shadowing agreement) are distinct from their potential interactions as governed by the binding (e.g. the interactionto update a unit of replication).

The state transitions are as follows:

a) The establishment transition creates an instance of an operational binding of a particular type between twoDSAs, resulting in the movement from the non-cooperative to the cooperative state.

b) The termination transition destroys an instance of an operational binding of a particular type between twoDSAs, resulting in the movement from the cooperative to the non-cooperative state.

c) The modification transition modifies the parameters of an instance of an operational binding between twoDSAs, resulting in the movement from the cooperative state to the cooperative state.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 89

modification

terminationestablishment

cooperative

state

non-cooperativestate

Figure 17 – States of cooperation

These generic states and transitions are illustrated in Figure 17.

23 Operational binding specification and management23.1 Operational binding type specification

When applying the framework to define a specific type of operational binding, the following characteristics of thetype shall be specified:

a) symmetry

A specification of the respective roles of the DSAs that are party to the operational binding.

Operational bindings may be symmetric, in which case the role of one DSA is interchangeable with theother and both DSAs exhibit the same external interactions. They may also be asymmetric, in which caseeach DSA plays a distinct role and both DSAs exhibit different external interactions. In this latter case theDirectory operational framework distinguishes the two abstract roles as “ROLE-A” and “ROLE-B”.

Each of the abstract roles “ROLE-A” and “ROLE-B” have to be associated with a concrete role withdefined semantics (e.g. “ROLE-A” as shadow supplier, “ROLE-B” as shadow consumer).

b) agreement

A definition of the semantics and representation of the components of the “agreement”. This informationparameterizes the specific instance of an operational binding between two DSAs.

c) initiator

A definition which of the two abstract roles “ROLE-A” and “ROLE-B” is allowed to initiate theestablishment, modification or termination of an operational binding of this type.

d) management procedures

A set of procedures that a DSA shall follow when the operational binding of this type is established,modified or terminated.

e) type identification

This identifies the type of DSA interaction that is determined by the operational binding. These identifiersare object identifier values.

f) application-contexts, operations and procedures

This identifies the set of application-contexts whose operations (or a subset thereof) may be employedduring the co-operative phase of the operational binding.

For each operation referenced by the operational binding type a description of the procedures to befollowed by a DSA if the operation is invoked is required (this may be done by reference to another part ofthese Directory Specifications).

ISO/IEC 9594-2 : 1993(E)

90 ITU-T Rec. X.501 (1993 E)

For those operational bindings that are to be managed using the generic operational binding management operationsprovided in this clause, the binding type shall be specified using the three information object classesOPERATIONAL-BINDING, OP-BIND-COOP and OP-BIND-ROLE defined in this clause.

23.2 Operational binding management

In general, the management of an operational binding requires initially the establishment of an operational bindinginstance. This may optionally be followed by one or more modifications to some or all of the parameters of theinitial agreement, and finally may involve the termination of the operational binding instance. The precise details ofhow an instance may be managed are defined during the definition of the operational binding type. This typedefinition requires the specification of:

a) the initiator of each of the management operations (this can be either, both, or neither of the two DSAs);

b) the parameters for each of the management operations; and

c) the procedures that each DSA must follow for each of the management operations.

During the establishment of an operational binding instance, an operational binding instance identifier (binding id) iscreated. This identifier, when combined with the distinguished names of the two DSAs involved in the operationalbinding, will form a unique identifier for the binding instance. All management operations subsequent to theestablishment of the operational binding instance will use the binding id to identify which operational bindinginstance is being modified or terminated.

DSAB

DSAA

establish (a, p )A → B

error (a')

result (p )B → A

a — agreement p — establishment parameter

Figure 18 — DSA with Role A initiating establishment

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 91

DSAB

DSAA

establish (a, p )B → A

error (a')

result (p )A → B

a — agreement p — establishment parameter

Figure 19 — DSA with Role B initiating establishment

The initiator of the establish operation always transfers the parameters of the “agreement” to the second DSA. Inaddition the initiator may also transfer some establishment parameters which are specific to its role in the operationalbinding. If the responding DSA is willing to enter into the operational binding, it may return in the resultestablishment parameters which are specific to its role. If the responding DSA is unwilling to enter into theoperational binding, it shall return an error, which may optionally contain an agreement with a revised set ofparameters. This is depicted in Figure 18 in the case where role A and in Figure 19 in the case where role B is theinitiator of the establish operation.

23.3 Operational binding specification templates

For the definition of a specific type of operational binding the following three ASN.1 information object classes maybe used as templates. They allow those parts of the operational binding type that can be formalized to be specified bythe use of ASN.1. Other aspects of the operational binding type, such as the procedures a DSA has to follow whenan operational binding is established or terminated have to be specified by some other means (This can be done in amanner similar to the informal description of the DSA procedures during the name resolution process described inITU-T Rec. X.518 | ISO/IEC 9594-4).

23.3.1 Operational binding information object class

OPERATIONAL-BINDING ::= CLASS {&Agreement,&Cooperation OP-BINDING-COOP,&both OP-BIND-ROLE OPTIONAL,&roleA OP-BIND-ROLE OPTIONAL,&roleB OP-BIND-ROLE OPTIONAL,&id OBJECT IDENTIFIER UNIQUE }

WITH SYNTAX {AGREEMENT &AgreementAPPLICATION CONTEXTS &Cooperation[ SYMMETRIC &both ][ ASYMMETRIC

[ ROLE-A &roleA ][ ROLE-B &roleB ]]

ID &id}

The OPERATIONAL-BINDING information object class serves as a specification template for an operationalbinding type. A variable notation is defined for this class to simplify its use as a template. The correspondencebetween the definition of an operational binding type and the fields of the variable notation is as follows:

a. The ASN.1 type of the agreement parameter that is used for this type of operational binding is thatreferenced by the “AGREEMENT” field.

b. The application contexts and the operations of these application-contexts that are employed within the co-operation phase of an operational binding instance of the defined type are those enumerated following the

ISO/IEC 9594-2 : 1993(E)

92 ITU-T Rec. X.501 (1993 E)

“APPLICATION-CONTEXTS” field. All operations of a listed application-context are selected unless theoptional “APPLIES TO” field is present and followed by a list of references to operations that are selectedfrom the application context. This list is an object class set composed of instances of the OPERATIONinformation object class.

c. The class of the operational binding is defined by the “SYMMETRIC” or “ASYMMETRIC” fields. In thecase of a symmetric operational binding, the term “SYMMETRIC” is followed by a single informationobject of class OP-BIND-ROLE that is valid for both roles of the operational binding. In the case of anasymmetric operational binding, the term “ASYMMETRIC” is followed by two information objects ofclass OP-BIND-ROLE, one referenced by the subfield “ROLE-A” and the other by “ROLE-B”.

d. The object identifier value that serves to identify this type of operational binding is defined by the “ID”field.

23.3.2 Operational binding cooperation information object class

OP-BINDING-COOP ::= CLASS {&applContext APPLICATION-CONTEXT,&Operations OPERATION OPTIONAL }

WITH SYNTAX {&applContext[ APPLIES TO &Operations ]}

The OP-BIND-COOP information object class serves as a specification template for the identification of theoperations of a named application context, some aspect of which is determined by the operational binding. Aninstance of this class is meaningful only within the context of a particular operational binding type. A variablenotation is defined for this class to simplify its use as a template. The correspondence between the definition of anoperational binding type and the fields of the variable notation is as follows:

a. The applContext field identifies an application context, some or all of whose operations are in some waydetermined by an operational binding.

b. The “APPLIES TO” field, if present, identifies the particular operations to which the operational bindingapplies. If the field is absent, the operational binding applies to all the operations of the application context.

23.3.3 Operational binding role information object class

OP-BIND-ROLE ::= CLASS {&establish BOOLEAN DEFAULT FALSE,&EstablishParam OPTIONAL,&modify BOOLEAN DEFAULT FALSE,&ModifyParam OPTIONAL,&terminate BOOLEAN DEFAULT FALSE,&TerminateParam OPTIONAL }

WITH SYNTAX {[ ESTABLISHMENT-INITIATOR &establish ][ ESTABLISHMENT-PARAMETER &EstablishParam ][ MODIFICATION-INITIATOR &modify ][ MODIFICATION-PARAMETER &ModifyParam ][ TERMINATION-INITIATOR &terminate ][ TERMINATION-PARAMETER &TerminateParam ]}

The OP-BIND-ROLE information object class serves as a specification template for roles of an operational bindingtype. An instance of this class is meaningful only within the context of a particular operational binding type. Avariable notation is defined for this class to simplify its use as a template. The correspondence between the definitionof an operational binding role and the fields of the variable notation is as follows:

a. The “ESTABLISHMENT INITIATOR” field indicates whether the DSA assuming the defined role mayinitiate the establishment of an operational binding of a particular type.

b. The “ESTABLISHMENT PARAMETER” field defines the ASN.1 type exchanged by a DSA assuming thedefined role when an instance of the operational binding type is established.

c. The “MODIFICATION INITIATOR” field indicates whether the DSA assuming the defined role mayinitiate the modification of an operational binding of a particular type.

d. The “MODIFICATION PARAMETER” field defines the ASN.1 type exchanged by a DSA assuming thedefined role when an instance of the operational binding type is modified.

e. The “TERMINATION INITIATOR” field indicates whether the DSA assuming the defined role mayterminate the establishment of an operational binding of a particular type.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 93

f. The “TERMINATION PARAMETER” field defines the ASN.1 type exchanged by a DSA assuming thedefined role when an instance of the operational binding type is terminated.

24 Operations for operational binding managementThis clause defines a set of operations that can be used to establish, modify and terminate operational bindings ofvarious types. These operations are generic in the way that they can be used to manage operational bindings of anytype. The specification of these operations make use of the definitions provided for a certain type of operationalbinding by application of the OPERATIONAL-BINDING information object class template.

Note – By using this facility, arbitrary types of operational bindings may be managed. These operations (together with theassociated application-context) provide a means of extensibility concerning DSA interactions. New types of operationalbindings may be defined in the future which extend the functionality that is provided between DSAs.

24.1 Application-context definition

The set of operations for managing operational binding instances can be used for the definition of an applicationcontext in the following two ways:

1. An application-context may be constructed containing only the operations for operational bindingmanagement. An application context for generic operational binding management is defined in ITU-T Rec.X.519 | ISO/IEC 9594-5.

The operations that may be exchanged during the co-operative phase of the operational binding form one ormore separate application contexts.

2. The set of operations can be imported into the module used to define a specific application-context. Theoperational binding management operations can then be used together with the operations of the co-operative phase within a single application context.

Note – The first approach is useful in the case where a specialized component of a DSA wants to use an association solelyfor managing the set of operational bindings of that DSA, and it is not prepared to accept any of the operations defined forthe co-operative phase (e.g. updateShadow).

24.2 Establish Operational Binding operation

The Establish Operational Binding operation allows establishment of a operational binding instance of a pre-definedtype, between two DSAs. This is achieved through the transfer of the establishment parameters and the terms ofagreement which were defined in the definition of the operational binding type.

In the case of a symmetrical operational binding, either of the two DSAs may take the initiative to establish anoperational binding instance of the pre-defined type.

In the case of an asymmetrical operational binding, either the DSA assuming “ROLE-A” or “ROLE-B” establishesthe operational binding, depending on the specific definition of the operational binding type.

establishOperationalBinding OPERATION ::= {ARGUMENT EstablishOperationalBindingArgumentRESULT EstablishOperationalBindingResultERRORS {operationalBindingError | securityError}CODE id-op-establishOperationalBinding }

ISO/IEC 9594-2 : 1993(E)

94 ITU-T Rec. X.501 (1993 E)

EstablishOperationalBindingArgument ::= SEQUENCE {bindingType [0] OPERATIONAL-BINDING.&id ({OpBindingSet}),bindingID [1] OperationalBindingID OPTIONAL,accessPoint [2] AccessPoint,-- symmetric, role A initiates, or role B initiates --initiator CHOICE {

symmetric [3] OPERATIONAL-BINDING.&both.&EstablishParam({OpBindingSet}{@bindingType}),

roleA-initiates [4] OPERATIONAL-BINDING.&roleA.&EstablishParam({OpBindingSet}{@bindingType}),

roleB-initiates [5] OPERATIONAL-BINDING.&roleB.&EstablishParam({OpBindingSet}{@bindingType})} OPTIONAL,

agreement [6] OPERATIONAL-BINDING.&Agreement({OpBindingSet}{@bindingType}),

valid [7] Validity DEFAULT { } }

OpBindingSet OPERATIONAL-BINDING ::= {shadowOperationalBinding |hierarchicalOperationalBinding |nonSpecificHierarchicalOperationalBinding }

OperationalBindingID ::= SEQUENCE {identifier INTEGER,version INTEGER }

The component bindingType states which type of operational binding is to be established. Operational binding typesare defined by the use of the OPERATIONAL-BINDING information object class template which assigns an objectidentifier value to the operational binding type. The bindingType is taken from the “ID” field of one of the instancesof an operational binding type referenced by OpBindingSet . This set is a parameter ofEstablishOperationalBindingArgument , a parameterized type.

The initiating DSA may assign an identification to the operational binding instance via the bindingID component. IfbindingID is absent within the operation argument, the responding DSA shall assign an ID to the operational bindinginstance and return it in the bindingID component of the establishOperationalBindingResult . In either case, whenestablishing an operational binding both the identifier and version components of the OperationalBindingID valuemust be assigned and issued by the DSA making the assignment.

The component accessPoint specifies the access point of the initiator for subsequent interactions.

The role that the DSA issuing the Establish Operational Binding operation assumes is indicated by the CHOICE typewith the options symmetric, roleA-initiates , and roleB-initiates . The CHOICE option governs the particularestablishment parameters employed by the initiating and responding DSAs. The semantics of the roles are defined aspart of the definition of the operational binding type. The ASN.1 type of the CHOICE is determined by the“ESTABLISHMENT PARAMETER” of the initiator’s OP-BIND-ROLE information object class template. TheCHOICE type is omitted if establishment of the operational binding type requires no establishment parameter fromthe initiator.

The component agreement contains the terms of agreement governing the operational binding instance. Its actualcontent depends on the type of operational binding to be established. The ASN.1 type for this parameter is definedby the “AGREEMENT” field of the OPERATIONAl-BINDING information object class template of the operationalbinding type.

The duration that the operational binding instance shall exist is defined in valid . The starting time of the existence ofthe operational binding instance is specified in validFrom and the time that the operational binding instance isterminated is given in validUntil .

Validity ::= SEQUENCE {validFrom [0] CHOICE {

now [0] NULL,time [1] UTCTime } DEFAULT now : NULL,

validUntil [1] CHOICE {explicitTermination [0] NULL,time [1] UTCTime } DEFAULT explicitTermination : NULL }

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 95

If the Establish Operational Binding operation succeeds, the following result is returned:

EstablishOperationalBindingResult ::= SEQUENCE {bindingType [0] OPERATIONAL-BINDING.&id ({OpBindingSet}),bindingID [1] OperationalBindingID OPTIONAL,accessPoint [2] AccessPoint,-- symmetric, role A replies , or role B replies --initiator CHOICE {


roleA-replies [4] OPERATIONAL-BINDING.&roleA.&EstablishParam({OpBindingSet}{@bindingType}),

roleB-replies [5] OPERATIONAL-BINDING.&roleB.&EstablishParam({OpBindingSet}{@bindingType})} OPTIONAL}

The bindingType component is contained within the result to indicate the type of operational binding for use withinthe CHOICE element. Its value is the same as that provided by the establishment initiator and is taken from the “ID”field of one of the instances of an operational binding type referenced by OpBindingSet . This set is a parameter ofEstablishOperationalBindingResult , a parameterized type.

The identification of the established operational binding instance may be returned in bindingID . It shall be used toidentify this operational binding instance in any subsequent Modify or Terminate Operational Binding operation,and may be used in any other operation that is executed within the co-operative phase of the established operationalbinding instance.

Note – In the Terminate Operational Binding operation only the identifier component of OperationalBindingID is present.

The component accessPoint specifies the access point of the responder for subsequent interactions.

The initiating DSA may assign an identification to the operational binding instance via the bindingID component. IfbindingID is absent within the operation argument, the responding DSA shall assign an ID to the operational bindinginstance and return it in the bindingID component of the establishOperationalBindingResult .

The role that the DSA replying to the Establish Operational Binding operation assumes is indicated by the CHOICEtype with the options symmetric, roleA-initiates and roleB-initiates . The semantics of the roles are defined as partof the definition of the operational binding type. The ASN.1 type of the CHOICE is determined by the“ESTABLISHMENT PARAMETER” of the responder’s OP-BIND-ROLE information object class template. TheCHOICE type is omitted if establishment of the operational binding type requires no establishment parameter fromthe responder.

24.3 Modify Operational Binding operation

The Modify Operational Binding operation is used to modify an established operational binding. The right to modifyis indicated by the “MODIFICATION INITIATOR” field(s) within the definition of the operational binding typeusing the OP-BIND-ROLE and OPERATIONAL-BINDING information object class templates.

The components of an operational binding that can be modified are the content of the agreement for the operationalbinding and its period of validity. Further, a modification parameter can be specified by the initiating role.

modifyOperationalBinding OPERATION ::= {ARGUMENT ModifyOperationalBindingArgumentRESULT ModifyOperationalBindingResultERRORS { operationalBindingError | securityError }CODE id-op-modifyOperationalBinding }

ISO/IEC 9594-2 : 1993(E)

96 ITU-T Rec. X.501 (1993 E)

ModifyOperationalBindingArgument ::= SEQUENCE {bindingType [0] OPERATIONAL-BINDING.&id ({OpBindingSet}),bindingID [1] OperationalBindingID,accessPoint [2] AccessPoint OPTIONAL,-- symmetric, role A initiates, or role B initiates --initiator CHOICE {

symmetric [3] OPERATIONAL-BINDING.&both.&ModifyParam({OpBindingSet}{@bindingType}),

roleA-initiates [4] OPERATIONAL-BINDING.&roleA.&ModifyParam({OpBindingSet}{@bindingType}),

roleB-initiates [5] OPERATIONAL-BINDING.&roleB.&ModifyParam({OpBindingSet}{@bindingType})} OPTIONAL,

newBindingID [6] OperationalBindingID,newAgreement [7] OPERATIONAL-BINDING.&Agreement

({OpBindingSet}{@bindingType}),valid [8] Validity OPTIONAL}

The component bindingType states which type of operational binding is to be modified. The bindingType is takenfrom the “ID” field of one of the instances of an operational binding type referenced by OpBindingSet . This set is aparameter of ModifyOperationalBindingArgument , a parameterized type.

The identification of the operational binding instance to be modified is given by bindingID. The revised identifier ofthe operational binding instance is given by newBindingID . The version component of newBindingID must begreater than that of bindingID .

The optional component accessPoint is present if the initiator’s access point for subsequent interactions is to bechanged.

The role that the DSA issuing the Modify Operational Binding operation assumes is indicated by the CHOICE typewith the options symmetric, roleA-initiates and roleB-initiates . The semantics of the roles are defined as part of thedefinition of the operational binding type. The ASN.1 type of the CHOICE is determined by the “MODIFICATIONPARAMETER” of the initiator’s OP-BIND-ROLE information object class template. The CHOICE type is omitted ifmodification of the operational binding type requires no modification parameter from the initiator.

The component newAgreement, if present, contains the modified terms of agreement governing the operationalbinding instance. The ASN.1 type for this parameter is defined by the “AGREEMENT” field of theOPERATIONAL-BINDING information object class template of the operational binding type. If newAgreement isnot present, the parameters of the agreement are not changed by the operation.

The optional valid component may be used to indicate a revised period of validity for the altered agreement. If thevalid component is absent, the validFrom component is presumed to have the value now and the validUntilcomponent is assumed to be unchanged. If the validFrom component is present and refers to an instant of time in thefuture, the current agreement remains in effect until that time.

If the Modify Operational Binding operation succeeds, a NULL result is returned:

ModifyOperationalBindingResult ::= NULL

It is not possible for the responding DSA to return the modification parameter defined for its role to the modificationinitiator.

24.4 Terminate Operational Binding operation

The Terminate Operational Binding operation is used to request the termination of an established operationalbinding instance. The right to request termination is indicated by the “TERMINATION INITIATOR” field(s) withinthe definition of the operational binding type using the OP-BIND-ROLE and OPERATIONAL-BINDINGinformation object class templates.

terminateOperationalBinding OPERATION ::= {ARGUMENT TerminateOperationalBindingArgumentRESULT TerminateOperationalBindingResultERRORS {operationalBindingError | securityError}CODE id-op-terminateOperationalBinding }

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 97

TerminateOperationalBindingArgument ::= SEQUENCE {bindingType [0] OPERATIONAL-BINDING.&id ({OpBindingSet}),bindingID [1] OperationalBindingID,-- symmetric, role A initiates, or role B initiates --initiator CHOICE {

symmetric [2] OPERATIONAL-BINDING.&both.&TerminateParam({OpBindingSet}{@bindingType}),

roleA-initiates [3] OPERATIONAL-BINDING.&roleA.&TerminateParam({OpBindingSet}{@bindingType}),

roleB-initiates [4] OPERATIONAL-BINDING.&roleB.&TerminateParam({OpBindingSet}{@bindingType})} OPTIONAL,

terminateAt [5] UTCTime OPTIONAL}

The component bindingType states which type of operational binding is to be terminated. The bindingType is takenfrom the “ID” field of one of the instances of an operational binding type referenced by OpBindingSet . This set is aparameter of TerminateOperationalBindingArgument, a parameterized type.

The identification of the operational binding instance to be terminated is given by bindingID. Only the identifiercomponent of the bindingID need be supplied by the initiator. If the version component is present in the bindingID,it is ignored.

The role that the DSA issuing the Terminate Operational Binding operation assumes is indicated by the CHOICEtype with the options symmetric, roleA-initiates and roleB-initiates . The semantics of the roles are defined as partof the definition of the operational binding type. The ASN.1 type of the CHOICE is determined by the“TERMINATION PARAMETER” of the initiator’s OP-BIND-ROLE information object class template. TheCHOICE type is omitted if termination of the operational binding type requires no termination parameter from theinitiator.

If the operational binding is not to be terminated immediately, a delayed termination time can defined interminateAt .

If the Terminate Operational Binding operation succeeds, a NULL result is returned:

TerminateOperationalBindingResult ::= NULL

It is not possible for the responding DSA to return the termination parameter defined for its role to the terminationinitiator.

24.5 Operational Binding Error

An Operational Binding Error reports a problem related to the usage of operations for management of operationalbindings

operationalBindingError ERROR ::= {PARAMETER OpBindingErrorParamCODE id-err-operationalBindingError }

OpBindingErrorParam ::= SEQUENCE {problem [0] ENUMERATED {

invalidID (0),duplicateID (1),unsupportedBindingType (2),notAllowedForRole (3),parametersMissing (4),roleAssignment (5),invalidStartTime (6),invalidEndTime (7),invalidAgreement (8),currentlyNotDecidable (9),modificationNotAllowed (10)},

bindingType [1] OPERATIONAL-BINDING.&id ({OpBindingSet}) OPTIONAL,agreementProposal [2] OPERATIONAL-BINDING.&Agreement

({OpBindingSet}{@bindingType}) OPTIONAL,retryAt [3] UTCTime OPTIONAL }

ISO/IEC 9594-2 : 1993(E)

98 ITU-T Rec. X.501 (1993 E)

The values of problem have the following meanings:

a) invalidID: The operational binding ID given in the request is not known by the receiving DSA.

b) duplicateID: The operational binding ID given in the establishment request already exists at the responder.This may be caused by a prior attempt to establish an operational binding instance when the result was lostand initiator has repeated the establishment request.

c) unsupportedBindingType: The requested operational binding type is not supported by the DSA.

d) notAllowedForRole: A management operation on the operational binding instance has been requestedwhich is not allowed for the role that the requestor plays (e.g. a Terminate Operational Binding operationhas been issued by a DSA that takes a role which is not allowed to initiate the termination of the operationalbinding instance).

e) parametersMissing: Any required establishment or termination parameters that are defined for the type ofoperational binding are missing.

f) roleAssignment: The requested role assignment for an asymmetric operational binding instance has notbeen accepted.

g) invalidStartTime: The specified starting time for the operational binding instance has not been accepted.

h) invalidEndTime: The specified termination time for the operational binding instance has not been accepted.

i) invalidAgreement: The terms of agreement for the requested operational binding instance have not beenaccepted. The terms of agreement that would be accepted by the responding DSA can be returned inagreementProposal.

j) currentlyNotDecidable: The DSA is not able to decide on-line about the establishment or modification ofthe requested operational binding instance. A time when the request should be repeated can be given inretryAt.

k) modificationNotAllowed : The Modify Operational Binding operation is rejected since modification is notpermitted for this binding instance.

The bindingType component shall be the same as that transmitted by the invoker of the failed operational bindingmanagement operation.

The agreementProposal component shall only be used in response to an EstablishOperationalBinding operationto propose a revised set of agreement parameters as described in 23.2.

The retryAt component shall be used only in conjunction with the problem value currentlyNotDecidable toindicate a time when the EstablishOperationalBinding or ModifyOperationalBinding operation should be retried.

24.6 Operational Binding Management Bind and Unbind

The DSAOperationalBindingManagementBind and DSAOperationalBindingManagementUnBind operations,defined in 24.6.1 and 24.6.2, are used by a DSA at the beginning and end of a particular period of operationalbinding management activity.

24.6.1 DSA Operational Binding Management Bind

A dSAOperationalBindingManagementBind operation is used to begin a period of operational bindingmanagement.

dSAOperationalBindingManagementBind OPERATION ::= directoryBind

The components of the dSAOperationalManagementBind are identical to their counterparts in directoryBind (seeITU-T Rec. X.511 | ISO/IEC 9594-3) with the following differences.

24.6.1.1 Initiator Credentials

The Credentials of the DirectoryBindArgument allows information identifying the AE-Title of the initiating DSAto be sent to the responding DSA. The AE-title shall be in the form of a Directory Distinguished Name.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 99

24.6.1.2 Responder Credentials

The Credentials of the DirectoryBindResult allows information identifying the AE-Title of the responding DSA tobe sent to the initiating DSA. The AE-title shall be in the form of a Distinguished Name.

24.6.2 DSA Operational Binding Management Unbind

A dSAOperationalManagementUnbind operation is used to end a period of providing operational bindingmanagement.

dSAOperationalBindingManagementUnbind OPERATION ::= directoryUnbind

There are no arguments, results or errors.

ISO/IEC 9594-2 : 1993(E)

100 ITU-T Rec. X.501 (1993 E)

Annex A — Object identifier usage(This annex forms an integral part of this Recommendation | International Standard)

This annex documents the upper reaches of the object identifier subtree in which all of the object identifiers assignedin the Directory Specifications reside. It does so by providing an ASN.1 module called “UsefulDefinitions” inwhich all non-leaf nodes in the subtree are assigned names.

UsefulDefinitions {joint-iso-ccitt ds(5) module(1) usefulDefinitions(0) 2}DEFINITIONS ::=BEGIN

-- EXPORTS All --

-- The types and values defined in this module are exported for use in the other ASN.1 modules contained-- within the Directory Specifications, and for the use of other applications which will use them to access-- Directory services. Other applications may use them for their own purposes, but this will not constrain-- extensions and modifications needed to maintain or improve the Directory service.

ID ::= OBJECT IDENTIFIER

ds ID ::= {joint-iso-ccitt ds(5)}

-- categories of information object --

module ID ::= {ds 1}serviceElement ID ::= {ds 2}applicationContext ID ::= {ds 3}attributeType ID ::= {ds 4}attributeSyntax ID ::= {ds 5}objectClass ID ::= {ds 6}-- attributeSet ID ::= {ds 7}algorithm ID ::= {ds 8}abstractSyntax ID ::= {ds 9}-- object ID ::= {ds 10}-- port ID ::= {ds 11}dsaOperationalAttribute ID ::= {ds 12}matchingRule ID ::= {ds 13}knowledgeMatchingRule ID ::= {ds 14}nameForm ID ::= {ds 15}group ID ::= {ds 16}subentry ID ::= {ds 17}operationalAttributeType ID ::= {ds 18}operationalBinding ID ::= {ds 19}schemaObjectClass ID ::= {ds 20}schemaOperationalAttribute ID ::= {ds 21}administrativeRoles ID ::= {ds 23}accessControlAttribute ID ::= {ds 24}rosObject ID ::= {ds 25}contract ID ::= {ds 26}package ID ::= {ds 27}accessControlSchemes ID ::= {ds 28}

-- modules --

usefulDefinitions ID ::= {module usefulDefinitions(0) 2}informationFramework ID ::= {module informationFramework(1) 2}directoryAbstractService ID ::= {module directoryAbstractService(2) 2}distributedOperations ID ::= {module distributedOperations(3) 2}protocolObjectIdentifiers ID ::= {module protocolObjectIdentifiers (4) 2}selectedAttributeTypes ID ::= {module selectedAttributeTypes(5) 2}selectedObjectClasses ID ::= {module selectedObjectClasses(6) 2}

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 101

authenticationFramework ID ::= {module authenticationFramework(7) 2}algorithmObjectIdentifiers ID ::= {module algorithmObjectIdentifiers(8) 2}directoryObjectIdentifiers ID ::= {module directoryObjectIdentifiers(9) 2}upperBounds ID ::= {module upperBounds(10) 2}dap ID ::= {module dap(11) 2}dsp ID ::= {module dsp(12) 2}distributedDirectoryOIDs ID ::= {module distributedDirectoryOIDs(13) 2}directoryShadowOIDs ID ::= {module directoryShadowOIDs(14) 2}directoryShadowAbstractService ID ::= {module directoryShadowAbstractService(15) 2}disp ID ::= {module disp(16) 2}dop ID ::= {module dop(17) 2}opBindingManagement ID ::= {module opBindingManagement(18) 2}opBindingOIDs ID ::= {module opBindingOIDs(19) 2}hierarchicalOperationalBindings ID ::= {module hierarchicalOperationalBindings(20) 2}

dsaOperationalAttributeTypes ID ::= {module dsaOperationalAttributeTypes(22) 2}schemaAdministration ID ::= {module schemaAdministration(23) 2}basicAccessControl ID ::= {module basicAccessControl(24) 2}directoryOperationalBindingTypes

ID ::= {module directoryOperationalBindingTypes(25) 2}

-- synonyms --

id-oc ID ::= objectClassid-at ID ::= attributeTypeid-as ID ::= abstractSyntaxid-mr ID ::= matchingRuleid-nf ID ::= nameFormid-sc ID ::= subentryid-oa ID ::= operationalAttributeTypeid-ob ID ::= operationalBindingid-doa ID ::= dsaOperationalAttributeid-kmr ID ::= knowledgeMatchingRuleid-soc ID ::= schemaObjectClassid-soa ID ::= schemaOperationalAttributeid-ar ID ::= administrativeRolesid-aca ID ::= accessControlAttributeid-ac ID ::= applicationContextid-rosObject ID ::= rosObjectid-contract ID ::= contractid-package ID ::= packageid-acScheme ID ::= accessControlSchemes

-- obsolete module identifiers --

-- usefulDefinitions ID ::= {module 0}-- informationFramework ID ::= {module 1}-- directoryAbstractService ID ::= {module 2}-- distributedOperations ID ::= {module 3}-- protocolObjectIdentifiers ID ::= {module 4}-- selectedAttributeTypes ID ::= {module 5}-- selectedObjectClasses ID ::= {module 6}-- authenticationFramework ID ::= {module 7}-- algorithmObjectIdentifiers ID ::= {module 8}-- directoryObjectIdentifiers ID ::= {module 9}-- upperBounds ID ::= {module 10}-- dap ID ::= {module 11}-- dsp ID ::= {module 12}-- distributedDirectoryObjectIdentifiers

ID ::= {module 13}

ISO/IEC 9594-2 : 1993(E)

102 ITU-T Rec. X.501 (1993 E)

-- unused module identifiers --

-- directoryShadowOIDs ID ::= {module 14}-- directoryShadowAbstractService ID ::= {module 15}-- disp ID ::= {module 16}-- dop ID ::= {module 17}-- opBindingManagement ID ::= {module 18}-- opBindingOIDs ID ::= {module 19}-- hierarchicalOperationalBindings ID ::= {module 20}

-- dsaOperationalAttributeTypes ID ::= {module 22}-- schemaAdministration ID ::= {module 23}-- basicAccessControl ID ::= {module 24}-- operationalBindingOIDs ID ::= {module 25}

END

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 103

Annex B — Information Framework in ASN.1(This annex forms an integral part of this Recommendation | International Standard)

This annex provides a summary of all of the ASN.1 type, value and macro definitions contained in this DirectorySpecification. The definitions form the ASN.1 module InformationFramework .

InformationFramework {joint-iso-ccitt ds(5) module(1) informationFramework(1) 2}DEFINITIONS ::=BEGIN

-- EXPORTS All --


IMPORTSid-oc, id-at, id-mr, id-oa, id-sc, id-ar, selectedAttributeTypes

FROM UsefulDefinitions {joint-Iso-ccitt-ds(5) module(1) usefulDefinitions(0) 2}

generalizedTimeMatch, generalizedTimeOrderingMatchFROM SelectedAttributeTypes selectedAttributeTypes ;

-- attribute data types --

Attribute ::= SEQUENCE {type AttributeType ({SupportedAttributes}),values SET SIZE (1 .. MAX) OF AttributeValue ({SupportedAttributes}{@type})}

AttributeType ::= ATTRIBUTE.&id

AttributeValue ::= ATTRIBUTE.&Type

AssertionValue ::= ATTRIBUTE.&equality-match.&AssertionType

AttributeTypeAndValue ::= SEQUENCE {type AttributeType ({SupportedAttributes}),value AttributeValue ({SupportedAttributes}{@type})}

AttributeValueAssertion ::= SEQUENCE {type AttributeType ({SupportedAttributes}),assertion AssertionValue ({SupportedAttributes}{@type})}

-- Definition of the following information object set is deferred, perhaps to standardized-- profiles or to protocol implementation conformance statements. The set is required to-- specify a table constraint on the values component of Attribute, the value component-- of AttributeTypeAndValue , and the assertion component of AttributeValueAssertion .

-- SupportedAttributes ATTRIBUTE ::=-- { id-at-objectClass | id-at-aliasedEntryName | ... }

-- naming data types --

Name ::= CHOICE { - - only one possibility for now - -rdnSequence RDNSequence }

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

DistinguishedName ::= RDNSequence

RelativeDistinguishedName ::= SET SIZE (1 .. MAX) OF AttributeTypeAndValue

ISO/IEC 9594-2 : 1993(E)

104 ITU-T Rec. X.501 (1993 E)

-- subtree data types --

SubtreeSpecification ::= SEQUENCE {base [0] LocalName DEFAULT { },COMPONENTS OF ChopSpecification,specificationFilter [4] Refinement OPTIONAL }-- empty set specifies whole administrative area

LocalName ::= RDNSequence

ChopSpecification ::= SEQUENCE {specificExclusions [1] SET OF CHOICE {

chopBefore [0] LocalName,chopAfter [1] LocalName } OPTIONAL,

minimum [2] BaseDistance DEFAULT 0,maximum [3] BaseDistance OPTIONAL }

BaseDistance ::= INTEGER (0 .. MAX)

Refinement ::= CHOICE {item [0] OBJECT-CLASS.&id,and [1] SET OF Refinement ,or [2] SET OF Refinement,not [3] Refinement }

-- OBJECT-CLASS information object class specification --

OBJECT-CLASS ::= CLASS {&Superclasses OBJECT-CLASS OPTIONAL,&kind ObjectClassKind DEFAULT structural,&MandatoryAttributes ATTRIBUTE OPTIONAL,&OptionalAttributes ATTRIBUTE OPTIONAL,&id OBJECT IDENTIFIER UNIQUE }

WITH SYNTAX {[ SUBCLASS OF &Superclasses ][ KIND &kind][ MUST CONTAIN &MandatoryAttributes ][ MAY CONTAIN &OptionalAttributes ]ID &id }

ObjectClassKind ::= ENUMERATED {abstract (0),structural (1),auxiliary (2) }

-- object classes --

top OBJECT-CLASS ::= {KIND abstractMUST CONTAIN { objectClass }ID id-oc-top }

alias OBJECT-CLASS ::= {SUBCLASS OF { top }MUST CONTAIN { aliasedEntryName }ID id-oc-alias }

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 105

-- ATTRIBUTE information object class specification --

ATTRIBUTE ::= CLASS {&derivation ATTRIBUTE OPTIONAL,&Type OPTIONAL, -- either &Type or &derivation required --&equality-match MATCHING-RULE OPTIONAL,&ordering-match MATCHING-RULE OPTIONAL,&substrings-match MATCHING-RULE OPTIONAL,&single-valued BOOLEAN DEFAULT FALSE,&collective BOOLEAN DEFAULT FALSE,-- operational extensions --&no-user-modification BOOLEAN DEFAULT FALSE,&usage AttributeUsage DEFAULT userApplications,&id OBJECT IDENTIFIER UNIQUE }

WITH SYNTAX {[ SUBTYPE OF &derivation ][ WITH SYNTAX &Type ][ EQUALITY MATCHING RULE &equality-match ][ ORDERING MATCHING RULE &ordering-match ][ SUBSTRINGS MATCHING RULE &substrings-match ][ SINGLE VALUE &single-valued ][ COLLECTIVE &collective ][ NO USER MODIFICATION &no-user-modification ][ USAGE &usage ]ID &id }

AttributeUsage ::= ENUMERATED {userApplications (0),directoryOperation (1),distributedOperation (2),dSAOperation (3) }

-- attributes --

objectClass ATTRIBUTE ::= {WITH SYNTAX OBJECT IDENTIFIEREQUALITY MATCHING RULE objectIdentifierMatchID id-at-objectClass }

aliasedEntryName ATTRIBUTE ::= {WITH SYNTAX DistinguishedNameEQUALITY MATCHING RULE distinguishedNameMatchSINGLE VALUE TRUEID id-at-aliasedEntryName }

-- MATCHING-RULE information object class specification --

MATCHING-RULE ::= CLASS {&AssertionType OPTIONAL,&id OBJECT IDENTIFIER UNIQUE }

WITH SYNTAX {[ SYNTAX &AssertionType ]ID &id}

-- matching rules --

objectIdentifierMatch MATCHING-RULE ::= {SYNTAX OBJECT IDENTIFIERID id-mr-objectIdentifierMatch }

distinguishedNameMatch MATCHING-RULE ::= {SYNTAX DistinguishedNameID id-mr-distinguishedNameMatch }

ISO/IEC 9594-2 : 1993(E)

106 ITU-T Rec. X.501 (1993 E)

-- NAME-FORM information object class specification --

NAME-FORM ::= CLASS {&namedObjectClass OBJECT-CLASS,&MandatoryAttributes ATTRIBUTE,&OptionalAttributes ATTRIBUTE OPTIONAL,&id OBJECT IDENTIFIER UNIQUE }

WITH SYNTAX {NAMES &namedObjectClassWITH ATTRIBUTES &MandatoryAttributes[ AND OPTIONALLY &OptionalAttributes ]ID &id }

-- STRUCTURE-RULE class and DIT structure rule data types --

STRUCTURE-RULE ::= CLASS {&nameForm NAME-FORM,&SuperiorStructureRules STRUCTURE-RULE OPTIONAL,&id RuleIdentifier UNIQUE }

WITH SYNTAX {[ NAME FORM &nameForm ][ SUPERIOR RULES &SuperiorStructureRules ]ID &ruleIdentifier }

DITStructureRule ::= SEQUENCE {ruleIdentifier RuleIdentifier ,

-- must be unique within the scope of the subschemanameForm NAME-FORM.&id,superiorStructureRules SET OF RuleIdentifier OPTIONAL }

RuleIdentifier ::= INTEGER

-- CONTENT-RULE class and DIT content rule data types --

CONTENT-RULE ::= CLASS {&structuralClass OBJECT-CLASS.&id UNIQUE,&Auxiliaries OBJECT-CLASS OPTIONAL,&Mandatory ATTRIBUTE OPTIONAL,&Optional ATTRIBUTE OPTIONAL,&Precluded ATTRIBUTE OPTIONAL }

WITH SYNTAX {STRUCTURAL OBJECT-CLASS &structuralClass[ AUXILIARY OBJECT-CLASSES &Auxiliaries ][ MUST CONTAIN &Mandatory ][ MAY CONTAIN &Optional ][ MUST NOT CONTAIN &Precluded ] }

DITContentRule ::= SEQUENCE {structuralObjectClass OBJECT-CLASS.&id,auxiliaries SET OF OBJECT-CLASS.&id OPTIONAL,mandatory [1] SET OF ATTRIBUTE.&id OPTIONAL,optional [2] SET OF ATTRIBUTE.&id OPTIONAL,precluded [3] SET OF ATTRIBUTE.&id OPTIONAL }

-- system schema information objects --


subentry OBJECT-CLASS ::= {SUBCLASS OF { top }KIND structuralMUST CONTAIN { commonName | subtreeSpecification }ID id-sc-subentry }

accessControlSubentry OBJECT-CLASS ::= {KIND auxiliaryID id-sc-accessControlSubentry }

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 107

collectiveAttributeSubentry OBJECT-CLASS ::= {KIND auxiliaryID id-sc-collectiveAttributeSubentry }

-- attributes --

createTimestamp ATTRIBUTE ::= {WITH SYNTAX GeneralizedTime

-- as per clause 34.3 b) and c) of CCITT Rec. X.208 | ISO/IEC 8824-1EQUALITY MATCHING RULE generalizedTimeMatchORDERING MATCHING RULE generalizedTimeOrderingMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE directoryOperationID id-oa-createTimestamp }

modifyTimestamp ATTRIBUTE ::= {WITH SYNTAX GeneralizedTime

-- as per clause 34.3 b) and c) of CCITT Rec. X.208 | ISO/IEC 8824-1EQUALITY MATCHING RULE generalizedTimeMatchORDERING MATCHING RULE generalizedTimeOrderingMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE directoryOperationID id-oa-modifyTimestamp }

creatorsName ATTRIBUTE ::= {WITH SYNTAX DistinguishedNameEQUALITY MATCHING RULE distinguishedNameMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE directoryOperationID id-oa-creatorsName }

modifiersName ATTRIBUTE ::= {WITH SYNTAX DistinguishedNameEQUALITY MATCHING RULE distinguishedNameMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE directoryOperationID id-oa-modifiersName }

administrativeRole ATTRIBUTE ::= {WITH SYNTAX OBJECT-CLASS.&idEQUALITY MATCHING RULE objectIdentifierMatchUSAGE directoryOperationID id-oa-administrativeRole }

subtreeSpecification ATTRIBUTE ::= {WITH SYNTAX SubtreeSpecificationSINGLE VALUE TRUEUSAGE directoryOperationID id-oa-subtreeSpecification }

collectiveExclusions ATTRIBUTE ::= {WITH SYNTAX OBJECT IDENTIFIEREQUALITY MATCHING RULE objectIdentifierMatchUSAGE directoryOperationID id-oa-collectiveExclusions }

-- object identifier assignments --


id-oc-top OBJECT IDENTIFIER ::= {id-oc 0}id-oc-alias OBJECT IDENTIFIER ::= {id-oc 1}

ISO/IEC 9594-2 : 1993(E)

108 ITU-T Rec. X.501 (1993 E)

-- attributes --

id-at-objectClass OBJECT IDENTIFIER ::= {id-at 0}id-at-aliasedEntryName OBJECT IDENTIFIER ::= {id-at 1}


id-mr-objectIdentifierMatch OBJECT IDENTIFIER ::= {id-mr 0}id-mr-distinguishedNameMatch OBJECT IDENTIFIER ::= {id-mr 1}

-- operational attributes --

id-oa-excludeAllCollectiveAttributes OBJECT IDENTIFIER ::= {id-oa 0}id-oa-createTimestamp OBJECT IDENTIFIER ::= {id-oa 1}id-oa-modifyTimestamp OBJECT IDENTIFIER ::= {id-oa 2}id-oa-creatorsName OBJECT IDENTIFIER ::= {id-oa 3}id-oa-modifiersName OBJECT IDENTIFIER ::= {id-oa 4}id-oa-administrativeRole OBJECT IDENTIFIER ::= {id-oa 5}id-oa-subtreeSpecification OBJECT IDENTIFIER ::= {id-oa 6}id-oa-collectiveExclusions OBJECT IDENTIFIER ::= {id-oa 7}

-- subentry classes --

id-sc-subentry OBJECT IDENTIFIER ::= {id-sc 0}id-sc-accessControlSubentry OBJECT IDENTIFIER ::= {id-sc 1}id-sc-collectiveAttributeSubentry OBJECT IDENTIFIER ::= {id-sc 2}

-- administrative roles --

id-ar-autonomousArea OBJECT IDENTIFIER ::= {id-ar 1}id-ar-accessControlSpecificArea OBJECT IDENTIFIER ::= {id-ar 2}id-ar-accessControlInnerArea OBJECT IDENTIFIER ::= {id-ar 3}id-ar-subschemaAdminSpecificArea OBJECT IDENTIFIER ::= {id-ar 4}id-ar-collectiveAttributeSpecificArea OBJECT IDENTIFIER ::= {id-ar 5}id-ar-collectiveAttributeInnerArea OBJECT IDENTIFIER ::= {id-ar 6}

END

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 109

Annex C — SubSchema Administration Schema in ASN.1(This annex forms an integral part of this Recommendation | International Standard)

This annex contains the ASN.1 type, value and information object definitions for subschema administration in theform of an ASN.1 module, SchemaAdministration .

SchemaAdministration {joint-iso-ccitt ds(5) module(1) schemaAdministration(23) 2}DEFINITIONS ::=BEGIN

-- EXPORTS All --


IMPORTSinformationFramework, selectedAttributeTypes, upperBounds, id-soc, id-soa

FROM UsefulDefinitions {joint-iso-ccitt ds(5) module(1) usefulDefinitions(0) 2}

OBJECT-CLASS, ATTRIBUTE, MATCHING-RULE, DITStructureRule, DITContentRule,ObjectClassKind, AttributeUsage, NAME-FORM, objectIdentifierMatch

FROM InformationFramework informationFramework

DirectoryString {}, integerFirstComponentMatch, integerMatch,objectIdentifierFirstComponentMatch

FROM SelectedAttributeTypes selectedAttributeTypes

ub-schemaFROM UpperBounds upperBounds ;

-- types --

DITStructureRuleDescription ::= SEQUENCE {COMPONENTS OF DITStructureRule,name [1] SET OF DirectoryString { ub-schema } OPTIONAL,description DirectoryString { ub-schema } OPTIONAL,obsolete BOOLEAN DEFAULT FALSE }

DITContentRuleDescription ::= SEQUENCE {COMPONENTS OF DITContentRule,name [4] SET OF DirectoryString { ub-schema } OPTIONAL,description DirectoryString { ub-schema }OPTIONAL,obsolete BOOLEAN DEFAULT FALSE}

MatchingRuleDescription ::= SEQUENCE {identifier MATCHING-RULE.&id,name SET OF DirectoryString { ub-schema } OPTIONAL,description DirectoryString { ub-schema } OPTIONAL,obsolete BOOLEAN DEFAULT FALSE,information [0] DirectoryString { ub-schema } }

-- describes the ASN.1 syntax

AttributeTypeDescription ::= SEQUENCE {identifier ATTRIBUTE.&id,name SET OF DirectoryString { ub-schema } OPTIONAL,description DirectoryString { ub-schema } OPTIONAL,obsolete BOOLEAN DEFAULT FALSE,information [0] AttributeTypeInformation }

ISO/IEC 9594-2 : 1993(E)

110 ITU-T Rec. X.501 (1993 E)

AttributeTypeInformation ::= SEQUENCE {derivation [0] ATTRIBUTE.&id OPTIONAL,equalityMatch [1] MATCHING-RULE.&id OPTIONAL,orderingMatch [2] MATCHING-RULE.&id OPTIONAL,substringsMatch [3] MATCHING-RULE.&id OPTIONAL,attributeSyntax [4] DirectoryString { ub-schema } OPTIONAL,multi-valued [5] BOOLEAN DEFAULT TRUE,collective [6] BOOLEAN DEFAULT FALSE,userModifiable [7] BOOLEAN DEFAULT TRUE,application AttributeUsage OPTIONAL }

ObjectClassDescription ::= SEQUENCE {identifier OBJECT-CLASS.&id,name SET OF DirectoryString { ub-schema } OPTIONAL,description DirectoryString { ub-schema } OPTIONAL,obsolete BOOLEAN DEFAULT FALSE,information [0] ObjectClassInformation }

ObjectClassInformation ::= SEQUENCE {subclassOf SET OF OBJECT-CLASS.&id OPTIONAL,kind ObjectClassKind DEFAULT structural,mandatories [3] SET OF ATTRIBUTE.&id OPTIONAL,optionals [4] SET OF ATTRIBUTE.&id OPTIONAL }

NameFormDescription ::= SEQUENCE {identifier NAME-FORM.&id,name SET OF DirectoryString { ub-schema } OPTIONAL,description DirectoryString { ub-schema } OPTIONAL,obsolete BOOLEAN DEFAULT FALSE,information [0] NameFormInformation }

NameFormInformation ::= SEQUENCE {subordinate OBJECT-CLASS.&id,namingMandatories SET OF ATTRIBUTE.&id,namingOptionals SET OF ATTRIBUTE.&id OPTIONAL }

MatchingRuleUseDescription ::= SEQUENCE {identifier MATCHING-RULE.&id,name SET OF DirectoryString { ub-schema } OPTIONAL,description DirectoryString { ub-schema } OPTIONAL,obsolete BOOLEAN DEFAULT FALSE,information [0] SET OF ATTRIBUTE.&id }


subschema OBJECT-CLASS ::= {KIND auxiliaryMAY CONTAIN {

dITStructureRules |nameForms |dITContentRules |objectClasses |attributeTypes |matchingRules |matchingRuleUse }

ID id-soc-subschema }

-- attributes --

dITStructureRules ATTRIBUTE ::= {WITH SYNTAX DITStructureRuleDescriptionEQUALITY MATCHING RULE integerFirstComponentMatchUSAGE directoryOperationID id-soa-dITStructureRule }

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 111

dITContentRules ATTRIBUTE ::= {WITH SYNTAX DITContentRuleDescriptionEQUALITY MATCHING RULE objectIdentifierFirstComponentMatchUSAGE directoryOperationID id-soa-dITContentRules }

matchingRules ATTRIBUTE ::= {WITH SYNTAX MatchingRuleDescriptionEQUALITY MATCHING RULE objectIdentifierFirstComponentMatchUSAGE directoryOperationID id-soa-matchingRules }

attributeTypes ATTRIBUTE ::= {WITH SYNTAX AttributeTypeDescriptionEQUALITY MATCHING RULE objectIdentifierFirstComponentMatchUSAGE directoryOperationID id-soa-attributeTypes }

objectClasses ATTRIBUTE ::= {WITH SYNTAX ObjectClassDescriptionEQUALITY MATCHING RULE objectIdentifierFirstComponentMatchUSAGE directoryOperationID id-soa-objectClasses }

nameForms ATTRIBUTE ::= {WITH SYNTAX NameFormDescriptionEQUALITY MATCHING RULE objectIdentifierFirstComponentMatchUSAGE directoryOperationID id-soa-nameForms }

matchingRuleUse ATTRIBUTE ::= {WITH SYNTAX MatchingRuleUseDescriptionEQUALITY MATCHING RULE objectIdentifierFirstComponentMatchUSAGE directoryOperationID id-soa-matchingRuleUse }

structuralObjectClass ATTRIBUTE ::= {WITH SYNTAX OBJECT IDENTIFIEREQUALITY MATCHING RULE objectIdentifierMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE directoryOperationID id-soa-structuralObjectClass }

governingStructureRule ATTRIBUTE ::= {WITH SYNTAX INTEGEREQUALITY MATCHING RULE integerMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE directoryOperationID id-soa-governingStructureRule }


-- schema object classes --

id-soc-subschema OBJECT IDENTIFIER ::= {id-soc 1}

ISO/IEC 9594-2 : 1993(E)

112 ITU-T Rec. X.501 (1993 E)

-- schema operational attributes --

id-soa-dITStructureRule OBJECT IDENTIFIER ::= {id-soa 1}id-soa-dITContentRules OBJECT IDENTIFIER ::= {id-soa 2}id-soa-matchingRules OBJECT IDENTIFIER ::= {id-soa 4}id-soa-attributeTypes OBJECT IDENTIFIER ::= {id-soa 5}id-soa-objectClasses OBJECT IDENTIFIER ::= {id-soa 6}id-soa-nameForms OBJECT IDENTIFIER ::= {id-soa 7}id-soa-matchingRuleUse OBJECT IDENTIFIER ::= {id-soa 8}id-soa-structuralObjectClass OBJECT IDENTIFIER ::= {id-soa 9}id-soa-governingStructureRule OBJECT IDENTIFIER ::= {id-soa 10}

END

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 113

Annex D — Basic Access Control in ASN.1(This annex forms an integral part of this Recommendation | International Standard)

This annex provides a summary of all of the ASN.1 type and value definitions for Basic Access Control. Thedefinitions form the ASN.1 module BasicAccessControl .

BasicAccessControl {joint-iso-ccitt ds(5) module(1) basicAccessControl(24) 2}DEFINITIONS ::=BEGIN

-- EXPORTS All --


IMPORTSid-aca, id-acScheme, informationFramework, upperBounds, selectedAttributeTypes


ATTRIBUTE, AttributeType, AttributeTypeAndValue, DistinguishedName, SubtreeSpecification,MATCHING-RULE, objectIdentifierMatch

FROM InformationFramework informationFramework

ub-tagFROM UpperBounds upperBounds

UniqueIdentifier, NameAndOptionalUID, directoryStringFirstComponentMatch,DirectoryString

FROM SelectedAttributeTypes selectedAttributeTypes ;

-- types --

ACIItem ::= SEQUENCE {identificationTag DirectoryString { ub-tag },precedence Precedence,authenticationLevel AuthenticationLevel,itemOrUserFirst CHOICE {

itemFirst [0] SEQUENCE {protectedItems ProtectedItems,itemPermissions SET OF ItemPermission },

userFirst [1] SEQUENCE {userClasses UserClasses,userPermissions SET OF UserPermission }}}

Precedence ::= INTEGER (0..255)

ProtectedItems ::= SEQUENCE {entry [0] NULL OPTIONAL,allUserAttributeTypes [1] NULL OPTIONAL,attributeType [2] SET OF AttributeType OPTIONAL,allAttributeValues [3] SET OF AttributeType OPTIONAL,allUserAttributeTypesAndValues [4] NULL OPTIONAL,attributeValue [5] SET OF AttributeTypeAndValue OPTIONAL,selfValue [6] SET OF AttributeType OPTIONAL }

ISO/IEC 9594-2 : 1993(E)

114 ITU-T Rec. X.501 (1993 E)

UserClasses ::= SEQUENCE {allUsers [0] NULL OPTIONAL,thisEntry [1] NULL OPTIONAL,name [2] SET OF NameAndOptionalUID OPTIONAL,userGroup [3] SET OF NameAndOptionalUID OPTIONAL,

-- dn component must be the name of an-- entry of GroupOfUniqueNames

subtree [4] SET OF SubtreeSpecification OPTIONAL}

ItemPermission ::= SEQUENCE {precedence Precedence OPTIONAL,

-- defaults to precedence in ACIItem --userClasses UserClasses,grantsAndDenials GrantsAndDenials }

UserPermission ::= SEQUENCE {precedence Precedence OPTIONAL,

-- defaults to precedence in ACIItemprotectedItems ProtectedItems,grantsAndDenials GrantsAndDenials }

AuthenticationLevel ::= CHOICE {basicLevels SEQUENCE {

level ENUMERATED { none (0), simple (1), strong (2) },localQualifier INTEGER OPTIONAL},

other EXTERNAL }

GrantsAndDenials ::= BIT STRING {-- permissions that may be used in conjunction with-- with any component of ProtectedItemsgrantAdd (0),denyAdd (1),grantDiscloseOnError (2),denyDiscloseOnError (3),grantRead (4),denyRead (5),grantRemove (6),denyRemove (7),-- permissions that may be used only in conjunction-- with the entry componentgrantBrowse (8),denyBrowse (9),grantExport (10),denyExport (11),grantImport (12),denyImport (13),grantModify (14),denyModify (15),grantRename (16),denyRename (17),grantReturnDN (18),denyReturnDN (19),-- permissions that may be used in conjunction-- with any component, except entry, of ProtectedItemsgrantCompare (20),denyCompare (21),grantFilterMatch (22),denyFilterMatch (23) }

-- attributes --

accessControlScheme ATTRIBUTE ::= {WITH SYNTAX OBJECT IDENTIFIEREQUALITY MATCHING RULE objectIdentifierMatchSINGLE VALUE TRUEUSAGE directoryOperationID id-aca-accessControlScheme }

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 115

prescriptiveACI ATTRIBUTE ::= {WITH SYNTAX ACIItemEQUALITY MATCHING RULE directoryStringFirstComponentMatchUSAGE directoryOperationID id-aca-prescriptiveACI }

entryACI ATTRIBUTE ::= {WITH SYNTAX ACIItemEQUALITY MATCHING RULE directoryStringFirstComponentMatchUSAGE directoryOperationID id-aca-entryACI }

subentryACI ATTRIBUTE ::= {WITH SYNTAX ACIItemEQUALITY MATCHING RULE directoryStringFirstComponentMatchUSAGE directoryOperationID id-aca-subentryACI }


-- attributes --

id-aca-accessControlScheme OBJECT IDENTIFIER ::= { id-aca 1 }id-aca-prescriptiveACI OBJECT IDENTIFIER ::= { id-aca 4 }id-aca-entryACI OBJECT IDENTIFIER ::= { id-aca 5 }id-aca-subentryACI OBJECT IDENTIFIER ::= { id-aca 6 }

-- access control schemes --

basicAccessControlScheme OBJECT IDENTIFIER ::= { id-acScheme 1 }simplifiedAccessControlScheme OBJECT IDENTIFIER ::= { id-acScheme 2 }

END

ISO/IEC 9594-2 : 1993(E)

116 ITU-T Rec. X.501 (1993 E)

Annex E — DSA Operational Attribute Types in ASN.1(This annex forms an integral part of this Recommendation | International Standard)

This annex includes all of the ASN.1 type and value definitions contained in clauses 10 through 20 of this DirectorySpecification in the form of an ASN.1 module, DSAOperationalAttributeTypes.

DSAOperationalAttributeTypes {joint-iso-ccitt ds(5) module(1) dsaOperationalAttributeTypes(22) 2}DEFINITIONS ::=BEGIN

-- EXPORTS All --


IMPORTSid-doa, id-kmr, informationFramework, distributedOperations, opBindingManagement,selectedAttributeTypes

FROM UsefulDefinitions {joint-iso-ccitt ds(5) module(1) usefulDefinitions(0) 2 }

ATTRIBUTE, MATCHING-RULE, NameFROM InformationFramework informationFramework

OperationalBindingIDFROM OperationalBindingMangement opBindingManagement

AccessPoint, MasterAndShadowAccessPointsFROM DistributedOperations distributedOperations

bitStringMatchFROM SelectedAttributeTypes selectedAttributeTypes ;

-- data types --

DSEType ::= BIT STRING {root (0), --root DSE --glue (1), -- represents knowledge of a name only --cp (2), -- context prefix --entry (3), -- object entry --alias (4), -- alias entry --subr (5), -- subordinate reference --nssr (6), -- non-specific subordinate reference --supr (7), -- superior reference --xr (8), -- cross reference --admPoint (9), -- administrative point --subentry (10), -- subentry --shadow (11), -- shadow copy --immSupr (13), -- immediate superior reference --rhob (14), -- rhob information --sa (15)} -- subordinate reference to alias entry --

SupplierOrConsumer ::= SET {COMPONENTS OF AccessPoint, -- supplier or consumer --agreementID [3] OperationalBindingID }

SupplierInformation ::= SET {COMPONENTS OF SupplierOrConsumer, -- supplier --supplier-is-master [4] BOOLEAN DEFAULT TRUE,non-supplying-master [5] AccessPoint OPTIONAL }

ConsumerInformation ::= SupplierOrConsumer -- consumer --

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 117

SupplierAndConsumers ::= SET {COMPONENTS OF AccessPoint, -- supplier --consumers [3] SET OF AccessPoint }

-- attribute types --

dseType ATTRIBUTE ::= {WITH SYNTAX DSETypeEQUALITY MATCHING RULE bitStringMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE dSAOperationID id-doa-dseType }

myAccessPoint ATTRIBUTE ::= {WITH SYNTAX AccessPointEQUALITY MATCHING RULE accessPointMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE dSAOperationID id-doa-myAccessPoint }

superiorKnowledge ATTRIBUTE ::= {WITH SYNTAX AccessPointEQUALITY MATCHING RULE accessPointMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE dSAOperationID id-doa-superiorKnowledge }

specificKnowledge ATTRIBUTE ::= {WITH SYNTAX MasterAndShadowAccessPointsEQUALITY MATCHING RULE masterAndShadowAccessPointsMatchSINGLE VALUE TRUENO USER MODIFICATION TRUEUSAGE distributedOperationID id-doa-specificKnowledge }

nonSpecificKnowledge ATTRIBUTE ::= {WITH SYNTAX MasterAndShadowAccessPointsEQUALITY MATCHING RULE masterAndShadowAccessPointsMatchNO USER MODIFICATION TRUEUSAGE distributedOperationID id-doa-nonSpecificKnowledge }

supplierKnowledge ATTRIBUTE ::= {WITH SYNTAX SupplierInformationEQUALITY MATCHING RULE supplierOrConsumerInformationMatchNO USER MODIFICATION TRUEUSAGE dSAOperationID id-doa-supplierKnowledge }

consumerKnowledge ATTRIBUTE ::= {WITH SYNTAX ConsumerInformationEQUALITY MATCHING RULE supplierOrConsumerInformationMatchNO USER MODIFICATION TRUEUSAGE dSAOperationID id-doa-consumerKnowledge }

secondaryShadows ATTRIBUTE ::= {WITH SYNTAX SupplierAndConsumersEQUALITY MATCHING RULE supplierAndConsumersMatchNO USER MODIFICATION TRUEUSAGE dSAOperationID id-doa-secondaryShadows }

ISO/IEC 9594-2 : 1993(E)

118 ITU-T Rec. X.501 (1993 E)


accessPointMatch MATCHING-RULE ::= {SYNTAX NameID id-kmr-accessPointMatch }

masterAndShadowAccessPointsMatch MATCHING-RULE ::= {SYNTAX SET OF NameID id-kmr-masterShadowMatch }

supplierOrConsumerInformationMatch MATCHING-RULE ::= {SYNTAX SET {

ae-title [0] Name,agreement-identifier [2] INTEGER }

ID id-kmr-supplierConsumerMatch }

supplierAndConsumersMatch MATCHING-RULE ::= {SYNTAX NameID id-kmr-supplierConsumersMatch }


-- dsa operational attributes --

id-doa-dseType OBJECT IDENTIFIER ::= {id-doa 0}id-doa-myAccessPoint OBJECT IDENTIFIER ::= {id-doa 1}id-doa-superiorKnowledge OBJECT IDENTIFIER ::= {id-doa 2}id-doa-specificKnowledge OBJECT IDENTIFIER ::= {id-doa 3}id-doa-nonSpecificKnowledge OBJECT IDENTIFIER ::= {id-doa 4}id-doa-supplierKnowledge OBJECT IDENTIFIER ::= {id-doa 5}id-doa-consumerKnowledge OBJECT IDENTIFIER ::= {id-doa 6}id-doa-secondaryShadows OBJECT IDENTIFIER ::= {id-doa 7}

-- knowledge matching rules --

id-kmr-accessPointMatch OBJECT IDENTIFIER ::= {id-kmr 0}id-kmr-masterShadowMatch OBJECT IDENTIFIER ::= {id-kmr 1}id-kmr-supplierConsumerMatch OBJECT IDENTIFIER ::= {id-kmr 2}id-kmr-supplierConsumersMatch OBJECT IDENTIFIER ::= {id-kmr 3}

END

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 119

Annex F — Operational Binding Management in ASN.1(This annex forms an integral part of the Recommendation | International Standard)

This annex includes all of the ASN.1 type, value and information object class definitions regarding OperationalBindings relevant to this Directory Specification in the form of the ASN.1 moduleOperationalBindingManagement.

OperationalBindingManagement {joint-iso-ccitt ds(5) module(1) opBindingManagement(18) 2}DEFINITIONS ::=BEGIN

-- EXPORTS All --


IMPORTSdirectoryShadowAbstractService, hierarchicalOperationalBindings,dop, directoryAbstractService, distributedOperations


shadowOperationalBindingFROM DirectoryShadowAbstractService directoryShadowAbstractService

hierarchicalOperationalBinding, nonSpecificHierarchicalOperationalBindingFROM HierarchicalOperationalBindings hierarchicalOperationalBindings

OPERATION, ERRORFROM Remote-Operations-Information-Objects

{joint-iso-ccitt remote-operations(4) informationObjects(5) version1(0)}

APPLICATION-CONTEXTFROM Remote-Operations-Information-Objects-extension {joint-iso-ccitt

remote-operations(4) informationObjects-extension(8) version1(0)}

id-op-establishOperationalBinding, id-op-modifyOperationalBinding,id-op-terminateOperationalBinding, id-err-operationalBindingError

FROM DirectoryOperationalBindingManagementProtocol dop

directoryBind, directoryUnbindFROM DirectoryAbstractService directoryAbstractService

AccessPointFROM DistributedOperations distributedOperations ;

-- bind and unbind --

dSAOperationalBindingManagementBind OPERATION ::= directoryBind

dSAOperationalBindingManagementUnbind OPERATION ::= directoryUnbind

-- operations, arguments, and results --

establishOperationalBinding OPERATION ::= {ARGUMENT EstablishOperationalBindingArgumentRESULT EstablishOperationalBindingResultERRORS {operationalBindingError | securityError}CODE id-op-establishOperationalBinding }

ISO/IEC 9594-2 : 1993(E)

120 ITU-T Rec. X.501 (1993 E)

EstablishOperationalBindingArgument ::= SEQUENCE {bindingType [0] OPERATIONAL-BINDING.&id ({OpBindingSet}),bindingID [1] OperationalBindingID OPTIONAL,accessPoint [2] AccessPoint,-- symmetric, role A initiates, or role B initiates --initiator CHOICE {


roleA-initiates [4] OPERATIONAL-BINDING.&roleA.&EstablishParam({OpBindingSet}{@bindingType}),

roleB-initiates [5] OPERATIONAL-BINDING.&roleB.&EstablishParam({OpBindingSet}{@bindingType})} OPTIONAL,

agreement [6] OPERATIONAL-BINDING.&Agreement({OpBindingSet}{@bindingType}),

valid [7] Validity DEFAULT { } }

OperationalBindingID ::= SEQUENCE {identifier INTEGER,version INTEGER }

Validity ::= SEQUENCE {validFrom [0] CHOICE {

now [0] NULL,time [1] UTCTime } DEFAULT now : NULL,

validUntil [1] CHOICE {explicitTermination [0] NULL,time [1] UTCTime } DEFAULT explicitTermination : NULL }

EstablishOperationalBindingResult ::= SEQUENCE {bindingType [0] OPERATIONAL-BINDING.&id ({OpBindingSet}),bindingID [1] OperationalBindingID OPTIONAL,accessPoint [2] AccessPoint,-- symmetric, role A replies , or role B replies --initiator CHOICE {


roleA-replies [4] OPERATIONAL-BINDING.&roleA.&EstablishParam({OpBindingSet}{@bindingType}),

roleB-replies [5] OPERATIONAL-BINDING.&roleB.&EstablishParam({OpBindingSet}{@bindingType})} OPTIONAL}

modifyOperationalBinding OPERATION ::= {ARGUMENT ModifyOperationalBindingArgumentRESULT ModifyOperationalBindingResultERRORS { operationalBindingError | securityError }CODE id-op-modifyOperationalBinding }

ModifyOperationalBindingArgument ::= SEQUENCE {bindingType [0] OPERATIONAL-BINDING.&id ({OpBindingSet}),bindingID [1] OperationalBindingID,accessPoint [2] AccessPoint OPTIONAL,-- symmetric, role A initiates, or role B initiates --initiator CHOICE {

symmetric [3] OPERATIONAL-BINDING.&both.&ModifyParam({OpBindingSet}{@bindingType}),

roleA-initiates [4] OPERATIONAL-BINDING.&roleA.&ModifyParam({OpBindingSet}{@bindingType}),

roleB-initiates [5] OPERATIONAL-BINDING.&roleB.&ModifyParam({OpBindingSet}{@bindingType})} OPTIONAL,

newBindingID [6] OperationalBindingID,newAgreement [7] OPERATIONAL-BINDING.&Agreement

({OpBindingSet}{@bindingType}),valid [8] Validity OPTIONAL}

ModifyOperationalBindingResult ::= NULL

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 121

terminateOperationalBinding OPERATION ::= {ARGUMENT TerminateOperationalBindingArgumentRESULT TerminateOperationalBindingResultERRORS {operationalBindingError | securityError}CODE id-op-terminateOperationalBinding }

TerminateOperationalBindingArgument ::= SEQUENCE {bindingType [0] OPERATIONAL-BINDING.&id ({OpBindingSet}),bindingID [1] OperationalBindingID,-- symmetric, role A initiates, or role B initiates --initiator CHOICE {

symmetric [2] OPERATIONAL-BINDING.&both.&TerminateParam({OpBindingSet}{@bindingType}),

roleA-initiates [3] OPERATIONAL-BINDING.&roleA.&TerminateParam({OpBindingSet}{@bindingType}),

roleB-initiates [4] OPERATIONAL-BINDING.&roleB.&TerminateParam({OpBindingSet}{@bindingType})} OPTIONAL,

terminateAt [5] UTCTime OPTIONAL}

TerminateOperationalBindingResult ::= NULL

-- errors and parameters --

operationalBindingError ERROR ::= {PARAMETER OpBindingErrorParamCODE id-err-operationalBindingError }

OpBindingErrorParam ::= SEQUENCE {problem [0] ENUMERATED {

invalidID (0),duplicateID (1),unsupportedBindingType (2),notAllowedForRole (3),parametersMissing (4),roleAssignment (5),invalidStartTime (6),invalidEndTime (7),invalidAgreement (8),currentlyNotDecidable (9),modificationNotAllowed (10)},

bindingType [1] OPERATIONAL-BINDING.&id ({OpBindingSet}) OPTIONAL,agreementProposal [2] OPERATIONAL-BINDING.&Agreement

({OpBindingSet}{@bindingType}) OPTIONAL,retryAt [3] UTCTime OPTIONAL }

-- information object classes --

OPERATIONAL-BINDING ::= CLASS {&Agreement,&Cooperation OP-BINDING-COOP,&both OP-BIND-ROLE OPTIONAL,&roleA OP-BIND-ROLE OPTIONAL,&roleB OP-BIND-ROLE OPTIONAL,&id OBJECT IDENTIFIER UNIQUE }

WITH SYNTAX {AGREEMENT &AgreementAPPLICATION CONTEXTS &Cooperation[ SYMMETRIC &both ][ ASYMMETRIC

[ ROLE-A &roleA ][ ROLE-B &roleB ]]

ID &id}

ISO/IEC 9594-2 : 1993(E)

122 ITU-T Rec. X.501 (1993 E)

OP-BINDING-COOP ::= CLASS {&applContext APPLICATION-CONTEXT,&Operations OPERATION OPTIONAL }

WITH SYNTAX {&applContext[ APPLIES TO &Operations ]}

OP-BIND-ROLE ::= CLASS {&establish BOOLEAN DEFAULT FALSE,&EstablishParam OPTIONAL,&modify BOOLEAN DEFAULT FALSE,&ModifyParam OPTIONAL,&terminate BOOLEAN DEFAULT FALSE,&TerminateParam OPTIONAL }

WITH SYNTAX {[ ESTABLISHMENT-INITIATOR &establish ][ ESTABLISHMENT-PARAMETER &EstablishParam ][ MODIFICATION-INITIATOR &modify ][ MODIFICATION-PARAMETER &ModifyParam ][ TERMINATION-INITIATOR &terminate ][ TERMINATION-PARAMETER &TerminateParam ]}

OpBindingSet OPERATIONAL-BINDING ::= {shadowOperationalBinding |hierarchicalOperationalBinding |nonSpecificHierarchicalOperationalBinding }

END

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 123

Annex G — The Mathematics of Trees(This annex does not form an integral part of this Recommendation | International Standard)

V1

V2 V3

V4 V5 V6

V7

a1 a2

a3 a4 a5

a6

A tree is a set of points, called vertices, and a set of directed lines, called arcs ; each arc a leads from a vertex V to avertex V’. For example, the tree in the figure has seven vertices; labelled V1 through V7, and six arcs, labelled a1

through a6.

Two vertices V and V’ are said to be the initial and final vertices, respectively, of an arc a from V to V’. Forexample, V2 and V3 are the initial and final vertices, respectively, of arc a2 . Several different arcs may have thesame initial vertex, but not the same final vertex. For example, arcs a1 and a3 have the same initial vertex, V1, butno two arcs in the figure have the same final vertex.

The vertex that is not the final vertex of any arc is often referred to as the root vertex, or even more informally as the“root” of the tree. For example, in the figure, V1 is the root.

A vertex that is not the initial vertex of any arc is often referred to informally as a leaf vertex, or even moreinformally, as a “leaf” of the tree graph. For example, vertices V3, V6, and V7 are leaves.

An oriented path from a vertex V to a vertex V’ is a set of arcs (a1, a2, ..., an) (n ≥ 1) such that V is the initial vertexof arc a1, V’ is the final vertex of arc an, and the final vertex of arc ak is also the initial vertex of arc ak+1 for 1 ≤ k <n. For example, the oriented path from vertex V1 to vertex V6 is the set of arcs (a3 , a4, a5). The term “path” shouldbe understood to denote an oriented path from the root to a vertex.

ISO/IEC 9594-2 : 1993(E)

124 ITU-T Rec. X.501 (1993 E)

Annex H — Name Design Criteria(This annex does not form an integral part of this Recommendation | International Standard)

The information framework is very general, and allows for arbitrary variety of entries and attributes within the DIT.Since, as defined there, names are closely related to paths through the DIT, this means that arbitrary variety in namesis possible. This annex suggests criteria to be considered in the design of names. The appropriate criteria have beenused in the design of the recommended name forms which are to be found in ITU-T Rec. X.521 | ISO/IEC 9594-7. Itis suggested that the criteria also be used, where appropriate, in designing the names for objects to which therecommended name forms do not apply.

Presently, only one criterion is addressed; that of user-friendliness.

Note - Not all names need to be user-friendly.

The remainder of this annex discusses the concept of user friendliness applied to names.

Names with which human beings must deal directly should be user-friendly. A user-friendly name is one that takesthe human user’s point of view, not the computer’s. It is one that is easy for people to deduce, remember, andunderstand, rather than one that is easy for computers to interpret.

The goal of user-friendliness can be stated somewhat more precisely in terms of the following two principles:

— A human being usually should be able to correctly guess an object’s user-friendly name on the basis ofinformation about the object that he naturally possesses. For example, one should be able to guess abusiness person’s name given only the information about her casually acquired through normal businessassociation.

— When a object’s name is ambiguously specified, the Directory should recognize that fact rather thanconclude that the name identifies one particular object. For example, where two people have the same lastname, the last name alone should be considered inadequate identification of either party.

The following subgoals follow from the goal of user-friendliness:

a) Names should not artificially remove natural ambiguities. For example, if two people share the last name“Jones”, neither should be required to answer to “WJones” or “Jones2”. Instead, the naming conventionshould provide a user-friendly means of discriminating between the entities. For example, it might requirefirst name and middle initial in addition to last name.

b) Names should admit common abbreviations and common variations in spelling. For example, if one isemployed by the Conway Steel Corporation and the name of one’s employer figures in one’s name, any ofthe names “Conway Steel Corporation”, “Conway Steel Corp.”, “Conway Steel”, and “CSC” should sufficeto identify the organization in question.

c) In certain cases, alias names can be used: to direct the search for a particular entry, in order to be more user-friendly, or to reduce the scope of a search. The following example demonstrates the use of an alias namefor such a purpose: As shown in figure H-1, the branch office in Osaka can also be identified with the name{ C = Japan, L = Osaka, O = ABC, OU = Osaka-branch }.

d) If names are multi-part, both the number of mandatory parts and the number of optional parts should berelatively small and thus easy to remember.

e) If names are multi-part, the precise order in which those parts appear should generally be immaterial.

f) User-friendly names should not involve computer addresses.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 125

C=Japan

L=Osaka L=Tokyo

O=ABC O=ABC

OU=Osaka-branch

Figure H–1 — Aliasing Example

ISO/IEC 9594-2 : 1993(E)

126 ITU-T Rec. X.501 (1993 E)

Annex J— Examples of various aspects of schema(This annex does not form an integral part of this Recommendation | International Standard)

J.1 Example of an Attribute Hierarchy

Figure J-1 shows a simple hierarchy of values of a generic telephoneNumber attribute, values of which arerepresented as contained in the outer set. Two specific attribute types are derived from the generic type,workTelephoneNumber and homeTelephoneNumber. Values of these types are represented as contained in theinner sets.

A value of type homeTelephoneNumber is contained in both the inner set representing homeTelephoneNumberand the outer set representing telephoneNumber , but not the inner set representing workTelephoneNumber values.

A DIT structure rule could be defined which permits entries to contain values of all three types shown in Figure J-1.Another rule could be defined permitting entries to contain only values of type telephoneNumber.

TT

T

T

T T

T

T

T

homeTelephoneNumber

workTelephoneNumber

TelephoneNumber

T a value having telephoneNumberSyntax

Figure J-1 — Hierarchy of Telephone Number Attribute Values.

J.2 Example of a Subtree Specification

The following is an example illustrating the specification of subtrees. Consider the portion of the DIT represented inFigure J-2.

Subtree 1 and subtree 2 are specified with respect to the administrative point having name a. The identifiers b1, c2,d3, etc. represent local name values with respect to the administrative point a.

Subtree 1 may be specified as:

subtree1 SubtreeSpecification ::= {specficExclusions { chopBefore b1 }}

Subtree 2 may be specified as:

subtree2 SubtreeSpecification ::={base b1 }

Suppose that the entries identified in the figure with local names e1, e2, etc. represent organizational person entries.A subtree refinement could be specified to include all of these entries in the administrative area as:

subtree-refinement1 SubtreeSpecification ::= {specificationFilter

item id-oc-organizationalPerson }

This could be further refined to include only the organizational persons in subtree 2 as:

subtree2-refinement SubtreeSpecification ::= {base b1,specificationFilter

item id-oc-organizationalPerson }

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 127

e1 e2

e5

d1 d2 d3 d4

b1 b2 b3

d6d5 d8d7

c1 c2

a

subtree 1

subtree 2

d10 e6

e4e3

c3

d9

subtree refinement 1

AA

AP

Figure J-2 — Subtree Specification Example

J.3 Schema Specification

J.3.1 Object Classes and Name Forms

The following object classes, defined in ITU-T Rec. X.521 | ISO/IEC 9594-7, are used within a particularsubschema administrative area:

— organization;

— organizationalUnit;

— organizationalPerson.

A name form is not required for the administrative entry, which will be the only entry in the subschema of objectclass organization . The following name forms, defined in ITU-T Rec. X.521 | ISO/IEC 9594-7, are used to includeentries of class organizationalUnit and organizationalPerson:

— orgNameForm;

— orgUnitNameForm ;

— orgPersonNameForm .

J.3.2 DIT Structure Rules

The following structure rules are defined to specify a tree structure as shown in Figure J–3. Figure J–3 illustrateswhich rule may be used to add entries at the various points in the DIT.

rule-0 STRUCTURE-RULE::= {NAME FORM orgNameFormID 0 }

rule-1 STRUCTURE-RULE::= {NAME FORM orgUnitNameFormSUPERIOR RULES { rule-0 }ID 1 }

rule-2 STRUCTURE-RULE::= {NAME FORM orgUniNameFormSUPERIOR RULES { rule-1 }ID 2 }

rule-3 STRUCTURE-RULE::= {NAME FORM orgUniNameFormSUPERIOR RULES { rule-2 }ID 3 }

ISO/IEC 9594-2 : 1993(E)

128 ITU-T Rec. X.501 (1993 E)

rule-4 STRUCTURE-RULE::= {NAME FORM orgPersonNameFormSUPERIOR RULES { rule-1, rule-2, rule-3 }ID 4 }

Organization

OrganizationalUnit

OrganizationalUnit

OrganizationalUnit

OrganizationalPerson

Rule #1

Rule #2

Rule #3

Rule #4



Rule #4

Rule #4

Figure J–3 — Example Subschema.

J.4 DIT content rules

The subschema administrator has the following two requirements to add supplemental information to entries in thesubschema administrative area:

— a l l organizationalPerson and organizationalUnit en t r i e s shou ld have theorganizationalTelephoneNumber attribute. This attribute should be returned when the Directory isqueried for telephoneNumbers;

— all organizationalPerson entries will have the new attribute manager.

The following attribute types are defined to meet these requirements:

manager ATTRIBUTE ::= {WITH SYNTAX BOOLEANEQUALITY MATCHING RULE booleanMatchSINGLE VALUE TRUEID id-ex-managerAttribute }

organizationalTelephoneNumber ATTRIBUTE ::= {SUBTYPE OF telephoneNumberCOLLECTIVE TRUEID id-ex-organizationalTelephoneNumber }

The following DIT content rules are defined to meet these requirements:

organizationRule CONTENT-RULE ::= {STRUCTURAL OBJECT CLASS organization }

organizationalUnitRule CONTENT-RULE ::= {STRUCTURAL OBJECT CLASS organizationalUnitMAY CONTAIN { organizationalTelephoneNumber } }

organizationalPersonRule CONTENT-RULE ::= {STRUCTURAL OBJECT CLASS organizationalPersonMUST CONTAIN { manager }MAY CONTAIN { organizationalTelephoneNumber }}

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 129

Annex K — Overview of Basic Access Control Permissions(This annex does not form an integral part of this Recommendation | International Standard)

K.1 Introduction

This annex is informative and is intended to provide an overview of the meaning of various combinations ofoperations, protected items, and permission categories. In cases where there is a perceived difference between thisoverview and the specification provided in the body of this amendment, the normative text in the body shall bedefinitive.

Table K-1 relates Directory operations to the entry and attribute access controls to provide an overview of thepermission categories that must be granted in order to allow the operation to succeed.

Table K-2 provides an overview of the returnDN and discloseOnError permission categories and how grants anddenials relate to various protocol elements.

Table K-3 provides an overview of the semantics associated with grants and denials of entry access controls.

Table K-4 provides an overview of the semantics associated with grants and denials of attribute access controls.

ISO/IEC 9594-2 : 1993(E)

130 ITU-T Rec. X.501 (1993 E)

Table K-1 — Directory information permissions required according to Directory operation

DirectoryOperation

Entry Protected Item PermissionsRequired

Attribute And Attribute Value Protected ItemPermissions Required

Compare Read Compare for attribute being comparedcompare for attribute value being compared

Read Read Read for any attribute type information returnedRead for any attribute values returned

List Browse and ReturnDN for allsubordinate entries for which an RDN isreturned

none

Search Browse for entries in the search scopethat are potential candidates forselection

FilterMatch for attribute type and value information,if any, used to evaluate a filter item as TRUE orFALSE

Read for any attribute type information returnedRead for any attribute values returned

Add Entry Add Add for all attribute types specifiedAdd for all attribute values specified

RemoveEntry

Remove none

Modify Entry Modify Add for all attributes being addedAdd for all attribute values being addedRemove for attributes being removedRemove for all attribute values being removed

ModifyDN Rename at the original location if onlythe last RDN is changed

Export to move a subtree from theoriginal location

Import to relocate a subtree at thedestination location

none

Table K-2 — Permissions affecting error and name return

Protocol Elements Affected Meaning

ReturnDN EntryInformationCompareResultListResultSearchResultNameErrorContinuationReference

If granted, may return actual Distinguished Name.

If denied, prohibits return of actual DistinguishedName. By local policy, a valid alias name may bereturned instead.

DiscloseOnError NameErrorUpdateErrorAttributeErrorSecurityError

If granted, permits return an error that may disclosethat the protected item exists.

If denied, requires the Directory to conceal theexistence of the protected item.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 131

Table K-3 — Entry level permissions and meaning

Permission Meaning

Read If granted, allows Directory Read or Compare operations on the entry, but does not, by itself,authorize return of any attribute information from that entry

If denied, prevents Read or Compare operations on the entry

Browse If granted, permits the entry to participate as a candidate for selection in the scope of a List orSearch operation

If denied, excludes that entry from the scope of any Search or List operation

Add If granted, permits the entry itself, exclusive of its attributes, to be added. Add is onlymeaningful as prescriptive ACI

If denied, prevents addition of the entry

Modify If granted, permits Modify operations on the entry.

If denied, prevents Modify operations on the entry.

Remove If granted, permits the entry to be removed, irrespective of any attribute considerations.

If denied, prevents removal of the entry.

Rename If granted, allows the RDN of the entry to be changed, and, optionally, an old value removedand a new value added, irrespective of attribute or attribute value protection that might beapplicable to that entry, by means of a ModifyDN operation subject to Import and Exportpermissions as appropriate.

If denied, prevents the RDN of the entry from being changed.

Import If granted, allows entries, including all subordinates, to be relocated at the designated locationin the DIT in a ModifyDN operation. Import is only meaningful as prescriptive ACI.

If denied, prevents relocation of an entry with subordinates at the indicated point in the DITusing a ModifyDN operation.

Export If granted, permits a ModifyDN operation to relocate the entry, including all subordinates, to adesignated point someplace else in the DIT. The requestor must have import permission at thetarget location.

If denied, prevents relocation of the entry and its subordinates in a single ModifyDN operation.

ReturnDN If granted, permits return of the Distinguished Name of entry in an operation result.

If denied, prohibits return of distinguished name. By local policy, a valid alias name may bereturned instead

DiscloseOnError If granted, permits return of an error that may disclose existance of the entry.

If denied, requires the Directory to conceal existance of the entry. DiscloseOnError , of itself,does not deny ability to detect the entry by other means for which the appropriate permissionsare granted.

ISO/IEC 9594-2 : 1993(E)

132 ITU-T Rec. X.501 (1993 E)

Table K-4 — Attribute level permissions and meaning

Permission Protected Item

Category

Meaning

Read AttributeType

If granted, allows information about that attribute type to be returned in a Read or Searchoperation. Although a prerequisite for reading values for that attribute, it grants no rights to anyvalues of that attribute, of itself.

If denied, prevents return of information about that attribute type.in Read or Search operations.In effect, this denies all values as well.

Read AttributeValue

If granted, allows designated value(s) of an attribute type to be returned in a Read or Searchoperation. It grants no rights to the attribute type itself. Read permission to the attribute type isalso required in order to read a value.

If denied, prevents return of designated values of that attribute type in Read or Searchoperations. It does not, of itself, deny access to other values, or the attribute type itself.

Compare AttributeType

If granted, allows Compare operations to test for the attribute type. Although a prerequisite tocomparing values, it does not, of itself, permit compares for any values.

If denied, prevents Compare operations from testing that attribute. This prevents testing for allvalues.

Compare AttributeValue

If granted, allows Compare operations to test for the designated value of the designated type.It grants no rights to the attribute type itself. Compare permission to the attribute type is alsorequired in order to compare a value.

If denied, prevents Compare operations from testing for the designated value.

FilterMatch AttributeType

If granted, permits the attribute type to be used in evaluation of a Search filter item. It is aprerequisite for including values of that type in filter evaluations, but does not, of itself, grantrights to any values.

If denied, prevents use of that attribute type, including any of its values, in evaluating a filteritem.

FilterMatch AttributeValue

If granted, permits the attribute value(s) to be used in evaluation of a Search filter item.FilterMatch is also required for the attribute type for a successful evaluation.

If denied, prevents use of the value(s) in evaluation of a filter item.

Add AttributeType

If granted, permits the designated attribute type to be added. Grants no rights to add anyattribute values.

If denied, prevents addition of the designated attribute type, and, as a consequence, anyvalues.

Add AttributeValue

If granted, permits the designated attribute values to be added. No rights to add the type itselfare granted. Conversely, no rights to add the attribute type are needed to add a value to anexisting attribute.

If denied, prevents addition of the designated attribute values.

Remove AttributeType

If granted, permits the designated attribute type and all of its values to be removed in a Modifyoperation. Does not, of itself, grant the right to remove individual values.

If denied, prevents removal of the attribute type in a Modify operation.

Remove AttributeValue

If granted, permits the designated attribute values to be removed in a Modify operation.Remove permission to the attribute type is also needed to remove the last attribute value.

If denied, prevents removal of the designated attribute values in a Modify operation.

Disclose OnError

AttributeType

If granted, permits return of an error that may disclose the existance of the attribute.

If denied, requires the Directory to conceal the existance of the attribute. DiscloseonError , ofitself, does not deny ability to detect the attribute type by other means for which theappropriate permissions are granted.

Disclose OnError

AttributeValue

If granted, permits return of an error that may disclose the existance of the attribute value.

If denied, requires the Directory to conceal the existance of the attribute value.DiscloseonError , of itself, does not deny ability to detect the attribute value(s) by other meansfor which the appropriate permissions are granted.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 133

Annex L — Example of Basic Access Control(This annex does not form an integral part of this Recommendation | International Standard)

L.1 Introduction

This annex is for information and tutorial purposes only. It addresses two primary topics: design principles that areimportant in the architecture of the Basic Access Control mechanism; and an extended example of Basic AccessControl. Detailed information on Basic Access control is provided in clause 15 of this Directory Specification andin ITU-T Recommendation X.511 | ISO/IEC 9594-3.

L.2 Design principles for Basic Access Control

This clause presents several of the most important design principles used in the architecture of Basic AccessControl. To facilitate referencing, each principle is labeled (e.g., PR-1).

PR-1: Generally, permissions associated with UserClasses of higher specificity override permissions associatedwith UserClasses of less specificity. This principle applies when the permissions have the same precedence level.Specificity, in this principle, measures how explicitly a requestor’s name relates to a particular UserClassesspecification; allUsers is of lowest specificity while name is very specific. This principle is manifest in 15.8.4 b) ofthis Directory Specification. It facilitates situations where policy about default permissions (expressed in terms ofless specific UserClasses) is selectively overridden by permissions associated with a more specific UserClassesspecification.

PR-2: Generally, permissions associated with ProtectedItems of higher specificity override permissionsassociated with ProtectedItems of less specificity. This principle applies when the permissions have the sameprecedence level and the same UserClasses specificity. Specificity, in this principle, is a measure of how explicitlythe ProtectedItems specification relates to the exact item to which access is sought. For example, when the targetprotected item is a specific attribute value, allAttributeValues and allUserAttributeTypesAndValues are lessspecific than attributeValue . This principle is manifest in clause 15.8.4 c) of this Directory Specification. Itfacilitates situations where policy about default permissions (expressed in terms of less specific ProtectedItems ) isselectively overridden by permissions associated with a more specific ProtectedItems specification.

PR-3: Basic Access Control is modeled as completely independent of the name resolution process except in thecase of alias dereferencing. Except for alias dereferencing, access control decisions occur only after the Directoryhas successfully located a suitable DSA containing the target protected item. A corollary principle is that BasicAccess Control has no effect on how the Directory generates subrequests and it has no effect on how the Directoryperforms name resolution associated with subrequests (except in the case of alias dereferencing).

PR-4: Precedence can be used to enforce the relationship between a superior and a subordinate authority suchthat the superior can override controls set by the subordinate. For example: let SE1 denote a subentry of theadministrative entry for an ACSA, say ACSA-1; similarly, let SE2 denote a subentry of the administrative entry foran ACIA inside of ACSA-1. Limits on the Precedence occurring in SE2 may be specified by the ACSA-1 authoritysuch that prescriptiveACI in SE2 cannot countermand prescriptive ACI in SE1. Also, limits on Precedence forentryACI (within ACSA-1) can be specified such that entryACI cannot countermand prescriptive controls set inSE1. This principle facilitates implementation of partial delegation of authority.

Note — The Directory Specification presumes that a method of limiting precedence for authorities associated with innerareas will be implemented. However, the Directory Specification does not define (or describe) how precedence is to belimited.

PR-5: Basic Access Control never passively grants access; each decision to grant access is based on explicitlyspecified access control information. A corollary principle is that granting one form of access never impliespermission to perform another form of access. These principles are consistent with a more general security designprinciple known as least privilege .

PR-6: In the absence of any prescriptiveACI, entryACI or subentryACI on which to base a decision, the ACDFwill deny access. All other decision parameters being equal, denials override grants (e.g., in the situation wherethere are ACIItems that grant and others that deny and where the Precedence and specificity are equal, the denialprevails).

ISO/IEC 9594-2 : 1993(E)

134 ITU-T Rec. X.501 (1993 E)

L.3 Introduction to example

Figure L-1 depicts the DIT subtree of a fictitious company, Z Computer Corporation (ZCC), used throughout theexample. The naming structure in figure L-1 follows the suggestions in ITU-T Recommendation X.521 | ISO/IEC9594-7 Annex B. The node with distinguished name {C=US, O=ZCC} is an administrative entry and is theautonomous administrative point for ZCC; it therefore defines the beginning of an Autonomous AdministrativeArea (AAA). The contents of an AAA is an implicitly defined subtree beginning at the autonomous administrativepoint and ending at either leaf nodes or when another autonomous administrative point is encountered. Since thereare no other autonomous administrative points below {C=US, O=ZCC}, the AAA contains all the nodes below{C=US} in figure L-1. The structural object class for {C=US, O=ZCC} is organization ; it also has an auxiliaryobject class of certificationAuthority . The auxiliary object class is present to help support strong authenticationwhere needed.

Below the autonomous administrative point there are three subtrees: Administration (Admin); Research andDevelopment (R&D); and Sales. The root of each of the subtrees is an entry with structural object classorganizationalUnit and auxiliary object class certificationAuthority . The R&D subtree contains entries ofstructural object class organizationalUnit , corresponding to remote sites, under which appear leaf objects ofstructural class organizationalPerson . Only a few representative objects of class organizationalPerson are shown.All objects of structural class organizationalUnit have an auxiliary object class of certificationAuthority . Allobjects of structural class organizationalPerson have an auxiliary object class of strongAuthenticationUser .These auxiliary object classes help support strong authentication where needed.

The object with distinguished name {C=US, O=ZCC, OU=Admin, CN=Ops} is of structural object classgroupOfUniqueNames; its uniqueMember attribute values include namespace administrators. One name itcontains is {C=US, O=ZCC, OU=Admin, CN=Cauchy}. There are two other such objects: {C=US, O=ZCC,OU=R&D, CN=Ops} has members responsible for maintaining entries in the R&D subtree; and {C=US, O=ZCC,CN=Ops} has members responsible for entries that are immediately subordinate to {C=US, O=ZCC}. The user withdistinguished name {C=US, O=ZCC, OU=R&D, OU=West, CN=Cayley} is a member of the latter two groups.

The two trapezoids in figure L-1 represent partial subtrees, the details of which are not important for the example.

L.4 Policy affecting the definition of specific and inner areas.

To support Basic Access Control, two types of administrative areas may be established within an AAA: AccessControl Specific Area (ACSA), and Access Control Inner Area (ACIA). An administrative area of either type isestablished by assigning the appropriate value to the administrative-role attribute in the administrative entry that isto serve as the root vertex for the area. The content of an ACSA is an implicitly defined subtree that begins at theroot vertex and extends down to leaf objects or until the root of another ACSA is encountered. Also, the boundaryof an ACSA never extends beyond the lower boundary of the enclosing AAA. In the case of an ACIA, the lowerboundary will occur upon encountering either a leaf entry or the boundary of the enclosing ACSA. Nested ACIAshave the same lower boundary and that boundary is the same as the lower boundary for the enclosing ACSA.

ZCC has established policy that affects the number and types of administrative areas needed within the AAA. Thefirst such policy is that the organizational unit known as Basic Research Consortium (BRC) is delegated completeauthority for establishing prescriptive access control attributes to control entries in the subtree with root vertex{C=US, O=ZCC, OU=R&D, OU=BRC}. To facilitate the implementation of the policy, the root {C=US, O=ZCC,OU=R&D, OU=BRC} has been designated as an administrative entry with administrative role id-ar-accessControlSpecificArea . The lower boundary of the resulting ACSA is implicitly defined by the occurrence ofleaf entries.

Note — An ACSA embodies the concept of complete delegation of authority because access decisions depend on ACIoccurring inside the ACSA containing the target protected item and are unaffected by ACI occurring outside that ACSA.

Furthermore, the ACSA described above is the only instance of complete delegation of access control authoritywithin ZCC. However, a consequence of the Directory Administrative Model is that when there is at least oneACSA in an AAA, each (and every) object in the AAA shall be contained in one (and only one) ACSA. Thisrequirement can be stated more clearly in terms of set theory where each ACSA and the associated AAA are viewedas sets of entries: the set intersection of each pair of ACSAs is empty and the set union of all ACSAs is equal to theAAA. Therefore, in the example, at least one additional ACSA is needed to contain the objects that are in the AAAbut outside the BRC subtree. Because there is only one instance of complete delegation within the AAA, the AAAroot is also the beginning of an ACSA that contains all the entries in the AAA except those in the BRC subtree.

The resulting ACSAs are depicted as ACSA-1 and ACSA-2 in figure L-2. In figure L-2, also notice that sinceadministrative areas are (implicitly defined) subtrees, each area includes its root vertex. The content of ACSA-1

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 135

extends downward from its root to leaf objects or until the root vertex of another ACSA is encountered (as is thecase at {C=US, O=ZCC, OU=R&D, OU=BRC}). In this example, there are no autonomous administrative pointsbelow {C=US, O=ZCC} and therefore the lower boundary of the AAA is defined entirely by leaf objects. Theremainder of this example will focus on access control within ACSA-1 (ACSA-2 will not be discussed further).Also for simplicity, this example does not discuss control of the subordinates under {C=US, O=ZCC, OU=Sales}.

Another ZCC policy affecting the definition of administrative areas is that the Western R&D organizational unit isdelegated partial authority for access control operational attributes affecting the entries in the subtree with rootvertex {C=US, O=ZCC, OU=R&D, OU=West}. The policy is best implemented by making the root of the R&DWest subtree an administrative point with administrative role id-ar-accessControlInnerArea. This meansprescriptive access controls for that subtree will, in general, be a combination of controls defined in the subentries ofthe root of that subtree and controls defined in the subentries of the root of the enclosing ACSA (ACSA-1). Thecontent of the resulting ACIA is an implicitly defined subtree with root at {C=US, O=ZCC, OU=R&D, OU=West}and extending down until leaf objects are encountered. Since an ACIA is a subtree, its content includes the rootvertex of that subtree.

A similar policy holds for the R&D East organizational unit. The corresponding ACIA has root vertex at {C=US,O=ZCC, OU=R&D, OU=East}. Figure L-3 depicts the two ACIAs within ACSA-1. The ACIA for R&D West islabeled ACIA-1; the one for R&D East is labeled ACIA-2.

L.5 Policy affecting the definition of DACDs

Prescriptive access controls are defined in subentries (with object class accessControlSubentry) of access controladministrative entries. Each such subentry has an associated subtreeSpecification attribute that defines the set ofentries in the scope of the subentry. The entries contained in the scope may form a subtree or may form a subtreerefinement. In the context of Basic Access Control, the scope of an access control subentry is called a DirectoryAccess Control Domain (DACD). Security authorities using Basic Access Control should be careful not to confusethe concept of administrative area with the concept of DACD. This clause begins with an examination of thedifferences and relationships between administrative areas and DACDs and then proceeds to discuss ZCC policythat gives rise to individual DACDs.

The basic distinctions between administrative areas and DACDs can be summarized as follows.

— An administrative area is an implicitly defined subtree with its root at an administrative entry and extendingdownward as described in clause L.4. Such an area is said to be implicitly defined because there is nostandardized attribute in the Directory that specifies its boundary; the DIT is logically examined todetermine the boundary of an administrative area. An administrative area is never a subtree refinement.

Note — A consequence of the way in which administrative areas are defined is that for each entry affected by BasicAccess Control, there shall be exactly one ACSA containing the entry (even if the entry is not included in any DACDwithin the ACSA).

— A DACD is a subtree or subtree refinement explicitly defined in the subtreeSpecification attribute of asubentry with object class accessControlSubentry.

— ACSAs and ACIAs are used by the ACDF to determine which prescriptive access controls (i.e., whichaccess control subentries) potentially effect the outcome of a given access control decision. ACSAs areused to implement full delegation of authority for access control. ACIAs are used to implement partialdelegation of authority for access control.

— A DACD is used to specify which entries (or potential entries) may be affected by the associated accesscontrol subentry.

Other important aspects of administrative areas and DACDs and how they relate to each other include the followingobservations.

— Each DACD is defined in a subentry of a particular administrative entry which is, in turn, the root vertex ofsome administrative area. This association between a DACD, a subentry, an administrative entry, and anadministrative area allows the determination, for a given DACD, of the associated administrative area (seeL.5.1) The set of entries contained in the DACD may be a proper or improper subset of the entriescontained in the associated administrative area.

Note — The terms proper subse t and improper subset are borrowed from mathematical set theory. The set A is aproper subset of set B if and only if every element of A is also an element of B and there is at least one element of Bthat is not an element of A. The set A is an improper subset of B if and only if both sets contain exactly the sameelements.

ISO/IEC 9594-2 : 1993(E)

136 ITU-T Rec. X.501 (1993 E)

— In the case where the set of entries in the DACD is an improper subset of the entries in the associatedadministrative area, the DACD and the administrative area are said to be congruent. However, even whensuch congruence occurs, the DACD and the administrative area continue to serve fundamentally differentpurposes (areas determine which subentries are allowed to potentially effect the outcome of a specificaccess control decision while each DACD specifies exactly which entries are affected by the prescriptivecontrols in a given subentry).

— The DACD can never contain entries that are outside the associated administrative area.

— The ACDF is designed to be robust in the sense that even if the subtreeSpecification defining a DACDhas within its scope entries outside the associated administrative area, access control decisions regardingthose entries will be unaffected. This aspect of robustness is manifest in the ACDF procedure fordetermining which subentries potentially effect a given decision (see 15.3.2 and 15.8.1 d.)

— DACDs defined in subentries of the same administrative entry may freely overlap within the commonassociated administrative area.

— ACSAs never overlap; every ACIA is properly nested within an ACSA. Properly nested means the entriesin an enclosed area form a proper subset of the entries in the enclosing area. Also, an ACIA may containone or more properly nested ACIAs.

— Where administrative areas are nested, DACDs associated with an enclosing area may freely overlapDACDs associated with any enclosed area. The enclosing area may be an ACSA or an ACIA, while theenclosed area is always an ACIA.

Each DACD is associated with an aspect of policy that affects one or more entries or potential entries. The entriesthat are affected by a particular aspect of policy form a DACD. The DACD for a particular aspect of policy shouldbe associated with the administrative area controlled by the authority responsible for enforcing that aspect of policy.

In the example, there are several aspects of policy to be enforced by the authority that controls ACSA-1. There are,for instance, “default” controls that apply to objects throughout ACSA-1. Such controls are assigned a precedenceand level of specificity that allows them to be easily overridden by other prescriptive controls or entryACIattributes. There is also policy that applies only to immediate subordinates of {C=US, O=ZCC} (within ZCC, suchentries are referred to as administrative level entries). There is also policy that applies only to the entries that havestructural object class organizationalPerson .

All entries in ACSA-1 are included in the DACD associated with default controls. The DACD is therefore definedto be a subtree with base vertex at {C=US, O=ZCC} and a chop specification that excludes the subtree with root at{C=US, O=ZCC, OU=R&D, OU=BRC}. The resulting DACD is congruent to ACSA-1 and is depicted as DACD-1in figure M–4.

Note — See 15.3.2 g) for the meaning of congruent in this context.

Also within ACSA-1, the DACD to control organizationalPerson entries is a subtree refinement with base vertexat {C=US, O=ZCC} and a specificationFilter that includes only the entries with objectClass oforganizationalPerson (see subtree-refinement1 in Annex J of this Directory Specification. This DACD isdepicted as DACD-2, in figure L-4.

A third DACD within ACSA-1 is related to controlling administrative level entries (i..e., immediate subordinates,other than subentries, of the organizational root entry). This DACD is a (chopped) subtree with base vertex at{C=US, O=ZCC} and a chop specification that includes only the immediate subordinates, other than subentries, of{C=US, O=ZCC}. This DACD is depicted as DACD-5 in figure M–4.

For ACIA-1, a DACD is required to handle an aspect of policy that has been delegated to the authority controllingthe inner area. The delegated authority affects only subordinates of {C=US, O=ZCC, OU=R&D, OU=West} andtherefore the DACD is not congruent to ACIA-1. The DACD is labeled DACD-3 in figure M–4.

For ACIA-2, there is only one DACD required; however the delegated authority affects all entries in ACIA-2 andtherefore the DACD is congruent to ACIA-2. The DACD is labeled DACD-4 in figure L-4.

L.5.1 Administrative area associated with each DACD

Each subentry used in the example is shown in figure M–4. This clause summarizes the location of each subentryand also indicates the administrative area that is associated with each DACD.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 137

DACD-1, DACD-2, and DACD-5 are defined in subentries to {C=US, O=ZCC} which is the administrative entrythat defines the root vertex of ACSA-1. Therefore, these three DACDs are said to be associated with ACSA-1. Thename of the subentry defining DACD-1 is {C=US, C=ZCC, CN=SE_DACD1}. The other subentries have similarnames that indicate which DACD they define.

DACD-3 is defined in a subentry to {C=US, O=ZCC, OU=R&D, OU=West} which is the administrative entry thatis the root vertex of ACIA-1. Therefore, DACD-4 is associated with ACIA-1.

DACD-4 is defined in a subentry to {C=US, O=ZCC, OU=R&D, OU=East} which is the administrative entry thatdefines the root vertex of ACIA-2. Therefore, DACD-4 is associated with ACIA-2.

L.6 Policy expressed in prescriptiveACI attributes

This subclause contains a detailed description of access control policy applicable to each DACD in ACSA-1. Thepolicy discussed in this example should be considered a partial policy that is simplified for ease of presentation. Inparticular, there is no discussion related to how passwords are controlled since, in general, passwords represent aspecial case of access control; also there is no discussion of the DiscloseOnError or ReturnDN permissions.

The policy discussed in this subclause is presented in terms of policy fragments that facilitate understanding of howprescriptiveACI attributes are used to collectively enforce the overall policy. Each fragment is given a referencelabel that is used in later subclauses; the labels are of the form PF-n where n is a sequential integer. For each DACDthere is also an indication of how the applicable policy fragments could be expressed in terms of one or moresubentries (containing prescriptiveACI attributes).

L.6.1 prescriptiveACI for DACD-1

One of the main purposes of DACD-1 is to enforce policy fragments that are concerned with “default” accesscontrol. Such policy fragments provide backstop controls that apply when there is no other control that is higher inprecedence or specificity. Specificity is discussed under design principles PR-1 and PR-2 in subclause L.2.

ZCC has stated their policy with regard to public access in terms of default policy rules which may be overriddenfor certain entries that need more restrictive control. The default policy is stated in PF-1 and PF-2. Note that,according to ZCC policy, those who implement the policy are responsible for ensuring that any deviation from thedefault rules is more restrictive than the default rules.

PF-1: Employees are to be distinguished from the general public. Public access rights, in general, shall be limitedaccording to a) and b) below; however, public access may be more restricted for specific entries (it is never lessrestricted).

a) Entries may be located by common name. Search on common name is permitted to accommodateapproximate match and alternate names. In particular, search based on telephone number is not allowed tothe general public, but is permitted to those inside the organization. Search results may disclose all valuesof commonName.

b) The only public attributes are commonName, telephoneNumber, components from postalAttributeSet ,and facsimileTelephoneNumber.

PF-2: General Public access may be unauthenticated, but an identity must be presented.

ZCC also uses default policy rules to express their general policy with regard to employee access. Deviations fromthe default policy rules may be more restrictive or may be less restrictive. The default policy is stated in PF-3 andPF-4.

PF-3: Employees, in general, enjoy read and search access to most attributes of most entries.

PF-4: Simple authentication is required for employee access that does not modify (in any way) the contents ofACSA-1.

There are also some policy fragments applying to DACD-1 that are not treated as defaults. Two examples of suchfragments are given in PF-5 and PF-6; they are related to administration of entries.

PF-5: {C=US, O=ZCC, CN=Cauchy} is “superuser”, authorized to access all data and perform any necessaryoperations.

ISO/IEC 9594-2 : 1993(E)

138 ITU-T Rec. X.501 (1993 E)

PF-6: Strong authentication is required to make any modification to the contents of the ACSA-1.

One or more subentries to {C=US, O=ZCC} can be used to implement the policy fragments for DACD-1. Eachsuch subentry would have the same subtreeSpecification with base of {C=US, O=ZCC} and a chop specificationto exclude the OU=BRC subtree. Each such subentry would also contain a prescriptiveACI attribute thatimplements some subset of the policy fragments for DACD-1. For the purposes of the example, it is assumed that asingle subentry is used to capture all prescriptive controls associated with DACD-1 (there is no compelling technicalreason to use more than one). To facilitate referencing, this subentry is referred to as SE_DACD1. TheprescriptiveACI attribute in SE_DACD1 has several values; the design of each value is discussed in the remainderof this subclause.

The number of values occurring in a prescriptiveACI attribute depends partly on how the policy fragments aregrouped for convenience into itemFirst and userFirst values (either style may be used in any given situation); italso depends on how access control for the prescriptive controls themselves is to be handled.

For example, part of implementing PF-1 requires public users (i.e., allUsers) to be granted all of the followingpermissions:

a) Browse for the protected item entry ;

b) FilterMatch and Read for protected item attributeType {commonName};

c) FilterMatch and Read for protected item allAttributeValues {commonName}.

These permissions are necessary (but are not sufficient — see Note below) to implement PF-1. Since there are threeprotected items (entry , attributeType , and allAttributeValues) and just one user class (allUsers), it seems mostnatural to use a single ACIItem of the userFirst style but the itemFirst style could be used instead.

Note — The permissions discussed above would also be sufficient to allow search on commonName if the following twoconditions are simultaneously satisfied: (a) there are no other relevant ACIItems with higher precedence or specificity thatdeny any of the Browse or FilterMatch permissions listed above; and (b) there are no other values for the prescriptiveACIattribute in SE_DACD1 that deny any of the Browse , Read, or FilterMatch permissions listed above.

Alternatively, three separate ACIItems could be used: one for each of the protected items. This alternative allowseach ACIItem to have separate access control; each has an identificationTag that is unique (with respect to theother identificationTags for other values in the same prescriptiveACI attribute) and which can be referenced inanother ACIItem where the protected item is attributeValue and the associated attribute value assertion specifies theidentificationTag of the value to be protected. Note that using attributeValue in this way takes advantage of theparticular equality matching rule defined for prescriptiveACI attributes (see clause 15.5.4 of this Amendment).Examples of protecting ACI are discussed in detail later in the example.

For the purpose of the example, six values for the prescriptiveACI attribute in SE_DACD1 are used to implementpolicy fragments PF-1 through PF-4. The design of each of the three values is summarized below.

Notes

1 Each protected item in the design summaries below have a label to facilitate referencing. The label is in parentheses andis italicized (e.g., A1 , A2 , B1 ).

2 The example uses four levels of precedence: 10, 20, 30, and 40.

identificationTag : “Public Access – Enable entry access for List and Search oncommon name”

Precedence : 10UserClasses: { allUsers }authenticationLevel: noneProtectedItems : { (A1 ) entry }grantsAndDenials : { grantBrowse }

---------------------------------------------------

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 139

identificationTag : “Public Access – Enable filter access for Search”Precedence : 10UserClasses: { allUsers }authenticationLevel: noneProtectedItems : { (B1 ) attributeType { commonName },

(B2 ) allAttributeValues { commonName }, (B3 ) attributeType { objectClass }, (B4 ) allAttributeValues { objectClass } }

grantsAndDenials : { grantFilterMatch }---------------------------------------------------

identificationTag : “Public Access – Enable entry access for Read andCompare operations”

Precedence : 10UserClasses: { allUsers }authenticationLevel: noneProtectedItems : { (C1 ) entry }grantsAndDenials : { grantRead }

---------------------------------------------------

identificationTag : “Public Access – Enable attribute access for interrogation operations”Precedence : 10UserClasses: { allUsers }authenticationLevel: noneProtectedItems : { (D1 ) attributeType { commonName,

postalAttributeSet,telephoneNumber,facsimileTelephoneNumber } ,

(D2 ) allAttributeValues { commonName,postalAttributeSet,telephoneNumber,facsimileTelephoneNumber } }

grantsAndDenials: { grantRead, grantCompare }---------------------------------------------------

identificationTag : “Employee Access – Enable attribute access for interrogationoperations”

Precedence : 10UserClasses: subtree with base { C=US, O=ZCC } and chop to

exclude O=BRC subtreeauthenticationLevel: simpleProtectedItems : { (E1 )allUserAttributeTypesAndValues }grantsAndDenials : { grantRead, grantCompare }

---------------------------------------------------

identificationTag : “Employee Access – Enable filter access for Search”Precedence : 10UserClasses: subtree with base { C=US, O=ZCC } and chop to

exclude O=BRC subtreeauthenticationLevel: simpleProtectedItems : { (F1 ) allUserAttributeTypesAndValues }grantsAndDenials : { grantFilterMatch }

---------------------------------------------------

Note — Permissions for employees are the union of permissions for the public and permissions specific to employees. Theabove ACIItem values for employee access are strongly coupled to values associated with public access. This strongcoupling could be avoided, if necessary, by repeating each of the values for public access (each repeated value would have anew UserClasses that specifies only employees).

There are two other values of the attribute which are related to implementing policy regarding how entries areadministered (PF-5 and PF-6). For simplicity, this example assumes that access control attributes are the onlyoperational attributes present in the AAA. The design of the two values is summarized below.

ISO/IEC 9594-2 : 1993(E)

140 ITU-T Rec. X.501 (1993 E)

identificationTag : “Cauchy is superuser (Part 1)”Precedence : 40UserClasses: user { C=US, O=ZCC, OU=Admin, CN=Cauchy }

uniqueIdentifier = 12345authenticationLevel: strongProtectedItems : { (G1 )entry }grantsAndDenials : { grantAdd, grantRead , grantRemove, grantBrowse , grantModify ,

grantRename}---------------------------------------------------


uniqueIdentifier = 12345authenticationLevel: strongProtectedItems : { (H1 ) allUserAttributeTypesAndValues ,

(H2 ) attributeType { entryACI }, (H3 ) allAttributeValues { entryACI } }

grantsAndDenials : { grantAdd, grantRead , grantRemove, grantCompare , grantFilterMatch }

---------------------------------------------------

Note that the above two values are necessary, but not sufficient, to make Cauchy a superuser. They are not sufficientbecause they do not enable Cauchy’s control over subentries of the administrative point for ACSA-1; there are tworeasons why this is true. First, prescriptive ACI does not apply to the subentry in which it appears. Second,prescriptive ACI placed in a subentry, say subentry–1, cannot be used to control subentries that are siblings ofsubentry–1. Therefore, it is necessary to place subentryACI in the entry corresponding to the administrative pointfor ACSA–1 such that Cauchy is allowed to administer his authority over the subentries of that administrative point.The necessary subentryACI is discussed in L.7.

Note also that the authority granted in the above two values of prescriptive ACI allow Cauchy to administer fullcontrol over the subentries associated with administrative points that are subordinate to the administrative point forACSA-1.


DACD-2 is defined in a subentry of the administrative entry for ACSA-1. DACD-2 is concerned with controllingentries with object class organizationalPerson . The following policy fragment is relevant.

PF-7: Only members of the namespace administration group {C=US, O=ZCC, OU=Admin, CN=Ops} can add,delete, or rename user entries. However, they are only permitted to add mandatory attributes to a new entry (anentry containing only mandatory attributes is referred as a minimal entry).

The following two values in the prescriptiveACI attribute of SE_DACD2 implement PF-7.

Note — Renaming of entries, in the context of PF-7, is understood to mean renaming without changing the immediatesuperior. For simplicity, this example does not address the more complicated case where renaming involves changing theimmediate superior of the renamed entry (and its subordinates); in this case, Import and Export permissions must beconsidered.

identificationTag: “Minimal leaf entry administration (Part 1)”Precedence: 20UserClasses: userGroup { C=US, O=ZCC, OU=Admin, CN=Ops }authenticationLevel: strongProtectedItems: { (J1 ) entry,

(J2 ) attributeType {commonName, surname }, (J3 ) allAttributeValues {commonName, surname } }

grantsAndDenials: { grantAdd, grantRemove }---------------------------------------------------

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 141

identificationTag: “Minimal leaf entry administration (Part 2)”Precedence: 20UserClasses: userGroup { C=US, O=ZCC, OU=Admin, CN=Ops }authenticationLevel: strongProtectedItems: { (K1 ) entry }grantsAndDenials: { grantRename }

---------------------------------------------------


DACD-3 is defined in a subentry to the administrative entry for ACIA-1. It implements policy fragments regardingpolicy that has been partially delegated to ACIA-1. An example is that the policy for ACIA-1 regardingtelephoneNumber is different from that provided in default policy within DACD-1. Within DACD-3,telephoneNumber is not regarded to be a public access iteL. This is reflected in the following policy fragment.

PF-8: The only public attributes within ACIA-1 are commonName, components from postalAttributeSet , andfacsimileTelephoneNumber .

The following value in the prescriptiveACI attribute of the subentry {C=US, O=ZCC, OU=R&D, OU=West,CN=SE_DACD3} implements PF-8.

identificationTag : “Delegated control of public access”Precedence : 10UserClasses: { allUsers }authenticationLevel: noneProtectedItems : { (L1 )attributeType { telephoneNumber },grantsAndDenials: { denyRead, denyCompare, denyFilterMatch }

---------------------------------------------------

The R&D West organization is also delegated authority to implement self–administration for entries of object classorganizationalPerson. The policy is reflected in the following fragment.

PF-9: Employees of R&D West may administer values within their own Directory entry for the following attributetypes: telephoneNumber, commonName, and facsimileNumber; however, they may not modify or remove thetelephone number value supplied by the administration.

The first part of PF-9 is reflected in the two ACIItems below. The restriction on removal of a particular value oftelephoneNumber is implemented using entryACI as described in clause C.8.

identificationTag : “Self Administration of R&D West employee entries (part 1)”Precedence : 20UserClasses: thisEntryauthenticationLevel: strongProtectedItems : { (M1 ) entry }grantsAndDenials: { grantModify }

---------------------------------------------------

identificationTag : “Self Administration of R&D West employee entries (part 2)”Precedence : 20UserClasses: thisEntryauthenticationLevel: strongProtectedItems : { (N1 ) attributeType { commonName,

postalAttributeSet ,telephoneNumber,facsimileTelephoneNumber },

(N2 )allAttributeValues { commonName,postalAttributeSet ,telephoneNumber,facsimileTelephoneNumber } }

grantsAndDenials: { grantAdd, grantRemove }---------------------------------------------------

PF-10: The group with members identified in {C=US, O=ZCC, OU=R&D, CN=Ops} are responsible for generalmaintenance of user attributes for entries in ACIA-1; however, they may not modify subentries located insideACIA-1.

ISO/IEC 9594-2 : 1993(E)

142 ITU-T Rec. X.501 (1993 E)

The first part of this policy is reflected in the following ACIItem :

identificationTag : “R&D general administration (part 1)”Precedence : 20UserClasses: userGroup { C=US, O=ZCC, OU=R&D, CN=Ops }authenticationLevel: strongProtectedItems : { (P1 )entry }grantsAndDenials: { grantModify, grantAdd , grantRemove, grantBrowse ,

grantRead, grantRename }---------------------------------------------------

identificationTag : “R&D general administration (part 2)”Precedence : 20UserClasses: userGroup { C=US, O=ZCC, OU=R&D, CN=Ops }authenticationLevel: strongProtectedItems : { (Q1 )allUserAttributeTypesAndValues }grantsAndDenials: { grantAdd, grantRemove , grantRead, grantFilterMatch ,

grantCompare}---------------------------------------------------

The restriction with regard to subentries is handled by not including any subentryACI values in the administrativeentry for ACIA-1 that allow the access.


DACD-4 is defined in a subentry to the administrative entry for ACIA-2. As such, it implements policy fragmentsregarding policy that has been partially delegated to ACIA-2.

For simplicity, DACD-4 is not discussed further.


DACD-5 is defined in a subentry to the administrative point for ACSA-1. This DACD is used to control access to allimmediate subordinates, other than subentries, of the organizational root. In particular, the following policy applies.

PF-11: The Operations Group {C=US, O=ZCC, CN=Ops} is responsible for administration of all entries that areimmediately subordinate to {C=US, O=ZCC}.

PF-11 is expressed in the following ACIItem values.

. identificationTag: “Control of administrative level entries (part 1)”Precedence: 40UserClasses: { userGroup { C=US, O=ZCC, CN=Ops }authenticationLevel: strongProtectedItems: { (R1 ) entry }grantsAndDenials: { grantRead, grantBrowse , grantRemove, grantAdd , grantRename ,

grantModify }---------------------------------------------------

identificationTag: “Control of administrative level entries (part 2)”Precedence: 40UserClasses: { userGroup { C=US, O=ZCC, CN=Ops }authenticationLevel: strongProtectedItems: { (S1 ) allUserAttributeTypesAndValues ,

(S2 ) attributeType { entryACI }, (S3 ) allAttributeValues { entryACI } }

grantsAndDenials: { grantRead, grantRemove , grantAdd, grantCompare , grantFilterMatch }

---------------------------------------------------

L.7 Policy expressed in subentryACI attributes

L.7.1 subentryACI in the administrative entry for ACSA-1

PF-5 is manifested in a combination of prescriptiveACI and subentryACI; the associated prescriptiveACI hasalready been described in L.6.1. To enable Cauchy to administer the subentries of the administrative point forACSA-1 (and any subentries for administrative points subordinate to the administrative point for ACSA-1), it is

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 143

necessary to place the following subentryACI values in the entry corresponding to the administrative point forACSA-1.


uniqueIdentifier = 12345authenticationLevel: strongProtectedItems : { (G1 )entry }grantsAndDenials : { grantAdd, grantRead , grantRemove, grantBrowse , grantModify ,

grantRename}---------------------------------------------------


uniqueIdentifier = 12345authenticationLevel: strongProtectedItems : { (H1 ) allUserAttributeTypesAndValues ,

(H2 ) attributeType { entryACI }, (H3 ) allAttributeValues { entryACI } }

grantsAndDenials : { grantAdd, grantRead , grantRemove, grantCompare , grantFilterMatch }

---------------------------------------------------

L.7.2 subentryACI in the administrative entry for ACIA-1

A subentryACI attribute is placed in the root vertex of ACIA-1 to implement the following policy fragment:

PF-12: The user with common name Cayley is responsible for managing all prescriptiveACI defined in ACIA-1.

The following two values in the subentryACI attribute implement PF-12.

identificationTag : “Cayley manages subentries in ACIA-1 (part 1)”Precedence : 20UserClasses: user { C=US, O=ZCC, OU=R&D, OU=West, CN=Cayley }authenticationLevel: strongProtectedItems : { (T1 ) entry ,grantsAndDenials : { grantRead, grantBrowse , grantRemove, grantAdd ,

grantRename, grantModify }---------------------------------------------------

identificationTag : “Cayley manages subentries in ACIA-1 (part 2)”Precedence : 20UserClasses: user { C=US, O=ZCC, OU=R&D, OU=West, CN=Cayley }authenticationLevel: strongProtectedItems : { (U1 ) attributeType { prescriptiveACI },

(U2 ) allAttributeValues { prescriptiveACI } }grantsAndDenials: { grantAdd, grantRead , grantRemove, grantCompare ,

grantFilterMatch }---------------------------------------------------

L.8 Policy expressed in entryACI attributes

PF-9 requires that each R&D West employee be allowed to manage all values of telephoneNumber in his/herDirectory entry with the restriction that they may not modify or remove a particular value supplied byadministration. To enforce the restriction, the administration adds an entryACI value to each entry at the time thatthe restricted telephone number is added to the entry. The entryACI value is summarized as follows:

ISO/IEC 9594-2 : 1993(E)

144 ITU-T Rec. X.501 (1993 E)

identificationTag : “Restrict self-administration of telephone numbers”Precedence : 30UserClasses: thisEntryauthenticationLevel: noneProtectedItems : { (V1 ) attributeValue { telephoneNumber = value supplied by

administration } }grantsAndDenials: { denyRemove }

---------------------------------------------------

Note that since users cannot modify the entryACI attribute (it is not part of self administration as defined in PF-9),the above control cannot be overridden by the user.

The following policy fragment is an example of using entryACI to implement a self administration for a groupentry.

PF-13: The entry {C=US, O=ZCC, OU=Admin, CN=Ops} is a “self-administered” group entry; this means thateach member of the group may remove their name from the group or change their name in the group. They may notremove or rename the group itself.

PF-13 is implemented by an entryACI attribute in the entry {C=US, O=ZCC, OU=Admin, CN=Ops} with twovalues as summarized below.

identificationTag : “self-administration of the Administrative Ops group (part 1)”Precedence : 30UserClasses: userGroup { C=US, O=ZCC, OU=Admin, CN=Ops }authenticationLevel: strongProtectedItems : { (W1 ) entry }grantsAndDenials: { grantModify }

---------------------------------------------------

identificationTag : “self-administration of the Administrative Ops group (part 2)”Precedence : mediumUserClasses: userGroup { C=US, O=ZCC, OU=Admin, CN=Ops }authenticationLevel: strongProtectedItems : { (X1 ) selfValue { uniqueMember }grantsAndDenials: { grantRemove, grantAdd }

---------------------------------------------------

L.9 ACDF examples

L.9.1 Public access read

A member of the general public, with distinguished name {C=GB, O=XC, CN=Smith} attempts a read operationrequesting telephone number values for user Cayley. The access control decisions for the operation are defined inITU-T Recommendation X.511 | ISO/IEC 9594-3. Assuming there is no alias dereferencing involved in nameresolution, the first decision point is to determine if Read permission for the target entry is granted; this decision isbased on the following inputs to the ACDF.

— requested permission: Read

— originator: {C=GB, O=XC, CN=Smith} with no unique identifier

— authentication level: none

— protected item: entry{C=US, O=ZCC, OU=R&D, OU=West, CN=Cayley}

— tuples shown in Table L-1

The protected target entry is in the scope of DACD-1, DACD-2, and DACD-3 (see figure L-4 of this appendix). Ithas no entryACI . The three DACDs contribute the tuples (applicable to the specified originator) shown in Table L-1to the ACDF procedure described in 15.8 of this Directory Specification.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 145

Table L-1

User Item Permission

Grantor

DenyPrece-dence

Authenti-cationLevel

allUsersallUsersallUsersallUsersallUsersallUsersallUsersallUsersallUsersallUsersallUsersallUsersallUsersallUsersallUsersallUsersallUsers

(A1)entry(B1)commonName type

(B2)commonName values(B3)objectClass type

(B4)objectClass values(C1 )entry

(D1 )commonName type(D1 )postalAttributeSet type(D1 )telephoneNumber type

(D1 )facsimileTelephoneNo. type(D2 )commonName values

(D2 )postalAttributeSet values(D2 )telephoneNumber values

(D2 )facsimileTelephoneNo. values(L1)telephoneNumber type(L1)telephoneNumber type(L1)telephoneNumber type

BrowseFilterMatchFilterMatchFilterMatchFilterMatch

ReadReadReadReadReadReadReadReadReadRead

CompareFilterMatch

GGGGGGGGGGGGGGDDD

1010101010101010101010101010101010

nonenonenonenone

noneSnonenonenonenonenonenonenonenonenonenonenonenone

The ACDF, after discarding non–relevant rows, ends up with just two rows to consider: row 4 which grants Read onthe entry and row 13 which denies Read on the entry. The ACDF therefore denies access.

Note — For simplicity, this example does not address permissions and procedures associated with error conditions.However, in the above case of denied access, the behavior of the responding DSA would be governed by 7.11.3 of thisDirectory Specification and would involve using the ACDF again to determine if DiscloseOnError is granted for the targetentry.

L.9.2 Public access search

A member of the general public, with distinguished name {C=GB, O=XC, CN=Smith} attempts a search operationrequesting all values of all attributes for all users (wholeSubtree) subordinate to base object {C=US, O=ZCC,OU=R&D, OU=West}; the filter specifies FilterItem equality: objectClass = organizationalPerson. The accesscontrol decision points for the operation are defined in 10.2.5 of ITU-T Recommendation X.511 | ISO/IEC 9594-3.

L.9.2.1 Check each entry in the Search scope for proper entry permission

For each entry in the search scope, assuming there is no alias dereferencing involved in name resolution, the firstdecision point is to determine if Browse is granted for that entry. For the first such entry, the ACDF inputs are:

— requested permission: Browse

— originator: {C=GB, O=XC, CN=Smith}

— unique identifier: none


— protected item: entry{C=US, O=ZCC, OU=R&D, OU=West}


Since the entry being checked is included in DACD-1 only, the initial set of tuples gathered by the ACDF is shownin Table L-2. Note that there is no entryACI to consider.

Table L-2

User Item Permission

Grantor

DenyPrece-dence

Authenti-cationLevel

ISO/IEC 9594-2 : 1993(E)

146 ITU-T Rec. X.501 (1993 E)

allUsersallUsersallUsersallUsersallUsersallUsersallUsersallUsersallUsersallUsersallUsersallUsersallUsersallUsers

(A1)entry(B1)commonName type

(B2)commonName values(B3)objectClass type

(B4)objectClass values(C1 )entry

(D1 )commonName type(D1 )postalAttributeSet type(D1 )telephoneNumber type

(D1 )facsimileTelephoneNo. type(D2 )commonName values

(D2 )postalAttributeSet values(D2 )telephoneNumber values

(D2 )facsimileTelephoneNo. values

BrowseFilterMatchFilterMatchFilterMatchFilterMatch

ReadReadReadReadReadReadReadReadRead

GGGGGGGGGGGGGG

1010101010101010101010101010

nonenonenonenonenonenonenonenonenonenonenonenonenonenone

The ACDF procedure of discarding rows from Table L-2 results in only the first row being retained; the ACDFtherefore grants the requested access.

Similarly, the ACDF will grant Browse for each entry in the scope of the Search.

L.9.2.2 Check for satisfaction of Filter

For each entry in the search scope for which Browse is granted, the next decision point is to determine if FilterMatchis granted on the objectClass attribute. For the first such entry, the ACDF inputs are:

— requested permission: Browse

— originator: {C=GB, O=XC, CN=Smith}

— unique identifier: none


— protected item: entry{C=US, O=ZCC, OU=R&D, OU=West}


The ACDF will discard all rows of Table L-2 except for row 4; the access will, therefore be granted. Next, theSearch operation will check to see if any of the values of the objectClass attribute equal organizationalPerson.Since the entry being checked is an organizational unit entry, the Filter will evaluate to FALSE .

Similarly, the Filter will evaluate to FALSE for the entry with CN = SE_DACD3.

For the other two entries in the scope of the Search (CN=Cayley, CN=Noether), the Filter will evaluate to TRUE .For each of these entries, the next access control decision is to determine if FilterItem is granted for the attributevalue that caused the Filter to be evaluated as TRUE. Because these entries are included in both DACD-1, DACD-2,and DACD-3, the initial set of tuples input to the ACDF is Table L-1. Row 5 of Table L-1 grants the requestedaccess for both entries.

Hence, the Search result contains information from the entries for Cayley and Noether. Additional access controldecisions for these two entries are essentially the same as shown in the example of public Read in L.8.1.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 147

O = ZCC(AAA, ACSA)

C = US

OU = Admin OU = R&DCN = Ops

OU = Sales

CN = Ops CN = Cauchy

CORPORATE ADMINISTRATIVE AREA

CN = Cayley

CN = Ops

CN = Noether

OU = West(ACIA)

CN = Galois

CN = Peirce

OU = EAST(ACIA)

OU = BRC(ACSA)

Figure L-1 — DIT branch for the Z Computer Corporation (ZCC)

ISO/IEC 9594-2 : 1993(E)

148 ITU-T Rec. X.501 (1993 E)

CN = Ops

CN = Ops OU = East(ACIA)

C = US


OU = Sales

CN = Cauchy

CN = Cayley

CN = Noether

OU = West(ACIA)

CN = GaloisCN = Peirce

ACSA - 1O = ZCC

(AAA, ACSA)

OU = BRC(ACSA)

ACSA - 2

Figure L-2 — Access Control Specific Areas

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 149

CN = Ops

CN = OpsOU = East

(ACIA)

C = US


OU = Sales

CN = Cauchy

CN = Cayley

CN = Noether

OU = West(ACIA)

CN = GaloisCN = Peirce

ACSA - 1O = ZCC

(AAA, ACSA)

ACIA - 1 ACIA - 2

Figure L-3 — Access Control Inner Areas

ISO/IEC 9594-2 : 1993(E)

150 ITU-T Rec. X.501 (1993 E)

DACD - 5

O = ZCC(AAA, ACSA)

C = US

OU = Admin OU = R&D OU = Sales

CN = Ops

OU = West(ACIA)

CN = Galois

CN = Peirce

OU = East(ACIA)

DACD - 1

CN = CauchyCN = Ops

DACD - 3

DACD - 4

CN = CayleyCN = Noether

CN = Ops

CN = SE_DACD1

CN = SE_DACD2

CN = SE_DACD5

CN = SE_DACD3

User entry in DACD-2

Administrative Point Subentry

CN = SE_DACD4

Figure L-4 — Directory Access Control Domains

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 151

Annex M — DSE Type Combinations(This annex does not form an integral part of this Recommendation | International Standard)

Table M-1 specifies a number of DSE type combinations (i.e. combinations of the named bits of the dseTypeattribute) that are likely to occur when applying the DSA information model to DSA in the absence of shadowing.The table is provided to help clarify the DSA information model. Support for these (or other DSE typecombinations) is not mandated by this Directory Specification.

Table M-1 – Defined DSE Type Combinations in the Absence of Shadowing

DSE Type admPoint cp supr nssr sa Comments

root 3 3 Root DSE for a first level DSA. First levelDSA with an nssr if nssr bit set. RootDSE for a non-first level if DSA is suprbit set.

glue Glue DSE.

entry 3 3 3 Object entry DSE; also an administrativepoint if admPoint bit set; context prefix ifcp bit set; nssr if nssr bit set

alias 3 Alias entry DSE.

subentry Subentry DSE.

subr 3 Subordinate reference DSE; subordinatereference points to alias if sa bit is set.

immSupr 3 Immediate superior reference.

xr Cross reference DSE.

Note – The DSE type subr and immSupr may also occur (possibly with the additional bit admPoint ), although it is notconvenient to represent it in the table. Subentry and administrative point information maintained by RHOBs are indicated bythe presence of the rhob bit.

The first column of the table designates the DSE types which need not combine with any other DSE type to expressthe function of a DSE. For example, a DSE may be found with only the entry bit set. The second through sixthcolumns indicate by a tick mark (3) additional DSE type bits that may also be set in addition to the bit designated inthe first column. These bits may be set independently. For example, an entry DSE may also have the nssr bit, theadmPoint and cp bits, or several other combinations of the admPoint , cp and nssr bits set The final columndescribes the various DSE type combinations indicated in its table row.

Table M-2 specifies a number of additional DSE type combinations that are likely to occur when shadowing occurs.As in the case of the previous table, the first column of the table designates the DSE types which need not, in ashadow DSA for the DSE, combine with any other DSE type to express the function of a DSE. The second throughsixth columns indicate by a tick mark (3) additional DSE type bits that may also be set in addition to the bitdesignated in the first column. These bits may be set independently.

ISO/IEC 9594-2 : 1993(E)

152 ITU-T Rec. X.501 (1993 E)

Table M-2 – Additional Defined DSE Type Combinations when Shadowing Employed

DSE Type admPoint cp supr nssr sa Comments

root 3 Root DSE for shadow first level DSA withan nssr.

entry 3 3 3 Object entry DSE; also an administrativepoint if admPoint bit set; context prefix ifcp bit set; nssr if nssr bit set

alias 3 Alias entry DSE.

subentry Subentry DSE.

subr 3 Subordinate reference DSE; subordinatereference points to alias if sa bit is set.

immSupr 3 Immediate superior reference.

admPoint 3 3 Administrative point DSE without userattributes (entry not shadowed); alsocontext prefix if cp bit set; also nssr ifnssr bit set.

cp 3 3 Context prefix DSE (entry not shadowed);also nssr if nssr bit set.

nssr Nssr DSE (entry not shadowed).

Note – The shadow bit is set in all cases in the table (and therefore not explicitly represented). As in the case of table G–1,the DSE type subr , immSupr and shadow may also occur (possibly with the additional bit admPoint ). Finally, for DSEswith the subr and/or immSupr bits set, the entry and shadow bits may also occur as shadowed entry information is overlaidon knowledge information maintained either by RHOBs or shadowing.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 153

Annex N — Modelling of knowledge(This annex does not form an integral part of the Recommendation | International Standard)

The following example illustrates an hypothetical DIT, its potential mapping onto three DSAs, and the informationthe DSAs would have to maintain (including knowledge information) to support the mapping.

In Figures N-1 and N-2 below the following symbols are used.

object entry

alias entry

subentry

extent of autonomousadministrative area

extent ofnaming context

Figure N-1 depicts the hypothetical DIT. It is partitioned into four autonomous administrative areas: the degeneratecases of the single entries {C=WW} and {C=VV} and the two subtrees rooted at {C=WW, O=ABC} and {C=VV,O=DEF}. One entry, {C=VV, O=DEF, OU=K}, is an alias of the object entry {C=WW, O=ABC, OU=I}.

Root

C=VVC=WW

O=ABC

OU=G

CN=l CN=m CN=n

OU=H

OU=I

O=DEF

OU=J OU=K

CN=o CN=p CN=qAutonomous

AdministrativeArea AA

AutonomousAdministrative

Area BB

CN=AA CN=BB

Figure N-1 – Hypothetical DIT

Figure N-2 depicts the partitioning of the hypothetical DIT into five naming contexts (A, B, C, D and E) and theirmapping onto three DSAs (DSA1, DSA2 and DSA 3). In the figure DSA1 holds context C, DSA2 holds contexts A,B and E, and DSA3 holds context D.

ISO/IEC 9594-2 : 1993(E)

154 ITU-T Rec. X.501 (1993 E)

Root

C=VVC=WW

O=ABC

OU=G

CN=l CN=m CN=n

OU=H

OU=I

O=DEF

OU=J OU=K

CN=o CN=p CN=qAutonomous

AdministrativeArea AA

AutonomousAdministrative

Area BB

CN=AA CN=BB

context Acontext B

context C context D

context E

DSA 1 DSA2 DSA3

Figure N-2 – Hypothetical DIT Mapped onto three DSAs

The knowledge held by the three DSAs is as follows: DSA1 employs DSA2 as its superior reference and has a non-specific subordinate reference to DSA2 for information subordinate to {C=WW, O=ABC}. DSA2 is a first levelDSA and maintains a subordinate reference to DSA1 for context C and an immediate superior reference to it for thecontext immediately superior to context E. DSA2 maintains a subordinate reference to DSA3 for context D. DSA3also employs DSA2 as its superior reference and has a cross reference to DSA 2 for context E.

Figures N-3 through N-6 depict the information held in each of the DSAs (i.e. the DSA information tree of eachDSA) to support this configuration. The following symbols are employed in these figures.

root DSE

glue DSE

subr DSE

entry DSE

alias DSE

subentry DSE

also DSE type x xr DSE(x)

Figure N-3 illustrates the DSA information tree of DSA1.

Since DSA1 is not a first level DSA, its root DSE holds a superior reference, which in this example is the accesspoint for DSA2. This DSE is of type root + supr.

DSA1 holds one glue DSE to represent its knowledge of the name {C=WW}.

The autonomous administrative area AA is subdivided into two naming contexts C and E, with context C held inDSA1. For the sake of simplicity in this example it is assumed that the specific administrative areas relative toaccess control and subschema information coincide and that there is a single access control domain and a singlesubschema for the entire autonomous administrative area. A consequence of this is that only a single (multi-purpose)subentry is required for each of the autonomous administrative areas of the example.

For DSA1 the DSE at {C=WW, O=ABC}, representing the administrative point for AA, the context prefix forcontext C and an non-specific subordinate reference to DSA2, is of type entry + cp + admPoint + nssr. The areaoperational information is held in the subentry {C=WW, O=ABC, CN=AA}.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 155

DSA1 holds the following entries contained in context C: {C=WW, O=ABC, OU=G}, {C=WW, O=ABC, OU=H},{C=WW, O=ABC, OU=G, CN=l}, {C=WW, O=ABC, OU=G, CN=m} and {C=WW, O=ABC, OU=G, CN=n}.

(cp + admPoint + nssr + entry)

Root

C=WWC=WW

O=ABC

OU=G

CN=l CN=m CN=n

OU=H

CN=AA

(supr)

Figure N-3 – DSA Information Tree for DSA1

Figure N-4 illustrates one potential DSA information tree for DSA2.

In this hypothetical situation, DSA2 is a first level DSA, so its root DSE does not hold a superior reference.

The two degenerate autonomous administrative areas, {C=WW} and {C=VV} are represented by DSEs of type cp +entry + admPoint.

Subordinate knowledge of the DIT is represented by two subordinate reference DSEs, {C=WW, O=ABC} and{C=VV, O=DEF}. In the former case this DSE is of type subr + admPoint + immSupr + rhob for reasons that willbe described next.

In Figure N-4 DSA2 is configured assuming that a single subentry holds the area operational information regardingAA. This requires that a copy of the subentry be present at DSA2 (for reasonable performance). One way toaccomplish this is by establishing a NHOB between DSA1 and DSA2 to maintain a copy of the subentry. In thiscase the area operational information is held in the DSE named {C=WW, O=ABC, CN=AA} which is of typesubentry + rhob . The administrative-role attribute held in the DSE at {C=WW, O=ABC}is provided to DSA2from DSA1 as part of the NHOB. For this reason the DSE is of type admPoint + rhob.

Finally the naming context E is held as the context prefix DSE {C=WW, O=ABC, OU=I) which is of type cp +entry and the three entry DSEs {C=WW, O=ABC, OU=I, CN=o}, {C=WW, O=ABC, OU=I, CN=p} and {C=WW,O=ABC, OU=I, CN=q}.

ISO/IEC 9594-2 : 1993(E)

156 ITU-T Rec. X.501 (1993 E)

Root

C=VVC=WW

OU=I

CN=o CN=p CN=q

CN=AA

C=VV

O=DEFO=ABC

(rhob)

(admPoint + immSupr +rhob)

(cp + entry)

(cp + admPoint) (cp + admPoint + entry)


An alternative means of configuring DSA2 is illustrated in Figure N-5.

This differs from the configuration depicted in Figure P–4 only in the handling of the area operational information,motivated, perhaps, by a desire to avoid having to maintain a NHOB with DSA1.

The strategy in this case is to partition AA (i.e. partition the domain access control information—and similarly thesubschema information) into two autonomous administrative areas, one coinciding with context C and the other withcontext E

In this case the context prefix DSE {C=WW, O=ABC, OU=I} also becomes an administrative point, the DSE typebeing cp + admPoint + entry . Instead of a shadowed subentry supplied by DSA1 as part of a NHOB, the reducedarea operational information is held in the subentry {C=WW, O=ABC, OU=I, CN=AA}.

Root

C=VVC=WW

OU=I

CN=o CN=p CN=q

CN=AA

C=VV

O=DEFO=ABC

(cp + admPoint + entry)

(cp) (cp)

Figure N-5 – Alternative DSA Information Tree for DSA2

Figure N-6 illustrates the DSA information tree of DSA3.

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 157

Like DSA1, DSA 3 is not a first level DSA. Its root DSE holds a superior reference, which in this example is theaccess point for DSA2. This DSE is of type root + supr.

DSA2 holds one glue DSE to represent its knowledge of the name {C=VV}.

The autonomous administrative area BB coincides with the naming context D. For the sake of simplicity in thisexample it is assumed, as in the case of the autonomous administrative area AA, that the specific administrativeareas relative to access control and subschema information coincide and that there is a single access control domainand a single subschema for the entire autonomous administrative area. Thus only a single (multi-purpose) subentry isrequired for each of the autonomous administrative areas of the example.

For DSA3 the DSE at {C=VV, O=DEF}, representing the administrative point for BB and the context prefix forcontext D, is of type entry + cp + admPoint. The area operational information is held in the subentry {C=VV,O=DEF, CN=BB}.

DSA3 holds one object and one alias entry contained in context D: {C=VV, O=DEF, OU=J}, (of type entry) and{C=VV, O=DEF, OU=K} (of type alias and containing an attribute aliasedEntryName having the value {C=WW,O=ABC, OU=I}).

Finally, DSA3 holds a cross reference to context E, a DSE of type xr with name {C=WW, O=ABC, OU=I}.

OU=I

Root

C=VV

O=DEF

OU=J OU=K

CN=BB(cp + admPoint + entry)

(supr)

C=WW

O=ABC


ISO/IEC 9594-2 : 1993(E)

158 ITU-T Rec. X.501 (1993 E)

Annex P — Alphabetical index of definitions(This annex does not form an integral part of this Recommendation | International Standard)

This annex alphabetically lists all of the terms defined in this Directory Specification together with a cross referenceto the clause in which they are defined.

A access control scheme ................................ clause 15access point .................................................. clause 6Administration Directory ManagementDomain ........................................................ clause 6administrative area..................................... clause 10Administrative Authority............................. clause 6administrative entry ................................... clause 10administrative point ................................... clause 10administrative user ..................................... clause 10alias .............................................................. clause 9alias entry..................................................... clause 7alias dereferencing ........................ see dereferencingalias name .................................................. see aliasattribute ........................................................ clause 8attribute hierarchy ........................................ clause 8attribute subtype (subtype) .......................... clause 8attribute supertype (supertype) .................... clause 8attribute syntax .......................................... clause 12attribute type ................................................ clause 8attribute value .............................................. clause 8attribute value assertion ............................... clause 8autonomous administrative area ................ clause 10auxiliary object class .................................... clause 8

B base ............................................................ clause 11

C category...................................................... clause 18chop............................................................ clause 11collective attribute ....................................... clause 8commonly usable ....................................... clause 18context prefix ............................................. clause 17cooperative state ........................................ clause 21cross reference ........................................... clause 18

D dereferencing ............................................... clause 9direct attribute reference .............................. clause 8direct superclass ........................................... clause 7(the) Directory ............................................. clause 6Directory administrative and operationalInformation .................................................. clause 6Directory entry............................................. clause 7Directory Information Base (DIB) .............. clause 7DIB fragment ............................................. clause 17Directory Information Tree (DIT) ............... clause 7Directory Management Domain (DMD) ..... clause 6directory name ............................................. clause 9Directory operational attribute .................. clause 11directory operational framework ............... clause 21Directory Schema ...................................... clause 12Directory Subschema................................. clause 12Directory system schema........................... clause 11Directory System Agent (DSA)................... clause 6Directory user .............................................. clause 6Directory User Agent (DUA) ...................... clause 6Directory user information .......................... clause 6

distinguished name ...................................... clause 9distinguished value ...................................... clause 8DIT Content Rule ...................................... clause 12DIT Domain................................................. clause 6DIT Domain Administrative Authority ..... clause 10DIT Domain policy ................................... clause 10DIT Structure Rule .................................... clause 12DMD Administrative Authority ............... clause 10DMD policy.............................................. clause 10DMO policy.............................................. clause 10DSA information tree ............................... clause 19DSA–shared attribute ................................ clause 19DSA–specific attribute .............................. clause 19DSA–specifc entry..................................... clause 19DSE type .................................................. clause 19

E entry ........................................................... clause 11entry collection ............................................ clause 8entry name ................................................... clause 9

G Governing Structure Rule ......................... clause 12

I immediate(ly) superior ................................ clause 7immediate superior reference .................... clause 18indirect attribute reference........................... clause 8inner administrative area ........................... clause 10

K knowledge (information) ........................... clause 18knowledge reference................................. clause 18

M master knowledge...................................... clause 18matching rule .............................................. clause 8matching rule assertion................................ clause 8

N naming authority ......................................... clause 9naming context .......................................... clause 17Name Form................................................ clause 12non–cooperative state ................................ clause 21non–specific subordinate reference ........... clause 18

O object (of interest) ....................................... clause 7object class ................................................... clause 7object entry .................................................. clause 7operational attribute ..................................... clause 8operational binding.................................... clause 21operational binding type ............................ clause 21operational binding instance...................... clause 21operational binding establishment ............. clause 21operational binding modification ............. clause 21operational binding terminiation ............... clause 21operational binding management .............. clause 21

P policy ......................................................... clause 10policy attribute ........................................... clause 10policy object .............................................. clause 10

ISO/IEC 9594-2 : 1993(E)

ITU-T Rec. X.501 (1993 E) 159

policy procedure ........................................ clause 10policy parameter ........................................ clause 10Private Directory Management Domain ..... clause 6protected item ............................................ clause 15purported name............................................ clause 9

R reference path ............................................ clause 18relative distinguished name ......................... clause 9

S shadow knowledge .................................... clause 18specific administrative area ....................... clause 10specific administrative point ..................... clause 10structural object class .................................. clause 8Structural Object Class of an entry ............. clause 7subclass ........................................................ clause 7

subentry ..................................................... clause 11subtype ................................... see attribute subtypesubordinate .................................................. clause 7subordinate reference ................................ clause 18Subschema ...................... see Directory Subschemasubtree ....................................................... clause 11subtree refinement ..................................... clause 11subtree specification .................................. clause 11superclass .................................................... clause 7superior ........................................................ clause 7superior reference ...................................... clause 18Superior Structure Rule ............................. clause 12supertype ............................. see attribute supertype

U user attribute ................................................ clause 8

ISO/IEC 9594-2 : 1993(E)

160 ITU-T Rec. X.501 (1993 E)

Annex R — Amendments & corrigenda(This annex does not form an integral part of this Recommendation | International Standard)

This edition of this Directory Specification includes the following amendments:

— Amendment 1 for Access Control

— Amendment 2 for Schema Extensions

— Amendment 3 for Replication

This edition of this Directory Specification includes the following technical corrigenda correcting the defects in thefollowing defect reports (some parts of some of the following Technical Corrigenda may have been subsumed by theamendments that formed this edition of this Directory Specification):

— Technical Corrigendum 1 (covering Defect Reports 006, 021).

— Technical Corrigendum 2 (covering Defect Reports 036, 037).

information technology — open systems interconnection...

Documents