idnits 2.17.1 draft-legg-ldap-binary-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 354. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (30 January 2006) is 6658 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3383 (ref. 'BCP64') (Obsoleted by RFC 4520) -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ROADMAP' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MODELS' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PROT' -- No information found for draft-ietf-ldapbis-syntaxes-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SYNTAX' -- No information found for draft-zeilenga-ldap-x509-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PKI' -- Possible downref: Non-RFC (?) normative reference: ref. 'BER' -- Obsolete informational reference (is this intentional?): RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 3377 (Obsoleted by RFC 4510) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Legg 3 draft-legg-ldap-binary-04.txt eB2Bcom 4 Intended Category: Standards Track 30 January 2006 6 Lightweight Directory Access Protocol (LDAP): 7 The Binary Encoding Option 9 Copyright (C) The Internet Society (2006). 11 Status of this Memo 13 By submitting this Internet-draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Technical discussion of this document should take place on the IETF 35 LDAP Revision Working Group (LDAPbis) mailing list 36 . Please send editorial comments directly 37 to the editor . 39 This Internet-Draft expires on 30 July 2006. 41 Abstract 43 Each attribute stored in a Lightweight Directory Access Protocol 44 (LDAP) directory has a defined syntax (i.e., data type). A syntax 45 definition specifies how attribute values conforming to the syntax 46 are normally represented when transferred in LDAP operations. This 47 representation is referred to as the LDAP-specific encoding to 48 distinguish it from other methods of encoding attribute values. This 49 document defines an attribute option, the binary option, which can be 50 used to specify that the associated attribute values are instead 51 encoded according to the Basic Encoding Rules (BER) used by X.500 52 directories. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. The binary Option. . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Syntaxes Requiring Binary Transfer . . . . . . . . . . . . . . 4 60 5. Attributes Returned in a Search. . . . . . . . . . . . . . . . 5 61 6. All User Attributes. . . . . . . . . . . . . . . . . . . . . . 6 62 7. Conflicting Requests . . . . . . . . . . . . . . . . . . . . . 6 63 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 6 64 9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 10.1. Normative References. . . . . . . . . . . . . . . . . . 7 67 10.2. Informative References. . . . . . . . . . . . . . . . . 7 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 Each attribute stored in a Lightweight Directory Access Protocol 74 (LDAP) directory [ROADMAP] has a defined syntax (i.e., data type) 75 which constrains the structure and format of its values. 77 The description of each syntax [SYNTAX] specifies how attribute or 78 assertion values [MODELS] conforming to the syntax are normally 79 represented when transferred in LDAP operations [PROT]. This 80 representation is referred to as the LDAP-specific encoding to 81 distinguish it from other methods of encoding attribute values. 83 This document defines an attribute option, the binary option, which 84 can be used in an attribute description [MODELS] in an LDAP operation 85 to specify that the associated attribute values or assertion values 86 are, or are requested to be, encoded according to the Basic Encoding 87 Rules (BER) [BER] as used by X.500 [X.500] directories, instead of 88 the usual LDAP-specific encoding. 90 The binary option was originally defined in RFC 2251 [RFC2251]. The 91 LDAP technical specification [ROADMAP] has obsoleted the previously 92 defined LDAP technical specification [RFC3377], which included RFC 93 2251. The binary option was not included in the revised LDAP 94 technical specification for a variety of reasons including 95 implementation inconsistencies. No attempt is made here to resolve 96 the known inconsistencies. 98 This document reintroduces the binary option for use with certain 99 attribute syntaxes, such as certificate syntax [PKI], which 100 specifically require it. No attempt has been made to address use of 101 the binary option with attributes of syntaxes which do not require 102 its use. Unless addressed in a future specification, this use is to 103 be avoided. 105 2. Conventions 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in BCP 14, RFC 2119 110 [BCP14]. 112 3. The binary Option 114 The binary option is indicated with the attribute option string 115 "binary" in an attribute description. Note that, like all attribute 116 options, the string representing the binary option is case 117 insensitive. 119 Where the binary option is present in an attribute description the 120 associated attribute values or assertion values MUST be BER encoded 121 (otherwise the values are encoded according to the LDAP-specific 122 encoding [SYNTAX] for the attribute's syntax). Note that it is 123 possible for a syntax to be defined such that its LDAP-specific 124 encoding is exactly the same as its BER encoding. 126 In terms of the protocol [PROT], the binary option specifies that the 127 contents octets of the associated AttributeValue or AssertionValue 128 OCTET STRING are a complete BER encoding of the relevant value. 130 The binary option is not a tagging option [MODELS] so the presence of 131 the binary option does not specify an attribute subtype. An 132 attribute description containing the binary option references exactly 133 the same attribute as the attribute description without the binary 134 option. The supertype/subtype relationships of attributes with 135 tagging options are not altered in any way by the presence or absence 136 of the binary option. 138 An attribute description SHALL be treated as unrecognized if it 139 contains the binary option and the syntax of the attribute does not 140 have an associated ASN.1 type [SYNTAX], or the BER encoding of values 141 of that type is not supported. 143 The presence or absence of the binary option only affects the 144 transfer of attribute and assertion values in protocol; servers store 145 any particular attribute value in a format of their choosing. 147 4. Syntaxes Requiring Binary Transfer 148 The attribute values of certain attribute syntaxes are defined 149 without an LDAP-specific encoding and are required to be transferred 150 in the BER encoded form. For the purposes of this document, these 151 syntaxes are said to have a binary transfer requirement. The 152 Certificate, Certificate List, Certificate Pair and Supported 153 Algorithm syntaxes [PKI] are examples of syntaxes with a binary 154 transfer requirement. These syntaxes also have an additional 155 requirement that the exact BER encoding must be preserved. Note that 156 this is a property of the syntaxes themselves, and not a property of 157 the binary option. In the absence of this requirement, LDAP clients 158 would need to re-encode values using the Distinguished Encoding Rules 159 (DER). 161 5. Attributes Returned in a Search 163 An LDAP search request [PROT] contains a list of the attributes (the 164 requested attributes list) to be returned from each entry matching 165 the search filter. An attribute description in the requested 166 attributes list also implicitly requests all subtypes of the 167 attribute type in the attribute description, whether through 168 attribute subtyping or attribute tagging option subtyping [MODELS]. 170 The requested attributes list MAY contain attribute descriptions with 171 the binary option, but MUST NOT contain two attribute descriptions 172 with the same attribute type and the same tagging options (even if 173 only one of them has the binary option). The binary option in an 174 attribute description in the requested attributes list implicitly 175 applies to all the subtypes of the attribute type in the attribute 176 description (however, see Section 7). 178 Attributes of a syntax with the binary transfer requirement, if 179 returned, SHALL be returned in the binary form, i.e., with the binary 180 option in the attribute description and the associated attribute 181 values BER encoded, regardless of whether the binary option was 182 present in the request (for the attribute or for one of its 183 supertypes). 185 Attributes of a syntax without the binary transfer requirement, if 186 returned, SHOULD be returned in the form explicitly requested. That 187 is, if the attribute description in the requested attributes list 188 contains the binary option then the corresponding attribute in the 189 result SHOULD be in the binary form. If the attribute description in 190 the request does not contain the binary option then the corresponding 191 attribute in the result SHOULD NOT be in the binary form. A server 192 MAY omit an attribute from the result if it does not support the 193 requested encoding. 195 Regardless of the encoding chosen, a particular attribute value is 196 returned at most once. 198 6. All User Attributes 200 If the list of attributes in a search request is empty, or contains 201 the special attribute description string "*", then all user 202 attributes are requested to be returned. 204 Attributes of a syntax with the binary transfer requirement, if 205 returned, SHALL be returned in the binary form. 207 Attributes of a syntax without the binary transfer requirement and 208 having a defined LDAP-specific encoding SHOULD NOT be returned in the 209 binary form. 211 Attributes of a syntax without the binary transfer requirement and 212 without a defined LDAP-specific encoding may be returned in the 213 binary form or omitted from the result. 215 7. Conflicting Requests 217 A particular attribute could be explicitly requested by an attribute 218 description and/or implicitly requested by the attribute descriptions 219 of one or more of its supertypes, or by the special attribute 220 description string "*". If the binary option is not present in all 221 these attribute descriptions, nor absent in all these attribute 222 descriptions, then the effect of the request with respect to binary 223 transfer is implementation defined. 225 8. Security Considerations 227 When interpreting security-sensitive fields, and in particular fields 228 used to grant or deny access, implementations MUST ensure that any 229 matching rule comparisons are done on the underlying abstract value, 230 regardless of the particular encoding used. 232 9. IANA Considerations 234 The Internet Assigned Numbers Authority (IANA) is requested to update 235 the LDAP attribute description option registry [BCP64] as indicated 236 by the following template: 238 Subject: 239 Request for LDAP Attribute Description Option Registration 240 Option Name: binary 241 Family of Options: NO 242 Person & email address to contact for further information: 243 Steven Legg 245 Specification: RFC XXXX 246 Author/Change Controller: IESG 247 Comments: The existing registration for "binary" 248 should be updated to refer to RFC XXXX. 250 10. References 252 10.1. Normative References 254 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, March 1997. 257 [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 258 Considerations for the Lightweight Directory Access 259 Protocol (LDAP)", BCP 64, RFC 3383, September 2002. 261 [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol 262 (LDAP): Technical Specification Road Map", 263 draft-ietf-ldapbis-roadmap-xx.txt, a work in progress, 264 February 2005. 266 [MODELS] Zeilenga, K., "LDAP: Directory Information Models", 267 draft-ietf-ldapbis-models-xx.txt, a work in progress, 268 February 2005. 270 [PROT] Sermersheim, J., "LDAP: The Protocol", 271 draft-ietf-ldapbis-protocol-xx.txt, a work in progress, 272 October 2005. 274 [SYNTAX] Legg, S., "Lightweight Directory Access Protocol (LDAP): 275 Syntaxes and Matching Rules", 276 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress, 277 June 2005. 279 [PKI] Zeilenga, Kurt D., "Lightweight Directory Access Protocol 280 (LDAP) schema definitions for X.509 Certificates", 281 draft-zeilenga-ldap-x509-xx.txt, a work in progress, July 282 2005. 284 [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1, 285 Information Technology - ASN.1 encoding rules: 286 Specification of Basic Encoding Rules (BER), Canonical 287 Encoding Rules (CER) and Distinguished Encoding Rules 288 (DER). 290 10.2. Informative References 292 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory 293 Access Protocol (v3)", RFC 2251, December 1997. 295 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 296 Protocol (v3): Technical Specification", RFC 3377, 297 September 2002. 299 [X.500] ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001, 300 Information technology - Open Systems Interconnection - 301 The Directory: Overview of concepts, models and services 303 Author's Address 305 Dr. Steven Legg 306 eB2Bcom 307 Suite 3, Woodhouse Corporate Centre 308 935 Station Street 309 Box Hill North, Victoria 3129 310 AUSTRALIA 312 Phone: +61 3 9896 7830 313 Fax: +61 3 9896 7801 314 EMail: steven.legg@eb2bcom.com 316 Full Copyright Statement 318 Copyright (C) The Internet Society (2006). 320 This document is subject to the rights, licenses and restrictions 321 contained in BCP 78, and except as set forth therein, the authors 322 retain all their rights. 324 This document and the information contained herein are provided on an 325 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 326 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 327 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 328 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 329 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 330 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 332 Intellectual Property 334 The IETF takes no position regarding the validity or scope of any 335 Intellectual Property Rights or other rights that might be claimed to 336 pertain to the implementation or use of the technology described in 337 this document or the extent to which any license under such rights 338 might or might not be available; nor does it represent that it has 339 made any independent effort to identify any such rights. Information 340 on the procedures with respect to rights in RFC documents can be 341 found in BCP 78 and BCP 79. 343 Copies of IPR disclosures made to the IETF Secretariat and any 344 assurances of licenses to be made available, or the result of an 345 attempt made to obtain a general license or permission for the use of 346 such proprietary rights by implementers or users of this 347 specification can be obtained from the IETF on-line IPR repository at 348 http://www.ietf.org/ipr. 350 The IETF invites any interested party to bring to its attention any 351 copyrights, patents or patent applications, or other proprietary 352 rights that may cover technology that may be required to implement 353 this standard. Please address the information to the IETF at 354 ietf-ipr@ietf.org.