6:24 a.m.
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.
The example of Case2 equivalent to the example of Case1 given in the RFC would be:
<name of the attribute with OID 1.3.6.1.4.1.1466.0>=#4869
I have tested using openLDAP 2.4.39 a number of cases involving RDNs starting with #,
including an example very close to the example from the RFC.
The results show that:
· If RDN value is provided as e.g. string value, LDAP operations like add, search
and delete work well
· If RDN value is provided as # prefixed hexadecimal value corresponding to the
cases 1 and 2, none of this cases work and in all the cases I get the error "Invalid
DN syntax"
The schema file, scripts used to run the test and the test results are in the attached zip
file.
I would like to know:
· If you share our understanding of the problem and in particular our
interpretation of the Case2, for which there is no explicit example in the RFC4514.
· 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.
Thanks in advance for your answer.
Regards,
Lech POFELSKI
Lech POFELSKI,
Software Development Engineer
Hewlett-Packard Centre de Compétences France
5 Avenue Raymond Chanas
38320 Eybens - France
lech.pofelski@hp.com<mailto:lech.pofelski@hp.com>
10:25 p.m.
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, Id 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/
3:09 a.m.
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:hyc@symas.com]
Sent: Sunday, April 26, 2015 7:26 AM
To: Pofelski, Lech; openldap-technical(a)openldap.org
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/
4:39 a.m.
Pofelski, Lech wrote:
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.
Not quite. The # prefix means the following hex string must be a valid
BER encoding of whatever value. Thus, while the octetString value may be
arbitrary, including zero length, it must still have a valid BER tag and
length.
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 ?
You're welcome to submit a patch enabling hex format for attributes of
octetString syntax, but it cannot simply pass thru any hex string. The
decoded hex string must still conform to BER.
Internally, we would expect the normalized form to be stored in binary,
not hex. (UUIDs are also treated this way already.) But the text/hex
form would be given back to clients.
Have to say, using octetString syntax for naming attributes is rather
user-unfriendly. You should reconsider your app design.
Regards,
Lech POFELSKI
-----Original Message-----
From: Howard Chu [mailto:hyc@symas.com]
Sent: Sunday, April 26, 2015 7:26 AM
To: Pofelski, Lech; openldap-technical(a)openldap.org
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/
6:07 a.m.
Hello Mr Chu,
Thanks for proposing us to submit a patch. We are starting to work on it.
There is still one point to clarify about two possible forms of RDNs with values starting
with #.
The RFC4514 says:
"
If the AttributeType is of the dotted-decimal form, the
AttributeValue is represented by an number sign ('#' U+0023)
character followed by the hexadecimal encoding of each of the octets
of the BER encoding of the X.500 AttributeValue
"
This statement explains clearly, without any ambiguity the case when the RDN is of form:
<attribute type OID>=#<BER encoded value in form of hexstring>
However, the RDN syntax definition presented in the same RFC allows also the form:
<attribute type NAME>=#<hexstring>
i.e. where the AttributeType is NOT and OID. This form has the <hexstring> value
which does not seem to be explicitly restricted by any constraint, i.e. it is not
necessarily a BER.
In brief, there may be two interpretations of this part of the RFC:
* A permissive one:
o In the form <attribute type NAME>=#<hexstring> any <hexstring> is
allowed (implicitly, by syntax and not constrained)
o In the form <attribute type OID>=#<hexstring> only BER <hexstring>
is allowed (explicitly, including examples)
* A restrictive one:
o in both cases (attribute type NAME / OID)=#<hexstring> - only BER
<hexstring> is allowed
Note that in any case we consider only the attribute types having the syntax of Octet
String, so as we discussed earlier we don't expect any pitfall issue described in
(https://www.openldap.org/its/index.cgi/Software%20Bugs?id=6570).
Between the two interpretations presented above our preferred choice is the permissive
one, i.e. <attribute type NAME>=#<hex string>, with no constraint on the
<hex string> value. Note that the restrictive interpretation seems to be more
restrictive than the RFC itself.
Which interpretation would you recommend for our fix?
Thanks in advance,
Regards,
Lech POFELSKI
-----Original Message-----
From: Howard Chu [mailto:hyc@symas.com]
Sent: Tuesday, April 28, 2015 1:40 PM
To: Pofelski, Lech; openldap-technical(a)openldap.org
Subject: Re: About RDN values starting with #
Pofelski, Lech wrote:
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.
Not quite. The # prefix means the following hex string must be a valid BER encoding of
whatever value. Thus, while the octetString value may be arbitrary, including zero length,
it must still have a valid BER tag and length.
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 ?
You're welcome to submit a patch enabling hex format for attributes of octetString
syntax, but it cannot simply pass thru any hex string. The decoded hex string must still
conform to BER.
Internally, we would expect the normalized form to be stored in binary, not hex. (UUIDs
are also treated this way already.) But the text/hex form would be given back to clients.
Have to say, using octetString syntax for naming attributes is rather user-unfriendly. You
should reconsider your app design.
Regards,
Lech POFELSKI
-----Original Message-----
From: Howard Chu [mailto:hyc@symas.com]
Sent: Sunday, April 26, 2015 7:26 AM
To: Pofelski, Lech; openldap-technical(a)openldap.org
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/
6:28 a.m.
Pofelski, Lech wrote:
Hello Mr Chu,
Thanks for proposing us to submit a patch. We are starting to work on it.
There is still one point to clarify about two possible forms of RDNs with values starting
with #.
The RFC4514 says:
"
If the AttributeType is of the dotted-decimal form, the
AttributeValue is represented by an number sign ('#' U+0023)
character followed by the hexadecimal encoding of each of the octets
of the BER encoding of the X.500 AttributeValue
"
This statement explains clearly, without any ambiguity the case when the RDN is of form:
<attribute type OID>=#<BER encoded value in form of hexstring>
However, the RDN syntax definition presented in the same RFC allows also the form:
<attribute type NAME>=#<hexstring>
i.e. where the AttributeType is NOT and OID. This form has the <hexstring> value
which does not seem to be explicitly restricted by any constraint, i.e. it is not
necessarily a BER.
In brief, there may be two interpretations of this part of the RFC:
* A permissive one:
o In the form <attribute type NAME>=#<hexstring> any <hexstring> is
allowed (implicitly, by syntax and not constrained)
o In the form <attribute type OID>=#<hexstring> only BER <hexstring>
is allowed (explicitly, including examples)
* A restrictive one:
o in both cases (attribute type NAME / OID)=#<hexstring> - only BER
<hexstring> is allowed
Note that in any case we consider only the attribute types having the syntax of Octet
String, so as we discussed earlier we don't expect any pitfall issue described in
(https://www.openldap.org/its/index.cgi/Software%20Bugs?id=6570).
Between the two interpretations presented above our preferred choice is the permissive
one, i.e. <attribute type NAME>=#<hex string>, with no constraint on the
<hex string> value. Note that the restrictive interpretation seems to be more
restrictive than the RFC itself.
Which interpretation would you recommend for our fix?
The text is quite clear - the hexstring is of the BER encoding of the
value. There is no ambiguity here.
"This form is also used when the AttributeValue does not have an
LDAP-specific string encoding for it, or the LDAP-specific string
encoding is not restricted to UTF-8 encoded Unicode characters."
"This form" refers to "the
AttributeValue is represented by an number sign ('#' U+0023)
character followed by the hexadecimal encoding of each of the octets
of the BER encoding of the X.500 AttributeValue."
It does not allow the possibility of any other "form."
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:51 a.m.
Hello Mr Chu,
[ I am resending this e-mail, because I forgot to use "ReplyToAll" in my first
sending, so the e-mail was not sent to openldap-technical)]
Thanks for explanation.
I have just the last question.
As RFC4514 says:
"
If the AttributeType is of the dotted-decimal form, the AttributeValue is represented by
an number sign ('#' U+0023) character followed by the hexadecimal encoding of
each of the octets of the BER encoding of the X.500 AttributeValue "
"
It suggest that the legal form of RDN with BER encoding is:
<attribute type OID>=#<BER encoded value in form of hexstring>
However, according to the syntax the form:
<attribute type NAME>=#<BER encoded value in form of hexstring>
is also correct.
Should we also consider the form:
<attribute type NAME>=#<BER encoded value in form of hexstring>
as legal?
Sorry for asking for such a detail, but we want to avoid any misunderstanding in the patch
preparation.
Regards,
Lech POFELSKI
-----Original Message-----
From: Howard Chu [mailto:hyc@symas.com]
Sent: Thursday, April 30, 2015 3:28 PM
To: Pofelski, Lech; openldap-technical(a)openldap.org
Subject: Re: About RDN values starting with #
Pofelski, Lech wrote:
Hello Mr Chu,
Thanks for proposing us to submit a patch. We are starting to work on it.
There is still one point to clarify about two possible forms of RDNs with values starting
with #.
The RFC4514 says:
"
If the AttributeType is of the dotted-decimal form, the AttributeValue
is represented by an number sign ('#' U+0023) character followed by
the hexadecimal encoding of each of the octets of the BER encoding of
the X.500 AttributeValue "
This statement explains clearly, without any ambiguity the case when the RDN is of form:
<attribute type OID>=#<BER encoded value in form of hexstring>
However, the RDN syntax definition presented in the same RFC allows also the form:
<attribute type NAME>=#<hexstring>
i.e. where the AttributeType is NOT and OID. This form has the <hexstring> value
which does not seem to be explicitly restricted by any constraint, i.e. it is not
necessarily a BER.
In brief, there may be two interpretations of this part of the RFC:
* A permissive one:
o In the form <attribute type NAME>=#<hexstring> any <hexstring> is
allowed (implicitly, by syntax and not constrained)
o In the form <attribute type OID>=#<hexstring> only BER <hexstring>
is allowed (explicitly, including examples)
* A restrictive one:
o in both cases (attribute type NAME / OID)=#<hexstring> - only BER
<hexstring> is allowed
Note that in any case we consider only the attribute types having the syntax of Octet
String, so as we discussed earlier we don't expect any pitfall issue described in
(https://www.openldap.org/its/index.cgi/Software%20Bugs?id=6570).
Between the two interpretations presented above our preferred choice is the permissive
one, i.e. <attribute type NAME>=#<hex string>, with no constraint on the
<hex string> value. Note that the restrictive interpretation seems to be more
restrictive than the RFC itself.
Which interpretation would you recommend for our fix?
The text is quite clear - the hexstring is of the BER encoding of the value. There is no
ambiguity here.
"This form is also used when the AttributeValue does not have an LDAP-specific string
encoding for it, or the LDAP-specific string encoding is not restricted to UTF-8 encoded
Unicode characters."
"This form" refers to "the
AttributeValue is represented by an number sign ('#' U+0023)
character followed by the hexadecimal encoding of each of the octets
of the BER encoding of the X.500 AttributeValue."
It does not allow the possibility of any other "form."
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2875
days inactive
2887
days old
openldap-technical@openldap.org
6 comments
2 participants
participants (2)
-
Howard Chu -
Pofelski, Lech