XML Signature
From Wikipedia, the free encyclopedia
XML Signature (also called XMLDsig, XML-DSig, XML-Sig) is a W3C recommendation that defines an XML syntax for digital signatures. 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; if it contains the signed data within itself it is called an enveloping signature.
Contents |
[edit] 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
SignatureMethod
CanonicalizationMethod
Reference
Transforms
DigestMethod
DigestValue
Reference ...
SignatureValue
KeyInfo
Object
- The SignedInfo element specifies what was signed and with what algorithms.
The SignatureMethod and CanonicalizationMethod elements are used by the SignatureValue element and are included in SignedInfo to protect them from tampering.
A list of Reference elements specify which resources have been signed, using URI references; this element also specifies any transforms to apply to the resource before applying the hash, the digest (hash) algorithm (in DigestMethod), and the result of applying it to the resource (Base64-encoded in DigestValue).
- The SignatureValue is the Base64-encoded value of the signature. This value is the signature (produced according to the specification of the SignatureMethod element) of the SignedInfo element after serializing it with the algorithm specified by the CanonicalizationMethod element (see below for more on canonicalization).
- The KeyInfo is an optional element that enables the recipients to obtain the key needed to validate the signature. Typically it can contain a set of X.509 certificates. If a KeyInfo element is not present, the recipient is expected to identify the key from context.
- The Object is an optional element used to hold the signed data in the case of an enveloping signature.
[edit] 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 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 extensibiliy 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.
[edit] XML Canonicalization
The creation of XML Signatures is a bit 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 is created by using an asymmetric key algorithm (typically RSA) to encrypt the results of running the serialized XML document through a Cryptographic hash function (typically SHA1), a single-byte difference would cause the digital signature to vary.
To avoid this problem and guarantee that logically-identical XML documents give identical digital signatures, an XML canonicalization transform (frequently abbreviated C14n) is nearly always employed when signing XML documents (for signing the SignedInfo, a canonicalization is mandatory). These algorithms guarantee that logically-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.
[edit] Criticisms
There are criticisms directed at the suitability of XML canonicalization 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.
[edit] See also
- Canonical XML
- XAdES, extensions to XML-DSig for use with advanced electronic signature
[edit] External links
- Performance of Web Services Security
- W3C workshop presentation on XML security
- Performance Comparison of Security Mechanisms for Grid Services
- Why XML canonicalization is bad for Web Services Security
- XML-Signature Syntax and Processing (W3C)
- Canonical XML
- Exclusive XML Canonicalization
- Why XML Security is Broken
- XMLSignatures Java binding for XMLBeans and JAXB.
|
|||||||||||
