This article explains how to guarantee the long-term validity of electronic signatures with TrustedX.
Electronic signature preservation
It should be possible to repeat a electronic signature verification service, even years after its generation. Given that algorithms, keys and other cryptographic elements can become vulnerable over time, electronic evidence is considered to be temporary; and, therefore evidence must be renewed (i.e. evidence that was once valid, is rendered invalid as of a certain point in time).
IETF's (Internet Engineering Task Force) RFC 3126, 2001, explains how to solve this problem. The solution was also later adopted by the ETSI (European Telecommunications Standards Institute) XAdES and CAdES standards. TrustedX recognizes the XAdES and CAdES standards and makes a distinction between four basic blocks of electronic signatures:
- Basic electronic signature (BES) and explicit policy electronic signature (EPES). The electronic signature does not include a time-stamp; the signer states the date of the electronic signature. A third party (electronic notary) must endorse the time of the electronic signature and the electronic signature validity.
- Electronic signature with time-stamp (ES-T). A TSA endorses the date of the electronic signature, and consequently, it can be calculated with precision, whether the electronic signature was generated before or after a possible digital certificate revocation. Nonetheless, they do not cease to be short-term electronic signatures since they lack tehe evicendes. Therefore, a third party (electronic notary) is required to endorse the validity of the electronic signature at the time of generation.
- Electronic signature with complete validation data (ES-C). As a means of a basis for long-term verification, the electronic signature includes a set of references to the digital certificates from the digital certificate chain and their revocation status (CRLs or OCSPs). A trusted third party (e.g. the CA) shall be required to store digital certificate status information.
- Electronic signature with electronic evidence; also known as the archive electronic signature (ES-A). All data required for verifying the electronic signature is included in the electronic signature. Time-stamps are used to maintain the trustworthiness of this data throughout the time. These profile of electronic signatures are the basis for long-term electronic signatures. Unlike the previously mentioned types, these profiles of electronic signatures have the advantage of not requiring any additional data to be retained by trusted third parties for the subsequent verification process.
To obtain CAdES and XAdES long-term electronic signatures, during the electronic signature verification process, all the evidences required for later verification must be saved and preserved. In accordance with the above information, this evidence may be included in the electronic signature itself; or it may be necessary to store the evidence in external systems, which would limit the portability of electronic signatures. In TrustedX, the implementation of functions for preserving the electronic signatures is based on the ES-A electronic signature type and includes the electronic signature maintenance functions in accordance with the standards.
Furthermore, the ETSI has recently published the PAdES technical specification (ETSI TS 102 778). This specification comprises five parts and defines a set of profiles (PAdES-CMS, PAdES-BES, PAdES-EPES, PAdES-XML and PAdES-LTV) that describe how to use the support for PDF digital signatures (ISO 32000-1) so that the electronic signatures included in a PDF document are regarded as advanced electronic signatures, as per Directive 1999/93/CE of the European Parliament and its implementations to the legislation of Member States (e.g., Law 59/2003 on Electronic Signature in the case of Spain). These profiles give the PDF digital signatures the same characteristics as the CAdES (TS 101 733) and XAdES (TS 101 903) (XAdES) digital signatures, including the support for validating signed documents stored over long periods.
On the base of a PDF file that contains electronic signatures built using the PAdES-CMS, PAdES-BES, PAdES-EPES or PAdES profiles, the data structures (Document Security Store and Document Time-stamp) defined by PAdES-LTV for updating the PDF so the validity of its electronic signatures are preserved for any length of time can be used. This gives the PDF digital signatures the same long-lasting characteristics as the CAdES-A and XAdES digital signatures.
Electronic signature preservation using TrustedX
The TrustedX services involved in the preservation of electronic signatures are the non-repudiation service and the electronic signature custody service. Both services complement the electronic signature verification service and both can be accessed as Web services. Consequently, where the application is concerned, preserving electronic signatures is as simple as consuming a service.
In “Electronic signature verification with TrustedX (PKCS#7/CMS, XML-DSig, PDF, S/MIME, CAdES, XAdES and WS-Security)” it is provided a good approximation of how the TrustedX electronic signature verification service operates. The non-repudiation service interface follows the OASIS's DSS (Digital Signature Service) specification for returning, in the case of the CAdES, XAdES and PAdES, an archive electronic signature (ES-A) from a basic electronic signature (BES, EPES or ES-T), or an updated archive electronic signature (ES-A) from a previous archive electronic signature (ES-A).Updates to ES-T and ES-C are also permitted.
The process is as follows:
- Data from trusted third parties (revocation and time-stamp information) is added to a signature (e.g. a CMS/PKCS #7 or XML-DSig). Finally, an advanced long-term CAdES-A/XAdES-A/PAdES-LTV electronic signature is generated.
- If, however, a long-term electronic signature is provided, data is collected from the trusted third parties and grouped together so as to create a long-term electronic signature on top of the previous one (a more recent and lasting CAdES-A/XAdES-A/PAdES-LTV).
Next, you will see an example of a PKCS#7/CMS electronic signature update request, using the OASIS DSS standard, where the documents to be updated are included in the element. It will be possible to indicate to TrustedX which type of update is to be performed, i.e. ES-T, ES-C, ES-A or updatesig (automatic):
<dss:VerifyRequest Profile=" urn:safelayer:tws:dss:1.0:profiles:nonrep:1.0:verify" Attributes>
In turn, the non-repudiation service is complemented by the TrustedX electronic signature custody service. This TrustedX service will be responsible for storing and maintaining the electronic signatures. The service will be in charge of storing and updating the electronic signatures, in a transparent fashion, by performing updatesig type operations on the electronic signature, before the electronic signature weakens or expires.