« Good reasons for NOT buying my book | Main | Client side single sign-on »

Why is developing JCE Providers so hard?

Don't take me wrong -- I don't mean to say that the JCE API is complex or the logic of providers is difficult to get right. The JCE framework itself is quite simple, in fact same as the JCA. The algorithms implemented by a JCE provider could be complicated, but that is not the point. One could develop a JCE provider by just writing a wrapper over some existing library (like OpenSSL or MS CAPI on Windows).

What makes writing JCE providers is the requirement that it must be signed by a certificate issued by, directly or indirectly, a certification authority with distinguished name of CN=JCE Code Signing CA, OU=Java Software Code Signing, O=Sun Microsystems Inc, L=Palo Alto, ST=CA, C=US. This is checked by the JCE engine that come with J2SE -- it simply refuses to load JCE provider jars that are not signed by an appropriate code signing authority.

As per the JCE documentation, if you are writing a JCE provider then you should make a request to Sun for a code signing certificate. This in itself is not bad. But the caveat is that you must be a vendor to actually get the code signing certificate. This will actually get verified -- making the whole process quite beurocratic and beyond the reach of individual developers. For example, I am interested in trying out my little wrapper over MS-CAPI, but I am not a vendor, and so cannot test my little program!

This was just a little annoyance with J2SE1.4.x, for I had figured out that I could simply remove the jce.jar from jre\lib, and place the opensource Cryptix implementation of JCE engine. This worked fine for all my experimentation. However, with J2SE1.5, the Cryptix JCE jar doesn't work. As I don't see much activity with Cryptix (actually, most of the time the website is down!), not much hope that I will have an updated opensource JCE engine.

And this is happening exactly when it has become somewhat interesting to plug-in my JCE provider to speed-up SSL processing in J2SE1.5 by simple configuration change (JSSE of J2SE1.4 didn't support pluggable crypto providers; JSSE of J2SE1.5 does.). How does Sun expect programmers like me to try out this new exciting feature!

I don't know the rationale of requiring signed JCE providers, but even if we assume that this is needed for some arcane reasons, it is possible to promote experimentation by allowing download of a JCE engine that doesn't require signed JCE provider for testing purposes. This will continue to allow Sun to have the same control over people or organization who distribute their providers, for the users of the JCE provider would still need signed jars.


This page contains a single entry from the blog posted on March 21, 2004 10:58 PM.

The previous post in this blog was Good reasons for NOT buying my book.

The next post in this blog is Client side single sign-on.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33