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 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 signatures:

1. Basic signature (BES) and explicit policy signature (EPES). The signature does not include a time-stamp; the signer states the date of the signature. A third party (electronic notary) must endorse the time of the signature and the signature validity.
2. Signature with time-stamp (ES-T). A TSA endorses the date of the signature, and consequently, it can be calculated with precision, whether the signature was generated before or after a possible certificate revocation. Nonetheless, they do not cease to be short-term signatures since they lack tehe evicendes. Therefore, a third party (electronic notary) is required to endorse the validity of the signature at the time of generation.
3. Signature with complete validation data (ES-C). As a means of a basis for long-term verification, the signature includes a set of references to the certificates from the certificate chain and their revocation status (CRLs or OCSPs). A trusted third party (e.g. the CA) shall be required to store certificate status information.
4. Signature with electronic evidence; also known as the archive signature (ES-A). All data required for verifying the signature is included in the signature. Time-stamps are used to maintain the trustworthiness of this data throughout the time. These profile of signatures are the basis for long-term electronic signatures. Unlike the previously mentioned types, these profiles of signatures have the advantage of not requiring any additional data to be retained by trusted third parties for the subsequent verification process.

To produce long-term signatures, all evidence that can be used for the signature's subsequent verification must be stored and maintained, during the signature verification process. In accordance with the above information, this evidence may be included in the 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 signature type and includes the electronic signature maintenance functions in accordance with the standards. 

Signature preservation using TrustedX

The TrustedX services involved in the preservation of electronic signatures are the non-repudiation service and the signature custody service. Both services complement the 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.

The “Electronic signature verification with TrustedX (PKCS#7/CMS, XML-DSig, PDF, S/MIME, CAdES, XAdES and WS-Security)” howto provides a good approximation of how the TrustedX signature verification service operates. The interface of the non-repudiation service follows the OASIS DSS (Digital Signature Service) specification, when, restoring the archive signature (ES-A) from basic signatures (BES, EPES or ES-T), or when, restoring an updated archive signature (ES-A) from a previous archive 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 signature is generated.
• If, however, a long-term signature is provided, data is collected from the trusted third parties and grouped together so as to create a long-term signature on top of the previous one (a more recent and lasting CAdES-A/XAdES-A).

Next, you will see an example of a PKCS#7/CMS signature update request, using the OASIS DSS standard, where the documents to be updated are included in the <dss:VerifyRequest> 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):

<SOAP-ENV:Envelope  Attributes>
<SOAP-ENV:Header>
         ...
</SOAP-ENV:Header>
<SOAP-ENV:Body Attributes>
<dss:VerifyRequest Profile=" urn:safelayer:tws:dss:1.0:profiles:nonrep:1.0:verify"  Attributes>
              ...
<dss:OptionalInputs>
	<dss:ReturnUpdatedSignature Type="urn:oasis:names:tc:dss:1.0:profiles:XAdES:forms:ES-A"/>
</dss:OptionalInputs> 
<dss:InputDocuments>…</dss:InputDocuments> 
<dss:SignatureObject>…</dss:SignatureObject> 
</dss:VerifyRequest> 
</SOAP-ENV:Body>
</SOAP-ENV:Envelope> 

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 signatures, in a transparent fashion, by performing updatesig type operations on the signature, before the signature weakens or expires.

Examples of use of the TrustedX non-repudiation service.

In the try section of this website, you will find examples of code, which you can use to see how TrustedX operates in the case of signature non-repudiation, when obtaining ES-T or ES-A signatures from a basic signature (BES).

Go to discussion forum (1)