When delving into the world of electronic signatures, it is almost unavoidable to come across the topic of different electronic signature formats. Today, there are numerous European standard solutions (e.g. CMS-based CAdES and PAdES signatures or, more recently, the JSON-based JAdES format), but the most commonly used format is still XAdES (XML Advanced Electronic Signature) that is based on the XML file format. As an electronic signature user, electronically signed documents are typically viewed with an electronic signature handling application.

However, this article is intended for electronic signature professionals who are also interested in what is "under the hood," i.e. what can be found in an electronic signature file. This article provides an overview of how an XAdES signature is constructed and what types of XAdES signatures exist.

The baseline levels and components of XAdES are defined by the ETSI EN 319 132-1 standard, while the extended XAdES levels are defined by the ETSI EN 319 132-2. An electronic signature that meets the XAdES standard can be created at different levels, depending on whether the signature only contains the most basic data or also contains additional information. Accordingly, we distinguish between XAdES-B (Basic), XAdES-T (Timestamp), XAdES-LT (Long-Term data) and XAdES-LTA (Long-Term data with Archive timestamp) signatures. Of these, the -LT level is relatively rarely encountered in practice, so the following will focus on the -B, -T, and -LTA levels.

Each level has an attached signed document in the e-dossier (.es3) format, each of which contains a XAdES signature. These can be opened with a simple text editor, and the characteristics of each level can be observed in the ds:Signature element.

XAdES-B

The XAdES-B, or basic level, contains the most basic elements that an electronic signature must contain, i.e. only the identifier of the algorithms used, the signer's certificate, and in the case of EPES (Explicit Policy based Electronic Signature - see ETSI EN 319 132-2), the signature policy identifier appear in the signature. In addition, the signature timestamp, location, type of commitment, signer's role and format of the signed document can be given as optional.

Since a timestamp is not placed in signatures created at the XAdES-B level, it is important to note that the validity of the signature is limited only to the validity period of the certificate used for creation. This period is currently three years in Hungary for qualified electronic signatures. To make our signature valid beyond this time, it is necessary to place a timestamp on the signature as well.

[B.es3]

In the example, the identifier of the signature algorithm is the value of the Algorithm parameter within the ds:SignatureMethod element (i.e. ecdsa-sha256), and the PEM-encoded certificate can be found in the <CertificateValues> child element of the last ds:Object.

XAdES-T

A XAdES-T, or timestamp level, contains all of the basic elements of XAdES-B, but in addition to this, a timestamp is placed on the signature, which proves that the given file existed at the given time (that is, at the moment of timestamping).

Since the certificate of the time stamp authority is usually issued for a longer period (up to more than 10 years) than the signer's certificate, the timestamped electronic signature also has a much longer validity period than in the case of XAdES-B. In the case of timestamping authority certificates, the responsibility of the service provider is to issue these using a cryptographic algorithm that is sufficiently secure in the long term. Currently, algorithms that use elliptic curve cryptography (ECC) are considered to be such. Therefore, it is recommended that in practice we create at least a XAdES-T level (i.e. containing a time stamp) electronic signature on our documents.

[T.es3]

In the example, the value of the timestamp can be found as the value of <SignatureTimeStamp> within the last ds:Object element.

XAdES-LTA

XAdES-LTA (Long-Term Data with Archive Timestamp) signatures contain additional information compared to XAdES-T level elements, such as revocation information regarding the signer's certificate, the time stamps on them, the complete certificate chain of the signer's certificate and that of the provider issuing the revocation information, the complete certificate chain of all time stamp providers and all revocation information for each element of the certificate chain. These are protected by an external, so-called archive time stamp.

This type of signature already contains all the data that can be obtained after the signature is created to facilitate future validation, but some information must still be obtained when the LTA signatures are checked later (e.g. whether the cryptography algorithm used has not become obsolete or whether the key of the time stamp authority that created the archive time stamp has not been compromised).

Due to the possibility of cryptographic weaknesses, a new archive time stamp must be placed on the signature before any occur, requiring regular "maintenance" of the archive signature. This can be done by the signer independently, but it can be costly and involves great responsibility and continuous tasks. A simpler solution is for a qualified archiving service provider to perform this task, not only freeing the user from responsibility, but also providing legal protection in case of litigation, as in the case of "independent" archiving, the archiver must prove that they acted properly in archiving the files, while in the case of a certified archiving service provider, this is presumed.

[LTA.es3]

If we open the attached example, we can see that it is already more extensive at first glance than the previous two. We can see numerous certificates in the <EncapsulatedX509Certificate> elements, and we can discover the revocation information (in this case OCSP information) in the values within the <RevocationValues> element, which is immediately followed by the <ArchiveTimeStamp> element containing the archive timestamp.