XML Signatures
An XML file can be digitally signed and the signature can be subsequently verified. If the file has been changed after it was signed, then the verification will fail. XMLSpy supports both the creation and the verification of XML signatures.
XML signatures in XMLSpy views
XML signatures can be created for all types of XML files, including for XML Schema, WSDL, and XBRL files. The XML | Create XML Signature and XML | Verify XML Signature commands, therefore, are available in all XMLSpy views: Text View, Grid View, Schema View, WSDL View, and XBRL View.
How XML signatures work
The entire process, from signature-creation to signature-verification, works as follows:
1.The XML file is signed using either the private key of a certificate or a password. In XMLSpy you can create a signature using the XML | Create XML Signature command. The signature is obtained by processing: (i) the XML document, and (ii) the private key of a certificate, or a password.
2.The signature can be either included with the XML file or stored in a separate file.
3.The signature of the XML file is verified using the public key of the certificate or the password. The verification process works by, first, processing: (i) the XML document, and (ii) the public key of the certificate, or the password, used for signing, and, second, comparing this result with the signature. If the XML file was changed after it was signed, then the verification will fail. In XMLSpy you can verify a signature using the XML | Verify XML Signature command.
The details of how to create and verify signatures in XMLSpy are described in sub-sections of this section:
How certificates are used in XML signatures
To be used with XML signatures, certificates must have a private key and public key. The private key is used to create the XML signature, the public key is used to verify the XML signature.
In a typical scenario, the sender of an XML document has access to the private key of a certificate and creates the XML signature with it. The receiver of the document will have access to the public key of the certificate. This access can be of two types: (i) The sender sends the public key information with the signature; (ii) The receiver has access to a public-key version of the certificate used by the sender.
For more details about certificates, see the sub-section, Working with Certificates.
| Note: | XMLSpy's XML Signature feature supports certificates of type RSA-SHA1, DSA-SHA1, and SHA-256. Signatures that are based on passwords use the HMAC-SHA256 algorithm (XMLSpy 2018 onwards; see Creating XML Signatures). |
XML document validity
If an XML signature is embedded in the XML document, a Signature element in the namespace http://www.w3.org/2000/09/xmldsig# is added to the XML document. In order for the document to remain valid according to a schema, the schema must contain the appropriate element declarations. XMLSpy embeds signatures in two ways:
•Enveloped: The Signature element is created as the last child element of the root (or document) element.
•Enveloping: The Signature element is created as the root (or document) element, and the original XML document element is placed inside a child element of the signature element named Object.
If you do not wish to modify the schema of the XML document, the XML signature can be created in an external file. For more details, see the description of the placement options in the section, Creating XML Signatures.
Given below are excerpts from XML Schemas that show how the Signature element of an enveloped signature can be allowed. You can use these examples as guides to modify your own schemas.
In the first of the two listings below, the XML Signature Schema is imported into the user's schema. The XML Signature Schema is located at the web address: http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsig="http://www.w3.org/2000/09/xmldsig#"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element ref="FirstChildOfRoot"/>
<xs:element ref="SecondChildOfRoot" minOccurs="0"/>
<xs:element ref="ThirdChildOfRoot" minOccurs="0"/>
<xs:element ref="xsig:Signature" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
...
</xs:schema>
A second option (listing below) is to add a generic wildcard element which matches any element from other namespaces. Setting the processContents attribute to lax causes the validator to skip over this element—because no matching element declaration is found. Consequently, the user does not need to reference the XML Signatures Schema. The drawback of this option, however, is that any element (not just the Signature element) can be added at the specified location in the XML document without invalidating the XML document.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element ref="selection"/>
<xs:element ref="newsitems" minOccurs="0"/>
<xs:element ref="team" minOccurs="0"/>
<xs:any namespace="##other" minOccurs="0" processContents="lax"/>
</xs:sequence>
</xs:complexType>
</xs:element>
...
</xs:schema>
W3C Specification
For more details about XML signatures, see the W3C specification for XML signatures at https://www.w3.org/TR/xmldsig-core1/.