Re: [ldapext] draft-stroeder-hashed-userpassword-values-01

[Michael Ströder <[e-mail]>]

Howard Chu wrote:
> Michael Ströder wrote:
>> Another use-cases is dealing with data migration to server product of another
>> vendor.
> 
> In which case the Admin must look up the documentation of the other vendor's
> product.

Yes. But it's so much easier to ask a vendor whether the userPassword syntax
adheres to some of the variants described in this document. Actually according
to your statement above it's a pretty good example why such a document is needed.

>>> Finally, an objectclass that defines "MUST userPassword" also has to be
>>> considered broken. (Reminds me of groupOfNames / MUST member.)
>>
>> That's simply your personal opinion not a strong objecting argument.
> 
> You're obviously missing the bigger picture then.

I don't. But this document is not about schema design anyway.

> I shouldn't need to remind
> you of all the trouble that "MUST member" has caused.

Ok, let's go for this example...

I remember Kurt pointing out one use-case for "MUST member" during discussion
about draft-findlay-ldap-groupofentries:
You can check whether 'member' is empty or whether access was prohibited by ACLs.

Not that I'm *personally* in favour of such a use-case (up to now). But
another deployer could have good reasons to want that and it was good to read
Kurt's hint about something I personally did not think about before. Or maybe
even I personally might have such a use-case in the future.

So stating that "MUST userPassword" is broken in any case for every deployment
is pretty presumptuous.

> In this case, deleting a userPassword is a straightforward way of disabling
> authentication for an account.

It's one possibility to do it.
It's not the variant I prefer though.

And also normal user accounts for humans are not the only user accounts to
consider.

> If your schema prevents this mechanism your schema is broken. That's
> not an opinion, that's fact.

I strongly disagree for various reasons we should discuss in another thread if
you really want.

>> Yes. But this would just be another scheme to be defined somewhere else.
>> This draft does not claim to cover everything you could ever stuff into
>> 'userPassword'.
> 
> But defining a formal syntax as you're doing *does* exactly that. Which is why
> I'm telling you you're making a mistake.

This draft does not claim that the formal syntax specified therein is the only
possible syntax for 'userPassword' ever used.

If you suggest wording to make that more clear I'd of course consider it to be
added.

Ciao, Michael.