Menu
▾
▴
Re: [Ejbca-develop] LDAP DN order is wrong
|
From: Tomas G. <to...@pr...> - 2019-04-25 19:05:54
|
Hi Jaime, If you create one in "EJBCA Community" I'll move to to ECA. Cheers, Tomas On 2019-04-25 19:14, Jaime Hablutzel wrote: > > > Sent from Android. > > On Thu, Apr 25, 2019, 2:52 AM Tomas Gustavsson <to...@pr... > <mailto: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...> > > <mailto: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...> > > <mailto: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...> > > <mailto:Ejb...@li... > <mailto:Ejb...@li...>> > > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > > > > > > > > -- > > Jaime Hablutzel - RPC 994690880 > > > > > > _______________________________________________ > > Ejbca-develop mailing list > > Ejb...@li... > <mailto:Ejb...@li...> > > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > <mailto:Ejb...@li...> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
