|
From: Michael S. <mi...@st...> - 2014-10-15 08:21:41
|
Tomas Gustavsson wrote:
>
> What do you mean it is wrong?
If you enable "LDAP DN order" the order is actually reversed. When displaying
the certs with OpenSSL subject and issuer are *not* LDAP DN order. Please
check yourself with
openssl x509 -nameopt rfc2253
^^^^^^^^^^^^^^^^
(If you don't use this -nameopt value you get some obscure OpenSSL internal
string representation which is definitely *not* LDAP DN order although in
recent versions separated by comma.)
I'd suggest to completely drop this flawed configuration option.
> Can you suggest some new help text?
1. There is no such thing as a X.500 DN string representation. The only
well-defined string representation for distinguished names is RFC 4514
(formerly RFC 2253) which defines what you call "LDAP DN order".
BTW: Obviously the ASN.1 string type gets lost with this representation.
=> IMO if generating strings of DNs this RFC 4514 representation should be
*always* used
2. And this help text is plain wrong:
"In theory the order of the DN should not matter, because comparisons between
DNs should be done on the RDN level."
It is confusing and in contradiction to
http://tools.ietf.org/html/rfc5280#section-7.1
[..] Two distinguished names DN1 and DN2 match if they
have the same number of RDNs, for each RDN in DN1 there is a matching
RDN in DN2, and the matching RDNs appear in the same order in both
DNs.
Note the words "same order" herein.
Also in some protocols DN matching is even done by strictly comparing the DER
encoding of the DNs to avoid having to deal with compability issues of the
different ASN.1 string types.
Ciao, Michael.
|