Security is surely one of the most talked-about subjects this year. Many books about writing secure code have surfaced over the past several months (for Windows and Unix too!). Early in the year, Microsoft announced its Trustworthy Computing initiative. In addition, the company's partnership with IBM and Verisign has resulted in WS-Security (Web Services Security), a platform- and language-neutral security standard for Web services.
WS-Security enhances SOAP (Simple Object Access Protocol) messaging to provide confidentiality and integrity, which form the basis for higher-level security aspects, such as trust, authorization, or policy. In Part 1, I discussed XML Encryption, which covers WS-Security confidentiality. In this article, we look closer at the integrity part of the equation: XML Signature, which turns out to be a bit more complicated than its confidentiality counterpart.
Read the whole series on XML security, "Yes, You Can Secure Your Web Services Documents:"
The main difference between XML Signature and other digital signature standards such as PKCS#7 (Public-Key Cryptography Standard #7) is that it is—surprise, surprise—XML-aware. That is, with XML Signature, not only can you sign arbitrary digital content as a whole, but you can also sign just specific parts of XML documents. This proves useful when parts of XML documents can be moved, copied, encrypted, signed, and verified in any order, which is quite likely to happen as we move more towards shuffling around XML messages instead of binary payload over the wire. However, as you will see later, XML awareness doesn't come free.
Compared to XML Signature, XML Encryption is relatively straightforward. You select some nodes to encrypt, and that's basically it. You decrypt the ciphertext with the correct key, and you retrieve the plaintext—as simple as that. Not so with XML Signature! XML Signature is more complicated because signatures need to be verified correctly. Now, what can be so difficult about verification? Read on.
Generating a signature over a document usually means calculating that document's digest and encrypting it with your private key. When you need to verify it on the other side of the wire, simply recalculate the document's digest and compare it with the digest you get from decrypting the encrypted digest with the signer's public key. That way, you can ensure the document has not changed, not even slightly.
But XML Signature is XML-aware, which introduces a new challenge. Look at the snippets below:
<blah meaning="also nothing" purpose='nothing' > <blah2 /> </blah>
and
<blah purpose='nothing' meaning = 'also nothing'> <blah2></blah2> </blah>
Though both snippets have identical information content, because of their permissible differences, their digests will definitely differ. That's what you get when mixing XML with digital signature: digital signature checks whether a message has changed along the way, but an XML document's physical representation can—and quite likely will—change during processing, even though its information content remains the same.