Internet-Draft D.W.Chadwick
PKIX WG University of Salford
Intended Category: Standards Track
Expires: 20 February 2000 20 August 1999
Internet X.509 Public Key Infrastructure
Operational Protocols - LDAPv3
<draft-ietf-pkix-ldap-v3-01.txt>
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all the provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft expires on 20 February 2000. Comments and
suggestions on this document are encouraged. Comments on this
document should be sent to the PKIX working group discussion list:
<ietf-pkix@imc.org>
or directly to the author.
ABSTRACT
This document describes the features of the Lightweight Directory
Access Protocol v3 that are needed in order to support a public key
infrastructure based on X.509 certificates and CRLs.
1. Introduction
RFC 2559 [1] specifies the subset of LDAPv2 [2] that is necessary to
retrieve X.509 [9] certificates and CRLs from LDAP servers. However
LDAPv2 has a number of deficiencies that may limit its usefulness in
certain circumstances. The most notable of these are:
- LDAPv2 distinguished names must be composed from the IA5
character set and cannot contain accented or non-latin characters,
- LDAPv2 only has a limited number of supported authentication
schemes for binding to the server, in particular the use of hashed
passwords or TLS [3] are not supported,
- LDAPv2 only supports a single directory server. It is the
responsibility of the user to pre-configure his client with the
required set of LDAP servers, and to choose the correct one for each
certificate and CRL retrieval.
It is for these reasons (and others not listed here) that the IETF
have stopped the standardisation of the LDAPv2 protocol and have
replaced it with the LDAPv3 protocol [4]. However the LDAPv3 protocol
is much more complex than the LDAPv2 protocol and many of its
features are not essential for simple PKIX use. This document
describes the features of LDAPv3 that are essential, or not required,
or are optional for servers to support a PKI based on X.509.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5].
2. Features Of Ldapv3 That MUST Be Supported
Attribute descriptions are a superset of attribute type definitions.
They allow attribute subtyping to be specified in the LDAPv3
protocol. The ;binary option is an exception to this. This option
allows certificates and CRLs to be asked for and returned as binary
values encoded using the Basic Encoding Rules [11]. The mechanism
described in RFC2559 (PKIX LDAPv2) [1] is fully compliant with the
;binary option of LDAPv3. The ;binary option of attribute
descriptions MUST be supported by all implementations. When a client
adds, deletes, retrieves or modifies values that are defined to have
the binary syntax defined in RFC 2252 [14], the attribute type name
MUST always be specified with the ;binary attribute option as
described in RFC 2256 [13]. When the server returns such an attribute
in a search result, the attribute type name ?SHOULD/MUST? include the
;binary option. Other attribute description options SHOULD NOT be
generated by clients. Servers MAY choose to support them at their
discretion.
Other parameters of the Search operation for "read" or "search" type
queries will usually be set as specified in RFC 2559.
UTF8 encoding [12] allows the full ISO 10646 character set to be used
in the creation of distinguished names. UTF8 encoding of
distinguished names MUST be supported as specified in RFC2253 [6].
Multiple attribute value assertions (AVAs) within RDN components of
distinguished names MUST be supported and the ordering of the AVAs is
non-deterministic. For example cn=John + uid=123 is the same as
uid=123 + cn=John.
LDAPv3 has the concept of unsolicited notifications that can be sent
from the server to the client. This is used to indicate when the
server is going down, so that a client can distinguish between a
server failure and a network failure. A client MUST be prepared to
accept unsolicited notifications defined in RFC 2251 [4].
The altServer attribute is used by servers to point to alternative
servers that may be contacted if this server is temporarily
unavailable. This attribute MUST be stored in the root DSE of the
server and MUST be available to clients for retrieval. (The access
controls on this attribute MUST be the same or less than those on
certificates and revocation lists.) If no alternative servers exist
this attribute MUST point to the current server. Clients MAY make use
of this feature but do not need to. Servers MAY store any other
operational attributes in the root DSE, but do not need to, except
where mandated in this profile.
If the Certification Practice Statement (CPS) allows unauthenticated
anonymous access to the server, then the server MUST allow a client
to perform a Search operation (for a "read" or "search" type request)
without issuing a prior Bind operation. The server MUST also allow
the client to present a Bind request with the simple authentication
choice and a zero-length OCTET STRING.
3. Features Of Ldapv3 That SHOULD Be Supported
In a distributed directory with multiple servers, LDAPv3 supports
referrals as the mechanism to allow one server that cannot fulfil a
client's request, to refer the client to another server that might be
better able to fulfil the request. Servers SHOULD be able to return
referrals to clients. Clients SHOULD be able to receive referrals,
although they are not required to automatically process them and
support multiple asynchronous outgoing connections. As a minimum,
clients SHOULD be able to ask the user if the referrals are to be
cached locally and added to the set of servers known to the client.
Partial Search results are returned when a server only has a subset
of the certificates requested by the client. Referrals to other
servers are embedded in the SearchResultReference field. Clients and
servers SHOULD be able to handle SearchResultReferences in the same
way as they handle referrals.
However, the returned referrals SHOULD NOT specify new search
filters, attributes to be returned or user credentials. Servers
SHOULD only return the hostport, and DN components and MAY return the
scope component.
4. Features Of Ldapv3 that are Not Used by this Profile
A client following this profile need not send the ModifyDN, Compare
and Abandon operations. The server MAY choose to support these
operations at its discretion. (Note that a client wishing to
abnormally terminate a search request may, instead of issuing an
Abandon operation, close the TCP/IP connection.)
Editors note. Some people have wondered if we should make the Abandon
operation optional for the client and mandatory for the server.
Comments on this issue are requested.
The LDAPv3 protocol is infinitely extensible via two mechanisms:
extended operations and controls on existing operations. The client
does not need to generate any LDAPv3 protocol extensions (extended
operations or controls), unless flexible searching for certificates
is supported (see below). The server SHOULD NOT return any LDAPv3
protocol extensions (extended operations or controls) apart from
supported controls which were marked as critical by the user.
Operational attributes are attributes stored by the server that hold
administrative information. Clients following this profile do not
need any operational attributes from the server, other than the
altServer and subschemaSubentry attributes of the root DSE. The
server need not store any operational attributes other than these in
the root DSE.
5. Features Of Ldapv3 That MAY Be Supported
The default behaviour for LDAPv2 and LDAPv3 servers is that a user
must retrieve all the attribute values from an attribute, or none of
them (subject of course to having access rights to the values). If
the user of the LDAPv3 server wishes to retrieve a limited number of
userCertificates from a user's entry, specifically those that match
certain criteria, then this MAY be achieved by using the LDAPv3
matchedValuesOnly control [15] and the certificateMatch matching
rule. Servers that support flexible matching via the certificateMatch
matching rule SHOULD support the matchedValuesOnly control.
If the CPS allows weak password based authentication for "read" or
"search" access to the server, the client and the server SHOULD
support the DIGEST-MD5 mechanism [7] as specified in [8], and MAY
support a simple password Bind sequence following the negotiation of
a TLS ciphersuite to provide connection confidentiality, as specified
in [10].
If the CPS requires strong authentication for access to the server
then the client and the server SHOULD support certificate based
authentication as specified in [10].
6. Schema Issues
RFC2587 [16] describes some of the subschema applicable to LDAPv2
servers, specifically the public key certificate related attribute
types and object classes that MUST or MAY be supported. RFC2587 is
equally applicable to LDAPv3 servers and MUST be supported by them.
RFC2587 does not describe in detail the matching rules that should be
supported by LDAP servers, nor does it describe how attribute value
assertions for each matching rule should be encoded in filter items
(in fact these AVA encodings are not currently described anywhere).
Finally RFC2587 does not mention attributeCertificates, since these
are a relatively new development.
LDAPv3 allows the subschema supported by a server to be published in
a subschema subentry. Clients following this profile which support
the Search operation containing an extensible matching rule MAY use
the subschemaSubentry attribute in the root DSE to find the
subschemaSubentry, and MAY use the matchingRule and matchingRuleUse
operational attributes in the subschema subentry in order to
determine whether the server supports the various matching rules
described below. Servers which support extensible matching SHOULD
publish the matching rules they support in the matchingRule and
matchingRuleUse operational attributes.
X.509(1997) [9] supports both equality and flexible certificate
matching rules by the server, via the certificateExactMatch and
certificateMatch MATCHING-RULEs respectively. (For example, a client
may flexibly search for certificates with a particular validity time,
key usage, policy or other field.) LDAPv3 servers MUST support the
certificateExactMatch matching rule. Clients MAY support
certificateExactMatch values for equalityMatch filters. LDAPv3
servers MAY support the certificateMatch matching rule. If the server
does support flexible matching (either via certificateMatch or some
other matching rule), then the extensibleMatch filter of the Search
request MUST be supported. Clients MAY support the extensibleMatch
filter and one or more of the optional elements of certificateMatch.
However, neither of the above matching rules are mentioned in the
LDAPv3 standards [13 or 14], and only the equality matching rule is
mentioned in [16], but nowhere is it defined for LDAP servers. It is
expected that future revisions of the LDAPv3 documents will include
these definitions, which are tentatively proposed below.
( 2.5.13.34 NAME 'certificateExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 )
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'Certificate Serial Number and
Issuer' )
Values in this syntax are encoded as an integer, a dollar ($)
separator and a string encoding of the distinguished name of the
issuing CA.
The string description of the certificateMatch matching rule is
proposed here as:
( 2.5.13.35 NAME 'certificateMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.55 )
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.55 DESC 'Certificate Assertion' )
The ASN.1 for certificateAssertion is defined in 12.7.2 of [9]. The
LDAP string encoding of this is t.b.d. (but it will be similar to
userCertificate syntax defined in RFC 1778).
X.509(1997) [9] supports both equality and flexible matching rules of
CRLs by the server, via the certificateListExactMatch and
certificateListMatch MATCHING-RULEs respectively. LDAPv3 servers MUST
(or should it be MAY?) support the certificateListExactMatch matching
rule. Clients MAY support certificateListExactMatch values for
equalityMatch filters. LDAPv3 servers MAY support the
certificateListMatch matching rule. If the server does support
flexible matching (either via certificateListMatch or some other
matching rule), then the extensibleMatch filter of the Search request
MUST be supported. Clients MAY support the extensibleMatch filter and
one or more of the optional elements of certificateListMatch.
Neither of the above matching rules are mentioned in the LDAPv3
standards [13 or 14], and only the certificateListExactMatch matching
rule is mentioned in [16], but nowhere is it defined for LDAP
servers. It is expected that future revisions of the LDAPv3 documents
will include these definitions, which are tentatively proposed below.
( 2.5.13.38 NAME 'certificateListExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.56 )
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.56 DESC 'Issuer name, time and
distribution point name' )
Values in this syntax are encoded as a string encoding of a
distinguished name, a dollar ($) separator, a string representation
of generalised time, a dollar separator and an optional string
encoding of the distinguished name of the distribution point. (Note
that the latter DN encoding for a distribution point name is a subset
of the allowed variants, which can be a generalName or an RDN. Should
this simplification be allowed?)
The string description of the certificateListMatch matching rule is
proposed here as:
( 2.5.13.39 NAME 'certificateListMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.57 )
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.57 DESC 'Certificate List Assertion' )
The ASN.1 for certificateListAssertion is defined in 12.7.6 of [9].
The LDAP string encoding of this is t.b.d.
Editors Notes.
1. We need to decide whether searching for cross certificates should
be supported by this LDAPv3 profile or not. If we decide that this
should be supported, then we will need to define the matching
rules to be supported and the string encodings for the assertion
syntaxes (in fact this is not too difficult since they are similar
to certificate matching rules and AVAs).
2. We need to decide if userSMIMECertificates should also be
supported as part of this profile or not.
LDAPv3 servers MAY store attributeCertificates, and clients MAY
request then to be returned by adding them to the Search Request
AttributeDescriptionList (either explicitly or implicity via
requesting all attributes). LDAPv3 servers MAY support searching for
entries containing specific attribute certificates, via either the
attributeCertificateExactMatch or attributeCertificateMatch matching
rules. For the convenience of the reader, some of the subchema
definitions to support attribute certificates are produced below, but
it is anticipated that these will be moved to a subsequent revision
of the LDAPv3 standard.
attributeCertificate ATTRIBUTE ::= {
WITH SYNTAX AttributeCertificate
EQUALITY MATCHING RULE attributeCertificateExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4)
attributeCertificate(58) }
pmiUser OBJECT-CLASS ::= {
-- a PMI user (i.e., a "claimant")
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN {attributeCertificate}
ID joint-iso-ccitt(2) ds(5) objectClass(6) pmiUser (24)}
attributeCertificateExactMatch MATCHING-RULE ::= {
SYNTAX AttributeCertificateExactAssertion
ID joint-iso-ccitt(2) ds(5) mr (13) attributeCertificateExactMatch
(45) }
AttributeCertificateExactAssertion ::= SEQUENCE {
serialNumber CertificateSerialNumber,
issuer IssuerSerial }
attributeCertificateMatch MATCHING-RULE ::= {
SYNTAX AttributeCertificateAssertion
ID joint-iso-ccitt(2) ds(5) mr (13)
attributeCertificateMatch (??) }
AttributeCertificateAssertion ::= SEQUENCE {
subject [0] CHOICE {
baseCertificateID [0] IssuerSerial,
subjectName [1] GeneralNames} OPTIONAL,
issuer [1] GeneralNames OPTIONAL,
attCertValidity [2] GeneralizedTime OPTIONAL,
attType [3] SET OF AttributeType OPTIONAL}
--At least one component of the sequence must be present
The LDAP definitions and syntaxes for the above matching rules are
suggested to be:
( 2.5.13.45 NAME 'attributeCertificateExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Attribute certificate serial
number and public key issuer and serial number' )
Values in this syntax are encoded as a string encoding of an integer
(the serial number of the attribute certificate), a dollar ($)
separator, a string representation of the distinguished name of the
CA of the issuer (note this is a subset of the allowed GeneralName),
a dollar separator and a string encoding of an integer (the serial
number of the issuer's public key certificate).
The LDAP definition of the attributeCertificateMatch matching rule is
proposed here as:
( 2.5.13.?? NAME 'attributeCertificateMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.59 )
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.59 DESC 'Attribute Certificate
Assertion' )
The LDAP string encoding of this is t.b.d.
7. Security Considerations
The PKI information to be retrieved from LDAPv3 servers (certificates
and CRLs) is digitally signed and therefore additional integrity
services are NOT REQUIRED. The CPS will specify whether the
information should be publicly available or not. If publicly
available, privacy services will NOT be REQUIRED for retrieval
requests. If not publicly available, privacy services MAY be REQUIRED
and these can be provided by a TLS ciphersuite as specified in clause
5.
For update of the information by CAs either strong authentication or
weaker password based authentication MUST be supported as specified
in clause 5. Additional access controls SHOULD be provided.
Organizations are NOT REQUIRED to provide external CAs or users with
access to their directories.
7 Copyright
Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
8. References
[1] S.Boeyen, T. Howes, P. Richard "Internet X.509 Public Key
Infrastructure Operational Protocols - LDAPv2", RFC 2559, April 1999
[2] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
[3] T. Dierks, C. Allen. "The TLS Protocol Version 1.0", RFC 2246,
January 1999.
[4] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", Dec. 1997, RFC 2251
[5] S.Bradner. "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[6] M. Wahl, S. Kille, T. Howes. "Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished Names",
RFC2253, December 1997.
[7] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April
1992
[8] P. Leach, C. Newman, "Using Digest Authentication as a SASL
Mechanism", INTERNET DRAFT <draft-leach-digest-sasl-01.txt>, November
1998.
[9] ITU-T Rec. X.509(97) The Directory: Authentication
Framework
[10] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan.
"Authentication Methods for LDAP" <draft-ietf-ldapext-authmeth-
03.txt>, November 1998
[11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic,
Canonical, and Distinguished Encoding Rules", 1994.
[12] F. Yergeau. "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[13] M.Wahl. "A Summary of the X.500(96) User Schema for use with
LDAPv3" RFC 2256, Dec 1997
[14] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, Dec
1997
[15] D.Chadwick, "Returning Matched Values with LDAPv3", Internet
Draft <draft-ldapext-matchedval-00.txt>, Aug 1999
[16] S.Boeyen, T. Howes, P. Richard "Internet X.509 Public Key
Infrastructure, LDAPv2 Schema", RFC 2587, June 1999
10 Authors Address
David Chadwick
IS Institute
University of Salford
Salford
England
M5 4WT
Email: d.w.chadwick@salford.ac.uk
Internet-Draft PKIX Operational Protocols - LDAPv3 20 August 1999
4