Re: [Ejbca-develop] LDAP DN order is wrong

[Tomas G. <to...@pr...>]

On 2014-10-15 10:21, Michael Ströder wrote:
> 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
>               ^^^^^^^^^^^^^^^^

This option does not print the "actual" asn.1 order. -nameopt rfc2253 
converts the string into something specified, but not the actual order. 
You can see the actual order (which is printed when not using -nameopt) by:
openssl asn1parse

> (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.

It is not flawed because it affects the actual order of the DN in the 
generated asn.1 This is vital to be able to do this to be compatible 
with different implementation of how x.509 certificates are used.
The name could be be better describing though.

>
>> 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

I do not agree on this. String representations of DNs are a tru mess, 
one of the biggest misstakes. Using RFC definition will usually result 
in non-understandable OIDs for many of the DN components. And the 
printed representation still will differ between different 
implementation (i.e. openssl vs bouncy castle etc).
There simply is no good string representation.

>
> 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.

Thanks.

>
> 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.

This is the only way to be sure.

>
> Ciao, Michael.
>
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
>
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>