[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Fw: Reserved characters for a LDAP URI



At 11:57 PM 12/21/2002, you wrote:
>For example, for the following DN:
>  cuntry name: TW
>  organization name: Chunghwa Telecom Co., Ltd.
>  organizational unit name: PKI IWG

First, one needs to construct an LDAP DN string representation
of the DN to encode into the URL.  With minimal escaping, the DN
could be represented as:
       ou=PKI IWG,o=Chunghwa Telecom Co.\2C Ltd.,c=TW
or,
       ou=PKI IWG,o=Chunghwa Telecom Co.\2c Ltd.,c=TW

or, optionally,
        ou=PKI IWG,o=Chunghwa Telecom Co.\, Ltd.,c=TW

Of course, implementations are free to escape other characters
as they see fit.  RFC 2253 does not provide a canonical string
representation of a DN (nor is the string reversible to DER).

Second, the DN strings can be encoded into URLs as follows:
       ldap:///ou=PKI%20IWG,o=Chunghwa%20Telecom Co.%5C2C%20Ltd.,c=TW
       ldap:///ou=PKI%20IWG,o=Chunghwa%20Telecom Co.%5C2c%20Ltd.,c=TW
        ldap:///ou=PKI%20IWG,o=Chunghwa%20Telecom Co.%5C,%20Ltd.,c=TW

respectively.

>ou=PKI%20IWG,o=Chunghwa%20Telecom%20Co.%5C,%20Ltd.,c=TW
>
>However, Japan side insists that it should be:
>
>ou=PKI%20IWG,o=Chunghwa%20Telecom%20Co.%5C%2C%20Ltd.,c=TW
>
>(The difference is between "%5C,%20" and "%5C%2C%%20".)

It is not necessary (but allowed) to escape commas when encoding
a DN string into the DN part of an LDAP URL.  That is, "," is
considered to be safe.

The logic that extra escaping in the latter case is necessary
is flawed as there is no ambiguity as to which DN string the first
decodes to.  I think proponents of the first confuse decoding
of the DN part with decoding of the DN string to obtain RDNs.
One cannot decode the RDN strings from the DN part directly.
One must first decode the DN string from the DN part before
the RDN strings can be extracted.

Mark, maybe an additional example should be added to RFC 2255bis
to clarify this?

Kurt