**TITLE: Information Technology-International Standardized Profile
ADY42 - the Directory Part 6 - DSA Authentication As DAP Responder**

**Editors:** Laura Boyer, J.G. Van Dyke & Associates, Inc.

> Sandi Miklos
>
> Bill Curtin, Defense Information Systems Agency (DISA)

**STATUS:** This is the eigth (and final) preliminary Draft of this
document.

**DATE:** 16-June-1998

**COMMENTS:**

**Contents**

Foreward [v](#__RefHeading___Toc416756193)

Introduction [vii](#__RefHeading___Toc416756194)

1\. Scope [1](#scope)

1.1 General [1](#general)

1.2 Position Within The Taxonomy [1](#position-within-the-taxonomy)

1.3 Scenario [2](#scenario)

2\. Normative References [3](#__RefHeading___Toc416756199)

2.1 Paired ITU Recommendations \| International Standards equivalent in
technical content [3](#__RefHeading___Toc416756200)

2.2 Normative Amendments and Technical Corrigenda
[5](#normative-amendments-and-technical-corrigenda2.2)

2.3 Additional Normative References [6](#__RefHeading___Toc416756202)

3\. Definitions [7](#definitions)

3.1 General [7](#general-1)

3.2 Conformance definitions [8](#conformance-definitions3.2)

3.3 Basic directory conformance definitions
[8](#basic-directory-conformance-definitions3.3)

4\. Abbreviations [8](#abbreviations)

5\. Conformance [9](#conformance)

5.1 Conformance Statement [9](#conformance-statement)

5.2 Static Conformance Requirements
[10](#static-conformance-requirements)

5.2.1 Simple Protected Authentication
[11](#simple-protected-authentication)

5.2.2 Strong Authentication in the Directory Bind
[11](#strong-authentication-in-the-directory-bind)

5.2.3 Signed DAP Operations [11](#signed-dap-operations)

5.2.4 Signed Results [12](#signed-results)

5.2.5 Certificates and Revocation Lists
[12](#certificates-and-revocation-lists)

5.2.5.1 Certificates [12](#__RefHeading___Toc416756216)

5.2.5.2 Revocation Lists [12](#revocation-lists)

5.2.5.3 Certification Hierarchy Topology
[13](#certification-hierarchy-topology)

6\. Procedures [14](#procedures)

6.1 Two-way Authentication [14](#two-way-authentication)

6.2 Random Numbers [15](#random-numbers)

6.3 Distinguished Encoding Rules [15](#distinguished-encoding-rules)

6.4 Simple Protected Authentication
[17](#simple-protected-authentication-1)

6.4.1 Responder to the Bind [17](#responder-to-the-bind)

6.4.2 Response to the Bind [18](#response-to-the-bind)

6.5 Strong Authentication in the Directory Bind
[19](#strong-authentication-in-the-directory-bind-1)

6.5.1 One-Way Strong Authentication [19](#one-way-strong-authentication)

6.5.2 Two-Way Strong Authentication [19](#two-way-strong-authentication)

6.5.3 Response to the Bind [20](#response-to-the-bind-1)

6.6 Signed DAP Operations [21](#signed-dap-operations-1)

6.6.1 Digitally Signed Directory Operations
[21](#digitally-signed-directory-operations)

6.6.2 Response to the Signed Operation
[21](#response-to-the-signed-operation)

6.7 Certificates [22](#certificates)

6.7.1 Certification Path Creation [22](#certification-path-creation)

6.7.2 Certification Path Use [22](#certification-path-use)

6.7.3 Certificate Processing [22](#certificate-processing)

6.7.4 Revocation List Processing [23](#revocation-list-processing)

**Annex A -- Profile Requirements List** [A-1](#section-7)

A.1 Introduction [A-1](#introductiona.1)

A.2 Identification of the Implementation
[A-1](#identification-of-the-implementationa.2)

A.2.1 Identification of the PICS [A-1](#identification-of-the-picsa.2.1)

A.3 Instructions [A-2](#instructions)

A.3.1 Purpose and structure of the PRL
[A-2](#purpose-and-structure-of-the-prl)

A.3.2 Symbols, terms, and abbreviations
[A-2](#symbols-terms-and-abbreviationsa.3.2)

A.3.2.1 Introduction [A-2](#introductiona.3.2.1)

A.3.2.2 Prerequisite notation [A-2](#prerequisite-notationa.3.2.2)

A.3.2.3 Item reference numbers s [A-3](#item-reference-numbersa.3.2.3)

A.3.2.4 Protocol Status column [A-3](#protocol-status-columna.3.2.4)

A.3.2.5 Profile Status column [A-4](#profile-status-columna.3.2.5)

A.3.2.6 Predicate column [A-4](#predicate-columna.3.2.6)

A.3.2.7 Predicate Name [A-4](#predicate-namea.3.2.7)

A.3.2.8 Note column [A-4](#note-columna.3.2.8)

A.4 PRL Tables [A-5](#prl-tablesa.4)

A.4.1 Roles [A-5](#rolesa.4.1-ref.-a.6.1)

A.4.2 General Capabilities and Global statement of conformance
[A-5](#general-capabilities-and-global-statement-of-conformancea.4.2)

A.4.2.1 General Capabilities
[A-5](#general-capabilitiesa.4.2.1-ref.-a.6.2.2.1)

A.4.2.2 Supported Security Levels
[A-5](#supported-security-levelsa.4.2.2-ref.-a.6.2.2.2)

A.4.2.3 Supported Access Control Schemes
[A-6](#supported-access-control-schemesa.4.2.3-ref.-a.6.2.2.3)

A.4.3 Capabilities and options [A-6](#capabilities-and-options.-a.4.3)

A.4.3.1 Supported application context
[A-6](#supported-application-context.-a.4.3.1)

A.4.3.2 Operations and extensions
[A-6](#operations-and-extensionsa.4.3.2)

A.4.3.2.1 Operations [A-6](#operationsa.4.3.2.1-ref.-a.6.3.2.1)

A.4.3.2.2 Extensions [A-6](#extensionsa.4.3.2.2-ref.-a.6.3.2.2)

A.4.3.3 Protocol elements [A-7](#protocol-elementsa.4.3.3)

A.4.3.3.1 DirectoryBind Elements [A-7](#directorybind-elementsa.4.3.3.1)

A.4.3.3.1.1 Directory Bind Arguments
[A-7](#directory-bind-argumentsa.4.3.3.1.1-ref.-a.6.3.3.1.1)

A.4.3.3.1.2 Directory Bind Result
[A-8](#directory-bind-resulta.4.3.3.1.2-ref.-a.6.3.3.1.2)

A.4.3.3.1.3 Directory Bind Error
[A-8](#directory-bind-errora.4.3.3.1.3-ref.-a.6.3.3.1.3)

A.4.3.3.2 Directory Unbind Elements
[A-8](#directory-unbind-elementsa.4.3.3.2)

A.4.3.3.3 Read Elements [A-9](#read-elementsa.4.3.3.3-ref.-a.6.3.3.3)

A.4.3.3.4 Compare Elements
[A-10](#compare-elementsa.4.3.3.4-ref.-a.6.3.3.4)

A.4.3.3.6 List Elements [A-11](#list-elementsa.4.3.3.6-ref.-a.6.3.3.6)

A.4.3.3.7 Search Elements
[A-12](#search-elementsa.4.3.3.7-ref.-a.6.3.3.7)

A.4.3.3.8 Add Entry Elements
[A-13](#add-entry-elementsa.4.3.3.8-ref.-a.6.3.3.8)

A.4.3.3.9 Remove Entry Elements
[A-13](#remove-entry-elementsa.4.3.3.9-ref.-a.6.3.3.9)

A.4.3.3.10 Modify Entry Elements
[A-14](#modify-entry-elementsa.4.3.3.10-ref.-a.6.3.3.10)

A.4.3.3.11 ModifyDN Elements
[A-14](#modifydn-elementsa.4.3.3.11-ref.-a.6.3.3.11)

A.4.3.3.12 Errors and Parameters
[A-14](#errors-and-parametersa.4.3.3.12-ref.-a.6.3.3.12)

A.4.3.3.13 Common Arguments Elements
[A-15](#common-arguments-elementsa.4.3.3.13-ref.-a.6.3.3.13)

A.4.3.3.14 Common Results Elements
[A-15](#common-results-elementsa.4.3.3.14-ref.-a.6.3.3.14)

A.4.3.3.15 Service Controls
[A-15](#service-controlsa.4.3.3.15-ref.-a.6.3.3.15)

A.4.3.3.16 Entry Information Selection
[A-15](#entry-information-selectiona.4.3.3.16-ref.-a.6.3.3.16)

A.4.3.3.17 Entry Information
[A-15](#entry-informationa.4.3.3.17-ref.-a.6.3.3.17)

A.4.3.3.18 Filter Elements
[A-16](#filter-elementsa.4.3.3.18-ref.-a.6.3.3.18)

A.4.3.3.19 Filter Item Elements
[A-16](#filter-item-elementsa.4.3.3.19-ref.-a.6.3.3.19)

A.4.3.3.20 Paged Results
[A-16](#paged-resultsa.4.3.3.20-ref.-a.6.3.3.20)

A.4.3.3.21 Continuation Reference
[A-16](#continuation-referencea.4.3.3.21-ref.-a.6.3.3.21)

A.4.3.3.22 Security Parameters
[A-16](#security-parametersa.4.3.3.22-ref.-a.6.3.3.22)

A.4.3.3.23 CertificationPath
[A-16](#certificationpatha.4.3.3.23-ref.-a.6.3.3.23)

A.4.3.3.23.1 Certificate
[A-17](#certificatea.4.3.3.23.1-ref.-a.6.3.3.23.1)

A.4.3.3.23.2 Algorithm Identifier
[A-17](#algorithm-identifiera.4.3.3.23.2-ref.-a.6.3.3.23.2)

A.4.3.3.23.3 Extensions
[A-17](#extensionsa.4.3.3.23.3-ref.-a.6.3.3.23.3)

A.4.3.3.24 Access Control [A-17](#access-controla.4.3.3.24)

A.4.3.3.25 Supported References
[A-18](#supported-referencesa.4.3.3.25-ref.-a.6.3.3.25)

A.4.3.3.26 Access Point [A-18](#access-pointa.4.3.3.26-ref.-a.6.3.3.26)

A.4.4 Directory Schema and Directory System Schema
[A-18](#directory-schema-and-directory-system-schema-ref.-a.6.4a.4.4)

A.4.4.1 Standard Object Classes
[A-18](#standard-object-classes-ref.-a.6.4.1.1a.4.4.1)

A.4.4.2 Attribute Types [A-18](#attribute-typesa.4.4.2-ref.-a.6.4.3.1)

A.4.5 Supported ISO/IEC 10646-1 Character Sets
[A-18](#supported-isoiec-10646-1-character-setsa.4.5)

**Annex B - Profile Specific Implementation Conformance Statement**
[B-1](#annex-b)

B.1 Introduction [B-1](#introductionb.1)

B.2 Identification of Profile Corrigenda
[B-1](#identification-of-the-profile-corrigendab.2)

B.3 General Security [B-2](#general-securityb.3)

B.4 Simple Authentication [B-2](#simple-authenticationb.4)

B.5 Strong Authentication [B-3](#strong-authenticationb.5)

B.6 Signed Operations [B-3](#signed-operationsb.6)

**Annex C - Recommended Practices** [C-2](#annex-c)

C.1 Certificate [C-2](#certificatec.1)

C.1.1 Certificate Cache Management
[C-2](#certificate-cache-management-c.1.1)

C.1.2 Revocation of Certificates [C-2](#revocation-of-certificatesc.1.2)

C.1.3 Certificate Revocation List
[C-2](#certificate-revocation-list-c.1.3)

C.1.4 Certificate Hierarchy [C-3](#certificate-hierarchyc.1.4)

C.1.4.1 Support of Hierarchical/Non-hierarchical CA-structures
[C-3](#support-of-hierarchicalnon-hierarchical-ca-structures-c.1.4.1)

C.2 Generation of Key Pairs [C-3](#generation-of-key-pairsc.2)

C.3 Use of Time Stamps [C-4](#use-of-time-stampsc.3)

C.4 Correlation of List and Search results
[C-4](#correlation-of-list-and-search-resultsc.4)

C.5 Periodic Revocation List Checks
[C-4](#periodic-revocation-list-checks-c.5)

**Annex D - Commonly Used Algorithms** [D-1](#annex-d)

D.1 Message Digest Algorithms [D-1](#message-digest-algorithmsd.1)

D.2 Reversible Public Key Algorithms
[D-1](#reversible-public-key-algorithmsd.2)

D.3 Irreversible Public Key Algorithms
[D-2](#irreversible-public-key-algorithmsd.3)

D.4 Signature Algorithms [D-2](#signature-algorithmsd.4)

Figures

Figure 1 : Scenario [2](#__RefHeading___Toc416777652)

Figure 2 : Returning Signed Results [3](#__RefHeading___Toc416777653)

Figure 3 : Certificate Hierarchies and evaluation paths
[13](#__RefHeading___Toc416777654)

Figure 4 : Validation strategies [14](#__RefHeading___Toc416777655)

Figure 5 : Simple Protected Authentication
[17](#__RefHeading___Toc416777656)

Figure 6 : One-Way Strong Authentication
[19](#__RefHeading___Toc416777657)

Figure 7: Two-Way Strong Authentication
[20](#__RefHeading___Toc416777658)

Figure 8: Digitally Signed Operations [21](#__RefHeading___Toc416777659)

Figure 9 : CA Structures [C-3](#__RefHeading___Toc416777660)

Tables

Table 1: Definitions and References [7](#__RefHeading___Toc416242907)

Foreword[]{#__RefHeading___Toc416756193 .anchor}

ISO (the International Organization for Standardization) and IEC (the
International Electrotechnical Commission) form the specialized system
for world-wide standardization. National bodies that are members of ISO
or IEC participate in the development of International Standards through
technical committees established by the respective organizations to deal
with particular fields of technical activity. ISO and IEC technical
committees collaborate in fields of mutual interest. Other international
organizations, governmental or 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 JTC1.

An International Standardized Profile is an internationally agreed,
harmonized document which identifies a standard or group of standards,
together with options and parameters, necessary to accomplish a function
or set of functions.

Draft International Standardized Profiles are circulated to national
bodies for voting. Publication as an International Standardized Profile
requires approval by at least 75% of the national bodies casting a vote.

This ISP, ISO/IEC ISP 15125 was prepared with the collaboration of the
following organizations:

-   Asia-Oceania Workshop (AOW)

-   European Workshop for Open Systems (EWOS)

-   European Telecommunications Standards Institute (ETSI)

-   Open Systems Environment Implementor's Workshop (OIW)

ISO/IEC ISP 15125 consists of the following parts under the general
title *Information Technology-International Standardized Profiles
ISO/IEC ISP 15125 -The Directory*

-   Introduction

-   Supporting Layers

-   Part 0 - Common Upper Layer Requirements for the Directory

-   Part 1-ADY11: DUA support of Directory Access Protocol

-   Part 2-ADY12: DUA support of Distributed Operations

-   Part 3-ADY21: DSA support of Directory Access Protocol

-   Part 4-ADY22: DSA support of Distributed Operations

-   Part 5-ADY41: DUA Authentication as DAP initiator

-   Part 6-ADY42: DSA Authentication as DAP responder

-   Part 7-ADY43: DSA Authentication for DSP

-   Part 9-ADY45: DSA Access Control [^1]

-   Part 10-ADY51: Shadowing using ROSE

-   Part 11-ADY52: Shadowing using RTSE

-   Part 12-ADY53: Shadowing subset

-   Part 13-ADY61: Administrative areas

-   Part 14-ADY62: Establishment and utilization of shadowing agreements

-   Part 15-ADY63: Schema administration and publication

-   Part 16-ADY71: Shadowing Operational Binding

-   Part 17-ADY72: Hierarchical Operational Binding

-   Part 18-ADY73: Non-specific Hierarchical Operational Binding

ISO/IEC ISP 15126 consists of the following parts under the general
title *Information Technology-International Standardized Profiles
ISO/IEC ISP 15126 -The Directory*

-   Part 1-FDY11: Common Directory Use

-   Part 2-FDY12: Directory System Schema

The present document contains two normative annexes:

-   Annex A: Profile Requirements List of ISO/IEC ISP 15125-6 - DSA
    Authentication as DAP Responder

-   Annex B: Profile Specific Implementation Conformance Statement (ICS)

    The present document contains two informative annexes:

-   Annex C: Recommended Practices

-   Annex D: Commonly Used Algorithms

-   

-   

-   

-   

Introduction[]{#__RefHeading___Toc416756194 .anchor}

The concept and structure of International Standardized Profiles for
Information Systems are laid down in the Technical Report ISO/IEC TR
10000. The purpose of an International Standardized Profile is to
recommend when and how certain information technology standards shall be
used. This International Standardized Profile ISO/IEC ISP 15125
specifies application profile ADY42 as defined in the Technical Report
ISO/IEC TR 10000-2.

ISO/IEC ISP 15125 is one of a set of International Standardized Profiles
relating to the Directory (see TR 10000-2) for the '93 standards.

ISO/IEC ISP 15125-6 profiles the manner in which DSAs are to behave when
authenticating simple protected authentication or strong authentication
as a DAP responder. ISO/IEC ISP 15125-6 also profiles the manner in
which DSAs will perform digitally signed operations with DUAs over a DAP
connection.

This International Standardized Profile (ISP) is defined within the
context of Functional Standardization, in accordance with the principles
specified by ISO/IEC TR 10000, \"Framework and Taxonomy of International
Standardized Profiles\". The concept of Functional Standardization is
one part of the overall field of Information Technology (IT)
standardization activities, covering base standards, profiles, and
registration mechanisms. A profile defines a combination of base
standards that collectively perform a specific well-defined IT function.
Profiles standardize the use of options and other variations in the base
standards, and provide a basis for the development of uniform,
internationally recognized system tests.

One of the most important roles for an ISP is to serve as the basis for
the development (by organizations other than ISO and IEC) of
internationally recognized tests and test methods. ISPs are produced not
simply to \"legitimise\" a particular choice of base standards and
options, but to promote real system interoperability. The development
and widespread acceptance of tests based on this and other ISPs is
crucial to the successful realisation of this goal.

The text of this ISP was developed in close co-operation among the
Directory Expert Groups of the three International OSI Workshops:

• OSE Implementors Workshop (OIW)

• The European Workshop for Open Systems (EWOS) and

• The OSI Asia-Oceania Workshop (AOW).

**INFORMATION TECHNOLOGY - International Standardized Profile 15125 -
The Directory**

**Part 6: DSA Authentication as DAP Responder**

# Scope

Primary DSA conformance requirements, when acting as a DAP responder,
are stated in the Directory Standards as profiled in ISO/IEC ISP 15125-3
(ADY 21). This part, ISO/IEC ISP 15125-6 (ADY 42), covers DSA specific
use of authentication beyond simple unprotected binds, the use of
different levels of authentication, the use of different security
infrastructures (e.g., support of hierarchical/non-hierarchical
CA-structures), and the use of protocol elements. In addition, it covers
actions by the DSA on handling (i.e., validating or not) credentials
sent by the DUA, the use of two-way strong authentication and digitally
signed operations. Any externally defined forms of authentication are
beyond the scope of this profile.

## General

This part of ISO/IEC ISP 15125 (ADY42) covers the Directory System Agent
(DSA) Authentication as a Directory Access Protocol (DAP) Responder as
defined in the 1993 ITU X.500 series of recommendations and the 1995
ISO/IEC 9594 series of standards. Although ITU X.509 describes a
framework for providing authentication services by the Directory, it
does not fully specify the behavior of a DSA acting as a responder of an
authenticated DAP request. This specification profiles the behavior that
a DSA supports when returning simple protected and strongly
authenticated bind results, or when responding to digitally signed
operations. This specification also profiles the behavior that a DSA
supports when resolving simple protected and strongly authenticated bind
requests. It also covers the DSA's role in generating digitally signed
DAP results. The protocol elements necessary to provide authentication
will also be discussed in this specification.

The objective of ISO/IEC ISP 15125-6 is to profile the DSA specific use
of authentication beyond simple unprotected binds and includes use of
different levels of authentication. It covers the issues involved in
receiving strong authentication during a Directory Bind and the
generation and use of digitally signed DAP operations. The use of
different security infrastructures (e.g. support of
hierarchical/non-hierarchical CA-structures) are discussed for
completeness and context. Factors outside the scope of ISO/IEC ISP
15125-6 include, but are not limited to key management processes,
algorithms, cryptographic processes, DIT structure, procedures for
distributed operations, simple authentication management, and the source
and synchronization of the time-stamp parameters used in one- and
two-way authentication.

## Position Within The Taxonomy

This part of ISO/IEC 15125 is one part of a multi part ISP identified in
ISO/IEC TR 10000-2 as \"ADY42- DSA Authentication as DAP Responder.\"

This part of ISO/IEC ISP 15125 shall be combined with Part 3 -- \"ADY21:
DSA Support of Directory Access Protocol\". Where there is a conflict
between this part and part 3 of the ISP, this part will take precedence.

It may be combined with other parts of ISO/IEC ISP 15125, or with
ISO/IEC ISP 15126 specifying the normal use of the directory, and with
T-Profiles specifying the OSI connection-mode transport service

## Scenario

A DSA may utilize various levels of authentication: none, simple
unprotected and simple protected authentication, strong authentication,
and externally defined methods. Simple unprotected authentication offers
limited protection using a password transmitted in the clear to verify
the users claimed identity. Simple protected authentication hashes the
password prior to transmission, for additional protection.

Strong authentication is based upon public-key cryptosystems and is used
to protect against a greater number of threats.

The authentication framework profiled in this specification is not
dependent on the use of a particular cryptographic algorithm. Strong
authentication makes use of cryptographic systems known as public-key
cryptosystems (PKCS). These cryptosystems are described as asymmetric,
involving a pair of keys, one private and one public.

For purposes of strong authentication, each user must have a unique
distinguished name and this name must be bound to the user's public key
in a manner that can be verified by other users in the system. The
user's unique name and public key information is placed into a structure
called a certificate.

A DSA may also return signed results for a given operation. This may
come in the form of the DSA returning a signed result in a role as a
centralized DSA or a DSA returning a signed result from a chained DSP
operation.

[]{#__RefHeading___Toc416756199 .anchor}When the DSA receives digitally
signed results from a remote DSA, it must be responsible for verifying
the DSP signature from that remote DSA. The DSA can then sign the DAP
result being passes to the DUA, thereby supporting end-to-end
signatures. DSA 'b' will be responsible for verifying the remote DSA's
DSP Signature, and the DUA 'a' will be responsible for verifying the
DSA's DAP Result Signature.

The DUA must be capable of verifying digital signatures from more than
one DSA if a distributed environment was used to generate the List or
Search results. Correlating the results of List and Search operations is
the responsibility of the DUA. DSA's should not merge these results on
behalf of the DUA user. In some cases, the DUA may receive information
from various DSAs each supporting different levels of authentication and
digital signatures. The DUA must make a decision whether or not to use
the returned information if the digital signature is invalid.

Signed operations associated with the Directory System Protocol are
addressed in ISO/IEC ISP 15125-7 (ADY 43). Signed operations associated
with the DUA acting as the Directory Access Protocol (DAP) initiator are
addressed in ISO/IEC ISP 15125-5 (ADY 41).

# Normative References

[]{#__RefHeading___Toc416756200 .anchor}

The following ITU-T Recommendations and International Standards contain
provisions which, through references in this text, constitute provisions
of this International Standardized Profile. At the time of publication,
the editions indicated were valid. All documents are subject to
revision, and parties to agreements based on this International
Standardized Profile are warned against automatically applying any more
recent editions of the documents listed below, since the nature of
references made by ISPs to such documents is that they may be specific
to a particular edition.

Members of IEC and ISO maintain registers of currently valid
International Standards and ISPs, and ITU-T maintains published editions
of its current Recommendations.

## Paired ITU Recommendations \| International Standards equivalent in technical content

-   ITU-T Recommendation X.500 (1993) \| ISO/IEC 9594-1:1995,
    *Information technology \-- Open Systems Interconnection \-- The
    Directory: Overview of concepts, models and services.*

-   ITU-T Recommendation X.501 (1993) \| ISO/IEC 9594-2:1995,
    I*nformation technology \-- Open Systems Interconnection \-- The
    Directory: Models.*

-   ITU-T Recommendation X.511 (1993) \| ISO/IEC 9594-3:1995,
    *Information technology \-- Open Systems Interconnection \-- The
    Directory: Abstract service definition.*

-   ITU-T Recommendation X.518 (1993) \| ISO/IEC 9594-4:1995,
    *Information technology \-- Open Systems Interconnection \-- The
    Directory: Procedures for distributed operations.*

-   ITU-T Recommendation X.519 (1993) \| ISO/IEC 9594-5:1995,
    *Information technology \-- Open Systems Interconnection \-- The
    Directory: Protocol specifications.*

-   ITU-T Recommendation X.520 (1993) \| ISO/IEC 9594-6:1995,
    *Information technology \-- Open Systems Interconnection \-- The
    Directory: Selected attribute types.*

-   ITU-T Recommendation X.521 (1993) \| ISO/IEC 9594-7:1995,
    *Information technology \-- Open Systems Interconnection \-- The
    Directory: Selected object classes.*

-   ITU-T Recommendation X.509 (1993) \| ISO/IEC 9594-8:1995,
    I*nformation technology \-- Open Systems Interconnection \-- The
    Directory: Authentication framework.*

-   ITU-T Recommendation X.525 (1993) \| ISO/IEC 9594-9:1995,
    *Information technology \-- Open Systems Interconnection \-- The
    Directory: Replication.*

-   ITU-T Recommendation X.583 (1997) \| ISO/IEC 13248-1: 1997,
    *Information technology \-- Open Systems Interconnection -Directory
    Access Protocol: Protocol Implementation Conformance Statement
    (PICS) Proforma.*

-   CCITT Recommendation X.680: 1994 \| ISO/IEC 8824-1:1994,
    I*nformation technology - Open Systems Interconnection (OSI) -
    Abstract Syntax Notation One (ASN.1): Specification of basic
    notation.*

-   CCITT Recommendation X.681: 1994 \| ISO/IEC 8824-2:1994,
    *Information technology - Open Systems Interconnection (OSI) -
    Abstract Syntax Notation One (ASN.1): Information Object
    Specification.*

-   CCITT Recommendation X.682: 1994 \| ISO/IEC 8824-3:1994,
    *Information technology - Open Systems Interconnection (OSI) -
    Abstract Syntax Notation One (ASN.1): Constraints Specification.*

-   CCITT Recommendation X.683: 1994 \| ISO/IEC 8824-4:1994,
    *Information technology - Open Systems Interconnection (OSI) -
    Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1
    specification.*

-   CCITT Recommendation X.684: 1994 \| ISO/IEC 8825-1:1994,
    *Information technology - Open Systems Interconnection (OSI) -
    Specification of Abstract Syntax Notation One (ASN.1) Encoding
    Rules: Basic, Canonical and Distinguished Encoding Rules.*

-   CCITT Recommendation X.880: 1994 \| ISO/IEC 13712-1:1994,
    *Information technology - Open Systems Interconnection (OSI) -
    Remote Operations: Concepts models and notation.*

-   CCITT Recommendation X.881: 1994 \| ISO/IEC 13712-2:1994,
    *Information technology - Open Systems Interconnection (OSI) - OSI
    Realizations - Remote Operations Service Element (ROSE) service
    definition.*

-   CCITT Recommendation X.882: 1994 \| ISO/IEC 13712-3:1994,
    *Information technology - Open Systems Interconnection (OSI) - OSI
    Realizations - Remote Operations Service Element (ROSE) protocol
    specification.*

## Normative Amendments and Technical Corrigenda2.2

-   Technical Corrigendum 1 to Recommendation X.501 (1993) \| ISO/IEC
    9594-2:1995 (covering resolutions to defect reports 088, 089, 090,
    091, 102, 104, 125)

-   Draft Technical Corrigendum 2 to Recommendation X.501 (1993) \|
    ISO/IEC 9594-2:1995 (covering resolutions to defect reports 134,
    136, 140, 143, 144, 145, 147, 149, 171, 172, 174)

-   Technical Corrigendum 1 to Recommendation X.509 (1993) \| ISO/IEC
    9594-8:1995 (covering resolutions to defect report 128)

-   Technical Corrigendum 2 to Recommendation X.509 (1993) \| ISO/IEC
    9594-8:1995 (covering resolutions to defect report 077, 078, 083,
    084)

-   Draft Technical Corrigendum 3 to Recommendation X.509 (1993) \|
    ISO/IEC 9594-8:1995 (covering resolutions to defect report 80, 92,
    100, 177, 183, 194, 196)

-   Technical Corrigendum 1 to Recommendation X.511 (1993) \| ISO/IEC
    9594-3:1995 (covering resolutions to defect report 085)

-   Draft Technical Corrigendum 2 to Recommendation X.511 (1993) \|
    ISO/IEC 9594-3:1995 (covering resolutions to defect reports 104,
    119, 133, 137, 138, 148, 150, 175)

-   Technical Corrigendum 1 to Recommendation X.518 (1993) \| ISO/IEC
    9594-4:1995 (covering resolutions to defect reports 094, 106, 108,
    109, 111, 112, 113, 114, 115)

-   Draft Technical Corrigendum 2 to Recommendation X.518 (1993) \|
    ISO/IEC 9594-4:1995 (covering resolutions to defect reports 116,
    117, 118, 119, 120, 121, 130, 152, 153, 154, 155, 156, 158, 160,
    161, 165, 167)

-   Technical Corrigendum 1 to Recommendation X.519 (1993) \| ISO/IEC
    9594-5:1995 (covering resolutions to defect reports 075, 124)

-   Draft Technical Corrigendum 2 to Recommendation X.519 (1993) \|
    ISO/IEC 9594-5:1995 (covering resolutions to defect reports 127,
    139)

-   Technical Corrigendum 1 to Recommendation X.520 (1993) \| ISO/IEC
    9594-6:1995 (covering resolutions to defect reports 076, 122, 127)

-   Draft Technical Corrigendum 2 to Recommendation X.520 (1993) \|
    ISO/IEC 9594-6:1995 (covering resolutions to defect reports 135,
    146)

-   Technical Corrigendum 1 to Recommendation X.525 (1993) \| ISO/IEC
    9594-9:1995 (covering resolutions to defect reports 097, 099, 123)

-   Draft Technical Corrigendum 2 to Recommendation X.525 \| ISO/IEC
    9594-9:1995 (covering resolutions to defect reports 132, 141, 142)

## Additional Normative References

-   CCITT Recommendation X.200 (1988) Reference Model of Open Systems
    Interconnection for CCITT Applications.

-   ISO 7498:1984, *Information Processing Systems - Open Systems
    Interconnection - Basic Reference Model.*

-   ISO/IEC 9646-1:1994, *Information technology \-- Open Systems
    Interconnection \-- Conformance testing methodology and framework -
    Part 1: General concepts.*

-   ISO/IEC 9646-7:1995, *Information technology \-- Open Systems
    Interconnection \-- Conformance testing methodology and framework -
    Part 7: Implementation conformance statements*

-   ISO/IEC TR 10000-1:1995, *Information Technology - Framework and
    taxonomy of International Standardized Profiles - Part 1:
    Framework.*

-   ISO/IEC TR 10000-2:1995, *Information Technology - Framework and
    taxonomy of International Standardized Profiles - Part 2: Taxonomy
    of Profiles.*

# Definitions

For the purpose of this part of ISO/IEC ISP 15125, the following
definitions apply

.

## General

Many of the definitions used may be found in the Standards. Since not
all of the definitions are to be found in the Definitions clauses within
the standards documents, references are listed in Table 1 below. The
Part referenced is ISO/IEC 9594 : 1995.

### 

## Conformance definitions3.2

The following terms are defined in ISO/IEC 9646:

> a\) Protocol Implementation Conformance Statement (PICS);
>
> b\) PICS Proforma;
>
> c\) Profile Requirements List (PRL)
>
> d\) conformance;
>
> e\) mandatory requirement;
>
> f\) optional requirement;
>
> g\) conditional requirement.

## Basic directory conformance definitions3.3

### 

### 

## 

-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   

## 

## 

## 

-   
-   
-   
-   
-   
-   
-   
-   

The terms in the following subclauses are defined for the purposes of
this ISP.

  ----------------- -----------------------------------------------------
  **Signed DAP      A DAP operation may use the SIGNED option of the
  Operation:**      OPTIONALLY-SIGNED information object class as defined
                    in 9594-3 Clauses 9.1.1, 9.2.1, 10.1.1, 10.2.1,
                    11.1.1, 11.2.1, 11.3.1, 11.4.1.

  **Policy CA**     The topmost CA in the CA hierarchy within an
                    organisation

  **Trusted CA**    A CA whose public key has been acquired in a trusted
                    manner (for example, by a DSA), support reliable
                    attribution of public keys, and follow procedures for
                    the protection of private keys.
  ----------------- -----------------------------------------------------

# Abbreviations

**The following abbreviations are used as defined in \[ITU-T Rec. X.500
(1993) \| ISO/IEC 9594:1995\] or in ISO/IEC TR 10000-1:**

ACSE Association Control Service Element

APDU Application Protocol Data Unit

ASN.1 Abstract Syntax Notation One

BER Basic Encoding Rules

CA Certification Authority

CCITT International Telegraph & Telephone Consultative Committee (now
ITU-T)

CRL Certificate Revocation List

DAP Directory Access Protocol

DER Distinguished Encoding Rules

DIB Directory Information Base

DIT Directory Information Tree

DSA Directory System Agent

DSA Directory User Agent

DSP Directory System Protocol

DUA Directory User Agent

IEC International Electrotechnical Commission

IPRL ISPICS Requirements List

ISPICS ISP Implementation Conformance Statement

ISO International Organization for Standardization

ISP International Standardized Profile

ITU International Telecommunications Union

ITU-T ITU Telecommunication Standardization Sector

IUT Implementation Under Test

KMS Key Management System

OSI Open Systems Interconnection

PDU Protocol Data Unit

PICS Protocol Implementation Conformance Statement

PKCS Public-Key Cryptosystems

PRL Protocol Requirements List

RDN Relative Distinguished Name

ROSE Remote Operations Service Element

SUT System Under Test

# Conformance

Primary DSA conformance requirements, when acting as a DAP responder,
are stated in the Directory Standards as profiled in ISO/IEC ISP 15125-3
(ADY 21). The protocol specifications stipulate the use of particular
elements concerned with the process of simple protected authentication,
strong authentication, or digital signatures, but in a number of cases
the contents of actual values are left incompletely specified.

ISO/IEC ISP 15125-6 addresses the procedures the DSA shall be capable of
supporting when responding to authenticated operations.

A DSA compliant with these procedures shall be capable of being tested
by setting up suitable test suites, which shall observe only the
externally observable behavior of the DSA. The conformance statements of
this ISP lay down the range of information for suitable DSA test suites.

## Conformance Statement

For each implementation claiming conformance to ISO/IEC ISP 15125-6, an
appropriate set of PICS, ITU-T Recommendation X.583 (1997) \| ISO/IEC
13248-1: 1997, shall be produced stating the support or non-support of
each option identified.

The PICS shall satisfy all DSA requirements defined in \[ISO/IEC
9594-8:1995 \| ITU X.509 (1993), part 3 of this ISP (ISO/IEC ISP
15125-3), non-DSP related distributed operations found in part 4 of this
ISP (ISO/IEC ISP 15125-4), in addition to the PRL found in Annex A and
the Profile Specific ICS found in Annex B of this document.

When combined, some features that are found in Annex A of this document
will overlap features found in the PRLs of ISO/IEC ISP 15125-3 and
ISO/IEC ISP 15125-4. In those cases the requirements defined in this
part of the ISP will take precedence.

ITU-T Recommendation X.583 (1997) \| ISO/IEC 13248-1: 1997 covers all
aspects of the DAP protocol. For the purpose of conformance for this
part of the ISP the implementation need only demonstrate support
appropriate to this part of the ISP (e.g. DSA column and signed
operations).

DSAs claiming conformance to ISO/IEC ISP 15125-6 shall satisfy Annex A
and Annex B of this document and also satisfy the basic conformance
requirements defined in \[ITU-T Rec. X.509 (1993) \| ISO/IEC
9594-8:1995\].

DSAs conformant with this part of the ISP shall claim conformance to one
or more of the following:

\- Simple Protected Authentication Conformance Requirements as specified
in Clause 5.2.1.

\- Strong Authentication for the bind as specified in Clause 5.2.2.

\- Signed operations as specified in Clause 5.2.3.

DSAs claiming conformance with this ISP for Simple Protected or Strong
Authentication for Directory Bind operations, or claiming conformance
for signed DAP operations, may optionally be able to claim conformance
to two-way authentication. If they do claim conformance to two-way
authentication, they shall be able to demonstrate conformance to the
corresponding procedures of Clause 6.2.

DSAs claiming conformance with this ISP for Simple Protected or Strong
Authentication in the Directory Bind shall comply with the error
handling procedures specified in ADY22 when carrying out Simple
Protected or Strong Authentication in the Directory Bind.

DSAs claiming conformance with this ISP for signed DAP operations shall
comply with the error handling procedures specified in ADY22. However,
handling of digitally signed errors is not supported.

DSAs claiming conformance with this ISP for Signed DAP operations shall
also support Strong Authentication in the Directory Bind.

## Static Conformance Requirements

Each feature (operation or protocol element) listed in Annex A is
designated as having a support requirement of mandatory, optional,
conditional, excluded, out-of-scope, or not applicable. Some features
have a conditional designation specifying whether the feature is
mandatory or optional based on a predicate. The conditions and
predicates are stated in the PRL. Implementations shall support all
features designated mandatory in the PRL except those that are part of
an unsupported protocol element. Where protocol elements are nested, the
requirement to support the nested element is relevant only when the
immediately containing element is supported.

### Simple Protected Authentication

DSAs claiming conformance to Simple Protected Authentication, as
responder, shall be:

1.  Configurable to require Simple Protected Authentication as the sole
    means of authentication.

2.  Able to accept and validate simple protected credentials generated
    by the initiator of a Directory Bind, in accordance with the
    procedures specified in Clause 6.4.2, and able to create return
    credentials in accordance with the procedures specified in Clause
    6.4.2 or able to respond with an appropriate Bind Error.

3.  Able to acquire or hold its own password without requiring any
    Directory operation to other DSAs.

4.  Able to configure a validity period for the acceptability of a
    protected password.

The support of Simple Protected Authentication using **time2** and
**random2** is outside the scope of this ISP.

These requirements do not preclude DSAs from *additionally* supporting
procedures other than those specified in the referenced clauses.

### Strong Authentication in the Directory Bind

DSAs claiming conformance to Strong Authentication on a Bind Request and
Bind Result, as responder shall be:

1.  Configurable to require Strong Authentication as the sole means of
    authentication that can be accepted.

    Note: A conformant DSA may nevertheless be configurable to accept
    any or all of the forms of authentication permitted by the Directory
    standards at any particular time.

2.  Capable of accepting and validating strong credentials generated by
    the initiator of a Directory Bind, in accordance with the procedures
    specified in Clause 6.5.2; creating return strong credentials in
    accordance with the procedures specified in Clause 6.5.2 or
    responding with an appropriate Bind Error in accordance with the
    procedures profiled in ADY22.

3.  Capable of obtaining (as necessary) and validating (i) the user\'s
    certificate (if not provided in the bind-request), (ii) CA
    Certificates (if not provided in the bind-request), and (ii)
    Revocation Lists relevant to the certificates held for the initiator
    of the Directory Bind with the requirements specified in Clause
    5.2.4 below, and in the event of invalidity sending a bind error to
    the DUA.

These requirements do not preclude DSAs from *additionally* supporting
procedures other than those specified in the referenced clauses.

### Signed DAP Operations

DSAs claiming conformance to Signed DAP Operations, as performer, shall
be:

1\. Capable of signing operations as requested in the
**ProtectionRequest** field and as specified in ISO/IEC 9594-3 Clause
7.10.

2\. Configurable to require all DAP operations to be signed.

3\. As responder, capable of initiating signed DAP results in accordance
with the procedures specified in Clause 6.6.2.

4\. As responder, capable of accepting, and validating the signature of
a signed DAP request (when the definition of the operation permits it),
in accordance with the procedures specified in Clause 6.6.2; or
discarding the result and generating an appropriate DAP Error if the
signature is invalid in accordance with the procedures profiled in
ADY22.

5\. Validating (i) CA Certificates and (ii) Revocation Lists relevant to
the certificates held for the initiator of the DAP operation with the
requirements of Clause 5.2.4 and in the event of invalidity terminating
the DAP association.

6\. Configurable to always validate certificates and (ii) Revocation
Lists relevant to the certificates held for the correspondent DUA.

Note: There is no requirement that the CA Certificate and Revocation
List validation process be carried out in respect to each DAP operation.
In fact, doing so would multiply the traffic by a factor of at least
three (the original operation plus at least one read operation initiated
by the Responder to obtain a CA Certificate a Revocation List, plus at
least one similar operation initiated by the Invoker). It would be
reasonable to carry out such checks periodically (e.g., once every hour,
or when new revocation lists are known to have been posted.

###  Signed Results

DSAs claiming conformance to ISO/IEC ISP 15125-6 in supporting signed
DSP operations shall be capable of signing Directory Abstract Service
return results, as permitted by the protocol and defined in \[ITU-T Rec.
X.511 (1993) \| ISO/IEC 9594-3:1995\] Clauses 7.10, 9, 10, and 11, and
shall also be capable of signing the aggregation of locally generated
list results, and search results in accordance with \[ITU-T Rec. X.511
(1993) \| ISO/IEC 9594-3:1995\] Clause 10 .

### Certificates and Revocation Lists

1.  []{#__RefHeading___Toc416756216 .anchor}Certificates

DSAs claiming conformance to this ISP in support of Strong
Authentication or Signed DAP operations shall support Certificates in
accordance with Version 3 as defined by \[ITU-T Rec. X.509 (1993) \|
ISO/IEC 9594-8:1995\], as amended by the extension mechanism of
Corrigendum 2 to \[ITU-T Rec. X.509 (1993) \| ISO/IEC 9594-8:1995\]
(except that there is no requirement to support any Version 3
extension), and in accordance with Clause 6.7 below.

Note: When an implementation processing a Certificate does not recognize
an extension, if the extension is non-critical, it may ignore that
extension. If the extension is critical, and the particular extension
field type is not recognized by the DSA, then the certificate should be
considered invalid.

#### Revocation Lists

DSAs claiming conformance to this ISP in supporting Strong
Authentication or Signed DAP operations shall support Revocation Lists
in accordance with the definitions of \[ITU-T Rec. X.509 (1993) \|
ISO/IEC 9594-8:1995\], as amended by the extension mechanism of
Corrigendum 2 to \[ITU-T Rec. X.509 (1993) \| ISO/IEC 9594-8:1995\]
(except that there is no requirement to support any Version 3
extension), and in accordance with Clause 6.7.4 below.

Notes

1.  If an extension is defined as critical, DSAs conformant to this ISP
    shall handle it as specified in Clause 6.6.4.

2.  The \'88 form of CRL was amended, outside the scope of
    extensibility, to correct certain problems. It therefore seems
    appropriate to mandate the \'93 form.

#### Certification Hierarchy Topology

A DUA's signature is provided as credentials (bottom right of the Figure
3) for evaluation by reference to the signing DSA's certificate. This
signature may be provided in a bind request, or as part of a signed
operation. The certificate can be held by the evaluating DSA, or
otherwise made available to the evaluating DSA in the same protocol
exchange, or in different ones.

DSAs shall be able to support a certification topology whereby
validation of all correspondent DUAs shall be possible in accordance
with the following arrangements (see Figure 3). The validation referred
to here is the full validation by reference to all relevant certificates
and revocation lists, and not the validation of credentials by means of
pre-stored certificates, etc.

There are two arrangements of CA that must be supported:

1.  The DSA holds the public key for at least one trusted CA (top left
    of the figure - see definition in 3.1), which can be used to
    validate certificates for DUAs which contains this CA in their own
    certification hierarchy (left side of the figure).

    Note. This CA may be, but need not be, the Policy CA for the
    organisation that owns the DSA.

2.  The entry for this trusted CA may hold cross-certificates (top right
    of the figure) which can be used to validate certificates for DUAs
    in a certification hierarchy which is directly referenced by such
    cross-certificates.

The procedures for full validation in accordance with this topology are
as follows (see Figure 4 which uses precisely the same graphic elements
as Figure 3, but omits the captions on the elements):

1.  Validate the signature of the user by reference to the public key
    held in the user's certificate; validate the issuer's signature for
    this certificate by reference to the public key held in the issuer's
    certificate, and so on. Where the issuer of one of the certificates
    encountered in this way is the trusted CA whose public key is held,
    establish that no such certificate has been revoked. (In the left
    hand side of Figure 4, the first known issuer is the trusted CA; in
    the centre figure, a known issuer is encountered earlier).

2.  As above, except that the trusted CA is not in the same hierarchy as
    the user. However, the issuer of one of the certificates encountered
    in this way has its public key supplied in the set of
    cross-certificates issued by the trusted CA whose public key is held
    (right hand side of the figure).

If the top of the certification hierarchy for the credentials signature
is reached without encountering a CA whose public key is known in this
manner, or if one of the required certificates is unavailable or has
been revoked, the evaluation may fail.

Notes.

1.  There are many possibilities for practical topologies, and this
    requirement in no way obligates the use of this particular topology.
    Other topologies may be supported.

2.  In particular, some topologies demand that the CA hierarchy must be
    reflected in the DIT hierarchy. However, this is not compatible with
    some practical naming strategies, for example those in which two
    parts of a company are placed under different country entries. CAs
    for the two parts of the tree cannot then have a hierarchical
    relationship. DSAs compatible with this profile are therefore not
    permitted to assume that CAs have a hierarchical relationship.

# Procedures

DSAs claiming conformance to ISO/IEC ISP 15125-6 shall be capable of
carrying out the procedures specified below, in conjunction with other
conformance requirements specified above.

## Two-way Authentication

DSAs supporting Simple Protected or Strong Authentication for DAP may
optionally be able to claim conformance to two-way authentication as
opposed to two one-way authentications. In the present context the
difference is that, for two-way authentication, the random number that
is sent by the DUA is returned by the DSA, *in addition to*, a random
number of the DSA's own choosing. With two one-way authentications, the
only random number returned is a random number of the DSA's own
choosing; there is no correlation with the originator's (DUAs) random
number.

The choice of two-way authentication as opposed to two one-way
authentications is a matter of authentication policy between a DUA and a
DSA. ISO/IEC ISP 15125-6 makes no recommendation as to when two-way
authentication should be applied, or how DUAs and DSAs should enter the
necessary bilateral agreements.

Note: When two-way authentication is being used, the responding DSA must
be configured to expect two-way authentication, and shall ensure that
the random number, as returned, is identical to the value as initially
sent in the BindArgument.

The ASN.1 elements **SimpleCredentials.validity.random1**,
**StrongCredentials.bind-token.random** and
**SecurityParameters.random**, each of which is defined as having **BIT
STRING** syntax can be used to carry the information necessary for
two-way authentication. The initiator supplies a random number (call it
r^A^) and may wish to signal that two-way authentication is to be used.
The responder returns both r^A^ and r^B^. All this information needs to
be placed in the referred to **random1** or **random** elements.

DSAs claiming support for two-way authentication, when two-way
authentication is being applied, shall:[^2]

1.  As initiator (or invoker), encode the initiator/invoker-supplied
    random number r^A^ (a **BIT STRING**) in the form of a **BIT
    STRING** containing the value r^A^~,~ encoded most significant bit
    first, potentially with leading 0's (i.e. it is legitimate to round
    off the bits to 8-bit boundaries).

2.  As responder (or performer), encode the random number r^B^ (a **BIT
    STRING**) in the form of a **BIT STRING** containing the simple
    concatenation of r^A^ and r^B^. For example, if r^A^ is 1A3C50~16~
    and r^B^ is 03E660~16~, then the resulting bitstring is the
    1A3C5003E660~16~, again with most significant bit first; r**^A^**
    being retained as is, and r^B^ potentially having leading 0's.

3.  As initiator (or invoker), declare the returned credentials as
    invalid if the returning **random1** or **random** bitstring is not
    the same as the outgoing bitstring with additional bits
    concatenated.

The responder must determine, from bilateral agreement with the
initiator, that two way authentication is required, as this cannot be
determined from the incoming protocol.

## Random Numbers

The random numbers used to derive **SimpleCredentials.validity.random1**
in the case of Simple Protected Credentials,
**StrongCredentials.bind-token.SIGNED.random** in the case of Strong
Credentials in the bind or **SecurityParameters.random** for signed
operations, shall not repeat regularly within 2^32^-1 iterations.

## Distinguished Encoding Rules

The encoding rules for DER (Distinguished Encoding Rules) are defined in
\[ITU-T Rec. X.509 (1993) \| ISO/IEC 9594-8:1995\] Clause 9. However,
these rules make the presumption that the mechanism carrying out the
encoding are aware of the precise syntax of what is encoded. This is not
the case for the Directory, since DSAs must handle encodings prepared by
other entities, and these encoding may contain (A) unknown extensions,
(B) values encoded in accordance with locally unknown syntaxes, and (C)
info and other elements encoded with an unknown **ANY** syntax.

When the DER rules cannot be completely applied, for these reasons, the
rules shall be applied in a form modified as follows:

a)  As in X.509;

b)  for string types which are identifiable as such by the ASN.1
    encoding or by knowledge of the syntax, the constructed form of
    encoding shall not be used; in other cases, the form of the syntax
    shall remain as supplied to the DSA by the originating entity,
    modified by other of these rules as necessary;

c)  if a value of a type is its default value, where identifiable as
    such by knowledge of the syntax, it shall be absent; in other cases,
    the value shall remain (i.e. as supplied to the DSA by the
    originating entity, modified by other of these rules as necessary);

d)  the components of a Set type (but not a Set-of type), where
    identifiable as such by knowledge of the syntax[^3], shall be
    encoded in ascending order of their tag value; where absence of
    knowledge of the syntax makes it impossible to distinguish between a
    Set type and a Set-of type, the Set-of type encoding rule, as
    defined below shall be used; in other cases, the value shall remain
    (i.e. as supplied to the DSA by the originating entity, modified by
    other of these rules as necessary);

e)  the components of a Set-of type (but not a Set type), where
    identifiable as such by knowledge of the syntax, shall be encoded in
    ascending order of their octet value; this rule shall also apply
    where absence of knowledge of the syntax makes it impossible to
    distinguish between a Set type and a Set-of type; in other cases,
    the value shall remain (i.e. as supplied to the DSA by the
    originating entity, modified by other of these rules as necessary);

f)  if for a value of Boolean type, which is identifiable as such by the
    ASN.1 encoding or by knowledge of the syntax, the value is true, the
    encoding shall have its contents octet set to "FF"~16~; in other
    cases, the form of the syntax shall remain as supplied to the DSA by
    the originating entity, modified by other of these rules as
    necessary;

g)  if for a value of Bit String type, which is identifiable as such by
    the ASN.1 encoding or by knowledge of the syntax, each of the unused
    bits in the final octet of the encoding, if there are any, shall be
    set to zero; in other cases, the form of the syntax shall remain as
    supplied to the DSA by the originating entity, modified by other of
    these rules as necessary;

h)  for a value of Real type, which is identifiable as such by the ASN.1
    encoding or by knowledge of the syntax, bases 8, 10, and 16 shall
    not be used, and the binary scaling factor shall be zero. In other
    cases the form of the syntax, modified by other of these rules as
    necessary, shall remain as supplied to the DSA by the originating
    entity.

i)  for all values of UTCTime type, which is identifable as such by the
    ASN.1 encoding or by knowledge of the syntax, the representation
    must be bilaterally agreed upon and the form of the syntax shall
    remain as supplied to the DSA by the originating entity, modified by
    other of these rules as necessary. In the absence of a bilateral
    agreement, implementations should support UTCTime in Greenwich Mean
    Time (Zulu) with the seconds set to zero. Thus, the UTCTime is
    encoded using the year, month, day, hours, and minutes followed by
    "00Z" (YYMMDDHHMM00Z).

j)  to correctly interpret UTCTime past the year 2000 (Y2K) the two
    digit year associated with UTCTime shall be rationalized into a four
    digit year value as follows:

-   if the 2 digit value is 00 through 49 inclusive, the value shall
    have 2000 added to it;

-   if the 2 digit value is 50 through 99 inclusive, the value shall
    have 1900 added to it.

## Simple Protected Authentication

Simple protected authentication requires the DUA to provide the
distinguished name of the user and a bilaterally agreed, enciphered
password as part of the bind operation when establishing a connection to
a DSA.

Note: DAP supports the DSA sending a protected password in the Directory
Bind Result.

### Responder to the Bind

For a DSA claiming conformance to Simple Protected Authentication, the
responder shall:

-   Comply with \[ITU-T Rec. X.511 (1993) \| ISO/IEC 9594-3:1995\]
    Clause 8.1.2 second paragraph and \[ITU-T Rec. X.509 (1993) \|
    ISO/IEC 9594-8:1995\] Clauses 6.1 and 6.2 following the procedures
    that do not include t2A and q2A.

with additional requirements as specified below.

1.  Ensure **time1** is set equal to an expiry time for the bind
    credentials, down to the seconds, using any compliant **UTCTime**
    encoding that includes the seconds field, in accordance with ISO/IEC
    8824-1\| ITU-T Rec. X.680 (1993) Clause 35.3 a), b) option 2), c)
    option 1 or 2.

```{=html}
<!-- -->
```
2.  Ensure **random1** is present, and does not repeat regularly within
    N iterations. If two-way authentication is to be supported, then the
    DSA shall be able to encode this element in accordance with the
    requirements in Clause 6.2.

3.  Choose the **PROTECTED** password.

4.  Ensure the algorithm within the **SIGNATURE** represents a commonly
    used hashing algorithm, such as those given in Informative Annex D.

    Note: This algorithm must include any padding that may be needed to
    bring the length to one compatible with the hashing algorithm.

5.  Ensure the **encrypted** element within the **SIGNATURE** is taken
    as a binary number, equal the result of application of the algorithm
    (used in 4 above) to the octet string formed by the simple
    concatenation of the following ASN.1 DER encodings of:

SEQUENCE {

name DistinguishedName, \-- equal to SimpleCredentials.name

time1 UTCTime, \-- equal to SimpleCredentials.validity.time1random1

random1 BIT STRING, \-- equal to SimpleCredentials.validity.random1

password OCTET STRING equal to SimpleCredentials.password.unprotected

}

where the last element is the value (of the DUA's password) that would
have been supplied if the credentials had been unprotected.

Notes.

1.  While the use of **time2** and **random2** are out of the scope of
    this ISP, if used they should be present as follows:

    SEQUENCE {

    name DistinguishedName, \-- equal to SimpleCredentials.name

    time1 UTCTime, \-- equal to SimpleCredentials.validity.time1

    time2 UTCTime, \-- equal to SimpleCredentials.validity.time2

    random1 BIT STRING, \-- equal to SimpleCredentials.validity.random1

> random2 BIT STRING, \-- equal to SimpleCredentials.validity.random2
>
> password OCTET STRING \-- equal to
> SimpleCredentials.password.unprotected
>
> }

2.  It is recommended that the values of each of the
    **SimpleCredentials** elements in the Directory Bind be DER encoded.
    **If so encoded, the receiving DSA does not have to re-create the
    DER encoding. However, this is a recommendation only.**

3.  DUAs may support and use hashing algorithms other than those given
    in the Informative Annex D; the requirements stated above represent
    a basic capability.

### Response to the Bind

The responder to the Directory Bind shall validate the incoming
protected simple credentials as follows (order of execution is optional)
:

• It shall synthesise the value of
**SimpleCredentials.password.protected** in accordance with the
procedures of the preceding clause, but making use of its own stored
knowledge of the responding user's password as the notional value of
**SimpleCredentials.password.unprotected**; the credentials shall be
taken as invalid if the two hashed password values, as received and as
synthesised, are different.

-   It shall determine that the credentials are invalid if the timestamp
    is older than the present time by more than the value of the
    configurable expiry period (see static conformance requirements).

• It shall maintain a list of information (e.g. {originator-name,
**time1** value, **random1** value} for each incoming bind for at least
the time specified by the configurable expiry period, and shall detect a
repetition of the combination; if repetition is detected, the
credentials shall be taken as invalid.

As responder in a two-way bind process the DSA follows the steps in
6.4.1 when generating the bind response.

## Strong Authentication in the Directory Bind

### One-Way Strong Authentication

One-Way authentication involves a further transfer of information from
the DUA intended for the DSA and establishes the following:

\- the identity of the DUA, and that the authentication token actually
was generated by the DUA;

\- the integrity and "originality" (the property of not having been sent
two or more times) of the authentication token being transferred.

In addition to the user's distinguished name, the DUA sends a timestamp
and random number to the DSA.

### Two-Way Strong Authentication

Two way authentication allows the DUA and the DSA to prove each others
identities and ensures the response is linked to the original request.
In this method of authentication, the DUA generates and sends a
timestamp and random number to the DSA as defined in one-way
authentication. The DSA then generates a timestamp and random number.
The DSA sends the DUA the timestamp and random number that the DSA
generated along with its distinguished name and the random number that
the DUA sent in the original request.

![](media/image13.wmf){width="5.586111111111111in"
height="2.6131944444444444in"}

Note: Strong Authentication can be provided as two one-way strong
authentications or as one two-way authentication as defined in Clause
6.1.

### Response to the Bind

The responder to the bind shall validate the incoming strong credentials
as follows (the order of execution is optional):

1\. The DSA shall comply with procedures laid down in \[ITU-T Rec. X.509
(1993) \| ISO/IEC 9594-8:1995\] Clause 10.2 and 10.3.

2.  The DSA shall check that the **bind-token.algorithm** is supported,
    that the **bind-token.name** value is identical to that of the
    initiator, and that the **bind-token.time** is earlier than the
    present time; otherwise, the credentials shall be taken as invalid.

```{=html}
<!-- -->
```
3.  The DSA shall verify that the signature of the initiator is correct
    by obtaining the user\'s certificate, CA certificate, and CRL from
    the directory; by use of pre-stored / cache certificate information;
    or by other means that do not require Directory operations.
    Otherwise, the credentials shall be taken as invalid.

4.  In the Directory Bind Result, the responder shall generate a
    **bind-token.random** that is the composition of a sequence with the
    random number that was generated by the DUA followed by the random
    number generated by the DSA.

5.  The DSA shall optionally check the initiator\'s certificate
    (including validation against the appropriate Revocation Lists), but
    shall not be required to do so before the DAP association has been
    established.

6.  DSAs shall demonstrate that they are capable of validating the
    certificates (and as necessary, certificates associated by
    reference) to revocations lists, and that they can close down the
    DAP association in consequence.

7.  If the responder\'s credentials are invalid, or if the Bind Request
    is to be rejected, the error procedures profiled in ADY22 shall be
    followed.

## Signed DAP Operations

###  Digitally Signed Directory Operations

Information is signed by appending to it an enciphered summary of the
information. The summary is produced by means of a one-way hash
function, while the enciphering is carried out using the private key of
the signer. This process is known as applying a digital signature to
information. The current version of the standard does not support
digitally signed errors and update results by the DSA.

### Response to the Signed Operation

The performing DSA shall support the following procedures for validating
a signed DAP operation:

1.  In **DAP Arguments**:

• **securityParameters** shall be present

• **securityParameters.certification-path** shall be present if the
argument or result is signed; otherwise it may optionally be present. If
present, the name of the subject of the certificate shall be equal to
the name of the invoking DUA and the restrictions of 6.4.1 shall apply.

• **securityParameters.time** shall be the expiry time of the signature

**• securityParameters.protectionRequest** shall be set to the value (1)
to indicate that the result should besigned.

2.  The DSA shall check that the security-parameters.name value is
    identical to that of the initiator and, if the certificate is
    present in security-parameters.certification-path, it is identical
    to the subject name of the certificate.

3.  The performer shall check that the signature of the invoker is
    valid, by obtaining the user\'s certificate, CA certificate, and CRL
    from the directory; by use of pre-stored / cache certificate
    information; or by other means that do not require Directory
    operations. Otherwise, the signature shall be taken as invalid.

4.  The performer shall maintain a list of information for each incoming
    operation for the length of the association, to detect a repetition
    of information. This information should include, at a minimum, the
    invoker-name and securityParameters.random value. If repetition is
    detected, the signature shall be taken as invalid.

5.  The performer shall be capable of checking the invoker\'s
    certificate (including validation against the appropriate Revocation
    Lists), before responding to the operation, by reference to locally
    cached information that is refresed from time to time, the DSA shall
    be capable of demonstrating that it can close down the DAP
    association as a result of a certificate error, and that they are
    capable of obtaining and acting on refreshed certificate or CRL
    information (e.g. which revokes the invoker's certificate).

6.  When a return result is to be returned (e.g. as requested by use of
    the SecurityParameters.target protection request element), the
    performer shall respond to an incoming signed operation with a
    signed returned result. The performer DSA shall support the
    procedures for creating a signed returned result, as defined in the
    preceding subclause. If two-way authentication is to be supported,
    then the DSA shall be able to encode the value
    **securityParameters.random** in accordance with the requirements of
    Clause 6.2.

    If the invoker's credentials are invalid, the error procedures
    profiled in ADY22 shall be followed.

## Certificates

### Certification Path Creation

There is no requirement to generate the following elements:

• **Credentials.strong.certification-path.theCACertificates**

• **SecurityParameters.certification-path.theCACertificates**

However, these elements may be supplied in accordance with an algorithm
of the implementor\'s choosing

If supplied, they shall be subject to the following general
requirements:

• Forward certificates shall represent a single unbroken directed graph
(i.e. the subject of each certificate shall be the issuer of another
forward certificate or of the originator\'s certificate)

-   A Reverse certificate shall match the corresponding forward
    certificate if both are present in a single **CertificatePair**
    element (i.e. the issuer of the one is the subject of the other).

### Certification Path Use

There is no requirement to use the following elements:

• **Credentials.strong.certification-path.theCACertificates**

• **SecurityParameters.certification-path.theCACertificates**

However, these elements may be used in accordance with an algorithm of
the implementor\'s choosing.

### Certificate Processing

1.  Processing of Certificates shall be carried out in accordance with
    the principles of \[ITU-T Rec. X.509 (1993) \| ISO/IEC 9594-8:1995\]
    Clause 11.2.

2.  In cases where the unique identifier is available, e.g.:

• In a Version 2 certificate or later and **xxxUniqueIdentifier** is
present

> • When available without a further Directory operation in a
> corresponding attribute value (e.g. **uniqueIdentifier** see \[ITU-T
> Rec. X.520 (1993) \| ISO/IEC 9594-6:1995\] Clause 5.2.7).
>
> the two unique identifiers shall match.

3.  DSAs shall be capable of configuration to match issuer or subject
    names when the name matches, but the **xxxUniqueIdentifier** is
    unknown or cannot be obtained without a Directory operation.

4.  A Version 3 certificate shall be taken as invalid if an unsupported
    critical extension is defined for it, in accordance with the
    corresponding Technical Corrigendum.

> If the extension is critical, and the particular extension type is not
> recognized by the DSA, then the certificate should be considered
> invalid.
>
> When an implementation processing a certificate does not recognize an
> non-critical extension, it may ignore that extension, and can consider
> the certificate to be valid.

### Revocation List Processing

Processing of Revocation Lists shall be carried out in accordance with
the principles of \[ITU-T Rec. X.509 (1993) \| ISO/IEC 9594-8:1995\]
Clause 11.2. The following stipulations also apply:

-   A DSA shall be capable of detecting the presence of a certificate on
    a Revocation List by scanning the complete list of serial numbers,
    and shall then consider it revoked, whether or not critical
    extensions are supported.

-   A DSA shall be capable of detecting whether a Revocation List has
    expired by analysis of the **nextUpdate** element of the
    **CertificateList** value. However, certificates revoked by an
    expired Revocation List shall be taken as invalid.

-   A certificate found to be revoked by a Revocation List for which the
    signature cannot be validated or which appears to be invalid in any
    other way may optionally be considered to be actually revoked.

-   A certificate for which the corresponding Revocation List cannot be
    read from the Directory, or which can be read, but is found to have
    expired may optionally be considered to be revoked.

######## 

# (Normative) {#normative .Annex .unnumbered}

**Profile Requirements List**

In the event of a discrepancy becoming apparent in the body of
autonomous DSA procedures and the tables in this Annex, this Annex is to
take precedence.

######### IntroductionA.1 {#introductiona.1 .Annex-1}

This annex specifies the constraints and characteristics on what shall
or may appear in an implementor's PICS for an implementation conformant
to this part of ISO/IEC ISP 15125. This annex identifies restrictions
placed by this part of the ISP on the corresponding base specification
requirements.

This PRL only addresses features required for the support of simple
protected authentication, strong authentication, and signed operations
for a DSA acting as a DAP responder. As such, it only identifies those
features from ISO/IEC ISP 15125-3 which have been deemed out of scope
because they address authentication above simple unprotected, or signed
operations. When filling in the PICS Proforma this PRL must be combined
with the PRL found in ISO/IEC ISP 15125-3 and ISO/IEC ISP 15126-1 (FDY
11); however this PRL shall take precedence for like features.

######### Identification of the ImplementationA.2 {#identification-of-the-implementationa.2 .Annex-1}

## Identification of the PICSA.2.1 {#identification-of-the-picsa.2.1 .Annex-2}

This part of the ISP is based on ITU-T Recommendation X.583 (1997) \|
ISO/IEC 13248-1: 1997, *Information technology \-- Open Systems
Interconnection -Directory Access Protocol: Protocol Implementation
Conformance Statement (PICS) Proforma.* PRL tables. The tables in this
Annex, while not necessary following the same numbering as the
corresponding PICS tables, carry the same title.

This PRL must be combined with ISO/IEC ISP 15125-3 to properly complete
the PICS. Support for elements in this PRL should be used in place of
those same items found in ISO/IEC ISP 15125-3. Implementations compliant
with this part of the ISP should show support, based on this part of the
ISP, in the PICS.

The PICS covers all aspects of the DAP protocol, which is a broader
scope than covered in this part of the ISP. Implementations showing
support for this part of the ISP should address the following ICS
tables:

-   All general ICS tables (i.e. those tables that are not associated
    with a DUA or DSA). These are tables that do not delineate support
    for DUAs and DSAs. (PICS clause A.3, A.4, A.5, and subclause A.6.1)

-   ICS tables that are included in a clause associated with a DSA.
    (PICS subclause A.6.2.1)

-   The DSA support column for ICS tables that delineate between DUAs
    and DSAs support. Where the DSA support column is further delineated
    between digitally signed and unsigned columns, the signed column
    should be used (PICS subclause A.6.3) where support for signed
    operations is claimed in this part of the ISP.

######### Instructions  {#instructions .Annex-1}

## Purpose and structure of the PRL {#purpose-and-structure-of-the-prl .Annex-2}

The purpose of this PRL is to provide supplier's of implementations to
the ITU-T Recommendations X.500 (1993) \| International Standards
ISO/IEC 9594:1995 with a consistent expression of restrictions to the
corresponding PICS proforma based on this part of the ISP.

The PRL is in the form of a set of items. An item is provided for each
capability for which an implementation choice is allowed. Items are also
provided for mandatory capabilities for which no implementation choice
is allowed. Each item includes an item number, item description, a
protocol status value (which reflects the base specification
requirements as expressed in the PICS), a profile status value (which
reflects restrictions to the PICS imposed by this part of the ISP), a
predicate column (which predicates are set or employed by the profile),
and profile note column.

This clause provides general information and instructions for completion
of the proforma.

Subclause A.4 contains the PRL tables.

Subclause B.2 is for the identification of the technical corrigenda to
this part of the ISP.

## Symbols, terms, and abbreviationsA.3.2 {#symbols-terms-and-abbreviationsa.3.2 .Annex-2}

### IntroductionA.3.2.1 {#introductiona.3.2.1 .Annex-3}

Notations have been introduced in order to reduce the size of the tables
in the PRL. These have allowed the use of multi-column layout where the
columns are headed 'Protocol Status' and 'Profile Status'. Definitions
of each are given below. Additionally, the following definitions apply:

protocol status (value): An allowed entry in the status column for an
item in a PICS proforma table;

profile status (value): An allowed entry in the status column for an
item in a PRL table which reflects restrictions imposed by this part of
the ISP;

### Prerequisite notationA.3.2.2 {#prerequisite-notationa.3.2.2 .Annex-3}

If a predicate applies to a whole table, a prerequisite line may be
specified in front of the table to which it applies. A prerequisite line
takes the form:

Prerequisite: \<Predicate\>

The meaning of such a line is that if \<predicate\> is True, then the
table applies, else it is not applicable.

### Item reference numbersA.3.2.3 {#item-reference-numbersa.3.2.3 .Annex-3}

Each line within the PRL is numbered at the left-hand edge of the line.
This numbering is included as a means of uniquely identifying all
possible implementation details within the PRL. This referencing should
be consistent with the corresponding PICS item reference.

The means of referencing individual responses is done by the following
sequence:

\- a reference to the smallest enclosing the relevant item;

\- a solidus character, \'/\';

\- the reference number of the row in which the response appears;

\- if, and only if, more than one response occurs in the row identified
by the reference number, then each possible entry is implicitly labeled
a, b, c, etc. from left to right, and this letter is appended to the
sequence.

An example of the use of this notation would be A.4.3.3.4/1, which
refers to the support for CompareArgument in a Compare protocol data
unit.

### Protocol Status columnA.3.2.4 {#protocol-status-columna.3.2.4 .Annex-3}

This column indicates the level of support required for conformance to
this ITU-T \| ISO/IEC standard, as expressed in the PICS.

The values are as follows:

> m the capability is required to be implemented, in conformance with
> the related specification;
>
> o the capability may be implemented, and if it is implemented it is
> required to conform to the related specification
>
> c the requirement on the capability depends on the selection of other
> optional or conditional items;
>
> i the capability is outside the scope of the PICS, and hence
> irrelevant and not subject to conformance testing;
>
> \- in the given context it is impossible to use this capability.

Nested conditionals are denoted by nested numbering (e.g. 1, 1.1, 1.1.1,
etc.) of the item descriptions in the tables. A table may have zero, one
or more levels of nesting. The status of a leading item is specified by
its status entry, as defined above. The status of a subordinate (that is
nested) item is specified as follows: If the superior item is supported,
the status of the subordinate item is determined by its status column
entry and applicable predicate, if any. If the superior item is not
supported, the subordinate item is not applicable, independent of its
status column entry.

> Note: It is possible to label conditional and optional status items
> (usually by use of a number). For the purpose of the PRL, in order to
> avoid confusion between the Protocol Status and Profile Status
> numbering, conditional and optional numbering as expressed in the
> PICS, and associated Protocol Status column, is dropped. The notation
> is instead replaced with 'cn' and 'o.n' to reflect that the PICS
> conditional and optional items have associated numbers.

### Profile Status columnA.3.2.5 {#profile-status-columna.3.2.5 .Annex-3}

This column indicates the level of support required for conformance to
this part of the ISP.

The values are as follows:

> m the capability is required to be implemented, in conformance with
> the related specification;
>
> o the capability may be implemented, and if it is implemented it is
> required to conform to the related specification
>
> c the requirement on the capability depends on the selection of other
> optional or conditional items;
>
> i the capability is outside the scope of this part of the ISP, and
> hence irrelevant and not subject to conformance testing;
>
> \- in the given context it is impossible to use this capability.

Nested conditionals are denoted by nested numbering (e.g. 1, 1.1, 1.1.1,
etc.) of the item descriptions in the tables. A table may have zero, one
or more levels of nesting. The status of a leading item is specified by
its status entry, as defined above. The status of a subordinate (that is
nested) item is specified as follows: If the superior item is supported,
the status of the subordinate item is determined by its status column
entry and applicable predicate, if any. If the superior item is not
supported, the subordinate item is not applicable, independent of its
status column entry.

### Predicate columnA.3.2.6 {#predicate-columna.3.2.6 .Annex-3}

The item number contained in the predicate column, if any, means that
the status in the \"Profile Status\" column applies only when the PRL
states that one or more features identified by the item is supported.

### Predicate NameA.3.2.7 {#predicate-namea.3.2.7 .Annex-3}

The predicate name indicates that name upon which the predicate is
based. A predicate name flagged with an asterisk preceding the predicate
name indicates the condition by which the predicate is being set. A
predicate name not flagged with an asterisk indicates the predicate on
which the conditional support is based.

### Note columnA.3.2.8 {#note-columna.3.2.8 .Annex-3}

This column indicates the following:

> notexx - refers to Note xx;
>
> See xx - refers to Table xx.
>
> See Part xx - refers to another part of the ISO/IEC ISP 15125
> associated with the element.

Information entered into this column applies to the PRL and the Profile
Status column. These notes may also have meaning to the Protocol Status
column, however, notes specific to the Protocol Status column are found
in the PICS.

######### PRL TablesA.4 {#prl-tablesa.4 .Annex-1}

These tables reflect restrictions to the base specification imposed by
this part of the ISP. Not all of the PICS tables are listed in this PRL,
but instead just those deemed necessary to reflect the PRL.

The PRL tables reflect support for items which are different than that
found in ISO/IEC ISP 15125-3 and ISO/IEC ISP 15126-1 (FDY 11). For
consistency the item numbering follow numbering for the same item for
the ISO/IEC ISP 15125-3 and ISO/IEC ISP 15126-1 PRL. Tables will
therefore show gaps in numbering and will not necessarily start with the
number one.

Cross-references to the corresponding PICS tables are supplied in the
table title. For instance "Ref. A.6.3.3.1.1" would refer to table
A.6.3.3.1.1 of Appendix A in the PICS.

Implementers should submit completed PICS based on guidance expressed in
above

Prior to completing the PICS based on this PRL, the Profile Specific
Implementation Conformance Statement (ICS) found in Annex B of this
document should first be filled out. [The Profile Specific ICS sets
predicates that are used by this PRL]{.underline}. Implementors should
therefore first address clause A.4.2 (General Capabilities and Global
statement of conformance) below because this clause sets predicates used
in Annex B. Implementors should next address the Profile Specific ICS in
Annex B which sets predicates used throughout the rest of this PRL.

## RolesA.4.1 Ref. A.6.1 {#rolesa.4.1-ref.-a.6.1 .Annex-2}

No additional requirements beyond those specified in ISO/IEC ISP
15125-3.

## General Capabilities and Global statement of conformanceA.4.2 {#general-capabilities-and-global-statement-of-conformancea.4.2 .Annex-2}

Non-supported mandatory capabilities are to be identified in the PICS,
with an explanation of why the implementation is non-conformant. Such
information shall be provided in subclause A.6.6 \"Other Information\"
of the PICS.

### General CapabilitiesA.4.2.1 Ref. A.6.2.2.1 {#general-capabilitiesa.4.2.1-ref.-a.6.2.2.1 .Annex-3}

+------+-------------------------------+----+----+-----------+-------+
| Item | Question                      | Pr | P  | Predicate | Note  |
| No.  |                               | ot | ro | Name      |       |
|      |                               | oc | fi |           |       |
|      |                               | ol | le |           |       |
|      |                               |    |    |           |       |
|      |                               | St | St |           |       |
|      |                               | at | at |           |       |
|      |                               | us | us |           |       |
+======+===============================+====+====+===========+=======+
| 5    | Does the DSA support signed   | o  | o  | \*d       | See   |
|      | DAP operations and results?   |    |    | igitalSig | B.6   |
+------+-------------------------------+----+----+-----------+-------+

### Supported Security LevelsA.4.2.2 Ref. A.6.2.2.2 {#supported-security-levelsa.4.2.2-ref.-a.6.2.2.2 .Annex-3}

+------+-------------------------------+----+----+-----------+-------+
| Item | Question                      | Pr | P  | Predicate | Note  |
| No.  |                               | ot | ro | Name      |       |
|      |                               | oc | fi |           |       |
|      |                               | ol | le |           |       |
|      |                               |    |    |           |       |
|      |                               | St | St |           |       |
|      |                               | at | at |           |       |
|      |                               | us | us |           |       |
+======+===============================+====+====+===========+=======+
| 1    | none                          | o  | i  |           | See   |
|      |                               | .n |    |           | part  |
|      |                               |    |    |           | 1     |
+------+-------------------------------+----+----+-----------+-------+
| 2    | simple                        | o  | o  |           | See   |
|      |                               | .n |    |           | B.4   |
+------+-------------------------------+----+----+-----------+-------+
| 3    | strong                        | o  | c1 | \*s       | See   |
|      |                               | .n |    | trongAuth | B.5   |
+------+-------------------------------+----+----+-----------+-------+
| 4    | external                      | i  | i  |           |       |
+------+-------------------------------+----+----+-----------+-------+

c1: If \[digitalSig \] then support of this feature is m else o.

### Supported Access Control SchemesA.4.2.3 Ref. A.6.2.2.3 {#supported-access-control-schemesa.4.2.3-ref.-a.6.2.2.3 .Annex-3}

No additional requirements beyond those specified in ISO/IEC ISP
15125-3.

## Capabilities and options. A.4.3 {#capabilities-and-options.-a.4.3 .Annex-2}

This part of the ISP identifies the supported application context, the
PDUs and operations.

The operation arguments and PDU parameters are identified.

### Supported application context. A.4.3.1 {#supported-application-context.-a.4.3.1 .Annex-3}

The only application context supported is Directory Access application
context.

### Operations and extensionsA.4.3.2 {#operations-and-extensionsa.4.3.2 .Annex-3}

#### OperationsA.4.3.2.1 Ref. A.6.3.2.1 {#operationsa.4.3.2.1-ref.-a.6.3.2.1 .Annex-4}

No additional requirements beyond those specified in ISO/IEC ISP
15125-3.

Note that this part of the ISP addresses simple protected and strong
authentication for bind arguments and results, and signed operations.

#### ExtensionsA.4.3.2.2 Ref. A.6.3.2.2 {#extensionsa.4.3.2.2-ref.-a.6.3.2.2 .Annex-4}

DSAs should conform as a precondition to ISO/IEC 15125-3 (ADY 21).
Extensions should be consistent with support found in ISO/IEC 15125-3.

+-----+------------------+-------+------+-------------+-------------+
| I   | Extension        | Pro   | Pro  | Predicate   | Note        |
| tem |                  | tocol | file | Name        |             |
| No. |                  |       |      |             |             |
|     |                  | S     | St   |             |             |
|     |                  | tatus | atus |             |             |
+=====+==================+=======+======+=============+=============+
| 1   | subentries       | o     | o    |             |             |
+-----+------------------+-------+------+-------------+-------------+
| 2   | copyShallDo      | o     | o    |             |             |
+-----+------------------+-------+------+-------------+-------------+
| 3   | at               | o     | o    | \*at        |             |
|     | tributesizelimit |       |      | trsizelimit |             |
+-----+------------------+-------+------+-------------+-------------+
| 4   | extraAttributes  | o     | o    |             |             |
+-----+------------------+-------+------+-------------+-------------+
| 5   | mod              | o     | o    | \*m         |             |
|     | ifyRightsRequest |       |      | odrightsreq |             |
+-----+------------------+-------+------+-------------+-------------+
| 6   | pag              | o     | o    | \           |             |
|     | edResultsRequest |       |      | *pageresreq |             |
+-----+------------------+-------+------+-------------+-------------+
| 7   | m                | o     | o    | \*m         |             |
|     | atchedValuesOnly |       |      | atchvalonly |             |
+-----+------------------+-------+------+-------------+-------------+
| 8   | extendedFilter   | o     | o    | \*extfilter |             |
+-----+------------------+-------+------+-------------+-------------+
| 9   | targetSystem     | o     | o    | \*t         |             |
|     |                  |       |      | argetsystem |             |
+-----+------------------+-------+------+-------------+-------------+
| 10  | useAliasOnUpdate | o     | o    |             |             |
+-----+------------------+-------+------+-------------+-------------+
| 11  | newSuperior      | o     | o    | \*          |             |
|     |                  |       |      | newsuperior |             |
+-----+------------------+-------+------+-------------+-------------+

### Protocol elementsA.4.3.3 {#protocol-elementsa.4.3.3 .Annex-3}

#### DirectoryBind ElementsA.4.3.3.1  {#directorybind-elementsa.4.3.3.1 .Annex-4}

This part of the ISP only addresses simple protected or strong
authentication on the Bind. If supported authentication is none or
simple unprotected implementations should conform to part 3 of this ISP
(ADY 21).

##### Directory Bind ArgumentsA.4.3.3.1.1 Ref. A.6.3.3.1.1 {#directory-bind-argumentsa.4.3.3.1.1-ref.-a.6.3.3.1.1 .Annex-5}

Prerequisite: \[protectedSimple or strongAuth\]

Note: This ISP addresses the DSA as a responder, support for this table
implies being able to receive and process the bind argument, not
initiate it.

+-----+--------------------+------+-----+-------------+-------------+
| I   | Protocol Element   | Prot | P   | Predicate   | Note        |
| tem |                    | ocol | rof | Name        |             |
| No. |                    |      | ile |             |             |
|     |                    | St   |     |             |             |
|     |                    | atus | Sta |             |             |
|     |                    |      | tus |             |             |
+=====+====================+======+=====+=============+=============+
| 1   | credentials        | cn   | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.1 | simple             | c:cn | c2  |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.  | name               | c:m  | c:m |             |             |
| 1.1 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.  | validity           | c:o  | c:m |             |             |
| 1.2 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | time1              | c:o  | c:m |             | Note 1      |
| .1. |                    |      |     |             |             |
| 2.1 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | time2              | c:o  | c:o |             |             |
| .1. |                    |      |     |             |             |
| 2.2 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | random1            | c:o  | c:m |             |             |
| .1. |                    |      |     |             |             |
| 2.3 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | random2            | c:o  | c:o |             |             |
| .1. |                    |      |     |             |             |
| 2.4 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.  | password           | c:o  | c:m |             |             |
| 1.3 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | unprotected        | c    | i   |             | See Part 3  |
| .1. |                    | :o.n |     |             |             |
| 3.1 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | protected          | c    | c:m |             |             |
| .1. |                    | :o.n |     |             |             |
| 3.2 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.1 | a                  | c:m  | c:m |             |             |
| .3. | lgorithmIdentifier |      |     |             |             |
| 2.1 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.1 | encrypted          | c:m  | c:m |             |             |
| .3. |                    |      |     |             |             |
| 2.2 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.2 | strong             | c:cn | c3  |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.  | certification-path | c:o  | c:  |             |             |
| 2.1 |                    |      | o.1 |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.  | bind-token         | c:m  | c:m |             |             |
| 2.2 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | toBeSigned         | c:m  | c:m |             |             |
| .2. |                    |      |     |             |             |
| 2.1 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.2 | algorithm          | c:m  | c:m |             |             |
| .2. |                    |      |     |             |             |
| 1.1 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.2 | name               | c:m  | c:m |             |             |
| .2. |                    |      |     |             |             |
| 1.2 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.2 | time               | c:m  | c:m |             |             |
| .2. |                    |      |     |             |             |
| 1.3 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.2 | random             | c:m  | c:m |             |             |
| .2. |                    |      |     |             |             |
| 1.4 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | a                  | c:m  | c:m |             |             |
| .2. | lgorithmIdentifier |      |     |             |             |
| 2.2 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | encrypted          | c:m  | c:m |             |             |
| .2. |                    |      |     |             |             |
| 2.3 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.  | name               | c:o  | c:  |             |             |
| 2.3 |                    |      | o.1 |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.3 | externalProcedure  | i    | i   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2   | versions           | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2.1 | v1                 | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+

c2 if \[protectedSimple\] then m else o.

c3 if \[strongAuth\] then m else o.

o.1 At least one or both of the certification-path and name must always
be present, and if both, then they must "agree", i.e., indicate the same
name.

Note 1: The time should be configurable to the level of granularity of
local policy taking network delays into consideration.

##### Directory Bind ResultA.4.3.3.1.2 Ref. A.6.3.3.1.2 {#directory-bind-resulta.4.3.3.1.2-ref.-a.6.3.3.1.2 .Annex-5}

Prerequisite: \[protectedSimple or strongAuth\]

+-----+--------------------+------+-----+-------------+-------------+
| I   | Protocol Element   | Prot | P   | Predicate   | Note        |
| tem |                    | ocol | rof | Name        |             |
| No. |                    |      | ile |             |             |
|     |                    | St   |     |             |             |
|     |                    | atus | Sta |             |             |
|     |                    |      | tus |             |             |
+=====+====================+======+=====+=============+=============+
| 1   | credentials        | cn   | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.1 | simple             | c:cn | c2  |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.  | name               | c:m  | c:m |             |             |
| 1.1 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.  | validity           | c:o  | c:m |             |             |
| 1.2 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | time1              | c:o  | c:m |             |             |
| .1. |                    |      |     |             |             |
| 2.1 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | time2              | c:o  | c:o |             |             |
| .1. |                    |      |     |             |             |
| 2.2 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | random1            | c;o  | c:m |             |             |
| .1. |                    |      |     |             |             |
| 2.3 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | random2            | c:o  | c:o |             |             |
| .1. |                    |      |     |             |             |
| 2.4 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.  | password           | c:o  | c:m |             |             |
| 1.3 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | unprotected        | c    | i   |             | See Part 3  |
| .1. |                    | :o.n |     |             |             |
| 3.1 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | protected          | c    | c:m |             |             |
| .1. |                    | ;o.n |     |             |             |
| 3.2 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.1 | a                  | c:m  | c:m |             |             |
| .3. | lgorithmIdentifier |      |     |             |             |
| 2.1 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.1 | encrypted          | c:m  | c:m |             |             |
| .3. |                    |      |     |             |             |
| 2.2 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.2 | strong             | c:cn | c3  |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.  | certification-path | c:o  | c:  |             |             |
| 2.1 |                    |      | o.1 |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.  | bind-token         | c:m  | c:m |             |             |
| 2.2 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | toBeSigned         | c:m  | c:m |             |             |
| .2. |                    |      |     |             |             |
| 2.1 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.2 | algorithm          | c:m  | c:m |             |             |
| .2. |                    |      |     |             |             |
| 1.1 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.2 | name               | c:m  | c:m |             |             |
| .2. |                    |      |     |             |             |
| 1.2 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.2 | time               | c:m  | c:m |             |             |
| .2. |                    |      |     |             |             |
| 1.3 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.2 | random             | c:m  | c:m |             |             |
| .2. |                    |      |     |             |             |
| 1.4 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | a                  | c:m  | c:m |             |             |
| .2. | lgorithmIdentifier |      |     |             |             |
| 2.2 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1   | encrypted          | c:m  | c:m |             |             |
| .2. |                    |      |     |             |             |
| 2.3 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.  | name               | c:o  | c:  |             |             |
| 2.3 |                    |      | o.1 |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.3 | externalProcedure  | i    | i   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2   | versions           | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2.1 | v1                 | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+

c2: if \[protectedSimple\] then m else o.

c3: if \]strongAuth\] then m else o.

o.1: At least one or both of the certification-path and name must always
be present, and if both, then they must "agree", i.e., indicate the same
name.

##### Directory Bind ErrorA.4.3.3.1.3 Ref. A.6.3.3.1.3 {#directory-bind-errora.4.3.3.1.3-ref.-a.6.3.3.1.3 .Annex-5}

No additional requirements beyond those specified in ISO/IEC ISP
15125-3.

#### Directory Unbind ElementsA.4.3.3.2  {#directory-unbind-elementsa.4.3.3.2 .Annex-4}

DirectoryUnbind has no arguments (see Section 8.2 of ITU-T X.511 \|
ISO/IEC 9594-3).

#### Read ElementsA.4.3.3.3 Ref. A.6.3.3.3 {#read-elementsa.4.3.3.3-ref.-a.6.3.3.3 .Annex-4}

Prerequisite: \[signRead\]

This ISP deals with the DSA as a responder, support for this table
implies being able to receive and process the readArgument and to
generate the readResult.

+-----+--------------------+------+-----+-------------+-------------+
| I   | Protocol Element   | Prot | P   | Predicate   | Note        |
| tem |                    | ocol | rof | Name        |             |
| No. |                    |      | ile |             |             |
|     |                    | St   |     |             |             |
|     |                    | atus | Sta |             |             |
|     |                    |      | tus |             |             |
+=====+====================+======+=====+=============+=============+
| 1   | ReadArgument       | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.1 | toBeSigned         | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.2 | object             | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.3 | selection          | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.4 | m                  | cn   | c4  |             |             |
|     | odifyRightsRequest |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.5 | CommonArguments    | m    | m   | \*Comm-Arg  | See         |
|     |                    |      |     |             | A.4.3.3.13  |
+-----+--------------------+------+-----+-------------+-------------+
| 1.6 | a                  | m    | m   |             |             |
|     | lgorithmIdentifier |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.7 | encrypted          | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2   | ReadResult         | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2.1 | toBeSigned         | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2.2 | entry              | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2.3 | modifyRights       | o    | c4  |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2.  | item               | c:m  | c:m |             |             |
| 3.1 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2   | entry              | c:m  | c:m |             |             |
| .3. |                    |      |     |             |             |
| 1.1 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2   | attribute          | c:m  | c:m |             |             |
| .3. |                    |      |     |             |             |
| 1.2 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2   | value              | c:m  | c:m |             |             |
| .3. |                    |      |     |             |             |
| 1.3 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2.  | permission         | c:m  | c:m |             |             |
| 3.2 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2.4 | CommonResults      | m    | m   | \*Comm-Res  | See         |
|     |                    |      |     |             | A.4.3.3.14  |
+-----+--------------------+------+-----+-------------+-------------+
| 2.5 | a                  | m    | m   |             |             |
|     | lgorithmIdentifier |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2.6 | encrypted          | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 3   | Errors             | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+

c4: If \[modrightsreq\] then support of this feature is m else o.

#### Compare ElementsA.4.3.3.4 Ref. A.6.3.3.4 {#compare-elementsa.4.3.3.4-ref.-a.6.3.3.4 .Annex-4}

Prerequisite: \[signCompare\]

This ISP deals with the DSA as a responder, support for this table
implies being able to receive and process the compareArgument and to
generate the compareResult.

+-----+--------------------+------+-----+-------------+-------------+
| I   | Protocol Element   | Prot | P   | Predicate   | Note        |
| tem |                    | ocol | rof | Name        |             |
| No. |                    |      | ile |             |             |
|     |                    | St   |     |             |             |
|     |                    | atus | Sta |             |             |
|     |                    |      | tus |             |             |
+=====+====================+======+=====+=============+=============+
| 1   | CompareArgument    | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.1 | toBeSigned         | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.2 | object             | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.3 | purported          | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.4 | CommonArguments    | m    | m   | \*Comm-Arg  | See         |
|     |                    |      |     |             | A.4.3.3.13  |
+-----+--------------------+------+-----+-------------+-------------+
| 1.5 | a                  | m    | m   |             |             |
|     | lgorithmIdentifier |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 1.6 | encrypted          | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2   | CompareResult      | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2.1 | toBeSigned         | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2.2 | name               | o    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2.3 | matched            | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2.4 | fromEntry          | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2.5 | matchedSubtype     | o    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2.6 | CommonResults      | m    | m   | \*Comm-Res  | See         |
|     |                    |      |     |             | A.4.3.3.14  |
+-----+--------------------+------+-----+-------------+-------------+
| 2.7 | a                  | m    | m   |             |             |
|     | lgorithmIdentifier |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2.8 | encrypted          | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 3   | Errors             | m    | m   |             |             |
+-----+--------------------+------+-----+-------------+-------------+

#### Abandon Elements {#abandon-elements .Annex-4}

Abandon operations cannot be digitally signed. This includes the abandon
argument and the abandon results.

#### List ElementsA.4.3.3.6 Ref. A.6.3.3.6 {#list-elementsa.4.3.3.6-ref.-a.6.3.3.6 .Annex-4}

Prerequisite: \[signList\]

This ISP deals with the DSA as a responder, support for this table
implies being able to receive and process the listArgument and to
generate the listResult.

+-----+---------------------+-----+-----+-------------+-------------+
| I   | Protocol Element    | Pr  | P   | Predicate   | Note        |
| tem |                     | oto | rof | Name        |             |
| No. |                     | col | ile |             |             |
|     |                     |     |     |             |             |
|     |                     | Sta | Sta |             |             |
|     |                     | tus | tus |             |             |
+=====+=====================+=====+=====+=============+=============+
| 1   | ListArgument        | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.1 | toBeSigned          | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.2 | object              | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.3 | pagedResults        | cn  | c5  |             | See         |
|     |                     |     |     |             | A.4.3.3.20  |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.4 | CommonArguments     | m   | m   | \*Comm-Arg  | See         |
|     |                     |     |     |             | A.4.3.3.13  |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.5 | algorithmIdentifier | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.6 | encrypted           | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | ListResult          | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.1 | toBeSigned          | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.2 | listInfo            | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.  | name                | o   | m   |             |             |
| 2.1 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.  | subordinates        | m   | m   |             |             |
| 2.2 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | rdn                 | m   | m   |             |             |
| .2. |                     |     |     |             |             |
| 2.1 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | aliasEntry          | m   | m   |             |             |
| .2. |                     |     |     |             |             |
| 2.2 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | fromEntry           | m   | m   |             |             |
| .2. |                     |     |     |             |             |
| 2.3 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.  | part                | m   | m   |             |             |
| 2.3 | ialOutcomeQualifier |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | limitProblem        | o   | m   |             |             |
| .2. |                     |     |     |             |             |
| 3.1 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.2 | timeLimitExceeded   | c:m | m   |             |             |
| .3. |                     |     |     |             |             |
| 1.1 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.2 | sizeLimitExceeded   | c:m | m   |             |             |
| .3. |                     |     |     |             |             |
| 1.2 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.2 | administ            | c:m | m   |             |             |
| .3. | rativeLimitExceeded |     |     |             |             |
| 1.3 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | unexplored          | o   | m   |             |             |
| .2. |                     |     |     |             |             |
| 3.2 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | unavailabl          | m   | m   |             |             |
| .2. | eCriticalExtensions |     |     |             |             |
| 3.3 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | unknownErrors       | o   | m   |             |             |
| .2. |                     |     |     |             |             |
| 3.4 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | queryReference      | cn  | c5  |             |             |
| .2. |                     |     |     |             |             |
| 3.5 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.  | CommonResults       | m   | m   | \*Comm-Res  | See         |
| 2.4 |                     |     |     |             | A.4.3.3.14  |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.3 | u                   | cn  | m   |             |             |
|     | ncorrelatedListInfo |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.4 | algorithmIdentifier | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.5 | encrypted           | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 3   | Errors              | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+

c5: If \[pageresreq\] then support of this feature is m else o.

#### Search ElementsA.4.3.3.7 Ref. A.6.3.3.7 {#search-elementsa.4.3.3.7-ref.-a.6.3.3.7 .Annex-4}

Prerequisite: \[signSearch\]

This ISP deals with the DSA as a responder, support for this table
implies being able to receive and process the searchArgument and to
generate the searchResult.

+-----+---------------------+-----+-----+-------------+-------------+
| I   | Protocol Element    | Pr  | P   | Predicate   | Note        |
| tem |                     | oto | rof | Name        |             |
| No. |                     | col | ile |             |             |
|     |                     |     |     |             |             |
|     |                     | Sta | Sta |             |             |
|     |                     | tus | tus |             |             |
+=====+=====================+=====+=====+=============+=============+
| 1   | SearchArgument      | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.1 | toBeSigned          | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.2 | baseObject          | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.3 | subset              | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.4 | filter              | m   | o   | \*Filter    | See         |
|     |                     |     |     |             | A.4.3.18    |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.5 | searchAliases       | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.6 | selection           | m   | m   | \*Info-Sel  | See         |
|     |                     |     |     |             | A.4.3.16    |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.7 | pagedResults        | cn  | c5  |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.8 | matchedValuesOnly   | cn  | c6  |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.9 | extendedFilter      | cn  | c7  |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1   | CommonArguments     | m   | m   | \*Comm-Arg  | See         |
| .10 |                     |     |     |             | A.4.3.13    |
+-----+---------------------+-----+-----+-------------+-------------+
| 1   | algorithmIdentifier | m   | m   |             |             |
| .11 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1   | encrypted           | m   | m   |             |             |
| .12 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | SearchResult        | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.1 | toBeSigned          | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.2 | searchInfo          | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.  | name                | o   | m   |             |             |
| 2.1 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.  | entries             | m   | m   | \           | See         |
| 2.2 |                     |     |     | *Entry-Info | A.4.3.17    |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.  | part                | m   | m   |             |             |
| 2.3 | ialOutcomeQualifier |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | limitProblem        | o   | m   |             |             |
| .2. |                     |     |     |             |             |
| 3.1 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.2 | timeLimitExceeded   | c:m | m   |             |             |
| .3. |                     |     |     |             |             |
| 1.1 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.2 | sizeLimitExceeded   | c:m | m   |             |             |
| .3. |                     |     |     |             |             |
| 1.2 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.2 | administ            | c:m | m   |             |             |
| .3. | rativeLimitExceeded |     |     |             |             |
| 1.3 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | unexplored          | o   | m   |             |             |
| .2. |                     |     |     |             |             |
| 3.2 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | unavailabl          | m   | m   |             |             |
| .2. | eCriticalExtensions |     |     |             |             |
| 3.3 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | unknownErrors       | o   | m   |             |             |
| .2. |                     |     |     |             |             |
| 3.4 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | queryReference      | cn  | c5  |             |             |
| .2. |                     |     |     |             |             |
| 3.5 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.  | CommonResults       | m   | m   | \*Comm-Res  | See         |
| 2.4 |                     |     |     |             | A.4.3.14    |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.3 | unc                 | cn  | m   |             |             |
|     | orrelatedSearchInfo |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.4 | algorithmIdentifier | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.5 | encrypted           | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 3   | Errors              | m   | m   |             | See         |
|     |                     |     |     |             | A.4.3.12    |
+-----+---------------------+-----+-----+-------------+-------------+

c5: If \[pageresreq\] then support of this feature is m else o.

c6 If \[matchvalonly\] then support of this feature is m else o.

c7: If \[extfilter\] then support of this feature is m else o.

#### Add Entry ElementsA.4.3.3.8 Ref. A.6.3.3.8 {#add-entry-elementsa.4.3.3.8-ref.-a.6.3.3.8 .Annex-4}

Prerequisite: \[signAdd\]

This ISP deals with the DSA as a responder, support for this table
implies being able to receive and process the addEntryArgument and to
generate the addEntryResult.

+-----+---------------------+-----+-----+-------------+-------------+
| I   | Protocol Element    | Pr  | P   | Predicate   | Note        |
| tem |                     | oto | rof | Name        |             |
| No. |                     | col | ile |             |             |
|     |                     |     |     |             |             |
|     |                     | Sta | Sta |             |             |
|     |                     | tus | tus |             |             |
+=====+=====================+=====+=====+=============+=============+
| 1   | AddEntryArgument    | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.1 | toBeSigned          | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.2 | object              | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.3 | entry               | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.4 | targetSystem        | cn  | c8  |             | See         |
|     |                     |     |     |             | A.4.3.26    |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.5 | CommonArguments     | m   | m   | \*Comm-Arg  | See         |
|     |                     |     |     |             | A.4.3.13    |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.6 | algorithmIdentifier | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.7 | encrypted           | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | AddEntryResult      | m   | m   |             | Note 2      |
+-----+---------------------+-----+-----+-------------+-------------+
| 3   | Errors              | m   | m   |             | See         |
|     |                     |     |     |             | A.4.3.12    |
+-----+---------------------+-----+-----+-------------+-------------+

c8: If\[ targetsystem\] then support of this feature is m else o.

Note 2: Results return a NULL and cannot be signed. Implementation
should return unsigned results.

#### Remove Entry ElementsA.4.3.3.9 Ref. A.6.3.3.9 {#remove-entry-elementsa.4.3.3.9-ref.-a.6.3.3.9 .Annex-4}

Prerequisite: \[signRemove\]

This ISP deals with the DSA as a responder, support for this table
implies being able to receive and process the removeEntryArgument and to
generate the removeEntryResult.

+-----+---------------------+-----+-----+-------------+-------------+
| I   | Protocol Element    | Pr  | P   | Predicate   | Note        |
| tem |                     | oto | rof | Name        |             |
| No. |                     | col | ile |             |             |
|     |                     |     |     |             |             |
|     |                     | Sta | Sta |             |             |
|     |                     | tus | tus |             |             |
+=====+=====================+=====+=====+=============+=============+
| 1   | RemoveEntryArgument | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.1 | toBeSigned          | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.2 | object              | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.3 | CommonArguments     | m   | m   | \*Comm-Arg  | See         |
|     |                     |     |     |             | A.4.3.13    |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.4 | algorithmIdentifier | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.5 | encrypted           | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | RemoveEntryResult   | m   | m   |             | Note 2      |
+-----+---------------------+-----+-----+-------------+-------------+
| 3   | Errors              | m   | m   |             | See         |
|     |                     |     |     |             | A.4.3.12    |
+-----+---------------------+-----+-----+-------------+-------------+

Note 2: Results return a NULL and cannot be signed. Implementation
should return unsigned results.

#### Modify Entry ElementsA.4.3.3.10 Ref. A.6.3.3.10 {#modify-entry-elementsa.4.3.3.10-ref.-a.6.3.3.10 .Annex-4}

Prerequisite: \[signModifyReq\]

This ISP deals with the DSA as a responder, support for this table
implies being able to receive and process the modifyEntryArgument and to
generate the modifyEntryResult.

+-----+---------------------+-----+-----+-------------+-------------+
| I   | Protocol Element    | Pr  | P   | Predicate   | Note        |
| tem |                     | oto | rof | Name        |             |
| No. |                     | col | ile |             |             |
|     |                     |     |     |             |             |
|     |                     | Sta | Sta |             |             |
|     |                     | tus | tus |             |             |
+=====+=====================+=====+=====+=============+=============+
| 1   | ModifyEntryArgument | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.1 | toBeSigned          | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.2 | object              | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.3 | changes             | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.  | addAttribute        | m   | m   |             |             |
| 3.1 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.  | removeAttribute     | m   | m   |             |             |
| 3.2 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.  | addValues           | m   | m   |             |             |
| 3.3 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.  | removeValues        | m   | m   |             |             |
| 3.4 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.4 | CommonArguments     | m   | m   | \*Comm-Arg  | See         |
|     |                     |     |     |             | A.4.3.13    |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.5 | algorithmIdentifier | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.6 | encrypted           | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | ModifyEntryResult   | m   | m   |             | Note 2      |
+-----+---------------------+-----+-----+-------------+-------------+
| 3   | Errors              | m   | m   |             | See         |
|     |                     |     |     |             | A.4.3.12    |
+-----+---------------------+-----+-----+-------------+-------------+

Note 2: Results return a NULL and cannot be signed. Implementation
should return unsigned results.

#### ModifyDN ElementsA.4.3.3.11 Ref. A.6.3.3.11 {#modifydn-elementsa.4.3.3.11-ref.-a.6.3.3.11 .Annex-4}

Prerequisite: \[signModDN\]

This ISP deals with the DSA as a responder, support for this table
implies being able to receive and process the modifyDNArgument and to
generate the modifyDNResult.

+-----+---------------------+-----+-----+-------------+-------------+
| I   | Protocol Element    | Pr  | P   | Predicate   | Note        |
| tem |                     | oto | rof | Name        |             |
| No. |                     | col | ile |             |             |
|     |                     |     |     |             |             |
|     |                     | Sta | Sta |             |             |
|     |                     | tus | tus |             |             |
+=====+=====================+=====+=====+=============+=============+
| 1   | ModifyDNArgument    | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.1 | toBeSigned          | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.2 | object              | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.3 | newRDN              | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.4 | deleteOldRDN        | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.5 | newSuperior         | cn  | c9  |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.6 | CommonArguments     | m   | m   | \*Comm-Arg  | See         |
|     |                     |     |     |             | A.4.3.13    |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.7 | algorithmIdentifier | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.8 | encrypted           | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | ModifyDNResult      | m   | m   |             | Note 2      |
+-----+---------------------+-----+-----+-------------+-------------+
| 3   | Errors              | m   | m   |             | See         |
|     |                     |     |     |             | A.4.3.12    |
+-----+---------------------+-----+-----+-------------+-------------+

c9: If \[newsuperior\] then support of this feature is m else o.

Note 2: Results return a NULL and cannot be signed. Implementation
should return unsigned results..

#### Errors and ParametersA.4.3.3.12 Ref. A.6.3.3.12 {#errors-and-parametersa.4.3.3.12-ref.-a.6.3.3.12 .Annex-4}

Only additional requirements or those different from the requirements
specified in ISO/IEC ISP 15125-3 are defined below.

+------+---------------------+-----+-----+-------------+-------------+
| Item | Protocol Element    | Pr  | P   | Predicate   | Note        |
| No.  |                     | oto | rof | Name        |             |
|      |                     | col | ile |             |             |
|      |                     |     |     |             |             |
|      |                     | Sta | Sta |             |             |
|      |                     | tus | tus |             |             |
+======+=====================+=====+=====+=============+=============+
| 6    | invalidSignature    | c   | c:  |             |             |
| .1.4 |                     | :cn | c10 |             |             |
+------+---------------------+-----+-----+-------------+-------------+
| 6    | protectionRequired  | c:  | c:  |             |             |
| .1.5 |                     | cn  | c10 |             |             |
+------+---------------------+-----+-----+-------------+-------------+

c10: If \[digitalSig\] then support for this feature is m else -.

#### Common Arguments ElementsA.4.3.3.13 Ref. A.6.3.3.13 {#common-arguments-elementsa.4.3.3.13-ref.-a.6.3.3.13 .Annex-4}

Prerequisite: \[Comm-Arg\]

Only additional requirements or those different from the requirements
specified in ISO/IEC ISP 15125-3 are defined below.

+-----+---------------------+-----+-----+-------------+-------------+
| I   | Protocol Element    | Pr  | P   | Predicate   | Note        |
| tem |                     | oto | rof | Name        |             |
| No. |                     | col | ile |             |             |
|     |                     |     |     |             |             |
|     |                     | Sta | Sta |             |             |
|     |                     | tus | tus |             |             |
+=====+=====================+=====+=====+=============+=============+
| 2   | securityParameters  | cn  | c10 |             |             |
+-----+---------------------+-----+-----+-------------+-------------+

c10: If \[digitalSig\] then support for this feature is m else -.

#### Common Results ElementsA.4.3.3.14 Ref. A.6.3.3.14 {#common-results-elementsa.4.3.3.14-ref.-a.6.3.3.14 .Annex-4}

Prerequisite: \[Comm-Res\]

Only additional requirements or those different from the requirements
specified in ISO/IEC ISP 15125-3 are defined below.

+-----+---------------------+-----+-----+-------------+-------------+
| I   | Protocol Element    | Pr  | P   | Predicate   | Note        |
| tem |                     | oto | rof | Name        |             |
| No. |                     | col | ile |             |             |
|     |                     |     |     |             |             |
|     |                     | Sta | Sta |             |             |
|     |                     | tus | tus |             |             |
+=====+=====================+=====+=====+=============+=============+
| 1   | securityParameters  | cn  | c10 |             |             |
+-----+---------------------+-----+-----+-------------+-------------+

c10: If \[digitalSig\] then support for this feature is m else -.

#### Service ControlsA.4.3.3.15 Ref. A.6.3.3.15  {#service-controlsa.4.3.3.15-ref.-a.6.3.3.15 .Annex-4}

Prerequisite: \[Serv-Ctrls\]

There are no additional requirements for Service Controls beyond those
specified in ISO/IEC ISP 15125-3.

#### Entry Information SelectionA.4.3.3.16 Ref. A.6.3.3.16 {#entry-information-selectiona.4.3.3.16-ref.-a.6.3.3.16 .Annex-4}

There are no additional requirements for Entry Information Selection
beyond those specified in ISO/IEC ISP 15125-3.

#### Entry InformationA.4.3.3.17 Ref. A.6.3.3.17 {#entry-informationa.4.3.3.17-ref.-a.6.3.3.17 .Annex-4}

There are no additional requirements for Entry Information beyond those
specified in ISO/IEC ISP 15125-3.

#### Filter ElementsA.4.3.3.18 Ref. A.6.3.3.18 {#filter-elementsa.4.3.3.18-ref.-a.6.3.3.18 .Annex-4}

There are no additional requirements for Filter Elements beyond those
specified in ISO/IEC ISP 15125-3.

#### Filter Item ElementsA.4.3.3.19 Ref. A.6.3.3.19  {#filter-item-elementsa.4.3.3.19-ref.-a.6.3.3.19 .Annex-4}

There are no additional requirements for Filter Item Elements beyond
those specified in ISO/IEC ISP 15125-3.

#### Paged ResultsA.4.3.3.20 Ref. A.6.3.3.20 {#paged-resultsa.4.3.3.20-ref.-a.6.3.3.20 .Annex-4}

There are no additional requirements for Paged Results beyond those
specified in ISO/IEC ISP 15125-3.

#### Continuation ReferenceA.4.3.3.21 Ref. A.6.3.3.21 {#continuation-referencea.4.3.3.21-ref.-a.6.3.3.21 .Annex-4}

Out of scope. See ISO/IEC ISP 15125-4.

#### Security ParametersA.4.3.3.22 Ref. A.6.3.3.22 {#security-parametersa.4.3.3.22-ref.-a.6.3.3.22 .Annex-4}

Prerequisite: \[strongAuth or digitalSig\]

+-----+---------------------+-----+-----+-------------+--------------+
| I   | Protocol Element    | Pr  | P   | Predicate   | Note         |
| tem |                     | oto | rof |             |              |
|     |                     | col | ile |             |              |
| No. |                     |     |     |             |              |
|     |                     | Sta | Sta |             |              |
|     |                     | tus | tus |             |              |
+-----+---------------------+-----+-----+-------------+--------------+
| 1   | certification-path  | m   | m   | \*Cert-Path | Ref.         |
|     |                     |     |     |             | A.4.3.3.23   |
+-----+---------------------+-----+-----+-------------+--------------+
| 2   | name                | o   | m   |             |              |
+-----+---------------------+-----+-----+-------------+--------------+
| 3   | time                | o   | m   |             |              |
+-----+---------------------+-----+-----+-------------+--------------+
| 4   | random              | o   | m   |             |              |
+-----+---------------------+-----+-----+-------------+--------------+
| 5   | target              | o   | m   |             |              |
+-----+---------------------+-----+-----+-------------+--------------+

#### CertificationPathA.4.3.3.23 Ref. A.6.3.3.23 {#certificationpatha.4.3.3.23-ref.-a.6.3.3.23 .Annex-4}

Prerequisite: \[Cert-Path\]

+-----+---------------------+-----+-----+-------------+-------------+
| I   | Protocol Element    | Pr  | P   | Predicate   | Note        |
| tem |                     | oto | rof |             |             |
|     |                     | col | ile |             |             |
| No. |                     |     |     |             |             |
|     |                     | Sta | Sta |             |             |
|     |                     | tus | tus |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1   | userCertificate     | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | theCACertificates   | o   | o   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.1 | forward             | c:  | c:  |             |             |
|     |                     | o.n | o.2 |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.2 | reverse             | c:  | c:  |             |             |
|     |                     | o.n | o.2 |             |             |
+-----+---------------------+-----+-----+-------------+-------------+

o.2: At least one of the pair shall be present as specified in ITU-T
Rec. X.509 \| ISO/IEC 9594-8, Clause 8. If both are present, issuer
shall match subject.

##### CertificateA.4.3.3.23.1 Ref. A.6.3.3.23.1 {#certificatea.4.3.3.23.1-ref.-a.6.3.3.23.1 .Annex-5}

Prerequisite: \[Cert-Path\]

+-----+---------------------+-----+-----+--------------+-------------+
| I   | Protocol Element    | Pr  | P   | Predicate    | Note        |
| tem |                     | oto | rof |              |             |
|     |                     | col | ile |              |             |
| No. |                     |     |     |              |             |
|     |                     | Sta | Sta |              |             |
|     |                     | tus | tus |              |             |
+-----+---------------------+-----+-----+--------------+-------------+
| 1   | toBeSigned          | m   | m   |              |             |
+-----+---------------------+-----+-----+--------------+-------------+
| 1.1 | version             | m   | m   |              |             |
+-----+---------------------+-----+-----+--------------+-------------+
| 1.2 | serialNumber        | m   | m   |              |             |
+-----+---------------------+-----+-----+--------------+-------------+
| 1.3 | signature           | m   | m   |              | See         |
|     |                     |     |     |              | A           |
|     |                     |     |     |              | .4.3.3.23.2 |
+-----+---------------------+-----+-----+--------------+-------------+
| 1.4 | issuer              | m   | m   |              |             |
+-----+---------------------+-----+-----+--------------+-------------+
| 1.5 | validity            | m   | m   |              |             |
+-----+---------------------+-----+-----+--------------+-------------+
| 1.  | notBefore           | m   | m   |              |             |
| 5.1 |                     |     |     |              |             |
+-----+---------------------+-----+-----+--------------+-------------+
| 1.  | notAfter            | m   | m   |              |             |
| 5.2 |                     |     |     |              |             |
+-----+---------------------+-----+-----+--------------+-------------+
| 1.6 | subject             | m   | m   |              |             |
+-----+---------------------+-----+-----+--------------+-------------+
| 1.7 | s                   | m   | m   |              |             |
|     | ubjectPublicKeyInfo |     |     |              |             |
+-----+---------------------+-----+-----+--------------+-------------+
| 1.  | algorithm           | m   | m   |              |             |
| 7.1 |                     |     |     |              |             |
+-----+---------------------+-----+-----+--------------+-------------+
| 1.  | subjectPublicKey    | m   | m   |              |             |
| 7.2 |                     |     |     |              |             |
+-----+---------------------+-----+-----+--------------+-------------+
| 1.8 | iss                 | o   | o   |              | Note 3      |
|     | uerUniqueIdentifier |     |     |              |             |
+-----+---------------------+-----+-----+--------------+-------------+
| 1.9 | subj                | o   | o   |              | Note 3      |
|     | ectUniqueIdentifier |     |     |              |             |
+-----+---------------------+-----+-----+--------------+-------------+
| 1   | extensions          | cn  | m   | \*Extensions | See         |
| .10 |                     |     |     |              | A           |
|     |                     |     |     |              | .4.3.3.23.3 |
+-----+---------------------+-----+-----+--------------+-------------+
| 2   | algorithmIdentifier | m   | m   | \*Algor-ID   | See         |
|     |                     |     |     |              | A           |
|     |                     |     |     |              | .4.3.3.23.2 |
+-----+---------------------+-----+-----+--------------+-------------+
| 3   | encrypted           | m   | m   |              |             |
+-----+---------------------+-----+-----+--------------+-------------+

Note 3: If present, version must be 2 or 3.

##### Algorithm IdentifierA.4.3.3.23.2 Ref. A.6.3.3.23.2 {#algorithm-identifiera.4.3.3.23.2-ref.-a.6.3.3.23.2 .Annex-5}

Prerequisite: \[Algor-ID\]

+-----+---------------------+-----+-----+-------------+-------------+
| I   | Protocol Element    | Pr  | P   | Predicate   | Note        |
| tem |                     | oto | rof |             |             |
|     |                     | col | ile |             |             |
| No. |                     |     |     |             |             |
|     |                     | Sta | Sta |             |             |
|     |                     | tus | tus |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1   | algorithm           | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | parameters          | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+

##### ExtensionsA.4.3.3.23.3 Ref. A.6.3.3.23.3 {#extensionsa.4.3.3.23.3-ref.-a.6.3.3.23.3 .Annex-5}

Prerequisite: \[Extensions\]

+-----+---------------------+-----+-----+-------------+-------------+
| I   | Protocol Element    | Pr  | P   | Predicate   | Note        |
| tem |                     | oto | rof |             |             |
|     |                     | col | ile |             |             |
| No. |                     |     |     |             |             |
|     |                     | Sta | Sta |             |             |
|     |                     | tus | tus |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1   | extnID              | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | critical            | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 3   | extnValue           | m   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+

#### Access ControlA.4.3.3.24  {#access-controla.4.3.3.24 .Annex-4}

Out of scope. See ISO/IEC ISP 15125-9.

#### Supported ReferencesA.4.3.3.25 Ref. A.6.3.3.25 {#supported-referencesa.4.3.3.25-ref.-a.6.3.3.25 .Annex-4}

There are no additional requirements beyond those specified in ISO/IEC
ISP 15125-3.

#### Access PointA.4.3.3.26 Ref. A.6.3.3.26 {#access-pointa.4.3.3.26-ref.-a.6.3.3.26 .Annex-4}

There are no additional requirements beyond those specified in ISO/IEC
ISP 15125-3.

## Directory Schema and Directory System Schema Ref. A.6.4A.4.4 {#directory-schema-and-directory-system-schema-ref.-a.6.4a.4.4 .Annex-2}

**Directory Schema** - With the exception of the object classes and
attributes shown in tables A.4.4.1 and A.4.4.2 there are no additional
requirements beyond those specified in ISO/IEC ISP 15126-1 (FDY 11).

**Directory System Schema** - Out of scope. See ISO/IEC ISP 15126-2 (FDY
12) for Directory System Schema.

### Standard Object Classes Ref. A.6.4.1.1A.4.4.1 {#standard-object-classes-ref.-a.6.4.1.1a.4.4.1 .Annex-3}

+------+-------------------+------+-----+-------------+-------------+
| Item | Object class      | Prot | P   | Predicate   | Notes       |
| No.  |                   | ocol | rof |             |             |
|      |                   |      | ile |             |             |
|      |                   | St   |     |             |             |
|      |                   | atus | Sta |             |             |
|      |                   |      | tus |             |             |
+------+-------------------+------+-----+-------------+-------------+
| 17   | strongA           | o    | c11 |             |             |
|      | uthenticationUser |      |     |             |             |
+------+-------------------+------+-----+-------------+-------------+
| 18   | certi             | o    | m   |             |             |
|      | ficationAuthority |      |     |             |             |
+------+-------------------+------+-----+-------------+-------------+

c11: if \[strongAuth or digitalSig\] then m else o.

### Attribute TypesA.4.4.2 Ref. A.6.4.3.1 {#attribute-typesa.4.4.2-ref.-a.6.4.3.1 .Annex-3}

+------+--------------------+------+------+-----------+--------------+
| **   | **Attribute Type** | Prot | Pro  | **Pr      | **Notes**    |
| Item |                    | ocol | file | edicate** |              |
| N    |                    |      |      |           |              |
| o.** |                    | St   | St   |           |              |
|      |                    | atus | atus |           |              |
+------+--------------------+------+------+-----------+--------------+
| 48   | userCertificate    | cn   | c11  |           |              |
+------+--------------------+------+------+-----------+--------------+
| 49   | cACertificate      | cn   | m    |           |              |
+------+--------------------+------+------+-----------+--------------+
| 50   | autho              | o    | c12  |           |              |
|      | rityRevocationList |      |      |           |              |
+------+--------------------+------+------+-----------+--------------+
| 51   | certifi            | o    | c13  |           |              |
|      | cateRevocationList |      |      |           |              |
+------+--------------------+------+------+-----------+--------------+
| 52   | cr                 | o    | o    |           |              |
|      | ossCertificatePair |      |      |           |              |
+------+--------------------+------+------+-----------+--------------+

c11: if \[strongAuth or digitalSig\] then m else o.

c12: if \[arl\] then m else o.

c13: if \[crl\] then m else o.

## Supported ISO/IEC 10646-1 Character SetsA.4.5  {#supported-isoiec-10646-1-character-setsa.4.5 .Annex-2}

Out of scope. See ISO/IEC ISP 15126-1.

######## [^4]**^)^****Annex B**

# (Normative) {#normative-1 .Annex .unnumbered}

**Profile Specific Implementation Conformance Statement**

######### IntroductionB.1 {#introductionb.1 .Annex-1}

Implementations claiming support to ISO/IEC 15125-6 should include this
Profile Specific Implementation Conformance Statement (ICS) with ITU-T
Recommendation X.583 (1997) \| ISO/IEC 13248-1: 1997, *Information
technology \-- Open Systems Interconnection -Directory Access Protocol:
Protocol Implementation Conformance Statement (PICS) Proforma*. This
annex sets predicates, which are necessary to determine the proper
support for elements of the PRL tables found in annex A, and should
therefore be addressed prior to filling out the PICS.

The proper submittal of this ICS shall be based on guidance given in
ITU-T Recommendation X.583 (1997) \| ISO/IEC 13248-1: 1997, *Information
technology \-- Open Systems Interconnection -Directory Access Protocol:
Protocol Implementation Conformance Statement (PICS) Proforma*.

######### Identification of the Profile CorrigendaB.2 {#identification-of-the-profile-corrigendab.2 .Annex-1}

The supplier of the PICS proforma shall identify any corrigenda (i.e.
Technical Corrigenda or equivalent) to the published ISP that have been
applied. Suppliers of the proforma should modify the proforma, or attach
relevant additional pages in order to apply the corrigenda, and then
record the application of the profile corrigenda in the PICS tables.

+---------------------+------------------------------------------------+
| Identification of   | ISO/IEC 15125-6                                |
| corrigenda applied  |                                                |
| to this part of the | Corr:                                          |
| ISP                 |                                                |
|                     | Corr:                                          |
|                     |                                                |
|                     | Corr:                                          |
|                     |                                                |
|                     | Corr:                                          |
+---------------------+------------------------------------------------+

######### General SecurityB.3 {#general-securityb.3 .Annex-1}

+-----+-----------------------------+----+----+------+-------+------+
| I   | Operation                   | Pr | P  | Sup  | Pred  | N    |
| tem |                             | ot | ro | port | icate | otes |
| No. |                             | oc | fi |      | Name  |      |
|     |                             | ol | le |      |       |      |
|     |                             |    |    |      |       |      |
|     |                             | St | St |      |       |      |
|     |                             | at | at |      |       |      |
|     |                             | us | us |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 1   | Does the DSA support        | o  | o  |      |       | SeeA |
|     | commonly used Algorithms?   |    |    |      |       | nnex |
|     |                             |    |    |      |       | D    |
+-----+-----------------------------+----+----+------+-------+------+
| 2   | Does the DSA support        | o  | o  |      |       |      |
|     | Certificates?               |    |    |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 2.1 | Version 1                   | c  | c  |      |       |      |
|     |                             | :o | :o |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 2.2 | Version 2                   | c  | c  |      |       |      |
|     |                             | :o | :o |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 2.3 | Version 3                   | c  | c  |      |       |      |
|     |                             | :o | :m |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 2.4 | Other                       | i  | i  |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 3   | Does the DSA support        | o  | o  |      |       |      |
|     | Certificate Revocation      |    |    |      |       |      |
|     | List?                       |    |    |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 3.1 | Version 1                   | c  | c  |      |       |      |
|     |                             | :o | :o |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 3.2 | Version 2                   | c  | c: |      | \*crl |      |
|     |                             | :o | c1 |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 3.3 | other                       | i  | i  |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 4   | Does the DSA support        | o  | o  |      | \*arl |      |
|     | Authority Revocation List?  |    |    |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 5   | Does the DSA support the    | o  | o  |      |       | Note |
|     | ASN.1 Distinguished         |    |    |      |       | 1    |
|     | Encoding Rules (DER)?       |    |    |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 6   | Does the DSA support the    | \- | m  |      |       | See  |
|     | correct interpretation of   |    |    |      |       | 6    |
|     | UTCTime for Y2K?            |    |    |      |       | .3.j |
+-----+-----------------------------+----+----+------+-------+------+

c1: If the implementation supports strong authentication (See A.4.2.2/3
in Annex A) then this feature is m else o.

Note 1: DSAs shall conform to the encoding rules as specified in \[ITU-T
Rec. X.509 (1993) \| ISO/IEC 9594-8:1995\] Clause 9.

######### Simple AuthenticationB.4 {#simple-authenticationb.4 .Annex-1}

ISO/IEC 15125-6 (ADY 42) only addresses support for Protected Simple
Authentication. Implementor\'s should see ISO/IEC 15125-3 (ADY 21) for
support of Unprotected Simple Authentication.

+---+-----------------------------+----+----+-----+---------+------+
| I | Operation                   | Pr | P  | S   | Pr      | N    |
| t |                             | ot | ro | upp | edicate | otes |
| e |                             | oc | fi | ort | Name    |      |
| m |                             | ol | le |     |         |      |
| N |                             |    |    |     |         |      |
| o |                             | St | St |     |         |      |
| . |                             | at | at |     |         |      |
|   |                             | us | us |     |         |      |
+---+-----------------------------+----+----+-----+---------+------+
| 1 | Does the DSA support Simple | o  | i  |     |         | See  |
|   | Unprotected Authentication? |    |    |     |         | Part |
|   |                             |    |    |     |         | 3    |
+---+-----------------------------+----+----+-----+---------+------+
| 2 | Does the DSA support        | o  | o  |     | \*p     | Note |
|   | Protected Simple            |    |    |     | rotecte | 2    |
|   | Authentication?             |    |    |     | dSimple |      |
+---+-----------------------------+----+----+-----+---------+------+
| 2 | Does the DSA support simple | c  | c  |     |         |      |
| . | protected authentication in | :o | :o |     |         |      |
| 1 | the initiator role?         |    |    |     |         |      |
+---+-----------------------------+----+----+-----+---------+------+
| 2 | Does the DSA support simple | c  | c  |     |         |      |
| . | protected authentication in | :o | :o |     |         |      |
| 2 | the responder role?         |    |    |     |         |      |
+---+-----------------------------+----+----+-----+---------+------+

Note 2: A positive response implies support for simple authentication
(See A.4.2.2/2 in Annex A).

######### Strong AuthenticationB.5 {#strong-authenticationb.5 .Annex-1}

+-----+-----------------------------+----+----+------+------+-------+
| I   | Operation                   | Pr | P  | Sup  | P    | Notes |
| tem |                             | ot | ro | port | redi |       |
| No. |                             | oc | fi |      | cate |       |
|     |                             | ol | le |      | Name |       |
|     |                             |    |    |      |      |       |
|     |                             | St | St |      |      |       |
|     |                             | at | at |      |      |       |
|     |                             | us | us |      |      |       |
+-----+-----------------------------+----+----+------+------+-------+
| 1   | Does the DSA support Strong | o  | o  |      |      | Note  |
|     | Authentication on Bind      |    |    |      |      | 3     |
|     | Request?                    |    |    |      |      |       |
+-----+-----------------------------+----+----+------+------+-------+
| 1.1 | One-way                     | c  | c  |      |      |       |
|     |                             | :o | :o |      |      |       |
+-----+-----------------------------+----+----+------+------+-------+
| 1.2 | Two-way                     | c  | c  |      |      |       |
|     |                             | :o | :o |      |      |       |
+-----+-----------------------------+----+----+------+------+-------+
| 1.3 | Three-way                   | \- | \- |      |      | Note  |
|     |                             |    |    |      |      | 4     |
+-----+-----------------------------+----+----+------+------+-------+
| 2   | Does the DSA support Strong | o  | o  |      |      | Note  |
|     | Authentication on Bind      |    |    |      |      | 3     |
|     | Result?                     |    |    |      |      |       |
+-----+-----------------------------+----+----+------+------+-------+
| 3   | Does the DSA support strong | o  | o  |      | \*st | Note  |
|     | authentication in the       |    |    |      | rong | 3     |
|     | initiator role?             |    |    |      | Auth |       |
+-----+-----------------------------+----+----+------+------+-------+
| 4   | Does the DSA support strong | o  | o  |      | \*st | Note  |
|     | authentication in the       |    |    |      | rong | 3     |
|     | responder role?             |    |    |      | Auth |       |
+-----+-----------------------------+----+----+------+------+-------+
| 5   | Does the DSA support the    | o  | o  |      |      |       |
|     | generation of certification |    |    |      |      |       |
|     | path for strong             |    |    |      |      |       |
|     | authentication?             |    |    |      |      |       |
+-----+-----------------------------+----+----+------+------+-------+

Note 3: A positive response implies support for strong authentication
(See A.4.2.2/3 in Annex A).

Note 4: Three-way authentication is not supported by the X.500 standard.

######### Signed OperationsB.6 {#signed-operationsb.6 .Annex-1}

+---+-----------------------------+----+----+------+--------+------+
| I | Operation                   | Pr | P  | Sup  | Pre    | N    |
| t |                             | ot | ro | port | dicate | otes |
| e |                             | oc | fi |      | Name   |      |
| m |                             | ol | le |      |        |      |
| N |                             |    |    |      |        |      |
| o |                             | St | St |      |        |      |
| . |                             | at | at |      |        |      |
|   |                             | us | us |      |        |      |
+---+-----------------------------+----+----+------+--------+------+
| 1 | Does the DSA support Signed | o  | o  |      | \*si   | Note |
|   | Read?                       |    |    |      | gnRead | 5    |
+---+-----------------------------+----+----+------+--------+------+
| 2 | Does the DSA support Signed | o  | o  |      | \      | Note |
|   | Compare?                    |    |    |      | *signC | 5    |
|   |                             |    |    |      | ompare |      |
+---+-----------------------------+----+----+------+--------+------+
| 3 | Does the DSA support Signed | o  | o  |      | \*si   | Note |
|   | List Request?               |    |    |      | gnList | 5    |
+---+-----------------------------+----+----+------+--------+------+
| 4 | Does the DSA support Signed | o  | o  |      | \*sign | Note |
|   | Search?                     |    |    |      | Search | 5    |
+---+-----------------------------+----+----+------+--------+------+
| 5 | Does the DSA support Signed | o  | o  |      | \*s    | Note |
|   | Add Entry?                  |    |    |      | ignAdd | 5    |
+---+-----------------------------+----+----+------+--------+------+
| 6 | Does the DSA support Signed | o  | o  |      | \*sign | Note |
|   | Remove Entry?               |    |    |      | Remove | 5    |
+---+-----------------------------+----+----+------+--------+------+
| 7 | Does the DSA support Signed | o  | o  |      | \*sign | Note |
|   | Modify Entry?               |    |    |      | Modify | 5    |
+---+-----------------------------+----+----+------+--------+------+
| 8 | Does the DSA support Signed | o  | o  |      | \*sig  | Note |
|   | ModifyDN?                   |    |    |      | nModDN | 5    |
+---+-----------------------------+----+----+------+--------+------+

Note 5: A positive response implies support for Signed DAP operations
(See A.4.2.1/5 in Annex A).

######## **Annex C**

**(Informative)**

# Recommended Practices {#recommended-practices .Annex .unnumbered}

This annex identifies additional information about authenticated
Directory access. It is not necessary to follow the recommended
practices when claiming conformance to this profile. The information in
this annex may be required by local Security Policies.

######### CertificateC.1 {#certificatec.1 .Annex-1}

Authentication relies on each user possessing a unique distinguished
name. The allocation of distinguished names is the responsibility of the
Naming Authorities. Each user shall therefore trust the Naming
Authorities not to issue duplicate distinguished names. The certificate
binds the user's distinguished name (DN) with the public key
information, in a manner which can be authenticated by other users. A
certification path is an ordered sequence of certificates which can be
authenticated to verify that a user's certificate is valid.

## Certificate Cache Management C.1.1 {#certificate-cache-management-c.1.1 .Annex-2}

The DUA should validate the certificates retrieved from the DSA DIB. The
certificates are composed of the complete certification path(s) required
for each secure transaction. The DUA should either retrieve the
certificates from the Directory, from a local cache (database) that it
maintains, or from a file. If a local cache of certificates is
maintained by the DUA, the DUA should validate any certificates used,
and verify that they have not been revoked. Certificates may also be
passed with directory protocol security parameters.

## Revocation of CertificatesC.1.2 {#revocation-of-certificatesc.1.2 .Annex-2}

A certificate may become invalid and need to be removed from the system.
The mechanism used to revoke certificates is a Certificate Revocation
List (CRL). Once placed on a CRL, a certificate should remain on the
list until it has expired. If the Certificate is stored in the
directory, it should be removed from the corresponding entry prior to
being placed on the CRL. DUAs should be capable of checking the CRL to
ensure the validity of the certificate.

## Certificate Revocation List C.1.3 {#certificate-revocation-list-c.1.3 .Annex-2}

In order to verify a signature on a document, an iterative process
determines the next step in the certification path and which certificate
should be obtained next. Each certificate obtained should be checked
against the appropriate CRL before it can be used. Starting with the key
of the entity where the certification path ends, the user verifies the
signature on the certificate signed by that entity. Once this
certificate is verified, the public key within it is extracted and is
used to verify the next signature in the path. The verification process
continues until the signature on the document signer's certificate is
verified and the public key is extracted.

## Certificate HierarchyC.1.4 {#certificate-hierarchyc.1.4 .Annex-2}

A certification path logically forms an unbroken chain of trusted points
in the Directory Information Tree (DIT) between two users wishing to
authenticate. The precise method used to obtain the certification path
may be hierarchical or non-hierarchical. A user's certificate is signed
by a Certification Authority (CA). A hierarchical CA-structure has one
CA who is responsible for issuing certificates to the users in the
system. The CA becomes the root of a small tree structure. A
non-hierarchical CA-structure is one in which two CAs meet and exchange
CA public keys. Each will create a certificate binding the other CA's
unique name to its public key and sign the certificate with its own
private key. This process is called cross certification.

### Support of Hierarchical/Non-hierarchical CA-structures C.1.4.1 {#support-of-hierarchicalnon-hierarchical-ca-structures-c.1.4.1 .Annex-3}

There are several schemes for organizing Certification Authority
(CA)-structures within a Key Management System (KMS). CA-structures can
be hierarchical in nature where there is always one root or top-level
CA, or non-hierarchical where several CA's can agree to cross-certify
each other.

######### Generation of Key PairsC.2 {#generation-of-key-pairsc.2 .Annex-1}

If a user generates their own key pair, they are responsible for
ensuring that they use a method for generating a good key pair. The user
should store the private key in a secure location so that it cannot be
easily compromised. This is typically a smart card, PCMCIA card or an
encrypted diskette. The user is also responsible for having their public
key certified by a Certificate Authority (CA). To have their public key
certified by a CA, the user can present themselves and their key to the
CA. The CA should then authenticate the user. If authentication is to
occur in person, it may consist of the examination of several forms of
identification which the user presents. Once the CA is sure of the
identity of the user and the validity of the key, it will generate a
certificate for the user that will bind the identity of the user to
their public key. The CA may distribute the certificate to the user in
person, through the mail, or electronically. The CA will then post the
certificate with the appropriate directory server.

In order to generate the user's key pair, the user should have either
hardware or software that is capable of generating key pairs. If it is
not practical to distribute these resources to all users, a central key
generating system may be necessary. This would require all users to go
to a particular location in order to generate their key pairs. Once the
system has generated these key pairs it gives the public and private
keys to the user. The key generating system should then automatically
destroy the copy of the user's private key once given to the user. The
user would then follow the proper identification processes for the
certificate generating procedures.

In the event that a user's private key is compromised, their public
certificate should be revoked. Compromise will typically occur when
their private key is lost or stolen.

######### Use of Time StampsC.3 {#use-of-time-stampsc.3 .Annex-1}

To use timestamps for authentication, all parties should maintain local
clocks that are periodically synchronized in a secure manner with a
reliable source of time. Between synchronizations with a reliable time
source, local clocks may drift. Two parties should allow a time window
for timestamps to compensate for local clock drift and the fact that
Directory requests/responses take time to cross a network.

######### Correlation of List and Search resultsC.4 {#correlation-of-list-and-search-resultsc.4 .Annex-1}

If digital signatures are supported, the DUA is responsible for
verifying the digital signatures returned by the DSA in a list or search
result. The DUA should be capable of verifying digital signatures from
more than one DSA if a distributed environment were used to generate the
list or search results. Correlating the results of list and search
operations is the responsibility of the DUA. The merging of list and
search information returned in the result is the responsibility of the
DUA. DSAs should not merge these results on behalf of the DUA. In some
cases, the DUA may receive information from various DSA each supporting
different levels of authentication and digital signatures. The decision
as to whether unverified information can be used needs to be determined.
The DUA should make a decision whether or not to use the information if
the digital signature is invalid.

######### Periodic Revocation List Checks C.5 {#periodic-revocation-list-checks-c.5 .Annex-1}

There is no requirement that the CA Certificate and Revocation List
validation process be carried out in respect to each DAP operation. In
fact, doing so would multiply the traffic by a factor of at least three
(the original operation plus at least one read operation initiated by
the Responder to obtain a CA Certificate, a Revocation List, plus at
least one similar operation initiated by the Invoker). It would be
reasonable to carry out such checks periodically (e.g., once every hour,
or when new revocation lists are known to have been posted

.

######## **Annex D**

**(Informative)**

# Commonly Used Algorithms {#commonly-used-algorithms .Annex .unnumbered}

This annex identifies commonly used algorithms. It is not necessary to
follow the recommended practices when claiming conformance to this
profile. Unless explicitly indicated, all algorithms have a NULL
parameter.

######### Message Digest AlgorithmsD.1 {#message-digest-algorithmsd.1 .Annex-1}

The following message digests algorithms may be used:

-   Square mod N (as registered in X.509 (88)): deprecated

-   MD2: { rsadsi digestAlgorithm(2) 2 }

-   MD4: { rsadsi digestAlgorithm(2) 4 }

-   MD5: { rsadsi digestAlgorithm(2) 5 }

-   SHA: { algorithm 18 } Note: This is the NIST Secure Hash Algorithm

-   MDC-2: { algorithm 19 } Note: DES-based hash algorithm (ANSI X93.1
    Part 2)

-   SHA-1: { algorithm 26 } Note: Fixed version of SHA

######### Reversible Public Key AlgorithmsD.2 {#reversible-public-key-algorithmsd.2 .Annex-1}

The following reversible public key algorithms may be used :

-   RSA: Registration from X.509. The text suggests "rsaEncryption"
    might be better, as X.509 specifies

no padding rules.

-   RSA Encryption: per PKCS #1 (available from pkcs@rsa.com). OID is {
    rsadsi pkcs(1) pkcs-1(1) 1 }

-   RSA Signature: ISO 9766 w/ signing and verifying functions. This is
    being published as ANSI

    X9.31 Part 1. { algorithm 11 }

######### Irreversible Public Key AlgorithmsD.3 {#irreversible-public-key-algorithmsd.3 .Annex-1}

The following irreversible public key algorithms may be used :

-   EIGamal: { dssig-algorithm encryption-algorithm(1) 1 }

-   DSA: This is the NIST Digital Signature Algorithm, also X.9.30-1: {
    algorithm 12 }

    It carries a parameter, of type:

    DSAParameters ::= SEQUENCE {

    modulusLength INTEGER, \-- length of p in bits

    prime1 INTEGER, \-- modulus p

    prime2 INTEGER, \-- modulus q

    base INTEGER } \-- base g

    Another version assumes the parameters are distributed by external
    means. This one is deprecated, since it can use the dsa ID.

    dsa-common

    PARAMETER NULL ::= { algorithm 20 }

######### Signature AlgorithmsD.4 {#signature-algorithmsd.4 .Annex-1}

The following signature algorithms may be used. These combine a hash and
public key algorithm and are what is used in the "signature" field in a
certificate, etc.

-   Square-mod-n with RSA: From X.509 (deprecated).

-   MD2 with RSA: This uses the X.509 version of RSA.

    { dssig-algorithm signatureAlgorithm(3) 1 }

-   MD4 with RSA: { algorithm 2 }

-   MD5 with RSA: { algorithm 3 }

-   MD2 with RSA Encryption: Uses PKCS version of RSA.

    { rsadsi pkcs(1) pkcs-1(1) 2 }

-   MD4 with RSA Encryption: Uses PKCS version of RSA.

    { algorithm 4 }

-   MD5 with RSA Encryption: Uses PKCS version of RSA.

    { rsadsi pkcs(1) pkcs-1(1) 4 }

-   MD2 with EIGamal:

    { dssig-algorithm signatureAlgorithm(3) 2 }

-   DSA with SHA: (Carries DSAParameters) { algorithm 2 }

-   DSA with SHA-1: { algorithm 27 }

-   DSA Common With SHA: (DSA with common parameters) (deprecated) {
    algorithm 21 }

-   MDC-2 with RSA Signature: { algorithm 14 }

-   SHA with RSA Signature: { algorithm 15 }

-   SHA-1 with RSA Signature: { algorithm 29 }

-   MD2 with RSA Signature: { algorithm 22 }

-   MD5 with RSA Signature: { algorithm 23 }

[^1]: Part 8 (ADY 44) DSA Simple Access Control, in the taxonomy, was
    combined with part 9 (ADY 45) to form a single profile on Access
    Control. Part 8 therefore does not exist.

[^2]: The Directory Standards do not define precisely how two way
    authentication is done. The method defined above is one of several
    choices. Future versions may specify alternative encodings.

[^3]: Where the syntax is unknown, it is impossible to distinguish
    between a Set and a Set-of type. In addition, implicit encoding may
    be Set or Set-of types, but cannot be recognised as such by the DSA
    if the encoding is unknown

[^4]: Copyright release for ICS proformas: Users of this
    Recommendation/International Standard may freely reproduce this ICS
    proforma so that it can be used for its intended purpose and may
    further publish the completed ICS.