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

Update I-Ds and RFCs

Browse source
This commit is contained in:
Kurt Zeilenga 2004-11-28 22:09:38 +00:00
parent e1080c8694
commit ae1bf4169a
11 changed files with 6738 additions and 2311 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

File diff suppressed because it is too large Load diff

519
doc/drafts/draft-ietf-ldapbis-dn-xx.txt
View file

File diff suppressed because it is too large Load diff

533
doc/drafts/draft-ietf-ldapbis-filter-xx.txt
View file

@ -1,30 +1,40 @@
Network Working Group M. Smith, Editor
Request for Comments: DRAFT Pearl Crescent, LLC
Obsoletes: RFC 2254 T. Howes
Expires: 13 August 2004 Opsware, Inc.
13 February 2004
Expires: 24 April 2005 Opsware, Inc.
24 October 2004
LDAP: String Representation of Search Filters
<draft-ietf-ldapbis-filter-06.txt>
<draft-ietf-ldapbis-filter-08.txt>
1. Status of this Memo
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
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 3668.
This document is intended to be published as a Standards Track RFC,
replacing RFC 2254. Distribution of this memo is unlimited.
Technical discussion of this document will take place on the IETF
LDAP (v3) Revision (ldapbis) Working Group mailing list
<ietf-ldapbis@openldap.org>. Please send editorial comments directly
to the editor <mcs@pearlcrescent.com>.
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
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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
@ -32,19 +42,10 @@ Expires: 13 August 2004 Opsware, Inc.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Discussion of this document should take place on the LDAP (v3)
Revision (ldapbis) Working Group mailing list <ietf-
ldapbis@openldap.org>.
Copyright (C) The Internet Society (2004). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
2. Abstract
LDAP search filters are transmitted in the LDAP protocol using a
binary representation that is appropriate for use on the network.
This document defines a human-readable string representation of LDAP
search filters that is appropriate for use in LDAP URLs and in other
applications.
@ -52,33 +53,41 @@ Expires: 13 August 2004 Opsware, Inc.
Smith & Howes Intended Category: Standards Track [Page 1]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
3. Table of Contents
Abstract
1. Status of this Memo............................................1
2. Abstract.......................................................1
3. Table of Contents..............................................2
4. Introduction...................................................2
5. LDAP Search Filter Definition..................................2
6. String Search Filter Definition................................4
7. Examples.......................................................5
8. Security Considerations........................................7
9. Normative References...........................................7
10. Informative References.........................................8
11. Intellectual Property Rights...................................8
12. Acknowledgments................................................8
13. Authors' Addresses.............................................9
14. Full Copyright Statement.......................................9
15. Appendix A: Changes Since RFC 2254.............................10
15.1. Technical Changes...........................................10
15.2. Editorial Changes...........................................10
16. Appendix B: Changes Since Previous Document Revision...........11
16.1. Technical Changes...........................................12
16.2. Editorial Changes...........................................12
LDAP search filters are transmitted in the LDAP protocol using a
binary representation that is appropriate for use on the network.
This document defines a human-readable string representation of LDAP
search filters that is appropriate for use in LDAP URLs and in other
applications.
4. Introduction
Table of Contents
Status of this Memo............................................1
Abstract.......................................................2
Table of Contents..............................................2
1. Introduction...................................................2
2. LDAP Search Filter Definition..................................3
3. String Search Filter Definition................................4
4. Examples.......................................................6
5. Security Considerations........................................7
6. IANA Considerations............................................7
7. Normative References...........................................7
8. Informative References.........................................8
9. Acknowledgments................................................8
10. Authors' Addresses.............................................8
11. Appendix A: Changes Since RFC 2254.............................9
11.1. Technical Changes...........................................9
11.2. Editorial Changes...........................................10
12. Appendix B: Changes Since Previous Document Revision...........11
12.1. Editorial Changes...........................................11
13. Intellectual Property Rights...................................11
14. Full Copyright.................................................12
1. Introduction
The Lightweight Directory Access Protocol (LDAP) [Protocol] defines a
network representation of a search filter transmitted to an LDAP
@ -89,61 +98,62 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
possible LDAP version 3 search filters, including extended match
filters.
This document is an integral part of the LDAP Technical
Specification [Roadmap].
This document is an integral part of the LDAP Technical Specification
[Roadmap].
This document replaces RFC 2254. Changes to RFC 2254 are summarized
in Appendix A.
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].
5. LDAP Search Filter Definition
An LDAPv3 search filter is defined in Section 4.5.1 of [Protocol] as
follows:
Smith & Howes Intended Category: Standards Track [Page 2]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
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].
2. LDAP Search Filter Definition
An LDAPv3 search filter is defined in Section 4.5.1 of [Protocol] as
follows:
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- initial and final can occur at most once
substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
initial [0] AssertionValue,
any [1] AssertionValue,
final [2] AssertionValue } }
type AttributeDescription,
-- initial and final can occur at most once
substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
initial [0] AssertionValue,
any [1] AssertionValue,
final [2] AssertionValue } }
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
attributeDesc AttributeDescription,
assertionValue AssertionValue }
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
AttributeDescription ::= LDAPString
-- Constrained to <attributedescription>
-- [Models]
-- Constrained to <attributedescription>
-- [Models]
AttributeValue ::= OCTET STRING
@ -151,32 +161,31 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
AssertionValue ::= OCTET STRING
Smith & Howes Intended Category: Standards Track [Page 3]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [ISO10646] characters
-- [Unicode] characters
The AttributeDescription is a string representation of the attribute
description and is defined in [Protocol]. The AttributeValue and
AssertionValue OCTET STRING have the form defined in [Syntaxes]. The
Filter is encoded for transmission over a network using the Basic
Encoding Rules defined in [X.690], with simplifications described in
Encoding Rules (BER) defined in [X.690], with simplifications
described in [Protocol].
Smith & Howes Intended Category: Standards Track [Page 3]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
[Protocol].
6. String Search Filter Definition
3. String Search Filter Definition
The string representation of an LDAP search filter is a string of
UTF-8[RFC3629] encoded ISO 10646-1 characters that is defined by the
following grammar, following the ABNF notation defined in [RFC2234].
The productions used that are not defined here are defined in section
1.4 (Common ABNF Productions) of [Models] unless otherwise noted.
The filter format uses a prefix notation.
UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined
by the following grammar, following the ABNF notation defined in
[RFC2234]. The productions used that are not defined here are
defined in section 1.4 (Common ABNF Productions) of [Models] unless
otherwise noted. The filter format uses a prefix notation.
filter = LPAREN filtercomp RPAREN
filtercomp = and / or / not / item
@ -186,13 +195,15 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
filterlist = 1*filter
item = simple / present / substring / extensible
simple = attr filtertype assertionvalue
filtertype = equal / approx / greater / less
filtertype = equal / approx / greaterorequal / lessorequal
equal = EQUALS
approx = TILDE EQUALS
greater = RANGLE EQUALS
less = LANGLE EQUALS
extensible = attr [dnattrs] [matchingrule] COLON EQUALS assertionvalue
/ [dnattrs] matchingrule COLON EQUALS assertionvalue
greaterorequal = RANGLE EQUALS
lessorequal = LANGLE EQUALS
extensible = attr [dnattrs]
[matchingrule] COLON EQUALS assertionvalue
/ [dnattrs]
matchingrule COLON EQUALS assertionvalue
/ COLON EQUALS assertionvalue
present = attr EQUALS ASTERISK
substring = attr EQUALS [initial] any [final]
@ -205,8 +216,16 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
dnattrs = COLON "dn"
matchingrule = COLON oid
assertionvalue = valueencoding
; The <valueencoding> rule is used to encode an
; <AssertionValue> from Section 4.1.6 of [Protocol].
Smith & Howes Intended Category: Standards Track [Page 4]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
; The <valueencoding> rule is used to encode an <AssertionValue>
; from Section 4.1.6 of [Protocol].
valueencoding = 0*(normal / escaped)
normal = UTF1SUBSET / UTFMB
escaped = ESC HEX HEX
@ -215,14 +234,6 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
; RPAREN, ASTERISK, and ESC.
EXCLAMATION = %x21 ; exclamation mark ("!")
AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
Smith & Howes Intended Category: Standards Track [Page 4]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
ASTERISK = %x2A ; asterisk ("*")
COLON = %x3A ; colon (":")
VERTBAR = %x7C ; vertical bar (or pipe) ("|")
@ -261,9 +272,17 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
are not valid UTF-8 strings. This is necessary because RFC 2254 did
not clearly define the term "string representation" (and in
particular did not mention that the string representation of an LDAP
search filter is a string of UTF-8 encoded ISO 10646-1 characters).
7. Examples
Smith & Howes Intended Category: Standards Track [Page 5]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
search filter is a string of UTF-8 encoded Unicode characters).
4. Examples
This section gives a few examples of search filters written using
this notation.
@ -271,14 +290,6 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
(cn=Babs Jensen)
(!(cn=Tim Howes))
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
Smith & Howes Intended Category: Standards Track [Page 5]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
(o=univ*of*mich*)
(seeAlso=)
@ -317,6 +328,14 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
The following examples illustrate the use of the escaping mechanism.
(o=Parens R Us \28for all your parenthetical needs\29)
Smith & Howes Intended Category: Standards Track [Page 6]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
(cn=*\2A*)
(filename=C:\5cMyFile)
(bin=\00\00\00\04)
@ -327,14 +346,6 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
represent parenthesis characters. The second shows how to represent a
"*" in an assertion value, preventing it from being interpreted as a
substring indicator. The third illustrates the escaping of the
Smith & Howes Intended Category: Standards Track [Page 6]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
backslash character.
The fourth example shows a filter searching for the four-byte value
@ -347,7 +358,7 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
The sixth and final example demonstrates assertion of a BER encoded
value.
8. Security Considerations
5. Security Considerations
This memo describes a string representation of LDAP search filters.
While the representation itself has no known security implications,
@ -358,21 +369,29 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
Please refer to the Security Considerations sections of [Protocol]
and [AuthMeth] for more information.
9. Normative References
6. IANA Considerations
This document has no actions for IANA.
7. Normative References
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms", draft-ietf-ldapbis-
authmeth-xx.txt, a work in progress.
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC 10646-1,
1993.
Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information Models",
draft-ietf-ldapbis-models-xx.txt, a work in progress.
[Protocol] draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
Smith & Howes Intended Category: Standards Track [Page 7]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
@ -382,52 +401,28 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 3629, November 2003.
Smith & Howes Intended Category: Standards Track [Page 7]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
[Syntaxes] Dally, K. (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
syntaxes-xx.txt, a work in progress.
[Syntaxes] Dally, K. (editor), "LDAP: Syntaxes",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.0"
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as
amended by the "Unicode Standard Annex #27: Unicode 3.1"
(http://www.unicode.org/reports/tr27/) and by the "Unicode
Standard Annex #28: Unicode 3.2."
[X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and
Distinguished Encoding Rules, ITU-T Recommendation X.690,
1994.
10. Informative References
8. Informative References
None.
11. 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.
12. Acknowledgments
9. Acknowledgments
This document replaces RFC 2254 by Tim Howes. Changes included in
this revised specification are based upon discussions among the
@ -437,17 +432,7 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
acknowledged.
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
13. Authors' Addresses
10. Authors' Addresses
Mark Smith, Editor
Pearl Crescent, LLC
@ -455,8 +440,17 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
Saline, MI 48176
USA
+1 734 944-2856
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
mcs@pearlcrescent.com
Tim Howes
Opsware, Inc.
599 N. Mathilda Ave.
@ -465,53 +459,17 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
+1 408 744-7509
howes@opsware.com
14. Full Copyright Statement
11. Appendix A: Changes Since RFC 2254
Copyright (C) The Internet Society (2004). All Rights Reserved.
11.1. Technical Changes
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.
The limited permissions granted above are perpetual and will not be
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.
Smith & Howes Intended Category: Standards Track [Page 9]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
15. Appendix A: Changes Since RFC 2254
15.1. Technical Changes
Replaced [ISO 10646] reference with [Unicode].
The following technical changes were made to the contents of the
"String Search Filter Definition" section:
Added statement that the string representation is a string of UTF-8
encoded ISO 10646-1 characters.
encoded Unicode characters.
Revised all of the ABNF to use common productions from [Models].
@ -523,6 +481,9 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
precisely reference productions from the [Models] and [Protocol]
documents.
"String Search Filter Definition" section: replaced "greater" and
"less" with "greaterorequal" and "lessorequal" to avoid confusion.
Introduced the "valueencoding" and associated "normal" and "escaped"
rules to reduce the dependence on descriptive text. The "normal"
production restricts filter strings to valid UTF-8 sequences.
@ -534,7 +495,16 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
of a clear definition of "string representation."
15.2. Editorial Changes
Smith & Howes Intended Category: Standards Track [Page 9]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
11.2. Editorial Changes
Changed document title to include "LDAP:" prefix.
@ -544,21 +514,13 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
Header and "Authors' Addresses" sections: added Mark Smith as the
document editor and updated affiliation and contact information.
"Table of Contents" and "Intellectual Property Rights" sections:
added.
"Table of Contents", "IANA Considerations", and "Intellectual
Property Rights" sections: added.
Copyright: updated per latest IETF guidelines.
"Abstract" section: separated from introductory material.
Smith & Howes Intended Category: Standards Track [Page 10]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
"Introduction" section: new section; separated from the Abstract.
Updated second paragraph to indicate that RFC 2254 is replaced by
this document (instead of RFC 1960). Added reference to the [Roadmap]
@ -585,10 +547,19 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
"Normative References" section: renamed from "References" per new RFC
guidelines. Changed from [1] style to [Protocol] style throughout the
document. Added entries for [ISO10646], [RFC2119], [AuthMeth],
document. Added entries for [Unicode], [RFC2119], [AuthMeth],
[Models], and [Roadmap] and updated the UTF-8 reference. Replaced
RFC 822 reference with a reference to RFC 2234.
Smith & Howes Intended Category: Standards Track [Page 10]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
"Informative References" section: added for clarity.
"Acknowledgments" section: added.
@ -599,54 +570,84 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
added.
16. Appendix B: Changes Since Previous Document Revision
12. Appendix B: Changes Since Previous Document Revision
This appendix lists all changes relative to the previously published
revision, draft-ietf-ldapbis-filter-05.txt. Note that when
revision, draft-ietf-ldapbis-filter-07.txt. Note that when
appropriate these changes are also included in Appendix A, but are
also included here for the benefit of the people who have already
reviewed draft-ietf-ldapbis-filter-05.txt. This section will be
reviewed draft-ietf-ldapbis-filter-07.txt. This section will be
removed before this document is published as an RFC.
12.1. Editorial Changes
"Status of this Memo" section: replaced RFC 3668 (IPR) boilerplate
paragraph with the version that says "each author" instead of "I."
"Status of this Memo" section: added 2 paragraphs that were
accidently removed from the -07 revision (one begins with "The list
of current Internet-Drafts..." and the other begins with "The list of
Internet-Draft Shadow Directories...."
13. 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.
Smith & Howes Intended Category: Standards Track [Page 11]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 13 February 2004
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
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.
14. 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.
This Internet Draft expires on 24 April 2005.
16.1. Technical Changes
None.
16.2. Editorial Changes
"LDAP Search Filter Definition" section: changed the LDAPv3 search
filter ABNF so it matches that used in the latest revision of
[Protocol] and removed the following redundant descriptive text:
"where the LDAPString above is limited to the UTF-8 encoding [UTF-8]
of the ISO 10646 character set [ISO10646]."
"String Search Filter Definition" section: Corrected section
reference to [Models] and replaced this sentence: "Implementations
SHOULD accept as input a string that includes invalid UTF-8 octet
sequences." with the following: "Implementations SHOULD accept as
input strings that are not valid UTF-8 strings."
"Examples" section: Corrected the description of this example:
(sn:dn:2.4.6.8.10:=Barney Rubble).
"Normative References" section: changed UTF-8 reference to point to
RFC 3629, replaced [ASN.1] with [X.690] for consistency, and indented
the reference descriptions to enhance readability.
Authors' Addresses section: New contact information for Mark Smith.
Updated the copyright year to 2004.
This Internet Draft expires on 13 August 2004.

1631
doc/drafts/draft-ietf-ldapbis-models-xx.txt
View file

File diff suppressed because it is too large Load diff

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

File diff suppressed because it is too large Load diff

319
doc/drafts/draft-ietf-ldapbis-roadmap-xx.txt
View file

@ -1,25 +1,20 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 15 February 2004
Obsoletes: RFC 2251-2256, 2829-2830, 3377
Expires in six months 24 October 2004
Obsoletes: RFC 2251-2256, 2829-2830, 3377, 3771
Lightweight Directory Access Protocol (LDAP):
Technical Specification Road Map
<draft-ietf-ldapbis-roadmap-04.txt>
<draft-ietf-ldapbis-roadmap-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 published as a Standard Track RFC.
Distribution of this memo is unlimited. Technical discussion of this
@ -27,27 +22,51 @@ Status of this Memo
mailing list <ietf-ldapbis@openldap.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 (C) The Internet Society (2004). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga LDAP: TS Road Map [Page 1]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
Abstract
The Lightweight Directory Access Protocol (LDAP) is an Internet
protocol for accessing distributed directory services which act in
accordance with X.500 data and service models. This document provides
@ -55,24 +74,23 @@ Abstract
Zeilenga LDAP: TS Road Map [Page 1]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-04 15 February 2004
Conventions
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].
1. The LDAP Technical Specification
The technical specification detailing version 3 of the Lightweight
Directory Access Protocol (LDAP), an Internet Protocol, consists of
this document and the following documents:
LDAP: The Protocol [Protocol],
LDAP: Directory Information Models [Models],
LDAP: Authentication Methods and Connection Level Security
@ -84,22 +102,37 @@ Conventions
LDAP: Internationalized String Preparation [LDAPprep], and
LDAP: User Schema [Schema].
The terms "LDAP" and "LDAPv3" are commonly used to informally refer to
the protocol specified by this technical specification. The LDAP
suite, as defined here, should be formally identified in other
documents by a normative reference to this document.
Extensions to LDAP may be specified in other documents. Nomenclature
denoting such combinations of LDAP-plus-extension(s) is not defined by
this document but may be defined in some future document(s).
LDAP is an extensible protocol. Extensions to LDAP may be specified
in other documents. Nomenclature denoting such combinations of
LDAP-plus-extension(s) is not defined by this document but may be
defined in some future document(s). Extensions are expected to be
truly optional.
IANA (Internet Assigned Numbers Authority) considerations for LDAP
described in BCP 64 [BCP64bis] apply fully to this revision of the
LDAP technical specification.
Zeilenga LDAP: TS Road Map [Page 2]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
2. Relationship to X.500
This technical specification defines LDAP in terms of [X.500] as an
X.500 access mechanism. An LDAP server MUST act in accordance with
X.500(1993) series of International Telecommunication Union - Telecom
@ -110,230 +143,316 @@ Conventions
[X.501][X.511] as used in LDAP is not violated in the LDAP interface.
Zeilenga LDAP: TS Road Map [Page 2]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-04 15 February 2004
This technical specification explicitly incorporates portions of
X.500(93). Later revisions of X.500 do not automatically apply.
3. Security Considerations
LDAP security considerations are discussed in each document comprising
the technical specification.
4. Relationship to Obsolete Specifications
This technical specification, as defined in Section 1, obsoletes
entirely the previously defined LDAP technical specification [RFC3377]
(which consists of RFC 2251-2256, RFC 2829-2830 and RFC 3377 itself).
The technical specification was significantly reorganized.
(which consists of RFC 2251-2256, RFC 2829-2830, RFC 3771, and RFC
3377 itself). The technical specification was significantly
reorganized.
This document replaces RFC 3377 as well as Section 3.3 of RFC 2251.
[Models] replaces portions of RFC 2251, RFC 2252 and RFC 2256.
[Protocol] replaces the majority RFC 2251 and portions of RFC 2252.
[AuthMeth] replaces RFC 2829, RFC 2830, and portions of RFC 2251.
[Syntaxes] replaces the majority of RFC 2252 and portions of RFC 2256.
[Schema] replaces the majority of RFC 2256. [LDAPDN] replaces RFC
2253. [Filters] replaces RFC 2254. [LDAPURL] replaces RFC 2255.
[Protocol] replaces the majority RFC 2251, portions of RFC 2252, and
all of RFC 3771. [AuthMeth] replaces RFC 2829, RFC 2830, and portions
of RFC 2251. [Syntaxes] replaces the majority of RFC 2252 and
portions of RFC 2256. [Schema] replaces the majority of RFC 2256.
[LDAPDN] replaces RFC 2253. [Filters] replaces RFC 2254. [LDAPURL]
replaces RFC 2255.
[LDAPprep] is new to this revision of the LDAP technical
specification.
Each document of this specification contains appendices summarizing
changes to all sections of the specifications they replace. Appendix
A.1 of this document details changes made to RFC 3377. Appendix A.2
of this document details changes made to Section 3.3 of RFC 2251.
Additionally, portions of this technical specification update and/or
replace documents not listed above. These relationships are discussed
in the documents detailings these portions of this technical
specification.
replace a number of other documents not listed above. These
Zeilenga LDAP: TS Road Map [Page 3]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
relationships are discussed in the documents detailings these portions
of this technical specification.
5. Acknowledgments
This document is based largely on RFC 3377 by J. Hodges and R.
Morgan, a product of the LDAPBIS and LDAPEXT Working Groups. The
document also borrows from RFC 2251 by M. Wahl, T. Howes, and S.
Kille, a product of the ASID Working Group.
This document is a product of the IETF LDAPBIS Working Group.
Zeilenga LDAP: TS Road Map [Page 3]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-04 15 February 2004
6. Author's Address
Kurt Zeilenga
E-mail: <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.]]
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft-
ietf-ldapbis-bcp64-xx.txt, a work in progress.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-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.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
work in progress.
Zeilenga LDAP: TS Road Map [Page 4]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
[Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
Representation of Search Filters",
draft-ietf-ldapbis-filter-xx.txt, a work in progress.
[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
draft-ietf-ldapbis-url-xx.txt, a work in progress.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[LDAPprep] Zeilenga, K., "LDAP: Internationalized String
Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work
in progress.
[Schema] Dally, K. (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in
progress.
Zeilenga LDAP: TS Road Map [Page 4]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-04 15 February 2004
[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.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).
Directory: Abstract Service Definition", X.511(1993)
(also ISO/IEC 9594-3:1993).
7.2. Informative References
None.
Appendix A. Changes to Previous Documents
This appendix outlines changes this document makes relative to the
documents it replaces (in whole or in part).
Appendix A.1. Changes to RFC 3377
This document is nearly a complete rewrite of RFC 3377 as much of the
material of RFC 3377 is no longer applicable. The changes include
Zeilenga LDAP: TS Road Map [Page 5]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
redefining the terms "LDAP" and "LDAPv3" to refer to this revision of
the technical specification.
Appendix A.2. Changes to Section 3.3 of RFC 2251
The section was modified slightly (the word "document" was replaced
with "technical specification") to clarify that it applies to the
entire LDAP technical specification.
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
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: TS Road Map [Page 5]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-04 15 February 2004
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.
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.
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.
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,
Zeilenga LDAP: TS Road Map [Page 6]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
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: TS Road Map [Page 7]

549
doc/drafts/draft-ietf-ldapbis-url-xx.txt
View file

@ -1,32 +1,40 @@
Network Working Group Mark Smith, Editor
Request for Comments: DRAFT Pearl Crescent, LLC
Obsoletes: RFC 2255 Tim Howes
Expires: 13 August 2004 Opsware, Inc.
Expires: 24 April 2005 Opsware, Inc.
13 February 2004
24 October 2004
LDAP: Uniform Resource Locator
<draft-ietf-ldapbis-url-05.txt>
<draft-ietf-ldapbis-url-07.txt>
1. Status of this Memo
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
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 3668.
This document is intended to be published as a Standards Track RFC,
replacing RFC 2255. Distribution of this memo is unlimited.
Technical discussion of this document will take place on the IETF
LDAP (v3) Revision (ldapbis) Working Group mailing list
<ietf-ldapbis@openldap.org>. Please send editorial comments directly
to the editor <mcs@pearlcrescent.com>.
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
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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
@ -34,13 +42,20 @@ Expires: 13 August 2004 Opsware, Inc.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Discussion of this document should take place on the LDAP (v3)
Revision (ldapbis) Working Group mailing list <ietf-
ldapbis@openldap.org>.
Copyright (C) The Internet Society (2004). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Copyright (C) The Internet Society (2004). All Rights Reserved.
2. Abstract
Smith & Howes Intended Category: Standards Track [Page 1]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
Abstract
This document describes a format for an LDAP Uniform Resource Locator
(URL). An LDAP URL describes an LDAP search operation that is used
@ -48,39 +63,32 @@ Copyright (C) The Internet Society (2004). All Rights Reserved.
an LDAPv3 referral or reference, an LDAP URL describes a service
where an LDAP operation may be progressed.
Table of Contents
Status of this Memo............................................1
Abstract.......................................................2
Table of Contents..............................................2
1. Introduction...................................................2
2. URL Definition.................................................3
2.1. Escaping Using the % Method.................................5
3. Defaults for Fields of the LDAP URL............................5
4. Examples.......................................................6
5. Security Considerations........................................8
6. IANA Considerations............................................9
7. Normative References...........................................9
8. Informative References.........................................10
9. Intellectual Property Rights...................................10
10. Acknowledgements...............................................10
11. Authors' Addresses.............................................11
12. Appendix A: Changes Since RFC 2255.............................11
12.1. Technical Changes...........................................11
12.2. Editorial Changes...........................................12
13. Appendix B: Changes Since Previous Document Revision...........13
13.1. Editorial Changes...........................................14
14. Intellectual Property Rights...................................14
15. Full Copyright.................................................14
Smith & Howes Intended Category: Standards Track [Page 1]
INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
3. Table of Contents
1. Status of this Memo............................................1
2. Abstract.......................................................1
3. Table of Contents..............................................2
4. Introduction...................................................2
5. URL Definition.................................................3
5.1. Escaping Using the % Method.................................4
6. Defaults for Fields of the LDAP URL............................5
7. Examples.......................................................5
8. Security Considerations........................................7
9. Normative References...........................................8
10. Informative References.........................................9
11. Intellectual Property Rights...................................9
12. Acknowledgements...............................................10
13. Authors' Addresses.............................................10
14. Full Copyright Statement.......................................11
15. Appendix A: Changes Since RFC 2255.............................11
15.1. Technical Changes...........................................11
15.2. Editorial Changes...........................................12
16. Appendix B: Changes Since Previous Document Revision...........13
16.1. Technical Changes...........................................14
16.2. Editorial Changes...........................................14
4. Introduction
1. Introduction
LDAP is the Lightweight Directory Access Protocol, defined in
[Protocol]. This document specifies the LDAP URL format for version
@ -95,24 +103,22 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
This document is an integral part of the LDAP Technical Specification
[Roadmap].
This document replaces RFC 2255. See Appendix A for a list of changes
relative to RFC 2255.
The key words "MUST", "MAY", and "SHOULD" used in this document are
to be interpreted as described in [RFC2119].
Smith & Howes Intended Category: Standards Track [Page 2]
INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
5. URL Definition
This document replaces RFC 2255. See Appendix A for a list of changes
relative to RFC 2255.
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].
2. URL Definition
An LDAP URL begins with the protocol prefix "ldap" and is defined by
the following grammar, following the ABNF notation defined in
@ -123,35 +129,48 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
[QUESTION [filter] [QUESTION extensions]]]]]
scheme = "ldap"
hostport = <hostport from Section 3.2.2 of [RFC2396]>
; as updated by [RFC2732] to allow IPv6 literal addresses
; As updated by [RFC2732] to allow
; IPv6 literal addresses
dn = <distinguishedName from Section 3 of [LDAPDN]>
; see the "Escaping Using the % Method" section below.
; See the "Escaping Using the % Method"
; section below.
attributes = attrdesc *(COMMA attrdesc)
attrdesc = <AttributeDescription from Section 4.1.4 of [Protocol]>
attrdesc = <AttributeDescription
from Section 4.1.4 of [Protocol]>
/ ASTERISK
; see the "Escaping Using the % Method" section below.
; See the "Escaping Using the % Method"
; section below.
scope = "base" / "one" / "sub"
filter = <filter from Section 4 of [Filters]>
; see the "Escaping Using the % Method" section below.
; See the "Escaping Using the % Method"
; section below.
extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid / oiddescr
exvalue = <LDAPString from section 4.1.2 of [Protocol]>
; see the "Escaping Using the % Method" section below.
; See the "Escaping Using the % Method"
; section below.
oid = <LDAPOID from section 4.1.2 of [Protocol]>
oiddescr = <name from section 3.3 of [LDAPIANA]>
EXCLAMATION = %x21 ; exclamation mark ("!")
ASTERISK = %x2A ; asterisk ("*")
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
SLASH = %x5C; forward slash ("/")
The "ldap" prefix indicates an entry or entries residing in the LDAP
server running on the given hostname at the given portnumber. Note
that the hostport may contain literal IPv6 addresses as specified in
[RFC2732].
Smith & Howes Intended Category: Standards Track [Page 3]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
The "ldap" prefix indicates an entry or entries accessible from the
LDAP server running on the given hostname at the given portnumber.
Note that the hostport may contain literal IPv6 addresses as
specified in [RFC2732].
The dn is an LDAP Distinguished Name using the string format
described in [LDAPDN]. It identifies the base object of the LDAP
@ -161,13 +180,6 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
be returned from the entry or entries. Individual attrdesc names are
as defined for AttributeDescription in [Protocol].
Smith & Howes Intended Category: Standards Track [Page 3]
INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
The scope construct is used to specify the scope of the search to
perform in the given LDAP server. The allowable scopes are "base"
for a base object search, "one" for a one-level search, or "sub" for
@ -185,14 +197,15 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
LDAP URL extensions are not necessarily related to any of the LDAPv3
extension mechanisms. Extensions may be supported or unsupported by
the client resolving the URL. An extension prefixed with a '!'
character (ASCII 33) is critical. An extension not prefixed with a
character (ASCII 0x21) is critical. An extension not prefixed with a
'!' character is non-critical.
If an LDAP URL extension is recognized by an implementation, the
If an LDAP URL extension is implemented (that is, if the
implementation understands it and is able to use it), the
implementation MUST make use of it. If an extension is not
recognized and is marked critical, the implementation MUST NOT
process the URL. If an extension is not recognized and it not marked
critical, the implementation MUST ignore the extension.
implemented and is marked critical, the implementation MUST NOT
process the URL. If an extension is not implemented and it not
marked critical, the implementation MUST ignore the extension.
The extension type (extype) MAY be specified using the oid form
(e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension). Use
@ -202,9 +215,17 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
No LDAP URL extensions are defined in this document. Other documents
or a future version of this document MAY define one or more
Smith & Howes Intended Category: Standards Track [Page 4]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
extensions.
5.1. Escaping Using the % Method
2.1. Escaping Using the % Method
A generated LDAP URL MUST consist only of the restricted set of
characters included in the uric production that is defined in section
@ -217,19 +238,16 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
[RFC2396] or in the unreserved set defined in section 2.3 of
[RFC2396].
Smith & Howes Intended Category: Standards Track [Page 4]
INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
It is the single Reserved character '?' and occurs inside a dn,
filter, or other element of an LDAP URL.
It is a comma character ',' that occurs inside an extension value.
6. Defaults for Fields of the LDAP URL
Note that before the % method of escaping is applied, the extensions
component of the LDAP URL may contain one or more null (zero) bytes.
No other component may.
3. Defaults for Fields of the LDAP URL
Some fields of the LDAP URL are optional, as described above. In the
absence of any other specification, the following general defaults
@ -254,6 +272,13 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
request to a NULL list, or (in LDAPv3) by requesting the special
attribute name "*").
Smith & Howes Intended Category: Standards Track [Page 5]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
scope
If scope is omitted, a scope of "base" is assumed.
@ -264,22 +289,13 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
If extensions is omitted, no extensions are assumed.
7. Examples
4. Examples
The following are some example LDAP URLs using the format defined
above. The first example is an LDAP URL referring to the University
of Michigan entry, available from an LDAP server of the client's
choosing:
Smith & Howes Intended Category: Standards Track [Page 5]
INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
ldap:///o=University%20of%20Michigan,c=US
The next example is an LDAP URL referring to the University of
@ -312,6 +328,13 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
The next example is an LDAP URL referring to all children of the c=GB
entry:
Smith & Howes Intended Category: Standards Track [Page 6]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
ldap://ldap1.example.com/c=GB?objectClass?one
The objectClass attribute is requested to be returned along with the
@ -327,15 +350,6 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
illustrates the interaction between the LDAP string representation of
filters quoting mechanism and URL quoting mechanisms.
Smith & Howes Intended Category: Standards Track [Page 6]
INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
ldap://ldap3.example.com/o=Babsco,c=US
???(four-octet=%5c00%5c00%5c00%5c04)
@ -368,30 +382,32 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
These three URLs all point to the root DSE on the ldap.example.net
server.
Smith & Howes Intended Category: Standards Track [Page 7]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
The final two examples show use of a hypothetical, experimental bind
name extension (the value associated with the extension is an LDAP DN).
ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
The two URLs are the same, except that the second one marks the e-
bindname extension as critical. Notice the use of the % encoding
The two URLs are the same, except that the second one marks the
e-bindname extension as critical. Notice the use of the % encoding
method to encode the commas within the distinguished name value in
the e-bindname extension.
8. Security Considerations
5. Security Considerations
General URL security considerations discussed in [RFC2396] are
relevant for LDAP URLs.
Smith & Howes Intended Category: Standards Track [Page 7]
INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
The use of security mechanisms when processing LDAP URLs requires
particular care, since clients may encounter many different servers
via URLs, and since URLs are likely to be processed automatically,
@ -423,6 +439,14 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
methods that do not reveal sensitive information is much preferred.
If the URL represents a referral for an update operation, strong
authentication methods SHOULD be used. Please refer to the Security
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
Considerations section of [AuthMeth] for more information.
The LDAP URL format allows the specification of an arbitrary LDAP
@ -432,7 +456,11 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
search, etc. The security implications of resolving an LDAP URL are
the same as those of resolving an LDAP search query.
9. Normative References
6. IANA Considerations
This document has no actions for IANA.
7. Normative References
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a
@ -440,28 +468,20 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
in progress.
[Filters] Smith, M. and Howes, T., "LDAP: String Representation of
Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in
progress.
[LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf-
ldapbis-bcp64-xx.txt, a work in progress.
[LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels," RFC 2119, BCP 14, March 1997.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft-ietf-
ldapbis-protocol-xx.txt, a work in progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
@ -476,14 +496,21 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
Smith & Howes Intended Category: Standards Track [Page 9]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 3629, November 2003.
10. Informative References
8. Informative References
None.
11. Intellectual Property Rights
9. 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
@ -496,14 +523,6 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
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
Smith & Howes Intended Category: Standards Track [Page 9]
INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
@ -513,7 +532,7 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
this standard. Please address the information to the IETF Executive
Director.
12. Acknowledgements
10. Acknowledgements
The LDAP URL format was originally defined at the University of
Michigan. This material is based upon work supported by the National
@ -531,7 +550,16 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
thanks for their contributions.
13. Authors' Addresses
Smith & Howes Intended Category: Standards Track [Page 10]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
11. Authors' Addresses
Mark Smith, Editor
Pearl Crescent, LLC
@ -549,48 +577,9 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
+1 408 744-7509
howes@opsware.com
12. Appendix A: Changes Since RFC 2255
Smith & Howes Intended Category: Standards Track [Page 10]
INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
14. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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 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.
The limited permissions granted above are perpetual and will not be
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.
15. Appendix A: Changes Since RFC 2255
15.1. Technical Changes
12.1. Technical Changes
The following technical changes were made to the contents of the "URL
Definition" section:
@ -607,15 +596,6 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
Added angle brackets around free-form prose in the "dn", "hostport",
"attrdesc", "filter", and "exvalue" rules.
Smith & Howes Intended Category: Standards Track [Page 11]
INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
Changed the ABNF for ldapurl to group the dn component with the
preceding slash.
@ -626,10 +606,19 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
Reordered rules to more closely follow the order the elements appear
in the URL.
Smith & Howes Intended Category: Standards Track [Page 11]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
"Bindname Extension": removed due to lack of known implementations.
15.2. Editorial Changes
12.2. Editorial Changes
Changed document title to include "LDAP:" prefix.
@ -641,7 +630,7 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
"Abstract" section: separated from introductory material.
"Table of Contents" section: added.
"Table of Contents" and "IANA Considerations" sections: added.
"Introduction" section: new section; separated from the Abstract.
Changed the text indicate that RFC 2255 is replaced by this document
@ -654,24 +643,19 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
"URL Definition" section: removed second copy of ldapurl grammar and
following two paragraphs (editorial error in RFC 2255). Fixed line
break within '!' sequence. Reworded last paragraph to clarify which
break within '!' sequence. Replaced "residing in the LDAP server"
with "accessible from the LDAP server" in the sentence immediately
following the ABNF. Reworded last paragraph to clarify which
characters must be URL escaped. Added text to indicate that LDAP
URLs are used for references and referrals. Added text that refers
to the ABNF from RFC 2234. Clarified and strengthened the
requirements with respect to processing of URLs that contain
recognized and unrecognized extensions (the approach now matches that
specified in [Protocol] for LDAP controls).
implements and not implemented extensions (the approach now closely
matches that specified in [Protocol] for LDAP controls).
"Defaults for Fields of the LDAP URL" section: added; formed by
moving text about defaults out of the "URL Definition" section.
Smith & Howes Intended Category: Standards Track [Page 12]
INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
"URL Processing" section: clarified that connections MAY be reused
only if the open connection is compatible with the URL. Added text
to indicate that use of security services is encouraged and that they
@ -679,6 +663,14 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
discussion of authentication methods. Added note that the client MAY
interrogate the server to determine the most appropriate method.
Smith & Howes Intended Category: Standards Track [Page 12]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
"Examples" section: Modified examples to use example.com and
example.net hostnames. Added missing '?' to the LDAP URL example
whose filter contains three null bytes. Removed space after one
@ -715,70 +707,133 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
Copyright: updated the year.
16. Appendix B: Changes Since Previous Document Revision
13. Appendix B: Changes Since Previous Document Revision
This appendix lists all changes relative to the previously published
revision, draft-ietf-ldapbis-url-04.txt. Note that when appropriate
revision, draft-ietf-ldapbis-url-06.txt. Note that when appropriate
these changes are also included in Appendix A, but are also included
here for the benefit of the people who have already reviewed
draft-ietf-ldapbis-url-06.txt. This section will be removed before
this document is published as an RFC.
Smith & Howes Intended Category: Standards Track [Page 13]
INTERNET-DRAFT LDAP: Uniform Resource Locator 13 February 2004
here for the benefit of the people who have already reviewed draft-
ietf-ldapbis-url-04.txt. This section will be removed before this
document is published as an RFC.
16.1. Technical Changes
Clarified and strengthened the requirements with respect to
processing of URLs that contain recognized and unrecognized
extensions (the approach now matches that specified in [Protocol] for
LDAP controls).
16.2. Editorial Changes
"URL Definition" section: corrected a section reference to
[Protocol].
"Examples" section: improved formatting and fixed a typographic error
(removed extraneous "IP") in the "four-octet" example.
"Normative References" section: changed the UTF-8 reference to point
to RFC 3629, changed the RFC 3383 reference to point to the LDAP IANA
Internet Draft, and indented the reference descriptions to enhance
readability.
Authors' Addresses section: New contact information for Mark Smith.
Updated the copyright year to 2004.
This Internet Draft expires on 13 August 2004.
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
13.1. Editorial Changes
"Status of this Memo" section: replaced RFC 3668 (IPR) boilerplate
paragraph with the version that says "each author" instead of "I."
"URL Definition" section: replaced phrases such as "recognized by"
with "implemented by" when referring to LDAP URL extensions.
"URL Definition" section: added the following two sentences at the
end of the subsection on "Escaping Using the % Method":
Note that before the % method of escaping is applied, the
extensions component of the LDAP URL may contain one or more null
(zero) bytes. No other component may.
14. 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.
15. 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,
Smith & Howes Intended Category: Standards Track [Page 14]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
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 Internet Draft expires on 24 April 2005.
Smith & Howes Intended Category: Standards Track [Page 15]

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

@ -0,0 +1,278 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Experimental OpenLDAP Foundation
Expires in six months 17 October 2004
LDAP Modify-Increment Extension
<draft-zeilenga-ldap-incr-00.txt>
Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as an Experimental 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, 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.
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.
1. Background and Intended Use
The Lightwieght 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
other clients between this add and modify, the client must be careful
to construct the modify request so that it fails in this case, and
upon failure, re-read the values and construct a new modify request.
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.
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].
2. The Modify-Increment Extension
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.
Zeilenga LDAP Modify-Increment Extension [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
3. LDIF Support
To represent Modify-Increment requests in LDAP Data Interchange Format
[RFC2849], the ABNF [RFC2234] production <mod-spec> is extended as
follows:
mod-spec /= "increment:" FILL AttributeDescription SEP
attrval-spec "-" SEP
For example,
# Increment uidNumber
dn: cn=max-assigned uidNumber,dc=example,dc=com
changetype: modify
increment: uidNumber
uidNumber: 1
-
This LDIF fragment represents a Modify request to increment the
value(s) of uidNumber by 1.
4. Security Considerations
General LDAP security considerations [Roadmap], as well as those
specific to the LDAP Modify [Protocol], apply to this Modify-Increment
extension. Beyond these considerations, it is noted that introduction
of this extension should reduce application complexity (by provide one
operation what presently requires multiple operation) and, hence, may
aide in the production of correct and secure implementations.
5. IANA Considerations
Registration of the LDAP Protocol Mechanism [BCP64bis] defined in
document is requested.
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: OID-TBD
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
Zeilenga LDAP Modify-Increment Extension [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
6. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
7. 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.
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
Technical Specification", RFC 2849, June 2000.
[Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674,
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.
8. 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",
draft-zeilenga-ldap-readentry-xx.txt, a work in
progress.
[ASSERT] Zeilenga, K., "LDAP Assertion Control",
draft-zeilenga-ldap-assert-xx.txt, a work in progress.
[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.
Zeilenga LDAP Modify-Increment Extension [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
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
"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 Modify-Increment Extension [Page 5]

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

@ -0,0 +1,895 @@
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]

1
doc/rfc/INDEX
View file

@ -47,6 +47,7 @@ rfc3829.txt LDAP Authorization Identity Controls (I)
rfc3866.txt Language Tag and Ranges in LDAP (PS)
rfc3876.txt Returning Matched Values with LDAP (PS)
rfc3909.txt LDAP Cancel Operation (PS)
rfc3928.txt LDAP Client Update Protocol (PS)
Legend:
STD Standard

1683
doc/rfc/rfc3928.txt Normal file
View file

File diff suppressed because it is too large Load diff