[Date Prev][Date Next] [Chronological] [Thread] [Top]

draft-wahl-ldap-digest-example-00.txt



Mark, please forward to Andy as appropriate.  His address was not
listed in the I-D.

Thanks for documenting your approach.  The OpenLDAP approach
(under development) is quite similar.  We don't have a prefix
("dn:") on the username, instead we use the realm to imply
the form of the identity.  We plan to support both authPassword
and external storage, but have not adequately resolved the
DN normalization issue adequately yet.

How do you handle:
	alternative names such as cn vs commonName?
	attribute OIDs instead of names?
	multivalued RDN issues ( cn=foo+uid=bar vs uid=bar+cn=foo)?
	quoting issues? ( cn=foo\,bar vs cn="foo,bar" )
	escaping issues? ( cn=foo\,bar vs cn=foo\2Cbar )
	#base64 encoded values?
	UTF-8 lowercase vs uppercase odditities?

I also note that you store
	hd-value = { "{HD}", base64(hash-a1) }

which doesn't include the username nor realm (in plain text).
You derive realm from the FQDN of the server, how do you
handle use of the values in face of replication?  Do you
use the FQDN of the master?

We resolve this by issue by storing the username, realm,
and hash-a1 together.  We need to do this regardless as we
use the same storage for non-LDAPDN usernames.