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

[Michael S. <mi...@st...>]

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.

RFC 4514 (which obsoletes RFC 2253) clears says:

   "the output consists of the string encodings of each
   RelativeDistinguishedName in the RDNSequence (according to Section
   2.2), starting with the last element of the sequence and moving
   backwards toward the first."

http://tools.ietf.org/html/rfc4514#section-2.1

(Note also the following section about *unordered* multi-valued RDNs!)

This means the conversion is already well-defined for the RDNSequence and LDAP
string representations of DNs are always from left-to-right to be interpreted
as bottom-up in the Directory Information Tree (similar to concantenation of
DNS labels to FQDNs).

And: There is no difference in X.500 and LDAP "name order" because simply
X.500 strings are not defined at all.

> You can see the actual order (which is printed when not using -nameopt) by:
> openssl asn1parse

In PKIX the sequence Name is specified as RDNSequence here:

http://tools.ietf.org/html/rfc5280#section-4.1.2.4

So you're right that the RDNSequence in a X.509 certificate is to be
interpreted from first-to-last as top-down in the Directory Information Tree
(I'm too lazy to dig out a reference for the usual X.521 naming with C to CN
etc.).
But RFC 4514 clearly defines how to convert this into the correct DN string
representation. Note that I'm deliberately using "first-to-last" for the
RDNSequence items instead of left-to-right here.

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

The configuration option is seriously flawed just because of its existence.
Can you clearly define a real use-case?
Which real-world problem is solved by this without introducing another issue?

IMHO this option is strongly contributing to all the misunderstandings about
DN order and DN string representations.

My strong recommendation:
If you're dealing with string representation in a user interface or
configuration file etc. then consistently treat every DN or DN regex pattern
etc. according to RFC 4514.
(Bear in mind you loose UTF8String vs. PrintableString information though.)

Believe me: I'm really using a lot of complicated cert-subject-DN to LDAP-DN
identity mappings in real-world productive configs. Consistently using RFC4514
makes things clear, everything else leads to big mess.

Of course you have to correctly use the BouncyCastle or OpenSSL API to convert
the string representation to the correct ordering in the X.509 cert when
generating certs and vice versa.

Ciao, Michael.