This article explains how to verify electronic signatures using TrustedX.

Description of the electronic signature verification process

Details on the procedure for verifying electronic signatures can be found in the ETSI (www.etsi.org), W3C (www.w3.org) and IETF (www.ietf.org) standards. The following are the results that can be obtained by the verification process:

• Signature valid
• Signature not valid
• Verification incomplete

The signature verification procedure includes the following steps:

• Verify the electronic signature production date.
• Obtain and validate the certificates at the time of signing.
• Retrieve the certificate status information at the time of signing (e.g. CRL or OCSP) to check that neither CRLs nor OCSPs have been revoked.
• Verify the integrity of the electronic data using the recognized cryptographic algorithms.
• Check the legal/contractual context, which is expressed through a set of signature policies.
• Check the signer role (for example: sales manager), what type of commitments will he be assigned (for example: is he the author of the document? is he the approver of the document? or, did he merely send, distribute or receive it?) and/or where was the signature produced (for example: in which city).
• Specify the signer's data (e.g. name, surnames, organization, whether natural or legal person, official ID number/VAT, etc.).
• Determine the level of trustworthiness of CAs, VAs and/or TSAs in the corporate context, so as to determine the level of trust of the signature.

One of the problems associated with the implementation of the signature verification procedure is trust management. Among others, one of the most critical trust parameters is CA management; not all CAs offer the same level of technical or legal security guarantees, and, therefore, not all electronic signatures have the same value for the different business processes.

Traditionally, the tools used for implementing security mechanisms do not provide all the functionality required. Therefore, its use affects the application's complexity. One of the basic requirements for implementing security mechanisms is that integration tools must provide all the information in a format that is easy to use, and in a way that is both uniform and intelligible to the applications, regardless of the format and profile of the electronic signature.

On the other hand, and normally, it should be possible to repeat the signature verification process even years after its generation. Therefore, the electronic signature tools must be capable of preserving the properties of signatures over the course of time, in accordance with ETSI and IETF specifications. For details on how to manage the long-term validity of electronic signatures with TrustedX, see the HOWTO Non-Repudiation and Long-Term Signatures (XAdES and CAdES).

Implementation of the signature verification process with TrustedX

Using TrustedX allows the application to completely delegate the logic of the signature verification process to a corporate trust service. In this way, TrustedX will manage the signature policies and the trust of the trusted third parties (TTP), in addition to providing a unique audit system.

Where the application is concerned, verifying an electronic signature will consist in, sending the documents to be verified, to TrustedX, in order to obtain a validity declaration (valid, invalid, incomplete) and a level of trust for the signature. The PKCS#7/CMS, CAdES, XML-Dsig, XAdES, S/MIME, PDF or WS-Security signature formats can be used in documents. If only the validation of a digital certificate is required, the procedure is the same (see howto: “Digital Certificate Validation (X.509v3)”).

As we have already mentioned, TrustedX acts as a trust provider, allowing, therefore, the centralization and application of signing policies at corporate level. For example, trusting a set of CAs, TSAs or certain signature cryptographic algorithms, determining the level of trust for these, and determining how to validate the digital certificate are not decisions that will be made by the application. These are deemed coporate decisions, and, are managed, therefore, by TrustedX.

In this sense, TrustedX provides applications with a uniform trust report on an electronic signature regardless of its format and adapted to the policies that have been corporately established. This notably improves the corporation’s trust management, since it is centralised in TrustedX rather than individually in multiple applications.

TrustedX services are provided as Web services and are accessed via SOAP/WS, REST/WS, or via the TrustedX Java API. To learn about the different integration architectures of TrustedX, consult the howto “TrustedX Integration Architectures”.

Next, you will see an example of a PKCS#7/CMS signature verification request, using the OASIS DSS standard, where the documents to be verified include the <dss:VerifyRequest> element:

<SOAP-ENV:Envelope  Attributes>
<SOAP-ENV:Header>
...
</SOAP-ENV:Header>
<SOAP-ENV:Body Attributes>
<dss:VerifyRequest Profile="urn:safelayer:tws:dss:1.0:profiles:cmspkcs7sig:1.0:verify"  Attributes>
<dss:OptionalInputs>…</dss:OptionalInputs> 
<dss:InputDocuments>…</dss:InputDocuments> 
<dss:SignatureObject>…</dss:SignatureObject>
</dss:VerifyRequest>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope> 

The response from TrustedX will be an XML document, indicating the results of the signature verification. This document also contains the signer information (for example: name, department, role, etc....) and may include full data on the digital certificates, as well as time-stamps and the CRL/OCSP responses used. Once the signature has been verified, TrustedX can also return the signature, updated with the time-stamp and the electronic evidence on the status of the digital certificates, in accordance with the ES-T, ES-C and ES-A formats defined in CAdES/XAdES.

In the response information of the signature verification, TrustedX includes a specific diagnosis on the level of trust of the signature as determined by the system. This diagnosis is expressed in a decimal value 0 (low trust), 1 (medium trust), 2 (trustworthy) or 3 (highly trustworthy), and in a textual value called trust label (for instance DNIe, FNMT Class2, Verisign Class3, etc.). Thus, applications can ignore any indication of complexity associated with the signature’s trust (signature formats, certificates, CRLs, etc.) and simply and exclusively focus on a decimal value and text string.

Examples of use of TrustedX

In the try section of TrustedX Labs, you will find a collection of example codes, which show how TrustedX operates in relation to the various aspects of signature verification.

Go to discussion forum (1)