Safelayer Secure Communications
 
 
Search
Home arrow How to arrow Digital Signatures in Documents (OASIS DSS) arrow Digital Certificate Validation (X.509v3)


TeleTrust Innovation Price

Innovation Award
for TrustedX 2007

The European ICT Price. Nominee

for TrustedX 2007

Safelayer Labs
 
How To

Digital Signatures in Documents (OASIS DSS)

Digital Certificate Validation (X.509v3)

This article explains how to validate digital certificates using TrustedX.

Description of the digital signature validation process

The digital certificate verification procedure is outlined in the ITU-T x509v3 standard. The results of this procedure can be:

  • Certificate valid. The certificate has been issued by a CA, it has not expired and it has not been revoked.
  • Certificate invalid. The certificate has been issued by a CA that is not trusted, it has expired, or it has been revoked.
  • The validation cannot be completed.

The procedure consists in:

  • Validating all the certificates in the certificate chain.
  • Verifying the level of trust of the different CAs and VAs used, to check the certificate status (e.g. to determine which level of privileges will be granted to the user).
  • Analysing the data included in the certificates.
  • Specifying the user's data (e.g. name, surname, organization, whether natural or legal person, NIF/CIF/VAT, etc.)

Certificate chain building, digital certificate status verification, and the later certificate parsing and data interpretation, are common procedures to all the applications. Nonetheless, trust management (i.e. defining which CAs will be recognized in each corporate context) is a critical issue, which must be carried out in an orchestrated, easy-to-audit manner, and which, must be in accordance with the corporate security policies.

Implementation of the certificate validation process with TrustedX

Where the application is concerned, the implementation of the certificate validation process will only, and exclusively, consist in the consumption of a TrustedX service. Furthermore, it is in the TrustedX configuration that the corporate certificate validation policies are applied (e.g. which CAs are recognized, how the status of a certificate must be checked and which data must be interpreted); the level of trust of the trusted entities is also maintained here.  

In this way, the validation of a digital certificate will consist in sending a document to TrustedX and in delegating the tasks of diagnosing the level of trust of the certificate and executing any other operation relating to the digital certificate (e.g. obtaining the certificate data) to TrustedX.

TrustedX recognizes different integration architectures and its services can be used as SOAP/WS or as REST/WS (see howto “TrustedX Integration Architectures”). As in the case of the electronic signature verification services, the OASIS DSS specifications are recognized (see the howto “Electronic signature verification with TrustedX (CMS, XML-DSig, PDF, S/MIME, CAdES and XAdES)”.

Next, you will see an example of a validation request for an X.509 certificate, which uses the OASIS DSS standard, and where, the certificates include the <dss:VerifyRequest> element. In addition to the validation result, the response will include a diagnosis of the level of trust of the certificates (<css:TrustInfo> and  <css:TrustInfoSummary>elements):

<SOAP-ENV:Envelope Attributes>
  <SOAP-ENV:Header>
           ...
  </SOAP-ENV:Header>
  <SOAP-ENV:Body Attributes>
  <dss:VerifyRequest Profile=" urn:safelayer:tws:dss:1.0:profiles:certstatus:1.0:verify"  Attributes>
                ...
  </dss:VerifyRequest>
  </SOAP-ENV:Body>
  </SOAP-ENV:Envelope> 
      

In elements <TrustInfo> and <TrustInfoSummary>, TrustedX includes a specific diagnosis of the level of trust determined by the system for each certificate (as many <TrustInfo> as certificates). 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.). A summary diagnosis is also included (in the <TrustInfoSummary> element) that expresses the lowest level of trust achieved (NOTE. The overall strength of a chain is equal to the strength of its weakest link). Thus, applications can ignore any indication of complexity associated with the signature’s trust (certificates, CRLs, OCSPs, etc.) and simply and exclusively focus on a decimal value and text string.

Examples of use of TrustedX

In the try section of this website, you will find a collection of examples of code, which show how TrustedX operates when validating certificates.