annex 1 agreement on electronic document flow

advertisement
ANNEX 1 AGREEMENT ON ELECTRONIC DOCUMENT FLOW
1.
Compliance of this Agreement with legislative rules
1.1. This Agreement is developed in accordance with the requirements of the Federal Laws No. 63-FZ “On Electronic
Signatures” of 06.04.2011 and No. 149-FZ “On Information, Information Technologies and Information Protection” of
27.07.2006.
1.2. Terms and definitions of this Agreement are also correlated with international practices and standards for use of electronic
signatures, in particular PKI (Public Key Infrastructure) standard X.509. PKI operation procedure is described in RFC
1422, and the X.509 certificate format - in RFC 5280.
2.
Terms used in the present Agreement
2.1. Electronic document management – a system of work with electronic documents, when all electronic documents are
created, transferred and stored with help of information and communication technologies on computers, united in a
network structure.
2.2. Electronic Document (hereinafter - ED) – documented information, presented in electronic form, i.e. in a form, suitable
for human perception with the use of electronic computing machines, as well as for the transmission through information
and communication networks or processing in information systems.
2.3. Electronic Signature (hereinafter - ES) – information in electronic form, attached to other information in electronic form
(the information being signed) or otherwise associated with such information and used to identify the person, subscribing
the information (electronic document).
2.4. Electronic signature key – a unique sequence of symbols, designed to create the ES. It is also known as a private key.
2.5. Electronic signature verification key – a unique sequence of symbols, unambiguously connected with the electronic
signature key and intended to authenticate the ES (hereinafter – ES verification). It is also known as a public key. The
value of the electronic signature verification key is contained in the certificate.
2.6. ES Security Code – a secret password (20 odd symbols), formed by the Counterparty and used when calculating a
cryptographic hash, which is used as a simple ES.
2.7. Certificate of electronic signature verification key (hereinafter – the Certificate) – an electronic document or a document
in hard copy, issued by a certification authority or an authorized representative of the certification authority and confirming
the belonging of the electronic signature verification key to the owner of the certificate of electronic signature verification
key. It is also known as a public key certificate. The certificate contains a serial number, information about the owner,
used cryptographic algorithms, usage restrictions, ES verification key and other information. The certificate has its ES,
created by the certification authority.
2.8. Electronic signature facilities (hereinafter – ES facilities) – encryption (cryptographic) facilities, used for realization of
at least one of the following functions – the ES creation, ES verification, creation of electronic signature key and electronic
signature verification key.
2.9. Encryption facilities – hardware, software, hardware-software encryption (cryptographic) facilities, implementing
algorithms of cryptographic transformation of information to restrict access thereto, including during its storage,
processing and transmission.
2.10. ES creation – the result of work of ES facilities when creating the ES, resulting in a bit chain of fixed-length data after
the cryptographic transformation of an electronic document into hash, and hash encrypting using the electronic signature
key. The length, names of hash and encrypting algorithms are specified in the Certificate.
2.11. ES authentication – a positive result of work of ES facilities when verifying the ES. The verification procedure for each
type of ES is described in the Agreement.
2.12. Hash – the result of work of a hash function, which transforms the input array of random length into the output bit string
of fixed length. The hash function should not allow to obtain the original input array on the basis of the hash and choose
another input array, the hash of which will coincide with the hash of the first array.
2.13. Participants of electronic document management – persons exchanging information in electronic form under the
present Agreement.
2.14. ES key compromise — a breach of confidentiality of ES key, when a person other than the Certificate owner knew the
value of the ES key.
2.15. Сontract — a contract concluded between the Operator and the Counterparty in accordance with the General Terms and
Conditions.
2.16. EDM System, System – a common name for all facilities, allowing carrying out electronic interchange between the
Participants of EDM. EDM System includes ES facilities and provides ED preparation, ES generation, ES verification,
acceptance, transmission and processing of ED signed, with the use of means of computer technology by each Party. The
Participants complete it by themselves.
2.17. Protocol of Information Exchange – a protocol, defined by the Operator, contains a technical description of the procedure
for interchange of information on payments between the Operator and the Counterparty.
3.
Subject of the Agreement
3.1. The present Agreement establishes the procedure for organization of electronic document management with the use of
electronic signature between the parties in pursuance of the Contract.
3.2. The Parties recognize the validity of all electronic documents, signed with an electronic signature, equal to legal force of
documents in hard copy, signed with a handwritten signature, accompanied by impressions of seals of the Parties (if
necessary), under the following conditions:
 the electronic signature is created according to the rules if this Agreement;
 the electronic signature has been tested under this Agreement and recognized authentic.
3.3. The list of electronic documents, signed with ES:

On behalf of the Operator:

Transfers: request checkOrder;

Transfers: request paymentAviso;

Transfers: email-notice of transfers;

Transfers: register of transfers received;

Replenishment: answers to all requests.

On behalf of the Counterparty:

MWS: returnPayment;

MWS: confirmPayment;

MWS: cancelPayment;

MWS: repeatCardPayment;

Replenishment: all requests.
3.4. The Parties recognize that the use of ES ensures integrity and non-repudiation of authorship of information in signed ED.
3.5. Information security requirements, which are not related to the question of the use of ES, are fulfilled independently by
the Parties under the provisions of the Contract, the current legislation or the requirements of internal regulations of the
Parties, if any.
4.
General principles for electronic document management
4.1. The Agreement provides for the use of two types of ES:

simple ES;

enhanced non-certified ES.
4.2. Simple ES is an electronic signature, which confirms the fact of formation of the electronic signature by a certain person,
using codes, passwords or other means.
4.3. Enhanced non-certified electronic signature (ENES) is an electronic signature, which:

is obtained as a result of a cryptographic transformation of information with the use of electronic signature
key;

allows to identify a person, who signed the electronic document;

allows to detect the fact of introduction of amendments to the electronic document after its signing;

is created with the use of electronic signature facilities.
4.4. The Parties shall determine cases, in which different types of ES should be applied, based on the Contract and annexes
thereto. In particular, when using passwords, security codes or hashes of such codes, ES is simple, and in case of using
cryptographic keys, ES should be ENES.
4.5. The Parties recognize that:

the introduction of amendments to the signed ED gives a negative result of ES verification:

ES forgery is impossible without using ES key of the owner or a security code;

each Party is responsible for the safekeeping of its key/code and actions of its employees when using ES facilities;

the signed ED shall enter into legal force since the moment when such document is received through the System by
the recipient and reflected in the register.
4.6. The parties shall transfer ED by transmitting data via the Internet. The Parties shall connect to the Internet by themselves
and such connection is not a subject of this Agreement.
4.7. Before using EDM, the Operator and the Counterparty shall exchange the necessary keys and/or codes. After the exchange,
the Parties shall carry out a test exchange of signed ED and ES verification in test ED.
5.
Procedure for using a simple ES
5.1. The Parties have agreed to assume that for the formation and verification of a simple ES it is enough to know the security
code (password). The Parties have agreed not to present the value of the security code to third parties and to take all
necessary measures to guarantee its confidentiality by themselves.
5.2. In order to form a simple electronic signature, one of the parties shall calculate a hash of value sequence of a number of
parameters, separated by the symbol “;” (semicolon). Such number of parameters should contain ID parameters of the
Counterparty and the security code of the Counterparty. The calculated hash is ES and should be added to the electronic
document before sending.
5.3. In order to verify a simple ES, the other Party shall repeat all the actions for the formation of a simple ES and compare the
resulting hash with the value, transmitted from the other Party. If the values coincide, then the simple ES is considered
invalid and the party, verifying ES, shall notify the other Party about it.
5.4. A cryptographic hash algorithm and the composition of parameters are defined by the Operator in the Information
Exchange Protocol when carrying out transfers.
5.5. The Parties believe that the received ED was signed by the sending party.
6.
Procedure for using an enhanced non-certified ES
6.1. In order to create and verify ENES, it is necessary to have two keys: ES key and ES verification key.
6.2. For counterfeit protection of ES verification keys, when they are transferred between the Parties, a corresponding
certificate of ES verification key shall be created in a Certification Authority.
6.3. In order to create ENES, the Party shall use ES Facility, which:

forms a hash of the original electronic document by an algorithm, specified in the Certificate;

encrypts the resulting hash, using ES key by an algorithm, specified in the Certificate;

the resulting value is ES and shall be added to the original electronic document together with the certificate, used to
create ES.
6.4. Before ENES verification the Party must check the received certificate:

the certificate must belong to the transmitting Party;

the certificate must be valid at the moment of ES verification, according to the fixed dates of the beginning and end
of the certificate validity;

the certificate shouldn’t be withdrawn or its effect shouldn’t be suspended.
6.5. In order to verify ENES, the Party shall use ES Facility, which:

forms a hash of the original electronic document by an algorithm, specified in the received Certificate;

decrypts the resulting ES, using ES verification key from the received Certificate;

compares the resulting values – if they coincide, then ES is authentic; if not, then ES is deemed invalid and the
verifying Party shall notify the sender about it.
6.6. The Counterparty and the Operator use a Certification Authority of the Operator in order to obtain the certificate of ES
verification key.
6.7. To obtain the certificate, the Counterparty shall generate ES key and a corresponding ES verification key by itself, using
ES facilities, as well as the request for certificate of PKCS#10 format.
6.8. In the request for certificate the Counterparty shall fill the following fields:

CN = Full name of the responsible officer or the name of the organization or the alias;

E = E-mail address;

OU = Name of the organization unit;

O = Name of the organization;

L = City of location of the organization;

C = Country code (for example, for Russia C=RU).
6.9. The Operator receives the Counterparty's request and, based on it, forms a certificate of ES verification key of the
Counterparty.
6.10. The certificate has the following parameters:

signature algorithm – RSA;

key length – 2048 бит;

hash algorithm – sha1.
6.11. A hash algorithm can be replaced by a more stable one by mutual consent of the Parties.
6.12. The Operator shall send to the Counterparty the certificate, which will be used to sign ED in the System, as well as the
full certificate chain:

CA root certificate;

CA intermediate certificates.
6.13. The Parties have agreed to trust the certificates they exchanged.
6.14. The certificate file shall be transmitted in X.509 (Base64 or DER encoding, .cer file extension) or PKCS#7 (.p7b file
extension) format by e-mail or in a different way, agreed in advance.
6.15. The Parties shall print their certification files in hard copies, sign by the responsible person with the seal of the organization
and transfer to the other Party. An example of the certificate form in hard copy is presented at the end of this Annex.
6.16. The Parties undertake to use all reasonable efforts for confidentiality preservation of ES keys.
6.17. In case of ES key compromise (or reasonable suspicions of this), the Party shall:

stop the transmission of ED in the System and immediately (if not possible, within 1 business day) notice the other
Party about the fact of compromise of its ES key;

generate a new ES key, ES verification key and issue a new certificate of ES verification key;

transfer a file with a new certificate to the other Party;

check that the CA has entered a serial number of the compromised certificate in the list of withdrawn certificates and
published a new list of withdrawn certificates;

restore work of the System as agreed with the other Party.
6.18. At transferring encrypted electronic documents, the following procedure is applied:

The transferring Party shall sign the electronic document with its ES key, encrypt the signed ED with ES verification
key from the certificate of the receiving Party and send the encrypted signed ED.

The receiving Party shall decrypt the received document with its ES key and verify ES, using ES verification key
from the certificate of the transferring Party.
7. Obligations of the Parties
The Parties undertake:
7.1.
7.2.
7.3.
7.4.
To complete the System with necessary hardware and software facilities by themselves;
To exchange certificates of ES verification key;
To appoint persons responsible for working with the System in accordance with the present Agreement;
To appoint the Security Manager, responsible for generation, recording, exchange and safety of keys/codes, used in the
System, for protecting against unauthorized access and maintaining System ES facilities in operation.
7.5. To carry out timely scheduled replacement of ES keys and corresponding certificates in accordance with the existing
requirements:

CA regulations;

current legislation;

internal executive documents.
If there are no such requirements, it is recommended to carry out scheduled replacement 10 days before the expiry of
validity period of the certificate.
7.6. To inform the other Party immediately about all cases of loss, theft, unauthorized access to ES key at the following
addresses: the Operator merchants@money.yandex.ru, the Counterparty –addresses specified in the Contract or in the
Application. In this case, work in the System shall be suspended until scheduled replacement of keys is carried out.
7.7. To assume all risks related to the performance of its equipment and communication lines.
7.8. To maintain software and hardware complexes for performance assurance of computing and communication engineering,
providing electronic documents management, within the System, in proper working order on its own account.
7.9. To enable access to ES facilities only for persons authorized to sign documents.
7.10. Not to take actions which could harm the System of the other Party when using EDM, for example, not to arrange network
attacks, attacks on denial of service, virus attacks and others.
7.11. To inform the other Party (by e-mail from p.5.6. and/or by phone) about all cases of technical faults or other circumstances,
preventing electronic document management, in time.
7.12. In case of detection of potential security threats, the Parties undertake to inform each other about such threats in time in
order to take agreed measures to neutralize them.
7.13. To meet the requirements of technical and operational documentation for software and hardware of the System.
7.14. It is recommended to develop and implement measures to ensure the System information security:

confidentiality, integrity and availability of software and hardware;

confidentiality of ED transferred;

integrity and availability of event registration protocols;

confidentiality, integrity of the existing key and password information;

to organize the internal operation mode of the workplace of the responsible person in such a way as to preclude the
possibility of using the System by persons, who has no access to work with it;

to ensure confidentiality of data concerning information security technologies, used in the System.
7.15. To maintain the system time of hardware and software facilities of the System in accordance with the current astronomical
time with the accuracy of five minutes. The Parties acknowledge Moscow Time MSK (UTC +3) as a single timescale.
7.16. The Parties shall organize ED archiving during the term of validity of similar documents, executed in hard copies.
8. Rights of the Parties
The Parties are entitled:
8.1. To restrict or suspend the use of the System in case of improper performance of the Agreement by the other Party, with a
notice no later than the date of the suspension, and at the request of competent public authorities where and as provided
by the legislation of the Russian Federation.
8.2. To replace hardware and software of the System subject to minimum three working days’ prior notice to the other Party.
8.3. To stop operation of the System for technical reasons until its performance is restored.
8.4. To perform scheduled and unscheduled replacement of the security code, ES key, ES verification key subject to minimum
two working days’ prior notice to the other Party.
9.
Liability of the Parties and Downside Risks
9.1. The Parties are responsible for the content of ED, signed by them, subject to authenticity of ES.
9.2. The Parties are responsible for the confidentiality and procedure for using ES keys and codes.
9.3. The Party, which allowed ES key compromise, is responsible for ED, signed with the use of the compromised ES key,
until the official notice of cancellation (withdrawal) of a corresponding certificate.
9.4. The Party, which informed about cases of loss or compromise of ES key untimely, shall bear associated risks.
9.5. In case of losses, the Party, which failed to perform (improperly performed) its obligations under the Agreement, shall be
liable to the other Party for the losses incurred. In the absence of evidence of non-performance (improper performance) of
obligations under the Agreement by the Parties, the Party, ES of which is in ED, performance of which resulted in losses,
shall bear downside risks.
9.6. The Parties shall be free from the responsibility for partial or complete non-performance of their obligations under the
Agreement, if such non-performance arose from force majeure circumstances, occurred after the entry into force of the
Agreement, as a result of extraordinary events, which could not be foreseen and prevented by reasonable measures. The
Party shall immediately notify the other Party about the occurrence and termination of force majeure circumstances,
preventing the performance of its obligations under the Agreement. In this case, the term of performance of obligations
under the Agreement shall be prolonged in proportion to the period of such circumstances.
9.7. In case of termination of this Agreement for any reason, the Parties shall bear the responsibility for obligations arising
prior to the termination of the Agreement, in accordance with the legislation of the Russian Federation.
10. Settlement of disputes related to ES authentication
10.1. Any disputes between the Parties, the subject of which is authentication of electronic signature in ED, i.e. verification of
text integrity and authenticity of the sender of ED, shall be submitted for settlement to a specially created Expert
Commission.
10.2. The Expert Commission shall be convened on the basis of a written statement (claim) of any of the Parties. In the
abovementioned statement, the Party shall indicate the details of the contested signed ED and persons, authorized to
represent the interests of this Party as part of the Expert Commission.
10.3. Not later than 10 working days from receipt of the statement (claim) by the other Party, the Parties shall determine the
date, place and time of the beginning of work of the Expert Commission, determine, what Party will provide the room and
carry out configuration of ES facilities.
10.4. Powers of members of the Expert Commission shall be confirmed by powers of attorney.
10.5. The Expert Commission shall be formed of representatives of the Parties in equal proportions.
10.6. The expert examination of the contested ED shall be performed in the presence of all members of the Expert Commission.
10.7. The expert examination shall be performed in for steps:
1st step: the Parties shall jointly install, configure and test ES facility.
2nd step: the Parties shall provide their copies of certificates of ES verification keys for ENES or security codes for a simple
ES, used to create ES of the contested ED;
Зrd step: the Commission shall compare the obtained certificates with corresponding certificates or security codes to the
codes from the questionnaire received durion the conclusion of the Contract. Certificates and codes, which coincided, are
deemed authentic. The Commission also verifies the authenticity of the whole chain of certificates, if any.
4th step: if the third step is passed successfully, the Commission shall verify authenticity of ES under the contested
document under the normal procedure, described in this Agreement.
10.8. Expert examination results shall be documented in the form of written opinion – Expert Commission Act, signed by all
members of the Expert Commission. The Act shall be drawn up immediately after the completion of the last step of the
expert examination. The Act shall contain results of all steps of the performed expert examination, as well as all essential
details of the contested ED. The Act is made in two copies – one for each Party. The Commission Act is final and not
subject to revision.
10.9. The authentication of ES in the contested signed ED and fixed in the Act shall mean that this ED has full force and effect
and entails the emergence of rights and obligations of the Parties, established by the Contract and the Agreement.
10.10.
The Parties acknowledge that the Act, drawn up by the Expert Commission, is binding on the Parties and can serve
as evidence in further consideration of a dispute in the Arbitration Court.
10.11.
In the absence of agreement on disputable issues and voluntary execution of the decision of the Expert
Commission, all materials on these matters may be referred to the Arbitration Court of Moscow.
11. Authorized persons, entitled to use ES in the name of the Parties, are:
Authorized persons to use the ES on behalf of the Parties are: from the Operator — Chairman of the Board, Tatyana Andreevna
Shabanova, from the Counterparty — the person who signed the Application or the Conract on behalf of the Counterparty.
12. An example of the form for Certificate printing:
Yandex.Money Certification Authority
Signature Key Certificate
Issued to: Yandex.Money
Issued by: Yandex.Money CA
Valid from January 1, 2010 till December 31, 2020.
Version:
V3
Serial number:
00 00 00 01
Signature algorithm:
sha1RSA
Issuer (CN):
Yandex.Money CA
Organization Unit (OU):
CA
Organization (O):
Yandex.Money
City (L):
Moscow
Region (S):
Moscow
Country (C):
RU
Valid from:
January 1, 2010 0:00:00 (GMT+04:00)
Valid till:
December 31, 2020 23:59:59 (GMT+04:00)
Owner (CN):
Yandex.Money
Organization Unit (OU):
Web
Organization (O):
Yandex.Money
City (L):
Moscow
Region (S):
Moscow
Country (C):
RU
Public Key:
RSA (2048 bits)
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
Print algorithm:
sha1
Print:
8a 16 b4 5c 3b 86 f9 84 31 d9 4e 68 89 3c 0c e1 d0 2a 0f 0e
Results of certificate verification: The Certificate is valid. Verified on April 1, 2015 0:00:00 (GMT+04:00).
Authorized person of the Certification Authority
Signature __________________ L.S.
«____» ________________ 20 __
Download