Subject: RE: IETF ldapbis WG Last Call: draft-ietf-ldapbis-user-schema-05.txt

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 27 May 2003 14:19:30 +1000

I agree with the resolutions, except for passwords. For passwords, I agree that there was WG consensus. My own opinion, however, is that these are octet strings and that a password matches only if the sequence of octets is the same.

I think I have only seen about five names in messages to the list - is this enough to declare consensus?

Ron

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Tuesday, 27 May 2003 04:41
To: [email-masked]
Subject: Re: IETF ldapbis WG Last Call:
draft-ietf-ldapbis-user-schema-05.txt

This message serves to summarize issues to be addressed
before this I-D is progressed.  For each issue, I have suggested
a course of action which I believe to be consistent with WG
consensus.  If you don't believe the this course of action
is appropriate, please comment within the next couple of days.
Otherwise, the chairs will declare these issues resolved and
direct the editor to revise the document accordingly.

KurtZ raised concerns regarding the ommission of an 'uid' attribute
type specification.  He made a proposal to add it.  No one opposed
this proposal, implement it.

MarkH raised concerns regarding suggested upper limits.
StevenL proposed that all suggested upper limits be removed
to avoid confusion.  No one opposed this proposal, implement it.

KurtZ raised concerns regarding internationalization of textual
user passwords.  Kurt proposed that it be recommended that applications
prepare textural passwords by first transcoding them to Unicode,
apply SASLprep, and then encoding them as UTF-8.  Hallvard offered
some word smithing which was found acceptable.  No one opposed this
proposal, implement it.

NorbertK raised concerns regarding alternative names used for
in some implementations which do not appear in the attribute
type's formal description and suggested they be added.  Objections
to the proposal were raised.  The proposal is rejected.

KurtZ provided a laundry list of issues.  For brevity, I will
only summarize technical issues.  There were no opposing comments
to any of his proposals.

KurtZ noted that most attribute types are discussed in single
value terms though are declared as multiple values.  Kurt
proposed that the editor reword each description to reflect
their multi-valued-ness.  Clarify.

KurtZ noted that the description of 'dc' is needs further
clarification.  Clarify as noted.

KurtZ noted 'destinationIndicator' specification does not
include a statement of how the attribute type is used.  Clarify.

KurtZ noted the description of 'givenName' is inconsistent
with that provided in X.520.  Clarify.

KurtZ proposed that the 'domain' object class should not have
been added to the specification.  Remove.

KurtZ raised a security consideration regarding session hijacking.
Add consideration.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 26 May 2003 23:55:11 -0700

At 09:19 PM 5/26/2003, Ramsay, Ron wrote:
>I agree with the resolutions, except for passwords. For passwords, I agree that there was WG consensus.

Noted.

>My own opinion, however, is that these are octet strings and that a password matches only if the sequence of octets is the same.

I note that the requirement is applied by applications on input
to the directory.  To the directory service, they are still
octets strings matched octet-wise.

>I think I have only seen about five names in messages to the list - is this enough to declare consensus?

All the input was enough to gain a good sense of WG consensus
and to suggest courses of action for the WG to consider.
We'll have to wait a few days to see whether we really
have consensus or not.

Kurt

---

From: Michael Ströder <[email-masked]>
Date: Tue, 27 May 2003 08:53:47 +0200

Ramsay, Ron wrote:
> I agree with the resolutions, except for passwords. For passwords, I
> agree that there was WG consensus. My own opinion, however, is that these
> are octet strings and that a password matches only if the sequence of
> octets is the same.

There was consensus that octet string matching of passwords will not be 
changed to ensure compability with implementations using some kind of local 
definition. But to solve current interoperability issues it is very 
important to recommend a character set/encoding (here UTF-8) for *textual* 
passwords sent by the LDAP client.

There was a thread on this list quite a while ago with subject
"Revisited: NON-ASCII chars in userPassword" started 2001-10-29.

Ciao, Michael.