The electronic signatures cross-border recognition service based on a trusted third party
In the era of the advent of computer technology and the further development of data transmission methods over communication channels, a new purpose of TTP appears, first formulated in the standard X. 842 ("Recommendations X. 842: Guidelines for the use and management of TTP services", which was developed by the International telecommunications Union).
TTP is defined in this document as "... an organization or its agent that provides one or more security services that is trusted by other entities as a provider of these services". TTP is being used to provide additional services for organizations or individuals seeking to increase the level of reliability and confidentiality of services consumed or provided to ensure secure communication with business partners and the ability to create, transmit and save the necessary confirmations to restore the course of events.
Among the promising areas of use of services that provide the functionality of TTP and are currently actively developing, more generally, it should be noted:
Service for Building the Trusted Interaction Environment
The service provides users with a trusted platform, where they can perform legally significant actions, sign e-documents with an e-signature and perform e-signature verification. In the case of a conflict, a user has the opportunity to make a request to an accredited organization that provides this service, and is liable for errors and damages caused by it related to verification of the e-signature.
Long-Term Storage (Archiving) Service
The service is designed to provide remote secure storage of e-documents with verification of the legitimacy of e-documents at the time of creation of an e-signature.
Secure Interaction Service
A service at the infrastructure telecommunications level provides a connected resource that is protected using e-signature tools.
Service of Cross-Border Interaction.
The service is designed to ensure cross-border interaction of subscribers located in the zones of different jurisdictions in order to confirm the authenticity of their e-signatures, as well as certificates of e-signature verification keys.
By clicking on the button, you confirm your consent to the transfer and processing of information (including personal data).
Structure of the Software and Hardware Complex of the E-signature Validation Service
Recommendation X.842 very broadly defined the functions of the TTPs. Most of these services are currently performed by accredited certification authorities. The TTP functions are more narrowly defined in the RFC 3029 standard. In this document, the main function of the TTP is to perform the data validation and certification service in accordance with the DVCS Protocol described in it. To fully perform the functions of the DVCS Protocol, the TTP must implement at least 2 additional services:
1) The time stamp service (TSP – Time-Stamp Protocol) described in RFC 3161.
2) The Service of an online certificate status checking (OCSP), described in RFC 6960.
In recent years, Russia has been actively developing hardware and software complexes (HSC) for validation services. According to the authors, one of the successful options for implementing the DVCS service is "The Litoria DVCS HSC" developed by Gazinformservice LLC. Let's take a closer look at its software and hardware complexes.
Litoria DVCS Trusted Third Party Services Software package
The Litoria DVCS Trusted Third Party Services (TTPS) software package (SP) verifies the e-signature and the validity of the e-signature verification key certificate. The SP allows the user to create verification requests, analyze such requests, and generate a response containing information about the result of the verification.
The main task of the SP TTPS Litoria DVCS is to provide e-signature validation services for interdepartmental information interaction of information exchange participants in the conditions of ensuring the integrity and reliability of e-documents and their e-signatures.
In order to perform this task, the SP TTPS Litoria DVCS implemented the following functions
Creating all DVCS requests (in accordance with RFC3029)
– confirm e-signature of document (Validation of Digitally Signed Document – VSD);
– verification of the validity of the signature key certificate (Validation of Public Key Certificates – VPKC);
– certificate of possession of information at the specified time and providing it to the service (Certificate of Possession of Data – CPD);
– certificate the information possession without providing it to the service (by hash) (certificate of Claim of Possession of Data – CCPD).
Checking all data contained in the request
Formation:
– time stamps
– DVC receipts and their analysis in accordance with the requirements of the RFC 3029 recommendations.
Archiving and storage of
– user information
– created DVC receipts with their serial numbers,
– audit log files on the SP authentication server TTPS Litoria DVCS, containing the type, time and date of the event.
Providing a developer with software tools that facilitate creation of client applications such as
– SDK-client of the DVCS service – a software component that includes libraries (C++, C#) used for creating applications that use the DVCS service functionality;
– The TSP service SDK client is a software component that includes libraries (C++, C#) used for creating applications that use time stamps in accordance with the requirements of the RFC3161 recommendations ("Internet X. 509 Public Key Infrastructure, Time-Stamp Protocol (TSP)").
The SP is based on the following international standards implemented in it:
1) RFC3029 "Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols (DVCS)";
2) RFC3161 "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)";
3) RFC6960 "Internet X.509 Public Key Infrastructure Online Certificate Status Protocol – OCSP".
The SP includes the following components:
1) Authentication Service (DVCS);
2) Time-Stamp Service (TSP);
3) SDK client for the DVCS service;
4) SDK client for the TSP service;
5) AWP (automated workplace) of the administrator.
The scheme of functioning of the SP TTPS Litoria DVCS is shown in the figure 1.
Figure 1. Scheme of functioning of the SP TTPS Litoria DVCS.
Example of cross-border paperless e-document interchange
A large number of cross-border paperless e-document interchange projects have already been implemented in Russia. Let's take a closer look at one of these projects.
As an example of implementation of cross-border paperless legally significant e-document interchange (EDI), the experience of two trade business partners from Belarus and Russia in
organizing cross-border legally significant exchange of electronic trade related documents (TRDs) should be presented.

A pilot project for the exchange and mutual recognition of TRDs was implemented by two EDI operators: from Belarus - LLC "Modern Technologies of Trade" (LLC "CTT") and from Russia – KORUS Consulting CIS. A structural diagram of the composition and relationships of the pilot project components is shown in figure 2.
Two operators of the e-signature verification service were engaged to verify the e-signature in TRDs: on the part of Belarus - the National Center for Electronic Services (NCES), and on the part of Russia - LLC "Certifying Authority GAZINFORMSERVICE" (LLC "CA GIS").

Let's take a closer look at the implemented EDI TRDs process between a product supplier from Belarus and a product buyer from Russia. The supplier from Belarus, when delivering the product, passes the TRDs signed by the e-signature created using the cryptographic standard of the Republic of Belarus, to the EDI operator LLC "CTT", which in turn passes the TRDs to the EDI operator from Russia - CORUS Consulting CIS. The latter determines when processing TRDs that they are signed by a foreign cryptography and cannot guarantee their legal significance in accordance with the legislation of the country where the e-document was created and signed. Next, CORUS Consulting CIS forms a request for checking the TRDs e-signature, and sends it for verification to LLC "CA GIS".
Figure 2. Structural diagram of the composition and relationships of the pilot project components.
In turn, LLC "CA GIS" determines that the TRDs are signed with a Belarusian signature and sends a request for verification of the e-signature to the Belarusian TTP operator - NCES. The NCES verifies the Belarusian signature, generates a receipt for the verification results, signs it with its own e-signature, and passes this receipt to the Russian partner – LLC "CA GIS" - the operator of the e-signature verification service. LLC "CA GIS" checks the e-signature under the receipt and, if it is correct, signs it with its own e-signature in Russian cryptography. Then the receipt is sent to the Russian operator EDI KORUS Consulting CIS, which passes it along with the TRDs to the buyer. The buyer, based on the results of the check reflected in the receipt, makes a decision on accepting or refusing to accept the TRDs. This concludes the EDI process.
By clicking on the button, you confirm your consent to the transfer and processing of information (including personal data).