fbpx
Wikipedia

XML Signature

XML Signature (also called XMLDSig, XML-DSig, XML-Sig) defines an XML syntax for digital signatures and is defined in the W3C recommendation XML Signature Syntax and Processing. Functionally, it has much in common with PKCS #7 but is more extensible and geared towards signing XML documents. It is used by various Web technologies such as SOAP, SAML, and others.

XML signatures can be used to sign data–a resource–of any type, typically XML documents, but anything that is accessible via a 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;[1] if it contains the signed data within itself it is called an enveloping signature.[2]

Structure

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> 
  • The SignedInfo element contains or references the signed data and specifies what algorithms are used.
    • The SignatureMethod and CanonicalizationMethod elements are used by the SignatureValue element and are included in SignedInfo to protect them from tampering.
    • One or more Reference elements specify the resource being signed by URI reference and any transformations to be applied to the resource prior to signing.
      • Transforms 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.[3]
      • DigestMethod specifies the hash algorithm before applying the hash.
      • DigestValue contains the Base64 encoded result of applying the hash algorithm to the transformed resource(s) defined in the Reference element attributes.
  • The SignatureValue element contains the Base64 encoded signature result - the signature generated with the parameters specified in the SignatureMethod element - of the SignedInfo element after applying the algorithm specified by the CanonicalizationMethod.
  • KeyInfo 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 KeyInfo is not present.
  • The Object 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.

  1. 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.
  2. Signature Validation: The SignedInfo element is serialized using the canonicalization method specified in CanonicalizationMethod, the key data is retrieved using KeyInfo or by other means, and the signature is verified using the method specified in SignatureMethod.

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 getElementByName methods.[4]

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 "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 <Elem > is syntactically identical to <Elem>.

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.

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,[5] 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.[6][7][8] The argument is that performing XML canonicalization causes excessive latency that is simply too much to overcome for transactional, performance sensitive SOA applications.

These issues are being addressed in the XML Security Working Group.[9][10]

Without proper policy and implementation[4] the use of XML Dsig in SOAP and WS-Security can lead to vulnerabilities,[11] such as XML signature wrapping.[12]

Applications

An example of applications of XML Signatures:

See also

References

  1. ^ "XML Signature Syntax and Processing Version 1.1".
  2. ^ "XML Signature Syntax and Processing Version 1.1".
  3. ^ http://www.w3.org/TR/xmldsig-filter2/ XML-Signature XPath Filter 2.0
  4. ^ a b Pawel Krawczyk (2013). "Secure SAML validation to prevent XML signature wrapping attacks".
  5. ^ Why XML Security is Broken
  6. ^ Performance of Web Services Security
  7. ^ Performance Comparison of Security Mechanisms for Grid Services
  8. ^ Zhang, Jimmy (January 9, 2007). "Accelerate WSS applications with VTD-XML". JavaWorld. Retrieved 2020-07-24.
  9. ^ W3C Workshop on Next Steps for XML Signature and XML Encryption, 2007
  10. ^ XML Security 2.0 Requirements and Design Considerations
  11. ^ http://domino.research.ibm.com/library/cyberdig.nsf/papers/73053F26BFE5D1D385257067004CFD80/$File/rc23691.pdf[bare URL PDF]
  12. ^ Juraj Somorovsky; Andreas Mayer; Jorg Schwenk; Marco Kampmann; Meiko Jensen (2012). "On Breaking SAML: Be Whoever You Want to Be" (PDF).
  13. ^ https://www.sbr-nl.nl/english/what-is-sbr/assurance/ SBR Assurance, Dutch government, 2018

External links

  • XML Signature Syntax and Processing
  • Canonical XML
  • Additional XML Security Uniform Resource Identifiers (URIs)
  • Exclusive XML Canonicalization
  • XMLSignatures Java binding for XMLBeans and JAXB.
  • Step-by-Step example of how a signature is created.

signature, also, called, xmldsig, dsig, defines, syntax, digital, signatures, defined, recommendation, syntax, processing, functionally, much, common, with, pkcs, more, extensible, geared, towards, signing, documents, used, various, technologies, such, soap, s. XML Signature also called XMLDSig XML DSig XML Sig defines an XML syntax for digital signatures and is defined in the W3C recommendation XML Signature Syntax and Processing Functionally it has much in common with PKCS 7 but is more extensible and geared towards signing XML documents It is used by various Web technologies such as SOAP SAML and others XML signatures can be used to sign data a resource of any type typically XML documents but anything that is accessible via a 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 1 if it contains the signed data within itself it is called an enveloping signature 2 Contents 1 Structure 2 Validation and security considerations 3 XML canonicalization 4 Benefits 5 Issues 6 Applications 7 See also 8 References 9 External linksStructure EditAn XML Signature consists of a Signature element in the http www w3 org 2000 09 xmldsig namespace The basic structure is as follows lt Signature gt lt SignedInfo gt lt CanonicalizationMethod gt lt SignatureMethod gt lt Reference gt lt Transforms gt lt DigestMethod gt lt DigestValue gt lt Reference gt lt Reference gt etc lt SignedInfo gt lt SignatureValue gt lt KeyInfo gt lt Object gt lt Signature gt The SignedInfo element contains or references the signed data and specifies what algorithms are used The SignatureMethod and CanonicalizationMethod elements are used by the SignatureValue element and are included in SignedInfo to protect them from tampering One or more Reference elements specify the resource being signed by URI reference and any transformations to be applied to the resource prior to signing Transforms 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 3 DigestMethod specifies the hash algorithm before applying the hash DigestValue contains the Base64 encoded result of applying the hash algorithm to the transformed resource s defined in the Reference element attributes The SignatureValue element contains the Base64 encoded signature result the signature generated with the parameters specified in the SignatureMethod element of the SignedInfo element after applying the algorithm specified by the CanonicalizationMethod KeyInfo 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 KeyInfo is not present The Object element optional contains the signed data if this is an enveloping signature Validation and security considerations EditWhen 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 SignedInfo element is serialized using the canonicalization method specified in CanonicalizationMethod the key data is retrieved using KeyInfo or by other means and the signature is verified using the method specified in SignatureMethod 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 getElementByName methods 4 XML canonicalization EditThe creation of XML Signatures is substantially more complex than the creation of an ordinary digital signature because a given XML Document an 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 lt Elem gt is syntactically identical to lt Elem gt 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 Benefits EditXML 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 EditThere are criticisms directed at the architecture of XML security in general 5 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 6 7 8 The argument is that performing XML canonicalization causes excessive latency that is simply too much to overcome for transactional performance sensitive SOA applications These issues are being addressed in the XML Security Working Group 9 10 Without proper policy and implementation 4 the use of XML Dsig in SOAP and WS Security can lead to vulnerabilities 11 such as XML signature wrapping 12 Applications EditAn example of applications of XML Signatures Digital signing of XBRL annual reports by auditors in the Netherlands A PKIoverheid X 509 certificate approved by the Royal National Institute of Chartered Accountants nl is required The electronic signature is legally binding The SBR Assurance standard 13 is part of the Dutch Standard Business Reporting program See also EditCanonical XML XML Encryption XAdES extensions to XML DSig for use with advanced electronic signature Cryptographic Message SyntaxReferences Edit XML Signature Syntax and Processing Version 1 1 XML Signature Syntax and Processing Version 1 1 http www w3 org TR xmldsig filter2 XML Signature XPath Filter 2 0 a b 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 Zhang Jimmy January 9 2007 Accelerate WSS applications with VTD XML JavaWorld Retrieved 2020 07 24 W3C Workshop on Next Steps for XML Signature and XML Encryption 2007 XML Security 2 0 Requirements and Design Considerations http domino research ibm com library cyberdig nsf papers 73053F26BFE5D1D385257067004CFD80 File rc23691 pdf bare URL PDF Juraj Somorovsky Andreas Mayer Jorg Schwenk Marco Kampmann Meiko Jensen 2012 On Breaking SAML Be Whoever You Want to Be PDF https www sbr nl nl english what is sbr assurance SBR Assurance Dutch government 2018External links EditXML Signature Syntax and Processing Canonical XML Additional XML Security Uniform Resource Identifiers URIs Exclusive XML Canonicalization XMLSignatures Java binding for XMLBeans and JAXB Step by Step example of how a signature is created Retrieved from https en wikipedia org w index php title XML Signature amp oldid 1105270970, wikipedia, wiki, book, books, library,

article

, read, download, free, free download, mp3, video, mp4, 3gp, jpg, jpeg, gif, png, picture, music, song, movie, book, game, games.