santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Walter Hoehn <>
Subject Re: JuiCE - some ideas and a proposed draft "roadmap"
Date Wed, 09 Nov 2005 15:52:01 GMT
Thought we might move this discussion over the juice-dev....

On Nov 8, 2005, at 1:51 PM, Werner Dittmann wrote:

> while working on some performance improvements for WSS4J I
> implemented a first draft of an openSSL binding for
> BouncyCastle. It proved to give some good results.
> Dims pointed me to the Apache JuiCE project (incubator)
> that has a similar goal - providing a JCE security provider
> that uses openSSL as underlying crypto implementation.
> Well, JuiCE seems to be dormant since about 1 1/2 year. The
> homepage still says the mailing lists need to be created - thus
> I'm sending this info to WSS4J and security-dev to get some
> info and feedback to the proposals/ideas listed below.

Right you are, nothing has been added for a long time.  The mailing  
lists were created and have been used on rare occasion.  I'm quite  
amazed, though, that every few months I hear mention of somebody  
using this code in a production shibboleth deployment.

> After looking at the JuiCE stuff I think we can enhance
> it a bit.
> Ideas, proposed JuiCE functionality:
> ===================================
> Well, IMO JuiCE should concentrate its efforts to bind to
> openSSL libcrypt, use it where it makes sense, and build
> up a small provider for just the algorithms openSSL supports.
> Then we have some quite fast algos at hand. One major
> goal must be to stay JCE compliant and behave as a normal
> JCE provider for some selected alorithms.

Right.  This sort of thing is only useful if you can plug it in just  
like any other JCE implementation.  The early work was focused on  
implementing the specific algorithms that we needed for the  
Shibboleth project.

> Other functions, such as keystore handling, x.509 certificate
> handling (creation and such) should stay with Sun or BC (or
> others) because these are not time critical and it would be
> a waste of time and effort to "reinvent the wheel".


> Because of the lookup mechanisms provided by Cipher
> and other security classes a user may register JuiCE as
> appropriate and use it instead of Sun's or the BC implementation.


> Proposed next steps:
> ====================
> I'll move over the code from my BC testbed (including
> the unit tests) into JuiCE which may take some in-depth
> modifications of existing JuiCE code, directory structure, etc,
> copying and resue some BC code where appropriate (the BC
> license is ok for this).

If you are hoping to actively evolve the code, I'm certain that  
nobody would object to these sorts of changes.  If I remember  
correctly, some amount of care was taken to add gnu autotools  
support.  It would be nice if you built on this.

> There is one missing link: to use JuiCE we need a certificate signed
> by Sun (Sun acting as a certificate authority in this case). There
> is (somewhere in the latest doc about JCE provider)
> a description how to get such a certificate - I can check it
> and provide the necessary info. This certificate must be used to
> sign the JuiCE jar

This is need by some algorithms, but not by all.  I can't remember  
the breakdown, but it would certainly be nice to have the cert...

> IMO it would be great if Apache as an organisation can get
> this necessary certificate. This would enable us to build
> and sign a JCE provider that works with every Sun JVM (I'm not
> familiar how this works out for other JVMs).
> After we got this important first step we can then do some
> further enhancements to exploit the openSSL libcrypt, e.g.
> looking at Diffie-Helman, Elliptic Curve, etc which may take
> some time.
> Btw: I havn't checked it - but who has write access to the JuiCE
> SVN repos? Or can grant write access to it?

I think the committers are:

Walter Hoehn
Noah Levitt
Berin Lautenbach

> Comments? Ideas?

The two main work items that were outstanding when the project was  
last discussed were implementing the openssl threading callbacks and  
investigating the adding of support for openssl-engine.  At the time,  
it seemed that more hardware crypto devices worked (or worked  
reliably) with openssl than with the JCE.


View raw message