authmeth: SASL authorization/authentication ID syntax

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

[Authmeth] says:

> 10.4. SASL Authorization Identity Syntax

>    The format of
>    userid is defined as only a sequence of UTF-8 [RFC3629] encoded
>    [Unicode] characters, and any further interpretation is a local
>    matter.  To compare  uAuthzID values, each uAuthzID value MUST be
>    prepared using [SASLPrep] and then the two values are compared
>    octet-wise.

This is inconsistent.  If userid can be 'interpreted', then that
interpretation can e.g. convert it to lowercase before it is compared,
so it isn't necessarily SASLPrepped and compared octet-wise.
Or is something else meant by 'further interpretation'?
Note that neither of the examples that follow are compared octet-wise if
they are implemented with their usual LDAP attributes, 'uid' and 'mail':

>    For example, the userid could identify a user of a specific
>    directory service, be a login name, or be an email address.

Also, 'compared octet-wise' with what?  I can think of two meanings:

- during bind, compare with the list of authorization IDs which
  the authentication ID may authorize,

- during non-bind, compare with the authorization IDs listed in the
  access controls which apply to that operation.

I notice that the wording has changed since I wrote this previously, but
I don't know if that is in response to my comment, and if so I don't see
how it addresses it.

========

> 11. SASL DIGEST-MD5 Mechanism

>    Username
>    and realm values that look like LDAP DNs in form, e.g. <cn=bob,
>    dc=example,dc=com>, are syntactically allowed, however DIGEST-MD5
>    treats them as simple strings for comparison purposes.

If the user name is a DN in the directory, is it OK to compare them with
distinguishedNameMatch?  The exact DN has already been _almost_ ensured
by using it for the DIGEST-MD5 hashes, though I suppose one could
construct a case where this was not so.

-- 
Hallvard