< draft-ietf-pkix-ldap-v3-04.txt   draft-ietf-pkix-ldap-v3-05.txt >
Internet-Draft D.W.Chadwick Internet-Draft D.W.Chadwick
PKIX WG University of Salford PKIX WG University of Salford
Intended Category: Standards Track 20 November 2001 Intended Category: Standards Track 5 January 2002
Expires: 20 April 2002 Expires: 5 July 2002
Internet X.509 Public Key Infrastructure Internet X.509 Public Key Infrastructure
Operational Protocols - LDAPv3 Operational Protocols - LDAPv3
<draft-ietf-pkix-ldap-v3-04.txt> <draft-ietf-pkix-ldap-v3-05.txt>
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all the provisions of Section 10 of RFC2026. all the provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at line 30 skipping to change at line 30
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft expires on 20 April 2002. This Internet-Draft expires on 5 July 2002.
Comments and suggestions on this document are encouraged. Comments on Comments and suggestions on this document are encouraged. Comments on
this document should be sent to the PKIX working group discussion this document should be sent to the PKIX working group discussion
list: list:
<ietf-pkix@imc.org> <ietf-pkix@imc.org>
or directly to the author. or directly to the author.
ABSTRACT ABSTRACT
skipping to change at line 76 skipping to change at line 76
replaced it with the LDAPv3 protocol [4]. However the LDAPv3 protocol replaced it with the LDAPv3 protocol [4]. However the LDAPv3 protocol
is much more complex than the LDAPv2 protocol and many of its is much more complex than the LDAPv2 protocol and many of its
features are not essential for simple PKIX use. This document features are not essential for simple PKIX use. This document
describes the features of LDAPv3 that are essential, or not required, describes the features of LDAPv3 that are essential, or not required,
or are optional for servers to support a PKI based on X.509. or are optional for servers to support a PKI based on X.509.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5]. document are to be interpreted as described in RFC 2119 [5].
2. Features Of Ldapv3 That MUST Be Supported 2. Model
The PKI components, as defined in RFC 2510 [16], which are involved
in PKIX operational protocol interactions include:
- End Entities
- Certification Authorities (CA)
- Repository
End entities and CAs using LDAPv3, retrieve PKI information from the
repository using a subset of the LDAPv3 protocol. Where the
retrieving entity has knowledge of the distinguished name of the LDAP
entry being sought, a "repository read" may be performed. Where the
distinguished name of the LDAP entry is not known, but some other
related information is known, a "repository search" is performed for
candidate entries.
CAs populate the repository with PKI information using a subset of
the LDAPv3 protocol. CAs may add, delete and modify PKI information
in the repository using "repository modify" operations.
3. LDAPv3 Operations
A repository read is performed using an LDAPv3 SearchRequest
operation, where the filter is set to present with an attribute type
of object class, the scope is set to baseObject, and the base object
is set to the distinguished name of the entry.
A repository search is performed for candidate entries using an
LDAPv3 SearchRequest operation where the filter is set to information
related to the LDAP entry being sought, and the base object is set to
the distinguished name of any entry, including null (but is typically
set to the name of an entry superior in the DIT to the entry being
sought). Scope may be set to any of the three values, but is
typically set to wholeSubtree.
BindRequests may or may not be sent prior to SearchRequest operations
(see later).
Repository modifies may be performed using an LDAPv3 AddRequest
operation to add a new entry to the LDAP repository, an LDAPv3
DelRequest to delete an existing entry from the LDAP repository, and
an LDAPv3 ModifyRequest to update the contents of an entry.
Repository modifies must be preceded by BindRequests to provide an
adequate level of authentication (see later).
No other LDAP operations are required by this profile.
4. Features Of Ldapv3 That MUST Be Supported
Attribute descriptions are a superset of attribute type definitions. Attribute descriptions are a superset of attribute type definitions.
They allow attribute subtyping to be specified in the LDAPv3 They allow attribute subtyping to be specified in the LDAPv3
protocol. The ;binary option is an exception to this. This option protocol. The ;binary option is an exception to this. This option
allows certificates and CRLs to be asked for and returned as binary allows certificates and CRLs to be asked for and returned as binary
values encoded using the Basic Encoding Rules [11]. The mechanism values encoded using the Basic Encoding Rules [11]. The mechanism
described in RFC2559 (PKIX LDAPv2) [1] is fully compliant with the described in RFC2559 (PKIX LDAPv2) [1] is fully compliant with the
;binary option of LDAPv3. The ;binary option of attribute ;binary option of LDAPv3. The ;binary option of attribute
descriptions MUST be supported by all implementations. When a client descriptions MUST be supported by all implementations. When a client
adds, deletes, retrieves or modifies attribute values that are adds, deletes, retrieves or modifies attribute values that are
defined in RFC 2256 [13] to be stored and requested in the binary defined in RFC 2256 [13] to be stored and requested in the binary
form, the attribute type name MUST always be specified with the form, the attribute type name MUST always be specified with the
;binary attribute option. When the server returns such an attribute ;binary attribute option. When the server returns such an attribute
in a search result, the attribute type name MUST include the ;binary in a search result, the attribute type name MUST include the ;binary
option. Other attribute description options SHOULD NOT be generated option. Other attribute description options SHOULD NOT be generated
by clients. Servers MAY choose to support them at their discretion. 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 [1].
UTF8 encoding [12] allows the full ISO 10646 character set to be used UTF8 encoding [12] allows the full ISO 10646 character set to be used
in the creation of distinguished names. UTF8 encoding of in the creation of distinguished names. UTF8 encoding of
distinguished names MUST be supported as specified in RFC2253 [6]. distinguished names MUST be supported as specified in RFC2253 [6].
Multiple attribute value assertions (AVAs) within RDN components of Multiple attribute value assertions (AVAs) within RDN components of
distinguished names MUST be supported and the ordering of the AVAs is distinguished names MUST be supported and the ordering of the AVAs is
non-deterministic. For example cn=John + serialNumber=123 is the same non-deterministic. For example cn=John + serialNumber=123 is the same
as serialNumber=123 + cn=John. as serialNumber=123 + cn=John.
LDAPv3 has the concept of unsolicited notifications that can be sent LDAPv3 has the concept of unsolicited notifications that can be sent
skipping to change at line 125 skipping to change at line 170
server and MUST be available to clients for retrieval. (The access server and MUST be available to clients for retrieval. (The access
controls on this attribute MUST be the same or less than those on controls on this attribute MUST be the same or less than those on
certificates and revocation lists.) If no alternative servers exist certificates and revocation lists.) If no alternative servers exist
this attribute MUST point to the current server. Clients MAY make use 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 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 operational attributes in the root DSE, but do not need to, except
where mandated in this or other profiles. where mandated in this or other profiles.
If the Certification Practice Statement (CPS) allows unauthenticated If the Certification Practice Statement (CPS) allows unauthenticated
anonymous access to the server, then the server MUST allow a client anonymous access to the server, then the server MUST allow a client
to perform a Search operation (for a "read" or "search" type request) to perform a SearchRequest operation (for a repository read or
without issuing a prior Bind operation. The server MUST also allow repository search type request) without issuing a prior Bind
the client to present a Bind request with the simple authentication operation. The server MUST also allow the client to present a Bind
choice and a zero-length OCTET STRING. request with the simple authentication choice and a zero-length OCTET
STRING.
If the CPS allows weak password based authentication for "read" or If the CPS allows weak password based authentication for repository
"search" access to the server, the client and the server MUST support read or repository search access to the server, the client and the
the DIGEST-MD5 mechanism [7] as specified in [8] and [10]. server MUST support the DIGEST-MD5 mechanism [7] as specified in [8]
and [10].
3. Features Of Ldapv3 That SHOULD Be Supported 5. Features Of Ldapv3 That SHOULD Be Supported
In a distributed directory with multiple servers, LDAPv3 supports In a distributed directory with multiple servers, LDAPv3 supports
referrals as the mechanism to allow one server that cannot fulfil a 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 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 better able to fulfil the request. Servers SHOULD be able to return
referrals to clients. Clients SHOULD be able to receive referrals and referrals to clients. Clients SHOULD be able to receive referrals and
process them, although they are not required to automatically process process them, although they are not required to automatically process
them and support multiple asynchronous outgoing connections. them and support multiple asynchronous outgoing connections.
Partial Search results are returned when a server only has a subset Partial Search results are returned when a server only has a subset
of the certificates requested by the client. Referrals to other of the certificates requested by the client. Referrals to other
servers are embedded in the SearchResultReference field. Clients and servers are embedded in the SearchResultReference field. Clients and
servers SHOULD be able to handle SearchResultReferences in the same servers SHOULD be able to handle SearchResultReferences in the same
way as they handle referrals. way as they handle referrals.
However, the returned referrals SHOULD NOT specify new search However, the returned referrals SHOULD NOT specify new search
filters, attributes to be returned or user credentials. Servers filters, attributes to be returned or user credentials. Servers
SHOULD only return the hostport and DN components and MAY return the SHOULD only return the hostport and DN components and MAY return the
scope component. scope component.
4. Features Of Ldapv3 that are Not Used by this Profile 6. Features Of Ldapv3 that are Not Used by this Profile
A client following this profile need not send the ModifyDN, Compare A client following this profile need not send the ModifyDN, Compare
and Abandon operations. The server MAY choose to support these and Abandon operations. The server MAY choose to support these
operations at its discretion. (Note that a client wishing to operations at its discretion. (Note that a client wishing to
abnormally terminate a search request may, instead of issuing an abnormally terminate a search request may, instead of issuing an
Abandon operation, close the TCP/IP connection.) Abandon operation, close the TCP/IP connection.)
The LDAPv3 protocol is infinitely extensible via two mechanisms: The LDAPv3 protocol is infinitely extensible via two mechanisms:
extended operations and controls on existing operations. The client extended operations and controls on existing operations. The client
does not need to generate any LDAPv3 protocol extensions (extended does not need to generate any LDAPv3 protocol extensions (extended
operations or controls), unless flexible searching for certificates operations or controls), unless flexible searching for certificates
is supported (see below). The server SHOULD NOT return any LDAPv3 is supported (see below). The server SHOULD NOT return any LDAPv3
protocol extensions (extended operations or controls) apart from protocol extensions (extended operations or controls) apart from
those necessary to support the controls already used by the client. those necessary to support the controls already used by the client.
5. Features Of Ldapv3 That MAY Be Supported 7. Features Of Ldapv3 That MAY Be Supported
The default behaviour for LDAPv3 servers is that a user must retrieve The default behaviour for LDAPv3 servers is that a user must retrieve
all the attribute values from an attribute, or none of them (subject 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 an of course to having access rights to the values). If the user of an
LDAPv3 server wishes to retrieve a limited number of attribute LDAPv3 server wishes to retrieve a limited number of attribute
values, specifically those that match certain filtering criteria, values, specifically those that match certain filtering criteria,
(for example a data encryption userCertificate from a userĘs entry, (for example a data encryption userCertificate from a userĘs entry,
or a revocation list that was current at a particular moment in time) or a revocation list that was current at a particular moment in time)
then this MAY be achieved by using the LDAPv3 valuesReturnFilter then this MAY be achieved by using the LDAPv3 valuesReturnFilter
control [15] along with the certificateExactMatch, certificateMatch, control [15] along with the certificateExactMatch, certificateMatch,
skipping to change at line 195 skipping to change at line 242
If the CPS allows weak password based authentication for "read" or If the CPS allows weak password based authentication for "read" or
"search" access to the server, the client and the server MAY support "search" access to the server, the client and the server MAY support
a simple password Bind sequence following the negotiation of a TLS a simple password Bind sequence following the negotiation of a TLS
ciphersuite to provide connection confidentiality, as specified in ciphersuite to provide connection confidentiality, as specified in
[10]. [10].
If the CPS requires strong authentication for access to the server If the CPS requires strong authentication for access to the server
then the client and the server SHOULD support certificate based then the client and the server SHOULD support certificate based
authentication as specified in [10]. authentication as specified in [10].
6. Security Considerations 8. Security Considerations
The PKI information to be retrieved from LDAPv3 servers (certificates The PKI information to be retrieved from LDAPv3 servers (certificates
and CRLs) is digitally signed and therefore additional integrity and CRLs) is digitally signed and therefore additional integrity
services are NOT REQUIRED. However, clients that retrieve CRLs services are NOT REQUIRED. However, clients that retrieve CRLs
without some way of verifying the server run the risk of being sent a without some way of verifying the server run the risk of being sent a
still current but superceded CRL. still current but superceded CRL.
The CPS will specify whether the information should be publicly The CPS will specify whether the information should be publicly
available or not. If publicly available, privacy services will NOT be available or not. If publicly available, privacy services will NOT be
REQUIRED for retrieval requests. If not publicly available, privacy REQUIRED for retrieval requests. If not publicly available, privacy
services MAY be REQUIRED and these can be provided by a TLS services MAY be REQUIRED and these can be provided by a TLS
ciphersuite as specified in clause 5. ciphersuite as specified in clause 5.
For update of the information by CAs either strong authentication or For update of the information by CAs either strong authentication or
weaker password based authentication MUST be supported as specified weaker password based authentication MUST be supported as specified
in clause 5. Additional access controls SHOULD be provided. in clause 5. Additional access controls SHOULD be provided.
Organizations are NOT REQUIRED to provide external CAs or users with Organizations are NOT REQUIRED to provide external CAs or users with
access to their directories. access to their directories.
7. Copyright 9. Copyright
Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
skipping to change at line 244 skipping to change at line 291
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
8. References 10. References
[1] S.Boeyen, T. Howes, P. Richard "Internet X.509 Public Key [1] S.Boeyen, T. Howes, P. Richard "Internet X.509 Public Key
Infrastructure Operational Protocols - LDAPv2", RFC 2559, April 1999 Infrastructure Operational Protocols - LDAPv2", RFC 2559, April 1999
[2] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access [2] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access
Protocol", RFC 1777, March 1995. Protocol", RFC 1777, March 1995.
[3] T. Dierks, C. Allen. "The TLS Protocol Version 1.0", RFC 2246, [3] T. Dierks, C. Allen. "The TLS Protocol Version 1.0", RFC 2246,
January 1999. January 1999.
[4] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access [4] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", Dec. 1997, RFC 2251 Protocol (v3)", Dec. 1997, RFC 2251
[5] S.Bradner. "Key words for use in RFCs to Indicate Requirement [5] S.Bradner. "Key words for use in RFCs to Indicate Requirement
skipping to change at line 276 skipping to change at line 323
[11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic, [11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic,
Canonical, and Distinguished Encoding Rules", 1994. Canonical, and Distinguished Encoding Rules", 1994.
[12] F. Yergeau. "UTF-8, a transformation format of ISO 10646", RFC [12] F. Yergeau. "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998. 2279, January 1998.
[13] M.Wahl. "A Summary of the X.500(96) User Schema for use with [13] M.Wahl. "A Summary of the X.500(96) User Schema for use with
LDAPv3" RFC 2256, Dec 1997 LDAPv3" RFC 2256, Dec 1997
[14] D.W.Chadwick, S.Legg. "Internet X.509 Public Key Infrastructure [14] D.W.Chadwick, S.Legg. "Internet X.509 Public Key Infrastructure
- LDAP Schema and Syntaxes for PKIs and PMIs", <draft-pkix-ldap- - LDAP Schema and Syntaxes for PKIs and PMIs", <draft-pkix-ldap-
schema-02.txt>, November 2001 schema-02.txt>, November 2001
[15] D.Chadwick, S.Mullan. "Returning Matched Values with LDAPv3", [15] D.Chadwick, S.Mullan. "Returning Matched Values with LDAPv3",
9. Authors Address [16] Adams, C., Farrell, S., "Internet X.509 Public Key
Infrastructure Certificate Management Protocols," RFC 2510, March
1999.
11. Authors Address
David Chadwick David Chadwick
IS Institute IS Institute
University of Salford University of Salford
Salford Salford
England England
M5 4WT M5 4WT
Email: d.w.chadwick@salford.ac.uk Email: d.w.chadwick@salford.ac.uk
10. Changes Made to Version 01 12. Document History
Changes Made to Version 01
i) Schema removed to a separate document i) Schema removed to a separate document
ii) Selecting individual attribute values updated to reflect new ii) Selecting individual attribute values updated to reflect new
LDAP Internet Draft LDAP Internet Draft
iii) Re-wording of text surrounding the use of ;binary option. iii) Re-wording of text surrounding the use of ;binary option.
Changes Made to Version 02 Changes Made to Version 02
i) Added text to Security section about superceded CRLs. i) Added text to Security section about superceded CRLs.
ii) Changed text in section 4 about which controls server can send ii) Changed text in section 4 about which controls server can send
to client to client
iii) Updated references section iii) Updated references section
iv) Added selective retrieving of CRLs to section 5 iv) Added selective retrieving of CRLs to section 5
Changes Made to Version 03 Changes Made to Version 03
i) Updated references only. i) Updated references only.
Changes Made to Version 04
i) Removed reference to RFC 2559 from all but the introduction to
this document and copied relevant text from it into the body of
this document, so that the reader will not need to reference
RFC2559 when implementing this RFC. (Note that not all of
RFC2559 has been copied as some of it has been superseded, and
some of it now seems to be unnecessary e.g. mandating time
limit of zero be supported).
 End of changes. 16 change blocks. 
23 lines changed or deleted 76 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/