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-04.txt                                    eB2Bcom
   9 Intended Category: Standards Track                       30 January 2006
  10
  11
  12              Lightweight Directory Access Protocol (LDAP):
  13                        The Binary Encoding Option
  14
  15                Copyright (C) The Internet Society (2006).
  16
  17    Status of this Memo
  18
  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.
  23
  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
  27    Internet-Drafts.
  28
  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".
  33
  34    The list of current Internet-Drafts can be accessed at
  35    http://www.ietf.org/1id-abstracts.html
  36
  37    The list of Internet-Draft Shadow Directories can be accessed at
  38    http://www.ietf.org/shadow.html
  39
  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>.
  44
  45    This Internet-Draft expires on 30 July 2006.
  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    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
  55
  56
  57
  58 Legg                      Expires 30 July 2006                  [Page 1]
  59 \f
  60 INTERNET-DRAFT      LDAP: The Binary Encoding Option    January 30, 2006
  61
  62
  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
 111
 112
 113
 114 Legg                      Expires 30 July 2006                  [Page 2]
 115 \f
 116 INTERNET-DRAFT      LDAP: The Binary Encoding Option    January 30, 2006
 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. . . . . . . . . . . . . . . . . . . . . .  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
 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.  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.
 162
 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
 167
 168
 169
 170 Legg                      Expires 30 July 2006                  [Page 3]
 171 \f
 172 INTERNET-DRAFT      LDAP: The Binary Encoding Option    January 30, 2006
 173
 174
 175    its use.  Unless addressed in a future specification, this use is to
 176    be avoided.
 177
 178
 179 2.  Conventions
 180
 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
 184    [BCP14].
 185
 186 3.  The binary Option
 187
 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
 191    insensitive.
 192
 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.
 199
 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.
 203
 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.
 211
 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.
 216
 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.
 220
 221 4.  Syntaxes Requiring Binary Transfer
 222
 223
 224
 225
 226 Legg                      Expires 30 July 2006                  [Page 4]
 227 \f
 228 INTERNET-DRAFT      LDAP: The Binary Encoding Option    January 30, 2006
 229
 230
 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
 242    (DER).
 243
 244 5.  Attributes Returned in a Search
 245
 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].
 252
 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).
 260
 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
 266    supertypes).
 267
 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
 276    requested encoding.
 277
 278    Regardless of the encoding chosen, a particular attribute value is
 279
 280
 281
 282 Legg                      Expires 30 July 2006                  [Page 5]
 283 \f
 284 INTERNET-DRAFT      LDAP: The Binary Encoding Option    January 30, 2006
 285
 286
 287    returned at most once.
 288
 289 6.  All User Attributes
 290
 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.
 294
 295    Attributes of a syntax with the binary transfer requirement, if
 296    returned, SHALL be returned in the binary form.
 297
 298    Attributes of a syntax without the binary transfer requirement and
 299    having a defined LDAP-specific encoding SHOULD NOT be returned in the
 300    binary form.
 301
 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.
 305
 306 7.  Conflicting Requests
 307
 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.
 315
 316 8.  Security Considerations
 317
 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.
 322
 323 9.  IANA Considerations
 324
 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:
 328
 329       Subject:
 330         Request for LDAP Attribute Description Option Registration
 331       Option Name: binary
 332       Family of Options: NO
 333       Person & email address to contact for further information:
 334         Steven Legg <steven.legg@eb2bcom.com>
 335
 336
 337
 338 Legg                      Expires 30 July 2006                  [Page 6]
 339 \f
 340 INTERNET-DRAFT      LDAP: The Binary Encoding Option    January 30, 2006
 341
 342
 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.
 347
 348 10.  References
 349
 350 10.1.  Normative References
 351
 352    [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
 353               Requirement Levels", BCP 14, RFC 2119, March 1997.
 354
 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.
 358
 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,
 362               February 2005.
 363
 364    [MODELS]   Zeilenga, K., "LDAP: Directory Information Models",
 365               draft-ietf-ldapbis-models-xx.txt, a work in progress,
 366               February 2005.
 367
 368    [PROT]     Sermersheim, J., "LDAP: The Protocol",
 369               draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
 370               October 2005.
 371
 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,
 375               June 2005.
 376
 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
 380               2005.
 381
 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
 386               (DER).
 387
 388 10.2.  Informative References
 389
 390    [RFC2251]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
 391
 392
 393
 394 Legg                      Expires 30 July 2006                  [Page 7]
 395 \f
 396 INTERNET-DRAFT      LDAP: The Binary Encoding Option    January 30, 2006
 397
 398
 399               Access Protocol (v3)", RFC 2251, December 1997.
 400
 401    [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
 402               Protocol (v3): Technical Specification", RFC 3377,
 403               September 2002.
 404
 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
 408
 409 Author's Address
 410
 411    Dr. Steven Legg
 412    eB2Bcom
 413    Suite 3, Woodhouse Corporate Centre
 414    935 Station Street
 415    Box Hill North, Victoria 3129
 416    AUSTRALIA
 417
 418    Phone: +61 3 9896 7830
 419      Fax: +61 3 9896 7801
 420    EMail: steven.legg@eb2bcom.com
 421
 422 Full Copyright Statement
 423
 424    Copyright (C) The Internet Society (2006).
 425
 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.
 429
 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.
 437
 438 Intellectual Property
 439
 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
 447
 448
 449
 450 Legg                      Expires 30 July 2006                  [Page 8]
 451 \f
 452 INTERNET-DRAFT      LDAP: The Binary Encoding Option    January 30, 2006
 453
 454
 455    found in BCP 78 and BCP 79.
 456
 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.
 463
 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
 468    ietf-ipr@ietf.org.
 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 30 July 2006                  [Page 9]
 507 \f