Subject: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3"

From: [email-masked]
Date: Mon, 26 Jun 2000 00:32:55 -0700

[this time I actually attached the I-D, doh ]

RFCs 2829 and 2830 were recently published, nominally meeting the IESG's 
requirement for rescinding the "IESG Note" gracing the first pages of RFCs 
2251..2256. Patrick has indicated that we can address the "Note" by publishing 
an RFC that "updates" 2251..2256.

Additionally, we've spoken at various times of a "core" set of LDAPv3 RFCs, 
nominally represented by 2251..2256 (plus the two I-Ds that have become 2829 
and 2830) but this has never been formally defined.

The attached I-D (draft-hodges-ldapv3-as-00.txt) is a draft for an 
"applicability statement" (see RFC 2026 section 3.2) both rescinding the Note 
and defining the set of RFCs constituting LDAPv3.

We're suggesting that LDAPEXT work to refine this I-D and submit it for 
Standards Track. This will clarify what constitutes LDAPv3 as presently 
specified and help mitigate any issues that might have arisen due to the "IESG 
Note".

May we please add this item to the Pittsburgh LDAPEXT agenda?

thanks,

Jeff Hodges & RL "Bob" Morgan

                                               Jeff Hodges, Oblix Inc.
INTERNET-DRAFT                     RL "Bob" Morgan, Univ of Washington
Intended Category:                                          June, 2000
  Standards Track
Updates: 2251, 2252, 2253, 2254,
  2255, 2256, 2829, 2830

              Lightweight Directory Access Protocol (v3):
                        Applicability Statement
                    <draft-hodges-ldapv3-as-00.txt>

                        Status of this Document

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet 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.

Comments and suggestions on this document are encouraged.  Comments on
this document should be sent to the LDAPEXT working group discussion
list:
                       [email-masked]

This document expires in January 2001.

Abstract

The specification for the Lightweight Directory Access Protocol version
3 (LDAPv3) nominally comprises eight separte RFCs which were issued in
two distinct subsets at separate times (RFCs 2251..2256 first, then RFCs
2229 and 2830 following later), but this has never been formally stated.
Additionally, RFCs 2251..2256 each are embellished with an "IESG Note"

Hodges, Morgan                                                  [Page 1]

I-D     LDAPv3: Applicability Statement                        June 2000

warning implementors and deployers of potential interoperability prob-
lems due to the lack of a specification of mandatory-to-implement
authentication mechanism(s). This document corrects both situations by
explicitly specifying the set of RFCs comprising LDAPv3 and rescinding
the "IESG Note" due to the specification of mandatory-to-implement
authentication mechanisms in RFC 2829.

1.  Conventions Used in this Document

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 [ReqsKeywords].

2.  Specification of LDAPv3

The Lightweight Directory Access Protocol version 3 (LDAPv3) is speci-
fied by this set of RFCs: 2251, 2252, 2253, 2254, 2255, 2256, 2829, 2830
[1..8]. The term "LDAPv3" MAY be used to informally refer to the proto-
col specified by this set of RFCs.

   [question: Should RFC 2849..

    <URL:ftp://ftp.isi.edu/in-notes/authors/rfc2849.txt>

    ..also be included in the "LDAPv3" definition?]

Other RFCs (and perhaps Internet-Drafts) MAY specify extensions to
LDAPv3.  Nomenclature denoting such combinations of LDAPv3-plus-
extension(s) is not defined at this time.

3.  Rescindment of the "IESG Note" from RFCs 2251..2256

The IESG approved publishing RFCs 2251..2256 with an attendant "IESG
Note" (Note).  The Note begins with..

   This document describes a directory access protocol that provides
   both read and update access.  Update access requires secure authenti-
   cation, but this document does not mandate implementation of any
   satisfactory authentication mechanisms.

The Note ends with this statement..

   Implementors are hereby discouraged from deploying LDAPv3 clients or
   servers which implement the update functionality, until a Proposed
   Standard for mandatory authentication in LDAPv3 has been approved and
   published as an RFC.

Hodges, Morgan                                                  [Page 2]

I-D     LDAPv3: Applicability Statement                        June 2000

RFC 2829 [7] is the "Proposed Standard for mandatory authentication in
LDAPv3" being called for in the Note. Therefore, the IESG Note on RFCs
2251, 2252, 2253, 2254, 2255, and 2256 is hereby rescinded.

4.  Security Considerations

This document does not directly discuss security, although the context
of the aforementioned "IESG Note" is security-related, as is the res-
cindment of the Note being recommended herein.

Please refer to the referenced documents, especially [7], for further
information concerning LDAPv3 security aspects.

5.  Acknowledgements

The authors thank ...  for their contributions to this document.

6.  References

[1]    M. Wahl, S. Kille and T. Howes, "Lightweight Directory Access
       Protocol (v3)", RFC 2251, December 1997.

[2]    M. Wahl, A. Coulbeck, T. Howes, and S. Kille, "Lightweight Direc-
       tory Access Protocol (v3): Attribute Syntax Definitions", RFC
       2252, December 1997.

[3]    S. Kille, M. Wahl, and T. Howes, "Lightweight Directory Access
       Protocol (v3): UTF-8 String Representation of Distinguished
       Names", RFC 2253, December 1997.

[4]    T. Howes, "The String Representation of LDAP Search Filters", RFC
       2254, December 1997.

[5]    T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December
       1997.

[6]    M. Wahl, "A Summary of the X.500(96) User Schema for use with
       LDAPv3", RFC 2256, December 1997.

[7]    M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. "Authentication
       Methods for LDAP", RFC 2829, May 2000.

[8]    J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access Pro-
       tocol (v3): Extension for Transport Layer Security", RFC 2830,
       May 2000.

[ReqsKeywords] Scott Bradner. "Key Words for use in RFCs to Indicate
               Requirement Levels". RFC 2119.

Hodges, Morgan                                                  [Page 3]

I-D     LDAPv3: Applicability Statement                        June 2000

7.  Authors' Addresses

   Jeff Hodges
   Oblix, Inc.
   18922 Forge Drive
   Cupertino, CA 95014
   USA

   Phone: +1-408-861-6656
   EMail: [email-masked]

   RL "Bob" Morgan
   Computing and Communications
   University of Washington
   Seattle, WA
   USA

   Phone: +1-206-221-3307
   EMail: [email-masked]

                  -----------------------------------

8.  Intellectual Property Rights Notices

The IETF takes no position regarding the validity or scope of any intel-
lectual 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 stan-
dard.  Please address the information to the IETF Executive Director.

9.  Copyright Notice and Disclaimer

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Hodges, Morgan                                                  [Page 4]

I-D     LDAPv3: Applicability Statement                        June 2000

   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 develop-
   ing 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 MER-
   CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

                    -----------------------------------

   This document expires in January 2001.

Hodges, Morgan                                                  [Page 5]

---

From: "David Chadwick" <[email-masked]>
Date: Thu, 29 Jun 2000 18:37:59 +0100

Jeff

I would like to suggest that we do not have an applicability 
statement as you are suggesting but rather that we re-issue the 
base RFC with bug fixes and omissions that various people have 
pointed out over the years. I believe that Mark Wahl is keeping a 
note of these. For your convenience, I reproduce below text from 
my PKIX ID that is profiling the use of LDAPv3 for PKIs. YOu will 
see that there are various omissions in the base LDAPv3 
documents that need to be fixed, and I would like to see the RFCs 
re-issued with the extra text inserted into them, rather than 
publishing your ID that simply removes the notes. What do others 
think?

David

Schema    Issues (taken from <draft-pkix-ldap-v3-01.txt>)

RFC2587 [16] describes some of the subschema applicable to 
LDAPv2 servers, specifically the public key certificate 
related attribute types and object classes that MUST or MAY 
be supported. RFC2587 is equally applicable to LDAPv3 
servers and MUST be supported by them.

RFC2587 does not describe in detail the matching rules that 
should be supported by LDAP servers, nor does it describe 
how attribute value assertions for each matching rule 
should be encoded in filter items (in fact these AVA 
encodings are not currently described anywhere).

Finally RFC2587 does not mention attributeCertificates, 
since these are a relatively new development.

LDAPv3 allows the subschema supported by a server to be 
published in a subschema subentry. Clients following this 
profile which support the Search operation containing an 
extensible matching rule MAY use the subschemaSubentry 
attribute in the root DSE to find the subschemaSubentry, 
and MAY use the matchingRule and matchingRuleUse 
operational attributes in the subschema subentry in order 
to determine whether the server supports the various 
matching rules described below. Servers which support 
extensible matching SHOULD publish the matching rules they 
support in the matchingRule and matchingRuleUse operational 
attributes.

X.509(1997) [9] supports both equality and flexible 
certificate matching rules by the server, via the 
certificateExactMatch and certificateMatch MATCHING-RULEs 
respectively. (For example, a client may flexibly search 
for certificates with a particular validity time, key 
usage, policy or other field.) LDAPv3 servers MUST support 
the certificateExactMatch matching rule. Clients MAY 
support certificateExactMatch values for equalityMatch 
filters. LDAPv3 servers MAY support the certificateMatch 
matching rule. If the server does support flexible matching 
(either via certificateMatch or some other matching rule), 
then the extensibleMatch filter of the Search request MUST 
be supported. Clients MAY support the extensibleMatch 
filter and one or more of the optional elements of 
certificateMatch.

However, neither of the above matching rules are mentioned 
in the LDAPv3 standards [13 or 14], and only the equality 
matching rule is mentioned in [16], but nowhere is it 
defined for LDAP servers. It is expected that future 
revisions of the LDAPv3 documents will include these 
definitions, which are tentatively proposed below. 

( 2.5.13.34 NAME 'certificateExactMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'Certificate Serial 
Number and Issuer' )

Values in this syntax are encoded as an integer, a dollar 
($) separator and a string encoding of the distinguished 
name of the issuing CA.

The string description of the certificateMatch matching 
rule is proposed here as:

( 2.5.13.35 NAME 'certificateMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.55 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.55 DESC 'Certificate 
Assertion' )

The ASN.1 for certificateAssertion is defined in 12.7.2 of 
[9]. The LDAP string encoding of this is t.b.d. (but it 
will be similar to userCertificate syntax defined in RFC 
1778).

X.509(1997) [9] supports both equality and flexible 
matching rules of CRLs by the server, via the 
certificateListExactMatch and certificateListMatch MATCHING-
RULEs respectively. LDAPv3 servers MUST (or should it be 
MAY?) support the certificateListExactMatch matching rule. 
Clients MAY support certificateListExactMatch values for 
equalityMatch filters. LDAPv3 servers MAY support the 
certificateListMatch matching rule. If the server does 
support flexible matching (either via certificateListMatch 
or some other matching rule), then the extensibleMatch 
filter of the Search request MUST be supported. Clients MAY 
support the extensibleMatch filter and one or more of the 
optional elements of certificateListMatch.

Neither of the above matching rules are mentioned in the 
LDAPv3 standards [13 or 14], and only the 
certificateListExactMatch matching rule is mentioned in 
[16], but nowhere is it defined for LDAP servers. It is 
expected that future revisions of the LDAPv3 documents will 
include these definitions, which are tentatively proposed 
below. 

( 2.5.13.38 NAME 'certificateListExactMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.56 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.56 DESC 'Issuer name, time and 
distribution point name' )

Values in this syntax are encoded as a string encoding of a 
distinguished name, a dollar ($) separator, a string 
representation of generalised time, a dollar separator and 
an optional string encoding of the distinguished name of 
the distribution point. (Note that the latter DN encoding 
for a distribution point name is a subset of the allowed 
variants, which can be a generalName or an RDN. Should this 
simplification be allowed?)

The string description of the certificateListMatch matching 
rule is proposed here as:

( 2.5.13.39 NAME 'certificateListMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.57 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.57 DESC 'Certificate List 
Assertion' )

The ASN.1 for certificateListAssertion is defined in 12.7.6 
of [9]. The LDAP string encoding of this is t.b.d.

Editors Notes.
We        need to decide whether searching for cross 
          certificates should be supported by this LDAPv3 profile 
          or not. If we decide that this should be supported, then 
          we will need to define the matching rules to be 
          supported and the string encodings for the assertion 
          syntaxes (in fact this is not too difficult since they 
          are similar to certificate matching rules and AVAs).
We        need to decide if userSMIMECertificates should also 
          be supported as part of this profile or not.

LDAPv3 servers MAY store attributeCertificates, and clients 
MAY request then to be returned by adding them to the 
Search Request AttributeDescriptionList (either explicitly 
or implicity via requesting all attributes). LDAPv3 servers 
MAY support searching for entries containing specific 
attribute certificates, via either the 
attributeCertificateExactMatch or attributeCertificateMatch 
matching rules. For the convenience of the reader, some of 
the subchema definitions to support attribute certificates 
are produced below, but it is anticipated that these will 
be moved to a subsequent revision of the LDAPv3 standard.

attributeCertificate    ATTRIBUTE  ::=  {
     WITH SYNTAX   AttributeCertificate
     EQUALITY MATCHING RULE   attributeCertificateExactMatch
     ID  joint-iso-ccitt(2) ds(5) attributeType(4) 
attributeCertificate(58) }

pmiUser OBJECT-CLASS ::= {  
-- a PMI user (i.e., a “claimant”)
   SUBCLASS OF  {top}
   KIND         auxiliary
   MAY CONTAIN  {attributeCertificate}
   ID 	joint-iso-ccitt(2) ds(5) objectClass(6) pmiUser 
(24)}

attributeCertificateExactMatch MATCHING-RULE  ::= {
SYNTAX	AttributeCertificateExactAssertion
ID	joint-iso-ccitt(2) ds(5) mr (13) 
attributeCertificateExactMatch (45) }

AttributeCertificateExactAssertion	::=	SEQUENCE {
serialNumber		CertificateSerialNumber,
issuer			IssuerSerial 	}

attributeCertificateMatch  MATCHING-RULE  ::=  {
	SYNTAX	AttributeCertificateAssertion
	ID		joint-iso-ccitt(2) ds(5) mr (13) 
attributeCertificateMatch (??) }

AttributeCertificateAssertion  ::=  SEQUENCE  {
subject		[0]	CHOICE {
			baseCertificateID	[0]  
IssuerSerial,
			subjectName		[1]  
GeneralNames} OPTIONAL,
	issuer		[1]	GeneralNames OPTIONAL,
	attCertValidity	[2]	GeneralizedTime OPTIONAL,
	attType		[3]	SET OF AttributeType 
OPTIONAL}
--At least one component of the sequence must be present

The LDAP definitions and syntaxes for the above matching 
rules are suggested to be:

( 2.5.13.45 NAME 'attributeCertificateExactMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Attribute certificate 
serial number and public key issuer and serial number' )

Values in this syntax are encoded as a string encoding of 
an integer (the serial number of the attribute 
certificate), a dollar ($) separator, a string 
representation of the distinguished name of the CA of the 
issuer (note this is a subset of the allowed GeneralName), 
a dollar separator and a string encoding of an integer (the 
serial number of the issuer’s public key certificate). 

The LDAP definition of the attributeCertificateMatch 
matching rule is proposed here as:

( 2.5.13.?? NAME 'attributeCertificateMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.59 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.59 DESC 'Attribute Certificate 
Assertion' )

The LDAP string encoding of this is t.b.d.

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 29 Jun 2000 11:52:35 -0700 (PDT)

On Thu, 29 Jun 2000, David Chadwick wrote:

> I would like to suggest that we do not have an applicability statement
> as you are suggesting but rather that we re-issue the base RFC with
> bug fixes and omissions that various people have pointed out over the
> years. I believe that Mark Wahl is keeping a note of these. For your
> convenience, I reproduce below text from my PKIX ID that is profiling
> the use of LDAPv3 for PKIs.  You will see that there are various
> omissions in the base LDAPv3 documents that need to be fixed, and I
> would like to see the RFCs re-issued with the extra text inserted into
> them, rather than publishing your ID that simply removes the notes.
> What do others think?

Well, if the effort required to produce 2251-2256 is set at 10, I'd say
the effort to issue followups to them is a 5, and we're hoping the effort
required to get this applicability statement out the door and officially
remove the IESG warning is a 1.  I agree that doing revised versions of
the base docs is A Good Thing To Do, but even deciding whether to recycle
them at Proposed or move to Draft is likely to be contentious.  I believe
this was briefly discussed in Adelaide and the WG chair indicated that he
thought that doing revised versions should come after completing the
existing work items, including access control, which themselves will take
a while.

 - RL "Bob"

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 29 Jun 2000 12:31:27 -0700

I feel:
	a) an applicability statement is needed
	b) RFC2251-56,2829-30 need revision (some more than others)

These, in my opinion, are separate issues.

I believe an applicability statement should be published
and that it should rescind the IESG notice regarding
applicability of the technical specifications (RFC 2251-56).

I believe we need to identify necessary work items necessary to
produce specifications progressable to Draft Standard.  I believe
it will be necessary to reissue the complete set of LDAPv3 RFC
as Proposed Standard.

I propose that we schedule an session at IETF#48 to discuss
the issues regarding the LDAPv3bis documents.  A separate
session, I believe, to ensure this and other agenda items
get the attention they deserve.

At 11:52 AM 6/29/00 -0700, RL 'Bob' Morgan wrote:
>I believe this was briefly discussed in Adelaide and the WG chair
>indicated that he thought that doing revised versions should come
>after completing the existing work items, including access control,
>which themselves will take a while.

Though I agree that the chair as stated this, I do not agree with
this approach.  LDAPv3bis documents are critical to the success
of LDAP.  We should work LDAPv3bis issues without delay.  There
is no shortage of volunteers to undertake LDAPv3bis work.

Kurt

---

From: "David Chadwick" <[email-masked]>
Date: Thu, 29 Jun 2000 23:33:46 +0100

> Well, if the effort required to produce 2251-2256 is set at 10, I'd
> say the effort to issue followups to them is a 5, and we're hoping the
> effort required to get this applicability statement out the door and
> officially remove the IESG warning is a 1. 

But the value of revised RFCs is an order of magnitude more than a 
removed warning. Therefore we should concentrate on the higher 
goal if we can and not be deflected by relative trivia.

David

>I agree that doing revised
> versions of the base docs is A Good Thing To Do, but even deciding
> whether to recycle them at Proposed or move to Draft is likely to be
> contentious.  I believe this was briefly discussed in Adelaide and the
> WG chair indicated that he thought that doing revised versions should
> come after completing the existing work items, including access
> control, which themselves will take a while.
> 
>  - RL "Bob"
> 
> 
> 

David Chadwick

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 29 Jun 2000 16:06:31 -0700

>applicability of the technical specifications (RFC 2251-56).

On second thought, I guess I would have to object to
the progression of the AS if it included any changes
to the technical specification.

If one were to rescind the IESG notice, I would think
it appropriate to strength the Security Considerations
of the specifications.  Something like:
   Update functionality SHOULD be restricted to securely
   authenticated clients.

As such, I cannot support progressing the AS in its
current form as it would either result in inadequate
specification of Security Considerations or would
modify the technical specification.

Kurt