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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Sent from Android.

On Thu, Apr 25, 2019, 2:52 AM Tomas Gustavsson <to...@pr...> wrote:

>
> Hi,
>
> It would be best if you create a new issue, linking to the old issues.
> Closed issues should typically never be re-opened.
>

My JIRA user (hablutzel1) seems unable to create issues in the ECA project.
Please see https://m.imgur.com/gallery/VSixjpG.

> The documentation does not seem to need a complete re-write? But the
> difference between binary (asn.1) order and string representation needs
> to be added for sure. Also additional information as you highlight
> should be added.
>
> Please open a new issue. that would be great!
>
> Cheers,
> Tomas
>
> On 2019-04-22 15:50, Jaime Hablutzel wrote:
> > 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 moving
> >     backwards* 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 the
> >     rules 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...
> > <mailto: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...
> >     <mailto: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...
> >     <mailto:Ejb...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >
> >
> >
> > --
> > Jaime Hablutzel -  RPC 994690880
> >
> >
> > _______________________________________________
> > Ejbca-develop mailing list
> > Ejb...@li...
> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>