DRAFT IETF 52 ldapbis WG meeting notes

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

Below are the DRAFT meeting notes from the ldapbis WG meeting at IETF 52
in Salt Lake City.  I offer my traditional apology that these are supposed
to be submitted to the IETF by 1700 EST-US today, so any changes will have
to get to me quickly.  But please do review and send me any corrections.

 - RL "Bob"

---

DRAFT ldapbis meeting notes
52nd IETF, Salt Lake City, December 12, 2001
Kurt Zeilenga and RL "Bob" Morgan, co-chairs
RL "Bob" Morgan, David Chadwick, and Roger Harrison, note-takers

Kurt called the meeting to order at 9AM.  Following agenda-bashing,
the first item was document status.

The LDAPv3 technical specification
(draft-ietf-ldapbis-ldapv3-ts-00.txt) is through IETF last call, and
is awaiting (and awaiting) action from the IESG.  The IANA
considerations document (draft-ietf-ldapbis-iana-04.txt) is in ldapbis
WG last call now.

3 documents (draft-ietf-ldapbis-dn-06.txt,
draft-ietf-ldapbis-filter-01.txt, draft-ietf-ldapbis-url-01.txt) are
already through WG last call and are awaiting implementation reports.

The four larger documents (protocol, authmeth, syntaxes, user-schema)
are making progress but still have open issues.  Each editor was asked
to estimate the date of producing the next revision and the date when
the doc will be ready for WG last call.

Kurt said that implementation reports are really about to start; help
is once again solicited.

Non-ldapbis documents on which progression of ldapbis documents
depend are:  a revision of RFC 2234 on ABNF (this has been promised by
the document author); a revision of RFC 2222 on SASL (this is in
process; a SASL WG may or may not be formed); a revision of RFC 2831
on Digest-MD5 (this is in process); and a revision of RFC 2246 on TLS
(there is no apparent activity on this, encouragement is necessary).

Kurt spoke about the IANA considerations document.  Comments have been
made on the list; Kurt has offered new text for sections 5.2 and 5.3.
A new revision will be produced shortly after the close of the last
call on 2001-12-17, and the doc should be ready to be sent to the ADs
at that point.

Jim Sermersheim spoke about the protocol document.  It is now at -05;
a change history is in the Appendix.  An engineering team was formed
after IETF 51 to work on issues with attribute options.  It has been
observed that different options work in different ways.  The team
proposes that two kinds of options be defined: (1) tagging
(specialization) options, based on the behavior of language tags; and
(2) transfer options, based on the behavior of the ";binary" option.
For tagging options, values are stored, the options carry
inheritance/subtyping semantics, and they are not mutually exclusive.
Transfer options, on the other hand, are not stored, are only
inherited down supertype chains, and are always mutually exclusive
(this applies to the implicit "native" transfer option as well).
Other types of options may be defined in the future; any such options
would have to describe both interactions among options of that type,
and interactions with options of other existing types.

There was discussion of the mutual exclusion requirement.  The
proposed behavior is that the response to a request with two transfer
encodings is undefined.  If it is useful to support multiple transfer
encodings this behavior could be defined in an extension.

The inheritance model was discussed (see Jim's presentation for
diagrams).  Four interpretations are possible; it is likely that
different implementations choose different ones.  Question: is this
the same as X.500?  Kurt:  in general yes, but LDAP is different in
supporting not just subtyping of attribute types, but of attribute
descriptions.  RFC 2251 also mentions option ordering but isn't
clear.  The revised document will make clear that no semantics are
implied by ordering.

Other issues remain, see Appendix C.  Jim will issue new drafts
dealing with a dozen or so issues every few weeks, so there will be
two or three more drafts before last call.

Roger Harrison spoke about the authmeth document.  It is now at -02,
with changes noted in Appendix F.  Terms have been aligned with RFC
2828.  State transition tables have been added, but definitely need
more scrutiny.  Question: what about when the SASL authorization-id is
the emprty string?  Kurt: this has been clarified in the SASL group:
an empty authorization-id and an absent field are treated identically.
Question: is Digest-MD5 really mandatory to implement?  Answer: if
authentication is implemented at all, Digest-MD5 must be implemented.
Question: should this document attempt to order authn methods by
"strength", and/or document known vulnerabilities?  Answer: no to
both.  There was discussion of the server hostname check in TLS:
should this become a SHOULD?  No, it must stay MUST, but language can
be clarified about permitting the client to have local policy that
will affect its behavior upon a failure to match.  Question: use of a
DN in the bindname field in a SASL bind?  Answer:  the server MUST
ignore this field, the client SHOULD NOT send it.

Roger will produce another draft in January.  The document should be
ready for last call by March.

Kathy Dally spoke about the user-schema and syntax documents, both of
which are now at -01.  Syntax items were discussed first.  References
to ";binary" have been removed.  There is an issue on inclusion of
schema elements in subschema attributes (?).  RFC 2252 apparently
changed the DIT Structure Rule list separator character from '$' (as
used in X.500) to ' '.  At least one implementation (from Adacel,
according to Steven Legg) makes use of this.  There are a few other
minor issues, and one substantial issues, that of binary syntax, see
discussion below.

Regarding the schema document, should all certificate-related
attributes and syntaxes be removed?  Answer:  yes, these will be dealt
with in PKIX WG documents.  Question:  what about
userSmimeCertificate?  Answer:  this can be dealt with by PKIX or by
the SMIME WG if needed.

Kathy said that the syntax document should be ready for last call by
March.  The user-schema document should be ready for last call
shortly.

Steven Legg spoke about issues with the binary syntax.  Note that this
is different from the ";binary" transfer option.  There have been two
interpretations of the ASN.1 data type for values with this syntax:
(1) the corresponding type is an OCTET string and the octets are any
valid BER of any type; (2) the ANY ASN.1 type.  For the "native"
transfer encoding, these are indistinguishable.  But with the
";binary" transfer encoding, with (1) the string is encapsulated in
BER, while with (2) the result is the same as if ";binary" had not
been chosen.  Mark Wahl commented that his interpretation of RFC 2252
is that the BER-encoding interpretation is invalid, and that RFC 2798
implies this too; and that a standards-track document
(draft-skibbie-krb-kdc-ldap-schema-01.txt) is being written based on
this.  Further discussion revealed that implementations are known to
exist with each interpretation.  After discussion, the consensus
position was that this syntax be removed from the normative portion of
the syntax document, and a note be added mentioning the now-deprecated
syntax and its problems.  A new syntax to meet the requirement for
"binary storage" should be defined (but not in ldapbis documents).

Kurt spoke about implementation reports, saying that work would begin
in earnest shortly.

Regarding charter milestones:  IANA considerations should go to IESG
in January 2002.  An implementation report Internet-Draft will be
submitted by April 2002.  The working group should conclude its work
by June 2002.  The WG will meet in Minneapolis in March but may not
meet in Yokohama in July.

Kurt also noted that his individual draft moving LDAP version 2 to
Historic status should go to the IESG shortly.

The meeting was adjourned at 11:30 AM.