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

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

I created an issue to improve the documentation/naming of this option.

https://jira.primekey.se/browse/ECA-3856

Cheers,
Tomas

On 2014-10-15 15:52, Tomas Gustavsson wrote:
>
> 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
>>
>
> ------------------------------------------------------------------------------
> 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
>