PKI And Digital Signature. Part II: Digital Signature as a Service


In the last post we talked about the Fexco PKI and the service of Digital Identity founded on a new concept based on a combination of vetting, certificates, keys, Authorization Server and secure practices that allowed us to maintain successfully a community of users free from hacking by impersonation techniques.

In this post we are going to talk about a meaningful service that can be possible ONLY if you have available this Identity Management system first: Secure Digital Signature.

What is Digital Signature?

Obviously, you’ll need some background to understand what a Digital Signature is.

Alice and Bob are still using this way to talk. It’s really awkward.

Basically, you (Alice) have a document. You can sign the document (using certain tools, that’s the question) that basically means you has to:

  • Calculate a hash from the content (bytes) of the document (we assume it is an electronic document, e.g. a PDF file) by using some algorithm (you can find a good article here).
  • Encrypt the hash with your private key. To do this properly, we have to assume you have a valid X509 certificate (please read our last post if you have any question in this subject). This information is included along with the old content of the document, that has been modified.
  • Then, send the document to Bob. He can verify that Alice was the author of the document by decrypting the encrypted hash with Alice’s Public Key (which is publicly available).

So, probably this other diagram is more accurate:

We can add some complications to this really simple scenario:

  • There are several signatories.
  • They want to see their signatures onto the document even when the document is printed.
  • You want to lock the document to new signatures.
  • We want to verify that the document and the signatures contained are valid, they are not broken because the document content changed AFTER some signature was applied.
  • The documents have to be audited and reviewed, with immutable recording of all actions to support the signatures on documents because the legal validity of the documents can be challenged on court.

Real life scenarios make things more complicated, as you can see, and that’s why a professional systems comes on our help.

eIDAS and Other Regulations

The EU released the eIDAS regulation as one of the most advanced attempts to regulate and ensure the quality and security in Digital Signature operations in the EU territory. It is a true big start and a signal of maturity for Digital Signatures in the European economy and European relationships. It distinguishes between three types of digital signatures considering the authority level that issues the digital identities (e.g. a X509 certificate, but not only).

Types of signatures in eIDAS

If we strictly look at the Regulation (EU) No 910/2014 (eIDAS), the three types of electronic signatures are defined as:

Simple or Basic electronic signature (SES). All electronic types of signatures that proves acceptance or approval by the signer by using some sort of certificate

Advanced Electronic Signature (AES). Article 26. These requirements are

  • It is uniquely linked to the signatory
  • It is capable of identifying the signatory
  • It is created using electronic signature creation data that the signatory can, with a high level of confidence, use under his sole control
  • It is linked to the data signed therewith in such a way that any subsequent change in the data is detectable.

So, an independent, private and auditable (by EU) service counting on a reliable Identity system, following Personal Data regulations could provide Advanced Signatures compliant with eIDAS.

Qualified Electronic Signature (QES) “means an advanced electronic signature that is created by a qualified electronic signature creation device, and which is based on a qualified certificate for electronic signatures”. Basically, the qualified electronic signature is one based on a Qualified Certificate that can be provide only by Qualified Providers. There is a list in each country in the EU and as I said only these entities are certified to provide Qualified Certificates.

National regulations more or less fit into this definition. For instance, the legal basis for electronic signatures in Ireland are the Electronic Commerce Act, 2000 and the statutory instrument issued Electronic Commerce (Certification Service providers Supervision Scheme) Regulations 2010, S.I. No.233 of 2010.

Signature Baselines

About digital signatures according to eIDAS is important to know previously what types of baselines you can provide. There are 4 types of signatures regarding their baselines and hardness:  

  • B: Basic Electronic Signature The lowest and simplest version just containing the SignedInfo, SignatureValue, KeyInfo and SignedProperties. This level combines the old -BES and -EPES levels. This form extends the definition of an electronic signature to conform to the identified signature policy.
  • T: Signature with a timestamp A timestamp regarding the time of signing is added to protect against repudiation.
  • LT: Signature with Long Term Data Certificates and revocation data are embedded to allow verification in future even if their original source is not available. This level is equivalent to the old -XL level.
  • LTA: Signature with Long Term Data and Archive timestamp By using periodical time stamping (e.g. each year) compromising is prevented which could be caused by weakening previous signatures during a long-time storage period. This level is equivalent to the old -A level.  

The EU DSS Project

EU’s CEF Digital supports the EU DSS framework

EU DSS is a framework developed and published by the EU to make possible to Third Parties the implementation of custom solutions involving Digital Signatures being compliant with eIDAS regulation. The framework is HUGE! and it integrates some Open Source tools that will make your life much easier. Besides, the level of integration and quality is really high.

EU DSS. A public framework, top-quality level, freely available.. It’s Amazing!

EU DSS supports several technical specifications for digital signatures. These are the main features:

  • XAdES detached and enveloping signatures can be used to sign any file.
  • XAdES enveloped signature can be used to sign an XML file.
  • PDF files can be signed with an enveloped PAdES signature.
  • CAdES enveloping or detached signatures can be used to sign any arbitrary files.
  • ASiC-S or ASiC-E containers can be used to sign at least one document.
  • The multiple parallel signatures can be created.
  • A user can use PKCS#11-compliant QSCD, MS-CAPI, MOCCA and PKCS#12 to sign.
  • Any kind of signature: CAdES, PAdES, XAdES, ASiC-S or ASiC-E can be validated.
  • A validation policy can be applied.
  • Two validation reports are available: Simple and Detailed.
  • The Diagnostic Data representing each static information used during the validation process is available.

We strongly recommend reading the EU DSS documentation as it is really extensive and detailed with tens of examples.

To start using EU DSS in your application the first step is to import its dependencies. In our case E-Sign imports several dependencies focused on PAdES:

libraryDependencies += "commons-logging" % "commons-logging" % "1.2"
val sdDssVersion = "5.5.RC1"
lazy val excludeCommonsLogging = ExclusionRule(organization = "commons-logging", name = "commons-logging")
libraryDependencies += "" % "dss-service" % sdDssVersion excludeAll(excludeCommonsLogging)
libraryDependencies += "" % "dss-model" % sdDssVersion
libraryDependencies += "" % "dss-spi" % sdDssVersion
libraryDependencies += "" % "dss-token" % sdDssVersion
libraryDependencies += "" % "dss-tsl-validation" % sdDssVersion
libraryDependencies += "" % "dss-utils-apache-commons" % sdDssVersion
libraryDependencies += "" % "dss-pades" % sdDssVersion
libraryDependencies += "" % "dss-pades-pdfbox" % sdDssVersion excludeAll(excludeCommonsLogging)

The Fexco API Solution

The main features of the Fexco solution are:

  • eIDAS compliant with Advanced Signatures.
  • It provides the 4 types of baselines, which is not trivial and dramatically important if you’re looking for full legal validity.
  • It provides multi-signatory scenarios.
  • It provides document sealing and closing features.
  • The Fexco API includes the immutable E-Ledger as a co-substantial part of the PKI/Digital Signature service, offering the full history of events in time.
  • Full life cycle support, from the creation of the Digital Identity to the validation of signatures.

The Fexco API includes the immutable E-Ledger as a co-substantial part of the PKI/Digital Signature service, offering the full history of events in time.

The main concept for consumers is the Digital Signature Request (DSR). Please find below the description of the DSR:

We’ll see now some key aspects of this service.


There are some important lessons learnt that we have to bear in mind:

  • If you add a comma to the document AFTER you apply a signature you are breaking it. In fact, you break ALL the signatures in the document.
  • The only change you can make is to add new signatures. Not the digital signature nor its visual representation are considered as a part of the document’s content. This allows to add multiple digital signatures.
  • Multiple digital signatures can be applied to the document, but not simultaneously

Application of multiple signatures is always a sequential process

Above diagram is really explicit. It displays the process of addition of modifications to the document with every new addition of a signature. Because the signing action is partially based on the calculation of the hash a second signature signs the content of the document including the first signature. A third signature validates the content and the first and second signatures. That is the main reason behind the constraint about the concurrent simultaneous application of several signatures on the same document.

So, this constraint makes us to protect the file against eventual Digital Signature Request. In fact, you have to maintain several versions of the document (which is the “logical” document) according to the sequentially applied signatures that can happen along a period of time.

Visual representations of signatures

Eventually you can be required to represent the applied digital signatures on a given document. It is remarkable the frequency and volume of the remnant usage of printed files on paper. Please, do not do that. Use the electronic files. However, it seems there still are many institutions and companies using paper documents.

Anyway, if you have to meet this requirement you’ll have to include the so-called Visual Representations (VR) of the digital signatures. Some caveats:

  • VRs are NOT the digital signatures. The only source of Truth is the digital signature.
  • Ideally the VR is merely informative, not pretending it is the only real signature.
  • VRs are part of the signature and therefore they do not break previous signatures.

VRs are NOT the digital signatures. The only source of Truth is the digital signature.

You can see here how Adobe Acrobat Reader display the REAL digital signature in the Signature Panel. We have inserted a VR onto the document. If the signature has not a VR you’d be able to see the signature only if you open the document using a PDF browser.

Let’s see some code

Below snippet shows how the DSS project has been integrated into our E-Sign component. Please, have a look and read the comments. DSS has been written in Java and therefore it can be used in JVM languages project with no restriction. We have used Scala to write the E-Sign component.

What happens later?

Once the signature has been applied into the document you’ll need a PDF browser to be able to inspect the components in the digital signatures.

The most popular PDF browser is Adobe Acrobat Reader but there are others that are really good. It depends on your OS and preferences. We’ll use Acrobat Reader for the next examples.

Acrobat Reader Signature Panel has several constraints. It is a proprietary system and it does not integrate well with OSs. You have to trust on certificates on Acrobat because it manages the certificates and keys in an independent way.

It would be brilliant to have a full integration with the key store in your OS. In this case the user could download the root CA certificate and all certificates issued by this CA should be automatically trusted. However, this is possible ONLY in the Acrobat scope.

To inspect the certificate can be the first thing to do.

You can even open the information about the Timestamp Authority (TSA).


  • Digital Signatures are not trivial. This subject requires tons of materials and time of research.
  • A pure and specialized component is not enough. The signatures and documents can be challenged in court. The signatures can be repudiated (the signer assures he/she never signed that document).
  • You need a PKI, a Digital Identity system to manage and provide certificates and keys. Besides, you need to proof the real identity of natural persons, avoiding any chance of impersonation.
  • You need an immutable data system (E-Ledger) to backup your digital signatures by providing secure stored events in time.
  • Only when you have all this rig you can say you are providing a Digital Signature service to deserve the trust of your partners and customers.

Do not forget to send us your thoughts and questions in the comments section. Cheers!

Author: Jesus de Diego

Software Architect and Team Lead

2 Replies to “PKI And Digital Signature. Part II: Digital Signature as a Service”

  1. Really good explanation Jesus, and a clear example of how we can build for multiple re-use and productise features and capabilities through smart design at the outset.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.