ejbca-develop — Development discussions

Re: [Ejbca-develop] Why ECDSA keys require a minimum size of 224 bits for Crypto Token key pair generation?

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

Good hunting of the originating committ!

I see it originates from this issue:
https://jira.primekey.se/browse/ECA-2801

There is no reference to the size 224 being a limit there, so we don't
know. Being since 2013, it's interesting that this is the first time
anyone asks for curves shorter than 224. Since EC is being used
extensively, I guess there is no real wide spread use of the sorter curves.

I made a note of this in the documentation for the next release. Unless
there is a substantial argument why you want to use shorter curves, I'll
leave it as it is.

Regards,
Tomas

On 2018-12-29 23:28, Andreas Kuehne wrote:
> Hi Jaime,
>
> an unclear reasoning and origin is a good starting point for conspiracy
> theories!
>
> The code snippet seems to implement a DIY approach to decide on
> algorithm suitability. A more standardized approach is given in
>
> Data Structure for the Security Suitability of Cryptographic Algorithms
> (DSSC)
> https://tools.ietf.org/html/rfc5698
>
> This could be a good base for a catalog  of supported algorithm.  A
> quick search did not reveal any ready-made implementations but I would
> guess a given standard is better than re-inventing a wheel.
>
> Greetings,
>
> Andreas
>> On Sat, Dec 22, 2018 at 1:59 PM Andreas Kuehne <ku...@tr...>
wrote:
>>
>>> Hi Jaime,
>>>
>>> interesting finding! Due to https://safecurves.cr.yp.to/ there are at
>>> least two curves with (slightly) shorter key length. On the other
hand the
>>> NIST-224 is considered insecure ...
>>>
>> Thanks for pointing out this resource.
>>
>>
>>> Are there any specific reasons for implementing this restriction?
>>>
>> I'm asking the same myself. I can trace back that change to the following
>> old (5 years ago) commit,
>>
https://github.com/rgorosito/ejbca/commit/49a8e1c5ff448c3d27c132e46675ed27ef7cb65b#diff-52fc78614bcdfb702e0bf5b66a3ffbfc,
>> but the motivation for it is no clear to me at first glance.
>>
>>
>>> Greetings,
>>>
>>> Andreas
>>>
>>> In EJBCA 6.10.1.2+, if you create a Crypto Token from the Admin GUI and
>>> then you try to generate an EC keypair for it, you find that certain
curves
>>> are not availabe, e.g. B-163, even when the documentation indicates
support
>>> for them
(seehttps://www.ejbca.org/docs/ECDSA_Keys_and_Signatures.html#src-16224742_id-.ECDSAKeysandSignaturesv6.12.0-Named_curves
>>> ).
>>>
>>> Looking at the source code I can see the cause for it is in the
following
>>> method, org.cesecore.keys.util.KeyTools#checkValidKeyLength:
>>>
>>> public static void checkValidKeyLength(final String keyAlg, final
int len)
>>> throws InvalidKeyException {
>>>   ...
>>>   if (*isEcdsa *|| isGost3410 || isDstu4145) {
>>>     ...
>>>     if ((len > 0) && (*len < 224)*) {
>>>       final String msg =
>>> intres.getLocalizedMessage("catoken.invalidkeylength", "ECDSA", "224",
>>> Integer.valueOf(len));
>>>       *throw new InvalidKeyException(msg);*
>>>     }
>>>   } ...
>>> }
>>>
>>> But, why is it so?. Are there potentials problems with EC curves
with a key
>>> size smaller than 224 bits?.
>>>
>>> PS: I'm a total ignorant of EC cryptography.
>>>
>>>
>>>
>>> _______________________________________________
>>> Ejbca-develop mailing
lis...@li...://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>>
>>>
>>> --
>>> Andreas Kühne
>>> phone: +49 177 293 24 97
>>> mailto: ku...@tr...
>>>
>>> Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659
Hannover Amtsgericht Hannover HRB 212612
>>>
>>> Director Andreas Kühne
>>>
>>> Company UK Company No: 5218868 Registered in England and Wales
>>>
>>> _______________________________________________
>>> 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
>
>
> --
> Andreas Kühne
> phone: +49 177 293 24 97
> mailto: ku...@tr...
>
> Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659
Hannover Amtsgericht Hannover HRB 212612
>
> Director Andreas Kühne
>
> Company UK Company No: 5218868 Registered in England and Wales
>
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

Re: [Ejbca-develop] Why ECDSA keys require a minimum size of 224 bits for Crypto Token key pair generation?

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

On Sat, Dec 29, 2018 at 5:29 PM Andreas Kuehne <ku...@tr...> wrote:

> Hi Jaime,
>
> an unclear reasoning and origin is a good starting point for conspiracy
> theories! ;-)
>
> The code snippet seems to implement a DIY approach to decide on algorithm
> suitability. A more standardized approach is given in
>
> Data Structure for the Security Suitability of Cryptographic Algorithms
> (DSSC)
> https://tools.ietf.org/html/rfc5698
>

Taking note.


>
> This could be a good base for a catalog  of supported algorithm.  A quick
> search did not reveal any ready-made implementations but I would guess a
> given standard is better than re-inventing a wheel.
>

I asked RFC authors if they know of any ECC oriented implementation of this
DSSC and I'll post it here if I receive any useful information.


>
> Greetings,
>
> Andreas
>
> On Sat, Dec 22, 2018 at 1:59 PM Andreas Kuehne <ku...@tr...> <ku...@tr...> wrote:
>
>
> Hi Jaime,
>
> interesting finding! Due to https://safecurves.cr.yp.to/ there are at
> least two curves with (slightly) shorter key length. On the other hand the
> NIST-224 is considered insecure ...
>
>
> Thanks for pointing out this resource.
>
>
>
> Are there any specific reasons for implementing this restriction?
>
>
> I'm asking the same myself. I can trace back that change to the following
> old (5 years ago) commit,https://github.com/rgorosito/ejbca/commit/49a8e1c5ff448c3d27c132e46675ed27ef7cb65b#diff-52fc78614bcdfb702e0bf5b66a3ffbfc,
> but the motivation for it is no clear to me at first glance.
>
>
>
> Greetings,
>
> Andreas
>
> In EJBCA 6.10.1.2+, if you create a Crypto Token from the Admin GUI and
> then you try to generate an EC keypair for it, you find that certain curves
> are not availabe, e.g. B-163, even when the documentation indicates support
> for them (seehttps://www.ejbca.org/docs/ECDSA_Keys_and_Signatures.html#src-16224742_id-.ECDSAKeysandSignaturesv6.12.0-Named_curves
> ).
>
> Looking at the source code I can see the cause for it is in the following
> method, org.cesecore.keys.util.KeyTools#checkValidKeyLength:
>
> public static void checkValidKeyLength(final String keyAlg, final int len)
> throws InvalidKeyException {
>   ...
>   if (*isEcdsa *|| isGost3410 || isDstu4145) {
>     ...
>     if ((len > 0) && (*len < 224)*) {
>       final String msg =
> intres.getLocalizedMessage("catoken.invalidkeylength", "ECDSA", "224",
> Integer.valueOf(len));
>       *throw new InvalidKeyException(msg);*
>     }
>   } ...
> }
>
> But, why is it so?. Are there potentials problems with EC curves with a key
> size smaller than 224 bits?.
>
> PS: I'm a total ignorant of EC cryptography.
>
>
>
> _______________________________________________
> Ejbca-develop mailing lis...@li...://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
>
> --
> Andreas Kühne
> phone: +49 177 293 24 97
> mailto: ku...@tr...
>
> Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612
>
> Director Andreas Kühne
>
> Company UK Company No: 5218868 Registered in England and Wales
>
> _______________________________________________
> Ejbca-develop mailing lis...@li...://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
>
>
> _______________________________________________
> Ejbca-develop mailing lis...@li...://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
>
> --
> Andreas Kühne
> phone: +49 177 293 24 97
> mailto: ku...@tr...
>
> Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612
>
> Director Andreas Kühne
>
> Company UK Company No: 5218868 Registered in England and Wales
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>


-- 
Jaime Hablutzel -  RPC 994690880

Re: [Ejbca-develop] Why ECDSA keys require a minimum size of 224 bits for Crypto Token key pair generation?

[Andreas K. <ku...@tr...>]

Hi Jaime,

an unclear reasoning and origin is a good starting point for conspiracy
theories! ;-)

The code snippet seems to implement a DIY approach to decide on
algorithm suitability. A more standardized approach is given in

Data Structure for the Security Suitability of Cryptographic Algorithms
(DSSC)
https://tools.ietf.org/html/rfc5698

This could be a good base for a catalog  of supported algorithm.  A
quick search did not reveal any ready-made implementations but I would
guess a given standard is better than re-inventing a wheel.

Greetings,

Andreas
> On Sat, Dec 22, 2018 at 1:59 PM Andreas Kuehne <ku...@tr...> wrote:
>
>> Hi Jaime,
>>
>> interesting finding! Due to https://safecurves.cr.yp.to/ there are at
>> least two curves with (slightly) shorter key length. On the other hand the
>> NIST-224 is considered insecure ...
>>
> Thanks for pointing out this resource.
>
>
>> Are there any specific reasons for implementing this restriction?
>>
> I'm asking the same myself. I can trace back that change to the following
> old (5 years ago) commit,
> https://github.com/rgorosito/ejbca/commit/49a8e1c5ff448c3d27c132e46675ed27ef7cb65b#diff-52fc78614bcdfb702e0bf5b66a3ffbfc,
> but the motivation for it is no clear to me at first glance.
>
>
>> Greetings,
>>
>> Andreas
>>
>> In EJBCA 6.10.1.2+, if you create a Crypto Token from the Admin GUI and
>> then you try to generate an EC keypair for it, you find that certain curves
>> are not availabe, e.g. B-163, even when the documentation indicates support
>> for them (seehttps://www.ejbca.org/docs/ECDSA_Keys_and_Signatures.html#src-16224742_id-.ECDSAKeysandSignaturesv6.12.0-Named_curves
>> ).
>>
>> Looking at the source code I can see the cause for it is in the following
>> method, org.cesecore.keys.util.KeyTools#checkValidKeyLength:
>>
>> public static void checkValidKeyLength(final String keyAlg, final int len)
>> throws InvalidKeyException {
>>   ...
>>   if (*isEcdsa *|| isGost3410 || isDstu4145) {
>>     ...
>>     if ((len > 0) && (*len < 224)*) {
>>       final String msg =
>> intres.getLocalizedMessage("catoken.invalidkeylength", "ECDSA", "224",
>> Integer.valueOf(len));
>>       *throw new InvalidKeyException(msg);*
>>     }
>>   } ...
>> }
>>
>> But, why is it so?. Are there potentials problems with EC curves with a key
>> size smaller than 224 bits?.
>>
>> PS: I'm a total ignorant of EC cryptography.
>>
>>
>>
>> _______________________________________________
>> Ejbca-develop mailing lis...@li...://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>
>>
>> --
>> Andreas Kühne
>> phone: +49 177 293 24 97
>> mailto: ku...@tr...
>>
>> Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612
>>
>> Director Andreas Kühne
>>
>> Company UK Company No: 5218868 Registered in England and Wales
>>
>> _______________________________________________
>> 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


-- 
Andreas Kühne 
phone: +49 177 293 24 97 
mailto: ku...@tr...

Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612

Director Andreas Kühne

Company UK Company No: 5218868 Registered in England and Wales 

Re: [Ejbca-develop] Why ECDSA keys require a minimum size of 224 bits for Crypto Token key pair generation?

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

On Sat, Dec 22, 2018 at 1:59 PM Andreas Kuehne <ku...@tr...> wrote:

> Hi Jaime,
>
> interesting finding! Due to https://safecurves.cr.yp.to/ there are at
> least two curves with (slightly) shorter key length. On the other hand the
> NIST-224 is considered insecure ...
>

Thanks for pointing out this resource.


>
> Are there any specific reasons for implementing this restriction?
>

I'm asking the same myself. I can trace back that change to the following
old (5 years ago) commit,
https://github.com/rgorosito/ejbca/commit/49a8e1c5ff448c3d27c132e46675ed27ef7cb65b#diff-52fc78614bcdfb702e0bf5b66a3ffbfc,
but the motivation for it is no clear to me at first glance.


>
> Greetings,
>
> Andreas
>
> In EJBCA 6.10.1.2+, if you create a Crypto Token from the Admin GUI and
> then you try to generate an EC keypair for it, you find that certain curves
> are not availabe, e.g. B-163, even when the documentation indicates support
> for them (seehttps://www.ejbca.org/docs/ECDSA_Keys_and_Signatures.html#src-16224742_id-.ECDSAKeysandSignaturesv6.12.0-Named_curves
> ).
>
> Looking at the source code I can see the cause for it is in the following
> method, org.cesecore.keys.util.KeyTools#checkValidKeyLength:
>
> public static void checkValidKeyLength(final String keyAlg, final int len)
> throws InvalidKeyException {
>   ...
>   if (*isEcdsa *|| isGost3410 || isDstu4145) {
>     ...
>     if ((len > 0) && (*len < 224)*) {
>       final String msg =
> intres.getLocalizedMessage("catoken.invalidkeylength", "ECDSA", "224",
> Integer.valueOf(len));
>       *throw new InvalidKeyException(msg);*
>     }
>   } ...
> }
>
> But, why is it so?. Are there potentials problems with EC curves with a key
> size smaller than 224 bits?.
>
> PS: I'm a total ignorant of EC cryptography.
>
>
>
> _______________________________________________
> Ejbca-develop mailing lis...@li...://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
>
> --
> Andreas Kühne
> phone: +49 177 293 24 97
> mailto: ku...@tr...
>
> Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612
>
> Director Andreas Kühne
>
> Company UK Company No: 5218868 Registered in England and Wales
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>


-- 
Jaime Hablutzel -  RPC 994690880

Re: [Ejbca-develop] Why ECDSA keys require a minimum size of 224 bits for Crypto Token key pair generation?

[Andreas K. <ku...@tr...>]

Hi Jaime,

interesting finding! Due to https://safecurves.cr.yp.to/ there are at
least two curves with (slightly) shorter key length. On the other hand
the NIST-224 is considered insecure ...

Are there any specific reasons for implementing this restriction?

Greetings,

Andreas
> In EJBCA 6.10.1.2+, if you create a Crypto Token from the Admin GUI and
> then you try to generate an EC keypair for it, you find that certain curves
> are not availabe, e.g. B-163, even when the documentation indicates support
> for them (see
> https://www.ejbca.org/docs/ECDSA_Keys_and_Signatures.html#src-16224742_id-.ECDSAKeysandSignaturesv6.12.0-Named_curves
> ).
>
> Looking at the source code I can see the cause for it is in the following
> method, org.cesecore.keys.util.KeyTools#checkValidKeyLength:
>
> public static void checkValidKeyLength(final String keyAlg, final int len)
> throws InvalidKeyException {
>   ...
>   if (*isEcdsa *|| isGost3410 || isDstu4145) {
>     ...
>     if ((len > 0) && (*len < 224)*) {
>       final String msg =
> intres.getLocalizedMessage("catoken.invalidkeylength", "ECDSA", "224",
> Integer.valueOf(len));
>       *throw new InvalidKeyException(msg);*
>     }
>   } ...
> }
>
> But, why is it so?. Are there potentials problems with EC curves with a key
> size smaller than 224 bits?.
>
> PS: I'm a total ignorant of EC cryptography.
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop


-- 
Andreas Kühne 
phone: +49 177 293 24 97 
mailto: ku...@tr...

Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612

Director Andreas Kühne

Company UK Company No: 5218868 Registered in England and Wales 

[Ejbca-develop] Why ECDSA keys require a minimum size of 224 bits for Crypto Token key pair generation?

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

In EJBCA 6.10.1.2+, if you create a Crypto Token from the Admin GUI and
then you try to generate an EC keypair for it, you find that certain curves
are not availabe, e.g. B-163, even when the documentation indicates support
for them (see
https://www.ejbca.org/docs/ECDSA_Keys_and_Signatures.html#src-16224742_id-.ECDSAKeysandSignaturesv6.12.0-Named_curves
).

Looking at the source code I can see the cause for it is in the following
method, org.cesecore.keys.util.KeyTools#checkValidKeyLength:

public static void checkValidKeyLength(final String keyAlg, final int len)
throws InvalidKeyException {
  ...
  if (*isEcdsa *|| isGost3410 || isDstu4145) {
    ...
    if ((len > 0) && (*len < 224)*) {
      final String msg =
intres.getLocalizedMessage("catoken.invalidkeylength", "ECDSA", "224",
Integer.valueOf(len));
      *throw new InvalidKeyException(msg);*
    }
  } ...
}

But, why is it so?. Are there potentials problems with EC curves with a key
size smaller than 224 bits?.

PS: I'm a total ignorant of EC cryptography.
-- 
Jaime Hablutzel -  RPC 994690880

Re: [Ejbca-develop] Subversion repository unavailable

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

Is there an approximate date to have the SVN repository publicly available
again?.

On Wed, Nov 21, 2018 at 1:57 AM Tomas Gustavsson <to...@pr...> wrote:

>
> Yes it is in maintenance since a server move. It's only accessible
> internally right now.
>
> /Tomas
>
> On 2018-11-21 01:08, Jaime Hablutzel wrote:
> > Is SVN repository under maintenance?.
> >
> > I'm getting an ERR_CONNECTION_TIMED_OUT trying to connect to
> > https://svn.cesecore.eu/svn/ejbca/trunk/ejbca/.
> >
> > --
> > 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
>


-- 
Jaime Hablutzel -  RPC 994690880

[Ejbca-develop] Merry Christmas and new year containers

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

Hi,

The EJBCA Team would like to wish everyone a merry Christmas and happy
new year. We are closing 2018 and looking forward to a new great PKI
year 2019.

The coming two weeks are expected to be quiet, but we have been working
hard the last year. Some of the ground work done will make it easier to
bring cool things next year.

You may have noticed EJBCA Enterprise being launched in AWS, which is so
far the absolutely easiest way to launch a CA, for testing or for
production. See the info on http://www.ejbca.org/.

We're not forgetting the Community though. Due to babies being delivered
the end of this year some deliverables have been a bit postponed, but
there are great plans for 2019...think containers...backed by a complete
CI pipe-line built for continuous delivery.
If you search closely you may find a sneak preview, from the official
source, on a Hub near you.

Merry Christmas from the EJBCA Team.

/Tomas

[Ejbca-develop] Updated ejbca-setup

[Christian F. <pu...@fe...>]

Hello,

there is a new branch for ejbca-setup with some bug fixes and a new
feature: It supports now Postgresql. See branch "development" at
https://github.com/ip6li/ejbca-setup

Cheers
Christian

Re: [Ejbca-develop] OCSP Key Binding is always expecting KU extension for OCSP signer certificate

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

I created this issue and fixed it:
https://jira.primekey.se/browse/ECA-7547

Thanks for the report.

Used your simple fix in OcspKeyBinding.java

            if (x509Certificate.getKeyUsage() != null &&
!x509Certificate.getKeyUsage()[0] && !x509Certificate.getKeyUsage()[1] ) {
                throw new CertificateImportException("Key Usage
digitalSignature is required (nonRepudiation would also be accepted).");
            }


Regards,
Tomas

On 2018-11-21 01:28, Jaime Hablutzel wrote:
> In EJBCA 6.10.1.2, if you try to configure an OCSP Key Binding with an
> OCSP signer certificate without the KU extension, it fails like this:
> 
> *Caused by: java.lang.NullPointerException
>         at
> org.cesecore.keybind.impl.OcspKeyBinding.assertCertificateCompatabilityInternal(OcspKeyBinding.java:234)*
>         at
> org.cesecore.keybind.impl.OcspKeyBinding.assertCertificateCompatability(OcspKeyBinding.java:117)
>         at
> org.cesecore.keybind.InternalKeyBindingMgmtSessionBean.assertCertificateIsOkToImport(InternalKeyBindingMgmtSessionBean.java:912)
>         at
> org.cesecore.keybind.InternalKeyBindingMgmtSessionBean.importCertificateForInternalKeyBinding(InternalKeyBindingMgmtSessionBean.java:768)
> 
> Because of the following highlighted code:
> 
> private static void assertCertificateCompatabilityInternal(final
> Certificate certificate, AvailableExtendedKeyUsagesConfiguration
> ekuConfig) throws CertificateImportException {
> ...
>         if (!*x509Certificate.getKeyUsage()[0]* &&
> !x509Certificate.getKeyUsage()[1] ) {
>             throw new CertificateImportException("Key Usage
> digitalSignature is required (nonRepudiation would also be accepted).");
>         }
> ...
> }
> 
> But PKIX profile doesn't require this extension for OCSP signer
> certificates, only for CA and CRL signers. From RFC 5280, "4.2.1.3.  Key
> Usage":
> 
>      Conforming CAs *MUST include this extension in certificates* that
>        contain public keys that are used *to validate digital signatures on
>        other public key certificates or CRLs*.
> 
> 
> In the other hand, RFC 6960, doesn't say anything about the KU extension.
> 
> So the previous code should maybe change to something like:
> 
> if (*x509Certificate.getKeyUsage() != null* &&
> !x509Certificate.getKeyUsage()[0] && !x509Certificate.getKeyUsage()[1]) {
>     throw new CertificateImportException("Key Usage digitalSignature is
> required (nonRepudiation would also be accepted).");
> }
> 
> PS: I've been unable to check if this behavior continue in the current
> SVN trunk version because SVN repository seems to be down.
> 
> -- 
> Jaime Hablutzel -  RPC 994690880
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

Re: [Ejbca-develop] OCSP Key Binding is always expecting KU extension for OCSP signer certificate

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

I actually don't know if there are clients requiring this extension, sorry,
but if there are, (according to the previously mentioned standards) they
would be at fault.

Anyway, I think that EJBCA should not demand for the KU in the OCSP signer
certificate when trying to setup a OCSP Key Binding to be standards
compliant and if there is any CA operator expecting the usage of a client
that does require this extension, they could always install a certificate
that includes it.

On Wed, Nov 21, 2018 at 2:03 AM Tomas Gustavsson <to...@pr...> wrote:

> Good notice.
>
> We know from before that some client (browsers?) used to require the use
> of digitalSignature keyUsage. Cna you confirm that this is not required
> by the clients?
>
> Regards,
> Tomas
> ---
> PrimeKey Solutions AB
> Solna Access Plan A8,
> Sundbybergsvägen 1, 171 63 Solna, Sweden
> Mob: +46 (0)707421096
> Internet: https://www.primekey.se/
> Twitter: twitter.com/primekeyPKI
>
> On 2018-11-21 01:28, Jaime Hablutzel wrote:
> > In EJBCA 6.10.1.2, if you try to configure an OCSP Key Binding with an
> > OCSP signer certificate without the KU extension, it fails like this:
> >
> > *Caused by: java.lang.NullPointerException
> >         at
> >
> org.cesecore.keybind.impl.OcspKeyBinding.assertCertificateCompatabilityInternal(OcspKeyBinding.java:234)*
> >         at
> >
> org.cesecore.keybind.impl.OcspKeyBinding.assertCertificateCompatability(OcspKeyBinding.java:117)
> >         at
> >
> org.cesecore.keybind.InternalKeyBindingMgmtSessionBean.assertCertificateIsOkToImport(InternalKeyBindingMgmtSessionBean.java:912)
> >         at
> >
> org.cesecore.keybind.InternalKeyBindingMgmtSessionBean.importCertificateForInternalKeyBinding(InternalKeyBindingMgmtSessionBean.java:768)
> >
> > Because of the following highlighted code:
> >
> > private static void assertCertificateCompatabilityInternal(final
> > Certificate certificate, AvailableExtendedKeyUsagesConfiguration
> > ekuConfig) throws CertificateImportException {
> > ...
> >         if (!*x509Certificate.getKeyUsage()[0]* &&
> > !x509Certificate.getKeyUsage()[1] ) {
> >             throw new CertificateImportException("Key Usage
> > digitalSignature is required (nonRepudiation would also be accepted).");
> >         }
> > ...
> > }
> >
> > But PKIX profile doesn't require this extension for OCSP signer
> > certificates, only for CA and CRL signers. From RFC 5280, "4.2.1.3.  Key
> > Usage":
> >
> >      Conforming CAs *MUST include this extension in certificates* that
> >        contain public keys that are used *to validate digital signatures
> on
> >        other public key certificates or CRLs*.
> >
> >
> > In the other hand, RFC 6960, doesn't say anything about the KU extension.
> >
> > So the previous code should maybe change to something like:
> >
> > if (*x509Certificate.getKeyUsage() != null* &&
> > !x509Certificate.getKeyUsage()[0] && !x509Certificate.getKeyUsage()[1]) {
> >     throw new CertificateImportException("Key Usage digitalSignature is
> > required (nonRepudiation would also be accepted).");
> > }
> >
> > PS: I've been unable to check if this behavior continue in the current
> > SVN trunk version because SVN repository seems to be down.
> >
> > --
> > 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
>


-- 
Jaime Hablutzel -  RPC 994690880

Re: [Ejbca-develop] OCSP Key Binding is always expecting KU extension for OCSP signer certificate

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

Good notice.

We know from before that some client (browsers?) used to require the use
of digitalSignature keyUsage. Cna you confirm that this is not required
by the clients?

Regards,
Tomas
---
PrimeKey Solutions AB
Solna Access Plan A8,
Sundbybergsvägen 1, 171 63 Solna, Sweden
Mob: +46 (0)707421096
Internet: https://www.primekey.se/
Twitter: twitter.com/primekeyPKI

On 2018-11-21 01:28, Jaime Hablutzel wrote:
> In EJBCA 6.10.1.2, if you try to configure an OCSP Key Binding with an
> OCSP signer certificate without the KU extension, it fails like this:
> 
> *Caused by: java.lang.NullPointerException
>         at
> org.cesecore.keybind.impl.OcspKeyBinding.assertCertificateCompatabilityInternal(OcspKeyBinding.java:234)*
>         at
> org.cesecore.keybind.impl.OcspKeyBinding.assertCertificateCompatability(OcspKeyBinding.java:117)
>         at
> org.cesecore.keybind.InternalKeyBindingMgmtSessionBean.assertCertificateIsOkToImport(InternalKeyBindingMgmtSessionBean.java:912)
>         at
> org.cesecore.keybind.InternalKeyBindingMgmtSessionBean.importCertificateForInternalKeyBinding(InternalKeyBindingMgmtSessionBean.java:768)
> 
> Because of the following highlighted code:
> 
> private static void assertCertificateCompatabilityInternal(final
> Certificate certificate, AvailableExtendedKeyUsagesConfiguration
> ekuConfig) throws CertificateImportException {
> ...
>         if (!*x509Certificate.getKeyUsage()[0]* &&
> !x509Certificate.getKeyUsage()[1] ) {
>             throw new CertificateImportException("Key Usage
> digitalSignature is required (nonRepudiation would also be accepted).");
>         }
> ...
> }
> 
> But PKIX profile doesn't require this extension for OCSP signer
> certificates, only for CA and CRL signers. From RFC 5280, "4.2.1.3.  Key
> Usage":
> 
>      Conforming CAs *MUST include this extension in certificates* that
>        contain public keys that are used *to validate digital signatures on
>        other public key certificates or CRLs*.
> 
> 
> In the other hand, RFC 6960, doesn't say anything about the KU extension.
> 
> So the previous code should maybe change to something like:
> 
> if (*x509Certificate.getKeyUsage() != null* &&
> !x509Certificate.getKeyUsage()[0] && !x509Certificate.getKeyUsage()[1]) {
>     throw new CertificateImportException("Key Usage digitalSignature is
> required (nonRepudiation would also be accepted).");
> }
> 
> PS: I've been unable to check if this behavior continue in the current
> SVN trunk version because SVN repository seems to be down.
> 
> -- 
> Jaime Hablutzel -  RPC 994690880
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

Re: [Ejbca-develop] Subversion repository unavailable

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

Yes it is in maintenance since a server move. It's only accessible
internally right now.

/Tomas

On 2018-11-21 01:08, Jaime Hablutzel wrote:
> Is SVN repository under maintenance?. 
> 
> I'm getting an ERR_CONNECTION_TIMED_OUT trying to connect to
> https://svn.cesecore.eu/svn/ejbca/trunk/ejbca/.
> 
> -- 
> Jaime Hablutzel -  RPC 994690880
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

[Ejbca-develop] OCSP Key Binding is always expecting KU extension for OCSP signer certificate

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

In EJBCA 6.10.1.2, if you try to configure an OCSP Key Binding with an OCSP
signer certificate without the KU extension, it fails like this:


*Caused by: java.lang.NullPointerException        at
org.cesecore.keybind.impl.OcspKeyBinding.assertCertificateCompatabilityInternal(OcspKeyBinding.java:234)*
        at
org.cesecore.keybind.impl.OcspKeyBinding.assertCertificateCompatability(OcspKeyBinding.java:117)
        at
org.cesecore.keybind.InternalKeyBindingMgmtSessionBean.assertCertificateIsOkToImport(InternalKeyBindingMgmtSessionBean.java:912)
        at
org.cesecore.keybind.InternalKeyBindingMgmtSessionBean.importCertificateForInternalKeyBinding(InternalKeyBindingMgmtSessionBean.java:768)

Because of the following highlighted code:

private static void assertCertificateCompatabilityInternal(final
Certificate certificate, AvailableExtendedKeyUsagesConfiguration ekuConfig)
throws CertificateImportException {
...
        if (!*x509Certificate.getKeyUsage()[0]* &&
!x509Certificate.getKeyUsage()[1] ) {
            throw new CertificateImportException("Key Usage
digitalSignature is required (nonRepudiation would also be accepted).");
        }
...
}

But PKIX profile doesn't require this extension for OCSP signer
certificates, only for CA and CRL signers. From RFC 5280, "4.2.1.3.  Key
Usage":

 Conforming CAs *MUST include this extension in certificates* that
>    contain public keys that are used
> *to validate digital signatures on   other public key certificates or CRLs*
> .


In the other hand, RFC 6960, doesn't say anything about the KU extension.

So the previous code should maybe change to something like:

if (*x509Certificate.getKeyUsage() != null* &&
!x509Certificate.getKeyUsage()[0] && !x509Certificate.getKeyUsage()[1]) {
    throw new CertificateImportException("Key Usage digitalSignature is
required (nonRepudiation would also be accepted).");
}

PS: I've been unable to check if this behavior continue in the current SVN
trunk version because SVN repository seems to be down.

-- 
Jaime Hablutzel -  RPC 994690880

[Ejbca-develop] Subversion repository unavailable

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

Is SVN repository under maintenance?.

I'm getting an ERR_CONNECTION_TIMED_OUT trying to connect to
https://svn.cesecore.eu/svn/ejbca/trunk/ejbca/.

-- 
Jaime Hablutzel -  RPC 994690880

Re: [Ejbca-develop] Publisher on CA vs Certificate Profile

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

On 2018-11-17 17:11, Jaime Hablutzel wrote:
> 
> 
> On Thu, Nov 15, 2018 at 2:09 AM Tomas Gustavsson <to...@pr...
> <mailto:to...@pr...>> wrote:
> 
> 
>     Hi,
> 
>     The publisher setting in the CA only publishes CA certificates and CRLs.
>     To public end entity certificates, configuring publishers in the
>     certificate profiles is needed.
> 
> 
> The previous means that certificates issued with the default ENDUSER
> certificate profile won't ever be published, right?.

That is correct. Unless you modify the database to switch EE profile for
those certificates. It's just a column in the DB.

>  
> 
> 
>     Regards,
>     Tomas
> 
>     On 2018-11-14 21:44, Willi Trace wrote:
>     > Hello all,
>     >
>     > What’s the difference in adding publisher on CA or Certificate
>     Profile?
>     > What is the behaviour of publisher in both cases?
>     >
>     > I expected that adding publisher to CA will publish issued
>     certificates,
>     > CRL, and revocations for all certificates issued by that CA, and
>     adding
>     > to Certificate Profile will publish issued certificates and revocation
>     > only by that particular Certificate Profile.
>     >
>     > However when I add publisher to CA, only CRLs are publisher altough I
>     > have configured publisher also for issued certificates and
>     revocations.
>     > Is it correct?
>     > How to configure publisher for CA to publish all certificates, not
>     only
>     > CRLs.
>     >
>     > I am using General Purpose Custom Publisher.
>     >
>     > WT
>     >
>     >
>     > _______________________________________________
>     > 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
> 
> 
> 
> -- 
> Jaime Hablutzel -  RPC 994690880
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

Re: [Ejbca-develop] Publisher on CA vs Certificate Profile

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

On Thu, Nov 15, 2018 at 2:09 AM Tomas Gustavsson <to...@pr...> wrote:

>
> Hi,
>
> The publisher setting in the CA only publishes CA certificates and CRLs.
> To public end entity certificates, configuring publishers in the
> certificate profiles is needed.
>

The previous means that certificates issued with the default ENDUSER
certificate profile won't ever be published, right?.


>
> Regards,
> Tomas
>
> On 2018-11-14 21:44, Willi Trace wrote:
> > Hello all,
> >
> > What’s the difference in adding publisher on CA or Certificate Profile?
> > What is the behaviour of publisher in both cases?
> >
> > I expected that adding publisher to CA will publish issued certificates,
> > CRL, and revocations for all certificates issued by that CA, and adding
> > to Certificate Profile will publish issued certificates and revocation
> > only by that particular Certificate Profile.
> >
> > However when I add publisher to CA, only CRLs are publisher altough I
> > have configured publisher also for issued certificates and revocations.
> > Is it correct?
> > How to configure publisher for CA to publish all certificates, not only
> > CRLs.
> >
> > I am using General Purpose Custom Publisher.
> >
> > WT
> >
> >
> > _______________________________________________
> > 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] Publisher on CA vs Certificate Profile

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

Hi,

The publisher setting in the CA only publishes CA certificates and CRLs.
To public end entity certificates, configuring publishers in the
certificate profiles is needed.

Regards,
Tomas

On 2018-11-14 21:44, Willi Trace wrote:
> Hello all,
> 
> What’s the difference in adding publisher on CA or Certificate Profile?
> What is the behaviour of publisher in both cases?
> 
> I expected that adding publisher to CA will publish issued certificates,
> CRL, and revocations for all certificates issued by that CA, and adding
> to Certificate Profile will publish issued certificates and revocation
> only by that particular Certificate Profile.
> 
> However when I add publisher to CA, only CRLs are publisher altough I
> have configured publisher also for issued certificates and revocations.
> Is it correct?
> How to configure publisher for CA to publish all certificates, not only
> CRLs.
> 
> I am using General Purpose Custom Publisher.
> 
> WT
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 

[Ejbca-develop] Publisher on CA vs Certificate Profile

[Willi T. <wil...@gm...>]

Hello all,

What’s the difference in adding publisher on CA or Certificate Profile?
What is the behaviour of publisher in both cases?

I expected that adding publisher to CA will publish issued certificates,
CRL, and revocations for all certificates issued by that CA, and adding to
Certificate Profile will publish issued certificates and revocation only by
that particular Certificate Profile.

However when I add publisher to CA, only CRLs are publisher altough I have
configured publisher also for issued certificates and revocations. Is it
correct?
How to configure publisher for CA to publish all certificates, not only
CRLs.

I am using General Purpose Custom Publisher.

WT

Re: [Ejbca-develop] Blockchain as a new protection mechanism for Database Integrity Protection

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

Just sayin' :-)

"...for every use of blockchain that you would consider today there is a
better technology"

https://www.innovationaus.com/2018/10/DTA-goes-cold-on-blockchain

Using merkle trees as a technology may have some interesting aspects
though.

Cheers,
Tomas

On 2018-11-01 22:00, Jaime Hablutzel wrote:
> On Fri, Oct 26, 2018, 11:34 AM Andreas Kuehne <ku...@tr...
> <mailto:ku...@tr...> wrote:
> 
>     Yes, a timestamp will do, or an Evidence Record (Merkle Tree +
>     Timestamp).
> 
>     Compared with BlockChain the responsiveness is likely the same and
>     there is
>     no need to run an additional power plant to perform useless PoW
>     computations.
> 
>     Another question always nagging me:
>     In non-monetary scenarios why should a significant number of parties,
>     unrelated to the given CA, perform the mining? What could be their
>     payback?
> 
> 
> Not 100% if this is a valid example, but what about digital certificates
> to be used for authentication/signature in inter-corporation processes
> where the CA  is a third party to all of them?. 
> 
> 
> 
>     Greetings,
> 
>     Andreas
> 
>     -----Ursprüngliche Nachricht-----
>     Von: Manuel Dejonghe [mailto:ma...@de...
>     <mailto:ma...@de...>]
>     Gesendet: Freitag, 26. Oktober 2018 07:32
>     An: ejbca-develop <ejb...@li...
>     <mailto:ejb...@li...>>
>     Betreff: Re: [Ejbca-develop] Blockchain as a new protection
>     mechanism for
>     Database Integrity Protection
> 
>     Hi,
>     I think CT Logs fulfill pretty exactly those requirements, and they
>     do store
>     their info in Merkle Trees, so you're pretty close here.
> 
>     cheers,
>     Manuel
>     On Thu, 25 Oct 2018 at 19:32, Jaime Hablutzel <hab...@gm...
>     <mailto:hab...@gm...>> wrote:
>     >
>     > Just a quick idea right now, but, what do you think of protecting
>     EJBCA
>     records with blockchain transactions?. This way, records in EJBCA
>     would be
>     verifiable with a distributed ledger and this could help to prove the
>     authenticity of certain data even to third parties (e.g.
>     government), for
>     example, the exact time when a certificate got revoked in the past.
>     >
>     > I think that this could be implemented just as a new protection
>     version
>     for Database Integrity Protection
>     (https://www.ejbca.org/docs/EJBCA_Security.html#src-23855405_id-.EJBCASecuri
>     tyv6.15.0-DatabaseIntegrityProtection).
>     >
>     > What do you think?.
>     >
>     > --
>     > 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...
>     <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] Blockchain as a new protection mechanism for Database Integrity Protection

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

On Fri, Oct 26, 2018, 11:34 AM Andreas Kuehne <ku...@tr... wrote:

> Yes, a timestamp will do, or an Evidence Record (Merkle Tree + Timestamp).
>
> Compared with BlockChain the responsiveness is likely the same and there is
> no need to run an additional power plant to perform useless PoW
> computations.
>
> Another question always nagging me:
> In non-monetary scenarios why should a significant number of parties,
> unrelated to the given CA, perform the mining? What could be their payback?
>

Not 100% if this is a valid example, but what about digital certificates to
be used for authentication/signature in inter-corporation processes where
the CA  is a third party to all of them?.


>
> Greetings,
>
> Andreas
>
> -----Ursprüngliche Nachricht-----
> Von: Manuel Dejonghe [mailto:ma...@de...]
> Gesendet: Freitag, 26. Oktober 2018 07:32
> An: ejbca-develop <ejb...@li...>
> Betreff: Re: [Ejbca-develop] Blockchain as a new protection mechanism for
> Database Integrity Protection
>
> Hi,
> I think CT Logs fulfill pretty exactly those requirements, and they do
> store
> their info in Merkle Trees, so you're pretty close here.
>
> cheers,
> Manuel
> On Thu, 25 Oct 2018 at 19:32, Jaime Hablutzel <hab...@gm...>
> wrote:
> >
> > Just a quick idea right now, but, what do you think of protecting EJBCA
> records with blockchain transactions?. This way, records in EJBCA would be
> verifiable with a distributed ledger and this could help to prove the
> authenticity of certain data even to third parties (e.g. government), for
> example, the exact time when a certificate got revoked in the past.
> >
> > I think that this could be implemented just as a new protection version
> for Database Integrity Protection
> (
> https://www.ejbca.org/docs/EJBCA_Security.html#src-23855405_id-.EJBCASecuri
> tyv6.15.0-DatabaseIntegrityProtection).
> >
> > What do you think?.
> >
> > --
> > 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
>
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

Re: [Ejbca-develop] Blockchain as a new protection mechanism for Database Integrity Protection

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

Hi Manuel, CT Logs would fulfill the requirement to monitor certificate
issuance but not certificate revocation history as well.

For example, if a CA revoked a certificate in the past and needs to prove
to third parties (e.g. government) the exact time and details of that
revocation event, if the update for revocation to its own CertificateData
table would be protected with the Database Integrity Protection mechanism
using a blockchain transaction, the CA could verify the details of this
event to the requesting third parties.

On Fri, Oct 26, 2018 at 12:33 AM Manuel Dejonghe <ma...@de...> wrote:

> Hi,
> I think CT Logs fulfill pretty exactly those requirements, and they do
> store their info in Merkle Trees, so you're pretty close here.
>
> cheers,
> Manuel
> On Thu, 25 Oct 2018 at 19:32, Jaime Hablutzel <hab...@gm...>
> wrote:
> >
> > Just a quick idea right now, but, what do you think of protecting EJBCA
> records with blockchain transactions?. This way, records in EJBCA would be
> verifiable with a distributed ledger and this could help to prove the
> authenticity of certain data even to third parties (e.g. government), for
> example, the exact time when a certificate got revoked in the past.
> >
> > I think that this could be implemented just as a new protection version
> for Database Integrity Protection (
> https://www.ejbca.org/docs/EJBCA_Security.html#src-23855405_id-.EJBCASecurityv6.15.0-DatabaseIntegrityProtection
> ).
> >
> > What do you think?.
> >
> > --
> > 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
>


-- 
Jaime Hablutzel -  RPC 994690880

Re: [Ejbca-develop] Blockchain as a new protection mechanism for Database Integrity Protection

[Andreas K. <ku...@tr...>]

Yes, a timestamp will do, or an Evidence Record (Merkle Tree + Timestamp).

Compared with BlockChain the responsiveness is likely the same and there is
no need to run an additional power plant to perform useless PoW
computations.

Another question always nagging me:
In non-monetary scenarios why should a significant number of parties,
unrelated to the given CA, perform the mining? What could be their payback?


Greetings,

Andreas

-----Ursprüngliche Nachricht-----
Von: Manuel Dejonghe [mailto:ma...@de...] 
Gesendet: Freitag, 26. Oktober 2018 07:32
An: ejbca-develop <ejb...@li...>
Betreff: Re: [Ejbca-develop] Blockchain as a new protection mechanism for
Database Integrity Protection

Hi,
I think CT Logs fulfill pretty exactly those requirements, and they do store
their info in Merkle Trees, so you're pretty close here.

cheers,
Manuel
On Thu, 25 Oct 2018 at 19:32, Jaime Hablutzel <hab...@gm...> wrote:
>
> Just a quick idea right now, but, what do you think of protecting EJBCA
records with blockchain transactions?. This way, records in EJBCA would be
verifiable with a distributed ledger and this could help to prove the
authenticity of certain data even to third parties (e.g. government), for
example, the exact time when a certificate got revoked in the past.
>
> I think that this could be implemented just as a new protection version
for Database Integrity Protection
(https://www.ejbca.org/docs/EJBCA_Security.html#src-23855405_id-.EJBCASecuri
tyv6.15.0-DatabaseIntegrityProtection).
>
> What do you think?.
>
> --
> 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] Blockchain as a new protection mechanism for Database Integrity Protection

[Manuel D. <ma...@de...>]

Hi,
I think CT Logs fulfill pretty exactly those requirements, and they do
store their info in Merkle Trees, so you're pretty close here.

cheers,
Manuel
On Thu, 25 Oct 2018 at 19:32, Jaime Hablutzel <hab...@gm...> wrote:
>
> Just a quick idea right now, but, what do you think of protecting EJBCA records with blockchain transactions?. This way, records in EJBCA would be verifiable with a distributed ledger and this could help to prove the authenticity of certain data even to third parties (e.g. government), for example, the exact time when a certificate got revoked in the past.
>
> I think that this could be implemented just as a new protection version for Database Integrity Protection (https://www.ejbca.org/docs/EJBCA_Security.html#src-23855405_id-.EJBCASecurityv6.15.0-DatabaseIntegrityProtection).
>
> What do you think?.
>
> --
> Jaime Hablutzel -  RPC 994690880
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop

Re: [Ejbca-develop] Blockchain as a new protection mechanism for Database Integrity Protection

[Andreas K. <ku...@tr...>]

Hi Jaime,

that's hip, but I'm not eager to apply the most resource consuming
technology available. Let me cite the Australia's Digital Transformation
Agency:

" ... for every use of blockchain you would consider today, there is a
better technology ..."

https://www.zdnet.com/article/dta-dunks-on-blockchain-hype-saying-for-every-use-there-is-a-better-alternative/


Greetings,

Andreas
> Just a quick idea right now, but, what do you think of protecting EJBCA
> records with blockchain transactions?. This way, records in EJBCA would be
> verifiable with a distributed ledger and this could help to prove the
> authenticity of certain data even to third parties (e.g. government), for
> example, the exact time when a certificate got revoked in the past.
>
> I think that this could be implemented just as a new protection version for
> Database Integrity Protection (
> https://www.ejbca.org/docs/EJBCA_Security.html#src-23855405_id-.EJBCASecurityv6.15.0-DatabaseIntegrityProtection
> ).
>
> What do you think?.
>
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop


-- 
Andreas Kühne 
phone: +49 177 293 24 97 
mailto: ku...@tr...

Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612

Director Andreas Kühne

Company UK Company No: 5218868 Registered in England and Wales