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

   1
   2
   3
   4
   5
   6
   7 INTERNET-DRAFT                                                   S. Legg
   8 draft-legg-ldap-binary-03.txt                                    eB2Bcom
   9 Intended Category: Standards Track                           7 June 2005
  10 Updates: [SYNTAX]
  11
  12
  13              Lightweight Directory Access Protocol (LDAP):
  14                        The Binary Encoding Option
  15
  16     Copyright (C) The Internet Society (2005). All Rights Reserved.
  17
  18    Status of this Memo
  19
  20    By submitting this Internet-draft, each author represents that any
  21    applicable patent or other IPR claims of which he or she is aware
  22    have been or will be disclosed, and any of which he or she becomes
  23    aware will be disclosed, in accordance with Section 6 of BCP 79.
  24
  25    By submitting this Internet-draft, I accept the provisions of Section
  26    3 of BCP 78.
  27
  28    Internet-Drafts are working documents of the Internet Engineering
  29    Task Force (IETF), its areas, and its working groups.  Note that
  30    other groups may also distribute working documents as
  31    Internet-Drafts.
  32
  33    Internet-Drafts are draft documents valid for a maximum of six months
  34    and may be updated, replaced, or obsoleted by other documents at any
  35    time.  It is inappropriate to use Internet-Drafts as reference
  36    material or to cite them other than as "work in progress".
  37
  38    The list of current Internet-Drafts can be accessed at
  39    http://www.ietf.org/1id-abstracts.html
  40
  41    The list of Internet-Draft Shadow Directories can be accessed at
  42    http://www.ietf.org/shadow.html
  43
  44    Technical discussion of this document should take place on the IETF
  45    LDAP Revision Working Group (LDAPbis) mailing list
  46    <ietf-ldapbis@openldap.org>.  Please send editorial comments directly
  47    to the editor <steven.legg@eb2bcom.com>.
  48
  49    This Internet-Draft expires on 7 December 2005.
  50
  51 Abstract
  52
  53    Each attribute stored in a Lightweight Directory Access Protocol
  54    (LDAP) directory has a defined syntax (i.e., data type).  A syntax
  55
  56
  57
  58 Legg                     Expires 7 December 2005                [Page 1]
  59 \f
  60 INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
  61
  62
  63    definition specifies how attribute values conforming to the syntax
  64    are normally represented when transferred in LDAP operations.  This
  65    representation is referred to as the LDAP-specific encoding to
  66    distinguish it from other methods of encoding attribute values.  This
  67    document defines an attribute option, the binary option, which can be
  68    used to specify that the associated attribute values are instead
  69    encoded according to the Basic Encoding Rules (BER) used by X.500
  70    directories.
  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
 111
 112
 113
 114 Legg                     Expires 7 December 2005                [Page 2]
 115 \f
 116 INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
 117
 118
 119 Table of Contents
 120
 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. . . . . . . . . . . . . . . . . . . . . .  5
 127    7.  Conflicting Requests . . . . . . . . . . . . . . . . . . . . .  6
 128    8.  Security Considerations. . . . . . . . . . . . . . . . . . . .  6
 129    9.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  6
 130    10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
 131        10.1.  Normative References. . . . . . . . . . . . . . . . . .  7
 132        10.2.  Informative References. . . . . . . . . . . . . . . . .  7
 133    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  8
 134    Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .  8
 135
 136 1.  Introduction
 137
 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.
 141
 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.
 147
 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.
 154
 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.  However the binary option was not included in the newer LDAP
 159    technical specification due to a lack of consistency in its
 160    implementation.  This document reintroduces the binary option.
 161    However, except for the case of certain attribute syntaxes whose
 162    values are required to BER encoded, no attempt is made here to
 163    eliminate the known consistency problems.  Rather the focus is on
 164    capturing current behaviours.  A more thorough solution is left for a
 165    future specification.
 166
 167
 168
 169
 170 Legg                     Expires 7 December 2005                [Page 3]
 171 \f
 172 INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
 173
 174
 175 2.  Conventions
 176
 177    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 178    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL" in this
 179    document are to be interpreted as described in BCP 14, RFC 2119
 180    [KEYWORD].
 181
 182 3.  The binary Option
 183
 184    The binary option is indicated with the attribute option string
 185    "binary" in an attribute description.  Note that, like all attribute
 186    options, the string representing the binary option is case
 187    insensitive.
 188
 189    Where the binary option is present in an attribute description the
 190    associated attribute values or assertion values MUST be BER encoded
 191    (otherwise the values are encoded according to the LDAP-specific
 192    encoding [SYNTAX] for the attribute's syntax).  Note that it is
 193    possible for a syntax to be defined such that its LDAP-specific
 194    encoding is exactly the same as its BER encoding.
 195
 196    In terms of the protocol [PROT], the binary option specifies that the
 197    contents octets of the associated AttributeValue or AssertionValue
 198    OCTET STRING are a complete BER encoding of the relevant value.
 199
 200    The binary option is not a tagging option [MODELS] so the presence of
 201    the binary option does not specify an attribute subtype.  An
 202    attribute description containing the binary option references exactly
 203    the same attribute as the attribute description without the binary
 204    option.  The supertype/subtype relationships of attributes with
 205    tagging options are not altered in any way by the presence or absence
 206    of the binary option.
 207
 208    An attribute description SHALL be treated as unrecognized if it
 209    contains the binary option and the syntax of the attribute does not
 210    have an associated ASN.1 type [SYNTAX], or the BER encoding of values
 211    of that type is not supported.
 212
 213    The presence or absence of the binary option only affects the
 214    transfer of attribute and assertion values in protocol; servers store
 215    any particular attribute value in a format of their choosing.
 216
 217 4.  Syntaxes Requiring Binary Transfer
 218
 219    The attribute values of certain attribute syntaxes are defined
 220    without an LDAP-specific encoding and are required to be transferred
 221    in the BER encoded form.  For the purposes of this document, these
 222    syntaxes are said to have a binary transfer requirement.  The
 223
 224
 225
 226 Legg                     Expires 7 December 2005                [Page 4]
 227 \f
 228 INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
 229
 230
 231    Certificate, Certificate List, Certificate Pair and Supported
 232    Algorithm syntaxes [PKI] are examples of syntaxes with a binary
 233    transfer requirement.  These syntaxes also have an additional
 234    requirement that the exact BER encoding must be preserved.  Note that
 235    this is a property of the syntaxes themselves, and not a property of
 236    the binary option.
 237
 238 5.  Attributes Returned in a Search
 239
 240    An LDAP search request [PROT] contains a list of the attributes (the
 241    requested attributes list) to be returned from each entry matching
 242    the search filter.  An attribute description in the requested
 243    attributes list also implicitly requests all subtypes of the
 244    attribute type in the attribute description, whether through
 245    attribute subtyping or attribute tagging option subtyping [MODELS].
 246
 247    The requested attributes list MAY contain attribute descriptions with
 248    the binary option, but MUST NOT contain two attribute descriptions
 249    with the same attribute type and the same tagging options (even if
 250    only one of them has the binary option).  The binary option in an
 251    attribute description in the requested attributes list implicitly
 252    applies to all the subtypes of the attribute type in the attribute
 253    description (however, see Section 7).
 254
 255    Attributes of a syntax with the binary transfer requirement, if
 256    returned, SHALL be returned in the binary form, i.e., with the binary
 257    option in the attribute description and the associated attribute
 258    values BER encoded, regardless of whether the binary option was
 259    present in the request (for the attribute or for one of its
 260    supertypes).
 261
 262    Attributes of a syntax without the binary transfer requirement, if
 263    returned, SHOULD be returned in the form explicitly requested.  That
 264    is, if the attribute description in the requested attributes list
 265    contains the binary option then the corresponding attribute in the
 266    result SHOULD be in the binary form.  If the attribute description in
 267    the request does not contain the binary option then the corresponding
 268    attribute in the result SHOULD NOT be in the binary form.  A server
 269    MAY omit an attribute from the result if it does not support the
 270    requested encoding.
 271
 272    Regardless of the encoding chosen, a particular attribute value is
 273    returned at most once.
 274
 275 6.  All User Attributes
 276
 277    If the list of attributes in a search request is empty, or contains
 278    the special attribute description string "*", then all user
 279
 280
 281
 282 Legg                     Expires 7 December 2005                [Page 5]
 283 \f
 284 INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
 285
 286
 287    attributes are requested to be returned.
 288
 289    Attributes of a syntax with the binary transfer requirement, if
 290    returned, SHALL be returned in the binary form.
 291
 292    Attributes of a syntax without the binary transfer requirement and
 293    having a defined LDAP-specific encoding SHOULD NOT be returned in the
 294    binary form.
 295
 296    Attributes of a syntax without the binary transfer requirement and
 297    without a defined LDAP-specific encoding may be returned in the
 298    binary form or omitted from the result.
 299
 300 7.  Conflicting Requests
 301
 302    A particular attribute could be explicitly requested by an attribute
 303    description and/or implicitly requested by the attribute descriptions
 304    of one or more of its supertypes, or by the special attribute
 305    description string "*".  If the binary option is not present in all
 306    these attribute descriptions, nor absent in all these attribute
 307    descriptions, then the effect of the request with respect to binary
 308    transfer is implementation defined.
 309
 310 8.  Security Considerations
 311
 312    When interpreting security-sensitive fields, and in particular fields
 313    used to grant or deny access, implementations MUST ensure that any
 314    matching rule comparisons are done on the underlying abstract value,
 315    regardless of the particular encoding used.
 316
 317 9.  IANA Considerations
 318
 319    The Internet Assigned Numbers Authority (IANA) is requested to update
 320    the LDAP attribute description option registry [BCP64] as indicated
 321    by the following template:
 322
 323       Subject:
 324         Request for LDAP Attribute Description Option Registration
 325       Option Name: binary
 326       Family of Options: NO
 327       Person & email address to contact for further information:
 328         Steven Legg <steven.legg@eb2bcom.com>
 329       Specification: RFC XXXX
 330       Author/Change Controller: IESG
 331       Comments: The existing registration for "binary"
 332                 should be updated to refer to RFC XXXX.
 333
 334 10.  References
 335
 336
 337
 338 Legg                     Expires 7 December 2005                [Page 6]
 339 \f
 340 INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
 341
 342
 343 10.1.  Normative References
 344
 345    [KEYWORD]  Bradner, S., "Key words for use in RFCs to Indicate
 346               Requirement Levels", BCP 14, RFC 2119, March 1997.
 347
 348    [BCP64]    Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
 349               Considerations for the Lightweight Directory Access
 350               Protcol (LDAP)", BCP 64, RFC 3383, September 2002.
 351
 352    [ROADMAP]  Zeilenga, K., "Lightweight Directory Access Protocol
 353               (LDAP): Technical Specification Road Map",
 354               draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
 355               February 2005.
 356
 357    [MODELS]   Zeilenga, K., "LDAP: Directory Information Models",
 358               draft-ietf-ldapbis-models-xx.txt, a work in progress,
 359               February 2005.
 360
 361    [PROT]     Sermersheim, J., "LDAP: The Protocol",
 362               draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
 363               February 2005.
 364
 365    [SYNTAX]   Legg, S. and K. Dally, "Lightweight Directory Access
 366               Protocol (LDAP): Syntaxes and Matching Rules",
 367               draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress,
 368               February 2005.
 369
 370    [PKI]      Zeilenga, Kurt D., "Lightweight Directory Access Protocol
 371               (LDAP) schema definitions for X.509 Certificates",
 372               draft-zeilenga-ldap-x509-xx.txt, a work in progress,
 373               February 2005.
 374
 375    [BER]      ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
 376               Information Technology - ASN.1 encoding rules:
 377               Specification of Basic Encoding Rules (BER), Canonical
 378               Encoding Rules (CER) and Distinguished Encoding Rules
 379               (DER).
 380
 381 10.2.  Informative References
 382
 383    [RFC2251]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
 384               Access Protocol (v3)", RFC 2251, December 1997.
 385
 386    [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
 387               Protocol (v3): Technical Specification", RFC 3377,
 388               September 2002.
 389
 390    [X.500]    ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
 391
 392
 393
 394 Legg                     Expires 7 December 2005                [Page 7]
 395 \f
 396 INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
 397
 398
 399               "Information Technology - Open Systems Interconnection -
 400               The Directory: Overview of concepts, models and services".
 401
 402 Author's Address
 403
 404    Steven Legg
 405    eB2Bcom
 406    Suite 3, Woodhouse Corporate Centre
 407    935 Station Street
 408    Box Hill North, Victoria 3129
 409    AUSTRALIA
 410
 411    Phone: +61 3 9896 7830
 412      Fax: +61 3 9896 7801
 413    EMail: steven.legg@eb2bcom.com
 414
 415 Full Copyright Statement
 416
 417    Copyright (C) The Internet Society (2005).
 418
 419    This document is subject to the rights, licenses and restrictions
 420    contained in BCP 78, and except as set forth therein, the authors
 421    retain all their rights.
 422
 423    This document and the information contained herein are provided on an
 424    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 425    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 426    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 427    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 428    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 429    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 430
 431 Intellectual Property
 432
 433    The IETF takes no position regarding the validity or scope of any
 434    Intellectual Property Rights or other rights that might be claimed to
 435    pertain to the implementation or use of the technology described in
 436    this document or the extent to which any license under such rights
 437    might or might not be available; nor does it represent that it has
 438    made any independent effort to identify any such rights.  Information
 439    on the procedures with respect to rights in RFC documents can be
 440    found in BCP 78 and BCP 79.
 441
 442    Copies of IPR disclosures made to the IETF Secretariat and any
 443    assurances of licenses to be made available, or the result of an
 444    attempt made to obtain a general license or permission for the use of
 445    such proprietary rights by implementers or users of this
 446    specification can be obtained from the IETF on-line IPR repository at
 447
 448
 449
 450 Legg                     Expires 7 December 2005                [Page 8]
 451 \f
 452 INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
 453
 454
 455    http://www.ietf.org/ipr.
 456
 457    The IETF invites any interested party to bring to its attention any
 458    copyrights, patents or patent applications, or other proprietary
 459    rights that may cover technology that may be required to implement
 460    this standard.  Please address the information to the IETF at
 461    ietf-ipr@ietf.org.
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506 Legg                     Expires 7 December 2005                [Page 9]
 507 \f