Agreement on Electronic Document Flow
1. Compliance of this Agreement with the Legislation
1.1. This Agreement is developed in accordance with the requirements of Federal laws no. 63-FZ ‘On Electronic Signatures’ as of 04/06/2011 and 149-FZ ‘On Information, Information Technology and Protection of Information’ as of 7/27/2006.
1.2. Terms of the Agreement are also correlated with international practices and standards of electronic signatures application, in particular with the PKI (public key infrastructure) X. 509 regulation. The PKI procedure is described in RFC 1422, and X. 509 certificate format - in RFC 5280.
2. Expressions used in this Agreement
2.1. Electronic document flow (hereinafter–"EDF") is a system processing the electronic documents, in which all electronic documents are created, transmitted and stored using information and communication technologies on computers integrated into a network structure.
2.2. Electronic document (hereinafter also referred to as ED)—a documented information provided in electronic form, i.e. in the form that is suitable for comprehension by people with the help of electronic computing machines, as well as for transmitting via information and telecommunication networks of information systems.
2.3. Electronic signature (hereinafter also—ESig)—an information in electronic form which is attached to the other information in electronic form (to the information being signed) or in other way related to such information that is used to identify the person signing the information (electronic document). There are simple and enhanced electronic signatures.
2.4. Electronic signature key (hereinafter–ES key) is a unique sequence of symbols intended for creating the ES. Also called a private key.
2.5. Electronic signature verification key (hereinafter–ES verification key) is a unique sequence of symbols uniquely associated with the electronic signature key and intended to verify the authenticity of the electronic signature (hereinafter–"ES verification"). Also called a public key. The value of the electronic signature verification key is contained in the certificate.
2.6. Secret ES code is a secret password (20 random characters), generated by the Counterparty and used in the calculation of the cryptographic hash sum which is used as a simple ES.
2.7. Electronic signature verification key certificate (hereinafter–"Certificate") is an electronic document or a paper document issued by the Certifying Center or Certifying Center trusted person. The document confirms that the electronic signature verification key belongs to the owner of the electronic signature verification certificate. Also called a public key certificate. The Certificate contains the serial number, information about the owner, cryptographic algorithm used, usage restrictions, ES verification key and other information. The certificate has its own ES created by the Certifying Center.
2.8. Means of electronic signature (hereinafter–ES means) are encryption (cryptographic) means used to implement at least one of the following functions: creation of ES, verification of ES, creation of electronic signature key and electronic signature verification key.
2.9. Encryption means—software, hardware, and combined encryption means that implement algorithms for cryptographic transforming of information in order to restrict access to it in the course of this storing, transmitting, and processing.
2.10. ESig Creation—is the result of work of the ESig means in the course of Esig creation that produces a sequence of data bits of the fixed length after cryptographic transformation of the electronic document to the hash and hash encryption by the electronic signature key. Length of the name of the hashing and encryption algorithms is specified in the Certificate.
2.11. Confirmation of the authenticity of the ESig—a positive result of the work of the ESig means in the course of Esig verification. Confirmation order for every type of the Esig verification is described in the Agreement.
2.12. Hash—a result of the hashing function, which converts the input data array of random length into the output bit string of the fixed length. The hash function should not allow to recreate the input data array from the hash and to guess another input data array whose hash will match the first array hash.
2.13. Electronic docflow participants—persons involved in the exchange of information in electronic form within the framework of this Agreement.
2.14. Compromised ESig key—a breach of confidentiality of ESig key, when the value of the privacy key becomes known to the person who is not the Certificate owner.
2.15. Main Contract—Contract concluded between the Operator and the Counterparty in accordance with the General terms and Conditions.
2.16. EDF system (the System)—is a common name for a set of tools that allow to perform electronic document flow between EDF Participants. The EDF system include ES tools, ES preparation, generation, verification, reception, transmission and processing of signed ES using computer means of each of the parties. The system is created by the participants.
2.17. Protocol of information exchange when performing transfers—a protocol created by the Operator that include technical description of information exchange procedure for the payments between the Operator and the Counterparty.
2.18. CC (hereinafter–Certifying Center) is the Operator’s certifying center.
3. Subject of the Agreement
3.1. This Agreement establishes the procedure for the organization and performance of electronic document flow using an electronic signature between the parties for fulfillment of the Main Contract.
3.2. The Parties acknowledge the legal force of electronic documents signed by the electronic signature equal to the legal force of documents on paper, signed by a handwritten signature and stamped by the parties (if required), under the following conditions:
the ES is created according to this Agreement;
the ES were verified and found valid according to this Agreement.
3.3. List of electronic documents signed by the ES:
Money Transfers: checkOrder request (simple ES);
Money Transfers: paymentAviso request (simple ES or enhanced non-certified ES depending on the integration);
Money Transfers: email-notification of transactions (Enhanced non-certified ES);
Money Transfers: Registers of Transfers accepted (Enhanced non-certified ES);
Replenishment: all requests.
API v3: answers GET/POST requests and notifications (Enhanced non-certified ES).
MWS: returnPayment (Enhanced non-certified ES);
MWS: confirmPayment (Enhanced non-certified ES);
MWS: cancelPayment (Enhanced non-certified ES);
MWS: repeatCardPayment (Enhanced non-certified ES);
API/v3: payment, including repetitions, clearings, confirmations (simple ES);
API/v3: refunds (simple ES);
Merchant Account: orders for returns (simple ES);
Replenishment: all requests;
API/offerwall: all methods (simple ES).
3.4. The Parties acknowledge that:
The use of ES ensures the validity of the authorship of information in the ED signed;
the use of enhanced non-certified ES ensures the integrity and validity of the authorship of information in the ED signed.
3.5. Information protection requirements (including when the information is transmitted over the Internet) that are not related to the use of ES are followed by the parties independently on the basis of the provisions of the Main Contract, technical documentation on the integration of the protocols used, the current legislation or the requirements of the internal regulatory documents of the parties, if any.
4. General Principles of Electronic Docflow
4.1. The Agreement allows using two types of the Esig:
enhanced encrypted non-certified Esig.
4.2. Simple ES is an electronic signature that uses the codes, passwords or other means in order to confirm the fact of the formation of an electronic signature by a certain person.
4.3. Enhanced unqualified electronic signature (EUES) is an electronic signature that:
Is obtained as a result of cryptographic transformation of the information using the electronic signature key;
Allows you to identify the person who signed the electronic document;
Allows to detect the fact of changes in the electronic document after the moment of its signing;
Is created using electronic signature means.
4.4. The Parties shall determine the cases in which different types of ES should be applied on the basis of the Main Contract and its annexes. In particular, when using passwords, secret codes or hashes from these codes, the ES is simple, and in the case of using the cryptographic keys of the ES, the EUES shall be used.
4.5. The Parties acknowledge that when using the enhanced non-certified ES and simple ES in the form of a calculated Hash:
Making changes to the signed ED makes the ES non-verified;
Faking of ES is impossible without using the owner's ES key or a secret code.
4.6. The Parties also acknowledge that:
Each party is responsible for the safety of its key/code and for the actions of its personnel using the ES tools;
The ED signed by ES comes into force in the moment when this signed ED is received through the System by the receiving party and logged in the journal.
4.7. Transfer of ED between the parties is carried out by means of data transfer via the Internet. Parties organize their access to the Internet independently and it is not the subject of this Agreement.
4.8. Before using the EDF, the Operator and the Counterparty exchange the necessary keys and/or codes. Operator’s ES Key and/or Certificate may be available on the public domain. After the exchange, the Parties conduct a test exchange of the signed ED and conduct an ES check in the test ED.
4.9. The type of ES used for signing Electronic Documents by the Operator and the Counterparty is defined in Clause 3.3. hereof.
5. Using of the Simple Esig
5.1. The Parties undertake that secret code (password) shall be enough for creating and forming of the simple Esig. The Parties undertake not to transmit value of the secret code to the third parties and to perform all required actions for preserving its confidentiality.
5.2. For MSW and HTTP protocols, a simple ES is formed by calculation of the hash from the sequence of values of a number of parameters, separated by the symbol ";" (semicolon). This set of parameters must contain the ID of the Counterparty and the secret code of the Counterparty. The calculated hash is a ES and it must be added to the electronic document before sending. For APIv3, a simple electronic signature is a secret that is added to the query. For orders in the Merchant Account, a simple electronic signature is one-time codes sent in SMS messages to a phone tied to Merchant Account.
5.3. To test a simple ES of MSW and HTTP protocols, the other party repeats all the steps to form a simple ES and then compares the created hash with the value transmitted from the other party. If the values are the same, then a simple EP is considered authentic. If the values do not match, then the signature is considered not verified, and the party verifying the ES must report to the other party about it. To verify the simple ES in APIv3, a check of the secret value is performed. To verify the simple ES generated in the Merchant Account, the code value entered from the SMS message is checked.
5.4. Algorithm of cryptographic hash and set of parameters shall be determined by the Operator in the Protocol of Information Exchange During Money Transfer.
6. Using of the EEsig
6.1. Creating and verifying the EEsig requires two keys: the Esig key and the Esig verification key.
6.2. In order the create the EUES, the party uses ES which:
Forms a hash from the source electronic document according to the certain algorithm;
Encrypts the received hash using the ES key according to the certain algorithm;
The resulted value is an ES and it is added to the original electronic document.
6.3. To verify the EUES, the Party uses the ES tools which:
Forms a hash from the source electronic document according to the certain algorithm;
Decrypts the received ES using the verification key of the ES;
Compares the received values - if they match, then the ES is considered genuine; If they do not match, then the ES is considered not verified, and the party verifying the ES must report to the other party about it.
6.4. The parameters and cryptographic algorithms used in the formation and verification of the EUES are determined by the technical documentation and the standards to which it refers, or by ES verification key certificates.
6.5. In order to protect against the counterfeiting of the ES verification keys when they are transmitted between the Parties, a corresponding ES verification key certificate in the Operator’s CC can be created for the ES verification key. The Counterparty and the Operator use the specified CC to obtain the ES verification key certificates. The need to use the Operator’s CC is determined on the basis of the information exchange protocols used by the Parties or by the agreement of the Parties.
6.6. When using verification key certificates, before a verification of the EUES, the Party receiving the document must check the received Certificate:
The certificate must belong to the transmitting party;
The certificate must be valid at the time of verification of the ES, in accordance with the established start and end dates of the Certificate;
The certificate must not be withdrawn, or its effect must not be suspended.
6.7. When submit answers for GET/POST requests and APIv3 notifications the Operator shall sign the Electronic Document with his ES key. The ES properties, checking algorithm ES security key are specified on web page https://kassa.yandex.ru/docs/api_public_keys.pdf
7. Operator’s CC Use Procedure
7.1. In order to receive the certificate, the Counterparty independently generates the ES key and the corresponding ES verification key using ES tools, as well as the request for the PKCS#10 certificate.
7.2. The Counterparty must fill the following fields in the request for a certificate:
CN = Full name of the responsible officer or organization name or pseudonym;
E = email address;
OU = Name of the organization subdivision;
O= Organization name;
L = Organization location city;
C = Country code (for example, for Russia C = RU).
7.3. The Operator accepts the request from the Counterparty and forms the certificate of the verification key of the Counterparty’s ES.
7.4. Certificate parameters:
signature algorithm – RSA;
key length – 2048 bit;
hashing algorithm – sha256.
7.5. The hashing, EUES formation algorithm and certificate parameters can be replaced by a more protected algorithm by mutual agreement of the parties.
7.6. The Operator sends to the Counterparty a certificate that will be used to sign the ED in the System, as well as a full chain of certificates:
Root certificate of the CC;
Intermediate certificates of the CC.
7.7. The parties agreed to trust the certificates that they exchange.
7.8. The certificate file is transmitted in X.509 format (Base64 or DER encoding, .cer format) or PKCS # 7 (file format .p7b) by e-mail or other pre-agreed method.
7.9. The parties print their files of certificates on paper, and then sign and seal it and transfer it to the other party. An example of the certificate form on paper is provided at the end of this Annex.
7.10. The Parties shall take all necessary measures to preserve the confidentiality of the ES keys.
7.11. If the EP key is compromised (or justifiably suspected in it), the Party must:
Stop the transfer of ED in the System and immediately (if it is impossible, within 1 Working Day) notify the other party about the fact of compromising its EP key;
Generate new ES key, a verification key, and issue new verification certificate to the new ES;
Transfer the file with a new certificate to the other party;
Ensure that the CC registered the serial number of the compromised certificate in the list of revoked certificates and published a new Certificate;
Restore the operation of the System in cooperation with the other Party.
7.12. The encrypted electronic documents are transmitted as follows:
the transmitting Party signs the electronic document with its ES key, encrypts the signed ED with the ES verification key from the certificate of the receiving Party and sends the encrypted signed ED.
the receiving Party decrypts the received document with its ES key and checks the ES with the verification key of the ES from the certificate of the transmitting Party.
8. Obligations of Parties
The Parties undertake:
8.1. Independently install all the necessary software and hardware in the System.
8.2. Exchange certificates of the ES verification keys, ES verification keys or secret ES codes, in accordance with the technical documentation for the protocols used for integration.
8.3. Appoint the persons responsible for work with the System in accordance with this Agreement.
8.4. Assign the security administrator responsible for the generation, accounting, exchange and security of keys/codes used in the System, for the protection against unauthorized access and for the maintaining the of ES system in working condition.
8.5. Timely change the ES keys and certificates of ES key verification in accordance with applicable requirements:
If there are no such requirements, the change is performed 10 days before the certificate expire or at least once a year for simple ES and EUES without the use of certificates.
8.6. Immediately inform the other party about all cases of loss, theft, unauthorized access to the ES key at the following addresses: Operator - firstname.lastname@example.org, Counterparty - the e-mail address specified in the Contract or the Application. At the same time, work in the System is suspended until unplanned change of keys is complete.
8.7. Take on all the risks associated with the performance of its equipment and communication channels.
8.8. At its own expense to maintain the System software and hardware systems to ensure the operability of computers and communications that provide electronic document flow.
8.9. Provide access to ES tools only for persons authorized to sign documents.
8.10. Do not take actions that could harm the System of the other Party while of using EDF, for example, launch network attacks, denial of service attacks, virus attacks, and others.
8.11. In a timely manner (by e-mail specified in 7.6 and/or telephone) inform the other side about all cases of technical malfunctions or other circumstances influencing the electronic document flow.
8.12. In case of possible security threats, the parties undertake to notify each other in a timely manner of such threats to take concerted measures to neutralize them.
8.13. Fulfill the requirements of technical and operational documentation for the software and hardware of the System.
8.14. It is recommended to develop and implement measures to ensure the information security of the System:
Confidentiality, integrity and accessibility of software and hardware;
Confidentiality of transmitted ED;
Integrity and accessibility of event registration protocols;
Confidentiality, integrity of the current keys and passwords;
To organize the work of the responsible person in such a way as to exclude the possibility of using the System by persons who are not allowed to work with it;
To keep confidential all the information on the technology of information protection used in the System.
8.15. Maintain the system time of the system's hardware and software in accordance with the current astronomical time with a tolerance of five minutes. The parties recognize the Moscow time MSK (UTC +3) as a single time scale.
8.16. The Parties shall organize the archival storage of ED during the period of validity of similar documents issued on paper carriers.
9. Rights of the Parties
The Parties shall have the right to:
9.1. Limit and suspend the use of the System in cases of incompliance with the of Agreement by another Party, with notification no later than the day of suspension, or at the request of the competent state authorities in the cases and in the manner provided for by the legislation of the Russian Federation.
9.2. Replace the system hardware and software with prior notification at least two working days of the other party.
9.3. Suspend the operation of the System for technical reasons, before restoring its operability.
9.4. Make scheduled and unscheduled replacement of the secret code, ES key, ES verification key and the certificate of ES verification key notifying the other party at least two working days before it.
10. Responsibilities of parties and the risks of losses
10.1. The Parties are responsible for the content of ED signed by them, subject to confirmation of the authenticity of the ES.
10.2. The Parties are responsible for the confidentiality and the procedures for the use of ES keys and codes.
10.3. The Party that committed the compromise of the ES key is responsible for the ED signed with the use of the compromised ES key, until the official notification of the cancellation (revocation) of the corresponding key or Certificate by the other Party.
10.4. The Party which did not timely report on the loss or compromise of the ES key, bears the associated risks.
10.5. In the event of a loss, the Party that failed to fulfill (or fulfilled improperly) the obligations under the Agreement shall be liable to the other party for the losses incurred by that. In the absence of evidence of non-fulfillment (improper fulfillment) of obligations under the Agreement by the parties, the risk of losses is borne by the party whose ES was used to sign the ED, the execution of which entailed such losses.
10.6. The parties are exempted from the liability for partial or complete non-fulfillment of their obligations under the Agreement, if such non-fulfillment resulted from force majeure circumstances that arose after the Agreement entered into force as a result of extraordinary events that could not be foreseen and prevented by reasonable measures. The Party shall immediately notify the other Party of the occurrence and termination of force majeure circumstances that impede the fulfillment of its obligations under the Agreement, while the term of performance of obligations under the Agreement is postponed proportionally to the time during which such circumstances acted.
10.7. In the event of termination of the Agreement for any reason, the Parties are liable for obligations that arose prior to the termination of the Agreement in accordance with the legislation of the Russian Federation.
11. Settlement of disputes related to the authenticity of the ES
11.1. Any disputes between the parties related to the determination of the authenticity of the electronic signature in the ED, i.e. the integrity of the text and the authenticity of the ED sender, are transmitted for the settlement to a specially created Expert Commission.
11.2. The Expert Commission is convened on the basis of a written application (claim) by either party. The application shall contain requisites of the disputed signed ED and persons authorized to represent the interests of this party in the Expert Commission.
11.3. Not later than 10 working days from the receipt of the application (s) by the other party, the parties determine the date, place and time of commencement of the Expert Commission work, determine which party provides the premises and configures the ES tools.
11.4. Powers of members of the Expert Commission are confirmed by powers of attorney.
11.5. The Expert Commission is formed in equal proportions from representatives of the parties.
11.6. The Expert Examination of the disputed ED is carried out in the presence of all members of the Expert Commission.
11.7. The Examination is carried out in four stages:
Stage 1: the parties jointly establish, configure and test the ES tools.
Stage 2: the parties provide their copies of certificates of verification keys for ES, the keys for generating and verifying ES for EUES or secret codes for simple ES used to create the ES of the disputed ED;
Stage 3: depending on the ES type, the commission compares the received certificates, verification keys for ES, or secret codes with the corresponding certificates or secret codes with the codes received at the conclusion of the Basic contract. Matching certificates, verification keys for ESand codes are considered as genuine. Also, the commission verifies the authenticity of the entire chain of certificates, if any.
Stage 4: if the third stage is successfully passed, the commission checks the authenticity of the ES in the disputed document in the usual manner described in this agreement.
11.8. The results of the examination are drawn up in the form of a written conclusion called an Act of the Expert Commission, signed by all members of the Expert Commission. The act is drawn up immediately after the completion of the last stage of the examination. The Act contains the results of all stages of the examination, as well as all the essential details of the disputed ED. The act is made in two copies - one for each of the parties. The act of the commission is final and not subject to revision.
11.9. Confirmation of the authenticity of the ES in the disputed ED and recorded in the Act will mean that this ED has legal force and entails the emergence of rights and obligations of the parties established by the Main Contract and the Agreement.
11.10. The Parties recognize that the Act drawn up by the Expert Committee shall be binding for the Parties and can serve as evidence in further litigation in arbitration court.
11.11. If there is no agreement on the disputable issues and the voluntary execution of the decision of the Expert Commission, all materials on these issues can be submitted to court of the Operator’s location or the location of its representative office in St. Petersburg.
12. Persons authorized by the Parties to use the ES:
on behalf of the Operator—Chairperson of the Board Tatyana Shabanova;
At the Counterparty’s side (legal entity) — the person authorized by the constituent documents or by the power of attorney – an individual entrepreneur or an individual who uses a special tax regime "Self-employed Tax" – a person registered as an individual entrepreneur, or a person authorized by a power of attorney.
13. Example of the form for Certificate print:
Yandex.Money certification authority
Signature key certificate
Issued to: Yandex.Money
Issued by: Yandex.Money CA
Valid 1 January 2010 to 31 December 2020
|Serial number:||00 00 00 01|
|Publisher (CN):||Yandex.Money CA|
|Organization unit (OU):||CA|
|Valid from:||1 January 2010 0:00:00 (GMT+04:00)|
|Expiration date:||23:59:59 (GMT+04:00) 31 December 2020|
|Organization unit (OU):||Web|
|Public key:||RSA (2048 bit) |
30 82 01 0a 02 82 01 01 00 87 17 c8 8e 57 1d 14 86 3e 03 86 ef 33 4d 43 44 03 1e ef 94 77 b3 4d c5 93 10 f4 3d 0c 5c 05
7f 33 5a cd 95 36 f4 85 84 2d c0 15 83 d4 a6 5e ee 3b bb d3 31 ed 41 49 58 9d c3 73 76 14 57 29 e1 aa dc 38 42 07 48 9a
5e 4f a3 fa e2 8e 23 23 28 c4 6f 01 8a 7e 57 6f 2c cb 4f 0f 15 a6 5c 6e c3 3b 5e 24 a4 30 b5 6c e4 7c 8c 39 c2 b2 40 51
80 40 c7 31 a2 64 3b ca 5d 53 54 a3 5d 38 79 a0 25 82 3b 34 3b 47 da c2 cd db f4 dd 07 ef 4b 92 f7 f2 91 a1 42 7a 7a 01
fd d5 8b 14 97 39 5b 67 1c 63 07 47 1c e3 b9 ba 15 bb 48 73 73 47 da 83 d2 c2 20 38 76 c7 e9 e1 b0 1e 28 4c 76 66 65 96
03 49 31 df 18 da 3a 0d 1d 69 71 50 a6 f0 88 5b a2 83 f4 74 a1 b8 25 f6 a6 33 3d ec bb 2a a1 65 67 89 07 4e 8b 86 93 3c
d0 b9 d3 d7 12 1f ae ff f7 fe 41 b1 ce 81 51 b7 20 87 2f 0b 43 fa a0 49 bd 02 03 01 00 01
|Imprint:||8a 16 b4 5c 3b 86 f9 84 31 d9 4e 68 89 3c 0c e1 d0 2a 0f 0e|
Certificate verification result: Valid. Reviewed 1 April 2015 0:00:00 (GMT+04:00).
Authorized person of the Certification Authority
____________________ 20 __
14. Example of the form for the EUES verification key print:
Issued by: Yandex.Money CA
|Public key:||RSA (2048 bit) |
00:a0:67:7c:2f:c8:de:00:06:da:b0:03:33:0d:c7: 81:41:e0:59:19:bf:7c:59:99:81:74:d1:03:4d:43: f2:1b:7d:08:33:13:7c:0c:06:b0:cc:29:2e:1b:81: 74:83:d2:dc:a0:61:96:85:6c:11:ed:85:db:3b:ed: c7:b7:3c:29:17:5e:41:87:80:9e:2e:3e:74:0a:93: 87:03:74:dc:f9:a6:60:3a:ce:63:6a:6a:18:3d:8d: 99:02:df:0d:13:6b:68:9e:d5:96:55:10:c4:0e:33: 73:01:a8:04:10:dc:59:12:94:40:22:f5:e8:2c:43: 94:18:6d:82:cc:71:ff:b5:da:bf:cd:55:b9:55:01: 72:74:85:da:a6:7d:61:d1:fb:1f:98:cf:c4:40:80: 27:9f:fe:a5:1c:01:8f:e5:59:8d:12:d2:ea:fc:84: 4a:c1:13:80:ed:d2:8f:16:3f:76:76:29:f9:00:81: 49:ae:6f:6a:8c:62:8a:d2:4c:18:6a:0c:69:8f:52: 09:47:4e:45:37:37:cd:b8:30:5f:f1:79:c5:0e:62: 0d:bc:5a:ee:13:19:3e:46:94:f0:03:ff:e5:cb:99: 43:63:51:84:16:53:86:7e:9b:b4:13:c9:31:85:cf: a2:e8:97:2b:8b:b3:34:16:19:03:05:84:a3:20:aa: 5f:95
Certificate validation result: the Certificate is valid. Validated on April 1, 2015. 0:00:00 (GMT+04:00).
Certification Center’s Authorized Person
Signature __________________ Seal
________________ 20 __