|
From: Jaime H. <hab...@gm...> - 2019-04-25 17:16:01
|
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 > |