**TITLE: Information Technology-International Standardized Profile ADY41
-the Directory Part 5 - DUA Authentication As DAP Initiator**

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

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

**STATUS:** This is the tenth preliminary Draft of this document.

**DATE:** 16-June-1998

**COMMENTS:**

**Contents**

Foreword [vii](#__RefHeading___Toc418042080)

Introduction [ix](#__RefHeading___Toc418042081)

1\. Scope [1](#scope1)

1.1 General [1](#general1.1)

1.2 Position Within The Taxonomy [1](#position-within-the-taxonomy1.2)

1.3 Scenario [2](#scenario1.3)

2\. Normative References [3](#normative-references2)

2.1 Paired ITU Recommendations \| International Standards equivalent in
technical content
[3](#paired-itu-recommendations-international-standards-equivalent-in-technical-content3)

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

2.3 Additional Normative References
[5](#additional-normative-references2.3)

3\. Definitions [6](#definitions3)

3.1 Directory Definitions [6](#directory-definitions3.1)

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

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

4\. Abbreviations [7](#abbreviations4)

5\. Conformance [8](#conformance5)

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

5.2 Static Conformance Requirements
[9](#static-conformance-requirements5.2)

5.2.1 Simple Protected Authentication
[10](#simple-protected-authentication5.2.1)

5.2.2 Strong Authentication in the Directory Bind
[10](#strong-authentication-in-the-directory-bind5.2.2)

5.2.3 Signed DAP Operations [11](#signed-dap-operations5.2.3)

5.2.4 Signed Results [11](#signed-results5.2.4)

5.2.5 Certificates and Revocation Lists
[12](#certificates-and-revocation-lists5.2.5)

5.2.5.1 Certificates [12](#certificates5.2.5.1)

5.2.5.2 Revocation Lists [12](#revocation-lists5.2.5.2)

5.2.5.3 Certification Hierarchy Topology
[13](#certification-hierarchy-topology5.2.5.3)

6\. Procedures [14](#procedures6)

6.1 Two-way Authentication [14](#two-way-authentication6.1)

6.2 Random Numbers [15](#random-numbers6.2)

6.3 Distinguished Encoding Rules [15](#distinguished-encoding-rules6.3)

6.4 Simple Protected Authentication
[17](#simple-protected-authentication6.4)

6.4.1 Initiator of the Bind [17](#initiator-of-the-bind6.4.1)

6.4.2 Initiator\'s response to Bind Result
[18](#initiators-response-to-bind-result6.4.2)

6.5 Strong Authentication in the Directory Bind
[19](#strong-authentication-in-the-directory-bind6.5)

6.5.1 One-Way Strong Authentication
[19](#one-way-strong-authentication6.5.1)

6.5.2 Two-Way Strong Authentication
[20](#two-way-strong-authentication6.5.2)

6.5.3 Initiator of the Bind [20](#initiator-of-the-bind6.5.3)

6.5.4 Initiator\'s response to Bind Result
[21](#initiators-response-to-bind-result6.5.4)

6.6 Signed DAP Operations [22](#signed-dap-operations6.6)

6.6.1 Digitally Signed Directory Operations
[22](#digitally-signed-directory-operations6.6.1)

6.6.2 Invoker of the Operation [22](#invoker-of-the-operation6.6.2)

6.6.3 Invoker receiving signed Return Result
[23](#invoker-receiving-signed-return-result6.6.3)

6.7 Certificates [23](#certificates6.7)

6.7.1 Certification Path Creation
[23](#certification-path-creation6.7.1)

6.7.2 Certification Path Use [23](#certification-path-use6.7.2)

6.7.3 Certificate Processing [24](#certificate-processing6.7.3)

6.7.4 Revocation List Processing [24](#revocation-list-processing6.7.4)

Annex A Profile Requirements List [A-1](#annex-a)

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

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

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

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

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

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

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

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

A.3.2.3 Item reference numbers s [A-2](#__RefHeading___Toc418042136)

A.3.2.4 Protocol Status column [A-3](#__RefHeading___Toc418042137)

A.3.2.5 Profile Status column [A-3](#__RefHeading___Toc418042138)

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

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

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

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

A.4.1 Roles [A-5](#__RefHeading___Toc418042143)

A.4.2 General Capabilities and Global statement of conformance
[A-5](#__RefHeading___Toc418042144)

A.4.2.1 General Capabilities [A-5](#__RefHeading___Toc418042145)

A.4.2.2 Supported Security Levels [A-5](#__RefHeading___Toc418042146)

A.4.2.3 Supported Access Control Schemes
[A-6](#__RefHeading___Toc418042147)

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

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

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

A.4.3.2.1 Operations [A-6](#__RefHeading___Toc418042151)

A.4.3.2.2 Extensions [A-6](#__RefHeading___Toc418042152)

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

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

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-9](#directory-bind-errora.4.3.3.1.3-ref.-a.6.3.3.1.3)

A.4.3.3.2 Directory Unbind Elements [A-9](#__RefHeading___Toc418042158)

A.4.3.3.3 Read Elements [A-9](#__RefHeading___Toc418042159)

A.4.3.3.4 Compare Elements [A-10](#__RefHeading___Toc418042160)

A.4.3.3.5 Abandon Elements [A-10](#__RefHeading___Toc418042161)

A.4.3.3.6 List Elements [A-11](#__RefHeading___Toc418042162)

A.4.3.3.7 Search Elements [A-12](#__RefHeading___Toc418042163)

A.4.3.3.8 Add Entry Elements [A-13](#__RefHeading___Toc418042164)

A.4.3.3.9 Remove Entry Elements [A-13](#__RefHeading___Toc418042165)

A.4.3.3.10 Modify Entry Elements [A-14](#__RefHeading___Toc418042166)

A.4.3.3.11 ModifyDN Elements [A-14](#__RefHeading___Toc418042167)

A.4.3.3.12 Errors and Parameters [A-14](#__RefHeading___Toc418042168)

A.4.3.3.13 Common Arguments Elements
[A-15](#__RefHeading___Toc418042169)

A.4.3.3.14 Common Results Elements [A-15](#__RefHeading___Toc418042170)

A.4.3.3.15 Service Controls [A-15](#__RefHeading___Toc418042171)

A.4.3.3.16 Entry Information Selection
[A-15](#__RefHeading___Toc418042172)

A.4.3.3.17 Entry Information [A-15](#__RefHeading___Toc418042173)

A.4.3.3.18 Filter Elements [A-15](#__RefHeading___Toc418042174)

A.4.3.3.19 Filter Item Elements [A-16](#__RefHeading___Toc418042175)

A.4.3.3.20 Paged Results [A-16](#__RefHeading___Toc418042176)

A.4.3.3.21 Continuation Reference [A-16](#__RefHeading___Toc418042177)

A.4.3.3.22 Security Parameters [A-16](#__RefHeading___Toc418042178)

A.4.3.3.23 CertificationPath [A-16](#__RefHeading___Toc418042179)

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](#__RefHeading___Toc418042183)

A.4.3.3.25 Supported References [A-18](#__RefHeading___Toc418042184)

A.4.3.3.26 Access Point [A-18](#__RefHeading___Toc418042185)

A.4.4 Directory Schema and Directory System Schema
[A-18](#__RefHeading___Toc418042186)

A.4.4.1 Standard Object Classes [A-18](#__RefHeading___Toc418042187)

A.4.4.2 Attribute Types [A-18](#__RefHeading___Toc418042188)

A.4.5 Supported ISO/IEC 10646-1 Character Sets
[A-18](#__RefHeading___Toc418042189)

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

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

B.2 Identification of Profile Corrigenda
[B-1](#__RefHeading___Toc418042192)

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

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

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

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

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

C.1 Certificate [C-1](#__RefHeading___Toc418042198)

C.2 Certificate Cache Management [C-1](#__RefHeading___Toc418042199)

C.2.1 Revocation of Certificates [C-1](#__RefHeading___Toc418042200)

C.2.2 Certificate Revocation List [C-1](#__RefHeading___Toc418042201)

C.2.3 Certificate Hierarchy [C-1](#__RefHeading___Toc418042202)

C.2.3.1 Support of Hierarchical/Non-hierarchical CA-structures
[C-2](#__RefHeading___Toc418042203)

C.3 Generation of Key Pairs [C-2](#__RefHeading___Toc418042204)

C.4 Use of Time Stamps [C-3](#__RefHeading___Toc418042205)

C.5 Correlation of List and Search results
[C-3](#__RefHeading___Toc418042206)

C.6 Periodic Revocation List Checks [C-3](#__RefHeading___Toc418042207)

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

D.1 Message Digest Algorithms [D-1](#__RefHeading___Toc418042209)

D.2 Reversible Public Key Algorithms [D-1](#__RefHeading___Toc418042210)

D.3 Irreversible Public Key Algorithms
[D-2](#__RefHeading___Toc418042211)

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

**Figures**

Figure 1: Scenario [2](#__RefHeading___Toc418042213)

Figure 2: Certificate Hierarchies and Evaluation Paths
[13](#__RefHeading___Toc418042214)

Figure 3: Validation Strategies [14](#__RefHeading___Toc418042215)

Figure 4: Simple Protected Authentication
[17](#__RefHeading___Toc418042216)

Figure 5: One-Way Strong Authentication
[19](#__RefHeading___Toc418042217)

Figure 6: Two-Way Strong Authentication
[20](#__RefHeading___Toc418042218)

Figure 7: Digitally Signed Operations [22](#__RefHeading___Toc418042219)

Tables

Table 1: Definitions and References [6](#__RefHeading___Toc418042220)

Foreword[]{#__RefHeading___Toc418042080 .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

```{=html}
<!-- -->
```
-   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-5 - DUA
    Authentication as DAP Initiator

```{=html}
<!-- -->
```
-   Annex B: Profile Specific Implementation Conformance Statement (ICS)

    The present document contains two informative annexes:

```{=html}
<!-- -->
```
-   Annex C: Recommended Practices

-   Annex D: Commonly Used Algorithms

Introduction[]{#__RefHeading___Toc418042081 .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-5,
specifies application profile ADY41 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-5 profiles the manner in which DUAs are to behave when
authenticating each other using simple protected authentication or
strong authentication as a DAP initiator. ISO/IEC ISP 15125-5 also
profiles the manner in which DUAs will perform digitally signed
operations.

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 5: DUA Authentication as DAP Initiator**

# Scope1

Primary DUA conformance requirements are stated in the Directory
Standards as profiled in ISO/IEC ISP 15125-1 (ADY 11). This part of the
profile, ISO/IEC ISP 15125-5 (ADY 41), covers DUA 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, support
for signed operations, and the use of protocol elements. In addition, it
covers actions by the DUA on handling (i.e., validating or not)
credentials returned by the DSA, the use of two-way strong
authentication and digitally signed operations. Any externally defined
forms of authentication are out of the scope of this profile.

## General1.1

This part of ISO/IEC ISP 15125 (ADY41) covers the Directory User Agent
(DUA) Authentication as a Directory Access Protocol (DAP) Initiator 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 DUA acting as an initiator of
an authenticated DAP request. This specification profiles the behavior
that a DUA supports when submitting simple protected and strongly
authenticated bind requests, generating digitally signed operation
requests to the Directory. This specification also profiles the behavior
that a DUA supports when resolving simple protected and strongly
authenticated bind responses, as well as, resolving digitally signed
results from the DSA. The protocol elements necessary to provide
authentication will also be discussed in this specification.

The objective of ISO/IEC 15125-5 is to profile the DUA-specific use of
authentication beyond simple unprotected binds and includes use of
different levels of authentication. It covers the issues involved in
using 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) is discussed for completeness and context. Factors
outside the scope of ISO/IEC ISP 15125-5 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 Taxonomy1.2

This document, part 5 of ISO/IEC ISP 15125, is one part of a multi part
ISP identified in ISO/IEC TR 10000-2 as \"ADY41- DUA Authentication as
DAP Initiator.\"

This part of ISO/IEC ISP 15125 shall be combined with Part 1 -- \"ADY11:
DUA Support of Directory Access Protocol\". Where there is a conflict
between this part and part 1 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

## Scenario1.3

A DUA 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 user's 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 which 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.

# Normative References2

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[3](#paired-itu-recommendations-international-standards-equivalent-in-technical-content3)

-   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 References2.3

-   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.*

# Definitions3

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

## Directory Definitions3.1

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 following terms 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.
  ----------------- -----------------------------------------------------

# Abbreviations4

**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

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 Profile Requirements List

RDN Relative Distinguished Name

ROSE Remote Operations Service Element

SUT System Under Test

# Conformance5

Primary DUA conformance requirements are stated in the Directory
Standards as profiled in ISO/IEC ISP 15125-1. The protocol
specifications specify 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-5 addresses the procedures the DUA shall be capable of
supporting when it initiates authenticated operations.

A DUA 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 DUA. The conformance statements of
ISO/IEC ISP 15125-5 lay down the range of information for suitable DUA
test suites.

## Conformance Statement

For each implementation claiming conformance to ISO/IEC ISP 15125-5, 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 requirements defined in \[ITU X.509 (1993) \|
ISO/IEC 9594-8:1995\], part 1 of this ISP (ISO/IEC ISP 15125-1), 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 found in Annex A of this document will
overlap features found in the PRL of ISO/IEC ISP 15125-1. 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. DUA column and signed
operations).

DUAs claiming conformance to ISO/IEC ISP 15125-5 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\].

DUAs conformant with ISO/IEC ISP 15125-5 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

DUAs claiming conformance with this ISP for the 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.

DUAs claiming conformance with this ISP for Simple Protected or Strong
Authentication in the Directory Bind shall comply with the error
handling procedures specified in ISO/IEC ISP 15125-1 when carrying out
Simple Protected or Strong Authentication in the Directory Bind.

DUAs claiming conformance with this ISP for signed DAP operations shall
comply with the error handling procedures specified in ISO/IEC ISP
15125-1. However, handling of digitally signed errors is not supported.

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

## Static Conformance Requirements5.2

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 Authentication5.2.1

DUAs claiming conformance to Simple Protected Authentication, as
initiator, shall be:

1.  Able to initiate a Directory Bind to a DSA using simple protected
    authentication in accordance with the procedures specified in Clause
    6.4.1.

2.  Able to accept, and validate simple protected credentials generated
    by the responding DSA to a Bind, in accordance with the procedures
    specified in Clause 6.4.2.

3.  Able to acquire or hold the passwords of DSAs to which Simple
    Protection for Bind is required, without requiring any Directory
    Operation.

4.  Able to configure an expiry time for the acceptability of a
    protected password between 1 and 900 seconds with a granularity of 1
    second or better (i.e. 1 sec, 2 sec, 3 sec, \... 900 sec).

Note: Configuration capability outside these limits is optional. The
interval actually chosen should normally be the shortest interval
guaranteed to be achieved between construction of the protocol and its
analysis, taking into account network delays.

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

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

### Strong Authentication in the Directory Bind5.2.2

DUAs claiming conformance to Strong Authentication on a Bind Request and
Bind Result, as initiator shall be capable of:

1\. Initiating a Directory Bind with a DSA using strong credentials in
accordance with the procedures specified in Clause 6.5.3.

2\. Accepting, and validating strong credentials generated by the
responder to a Directory Bind in accordance with the procedures
specified in Clause 6.5.4, and responding with an Unbind or Abort if the
credentials are invalid.

3\. Optionally acquiring or holding the certificates of DSAs to which
Directory Binds are to be possible, or acquiring or holding the public
keys or certificates of the issuers of certificates prior to Strong
Authentication in the Directory Bind without requiring any Directory
operation.

4\. Validating (i) CA Certificates and (ii) Revocation Lists relevant to
the certificates held for the corresponding DSA, when conformant with
the requirements specified in Clause 5.2.5, and terminating a DAP
association when identification of the communication partner is
uncertain by an abort or unbind.

Note: There is a requirement that conformant DUAs shall be able to
exercise the CA Certificate and Revocation List validation process
before returning control to the user. They may need to utilize the
association which will have been established when the DSA returns strong
credentials. However, a DSA in normal operation is not obliged always to
do so.

5\. Configuration to pass a certificate with the BindArgument.

6\. Configuring the time parameter.

Note: Strong authentication can only work satisfactorily when there is
adequate synchronization between the creator and the evaluator of a
signature. Achieving synchronization may be possible using a trusted
synchronization service, but other techniques are possible. Note that if
the means of synchronizing time is vulnerable to attack or correct time
synchronization is lost, then the authentication mechanism can become
vulnerable to replay attack.

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

### Signed DAP Operations5.2.3

DUAs claiming conformance to Signed DAP Operations, as invoker shall be
capable of:

1\. Configuration to Sign all DAP requests in a particular association.

2\. Initiating a signed DAP request in accordance with the procedures
specified in Clause 6.6.2.

3.  Validating (i) CA Certificates and (ii) Revocation Lists relevant to
    the certificates held for the corresponding DSA when conformant with
    the requirements specified in Clause 5.2.5, and providing indication
    to the user in the event of invalidity. Other actions (e.g. closing
    down the association) may be taken depending on the circumstances
    and on local policy.

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, obtaining a certificate and Certificate
Revocation list for the certificate. 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).

4.  As responder, accepting, and validating the signature of a signed
    DAP return result (when the definition of the operation permits it),
    in accordance with the procedures specified in Clause 6.6.3; or
    discarding the result and generating an abort, if appropriate, in
    the event that the returned signature is invalid in accordance with
    the procedures of ISO/IEC ISP 15125-1.

Note: Signature validation may require multiple signatures to be
validated and appropriate actions taken in the event of an invalid
signature.

### Signed Results5.2.4

DUAs claiming conformance to ISO/IEC ISP 15125-5 in support of Signed
DAP operations shall be capable of validating 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, and 10.

### Certificates and Revocation Lists5.2.5

#### Certificates5.2.5.1

DUAs 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 DUA, then the certificate should be
considered invalid.

#### Revocation Lists5.2.5.2

DUAs 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.

#### Certification Hierarchy Topology5.2.5.3

A DUA's signature is provided as credentials (bottom right of the Figure
2) for evaluation by reference to the signing DUA'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 2). 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 DUA 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 other DSAs which contain 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
    organization that owns the DUA.

2.  The entry for this trusted CA may hold cross-certificates (top right
    of the figure) which can be used to validate certificates for other
    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 3 which uses precisely the same graphic elements
as Figure 2, 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 3, the first known issuer is the trusted
    CA; in the center figure, a known issuer is encountered earlier).

2.  As above, except that the trusted CA is not in the same hierarchy as
    the user. 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 treen cannot then have a hierarchical
    relationship. DUAs compatible with this profile are therefore not
    permitted to assume that CAs have a hierarchical relationship.

# Procedures6

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

## Two-way Authentication6.1

DUAs 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 authentication. 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 authentication, 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
authentication is a matter of authentication policy between a DUA and a
DSA. ISO/IEC ISP 15125-5 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 initiating DUA
> shall check 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.

DUAs 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).

> Note: The DSA as responder (or performer), encodes 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.

2.  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.

> Note: 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 Numbers6.2

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 Rules6.3

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 shall remain as supplied to the DSA by
    the originating entity, modified by other of these rules as
    necessary.

i)  for all values of UTCTime type, which is identifiable 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 Authentication6.4

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.

### Initiator of the Bind6.4.1

For a DUA claiming conformance to Simple Protected Authentication, the
initiator 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 seconds, using any compliant UTCTime encoding
    that includes the seconds field, in accordance with ISO/IEC 8824-1:
    1995 \| 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 within N
    iterations. If two-way authentication is to be supported, then the
    DUA shall be able to encode this element in accordance with the
    requirements of 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 ASN.1 DER encodings of:

SEQUENCE {

name DistinguishedName, \-- equal to SimpleCredentials.name

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

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 own 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.

### Initiator\'s response to Bind Result6.4.2

The initiator of a Directory bind shall validate the incoming protected
simple credentials as follows (order of execution is not significant) :

• It shall synthesize the value of
**SimpleCredentials.password.protected** in accordance with the
procedures of the preceding clause; the credentials shall be taken as
invalid if the two hashed password values, as received and as
synthesized, are different.

• If the incoming timestamp **time1** is older than the present time by
more than the value of the configurable expiry period (see static
conformance requirements), or is older than the time of issue of the
original Bind Request by more than twice the value of the configurable
expiry period, the credentials shall be taken as invalid.

• If two-way authentication is to be supported, then the DUA shall be
able to decode and validate the incoming value of **random1** in
accordance with the requirements of Clause 6.2.

If the responder\'s credentials are invalid, or if the Bind Request is
to be rejected, the error procedures specified in ISO/IEC ISP 15125-1
shall be followed.

## Strong Authentication in the Directory Bind6.5

### One-Way Strong Authentication6.5.1

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 Authentication6.5.2

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.

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

### Initiator of the Bind6.5.3

The initiator shall support the following procedures:

1\. The initiator shall comply with procedures laid down in:

• \[ITU-T Rec. X.511 (1993) \| ISO/IEC 9594-3:1995\] Clause 8.1.2 3rd
paragraph.

• \[ITU-T Rec. X.509 (1993) \| ISO/IEC 9594-8:1995\] Clauses 10.2 or
10.3 depending on whether two one-way authentication or two-way
authentication is required.

Note: The selection of Clause 10.3 implies that two-way authentication
shall be supported, this does not preclude the use of two one-way
authentication for local purposes. Three-way authentication is not
supported by the Directory protocols for the Directory bind. If two-way
authentication is to be supported, then the DUA shall be able to encode
this element in accordance with the requirements of Clause 6.2.

2\. The initiator shall include either the
**StrongCredentials.certification-path** or the
**StrongCredentials.name** in the value of **StrongCredentials**.
Including both is legal (but unnecessary); if both are present, the
value of **StrongCredentials.certification-path.SIGNED.subject** shall
be identical to that of **StrongCredentials.name.**

3\. The inclusion of
**StrongCredentials.certification-path.theCACertificates** is optional,
but, if included, all certificates shall be subject to the restrictions
specified in Clause 6.7.1.

### Initiator\'s response to Bind Result6.5.4

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

1\. The DUA 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 DUA shall check that the **bind-token.algorithm** is supported,
that the **bind-token.name** value is identical to that of the DUA, and
that the **bind-token.time** is later than the present time; otherwise,
the credentials shall be taken as invalid.

3.  The DUA shall verify that the signature of the responder is correct
    by means of pre-stored certificate information, or by other means
    that do not require Directory operations; otherwise, the credentials
    shall be taken as invalid.

4 The DUA shall ensure that if there are appropriate revocation list,
the certificate received from the DSA is not present on these lists.

5.  The DUA should be capable of preventing user-initiated operations
    from taking place prior to validatin of the responding DSAs
    credentials.

6.  If any failure of return credentials is identified, closing the DAP
    association must be possible.

7.  If two-way authentication is to be supported, then the DSA shall be
    able to decode and validate the incoming value of random1 in
    accordance with the requirements of Clause 6.2.

If the DSA's credentials are invalid, or if the Bind Result is to be
rejected, the error procedures specified in ISO/IEC ISP 15125-1 shall be
followed.

## Signed DAP Operations6.6

### Digitally Signed Directory Operations6.6.1

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.![](media/image6.wmf){width="5.688888888888889in"
height="2.657638888888889in"}

###  Invoker of the Operation6.6.2

The invoking DUA shall support the following procedures for creating a
signed DAP operation over and above the stipulations of \[ITU-T Rec.
X.511 (1993) \| ISO/IEC 9594-3:1995\] Clause 7.10:

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 as authenticated by the Directory Bind; the
CACertificates is optionally included; if present, the restrictions of
6.7.1 shall apply.

• **securityParameters.time** shall be present and shall be an expiry
time for the validity of the signature.

-   **securityParameters.random** shall be present. If two-way
    authentication is to be supported, then the DUA shall be able to
    encode this element in accordance with the requirements of Clause
    6.2.

**• securityParameters.protectionRequest** shall be set to the value (1)
to indicate signed.

-   The **requestor** element from **CommonArguments** may be included,
    although it is redundant in that, if present, if shall always be
    identical to
    **securityParameters.certificationPath.userCertificate.subject.**

### Invoker receiving signed Return Result6.6.3

The invoking DUA shall support the following procedures for validating
the incoming Strong Credentials of the DSA (the order of execution is
optional) :

1\. The invoker shall check that the signature of the invoker is valid,
either using pre-stored certificate information, certificates/CRLs
obtained by from the Directory, or by other means; otherwise, the
signature shall be taken as invalid.

2.  The invoker shall maintain a list of information (e.g.
    {performer-name, **securityParameters.random** value}) for each
    incoming operation for at least the time preceding
    **securityParameters.time**, and shall detect a repetition of the
    combination on any association, if repetition is detected, the
    signature shall be taken as invalid.

```{=html}
<!-- -->
```
3.  If two-way authentication is to be supported, then the DUA shall be
    able to decode and validate the incoming value of **random1** in
    accordance with the requirements of Clause 6.2 and terminate the
    association if an invalid result is received.

If the DSA's credentials are invalid, or if the Bind Result is to be
rejected, the error procedures specified in ISO/IEC ISP 15125-1 shall be
followed.

## Certificates6.7

### Certification Path Creation6.7.1

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 Use6.7.2

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 Processing6.7.3

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, for example:

-   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 as defined in
    \[ITU-T Rec. X.520 (1993) \| ISO/IEC 9594-6:1995\] Clause 5.2.7).

the two unique identifiers shall match.

3.  DUAs shall be capable of configuring to match issuer or subject
    names when the name matches, and 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.

### Revocation List Processing6.7.4

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 DUA 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 DUA 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.

######## Annex A

# (Normative) {#normative .Annex}

**Profile Requirements List**

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

1.  Introduction[]{#__RefHeading___Toc418042128 .anchor}A.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 DUA acting as a DAP initiator. As such, it only identifies those
features from ISO/IEC ISP 15125-1 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-1 and ISO/IEC ISP 15126-1 (FDY
11); however this PRL shall take precedence for like features.

2.  Identification of the Implementation[]{#__RefHeading___Toc418042129
    .anchor}A.2

    1.  Identification of the PICS[]{#__RefHeading___Toc418042130
        .anchor}A.2.1

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-1 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-1. 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 DUA.
    (PICS subclause A.6.2.2)

-   The DUA support column for ICS tables that delineate between DUAs
    and DSAs support. Where the DUA 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.

    1.  Instructions []{#__RefHeading___Toc418042131 .anchor}

        1.  Purpose and structure of the
            PRL[]{#__RefHeading___Toc418042132 .anchor}

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.

2.  Symbols, terms, and abbreviations[]{#__RefHeading___Toc418042133
    .anchor}A.3.2

    1.  Introduction[]{#__RefHeading___Toc418042134 .anchor}A.3.2.1

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;

2.  Prerequisite notation[]{#__RefHeading___Toc418042135 .anchor}A.3.2.2

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.

3.  Item reference numbers[]{#__RefHeading___Toc418042136
    .anchor}A.3.2.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.

4.  Protocol Status column[]{#__RefHeading___Toc418042137
    .anchor}A.3.2.4

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.

5.  Profile Status column[]{#__RefHeading___Toc418042138 .anchor}A.3.2.5

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.

6.  Predicate column[]{#__RefHeading___Toc418042139 .anchor}A.3.2.6

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.

7.  Predicate Name[]{#__RefHeading___Toc418042140 .anchor}A.3.2.7

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.

8.  Note column[]{#__RefHeading___Toc418042141 .anchor}A.3.2.8

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.

2.  PRL Tables[]{#__RefHeading___Toc418042142 .anchor}A.4

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-1 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-1 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}.

1.  Roles[]{#__RefHeading___Toc418042143 .anchor}A.4.1 Ref. A.6.1

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

2.  General Capabilities and Global statement of
    conformance[]{#__RefHeading___Toc418042144 .anchor}A.4.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.

1.  General Capabilities[]{#__RefHeading___Toc418042145 .anchor}A.4.2.1
    Ref. A.6.2.2.1

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

2.  Supported Security Levels[]{#__RefHeading___Toc418042146
    .anchor}A.4.2.2 Ref. A.6.2.2.2

+------+-------------------------------+----+----+-----------+-------+
| 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.

3.  Supported Access Control Schemes[]{#__RefHeading___Toc418042147
    .anchor}A.4.2.3 Ref. A.6.2.2.3

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

3.  Capabilities and options. []{#__RefHeading___Toc418042148
    .anchor}A.4.3

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

The operation arguments and PDU parameters are identified.

1.  Supported application context. []{#__RefHeading___Toc418042149
    .anchor}A.4.3.1

The only application context supported is Directory Access application
context.

2.  Operations and extensions[]{#__RefHeading___Toc418042150
    .anchor}A.4.3.2

    1.  Operations[]{#__RefHeading___Toc418042151 .anchor}A.4.3.2.1 Ref.
        A.6.3.2.1

No additional requirements beyond those specified in ISO/IEC ISP 15125-1
and ISO/IEC ISP 15125-2.

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

2.  Extensions[]{#__RefHeading___Toc418042152 .anchor}A.4.3.2.2 Ref.
    A.6.3.2.2

DUAs should conform as a precondition to ISO/IEC 15125-1 (ADY 11).
Extensions should be consistent with support found in ISO/IEC 15125-1.

+-----+------------------+-------+------+-------------+-------------+
| 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 |             |
+-----+------------------+-------+------+-------------+-------------+

3.  Protocol elements[]{#__RefHeading___Toc418042153 .anchor}A.4.3.3

    1.  DirectoryBind Elements[]{#__RefHeading___Toc418042154
        .anchor}A.4.3.3.1

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 1 of this ISP
(ADY 11).

##### 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\]

+-----+--------------------+------+-----+-------------+-------------+
| 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 1  |
| .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\]

Note: This ISP deals with the DUA as an initiator, support for this
table implies being able to

receive and process the bind result, 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 |             |             |
| .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 1  |
| .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}

This ISP deals with the DUA as an initiator, support for this table
implies being able to receive and process the bind error, not initiate
it.

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

2.  Directory Unbind Elements[]{#__RefHeading___Toc418042158
    .anchor}A.4.3.3.2

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

3.  Read Elements[]{#__RefHeading___Toc418042159 .anchor}A.4.3.3.3 Ref.
    A.6.3.3.3

Prerequisite: \[signRead\]

This ISP deals with the DUA as an initiator, support for this table
implies being able to generate the readArgument and to receive and
process the readResult, not initiate it.

+-----+--------------------+------+-----+-------------+-------------+
| 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:o  | c:m |             |             |
| .3. |                    |      |     |             |             |
| 1.1 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2   | attribute          | c:o  | c:m |             |             |
| .3. |                    |      |     |             |             |
| 1.2 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2   | value              | c:o  | c:m |             |             |
| .3. |                    |      |     |             |             |
| 1.3 |                    |      |     |             |             |
+-----+--------------------+------+-----+-------------+-------------+
| 2.  | permission         | c:o  | 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.

4.  Compare Elements[]{#__RefHeading___Toc418042160 .anchor}A.4.3.3.4
    Ref. A.6.3.3.4

Prerequisite: \[signCompare\]

This ISP deals with the DUA as an initiator, support for this table
implies being able to generate the compareArgument and to receive and
process the compareResult, not initiate it.

+-----+--------------------+------+-----+-------------+-------------+
| 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          | o    | 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   |             |             |
+-----+--------------------+------+-----+-------------+-------------+

5.  Abandon Elements[]{#__RefHeading___Toc418042161 .anchor}A.4.3.3.5
    Ref. A.6.3.3.5

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

6.  List Elements[]{#__RefHeading___Toc418042162 .anchor}A.4.3.3.6 Ref.
    A.6.3.3.6

Prerequisite: \[signList\]

This ISP deals with the DUA as an initiator, support for this table
implies being able to generate the listArgument and to receive and
process the listResult, not initiate it.

+-----+---------------------+-----+-----+-------------+-------------+
| 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          | o   | m   |             |             |
| .2. |                     |     |     |             |             |
| 2.2 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | fromEntry           | o   | m   |             |             |
| .2. |                     |     |     |             |             |
| 2.3 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.  | part                | o   | o   |             |             |
| 2.3 | ialOutcomeQualifier |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | limitProblem        | c:o | c:o |             |             |
| .2. |                     |     |     |             |             |
| 3.1 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.2 | timeLimitExceeded   | c:m | c:m |             |             |
| .3. |                     |     |     |             |             |
| 1.1 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.2 | sizeLimitExceeded   | c:m | c:m |             |             |
| .3. |                     |     |     |             |             |
| 1.2 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.2 | administ            | c:m | c:m |             |             |
| .3. | rativeLimitExceeded |     |     |             |             |
| 1.3 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | unexplored          | c:o | c:m |             |             |
| .2. |                     |     |     |             |             |
| 3.2 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | unavailabl          | c:m | c:m |             |             |
| .2. | eCriticalExtensions |     |     |             |             |
| 3.3 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | unknownErrors       | c:o | c:o |             |             |
| .2. |                     |     |     |             |             |
| 3.4 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | queryReference      | c:  | c   |             |             |
| .2. |                     | cn  | :c5 |             |             |
| 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.

7.  Search Elements[]{#__RefHeading___Toc418042163 .anchor}A.4.3.3.7
    Ref. A.6.3.3.7

Prerequisite: \[signSearch\]

This ISP deals with the DUA as an initiator, support for this table
implies being able to generate the searchArgument and to receive and
process the searchResult, not initiate it.

+-----+---------------------+-----+-----+-------------+-------------+
| 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              | o   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.4 | filter              | o   | o   | \*Filter    | See         |
|     |                     |     |     |             | A.4.3.18    |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.5 | searchAliases       | o   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.6 | selection           | o   | o   | \*Info-Sel  | See         |
|     |                     |     |     |             | A.4.3.16    |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.7 | pagedResults        | cn  | c5  |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.8 | matchedValuesOnly   | o   | o   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.9 | extendedFilter      | cn  | c6  |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 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                | o   | o   |             |             |
| 2.3 | ialOutcomeQualifier |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | limitProblem        | c:o | c:o |             |             |
| .2. |                     |     |     |             |             |
| 3.1 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.2 | timeLimitExceeded   | c:m | c:m |             |             |
| .3. |                     |     |     |             |             |
| 1.1 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.2 | sizeLimitExceeded   | c:m | c:m |             |             |
| .3. |                     |     |     |             |             |
| 1.2 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2.2 | administ            | c:m | c:m |             |             |
| .3. | rativeLimitExceeded |     |     |             |             |
| 1.3 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | unexplored          | c:o | c:m |             |             |
| .2. |                     |     |     |             |             |
| 3.2 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | unavailabl          | c:o | c:m |             |             |
| .2. | eCriticalExtensions |     |     |             |             |
| 3.3 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | unknownErrors       | c:o | c:m |             |             |
| .2. |                     |     |     |             |             |
| 3.4 |                     |     |     |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 2   | queryReference      | c:  | c   |             |             |
| .2. |                     | cn  | :c5 |             |             |
| 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 \[extfilter\] then support of this feature is m else o.

8.  Add Entry Elements[]{#__RefHeading___Toc418042164 .anchor}A.4.3.3.8
    Ref. A.6.3.3.8

Prerequisite: \[signAdd\]

This ISP deals with the DUA as an initiator, support for this table
implies being able to generate the addEntryArgument and to receive and
process the addEntryResult, not initiate it.

+-----+---------------------+-----+-----+-------------+-------------+
| 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  | c7  |             | 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    |
+-----+---------------------+-----+-----+-------------+-------------+

c7: 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.

9.  Remove Entry Elements[]{#__RefHeading___Toc418042165
    .anchor}A.4.3.3.9 Ref. A.6.3.3.9

Prerequisite: \[signRemove\]

This ISP deals with the DUA as an initiator, support for this table
implies being able to generate the removeEntryArgument and to receive
and process the removeEntryResult, not initiate it.

+-----+---------------------+-----+-----+-------------+-------------+
| 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.

10. Modify Entry Elements[]{#__RefHeading___Toc418042166
    .anchor}A.4.3.3.10 Ref. A.6.3.3.10

Prerequisite: \[signModifyReq\]

This ISP deals with the DUA as an initiator, support for this table
implies being able to generate the modifyEntryArgument and to receive
and process the modifyEntryResult, not initiate it.

+-----+---------------------+-----+-----+-------------+-------------+
| 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.

11. ModifyDN Elements[]{#__RefHeading___Toc418042167 .anchor}A.4.3.3.11
    Ref. A.6.3.3.11

Prerequisite: \[signModDN\]

This ISP deals with the DUA as an initiator, support for this table
implies being able to generate the modifyDNEntryArgument and to receive
and process the modifyDNEntryResult, not initiate it.

+-----+---------------------+-----+-----+-------------+-------------+
| 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        | o   | m   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 1.5 | newSuperior         | cn  | c8  |             |             |
+-----+---------------------+-----+-----+-------------+-------------+
| 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    |
+-----+---------------------+-----+-----+-------------+-------------+

c8: 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..

12. Errors and Parameters[]{#__RefHeading___Toc418042168
    .anchor}A.4.3.3.12 Ref. A.6.3.3.12

Only additional requirements or those different from the requirements
specified in ISO/IEC ISP 15125-1 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 | :c9 |             |             |
+------+---------------------+-----+-----+-------------+-------------+
| 6    | protectionRequired  | c:  | c   |             |             |
| .1.5 |                     | cn  | :c9 |             |             |
+------+---------------------+-----+-----+-------------+-------------+

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

13. Common Arguments Elements[]{#__RefHeading___Toc418042169
    .anchor}A.4.3.3.13 Ref. A.6.3.3.13

Prerequisite: \[Comm-Arg\]

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

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

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

14. Common Results Elements[]{#__RefHeading___Toc418042170
    .anchor}A.4.3.3.14 Ref. A.6.3.3.14

Prerequisite: \[Comm-Res\]

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

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

15. Service Controls[]{#__RefHeading___Toc418042171 .anchor}A.4.3.3.15
    Ref. A.6.3.3.15

Prerequisite: \[Serv-Ctrls\]

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

16. Entry Information Selection[]{#__RefHeading___Toc418042172
    .anchor}A.4.3.3.16 Ref. A.6.3.3.16

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

17. Entry Information[]{#__RefHeading___Toc418042173 .anchor}A.4.3.3.17
    Ref. A.6.3.3.17

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

18. Filter Elements[]{#__RefHeading___Toc418042174 .anchor}A.4.3.3.18
    Ref. A.6.3.3.18

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

19. Filter Item Elements[]{#__RefHeading___Toc418042175
    .anchor}A.4.3.3.19 Ref. A.6.3.3.19

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

20. Paged Results[]{#__RefHeading___Toc418042176 .anchor}A.4.3.3.20 Ref.
    A.6.3.3.20

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

21. Continuation Reference[]{#__RefHeading___Toc418042177
    .anchor}A.4.3.3.21 Ref. A.6.3.3.21

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

22. Security Parameters[]{#__RefHeading___Toc418042178
    .anchor}A.4.3.3.22 Ref. A.6.3.3.22

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   |             |              |
+-----+---------------------+-----+-----+-------------+--------------+

23. CertificationPath[]{#__RefHeading___Toc418042179 .anchor}A.4.3.3.23
    Ref. A.6.3.3.23

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   |             |             |
+-----+---------------------+-----+-----+-------------+-------------+

24. Access Control[]{#__RefHeading___Toc418042183 .anchor}A.4.3.3.24

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

25. Supported References[]{#__RefHeading___Toc418042184
    .anchor}A.4.3.3.25 Ref. A.6.3.3.25

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

26. Access Point[]{#__RefHeading___Toc418042185 .anchor}A.4.3.3.26 Ref.
    A.6.3.3.26

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

4.  Directory Schema and Directory System Schema Ref.
    A.6.4[]{#__RefHeading___Toc418042186 .anchor}A.4.4

**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.

.

1.  Standard Object Classes Ref.
    A.6.4.1.1[]{#__RefHeading___Toc418042187 .anchor}A.4.4.1

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

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

2.  Attribute Types[]{#__RefHeading___Toc418042188 .anchor}A.4.4.2 Ref.
    A.6.4.3.1

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

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

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

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

5.  Supported ISO/IEC 10646-1 Character
    Sets[]{#__RefHeading___Toc418042189 .anchor}A.4.5

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

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

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

**Profile Specific Implementation Conformance Statement**

3.  Introduction[]{#__RefHeading___Toc418042191 .anchor}B.1

Implementations claiming support to ISO/IEC 15125-5 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*.

4.  Identification of the Profile
    Corrigenda[]{#__RefHeading___Toc418042192 .anchor}B.2

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-5                                |
| corrigenda applied  |                                                |
| to this part of the | Corr:                                          |
| ISP                 |                                                |
|                     | Corr:                                          |
|                     |                                                |
|                     | Corr:                                          |
|                     |                                                |
|                     | Corr:                                          |
+---------------------+------------------------------------------------+

5.  General Security[]{#__RefHeading___Toc418042193 .anchor}B.3

+-----+-----------------------------+----+----+------+-------+------+
| 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 DUA support        | o  | o  |      |       | See  |
|     | commonly used Algorithms?   |    |    |      |       | A    |
|     |                             |    |    |      |       | nnex |
|     |                             |    |    |      |       | D    |
+-----+-----------------------------+----+----+------+-------+------+
| 2   | Does the DUA 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 DUA support        | o  | o  |      |       |      |
|     | Certificate Revocation      |    |    |      |       |      |
|     | List?                       |    |    |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 3.1 | Version 1                   | c  | c  |      |       |      |
|     |                             | :o | :o |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 3.2 | Version 2                   | c  | c1 |      | \*crl |      |
|     |                             | :o |    |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 3.3 | other                       | i  | i  |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 4   | Does the DUA support        | o  | o  |      | \*arl |      |
|     | Authority Revocation List?  |    |    |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 5   | Does the DUA support the    | o  | o  |      |       | Note |
|     | ASN.1 Distinguished         |    |    |      |       | 1    |
|     | Encoding Rules (DER)?       |    |    |      |       |      |
+-----+-----------------------------+----+----+------+-------+------+
| 6   | Does the DUA 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: DUAs shall conform to the encoding rules as specified in \[ITU-T
Rec. X.509 (1993) \| ISO/IEC 9594-8:1995\] Clause 9.

6.  Simple Authentication[]{#__RefHeading___Toc418042194 .anchor}B.4

ISO/IEC 15125-5 (ADY 41) only addresses support for Protected Simple
Authentication. Implementor\'s should see ISO/IEC 15125-1 (ADY 11) 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 DUA support Simple | o  | i  |     |         | See  |
|   | Unprotected Authentication? |    |    |     |         | Part |
|   |                             |    |    |     |         | 1    |
+---+-----------------------------+----+----+-----+---------+------+
| 2 | Does the DUA support        | o  | o  |     | \*p     | Note |
|   | Protected Simple            | .1 |    |     | rotecte | 2    |
|   | Authentication?             |    |    |     | dSimple |      |
+---+-----------------------------+----+----+-----+---------+------+
| 2 | Does the DUA support simple | c  | c  |     |         |      |
| . | protected authentication in | :o | :o |     |         |      |
| 1 | the initiator role?         |    |    |     |         |      |
+---+-----------------------------+----+----+-----+---------+------+
| 2 | Does the DUA 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).

7.  Strong Authentication[]{#__RefHeading___Toc418042195 .anchor}B.5

+-----+-----------------------------+----+----+------+------+-------+
| 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 DUA 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 DUA support Strong | o  | o  |      |      | Note  |
|     | Authentication on Bind      |    |    |      |      | 3     |
|     | Result?                     |    |    |      |      |       |
+-----+-----------------------------+----+----+------+------+-------+
| 3   | Does the DUA support strong | o  | o  |      | \*st | Note  |
|     | authentication in the       |    |    |      | rong | 3     |
|     | initiator role?             |    |    |      | Auth |       |
+-----+-----------------------------+----+----+------+------+-------+
| 4   | Does the DUA support strong | o  | o  |      | \*st | Note  |
|     | authentication in the       |    |    |      | rong | 3     |
|     | responder role?             |    |    |      | Auth |       |
+-----+-----------------------------+----+----+------+------+-------+
| 5   | Does the DUA 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.

8.  Signed Operations[]{#__RefHeading___Toc418042196 .anchor}B.6

+---+-----------------------------+----+----+------+--------+------+
| 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 DUA support Signed | o  | o  |      | \*si   | Note |
|   | Read?                       |    |    |      | gnRead | 5    |
+---+-----------------------------+----+----+------+--------+------+
| 2 | Does the DUA support Signed | o  | o  |      | \      | Note |
|   | Compare?                    |    |    |      | *signC | 5    |
|   |                             |    |    |      | ompare |      |
+---+-----------------------------+----+----+------+--------+------+
| 3 | Does the DUA support Signed | o  | o  |      | \*si   | Note |
|   | List Request?               |    |    |      | gnList | 5    |
+---+-----------------------------+----+----+------+--------+------+
| 4 | Does the DUA support Signed | o  | o  |      | \*sign | Note |
|   | Search?                     |    |    |      | Search | 5    |
+---+-----------------------------+----+----+------+--------+------+
| 5 | Does the DUA support Signed | o  | o  |      | \*s    | Note |
|   | Add Entry?                  |    |    |      | ignAdd | 5    |
+---+-----------------------------+----+----+------+--------+------+
| 6 | Does the DUA support Signed | o  | o  |      | \*sign | Note |
|   | Remove Entry?               |    |    |      | Remove | 5    |
+---+-----------------------------+----+----+------+--------+------+
| 7 | Does the DUA support Signed | o  | o  |      | \*sign | Note |
|   | Modify Entry?               |    |    |      | Modify | 5    |
+---+-----------------------------+----+----+------+--------+------+
| 8 | Does the DUA 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}

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.

9.  Certificate[]{#__RefHeading___Toc418042198 .anchor}C.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.

10. Certificate Cache Management []{#__RefHeading___Toc418042199
    .anchor}C.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.

1.  Revocation of Certificates[]{#__RefHeading___Toc418042200
    .anchor}C.2.1

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.

2.  Certificate Revocation List []{#__RefHeading___Toc418042201
    .anchor}C.2.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.

3.  Certificate Hierarchy[]{#__RefHeading___Toc418042202 .anchor}C.2.3

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.

1.  Support of Hierarchical/Non-hierarchical CA-structures
    []{#__RefHeading___Toc418042203 .anchor}C.2.3.1

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.

![](media/image7.wmf)

11. Generation of Key Pairs[]{#__RefHeading___Toc418042204 .anchor}C.3

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.

12. Use of Time Stamps[]{#__RefHeading___Toc418042205 .anchor}C.4

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.

13. Correlation of List and Search
    results[]{#__RefHeading___Toc418042206 .anchor}C.5

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.

14. Periodic Revocation List Checks []{#__RefHeading___Toc418042207
    .anchor}C.6

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}

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.

15. Message Digest Algorithms[]{#__RefHeading___Toc418042209 .anchor}D.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*

    1.  Reversible Public Key Algorithms[]{#__RefHeading___Toc418042210
        .anchor}D.2

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}

1.  Irreversible Public Key Algorithms[]{#__RefHeading___Toc418042211
    .anchor}D.3

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}

    1.  Signature Algorithms[]{#__RefHeading___Toc418042212 .anchor}D.4

        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 encoding.

[^3]: Where the syntax is unknown, it is impossible to distinguish
    between a Set and a Set-of type. In addition, implicit encodings 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.