idnits 2.17.1 draft-ietf-asid-ldapv3-protocol-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 12) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope ENUMERATED {' ) ** 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.) ** There are 95 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 235: '... cldapUserName LDAPDN OPTIONAL,...' RFC 2119 keyword, line 429: '... referral [3] Referral OPTIONAL,...' RFC 2119 keyword, line 430: '... matchedSubtype [4] AttributeType OPTIONAL }...' RFC 2119 keyword, line 482: '... serviceControls [7] Controls OPTIONAL }...' RFC 2119 keyword, line 493: '... time1 [0] UTCTime OPTIONAL,...' (35 more instances...) == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC1798, but the abstract doesn't seem to directly say this. It does mention RFC1798 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC1777, but the abstract doesn't seem to directly say this. It does mention RFC1777 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 26 has weird spacing: '...listing conta...' == Line 965 has weird spacing: '...eturned actu...' -- 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 (23 February 1996) is 10290 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) -- Missing reference section? '1' on line 1789 looks like a reference -- Missing reference section? '2' on line 1790 looks like a reference -- Missing reference section? '6' on line 1659 looks like a reference -- Missing reference section? '12' on line 1394 looks like a reference -- Missing reference section? '3' on line 1791 looks like a reference -- Missing reference section? '4' on line 1682 looks like a reference -- Missing reference section? '5' on line 1658 looks like a reference -- Missing reference section? '0' on line 1788 looks like a reference -- Missing reference section? '9' on line 1662 looks like a reference -- Missing reference section? '10' on line 1388 looks like a reference -- Missing reference section? 'APPLICATION 0' on line 1559 looks like a reference -- Missing reference section? '7' on line 1660 looks like a reference -- Missing reference section? '14' on line 1400 looks like a reference -- Missing reference section? '13' on line 1397 looks like a reference -- Missing reference section? 'APPLICATION 1' on line 1613 looks like a reference -- Missing reference section? 'APPLICATION 17' on line 1615 looks like a reference -- Missing reference section? 'APPLICATION 2' on line 1619 looks like a reference -- Missing reference section? 'APPLICATION 3' on line 1621 looks like a reference -- Missing reference section? '8' on line 1661 looks like a reference -- Missing reference section? 'APPLICATION 4' on line 1677 looks like a reference -- Missing reference section? 'APPLICATION 18' on line 1687 looks like a reference -- Missing reference section? 'APPLICATION 5' on line 1689 looks like a reference -- Missing reference section? 'APPLICATION 6' on line 1704 looks like a reference -- Missing reference section? 'APPLICATION 7' on line 1713 looks like a reference -- Missing reference section? 'APPLICATION 8' on line 1715 looks like a reference -- Missing reference section? 'APPLICATION 9' on line 1723 looks like a reference -- Missing reference section? 'APPLICATION 10' on line 1725 looks like a reference -- Missing reference section? 'APPLICATION 11' on line 1727 looks like a reference -- Missing reference section? 'APPLICATION 12' on line 1728 looks like a reference -- Missing reference section? 'APPLICATION 13' on line 1734 looks like a reference -- Missing reference section? 'APPLICATION 14' on line 1736 looks like a reference -- Missing reference section? 'APPLICATION 15' on line 1742 looks like a reference -- Missing reference section? 'APPLICATION 16' on line 1744 looks like a reference -- Missing reference section? 'APPLICATION 23' on line 1746 looks like a reference -- Missing reference section? 'APPLICATION 24' on line 1750 looks like a reference -- Missing reference section? '11' on line 1391 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 40 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Wahl 2 INTERNET-DRAFT ISODE Consortium 3 Obsoletes: RFC 1777, RFC 1798 T. Howes 4 University of Michigan 5 S. Kille 6 ISODE Consortium 7 Expires in six months from 23 February 1996 8 Intended Category: Standards Track 10 Lightweight Directory Access Protocol (v3) 11 13 1. Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, and 17 its working groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 28 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 30 2. Abstract 32 The protocol described in this document is designed to provide access 33 to X.500 Directories while not incurring the resource requirements 34 of the Directory Access Protocol (DAP). This protocol is specifically 35 targeted at management applications and browser applications that 36 provide read/write interactive access to the X.500 Directory, and 37 is intended to be a complement to the DAP itself. 39 Key aspects of this version of LDAP are: 41 - All protocol elements of LDAP (RFC 1777) and CLDAP (RFC 1798) are 42 supported. 44 - Protocol elements are carried directly over TCP or other transport, 45 bypassing much of the session/presentation overhead. Connectionless 46 transport (UDP) is also supported for efficient lookup operations. 48 - If desired, many protocol data elements can be encoded as ordinary 49 strings (e.g., Distinguished Names). 51 - Important parameters of X.500(1993) DAP can be used. 53 - Referrals to other servers may be returned. 55 - The protocol may be extended to support bilaterally-defined 56 operations. 58 - Several of the service controls may be requested by the client. 60 3. Models 62 Interest in X.500 [1] technology in the Internet has lead to 63 efforts to reduce the high "cost of entry" associated with use of the 64 technology. This document continues the efforts to define Directory 65 protocol alternatives: it builds heavily on the LDAP [2] protocol 66 specification, and allows support for additional X.500(1993) features. 68 3.1. Protocol Model 70 The general model adopted by this protocol is one of clients 71 performing protocol operations against servers. In this model, this 72 is accomplished by a client transmitting a protocol request 73 describing the operation to be performed to a server, which is then 74 responsible for performing the necessary operations on the Directory. 75 Upon completion of the necessary operations, the server returns a 76 response containing any results or errors to the requesting client. 77 In keeping with the goal of easing the costs associated with use of 78 the Directory, it is an objective of this protocol to minimize the 79 complexity of clients so as to facilitate widespread deployment of 80 applications capable of utilizing the Directory. 82 Note that, although servers are required to return responses whenever 83 such responses are defined in the protocol, there is no requirement 84 for synchronous behavior on the part of either client or server 85 implementations: requests and responses for multiple operations may 86 be exchanged by client and servers in any order, as long as clients 87 eventually receive a response for every request that requires one. 89 In LDAP versions 1 and 2, no provision was made for protocol servers 90 returning referrals to clients. However, for improved performance and 91 distribution this version of the protocol permits servers to return to 92 clients referrals to other servers if requested. 93 Clients may also request that no referrals be returned, in 94 which case the server must ensure that the operation is performed 95 against the Directory, or else return an error. 97 Note that this protocol can be mapped to a strict subset of the 98 directory abstract service, so it can be cleanly provided by the DAP. 99 However there is not a one-to-one mapping between LDAP protocol 100 operations and DAP operations: some server implementations may need to 101 make multiple DAP requests to perform extended operations. 103 3.2. Data Model 105 This section provides a brief introduction to the X.500 data model, as 106 used by LDAP. Schema rules and other features are not described here. 108 The LDAP protocol assumes there is one or more servers which jointly 109 provide access to a Directory Information Tree. The tree is made up of 110 entries. Entries have names: one or more values from the entry itself 111 form its relative distinguished name, which must be unique among all 112 its siblings. The concatenation of the relative distinguished names 113 of entries, starting from the immediate subordinate of the unnamed 114 root of the tree and continuing to a specific entry form's that entry's 115 Distinguished Name, which is unique in the tree. An example of a 116 Distinguished Name is 117 119 Entries consist of a set of attributes. An attribute is a type with 120 one or more values associated with that type. The attribute type is 121 an OID (object identifier) which governs the maximum number of values 122 permissible for that type in an entry, and the syntax to which the 123 values must conform. 124 An example of an attribute type is "rfc822Mailbox": the values of this 125 attribute must be IA5 strings. 127 All the attributes of an entry are mastered together in a single 128 server. Shadow or cached copies of entries may be held in other 129 servers, but these cannot be updated directly by users. 131 3.3. Relationship to X.500 133 This document defines LDAP in terms of X.500 as an X.500 access 134 mechanism. An LDAP server should act in accordance with the 135 X.500(1993) series of ITU Recommendations when providing the service. 136 However, it is not required that an LDAP server make use of any X.500 137 protocols in providing this service: e.g. LDAP can be mapped onto any 138 other Directory system so long as the X.500 data and service model is 139 supported in the LDAP interface. 141 3.4. Additional server data requirements 143 An LDAP server must provide a number of attributes in the root DSE, 144 that which is named with the zero-length LDAPDN. These attributes 145 should be retrievable if a client performs a base object search of the 146 root. They should not be included if the client performs a subtree 147 search starting from the root. The server need not allow the client 148 to modify these attributes. 150 The attributes are as follows: 152 - administratorAddress 153 This attribute's value is a string containing the RFC 822 address 154 of the LDAP server's human administrator. This information may be of 155 use when tracking down problems in a distributed directory. 157 - currentTime 158 This attribute's value is a string containing a UTCTime character 159 value. This attribute need only be present if the server supports 160 strong or protected simple authentication. Otherwise if the server 161 does not know the current time this attribute should not be present. 162 The client may wish to use this field to detect whether a strong or 163 protected bind would fail because the client and server clocks are 164 not sufficiently synchronized. Clients should not use this time field 165 for setting their own system clock. 167 - binaryName 168 This attribute's value is the binary ASN.1 encoding of the server's 169 Distinguished Name. If the server does not have a Distinguished Name 170 it will not be able to accept strong authentication, and this attribute 171 should be absent. 173 - path 174 This attribute contains a binary encoding of the AF.CertificationPath 175 data type, with the certificate path for the server. If the server 176 does not have a certificate path this attribute should be absent. 178 - context 179 The values of this attribute are the string representations of 180 Distinguished Names. Each value corresponds to a naming context which 181 this server masters or shadows. If the server does not master any 182 information (e.g. it is an LDAP gateway to a public X.500 Directory) 183 this attribute should be absent. If the server believes it contains 184 the entire Directory, the attribute should have a single value, and 185 that value should be the empty string (indicating the null DN of the 186 root). 188 - altLdapServer 189 The values of this attribute are URLs of other LDAP servers which 190 may be contacted when this server becomes unavailable. If the server 191 does not know of any other LDAP servers which could be used this 192 attribute should be absent. Clients should cache this information in 193 case their preferred LDAP server later becomes unavailable. 195 - altX500Server 196 The values of this attribute are encoded with the AccessPoint93 197 syntax. They are the access points of X.500 DSAs which could be 198 contacted when this server becomes unavailable. If this server does 199 not know of any X.500 DSAs this attribute should be absent. Clients 200 which support DAP should cache this information in case their 201 preferred LDAP server later becomes unavailable. 203 - supportedExtension 204 The values of this attribute are the string representations of 205 OBJECT IDENTIFIERs, in the dotted decimal form. Each value is the 206 name of an extended request which this server supports (see section 207 4.11). If the server does not support any extended operations this 208 attribute should be absent. 210 The ASN.1 type DistinguishedName is defined in [6], and the type 211 CertificationPath is defined in [12]. They are included in Appendix B 212 for reference. 214 4. Elements of Protocol 216 The LDAP protocol is described using Abstract Syntax Notation 1 [3]. It 217 is typically transferred using a subset of the Basic Encoding Rules. 218 In order to support future extensions to this protocol, clients and 219 servers should ignore elements of SEQUENCEs whose tags they do not 220 recognize. 222 4.1. Common Elements 224 This section describes the LDAPMessage envelope PDU format, as well as 225 data type definitions which are used in the protocol operations. 227 4.1.1. Message Envelope 229 For the purposes of protocol exchanges, all protocol operations are 230 encapsulated in a common envelope, the LDAPMessage, which is defined 231 as follows: 233 LDAPMessage ::= SEQUENCE { 234 messageID MessageID, 235 cldapUserName LDAPDN OPTIONAL, 236 protocolOp CHOICE { 237 bindRequest BindRequest, 238 bindRespBasic BindResponseBasic, 239 bindRespExtd BindResponseExtended, 240 unbindRequest UnbindRequest, 241 searchRequest SearchRequest, 242 searchResEntry SearchResultEntry, 243 searchResDone SearchResultDone, 244 searchResRef SearchResultReference, 245 searchResFull SearchResultFull, 246 modifyRequest ModifyRequest, 247 modifyResponse ModifyResponse, 248 addRequest AddRequest, 249 addResponse AddResponse, 250 delRequest DelRequest, 251 delResponse DelResponse, 252 modDNRequest ModifyDNRequest, 253 modDNResponse ModifyDNResponse, 254 compareRequest CompareRequest, 255 compareResponse CompareResponse, 256 abandonRequest AbandonRequest, 257 extendedReq ExtendedRequest, 258 extendedResp ExtendedResponse } } 260 MessageID ::= INTEGER (0 .. maxInt ) 262 maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- 263 -- later may be extended to 9223372036854775807 (2^^63 - 1) -- 265 The function of the LDAPMessage is to provide an envelope containing 266 common fields required in all protocol exchanges. At this time the 267 only common fields are the message ID and cldapUserName. 269 The message ID is required to have a value different from the values of 270 any other requests outstanding in the LDAP session of which this 271 message is a part. Typically a client may increment a counter for each 272 request. The message ID value must be echoed in all LDAPMessage 273 envelopes encapsulating responses corresponding to the request 274 contained in the LDAPMessage in which the message ID value was 275 originally used. 277 The cldapUserName identifies the requesting user for this message. It 278 is only present if this LDAPMessage is carried in a connectionless 279 transport protocol, such as UDP. This is described in section 5.1.3. 280 When the LDAP session is carried in a connection-oriented transport 281 protocol this field must be absent. 283 4.1.2. String 285 The LDAPString is a notational convenience to indicate that, although 286 strings of LDAPString type encode as OCTET STRING types, the legal 287 character set in such strings is limited to the IA5 character set. 289 LDAPString ::= OCTET STRING 291 4.1.3. Distinguished Name and Relative Distinguished Name 293 An LDAPDN and a RelativeLDAPDN are respectively defined to be the 294 representation of a Distinguished Name and a Relative Distinguished 295 Name after encoding according to the specification in [4], such that 297 ::= 299 ::= 301 where and are as defined in [4]. 303 LDAPDN ::= LDAPString 305 RelativeLDAPDN ::= LDAPString 307 4.1.4. Attribute Type 309 An AttributeType takes on as its value the textual string associated 310 with that AttributeType in its specification. If this string is not 311 known, the AttributeType should take the ASCII representation of its 312 OBJECT IDENTIFIER, as decimal digits with components separated by 313 periods, e.g. "2.5.4.10". The attribute type strings which must be 314 supported are described in section [5]. 316 AttributeType ::= LDAPString 318 This data type describes a list of 0 or more attribute types. Clients 319 and servers should be prepared to accept a list of many hundreds of 320 attribute types. 322 AttributeTypeList ::= SEQUENCE SIZE (0..maxInt) OF AttributeType 323 4.1.5. Attribute Value 325 A field of type AttributeValue takes on as its value an octet string 326 encoding of a Directory AttributeValue type. The definition of these 327 string encodings for different Directory AttributeValue types may be 328 found in companions to this document that define the encodings of 329 various attribute syntaxes such as [5]. 331 AttributeValue ::= OCTET STRING 333 Note that there is no defined limit on the size of this encoding; thus 334 PDUs including multi-megabyte photograph attributes may be returned. If 335 the client has limited memory or storage capabilities it may wish to 336 set the attrSizeLimit field when invoking a search operation. 338 4.1.6. Attribute Value Assertion 340 The AttributeValueAssertion type definition is similar to the one in 341 the X.500 Directory standards. It contains an attribute type and a 342 equality matching assertion suitable for that type. 344 AttributeValueAssertion ::= SEQUENCE { 345 attributeType AttributeType, 346 assertionValue AssertionValue } 348 AssertionValue ::= OCTET STRING 350 For all the standard attributes, the assertion value syntax is the 351 same as the value syntax. 353 4.1.7. Attribute 355 An attribute consists of a type and one or more values of that type. 357 Attribute ::= SEQUENCE { 358 type AttributeType, 359 vals SET SIZE (1..maxInt) OF AttributeValue } 361 Clients and servers should be prepared to accept attributes with 362 many hundreds of values. 364 4.1.8. Matching Rule Identifier 366 An X.501(1993) Matching Rule is identified in the LDAP protocol by the 367 ASCII representation of its OBJECT IDENTIFIER, as decimal digits with 368 components separated by periods, e.g. "1.3.6.1.4.1.453.33.33". 370 MatchingRuleId ::= LDAPString 372 4.1.9. Result Message 374 The LDAPResult is the construct used in this protocol to return 375 success or failure indications from servers to clients. In response 376 to various requests, servers will return responses containing fields 377 of type LDAPResult to indicate the final status of a protocol 378 operation request. 380 LDAPResult ::= SEQUENCE { 381 resultCode ENUMERATED { 382 success (0), 383 operationsError (1), 384 protocolError (2), 385 timeLimitExceeded (3), 386 sizeLimitExceeded (4), 387 compareFalse (5), 388 compareTrue (6), 389 authMethodNotSupported (7), 390 strongAuthRequired (8), 391 -- 9 reserved -- 392 referral (10), -- new 393 adminLimitExceeded (11), -- new 394 unavailableCriticalExtension (12), -- new 395 -- 14-15 unused -- 396 noSuchAttribute (16), 397 undefinedAttributeType (17), 398 inappropriateMatching (18), 399 constraintViolation (19), 400 attributeOrValueExists (20), 401 invalidAttributeSyntax (21), 402 -- 22-31 unused -- 403 noSuchObject (32), 404 aliasProblem (33), 405 invalidDNSyntax (34), 406 isLeaf (35), 407 aliasDereferencingProblem (36), 408 -- 37-47 unused -- 409 inappropriateAuthentication (48), 410 invalidCredentials (49), 411 insufficientAccessRights (50), 412 busy (51), 413 unavailable (52), 414 unwillingToPerform (53), 415 loopDetect (54), 416 -- 55-63 unused -- 417 namingViolation (64), 418 objectClassViolation (65), 419 notAllowedOnNonLeaf (66), 420 notAllowedOnRDN (67), 421 entryAlreadyExists (68), 422 objectClassModsProhibited (69), 423 resultsTooLarge (70), -- cl only 424 affectsMultipleDSAs (71), -- new 425 -- 72-79 unused -- 426 other (80) }, 427 matchedDN LDAPDN, 428 errorMessage LDAPString (SIZE (0..maxInt)), 429 referral [3] Referral OPTIONAL, 430 matchedSubtype [4] AttributeType OPTIONAL } 431 The errorMessage field of this construct may, at the servers option, 432 be used to return an ASCII string containing a textual, human-readable 433 error diagnostic. As this error diagnostic is not standardized, 434 implementations should not rely on the values returned. If the server 435 chooses not to return a textual diagnostic, the errorMessage field of 436 the LDAPResult type should contain a zero length string. 438 For resultCodes of noSuchObject, aliasProblem, invalidDNSyntax, 439 isLeaf, and aliasDereferencingProblem, the matchedDN field is set to 440 the name of the lowest entry (object or alias) in the DIT that was 441 matched and is a truncated form of the name provided or, if an alias 442 has been dereferenced, of the resulting name in a Search or Compare 443 result. The matchedDN field should be set to a NULL DN (a zero length 444 string) in all other cases. 446 When the resultCode is compareTrue or compareFalse the matchedSubtype 447 field will contain the type name of the attribute whose value matched 448 the ava in the Compare operation. 450 4.1.10. Referral 452 The referral field is present in an LDAPResult if the 453 LDAPResult.resultCode field value is referral. It contains a reference 454 to another server (or set of servers) which may be accessed via LDAP 455 or other protocols. 457 Referral ::= SEQUENCE { 458 servers [0] SET SIZE (1..maxInt) OF LDAPURL } 460 The servers field contains a list of URLs of servers, and each must be 461 capable of processing the operation and presenting a consistent view 462 to clients. URLs for servers implementing the LDAP protocol are 463 written according to [9]. 465 LDAPURL ::= LDAPString 467 The ASN.1 type Exclusions is defined in [10], and is included in 468 Appendix B for reference. The server should place its own URL in the 469 referringServer field, as this information may be useful for tracing 470 referral loops and inconsistencies. 472 4.2. Bind Operation 474 The function of the Bind Operation is to initiate a protocol session 475 between a client and a server, and to allow the authentication of the 476 client to the server. The Bind Request is defined as follows: 478 BindRequest ::= [APPLICATION 0] SEQUENCE { 479 version INTEGER (1 .. 127), 480 name LDAPDN, 481 authentication AuthenticationChoice, 482 serviceControls [7] Controls OPTIONAL } 484 AuthenticationChoice ::= CHOICE { 485 simple [1] OCTET STRING, 486 krbv42LDAP [2] OCTET STRING, 487 krbv42DSA [3] OCTET STRING, 488 protected [4] ProtectedPassword, 489 strong [5] StrongCredentials, 490 nonstandard [6] NonstandardCredentials } 492 ProtectedPassword ::= SEQUENCE { 493 time1 [0] UTCTime OPTIONAL, 494 time2 [1] UTCTime OPTIONAL, 495 random1 [2] BIT STRING OPTIONAL, 496 random2 [3] BIT STRING OPTIONAL, 497 protected [4] OCTET STRING } 499 StrongCredentials ::= SEQUENCE { 500 certification-path [0] AF.CertificationPath OPTIONAL, 501 bind-token [1] DAS.Token } 503 NonstandardCredentials ::= SEQUENCE { 504 authMechanism [0] LDAPString, 505 authToken [1] OCTET STRING } 507 Controls ::= SEQUENCE SIZE (1..maxInt) OF SEQUENCE { 508 criticality [0] BOOLEAN DEFAULT FALSE, 509 control ServiceControl } 511 ServiceControl ::= CHOICE { 512 referringServer [0] LDAPURL, 513 chainingProhibited [1] BOOLEAN, 514 scopeOfReferral [2] ENUMERATED { 515 any(-1), 516 dmd(0), 517 country(1) }, 518 referToLDAPServers [3] BOOLEAN, 519 referToDAPServers [4] BOOLEAN, 520 preferredSyntax [5] SyntaxEncoding, 521 extendedControl [6] ExtendedControl } 523 SyntaxEncoding ::= SEQUENCE { 524 attributeType [0] AttributeType, 525 encodingPreference [1] SyntaxName } 527 SyntaxName ::= LDAPString 529 ExtendedControl ::= SEQUENCE { 530 controlName [0] LDAPString, 531 controlValue [1] OCTET STRING } 532 Parameters of the Bind Request are: 534 - version: A version number indicating the version of the protocol to 535 be used in this protocol session. This document describes version 536 3 of the LDAP protocol. Note that there is no version negotiation, 537 and the client should just set this parameter to the version it 538 desires. The client may request version 2, in which case the server 539 should implement only the protocol as described in [2], by NOT 540 returning: 541 - BindResponseExtended in response to this request, 542 - result codes referral, adminLimitExceeded, 543 unavailableCriticalExtension, 544 resultsTooLarge or affectsMultipleDSAs, 545 - referral or matchedSubtype in LDAPResult, 546 - fromEntry in SearchResultEntry, 547 - SearchResultReference in response to searches. 549 - name: The name of the Directory object that the client wishes to 550 bind as. This field may take on a null value (a zero length 551 string) for the purposes of anonymous binds. 553 - authentication: information used to authenticate the name, if any, 554 provided in the Bind Request. 556 - serviceControls: additional requests the client may make about the 557 protocol. 559 Upon receipt of a Bind Request, a protocol server will authenticate 560 the requesting client if necessary, and attempt to set up a protocol 561 session with that client. The server will then return a Bind Response 562 to the client indicating the status of the session setup request. 564 Unlike LDAP v2, the client need not send a Bind Request in the first 565 PDU of the connection. The client may request any operations and the 566 server should treat these as unauthenticated. If the server requires 567 that the client bind first, the server should reject any request other 568 that binding or unbinding with the "operationsError" result. If the 569 client did not bind before sending a request and receives an 570 operationsError, it should close the connection, reopen it and begin 571 again by first sending a PDU with a Bind Request. This will aid in 572 interoperating with LDAPv2 servers. 574 Clients should not send more than one Bind Request on a connection. 576 4.2.1 Authentication 578 The "simple" authentication option provides minimal authentication 579 facilities, with the contents of the authentication field consisting 580 only of a cleartext password. This option should also be used when 581 unauthenticated or anonymous binds are to be performed, with the field 582 containing a zero length string in such cases. 584 Kerberos version 4 [14] authentication to the LDAP server and the DSA 585 is accomplished by using the krbv42LDAP and krbv42DSA authentication 586 options, respectively. Note that though they are referred to as 587 separate entities here, there is no requirement these two entities be 588 distinct (i.e., a DSA could speak LDAP directly). Two separate 589 authentication options are provided to support all implementations. 590 Each octet string should contain the kerberos ticket (e.g., as 591 returned by krb_mk_req()) for the appropriate service. The suggested 592 service name for authentication to the LDAP server is "ldapserver". 593 The suggested service name for authentication to the DSA is "x500dsa". 594 In both cases, the suggested instance name for the service is the name 595 of the host on which the service is running. Of course, the actual 596 service names and instances will depend on what is entered in the 597 local kerberos principle database. 599 The ProtectedPassword authentication option allows a hash of the 600 password, combined optionally with the current time and a random 601 number, to be sent to the DSA. The protected field contains the hash 602 value. 604 Strong authentication to the Directory can be accomplished using the 605 strong credentials option. The ASN.1 type "CertificationPath" is 606 defined in [12], and the ASN.1 type "Token" is defined in [13]. They 607 are included in Appendix B for Reference. 609 Nonstandard authentication to the Directory can be performed using the 610 nonstandard credentials option. The authMechanism must be the 611 dotted-decimal printable representation of an OBJECT IDENTIFIER of that 612 authentication mechanism: for interoperability the full decimal format 613 must be used. The authToken is arbitrary information of a form 614 defined by that authentication mechanism, encoded in an OCTET STRING. 616 4.2.1.1. Strong Credentials Signature Algorithm 618 It is recommended for interoperability that if strong authentication 619 is to be performed, then if the server's or client's certificates 620 contain RSA public keys the PKCS md5WithRSAEncryption 621 (1.2.840.113549.1.1.4) algorithm should be used. 623 4.2.2. Service Controls 625 Service Controls are requests made by the client which affect its 626 interaction with the server. Controls are not saved after a session 627 unbinds or disconnects abruptly, and do not affect other sessions to 628 this or other servers. 630 If the server is not capable of setting one or more requested controls, 631 it should set as many as possible. If any of the controls which the 632 server could not set are marked as critical, it should return the 633 unavailableCriticalExtension error. 635 The referringServer control is non-critical. This field contains the URL 636 of another server which referred an operation to this server. This control 637 should only be present if the connection is being made only to process a 638 referral. If the connection will be held open to handle referrals from 639 other servers this control should be omitted. 641 If the chainingProhibited field is set to TRUE, the server set the 642 chainingProhibited service control on any DAP requests it makes. If 643 the referToLDAPServers or returnToDAPServers fields are set to TRUE, 644 the server should return referrals to clients. Otherwise if neither 645 of these are set to TRUE the server should itself follow referrals. 647 If the referToLDAPServers field is set to TRUE, the server is permitted 648 by the client to return referrals to other LDAP servers. 650 If the referToDAPServers field is set to TRUE, the server is permitted 651 by the client to return referrals to other X.500 servers which accept 652 incoming DAP associations. 654 The preferredSyntax fields control how the server should in Search 655 Responses return values of attributes, and how it should interpret 656 values presented in Compare, Add and Modify arguments. The attribute 657 field is the attribute whose syntax preference is being noted, if the 658 field is a zero length string the preference applies to all attributes. 659 The following encodingPref values have been defined: 660 - The zero-length empty string corresponds to the default syntax for 661 the server. It may be binary, readable or something else for each 662 attribute. 664 - The string "binary" requests that the binary BER encoding be used for 665 the selected (or all) attributes. Note that Attribute Types, as 666 well as distinguished names transferred as protocol elements (not as 667 attribute values) are still carried in string representations. 669 - The string "readable" requests that printable encodings be used for 670 the selected attributes, and that IA5 character sets be used where 671 possible. If the attribute field is of zero length this requests the 672 server to encode unrecognized attributes using the "Readable" 673 default encoding. 675 Subsequent documents may define additional encoding preference values 676 to support internationalization. 678 The extendedControl is used to exchange bilaterally-defined information 679 from a client to a server. The controlName must be the dotted-decimal 680 printable representation of an OBJECT IDENTIFIER of that control: for 681 interoperability the full decimal format must be used. The 682 controlValue is arbitrary information of a form defined by that 683 control, encoded in an OCTET STRING. 685 4.2.3. Bind Response 687 The Bind Response will be one of the following, either 688 BindResponseBasic or BindResponseExtended. 690 BindResponseBasic ::= [APPLICATION 1] LDAPResult 692 A BindResponseBasic consists simply of an indication from the server of 693 the status of the client's request for the initiation of a protocol 694 session. If the bind was successful, the resultCode will be success, 695 otherwise it will be one of: 697 operationsError 698 protocolError 699 authMethodNotSupported 700 strongAuthRequired 701 referral 702 inappropriateAuthentication 703 invalidCredentials 704 unavailable 706 If the client receives a BindResponseBasic response where the 707 resultCode was not success, it should close the connection as the 708 server will be unwilling to accept further operations. 710 A BindResponseExtended will only be returned if the bind was successful 711 and additional information is to be returned to the client. 713 BindResponseExtended ::= [APPLICATION 17] SEQUENCE { 714 serverURL [0] LDAPURL, 715 serverCreds AuthenticationChoice } 717 The serverURL contains the URL of this LDAP server. The serverCreds 718 allows the client to authenticate the server to which it is 719 communicating. 721 4.3. Unbind Operation 723 The function of the Unbind Operation is to terminate a protocol 724 session. The Unbind Operation is defined as follows: 726 UnbindRequest ::= [APPLICATION 2] NULL 728 The Unbind Operation has no response defined. Upon transmission of an 729 UnbindRequest, a protocol client may assume that the protocol session 730 is terminated. Upon receipt of an UnbindRequest, a protocol server 731 may assume that the requesting client has terminated the session and 732 that all outstanding requests may be discarded. 734 4.4. Search Operation 736 The Search Operation allows a client to request that a search be 737 performed on its behalf by a server. The Search Request is defined as 738 follows: 740 SearchRequest ::= [APPLICATION 3] SEQUENCE { 741 baseObject LDAPDN, 742 scope ENUMERATED { 743 baseObject (0), 744 singleLevel (1), 745 wholeSubtree (2) }, 746 derefAliases ENUMERATED { 747 neverDerefAliases (0), 748 derefInSearching (1), 749 derefFindingBaseObj (2), 750 derefAlways (3) }, 751 sizeLimit INTEGER (0 .. maxInt), 752 timeLimit INTEGER (0 .. maxInt), 753 typesOnly BOOLEAN, 754 filter Filter, 755 attributes AttributeTypeList, 756 matchedOnly [0] BOOLEAN DEFAULT FALSE, 757 sortKeys [1] SortKeyList OPTIONAL, 758 reverseSort [2] BOOLEAN DEFAULT FALSE, 759 modifyRightsReq [3] BOOLEAN DEFAULT FALSE, 760 extraAttributes [4] BOOLEAN DEFAULT FALSE, 761 attrSizeLimit [5] INTEGER OPTIONAL, 762 subentries [6] BOOLEAN DEFAULT FALSE, 763 dontUseCopy [7] BOOLEAN DEFAULT FALSE } 765 SortKeyList ::= SEQUENCE SIZE (1..maxInt) OF SEQUENCE { 766 attributeType AttributeType, 767 orderingRule [0] MatchingRuleId OPTIONAL, 768 startFrom [1] AssertionValue OPTIONAL, 769 endWith [2] AssertionValue OPTIONAL } 771 Filter ::= CHOICE { 772 and [0] SET SIZE (1..maxInt) OF Filter, 773 or [1] SET SIZE (1..maxInt) OF Filter, 774 not [2] Filter, 775 equalityMatch [3] AttributeValueAssertion, 776 substrings [4] SubstringFilter, 777 greaterOrEqual [5] AttributeValueAssertion, 778 lessOrEqual [6] AttributeValueAssertion, 779 present [7] AttributeType, 780 approxMatch [8] AttributeValueAssertion, 781 extensibleMatch [9] MatchingRuleAssertion } 783 SubstringFilter ::= SEQUENCE { 784 type AttributeType, 785 substrings SEQUENCE SIZE (1..maxInt) OF CHOICE { 786 initial [0] LDAPString, 787 any [1] LDAPString, 788 final [2] LDAPString } } 790 MatchingRuleAssertion ::= SEQUENCE { 791 matchingRules [1] SET SIZE (0..maxInt) OF MatchingRuleId, 792 type [2] AttributeType, 793 matchValue [3] AssertionValue, 794 dnAttributes [4] BOOLEAN } 796 Parameters of the Search Request are: 798 - baseObject: An LDAPDN that is the base object entry relative to 799 which the search is to be performed. 801 - scope: An indicator of the scope of the search to be performed. The 802 semantics of the possible values of this field are identical to the 803 semantics of the scope field in the Directory Search Operation. 805 - derefAliases: An indicator as to how alias objects should be 806 handled in searching. The semantics of the possible values of 807 this field are: 809 neverDerefAliases: do not dereference aliases in searching 810 or in locating the base object of the search; 812 derefInSearching: dereference aliases in subordinates of 813 the base object in searching, but not in locating the 814 base object of the search; 816 derefFindingBaseObject: dereference aliases in locating 817 the base object of the search, but not when searching 818 subordinates of the base object; 820 derefAlways: dereference aliases both in searching and in 821 locating the base object of the search. 823 - sizelimit: A sizelimit that restricts the maximum number of entries 824 to be returned as a result of the search. A value of 0 in this 825 field indicates that no sizelimit restrictions are in effect for 826 the search. 828 - timelimit: A timelimit that restricts the maximum time (in seconds) 829 allowed for a search. A value of 0 in this field indicates that no 830 timelimit restrictions are in effect for the search. 832 - typesOnly: An indicator as to whether search results should contain 833 both attribute types and values, or just attribute types. Setting 834 this field to TRUE causes only attribute types (no values) to be 835 returned. Setting this field to FALSE causes both attribute types 836 and values to be returned. 838 - filter: A filter that defines the conditions that must be fulfilled 839 in order for the search to match a given entry. The and, or and not 840 choices may be used to form boolean combinations of filters. 842 - attributes: A list of the attributes from each entry found as a 843 result of the search to be returned. An empty list signifies that 844 all attributes from each entry found in the search are to be 845 returned. 847 - matchedOnly: If this field is set to TRUE, then in search results if 848 there are multivalued attributes where some but not all of the values 849 contributed to the search filter returning TRUE via filters other 850 than equality or present, then the values which did not contribute 851 are not returned in the entry attribute list. 853 - sortKeys: If this field is present, then it specifies one or more 854 attribute types and matching rules, and the returned entries should 855 be sorted in order based on these types. 857 The startFrom and endWith assertion values specify a range of entries 858 which are to be returned. If an entry matches a specified sortKey but 859 with a value before the startFrom assertion or after the endWith 860 assertion, that entry is not returned as a result. 862 If the server does not recognize any of the attribute types, or the 863 ordering rule associated with an attribute type is not applicable, or 864 none of the attributes in the search responses are of these types, 865 then the sortKeys field is ignored and result entries are returned 866 in random order. 868 Support for this field is optional, and clients should expect that 869 not all servers will implement result sorting. 871 - reverseSort: If this field is set to TRUE and the sortKeys field is 872 also present, then the entries will be presented in reverse sorted 873 order. 875 - modifyRightsReq: If this field is set to TRUE and the scope field is 876 set to baseObject, then the client requests that the modification 877 rights for the entry be included in the search result. Support for 878 this field is optional, and clients should expect that not all 879 servers will implement returning modify rights. 881 - extraAttributes: If this field is present and set to TRUE then 882 all operational attributes are requested to be returned as well. 883 Note that specific operational attributes may instead be listed in 884 the attributes field. Servers are permitted to ignore extraAttributes 885 if returning this information is prohibited by security policy. 886 Clients should note that many operational attributes are not 887 modifiable. 889 - attrSizeLimit: If this field is present, then if the size in bytes 890 of an attribute and all its values which would be returned in a 891 result entry exceeds this size in bytes, then the attribute is not 892 included in the result and the incompleteEntry field is set to TRUE. 894 - subentries: if present and set to TRUE, the server should ignore 895 ordinary entries and only perform the search against subentries. If 896 the server not support subentries and this field is TRUE it should 897 not do any searching, and either return an error (protocolError) or 898 an empty result. 900 - dontUseCopy: if present and set to TRUE, only the server which holds 901 the master copy of the entry is permitted to perform the filtering 902 and attribute selection. 904 The results of the search attempted by the server upon receipt of a 905 Search Request are returned in Search Responses, which are LDAP 906 messages containing either SearchResultEntry, SearchResultReference, 907 SearchResultDone or SearchResultFull data types. 909 SearchResultEntry ::= [APPLICATION 4] SEQUENCE { 910 objectName LDAPDN, 911 attributes PartialAttributeList, 912 modifyRights [2] ModifyRights OPTIONAL, 913 incompleteEntry [3] BOOLEAN DEFAULT FALSE, 914 fromEntry [4] BOOLEAN DEFAULT FALSE } 915 PartialAttributeList ::= SEQUENCE SIZE (0..maxInt) OF SEQUENCE { 916 type AttributeType, 917 vals SET SIZE (0..maxInt) OF AttributeValue } 919 SearchResultReference ::= [APPLICATION 18] Referral 921 SearchResultDone ::= [APPLICATION 5] LDAPResult 923 SearchResultFull ::= SEQUENCE SIZE (1..maxInt) OF CHOICE { 924 entry SearchResultEntry, 925 reference SearchResultReference, 926 resultCode SearchResultDone } 928 ModifyRights ::= SEQUENCE { 929 entryRemove BOOLEAN, 930 entryModifyDN BOOLEAN, 931 attrRights SET SIZE (0..maxInt) OF SEQUENCE { 932 type AttributeType, 933 grantAdd BOOLEAN, 934 grantRemove BOOLEAN } } 936 Upon receipt of a Search Request, a server will perform the necessary 937 search of the DIT. 939 If the LDAP session is operating over a connection-oriented transport 940 such as TCP, the server will return to the client a sequence of 941 responses in separate LDAP messages. There may be zero or more 942 responses containing SearchResultEntry, one for each entry found 943 during the search. There may also be zero or more responses 944 containing SearchResultReference, one for each area not explored by 945 this server during the search. There must always be a final response 946 containing the SearchResultDone, which contains an indication of 947 success, or detailing any errors that have occurred. 949 If the LDAP session is operating over a connectionless transport such 950 as UDP, the server will return to the client only one response, a 951 LDAPMessage containing a SearchResultFull data type. All if any but 952 the last element of the SEQUENCE OF must be of the SearchResultEntry 953 type, and the last must be of the SearchResultDone type. 955 Each entry returned in a SearchResultEntry will contain all attributes, 956 complete with associated values if necessary, as specified in the 957 attributes field of the Search Request. 959 In a SearchResultEntry, as an encoding optimisation, the value of the 960 objectName LDAP DN may use a trailing '*' character to refer to the 961 baseObject of the corresponding searchRequest. For example, if the 962 baseObject is specified as "o=UofM, c=US", then the following 963 objectName LDAPDNs in a response would have the indicated meanings 965 objectName returned actual LDAPDN denoted 966 ____________________________________________________ 967 "*" "o=UofM, c=US" 968 "cn=Babs Jensen, *" "cn=Babs Jensen, o=UofM, c=US" 969 If (and only if) the modifyRightsReq field was present in the Search 970 Request may the server also include the ModifyRights field in the 971 entry. This field details the operations which are expected to succeed 972 if requested by that user later in this session. The server need not 973 guarantee that these permissions will be granted, however it should 974 avoid suggesting permissions that are not currently granted. If no 975 information is available the server should not include the 976 modifyRights field in the response. 978 The incompleteEntry flag is set if one or more attributes are not 979 present in the PartialAttributeList, because their size would have 980 exceeded the attribute size limit. It is never set if typesOnly was 981 set to TRUE. 983 The server may set the fromEntry field in a SearchResult entry to TRUE 984 if it is known that the search is not based upon a shadow or cached 985 copy of the entry, but that the source of entry data has been directly 986 contacted. 988 If the server was able to locate the entry referred to by the 989 baseObject but was unable to search all the entries in the scope at 990 and under the baseObject, the server may return one or more 991 SearchResultReference, each containing a reference to another LDAP or 992 to an X.500 server for continuing the operation. The server should 993 return at most one SearchResultReference for a subtree. A server must 994 not return a SearchResultReference if it has located the baseObject 995 and thus has not searched any entries; in this case it should return a 996 SearchResultDone containing a referral resultCode and the 997 continuationReference. 999 Note that an X.500 "list" operation can be emulated by a one-level 1000 LDAP search operation with a filter checking for the existence of the 1001 objectClass attribute, and that an X.500 "read" operation can be 1002 emulated by a base object LDAP search operation with the same filter. 1004 4.5. Modify Operation 1006 The Modify Operation allows a client to request that a modification 1007 of the DIB be performed on its behalf by a server. The Modify 1008 Request is defined as follows: 1010 ModifyRequest ::= [APPLICATION 6] SEQUENCE { 1011 object LDAPDN, 1012 modification SEQUENCE SIZE (1..maxInt) OF SEQUENCE { 1013 operation ENUMERATED { 1014 add (0), 1015 delete (1), 1016 replace (2) }, 1017 modification Attribute } } 1019 Parameters of the Modify Request are: 1021 - object: The object to be modified. The value of this field should 1022 name the object to be modified. The server will not perform any 1023 alias dereferencing in determining the object to be modified. 1025 - A list of modifications to be performed on the entry to be modified. 1026 The entire list of entry modifications should be performed 1027 in the order they are listed, as a single atomic operation. While 1028 individual modifications may violate the Directory schema, the 1029 resulting entry after the entire list of modifications is performed 1030 must conform to the requirements of the Directory schema. The 1031 values that may be taken on by the 'operation' field in each 1032 modification construct have the following semantics respectively: 1034 add: add values listed to the given attribute, creating 1035 the attribute if necessary; 1037 delete: delete values listed from the given attribute, 1038 removing the entire attribute if no values are listed, or 1039 if all current values of the attribute are listed for 1040 deletion; 1042 replace: replace existing values of the given attribute 1043 with the new values listed, creating the attribute if 1044 necessary. 1046 The result of the modify attempted by the server upon receipt of a 1047 Modify Request is returned in a Modify Response, defined as follows: 1049 ModifyResponse ::= [APPLICATION 7] LDAPResult 1051 Upon receipt of a Modify Request, a server will perform the necessary 1052 modifications to the DIB. 1054 The server will return to the client a single Modify Response 1055 indicating either the successful completion of the DIB modification, 1056 or the reason that the modification failed. Note that due to the 1057 requirement for atomicity in applying the list of modifications in 1058 the Modify Request, the client may expect that no modifications of 1059 the DIB have been performed if the Modify Response received indicates 1060 any sort of error, and that all requested modifications have been 1061 performed if the Modify Response indicates successful completion of 1062 the Modify Operation. 1064 4.6. Add Operation 1066 The Add Operation allows a client to request the addition of an entry 1067 into the Directory. The Add Request is defined as follows: 1069 AddRequest ::= [APPLICATION 8] SEQUENCE { 1070 entry LDAPDN, 1071 attributes AttributeList } 1073 AttributeList ::= SEQUENCE SIZE (1..maxInt) OF SEQUENCE { 1074 type AttributeType, 1075 vals SET SIZE (1..maxInt) OF AttributeValue } 1076 Parameters of the Add Request are: 1078 - entry: the Distinguished Name of the entry to be added. Note that 1079 all components of the name except for the last RDN component must 1080 exist for the add to succeed. Note also that the server will not 1081 dereference any aliases in locating the entry to be added, and that 1082 there are never any entries subordinate to an alias entry. 1084 - attributes: the list of attributes that make up the content of the 1085 entry being added. 1087 The result of the add attempted by the server upon receipt of a Add 1088 Request is returned in the Add Response, defined as follows: 1090 AddResponse ::= [APPLICATION 9] LDAPResult 1092 Upon receipt of an Add Request, a server will attempt to perform the 1093 add requested. The result of the add attempt will be returned to the 1094 client in the Add Response. 1096 4.7. Delete Operation 1098 The Delete Operation allows a client to request the removal of an 1099 entry from the Directory. The Delete Request is defined as follows: 1101 DelRequest ::= [APPLICATION 10] LDAPDN 1103 The Delete Request consists of the Distinguished Name of the 1104 entry to be deleted. Note that the server will not dereference aliases 1105 while resolving the name of the target entry to be removed. 1107 The result of the delete attempted by the server upon receipt of a 1108 Delete Request is returned in the Delete Response, defined as follows: 1110 DelResponse ::= [APPLICATION 11] LDAPResult 1112 Upon receipt of a Delete Request, a server will attempt to perform 1113 the entry removal requested. The result of the delete attempt will be 1114 returned to the client in the Delete Response. Note that only leaf 1115 objects may be deleted with this operation. 1117 4.8. Modify DN Operation 1119 The Modify DN Operation allows a client to change the last component 1120 of the name of an entry in the Directory, or to move a subtree of 1121 entries to a new location in the Directory. The Modify DN Request is 1122 defined as follows: 1124 ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { 1125 entry LDAPDN, 1126 newrdn RelativeLDAPDN, 1127 deleteoldrdn BOOLEAN, 1128 newSuperior [0] LDAPDN OPTIONAL } 1130 Parameters of the Modify DN Request are: 1132 - entry: the name of the entry to be changed. 1134 - newrdn: the RDN that will form the last component of the new name. 1136 - deleteoldrdn: a boolean parameter that controls whether the old RDN 1137 attribute values should be retained as attributes of the entry or 1138 deleted from the entry. 1140 - newSuperior: if present, this is the name of another entry which 1141 should be the superior of the subtree in the entry field. 1143 The result of the name change attempted by the server upon receipt of 1144 a Modify DN Request is returned in the Modify DN Response, defined 1145 as follows: 1147 ModifyDNResponse ::= [APPLICATION 13] LDAPResult 1149 Upon receipt of a Modify RDN Request, a server will attempt to 1150 perform the name change. The result of the name change attempt will 1151 be returned to the client in the Modify DN Response. The attributes 1152 that make up the old RDN are deleted from the entry, or kept, 1153 depending on the setting of the deleteoldrdn parameter. 1155 4.9. Compare Operation 1157 The Compare Operation allows a client to compare an assertion 1158 provided with an entry in the Directory. The Compare Request is 1159 defined as follows: 1161 CompareRequest ::= [APPLICATION 14] SEQUENCE { 1162 entry LDAPDN, 1163 ava AttributeValueAssertion, 1164 timeLimit [0] INTEGER (0 .. maxInt) OPTIONAL, 1165 dontUseCopy [1] BOOLEAN DEFAULT FALSE } 1167 Parameters of the Compare Request are: 1169 - entry: the name of the entry to be compared with. 1171 - ava: the assertion with which an attribute in the entry is to be 1172 compared. 1174 - timeLimit: the maximum time in seconds the server should spend in 1175 handling this operation. 1177 - dontUseCopy: if present and set to TRUE, only the server which holds 1178 the master copy of the entry is permitted to return the compareTrue 1179 or compareFalse results. 1181 The result of the compare attempted by the server upon receipt of a 1182 Compare Request is returned in the Compare Response, defined as 1183 follows: 1185 CompareResponse ::= [APPLICATION 15] LDAPResult 1187 Upon receipt of a Compare Request, a server will attempt to perform 1188 the requested comparison. The result of the comparison will be 1189 returned to the client in the Compare Response. Note that errors and 1190 the result of comparison are all returned in the same construct. 1192 This operation is defined for backwards compatability with earlier 1193 versions of LDAP. Any new clients written should not use the 1194 comparison operation, but instead should use the search operation, 1195 with scope set to baseObject and filter containing one element, an 1196 equality match. Note that different results will be returned than 1197 from the comparison operation: in search if the filter match is 1198 successful, the entry will be returned, and if the attribute 1199 value is not present, no entries will be returned. 1201 4.10. Abandon Operation 1203 The function of the Abandon Operation is to allow a client to request 1204 that the server abandon an outstanding operation. The Abandon 1205 Request is defined as follows: 1207 AbandonRequest ::= [APPLICATION 16] MessageID 1209 The MessageID must be that of a Search or Compare operation which was 1210 requested earlier during this association. Other types of operations 1211 cannot be abandoned. 1213 There is no response defined in the Abandon Operation. Upon 1214 transmission of an Abandon Operation, a client may expect that the 1215 operation identified by the Message ID in the Abandon Request has 1216 been abandoned. In the event that a server receives an Abandon 1217 Request on a Search Operation in the midst of transmitting responses 1218 to that search, that server should cease transmitting entry responses 1219 to the abandoned search immediately. 1221 4.11 Extended Operation 1223 The following operation allows clients to make requests of forms not 1224 defined in this document. The requestName is a dotted-decimal 1225 representation of the OBJECT IDENTIFIER corresponding to the request. 1226 The requestValue is information in a form defined by that request, 1227 encapsulated inside an OCTET STRING. 1229 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 1230 requestName [0] LDAPString, 1231 requestValue [1] OCTET STRING } 1233 The server will respond to this with an LDAPMessage containing the 1234 ExtendedResponse. 1236 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { 1237 response [0] OCTET STRING OPTIONAL, 1238 standardResponse [1] LDAPResult } 1240 If the server does not recognize the operation name, it should return 1241 only the standardResponse, containing the protocolError result code. 1243 5. Protocol Element Encodings and Transfer 1245 The protocol elements of LDAP are encoded for exchange using the 1246 Basic Encoding Rules (BER) [11] of ASN.1 [3]. However, due to the 1247 high overhead involved in using certain elements of the BER, the 1248 following additional restrictions are placed on BER-encodings of LDAP 1249 protocol elements: 1251 (1) Only the definite form of length encoding will be used. 1253 (2) Bitstrings and octet strings and all character string types 1254 will be encoded in the primitive form only. 1256 (3) UTC Times should be encoded with the "Z" suffix, not as a local 1257 time. 1259 (4) If the value of a BOOLEAN type is true, the encoding should have 1260 its contents octets set to hex "FF". 1262 (5) The components of a SET type, currently only DO.AccessPoint, should 1263 be encoded in ascending order of tag value. 1265 (6) Unused bits in the final octet of the encoding of a BIT STRING 1266 value, if there are any, should always be set to zero. 1268 (7) If a value of a type is its default value, it should be absent. 1269 Only BOOLEAN and ENUMERATED types have default values. 1271 These restrictions do not apply to ASN.1 types encapsulated inside of 1272 OCTET STRINGs. 1274 5.1. Mapping Onto Transport Services 1276 This protocol is designed to run over connection-oriented, reliable 1277 transports, with all 8 bits in an octet being significant in the data 1278 stream. For compatibility with the existing LDAP v2 and CLDAP 1279 protocols, three underlying services are defined here. However an 1280 LDAP server need not implement all three. Separate documents may 1281 define other mappings, such as to a MIME Content-type for use in 1282 messaging and WWW. 1284 5.1.1. Transmission Control Protocol (TCP) 1286 The LDAPMessage PDUs are mapped directly onto the TCP bytestream. 1287 Server implementations running over the TCP should provide a protocol 1288 listener on port 389. 1290 5.1.2. Connection Oriented Transport Service (COTS) 1292 The connection is established. No special use of T-Connect is made. 1293 Each LDAPMessage PDU is mapped directly onto T-Data. 1295 5.1.3. User Datagram Protocol (UDP) 1297 The LDAPMessage PDUs are mapped directly onto UDP datagrams. Only 1298 one request may be sent in a single datagram. Only one response may 1299 be sent in a single datagram. Server implementations running over 1300 the UDP should provide a protocol listener on port 389. 1302 The only operations which the client may request are searchRequest and 1303 abandonRequest. The server may only respond with the searchResultFull. 1305 6. Implementation Guidelines 1307 6.1. Server Implementations 1309 The server should be capable of recognizing all the attribute type 1310 names and implement the syntaxes specified in [5]. Servers may also 1311 recognize additional attribute type names. 1313 In order to prevent confusion, the server should respond with the OID 1314 form for the "uniqueIdentifier" standard and pilot attribute. 1316 6.2. Client Implementations 1318 As there is a conflict of names, the client must not request the 1319 "uniqueIdentifier" attribute. Instead it should use the OID form. 1321 For simple lookup applications using the connectionless transport 1322 protocol UDP, use of a retry algorithm with multiple servers similar 1323 to that commonly used in DNS stub resolver implementations is 1324 recommended. The location of a CLDAP server or servers may be better 1325 specified using IP addresses (simple or broadcast) rather than names 1326 that must first be looked up in another directory such as DNS. 1328 Servers will not dereference aliases encountered when performing an 1329 Add, Delete or Modify operation. If an alias was encountered an error 1330 will be returned. The client must retry the operation with an updated 1331 target entry name. Note that multiple aliases may be encounted while 1332 resolving the entry's true name. 1334 7. Security Considerations 1336 When used with a connection-oriented transport, this version of the 1337 protocol provides facilities for the LDAP v2 authentication mechanisms: 1338 simple authentication using a cleartext password and kerberos version 4 1339 authentication. It also provides for two other authentication 1340 mechanisms as described in X.511: transfer of a hash of the client's 1341 password, and strong authentication based on the private key of the 1342 client. 1344 When used with the connectionless transport, no security services are 1345 available. There has been some discussion about the desirability of 1346 authentication with connectionless LDAP requests. This might take the 1347 form of a clear text password (which would go against the current IAB 1348 drive to remove such things from protocols) or some arbitrary 1349 credentials. It is felt that, in general, authentication would incur 1350 sufficient overhead to negate the advantages of the connectionless 1351 basis of CLDAP. If an application requires authenticated access to the 1352 Directory then CLDAP is not an appropriate protocol. 1354 8. Acknowledgements 1356 This document is based heavily on RFC 1777, by Wengyik Yeong, Tim 1357 Howes, and Steve Kille. It also includes material from RFC 1798, by 1358 Alan Young. Design ideas included in this document are based on those 1359 discussed in ASID and other IETF Working Groups. 1361 9. Bibliography 1363 [1] The Directory: Overview of Concepts, Models and Service. ITU-T 1364 Recommendation X.500, 1993. 1366 [2] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access 1367 Protocol", RFC 1777, March 1995. 1369 [3] Specification of Abstract Syntax Notation One (ASN.1). CCITT 1370 Recommendation X.208, 1988. 1372 [4] S. Kille, "A String Representation of Distinguished Names", RFC 1373 1779, March 1995. 1375 [5] M. Wahl, A. Coulbeck, T. Howes, S. Kille, W. Yeong, C. Robbins, 1376 "Lightweight X.500 Directory Access Protocol Standard and Pilot 1377 Attribute Definitions", , 1378 February 1996. 1380 [6] The Directory: Models. ITU-T Recommendation X.501, 1993. 1382 [7] The Directory: Selected Attribute Types. ITU-T Recommendation 1383 X.520, 1993. 1385 [9] T. Howes, M. Smith, An LDAP URL Format, December 1995, 1386 1388 [10] The Directory: Procedures for Distributed Operation. ITU-T 1389 Recommendation X.518, 1993. 1391 [11] Specification of Basic Encoding Rules for Abstract Syntax 1392 Notation One (ASN.1). CCITT Recommendation X.209, 1988. 1394 [12] The Directory: Authentication Framework. ITU-T Recommendation 1395 X.509, 1993. 1397 [13] The Directory: Abstract Service Definition. ITU-T Recommendation 1398 X.511, 1993. 1400 [14] Kerberos Authentication and Authorization System. S.P. Miller, 1401 B.C. Neuman, J.I. Schiller, J.H. Saltzer; MIT Project Athena 1402 Documentation Section E.2.1, December 1987. 1404 10. Authors' Address 1406 Mark Wahl 1407 ISODE Consortium Inc. 1408 3925 West Braker Lane, Suite 333 1409 Austin, TX 78759 1410 USA 1412 Phone: +1 512-305-0280 1413 EMail: M.Wahl@isode.com 1415 Tim Howes 1416 University of Michigan 1417 ITD Research Systems 1418 535 W William St. 1419 Ann Arbor, MI 48103-4943 1420 USA 1422 Phone: +1 313 747-4454 1423 EMail: tim@umich.edu 1425 Steve Kille 1426 ISODE Consortium 1427 The Dome, The Square 1428 Richmond 1429 TW9 1DT 1430 UK 1432 Phone: +44-181-332-9091 1433 EMail: S.Kille@isode.com 1434 Appendix A - Complete ASN.1 Definition 1436 In the IMPORTS statement the "AF" module refers to X.509(1993), 1437 and the "DAS" module to X.511(1993). 1439 Lightweight-Directory-Access-Protocol-V3 DEFINITIONS 1440 IMPLICIT TAGS ::= 1442 BEGIN 1444 IMPORTS CertificationPath FROM AF 1445 Token FROM DAS; 1447 LDAPMessage ::= SEQUENCE { 1448 messageID MessageID, 1449 cldapUserName LDAPDN OPTIONAL, 1450 protocolOp CHOICE { 1451 bindRequest BindRequest, 1452 bindRespBasic BindResponseBasic, 1453 bindRespExtd BindResponseExtended, 1454 unbindRequest UnbindRequest, 1455 searchRequest SearchRequest, 1456 searchResEntry SearchResultEntry, 1457 searchResDone SearchResultDone, 1458 searchResRef SearchResultReference, 1459 searchResFull SearchResultFull, 1460 modifyRequest ModifyRequest, 1461 modifyResponse ModifyResponse, 1462 addRequest AddRequest, 1463 addResponse AddResponse, 1464 delRequest DelRequest, 1465 delResponse DelResponse, 1466 modDNRequest ModifyDNRequest, 1467 modDNResponse ModifyDNResponse, 1468 compareRequest CompareRequest, 1469 compareResponse CompareResponse, 1470 abandonRequest AbandonRequest, 1471 extendedReq ExtendedRequest, 1472 extendedResp ExtendedResponse } } 1473 MessageID ::= INTEGER (0 .. maxInt ) 1475 maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- 1476 -- later may be extended to 9223372036854775807 (2^^63 - 1) -- 1478 LDAPString ::= OCTET STRING 1480 LDAPDN ::= LDAPString 1482 RelativeLDAPDN ::= LDAPString 1484 AttributeType ::= LDAPString 1486 AttributeTypeList ::= SEQUENCE SIZE (0..maxInt) OF AttributeType 1488 AttributeValue ::= OCTET STRING 1490 AttributeValueAssertion ::= SEQUENCE { 1491 attributeType AttributeType, 1492 assertionValue AssertionValue } 1494 AssertionValue ::= OCTET STRING 1496 Attribute ::= SEQUENCE { 1497 type AttributeType, 1498 vals SET SIZE (1..maxInt) OF AttributeValue } 1500 MatchingRuleId ::= LDAPString 1502 LDAPResult ::= SEQUENCE { 1503 resultCode ENUMERATED { 1504 success (0), 1505 operationsError (1), 1506 protocolError (2), 1507 timeLimitExceeded (3), 1508 sizeLimitExceeded (4), 1509 compareFalse (5), 1510 compareTrue (6), 1511 authMethodNotSupported (7), 1512 strongAuthRequired (8), 1513 -- 9 reserved -- 1514 referral (10), -- new 1515 adminLimitExceeded (11), -- new 1516 unavailableCriticalExtension (12), -- new 1517 -- 14-15 unused -- 1518 noSuchAttribute (16), 1519 undefinedAttributeType (17), 1520 inappropriateMatching (18), 1521 constraintViolation (19), 1522 attributeOrValueExists (20), 1523 invalidAttributeSyntax (21), 1524 -- 22-31 unused -- 1525 noSuchObject (32), 1526 aliasProblem (33), 1527 invalidDNSyntax (34), 1528 isLeaf (35), 1529 aliasDereferencingProblem (36), 1530 -- 37-47 unused -- 1531 inappropriateAuthentication (48), 1532 invalidCredentials (49), 1533 insufficientAccessRights (50), 1534 busy (51), 1535 unavailable (52), 1536 unwillingToPerform (53), 1537 loopDetect (54), 1538 -- 55-63 unused -- 1539 namingViolation (64), 1540 objectClassViolation (65), 1541 notAllowedOnNonLeaf (66), 1542 notAllowedOnRDN (67), 1543 entryAlreadyExists (68), 1544 objectClassModsProhibited (69), 1545 resultsTooLarge (70), -- cl only 1546 affectsMultipleDSAs (71), -- new 1547 -- 72-79 unused -- 1548 other (80) }, 1549 matchedDN LDAPDN, 1550 errorMessage LDAPString (SIZE (0..maxInt)), 1551 referral [3] Referral OPTIONAL, 1552 matchedSubtype [4] AttributeType OPTIONAL } 1554 Referral ::= SEQUENCE { 1555 servers [0] SET SIZE (1..maxInt) OF LDAPURL } 1557 LDAPURL ::= OCTET STRING 1559 BindRequest ::= [APPLICATION 0] SEQUENCE { 1560 version INTEGER (1 .. 127), 1561 name LDAPDN, 1562 authentication AuthenticationChoice, 1563 serviceControls [7] Controls OPTIONAL } 1565 AuthenticationChoice ::= CHOICE { 1566 simple [1] OCTET STRING, 1567 krbv42LDAP [2] OCTET STRING, 1568 krbv42DSA [3] OCTET STRING, 1569 protected [4] ProtectedPassword, 1570 strong [5] StrongCredentials, 1571 nonstandard [6] NonstandardCredentials } 1572 ProtectedPassword ::= SEQUENCE { 1573 time1 [0] UTCTime OPTIONAL, 1574 time2 [1] UTCTime OPTIONAL, 1575 random1 [2] BIT STRING OPTIONAL, 1576 random2 [3] BIT STRING OPTIONAL, 1577 protected [4] OCTET STRING } 1579 StrongCredentials ::= SEQUENCE { 1580 certification-path [0] AF.CertificationPath OPTIONAL, 1581 bind-token [1] DAS.Token } 1583 NonstandardCredentials ::= SEQUENCE { 1584 authMechanism [0] LDAPString, 1585 authToken [1] OCTET STRING } 1587 Controls ::= SEQUENCE SIZE (1..maxInt) OF SEQUENCE { 1588 criticality [0] BOOLEAN DEFAULT FALSE, 1589 control ServiceControl } 1591 ServiceControl ::= CHOICE { 1592 referringServer [0] LDAPURL, 1593 chainingProhibited [1] BOOLEAN, 1594 scopeOfReferral [2] ENUMERATED { 1595 any(-1), 1596 dmd(0), 1597 country(1) }, 1598 referToLDAPServers [3] BOOLEAN, 1599 referToDAPServers [4] BOOLEAN, 1600 preferredSyntax [5] SyntaxEncoding, 1601 extendedControl [6] ExtendedControl } 1603 SyntaxEncoding ::= SEQUENCE { 1604 attributeType [0] AttributeType, 1605 encodingPreference [1] SyntaxName } 1607 SyntaxName ::= LDAPString 1609 ExtendedControl ::= SEQUENCE { 1610 controlName [0] LDAPString, 1611 controlValue [1] OCTET STRING } 1613 BindResponseBasic ::= [APPLICATION 1] LDAPResult 1615 BindResponseExtended ::= [APPLICATION 17] SEQUENCE { 1616 serverURL [0] LDAPURL, 1617 serverCreds AuthenticationChoice } 1619 UnbindRequest ::= [APPLICATION 2] NULL 1621 SearchRequest ::= [APPLICATION 3] SEQUENCE { 1622 baseObject LDAPDN, 1623 scope ENUMERATED { 1624 baseObject (0), 1625 singleLevel (1), 1626 wholeSubtree (2) }, 1627 derefAliases ENUMERATED { 1628 neverDerefAliases (0), 1629 derefInSearching (1), 1630 derefFindingBaseObj (2), 1631 derefAlways (3) }, 1632 sizeLimit INTEGER (0 .. maxInt), 1633 timeLimit INTEGER (0 .. maxInt), 1634 typesOnly BOOLEAN, 1635 filter Filter, 1636 attributes AttributeTypeList, 1637 matchedOnly [0] BOOLEAN DEFAULT FALSE, 1638 sortKeys [1] SortKeyList OPTIONAL, 1639 reverseSort [2] BOOLEAN DEFAULT FALSE, 1640 modifyRightsReq [3] BOOLEAN DEFAULT FALSE, 1641 extraAttributes [4] BOOLEAN DEFAULT FALSE, 1642 attrSizeLimit [5] INTEGER OPTIONAL, 1643 subentries [6] BOOLEAN DEFAULT FALSE, 1644 dontUseCopy [7] BOOLEAN DEFAULT FALSE } 1646 SortKeyList ::= SEQUENCE SIZE (1..maxInt) OF SEQUENCE { 1647 attributeType AttributeType, 1648 orderingRule [0] MatchingRuleId OPTIONAL, 1649 startFrom [1] AssertionValue OPTIONAL, 1650 endWith [2] AssertionValue OPTIONAL } 1652 Filter ::= CHOICE { 1653 and [0] SET SIZE (1..maxInt) OF Filter, 1654 or [1] SET SIZE (1..maxInt) OF Filter, 1655 not [2] Filter, 1656 equalityMatch [3] AttributeValueAssertion, 1657 substrings [4] SubstringFilter, 1658 greaterOrEqual [5] AttributeValueAssertion, 1659 lessOrEqual [6] AttributeValueAssertion, 1660 present [7] AttributeType, 1661 approxMatch [8] AttributeValueAssertion, 1662 extensibleMatch [9] MatchingRuleAssertion } 1664 SubstringFilter ::= SEQUENCE { 1665 type AttributeType, 1666 substrings SEQUENCE SIZE (1..maxInt) OF CHOICE { 1667 initial [0] LDAPString, 1668 any [1] LDAPString, 1669 final [2] LDAPString } } 1671 MatchingRuleAssertion ::= SEQUENCE { 1672 matchingRules [1] SET SIZE (0..maxInt) OF MatchingRuleId, 1673 type [2] AttributeType, 1674 matchValue [3] AssertionValue, 1675 dnAttributes [4] BOOLEAN } 1677 SearchResultEntry ::= [APPLICATION 4] SEQUENCE { 1678 objectName LDAPDN, 1679 attributes PartialAttributeList, 1680 modifyRights [2] ModifyRights OPTIONAL, 1681 incompleteEntry [3] BOOLEAN DEFAULT FALSE, 1682 fromEntry [4] BOOLEAN DEFAULT FALSE } 1683 PartialAttributeList ::= SEQUENCE SIZE (0..maxInt) OF SEQUENCE { 1684 type AttributeType, 1685 vals SET SIZE (0..maxInt) OF AttributeValue } 1687 SearchResultReference ::= [APPLICATION 18] Referral 1689 SearchResultDone ::= [APPLICATION 5] LDAPResult 1691 SearchResultFull ::= SEQUENCE SIZE (1..maxInt) OF CHOICE { 1692 entry SearchResultEntry, 1693 reference SearchResultReference, 1694 resultCode SearchResultDone } 1696 ModifyRights ::= SEQUENCE { 1697 entryRemove BOOLEAN, 1698 entryModifyDN BOOLEAN, 1699 attrRights SET SIZE (0..maxInt) OF SEQUENCE { 1700 type AttributeType, 1701 grantAdd BOOLEAN, 1702 grantRemove BOOLEAN } } 1704 ModifyRequest ::= [APPLICATION 6] SEQUENCE { 1705 object LDAPDN, 1706 modification SEQUENCE SIZE (1..maxInt) OF SEQUENCE { 1707 operation ENUMERATED { 1708 add (0), 1709 delete (1), 1710 replace (2) }, 1711 modification Attribute } } 1713 ModifyResponse ::= [APPLICATION 7] LDAPResult 1715 AddRequest ::= [APPLICATION 8] SEQUENCE { 1716 entry LDAPDN, 1717 attributes AttributeList } 1719 AttributeList ::= SEQUENCE SIZE (1..maxInt) OF SEQUENCE { 1720 type AttributeType, 1721 vals SET SIZE (1..maxInt) OF AttributeValue } 1723 AddResponse ::= [APPLICATION 9] LDAPResult 1725 DelRequest ::= [APPLICATION 10] LDAPDN 1727 DelResponse ::= [APPLICATION 11] LDAPResult 1728 ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { 1729 entry LDAPDN, 1730 newrdn RelativeLDAPDN, 1731 deleteoldrdn BOOLEAN, 1732 newSuperior [0] LDAPDN OPTIONAL } 1734 ModifyDNResponse ::= [APPLICATION 13] LDAPResult 1736 CompareRequest ::= [APPLICATION 14] SEQUENCE { 1737 entry LDAPDN, 1738 ava AttributeValueAssertion, 1739 timeLimit [0] INTEGER (0 .. maxInt) OPTIONAL, 1740 dontUseCopy [1] BOOLEAN DEFAULT FALSE } 1742 CompareResponse ::= [APPLICATION 15] LDAPResult 1744 AbandonRequest ::= [APPLICATION 16] MessageID 1746 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 1747 requestName [0] LDAPString, 1748 requestValue [1] OCTET STRING } 1750 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { 1751 response [0] OCTET STRING OPTIONAL, 1752 standardResponse [1] LDAPResult } 1754 END 1756 Appendix B - Imported ASN.1 Definitions 1758 Note that the types described here are distinct from those defined in 1759 the body of this document. 1761 B.1. Types from X.509(1993) "Authentication Framework" 1763 The type "Certificate" is defined in X.509(1993). It it strongly 1764 recommended that clients and server implementations which support 1765 certificates implement the draft addendums to X.509 which provide 1766 certificate extensions. 1768 AlgorithmIdentifier ::= SEQUENCE { 1769 algorithm OBJECT IDENTIFIER, 1770 parameters ANY OPTIONAL } 1772 CertificatePair ::= SEQUENCE { 1773 forward [0] Certificate OPTIONAL, 1774 reverse [1] Certificate OPTIONAL 1775 -- at least one of the pair shall be present -- } 1777 CertificationPath ::= SEQUENCE { 1778 userCertificate Certificate, 1779 theCACertificates SEQUENCE OF CertificatePair 1780 OPTIONAL } 1782 B.2. Types from X.511(1993) "Directory Abstract Syntax" 1784 The type "DistinguishedName" is defined in X.501(1993). It is the 1785 ASN.1 encoding, not a string encoding. 1787 Token ::= SIGNED { SEQUENCE { 1788 algorithm [0] AlgorithmIdentifier, 1789 name [1] DistinguishedName, 1790 time [2] UTCTime, 1791 random [3] BIT STRING } }