In previous blog posts on crypto, we discussed the signing of documents with tokens and proposed a simple tool to check the content of a PKCS#11 token. We also introduced digital signatures, X509, ASN.1, CMS, PDF and ETSI standards for signatures.

In this post, we introduce another free application to sign XML documents with PKCS#11 tokens or PKIX / PFX keys. The application is a proof of concept (PoC) because it has not been tested with all national variants for XML invoice signatures.

eXtended Markup Language (XML) signature for invoices

XML is a widespread format used in more and more applications and it is then not surprising to see it used for invoices, together with PDF, or even embedded in PDF invoices as in the Factur-X standard.

So the XML Advanced Electronic Signature (XAdES), based on XMLDIG-SIG, is the standard way to sign XML documents. XAdES standards have been published by ETSI and adpoted by the EU under the eIDAS regulation (many non EU countries have also adopted it).

XAdES can be used in three modes: detached, enveloping and enveloped. In the detached mode, the signature is stored in a separate section or document. In the enveloping mode, the signature wraps the original document. Finally, in the enveloped mode, the signature is added to the original document before the end of the main node.

Everything would be simple if the standard did not mandate the use of a "canonicalization" function to transform each XML document, using specific rules. This transformation is required so that a file is processed the same way by all tools. However some transformation rules are not straightforward and their application sometimes lacks logic. For what it's worth, to me, XML canonicalization is one of the worst existing standards to implement.

Here are the requirements to process an XML file before signing it:

• Encode the document in UTF-8 (we don't support all characters yet)
• Normalize line breaks to #xA on input, before parsing
• Normalize attribute values, as if by a validating processor
• Replace character and parsed entity references
• Replace CDATA sections with their character content
• Remove XML declaration and document type declaration (DTD)
• Convert empty elements to start-end tag pairs
• Normalize whitespace outside of the document element and within start and end tags
• Retain all whitespace in character content (excluding characters removed during line feed normalization)
• Set attribute value delimiters to quotation marks (double quotes)
• Replace special characters in attribute values and character content by character references
• Remove superfluous namespace declarations from each element
• Add default attributes to each element
• Organize the namespace declarations and attributes of each element in lexicographic order
• When canonicalizing a subset of a document (e.g., SignedProperties), propagate the XML namespaces (starting with xmlns) from the parent elements that have been omitted

Moreover, there are specific constraints on signatures added by national policies that need to be taken into account (such as name space values or algorithm types) when submitting invoices to an official system.

Using the tool

The TMSSigner tool is built on TMS Cryptography Pack 5.x to sign with XAdES (for XML files), PAdES (for PDF files) and CAdES (for any type of file). We are focusing here on XAdES that has a few extra options.

We have added the Template property to the XAdESObj class in v5.0.9.2 to take national policies into account, as opposed to developing a "one size fits all" version for all invoicing systems. Three cases are proposed: Basic, Spanish and Polish. Basic is the default template found in XAdESTemplate.pas. The Spanish template is separate and rather different to comply with national requirements (e.g., using SHA1 and SPI), whereas the Polish template is a variant of the Basic one.

For the Spanish template, the user role (supplier, customer, third party) shall be selected and added to the invoice. We may add more templates in future releases to comply with other national requirements.

Then the key and certificate shall be selected either from PKIX (PEM) or PFX files, or preferably from a PKCS#11 token. Note that if the certificate trust chain is not provided, as with a self-signed certificate, the signature verification will succeed but the document validation will fail (i.e., the invoice will be rejected by the national system).

To validate a signed document, anyone can create a free account on the ETSI web conformance checker (https://signatures-conformance-checker.etsi.org/) or use the EU web signature demo (https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/validation). National invoicing systems usually have a web site to validate signed test invoices.

Conclusion

TMSSigner is a free app running on Windows to sign files and the ZIP file for the 64-bit version can be downloaded here. Full Delphi source code is provided as part of a larger demo (in the "Demo" directory of the library!). All algorithms can be used in console mode, with the VCL or with FMX.

TMS Cryptography Pack 5.0 (available to all users with an active TMS Cryptography Pack license) implements all required algorithms to sign / verify and encrypt / decrypt data according to the most common EU / ETSI / NIST standards. So far, support for XAdES is restricted to the ETSI Baseline profile and canonicalization requirements are not all implemented. This will be improved over time (e.g., UTF-8 codes support will be extended).

Feel free to download the app and test a signed invoice against your national invoicing system. Feedback on tests will be appreciated.