XML Signature (also called XMLDSig, XML-DSig, XML-Sig) defines an
XML signatures can be used to sign data–a resource–of any
An XML Signature consists of a
Signature element in the
http://www.w3.org/2000/09/xmldsig# namespace. The basic structure is as follows:
<Signature> <SignedInfo> <CanonicalizationMethod /> <SignatureMethod /> <Reference> <Transforms /> <DigestMethod /> <DigestValue /> </Reference> <Reference /> etc. </SignedInfo> <SignatureValue /> <KeyInfo /> <Object /> </Signature>
SignedInfoelement contains or references the signed data and specifies what algorithms are used.
CanonicalizationMethodelements are used by the
SignatureValueelement and are included in
SignedInfoto protect them from tampering.
- One or more
Referenceelements specify the resource being signed by URI reference and any transformations to be applied to the resource prior to signing.
Transformscontains the transformations applied to the resource prior to signing. A transformation can be a XPath-expression that selects a defined subset of the document tree.
DigestMethodspecifies the hash algorithm before applying the hash.
DigestValuecontains the Base64 encoded result of applying the hash algorithm to the transformed resource(s) defined in the
SignatureValueelement contains the Base64 encoded signature result - the signature generated with the parameters specified in the
SignatureMethodelement - of the
SignedInfoelement after applying the algorithm specified by the
KeyInfoelement optionally allows the signer to provide recipients with the key that validates the signature, usually in the form of one or more X.509 digital certificates. The relying party must identify the key from context if
KeyInfois not present.
Objectelement (optional) contains the signed data if this is an enveloping signature.
Validation and security considerations
When validating an XML Signature, a procedure called Core Validation is followed.
- Reference Validation: Each
Reference's digest is verified by retrieving the corresponding resource and applying any transforms and then the specified digest method to it. The result is compared to the recorded
DigestValue; if they do not match, validation fails.
- Signature Validation: The
SignedInfoelement is serialized using the canonicalization method specified in
CanonicalizationMethod, the key data is retrieved using
KeyInfoor by other means, and the signature is verified using the method specified in
This procedure establishes whether the resources were really signed by the alleged party. However, because of the extensibility of the canonicalization and transform methods, the verifying party must also make sure that what was actually signed or digested is really what was present in the original data, in other words, that the algorithms used there can be trusted not to change the meaning of the signed data.
Because the signed document's structure can be tampered with leading to "signature wrapping" attacks, the validation process should also cover XML document structure. Signed element and signature element should be selected using absolute XPath expression, not
The creation of XML Signatures is substantially more complex than the creation of an ordinary digital signature because a given XML Document (an "
<Elem >is syntactically identical to
Since the digital signature ensures data integrity, a single-byte difference would cause the signature to vary. Moreover, if an XML document is transferred from computer to computer, the line terminator may be changed from CR to LF to CR LF, etc. A program that digests and validates an XML document may later render the XML document in a different way, e.g. adding excess space between attribute definitions with an element definition, or using relative (vs. absolute) URLs, or by reordering namespace definitions. Canonical XML is especially important when an XML Signature refers to a remote document, which may be rendered in time-varying ways by an errant remote server.
To avoid these problems and guarantee that logically-identical XML documents give identical digital signatures, an XML canonicalization transform (frequently abbreviated C14n) is employed when signing XML documents (for signing the
SignedInfo, a canonicalization is mandatory). These algorithms guarantee that semantically-identical documents produce exactly identical serialized representations.
Another complication arises because of the way that the default canonicalization algorithm handles namespace declarations; frequently a signed XML document needs to be embedded in another document; in this case the original canonicalization algorithm will not yield the same result as if the document is treated alone. For this reason, the so-called Exclusive Canonicalization, which serializes XML namespace declarations independently of the surrounding XML, was created.
XML Signature is more flexible than other forms of digital signatures such as
There are criticisms directed at the architecture of XML security in general, and at the suitability of XML canonicalization in particular as a front end to signing and encrypting XML data due to its complexity, inherent processing requirement, and poor performance characteristics. The argument is that performing XML canonicalization causes excessive latency that is simply too much to overcome for transactional, performance sensitive SOA applications.
An example of applications of XML Signatures:
- Digital signing of
- Canonical XML
- XML Encryption
- XAdES, extensions to XML-DSig for use with advanced electronic signature
- Cryptographic Message Syntax
- "XML Signature Syntax and Processing Version 1.1".
- "XML Signature Syntax and Processing Version 1.1".
- XML-Signature XPath Filter 2.0
- Pawel Krawczyk (2013). "Secure SAML validation to prevent XML signature wrapping attacks".
- "Why XML Security is Broken".
- Performance of Web Services Security
- Performance Comparison of Security Mechanisms for Grid Services
- W3C Workshop on Next Steps for XML Signature and XML Encryption, 2007
- "XML Security 2.0 Requirements and Design Considerations".
- "XML Signature Element Wrapping Attacks and Countermeasures" (PDF). IBM Research Division. Retrieved 2023-09-07.
- Juraj Somorovsky; Andreas Mayer; Jorg Schwenk; Marco Kampmann; Meiko Jensen (2012). "On Breaking SAML: Be Whoever You Want to Be" (PDF).
- "SBR Assurance". Retrieved 2023-09-07.