git.sur5r.net Git - openldap/blob - doc/drafts/draft-legg-ldap-binary-xx.txt

   1
   2
   3 INTERNET-DRAFT                                                   S. Legg
   4 draft-legg-ldap-binary-01.txt                        Adacel Technologies
   5 Intended Category: Standards Track                          16 June 2004
   6 Updates: RFC 2251bis
   7
   8
   9              Lightweight Directory Access Protocol (LDAP):
  10                        The Binary Encoding Option
  11
  12     Copyright (C) The Internet Society (2004). All Rights Reserved.
  13
  14    Status of this Memo
  15
  16
  17    This document is an Internet-Draft and is in full conformance with
  18    all provisions of Section 10 of RFC2026.
  19
  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
  23    Internet-Drafts.
  24
  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".
  29
  30    The list of current Internet-Drafts can be accessed at
  31    http://www.ietf.org/ietf/1id-abstracts.txt
  32
  33    The list of Internet-Draft Shadow Directories can be accessed at
  34    http://www.ietf.org/shadow.html.
  35
  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>.
  43
  44    This Internet-Draft expires on 16 December 2004.
  45
  46
  47 Abstract
  48
  49    Each attribute stored in a Lightweight Directory Access Protocol
  50    (LDAP) directory has a defined syntax (i.e., data type).  A syntax
  51
  52
  53
  54 Legg                    Expires 16 December 2004                [Page 1]
  55 \f
  56 INTERNET-DRAFT      LDAP: The Binary Encoding Option       June 16, 2004
  57
  58
  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
  66    directories.
  67
  68
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110 Legg                    Expires 16 December 2004                [Page 2]
 111 \f
 112 INTERNET-DRAFT      LDAP: The Binary Encoding Option       June 16, 2004
 113
 114
 115 Table of Contents
 116
 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
 131
 132 1.  Introduction
 133
 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.
 137
 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.
 143
 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.
 150
 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.
 162
 163
 164
 165
 166 Legg                    Expires 16 December 2004                [Page 3]
 167 \f
 168 INTERNET-DRAFT      LDAP: The Binary Encoding Option       June 16, 2004
 169
 170
 171 2.  Conventions
 172
 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
 176    [KEYWORD].
 177
 178 3.  The binary Option
 179
 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
 183    insensitive.
 184
 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.
 188
 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.
 193
 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.
 201
 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.
 206
 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.
 210
 211 4.  Syntaxes Requiring Binary Transfer
 212
 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
 219
 220
 221
 222 Legg                    Expires 16 December 2004                [Page 4]
 223 \f
 224 INTERNET-DRAFT      LDAP: The Binary Encoding Option       June 16, 2004
 225
 226
 227    this is a property of the syntaxes themselves, and not a property of
 228    the binary option.
 229
 230 5.  Attributes Returned in a Search
 231
 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].
 238
 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).
 246
 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).
 252
 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
 261    encoding.
 262
 263    Regardless of the encoding chosen, a particular attribute value is
 264    returned at most once.
 265
 266 6.  All User Attributes
 267
 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.
 271
 272    Attributes of a syntax with the binary transfer requirement SHALL be
 273    returned in the binary form.
 274
 275
 276
 277
 278 Legg                    Expires 16 December 2004                [Page 5]
 279 \f
 280 INTERNET-DRAFT      LDAP: The Binary Encoding Option       June 16, 2004
 281
 282
 283    Attributes of a syntax without the binary transfer requirement and
 284    having a defined LDAP-specific encoding SHOULD NOT be returned in the
 285    binary form.
 286
 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.
 290
 291 7.  Conflicting Requests
 292
 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.
 300
 301 8.  Security Considerations
 302
 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.
 307
 308 9.  IANA Considerations
 309
 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:
 313
 314       Subject: Request for
 315         LDAP Attribute Description Option Registration
 316       Option Name: binary
 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.
 324
 325 10.  References
 326
 327 10.1.  Normative References
 328
 329    [KEYWORD]  Bradner, S., "Key words for use in RFCs to Indicate
 330               Requirement Levels", BCP 14, RFC 2119, March 1997.
 331
 332
 333
 334 Legg                    Expires 16 December 2004                [Page 6]
 335 \f
 336 INTERNET-DRAFT      LDAP: The Binary Encoding Option       June 16, 2004
 337
 338
 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.
 342
 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,
 346               June 2004.
 347
 348    [MODELS]   Zeilenga, K., "LDAP: Directory Information Models",
 349               draft-ietf-ldapbis-models-xx.txt, a work in progress, June
 350               2004.
 351
 352    [PROT]     Sermersheim, J., "LDAP: The Protocol",
 353               draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
 354               May 2004.
 355
 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,
 359               May 2004.
 360
 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
 364               2002.
 365
 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
 370               (DER).
 371
 372 10.2.  Informative References
 373
 374    [RFC2251]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
 375               Access Protocol (v3)", RFC 2251, December 1997.
 376
 377    [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
 378               Protocol (v3): Technical Specification", RFC 3377,
 379               September 2002.
 380
 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".
 384
 385 Author's Address
 386
 387
 388
 389
 390 Legg                    Expires 16 December 2004                [Page 7]
 391 \f
 392 INTERNET-DRAFT      LDAP: The Binary Encoding Option       June 16, 2004
 393
 394
 395    Steven Legg
 396    Adacel Technologies Ltd.
 397    250 Bay Street
 398    Brighton, Victoria 3186
 399    AUSTRALIA
 400
 401    Phone: +61 3 8530 7710
 402      Fax: +61 3 8530 7888
 403    Email: steven.legg@adacel.com.au
 404
 405 Full Copyright Statement
 406
 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.
 410
 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.
 418
 419 Intellectual Property
 420
 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.
 429
 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.
 436
 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
 441    ietf-ipr@ietf.org.
 442
 443
 444
 445
 446 Legg                    Expires 16 December 2004                [Page 8]
 447 \f
 448