XML Signature 2.0
• 2002 – XML Signature 1.0
• 2007 – XML Signature 1.0, 2nd edition
– Adds support for Canonicalization
• 2009 end – XML Signature 1.1
– Adds support for Elliptic Curve algorithms required for Suite B
– SHA2 algorithms, DER format for keys, OCSP Response and few other
• 2010 mid – XML Signature 2.0
– Major changes – discussed in rest of presentation.
– The first draft of XML Signature 2.0 is out, and it now open for
• Reduce security attack surface
• Streaming & Performance
• Backward compatibility
• See draft specs
– Signature 2.0: http://www.w3.org/TR/2009/WD-xmldsig-core2-20091022/
– Canonicalization 2.0 http://www.w3.org/TR/2009/WD-xml-c14n2-20091022/
• Simplifies creating interoperable implementations
– Deals with difficult Whitespace issues
• Any change in whitespace causes the signature to break.
• It is popular misconception that canonicalization takes care of whitespace. It
• All of these will break the signature : a) pretty printing the document, b) converting
spaces to tabs, c) adding new lines, d) copy/pasting from log file .
– Enhances default Namespace handling
• Change in the prefix value breaks the signature. E.g <soap:Body> is not considered the
same as <s:Body> even if the prefixes “soap” and “s” are defined to be the same.
• Unused namespace declarations can break signature. – especially uses around default
• Exclusive canonicalization solves some namespace problems but not all.
• How XML Signature 2.0 solves most of these problems
– Merges “Inclusive” and “Exclusive” canonicalization into one – the new
canonicalization 2.0. XML Signature 2.0 needs to use this canonicalization.
– In canonicalization 2.0
• Text nodes are “trimmed”, i.e. leading and trailing whitespace is removed
• Namespace prefixes are rewritten. E.g. both <soap:Envelope> and <s:Envelope> will
be converted to <n1:Envelope>
• Prefixes that are embedded in content are also changed. The most common place is
the xsi:type attribute. E.g. if the original value of xsi:type was “xsd:string”, its value will
be changed during rewriting.
• These changes will help with XML Schema to native object translation (data bindings).
– Canonicalization 2.0 is “parameter based”. i.e. all of these new changes are
controlled by parameters and they can be turned off to get output that is
completely same as canonicalization 1.x
• XML Signature 1.x flexibility increases attack surface
– A signature has a set of “Transforms” to convert from XML -> bytes
• A transform is a procedural step e.g. XPath selection, XSLT snippet, canonicalization
• Low level crypto algorithm can only sign bytes. These transforms convert XML -> bytes.
• The simplest signature has only one transform – canonicalization.
• But a complex signature can have many e.g. an XPath selection, followed by XSLT
transformation, followed by canonicalization
• The signature verifier needs to execute each of these transforms and at the end of the
transform will get the bytes.
– Transforms can be misused for many kinds of attacks.
• Denial of Service attacks – complex XPath and XSLT
• Wrapping attacks – what is signed is not evident
• Cross site scripting attacks – gain elevated access privileges
XML Signature is used in a variety of security models
1. Client <-> Server messaging.
– E.g. in Web services, SAML, ebXML, remote Portlets etc.
– The server checks the signature in client‟s message to determine if the
message is valid. This happens before any kind of authorization.
(The message is completely untrusted when the signature check is happening, so
the signature check process needs to be secure. For outside firewall servers, the
message can have originated from anywhere on the internet.)
2. Long term document storage
– The server signs the document and stores it in an untrusted storage. Later
on it retrieves the document , and makes sure it has not been tampered
(Much more limited attack scope.)
• XML Signature 2.0 introduces “declarative model”
– Basic premise: before verification, signature is untrusted, so it cannot
specify how to verify itself. i.e. No TRANSFORMS.
– Transforms are replaced by simple properties
• Type/subtype of data, URI, Inclusion XPath, Exclusion XPath, Enveloped etc.
– Verifier decides how to actually check the signature instead of blindly running
through all the transforms.
• 1.x: Procedural – Signature says do these steps to verify me.
• 2.0: Declarative – Signature says this is what I sign. Verifier decides how to verify.
– Impacts the extension mechanism
• 1.x: a verifier could verify a signature without understanding what it is actually signing, it
simply has to execute a different sequence of transforms.
• 2.0: it can‟t. Extensibility has to be accomplished by adding new property and these
properties have to be exchanged out of band.
• XML signature 2.0 eliminates DoS attacks involving
– Since there are no transforms, the DoS attack of a Signature having 10,000
transforms is not possible any more.
– The n2 attack with namespace nodes is eliminated, because “nodeset” is not
used any more.
• (Suppose an incoming message has „n‟ elements and „n‟ namespaces, i.e. total „2n‟ nodes. XML
Signature 1.x will expand this out to „n2‟ nodes. This is exploited in many DoS attacks).
– Another n2 attack with XPath transform is eliminated too, because in XML
Signature 2.0, the Included XPath and exluded Xpath is executed only once, not
once per node.
• (suppose an incoming message has „n‟ elements. It is easy to contruct an XPath expression that
iterates through all the nodes. Since XPath transform‟s XPath is executed for every node, this would
result in „n2‟ traversals).
– An XPath Filter 2 Transform, could have thousands of Intesect/Union/Subtract
XPaths. But in signature 2.0 there are only two include and exclude.
– Loops in XSLT are also eliminated because XSLT is disallowed completely.
• XML Signature 2.0 eliminates the XSLT transform
– XSLT can be exploited for many kinds of attacks.
– e.g. an XSLT transform can execute code to shutdown the system
<xsl:variable name="runtime" select="java:lang.Runtime.getRuntime()"/>
<xsl:value-of select="os:exec($runtime, 'shutdown -i')" />
– e.g. an XSLT transform can run a very large loop causing a Dos attack
• XML Signature 2.0 also removes the Decrypt Transform
– The decrypt transform enabled signatures to be verified even if the order of the
operations Sign and Encrypt operations is not known.
• In all real uses cases the order of operations is known beforehand, e.g. through a Policy, so decrypt
transform is not used in practice.
• The other bigger issue is that during decryption there is no check done of what key was used to
encrypt the data, what was the strength of the algorithm used to encrypt it etc, decryption just happens
as a side effect. This means it insecure.
• Decrypt transform also has a performance impact, because after the decryption transform the
decrypted data is just passed to the next transform, they are not stored anywhere, So decryption
needs to be repeated.
Determine what was signed
• XML Signature 2.0 gives a mechanism to find out what
– In XML security 1.x some transforms select data to be signed, and some convert
that to bytes, and some transforms do both (.e.g STR-Transform). These
transforms can be intermixed in any order. This makes it very hard to determine
what is actually signed.
– 2.0 has clean separation between “Selection” and “Canonicalization”.
• Selection chooses the data to be signed using Ids, XPaths etc.
• Canonicalization converts the data to be signed.
– A Policy checker can look at the Selection part and figure out what was signed.
– This policy check helps prevent “Wrapping attacks”
• (E.g. in a WS-Security wrapping attack the Signature it will appear to sign the soap:Body element, but
this is not real soap:Body element, but rather another soap:Body element that is squirreled away deep
inside some soap:Header )
• Streaming is major goal for XML Signature 2.0
– It should be possible to sign/verify without loading the whole document in
• Currently web services prefer to work in streaming mode. But many implementations
end up converting to DOM just to execute sign/verify operations. This has a very high
• Estimate that streaming will give a 2x-4x boost on software.
• For Hardware devices streaming is an absolute most. Most current implementation work
with only the subset of XML signature that can be streamed.
– The biggest impediment to streaming was XPath.
• XML Signature 2.0 describes all operations in terms of “subtrees” instead of XPath
“nodesets”. Nodesets are by definition not streamable.
• 2.0 also defines a streamable subset of XPath, only XPaths in this subset are allowed.
– Note: Streaming does not necessarily imply only one pass.
• In WS-Security the signature is before the data that is being signed, so obviously one
needs to make a second pass to update the signature value.
• XML Signature 2.0 has performance improvements for
the non streaming implementations too.
– Canonicalization can be implemented by simple tree walk instead of iterating
The performance of canonicalization should be same as XML serialization.
• If you follow the 1.x spec exactly it would be extremely slow. Most mature implementations already do a tree walk, instead
of following the spec exactly. So really the spec will be updated to what some implementations are already doing.
– Does not do a namespace node expansion
• XML Signature 1.x is based on the XPath data model, in which namespace nodes are expanded out – this can result in very
high memory usage. E.g. if there are O(n) elements and O(m) namespaces,
it would use O(n * m) memory. With the new approach it only uses O(n + m). (Again some implementations are already
doing this internally.
– Does not evaluate XPath multiple times
• XPath evaluation is expensive, and in XPath Filter Transform, the XPath needs to be evaluated for every node. XPath Filter
2 Transform solves this problem, but it was not popular as many implementations do not support it, also it has nodeset and
namespace issues mentioned above. Signature 2.0 has a very simplified XPath model.
– Does not to automatic nodeset -> binary -> nodeset conversion
• In XML Signature 1.x, the transform processing is supposed to do these expensive operations whenever there is an
impedance mismatch between one transforms output and the next one‟s input. They are no longer applicable for 2.0
– Recommends combining canonicalization and digesting operations.
• XML Signature 2.0 also simplifies many aspects of XML
– Signature 2.0 identifies the most common transform cases and provides a simple
declarative means of using them. Only the simplest and most common use cases
– Any complex XML processing has been pushed outside the scope of the spec –
other technology should be used for this. e.g XProc (see
– There is only way to do XPath, and it is much simpler than either of the XPath
transforms. E.g. the XPath Filter 1 Transform:
count(parent::node()/namespace::* | self::node()))
– Nodeset has been removed. Nodesets are not only expensive, they are
notoriously tricky to implement. There are some complex test vectors that almost
no implementation supports.
• XML Signature 2.0 is backwards compatible with 1.x
– XML Signature 2.0 defines new mechanisms using the 1.x syntax
– Though not described, 1.x mechanisms can still be used if absolutely necessary.
– The declarative syntax is packaged as a new transform, so if a 1.x
implementation gets a 2.0 signature, it will fail gracefully.
• If instead we had changed the schema, some implementations would give a Runtime error which
would be very hard to debug, but with this approach it will give a proper error – “unknown transform”.
• XML Signature 2.0 offers many improvements, including simplicity,
performance, streamability, and reduced attack surface.
• XML Signature 2.0 is a major update to XML Signature based on experience with
XML Signature 1.0.
• Adoption will take time.