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

[Jaime H. <hab...@gm...>]

I've read the entire previous thread and given that as of EJBCA r32191 the
option "LDAP DN order" stil exists and is still being set by default, I
will try to complement the previous arguments presented by Michael and
explain why this option shouldn't exist or at least should be renamed and
not marked by default!.

So first, let's review the standards about the order for the LDAP string
representation of a DN (and remember that this is for the order of the
string representation, not the ASN.1 structured representation). From RFC
4514, "2.1. Converting the RDNSequence":

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 movingbackwards*
> toward the first.


And if we take a look at the following example from RFC 5280, with excerpts
from "Appendix C. Examples" onwards:

In places in this appendix where a distinguished name is specified
> using a string representation, the
> *strings are formatted using therules specified in [RFC4514]*.
> ...
> C.2. End Entity Certificate Using RSA
> ...
> (d) the subject’s *distinguished name is cn=End Entity,dc=example,dc=com*;
> ...
> 132 67: SEQUENCE {
> 134 19: SET {
> 136 17: SEQUENCE {
> 138 10: OBJECT IDENTIFIER
> : *domainComponent *(0 9 2342 19200300 100 1 25)
> 150 3: IA5String *’com’*
> : }
> : }
> 155 23: SET {
> 157 21: SEQUENCE {
> 159 10: OBJECT IDENTIFIER
> : *domainComponent *(0 9 2342 19200300 100 1 25)
> 171 7: IA5String *’example’*
> : }
> : }
> 180 19: SET {
> 182 17: SEQUENCE {
> 184 3: OBJECT IDENTIFIER *commonName *(2 5 4 3)
> 189 10: PrintableString *’End Entity’*
> : }
> : }
> : }


We can see that <cn=End Entity,dc=example,dc=com> corresponds to an LDAP
string representation (according to RFC 4514) of the DN displayed in the
example ASN.1 dump, where the order of attributes is the inverse.

Now, the problem with current EJBCA is that with "LDAP DN Order" enabled
and for the previous example, it would produce ASN.1 in the inverse order,
i.e. EJBCA would generate the following ASN.1:

SEQUENCE {
>  SET {
>   SEQUENCE {
>
> *   OBJECT IDENTIFIER commonName (2 5 4 3)   PrintableString 'End Entity'*
>   }
>  }
>  SET {
>   SEQUENCE {
>
> *   OBJECT IDENTIFIER domainComponent (0 9 2342 19200300 100 1 25)
>  IA5String 'example'*
>   }
>  }
>  SET {
>   SEQUENCE {
>
> *   OBJECT IDENTIFIER: domainComponent (0 9 2342 19200300 100 1 25)
>  IA5String 'com'*
>   }
>  }
> }


So the current "LDAP DN Order" option in EJBCA is misinterpreting RFC 4514
and is doing the opposite.

Now my improvement suggestions:

1. "LDAP DN Order" option has a wrong name and this should be removed or at
least renamed to something like "Reverse DN order".
2. Current "LDAP DN Order" option (to be renamed to "Reverse DN order")
should be disabled by default for new CAs and certificate profiles as this
is promoting the generation of non-standard DNs and affects unaware users
trusting in the EJBCA default configuration to be optimal, for example,
myself, which generated a couple of root CAs in the past with this type of
DN :(.

Additionally, the previous would require a full rewrite of the following
documentation,
https://www.ejbca.org/docs/Certificate_Profile_Fields.html#src-41288003_id-.CertificateProfileFieldsv7.0.1-UseLDAPDNOrderUse_LDAP_DN_Order
.

Finally, some related issues that I found:

- https://jira.primekey.se/browse/ECA-1701, should maybe be reopened?.
- https://jira.primekey.se/browse/ECA-1328
- https://jira.primekey.se/browse/ECA-3856

On Wed, Nov 12, 2014 at 2:55 AM Tomas Gustavsson <to...@pr...> wrote:

>
> Waiting for more remake of this "feature" I updated the docs for the
> next release.
>
> *** Use LDAP DN order ***
>
> In a certificate the order of the DN components (CN,O,C etc) can be put
> in different order, in the binary encoded certificate.
>
>      last-to-first, forward (historically called LDAP DN Order in
> EJBCA): CN=Common Name, O=Organization, C=Country
>      first-to-last, reverse order: C=Country, O=Organization, CN=Common
> name
>
> When using string representation of DNs, the actual order is commonly
> not displayed, but the tool used will display in the order it sees fit
> which might be the reverse of the real, binary, order. In order to see
> the real, binary, order an asn1 parsing tool, like OpenSSL, can be used.
> In practice DN order can be important as comparisons is often done using
> string comparisons, where the string value may be depending on the order
> or not.
>
> The most common order is first-to-last (i.e. C,O,CN), but for historical
> reasons EJBCA uses last-to-first (CN,O,C). Some applications do require
> first-to-last order however and therefore EJBCA gives you the choice
> (named as 'non LDAP DN order'). There are two places in EJBCA where this
> can be configured:
>
>      In the Certificate profile (Edit certificate profiles)
>      In the CA configuration (Edit Certificate Authorities)
>
> The relationship between the settings is that they are both evaluated in
> a logical AND expression. This means that if both are true the DN will
> have last-to-first (LDAP) DN order, but if any one of them is false the
> DN will have X.500 order.
>
> For some references see RFC2253 and RFC4514
>
> Cheers,
> Tomas
>
> On 2014-10-15 23:32, Michael Ströder wrote:
> > Tomas Gustavsson wrote:
> >> Of course EJBCA is not caring about the string representation of DNs,
> >
> > Not true! (not meant as offense)
> >
> > If you accept an input field or config file value with a DN (like EJBCA
> does
> > in various places) you're definitely in the business of dealing with
> string
> > representation of DNs!
> >
> > Let's pick an example from your docs:
> >
> > http://www.ejbca.org/docs/userguide.html#Name%20Constraints
> >
> > C=SE,O=Company
> >      Matches against the beginning of the Subject DN. The certificates
> must
> >      not use LDAP DN order, which is enabled by default!
> >
> > Can you see the confusion introduced?
> >
> >> Anyhow, to summarize your suggestion it is to "uncheck" the checkbox by
> >> default, and remove the option.
> >
> > Yepp.
> >
> >> Providing only one possible asn.1
> >> encoding, which in your view is the correct one?
> >
> > You simply have to preserve the RDNSequence order in whatever data
> structure
> > you keep or convert the DN at a given time. ;-)
> >
> > 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://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>


-- 
Jaime Hablutzel -  RPC 994690880