Menu
▾
▴
Re: [Ejbca-develop] LDAP DN order is wrong
|
From: Jaime H. <hab...@gm...> - 2019-04-26 13:40:53
|
I'm in bad luck today, no permission in "EJBCA Community Support" (COMMUNITY) too. I do only have access to create issues for: - NPKD - DSS May you check my JIRA user permissions?, username is "hablutzel1". PS: In JIRA, I see the following message in the top, "SUPPORT MIGRATED TO SUPPORT.PRIMEKEY.COM", is it maybe related to the reduced permissions?. On Thu, Apr 25, 2019 at 2:06 PM Tomas Gustavsson <to...@pr...> wrote: > > 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 > > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > -- Jaime Hablutzel - RPC 994690880 |
