Currently, holds the messages of the last two weeks. This service also makes the mailinglist reachable with a news reader.

You can use the ezmlm mailing list controller to recieve previous messages by email. Send an empty email to for detailed information on how to use this service

There are plenty of resources on the web, just use any search engine. You might start at or .

The best place to start is . Links on XML security in general can be found on .

The best place to start is . Links on XML security in general can be found on

A lot of resources exist on the web, including the 'green bible' for cryptography: . The &hac; is completely online and it should satisfy most of your cryptographic hunger. Disadvantage of it is that it goes rather deep, so it isn't a executive overview or a "Learn XYZ in 21 days"-book

Go to the of Sun. You can find forums where you can ask questions like "How do I generate a keypair", etc.

Go to the of Sun, section Java Technology & XML and have a look at .

Crimson is not supported at the moment. The main reason is that Crimson did not support the org.w3c.dom.traversal.TreeWalker interface in the past. Additionally, it does not support the org.apache.xerces.dom.DocumentImpl.putIdentifier(String ID, Element e) functionality where Xerces allows us to enable ID attributes during document generation.

Use instead of Crimson.

There is no JCE bundled together with this distribution. This is because the Apache Project web site is hosted in the US where some export restrictions apply to the cryptographic primitives.

The nice guys from the Legion of Bouncy Castle where so helpful to supply their JCE in a simple JAR package so that we can simply fetch it during the compilation process and put it into the libs/ directory. When you use the ant makefile build.xml and simply say ant compile or ant get-jce, ant tries to fetch this JAR from the australian server. After that step, the compilation works completely.

The ant make tools initiates an automated download of the BouncyCastle JCE. The file is downloaded into the libs/ directory and a "bc-" is prepended to the filename. This is done because we want the provider name (bc means BouncyCastle) being visible in the JAR's filename.

More information can be found in the Installation section.

The logging is configured in the config.xml file which either in the xmlsec.jar file or in the class path. This is a little bit complicated as config.xml is used both for library wide configurations like algorithms as well as for the user setting about log4j. This will be changed someday ;-))

OK, so it goes: In the xml-security/src/org/apache/xml/security/resource/config.xml file, there is an element called <log4j:configuration>. This element contains the XML style configuration information as defined in the log4j DOMConfigurator class. You can find examples here

Checkout the samples in src_samples/org/apache/xml/security/samples/signature/.

When you work with URIs like "http://www.example.com/index.html", it is quite sure what you mean as this is an absolute URL, i.e. it is clear which protocol ise used to fetch which file from which server. When you use such a URL inside a signature, the software can automatically figure out what you sign. But when you sign something in your local file system or if you use a relative path like "../1.txt", it's not possible to understand this reference without some context. This context is the BaseURI. For instance, if you sign URI="../1.txt" and the BaseURI="file:///home/user/work/signature.xml", it is clear that the file BaseURI="file:///home/user/1.txt" is to be signed. But when you create the signature, the file BaseURI="file:///home/user/work/signature.xml" does not yet exist; therefore, you have to supply the URL where you intend to store the signature later (relative to the signed objects).

The String BaseURI is the systemID on which the Object will be stored in the future. This is needed to resolve relative links in the Reference elements which point to the filesystem or something similar.

Example: Imagine that you want to create a signature to store it on a web server as http://www.acme.com/signatures/sig1.xml. So BaseURI="http://www.acme.com/sig1.xml". This means that if you create a Reference with URI="./index.html", the library can easily use it's HTTPResourceResolver to fetch http://www.acme.com/index.html without that you have to say URI="http://www.acme.com/index.html".

The enveloped transform is a special transform that enables the use of so-called enveloped signatures.

Enveloped signatures are signatures over an entire XML document, for which the <Signature> element is included in the document itself. An example could be:

]]>
 ]]>
  
 ]]>
 ]]>
  ]]>
   ]]>
    ]]>
     ]]>
    ]]>
   ]]>
  ]]>
  
 ]]>
]]>


The Reference indicates that Root and it's descendants (except for comments) are signed, but the Transform element says to throw out the Signature element (that is the parent of this Reference) from the stream that is to be signed. Note that if there are other Signature elements in Root, they will remain untouched.

C14N was introduced to solve some problems that arise when signing XML. Because XML allows to change the representation of an XML document without changing the actual content, signatures may break when different parsers are used to generate and verify the signature. A simple example of such an allowed change is changing the order of attributes within an element. (That is solved by C14N by sorting the attributes by alphabet)

Because a C14N'ed XML fragment inherits all the namespace declarations from it's ancestors, it is not possible to embed a signed XML fragment into a document that has other namespace declarations.

This is solved by ExclC14N. ExclC14N takes extra information as input in which you can specify which of the ancestor's namespaces should be included.

For more information on this topic, have a look at the C14N and ExclC14N sections of .

After SUN released the Java (TM) 2 Platform Standard Edition v1.4.0 , the xml-security package stopped working. This is a known problem: SUN packaged a beta of Xalan into the JDK1.4.0, but the xml-security package requires a stable version of Xalan (v2.2.0 or later). To fix the problem, you have to put the xalan.jar into a special directory in your JDK: j2sdk1.4.0/jre/lib/endorsed/xalan.jar. If you installed an out-of-the-box JDK1.4 (e.g. on Windows 2000), the "endorsed" directory does not exist: you'll have to create it by hand. Putting this JAR to another location like lib/ext WILL NOT WORK.

For more on that, you can also check the Unofficial JAXP FAQ .

Often, this problem is caused by using DOM1 calls like createElement(), setAttribute(), createAttribute(). These are non-namespace-aware and will cause XPath and C14N errors.
Always use the DOM2 create(Attribute|Element)NS(...) methods instead, even if you're creating an element without a namespace (in that case, you can use null as a namespace).

The Xalan-J Team told us that DOM1 calls are deprecated and are not to be used in code. xml-security has been reviewed and is DOM1 clean now. The Xalan folks told us that if you create Elements or attributes using DOM1 calls which are not namespace aware, they do not care about any problem you have because of incorrect hehaviour of Xalan.