ISO/IEC 9594-3:2014

INTERNATIONAL ISO/IEC
STANDARD 9594-3
Seventh edition
2014-03-01
Information technology — Open Systems
Interconnection — The Directory —
Part 3:
Abstract service definition
Technologies de l'information — Interconnexion de systèmes ouverts
(OSI) — L'annuaire
Partie 3: Définition du service abstrait

Reference number
©
ISO/IEC 2014
©  ISO/IEC 2014
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any
means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission.
Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2014 – All rights reserved

Foreword
ISO (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 IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and 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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. 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.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 9594-3 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 6, Telecommunications and information exchange between systems, in collaboration with
ITU-T. The identical text is published as Rec. ITU-T X.511 (10/2012).
This seventh edition cancels and replaces the sixth edition (ISO/IEC 9594-3:2008), which has been
technically revised. It also incorporates the Technical Corrigenda ISO/IEC 9594-3:2008/Cor.1:2011 and
ISO/IEC 9594-3:2008/Cor.2:2012.
ISO/IEC 9594 consists of the following parts, under the general title Information technology — Open Systems
Interconnection — 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: Public-key and attribute certificate frameworks
— Part 9: Replication
© ISO/IEC 2014 – All rights reserved

CONTENTS
Page
1 Scope . 1
2 Normative references . 1
2.1 Identical Recommendations | International Standards . 1
2.2 Other references . 2
3 Definitions . 2
3.1 Basic Directory definitions . 2
3.2 Directory model definitions . 2
3.3 Directory information base definitions . 2
3.4 Directory entry definitions . 2
3.5 Name definitions . 3
3.6 Distributed operations definitions . 3
3.7 Abstract service definitions . 3
4 Abbreviations . 4
5 Conventions . 4
6 Overview of the Directory service . 4
7 Information types and common procedures . 5
7.1 Introduction . 5
7.2 Information types defined elsewhere . 5
7.3 Common arguments . 6
7.4 Common results . 9
7.5 Service controls . 9
7.6 Entry information selection . 12
7.7 Entry information . 15
7.8 Filter . 17
7.9 Paged results . 20
7.10 Security parameters . 21
7.11 Common elements of procedure for access control. 23
7.12 Managing the DSA Information Tree . 24
7.13 Procedures for families of entries . 25
8 Bind, Unbind operations, Change Password and Administer Password operations . 26
8.1 Directory Bind . 26
8.2 Directory Unbind . 29
9 Directory Read operations . 29
9.1 Read . 29
9.2 Compare . 32
9.3 Abandon . 35
10 Directory Search operations . 35
10.1 List . 35
10.2 Search . 39
11 Directory Modify operations . 50
11.1 Add Entry . 50
11.2 Remove Entry . 52
11.3 Modify Entry . 54
11.4 Modify DN . 58
11.5 Change Password . 60
11.6 Administer Password . 61
12 Operations for LDAP messages . 62
12.1 LDAP Transport operation . 62
12.2 Linked LDAP operation . 64
13 Errors . 65
Rec. ITU-T X.511 (10/2012) iii

Page
13.1 Error precedence . 65
13.2 Abandoned . 65
13.3 Abandon Failed . 66
13.4 Attribute Error . 66
13.5 Name Error . 67
13.6 Referral. 68
13.7 Security Error . 68
13.8 Service Error . 69
13.9 Update Error . 71
14 Analysis of search arguments . 72
14.1 General check of search filter . 73
14.2 Check of request-attribute-profiles . 74
14.3 Check of controls and hierarchy selections . 76
14.4 Check of matching use . 76
Annex A – Abstract Service in ASN.1 . 78
Annex B – Operational semantics for Basic Access Control . 94
Annex C – Examples of searching families of entries . 107
C.1 Single family example . 107
C.2 Multiple families example . 108
Annex D – External ASN.1 module . 111
Annex E – Amendments and corrigenda . 115

iv Rec. ITU-T X.511 (10/2012)
Introduction
This Recommendation | International Standard, together with the other Recommendations | 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 that they hold, can be viewed as an integrated whole, called the
Directory. The information held by the Directory, collectively known as the Directory Information Base (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 of
technical agreement outside of the interconnection standards themselves, the interconnection of information processing
systems:
• from different manufacturers;
• under different managements;
• of different levels of complexity; and
• of different ages.
This Recommendation | International Standard defines the capabilities provided by the Directory to its users.
This Recommendation | International Standard provides the foundation frameworks upon which industry profiles can be
defined by other standards groups and industry forums. Many of the features defined as optional in these frameworks
may be mandated for use in certain environments through profiles. This seventh edition technically revises and
enhances the sixth edition of this Recommendation | International Standard.
This seventh edition specifies versions 1 and 2 of the Directory protocols.
The first and second editions specified only version 1. Most of the services and protocols specified in this edition are
designed to function under version 1. However some enhanced services and protocols, e.g., signed errors, will not
function unless all Directory entities involved in the operation have negotiated version 2. Whichever version has been
negotiated, differences between the services and between the protocols defined in the six editions, except for those
specifically assigned to version 2, are accommodated using the rules of extensibility defined in Rec. ITU-T X.519 |
ISO/IEC 9594-5.
Annex A, which is an integral part of this Recommendation | International Standard, provides the ASN.1 module for the
Directory abstract service.
Annex B, which is not an integral part of this Recommendation | International Standard, provides charts that describe
the semantics associated with Basic Access Control as it applies to the processing of a Directory operation.
Annex C, which is not an integral part of this Recommendation | International Standard, gives examples of the use of
families of entries.
Annex D, which is not an integral part of this Recommendation | International Standard, includes an updated copy of an
external ASN.1 module referenced by this Directory Specification.
Annex E, which is not an integral part of this Recommendation | International Standard, lists the amendments and defect
reports that have been incorporated to form this edition of this Recommendation | International Standard.
Rec. ITU-T X.511 (10/2012) v
INTERNATIONAL STANDARD
RECOMMENDATION ITU-T
Information technology – Open Systems Interconnection –
The Directory: Abstract service definition
1 Scope
This Recommendation | International Standard defines in an abstract way the externally visible service provided by the
Directory.
This Recommendation | International Standard does not specify individual implementations or products.
2 Normative references
The following Recommendations and International Standards contain provisions which, through reference in this text,
constitute provisions of this Recommendation | International Standard. At the time of publication, the editions indicated
were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this
Recommendation | International Standard are encouraged to investigate the possibility of applying the most recent
edition of the Recommendations and Standards listed below. Members of IEC and ISO maintain registers of currently
valid International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of currently
valid ITU-T Recommendations.
2.1 Identical Recommendations | International Standards
– Recommendation ITU-T X.200 (1994) | ISO/IEC 7498-1:1994, Information technology – Open Systems
Interconnection – Basic Reference Model: The basic model.
– Recommendation ITU-T X.500 (2012) | ISO/IEC 9594-1:2014, Information technology – Open Systems
Interconnection – The Directory: Overview of concepts, models and services.
– Recommendation ITU-T X.501 (2012) | ISO/IEC 9594-2:2014, Information technology – Open Systems
Interconnection – The Directory: Models.
– Recommendation ITU-T X.509 (2012) | ISO/IEC 9594-8:2014, Information technology – Open Systems
Interconnection – The Directory: Public-key and attribute certificate frameworks.
– Recommendation ITU-T X.518 (2012) | ISO/IEC 9594-4:2014, Information technology – Open Systems
Interconnection – The Directory: Procedures for distributed operation.
– Recommendation ITU-T X.519 (2012) | ISO/IEC 9594-5:2014, Information technology – Open Systems
Interconnection – The Directory: Protocol specifications.
– Recommendation ITU-T X.520 (2012) | ISO/IEC 9594-6:2014, Information technology – Open Systems
Interconnection – The Directory: Selected attribute types.
– Recommendation ITU-T X.521 (2012) | ISO/IEC 9594-7:2014, Information technology – Open Systems
Interconnection – The Directory: Selected object classes.
– Recommendation ITU-T X.525 (2012) | ISO/IEC 9594-9:2014, Information technology – Open Systems
Interconnection – The Directory: Replication.
– Recommendation ITU-T X.680 (2008) | ISO/IEC 8824-1:2008, Information technology – Abstract
Syntax Notation One (ASN.1): Specification of basic notation.
– Recommendation ITU-T X.681 (2008) | ISO/IEC 8824-2:2008, Information technology – Abstract
Syntax Notation One (ASN.1): Information object specification.
– Recommendation ITU-T X.682 (2008) | ISO/IEC 8824-3:2008, Information technology – Abstract
Syntax Notation One (ASN.1): Constraint specification.
– Recommendation ITU-T X.683 (2008) | ISO/IEC 8824-4:2008, Information technology – Abstract
Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications.
Rec. ITU-T X.511 (10/2012) 1
2.2 Other references
– IETF RFC 2025 (1996), The Simple Public-Key GSS-API Mechanism (SPKM).
– IETF RFC 4422 (2006), Simple Authentication and Security Layer (SASL).
– IETF RFC 4511 (2006), Lightweight Directory Access Protocol (LDAP): The Protocol.
3 Definitions
For the purposes of this Recommendation | International Standard, the following definitions apply.
3.1 Basic Directory definitions
The following terms are defined in Rec. ITU-T X.500 | ISO/IEC 9594-1:
a) Directory;
b) Directory Information Base;
c) (Directory) User.
3.2 Directory model definitions
The following terms are defined in Rec. ITU-T X.501 | ISO/IEC 9594-2:
a) Directory System Agent;
b) Directory User Agent.
3.3 Directory information base definitions
The following terms are defined in Rec. ITU-T X.501 | ISO/IEC 9594-2:
a) alias entry;
b) ancestor;
c) compound entry;
d) (Directory) entry;
e) Directory Information Tree;
f) family (of entries);
g) immediate superior;
h) immediately superior entry/object;
i) object;
j) object class;
k) object entry;
l) subordinate;
m) superior.
3.4 Directory entry definitions
The following terms are defined in Rec. ITU-T X.501 | ISO/IEC 9594-2:
a) attribute;
b) attribute type;
c) attribute value;
d) attribute value assertion;
e) context;
f) context type;
g) context value;
h) operational attribute;
2 Rec. ITU-T X.511 (10/2012)
i) matching rule;
j) user attribute.
3.5 Name definitions
The following terms are defined in Rec. ITU-T X.501 | ISO/IEC 9594-2:
a) alias, alias name;
b) distinguished name;
c) (directory) name;
d) purported name;
e) relative distinguished name.
3.6 Distributed operations definitions
The following terms are defined in Rec. ITU-T X.518 | ISO/IEC 9594-4:
a) bound DSA;
b) chaining;
c) initial performer;
d) LDAP requester;
e) referral.
3.7 Abstract service definitions
For the purposes of this Recommendation | International Standard, the following definitions apply.
3.7.1 additional search: A search that starts from joinBaseObject as specified by the originator in the search
request.
3.7.2 contributing member: A family member within a compound entry, which has made a contribution to either a
Read, Search or Modify Entry operation.
3.7.3 explicitly unmarked entry: An entry or a family member that is excluded from the SearchResult
according to a specification given in a control attribute referenced by the governing-search-rule.
3.7.4 family grouping: A set of members of a compound attribute that are grouped together for the purpose of
operation evaluation.
3.7.5 filter: An assertion about the presence or value of certain attributes of an entry in order to limit the scope of a
search.
3.7.6 originator: The user that originated an operation.
3.7.7 participation member: A family member that is either a contributing member or is a member of a family
grouping that as a whole matched a search filter.
3.7.8 primary search: The search that starts from baseObject as specified by the originator in the search request.
3.7.9 relaxation: A progressive modification of the behaviour of a filter during a search operation so as to achieve
more matched entries if too few are received, or fewer matched entries if too many are received.
3.7.10 reply: A DAP/DSP result or an error; or an LDAP result.
3.7.11 request: Information consisting of an operation code and associated arguments to convey a directory
operation from a requester to a performer.
3.7.12 requester: A DUA, an LDAP client or a DSA sending a request to perform (i.e., invoke) an operation.
3.7.13 service controls: Parameters conveyed as part of an operation, which constrain various aspects of its
performance.
3.7.14 strand: A family grouping comprising all the members in a path from a leaf family member up to the ancestor
inclusive. A family member will reside in as many strands as there are leaf family members below it (as immediate or
non-immediate subordinates).
Rec. ITU-T X.511 (10/2012) 3
4 Abbreviations
For the purposes of this Recommendation | International Standard, the following abbreviations apply.
ACI Access Control Information
AVA Attribute Value Assertion
DIB Directory Information Base
DIT Directory Information Tree
DMD Directory Management Domain
DSA Directory System Agent
DUA Directory User Agent
LDAP Lightweight Directory Access Protocol
RDN Relative Distinguished Name
5 Conventions
The term "Directory Specification" (as in "this Directory Specification") shall be taken to mean Rec. ITU-T X.511 |
ISO/IEC 9594-3. The term "Directory Specifications" shall be taken to mean the X.500-series Recommendations and all
parts of ISO/IEC 9594.
This Directory Specification uses the term first edition systems to refer to systems conforming to the first edition of the
Directory Specifications, i.e., the 1988 edition of the series of CCITT X.500 Recommendations and the
ISO/IEC 9594:1990 edition.
This Directory Specification uses the term second edition systems to refer to systems conforming to the second edition
of the Directory Specifications, i.e., the 1993 edition of the series of ITU-T X.500 Recommendations and the
ISO/IEC 9594:1995 edition.
This Directory Specification uses the term third edition systems to refer to systems conforming to the third edition of the
Directory Specifications, i.e., the 1997 edition of the series of ITU-T X.500 Recommendations and the
ISO/IEC 9594:1998 edition.
This Directory Specification uses the term fourth edition systems to refer to systems conforming to the fourth edition of
the Directory Specifications, i.e., the 2001 editions of Recs ITU-T X.500, X.501, X.511, X.518, X.519, X.520, X.521,
X.525, and X.530, the 2000 edition of Rec. ITU-T X.509, and parts 1-10 of the ISO/IEC 9594:2001 edition.
This Directory Specification uses the term fifth edition systems to refer to systems conforming to the fifth edition of the
Directory Specifications, i.e., the 2005 edition of the series of ITU-T X.500 Recommendations and the
ISO/IEC 9594:2005 edition.
This Directory Specification uses the term sixth edition systems to refer to systems conforming to the sixth edition of the
Directory Specifications, i.e., the 2008 edition of the series of ITU-T X.500 Recommendations and the
ISO/IEC 9594:2008 edition.
This Directory Specification uses the term seventh edition systems to refer to systems conforming to the seventh edition
of the Directory Specifications, i.e., the 2012 edition of the ITU-T X.500-series Recommendations and the
ISO/IEC 9594:2014 edition.
This Directory Specification presents ASN.1 notation in the bold Courier New typeface. When ASN.1 types and values
are referenced in normal text, they are differentiated from normal text by presenting them in the bold Courier New
typeface. The names of procedures, typically referenced when specifying the semantics of processing, are differentiated
from normal text by displaying them in bold Times New Roman. Access control permissions are presented in italicized
Times New Roman.
If the items in a list are numbered (as opposed to using "–" or letters), then the items shall be considered steps in a
procedure.
6 Overview of the Directory service
As described in Rec. ITU-T X.501 | ISO/IEC 9594-2, the services of the Directory are provided through access points to
DUAs, each acting on behalf of a user. These concepts are depicted in Figure 1. Through an access point, the Directory
provides service to its users by means of a number of Directory operations.
4 Rec. ITU-T X.511 (10/2012)
Access point
The
Directory
DUA
user Directory
X.511(12)_F01
Figure 1 – Access to the Directory
The Directory operations are of three different kinds:
a) Directory Read operations, which interrogate a single Directory entry;
b) Directory Search operations, which interrogate potentially several Directory entries; and
c) Directory Modify operations.
The Directory Read operations, the Directory Search operations and the Directory Modify operations are specified in
clauses 9, 10, and 11, respectively. Conformance to Directory operations is specified in Rec. ITU-T X.519 |
ISO/IEC 9594-5.
7 Information types and common procedures
7.1 Introduction
This clause identifies, and in some cases defines, a number of information types which are subsequently used in the
definition of Directory operations. The information types concerned are those which are common to more than one
operation, are likely to be in the future, or which are sufficiently complex or self-contained as to merit being defined
separately from the operation which uses them.
Several of the information types used in the definition of the Directory Service are actually defined elsewhere.
Clause 7.2 identifies these types and indicates the source of their definition. Each of the clauses (7.3 to 7.10) identifies
and defines an information type.
This clause also specifies some common elements of procedure that apply to most or all of the Directory operations.
7.2 Information types defined elsewhere
The following information types are defined in Rec. ITU-T X.501 | ISO/IEC 9594-2:
a) Attribute;
b) AttributeType;
c) AttributeValue;
d) AttributeValueAssertion;
e) Context;
f) ContextAssertion;
g) DistinguishedName;
h) Name;
i) OPTIONALLY-PROTECTED;
j) OPTIONALLY-PROTECTED-SEQ;
k) RelativeDistinguishedName.
The following information type is defined in Rec. ITU-T X.520 | ISO/IEC 9594-6:
a) PresentationAddress.
The following information types are defined in Rec. ITU-T X.509 | ISO/IEC 9594-8:
a) Certificate;
Rec. ITU-T X.511 (10/2012) 5
SIGNED;
b)
c) CertificationPath.
The following information type is defined in Rec. ITU-T X.880 | ISO/IEC 13712-1:
a) InvokeId.
The following information types are defined in Rec. ITU-T X.518 | ISO/IEC 9594-4:
a) OperationProgress;
ContinuationReference.
b)
7.3 Common arguments
The CommonArguments information may be present to qualify the invocation of each operation that the Directory can
perform.
CommonArguments ::= SET {
serviceControls   [30] ServiceControls  DEFAULT {},
securityParameters  [29] SecurityParameters OPTIONAL,
requestor      [28] DistinguishedName OPTIONAL,
operationProgress  [27] OperationProgress
DEFAULT {nameResolutionPhase notStarted},
aliasedRDNs     [26] INTEGER      OPTIONAL,
criticalExtensions  [25] BIT STRING     OPTIONAL,
referenceType    [24] ReferenceType   OPTIONAL,
entryOnly      [23] BOOLEAN      DEFAULT TRUE,
exclusions      [22] Exclusions     OPTIONAL,
nameResolveOnMaster [21] BOOLEAN      DEFAULT FALSE,
operationContexts  [20] ContextSelection  OPTIONAL,
familyGrouping    [19] FamilyGrouping   DEFAULT entryOnly,
... }
NOTE 1 – The above data type can only be used when included in set-constructs. An alternative data type
CommonArgumentsSeq has been defined to be used in sequence-constructs (see Annex A).
The ServiceControls component is specified in clause 7.5. Its absence is deemed equivalent to there being an empty
set of controls.
The SecurityParameters component is specified in clause 7.10. If the argument of the operation is to be signed by
the requester, the SecurityParameters component shall be included. The absence of the SecurityParameters
component is deemed equivalent to an empty set.
The requestor component, when present, shall hold the distinguished name of the originator (requester) of the
operation. If the distinguished name of the requester was established at bind time, the requestor component shall be
equal to that distinguished name. Likewise, it shall be equal to the distinguished name in subject field of the
end-entity public-key certificate of the requester if the certification-path component of the
SecurityParameters is present.
NOTE 2 – The bound DSA should check the equality of the distinguished names as indicated above (pre-seventh edition systems
may not do that).
NOTE 3 – If the distinguished name of the requester was not established at bind time and the certification-path component
of the SecurityParameters is not present in the request, a possible value in the requester component should not be
considered reliable for access control purposes.
The operationProgress, referenceType, entryOnly, exclusions and nameResolveOnMaster components
are defined in Rec. ITU-T X.518 | ISO/IEC 9594-4. They are supplied by a DUA either:
a) when acting on a continuation reference returned by a DSA in response to an earlier operation, and their
values are copied by the DUA from the continuation reference; or
b) when the DUA represents an administrative user that is managing the DSA Information Tree and the
manageDSAIT option is set in the service controls.
The aliasedRDNs component indicates to the DSA that the object component of the operation was created by the
dereferencing of an alias on an earlier operation attempt. The integer value indicates the number of RDNs in the name
that came from dereferencing the alias. (The value would have been set in the referral response of the previous
operation.)
NOTE 4 – This component is provided for compatibility with first edition implementations of the Directory. DUAs (and DSAs)
implemented according to later editions of the Directory Specifications shall always omit this parameter from the
6 Rec. ITU-T X.511 (10/2012)
CommonArguments of a subsequent request. In this way, the Directory will not signal an error if aliases dereference to further
aliases.
The operationContexts component supplies a set of context assertions which are applied to attribute value
assertions and entry information selection made within this operation, which do not otherwise contain context assertions
for the same attribute type and context type. If operationContexts is not present or does not address a particular
attribute type or context type, then default context assertions shall be applied by the DSA as described in clause 7.6.1
and in clauses 8.9.2.2 and 12.8 of Rec. ITU-T X.501 | ISO/IEC 9594-2. If allContexts is chosen, then all contexts for
all attribute types are valid and context defaults that might have been supplied by the DSA are overridden.
(ContextSelection is defined in clause 7.6).
familyGrouping is used to describe which family members should be selected for processing by a given operation. It
is described more fully in clause 7.3.2.
7.3.1 Critical extensions
The criticalExtensions component provides a mechanism to list a set of extensions that are critical to the
performance of a Directory operation. If the originator of the extended operation wishes to indicate that the operation
shall be performed with one or more extensions (i.e., that performing the operation without these extensions is not
acceptable), it does so by setting the criticalExtensions bit(s) which corresponds to the extension(s). If the
Directory, or some part of it, is unable to perform a critical extension, it returns an indication of
unavailableCriticalExtension (as a serviceError or PartialOutcomeQualifier). If the Directory is
unable to perform an extension that is not critical, it ignores the presence of the extension.
This Directory Specification does not establish rules regarding the order in which a performing DSA is to decode and
process PDUs that it receives. A DSA that receives an unknown critical extension shall return a ServiceError with
problem unavailableCriticalExtension to signal that the operation failed.
These Directory Specifications define a number of extensions. The extensions take such forms as additional numbered
bits in a BIT STRING, or additional components of a SET or SEQUENCE, and are ignored by first edition systems.
Each such extension is assigned an integer identifier, which is the number of the bit that may be set in
criticalExtensions. If the criticality of an extension is defined to be critical, the DUA shall set the corresponding
bit in criticalExtensions. If the defined criticality is non-critical, the DUA may or may not set the corresponding
bit in criticalExtensions.
The extensions, their identifiers, the operations in which they are permitted, the recommended criticality, the clauses in
which they are defined, and the corresponding LDAP controls (if any) are shown in Table 1.
Table 1 – Extensions
Defined
Extension Identifier Operations Criticality LDAP control
(clauses)
subentries 1 All Non-critical 7.5 1.3.6.1.4.1.4203.1.10.1
copyShallDo 2 Read, Compare, List, Non-critical 7.5
Search
attribute size limit 3 Read, Search Non-critical 7.5
extraAttributes 4 Read, Search Non-critical 7.6
modifyRightsRequest 5 Read Non-critical 9.1
pagedResultsRequest 6 List, Search Non-critical 10.1 1.2.840.113556.1.4.319
matchedValuesOnly 7 Search Non-critical 10.2 1.2.826.0.1.3344810.2.3
extendedFilter 8 Search Non-critical 10.2
targetSystem 9 Add Entry Critical 11.1
useAliasOnUpdate 10 Add Entry, Remove Critical 11.1
Entry, Modify Entry
newSuperior 11 Modify DN Critical 11.4
manageDSAIT 12 All Critical 7.5, 7.12 2.16.840.1.113730.3.4.2
Use of contexts 13 Read, Compare, List, Non-critical 7.6, 7.8
Search, Add Entry,
Modify Entry, Modify
DN
partialNameResolution 14 Read, Search Non-critical 7.5
overspecFilter 15 Search Non-critical 10.1.3 f)
Rec. ITU-T X.511 (10/2012) 7
Table 1 – Extensions
Defined
Extension Identifier Operations Criticality LDAP control
(clauses)
selectionOnModify 16 Modify Entry Non-critical 11.3.2
17 Reserved 7.10
Security parameters – 18 All Non-critical 7.10
Operation code
Security parameters – 19 All Non-critical 7.10
Attribute certification
path
Security parameters – 20 All Non-critical 7.10
Error Protection
21-24 Reserved
Service administration 25 Read, Search, Critical 10.2.2, 13,
ModifyEntry clause 16 of Rec.
ITU-T X.501 |
ISO/IEC 9594-2
entryCount 26 Search Non-critical 10.1.3
hierarchySelections 27 Search Non-critical 10.2.2
relaxation 28 Search Non-critical 7.8
Compare, Non-critical 7.3.2, 7.8.3
familyGrouping 29
Search, Non-critical &
RemoveEntry Critical 9.2.2
10.2
11.2.2
familyReturn 30 Read, Non- 7.6.4, 7.7.1
Search, critical &
ModifyEntry Non- 9.1.3
critical 10.2.3
Non- 11.3.3
critical
dnAttributes 31 Search Non-critical 10.2.2
friend attributes 32 Read, Search Non-critical 7.6, 7.8.2
Abandon of paged 33 List, Search critical 7.9
results
Paged results on the 34 List, Search Non-critical 7.9
DSP
replaceValues 35 ModifyEntry critical 11.3.1, 11.3.2 1.3.6.1.1.14
NOTE 1 – The first extension is given the identifier 1 and corresponds to bit 1 of the BIT STRING. Bit 0 of the BIT STRING is
not used.
NOTE 2 – Use of signing on errors Add Entry, Remove Entry, Modify Entry, Modify DN requires version 2 or higher of the
protocol.
NOTE 3 – The SPKM credentials extension shall be critical unless used in associations established using version 2 or higher.
7.3.2 Family grouping
Family grouping allows a single family member, several family members or all family members of a compound entry,
to be grouped together for joint consideration prior to operation evaluation. These semantics can then be applied to the
following operations (as indicated in the descriptions below): Compare (to define the scope within which the compared
attribute might lie), Search (to define the groupings for which filtering might take place), Remove Entry (to define the
groupings for removal). The following ASN.1 is used to select members of a family:

FamilyGrouping ::= ENUMERATED {
entryOnly   (1),
compoundEntry (2),
strands    (3),
multiStrand  (4),
... }
entryOnly means that the specific family member selected by the operation is to be considered in the group. This is
the default value, and ensures backward compatibility with previous editions of the Directory Specifications.
8 Rec. ITU-T X.511 (10/2012)
compoundEntry means that the complete compound entry selected by the operation is to be considered as a unit by
combining all the attributes. For Remove Entry operations, it is only applicable when the object name specified is that
of an ancestor of a compound entry, and it causes all family members to be removed by the same operation (subject to
access control).
strands means that all the strands associated with the family member are to be selected by the operation. This option
is not valid for the Remove Entry operation. For the Search operation, individual strands are considered for filter
purposes. If the combined set of attributes of one or more strands matches the filter, the compound entry is said to
match the filter. If the base object is a child member, only those strands that go through the base object are considered.
For Compare operations, all the attributes from all the family members in all the strands to which the entry belongs are
to be used in the comparison.
multiStrand is only applicable to the Search operation, and qualifies the matching rule for filtering on family
information. It is ignored for other operations. It specifies that one strand from each family within a compound entry is
to be considered at one time, but in all combinations. multiStrand is not applicable if the base object is a child family
member, in which case multiStrand shall be ignored and entryOnly shall be substituted.
7.4 Common results
The CommonResults or CommonResultsSeq information is present to qualify the result of each retrieval operation
that the Directory can perform. In addition, it is present in any returned error.

CommonResults ::= SET {
securityParameters [30] SecurityParameters OPTIONAL,
performer      [29] DistinguishedName  OPTIONAL,
aliasDereferenced  [28] BOOLEAN       DEFAULT FALSE,
notification    [27] SEQUENCE SIZE (1.MAX) OF Attribute
{{SupportedAttributes}} OPTIONAL,
... }
CommonResultsSeq ::= SEQUENCE {
securityParameters [30] SecurityParameters OPTIONAL,
performer      [29] DistinguishedName OPTIONAL,
aliasDereferenced  [28] BOOLEAN DEFAULT FALSE,
notification    [27] SEQUENCE SIZE (1.MAX) OF Attribute
{{SupportedAttributes}} OPTIONAL,
... }
NOTE – CommonResults and CommonResultsSeq consist of the same components. The former is used when included in set
types by the COMPONENT OF type, while the latter is used similarly in sequence types.
The SecurityParameters component is specified in clause 7.10. If the result is to be signed by the Directory, the
SecurityParameters component shall be included in the result. The absence of the SecurityParameters
com
...