Re: proxyAuthz value encoding

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

I thought they changed the OID when control value was changed
from a BER-encoded LDAPDN to a LDAP-authzid.  The former was 2.16.840.1.113730.3.4.12 and the latter 2.16.840.1.113730.3.4.18.
The Netscape C API supports both, proxyauth v proxiedauth.  I
was suspect the Sun (whatever) DS also supports both.

Unforunately, it appears the Mozilla C API implementation of
each is broken.  For the former, it seems to send as the
value a BER-encoded SEQUENCE containing a DN.  In the case
of the latter, it sends a BER-encoded authzid.

As I have noted previously, I generally oppose adding be-liberal
workarounds to bugs in other implementations before these other implementations have been fixed as doing so reduces pressure on
them to fix their bug.   Once fixed, I am fine with reasonable
be-liberal workarounds (such as detecting the BER-encoding
of the authzid and dealing with it).  I am also generally
opposed to adding workarounds that cause our software not to
be standard compliant in what it produces.

Instead of adding a workaround to generate non-standard
encodings of proxiedauth control (2.16.840.1.113730.3.4.18),
it might be better to implement defacto encodings of
the non-standard proxyauth control (2.16.840.1.113730.3.4.12).

Would this address your specific interoperability issue?

Kurt

At 10:19 AM 1/9/2006, Pierangelo Masarati wrote:
>Apparently, there are DSA implementations out there (SunONE) that require
>the proxyAuthz control value to be BER encoded, as dictated in earlier
>versions of draft-weltman-ldapv3-proxy.  Most of the story is clearly
>described here
><http://www.codecomments.com/archive408-2005-4-460507.html>.
>
>A (sanitized) berdump of the same request with Sun's and OpenLDAP's tools
>follows; no need to mention that SunONE appears to only accept Sun's
>encoding.
>
>I have a precise customer's request that OpenLDAP's slapd be able to use
>the proxyAuthz control with some version of SunONE that is affected by
>this problem.  Would a configure option to back-ldap that allows to use
>that encoding in identity assertion be acceptable?  What about a similar
>switch for OpenLDAP tools?
>
>p.
>
># Sun
>...
>0080  72 31 03 04 01 46 a0 55  30 53 04 18 32 2e 31 36   r1...F?U 0S..2.16
>0090  2e 38 34 30 2e 31 2e 31  31 33 37 33 30 2e 33 2e   .840.1.1 13730.3.
>00a0  34 2e 31 38 01 01 ff 04  34 04 32 64 6e 3a 75 69   4.18..ÿ. 4.2dn:ui
>00b0  64 3d 78 78 78 78 78 78  78 78 78 78 78 78 78 78   d=xxxxxx xxxxxxxx
>00c0  78 78 78 78 78 78 78 78  78 78 78 78 78 78 78 78   xxxxxxxx xxxxxxxx
>00d0  78 78 78 78 78 78 78 78  78 78 78 78 78            xxxxxxxx xxxxx
>
># OpenLDAP
>...
>0080  72 31 03 04 01 46 a0 53  30 51 04 18 32 2e 31 36   r1...F?S 0Q..2.16
>0090  2e 38 34 30 2e 31 2e 31  31 33 37 33 30 2e 33 2e   .840.1.1 13730.3.
>00a0  34 2e 31 38 01 01 ff 04  32 64 6e 3a 75 69 64 3d   4.18..ÿ. 2dn:uid=
>00b0  78 78 78 78 78 78 78 78  78 78 78 78 78 78 78 78   xxxxxxxx xxxxxxxx
>00c0  78 78 78 78 78 78 78 78  78 78 78 78 78 78 78 78   xxxxxxxx xxxxxxxx
>00d0  78 78 78 78 78 78 78 78  78 78 78                  xxxxxxxx xxx
>
>
>
>
>Ing. Pierangelo Masarati
>Responsabile Open Solution
>OpenLDAP Core Team
>
>SysNet s.n.c.
>Via Dossi, 8 - 27100 Pavia - ITALIA
>http://www.sys-net.it
>------------------------------------------
>Office:   +39.02.23998309          
>Mobile:   +39.333.4963172
>Email:    pierangelo.masarati@sys-net.it
>------------------------------------------