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: [EMAIL PROTECTED] >------------------------------------------
