4 draft-legg-ldap-binary-01.txt Adacel Technologies
5 Intended Category: Standards Track 16 June 2004
9 Lightweight Directory Access Protocol (LDAP):
10 The Binary Encoding Option
12 Copyright (C) The Internet Society (2004). All Rights Reserved.
17 This document is an Internet-Draft and is in full conformance with
18 all provisions of Section 10 of RFC2026.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress".
30 The list of current Internet-Drafts can be accessed at
31 http://www.ietf.org/ietf/1id-abstracts.txt
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
36 This document is intended to be, after appropriate review and
37 revision, submitted to the RFC Editor as a Standard Track document.
38 Distribution of this document is unlimited. Technical discussion of
39 this document should take place on the IETF LDAP Revision Working
40 Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
41 send editorial comments directly to the editor
42 <steven.legg@adacel.com.au>.
44 This Internet-Draft expires on 16 December 2004.
49 Each attribute stored in a Lightweight Directory Access Protocol
50 (LDAP) directory has a defined syntax (i.e., data type). A syntax
54 Legg Expires 16 December 2004 [Page 1]
56 INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
59 definition specifies how attribute values conforming to the syntax
60 are normally represented when transferred in LDAP operations. This
61 representation is referred to as the LDAP-specific encoding to
62 distinguish it from other methods of encoding attribute values. This
63 document defines an attribute option, the binary option, which can be
64 used to specify that the associated attribute values are instead
65 encoded according to the Basic Encoding Rules (BER) used by X.500
110 Legg Expires 16 December 2004 [Page 2]
112 INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
117 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
118 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 4
119 3. The binary Option. . . . . . . . . . . . . . . . . . . . . . . 4
120 4. Syntaxes Requiring Binary Transfer . . . . . . . . . . . . . . 4
121 5. Attributes Returned in a Search. . . . . . . . . . . . . . . . 5
122 6. All User Attributes. . . . . . . . . . . . . . . . . . . . . . 5
123 7. Conflicting Requests . . . . . . . . . . . . . . . . . . . . . 6
124 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 6
125 9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
126 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
127 10.1. Normative References. . . . . . . . . . . . . . . . . . 6
128 10.2. Informative References. . . . . . . . . . . . . . . . . 7
129 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
130 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8
134 Each attribute stored in a Lightweight Directory Access Protocol
135 (LDAP) directory [ROADMAP] has a defined syntax (i.e., data type)
136 which constrains the structure and format of its values.
138 The description of each syntax [SYNTAX] specifies how attribute or
139 assertion values [MODELS] conforming to the syntax are normally
140 represented when transferred in LDAP operations [PROT]. This
141 representation is referred to as the LDAP-specific encoding to
142 distinguish it from other methods of encoding attribute values.
144 This document defines an attribute option, the binary option, which
145 can be used in an attribute description [MODELS] in an LDAP operation
146 to specify that the associated attribute values or assertion value
147 are, or are requested to be, encoded according to the Basic Encoding
148 Rules (BER) [BER] as used by X.500 [X500] directories, instead of the
149 usual LDAP-specific encoding.
151 The binary option was originally defined in RFC 2251 [RFC2251]. The
152 LDAP technical specification [ROADMAP] has obsoleted the previously
153 defined LDAP technical specification [RFC3377], which included RFC
154 2251. However the binary option was not included in the newer LDAP
155 technical specification due to a lack of consistency in its
156 implementation. This document reintroduces the binary option.
157 However, except for the case of certain attribute syntaxes whose
158 values are required to BER encoded, no attempt is made here to
159 eliminate the known consistency problems. Rather the focus is on
160 capturing current behaviours. A more thorough solution is left for a
161 future specification.
166 Legg Expires 16 December 2004 [Page 3]
168 INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
175 document are to be interpreted as described in BCP 14, RFC 2119
180 The binary option is indicated with the attribute option string
181 "binary" in an attribute description. Note that, like all attribute
182 options, the string representing the binary option is case
185 In terms of the protocol [PROT], the binary option specifies that the
186 contents octets of the associated AttributeValue or AssertionValue
187 OCTET STRING are a complete BER encoding of the relevant value.
189 Where the binary option is present in an attribute description the
190 associated attribute values or assertion value MUST be BER encoded.
191 Note that it is possible for a syntax to be defined such that its
192 LDAP-specific encoding is exactly the same as its BER encoding.
194 The binary option is not a tagging option [MODELS] so the presence of
195 the binary option does not specify an attribute subtype. An
196 attribute description containing the binary option references exactly
197 the same attribute as the same attribute description without the
198 binary option. The supertype/subtype relationships of attributes
199 with tagging options are not altered in any way by the presence or
200 absence of the binary option.
202 An attribute description SHALL be treated as unrecognized if it
203 contains the binary option and the syntax of the attribute does not
204 have an associated ASN.1 type [SYNTAX], or the BER encoding of that
205 type is not supported.
207 The presence or absence of the binary option only affects the
208 transfer of attribute and assertion values in protocol; servers store
209 any particular attribute value in a single format of their choosing.
211 4. Syntaxes Requiring Binary Transfer
213 Certain syntaxes are required to be transferred in the BER encoded
214 form. These syntaxes are said to have a binary transfer requirement.
215 The Certificate, Certificate List, Certificate Pair and Supported
216 Algorithm syntaxes [PKI] are examples of syntaxes with a binary
217 transfer requirement. These syntaxes also have an additional
218 requirement that the exact BER encoding must be preserved. Note that
222 Legg Expires 16 December 2004 [Page 4]
224 INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
227 this is a property of the syntaxes themselves, and not a property of
230 5. Attributes Returned in a Search
232 An LDAP search request [PROT] contains a list of the attributes (the
233 requested attributes list) to be returned from each entry matching
234 the search filter. An attribute description in the requested
235 attributes list also implicitly requests all subtypes of the
236 attribute type in the attribute description, whether through
237 attribute subtyping or attribute tagging option subtyping [MODELS].
239 The requested attributes list MAY contain attribute descriptions with
240 the binary option, but MUST NOT contain two attribute descriptions
241 with the same attribute type and the same tagging options (even if
242 only one of them has the binary option). The binary option in an
243 attribute description in the requested attributes list implicitly
244 applies to all the subtypes of the attribute type in the attribute
245 description (however, see Section 7).
247 Attributes of a syntax with the binary transfer requirement SHALL be
248 returned in the binary form, i.e., with the binary option in the
249 attribute description and the associated attribute values BER
250 encoded, regardless of whether the binary option was present in the
251 request (for the attribute or for one of its supertypes).
253 Attributes of a syntax without the binary transfer requirement SHOULD
254 be returned in the form explicitly requested. That is, if the
255 attribute description in the requested attributes list contains the
256 binary option then the corresponding attribute in the result SHOULD
257 be in the binary form. If the attribute description in the request
258 does not contain the binary option then the corresponding attribute
259 in the result SHOULD NOT be in the binary form. A server MAY omit an
260 attribute from the result if it does not support the requested
263 Regardless of the encoding chosen, a particular attribute value is
264 returned at most once.
266 6. All User Attributes
268 If the list of attributes in a search request is empty, or contains
269 the special attribute description string "*", then all user
270 attributes are requested to be returned.
272 Attributes of a syntax with the binary transfer requirement SHALL be
273 returned in the binary form.
278 Legg Expires 16 December 2004 [Page 5]
280 INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
283 Attributes of a syntax without the binary transfer requirement and
284 having a defined LDAP-specific encoding SHOULD NOT be returned in the
287 Attributes of a syntax without the binary transfer requirement and
288 without a defined LDAP-specific encoding may be returned in the
289 binary form or omitted from the result.
291 7. Conflicting Requests
293 A particular attribute could be explicitly requested by an attribute
294 description and/or implicitly requested by the attribute descriptions
295 of one or more of its supertypes, or by the special attribute
296 description string "*". If the binary option is not present in all
297 these attribute descriptions, nor absent in all these attribute
298 descriptions, then the server is free to choose whether to return the
299 attribute in the binary form.
301 8. Security Considerations
303 When interpreting security-sensitive fields, and in particular fields
304 used to grant or deny access, implementations MUST ensure that any
305 matching rule comparisons are done on the underlying abstract value,
306 regardless of the particular encoding used.
308 9. IANA Considerations
310 The Internet Assigned Numbers Authority (IANA) is requested to update
311 the LDAP attribute description option registry [BCP64] as indicated
312 by the following template:
315 LDAP Attribute Description Option Registration
317 Family of Options: NO
318 Person & email address to contact for further information:
319 Steven Legg <steven.legg@adacel.com.au>
320 Specification: RFC XXXX
321 Author/Change Controller: IESG
322 Comments: The existing registration for "binary"
323 should be updated to refer to RFC XXXX.
327 10.1. Normative References
329 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
330 Requirement Levels", BCP 14, RFC 2119, March 1997.
334 Legg Expires 16 December 2004 [Page 6]
336 INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
339 [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
340 Considerations for the Lightweight Directory Access
341 Protcol (LDAP)", BCP 64, RFC 3383, September 2002.
343 [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
344 (LDAP): Technical Specification Road Map",
345 draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
348 [MODELS] Zeilenga, K., "LDAP: Directory Information Models",
349 draft-ietf-ldapbis-models-xx.txt, a work in progress, June
352 [PROT] Sermersheim, J., "LDAP: The Protocol",
353 draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
356 [SYNTAX] Legg, S. and K. Dally, "Lightweight Directory Access
357 Protocol (LDAP): Syntaxes and Matching Rules",
358 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress,
361 [PKI] Chadwick, D. and S. Legg, "Internet X.509 Public Key
362 Infrastructure Additional LDAP Schema for PKIs and PMIs",
363 draft-pkix-ldap-schema-xx.txt, a work in progress, April
366 [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
367 Information Technology - ASN.1 encoding rules:
368 Specification of Basic Encoding Rules (BER), Canonical
369 Encoding Rules (CER) and Distinguished Encoding Rules
372 10.2. Informative References
374 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
375 Access Protocol (v3)", RFC 2251, December 1997.
377 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
378 Protocol (v3): Technical Specification", RFC 3377,
381 [X500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
382 "Information Technology - Open Systems Interconnection -
383 The Directory: Overview of concepts, models and services".
390 Legg Expires 16 December 2004 [Page 7]
392 INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
396 Adacel Technologies Ltd.
398 Brighton, Victoria 3186
401 Phone: +61 3 8530 7710
403 Email: steven.legg@adacel.com.au
405 Full Copyright Statement
407 Copyright (C) The Internet Society (2004). This document is subject
408 to the rights, licenses and restrictions contained in BCP 78, and
409 except as set forth therein, the authors retain all their rights.
411 This document and the information contained herein are provided on an
412 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
413 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
414 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
415 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
416 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
417 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
419 Intellectual Property
421 The IETF takes no position regarding the validity or scope of any
422 Intellectual Property Rights or other rights that might be claimed to
423 pertain to the implementation or use of the technology described in
424 this document or the extent to which any license under such rights
425 might or might not be available; nor does it represent that it has
426 made any independent effort to identify any such rights. Information
427 on the procedures with respect to rights in RFC documents can be
428 found in BCP 78 and BCP 79.
430 Copies of IPR disclosures made to the IETF Secretariat and any
431 assurances of licenses to be made available, or the result of an
432 attempt made to obtain a general license or permission for the use of
433 such proprietary rights by implementers or users of this
434 specification can be obtained from the IETF on-line IPR repository at
435 http://www.ietf.org/ipr.
437 The IETF invites any interested party to bring to its attention any
438 copyrights, patents or patent applications, or other proprietary
439 rights that may cover technology that may be required to implement
440 this standard. Please address the information to the IETF at
446 Legg Expires 16 December 2004 [Page 8]