For more information and all parts of the series visit Introduction to eIDAS package for SignServer.
AdES stands for Advanced Electronic Signature. It is an electronic signature format that has met the requirements set forth under eIDAS regulation. These formats are technically implemented as a Baseline Profiles defined by the European Telecommunications Standards Institute (ETSI).
It includes the following eSignature baseline profiles:
(PDF Advanced Electronic Signature) Baseline Profile
(XML Advanced Electronic Signatures) Baseline Profile
(CMS Advanced Electronic Signature) Baseline Profile
Digital Signature Service framework
Digital Signature Service (DSS) framework is an open-source library for electronic signature creation and validation developed and provided by CEF Digital. Implementation of the AdES baseline profiles and signature formats is part of the DSS library. It supports all baseline levels:
B-B level provides requirements for the incorporation of signed and some unsigned attributes when the signature is actually generated.
B-T level provides requirement for the generation and inclusion of a trusted token for an existing signature, proving that the signature itself actually existed at a certain date and time.
B-LT level provides requirements for the incorporation of all the material required for validating the signature in the signature document. This level aims to tackle the long-term availability of the validation material.
B-LTA level provides requirements for the incorporation of time-stamp tokens that allow validation of the signature long time after its generation. This level aims to tackle the long-term availability and integrity of the validation material.
SignServer and DSS framework
AdES module for the SignServer seamlessly integrates the DSS framework libraries within the standard interfaces of the Signer Workers. Therefore, it is possible to achieve the same signature formats and compliance level.
Implementation class for the PAdES, XAdES, CAdES, or ASiC, is configured in the Signer together with other relevant properties, including the Crypto Token or internal TSAs. Integration of SignServer and DSS framework gives you all benefits of centralized mature signing solution with eIDAS compliant signature formats.
The table below specifies various signature possibilities available in DSS signature’s profiles/formats:
PAdES SignServer configuration
Let’s take a look at a sample configuration of the PAdES Signer in the SignServer. As an example, we will take a PAdES B-LTA signature format and will go through the properties which should be configured. We are not going to describe the CryptoToken, or other Signer related properties and interfaces. You can find more about it in the SignServer documentation.
“company.threekey.signserver.module.pades.signer.PAdESSigner” is the implementation class of the PAdES Signer, which contains the integration with the DSS framework and extends the Worker interface of the SignServer. If you would like to use the PAdES Signer, you must specify this property. The PAdES Signer will check its configuration properties, which follows.
The signature level property specified the desired baseline level of the signature. In this case, we would like to create a PDF files with the B-LTA signature format and level. However, you can change the level at any time. All levels are supported:
As we would like to use the B-LTA for long-term archiving of signed PDF files, we need a timestamp. For this purpose, we have to configure the TSA. TSA can be external, or provided internally by SignServer:
- TSA_URL property is used for external TSAs
- TSA_WORKER property is used to reference the name of internal TSA running in the SignServer
TSA usually needs authentication. You can use both Basic Authentication or authentication using client certificate:
- for Basic Authentication you’ll need to configure TSA_USERNAME and TSA_PASSWORD
- for client certificate-based authentication you’ll need to configure the keystore and truststore to establish the connection. The PAdES Signer supports this through TSA_KEYSTORE_TYPE, TSA_KEYSTORE_FILEPATH, TSA_KEYSTORE_PASSWORD, TSA_TRUSTSTORE_TYPE, TSA_TRUSTSTORE_FILEPATH, TSA_TRUSTSTORE_PASSWORD
To achieve B-LTA, we need to include all information regarding the identity of the signatory to be able to validate the signature over time, even when the CA or TSA is not operational anymore. It means that the complete trusted chain and revocation information must be included in the resulting PDF document. All information must be available for each certificate, including the TSA. The prerequisite here is to have the information about the issuing CA contained in the AIA of the certificate and the URI for the CRL or the OCSP responder.
We have 2 options that can be used and at least one of them must be configured:
- EMBED_CRL – revocation information is downloaded from the CRL location defined in the certificate
- EMBED_OCSP_RESPONSE – OCSP response is included from the URI contained in the certificate
eIDAS compliant remote signing
Using the AdES module for the SignServer you can start signing documents and data with all benefits of centralised signing solution and in a compliant way according the eIDAS regulation.
This powerful combination gives you the ability to remotely sign on the advanced or qualified signature level within a few minutes. If you would like to see how easy and flexible the solution is, do not hesitate and ask for the demonstration!