JGridstart/Bouncycastle and Java Web start

BouncyCastle is a cryptographic library for Java that complements the default Java Cryptography Extension. To use it as a provider (e.g. to access a KeyStore that is supported by BouncyCastle), one has to use the JAR file provided by them because that is signed by Sun (because of countries' security policies). When creating a Java Web Start application, both the application and the BouncyCastle JAR need to be included. This page explains how this can be done.

There is a number of ways in which Bouncycastle and Java Web Start can be combined. I have found no solution yet that is satisfying in all cases (platforms, JRE versions and configurations).

1. Using the Java Cryptography Extension with Bouncycastle
   1. All JARs in a single JNLP (requires signing the Bouncycastle JAR twice)
   2. Putting the Bouncycastle JAR in an extension JNLP
      1. Keep Bouncycastle JAR signed with just the JCE certificate (extra security dialog for user)
      2. Sign Bouncycastle JAR additionally with the application's certificate
2. Using Bouncycastle's leightweight API, bypassing the JCE (different API, no signing problems)

Option 1.1 suffers from Java bug #6598556 on JRE 1.6.0 until 1.6.0_13. Option 1.2.1 shows an extra security dialog to the user, which is confusing. Option 1.2.2 only seems to work when the publisher's certificate is stored as an accepted certificate in some cases (on by default on Linux and Windows for commercial certificates, off by default on Mac OS X; seen on JRE 1.6.0_26).

Option 2 is a lot of migration work when the application is written to use the standard Java Cryptography API.

Using a BouncyCastle JNLP extension

the way to do this is by referencing to a bouncycastle JNLP file using the extension tag. For example the file app.jnlp:

<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+" href="app.jnlp" codebase="http://somewhere/">
  <information>
    <title>App</title>
    <vendor>Nikhef</vendor>
    <homepage href="http://somewhere/"/>
  </information>
  <security>
    <all-permissions/>
  </security>
  <resources>
   <j2se href="http://java.sun.com/products/autodl/j2se" version="1.5+"/>
   <jar href="app.jar"/>
   <extension name="BouncyCastle cryptography library" href="bcprov-jdk15.jnlp"/>
  </resources>
  <application-desc main-class="app.Main"/>
 </jnlp>

References the file bcprov-jdk15.jnlp which describes the BouncyCastle extension. This can not be put in the application's JNLP because all JARs in a single JNLP file need to be signed by the same key. The file bcprov-jdk15.jnlp can contain:

 <?xml version="1.0" encoding="UTF-8"?>
 <jnlp spec="1.0+" codebase="http://somewhere/" href="bcprov-jdk15.jnlp">
  <information>
   <title>bcprov-jdk15</title>
   <vendor>Sun Microsystems, Inc.</vendor>
   <offline-allowed/>
  </information>
  <security>
    <all-permissions/>
  </security>
  <resources>
   <jar href="bcprov-jdk15-146.jar"/>
  </resources>
  <component-desc/>
 </jnlp>

You see that this file also has the all-permissions tag in the security section. This is to allow the file to register itself as a cryptography provider.

Now when the Java Web Start application is run, the user has to accept a warning dialog twice: one for the application itself, and one for the BouncyCastle extension. This is a little troublesome, since the user doesn't care about the extension; if he has just consented to grant the application access why does it ask for it again?

The solution to this issue is to sign the BouncyCastle JAR with the same key as the application JAR; the resulting BouncyCastle JAR will be signed twice: META-INF/BC-KEY.* gives the security permissions to be used as a cryptography provider, and META-INF/<MY-KEY>.* gives the other permissions. Because you use the same key for your application as BouncyCastle, the user only needs to accept it once.

If you don't want to sign the BouncyCastle JAR yourself, it is still possible to workaround the issue, please see Bouncycastle and Java Web Start workaround.