ejbca-develop — Development discussions

[Ejbca-develop] Include Archive Cutoff OCSP extension in all responses

[Jaime H. <hab...@gm...>]

Hi, I think that always including the Archive Cutoff OCSP extension (if
enabled) in responses would be really helpful. Now, some illustrative
examples:

Status for a given certificate might not be available anymore (e.g.
CertificateStatus.NOT_AVAILABLE), but it could have been good or revoked in
the past, for example, for an expired certificate deleted after the
retention interval got surpassed, so including the archive cutoff date
warns clients of this possibility, which is specially important when "Non
existing is good" is enabled, because the server could be responding good
now for a deleted certificate previously revoked.

If certificate status is still available (CertificateStatus.REVOKED or
CertificateStatus.OK), to provide the archive cutoff would help clients to
learn the server retention interval, so they can realize until when the
OCSP server guarantees to keep certificate status after expiration, e.g. a
client might be planning to demonstrate in a trial (in a given date in the
future) that a signature generated in the past was generated with a valid
certificate and knowing the archive cutoff would be helpful for him to know
until when that information will be available.

Now, quoting from RFC 6960, "4.4.4. Archive Cutoff":

OCSP servers that provide support for such a historical reference
> *SHOULD include an archive cutoff date extension in responses*.


It doesn't say that the extension should be included only for certificates
under a given criteria (e.g. only expired ones), it just say that if a
server support historical reference (e.g. a regular EJBCA setup), the
archive cutoff should be included in responses, where "responses" could be
interpreted as "all responses" for the sake of always providing clients
with this helpful information.

Finally, I’m attaching a proposed patch over r32508. Just note that
introducing this patch would require changes in
https://www.ejbca.org/docs/Archive_Cutoff.html, for example, the following
wouldn't be true anymore:

Archive Cutoff is only returned in the OCSP responses for expired
> certificates.


Jaime Hablutzel -  +51 994690880

Re: [Ejbca-develop] OCSP Archive Cutoff date not being calculated by substracting from the producedAt time

[Tomas G. <to...@pr...>]

Hi,

Your code is more correct, and right should be right. I applied the
patch in https://jira.primekey.se/browse/ECA-8230.

In the case of privateKeyUsagePeriod the difference could be many
minutes, or even hours, since notNefore is by default -10m and can be
set to any value, past or present.
In this case it is only a few lines of java code between the two
instances of getting current time, which is unlikely to take even 1ms.
Since times are rounded to seconds it the probability of 1 second
difference is small.

Cheers,
Tomas
---
PrimeKey Tech Days 2019
Stockholm, Sweden
17-18 September
www.primekey.com/tech-days


On 2019-05-28 00:36, Jaime Hablutzel wrote:
> RFC 6960, "4.4.4. Archive Cutoff" says:
> 
>     An OCSP responder MAY choose to retain revocation information beyond
>     a certificate’s expiration. The date obtained by *subtracting this
>     retention interval value from the producedAt time* in a response is
>     defined as the certificate’s "archive cutoff" date.
> 
> 
> But current code is not substracting the retention interval from the
> exact producedAt time, but from a freshly obtained current time.
> 
> Simple patch follows:
> 
> ---
> modules/cesecore-ejb/src/org/cesecore/certificates/ocsp/OcspResponseGeneratorSessionBean.java
> (revision 32428)
> +++
> modules/cesecore-ejb/src/org/cesecore/certificates/ocsp/OcspResponseGeneratorSessionBean.java
> (date 1558989475000)
> @@ -1353,8 +1353,8 @@
>                      log.info
> <http://log.info>(intres.getLocalizedMessage("ocsp.infoaddedstatusinfo",
> sStatus, certId.getSerialNumber().toString(16), caCertificateSubjectDn));
>                      respItem = new OCSPResponseItem(certId, certStatus,
> nextUpdate);
>                      if (addArchiveCutoff) {
> -                        addArchiveCutoff(respItem);
>                          producedAt = new Date();
> +                        addArchiveCutoff(respItem, producedAt);
>                      }
>                  }
>  
> @@ -1555,12 +1555,12 @@
>          return false;
>      }
>      
> -    private void addArchiveCutoff(OCSPResponseItem respItem) {
> +    private void addArchiveCutoff(OCSPResponseItem respItem, Date
> producedAt) {
>          long archPeriod = OcspConfiguration.getExpiredArchiveCutoff();
>          if (archPeriod == -1) {
>              return;
>          }
> -        long res = System.currentTimeMillis() - archPeriod;
> +        long res = producedAt.getTime() - archPeriod;
>          ASN1OctetString archiveCutoffValue;
>          try {
>              archiveCutoffValue = new DEROctetString(new
> ASN1GeneralizedTime(new Date(res)));
> 
> And I think that this change is actually required for compliance with
> the last part
> of https://jira.primekey.se/browse/ECA-3314?focusedCommentId=24954&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-24954:
> 
>     I think we should ensure that there are no differences. We had some
>     differences before in CAs with privateKeyUsagePeriod and notAfter,
>     and that turned out to be not good.
> 
> 
> -- 
> Jaime Hablutzel -  RPC 994690880
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

[Ejbca-develop] OCSP Archive Cutoff date not being calculated by substracting from the producedAt time

[Jaime H. <hab...@gm...>]

RFC 6960, "4.4.4. Archive Cutoff" says:

An OCSP responder MAY choose to retain revocation information beyond
> a certificate’s expiration. The date obtained by
> *subtracting thisretention interval value from the producedAt time* in a
> response is
> defined as the certificate’s "archive cutoff" date.


But current code is not substracting the retention interval from the exact
producedAt time, but from a freshly obtained current time.

Simple patch follows:

---
modules/cesecore-ejb/src/org/cesecore/certificates/ocsp/OcspResponseGeneratorSessionBean.java
(revision 32428)
+++
modules/cesecore-ejb/src/org/cesecore/certificates/ocsp/OcspResponseGeneratorSessionBean.java
(date 1558989475000)
@@ -1353,8 +1353,8 @@

log.info(intres.getLocalizedMessage("ocsp.infoaddedstatusinfo",
sStatus, certId.getSerialNumber().toString(16), caCertificateSubjectDn));
                     respItem = new OCSPResponseItem(certId, certStatus,
nextUpdate);
                     if (addArchiveCutoff) {
-                        addArchiveCutoff(respItem);
                         producedAt = new Date();
+                        addArchiveCutoff(respItem, producedAt);
                     }
                 }

@@ -1555,12 +1555,12 @@
         return false;
     }

-    private void addArchiveCutoff(OCSPResponseItem respItem) {
+    private void addArchiveCutoff(OCSPResponseItem respItem, Date
producedAt) {
         long archPeriod = OcspConfiguration.getExpiredArchiveCutoff();
         if (archPeriod == -1) {
             return;
         }
-        long res = System.currentTimeMillis() - archPeriod;
+        long res = producedAt.getTime() - archPeriod;
         ASN1OctetString archiveCutoffValue;
         try {
             archiveCutoffValue = new DEROctetString(new
ASN1GeneralizedTime(new Date(res)));

And I think that this change is actually required for compliance with the
last part of
https://jira.primekey.se/browse/ECA-3314?focusedCommentId=24954&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-24954
:

I think we should ensure that there are no differences. We had some
> differences before in CAs with privateKeyUsagePeriod and notAfter, and that
> turned out to be not good.


-- 
Jaime Hablutzel -  RPC 994690880

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

[Jaime H. <hab...@gm...>]

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

>
> Hi,
>
> It would be best if you create a new issue, linking to the old issues.
>

Done, https://jira.primekey.se/browse/COMMUNITY-203.

[Ejbca-develop] EJBCA now on DockerHub

[Tomas G. <to...@pr...>]

Hi,

The EJBCA project has worked for some time on making CI pipe-line work
with containers. The result of this is that EJBCA Community is now
available on DockerHub. Regularly updated, and easy to pull. We
recommend this as a great way to test EJBCA, integrate and just in
general try things out.

EJBCA Community on DockerHub:
https://hub.docker.com/r/primekey/ejbca-ce

Or for the one liner, just go:
docker pull primekey/ejbca-ce

Depending on your policy and requirements there may be things to
consider if you plan on putting containers in production, such as HSM
support and connecting to your database of choice, the integrity of
pulling production code from dockerhub, other secure concerns etc. The
standard stuff.

Regards,
The EJBCA Team
---
Registration for PrimeKey Tech Days 2019 is now open.
PKI Tech Days in Stockholm, Sweden, 17-18 September
www.primekey.com/tech-days

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

[Jaime H. <hab...@gm...>]

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

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

[Tomas G. <to...@pr...>]

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
> 

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

[Jaime H. <hab...@gm...>]

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
>

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

[Tomas G. <to...@pr...>]

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
> 

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

[Jaime H. <hab...@gm...>]

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 movingbackwards*
> 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 therules 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...> 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...
> > 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...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>


-- 
Jaime Hablutzel -  RPC 994690880

Re: [Ejbca-develop] Typos in RevokeEndEntityCommand "Reason" parameter documentation

[Tomas G. <to...@pr...>]

Thanks Jaime. Fixed for the next release.
https://jira.primekey.se/browse/ECA-8014

Cheers,
Tomas

On 2019-03-22 00:44, Jaime Hablutzel wrote:
> There are a couple of typos in
> modules/ejbca-ejb-cli/src/org/ejbca/ui/cli/ra/RevokeEndEntityCommand.java at
> rev 24892. 
> 
> A simple patch with highlighted changes follows:
> 
> ---
> modules/ejbca-ejb-cli/src/org/ejbca/ui/cli/ra/RevokeEndEntityCommand.java(revision
> 31921)
> +++
> modules/ejbca-ejb-cli/src/org/ejbca/ui/cli/ra/RevokeEndEntityCommand.java(date
> 1553211389718)
> @@ -62,8 +62,8 @@
>                  MandatoryMode.MANDATORY,
>                  StandaloneMode.ALLOW,
>                  ParameterMode.ARGUMENT,
> -                "Reason: *unused*(0), keyCompromise(1),
> cACompromise(2), affiliationChanged(3),"
> -                        + " superseded(4), cessationOfOperation(5),
> *certficateHold*(6), removeFromCRL(8), privilegeWithdrawn(9),
> aACompromise(10). Normal reason is 0"));
> +                "Reason: *unspecified*(0), keyCompromise(1),
> cACompromise(2), affiliationChanged(3),"
> +                        + " superseded(4), cessationOfOperation(5),
> *certificateHold*(6), removeFromCRL(8), privilegeWithdrawn(9),
> aACompromise(10). Normal reason is 0"));
>  
>      }
>  
> Regards.
> 
> 
> 
> 
> -- 
> Jaime Hablutzel -  RPC 994690880
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

[Ejbca-develop] Typos in RevokeEndEntityCommand "Reason" parameter documentation

[Jaime H. <hab...@gm...>]

There are a couple of typos in
modules/ejbca-ejb-cli/src/org/ejbca/ui/cli/ra/RevokeEndEntityCommand.java at
rev 24892.

A simple patch with highlighted changes follows:

---
modules/ejbca-ejb-cli/src/org/ejbca/ui/cli/ra/RevokeEndEntityCommand.java
(revision
31921)
+++
modules/ejbca-ejb-cli/src/org/ejbca/ui/cli/ra/RevokeEndEntityCommand.java (date
1553211389718)
@@ -62,8 +62,8 @@
                 MandatoryMode.MANDATORY,
                 StandaloneMode.ALLOW,
                 ParameterMode.ARGUMENT,
-                "Reason: *unused*(0), keyCompromise(1), cACompromise(2),
affiliationChanged(3),"
-                        + " superseded(4), cessationOfOperation(5),
*certficateHold*(6), removeFromCRL(8), privilegeWithdrawn(9),
aACompromise(10). Normal reason is 0"));
+                "Reason: *unspecified*(0), keyCompromise(1),
cACompromise(2), affiliationChanged(3),"
+                        + " superseded(4), cessationOfOperation(5),
*certificateHold*(6), removeFromCRL(8), privilegeWithdrawn(9),
aACompromise(10). Normal reason is 0"));

     }

Regards.




-- 
Jaime Hablutzel -  RPC 994690880

Re: [Ejbca-develop] Custom attribute "organizationIdentifier" broken: "Unsupported Subject DN Field found"

[Tomas G. <to...@pr...>]

I do not know the answer to this actually. Perhaps it has to do with the
"default" numbering for this DN components that was added to EJBCA.
Check DNFieldExtractor.java might help?

Cheers,
Tomas

On 2019-03-19 09:24, Arnaud Defos wrote:
> Hello,
> 
> As I said in my previous email and this line was not changed after the
> update:
> 
> At the end of $EJBCA_HOME/src/java/profilemappings.properties file:
> 
> DN;2.5.4.97;200;2.5.5.4.97;200;OrganizationIdentifier;organizationIdentifier
> (2.5.4.97)
> 
> Regards.
> 
> Le lun. 18 mars 2019 à 17:32, Tomas Gustavsson <to...@pr...
> <mailto:to...@pr...>> a écrit :
> 
> 
>     How about profilemappings.properties?
> 
>     Regards,
>     Tomas
> 
>     On 2019-03-15 16:33, Arnaud Defos wrote:
>     > Hello,
>     >
>     > We have updated our EJBCA Community from version 6.3.1.1.1 to
>     6.10.1.2.
>     >
>     > We added a custom DN attribute "organizationIdentifier" that
>     worked well
>     > in version 6.3 like this:
>     >
>     > $EJBCA_HOME/src/java/profilemappings.properties:
>     >
>     DN;2.5.4.97;200;2.5.5.4.97;200;OrganizationIdentifier;organizationIdentifier
>     > (2.5.4.97)
>     > $EJBCA_HOME/src/java/dncomponents.properties:
>     > organizationIdentifier=2.5.5.4.97
>     >
>     > Since the update, we have this error when we use this attribute:
>     >
>     > An exception has occurred.
>     > Unsupported Subject DN Field found in:CN=MYCN,SN=MYSN,O=MYO
>     > SAS,organizationIdentifier=MYOI,C=EN
>     >
>     > Is it related to the fact that this attribute was added in version
>     6.5.2
>     > on EJBCA Enterprise?
>     >
>     > Indeed, it is now defined in
>     > $EJBCA_HOME/src/java/dncomponents.properties.sample.
>     >
>     > How can this be corrected?
>     > We tried several things without finding a solution.
>     >
>     >
>     >
>     > _______________________________________________
>     > 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
> 

Re: [Ejbca-develop] Custom attribute "organizationIdentifier" broken: "Unsupported Subject DN Field found"

[Arnaud D. <arn...@gm...>]

Hello,

As I said in my previous email and this line was not changed after the
update:

At the end of $EJBCA_HOME/src/java/profilemappings.properties file:

DN;2.5.4.97;200;2.5.5.4.97;200;OrganizationIdentifier;organizationIdentifier
(2.5.4.97)

Regards.

Le lun. 18 mars 2019 à 17:32, Tomas Gustavsson <to...@pr...> a écrit :

>
> How about profilemappings.properties?
>
> Regards,
> Tomas
>
> On 2019-03-15 16:33, Arnaud Defos wrote:
> > Hello,
> >
> > We have updated our EJBCA Community from version 6.3.1.1.1 to 6.10.1.2.
> >
> > We added a custom DN attribute "organizationIdentifier" that worked well
> > in version 6.3 like this:
> >
> > $EJBCA_HOME/src/java/profilemappings.properties:
> >
> DN;2.5.4.97;200;2.5.5.4.97;200;OrganizationIdentifier;organizationIdentifier
> > (2.5.4.97)
> > $EJBCA_HOME/src/java/dncomponents.properties:
> > organizationIdentifier=2.5.5.4.97
> >
> > Since the update, we have this error when we use this attribute:
> >
> > An exception has occurred.
> > Unsupported Subject DN Field found in:CN=MYCN,SN=MYSN,O=MYO
> > SAS,organizationIdentifier=MYOI,C=EN
> >
> > Is it related to the fact that this attribute was added in version 6.5.2
> > on EJBCA Enterprise?
> >
> > Indeed, it is now defined in
> > $EJBCA_HOME/src/java/dncomponents.properties.sample.
> >
> > How can this be corrected?
> > We tried several things without finding a solution.
> >
> >
> >
> > _______________________________________________
> > 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
>

Re: [Ejbca-develop] Custom attribute "organizationIdentifier" broken: "Unsupported Subject DN Field found"

[Tomas G. <to...@pr...>]

How about profilemappings.properties?

Regards,
Tomas

On 2019-03-15 16:33, Arnaud Defos wrote:
> Hello,
> 
> We have updated our EJBCA Community from version 6.3.1.1.1 to 6.10.1.2.
> 
> We added a custom DN attribute "organizationIdentifier" that worked well
> in version 6.3 like this:
> 
> $EJBCA_HOME/src/java/profilemappings.properties:
> DN;2.5.4.97;200;2.5.5.4.97;200;OrganizationIdentifier;organizationIdentifier
> (2.5.4.97)
> $EJBCA_HOME/src/java/dncomponents.properties:
> organizationIdentifier=2.5.5.4.97
> 
> Since the update, we have this error when we use this attribute:
> 
> An exception has occurred.
> Unsupported Subject DN Field found in:CN=MYCN,SN=MYSN,O=MYO
> SAS,organizationIdentifier=MYOI,C=EN
> 
> Is it related to the fact that this attribute was added in version 6.5.2
> on EJBCA Enterprise?
> 
> Indeed, it is now defined in
> $EJBCA_HOME/src/java/dncomponents.properties.sample.
> 
> How can this be corrected?
> We tried several things without finding a solution.
> 
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

Re: [Ejbca-develop] Dangerous pattern of seeding SecureRandom instances

[Tomas G. <to...@pr...>]

Hi Jaime,

I have fixed this pattern in test classes in EJBCA.
https://jira.primekey.se/browse/ECA-7990

In test classes I use a plain Random now, so it's clear for anyone
looking at the code that it is not security relevant.

Thanks for the report.

Cheers,
Tomas

On 2019-03-15 19:45, Jaime Hablutzel wrote:
> I filled a couple of bug reports to Oracle for fixing and improving the
> current documentation:
> 
> - https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8220730
> - https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8220732
> 
> 
> On Thu, Mar 14, 2019 at 9:12 AM Martijn Brinkers <mar...@gm...
> <mailto:mar...@gm...>> wrote:
> 
>     >> On 14-03-19 13:18, Tomas Gustavsson wrote:
>     >>> Yes the javadoc says so, but analysis of the java source code
>     tells me
>     >>> otherwise. Unless I, and another guy in the Internet, read it
>     >>> incorrectly, is a subtle interpretation issue of the javadoc in the
>     >>> actual implementation.
>     >>> setSeed makes the internal seeding not to run, causing the
>     setSeed to be
>     >>> the only seeding. But subsequent calls to setSeed will
>     supplement the
>     >>> first call.
>     >>>
>     >>> I made the same interpretation as you from the javadoc, but
>     checking the
>     >>> implementation changed my mind.
>     >>
>     >> It looks like you are right when using SHA1PRNG. It is not the
>     case when
>     >> you create an instance of the default SecureRandom because that
>     is using
>     >> the NativePRNG (at least on Linux).
>     >>
>     >> The Javadoc is very unclear about this. To me it looks like a bug
>     in the
>     >> implementation of SHA1PRNG.
>     >>
>     >> That said, in my view you should never call SecureRandom#setSeed
>     unless
>     >> you want to seed it with a more secure random source than what is by
>     >> default provided.
>     >
>     > In the test code setSeed is probably used just no _not_ make it
>     wait for
>     > self-seeding, you want tests to run fast.
>     > Changing it to just Random for tests seems reasonable imho.
> 
>     Yes using it for testing is reasonable. It might be used for example if
>     you want a reproducible test case.
> 
>     I did some additional reading and the Javadoc for Java 9 are more clear
>     on the seeding subject
> 
>     "A PRNG SecureRandom will not seed itself automatically if setSeed is
>     called before any nextBytes or reseed calls. The caller should make sure
>     that the seed argument contains enough entropy for the security of this
>     SecureRandom."
> 
>     https://docs.oracle.com/javase/9/docs/api/java/security/SecureRandom.html
> 
>     They now also mention that SecureRandom is thread safe. In previous
>     Javadocs they did not mention anything about thread safety and you
>     therefore had to assume that SecureRandom was not thread safe (at least
>     in my view :)
> 
>     Kind regards,
> 
>     Martijn Brinkers
> 
> 
>     _______________________________________________
>     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
> 

Re: [Ejbca-develop] Suggestions around random serial number generation

[Tomas G. <to...@pr...>]

Hi Jaime,

Thanks for the patch (I lost that email...).
See issue:
https://jira.primekey.se/browse/ECA-7989

I made small modification to your patch, removed deprecated methods and
other tiny fixes, and added a multi-threaded test.

Otherwise a very elegant patch. Thanks.

Regards,
Tomas

On 2019-03-17 18:35, Jaime Hablutzel wrote:
> First, I wanted to clarify that with EJBCA <7.0.1, the default 8 bytes
> configuration for serial numbers generation wasn't delivering 63 bits of
> entropy (as being declared) mainly because of the implementation
> filtering out values that would produce a DER encoding in less than 8
> bytes, so the real entropy being provided would be around (or less than):
> 
> log2(0x7FFFFFFFFFFFFFFF - 0x80000000000000 + 1) = 62.99435343685886
> 
> Now, I would like to suggest to improve the documentation at
> https://www.ejbca.org/docs/CA_Fields.html#src-42205242_id-.CAFieldsv7.0.1-Ca_Serial_Number_Octet_Size,
> modifying it to something like this:
> 
>     Sets the length in octets of certificate serial numbers generated,
>     but note that the length of the serial number IS NOT the same that
>     the entropy it contains (e.g. 8 octets or 64 bit serial number
>     doesn't provide 64 bits of entropy) because some values are being
>     filtered out: 
>     - Negative values (all with the most-significant-bit set to 1).
>     - Values than would provide a shorter encoding than the requested
>     length in octets.
>     - Serial numbers for previously generated certificates.
>     Now, CA/B Forum requires the use of 64 bit entropy when generating
>     serial numbers, hence, for complying with that requirement, larger
>     sizes than 8 octets are required (for more information, refer to the
>     CA/Browser Forum information on Ballot 164 - Certificate Serial
>     Number Entropy). 
>     Possible values can range between 4 and 20 octets, and the default
>     for all new CAs is 20 octets.
> 
> 
> Finally, I have attached a patch with some improvements over the current
> code at ECA-4991.
> 
> -- 
> Jaime Hablutzel -  RPC 994690880
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

Re: [Ejbca-develop] Dangerous pattern of seeding SecureRandom instances

[Tomas G. <to...@pr...>]

Great bug reports imho.


On 2019-03-15 19:45, Jaime Hablutzel wrote:
> I filled a couple of bug reports to Oracle for fixing and improving the
> current documentation:
> 
> - https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8220730
> - https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8220732
> 
> 
> On Thu, Mar 14, 2019 at 9:12 AM Martijn Brinkers <mar...@gm...
> <mailto:mar...@gm...>> wrote:
> 
>     >> On 14-03-19 13:18, Tomas Gustavsson wrote:
>     >>> Yes the javadoc says so, but analysis of the java source code
>     tells me
>     >>> otherwise. Unless I, and another guy in the Internet, read it
>     >>> incorrectly, is a subtle interpretation issue of the javadoc in the
>     >>> actual implementation.
>     >>> setSeed makes the internal seeding not to run, causing the
>     setSeed to be
>     >>> the only seeding. But subsequent calls to setSeed will
>     supplement the
>     >>> first call.
>     >>>
>     >>> I made the same interpretation as you from the javadoc, but
>     checking the
>     >>> implementation changed my mind.
>     >>
>     >> It looks like you are right when using SHA1PRNG. It is not the
>     case when
>     >> you create an instance of the default SecureRandom because that
>     is using
>     >> the NativePRNG (at least on Linux).
>     >>
>     >> The Javadoc is very unclear about this. To me it looks like a bug
>     in the
>     >> implementation of SHA1PRNG.
>     >>
>     >> That said, in my view you should never call SecureRandom#setSeed
>     unless
>     >> you want to seed it with a more secure random source than what is by
>     >> default provided.
>     >
>     > In the test code setSeed is probably used just no _not_ make it
>     wait for
>     > self-seeding, you want tests to run fast.
>     > Changing it to just Random for tests seems reasonable imho.
> 
>     Yes using it for testing is reasonable. It might be used for example if
>     you want a reproducible test case.
> 
>     I did some additional reading and the Javadoc for Java 9 are more clear
>     on the seeding subject
> 
>     "A PRNG SecureRandom will not seed itself automatically if setSeed is
>     called before any nextBytes or reseed calls. The caller should make sure
>     that the seed argument contains enough entropy for the security of this
>     SecureRandom."
> 
>     https://docs.oracle.com/javase/9/docs/api/java/security/SecureRandom.html
> 
>     They now also mention that SecureRandom is thread safe. In previous
>     Javadocs they did not mention anything about thread safety and you
>     therefore had to assume that SecureRandom was not thread safe (at least
>     in my view :)
> 
>     Kind regards,
> 
>     Martijn Brinkers
> 
> 
>     _______________________________________________
>     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
> 

Re: [Ejbca-develop] Suggestions around random serial number generation

[Tomas G. <to...@pr...>]

Hi Jaime,

Great minds think alike :-)

I was already working on clarified documentation during the weekend.

Please check it out. I removed the references to B164, as it's only a
specific, current, use case, and it might change in the future with
another ballot. It's hard to keep track of documentation for all
ballots, better describe it clearly so anyone can check themselves
against the current BR, or whatever requirements they are checking against.

https://svn.cesecore.eu/svn/ejbca/trunk/ejbca/modules/cesecore-common/src/org/cesecore/certificates/ca/internal/SernoGeneratorRandom.java

Regards,
Tomas

On 2019-03-17 18:35, Jaime Hablutzel wrote:
> First, I wanted to clarify that with EJBCA <7.0.1, the default 8 bytes
> configuration for serial numbers generation wasn't delivering 63 bits of
> entropy (as being declared) mainly because of the implementation
> filtering out values that would produce a DER encoding in less than 8
> bytes, so the real entropy being provided would be around (or less than):
> 
> log2(0x7FFFFFFFFFFFFFFF - 0x80000000000000 + 1) = 62.99435343685886
> 
> Now, I would like to suggest to improve the documentation at
> https://www.ejbca.org/docs/CA_Fields.html#src-42205242_id-.CAFieldsv7.0.1-Ca_Serial_Number_Octet_Size,
> modifying it to something like this:
> 
>     Sets the length in octets of certificate serial numbers generated,
>     but note that the length of the serial number IS NOT the same that
>     the entropy it contains (e.g. 8 octets or 64 bit serial number
>     doesn't provide 64 bits of entropy) because some values are being
>     filtered out: 
>     - Negative values (all with the most-significant-bit set to 1).
>     - Values than would provide a shorter encoding than the requested
>     length in octets.
>     - Serial numbers for previously generated certificates.
>     Now, CA/B Forum requires the use of 64 bit entropy when generating
>     serial numbers, hence, for complying with that requirement, larger
>     sizes than 8 octets are required (for more information, refer to the
>     CA/Browser Forum information on Ballot 164 - Certificate Serial
>     Number Entropy). 
>     Possible values can range between 4 and 20 octets, and the default
>     for all new CAs is 20 octets.
> 
> 
> Finally, I have attached a patch with some improvements over the current
> code at ECA-4991.
> 
> -- 
> Jaime Hablutzel -  RPC 994690880
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

[Ejbca-develop] Suggestions around random serial number generation

[Jaime H. <hab...@gm...>]

First, I wanted to clarify that with EJBCA <7.0.1, the default 8 bytes
configuration for serial numbers generation wasn't delivering 63 bits of
entropy (as being declared) mainly because of the implementation filtering
out values that would produce a DER encoding in less than 8 bytes, so the
real entropy being provided would be around (or less than):

log2(0x7FFFFFFFFFFFFFFF - 0x80000000000000 + 1) = 62.99435343685886

Now, I would like to suggest to improve the documentation at
https://www.ejbca.org/docs/CA_Fields.html#src-42205242_id-.CAFieldsv7.0.1-Ca_Serial_Number_Octet_Size,
modifying it to something like this:

Sets the length in octets of certificate serial numbers generated, but note
> that the length of the serial number IS NOT the same that the entropy it
> contains (e.g. 8 octets or 64 bit serial number doesn't provide 64 bits of
> entropy) because some values are being filtered out:
> - Negative values (all with the most-significant-bit set to 1).
> - Values than would provide a shorter encoding than the requested length
> in octets.
> - Serial numbers for previously generated certificates.
> Now, CA/B Forum requires the use of 64 bit entropy when generating serial
> numbers, hence, for complying with that requirement, larger sizes than 8
> octets are required (for more information, refer to the CA/Browser Forum
> information on Ballot 164 - Certificate Serial Number Entropy).
> Possible values can range between 4 and 20 octets, and the default for all
> new CAs is 20 octets.


Finally, I have attached a patch with some improvements over the current
code at ECA-4991.

-- 
Jaime Hablutzel -  RPC 994690880

Re: [Ejbca-develop] Dangerous pattern of seeding SecureRandom instances

[Jaime H. <hab...@gm...>]

I filled a couple of bug reports to Oracle for fixing and improving the
current documentation:

- https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8220730
- https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8220732


On Thu, Mar 14, 2019 at 9:12 AM Martijn Brinkers <mar...@gm...>
wrote:

> >> On 14-03-19 13:18, Tomas Gustavsson wrote:
> >>> Yes the javadoc says so, but analysis of the java source code tells me
> >>> otherwise. Unless I, and another guy in the Internet, read it
> >>> incorrectly, is a subtle interpretation issue of the javadoc in the
> >>> actual implementation.
> >>> setSeed makes the internal seeding not to run, causing the setSeed to
> be
> >>> the only seeding. But subsequent calls to setSeed will supplement the
> >>> first call.
> >>>
> >>> I made the same interpretation as you from the javadoc, but checking
> the
> >>> implementation changed my mind.
> >>
> >> It looks like you are right when using SHA1PRNG. It is not the case when
> >> you create an instance of the default SecureRandom because that is using
> >> the NativePRNG (at least on Linux).
> >>
> >> The Javadoc is very unclear about this. To me it looks like a bug in the
> >> implementation of SHA1PRNG.
> >>
> >> That said, in my view you should never call SecureRandom#setSeed unless
> >> you want to seed it with a more secure random source than what is by
> >> default provided.
> >
> > In the test code setSeed is probably used just no _not_ make it wait for
> > self-seeding, you want tests to run fast.
> > Changing it to just Random for tests seems reasonable imho.
>
> Yes using it for testing is reasonable. It might be used for example if
> you want a reproducible test case.
>
> I did some additional reading and the Javadoc for Java 9 are more clear
> on the seeding subject
>
> "A PRNG SecureRandom will not seed itself automatically if setSeed is
> called before any nextBytes or reseed calls. The caller should make sure
> that the seed argument contains enough entropy for the security of this
> SecureRandom."
>
> https://docs.oracle.com/javase/9/docs/api/java/security/SecureRandom.html
>
> They now also mention that SecureRandom is thread safe. In previous
> Javadocs they did not mention anything about thread safety and you
> therefore had to assume that SecureRandom was not thread safe (at least
> in my view :)
>
> Kind regards,
>
> Martijn Brinkers
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>


-- 
Jaime Hablutzel -  RPC 994690880

[Ejbca-develop] Custom attribute "organizationIdentifier" broken: "Unsupported Subject DN Field found"

[Arnaud D. <arn...@gm...>]

Hello,

We have updated our EJBCA Community from version 6.3.1.1.1 to 6.10.1.2.

We added a custom DN attribute "organizationIdentifier" that worked well in
version 6.3 like this:

$EJBCA_HOME/src/java/profilemappings.properties:
DN;2.5.4.97;200;2.5.5.4.97;200;OrganizationIdentifier;organizationIdentifier
(2.5.4.97)
$EJBCA_HOME/src/java/dncomponents.properties:
organizationIdentifier=2.5.5.4.97

Since the update, we have this error when we use this attribute:

An exception has occurred.
Unsupported Subject DN Field found in:CN=MYCN,SN=MYSN,O=MYO
SAS,organizationIdentifier=MYOI,C=EN

Is it related to the fact that this attribute was added in version 6.5.2 on
EJBCA Enterprise?

Indeed, it is now defined in
$EJBCA_HOME/src/java/dncomponents.properties.sample.

How can this be corrected?
We tried several things without finding a solution.

Re: [Ejbca-develop] Dangerous pattern of seeding SecureRandom instances

[Martijn B. <mar...@gm...>]

>> On 14-03-19 13:18, Tomas Gustavsson wrote:
>>> Yes the javadoc says so, but analysis of the java source code tells me
>>> otherwise. Unless I, and another guy in the Internet, read it
>>> incorrectly, is a subtle interpretation issue of the javadoc in the
>>> actual implementation.
>>> setSeed makes the internal seeding not to run, causing the setSeed to be
>>> the only seeding. But subsequent calls to setSeed will supplement the
>>> first call.
>>>
>>> I made the same interpretation as you from the javadoc, but checking the
>>> implementation changed my mind.
>>
>> It looks like you are right when using SHA1PRNG. It is not the case when
>> you create an instance of the default SecureRandom because that is using
>> the NativePRNG (at least on Linux).
>>
>> The Javadoc is very unclear about this. To me it looks like a bug in the
>> implementation of SHA1PRNG.
>>
>> That said, in my view you should never call SecureRandom#setSeed unless
>> you want to seed it with a more secure random source than what is by
>> default provided.
> 
> In the test code setSeed is probably used just no _not_ make it wait for
> self-seeding, you want tests to run fast.
> Changing it to just Random for tests seems reasonable imho.

Yes using it for testing is reasonable. It might be used for example if
you want a reproducible test case.

I did some additional reading and the Javadoc for Java 9 are more clear
on the seeding subject

"A PRNG SecureRandom will not seed itself automatically if setSeed is
called before any nextBytes or reseed calls. The caller should make sure
that the seed argument contains enough entropy for the security of this
SecureRandom."

https://docs.oracle.com/javase/9/docs/api/java/security/SecureRandom.html

They now also mention that SecureRandom is thread safe. In previous
Javadocs they did not mention anything about thread safety and you
therefore had to assume that SecureRandom was not thread safe (at least
in my view :)

Kind regards,

Martijn Brinkers

Re: [Ejbca-develop] Dangerous pattern of seeding SecureRandom instances

[Tomas G. <to...@pr...>]

On 2019-03-14 14:51, Martijn Brinkers wrote:
> Hi Tomas,
> 
> See my comments inline
> 
> On 14-03-19 13:18, Tomas Gustavsson wrote:
>> Yes the javadoc says so, but analysis of the java source code tells me
>> otherwise. Unless I, and another guy in the Internet, read it
>> incorrectly, is a subtle interpretation issue of the javadoc in the
>> actual implementation.
>> setSeed makes the internal seeding not to run, causing the setSeed to be
>> the only seeding. But subsequent calls to setSeed will supplement the
>> first call.
>>
>> I made the same interpretation as you from the javadoc, but checking the
>> implementation changed my mind.
> 
> It looks like you are right when using SHA1PRNG. It is not the case when
> you create an instance of the default SecureRandom because that is using
> the NativePRNG (at least on Linux).
> 
> The Javadoc is very unclear about this. To me it looks like a bug in the
> implementation of SHA1PRNG.
> 
> That said, in my view you should never call SecureRandom#setSeed unless
> you want to seed it with a more secure random source than what is by
> default provided.

In the test code setSeed is probably used just no _not_ make it wait for
self-seeding, you want tests to run fast.
Changing it to just Random for tests seems reasonable imho.


> 
> Kind regards,
> 
> Martijn Brinkers
> 
> 
>> On 2019-03-13 23:01, Martijn Brinkers wrote:
>>> On 12-03-19 21:02, Jaime Hablutzel wrote:
>>>> I'm looking the following code pattern in several places of the source
>>>> code (mostly in tests):
>>>>
>>>> SecureRandom random = SecureRandom.getInstance("SHA1PRNG");
>>>> random.setSeed(new Date().getTime());
>>>> random.nextBytes(serno);
>>>>
>>>> Where the setSeed call just before the call to nextBytes prevents the
>>>> SHA1PRNG default implementation from feeding itself from system entropy,
>>>> so it relies on the provided timestamp as its only source of entropy,
>>>> which looks like a bad idea.
>>>
>>> According to SecureRandom javadoc, this should not have any implication
>>> on the security of the random generator (i.e., the randomness)
>>>
>>> https://docs.oracle.com/javase/7/docs/api/
>>>
>>> The given seed supplements, rather than replaces, the existing seed.
>>> Thus, repeated calls are guaranteed never to reduce randomness.
>>>
>>> Kind regards,
>>>
>>> Martijn Brinkers
>>>
>>>
>>> _______________________________________________
>>> 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
>>
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

Re: [Ejbca-develop] Dangerous pattern of seeding SecureRandom instances

[Martijn B. <mar...@gm...>]

Hi Tomas,

See my comments inline

On 14-03-19 13:18, Tomas Gustavsson wrote:
> Yes the javadoc says so, but analysis of the java source code tells me
> otherwise. Unless I, and another guy in the Internet, read it
> incorrectly, is a subtle interpretation issue of the javadoc in the
> actual implementation.
> setSeed makes the internal seeding not to run, causing the setSeed to be
> the only seeding. But subsequent calls to setSeed will supplement the
> first call.
> 
> I made the same interpretation as you from the javadoc, but checking the
> implementation changed my mind.

It looks like you are right when using SHA1PRNG. It is not the case when
you create an instance of the default SecureRandom because that is using
the NativePRNG (at least on Linux).

The Javadoc is very unclear about this. To me it looks like a bug in the
implementation of SHA1PRNG.

That said, in my view you should never call SecureRandom#setSeed unless
you want to seed it with a more secure random source than what is by
default provided.

Kind regards,

Martijn Brinkers


> On 2019-03-13 23:01, Martijn Brinkers wrote:
>> On 12-03-19 21:02, Jaime Hablutzel wrote:
>>> I'm looking the following code pattern in several places of the source
>>> code (mostly in tests):
>>>
>>> SecureRandom random = SecureRandom.getInstance("SHA1PRNG");
>>> random.setSeed(new Date().getTime());
>>> random.nextBytes(serno);
>>>
>>> Where the setSeed call just before the call to nextBytes prevents the
>>> SHA1PRNG default implementation from feeding itself from system entropy,
>>> so it relies on the provided timestamp as its only source of entropy,
>>> which looks like a bad idea.
>>
>> According to SecureRandom javadoc, this should not have any implication
>> on the security of the random generator (i.e., the randomness)
>>
>> https://docs.oracle.com/javase/7/docs/api/
>>
>> The given seed supplements, rather than replaces, the existing seed.
>> Thus, repeated calls are guaranteed never to reduce randomness.
>>
>> Kind regards,
>>
>> Martijn Brinkers
>>
>>
>> _______________________________________________
>> 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
>