January 2009

As mentioned before, I’m one of the coauthors for an article that is to be published in the proceedings of Financial Cryptography and Data Security 2009. The article is available here:

Any comment is more than welcome of course!


©2009 Springer. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the publisher, Springer.



One of the things I dislike in the Java world is the number of moving parts I sometimes have to deal with in order to get things going. For instance, as mentioned in my previous post, I often work with XML schemas. To successfully use JAXB, you have to be aware of:

  1. The Java version you’re using (Java SE 6, or 5?)
  2. The version of JAXB (is it 2.0 or 2.1?)
  3. The version of NetBeans (try 7.0 it rocks!)
  4. The OS you’re running all the above on

Depending on the various combination you have, you may need to tune things differently…

For instance the build.xml file contains information that relates to XJC’s location. Up to recently, I was successfully using the following setting on my OS X based machines:

<taskdef name=”xjc” classname=”com.sun.tools.xjc.XJCTask”>

       <fileset dir=”/Applications/NetBeans/NetBeans 6.5M1.app/Contents/Resources/NetBeans/java2/modules/ext/jaxws21″ includes=”**/*.jar”/>

Recently I upgraded to NetBeans 7.0 (which is great btw) and updated accordingly the build.xml for my project so that it matches the new location of jaxws21:

/Applications/NetBeans/NetBeans 7.0M1.app/Contents/Resources/NetBeans/java2/modules/ext/jaxws21

 Unfortunately, I got the following error message when building my project:

taskdef class com.sun.tools.xjc.XJCTask cannot be found


It turns out the proper directory is now:

/Applications/NetBeans/NetBeans 7.0M1.app/Contents/Resources/NetBeans/ide10/modules/ext/jaxb

Why the move to another location? Frankly I’m not sure but I bet it has to do with this. This site (named the unofficial JAXB guide) is a great source of information if you’re working with JAXB.


For most projects I’ve been working on lately, I have had to implement a library or an application starting from an XML schema file. There are several ways to generate Java classes from a schema (this process is called binding a schema to a Java representation). Of course, working at SUN, I naturally started with using JAXB

A key element of this binding process is the compiler that generates those Java classes. In JAXB, this task is dedicated to XJC. In order to call XJC you can either run it from the command line or, even better, invoke it directly from your NetBeans project. To do the latter, you will need to modify or add a few files to your project: the overall build.xml of the project and a catalog.xml and a binding.xml that relates directly to the schema(s) you have to start with.

First, you need to add a new target in your build.xml file to instruct NetBeans to generate the code and where to put those classes:

    <target name=”-pre-compile”>
        <echo message=”Compiling the schemas…”/>
        <mkdir dir=”build/gen-src”/>
        <xjc catalog=”Schemas/catalog.xml” binding=”Schemas/binding.xml” destDir=”build/gen-src”>
            <schema dir=”Schemas/”>
                <include name=”*.xsd”/>
            <produces dir=”build/gen-src/com/sun/myproject” includes=”**/*.java”/>

Don’t forget to explicitly declare where XJC can be found. On my Mac, it would look like:

    <taskdef name=”xjc” classname=”com.sun.tools.xjc.XJCTask”>
            <fileset dir=”/Applications/NetBeans/…/ext/jaxws21″ includes=”**/*.jar”/>

Once this is done, you’ll need to add a catalog.xml file in the schemas directory (or elsewhere). In a nutshell you declare where other resources (like schemas your own schema may depend upon) can be found (e.g. in a local directory or online). An example of such mapping would be:

<?xml version=”1.0″ envoding=”UTF-8″?>
<catalog xmlns=”urn:oasis:names:rc:entity:xmlns:xml:catalog” prefer=”system”>
   <system systemId=”http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd&#8221; uri=”w3-dsig/w3-2002-12-xenc-schema.xsd”/>
   <uri name=”http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd&#8221; uri=”w3-dsig/w3-2002-12-xenc-schema.xsd”/>
   <system systemId=”http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd&#8221; uri=”w3-dsig/w3-2000-09-xmldsig-core-schema.xsd”/>
   <uri name=”http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd&#8221; uri=”w3-dsig/w3-2000-09-xmldsig-core-schema.xsd”/>

You also need, and this is the 3rd file I mentioned, to have a binding.xml file which, among many other things, describes the mapping of the schemas to be compiled with your project structure/hierarchy. For instance, you can say that the Java classes created from the schema w3-2000-09-xmldsig-core-schema.xsd should be packaged as org.w3.xmldsig. An example of such file is below:

<jxb:bindings version=”2.1″

    <jxb:bindings schemaLocation=”rest-ds.xsd” node=”//xs:schema”>
            <jxb:package name=”com.sun.silverlining.identity”/>

    <jxb:bindings schemaLocation=”wssecurity-200401-secext-1.0.xsd” node=”//xs:schema”>
            <jxb:package name=”oasis.wss.secext”/>

    <jxb:bindings schemaLocation=”wssecurity-200401-utility-1.0.xsd” node=”//xs:schema”>
            <jxb:package name=”oasis.wss.utility”/>
    <jxb:bindings schemaLocation=”liberty-idwsf-utility-v2.0.xsd” node=”//xs:schema”>
            <jxb:package name=”liberty.util”/>


Don’t forget to instruct NetBeans to look for those newly generated classes. for this, in NetBeans, go to the properties of your project and look at the Sources in the Categories tab. There you should add the folder you declared in the build.xml file (in the above example: build/gen-src).

That’s it!
Building your project should now automatically generate Java classes from the schema and then build the whole project.

News of MD5 weaknesses have been around for a while but this recent publication goes further by demonstrating how this impacts X.509 certificates and our trust in secure web browsing (a lighter explanation of MD5’s weakness can be read here).
Basically one can create a rogue CA (certificate authority) certificate that will be trusted by most web browsers. The weakness at the crux of the issue is that it is possible to create collisions (2 messages leading to the same hash) with MD5. By extension, a rogue CA can create a certificate with a hash that matches the one of a certificate issued by a trusted root CA (one browsers trust).

I guess it’s fair to assume that all MD5-based signatures on certificates (or CRLs for that matter) should be rejected.