LDAPEXT Minutes

[Mark Wahl <Mark.Wahl@sun.com>]

Mark Wahl
Sun Microsystems Inc.

LDAPEXT: LDAP Extensions Working Group
Minutes recorded by Mark Wahl <Mark.Wahl@sun.com>

Agenda:
 - preliminaries
 - extensions
 - server discovery
 - access control
 - subentries
 - schema updates

Preliminaries
=============

Agenda discussion: where should the interaction of replication and Access
control be discussed? John Strassner said: Replication issues for acls are 
part of the scope of the acl document.

Draft status:

 cldap: there is a new draft -01.

 C API: no progress since last meeting.

 duplicate entries: last call will be done after meeting.

 java API: in WG last call.

 matched valued: last call will be done after meeting.

 referrals: last call on Kurt's document will be done after meeting.
 no progress for other referral types.

 server discovery: would like to last call the locate document after the
 meeting.  The taxonomy document is waiting on locate. 

 subentries: there is a new draft -07.

 X.509 SASL mechanism: no WG activity, would like to push out of WG and 
 make an individual work item.

 VLV: pending on the resolution of result codes, but otherwise done.

There was a brief charter discussion: What is LDAPEXT heading for??
Many possible future work items were discussed at the last meeting, but
other than those around schema update (to be discussed at the end of this
meeting), there was not a sign of significant interest from many different
people in working on them, only a few people seemed interested in these 
work items.

Charter and futures discussion taken to the mailing list.

Extension guide
===============

Topics discussed: result codes, meaning of multiple controls, 
border between defining new extensions and controls, extension to the ASN.1.

Result codes: How to extend result codes? A result code for controls? 

Kurt Zeilenga proposed having an IANA registry and a review process.  He
will write a BCP for last calling in both LDAPBIS and LDAPEXT.  

Bob Morgan suggested also a directorate to review other uses of LDAP.  Those 
discussions would then not need to occur on the working group mailing lists.
Ed Reed emphasised the need for review, to differentiate the use of 
extensions to the directory for using the directory, versus using LDAP as 
an arbitrary RPC.  Kurt Zeilenga recommended that this group would not itself
have enforcement power to restrict what implementors would do, but could
prevent conflicts through the use of a registry of known extensions.  

Multiple controls: what happens when this interaction is not defined?  There
could be a mismatch between this and the extensions handling behavior in 
X.500 and in PKIX for certificate extensions.  Kurt Zeilenga recommended not 
specifying the behavior for LDAP in order to avoid constraining controls: if
clients want particular semantics they should mark the controls as critical.
As there has been discussion for existing controls and their interaction,
Mark Wahl added that when an existing control RFC goes to Draft Standard
status, then textual clarifications could be added to resolve ambiguities.

When to define an extension versus when to define a control: should be in 
the extensions guide.

How much to change in the ASN.1 when extending?  Kurt Zeilenga proposed that
the type or scope of an extension could change the PDU if the peer advertised
support for it; others that the extension should not contradict the 
underlying specification. 

Server discovery through DNS (Bob Morgan)
=========================================

The document contains an algorithm to map some distinguished names to domain 
names.  Tim Polk, co-chair of PKIX, said he would like to use this general 
approach to locate directory servers, but the locate draft is too rigid.
PKI today has no global directory infrastructure, so a PKI user needs to find 
information from directory servers in other organizations.  One solution is 
to embed information into certificates and CRLs, such as the name of the 
repository, but this is not elegant. The PKI repository locator service uses 
DNS to find it: it will become an experimental RFC as it covers any possible 
protocol.  There is a need to find directories, and for that they need to
find out what the domain name is of the end-cert organization.

PKIX's specifications are agnostic about names: DN might be composed of any 
attributes.   Early adopters of PKI have used X.520 attributes: their 
certificates have had names rooted in C=US etc.  Tim Polk proposed that 
locate would be more useful with this change: process all RDN components, 
ignoring those which are not domain components.  While future deployments
might move to DC components entirely, this change would provide a 
migration strategy.

Some of the issues discussed:
 - The locate draft is based on RFC 2247, which is a bidirectional mapping.
   Would it be necessary to update 2247 as well?  (Mark Wahl)

 - This change may also imply a change in multivalued attributes processing.
   (Bob Morgan)

 - End users could add DC components 'below' their name, this might have 
   a security consideration.  (Kurt Zeilenga)

 - Also need to consider internationalized domain components. (Kurt Zeilenga)

 - Is the specification the only way to map from distinguished names to 
   domain names?  If this specification were to be a Proposed Standard,
   could there be others, for example to consider the problem where there
   are domain components elsewhere in the DN?  (Paul Leach)

 - There is a different approach from ITU-T/ISO X.500 for more general 
   mapping of distinguished names, based on a new DNS resource record.
   Skip Slone will publish an internet draft. (Skip Slone)

 - A variant which allows for any domain components (not just those on the
   right) to be used only if the certificate can be validated, by
   'canonicalizing' the DN. (Paul Leach)

 - Domain entries below organizations may not be supported by the 
   current DIT containment rules in X.500. (Ed Reed)

 - When using TLS, there are rules for matching names in server certificates.
   (Bob Morgan)

The document authors will get input and review possible changes.  If there
are changes and a new internet draft, it might need to go back through WG 
last call.
 
ACL
===

Issues:
 - application defined permission and extensibility
 - extensible operation permission
 - replication requirements

Ellen Stokes said that it was resolved at a prior meeting that application
defined permission would be out of scope.  Kurt Zeilenga added that a new
attribute type could be defined. 

As John Strassner, co-chair of LDUP, requested that replication requirements 
of a document should be addressed in the working group where the document is 
authored, Rick Huber will incorporate replication requirements into the 
access control drafts.  This will be completed by the next meeting, with 
a draft in June suitable for last call.

Subentry-07 (Ed Reed)
====================

Changes in subentry -07:
 - applied changes requested at last IETF,
 - removed inheritance propigation discussion to draft-reed-,
 - removed search filter mechanism, to avoid the complexity of search filters,
   use control only or base object search.

Kurt Zeilenga added that he would like to allow for any scope search to
match subentries if the base of the search is a subentry.

Ed Reed will separate inheritableLDAPSubentry to a different document, and
issue revision -08.

LDAP Schema update procedures (Tim Hahn)
========================================

Follow on from a Bar BOF at San Diego.

Topic areas of interest:

 - procedures for merging and updating schema in server.

 - extensions to attributeTypes and objectClasses BNF for flags, such as 
   uniqueness, referential integrity etc.

 - determine allowable changes to existing schema entries,  e.g. changing 
   matching rules of an attribute might do harm (cause inconsistency in the 
   DIT).

 - define procedures for partitioning schema.

 - Define how to ensure that unique attribute and object class names are used.

 - Allow clients to discover attribute type options e.g. ;binary.

There is some interest in this work area.  There was discussion of whether  
this belongs in LDAPEXT, or might be a new follow-on working group. 

End of Meeting
==============