Editing XML Signature

{{short description|XML syntax for digital signatures}}
'''XML Signature''' (also called ''XMLDSig'', ''XML-DSig'', ''XML-Sig'') defines an [[XML]] syntax for [[digital signatures]] and is defined in the [[W3C recommendation]] [http://www.w3.org/TR/xmldsig-core/ XML Signature Syntax and Processing]. Functionally, it has much in common with [[PKCS 7|PKCS #7]] but is more extensible and geared towards signing XML documents. It is used by various [[World Wide Web|Web]] technologies such as [[SOAP]], [[Security Assertion Markup Language|SAML]], and others.

XML signatures can be used to sign data&ndash;a '''resource'''&ndash;of any [[MIME#Content-Type|type]], typically XML documents, but anything that is accessible via a [[Uniform Resource Locator|URL]] can be signed. An XML signature used to sign a resource outside its containing XML document is called a [[detached signature]]; if it is used to sign some part of its containing document, it is called an '''enveloped''' signature;<ref>{{cite web | url=https://www.w3.org/TR/xmldsig-core/#def-SignatureEnveloped | title=XML Signature Syntax and Processing Version 1.1 }}</ref> if it contains the signed data within itself it is called an '''enveloping''' signature.<ref>{{cite web | url=https://www.w3.org/TR/xmldsig-core/#def-SignatureEnveloping | title=XML Signature Syntax and Processing Version 1.1 }}</ref>

== Structure ==
An XML Signature consists of a <code>Signature</code> element in the <code><nowiki>http://www.w3.org/2000/09/xmldsig#</nowiki></code> namespace. The basic structure is as follows:

<syntaxhighlight lang="xml">
<Signature>
  <SignedInfo>
    <CanonicalizationMethod />
    <SignatureMethod />
    <Reference>
       <Transforms />
       <DigestMethod />
       <DigestValue />
    </Reference>
    <Reference /> etc.
  </SignedInfo>
  <SignatureValue />
  <KeyInfo />
  <Object />
</Signature>
</syntaxhighlight>

* The <code>SignedInfo</code> element contains or references the signed data and specifies what algorithms are used.
** The <code>SignatureMethod</code> and <code>CanonicalizationMethod</code> elements are used by the <code>SignatureValue</code> element and are included in <code>SignedInfo</code> to protect them from tampering.
** One or more <code>Reference</code> elements specify the resource being signed by URI reference and any transformations to be applied to the resource prior to signing.
*** <code>Transforms</code> contains 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.<ref>[http://www.w3.org/TR/xmldsig-filter2/ XML-Signature XPath Filter 2.0]</ref>
*** <code>DigestMethod</code> specifies the hash algorithm before applying the hash.
*** <code>DigestValue</code> contains the [[Base64]] encoded result of applying the hash algorithm to the transformed resource(s) defined in the <code>Reference</code> element attributes.
* The <code>SignatureValue</code> element contains the [[Base64]] encoded signature result - the signature generated with the parameters specified in the <code>SignatureMethod</code> element - of the <code>SignedInfo</code> element after applying the algorithm specified by the <code>CanonicalizationMethod</code>.
* <code>KeyInfo</code> element 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 <code>KeyInfo</code> is not present.
* The <code>Object</code> element (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 <code>Reference</code>'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 <code>DigestValue</code>; if they do not match, validation fails.
# '''Signature Validation:''' The <code>SignedInfo</code> element is serialized using the canonicalization method specified in <code>CanonicalizationMethod</code>, the key data is retrieved using <code>KeyInfo</code> or by other means, and the signature is verified using the method specified in <code>SignatureMethod</code>.

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 <code>getElementByName</code> methods.<ref name="pk"/>

== XML canonicalization ==
The creation of XML Signatures is substantially more complex than the creation of an ordinary digital signature because a given XML Document (an "[[XML Infoset|Infoset]]", in common usage among XML developers) may have more than one legal serialized representation. For example, whitespace inside an XML Element is not syntactically significant, so that <code>&lt;Elem&nbsp;&gt;</code> is syntactically identical to <code>&lt;Elem&gt;</code>.

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 [[Newline|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 <code>SignedInfo</code>, 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.

== Benefits ==
XML Signature is more flexible than other forms of digital signatures such as [[Pretty Good Privacy]] and [[Cryptographic Message Syntax]], because it does not operate on [[binary data]], but on the [[XML Infoset]], allowing to work on subsets of the data (this is also possible with binary data in non-standard ways, for example encoding blocks of binary data in base64 ASCII), having various ways to bind the signature and signed information, and perform transformations. Another core concept is canonicalization, that is to sign only the "essence", eliminating meaningless differences like whitespace and line endings.

== Issues ==
There are criticisms directed at the architecture of XML security in general,<ref>{{Cite web|url=https://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt|title=Why XML Security is Broken}}</ref> 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.<ref>[http://grids.ucs.indiana.edu/ptliupages/publications/WSSPerf.pdf Performance of Web Services Security]</ref><ref>[http://www.extreme.indiana.edu/xgws/papers/sec-perf.pdf Performance Comparison of Security Mechanisms for Grid Services]</ref><ref>{{cite web |last1=Zhang |first1=Jimmy |date=2007-01-09 |df=mdy |url=https://www.infoworld.com/article/2077668/accelerate-wss-applications-with-vtd-xml.html |title=Accelerate WSS applications with VTD-XML |work=[[JavaWorld]] |access-date=2020-07-24}}</ref> The argument is that performing XML canonicalization causes excessive latency that is simply too much to overcome for transactional, performance sensitive [[Service-oriented architecture|SOA]] applications.

These issues are being addressed in the [http://www.w3.org/2008/xmlsec/ XML Security Working Group].<ref>[http://www.w3.org/2007/xmlsec/ws/report.html W3C Workshop on Next Steps for XML Signature and XML Encryption], 2007</ref><ref>{{Cite web|url=http://www.w3.org/TR/xmlsec-reqs2/|title=XML Security 2.0 Requirements and Design Considerations}}</ref>

Without proper policy and implementation<ref name="pk">{{cite web |author=Pawel Krawczyk |year=2013 |url=https://web.archive.org/web/20131214072339/https://ipsec.pl/node/1119 |title=Secure SAML validation to prevent XML signature wrapping attacks}}</ref> the use of XML Dsig in SOAP and WS-Security can lead to vulnerabilities,<ref>{{cite web |url=http://domino.research.ibm.com/library/cyberdig.nsf/papers/73053F26BFE5D1D385257067004CFD80/$File/rc23691.pdf|title=XML Signature Element Wrapping Attacks and Countermeasures|access-date=2023-09-07|publisher=IBM Research Division}}</ref> such as XML signature wrapping.<ref>{{cite web |author1=Juraj Somorovsky |author2=Andreas Mayer |author3=Jorg Schwenk |author4=Marco Kampmann |author5=Meiko Jensen |year=2012 |url=https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91-8-23-12.pdf |title=On Breaking SAML: Be Whoever You Want to Be}}</ref>

== Applications ==
An example of applications of XML Signatures:
* Digital signing of [[XBRL]] [[annual report]]s by [[auditor]]s in the [[Netherlands]]. A [[PKIoverheid]] [[X.509 certificate]], approved by the {{ill|Royal National Institute of Chartered Accountants|nl|Koninklijke Nederlandse Beroepsorganisatie van Accountants}}, is required. The electronic signature is legally binding. The [[SBR Assurance]] standard<ref name="sbra">{{cite web |url=https://www.sbr-nl.nl/english/what-is-sbr/assurance/ |title=SBR Assurance|access-date=2023-09-07}}</ref> is part of the Dutch [[Standard Business Reporting]] program.

==See also==
*[[Canonical XML]]
*[[XML Encryption]]
*[[XAdES]], extensions to XML-DSig for use with advanced electronic signature
*[[Cryptographic Message Syntax]]

==References==
<references/>

==External links==
* [https://www.w3.org/TR/xmldsig-core/ XML Signature Syntax and Processing]
* [https://www.w3.org/TR/2001/REC-xml-c14n-20010315 Canonical XML]
* [https://www.ietf.org/rfc/rfc4051.txt Additional XML Security Uniform Resource Identifiers (URIs)]
* [https://www.w3.org/TR/xml-exc-c14n/ Exclusive XML Canonicalization]
* [https://xmlbeans.googlepages.com/ XMLSignatures Java binding] for XMLBeans and JAXB.
* [https://www.di-mgt.com.au/xmldsig.html Step-by-Step example] of how a signature is created.

{{W3C standards}}

{{DEFAULTSORT:Xml Signature}}
[[Category:Cryptography standards]]
[[Category:XML-based standards]]