[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: please publish ldap password policy draft
I see your point now. To paraphrase, you would like to see the word userPassword removed from the document and replaced by newly defined password storage attribute. Alternately, I suppose the document could just refer to "the attribute holding the user's password", and leave it an implementation detail. That leaves an interoperability hole though.
There's a draft in the works that defines a 'crypt' attribute subtype which can be used with the userPassword attribute. I'd like to just defer to the outcome of that for the definition of stored hashed passwords.
Jim
>>> "Kurt D. Zeilenga" <kurt@openldap.org> 10/21/99 10:54PM >>>
At 06:16 PM 10/21/99 -0600, Jim Sermersheim wrote:
>>a) compare must use octetStringMatch
>This draft avoids talking about how the actual comparison takes place.
Well, I argue that you actual comparison (and other simple
operations) acting upon userPassword are already well defined
by existing specifications.
>>b) servers cannot encrypt (or hash) the password and store
>> it in userPassword.
>I don't want to use this document to re-hash (he he) the whole 'syntax of userPassword' discussion we've had twice now.
That wasn't my point. userPassword is what it is. Two standard
track documents should not be in direct conflict. The conflict
should be resolved before the I-D is progressed.
I believe it would be wise to not meantion userPassword in your
draft. I suggest adding an attribute type to the policy which
describes the attribute type that stores the hashed password
value. Then, if implementors and/or admins choose to abuse
userPassword, they do so... but at their own risk.
- Kurt
----
Kurt D. Zeilenga <Kurt@OpenLDAP.org>
OpenLDAP Project <http://www.OpenLDAP.org/>