Hello Mr Chu,
Thanks for the pointer. Now we understand why the RDNs like cn=#80 are not
supported in the current version of openldap.
However, we have a very particular use case, specific to the telecom network
usage of LDAP (something similar to TerraCortex presentation in Paris at
LDAPCon2013) that we must support: this is the case when the attribute type of
the RDN has the syntax Octet String. For that use case, we can't see any other
method than #<hexstring> to enable us to put the content of the Octet String
attribute required by the application in the RDN, keeping DN size, and
performance intact.
In that specific case, far more restrictive than the general LDAP RFC use case,
the attribute used in RDN has a, per application, mandatory syntax of Octet
String, and the BER encoding is restricted to Universal Class Tag "OctetString".
For all to understand, one example of RDN that must be supported is
x.y.v.z=#0403466f6f
i.e. x.y.v.z is the OID of an Octet String attribute and 0403466f6f is the BER
with the Octet String tag (04) (the case 2.5.4.3=#040180 ( cn=#80) will still
be kept not supported).
If we enable, under specific config flag control, the ability to decode RDN
similar to example given just above, in a modified openLDAP, we should not fall
in the pitfall described in the openLDAP ITS 6570
(https://www.openldap.org/its/index.cgi/Software%20Bugs?id=6570).
For the specific syntax OctetString, there is no normalization, nor
verification. Thus the risk to inject a bad DN values in this way is very, very
limited, as any value, including empty content, #80, arbitrary content.. are
already allowed.
Moreover, it may be possible to allow also the other syntax, far more user
friendly
myoctstringattr=#466f6f ( no BER, just direct hexa, and short name, not
OID)
Once again, the functionality is allowed ONLY for the syntax Octet String, i.e.
cn=#80 STILL not allowed.
This change could make openldap more LDAP v3 compliant.
Does someone have any idea of a theoretical side effect of enabling such
functionality ?
Regards,
Lech POFELSKI
-----Original Message-----
From: Howard Chu [mailto:[email protected]]
Sent: Sunday, April 26, 2015 7:26 AM
To: Pofelski, Lech; [email protected]
Subject: Re: About RDN values starting with #
Pofelski, Lech wrote:
> Hello openLDAP gurus,
>
> According to the RFC 4514, an RDN value may start with # and to be
> followed by a number of "hex pair" (pairs of hexadecimal values),
> representing octets of some binary value.
>
> There are two use cases involving such RDN syntax:
>
> *Case 1, where the RDN is of the form:
>
> <attribute OID (called also as attribute desc in dotted form)>=#<BER
> encoded attribute value in form of a sequence of hex pairs >
>
> *Case 2, where the RDN is of the form:
>
> <attribute name>=#<attribute value in form of a sequence of hex pairs>
>
> Case 1 is explicitly illustrated in the RFC 4514 by the example:
>
> 1.3.6.1.4.1.1466.0=#04024869
>
> Although Case 2 is not explicitly illustrated in the RFC4514, it is
> implicitly correct, as it is in the conformity with the RDN syntax
> provided by this RFC.
It is explicitly rejected by OpenLDAP.
https://www.openldap.org/its/index.cgi/Software%20Bugs?id=6570
> *If this is a known limitation in openLDAP.
>
> *If there is already a plan to fix the problem. If not, I'd be glad to
> contribute to fixing it.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
