idnits 2.17.00 (12 Aug 2021) /tmp/idnits62130/draft-ietf-pkix-ldap-v3-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 382 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (5 January 2002) is 7440 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2559 (ref. '1') (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 1777 (ref. '2') (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2251 (ref. '4') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2253 (ref. '6') (Obsoleted by RFC 4510, RFC 4514) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '7') ** Obsolete normative reference: RFC 2831 (ref. '8') (Obsoleted by RFC 6331) -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 2829 (ref. '10') (Obsoleted by RFC 4510, RFC 4513) -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 2279 (ref. '12') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2256 (ref. '13') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' ** Obsolete normative reference: RFC 2510 (ref. '16') (Obsoleted by RFC 4210) Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft D.W.Chadwick 2 PKIX WG University of Salford 3 Intended Category: Standards Track 5 January 2002 4 Expires: 5 July 2002 6 Internet X.509 Public Key Infrastructure 7 Operational Protocols - LDAPv3 8 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all the provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft expires on 5 July 2002. 32 Comments and suggestions on this document are encouraged. Comments on 33 this document should be sent to the PKIX working group discussion 34 list: 35 37 or directly to the author. 39 ABSTRACT 41 This document describes the features of the Lightweight Directory 42 Access Protocol v3 that are needed in order to support a public key 43 infrastructure based on X.509 certificates and CRLs. 45 1. Introduction 47 RFC 2559 [1] specifies the subset of LDAPv2 [2] that is necessary to 48 retrieve X.509 [9] certificates and CRLs from LDAP servers. However 49 LDAPv2 has a number of deficiencies that may limit its usefulness in 50 certain circumstances. The most notable of these are: 52 - LDAPv2 distinguished names must be composed from the IA5 53 character set and cannot contain accented or non-latin characters, 55 - LDAPv2 only has a limited number of supported authentication 56 schemes for binding to the server, in particular the use of hashed 57 passwords or TLS [3] are not supported, 59 - LDAPv2 only supports a single directory server. It is the 60 responsibility of the user to pre-configure his client with the 61 required set of LDAP servers, and to choose the correct one for each 62 certificate and CRL retrieval. 64 It is for these reasons (and others not listed here) that the IETF 65 have stopped the standardisation of the LDAPv2 protocol and have 66 replaced it with the LDAPv3 protocol [4]. However the LDAPv3 protocol 67 is much more complex than the LDAPv2 protocol and many of its 68 features are not essential for simple PKIX use. This document 69 describes the features of LDAPv3 that are essential, or not required, 70 or are optional for servers to support a PKI based on X.509. 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 [5]. 76 2. Model 78 The PKI components, as defined in RFC 2510 [16], which are involved 79 in PKIX operational protocol interactions include: 81 - End Entities 82 - Certification Authorities (CA) 83 - Repository 85 End entities and CAs using LDAPv3, retrieve PKI information from the 86 repository using a subset of the LDAPv3 protocol. Where the 87 retrieving entity has knowledge of the distinguished name of the LDAP 88 entry being sought, a "repository read" may be performed. Where the 89 distinguished name of the LDAP entry is not known, but some other 90 related information is known, a "repository search" is performed for 91 candidate entries. 93 CAs populate the repository with PKI information using a subset of 94 the LDAPv3 protocol. CAs may add, delete and modify PKI information 95 in the repository using "repository modify" operations. 97 3. LDAPv3 Operations 99 A repository read is performed using an LDAPv3 SearchRequest 100 operation, where the filter is set to present with an attribute type 101 of object class, the scope is set to baseObject, and the base object 102 is set to the distinguished name of the entry. 104 A repository search is performed for candidate entries using an 105 LDAPv3 SearchRequest operation where the filter is set to information 106 related to the LDAP entry being sought, and the base object is set to 107 the distinguished name of any entry, including null (but is typically 108 set to the name of an entry superior in the DIT to the entry being 109 sought). Scope may be set to any of the three values, but is 110 typically set to wholeSubtree. 112 BindRequests may or may not be sent prior to SearchRequest operations 113 (see later). 115 Repository modifies may be performed using an LDAPv3 AddRequest 116 operation to add a new entry to the LDAP repository, an LDAPv3 117 DelRequest to delete an existing entry from the LDAP repository, and 118 an LDAPv3 ModifyRequest to update the contents of an entry. 119 Repository modifies must be preceded by BindRequests to provide an 120 adequate level of authentication (see later). 122 No other LDAP operations are required by this profile. 124 4. Features Of Ldapv3 That MUST Be Supported 126 Attribute descriptions are a superset of attribute type definitions. 127 They allow attribute subtyping to be specified in the LDAPv3 128 protocol. The ;binary option is an exception to this. This option 129 allows certificates and CRLs to be asked for and returned as binary 130 values encoded using the Basic Encoding Rules [11]. The mechanism 131 described in RFC2559 (PKIX LDAPv2) [1] is fully compliant with the 132 ;binary option of LDAPv3. The ;binary option of attribute 133 descriptions MUST be supported by all implementations. When a client 134 adds, deletes, retrieves or modifies attribute values that are 135 defined in RFC 2256 [13] to be stored and requested in the binary 136 form, the attribute type name MUST always be specified with the 137 ;binary attribute option. When the server returns such an attribute 138 in a search result, the attribute type name MUST include the ;binary 139 option. Other attribute description options SHOULD NOT be generated 140 by clients. Servers MAY choose to support them at their discretion. 142 UTF8 encoding [12] allows the full ISO 10646 character set to be used 143 in the creation of distinguished names. UTF8 encoding of 144 distinguished names MUST be supported as specified in RFC2253 [6]. 146 Multiple attribute value assertions (AVAs) within RDN components of 147 distinguished names MUST be supported and the ordering of the AVAs is 148 non-deterministic. For example cn=John + serialNumber=123 is the same 149 as serialNumber=123 + cn=John. 151 LDAPv3 has the concept of unsolicited notifications that can be sent 152 from the server to the client. This is used to indicate when the 153 server is going down, so that a client can distinguish between a 154 server failure and a network failure. A client MUST be prepared to 155 accept unsolicited notifications defined in RFC 2251 [4]. 157 The altServer attribute is used by servers to point to alternative 158 servers that may be contacted if this server is temporarily 159 unavailable. This attribute MUST be stored in the root DSE of the 160 server and MUST be available to clients for retrieval. (The access 161 controls on this attribute MUST be the same or less than those on 162 certificates and revocation lists.) If no alternative servers exist 163 this attribute MUST point to the current server. Clients MAY make use 164 of this feature but do not need to. Servers MAY store any other 165 operational attributes in the root DSE, but do not need to, except 166 where mandated in this or other profiles. 168 If the Certification Practice Statement (CPS) allows unauthenticated 169 anonymous access to the server, then the server MUST allow a client 170 to perform a SearchRequest operation (for a repository read or 171 repository search type request) without issuing a prior Bind 172 operation. The server MUST also allow the client to present a Bind 173 request with the simple authentication choice and a zero-length OCTET 174 STRING. 176 If the CPS allows weak password based authentication for repository 177 read or repository search access to the server, the client and the 178 server MUST support the DIGEST-MD5 mechanism [7] as specified in [8] 179 and [10]. 181 5. Features Of Ldapv3 That SHOULD Be Supported 183 In a distributed directory with multiple servers, LDAPv3 supports 184 referrals as the mechanism to allow one server that cannot fulfil a 185 clientĘs request, to refer the client to another server that might be 186 better able to fulfil the request. Servers SHOULD be able to return 187 referrals to clients. Clients SHOULD be able to receive referrals and 188 process them, although they are not required to automatically process 189 them and support multiple asynchronous outgoing connections. 191 Partial Search results are returned when a server only has a subset 192 of the certificates requested by the client. Referrals to other 193 servers are embedded in the SearchResultReference field. Clients and 194 servers SHOULD be able to handle SearchResultReferences in the same 195 way as they handle referrals. 197 However, the returned referrals SHOULD NOT specify new search 198 filters, attributes to be returned or user credentials. Servers 199 SHOULD only return the hostport and DN components and MAY return the 200 scope component. 202 6. Features Of Ldapv3 that are Not Used by this Profile 204 A client following this profile need not send the ModifyDN, Compare 205 and Abandon operations. The server MAY choose to support these 206 operations at its discretion. (Note that a client wishing to 207 abnormally terminate a search request may, instead of issuing an 208 Abandon operation, close the TCP/IP connection.) 210 The LDAPv3 protocol is infinitely extensible via two mechanisms: 211 extended operations and controls on existing operations. The client 212 does not need to generate any LDAPv3 protocol extensions (extended 213 operations or controls), unless flexible searching for certificates 214 is supported (see below). The server SHOULD NOT return any LDAPv3 215 protocol extensions (extended operations or controls) apart from 216 those necessary to support the controls already used by the client. 218 7. Features Of Ldapv3 That MAY Be Supported 220 The default behaviour for LDAPv3 servers is that a user must retrieve 221 all the attribute values from an attribute, or none of them (subject 222 of course to having access rights to the values). If the user of an 223 LDAPv3 server wishes to retrieve a limited number of attribute 224 values, specifically those that match certain filtering criteria, 225 (for example a data encryption userCertificate from a userĘs entry, 226 or a revocation list that was current at a particular moment in time) 227 then this MAY be achieved by using the LDAPv3 valuesReturnFilter 228 control [15] along with the certificateExactMatch, certificateMatch, 229 certificateListExactMatch or certificateListMatch matching rules 230 [14]. 232 If the CPS allows weak password based authentication for "read" or 233 "search" access to the server, the client and the server MAY support 234 a simple password Bind sequence following the negotiation of a TLS 235 ciphersuite to provide connection confidentiality, as specified in 236 [10]. 238 If the CPS requires strong authentication for access to the server 239 then the client and the server SHOULD support certificate based 240 authentication as specified in [10]. 242 8. Security Considerations 244 The PKI information to be retrieved from LDAPv3 servers (certificates 245 and CRLs) is digitally signed and therefore additional integrity 246 services are NOT REQUIRED. However, clients that retrieve CRLs 247 without some way of verifying the server run the risk of being sent a 248 still current but superceded CRL. 250 The CPS will specify whether the information should be publicly 251 available or not. If publicly available, privacy services will NOT be 252 REQUIRED for retrieval requests. If not publicly available, privacy 253 services MAY be REQUIRED and these can be provided by a TLS 254 ciphersuite as specified in clause 5. 256 For update of the information by CAs either strong authentication or 257 weaker password based authentication MUST be supported as specified 258 in clause 5. Additional access controls SHOULD be provided. 260 Organizations are NOT REQUIRED to provide external CAs or users with 261 access to their directories. 263 9. Copyright 265 Copyright (C) The Internet Society (date). All Rights Reserved. 267 This document and translations of it may be copied and furnished to 268 others, and derivative works that comment on or otherwise explain it 269 or assist in its implementation may be prepared, copied, published 270 and distributed, in whole or in part, without restriction of any 271 kind, provided that the above copyright notice and this paragraph are 272 included on all such copies and derivative works. However, this 273 document itself may not be modified in any way, such as by removing 274 the copyright notice or references to the Internet Society or other 275 Internet organizations, except as needed for the purpose of 276 developing Internet standards in which case the procedures for 277 copyrights defined in the Internet Standards process must be 278 followed, or as required to translate it into languages other than 279 English. 281 The limited permissions granted above are perpetual and will not be 282 revoked by the Internet Society or its successors or assigns. 284 This document and the information contained herein is provided on an 285 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 286 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 287 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 288 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 289 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 291 10. References 293 [1] S.Boeyen, T. Howes, P. Richard "Internet X.509 Public Key 294 Infrastructure Operational Protocols - LDAPv2", RFC 2559, April 1999 295 [2] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access 296 Protocol", RFC 1777, March 1995. 297 [3] T. Dierks, C. Allen. "The TLS Protocol Version 1.0", RFC 2246, 298 January 1999. 299 [4] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 300 Protocol (v3)", Dec. 1997, RFC 2251 301 [5] S.Bradner. "Key words for use in RFCs to Indicate Requirement 302 Levels", RFC 2119, March 1997. 303 [6] M. Wahl, S. Kille, T. Howes. "Lightweight Directory Access 304 Protocol (v3): UTF-8 String Representation of Distinguished Names", 305 RFC2253, December 1997. 306 [7] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 307 1992 308 [8] P. Leach, C. Newman, "Using Digest Authentication as a SASL 309 Mechanism", RFC 2831, May 2000. 310 [9] ITU-T Rec. X.509(97) The Directory: Authentication Framework 311 [10] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. "Authentication 312 Methods for LDAP", RFC 2829, May 2000 313 [11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic, 314 Canonical, and Distinguished Encoding Rules", 1994. 315 [12] F. Yergeau. "UTF-8, a transformation format of ISO 10646", RFC 316 2279, January 1998. 317 [13] M.Wahl. "A Summary of the X.500(96) User Schema for use with 318 LDAPv3" RFC 2256, Dec 1997 319 [14] D.W.Chadwick, S.Legg. "Internet X.509 Public Key Infrastructure 320 - LDAP Schema and Syntaxes for PKIs and PMIs", , November 2001 322 [15] D.Chadwick, S.Mullan. "Returning Matched Values with LDAPv3", 323 [16] Adams, C., Farrell, S., "Internet X.509 Public Key 324 Infrastructure Certificate Management Protocols," RFC 2510, March 325 1999. 327 11. Authors Address 329 David Chadwick 330 IS Institute 331 University of Salford 332 Salford 333 England 334 M5 4WT 336 Email: d.w.chadwick@salford.ac.uk 338 12. Document History 340 Changes Made to Version 01 342 i) Schema removed to a separate document 343 ii) Selecting individual attribute values updated to reflect new 344 LDAP Internet Draft 345 iii) Re-wording of text surrounding the use of ;binary option. 347 Changes Made to Version 02 349 i) Added text to Security section about superceded CRLs. 350 ii) Changed text in section 4 about which controls server can send 351 to client 352 iii) Updated references section 353 iv) Added selective retrieving of CRLs to section 5 355 Changes Made to Version 03 357 i) Updated references only. 359 Changes Made to Version 04 361 i) Removed reference to RFC 2559 from all but the introduction to 362 this document and copied relevant text from it into the body of 363 this document, so that the reader will not need to reference 364 RFC2559 when implementing this RFC. (Note that not all of 365 RFC2559 has been copied as some of it has been superseded, and 366 some of it now seems to be unnecessary e.g. mandating time 367 limit of zero be supported).