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 digital 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 digital 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 digital 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 digital signature.
One of the problems associated with the implementation of the digital 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 digital signature verification process even years after its generation. Therefore, the electronic signature tools must be capable of preserving the properties of digital 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 Non-Repudiation and Long-Term Digital Signatures (XAdES, CAdES and PAdES).
Implementation of the electronic 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 electronic signature. The PKCS#7/CMS, PDF digital signature, S/MIME, CAdES, XAdES, PAdES or WS-Security electronic signature formats can be used in documents.
If only the validation of a digital certificate is required, the procedure is the same.
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 electronic 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 electronic signature verification request, using the OASIS DSS standard, where the documents to be verified are included in the <VerifyRequest> element:
<dss:VerifyRequest Profile="urn:safelayer:tws:dss:1.0:profiles:cmspkcs7sig:1.0:verify" Attributes>
The response from TrustedX will be an XML document, indicating the results of the electronic 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 electronic signature has been verified, TrustedX can also return the electronic 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.
In the response information of the electronic signature verification, TrustedX includes a specific diagnosis on the level of trust of the electronic 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 electronic signature’s trust (electronic signature formats, certificates, CRLs, etc.) and simply and exclusively focus on a decimal value and text string.