DN normalisation design document

[Ivanov Andrey (M.)]

Hi Noriko,

i've read the design document
http://directory.fedoraproject.org/wiki/Upgrade_to_New_DN_Format

In order to support "Old DN format including DN in the double quotes"
another cn=config switch may be necessary. It seems there was recently a new
switch introduced to make the dn syntax validation a little more "relaxed" -
nsslapd-dn-validate-strict. Maybe this one could be used to allow for DNs
with double-quoted values?

Here is the commit comment for that parameter :

commit 0410819d48795fca4faf986cf8658c34c4d929e3
Author: Nathan Kinder <nkinder(a)redhat.com&gt;
Date:   Wed May 13 11:12:11 2009 -0700

    Add strict DN syntax enforcement option.

    The DN syntax has become more restrictive over time, and the
    current rules are quite strict. Strict adherence to the rules
    defined in RFC 4514, section 3, would likely cause some pain to
    client applications. Things such as spaces between the RDN
    components are not allowed, yet many people use them still since
    they were allowed in the previous specification outlined in RFC
    1779.

    To deal with the special circumstances around validation of the DN
    syntax, a configuration attribute is provided named
    nsslapd-dn-validate-strict. This configuration attribute will
    ensure that the value strictly adheres to the rules defined in RFC
    4514, section 3 if it is set to on. If it is set to off, the server
    will normalize the value before checking it for syntax violations.
    Our current normalization function was designed to handle DN values
    adhering to RFC 1779 or RFC 2253

Concerning the logic of escaping/unescaping/normalisation we could test how
openldap behaves in each case (as you've made it in "DN HEX HEX" bug).

For upgrades/migrations and double quotes in DNs: the two values may be left
during the upgrade (just in case someone uses them as-is) and then an
optional validation/cleaning script could be provided separately? The
sensitive part here is the whole o-NetscapeRoot tree: console using and
writing this type of values, replication agreement/management etc

As for the "related bugs" section i think another bug should be added  (
https://bugzilla.redhat.com/show_bug.cgi?id=199923), it concernes the same
RFC4514 compliance.

[Noriko Hosoi]

Thanks for your comments, Andrey!

On 03/17/2010 08:02 AM, Andrey Ivanov wrote:
>  Hi Noriko,
>
>  i've read the design document 
>  http://directory.fedoraproject.org/wiki/Upgrade_to_New_DN_Format
>
>  In order to support "Old DN format including DN in the double quotes" 
>  another cn=config switch may be necessary. It seems there was recently 
>  a new switch introduced to make the dn syntax validation a little more 
>  "relaxed" - nsslapd-dn-validate-strict. Maybe this one could be used 
>  to allow for DNs with double-quoted values? 
Actually, the way how we are going to
handle the old style 'dn: 
<type>="<nested dn>",<the rest>' is converting the old
style to a new 
style in the normalization when the server receives DNs from clients and 
the converted new style DN is used in the rest of the process.  The 
nsslapd-dn-validate-strict value is examined in the DN syntax validation 
code for now.  Unless we change it, the DN syntax validation code always 
receives the new DN style.

That being said, are you suggesting if nsslapd-dn-validate-strict is on, 
we should not convert an old style DN to a new style?  That'd be really 
strict.  I'm leaning toward to the other side accepting the both old and 
new style with no restriction.  Do you see any disadvantages in allowing 
the old style?
>  Here is the commit comment for that parameter :
>
>  commit 0410819d48795fca4faf986cf8658c34c4d929e3
>  Author: Nathan Kinder <nkinder(a)redhat.com <mailto:[e-mail]>>
>  Date:   Wed May 13 11:12:11 2009 -0700
>
>      Add strict DN syntax enforcement option.
>
>      The DN syntax has become more restrictive over time, and the
>      current rules are quite strict. Strict adherence to the rules
>      defined in RFC 4514, section 3, would likely cause some pain to
>      client applications. Things such as spaces between the RDN
>      components are not allowed, yet many people use them still since
>      they were allowed in the previous specification outlined in RFC
>      1779.
>
>      To deal with the special circumstances around validation of the DN
>      syntax, a configuration attribute is provided named
>      nsslapd-dn-validate-strict. This configuration attribute will
>      ensure that the value strictly adheres to the rules defined in RFC
>      4514, section 3 if it is set to on. If it is set to off, the server
>      will normalize the value before checking it for syntax violations.
>      Our current normalization function was designed to handle DN values
>      adhering to RFC 1779 or RFC 2253
>
>  Concerning the logic of escaping/unescaping/normalisation we could 
>  test how openldap behaves in each case (as you've made it in "DN HEX 
>  HEX" bug). 
Yes, I did. :)  I found they are correctly handling the cases
including 
escaped characters and non-ASCII UTF-8 characters in the seamless manner.
>  For upgrades/migrations and double quotes in DNs: the two values may 
>  be left during the upgrade (just in case someone uses them as-is) and 
>  then an optional validation/cleaning script could be provided separately?  
All
right.  That should work.  I'm adding the validation/cleaning script 
to the design memo.
>  The sensitive part here is the whole o-NetscapeRoot tree: console 
>  using and writing this type of values, replication 
>  agreement/management etc 
Indeed.
>  As for the "related bugs" section i think another bug should be added  
>  (https://bugzilla.redhat.com/show_bug.cgi?id=199923), it concernes the 
>  same RFC4514 compliance. 
Oops.  That's right.  I'm adding it, too.

Thanks so much for your comments.
--noriko

[Ivanov Andrey (M.)]

>  In order to support "Old DN format including DN in the double quotes"
>  another cn=config switch may be necessary. It seems there was recently a new
>  switch introduced to make the dn syntax validation a little more "relaxed" -
>  nsslapd-dn-validate-strict. Maybe this one could be used to allow for DNs
>  with double-quoted values?
>
>  Actually, the way how we are going to handle the old style 'dn:
>  <type>="<nested dn>",<the rest>' is converting the old
> style to a new style
>  in the normalization when the server receives DNs from clients and the
>  converted new style DN is used in the rest of the process.  The
>  nsslapd-dn-validate-strict value is examined in the DN syntax validation
>  code for now.  Unless we change it, the DN syntax validation code always
>  receives the new DN style.
>
>  Ok. What i wanted to say is that we should avoid any new config parameters 
in
cn=config. The way you propose to handle the problem is the best one - it
is completely transparent to the user, the server back-end "sees" only the
normalised DNs so it does not complain and no additional configuration
parameters are necessary.

That being said, are you suggesting if nsslapd-dn-validate-strict is on, we
>  should not convert an old style DN to a new style?  That'd be
> really
>  strict.  I'm leaning toward to the other side accepting the both old and new
>  style with no restriction.  Do you see any disadvantages in allowing the old
>  style?
>  
No, absolutely not, i agree completely with your reasoning. The code should
be strict but not completely rigid :) Taking care of the "legacy"
presentation in a transparent manner is the ideal solution.

[Noriko Hosoi]

On 03/17/2010 01:13 PM, Andrey Ivanov wrote:
> >     In order to support "Old DN format including DN in the double
> >     quotes" another cn=config switch may be necessary. It seems there
> >     was recently a new switch introduced to make the dn syntax
> >     validation a little more "relaxed" - nsslapd-dn-validate-strict.
> >     Maybe this one could be used to allow for DNs with double-quoted
> >     values?
>      Actually, the way how we are going to handle the old style 'dn:
>      <type>="<nested dn>",<the rest>' is converting the
> old style to a
>      new style in the normalization when the server receives DNs from
>      clients and the converted new style DN is used in the rest of the
>      process.  The nsslapd-dn-validate-strict value is examined in the
>      DN syntax validation code for now.  Unless we change it, the DN
>      syntax validation code always receives the new DN style.
>
>  Ok. What i wanted to say is that we should avoid any new config 
>  parameters in cn=config. The way you propose to handle the problem is 
>  the best one - it is completely transparent to the user, the server 
>  back-end "sees" only the normalised DNs so it does not complain and no 
>  additional configuration
>  parameters are necessary.
>
>      That being said, are you suggesting if nsslapd-dn-validate-strict
>      is on, we should not convert an old style DN to a new style? 
>      That'd be really strict.  I'm leaning toward to the other side
>      accepting the both old and new style with no restriction.  Do you
>      see any disadvantages in allowing the old style?
>
>  No, absolutely not, i agree completely with your reasoning. The code 
>  should be strict but not completely rigid :) Taking care of the 
>  "legacy" presentation in a transparent manner is the ideal solution.
>
>  
Thanks so much for the confirmation, Andrey.  I'm working on the issue 
based on the design...
--noriko