8 draft-legg-ldap-binary-04.txt eB2Bcom
9 Intended Category: Standards Track 30 January 2006
12 Lightweight Directory Access Protocol (LDAP):
13 The Binary Encoding Option
15 Copyright (C) The Internet Society (2006).
19 By submitting this Internet-draft, each author represents that any
20 applicable patent or other IPR claims of which he or she is aware
21 have been or will be disclosed, and any of which he or she becomes
22 aware will be disclosed, in accordance with Section 6 of BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF), its areas, and its working groups. Note that
26 other groups may also distribute working documents as
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress".
34 The list of current Internet-Drafts can be accessed at
35 http://www.ietf.org/1id-abstracts.html
37 The list of Internet-Draft Shadow Directories can be accessed at
38 http://www.ietf.org/shadow.html
40 Technical discussion of this document should take place on the IETF
41 LDAP Revision Working Group (LDAPbis) mailing list
42 <ietf-ldapbis@openldap.org>. Please send editorial comments directly
43 to the editor <steven.legg@eb2bcom.com>.
45 This Internet-Draft expires on 30 July 2006.
49 Each attribute stored in a Lightweight Directory Access Protocol
50 (LDAP) directory has a defined syntax (i.e., data type). A syntax
51 definition specifies how attribute values conforming to the syntax
52 are normally represented when transferred in LDAP operations. This
53 representation is referred to as the LDAP-specific encoding to
54 distinguish it from other methods of encoding attribute values. This
58 Legg Expires 30 July 2006 [Page 1]
60 INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
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
114 Legg Expires 30 July 2006 [Page 2]
116 INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
121 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
122 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 4
123 3. The binary Option. . . . . . . . . . . . . . . . . . . . . . . 4
124 4. Syntaxes Requiring Binary Transfer . . . . . . . . . . . . . . 4
125 5. Attributes Returned in a Search. . . . . . . . . . . . . . . . 5
126 6. All User Attributes. . . . . . . . . . . . . . . . . . . . . . 6
127 7. Conflicting Requests . . . . . . . . . . . . . . . . . . . . . 6
128 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 6
129 9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
130 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
131 10.1. Normative References. . . . . . . . . . . . . . . . . . 7
132 10.2. Informative References. . . . . . . . . . . . . . . . . 7
133 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
134 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8
138 Each attribute stored in a Lightweight Directory Access Protocol
139 (LDAP) directory [ROADMAP] has a defined syntax (i.e., data type)
140 which constrains the structure and format of its values.
142 The description of each syntax [SYNTAX] specifies how attribute or
143 assertion values [MODELS] conforming to the syntax are normally
144 represented when transferred in LDAP operations [PROT]. This
145 representation is referred to as the LDAP-specific encoding to
146 distinguish it from other methods of encoding attribute values.
148 This document defines an attribute option, the binary option, which
149 can be used in an attribute description [MODELS] in an LDAP operation
150 to specify that the associated attribute values or assertion values
151 are, or are requested to be, encoded according to the Basic Encoding
152 Rules (BER) [BER] as used by X.500 [X.500] directories, instead of
153 the usual LDAP-specific encoding.
155 The binary option was originally defined in RFC 2251 [RFC2251]. The
156 LDAP technical specification [ROADMAP] has obsoleted the previously
157 defined LDAP technical specification [RFC3377], which included RFC
158 2251. The binary option was not included in the revised LDAP
159 technical specification for a variety of reasons including
160 implementation inconsistencies. No attempt is made here to resolve
161 the known inconsistencies.
163 This document reintroduces the binary option for use with certain
164 attribute syntaxes, such as certificate syntax [PKI], which
165 specifically require it. No attempt has been made to address use of
166 the binary option with attributes of syntaxes which do not require
170 Legg Expires 30 July 2006 [Page 3]
172 INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
175 its use. Unless addressed in a future specification, this use is to
181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
183 document are to be interpreted as described in BCP 14, RFC 2119
188 The binary option is indicated with the attribute option string
189 "binary" in an attribute description. Note that, like all attribute
190 options, the string representing the binary option is case
193 Where the binary option is present in an attribute description the
194 associated attribute values or assertion values MUST be BER encoded
195 (otherwise the values are encoded according to the LDAP-specific
196 encoding [SYNTAX] for the attribute's syntax). Note that it is
197 possible for a syntax to be defined such that its LDAP-specific
198 encoding is exactly the same as its BER encoding.
200 In terms of the protocol [PROT], the binary option specifies that the
201 contents octets of the associated AttributeValue or AssertionValue
202 OCTET STRING are a complete BER encoding of the relevant value.
204 The binary option is not a tagging option [MODELS] so the presence of
205 the binary option does not specify an attribute subtype. An
206 attribute description containing the binary option references exactly
207 the same attribute as the attribute description without the binary
208 option. The supertype/subtype relationships of attributes with
209 tagging options are not altered in any way by the presence or absence
210 of the binary option.
212 An attribute description SHALL be treated as unrecognized if it
213 contains the binary option and the syntax of the attribute does not
214 have an associated ASN.1 type [SYNTAX], or the BER encoding of values
215 of that type is not supported.
217 The presence or absence of the binary option only affects the
218 transfer of attribute and assertion values in protocol; servers store
219 any particular attribute value in a format of their choosing.
221 4. Syntaxes Requiring Binary Transfer
226 Legg Expires 30 July 2006 [Page 4]
228 INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
231 The attribute values of certain attribute syntaxes are defined
232 without an LDAP-specific encoding and are required to be transferred
233 in the BER encoded form. For the purposes of this document, these
234 syntaxes are said to have a binary transfer requirement. The
235 Certificate, Certificate List, Certificate Pair and Supported
236 Algorithm syntaxes [PKI] are examples of syntaxes with a binary
237 transfer requirement. These syntaxes also have an additional
238 requirement that the exact BER encoding must be preserved. Note that
239 this is a property of the syntaxes themselves, and not a property of
240 the binary option. In the absence of this requirement, LDAP clients
241 would need to re-encode values using the Distinguished Encoding Rules
244 5. Attributes Returned in a Search
246 An LDAP search request [PROT] contains a list of the attributes (the
247 requested attributes list) to be returned from each entry matching
248 the search filter. An attribute description in the requested
249 attributes list also implicitly requests all subtypes of the
250 attribute type in the attribute description, whether through
251 attribute subtyping or attribute tagging option subtyping [MODELS].
253 The requested attributes list MAY contain attribute descriptions with
254 the binary option, but MUST NOT contain two attribute descriptions
255 with the same attribute type and the same tagging options (even if
256 only one of them has the binary option). The binary option in an
257 attribute description in the requested attributes list implicitly
258 applies to all the subtypes of the attribute type in the attribute
259 description (however, see Section 7).
261 Attributes of a syntax with the binary transfer requirement, if
262 returned, SHALL be returned in the binary form, i.e., with the binary
263 option in the attribute description and the associated attribute
264 values BER encoded, regardless of whether the binary option was
265 present in the request (for the attribute or for one of its
268 Attributes of a syntax without the binary transfer requirement, if
269 returned, SHOULD be returned in the form explicitly requested. That
270 is, if the attribute description in the requested attributes list
271 contains the binary option then the corresponding attribute in the
272 result SHOULD be in the binary form. If the attribute description in
273 the request does not contain the binary option then the corresponding
274 attribute in the result SHOULD NOT be in the binary form. A server
275 MAY omit an attribute from the result if it does not support the
278 Regardless of the encoding chosen, a particular attribute value is
282 Legg Expires 30 July 2006 [Page 5]
284 INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
287 returned at most once.
289 6. All User Attributes
291 If the list of attributes in a search request is empty, or contains
292 the special attribute description string "*", then all user
293 attributes are requested to be returned.
295 Attributes of a syntax with the binary transfer requirement, if
296 returned, SHALL be returned in the binary form.
298 Attributes of a syntax without the binary transfer requirement and
299 having a defined LDAP-specific encoding SHOULD NOT be returned in the
302 Attributes of a syntax without the binary transfer requirement and
303 without a defined LDAP-specific encoding may be returned in the
304 binary form or omitted from the result.
306 7. Conflicting Requests
308 A particular attribute could be explicitly requested by an attribute
309 description and/or implicitly requested by the attribute descriptions
310 of one or more of its supertypes, or by the special attribute
311 description string "*". If the binary option is not present in all
312 these attribute descriptions, nor absent in all these attribute
313 descriptions, then the effect of the request with respect to binary
314 transfer is implementation defined.
316 8. Security Considerations
318 When interpreting security-sensitive fields, and in particular fields
319 used to grant or deny access, implementations MUST ensure that any
320 matching rule comparisons are done on the underlying abstract value,
321 regardless of the particular encoding used.
323 9. IANA Considerations
325 The Internet Assigned Numbers Authority (IANA) is requested to update
326 the LDAP attribute description option registry [BCP64] as indicated
327 by the following template:
330 Request for LDAP Attribute Description Option Registration
332 Family of Options: NO
333 Person & email address to contact for further information:
334 Steven Legg <steven.legg@eb2bcom.com>
338 Legg Expires 30 July 2006 [Page 6]
340 INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
343 Specification: RFC XXXX
344 Author/Change Controller: IESG
345 Comments: The existing registration for "binary"
346 should be updated to refer to RFC XXXX.
350 10.1. Normative References
352 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
353 Requirement Levels", BCP 14, RFC 2119, March 1997.
355 [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
356 Considerations for the Lightweight Directory Access
357 Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
359 [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
360 (LDAP): Technical Specification Road Map",
361 draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
364 [MODELS] Zeilenga, K., "LDAP: Directory Information Models",
365 draft-ietf-ldapbis-models-xx.txt, a work in progress,
368 [PROT] Sermersheim, J., "LDAP: The Protocol",
369 draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
372 [SYNTAX] Legg, S., "Lightweight Directory Access Protocol (LDAP):
373 Syntaxes and Matching Rules",
374 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress,
377 [PKI] Zeilenga, Kurt D., "Lightweight Directory Access Protocol
378 (LDAP) schema definitions for X.509 Certificates",
379 draft-zeilenga-ldap-x509-xx.txt, a work in progress, July
382 [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
383 Information Technology - ASN.1 encoding rules:
384 Specification of Basic Encoding Rules (BER), Canonical
385 Encoding Rules (CER) and Distinguished Encoding Rules
388 10.2. Informative References
390 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
394 Legg Expires 30 July 2006 [Page 7]
396 INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
399 Access Protocol (v3)", RFC 2251, December 1997.
401 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
402 Protocol (v3): Technical Specification", RFC 3377,
405 [X.500] ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001,
406 Information technology - Open Systems Interconnection -
407 The Directory: Overview of concepts, models and services
413 Suite 3, Woodhouse Corporate Centre
415 Box Hill North, Victoria 3129
418 Phone: +61 3 9896 7830
420 EMail: steven.legg@eb2bcom.com
422 Full Copyright Statement
424 Copyright (C) The Internet Society (2006).
426 This document is subject to the rights, licenses and restrictions
427 contained in BCP 78, and except as set forth therein, the authors
428 retain all their rights.
430 This document and the information contained herein are provided on an
431 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
432 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
433 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
434 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
435 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
436 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
438 Intellectual Property
440 The IETF takes no position regarding the validity or scope of any
441 Intellectual Property Rights or other rights that might be claimed to
442 pertain to the implementation or use of the technology described in
443 this document or the extent to which any license under such rights
444 might or might not be available; nor does it represent that it has
445 made any independent effort to identify any such rights. Information
446 on the procedures with respect to rights in RFC documents can be
450 Legg Expires 30 July 2006 [Page 8]
452 INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
455 found in BCP 78 and BCP 79.
457 Copies of IPR disclosures made to the IETF Secretariat and any
458 assurances of licenses to be made available, or the result of an
459 attempt made to obtain a general license or permission for the use of
460 such proprietary rights by implementers or users of this
461 specification can be obtained from the IETF on-line IPR repository at
462 http://www.ietf.org/ipr.
464 The IETF invites any interested party to bring to its attention any
465 copyrights, patents or patent applications, or other proprietary
466 rights that may cover technology that may be required to implement
467 this standard. Please address the information to the IETF at
506 Legg Expires 30 July 2006 [Page 9]