Menu
▾
▴
Re: [Ejbca-develop] LDAP DN order is wrong
|
From: Tomas G. <to...@pr...> - 2019-04-25 07:51:35
|
Hi,
It would be best if you create a new issue, linking to the old issues.
Closed issues should typically never be re-opened.
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
>
|
