upstream/openldap
1
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2026-02-02 11:59:45 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

Latest revisions

Browse source
This commit is contained in:
Kurt Zeilenga 2005-11-25 19:23:13 +00:00
parent 44a1f10d97
commit 186b8700ae
20 changed files with 10708 additions and 8404 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3142
doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt
View file

File diff suppressed because it is too large Load diff

7482
doc/drafts/draft-ietf-ldapbis-protocol-xx.txt
View file

File diff suppressed because it is too large Load diff

52
doc/drafts/draft-ietf-ldapbis-strprep-xx.txt
View file

@ -3,14 +3,15 @@
Internet-Draft Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 9 February 2005
Expires in six months 30 September 2005
LDAP: Internationalized String Preparation
<draft-ietf-ldapbis-strprep-05.txt>
<draft-ietf-ldapbis-strprep-06.txt>
@ -22,11 +23,10 @@ Status of this Memo
mailing list <ietf-ldapbis@openldap.org>. Please send editorial
comments directly to the editor <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
@ -54,9 +54,10 @@ Status of this Memo
Zeilenga LDAPprep [Page 1]
Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
Abstract
@ -112,7 +113,7 @@ Conventions and Terms
Zeilenga LDAPprep [Page 2]
Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
For instance, the caseIgnoreMatch matching rule may be used to compare
@ -168,7 +169,7 @@ Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Zeilenga LDAPprep [Page 3]
Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
b) after applying the Unicode string preparation steps outlined in
@ -224,7 +225,7 @@ Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Zeilenga LDAPprep [Page 4]
Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
5) Check bidi
@ -280,7 +281,7 @@ Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Zeilenga LDAPprep [Page 5]
Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
these code points: U+0020, 00A0, 1680, 2000-200A, 2028-2029, 202F,
@ -336,7 +337,7 @@ Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Zeilenga LDAPprep [Page 6]
Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
characters insignificant to the matching rule. This modification
@ -392,7 +393,7 @@ Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Zeilenga LDAPprep [Page 7]
Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
2.6.3. telephoneNumber Insignificant Character Handling
@ -448,7 +449,7 @@ Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Zeilenga LDAPprep [Page 8]
Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
6. References
@ -490,7 +491,7 @@ Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
[X.680] International Telecommunication Union -
Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic
Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
6.2. Informative References
@ -504,7 +505,7 @@ Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Zeilenga LDAPprep [Page 9]
Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
[X.501] International Telecommunication Union -
@ -560,7 +561,7 @@ Appendix B. Substrings Matching
Zeilenga LDAPprep [Page 10]
Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
In absence of substrings matching, the insignificant space handling
@ -616,7 +617,7 @@ Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Zeilenga LDAPprep [Page 11]
Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
requirements.
@ -672,7 +673,7 @@ Intellectual Property Rights
Zeilenga LDAPprep [Page 12]
Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
Copies of IPR disclosures made to the IETF Secretariat and any
@ -692,9 +693,11 @@ Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
Full Copyright
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
@ -721,11 +724,8 @@ Full Copyright
Zeilenga LDAPprep [Page 13]

339
doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt
View file

@ -1,28 +1,29 @@
INTERNET-DRAFT Editor: A. Sciberras
Intended Category: Standard Track eB2Bcom
Updates: RFC 2247, RFC 2798, RFC 2377 April 4, 2005
Updates: RFC 2247, RFC 2798, RFC 2377 July 11, 2005
Obsoletes: RFC 2256
LDAP: Schema for User Applications
draft-ietf-ldapbis-user-schema-09.txt
draft-ietf-ldapbis-user-schema-10.txt
Copyright (C) The Internet Society (2005). All Rights Reserved.
Copyright (C) The Internet Society (2005). All Rights Reserved.
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3978. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3979.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, I accept the provisions of Section
3 of BCP 78.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
@ -37,23 +38,22 @@ Obsoletes: RFC 2256
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Revision Working Group
(LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please send
editorial comments directly to the editor
Distribution of this document is unlimited. Technical discussion of
this document should take place on the IETF LDAP Revision Working
Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
send editorial comments directly to the editor
<andrew.sciberras@eb2bcom.com>.
This Internet-Draft expires on 4 October 2005.
Copyright Notice
Copyright (C) The Internet Society 2005. All Rights Reserved.
This Internet-Draft expires on 11 January 2006.
Sciberras Expires 4 October 2005 [Page 1]
Sciberras Expires 11 January 2006 [Page 1]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Abstract
@ -107,9 +107,9 @@ Abstract
Sciberras Expires 4 October 2005 [Page 2]
Sciberras Expires 11 January 2006 [Page 2]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Table of Contents
@ -163,9 +163,9 @@ Table of Contents
Sciberras Expires 4 October 2005 [Page 3]
Sciberras Expires 11 January 2006 [Page 3]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
2.37 'telexNumber'. . . . . . . . . . . . . . . . . . . . . . 19
@ -206,7 +206,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
9. Intellectual Property Statement . . . . . . . . . . . . . . . 32
10. Disclaimer of Validity. . . . . . . . . . . . . . . . . . . . 32
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 32
@ -219,9 +219,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 4]
Sciberras Expires 11 January 2006 [Page 4]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
1. Introduction
@ -235,7 +235,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
administration of directory servers, nor does it include directory
objects defined for specific uses in other documents.
1.1 Relationship with other specifications
1.1 Relationship with other specifications
This document is an integral part of the LDAP technical specification
[Roadmap] which obsoletes the previously defined LDAP technical
@ -263,7 +263,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
1.2 Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.3 General Issues
@ -275,9 +275,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 5]
Sciberras Expires 11 January 2006 [Page 5]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
using the Augmented Backus-Naur Form (ABNF) [RFC2234] of
@ -331,9 +331,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 6]
Sciberras Expires 11 January 2006 [Page 6]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Examples: "DE", "AU" and "FR".
@ -387,9 +387,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 7]
Sciberras Expires 11 January 2006 [Page 7]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
2.5 'description'
@ -443,9 +443,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 8]
Sciberras Expires 11 January 2006 [Page 8]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
attribute types with a DN syntax can inherit.
@ -499,9 +499,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 9]
Sciberras Expires 11 January 2006 [Page 9]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
( 2.5.4.47 NAME 'enhancedSearchGuide'
@ -510,8 +510,8 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
[Syntaxes].
Examples: "person#(sn$APPROX)#wholeSubtree"
"organizationalUnit#(ou$SUBSTR)#oneLevel"
Examples: "person#(sn$APPROX)#wholeSubtree" and
"organizationalUnit#(ou$SUBSTR)#oneLevel".
2.10 'facsimileTelephoneNumber'
@ -526,7 +526,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone
Number syntax [Syntaxes].
Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution"
Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution".
2.11 'generationQualifier'
@ -550,14 +550,14 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
( 2.5.4.42 NAME 'givenName'
SUP name )
Examples: "Andrew", "Charles" and "Joanne"
Examples: "Andrew", "Charles" and "Joanne".
Sciberras Expires 4 October 2005 [Page 10]
Sciberras Expires 11 January 2006 [Page 10]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
2.13 'houseIdentifier'
@ -575,7 +575,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[Syntaxes].
Examples: "20" to represent a the house number 20.
Examples: "20" to represent the house number 20.
2.14 'initials'
@ -605,15 +605,15 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
[Syntaxes].
Example: "0198 333 333"
Example: "0198 333 333".
Sciberras Expires 4 October 2005 [Page 11]
Sciberras Expires 11 January 2006 [Page 11]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
2.16 'l'
@ -639,7 +639,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
SUP distinguishedName )
Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and
"cn=John Xerri,ou=Finance,o=Widget\, Inc" may
"cn=John Xerri,ou=Finance,o=Widget\, Inc." may
be two members of the financial team (group) at Widget,
Inc. In which case, both of these distinguished names would
be present as individual values of the member attribute.
@ -667,9 +667,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 12]
Sciberras Expires 11 January 2006 [Page 12]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
2.19 'o'
@ -711,7 +711,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Example: The mailing list object, whose DN is "cn=All Employees,
ou=Mailing List,o=Widget\, Inc.", is owned by the Human
Resources Director.
Therefore, the value of the owner attribute within the
Therefore, the value of the 'owner' attribute within the
mailing list object, would be the DN of the director (role):
"cn=Human Resources Director,ou=employee,o=Widget\, Inc.".
@ -723,9 +723,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 13]
Sciberras Expires 11 January 2006 [Page 13]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
@ -779,9 +779,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 14]
Sciberras Expires 11 January 2006 [Page 14]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
at a box on premises of the Postal Service. Each postal box
@ -813,7 +813,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Example: If the mhs-delivery Delivery Method is preferred over
telephone-delivery, which is preferred over all other
methods, the value would be: "mhs $ telephone"
methods, the value would be: "mhs $ telephone".
2.27 'registeredAddress'
@ -835,9 +835,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 15]
Sciberras Expires 11 January 2006 [Page 15]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
2.28 'roleOccupant'
@ -872,14 +872,13 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [Syntaxes].
Example: "person#sn$EQ"
Example: "person#sn$EQ".
2.30 'seeAlso'
The 'seeAlso' attribute type contains Distinguished Names of objects
that are related to the subject object. Each related object name is
one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.34 NAME 'seeAlso'
@ -888,15 +887,15 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Example: The person object, "cn=James Brown,ou=employee,o=Widget\,
Inc." is related to the role objects, "cn=Football Team
Captain,ou=sponsored activities,o=Widget\, Inc." and
Sciberras Expires 4 October 2005 [Page 16]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
"cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.".
Sciberras Expires 11 January 2006 [Page 16]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Since the role objects are related to the person object, the
'seeAlso' attribute will contain the distinguished name of
each role object as separate values.
@ -928,7 +927,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
( 2.5.4.4 NAME 'sn'
SUP name )
Example: "Smith"
Example: "Smith".
2.33 'st'
@ -947,9 +946,10 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 17]
Sciberras Expires 11 January 2006 [Page 17]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
2.34 'street'
@ -968,7 +968,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[Syntaxes].
Example: "15 Main St."
Example: "15 Main St.".
2.35 'telephoneNumber'
@ -1003,9 +1003,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 18]
Sciberras Expires 11 January 2006 [Page 18]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
2.37 'telexNumber'
@ -1021,7 +1021,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax
[Syntaxes].
Example: "12345$023$ABCDE"
Example: "12345$023$ABCDE".
2.38 'title'
@ -1032,8 +1032,6 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
( 2.5.4.12 NAME 'title'
SUP name )
Examples: "Vice President", "Software Engineer" and "CEO".
2.39 'uid'
@ -1056,16 +1054,16 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
2.40 'uniqueMember'
The 'uniqueMember' attribute type contains the Distinguished Names of
Sciberras Expires 4 October 2005 [Page 19]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
an object that is on a list or in a group, where the Relative
Distinguished Names of the object include a value that distinguishes
Sciberras Expires 11 January 2006 [Page 19]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
between objects when a distinguished name has been reused. Each
distinguished name is one value of this multi-valued attribute.
(Source: X.520 [X.520])
@ -1089,7 +1087,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
string is one value of this multi-valued attribute.
The application SHOULD prepare textual strings used as passwords by
transcoding them to Unicode, applying SASLprep [SASLprep], and
transcoding them to Unicode, applying SASLprep [RFC4013], and
encoding as UTF-8. The determination of whether a password is
textual is a local client matter.
(Source: X.509 [X.509])
@ -1112,16 +1110,16 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
to use a different password generated by some automated system.
During transitional periods, like the last and first day of the
periods, it may be necessary to allow two passwords for the two
Sciberras Expires 4 October 2005 [Page 20]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
consecutive periods to be valid in the system.
Sciberras Expires 11 January 2006 [Page 20]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
2.42 'x121Address'
The 'x121Address' attribute type contains data network addresses as
@ -1171,9 +1169,11 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 21]
Sciberras Expires 11 January 2006 [Page 21]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
3. Object Classes
@ -1209,7 +1209,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
MAY ( searchGuide $
description ) )
3.3 'dcObject'
3.3 'dcObject'
The 'dcObject' object class permits an entry to contains domain
component information. This object class is defined as auxiliary,
@ -1227,9 +1227,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 22]
Sciberras Expires 11 January 2006 [Page 22]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
3.4 'device'
@ -1283,9 +1283,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 23]
Sciberras Expires 11 January 2006 [Page 23]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
cn )
@ -1339,9 +1339,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 24]
Sciberras Expires 11 January 2006 [Page 24]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
( 2.5.6.7 NAME 'organizationalPerson'
@ -1395,9 +1395,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 25]
Sciberras Expires 11 January 2006 [Page 25]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
3.12 'person'
@ -1433,7 +1433,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ st $ l ) )
3.14 'uidObject'
3.14 'uidObject'
The 'uidObject' object class permits an entry to contains user
identification information. This object class is defined as
@ -1451,9 +1451,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 26]
Sciberras Expires 11 January 2006 [Page 26]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
4. IANA Considerations
@ -1471,8 +1471,6 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Specification: RFC XXXX [editor's note: The RFC number will be
the one assigned to this document.]
Author/Change Controller: IESG
Comments
In the LDAP descriptors registry, the following descriptors (short
names) should be updated to refer to RFC XXXX [editor's note: This
@ -1504,16 +1502,16 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
GN A RESERVED
groupOfNames O 2.5.6.9
groupOfUniqueNames O 2.5.6.17
Sciberras Expires 4 October 2005 [Page 27]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
houseIdentifier A 2.5.4.51
initials A 2.5.4.43
Sciberras Expires 11 January 2006 [Page 27]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
internationalISDNNumber A 2.5.4.25
L A 2.5.4.7
locality O 2.5.6.3
@ -1560,24 +1558,24 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
5. Security Considerations
Attributes of directory entries are used to provide descriptive
Sciberras Expires 4 October 2005 [Page 28]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
information about the real-world objects they represent, which can be
people, organizations or devices. Most countries have privacy laws
Sciberras Expires 11 January 2006 [Page 28]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
regarding the publication of information about people.
Transfer of cleartext passwords is strongly discouraged where the
underlying transport service cannot guarantee confidentiality and may
result in disclosure of the password to unauthorized parties.
Multiple attribute values for the 'userPassword' needs to be used
with care. Especially reset/deletion of a password by an admin
Multiple attribute values for the 'userPassword' attribute need to be
used with care. Especially reset/deletion of a password by an admin
without knowing the old user password gets tricky or impossible if
multiple values for different applications are present.
@ -1585,13 +1583,14 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
value(s) with new value(s) should use modify/replaceValues (or
modify/deleteAttribute+addAttribute). Additionally, server
implementations are encouraged to provide administrative controls
which, if enabled, restrict the 'userPassword' attributer to one
which, if enabled, restrict the 'userPassword' attribute to one
value.
Note that when used for authentication purposes [AuthMeth], the user
need only prove knowledge of one of the values, not all of the
values.
6. Acknowledgements
The definitions, on which this document is based, have been developed
@ -1610,7 +1609,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
The 'uidObject' object class definition in this document supersedes
the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R.
Huber, S, Sataluri and M. Smith.
Huber, S. Sataluri and M. Smith.
This document is based upon input of the IETF LDAPBIS working group.
The author wishes to thank S. Legg and K. Zeilenga for their
@ -1619,9 +1618,10 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 29]
Sciberras Expires 11 January 2006 [Page 29]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
7. References
@ -1660,28 +1660,26 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003
[RFC4013] Zeilenga K., "SASLprep: Stringprep profile for User
Names and Passwords", RFC 4013, February 2005.
[Roadmap] Zeilenga, K., "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx (a work in
progress)
[SASLprep] Zeilenga K., "SASLprep: Stringprep profile for user
names and passwords", draft-ietf-sasl-saslprep-xx (a
work in progress)
[Syntaxes] S. Legg (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
syntaxes-xx (a work in progress)
[X.121] International numbering plan for public data networks,
Sciberras Expires 4 October 2005 [Page 30]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
ITU-T Recommendation X.121, 1996
Sciberras Expires 11 January 2006 [Page 30]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
[X.509] The Directory: Authentication Framework, ITU-T
Recommendation X.509, 1993
@ -1715,7 +1713,10 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
[RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
Class", RFC 2798, April 2000
[X.500] The Directory, ITU-T Recommendations X.501-X.525, 1993
[X.500] ITU-T Recommendations X.5000 (1993) | ISO/IEC
9594-1:1994, Information Technology - Open Systems
Interconnection - The Directory: Overview of concepts,
models and services.
8. Author's Address
@ -1727,15 +1728,16 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
AUSTRALIA
Phone: +61 3 9896 7833
Email: andrew.sciberras@eb2bcom.com
Sciberras Expires 4 October 2005 [Page 31]
Sciberras Expires 11 January 2006 [Page 31]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Email: andrew.sciberras@eb2bcom.com
9. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
@ -1760,7 +1762,13 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
10. Disclaimer of Validity
10. Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
@ -1770,10 +1778,6 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright (C) The Internet Society (2005). This
document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
@ -1783,13 +1787,9 @@ Copyright Statement Copyright (C) The Internet Society (2005). This
Sciberras Expires 4 October 2005 [Page 32]
Sciberras Expires 11 January 2006 [Page 32]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Appendix A Changes Made Since RFC 2256
@ -1843,9 +1843,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 33]
Sciberras Expires 11 January 2006 [Page 33]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
12. Numerous edititorial changes.
@ -1899,9 +1899,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 34]
Sciberras Expires 11 January 2006 [Page 34]
INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
30. Spelt out and referenced ABNF on first usage.
@ -1955,6 +1955,5 @@ INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Sciberras Expires 4 October 2005 [Page 35]
Sciberras Expires 11 January 2006 [Page 35]

291
doc/drafts/draft-legg-ldap-binary-xx.txt
View file

@ -1,21 +1,29 @@
INTERNET-DRAFT S. Legg
draft-legg-ldap-binary-01.txt Adacel Technologies
Intended Category: Standards Track 16 June 2004
Updates: RFC 2251bis
draft-legg-ldap-binary-03.txt eB2Bcom
Intended Category: Standards Track 7 June 2005
Updates: [SYNTAX]
Lightweight Directory Access Protocol (LDAP):
The Binary Encoding Option
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright (C) The Internet Society (2005). All Rights Reserved.
Status of this Memo
By submitting this Internet-draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
By submitting this Internet-draft, I accept the provisions of Section
3 of BCP 78.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
@ -28,21 +36,17 @@ Updates: RFC 2251bis
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
http://www.ietf.org/shadow.html
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this document is unlimited. Technical discussion of
this document should take place on the IETF LDAP Revision Working
Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
send editorial comments directly to the editor
<steven.legg@adacel.com.au>.
This Internet-Draft expires on 16 December 2004.
Technical discussion of this document should take place on the IETF
LDAP Revision Working Group (LDAPbis) mailing list
<ietf-ldapbis@openldap.org>. Please send editorial comments directly
to the editor <steven.legg@eb2bcom.com>.
This Internet-Draft expires on 7 December 2005.
Abstract
@ -51,9 +55,9 @@ Abstract
Legg Expires 16 December 2004 [Page 1]
Legg Expires 7 December 2005 [Page 1]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
definition specifies how attribute values conforming to the syntax
@ -107,9 +111,9 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
Legg Expires 16 December 2004 [Page 2]
Legg Expires 7 December 2005 [Page 2]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
Table of Contents
@ -124,9 +128,9 @@ Table of Contents
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References. . . . . . . . . . . . . . . . . . 6
10.1. Normative References. . . . . . . . . . . . . . . . . . 7
10.2. Informative References. . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
@ -143,10 +147,10 @@ Table of Contents
This document defines an attribute option, the binary option, which
can be used in an attribute description [MODELS] in an LDAP operation
to specify that the associated attribute values or assertion value
to specify that the associated attribute values or assertion values
are, or are requested to be, encoded according to the Basic Encoding
Rules (BER) [BER] as used by X.500 [X500] directories, instead of the
usual LDAP-specific encoding.
Rules (BER) [BER] as used by X.500 [X.500] directories, instead of
the usual LDAP-specific encoding.
The binary option was originally defined in RFC 2251 [RFC2251]. The
LDAP technical specification [ROADMAP] has obsoleted the previously
@ -163,9 +167,9 @@ Table of Contents
Legg Expires 16 December 2004 [Page 3]
Legg Expires 7 December 2005 [Page 3]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
2. Conventions
@ -182,48 +186,52 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
options, the string representing the binary option is case
insensitive.
Where the binary option is present in an attribute description the
associated attribute values or assertion values MUST be BER encoded
(otherwise the values are encoded according to the LDAP-specific
encoding [SYNTAX] for the attribute's syntax). Note that it is
possible for a syntax to be defined such that its LDAP-specific
encoding is exactly the same as its BER encoding.
In terms of the protocol [PROT], the binary option specifies that the
contents octets of the associated AttributeValue or AssertionValue
OCTET STRING are a complete BER encoding of the relevant value.
Where the binary option is present in an attribute description the
associated attribute values or assertion value MUST be BER encoded.
Note that it is possible for a syntax to be defined such that its
LDAP-specific encoding is exactly the same as its BER encoding.
The binary option is not a tagging option [MODELS] so the presence of
the binary option does not specify an attribute subtype. An
attribute description containing the binary option references exactly
the same attribute as the same attribute description without the
binary option. The supertype/subtype relationships of attributes
with tagging options are not altered in any way by the presence or
absence of the binary option.
the same attribute as the attribute description without the binary
option. The supertype/subtype relationships of attributes with
tagging options are not altered in any way by the presence or absence
of the binary option.
An attribute description SHALL be treated as unrecognized if it
contains the binary option and the syntax of the attribute does not
have an associated ASN.1 type [SYNTAX], or the BER encoding of that
type is not supported.
have an associated ASN.1 type [SYNTAX], or the BER encoding of values
of that type is not supported.
The presence or absence of the binary option only affects the
transfer of attribute and assertion values in protocol; servers store
any particular attribute value in a single format of their choosing.
any particular attribute value in a format of their choosing.
4. Syntaxes Requiring Binary Transfer
Certain syntaxes are required to be transferred in the BER encoded
form. These syntaxes are said to have a binary transfer requirement.
The Certificate, Certificate List, Certificate Pair and Supported
The attribute values of certain attribute syntaxes are defined
without an LDAP-specific encoding and are required to be transferred
in the BER encoded form. For the purposes of this document, these
syntaxes are said to have a binary transfer requirement. The
Legg Expires 7 December 2005 [Page 4]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
Certificate, Certificate List, Certificate Pair and Supported
Algorithm syntaxes [PKI] are examples of syntaxes with a binary
transfer requirement. These syntaxes also have an additional
requirement that the exact BER encoding must be preserved. Note that
Legg Expires 16 December 2004 [Page 4]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
this is a property of the syntaxes themselves, and not a property of
the binary option.
@ -244,21 +252,22 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
applies to all the subtypes of the attribute type in the attribute
description (however, see Section 7).
Attributes of a syntax with the binary transfer requirement SHALL be
returned in the binary form, i.e., with the binary option in the
attribute description and the associated attribute values BER
encoded, regardless of whether the binary option was present in the
request (for the attribute or for one of its supertypes).
Attributes of a syntax with the binary transfer requirement, if
returned, SHALL be returned in the binary form, i.e., with the binary
option in the attribute description and the associated attribute
values BER encoded, regardless of whether the binary option was
present in the request (for the attribute or for one of its
supertypes).
Attributes of a syntax without the binary transfer requirement SHOULD
be returned in the form explicitly requested. That is, if the
attribute description in the requested attributes list contains the
binary option then the corresponding attribute in the result SHOULD
be in the binary form. If the attribute description in the request
does not contain the binary option then the corresponding attribute
in the result SHOULD NOT be in the binary form. A server MAY omit an
attribute from the result if it does not support the requested
encoding.
Attributes of a syntax without the binary transfer requirement, if
returned, SHOULD be returned in the form explicitly requested. That
is, if the attribute description in the requested attributes list
contains the binary option then the corresponding attribute in the
result SHOULD be in the binary form. If the attribute description in
the request does not contain the binary option then the corresponding
attribute in the result SHOULD NOT be in the binary form. A server
MAY omit an attribute from the result if it does not support the
requested encoding.
Regardless of the encoding chosen, a particular attribute value is
returned at most once.
@ -267,18 +276,18 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
If the list of attributes in a search request is empty, or contains
the special attribute description string "*", then all user
Legg Expires 7 December 2005 [Page 5]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
attributes are requested to be returned.
Attributes of a syntax with the binary transfer requirement SHALL be
returned in the binary form.
Legg Expires 16 December 2004 [Page 5]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
Attributes of a syntax with the binary transfer requirement, if
returned, SHALL be returned in the binary form.
Attributes of a syntax without the binary transfer requirement and
having a defined LDAP-specific encoding SHOULD NOT be returned in the
@ -295,8 +304,8 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
of one or more of its supertypes, or by the special attribute
description string "*". If the binary option is not present in all
these attribute descriptions, nor absent in all these attribute
descriptions, then the server is free to choose whether to return the
attribute in the binary form.
descriptions, then the effect of the request with respect to binary
transfer is implementation defined.
8. Security Considerations
@ -311,12 +320,12 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
the LDAP attribute description option registry [BCP64] as indicated
by the following template:
Subject: Request for
LDAP Attribute Description Option Registration
Subject:
Request for LDAP Attribute Description Option Registration
Option Name: binary
Family of Options: NO
Person & email address to contact for further information:
Steven Legg <steven.legg@adacel.com.au>
Steven Legg <steven.legg@eb2bcom.com>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: The existing registration for "binary"
@ -324,18 +333,18 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
10. References
Legg Expires 7 December 2005 [Page 6]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
10.1. Normative References
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Legg Expires 16 December 2004 [Page 6]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
[BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access
Protcol (LDAP)", BCP 64, RFC 3383, September 2002.
@ -343,25 +352,25 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
[ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map",
draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
June 2004.
February 2005.
[MODELS] Zeilenga, K., "LDAP: Directory Information Models",
draft-ietf-ldapbis-models-xx.txt, a work in progress, June
2004.
draft-ietf-ldapbis-models-xx.txt, a work in progress,
February 2005.
[PROT] Sermersheim, J., "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
May 2004.
February 2005.
[SYNTAX] Legg, S. and K. Dally, "Lightweight Directory Access
Protocol (LDAP): Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress,
May 2004.
February 2005.
[PKI] Chadwick, D. and S. Legg, "Internet X.509 Public Key
Infrastructure Additional LDAP Schema for PKIs and PMIs",
draft-pkix-ldap-schema-xx.txt, a work in progress, April
2002.
[PKI] Zeilenga, Kurt D., "Lightweight Directory Access Protocol
(LDAP) schema definitions for X.509 Certificates",
draft-zeilenga-ldap-x509-xx.txt, a work in progress,
February 2005.
[BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
Information Technology - ASN.1 encoding rules:
@ -378,35 +387,38 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[X500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
[X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Legg Expires 7 December 2005 [Page 7]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
"Information Technology - Open Systems Interconnection -
The Directory: Overview of concepts, models and services".
Author's Address
Legg Expires 16 December 2004 [Page 7]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
Steven Legg
Adacel Technologies Ltd.
250 Bay Street
Brighton, Victoria 3186
eB2Bcom
Suite 3, Woodhouse Corporate Centre
935 Station Street
Box Hill North, Victoria 3129
AUSTRALIA
Phone: +61 3 8530 7710
Fax: +61 3 8530 7888
Email: steven.legg@adacel.com.au
Phone: +61 3 9896 7830
Fax: +61 3 9896 7801
EMail: steven.legg@eb2bcom.com
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
@ -432,6 +444,14 @@ Intellectual Property
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
Legg Expires 7 December 2005 [Page 8]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
@ -443,6 +463,45 @@ Intellectual Property
Legg Expires 16 December 2004 [Page 8]
Legg Expires 7 December 2005 [Page 9]

1220
doc/drafts/draft-sermersheim-ldap-csn-xx.txt
View file

File diff suppressed because it is too large Load diff

132
doc/drafts/draft-weltman-ldapv3-proxy-xx.txt
View file

@ -1,11 +1,11 @@
INTERNET-DRAFT Rob Weltman
Intended Category: Standards Track Netscape Communications Corp.
April 2003
Intended Category: Standards Track Yahoo!, Inc.
June 2005
LDAP Proxied Authorization Control
draft-weltman-ldapv3-proxy-12.txt
draft-weltman-ldapv3-proxy-13.txt
Status of this Memo
@ -13,20 +13,24 @@ Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Task Force
(IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
http://www.ietf.org/shadow.html
Abstract
@ -50,16 +54,16 @@ Abstract
identity distinct from the authentication identity, where the
authorization identity applies to the whole LDAP session. The Proxy
Authorization Control provides a mechanism for specifying an
Expires December 2005 [Page 1]
PROXIED AUTHORIZATION CONTROL June 2005
authorization identity on a per operation basis, benefiting clients
that need to efficiently perform operations on behalf of multiple
users.
Expires October 2003 [Page 1]
PROXIED AUTHORIZATION CONTROL April 2003
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
used in this document are to be interpreted as described in
[KEYWORDS].
@ -88,6 +92,13 @@ PROXIED AUTHORIZATION CONTROL April 2003
protects clients from submitting a request that is executed with an
unintended authorization identity.
Clients MUST include the criticality flag and MUST set it to TRUE.
Servers MUST reject any request containing a Proxy Authorization
Control without a criticality flag or with the flag set to FALSE with
a protocolError error. These requirements protect clients from
submitting a request that is executed with an unintended
authorization identity.
The controlValue SHALL be present and contain either an authzId
[AUTH] representing the authorization identity for the request or
empty if an anonymous association is to be used.
@ -102,6 +113,12 @@ PROXIED AUTHORIZATION CONTROL April 2003
[Note to the IESG/IANA/RFC Editor: the value TBD is to be replaced
with an IANA assigned LDAP Result Code (see RFC 3383 section 3.6]
Expires December 2005 [Page 2]
PROXIED AUTHORIZATION CONTROL June 2005
4. Implementation Considerations
@ -113,12 +130,6 @@ PROXIED AUTHORIZATION CONTROL April 2003
requester does not have the right to assume the requested identity
for searching the entry, even if the entry is within the scope of a
search request under a base DN which does imply such rights. This
Expires October 2003 [Page 2]
PROXIED AUTHORIZATION CONTROL April 2003
means that fewer results, or no results, may be returned compared to
the case where the proxy authorization identity issued the request
directly. An example of such a case may be a system with fine-grained
@ -155,7 +166,25 @@ PROXIED AUTHORIZATION CONTROL April 2003
7. Copyright
Copyright (C) The Internet Society (date). All Rights Reserved.
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Expires December 2005 [Page 3]
PROXIED AUTHORIZATION CONTROL June 2005
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
@ -172,21 +201,8 @@ PROXIED AUTHORIZATION CONTROL April 2003
English.
The limited permissions granted above are perpetual and will not be
Expires October 2003 [Page 3]
PROXIED AUTHORIZATION CONTROL April 2003
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
8. Normative References
@ -215,6 +231,12 @@ PROXIED AUTHORIZATION CONTROL April 2003
[RFC 2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997
Expires December 2005 [Page 4]
PROXIED AUTHORIZATION CONTROL June 2005
[RFC 2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
"Authentication Methods for LDAP", RFC 2829, May 2000
@ -226,27 +248,20 @@ PROXIED AUTHORIZATION CONTROL April 2003
9. Author's Address
Rob Weltman
Netscape Communications Corp.
360 W. Caribbean Drive
Yahoo!, Inc
701 First Avenue
Sunnyvale, CA 94089
USA
Expires October 2003 [Page 4]
PROXIED AUTHORIZATION CONTROL April 2003
+1 650 937-3194
rweltman@netscape.com
+1 408 349-5504
robw@worldspot.com
10. Acknowledgements
Mark Smith of Netscape Communications Corp., Mark Wahl of Sun
Microsystems, Inc, Kurt Zeilenga of OpenLDAP Foundation, Jim
Sermersheim of Novell, and Steven Legg of Adacel have contributed
with reviews of this document.
Mark Smith, formerly of Netscape Communications Corp., Mark Wahl,
formerly of Sun Microsystems, Inc, Kurt Zeilenga of OpenLDAP
Foundation, Jim Sermersheim of Novell, and Steven Legg of Adacel have
contributed with reviews of this document.
@ -267,21 +282,6 @@ PROXIED AUTHORIZATION CONTROL April 2003
@ -291,5 +291,5 @@ PROXIED AUTHORIZATION CONTROL April 2003
Expires October 2003 [Page 5]
Expires December 2005 [Page 5]

241
doc/drafts/draft-zeilenga-ldap-adlist-xx.txt
View file

@ -3,14 +3,16 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Informational OpenLDAP Foundation
Expires in six months 18 July 2004
Expires in six months 18 July 2005
Requesting Attributes by Object Class in the
Lightweight Directory Access Protocol
<draft-zeilenga-ldap-adlist-08.txt>
<draft-zeilenga-ldap-adlist-11.txt>
Status of this Memo
@ -22,11 +24,10 @@ Status of this Memo
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
@ -38,43 +39,47 @@ Status of this Memo
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
http://www.ietf.org/1id-abstracts.html
Copyright (C) The Internet Society (2004). All Rights Reserved.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Abstract
The Lightweight Directory Access Protocol (LDAP) search operation
Zeilenga Requesting Attributes by Object Class [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
Abstract
The Lightweight Directory Access Protocol (LDAP) search operation
provides mechanisms for clients to request all user application
attributes, all operational attributes, and/or attributes selected by
their description. This document extends LDAP to support a mechanism
that LDAP clients may use to request the return of all attributes
belonging to an object class.
that LDAP clients may use to request the return of all attributes of
an object class.
1. Overview
1. Background and Intended Use
In the Lightweight Directory Access Protocol (LDAP) [RFC3377], the
search operation [RFC2251] support requesting a sets of attributes.
This set is determined by a list of attribute descriptions. Two
special descriptors are defined to request all user attributes ("*")
[RFC2251] and all operational attributes ("+") [RFC3673]. However,
there is no convenient mechanism for requesting pre-defined sets of
attributes.
In the Lightweight Directory Access Protocol (LDAP) [Roadmap], the
search operation [Protocol] support requesting the return of a set of
attributes. This set is determined by a list of attribute
descriptions. Two special descriptors are defined to request all user
attributes ("*") [Protocol] and all operational attributes ("+")
[RFC3673]. However, there is no convenient mechanism for requesting
pre-defined sets of attributes such as the set of attributes used to
represent a particular class of object.
This document extends LDAP to allow an object class identifier to be
specified in attributes lists, such as in Search requests, to request
@ -84,13 +89,12 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
For example, the attribute list of "@country" is equivalent to the
attribute list of 'c', 'searchGuide', 'description', and
'objectClass'. This object class and its attributes are described in
[RFC2256].
This extension is intended to be used where the user is in direct
control of the parameters of the LDAP search operation, such as when
entering a LDAP URL [RFC2255] into a web browser.
'objectClass'. This object class is described in [Schema].
This extension is intended primarily to be used where the user is in
direct control of the parameters of the LDAP search operation, for
instance when entering a LDAP URL [LDAPURL] into a web browser. For
example, <ldap:///dc=example,dc=com?@organization?base>.
2. Terminology
@ -104,51 +108,50 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
3. Return of all Attributes of an Object Class
This extension allows object class identifiers is to be provided in
the attributes field of the LDAP SearchRequest [RFC2251] or other
request structures who borrow the attributes field and its semantics
Zeilenga Requesting Attributes by Object Class [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
(e.g., attributes field in pre/post read controls [READENTRY]). For
each object class identified in the attributes field, the request is
to be treated as if each attribute allowed by that class (by "MUST" or
"MAY", directly or by "SUP"erior) was itself listed.
This extension allows object class identifiers is to be provided in
the attributes field of the LDAP SearchRequest [Protocol] or other
request values of the AttributeSelection data type (e.g., attributes
field in pre/post read controls [ReadEntry]) and/or
<attributeSelector> production (e.g., attributes of an LDAP URL
[LDAPURL]). For each object class identified in the attributes field,
the request is to be treated as if each attribute allowed by that
class (by "MUST" or "MAY", directly or by "SUP"erior) [Models] was
itself listed.
If the object class identifier is unrecognized, it is be treated an an
unrecognized attribute description.
This extension extends attributeSelector [Protocol] production as
indicated by the following ABNF [ABNF]:
This extension redefines the attributes field of the SearchRequest to
be a DescriptionList described by the following ASN.1 [X.680] data
type:
attributeSelector /= objectclassdescription
objectclassdescription = ATSIGN oid options
ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040)
DescriptionList ::= SEQUENCE OF Description
Description ::= LDAPString
where <oid> and <options> productions are as defined in [Models].
The Description is string conforming to the ABNF [RFC2234]:
The <oid> component of an <objectclassdescription> production
identifies the object class by short name (descr) or object identifier
(numericoid). If the value of the <oid> component is unrecognized or
does not refer to an object class, the object class description is be
treated an an unrecognized attribute description.
Description = AttributeDescription | ObjectClassDescription.
ObjectClassDescription = AtSign ObjectClass *( ";" options )
AtSign = "@" ; U+0040
The <options> production is included in the grammar for extensibility
purposes. An object class description with an unrecognized or
inappropriate option is to be treated as an unrecognized.
where <AttributeDescription> and <options> productions are as defined
in Section 4.1.5 of [RFC2251] and an <ObjectClass> is an object
identifier, in either <numericoid> or <descr> form [RFC2252], of an
object class.
<ObjectClassDescription> <options> are provided for extensibility.
This document only defines semantics of <ObjectClassDescription>s with
zero options in the attributes field of a SearchRequest. Other uses
may be defined in future specifications.
While object class description options and attribute description
options share the same syntax, they are not semantically related.
This document does not define any object description option.
Servers supporting this feature SHOULD publish the object identifier
(OID) IANA-ASSIGNED-OID as a value of the 'supportedFeatures'
[RFC3674] attribute in the root DSE. Clients supporting this feature
(OID) 1.3.6.1.4.1.4203.1.5.2 as a value of the 'supportedFeatures'
[Models] attribute in the root DSE. Clients supporting this feature
SHOULD NOT use the feature unless they have knowledge the server
supports it.
@ -157,23 +160,25 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
This extension provides a shorthand for requesting all attributes of
an object class. As these attributes which could have been listed
individually, this shorthand is not believed to raise additional
security considerations.
Implementors of this (or any) LDAP extension should be familiar with
general LDAP security considerations [RFC3377].
individually, introduction of this shorthand is not believed to raise
additional security considerations.
Implementors of this LDAP extension should be familiar with security
Zeilenga Requesting Attributes by Object Class [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
considerations applicable to the LDAP search operation [Protocol], as
well as general LDAP security considerations [Roadmap].
4. IANA Considerations
Registration of the LDAP Protocol Mechanism [RFC3383] defined in
Registration of the LDAP Protocol Mechanism [BCP64bis] defined in
document is requested.
Subject: Request for LDAP Protocol Mechanism Registration
@ -199,57 +204,63 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
Email: Kurt@OpenLDAP.org
6. Normative References
6. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", draft-crocker-abnf-rfc2234bis, a
work in progress.
[RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674,
Zeilenga Requesting Attributes by Object Class [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
December 2003.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
draft-ietf-ldapbis-url-xx.txt, a work in progress.
[X.680] International Telecommunication Union -
Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic
Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
7. Informative References
[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
December, 1997.
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for
use with LDAPv3", RFC 2256, December 1997.
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
6.2. Informative References
[RFC3673] Zeilenga, K., "LDAPv3: All Operational Attributes", RFC
3673, December 2003.
[READENTRY] Zeilenga, K., "LDAP Read Entry Controls",
[Schema] Dally, K. (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in
progress.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
[ReadEntry] Zeilenga, K., "LDAP Read Entry Controls",
draft-zeilenga-ldap-readentry-xx.txt, a work in
progress.
@ -263,9 +274,19 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
Full Copyright
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Copyright (C) The Internet Society (2005).
Zeilenga Requesting Attributes by Object Class [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
@ -277,12 +298,6 @@ Full Copyright
Zeilenga Requesting Attributes by Object Class [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
@ -313,20 +328,6 @@ Intellectual Property Rights
@ -336,5 +337,3 @@ Intellectual Property Rights
Zeilenga Requesting Attributes by Object Class [Page 6]

172
doc/drafts/draft-zeilenga-ldap-assert-xx.txt
View file

@ -5,11 +5,12 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 18 July 2004
Expires in six months 10 February 2005
The LDAP Assertion Control
<draft-zeilenga-ldap-assert-03.txt>
<draft-zeilenga-ldap-assert-05.txt>
Status of this Memo
@ -37,28 +38,31 @@ Status of this Memo
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
http://www.ietf.org/1id-abstracts.html
Copyright (C) The Internet Society (2004). All Rights Reserved.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga LDAP Assertion Control [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
Abstract
This document defines the Lightweight Directory Access Protocol (LDAP)
Assertion Control which allows a client to specify that a directory
Zeilenga LDAP Assertion Control [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
operation should only be processed if an assertion applied to the
target entry of the operation is true. It can be used to construct
"test and set" and "test and clear" and other conditional operations.
@ -67,15 +71,16 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
1. Overview
This document defines the Lightweight Directory Access Protocol (LDAP)
[RFC3377] assertion control. The assertion control allows the client
[Roadmap] assertion control. The assertion control allows the client
to specify a condition which must be true for the operation to be
processed normally. Otherwise the operation fails.
processed normally. Otherwise the operation fails. For instance, the
control can be used with the Modify operation [Protocol] to perform
atomic "test and set" and "test and clear" operations.
The control can be used with the Modify operation [RFC2251] to perform
atomic "test and set" and "test and clear" operations as the asserted
condition is evaluated as an integral part the operation. The control
may be attached to other update operations to support conditional
addition, deletion, and renaming of objects.
The control may be attached to any update operation to support
conditional addition, deletion, modification, and renaming of the
target object. The asserted condition is evaluated as an integral
part the operation.
The control may also be used with the search operation. Here the
assertion is applied to the base object of the search before searching
@ -90,7 +95,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
Protocol elements are described using ASN.1 [X.680] with implicit
tags. The term "BER-encoded" means the element is to be encoded using
the Basic Encoding Rules [X.690] under the restrictions detailed in
Section 5.1 of [RFC2251].
Section 5.2 of [Protocol].
DSA stands for Directory System Agent (or server).
DSE stands for DSA-specific Entry.
@ -102,24 +107,23 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
3. The Assertion Control
The assertion control is an LDAP Control [RFC2251] whose controlType
is IANA-ASSIGNED-OID and controlValue is a BER-encoded Filter
[RFC2251, Section 4.5.1]. The criticality may be TRUE or FALSE.
There is no corresponding response control.
Zeilenga LDAP Assertion Control [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
The assertion control is an LDAP Control [Protocol] whose controlType
is IANA-ASSIGNED-OID and controlValue is a BER-encoded Filter
[Protocol, Section 4.5.1]. The criticality may be TRUE or FALSE.
There is no corresponding response control.
The control is appropriate for both LDAP interrogation and update
operations [RFC2251] including Add, Compare, Delete, Modify, ModifyDN
operations [Protocol] including Add, Compare, Delete, Modify, ModifyDN
(rename), and Search. It is inappropriate for Abandon, Bind nor
Unbind operations. It is also inappropriate for the Start TLS
[RFC2830] operation.
Unbind, and Start TLS operations.
When the control is attached to an LDAP request, the processing of the
request is conditional on the evaluation of the Filter as applied
@ -138,14 +142,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
For search operation, the target is indicated by the baseObject field
and the evaluation is done after "finding" but before "searching"
[RFC2251]. Hence, no entries or continuations references are returned
if the assertion fails.
[Protocol]. Hence, no entries or continuations references are
returned if the assertion fails.
Servers implementing this technical specification SHOULD publish the
object identifier IANA-ASSIGNED-OID as a value of the
'supportedControl' attribute [RFC2252] in their root DSE. A server
MAY choose to advertise this extension only when the client is
authorized to use it.
'supportedControl' attribute [Models] in their root DSE. A server MAY
choose to advertise this extension only when the client is authorized
to use it.
Other documents may specify how this control applies to other LDAP
operations. In doing so, they must state how the target entry is
@ -159,24 +163,25 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
appropriately protected.
As with any general assertion mechanism, the mechanism can be used to
determine directory content. Hence, this mechanism SHOULD be subject
to appropriate access controls.
Some assertions may be very complex, requiring significant time and
Zeilenga LDAP Assertion Control [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
determine directory content. Hence, this mechanism SHOULD be subject
to appropriate access controls.
Some assertions may be very complex, requiring significant time and
resources to evaluate. Hence, this mechanism SHOULD be subject to
appropriate administrative controls.
All security considerations for the base operations [RFC2251] to which
this control is attached to apply, as do general LDAP security
considerations [RFC3377].
Security considerations for the base operations [Protocol] extended by
this control, as well as general LDAP security considerations
[Roadmap], generally apply to implementation and use of this
extension.
5. IANA Considerations
@ -184,8 +189,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
5.1. Object Identifier
It is requested that IANA assign upon Standards Action an LDAP Object
Identifier [RFC3383] to identify the LDAP Assertion Control defined in
this document.
Identifier [BCP64bis] to identify the LDAP Assertion Control defined
in this document.
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
@ -197,7 +202,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
5.2 LDAP Protocol Mechanism
Registration of this protocol mechanism [RFC3383] is requested.
Registration of this protocol mechanism [BCP64bis] is requested.
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: IANA-ASSIGNED-OID
@ -212,21 +217,20 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
5.3 LDAP Result Code
Assignment of an LDAP Result Code [RFC3383] called 'assertionFailed'
Assignment of an LDAP Result Code [BCP64bis] called 'assertionFailed'
is requested.
Subject: LDAP Result Code Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Result Code Name: assertionFailed
Zeilenga LDAP Assertion Control [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
Subject: LDAP Result Code Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Result Code Name: assertionFailed
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
@ -245,27 +249,42 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
Email: Kurt@OpenLDAP.org
8. Normative References
8. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
9. Informative References
8.2. Informative References
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
Zeilenga LDAP Assertion Control [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
@ -275,14 +294,6 @@ Intellectual Property Rights
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
Zeilenga LDAP Assertion Control [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found
@ -305,7 +316,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
Full Copyright
Copyright (C) The Internet Society (2004). This document is subject
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
@ -323,17 +334,6 @@ Full Copyright
Zeilenga LDAP Assertion Control [Page 6]

322
doc/drafts/draft-zeilenga-ldap-authzid-xx.txt
View file

@ -1,63 +1,63 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 1 November 2002
Expires in six months 19 November 2004
LDAP "Who am I?" Operation
<draft-zeilenga-ldap-authzid-08.txt>
<draft-zeilenga-ldap-authzid-10.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extension Working Group
mailing list <ldapext@ietf.org>. Please send editorial comments
directly to the author <Kurt@OpenLDAP.org>.
document will take place on the IETF LDAP Extensions mailing list
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2002, The Internet Society. All Rights Reserved.
Copyright (C) The Internet Society (2004). All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
Please see the Full Copyright section near the end of this document
for more information.
Abstract
This specification provides a mechanism for Lightweight Directory
Access Protocol (LDAP) clients to obtain the authorization identity
which the server has associated with the user or application entity.
This mechanism is specified as an LDAP extended operation called the
LDAP "Who am I?" operation.
Zeilenga LDAP "Who am I?" [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
Access Protocol (LDAP) clients to obtain the authorization identity
which the server has associated with the user or application entity.
This mechanism is specified as an LDAP extended operation called the
LDAP "Who am I?" operation.
Conventions
@ -75,21 +75,21 @@ Conventions
associated with the user or application entity. The operation is
called the "Who am I?" operation.
This specification is intended to replace the existing [AUTHCTL]
This specification is intended to replace the existing [AUTHRESP]
mechanism which uses Bind request and response controls to request and
return the authorization identity. Bind controls are not protected by
the security layers established by the Bind operation which they are
transferred as part of. While it is possible to establish security
layers using Start TLS [RFC2830] prior to the Bind operation, it is
often desirable to use security layers established by the Bind
operation. An extended operation sent after a Bind operation is
protected by the security layers established by the Bind operation.
the security layers established by the Bind operation which includes
them. While it is possible to establish security layers using Start
TLS [RFC2830] prior to the Bind operation, it is often desirable to
use security layers established by the Bind operation. An extended
operation sent after a Bind operation is protected by the security
layers established by the Bind operation.
There are other cases where it is desirable to request the
authorization identity which the server associated with the client
separately from the Bind operation. For example, the "Who am I?"
operation can be augmented with a Proxied Authorization Control
[PROXYCTL] to determine the authorization identity which the server
[PROXYAUTH] to determine the authorization identity which the server
associates with the identity asserted in the Proxied Authorization
Control. The "Who am I?" operation can also be used prior to the Bind
operation.
@ -103,19 +103,18 @@ Conventions
authzId", respectively.
Zeilenga LDAP "Who am I?" [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
2. The "Who am I?" Operation
The "Who am I?" operation is defined as an LDAP Extended Operation
[RFC2251, Section 4.12] identified by the whoamiOID Object Identifier
(OID). This section details the syntax of the operation's whoami
Zeilenga LDAP "Who am I?" [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
request and response messages.
whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
@ -137,12 +136,12 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
The whoami response is an ExtendedResponse where the responseName
field is absent and the response field, if present, is empty or an
authzId [RFC2829]. For example, a whoami response returning the
authzId "u:kurt@OPENLDAP.ORG" (in response to the example request)
authzId "u:xxyyz@EXAMPLE.NET" (in response to the example request)
would be encoded as the sequence of octets (in hex):
30 21 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13
75 3a 6b 75 72 74 40 4f 50 45 4e 4c 44 41 50 2e
4f 52 47
75 3a 78 78 79 79 7a 40 45 58 41 4d 50 4c 45 2e
4e 45 54
3. Operational Semantics
@ -153,6 +152,20 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
mechanism, a whoami Response, for the server to respond to that
request.
Servers indicate their support for this extended operation by
providing whoamiOID object identifier as a value of the
'supportedExtension' attribute type in their root DSE. Server SHOULD
advertise this extension only when the client is willing and able to
perform this operation.
Zeilenga LDAP "Who am I?" [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
If the server is willing and able to provide the authorization
identity it associates with the client, the server SHALL return a
whoami Response with a success resultCode. If the server is treating
@ -164,14 +177,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
If the server is unwilling or unable to provide the authorization
identity it associates with the client, the server SHALL return a
whoami Response with an appropriate non-success resultCode (such as
Zeilenga LDAP "Who am I?" [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
operationsError, protocolError, confidentialityRequired,
insufficientAccessRights, busy, unavailable, unwillingToPerform, or
other) and an absent response field.
@ -181,7 +186,9 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
authenticated using the Bind operation. Clients MUST NOT invoke the
"Who Am I?" operation while any Bind operation is in progress,
including between two Bind requests made as part of a multi-stage Bind
operation.
operation. Where a whoami Request is received in violation of this
absolute prohibition, the server should return a whoami Response with
an operationsError resultCode.
4. Extending the "Who am I?" operation with controls
@ -195,7 +202,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
4.1. Proxied Authorization Control
The Proxied Authorization Control [PROXYCTL] is used by clients to
The Proxied Authorization Control [PROXYAUTH] is used by clients to
request that the operation it is attached to operates under the
authorization of an assumed identity. The client provides the
identity to assume in the Proxied Authorization request control. If
@ -207,33 +214,34 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
[RFC2829], it is desirable to request the server provide the authzId
it associates with the assumed identity.
Zeilenga LDAP "Who am I?" [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
When a Proxied Authorization Control is be attached to the "Who Am I?"
operation, the operation requests the return of the authzId the server
associates with the identity asserted in the Proxied Authorization
Control. The TBD result code is used to indicate that the server does
not allow the client to assume the asserted identity. [[Note to RFC
Editor: TBD is to be replaced with the name/code assigned by IANA for
[PROXYCTL] use.]]
[PROXYAUTH] use.]]
5. Security Considerations
Identities associated with users may be sensitive information. When
so, security layers [RFC2829][RFC2830] should be established to
Zeilenga LDAP "Who am I?" [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
protect this information. This mechanism is specifically designed to
allow security layers established by a Bind operation to protect the
integrity and/or confidentiality of the authorization identity.
Servers may place access control or other restrictions upon the use of
this operation.
this operation. As stated in Section 3, the server SHOULD advertise
this extension when it is willing and able to perform the operation.
As with any other extended operations, general LDAP security
considerations [RFC3377] apply.
@ -241,124 +249,150 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
6. IANA Considerations
This OID 1.3.6.1.4.1.4203.1.11.3 to identify the LDAP "Who Am I?
extended operation. This OID was assigned [ASSIGN] by OpenLDAP
The OID 1.3.6.1.4.1.4203.1.11.3 is used to identify the LDAP "Who Am
I?" extended operation. This OID was assigned [ASSIGN] by OpenLDAP
Foundation, under its IANA-assigned private enterprise allocation
[PRIVATE], for use in this specification.
Registration of this protocol mechansism is requested [RFC3383].
Subject: Request for LDAP Protocol Mechansism Registration
Registration of this protocol mechanism [RFC3383] is requested.
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.11.3
Description: Who am I?
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Extended Operation
Specification: RFCxxxx
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
7. Acknowledgment
This document borrows from prior work in this area including
"Authentication Response Control" [AUTHCTL] by Rob Weltman, Mark Smith
and Mark Wahl.
The LDAP "Who am I?" operation takes it name from the UNIX whoami(1)
command. The whoami(1) command displays the effective user id.
Zeilenga LDAP "Who am I?" [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
"Authentication Response Control" [AUTHRESP] by Rob Weltman, Mark
Smith and Mark Wahl.
The LDAP "Who am I?" operation takes it name from the UNIX whoami(1)
command. The whoami(1) command displays the effective user id.
8. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
Email: Kurt@OpenLDAP.org
9. Normative References
9. References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2829] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan,
"Authentication Methods for LDAP", RFC 2829, June 2000.
[RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
Access Protocol (v3): Extension for Transport Layer
Security", RFC 2830, May 2000.
[RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[PROXYCTL] R. Weltman, "LDAP Proxied Authentication Control", draft-
weltman-ldapv3-proxy-xx.txt (a work in progress).
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
10. Informative References
9.1. Normative References
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
RFC 3383), September 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
[RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[AUTHCTL] R. Weltman, M. Smith, M. Wahl, "LDAP Authentication
Response Control", draft-weltman-ldapv3-auth-response-
xx.txt (a work in progress).
[RFC2829] Wahl, M., H. Alvestrand, and J. Hodges, RL "Bob" Morgan,
"Authentication Methods for LDAP", RFC 2829, June 2000.
[PRIVATE] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers.
[RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight
Directory Access Protocol (v3): Extension for Transport
Layer Security", RFC 2830, May 2000.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[PROXYAUTH] Weltman, R., "LDAP Proxy Authentication Control",
draft-weltman-ldapv3-proxy-xx.txt, a work in progress.
Copyright 2002, The Internet Society. All Rights Reserved.
9.2. Informative References
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
Zeilenga LDAP "Who am I?" [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
(also RFC 3383), September 2002.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
[AUTHRESP] Weltman, R., M. Smith and M. Wahl, "LDAP Authorization
Identity Response and Request Controls",
draft-weltman-ldapv3-auth-response-xx.txt, a work in
progress.
This document and the information contained herein is provided on an
"AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
[PRIVATE] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers.
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Full Copyright
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
Zeilenga LDAP "Who am I?" [Page 7]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
@ -391,5 +425,21 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
Zeilenga LDAP "Who am I?" [Page 7]
Zeilenga LDAP "Who am I?" [Page 8]

1403
doc/drafts/draft-zeilenga-ldap-cosine-xx.txt Normal file
View file

File diff suppressed because it is too large Load diff

283
doc/drafts/draft-zeilenga-ldap-dontusecopy-xx.txt Normal file
View file

@ -0,0 +1,283 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 17 July 2005
The LDAP Don't Use Copy Control
<draft-zeilenga-ldap-dontusecopy-01.txt>
Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the IESG for consideration as a Standard Track
document. Distribution of this memo is unlimited. Technical
discussion of this document will take place on the IETF LDAP
Extensions mailing list <ldapext@ietf.org>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga LDAP Don't Use Copy Control [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005
Abstract
This document defines the Lightweight Directory Access Protocol (LDAP)
Don't Use Copy control extension which allows a client to specify that
copied information should not be used in providing service. This
control is based upon the X.511 dontUseCopy service control option.
1. Background and Intended Usage
This document defines the Lightweight Directory Access Protocol (LDAP)
[Roadmap] Don't Use Copy control extension. The control may be
attached to request messages to indicate that copied (replicated or
cached) information [X.500] should not be used in providing service.
This control is based upon the X.511 [X.511] dontUseCopy service
control option.
The Don't Use Copy control is intended to be used where the client
requires the service be provided using original (master) information
[X.500].
2. Terminology
DSA stands for Directory System Agent (or server).
DSE stands for DSA-specific Entry.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
3. The Don't Use Copy Control
The Don't Use Copy control is an LDAP Control [Protocol] whose
controlType is IANA-ASSIGNED-OID and controlValue is absent. The
criticality may be TRUE or FALSE. There is no corresponding response
control.
The control is appropriate for both LDAP interrogation operations,
including Compare and Search operations [Protocol]. It is
inappropriate for all other operations, including Abandon, Bind,
Delete, Modify, ModifyDN, StartTLS, and Unbind operations [Protocol].
When the control is attached to an LDAP request, the requested
operation MUST NOT be performed on copied information. That is, the
requested operation MUST be performed on original information.
Zeilenga LDAP Don't Use Copy Control [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005
If original information for the target or base object of the operation
is not available (either locally or through chaining), the server MUST
either return a referral directing the client to a server believed to
be better able to service the request or return an appropriate result
code (e.g., unwillingToPerform).
4. Security Considerations
This control is intended to be provided where providing service using
copied information might lead to unexpected application behavior.
Designers of directory applications should consider where it is
appropriate for clients to provide this control. Designers should
consider whether use of copied information, in particular security and
policy information, may result insecure behavior.
Security considerations for the base operations [Protocol] extended by
this control, as well as general LDAP security considerations
[Roadmap], generally apply to implementation and use of this
extension.
5. IANA Considerations
5.1. Object Identifier
It is requested that IANA assign upon Standards Action an LDAP Object
Identifier [BCP64bis] to identify the LDAP Don't Use Copy Control
defined in this document.
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
Identifies the LDAP Don't Use Copy Control
5.2 LDAP Protocol Mechanism
Registration of this protocol mechanism [BCP64bis] is requested.
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: IANA-ASSIGNED-OID
Description: Don't Use Copy Control
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Control
Zeilenga LDAP Don't Use Copy Control [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
6. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
Email: Kurt@OpenLDAP.org
7. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
7.2. Informative References
[X.500] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Overview of concepts, models and services,"
X.500(1993) (also ISO/IEC 9594-1:1994).
[X.511] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory: Abstract Service Definition", X.511(1993)
(also ISO/IEC 9594-3:1993).
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
Zeilenga LDAP Don't Use Copy Control [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Full Copyright
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zeilenga LDAP Don't Use Copy Control [Page 5]

162
doc/drafts/draft-zeilenga-ldap-incr.txt
View file

@ -1,10 +1,16 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Experimental OpenLDAP Foundation
Expires in six months 17 October 2004
Expires in six months 10 February 2005
LDAP Modify-Increment Extension
<draft-zeilenga-ldap-incr-00.txt>
<draft-zeilenga-ldap-incr-01.txt>
Status of this Memo
@ -32,28 +38,31 @@ Status of this Memo
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
http://www.ietf.org/1id-abstracts.html
Copyright (C) The Internet Society (2004). All Rights Reserved.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga LDAP Modify-Increment Extension [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
Abstract
This document describes an extension to the Lightweight Directory
Access Protocol (LDAP) Modify operation to support an increment
Zeilenga LDAP Modify-Increment Extension [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
capability. This extension is useful in provisioning applications,
especially when combined with the assertion control and/or the
pre-read or post-read control extension.
@ -61,7 +70,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
1. Background and Intended Use
The Lightwieght Directory Access Protocol [Roadmap] does not currently
The Lightweight Directory Access Protocol [Roadmap] does not currently
provide an operation to increment values of an attribute. A client
must read the values of the attribute, then modify those values to
increment them by the desired amount. As the values may be updated by
@ -72,8 +81,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
This document extends the LDAP Modify Operation [Protocol] to support
an increment values capability. This feature is intended to be used
with either the LDAP pre-read or post-read control extension
[READENTRY]. This feature may be used with the LDAP assertion control
[ASSERT] to provide test-and-increment functionality.
[ReadEntry]. This feature may also be used with the LDAP assertion
control [Assertion] to provide test-and-increment functionality.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
@ -84,30 +93,33 @@ INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
This document extends the LDAP Modify request to support a increment
values capability. Implementations of this extension SHALL support an
additional ModifyRequest operation enumeration value increment (3) as
described herein. Implementations not supporting this extension will
treat this value as they would an unlisted value, e.g., as a protocol
error.
The increment (3) operation value specifies that an increment values
modification is requested. All existing values of the modification
attribute are to be incremented by the listed value. The modification
attribute must be appropriate for request, e.g., must have INTEGER or
other incrementable values, and the modification must provide one and
only value.
Servers supporting this feature SHOULD publish the object identifier
(OID) OID-TBD as a value of the 'supportedFeatures' [RFC3674]
attribute in the root DSE. Clients supporting this feature SHOULD NOT
use the feature unless they have knowledge the server supports it.
additional ModifyRequest operation enumeration value increment (IANA-
ASSIGNED-TYPE) as described herein. Implementations not supporting
this extension will treat this value as they would an unlisted value,
e.g., as a protocol error.
The increment (IANA-ASSIGNED-TYPE) operation value specifies that an
increment values modification is requested. All existing values of
the modification attribute are to be incremented by the listed value.
The modification attribute must be appropriate for request, e.g., must
have INTEGER or other increment-able values, and the modification must
provide one and only value. If the attribute is not appropriate for
the request, a constraintViolation or other appropriate error is to be
returned. If multiple values are provided, a protocolError is to be
returned.
Zeilenga LDAP Modify-Increment Extension [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
Servers supporting this feature SHOULD publish the object identifier
(OID) IANA-ASSIGNED-OID as a value of the 'supportedFeatures'
[RFC3674] attribute in the root DSE. Clients supporting this feature
SHOULD NOT use the feature unless they have knowledge the server
supports it.
3. LDIF Support
@ -144,11 +156,38 @@ INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
5. IANA Considerations
Registration of the LDAP Protocol Mechanism [BCP64bis] defined in
document is requested.
Registration of the following values [BCP64bis] is requested.
5.1. Object Identifier
It is requested that IANA assign an LDAP Object Identifier to identify
the LDAP Modify-Increment feature as defined in this document.
Zeilenga LDAP Modify-Increment Extension [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFC XXXX
Author/Change Controller: Author
Comments:
Identifies the LDAP Modify-Increment feature
5.2. LDAP Protocol Mechanism
It is requested that the following LDAP Protocol Mechanism be
registered.
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: OID-TBD
Object Identifier: IANA-ASSIGNED-OID
Description: Modify-Increment
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
@ -158,12 +197,20 @@ INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
Comments: none
5.3. LDAP Protocol Mechanism
It is requested that IANA assign an LDAP ModifyRequest Operation Type
[BCP64bis] for use in this document.
Zeilenga LDAP Modify-Increment Extension [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
Subject: Request for LDAP Protocol Mechanism Registration
ModifyRequest Operation Name: increment
Description: Modify-Increment
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Feature
Specification: RFC XXXX
Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
Comments: none
6. Author's Address
@ -173,7 +220,21 @@ INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
<Kurt@OpenLDAP.org>
7. Normative References
Zeilenga LDAP Modify-Increment Extension [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
7. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
@ -195,16 +256,16 @@ INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
8. Informative References
7.2. Informative References
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
[READENTRY] Zeilenga, K., "LDAP Read Entry Controls",
[ReadEntry] Zeilenga, K., "LDAP Read Entry Controls",
draft-zeilenga-ldap-readentry-xx.txt, a work in
progress.
[ASSERT] Zeilenga, K., "LDAP Assertion Control",
[Assertion] Zeilenga, K., "LDAP Assertion Control",
draft-zeilenga-ldap-assert-xx.txt, a work in progress.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
@ -217,9 +278,9 @@ INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
Zeilenga LDAP Modify-Increment Extension [Page 4]
Zeilenga LDAP Modify-Increment Extension [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
Intellectual Property Rights
@ -250,7 +311,7 @@ Intellectual Property Rights
Full Copyright
Copyright (C) The Internet Society (2004). This document is subject
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
@ -273,6 +334,7 @@ Full Copyright
Zeilenga LDAP Modify-Increment Extension [Page 5]
Zeilenga LDAP Modify-Increment Extension [Page 6]

61
doc/drafts/draft-zeilenga-ldap-noop-xx.txt
View file

@ -3,14 +3,15 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 10 February 2005
Expires in six months 28 October 2005
The LDAP No-Op Control
<draft-zeilenga-ldap-noop-06.txt>
<draft-zeilenga-ldap-noop-07.txt>
Status of this Memo
@ -22,11 +23,10 @@ Status of this Memo
Extensions mailing list <ldapext@ietf.org>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
@ -54,9 +54,10 @@ Status of this Memo
Zeilenga LDAP No-Op Control [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-noop-06 10 February 2005
INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
Abstract
@ -81,8 +82,8 @@ Abstract
[Roadmap] No-Op control extension. The presence of the No-Op control
in an operation request message disables its normal effect upon the
directory which operation would otherwise have. Instead of updating
the directory and return the normal indication of success, the server
does not update the directory and indicates so by returning the
the directory and returning the normal indication of success, the
server does not update the directory and indicates so by returning the
noOperation resultCode (introduced below).
For example, when the No-Op control is present in a LDAP modify
@ -112,7 +113,7 @@ Abstract
Zeilenga LDAP No-Op Control [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-noop-06 10 February 2005
INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
2. No-Op Control
@ -139,6 +140,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-noop-06 10 February 2005
reason indicated by the result code. A result code of noOperation
(IANA-ASSIGNED-CODE) indicates that the server discovered no reason
why the operation would fail if submitted without the No-Op control.
It is noted that there may be reasons why the operation may fail which
are only discoverable when submitting without the No-Op control.
Servers SHOULD indicate their support for this control by providing
IANA-ASSIGNED-OID as a value of the 'supportedControl' attribute type
@ -161,16 +164,16 @@ INTERNET-DRAFT draft-zeilenga-ldap-noop-06 10 February 2005
[Roadmap].
4. IANA Considerations
Zeilenga LDAP No-Op Control [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-noop-06 10 February 2005
INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
4. IANA Considerations
4.1. Object Identifier
It is requested that IANA assign an LDAP Object Identifier [BCP64bis]
@ -218,13 +221,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-noop-06 10 February 2005
Kurt D. Zeilenga
OpenLDAP Foundation
Email: Kurt@OpenLDAP.org
Zeilenga LDAP No-Op Control [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-noop-06 10 February 2005
INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
Email: Kurt@OpenLDAP.org
6. References
@ -272,17 +276,17 @@ INTERNET-DRAFT draft-zeilenga-ldap-noop-06 10 February 2005
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
Zeilenga LDAP No-Op Control [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-noop-06 10 February 2005
INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found
@ -305,9 +309,11 @@ INTERNET-DRAFT draft-zeilenga-ldap-noop-06 10 February 2005
Full Copyright
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
@ -329,12 +335,5 @@ Full Copyright
Zeilenga LDAP No-Op Control [Page 6]

343
doc/drafts/draft-zeilenga-ldap-readentry-xx.txt
View file

@ -3,21 +3,18 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 26 October 2003
Expires in six months 10 February 2005
LDAP Read Entry Controls
<draft-zeilenga-ldap-readentry-01.txt>
<draft-zeilenga-ldap-readentry-04.txt>
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
@ -25,46 +22,59 @@ Expires in six months 26 October 2003
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
http://www.ietf.org/1id-abstracts.html
Copyright (C) The Internet Society (2003). All Rights Reserved.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Abstract
This specification describes controls which can be attached to a
Lightweight Directory Access Protocol (LDAP) update request to obtain
copies of the target entry before and/or after the requested update is
applied.
Zeilenga LDAP Read Entry Controls [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
Abstract
This document specifies an extension to the Lightweight Directory
Access Protocol (LDAP) to allow the client to read the target entry of
an update operation. The client may request to read the entry before
and/or after the modifications are applied. These reads are done as
an atomic part of the update operation.
1. Background and Intent of Use
This specification describes controls [RFC2251] which can be attached
to Lightweight Directory Access Protocol (LDAP) [RFC3377] update
requests to request and return copies of the target entry. One
This document specifies an extension to the Lightweight Directory
Access Protocol (LDAP) [Roadmap] to allow the client to read the
target entry of an update operation (e.g., Add, Delete, Modify,
ModifyDN). The extension utilizes controls [Protocol] attached to
update requests to request and return copies of the target entry. One
request control, called the Pre-Read request control, indicates that a
copy of the entry before application of update is to be returned.
Another control, called the Post-Read request control, indicates that
@ -72,6 +82,9 @@ INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
Each request control has a corresponding response control used to
return the entry.
To ensure proper isolation, the controls are processed as an atomic
part of the update operation.
The functionality offered by these controls is based upon similar
functionality in the X.500 Directory Access Protocol (DAP) [X.511].
@ -79,8 +92,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
of modified attributes or a copy of the entry being deleted.
The Post-Read controls may be used to obtain values of operational
attributes, such as the 'entryUUID' [EntryUUID] and 'modifytimestamp'
[RFC2252] attributes, updated by the server as part of the update
attributes, such as the 'entryUUID' [EntryUUID] and 'modifyTimestamp'
[Models] attributes, updated by the server as part of the update
operation.
@ -89,12 +102,19 @@ INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
Protocol elements are described using ASN.1 [X.680] with implicit
tags. The term "BER-encoded" means the element is to be encoded using
the Basic Encoding Rules [X.690] under the restrictions detailed in
Section 5.1 of [RFC2251].
Section 5.2 of [Protocol].
DN stands for Distinguished Name.
DSA stands for Directory System Agent (i.e., a directory server).
DSE stands for DSA-specific Entry.
Zeilenga LDAP Read Entry Controls [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
@ -107,38 +127,26 @@ INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
The Pre-Read request and response controls are identified by the
IANA-ASSIGNED-OID.1 object identifier. Servers implementing these
controls SHOULD publish IANA-ASSIGNED-OID.1 as a value of the
'supportedControl' [RFC2252] in their root DSE.
'supportedControl' [Models] in their root DSE.
Zeilenga LDAP Read Entry Controls [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
The Pre-Read request control is an LDAP Control [RFC2251] whose
controlType is IANA-ASSIGNED-OID.1 and controlValue is a BER-encoded
AttributeDescriptionList [RFC2251]. The criticality may be TRUE or
FALSE. This control is appropriate for the modifyRequest, delRequest,
and modDNRequest LDAP messages.
The Pre-Read request control is an LDAP Control [Protocol] whose
controlType is IANA-ASSIGNED-OID.1 and whose controlValue is a
BER-encoded AttributeSelection [Protocol], as extended by [RFC3673].
The criticality may be TRUE or FALSE. This control is appropriate for
the modifyRequest, delRequest, and modDNRequest LDAP messages.
The corresponding response control is a LDAP Control whose controlType
is IANA-ASSIGNED-OID.1 and the controlValue, an OCTET STRING, contains
a BER-encoded SearchResultEntry. The criticality may be TRUE or
FALSE. This control is appropriate for the modifyResponse,
is IANA-ASSIGNED-OID.1 and whose the controlValue, an OCTET STRING,
contains a BER-encoded SearchResultEntry. The criticality may be TRUE
or FALSE. This control is appropriate for the modifyResponse,
delResponse, and modDNResponse LDAP messages with a resultCode of
success (0).
When the request control is attached to an appropriate update LDAP
request, the control requests the return of a copy of target entry
prior to the application of the update. The AttributeDescriptionList
indicates which attributes are requested to appear in the copy. There
are two special AttributeDescriptions which may be included in the
list, "*" and "+". "*" requests all user attributes. "+" requests
all operational attributes. If the list is empty, all user attributes
are requested. If the list contains an unrecognized attribute type,
that type is simply ignored. If all attribute types are unrecognized,
no attributes are to be returned. The server is to return a
prior to the application of the update. The AttributeSelection
indicates, as discussed in [Protocol][RFC3673] which attributes are
requested to appear in the copy. The server is to return a
SearchResultEntry containing, subject to access controls and other
constraints, values of the requested attributes.
@ -146,7 +154,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
this control MUST be performed as one atomic action isolated from
other update operations.
If the update operation fails, no response control is provided.
If the update operation fails (in either normal or control
processing), no response control is provided.
3.2. The Post-Read Controls
@ -154,38 +163,34 @@ INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
The Post-Read request and response controls are identified by the
IANA-ASSIGNED-OID.2 object identifier. Servers implementing these
controls SHOULD publish IANA-ASSIGNED-OID.2 as a value of the
'supportedControl' [RFC2252] in their root DSE.
The Post-Read request control is an LDAP Control [RFC2251] whose
controlType is IANA-ASSIGNED-OID.2 and controlValue, an OCTET STRING,
contains a BER-encoded AttributeDescriptionList [RFC2251]. The
criticality may be TRUE or FALSE. This control is appropriate for the
addRequest, modifyRequest, and modDNRequest LDAP messages.
The corresponding response control is a LDAP Control whose controlType
is IANA-ASSIGNED-OID.2 and controlValue is a BER-encoded
Zeilenga LDAP Read Entry Controls [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
'supportedControl' [Models] in their root DSE.
The Post-Read request control is an LDAP Control [Protocol] whose
controlType is IANA-ASSIGNED-OID.2 and whose controlValue, an OCTET
STRING, contains a BER-encoded AttributeSelection [Protocol], as
extended by [RFC3673]. The criticality may be TRUE or FALSE. This
control is appropriate for the addRequest, modifyRequest, and
modDNRequest LDAP messages.
The corresponding response control is a LDAP Control whose controlType
is IANA-ASSIGNED-OID.2 and whose controlValue is a BER-encoded
SearchResultEntry. The criticality may be TRUE or FALSE. This
control is appropriate for the addResponse, modifyResponse, and
modDNResponse LDAP messages with a resultCode of success (0).
When the request control is attached to an appropriate update LDAP
request, the control requests the return of a copy of target entry
after the application of the update. The AttributeDescriptionList
indicates which attributes are requested to appear in the copy. There
are two special AttributeDescriptions which may be included in the
list, "*" and "+". "*" requests all user attributes. "+" requests
all operational attributes. If the list is empty, all user attributes
are requested. If the list contains an unrecognized attribute type,
that type is simply ignored. If all attribute types are unrecognized,
no attributes are to be returned. The server is to return a
after the application of the update. The AttributeSelection
indicates, as discussed in [Protocol][RFC3673], which attributes are
requested to appear in the copy. The server is to return a
SearchResultEntry containing, subject to access controls and other
constraints, values of the requested attributes.
@ -193,18 +198,18 @@ INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
this control MUST be performed as one atomic action isolated from
other update operations.
If the update operation fails, no response control is provided.
If the update operation fails (in either normal or control
processing), no response control is provided.
4. Interaction with other controls
The Pre- and Post-Read controls may be combined with each other and/or
with a variety of other controls. When combined with the assertion
control [ASSERT], the manageDsaIT control [RFC3296], and/or the proxy
authorization control [PROXYAUTH], the semantics of each control
included in the combination apply. The Pre- and Post-Read controls
may be combined with other controls as detailed in other technical
specifications.
The Pre-Read and Post-Read controls may be combined with each other
and/or with a variety of other controls. When combined with the
assertion control [Assertion] and/or the manageDsaIT control
[RFC3296], the semantics of each control included in the combination
apply. The Pre-Read and Post-Read controls may be combined with other
controls as detailed in other technical specifications.
5. Security Considerations
@ -215,20 +220,21 @@ INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
control in addition to ensuring the client is authorized to perform
the requested directory update.
Implementors of this (or any) LDAP extension should be familiar with
general LDAP security considerations [RFC3377].
6. IANA Considerations
Zeilenga LDAP Read Entry Controls [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
Registration of the following protocol values [RFC3383] is requested.
Security considerations for the update operations [Protocol] extended
by this control, as well as general LDAP security considerations
[Roadmap], generally apply to implementation and use of this extension
6. IANA Considerations
Registration of the following protocol values [BCP64bis] is requested.
6.1. Object Identifier
@ -269,47 +275,55 @@ INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
Usage: Control
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
in 2
7. Acknowledgment
The LDAP Pre- and Post-Read controls are modeled after similar
Zeilenga LDAP Read Entry Controls [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
capabilities offered in the DAP [X.511].
Comments: none
8. Normative References
7. Acknowledgment
The LDAP Pre-Read and Post-Read controls are modeled after similar
capabilities offered in the DAP [X.511].
8. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight
Directory Access Protocol (v3): Extension for Transport
Layer Security", RFC 2830, May 2000.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[RFC3296] Zeilenga, K., "Named Subordinate References in
Lightweight Directory Access Protocol (LDAP)
Directories", RFC 3296, July 2002.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[RFC3673] Zeilenga, K., "LDAPv3: All Operational Attributes", RFC
3673, December 2003.
[Assertion] Zeilenga, K., "LDAP Assertion Control",
draft-zeilenga-ldap-assert-xx.txt, a work in progress.
[X.680] International Telecommunication Union -
Telecommunication Standardization Sector, "Abstract
@ -317,106 +331,91 @@ INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
[X.690] International Telecommunication Union -
Zeilenga LDAP Read Entry Controls [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
Telecommunication Standardization Sector, "Specification
of ASN.1 encoding rules: Basic Encoding Rules (BER),
Canonical Encoding Rules (CER), and Distinguished
Encoding Rules (DER)", X.690(1997) (also ISO/IEC
8825-1:1998).
[PROXYAUTH] Weltman, R., "LDAP Proxy Authentication Control", draft-
weltman-ldapv3-proxy-xx.txt, a work in progress.
[ASSERT] Zeilenga, K., "LDAP Assertion Control",
draft-zeilenga-ldap-assert-xx.txt, a work in progress.
8.2. Informative References
9. Informative References
Zeilenga LDAP Read Entry Controls [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
[X.511] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory: Abstract Service Definition", X.511(1993).
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
[EntryUUID] Zeilenga, K., "The LDAP EntryUUID Operational
Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in
progress.
[X.511] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory: Abstract Service Definition", X.511(1993)
(also ISO/IEC 9594-3:1993).
10. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
Email: Kurt@OpenLDAP.org
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such proprietary
rights by implementors or users of this specification can be obtained
from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright
Copyright (C) The Internet Society (2003). All Rights Reserved.
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
Zeilenga LDAP Read Entry Controls [Page 7]
INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Full Copyright
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
@ -449,3 +448,5 @@ INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
Zeilenga LDAP Read Entry Controls [Page 8]

297
doc/drafts/draft-zeilenga-ldap-t-f-xx.txt
View file

@ -3,22 +3,18 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 25 October 2003
Expires in six months 10 February 2005
LDAP Absolute True and False Filters
<draft-zeilenga-ldap-t-f-07.txt>
<draft-zeilenga-ldap-t-f-10.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
@ -26,25 +22,43 @@ Status of this Memo
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
http://www.ietf.org/1id-abstracts.html
Copyright (C) The Internet Society (2003). All Rights Reserved.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga LDAP True & False Filters [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
Abstract
This document extends the Lightweight Directory Access Protocol (LDAP)
@ -54,12 +68,6 @@ Abstract
these filters.
Zeilenga LDAP True & False Filters [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
1. Background
The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
@ -71,19 +79,22 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
While LDAPv2 [RFC1777][RFC3494] placed no restriction on the number of
elements in 'and' and 'or' filter sets, the LDAPv2 string
representation [RFC1960] could not represent empty 'and' and 'or'
filter sets. Due to this, absolute True or False filters were
(unfortunately) eliminated from LDAPv3 [RFC3377].
representation [RFC1960][RFC3494] could not represent empty 'and' and
'or' filter sets. Due to this, absolute True or False filters were
(unfortunately) eliminated from LDAPv3 [Roadmap].
This documents extends LDAPv3 to support absolute True and False
matches by allowing empty 'and' and 'or' in Search filters [RFC2251]
and extends the filter string representation [RFC2254] to allow empty
filter lists.
assertions by allowing empty 'and' and 'or' in Search filters
[Protocol] and extends the filter string representation [Filters] to
allow empty filter lists.
It is noted that certain search operations, such as those used to
retrieve subschema information [Models], require use of particular
filters. This document does not change these requirements.
This feature is intended to allow a more direct mapping between DAP
and LDAP (as needed to implement DAP-to-LDAP gateways).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
@ -97,23 +108,22 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
An 'and' filter consisting of an empty set of filters SHALL evaluate
to True. This filter is represented by the string "(&)".
An 'or' filter consisting of an empty set of filters SHALL evaluate to
False. This filter is represented by the string "(|)".
Servers supporting this feature SHOULD publish the Object Identifier
(OID) 1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures'
[FEATURES] attribute in the root DSE.
Clients supporting this feature SHOULD NOT use the feature unless they
have knowledge the server supports it.
Zeilenga LDAP True & False Filters [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
An 'or' filter consisting of an empty set of filters SHALL evaluate to
False. This filter is represented by the string "(|)".
Servers supporting this feature SHOULD publish the Object Identifier
1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures' [RFC3674]
attribute in the root DSE.
Clients supporting this feature SHOULD NOT use the feature unless they
have knowledge the server supports it.
3. Security Considerations
@ -122,21 +132,16 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
believed to raise any new security considerations.
Implementors of this (or any) LDAPv3 extension should be familiar with
general LDAPv3 security considerations [RFC3377].
general LDAPv3 security considerations [Roadmap].
4. IANA Considerations
The OID 1.3.6.1.4.1.4203.1.5.3 identifies the feature described above.
This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
IANA-assigned private enterprise allocation [PRIVATE], for use in this
specification.
Registration of this feature is requested [FEATURES][RFC3383].
Registration of this feature is requested [BCP64bis].
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.5.3
Description: T/F Filters
Description: True/False filters
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Feature
@ -144,6 +149,10 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
Author/Change Controller: IESG
Comments: none
This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
IANA-assigned private enterprise allocation [PRIVATE], for use in this
specification.
5. Author's Address
@ -152,34 +161,46 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
<Kurt@OpenLDAP.org>
6. Normative References
6. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2254] Howes, T., "A String Representation of LDAP Search
Filters", RFC 2254, December 1997.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Zeilenga LDAP True & False Filters [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[FEATURES] Zeilenga, K., "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt, a work in progress.
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
7. Informative References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
Representation of Search Filters",
draft-ietf-ldapbis-filter-xx.txt, a work in progress.
[Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674,
December 2003.
6.2. Informative References
[RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight
Directory Access Protocol", RFC 1777, March 1995.
@ -187,8 +208,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
[RFC1960] Howes, T., "A String Representation of LDAP Search
Filters", RFC 1960, June 1996.
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
[RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
version 2 (LDAPv2) to Historic Status", RFC 3494, March
@ -199,10 +220,22 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
-- Overview of concepts, models and services,"
X.500(1993) (also ISO/IEC 9594-1:1994).
Zeilenga LDAP True & False Filters [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
[X.511] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory: Abstract Service Definition", X.511(1993)
(also ISO/IEC 9594-3:1993).
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
@ -214,70 +247,94 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
Zeilenga LDAP True & False Filters [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such proprietary
rights by implementors or users of this specification can be obtained
from the IETF Secretariat.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Full Copyright
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Zeilenga LDAP True & False Filters [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zeilenga LDAP True & False Filters [Page 6]

508
doc/drafts/draft-zeilenga-ldap-turn-xx.txt
View file

@ -3,21 +3,19 @@
INTERNET-DRAFT Kurt D. Zeilenga
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Experimental OpenLDAP Foundation
Expires in six months 8 February 2004
Expires in six months 28 October 2005
LDAP Turn Operation
<draft-zeilenga-ldap-turn-00.txt>
<draft-zeilenga-ldap-turn-03.txt>
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor for publication as an
Experimental document. Distribution of this memo is unlimited.
@ -25,20 +23,28 @@ Expires in six months 8 February 2004
Extensions mailing list <ldapext@ietf.org>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
http://www.ietf.org/1id-abstracts.html
Copyright (C) The Internet Society (2004). All Rights Reserved.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
@ -46,47 +52,50 @@ Expires in six months 8 February 2004
Abstract
This specification describes a Lightweight Directory Access Protocol
(LDAP) extended operation to reverse (or "turn") the roles of client
and server for subsequent protocol exchanges in the session.
Zeilenga LDAP Turn Op [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
This specification describes a Lightweight Directory Access Protocol
(LDAP) extended operation to reverse (or "turn") the roles of client
and server for subsequent protocol exchanges in the session, or to
enable each peer to act as both client and server with respect to the
other.
1. Background and Intent of Use
The Lightweight Directory Access Protocol (LDAP) [RFC3377] is a client
/ server protocol which typically operates over reliable octet stream
transports such as the Transport Control Protocol (TCP). Generally,
the client initiates the stream by connecting to the server's listener
at some well-known address.
The Lightweight Directory Access Protocol (LDAP) [Roadmap][Protocol]
is a client-server protocol which typically operates over reliable
octet-stream transports such as the Transport Control Protocol (TCP).
Generally, the client initiates the stream by connecting to the
server's listener at some well-known address.
There are cases where it is desirable for the server to initiate the
stream. While it certainly is possible to write a technical
specification detailing how to implement server-initiated LDAP
sessions, this would requiring designing new authentication and other
security features to support server-initiated LDAP sessions.
sessions, this would require the design of new authentication and
other security mechanisms to support server-initiated LDAP sessions.
This document instead introduces an operation, the Turn operation,
which may be used to reverse the client / server roles of the
protocol peers. This allows the initiating protocol peer to be server
(after reversal).
Instead, this document introduces an operation, the Turn operation,
which may be used to reverse the client-servers roles of the protocol
peers. This allows the initiating protocol peer to become server
(after the reversal).
As an additional feature, the Turn operation may be used to allow both
peers to act in both roles. This is useful where both peers are
directory servers which desire to issue, as LDAP clients, operations
against the other. This may be useful in replicated environments.
directory servers that desire to request, as LDAP clients, operations
be performed by the other. This may be useful in replicated and/or
distributed environments.
This operation is intended to used between protocol peers which have
established a mutual agreement, by means outside of the protocol,
which requires reversal of client / server roles or both peers to act
both as client and server.
This operation is intended to be used between protocol peers which
have established a mutual agreement, by means outside of the protocol,
which requires reversal of client-server roles, or allows both peers
to act both as client and server.
1.1 Terminology
@ -94,28 +103,24 @@ INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
Protocol elements are described using ASN.1 [X.680] with implicit
tags. The term "BER-encoded" means the element is to be encoded using
the Basic Encoding Rules [X.690] under the restrictions detailed in
Section 5.1 of [RFC2251].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
Section 5.2 of [Protocol].
2. Turn Operation
The Turn operation is defined as a LDAP Extended Operation [RFC2251,
Section 4.12] identified by the IANA-ASSIGNED-OID. The function of
the Turn Operation is to request that the client / server roles be
reversed, or, optionally to request that both protocol peers to be
Zeilenga LDAP Turn Op [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
able to act both as client and server.
The Turn operation is defined as a LDAP Extended Operation [Protocol,
Section 4.12] identified by the IANA-ASSIGNED-OID. The function of
the Turn Operation is to request that the client-server roles be
reversed, or, optionally to request that both protocol peers to be
able to act both as client and server in respect to the other.
2.1. Turn Request
@ -126,65 +131,219 @@ INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
turnValue ::= SEQUENCE {
mutual BOOLEAN DEFAULT FALSE,
identifier LDAPString,
identifier LDAPString
}
A TRUE value of the mutual field indicates a request to allow both
peers to act both as client and server while a FALSE value indicates a
A TRUE mutual field value indicates a request to allow both peers to
act both as client and server. A FALSE mutual field value indicates a
request to reserve the client and server roles.
The value of the identifier field is a locally-defined policy
identifier (typicallly associated with a mutual agreement for which
this turn is be executed as part of). This policy identifier is
called the turn indicator.
identifier (typically associated with a mutual agreement for which
this turn is be executed as part of).
2.2. Turn Response
A Turn response is an ExtendedResponse where the responseName and
response fields are absent. A resultCode of success is returned if
and only if the responder is willing and able to turn the session as
requested. Otherwise, a different resultCode is returned.
responseValue fields are absent. A resultCode of success is returned
if and only if the responder is willing and able to turn the session
as requested. Otherwise, a different resultCode is returned.
3. Security Considerations
3. Authentication
It is generally recommended that before issuing the Turn operation the
protocol peers:
This extension's authentication model assumes separate authentication
of the peers in each of their roles. A separate Bind exchange is
expected between the peers in their new roles to establish identities
in these roles.
- establish each other identities through appropriate authentication
mechanism,
- establish appropriate data integrity, data confidentiality, and
other protections,
- establish an LDAP association between the initiating peer and the
responding peer.
And upon successful completion of turn:
- establish an LDAP association in reverse.
That is, for peer A connecting to peer B listening and where TLS and
Upon completion of the Turn, the responding peer in its new client
role has an anonymous association at the initiating peer in its new
server role. If the turn was mutual, the authentication association
of the initiating peer in its pre-existing client role is left intact
at the responding peer in its pre-existing server role. If the turn
was not mutual, this association is void.
Zeilenga LDAP Turn Op [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
SASL/EXTERNAL were to be used, the sequence of operations would be:
The responding peer may establish its identity in its client role by
requesting and successfully completing a Bind operation.
A->B: StartTLS
A->B: Bind(SASL,EXTERNAL)
A->B: Turn
B->A: Bind(SASL,EXTERNAL)
The remainder of this section discuss some authentication scenarios.
In the protocol exchange illustrations, A refers to the initiating
peer (the original client) and B refers to the responding peer (the
original server).
3.1. Use with TLS and Simple Authentication
A->B: StartTLS Request
B->A: StartTLS(success) Response
A->B: Bind(Simple(cn=B,dc=example,dc=net,B's secret)) Request
B->A: Bind(success) Response
A->B: Turn(TRUE,"XXYYZ") Request
B->A: Turn(success) Response
A->B: Bind(Simple(DN/Password)) Request
B->A: Bind(Simple(cn=A,dc=example,dc=net,A's secret)) Request
A->B: Bind(success) Response
In this scenario, TLS (Transport Layer Security) [TLS] is started and
the initiating peer (the original client) establishes its identity
with the responding peer prior to the Turn using the the DN/password
mechanism of the Simple method of the Bind operation. After the turn,
the responding peer in its new client role establishes its identity
with the initiating peer in its new server role.
4. IANA Considerations
3.2. Use with TLS and SASL EXTERNAL
Registration of the following values [RFC3383] is requested.
A->B: StartTLS Request
B->A: StartTLS(success) Response
A->B: Bind(SASL(EXTERNAL)) Request
B->A: Bind(success) Response
A->B: Turn(TRUE,"XXYYZ") Request
B->A: Turn(success) Response
B->A: Bind(SASL(EXTERNAL)) Request
A->B: Bind(success) Response
In this scenario, TLS is started prior with each peer providing a
valid certificate and the initiating peer (the original client)
establishes its identity through the use of the EXTERNAL mechanism of
the SASL (Simple Authentication and Security Layer) [SASL] method of
the Bind operation prior to the Turn. After the turn, the responding
peer in its new client role establishes its identity with the
initiating peer in its new server role.
4.1. Object Identifier
Zeilenga LDAP Turn Op [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
3.3. Use of mutual authentication and SASL EXTERNAL
A number of SASL mechanisms, such as GSSAPI [GSSAPI] and DIGEST-MD5
[DIGEST-MD5], support mutual authentication. The initiating peer, it
its new server role, may use the identity of the responding peer
established by a prior authentication exchange, as its source for
"external" identity in subsequent EXTERNAL exchange.
A->B: Bind(SASL(GSSAPI)) Request
<intermediate messages>
B->A: Bind(success) Response
A->B: Turn(TRUE,"XXYYZ") Request
B->A: Turn(success) Response
B->A: Bind(SASL(EXTERNAL)) Request
A->B: Bind(success) Response
In this scenario, a GSSAPI mutual-authentication exchange is completed
between the initiating peer (the original client) and the the
responding server (the original server) prior to the turn. After the
turn, the responding peer in its new client role requests the
initiating peer utilize an "external" identity to establish its LDAP
authorization identity.
4. TLS and SASL security layers
As described in [Protocol], LDAP supports both Transport Layer
Security (TLS) [TLS] and Simple Authentication and Security Layer
(SASL) [SASL] security frameworks. The following table illustrates
the relationship between the LDAP message layer, SASL layer, TLS
layer, and transport connection within an LDAP session.
+----------------------+
| LDAP message layer |
+----------------------+ > LDAP PDUs
+----------------------+ < data
| SASL layer |
+----------------------+ > SASL-protected data
+----------------------+ < data
| TLS layer |
Application +----------------------+ > TLS-protected data
------------+----------------------+ < data
Transport | transport connection |
+----------------------+
This extension does not alter this relationship, nor does it remove
the general restriction against multiple TLS layers, nor does it
remove the general restriction against multiple SASL layers.
Zeilenga LDAP Turn Op [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
As specified in [Protocol], the StartTLS operation is used to initiate
negotiation of a TLS layer. If a TLS is already installed, the
StartTLS operation must fail. Upon establishment of the TLS layer,
regardless of which peer issued the request to start TLS, the peer
which initiated the LDAP session (the original client) performs the
"server identity check" as described in Section 3.1.5 of [AuthMeth]
treating itself as the "client" and its peer as the "server".
As specified in [SASL], newly negotiated SASL security layer replace
the installed SASL security layer. Though the client/server roles in
LDAP, and hence SASL, may be reversed in subsequent exchanges, only
one SASL security layer may be installed at any instance.
5. Security Considerations
Implementors should be aware that the reversing of client/server roles
and/or allowing both peers to act as client and server likely
introduces security considerations not foreseen by the authors of this
document. In particular, the security implications of the design
choices made in the authentication and data security models for this
extension (discussed in sections 3 and 4, respectively) are not fully
studied. It is hoped that experimentation with this extension will
lead to better understanding of the security implications of these
models and other aspects of this extension, and that appropriate
considerations will be documented in a future document. The following
security considerations are apparent at this time.
Implementors should take special care to process LDAP, SASL, TLS, and
other events the appropriate roles for the peers. It is noted that
while the Turn reverses the client/server roles with LDAP, and in SASL
authentication exchanges, it does not reverse the roles within the TLS
layer or the transport connection.
The responding server (the original server) should restrict use of
this operation to authorized clients. Client knowledge of a valid
identifier should not be the sole factor in determining authorization
to turn.
Where the peers except to establish TLS, TLS should be started prior
to the Turn and any request to authenticate via the Bind operation.
LDAP security considerations [Protocol][AuthMeth] generally apply to
this extension.
6. IANA Considerations
Zeilenga LDAP Turn Op [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
Registration of the following values [BCP64bis] is requested.
6.1. Object Identifier
It is requested that IANA assign an LDAP Object Identifier to identify
the LDAP Turn Operation as defined in this document.
@ -198,7 +357,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
Identifies the LDAP Turn Operation
4.2. LDAP Protocol Mechanism
6.2. LDAP Protocol Mechanism
It is requested that IANA register the LDAP Protocol Mechanism
described in this document.
@ -214,45 +373,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
Comments: none
5. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
Zeilenga LDAP Turn Op [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
[RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[X.680] International Telecommunication Union -
Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic
Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
[X.690] International Telecommunication Union -
Telecommunication Standardization Sector, "Specification
of ASN.1 encoding rules: Basic Encoding Rules (BER),
Canonical Encoding Rules (CER), and Distinguished
Encoding Rules (DER)", X.690(1997) (also ISO/IEC
8825-1:1998).
6. Informative References
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
7. Author's Address
Kurt D. Zeilenga
@ -261,55 +381,118 @@ INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
Email: Kurt@OpenLDAP.org
8. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
Zeilenga LDAP Turn Op [Page 7]
INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
8.1. Normative References
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
[SASL] Melnikov, A. (Editor), "Simple Authentication and
Security Layer (SASL)",
draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
[TLS] Dierks, T. and, E. Rescorla, "The TLS Protocol Version
1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
progress.
[X.680] International Telecommunication Union -
Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic
Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
[X.690] International Telecommunication Union -
Telecommunication Standardization Sector, "Specification
of ASN.1 encoding rules: Basic Encoding Rules (BER),
Canonical Encoding Rules (CER), and Distinguished
Encoding Rules (DER)", X.690(2002) (also ISO/IEC
8825-1:2002).
8.2. Informative References
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
[GSSAPI] Linn, J., "Generic Security Service
Application Program Interface, Version 2, Update 1", RFC
2743, January 2000.
[DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest
Authentication as a SASL Mechanism",
draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress.
Zeilenga LDAP Turn Op [Page 8]
INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such proprietary
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
Zeilenga LDAP Turn Op [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
rights by implementors or users of this specification can be obtained
from the IETF Secretariat.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Full Copyright
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright (C) The Internet Society (2005).
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
@ -320,20 +503,5 @@ Full Copyright
Zeilenga LDAP Turn Op [Page 6]
Zeilenga LDAP Turn Op [Page 9]

364
doc/drafts/draft-zeilenga-ldap-uuid-xx.txt
View file

@ -6,18 +6,17 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 25 October 2003
Expires in six months 18 July 2005
The LDAP entryUUID operational attribute
<draft-zeilenga-ldap-uuid-02.txt>
<draft-zeilenga-ldap-uuid-06.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as an Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
@ -25,20 +24,28 @@ Status of this Memo
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
http://www.ietf.org/1id-abstracts.html
Copyright (C) The Internet Society (2003). All Rights Reserved.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
@ -46,6 +53,13 @@ Status of this Memo
Abstract
Zeilenga draft-zeilenga-ldap-uuid-06 [Page 1]
INTERNET-DRAFT LDAP entryUUID 18 July 2005
This document describes the LDAP/X.500 'entryUUID' operational
attribute and associated matching rules and syntax. The attribute
holds a server-assigned Universally Unique Identifier (UUID) for the
@ -54,79 +68,75 @@ Abstract
after renaming.
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 1]
INTERNET-DRAFT LDAP entryUUID 25 October 2003
1. Background and Intended Use
In X.500 Directory Services [X.501], such as those accessible using
the the Lightweight Directory Access Protocol (LDAP) [RFC3377], an
object is identified by its distinguished name (DN). However, DNs are
not stable identifiers. That is, a new object may be identified by a
DN which previously identified another (now renamed or deleted)
object.
the Lightweight Directory Access Protocol (LDAP) [Roadmap], an object
is identified by its distinguished name (DN). However, DNs are not
stable identifiers. That is, a new object may be identified by a DN
which previously identified another (now renamed or deleted) object.
A Universally Unique Identifier (UUID) is "an identifier unique across
both space and time, with respect to the space of all UUIDs"
[UUIDURN]. UUIDs are used in a wide range of systems.
This document describes the 'entryUUID' operational attribute which
holds the Universally Unique Identifier (UUID) [ISO11578] assigned to
the object by the server. Clients may use this attribute to
distinguish objects identified by a distinguished name or to locate an
object after renaming.
holds the UUID assigned to the object by the server. Clients may use
this attribute to distinguish objects identified by a particular
distinguished name or to locate a particular object after renaming.
This document defines the UUID syntax, the 'uuidMatch' and
'uuidOrderingMatch' matching rules, the 'entryUUID' attribute type.
'uuidOrderingMatch' matching rules, and the 'entryUUID' attribute
type.
Schema definitions are provided using LDAP description formats
[Models]. Definitions provided here are formatted (line wrapped) for
readability.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
Schema definitions are provided using LDAP description formats
[RFC2252]. Definitions provided here are formatted (line wrapped) for
readability.
2. UUID Schema Elements
2.1 UUID Syntax
A Universally Unique Identifier (UUID) [ISO11578] is a 16-octet
(128-bit) value which identifies an object. The ASN.1 [X.690] type
UUID is defined to represent UUIDs.
A Universally Unique Identifier (UUID) [UUIDURN] is a 16-octet
(128-bit) value which identifies an object. The ASN.1 [X.680] type
UUID is defined to represent UUIDs as follows:
UUID ::= OCTET STRING (SIZE(16))
-- constrained to an UUID [ISO 11578]
-- constrained to an UUID [UUIDURN]
In LDAP, values of the UUID type are encoded using the [ASCII]
character string representation described in [ISO11578]. For example,
Zeilenga draft-zeilenga-ldap-uuid-06 [Page 2]
INTERNET-DRAFT LDAP entryUUID 18 July 2005
In LDAP, UUID values are encoded using the [ASCII] character string
representation described in [UUIDURN]. For example,
"597ae2f6-16a6-1027-98f4-d28b5365dc14".
The following is a LDAP syntax description [RFC2252] suitable for
publication in the subschema.
The following is a LDAP syntax description suitable for publication in
subschema subentries.
( IANA-ASSIGNED-OID.1 DESC 'UUID' )
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 2]
INTERNET-DRAFT LDAP entryUUID 25 October 2003
2.2 'uuidMatch' Matching Rule
The 'uuidMatch' matching rule compares an asserted UUID with a stored
UUID for equality. Its semantics are same as the octetStringMatch
[X.520][RFC2252] matching rule. The rule differs from
octetStringMatch in that the assertion value is encoded using the UUID
string representation instead of the normal OCTET STRING string
UUID for equality. Its semantics are same as the 'octetStringMatch'
[X.520][Syntaxes] matching rule. The rule differs from
'octetStringMatch' in that the assertion value is encoded using the
UUID string representation instead of the normal OCTET STRING string
representation.
The following is a LDAP matching rule description [RFC2252] suitable
for publication in the subschema.
The following is a LDAP matching rule description suitable for
publication in subschema subentries.
( IANA-ASSIGNED-OID.2 NAME 'uuidMatch'
SYNTAX IANA-ASSIGNED-OID.1 )
@ -136,15 +146,15 @@ INTERNET-DRAFT LDAP entryUUID 25 October 2003
The 'uuidOrderingMatch' matching rule compares an asserted UUID
with a stored UUID for ordering. Its semantics are the same as the
octetStringOrderingMatch [X.520][RFC2252] matching rule. The rule
differs from octetStringOrderingMatch in that the assertion value
is encoded using the UUID string representation instead of the
normal OCTET STRING string representation.
'octetStringOrderingMatch' [X.520][Syntaxes] matching rule. The
rule differs from 'octetStringOrderingMatch' in that the assertion
value is encoded using the UUID string representation instead of
the normal OCTET STRING string representation.
The following is a LDAP matching rule description [RFC2252] suitable
for publication in the subschema.
The following is a LDAP matching rule description suitable for
publication in subschema subentries.
( IANA-ASSIGNED-OID.3 NAME 'uuidMatch'
( IANA-ASSIGNED-OID.3 NAME 'uuidOrderingMatch'
SYNTAX IANA-ASSIGNED-OID.1 )
It is noted that not all UUID variants have a defined ordering and,
@ -154,48 +164,69 @@ INTERNET-DRAFT LDAP entryUUID 25 October 2003
2.4. 'entryUUID' attribute
The 'entryUUID' operational attribute provides the Universally Unique
Identifier (UUID) [ISO11578] assigned to the entry.
The following is a LDAP attribute type description [RFC2252] suitable
for publication in the subschema.
Zeilenga draft-zeilenga-ldap-uuid-06 [Page 3]
INTERNET-DRAFT LDAP entryUUID 18 July 2005
The 'entryUUID' operational attribute provides the Universally Unique
Identifier (UUID) assigned to the entry.
The following is a LDAP attribute type description suitable for
publication in subschema subentries.
( IANA-ASSIGNED-OID.4 NAME 'entryUUID'
DESC 'UUID of the entry'
EQUALITY uuidMatch
ORDERING uuidOrderingMatch
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 3]
INTERNET-DRAFT LDAP entryUUID 25 October 2003
SYNTAX IANA-ASSIGNED-OID.1
SINGLE-VALUE
NO-USER-MODIFICATION
USAGE directoryOperation )
Servers SHALL assign a UUID to each entry upon its addition to the
directory and provide the entry's UUID as the value of the
Servers SHALL generate and assign a new UUID to each entry upon its
addition to the directory and provide that UUID as the value of the
'entryUUID' operational attribute. An entry's UUID is immutable.
UUID are to be generated in accordance with Section 4 of [UUIDURN].
In particular, servers MUST ensure that each generated UUID is unique
in space and time.
3. Security Considerations
Servers should ensure that components of UUID values are publicly
disclosable.
An entry's relative distinguish name (RDN) is composed from attribute
values of the entry, values which are commonly descriptive of the
object the entry represents. While deployers are encouraged to use
naming attributes whose values are widely disclosable [LDAPDN],
entries are often named using information which cannot be disclosed to
all parties. As UUIDs do not contain any descriptive information of
the object they identify, UUIDs may be used to identify a particular
entry without disclosure of its contents.
General UUID security considerations [UUIDURN] apply.
General LDAP security considerations [RFC3377] apply.
4. IANA Considerations
It is requested that IANA register upon Standards Action the LDAP
values specified in this document.
4.1. Object Identifier Registration
It is requested that IANA register upon Standards Action an LDAP
Object Identifier for use in this technical specification.
Zeilenga draft-zeilenga-ldap-uuid-06 [Page 4]
INTERNET-DRAFT LDAP entryUUID 18 July 2005
Subject: Request for LDAP OID Registration
Person & email address to contact for further information:
@ -206,10 +237,20 @@ INTERNET-DRAFT LDAP entryUUID 25 October 2003
Identifies the UUID schema elements
4.2. Registration of the uuidMatch descriptor
4.2. UUID Syntax Registration
It is requested that IANA register upon Standards Action the LDAP
'uuidMatch' descriptor.
Subject: Request for LDAP Syntax Registration
Object Identifier: IANA-ASSIGNED-OID.1
Description: UUID
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
Identifies the UUID syntax
4.3. 'uuidMatch' Descriptor Registration
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): uuidMatch
@ -221,17 +262,7 @@ INTERNET-DRAFT LDAP entryUUID 25 October 2003
Author/Change Controller: IESG
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 4]
INTERNET-DRAFT LDAP entryUUID 25 October 2003
4.3. Registration of the uuidOrderingMatch descriptor
It is requested that IANA register upon Standards Action the LDAP
'uuidOrderingMatch' descriptor.
4.3. 'uuidOrderingMatch' Descriptor Registration
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): uuidOrderingMatch
@ -243,7 +274,15 @@ INTERNET-DRAFT LDAP entryUUID 25 October 2003
Author/Change Controller: IESG
4.4. Registration of the entryUUID descriptor
5.4. 'entryUUID' Descriptor Registration
Zeilenga draft-zeilenga-ldap-uuid-06 [Page 5]
INTERNET-DRAFT LDAP entryUUID 18 July 2005
It is requested that IANA register upon Standards Action the LDAP
'entryUUID' descriptor.
@ -258,43 +297,54 @@ INTERNET-DRAFT LDAP entryUUID 25 October 2003
Author/Change Controller: IESG
5. Acknowledgments
6. Acknowledgments
This document is based upon discussions in the LDAP Update and
Duplication Protocols (LDUP) WG. Members of the concluded LDAP
Extensions (LDAPEXT) Working Group provided review.
Duplication Protocols (LDUP) WG. Members of the LDAP Directorate
provided review.
6. Author's Address
7. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
Email: Kurt@OpenLDAP.org
7. Normative References
8. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[UUIDURN] Leach, P, M. Mealling, R. Salz, "A UUID URN Namespace",
a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 5]
Zeilenga draft-zeilenga-ldap-uuid-06 [Page 6]
INTERNET-DRAFT LDAP entryUUID 25 October 2003
INTERNET-DRAFT LDAP entryUUID 18 July 2005
[RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[ISO11578] International Organization for Standardization,
"Information technology - Open Systems Interconnection -
Remote Procedure Call", ISO/IEC 11578:1996.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
@ -311,72 +361,70 @@ INTERNET-DRAFT LDAP entryUUID 25 October 2003
[X.680] International Telecommunication Union -
Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic
Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
8. Informative References
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
8.2. Informative References
[UUIDinfo] The Open Group, "Universally Unique Identifier" appendix
of the CAE Specification "DCE 1.1: Remote Procedure
Calls", Document Number C706,
<http://www.opengroup.org/products/publications/catalog/c706.htm>
(appendix available at:
<http://www.opengroup.org/onlinepubs/9629399/apdxa.htm>),
August 1997.
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
work in progress.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 6]
Zeilenga draft-zeilenga-ldap-uuid-06 [Page 7]
INTERNET-DRAFT LDAP entryUUID 25 October 2003
INTERNET-DRAFT LDAP entryUUID 18 July 2005
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such proprietary
rights by implementors or users of this specification can be obtained
from the IETF Secretariat.
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Full Copyright
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2005).
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
@ -391,5 +439,13 @@ Full Copyright
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 7]
Zeilenga draft-zeilenga-ldap-uuid-06 [Page 8]

1403
doc/drafts/draft-zeilenga-ldap-x509-xx.txt Normal file
View file

File diff suppressed because it is too large Load diff

895
doc/drafts/draft-zeilenga-ldap-x509.txt
View file

@ -1,895 +0,0 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 17 October 2004
Obsoletes: RFC 2252, RFC 2256
LDAP X.509 Certificate Schema
<draft-zeilenga-ldap-x509-00.txt>
Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as an Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions mailing list
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
This document is intended to be published in conjunction to the
revised LDAP TS [Roadmap] when, in conjunction with this document,
obsoletes RFC 2252 and RFC 2256 in their entirety.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright (C) The Internet Society (2004). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga draft-zeilenga-ldap-x509-00 [Page 1]
INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
Abstract
This document describes schema for representing X.509 certificates,
X.521 security information, and related elements in directories
accessible using the Lightweight Directory Access Protocol (LDAP).
The LDAP definitions for these X.509 and X.521 schema elements
replaces those provided in RFC 2252 and RFC 2256.
1. Background and Intended Use
This document provides LDAP schema definitions for a subset of
elements specified in X.509 [X.509] and X.521 [X.521], including
attribute types for certificates, cross certificate pairs, and
certificate revocation lists; matching rules to be used with these
attribute types; and related object classes. LDAP syntax definitions
are also provided for associated assertion and attribute values.
As the semantics of these elements are as defined in X.509 and X.521,
knowledge of X.509 and X.521 is necessary to make use of the LDAP
schema definitions provided herein.
This document, together with [Roadmap], obsoletes RFC 2252 and RFC
2256 in their entirety. The changes made since RFC 2252 and RFC 2256
include:
- addition of pkiUser, pkiCA, and deltaCRL classes;
- updated of attribute types to include equality matching rules in
accordance with their X.500 specifications;
- addition of certificate, certificate pair, certificate list, and
algorithm identifer matching rules; and
- addition of LDAP syntax for assertion syntaxes for these matching
rules.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
Schema definitions are provided using LDAP description formats
[Models]. Definitions provided here are formatted (line wrapped) for
readability.
2. Syntaxes
This section describes various syntaxes used to transfer certificates
and related data types in LDAP.
Zeilenga draft-zeilenga-ldap-x509-00 [Page 2]
INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
2.1. Certificate
( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'X.509 Certificate' )
A value of this syntax is an X.509 Certificate [Section 7, X.509].
Due to changes made to the ASN.1 definition of a Certificate made
through time, no LDAP-specific encoding is defined for this syntax.
Values of this syntax are to encoded using DER [X.690] and MUST only
be transferred using the ;binary transfer option [Binary]. That is,
by requesting and returning values using attribute descriptions such
as "userCertificate;binary".
As values of this syntax contain digitally-signed data, values of this
syntax, and the form of the value, MUST be preserved as presented.
2.2. CertificateList
( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'X.509 Certificate List' )
A value of this syntax is an X.509 CertificateList [Section 7.3,
X.509].
Due to changes made to the ASN.1 definition of a CertificateList made
through time, no LDAP-specific encoding is defined for this syntax.
Values of this syntax are to encoded using DER [X.690] and MUST only
be transferred using the ;binary transfer option [Binary]. That is,
by requesting and returning values using attribute descriptions such
as "certificateRevocationList;binary".
As values of this syntax contain digitally-signed data, values of this
syntax, and the form of the value, MUST be preserved as presented.
2.3. CertificatePair
( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'X.509 Certificate Pair' )
A value of this syntax is an X.509 CertificatePair [Section 11.2.3,
X.509].
Due to changes made to the ASN.1 definition of an X.509
CertificatePair made through time, no LDAP-specific encoding is
defined for this syntax. Values of this syntax are to encoded using
DER [X.690] and MUST only be transferred using the ;binary transfer
option [Binary]. That is, by requesting and returning values using
attribute descriptions such as "crossCertificatePair;binary".
Zeilenga draft-zeilenga-ldap-x509-00 [Page 3]
INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
As values of this syntax contain digitally-signed data, values of this
syntax, and the form of the value, MUST be preserved as presented.
2.4 SupportedAlgorithm
( 1.3.6.1.4.1.1466.115.121.1.49
DESC 'X.508 Supported Algorithm' )
A value of this syntax is an X.509 SupportedAlgorithm [Section 11.2.7,
X.509].
Due to changes made to the ASN.1 definition of an X.509
SupportedAlgorithm made through time, no LDAP-specific encoding is
defined for this syntax. Values of this syntax are to encoded using
DER [X.690] and MUST only be transferred using the ;binary transfer
option [Binary]. That is, by requesting and returning values using
attribute descriptions such as "supportedAlgorithms;binary".
As values of this syntax contain digitally-signed data, values of this
syntax, and the form of the value, MUST be preserved as presented.
2.5. CertificateExactAssertion
( IANA-ASSIGNED-OID.1 DESC 'X.509 Certificate Exact Assertion' )
A value of this syntax is an X.509 CertificateExactAssertion [Section
11.3.1, X.509].
The LDAP-specific encoding used for this syntax is described by the
following ABNF [RFC2234]:
certificateExactAssertion = serialNumber DOLLAR issuer
serialNumber = number
issuer = distinguishedName
where <number> and <DOLLAR> are as given in [Models] and
<distinguishedName> is as given in [LDAPDN].
Example: 10$cn=Example$CA,dc=example,dc=com
Note: DOLLAR ('$') characters may appear in the <issuer> production.
2.6. CertificateAssertion
( IANA-ASSIGNED-OID.2 DESC 'X.509 Certificate Assertion' )
Zeilenga draft-zeilenga-ldap-x509-00 [Page 4]
INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
A value of this syntax is an X.509 CertificateAssertion [Section
11.3.2, X.509].
Values of this syntax are to be encoded using GSER [RFC3641].
Appendix A.1 provides an equivalent ABNF grammar for this syntax.
2.7. CertificatePairExactAssertion
( IANA-ASSIGNED-OID.3
DESC 'X.509 Certificate Pair Exact Assertion' )
A value of this syntax is an X.509 CertificatePairExactAssertion
[Section 11.3.3, X.509].
Values of this syntax are to be encoded using GSER [RFC3641].
Appendix A.2 provides an equivalent ABNF grammar for this syntax.
2.8. CertificatePairAssertion
( IANA-ASSIGNED-OID.4 DESC 'X.509 Certificate Pair Assertion' )
A value of this syntax is an X.509 CertificatePairAssertion [Section
11.3.4, X.509].
Values of this syntax are to be encoded using GSER [RFC3641].
Appendix A.3 provides an equivalent ABNF grammar for this syntax.
2.9. CertificateListExactAssertion
( IANA-ASSIGNED-OID.5
DESC 'X.509 Certificate List Exact Assertion' )
A value of this syntax is an X.509 CertificateListExactAssertion
[Section 11.3.5, X.509].
Values of this syntax are to be encoded using GSER [RFC3641].
Appendix A.4 provides an equivalent ABNF grammar for this syntax.
2.10. CertificateListAssertion
( IANA-ASSIGNED-OID.6 DESC 'X.509 Certificate List Assertion' )
A value of this syntax is an X.509 CertificateListAssertion [Section
11.3.6, X.509].
Zeilenga draft-zeilenga-ldap-x509-00 [Page 5]
INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
Values of this syntax are to be encoded using GSER [RFC3641].
Appendix A.5 provides an equivalent ABNF grammar for this syntax.
2.11 AlgorithmIdentifier
( IANA-ASSIGNED-OID.7 DESC 'X.509 Algorithm Identifier' )
A value of this syntax is an X.509 AlgorithmIdentifier [Section 7,
X.509].
Values of this syntax are to be encoded using GSER [RFC3641].
Appendix A.6 provides an equivalent ABNF grammar for this syntax.
3. Matching Rules
This section introduces a set of certificate and related matching
rules for use in LDAP. These rules are intended to act in accordance
with their X.500 counterparts.
3.1. certificateExactMatch
The certificateExactMatch matching rule compares the presented
certificate exact assertion value with an attribute value of the
certificate syntax as described in Section 11.3.1 of [X.509].
( 2.5.13.34 NAME 'certificateExactMatch'
DESC 'X.509 Certificate Exact Match'
SYNTAX IANA-ASSIGNED-OID.1 )
3.2. certificateMatch
The certificateMatch matching rule compares the presented certificate
assertion value with an attribute value of the certificate syntax as
described in Section 11.3.2 of [X.509].
( 2.5.13.35 NAME 'certificateMatch'
DESC 'X.509 Certificate Match'
SYNTAX IANA-ASSIGNED-OID.2 )
3.3. certificatePairExactMatch
The certificatePairExactMatch matching rule compares the presented
certificate pair exact assertion value with an attribute value of the
Zeilenga draft-zeilenga-ldap-x509-00 [Page 6]
INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
certificate pair syntax as described in Section 11.3.3 of [X.509].
( 2.5.13.36 NAME 'certificatePairExactMatch'
DESC 'X.509 Certificate Pair Exact Match'
SYNTAX IANA-ASSIGNED-OID.3 )
3.4. certificatePairMatch
The certificatePairMatch matching rule compares the presented
certificate pair assertion value with an attribute value of the
certificate pair syntax as described in Section 11.3.4 of [X.509].
( 2.5.13.37 NAME 'certificatePairMatch'
DESC 'X.509 Certificate Pair Match'
SYNTAX IANA-ASSIGNED-OID.4 )
3.5. certificateListExactMatch
The certificateListExactMatch matching rule compares the presented
certificate list exact assertion value with an attribute value of the
certificate pair syntax as described in Section 11.3.5 of [X.509].
( 2.5.13.38 NAME 'certificateListExactMatch'
DESC 'X.509 Certificate List Exact Match'
SYNTAX IANA-ASSIGNED-OID.5 )
3.6. certificateListMatch
The certificateListMatch matching rule compares the presented
certificate list assertion value with an attribute value of the
certificate pair syntax as described in Section 11.3.6 of [X.509].
( 2.5.13.39 NAME 'certificateListMatch'
DESC 'X.509 Certificate List Match'
SYNTAX IANA-ASSIGNED-OID.6 )
3.7. algorithmIdentifierMatch
The algorithmIdentifierMatch mating rule compares a presented
algorithm identifier with an attribute value of supported algorithm as
described in Section 11.3.7 of [X.509].
( 2.5.13.40 NAME 'algorithmIdentifier'
DESC 'X.509 Algorithm Identifier Match'
Zeilenga draft-zeilenga-ldap-x509-00 [Page 7]
INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
SYNTAX IANA-ASSIGNED-OID.7 )
4. Attribute Types
This section details a set of certificate and related attribute types
for use in LDAP.
4.1. userCertificate
The userCertificate attribute holds the X.509 certificates issued to
the user by one or more certificate authorities, as discussed in
Section 11.2.1 of [X.509].
( 2.5.4.36 NAME 'userCertificate'
DESC 'X.509 user certificate'
EQUALITY certificateExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
As required by this attribute type's syntax, values of this attribute
are requested and transferred using the attribute description
"userCertificate;binary".
4.2. cACertificate
The cACertificate attribute holds the X.509 certificates issued to the
certificate authority (CA), as discussed in Section 11.2.2 of [X.509].
( 2.5.4.37 NAME 'cACertificate'
DESC 'X.509 CA certificate'
EQUALITY certificateExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
As required by this attribute type's syntax, values of this attribute
are requested and transferred using the attribute description
"cACertificate;binary".
4.3. crossCertificatePair
The crossCertificatePair attribute holds an X.509 certificate pair, as
discussed in Section 11.2.3 of [X.509].
( 2.5.4.40 NAME 'crossCertificatePair'
DESC 'X.509 cross certificate pair'
EQUALITY certificatePairExactMatch
Zeilenga draft-zeilenga-ldap-x509-00 [Page 8]
INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
As required by this attribute type's syntax, values of this attribute
are requested and transferred using the attribute description
"crossCertificatePair;binary".
4.4. certificateRevocationList
The certificateRevocationList attribute holds certificate lists, as
discussed in 11.2.4 of [X.509].
( 2.5.4.39 NAME 'certificateRevocationList'
DESC 'X.509 certificate revocation list'
EQUALITY certificateListExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
As required by this attribute type's syntax, values of this attribute
are requested and transferred using the attribute description
"certificateRevocationList;binary".
4.5. authorityRevocationList
The authorityRevocationList attribute holds certificate lists, as
discussed in 11.2.5 of [X.509].
( 2.5.4.38 NAME 'authorityRevocationList'
DESC 'X.509 authority revocation list'
EQUALITY certificateListExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
As required by this attribute type's syntax, values of this attribute
are requested and transferred using the attribute description
"authorityRevocationList;binary".
4.6. deltaRevocationList
The deltaRevocationList attribute holds certificate lists, as
discussed in 11.2.6 of [X.509].
( 2.5.4.53 NAME 'deltaRevocationList'
DESC 'X.509 delta revocation list'
EQUALITY certificateListExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
As required by this attribute type's syntax, values of this attribute
Zeilenga draft-zeilenga-ldap-x509-00 [Page 9]
INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
MUST be requested and transferred using the attribute description
"deltaRevocationList;binary".
4.7. supportedAlgorithms
The supportedAlgorithms attribute holds supported algorithms, as
discussed in 11.2.7 of [X.509].
( 2.5.4.52 NAME 'supportedAlgorithms'
DESC 'X.509 supported algorithms'
EQUALITY algorithmIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )
As required by this attribute type's syntax, values of this attribute
MUST be requested and transferred using the attribute description
"supportedAlgorithms;binary".
5. Object Classes
This section details a set of certificate-related object classes for
use in LDAP.
5.1. pkiUser
This object class is used in augment entries for objects that may be
subject to certificates, as defined in Section 11.1.1 of [X.509].
( 2.5.6.21 NAME 'pkiUser'
DESC 'X.509 PKI User'
SUP top AUXILIARY
MAY userCertificate )
5.2. pkiCA
This object class is used to augment entries for objects which act as
certificate authorities, as defined in Section 11.1.2 of [X.509]
( 2.5.6.22 NAME 'pkiCA'
DESC 'X.509 PKI Certificate Authority'
SUP top AUXILIARY
MAY ( cACertificate $ certificateRevocationList $
authorityRevocationList $ crossCertificatePair ) )
Zeilenga draft-zeilenga-ldap-x509-00 [Page 10]
INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
5.3. cRLDistributionPoint
This class is used to represent objects which act as CRL distribution
points, as discussed in Section 11.1.3 of [X.509].
( 2.5.6.19 NAME 'cRLDistributionPoint'
DESC 'X.509 CRL distribution point'
SUP top STRUCTURAL
MUST cn
MAY ( certificateRevocationList $
authorityRevocationList $ deltaRevocationList ) )
5.4 deltaCRL
The deltaCRL object class is used to augment entries no hold delta
revocation lists, as discussed in Section 11.1.4 of [X.509].
( 2.5.6.23 NAME 'deltaCRL'
DESC 'X.509 delta CRL'
SUP top AUXILIARY
MAY deltaRevocationList )
5.5. strongAuthenticationUser
This object class is used to augment entries for objects participating
in certificate-based authentication, as defined in Section 6.15 of
[X.521]. This object class is deprecated in favor of pkiUser.
( 2.5.6.15 NAME 'strongAuthenticationUser'
DESC 'X.521 strong authentication user'
SUP top AUXILIARY
MUST userCertificate )
5.6. userSecurityInformation
This object class is used to augment entries with needed additional
associated security information, as defined in Section 6.16 of
[X.521].
( 2.5.6.18 NAME 'userSecurityInformation'
DESC 'X.521 user security information'
SUP top AUXILIARY
MAY ( supportedAlgorithms ) )
Zeilenga draft-zeilenga-ldap-x509-00 [Page 11]
INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
5.7. certificationAuthority
This object class is used to augment entries for objects which act as
certificate authorities, as defined in Section 6.17 of [X.521]. This
object class is deprecated in favor of pkiCA.
( 2.5.6.16 NAME 'certificationAuthority'
DESC 'X.509 certificate authority'
SUP top AUXILIARY
MUST ( authorityRevocationList $
certificateRevocationList $ cACertificate )
MAY crossCertificatePair )
5.8. certificationAuthority-V2
This object class is used to augment entries for objects which act as
certificate authorities, as defined in Section 6.18 of [X.521]. This
object class is deprecated in favor of pkiCA.
( 2.5.6.16.2 NAME 'certificationAuthority-V2'
DESC 'X.509 certificate authority, version 2'
SUP certificationAuthority AUXILIARY
MAY deltaRevocationList )
6. Security Considerations
The directory administrator is to use the server's access control
facilities to restrict access as desired.
General LDAP security considerations [Roadmap] apply.
7. IANA Considerations
7.1. Object Identifier Registration
It is requested that IANA register upon Standards Action an LDAP
Object Identifier for use in this technical specification.
Subject: Request for LDAP OID Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
Identifies the LDAP X.509 Certificate schema elements
Zeilenga draft-zeilenga-ldap-x509-00 [Page 12]
INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
7.2. Registration of the descriptor
It is requested that IANA update upon Standards Action the LDAP
Descriptor registry as indicated below.
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): see table
Object Identifier: see table
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: see table
Specification: RFC XXXX
Author/Change Controller: IESG
algorithmIdentifierMatch R 2.5.13.40
authorityRevocationList A 2.5.4.38 *
cACertificate A 2.5.4.37 *
cRLDistributionPoint O 2.5.6.19 *
certificateExactMatch R 2.5.13.34
certificateListExactMatch R 2.5.13.38
certificateListMatch R 2.5.13.39
certificateMatch R 2.5.13.35
certificatePairExactMatch R 2.5.13.36
certificatePairMatch R 2.5.13.37
certificateRevocationList A 2.5.4.39 *
certificationAuthority O 2.5.6.16 *
certificationAuthority-V2 O 2.5.6.16.2 *
crossCertificatePair A 2.5.4.40 *
deltaCRL O 2.5.6.23
deltaRevocationList A 2.5.4.53 *
pkiCA O 2.5.6.22
pkiUser O 2.5.6.21
strongAuthenticationUser O 2.5.6.15 *
supportedAlgorithms A 2.5.4.52 *
userCertificate A 2.5.4.36 *
userSecurityInformation O 2.5.6.18 *
* Updates previous registration
8. Acknowledgments
This document is based upon X.509, a product of the ITU-T. A number
of LDAP schema definitions were based on those found RFC 2252 and RFC
2256, both products of the IETF ASID WG.
Additional material was borrowed from prior works by David Chadwick
and/or Steven Legg to refine LDAP X.509 Schema.
Zeilenga draft-zeilenga-ldap-x509-00 [Page 13]
INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
9. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
Email: Kurt@OpenLDAP.org
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3641] Legg, S., "Generic String Encoding Rules for ASN.1
Types", RFC 3641, October 2003.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[Binary] Legg, S., "Lightweight Directory Access Protocol (LDAP):
The Binary Encoding Option",
draft-legg-ldap-binary-xx.txt, a work in progress.
[X.509] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory: Authentication Framework", X.509(2000).
[X.521] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory: Selected Object Classes", X.521(2000).
[X.680] International Telecommunication Union -
Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic
Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
[X.690] International Telecommunication Union -
Telecommunication Standardization Sector, "Specification
of ASN.1 encoding rules: Basic Encoding Rules (BER),
Canonical Encoding Rules (CER), and Distinguished
Zeilenga draft-zeilenga-ldap-x509-00 [Page 14]
INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
Encoding Rules (DER)", X.690(1997) (also ISO/IEC
8825-1:1998).
11. Informative References
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
[RFC3642] Legg, S., "Common Elements of GSER Encodings", RFC 3642,
October 2003.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
Appendix A.
This appendix is informative.
This appendix, once written, will provide ABNF [RFC2234] grammars for
GSER-based LDAP-specific encodings specified in this document. These
grammars where produced using, and rely on, Common Elements for GSER
Encodings [RFC3342].
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
Zeilenga draft-zeilenga-ldap-x509-00 [Page 15]
INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Full Copyright
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zeilenga draft-zeilenga-ldap-x509-00 [Page 16]