Trusted Third Party: How Your Electronic Signature Changes When It Appears





Over the past 10 years, the issues of convenient and long-term (or even "archival") storage of documents with an electronic signature (ES) and their exchange with mutual trust have not been fundamentally resolved. Yes, there are special “archived” versions of extended ES formats (CAdES-A and XAdES-A), which contain several time stamps, lists of revoked certificates and chains of certification authorities (CA) at the time of ES generation. There are options for solutions with "re-signing" documents with electronic signature or creation of a trusted environment for their storage. However, all of this does not add "usability". New problems also emerged: the lack of a unified policy for the use of qualified certificates in commercial information systems (especially on trading platforms), which is why highly specialized OIDs began to be added to certificates;lack of a unified register of issued certificates with a significant increase in their number; a large number of CAs and their turnover; attempted fraud with real estate and tax returns using qualified certificates with ES, obtained in a fraudulent manner.



The amendments to the Federal Law "On Electronic Signatures" adopted on December 27, 2019 are aimed at finally eliminating most of these problems, legalizing cloud-based electronic signature, and actually restructuring the market of certification centers. The law also introduces a new institution - a trusted third party (TTP). TPA regulations should come into force on January 1, 2021. Despite this, almost everything related to TPA is still awaiting clarification and regulation from regulators. I will try to describe in detail what awaits us.





What non-obvious problems of the “short-term” of a conventional electronic signature exist today?



I work in the application integration department. It so happened that we did not have to implement "standard" electronic signature for document flow "out of the box" or implement ready-made client applications for working with electronic signature. Almost always, implementation tasks boiled down to embedding electronic signatures (including various kinds of automation for servicing the life cycle of certificates, keys and their carriers) into existing and not at all boxed workflows or information systems, including those with long-term storage of documents. At the first stages of design, the process of forming an electronic signature usually did not cause great difficulties for anyone. It would seem, well, what is it? Generate a hash on a document and sign it with a private key using basic electronic signature formats, for example, CAdES-BES or XAdES-BES.But the need for further medium-term and long-term storage of documents with electronic signature, verification of electronic signature in document flow (including automated) always ultimately influenced the solution architecture. EDS formats became more complicated, starting from CAdES-T and XAdES-T (with time stamps) and ending with their extended and special “A” -versions (Archival). And then everything in a circle returned to the process of forming the electronic signature in order to provide the necessary context for the format chosen for it.to provide the necessary context for the format chosen for it.to provide the necessary context for the format chosen for it.



So how to check the electronic signature of a document, at least in 10-15 years? (Omit this detail, which is likely, after all these years will not be certified means of cryptographic protection of information (CIPF), supporting the necessary cryptographic algorithms and the necessary formats and the necessary means viewing electronic documents will not run on the current operating system.)



Referring to the law on EP (dated 06.04.2011 No. 63-FZ). What conditions for the recognition (verification) of a qualified electronic signature are contained in Article 11 "Recognition of a qualified electronic signature" (I will give only paragraph 2 of the article, because it is he who affects the verification of documents with electronic signature in time):

[…] :



2) ( ) , .



Key information (especially in the context of long-term storage of documents) is bracketed here. A qualified certificate must not only be valid at the time of signing an electronic document, but the very moment of signing an electronic document must be recorded, moreover, "authentically" - and this is a prerequisite.



The legislator did not suggest or even hint at ways to confirm the accuracy of information about the moment of signing an electronic document... However, this is normal. The process requirements should be disclosed by the responsible regulators. And 9 years later, after the amendments to the law on electronic signature came out at the end of 2019, the Ministry of Digital Affairs of Russia and the FSB of Russia (in terms of work with a time stamp, but more on that later), finally, have developed draft orders. In the meantime, the burden of proving the authenticity of the moment of signing still rests on the shoulders of the CIPF developers and the owners of information systems. For example, relying on open international specifications and standards, they are forced to choose the formats of electronic signature themselves, including those with a time stamp, and wait, court practice will confirm or correct their approach.



What solutions are usually used to bypass the “short-term” nature of the basic ES?



A single standard for the ES format with a time stamp in the development process. The most obvious, from the point of view of medium-term (5-10 years) and long-term storage of documents with electronic signature, is the implementation of qualified electronic signature in one of the extended formats (at the discretion of the IP owner) at least:



  • with an embedded time stamp to reliably determine the moment of signing an electronic document for a period of up to 15 years (theoretical maximum validity period of the certificate of the ES verification key "time stamp service");
  • with information about the fact of certificate verification in the form of an attached response from the OCSP service (online certificate status check service) or an attached certificate revocation list (providing confirmation of the validity of a qualified certificate at the time of signing), backed by a time stamp.


Less obvious and less common solutions that provide verification of the electronic signature of a document in N-years include the creation of trusted storage environments. In such an environment, a document with ES is most often placed during the validity of a qualified ES certificate issued to the user (for example, immediately after signing) with a maximum set of metadata. When a document with electronic signature is placed in a trusted environment, the electronic signature is checked, the status of the certificate, and extended reports on the facts of checks are generated. The integrity of the document and all associated metadata is then ensured by the trusted environment. Such solutions include, for example, internal / industry registers of large organizations, in which the maximum possible set of metadata for a document with ES is registered (at least, document attributes and its hash, ES, certificate identifier and the ES certificate itself,the fact of verification of the certificate with a time stamp, a separate time stamp on the electronic signature). If desired, all this can be signed from above with the technical signature of the "archivist". In general, this is suitable for the internal needs of large companies and organizations, where documents with electronic signature are not alienated from the system or the electronic signature itself was initially implemented without a time stamp.



Bulky trusted document storage environments help to avoid some potential problems with electronic signature compromise, since the signed document is saved with the entire set of metadata. But still they do not contribute to the implementation of electronic document flow with electronic signature between organizations. And again, unfortunately, they do not cancel the need to prove the accuracy of information about the moment of signing the document.



How will the introduction of a trusted third party make a difference?



We got to the most important thing. In additions to the 63-FZ "On Electronic Signatures" dated December 27, 2019, along with a number of changes, including the legal recognition of cloud-based electronic signature, the institution of a trusted third party appears (Article 18.1). This is a new type of organization, which is designed to ensure trust in the exchange of electronic documents with electronic signature.



The law defines the list of services that TTPs will provide to participants in electronic interaction:



  • to confirm the validity of electronic signatures used when signing an electronic document, including establishing the facts that the corresponding certificates are valid at a certain point in time, created and issued by accredited certification centers, the accreditation of which is valid on the day these certificates are issued;
  • to verify the compliance of all qualified certificates used when signing an electronic document with the requirements established by this Federal Law and other regulatory legal acts adopted in accordance with it;
  • on checking the powers of participants in electronic interaction;
  • on the creation and signing of a receipt with a qualified electronic signature of a trusted third party with the result of verification of a qualified electronic signature in an electronic document with reliable information about the moment of its signing;
  • data storage, including documentation of operations performed by a trusted third party.


In other words, an accredited organization appears (and not just a set of services at an accredited CA), providing such a necessary set of services:



  • verification of the validity of electronic signature and certificates at a certain point in time;
  • verification of the powers of the owners of ES certificates;
  • issuance of receipts with the results of verification of a qualified electronic signature;
  • maintaining the actual register of performed (verified) operations.


In fact, these are all those tasks and the corresponding "accredited" solutions for verifying electronic signatures in time, which are designed to ensure external trusted electronic document circulation with electronic signatures and at least medium-term storage of documents.



What's wrong with the timestamp and when should it work?



Let me emphasize that, first of all, I am interested in the legal consolidation of the use of a time stamp and the unification of the ES format with a time stamp, and not the extended ES formats themselves (based on different international standards), in which the time stamp has long been used.



Unfortunately, the legislator (until December 2019) and regulators (until September 2020) did not disclose the functionality of the "timestamp". From here came various incompatible electronic signature formats. They seemed to be strengthened qualified and were performed on certified means, but the exchange of documents with such electronic signatures with automatic trust between different information systems bypassing the system of interdepartmental electronic interaction (SMEV) was impossible. SMEV, of course, uses the timestamp issued by the internal service for electronic signature in the XAdES-T format, but it rather solves transport problems when transferring documents.



Today, there is more clarity with a time stamp, but so far it has not been enshrined in regulatory legal acts.



"Trusted time stamp" (this is exactly what is indicated in the law on electronic signature, but everywhere I write simply "time stamp") has been added by amendments to the law on electronic signature dated December 27, 2019. 2 "Basic concepts used in this Federal Law" and is not used anywhere else. The time stamp regulation enters into force simultaneously with the TPA regulation (from 01/01/2021), since they are related.



The law defines a "timestamp" as follows:

"Reliable information in electronic form about the date and time of signing an electronic document with an electronic signature, created and verified by a trusted third party, certification center or information system operator [...]".


Thus, the time stamp can be created and verified by the TTP, CA and the IS operator, if received:

"[...] at the time of signing an electronic document with an electronic signature in the manner prescribed by the authorized federal body using software and (or) hardware that have passed the procedure for confirming compliance with the requirements established in accordance with this Federal Law."



Almost a year later (September 14, 2020) after the appearance of the timestamp in the law on electronic signature, the order of the Ministry of Digital Industry of Russia No. 472 "On approval of the Electronic Signature Format, mandatory for implementation by all means of electronic signature" was issued . He finally:



  • unified the ES format,
  • introduced the requirement for the presence of the "time of creation of the ES" in the composition of the ES (without a clear indication of the time stamp),
  • provided the optional possibility of including a list of revoked certificates in the electronic signature.


Further. In addition to the order of the Ministry of Digital Security of Russia No. 472 (where, as I wrote above, there is neither a definition of the time stamp, nor a reference to it, but there is a requirement to place the “time of the creation of the ES” in the ES ), 2 draft legal acts have appeared:



  • , « » 09.10.2020. « » ( ), « » ( ), ;
  • « ‎№ 1 2 ‎ 27 2011 . № 796 « ». , « » « » .


Obviously, the TPA also needs a time stamp or an ES certificate, which has not yet expired , to record a “certain moment in time” . The time stamp must be both "trusted" and "correct" (the TTP must understand it). And, most likely, the ideal algorithm for checking electronic documents with electronic signature, in which the timestamp is implemented, in the TTP will be as follows:



  1. Creation of an electronic document with electronic signature, where the electronic signature is implemented by means and in a format with support for a time stamp (order of the Ministry of Digital Science of Russia No. 472).
  2. Obtaining a timestamp in the TTP or somewhere else (in the CA or from the IS operator).
  3. Embedding a timestamp (issued by an "accredited" service - TTP / CA / IS operator) into a document with electronic signature.


And only if all these stages are passed, the TTP will be able to "confirm the validity of the electronic signature" with all the "buns and extended reports". What follows from this? Anyone who wishes to use the TPA to check documents with ES after the expiration of the ES certificate must have:



  • Extended format electronic signature (the same order of the Ministry of Digital Industry of Russia No. 472, in which, I repeat once again, the time stamp is not defined);
  • tools for working with electronic signatures (cryptographic information protection tools, application software) that support working with time stamps (technically, it can be a separate file with another detached electronic signature of the time stamp service);
  • compliance with the algorithm for obtaining a time stamp and embedding it in a document with electronic signature.


Timestamp format
, , rfc 3161 «Time-Stamp Protocol (TSP)» . , « ». :



  • ;
  • ­ ;
  • (), ;
  • -, -;
  • - , ;
  • , .


, , TimeStampToken :



image



, ( , ) rfc3161.





The regulatory legal acts of the regulators have not yet been adopted, however, the puzzle with the timestamp is starting to converge:



  • there are requirements for the electronic signature (order of the Ministry of the Russian Federation No. 472, which determines the need to take into account the time of creating the electronic signature);
  • there are requirements for the service and the format of the timestamp (draft order of the Ministry of Digital Science, see above);
  • there are requirements for the CIPF, in which the time stamp must be maintained (draft FSB order, see above);
  • there are requirements for the CA and TTP, which should include a "trusted time stamp service" (the same draft FSB order, see above).




Complex functionality of checking credentials in TPA



Let's return to the TPA and the functionality of verifying the correct use of ES certificates and powers. In accordance with the amendments to the Law on Electronic Signature dated December 27, 2019, the DTS acts, among other things, as an "authorization" center performing:



  • verification of the compliance of all qualified certificates used when signing an electronic document with the requirements of regulatory legal acts;
  • checking the credentials of participants in electronic interaction.


At the same time, the first paragraph should also include checking the correctness of the application of the Qualified Electronic Signature Certificate (CEP):



  • the departmental or organizational affiliation of the CA, whose CEP certificate is used in specific electronic legal relations (legal relations of legal entities - the CA of the tax service; legal relations of financial, credit organizations - the CA of the Central Bank; legal relations of persons representing state authorities and local self-government bodies - the CA of the Federal Treasury; legal relations individuals - commercial accredited CAs);
  • type of certificate of a qualified electronic signature (individual, legal entity, individual entrepreneur) for the correctness of its application in a specific electronic legal relationship.


We will separately deal with the second point - the verification of credentials. In addition to the correct application of the type of certificate issued to an individual, legal entity or individual entrepreneur, a document of authority must be checked here, which must be “signed by the CEP of an official of the relevant state body or local government authorized in accordance with the established procedure for making appropriate decisions” . The powers themselves should be "determined on the basis of the classifier of powers, which the authorized federal body forms, updates"... In accordance with Articles 17.2 and 17.3 of the ES Law, it is also necessary to check the presence and content of an electronic power of attorney, since it is she who authorizes the party to certain legal relationships. Thus, when checking the authority, the TPA should also check:



  • a document of authority issued to an individual;
  • an electronic power of attorney issued to an individual (in cases requiring its use).


Of course, the application system will be able to perform these checks. She understands the context of electronic legal relations, knows what powers and powers of attorney are allowed with CEP certificates and with which CAs you can / should work with. Another question is how the TPA will conduct such checks, because it does not have information about the context of legal relations.



On the one hand, “authorization” operations when using ES certificates were unified. Specified OIDs in ES certificates should now be ignored, and authorization schemes based on your / someone else's OID principle are outlawed from 01.06.2020. On the other hand, the delineation of powers and the rules for the use of ES certificates have transformed into more complex processes that still need to be adjusted by 01.01.2022.



White spots in credentials
« , » «» . , 2.3 :



« – , ».




, , , , ? ? , , 01.01.2022, .



. - , , «» .





: - ?



"Legalization" of storage and remote use by means of the CA of the cloud-based digital signature should start a new round of its development from 01.01.2021. This applies to the increase in the number of implemented services on the basis of electronic signature (especially in our modern times) and convenient services for working with electronic signatures for mobile clients and clients at workplaces, which, in turn, will need external servicing services for verifying electronic signature (based on TPA) ...



Most likely, either on New Year's Eve, or immediately after the holidays, the orders I mentioned will be adopted. Then the developers of cryptographic information protection tools will need another 3-4 months to adjust the client software and libraries for the new format of electronic signature with a time stamp and services of trusted time stamp services. By the way, the latter have already been implemented and operated by key developers of cryptographic information protection tools as TSP time stamp services.



Further, it will take some more time to develop the TTP functionality, which is clearly not tied to any formats, but necessary under the law on electronic signature:



  • creation of receipts with the result of the CEP check in an electronic document;
  • data storage, including documentation of operations performed by the TPA.


Taking into account all the necessary software improvements, as well as organizational procedures for accreditation, I think it is not worth waiting for the first TPA to appear before the summer of 2021. Maybe the Federal Tax Service and the key developer of the CIPF will release something earlier as a test version of the TTP.



TTP services, obviously, will not be free for everyone, and all costs will directly or indirectly fall on the participants of electronic interaction.



The appearance of TPA on the market should ultimately contribute to the emergence of useful services (primarily in the form of an API for embedding) that can provide:



  • confirmation of the validity of electronic signatures,
  • verification of the powers of participants in electronic interaction;
  • formation of alienated receipts with the result of checking the CEP of electronic documents;
  • formation of time stamps that can be used not only for documents with electronic signature, but also for electronic correspondence, for other services that require time stamping.


These services can be built into information systems, for example:



  • for medium-term storage of documents,
  • to export / alienate documents to users without fear that they will become unverifiable in a year,
  • for automated decision-making based on the results of electronic signature checks.


The services will also find application in mobile clients of various information systems, including those for working with cloud-based digital signature. The second option is in line with the recently announced proposal of Maksut Shadayev, Minister of Digital Development, Communications and Mass Media of Russia:



« , — . , ».




This was said in the context of the ministry's support for the initiative to issue free electronic signatures to users of the public services portal.



Total: the announced changes in the law on ES and the proposed TPA functionality are really interesting, long-awaited and will certainly be in demand. The time stamp (which is introduced simultaneously with the TPA from 01/01/2021) will "automatically" solve the problems of medium-term storage of documents. TPA and a unified format for electronic signature with a time stamp will allow the trusted circulation of documents with electronic signature older than 1 year and check them after alienation from the system. Of course, a lot depends on the implementation, including the regulations and orders of the Ministry of the Russian Federation and orders of the FSB of Russia, which ideally should lead to a common denominator of technical solutions for all TPA.



Instead of PS The future of the CA and TPA market



And finally, I would like to write about a possible collapse of the CA market.



The same law changed the period for accreditation of the CA from 5 to 3 years. A similar period - 3 years - is determined for the accreditation of TPA. At the same time, the requirements for the CA have increased significantly. Now you need:



  • at least 1 billion rubles of own funds (capital) or 500 million rubles of capital, but at the same time one or several branches or representative offices of the CA must be placed in at least 3/4 of the constituent entities of Russia (a similar requirement for TPA);
  • financial security of liability for losses caused to third parties in the amount of at least 100 million rubles for the CA (now it is 30 million rubles). For TPA, the size has not yet been determined.


According to experts, an increase in the minimum capital requirements will lead to a decrease in the number of CAs by more than 10 times already in 2021 (from about 450 to 20-40). By analogy, the emergence of a significant number of TPA is not expected, which, most likely, will be created at key CAs (Central Bank, Tax Service, Treasury) to serve their internal needs. Perhaps they will appear in the presence of several large “surviving” commercial accredited CAs.



Users or developers of small application systems (those who would like to implement workflow with cloud-based electronic signature), of course, are more interested in working with TTPs independent of certification centers, as well as interacting with all or most large CAs.



I believe it would be interesting for the existing TCs to create their own TPA. For them, it is actually a processing center for checking the constant flow of documents with electronic signature, executed on their own products and solutions. Moreover, the law does not clearly prohibit combining CA and TPA in one legal entity. But with such capital requirements, only large tech banks have real opportunities to enter the market for these services.



Write if you have questions not for comments - here is my mail: SGontzov@croc.ru.



All Articles