One month after the 1.5.0 release, the bugfix release 1.5.1 of Apache Santuario is available. Two bugs were fixed: one in XMLSignatureInput when using a BufferedInputStream. The other one caused Santuario to still require Apache Xalan (which was changed to optional in 1.5.0). Besides that, encryption and decryption should work faster now.
The German XML Security tutorials are now developed on GitHub. This does not affect the Eclipse XML Security Tools at all; the German tutorials will never be integrated there. The sources are only used to generate the tutorials available on my home page.
I'm working on some content updates. As soon as this will be finished I'll provide a new html version.
The W3C recently published new working drafts of several XML Security related 1.1 versions: On May 13th, XML Signature Syntax and Processing, XML Encryption Syntax and Processing and XML Security Generic Hybrid Ciphers have been updated. These are so called Last Call Working Drafts, meaning the process is finally coming to an end and we should see the final recommendations within the next (couple of) months (in case there are no major updates required).
Quite a lot of XML Security related drafts were updated during my two months holiday:
Besides that there is a new XML Encryption Syntax and Processing Version 1.1 from March 16th 2010. This is a working draft too. The XML Security RELAX NG Schemas working draft reflects the latest changes on the RELAX NG schema side.
The likewise updated XML Security Generic Hybrid Ciphers working draft talks about a consistent treatment of asymmetric ciphers when encrypting data. The focus lies on interoperability, which on one side is a nice working draft but comes with the price of another namespace declaration and some new elements for the already complex XML Security recommendations…
And finally there is an update on the XML Security Algorithm Cross-Reference working draft which reflects all updates applied to XML Signature and XML Encryption working drafts (and recommendations) up to version 1.1 (the different working drafts for version 2.0 are not included in this one).
The new XML Signature version promises more simplicity and more performance. Chapter 10 lists the differences to the current version. In short: New namespace dsig2, Canonical XML 2.0 and a completely changed transformation model which isn't that general any more (which is good, since the completely open one we are using now may lead to a lot of security problems). The new one now separates between selection and canonicalization, which includes the new Selection element. In short this element chooses the data object that is to be signed.
Canonical XML 2.0 brings in more performance and more security. It is still designed for XML 1.0, not XML 1.1 (so still no canonicalization for XML 1.1 out there). And as written above it is required for XML Signature 2.0.
Since these are the first public drafts some things will change until the final recommendations will be available.
Version 1.4.3 of Apache XML Security (Santuario) is available. In case you do use this API you should update as soon as possible to the new release. This release doesn't provide any new features, but includes a lot of bug fixes, including a correction for the relatively serious security vulnerability that has been discovered lately.
There is a vulnerability with XML Signatures. The W3C recommendation includes support for HMAC truncation, as specified in RFC2104. The thing is, this support is not complete: The RFC does not allow truncation to less than half of the length of the hash output or less than 80 bits (whatever comes first). The XML Signature recommendation ignored this part of the RFC up to now. So when HMAC truncation is under the control of an attacker this can result in an effective authentication bypass.
On one side this is serious since it is possible to specify an HMACOutputLength of 1, so that only one bit of the signature is verified. This can allow an attacker to forge an XML Signature that will be accepted as valid. US-CERT lists the vulnerable products. Apache XML Security up to version 1.4.2 is vulnerable (among a lot of other products). Since version 1.4.3 should be available tomorrow (including a fix for this bug) at least Apache XML Security users will be on the safe side again. And on the other side the HMACOutputLength feature is not that widely used, so there is no need to panic.
The upcoming XML Signature 1.1 recommendation is already updated. See the Q&A page contains some additional information.
The WebApps working group has published a first working draft of the Widgets 1.0: Digital Signatures recommendation. This is normally neither my working nor my research area. But this recommendation makes already use of XML Signature 1.1 and is a really cool and obvious usage scenario for XML Signatures. Since the widgets are based on XML there is no better possibility to sign this data than using XML Signatures. Maybe this is the killer (end user) application for XML Signatures that has been missing so far…
The W3C XML Security Working Group has released eight first public working drafts last week, from updated XML Encryption 1.1 and XML Signature 1.1 specifications to even some new ones. Among others, these drafts include revisions to XML Signature and XML Encryption to support new algorithms and a new document proposing simplifications to the XML Signature Transform model to enhance performance and security.
XML Signature Best Practices experienced some updates to match the latest recommendations. XML Security Derived Keys, XML Signature Properties, XML Security Algorithm Cross-Reference and XML Security Use Cases and Requirements are completely new specifications.
XML Signature Syntax and Processing Version 1.1
This version mostly replaces more or less unsafe algorithms like SHA-1 with SHA-256 or higher (well, SHA-1 is not replaced, it is still a required algorithm, but SHA-256 is required too). Additionally elliptic curve cryptography has arrived in the recommendations in form of the ECPublicKey element and of course the matching algorithms. And we are confronted with a new digital signature namespace http://www.w3.org/2009/xmldsig11#. Check out the diff-marked version for all changes.
XML Encryption Syntax and Processing Version 1.1
Some updates on required and recommended algorithms too. Elliptic Curve Diffie-Hellman is now a required Key Agreement algorithm. Not too many changes here; and I couldn’t find a diff-marked version.
XML Security Derived Keys
This completely new specification defines a derived key XML type and associated elements, both used in XML Signature and XML Encryption.
XML Signature Properties
Signature properties are nothing new. Up to now it is possible to define any signature property one desires. This is still possible in the future, but this new recommendation will define some commonly used ones. Four properties are defined so far: Profile, Role, Expires and ReplayProtect. I guess we will see some more in the final recommendation…
XML Security Algorithm Cross-Reference
Another new document. And a really, really good idea! This reference contains all algorithms and their corresponding URI used in all XML Security recommendations. Bookmark this page, and never use an incorrect URI again!
XML Signature Best Practices
A collection of best practices, mostly security related, for implementers and users of the XML Signature recommendations. Not everything will be useful in every environment, but clearly this document points into the right direction of making a complex recommendation more practical in the daily usage.
XML Security Use Cases and Requirements
This document summarizes use cases and requirements driving revisions to XML Signature, XML Encryption and XML Canonicalization. Not that interesting for XML Security users.
XML Signature Transform Simplification: Requirements and Design
I like the idea behind this document. Basically it recommends replacing the current reference processing model with a simpler one. And simplicity is always good for security (and for performance). What may(!) happen is an extended Reference element with Selection, Transform and Canonicalization child elements. The Selection element chooses what is to be signed. The Transform element makes sure that you only sign what you see (it has a limited number of transformations that for). And finally the Canonicalization element is used to produce the input for the hash. So the reference processing may change a little bit in the future.