Click here to Skip to main content
13,864,785 members
Click here to Skip to main content
Add your own
alternative version


2 bookmarked
Posted 9 Sep 2018
Licenced CPOL

The *AdES Collection, Part 2: XAdES signing for Windows in C++

, 11 Oct 2018
Rate this:
Please Sign up or sign in to vote.
XAdES-B and XAdES-T signing with my AdES and XML libraries


This is a four part article about Advanced Electronic Signatures. The first part talks about CAdES, this part talks about XAdES, the third part is about PAdES and the final part considers ASiC.

My previous article about CAdES used the AdES library to create CMS Advanced Electronic Signatures, a set of extensions to Cryptographic Message Syntax (CMS) signed data making it suitable for advanced electronic signatures.

Using the same library, now you can sign XML data using XAdES, extension to XMLDSIG for signing XML documents.

While XAdES is way more complex than CAdES, it has one benefit: signed XML documents can still be read by encryption-unaware applications.


CMS can sign any sort of binary data, so why a XML specific method? Simply because an application that is not aware of cryptography cannot read its data if they are enclosed in a CMS format. XML signing allows cryptography elements to be present in a XML document while an application can still read its data.

XMLDSIG is a protocol describing how an XML document may be signed. It defines three methods of signing:

  • Detached: the signature resides in another location
  • Enveloping: the signature contains the element to be signed
  • Enveloped: the element to be signed contains the signature as a child node.

A detached XML signature can refer to any sort of data, not just XML.

My library supports all the above signature modes. It uses my XML library, updated to support canonicalization.

Current limitations:

  • No verification
  • No CDatas, namespaces or comments in XML files
  • Supports up to XAdES-XL
  • Hash support SHA-1 and SHA-256

XML Canonicalization

There are unlimited valid representations for the same XML data, for example 

<foo /> equals to <foo></foo>
<foo val="yo" a=   "b" /> equals to <foo  a="b" val="yo" />

Therefore, in order to make sure that hashing does not vary, we have to make XML in canonical form, i.e. a standard 1-1 mapping of the same data to the same XML. This process is really weird, with some of the rules (but not all) below:

  • DocType headers are removed.
  • Elements must not be closed with />.
  • Atrributes are sorted alphabetically, but xmlns: namespaced attributes go first.
  • Specific whitespace is trimmed.
  • Namespace declarations propagade to children (this was a real pain for me in trying to find out why hashing did not match).

A nice practical guide is here. For sake of simplicity, our library does not support CDatas, comments, or namespaces. The official document is here

If you use detached XML signatures to sign a XML file, then this file needs not to be canonicalized, because detached XML signatures can work on plain binary data. However, if you consider detached signatures, why the need of XML signature anyway?


The signing process is as follows:

  • Canonicalization of the element to be signed, if not using detached signatures.
  • Hashing of the element.
  • Creating a SignedInfo element which contains everything to be signed (transforms, message hash, algorithm)
  • Signing of the above element.
  • Creating an element which contains all the information.
<Signature xmlns="">
    <SignedInfo xmlns="">
        <CanonicalizationMethod Algorithm=""/>
        <SignatureMethod Algorithm=""/>
        <Reference URI="">
                <Transform Algorithm=""/>
            <DigestMethod Algorithm=""/>
    <SignatureValue xmlns:ds="">...</SignatureValue>

The reference URI is empty when it is an enveloped signature. For detached signatures, it contains an URI to the data. Note that the signature value is not a complete PKCS#7 message, but only the encrypted hash. Therefore, we cannot use CryptSignMessage to build it, we will use the low level message functions instead (CryptMsgOpenToEncode,CryptMsgUpdate, etc.).

The SignedInfo element can contain as many references as we want, allowing us to sign many portions of data in one operation.

Windows has a CryptXML api to create a XMLDSIG but, since it is useless for XAdES, we will not use it here.


XAdES builds on XMlDSIG with the following rules:

  • All elements are namespaced with ds:
  • SignedInfo element contains references to a set of SignedProperties
  • SignedInfo contains also a reference to the certificate. This allows us to sign in one operation the message, the signed properties and the certificate.
  • Unsigned properties are also added, similar to CAdES. When using XAdES-T, the entire ds:SignatureValue element is timestamped, not just the signature.
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
    <e3 id="elem3"/>
    <e6 a="">
        <e7 b="">
            <e8 c="">
                <e9 d=""/>
    <ds:Signature xmlns:ds="" 

        <ds:SignedInfo xmlns:ds="">
            <ds:CanonicalizationMethod Algorithm=""/>
            <ds:SignatureMethod Algorithm=""/>
            <ds:Reference URI="">
                    <ds:Transform Algorithm=""/>
                <ds:DigestMethod Algorithm=""/>
            <ds:Reference Type="" 

                    <ds:Transform Algorithm=""/>
                <ds:DigestMethod Algorithm=""/>
            <ds:Reference URI="#xmldsig-345B805C-ED11-469F-920A-AA82A6E02876-keyinfo">
                    <ds:Transform Algorithm=""/>
                <ds:DigestMethod Algorithm=""/>
        <ds:SignatureValue xmlns:ds="" 

        <ds:KeyInfo xmlns:ds="" 

            <xades:QualifyingProperties xmlns:xades="" 


                <xades:SignedProperties xmlns:ds="" 



                                    <ds:DigestMethod Algorithm=
                                    <ds:DigestMethod Algorithm=
                                <xades:Description>Indicates that the signer recognizes 
                                 to have created, approved and sent the signed data object
                            <ds:CanonicalizationMethod Algorithm=

This is a valid XAdES-T message containing signed properties and a timestamp.

In the UnsignedAttributes element, more levels can be added (for example, the C level).

Using the code

struct FILEREF
	const char* data = 0; // pointer to data
	DWORD sz = 0; // size, or 0 if null terminated XML
	const char* ref = 0;
	std::string mime = "application/octet-stream";

HRESULT XMLSign(LEVEL lev, std::vector<FILEREF>& data,const std::vector<CERT>& Certificates,SIGNPARAMETERS& Params, std::vector<char>& Signature);


  • lev is a value from the LEVEL enum (XMLDSIG, B,T). If you use XMLDSIG then the XML file is verifiable also with the Windows CryptXML API.
  • data contains the data to be signed. Each structure in the vector has:
    • A pointer to the bytes. If this is XML data and the signing mode is ENVELOPED, then this is a null terminated string and the second tuple parameter (DWORD) is zero. In this case, the data is signed as canonicalized XML and returned in enveloped mode.
    • If the mode is detached, then the two tuple parameters contain the pointer and size to the data, which is signed as raw.
    • The third parameter is the URI reference put in the signature. If this is an enveloped signature and the data is XML, this can be zero.
    • The fourth parameter is the MIME type of the content, by default, application/octet-stream.
  • Certificates contain the certificates to use for signing. If the mode is ENVELOPED, only one certificate is allowed.
  • Params is a structure that defines:
    • Hashing algorithm (default SHA-256, SHA-1 can also be specified)
    • Signing Policy
    • Timestamp parameters (URL, Policy, Nonce, Extensions)
    • The OID of a commitment type (1.2.840.113549. to 6)
  • Signature receives the signature.

If the mode is ENVELOPED, then the returned Signature is a single XMLElement which contains the original data and the enveloped signature.

If the mode is ENVELOPING with 1 certificate, then a single ds:Signature element is returned which contains the signature and a ds:Object element which contains the orignal data. If there are multiple certificates, multiple ds:Signature elements are returned in a <root> root element.

If the mode is DETACHED with 1 certificate, then a single ds:Signature element is returned. If there are multiple certificates, multiple ds:Signature elements are returned in a <root> root element.

For enveloped signatures, multiple signing is not possible for, when you add a signature to a XML element that already contains a ds:Signature element, the first signature will be rendered invalid (the hash of the content would change).

The XAdES file produced by my library validates as 100% correct at the ETSI conformance checker tools :)



  • 14th October, 2018: Changed parameters
  • 23th September, 2018: Added multiple certificate support
  • 22th September, 2018: Added enveloping mode
  • 14th September, 2018: Parameter updating
  • 12th September, 2018: Canonicalization info, ETSI tools
  • 9th September, 2018: First release


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Michael Chourdakis
Greece Greece
I'm working in C++, PHP , Java, Windows, iOS and Android.

I 've a PhD in Digital Signal Processing and Artificial Intelligence and I specialize in Pro Audio and AI applications.

My home page:

You may also be interested in...

Comments and Discussions

-- There are no messages in this forum --
Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web05 | 2.8.190214.1 | Last Updated 11 Oct 2018
Article Copyright 2018 by Michael Chourdakis
Everything else Copyright © CodeProject, 1999-2019
Layout: fixed | fluid