Электронные подписи и инфраструктуры (esi); усовершенствованные электронные подписи cms (CAdES)



бет6/17
Дата29.02.2016
өлшемі2.44 Mb.
#34652
1   2   3   4   5   6   7   8   9   ...   17
validation process validates an electronic signature; the output status of the validation process can be:<}0{>В процессе проверки выполняется проверка электронной подписи. В результате может быть получен один из следующих статусов:<0}

  • {0>invalid;<}0{>недействительный;<0}

  • {0>incomplete validation; or<}0{>незавершенная проверка;<0}

  • {0>valid.<}0{>действительный.<0}

{0>An invalid response indicates that either the signature format is incorrect or that the digital signature value fails verification (e.g. the integrity check on the digital signature value fails, or any of the certificates on which the digital signature verification depends is known to be invalid or revoked).<}0{>Недействительный статус означает, что формат подписи неправильный или цифровая подпись не смогла пройти проверку (например, произошла ошибка проверки целостности цифровой подписи или один из сертификатов, от которого зависит проверка цифровой подписи, является недействительным или отозванным).<0}

{0>An incomplete validation response indicates that the signature validation status is currently unknown.<}0{>Незавершенная проверка означает, что статус проверки подписи на данный момент неизвестен.<0} {0>In the case of incomplete validation, additional information may be made available to the application or user, thus allowing them to decide what to do with the electronic signature.<}100{>В случае незавершенной проверки приложению или пользователю могут быть предоставлены дополнительные сведения. Это позволит определить дальнейший ход действий при работе с электронной подписью.<0} {0>In the case of incomplete validation, the electronic signature may be checked again at some later time when additional information becomes available.<}0{>При незавершенной проверке электронную подпись можно проверить позже, когда станет доступна дополнительная информация.<0}

{0>NOTE:<}100{>ПРИМЕЧАНИЕ.<0} {0>For example, an incomplete validation may be because all the required certificates are not available or the grace period is not completed.<}0{>Статус незавершенной проверки, например, может быть вызван недоступностью всех необходимых сертификатов или незаконченным периодом отсрочки.<0}

{0>A valid response indicates that the signature has passed verification, and it complies with the signature validation policy.<}0{>Действительный статус означает, что подпись прошла проверку и соответствует регламенту проверки подписи.<0}

{0>Example validation sequences are illustrated in annex B.<}0{>Примеры последовательностей проверки приведены в приложении Б.<0}
5 {0>Electronic Signature Attributes<}100{>Атрибуты электронных подписей<0}

{0>This clause builds upon the existing Cryptographic Message Syntax (CMS), as defined in RFC 3852 [4], and Enhanced Security Services (ESS), as defined in RFC 2634 [5].<}0{>Этот пункт основан на существующем синтаксисе CMS, определенном в документе RFC 3852 [4], и улучшенных службах безопасности (ESS), определенных в документе RFC 2634 [5].<0} {0>The overall structure of an Electronic Signature is as defined in CMS.<}0{>Общая структура электронной подписи соответствует структуре, определенной в CMS.<0} {0>The Electronic Signature (ES) uses attributes defined in CMS, ESS, and the present document.<}0{>Электронная подпись использует атрибуты, определенные в CMS, ESS и настоящем документе.<0} {0>The present document defines ES attributes that it uses and that are not defined elsewhere.<}0{>В настоящем документе определены атрибуты подписи, используемые, но не определенные в других материалах.<0}

{0>The mandated set of attributes and the digital signature value is defined as the minimum Electronic Signature (ES) required by the present document.<}0{>В настоящем документе определен минимально необходимый набор атрибутов и значения цифровой подписи для электронной подписи.<0} {0>A signature policy may mandate that other signed attributes be present.<}0{>Регламент подписи может требовать наличия других подписанных атрибутов.<0}

5.1 {0>General Syntax<}100{>Общий синтаксис<0}



{0>The general syntax of the ES is as defined in CMS (RFC 3852 [4]).<}0{>Общий синтаксис электронной подписи соответствует синтаксису, определенному в CMS (RFC 3852 [4]).<0}

{0>NOTE:<}100{>ПРИМЕЧАНИЕ.<0} {0>CMS defines content types for id-data, id-signedData, id-envelopedData, id-digestedData, id-encryptedData, and id-authenticatedData.<}0{>Синтаксис CMS определяет типы содержимого для атрибутов id-data, id-signedData, id-envelopedData, id-digestedData, id-encryptedData и id-authenticatedData.<0} {0>Although CMS permits other documents to define other content types, the ASN.1 type defined should not be a CHOICE type.<}0{>Хотя CMS разрешает определение других типов содержимого в других документах, тип ASN.1 не должен быть типом CHOICE (выбор).<0} {0>The present document does not define other content types.<}0{>В данном документе не определяются другие типы содержимого.<0}

5.2 {0>Data Content Type<}100{>Тип содержимого данных<0}



{0>The data content type of the ES is as defined in CMS (RFC 3852 [4]).<}86{>Тип содержимого данных электронной подписи соответствует типу, определенному в CMS (RFC 3852 [4]).<0}

{0>NOTE:<}100{>ПРИМЕЧАНИЕ.<0} {0>If the content type is id-data, it is recommended that the content be encoded using MIME, and that the MIME type is used to identify the presentation format of the data.<}0{>Если типом содержимого является id-data, рекомендуется кодировать содержимое с помощью формата MIME и использовать тип MIME для определения формата представления данных.<0} {0>See clause F.1 for an example of using MIME to identify the encoding type.<}0{>Пример использования MIME для определения типа кодирования см. в пункте Е.1.<0}

5.3 {0>Signed-data Content Type<}100{>Тип содержимого подписанных данных<0}



{0>The Signed-data content type of the ES is as defined in CMS (RFC 3852 [4]).<}96{>Тип содержимого Signed-data электронной подписи соответствует типу, определенному в CMS (RFC 3852 [4]).<0}

5.4 {0>SignedData Type<}100{>Тип SignedData<0}



{0>The syntax of the SignedData of the ES is as defined in CMS (RFC 3852 [4]).<}82{>Синтаксис типа SignedData соответствует синтаксису, определенному в CMS (RFC 3852 [4]).<0}

{0>The fields of type SignedData are as defined in CMS (RFC 3852 [4]).<}71{>Поля типа SignedData соответствуют полям, определенным в CMS (RFC 3852 [4]).<0}

{0>The identification of a signer's certificate used to create the signature is always signed (see clause 5.7.3).<}0{>Идентификатор сертификата подписывающей стороны, использованного для создания подписи, всегда подписан (см. пункт 5.7.3).<0} {0>The validation policy may specify requirements for the presence of certain certificates.<}0{>Регламент проверки может задавать требования наличия определенных сертификатов.<0} {0>The degenerate case, where there are no signers, is not valid in the present document.<}0{>Случай вырождения, в котором подписывающих сторон нет, не является действительным согласно данному документу.<0}

5.5 {0>EncapsulatedContentInfo Type<}0{>Тип EncapsulatedContentInfo<0}



{0>The syntax of the EncapsulatedContentInfo type ES is as defined in CMS (RFC 3852 [4]).<}85{>Синтаксис типа EncapsulatedContentInfo электронной подписи соответствует синтаксису, определенному в CMS (RFC 3852 [4]).<0}

{0>For the purpose of long-term validation, as defined by the present document, it is advisable that either the eContent is present, or the data that is signed is archived in such as way as to preserve any data encoding.<}0{>В целях долгосрочной проверки, как определено в данном документе, рекомендуется использовать атрибут eContent или архивировать подписываемые данные так, чтобы сохранить кодирование данных.<0} {0>It is important that the OCTET STRING used to generate the signature remains the same every time either the verifier or an arbitrator validates the signature.<}0{>Важно, чтобы строка октетов (OCTET STRING), используемая для создания подписи, оставалась одинаковой при каждой проверке подписи арбитром или проверяющей стороной.<0}

{0>NOTE:<}100{>ПРИМЕЧАНИЕ.<0} {0>The eContent is optional in CMS:<}0{>В CMS атрибут eContent является необязательным:<0}

  • {0>When it is present, this allows the signed data to be encapsulated in the SignedData structure which then contains both the signed data and the signature.<}0{>если он присутствует, подписанные данные необходимо встроить в структуру SignedData, которая будет содержать как подписанные данные, так и подпись;<0} {0>However, the signed data may only be accessed by a verifier able to decode the ASN.1 encoded SignedData structure.<}0{>однако доступ к подписанным данным может получить только проверяющая сторона, которая может декодировать структуру SignedData, закодированную в формате ASN.1;<0}

  • {0>When it is missing, this allows the signed data to be sent or stored separately from the signature, and the SignedData structure only contains the signature.<}0{>если этот атрибут отсутствует, подписанные данные можно отправлять и хранить отдельно от подписи, а структура SignedData содержит только подпись;<0} {0>It is, in the case of the signature, only the data that is signed that needs to be stored and distributed in such as way as to preserve any data encoding.<}100{>в этом случае только подписываемые данные необходимо сохранять и распространять таким образом для сохранения кодировки данных.<0}

{0>The degenerate case where there are no signers is not valid in the present document.<}99{>Случай вырождения, когда подписывающих сторон нет, не является действительным согласно данному документу.<0}

5.6 {0>SignerInfo Type<}0{>Тип SignerInfo<0}



{0>The syntax of the SignerInfo type ES is as defined in CMS (RFC 3852 [4]).<}95{>Синтаксис типа SignerInfo электронной подписи соответствует синтаксису, определенному в CMS (RFC 3852 [4]).<0}

{0>Per-signer information is represented in the type SignerInfo.<}0{>В типе SignerInfo представлена информация о подписывающей стороне.<0} {0>In the case of multiple independent signatures (see clause B.5), there is an instance of this field for each signer.<}0{>При наличии нескольких независимых подписей (см. пункт Б.5) для каждой подписывающей стороны присутствует экземпляр этого поля.<0}

{0>The fields of type SignerInfo have the meanings defined in CMS (RFC 3852 [4]), but the signedAttrs field shall contain the following attributes:<}0{>Значение полей типа SignerInfo соответствует синтаксису CMS (RFC 3852 [4]), но поле signedAttrs должно содержать следующие атрибуты:<0}

  • {0>content-type, as defined in clause 5.7.1;<}0{>content-type, как определено в пункте 5.7.1;<0}

  • {0>message-digest, as defined in clause 5.7.2; and<}70{>message-digest, как определено в пункте 5.7.2;<0}

  • {0>signing-certificate, as defined in clause 5.7.3.<}74{>signing-certificate, как определено в пункте 5.7.3.<0}

5.6.1 {0>Message Digest Calculation Process<}100{>Процесс вычисления хэш-значения сообщения<0}

{0>The message digest calculation process is as defined in CMS (RFC 3852 [4]).<}67{>Процесс вычисления хэш-значения соответствует процессу, определенному в CMS (RFC 3852 [4]).<0}

5.6.2 {0>Signature Generation Process<}100{>Процесс формирования подписи<0}



{0>The input to the signature generation process is as defined in CMS (RFC 3852 [4]).<}76{>Входные данные для процесса формирования подписи соответствуют данным, определенным в CMS (RFC 3852 [4]).<0}

5.6.3 {0>Signature Verification Process<}100{>Процесс проверки подписи<0}



{0>The procedures for signature verification are defined in CMS (RFC 3852 [4]) and enhanced in the present document:<}0{>Процедуры проверки подписи определены в CMS (RFC 3852 [4]) и усовершенствованы в данном документе:<0} {0>the input to the signature verification process must be the signer's public key, which shall be verified as correct using the signing certificate reference attribute containing a reference to the signing certificate, i.e. when SigningCertificateV2 from RFC 5035 [15] or SigningCertificate from ESS RFC 2634 [5] is used, the public key from the first certificate identified in the sequence of certificate identifiers from SigningCertificate must be the key used to verify the digital signature.<}100{>входными данными для процесса проверки подписи должен быть открытый ключ подписывающей стороны, который должен проверяться с помощью атрибута ссылки сертификата подписи, который содержит ссылку на сертификат подписи. Т. е. если используется сертификат SigningCertificateV2 из документа RFC 5035 [15] или SigningCertificate из документа ESS RFC 2634 [5], открытый ключ из первого сертификата, который определен в последовательности идентификаторов сертификатов, полученный от SigningCertificate должен использоваться для проверки цифровой подписи.<0}

5.7 {0>Basic ES Mandatory Present Attributes<}100{>Обязательные атрибуты простой электронной подписи<0}



{0>The following attributes shall be present with the signed-data defined by the present document.<}0{>Следующие атрибуты должны присутствовать в подписанных данных, определенных в данном документе.<0} {0>The attributes are defined in CMS (RFC 3852 [4]).<}63{>Атрибуты определены в CMS (RFC 3852 [4]).<0}

5.7.1 {0>content-type<}100{>Атрибут content-type<0}



{0>The content-type attribute indicates the type of the signed content.<}0{>Атрибут content-type показывает тип подписываемого содержимого.<0} {0>The syntax of the content-type attribute type is as defined in CMS (RFC 3852 [4]), clause 11.1.<}76{>Синтаксис атрибутного типа content-type соответствует синтаксису, определенному в CMS (RFC 3852 [4]), пункт 11.1.<0}

{0>NOTE 1:<}100{>ПРИМЕЧАНИЕ 1.<0} {0>As stated in RFC 3852 [4], the content-type attribute has its value (i.e. ContentType) equal to the eContentType of the EncapsulatedContentInfo value being signed.<}0{>Как указано в документе RFC 3852 [4], значение атрибута content-type (т. е. ContentType) равно значению eContentType подписываемого атрибута EncapsulatedContentInfo.<0}

{0>NOTE 2:<}100{>ПРИМЕЧАНИЕ 2.<0} {0>For implementations supporting signature generation, if the content-type attribute is id-data, then it is recommended that the eContent be encoded using MIME.<}0{>Для реализаций, поддерживающих создание подписей, если значением атрибута content-type является id-data, рекомендуется кодировать eContent с использованием формата MIME.<0} {0>For implementations supporting signature verification, if the signed data (i.e. eContent) is MIME-encoded, then the OID of the content-type attribute is id-data.<}0{>Для реализаций, поддерживающих проверку подписей, если подписанные данные (т. е. eContent) закодированы с использованием формата MIME, то идентификатором объекта атрибута content-type является id-data.<0} {0>In both cases, the MIME content-type(s) is used to identify the presentation format of the data.<}0{>В обоих случаях атрибуты content-type MIME используются для определения формата представления данных.<0} {0>See annex F for further details about the use of MIME.<}0{>Дополнительные сведения об использовании MIME см. в приложении Е.<0}

5.7.2 {0>Message Digest<}100{>Хэш-значение сообщения<0}



{0>The syntax of the message-digest attribute type of the ES is as defined in CMS (RFC 3852 [4]).<}85{>Синтаксис атрибута message-digest (хэш-значение сообщения) электронной подписи соответствует синтаксису, определенному в CMS (RFC 3852 [4]).<0}

5.7.3 {0>Signing Certificate Reference Attributes<}100{>Атрибуты ссылки на сертификат подписи<0}



{0>The Signing certificate reference attributes are supported by using either the ESS signing-certificate attribute or the ESS-signing-certificate-v2 attribute.<}0{>Атрибуты ссылки на сертификат подписи поддерживаются с помощью атрибута ESS signing-certificate или атрибута ESS-signing-certificate-v2.<0}

{0>These attributes shall contain a reference to the signer's certificate; they are designed to prevent simple substitution and reissue attacks and to allow for a restricted set of certificates to be used in verifying a signature.<}0{>Эти атрибуты должны содержать ссылку на сертификат подписывающей стороны. Они предназначены для предотвращения простых атак с заменой и повторной выдачей, а также позволяют использовать ограниченный набор сертификатов для проверки подписи.<0} {0>They have a compact form (much shorter than the full certificate) that allows for a certificate to be unambiguously identified.<}0{>У них компактная форма (намного короче, чем у полных сертификатов), что позволяет однозначно идентифицировать сертификат.<0}

{0>One, and only one, of the following alternative attributes shall be present with the signedData, defined by the present document:<}61{>Один и только один из следующих атрибутов должен присутствовать в поле signedData, определенном в данном документе:<0}

  • {0>The ESS signing-certificate attribute, defined in ESS RFC 2634 [5], must be used if the SHA-1 hashing algorithm is used.<}0{>атрибут signing-certificate ESS, определенный в документе ESS RFC 2634 [5], должен использоваться, если применяется алгоритм хэширования SHA-1;<0}

  • {0>The ESS signing-certificate -v2 attribute, defined in "ESS Update:<}94{>атрибут signing-certificate-v2 ESS, определенный в документе ESS Update:<0} {0>Adding CertID Algorithm Agility", RFC 5035 [15], which shall be used when other hashing algorithms are to be used.<}0{>Adding CertID Algorithm Agility, RFC 5035 [15], который должен использовать при применении других алгоритмов хэширования.<0}

{0>The certificate to be used to verify the signature shall be identified in the sequence (i.e. the certificate from the signer), and the sequence shall not be empty.<}0{>Сертификат, используемый для проверки подписи (т. е. сертификат подписывающей стороны), должен быть определен в проверочной последовательности, и эта последовательность не должна быть пустой.<0} {0>The signature validation policy may mandate other certificates be present that may include all the certificates up to the trust anchor.<}0{>Регламент проверки подписи может требовать наличия других сертификатов, которые могут содержать все сертификаты, вплоть до точки доверия.<0}

5.7.3.1 {0>ESS signing-certificate Attribute Definition<}100{>Определение атрибута signing-certificate ESS<0}



{0>The syntax of the signing-certificate attribute type of the ES is as defined in Enhanced Security Services (ESS), RFC 2634 [5], and further qualified in the present document.<}0{>Синтаксис атрибута типа signing-certificate электронной подписи соответствует синтаксису, определенному в улучшенных службах безопасности (ESS), RFC 2634 [5], и описывается далее в данном документе.<0}

{0>The sequence of the policy information field is not used in the present document.<}0{>Последовательность поля с информацией о регламенте не используется в настоящем документе.<0}

{0>The ESS signing-certificate attribute shall be a signed attribute.<}0{>Атрибут signing-certificate ESS должен быть подписанным атрибутом.<0} {0>The encoding of the ESSCertID for this certificate shall include the issuerSerial field.<}0{>Кодированное значение ESSCertID для данного сертификата должно включать поле issuerSerial.<0}

{0>If present, the issuerAndSerialNumber in SignerIdentifier field of the SignerInfo shall match the issuerSerial field present in ESSCertID.<}0{>При наличии данного атрибута значение issuerAndSerialNumber в поле SignerIdentifier структуры SignerInfo должно совпадать со значением поля issuerSerial в ESSCertID.<0} {0>In addition, the certHash from ESSCertID shall match the SHA-1 hash of the certificate.<}0{>Кроме того, значение certHash из ESSCertID должно совпадать с хэш-значением сертификата, вычисленным по алгоритму SHA-1.<0} {0>The certificate identified shall be used during the signature verification process.<}0{>Опознанный сертификат должен использоваться в процессе проверки подписи.<0} {0>If the hash of the certificate does not match the certificate used to verify the signature, the signature shall be considered invalid.<}0{>Если хэш-значение сертификата не совпадает с хэш-значением сертификата, используемого для проверки подписи, подпись должна считаться недействительной.<0}

{0>NOTE:<}100{>ПРИМЕЧАНИЕ.<0} {0>Where an attribute certificate is used by the signer to associate a role, or other attributes of the signer, with the electronic signature; this is placed in the signer-attributes attribute as defined in clause 5.8.3.<}0{>Если атрибутный сертификат используется подписывающей стороной для связи роли или других атрибутов подписывающей стороны с электронной подписью, то данные сведения указываются в атрибуте signer-attributes, как определено в пункте 5.8.3.<0}

5.7.3.2 {0>ESS signing-certificate-v2 Attribute Definition<}100{>Определение атрибута ESS signing-certificate-v2<0}



{0>The ESS signing-certificate-v2 attribute is similar to the ESS signing-certificate defined above, except that this attribute can be used with hashing algorithms other than SHA-1.<}0{>Атрибут signing-certificate-v2 ESS аналогичен атрибуту signing-certificate ESS, определенному выше, за исключением того, что этот атрибут можно использовать с алгоритмами хэширования, отличными от SHA-1.<0}

{0>The syntax of the signing-certificate-v2 attribute type of the ES is as defined in "ESS Update:<}63{>Синтаксис атрибутного типа signing-certificate-v2 электронной подписи соответствует синтаксису, определенному в документе ESS Update:<0} {0>Adding CertID Algorithm Agility", RFC 5035 [15], and further qualified in the present document.<}0{>Adding CertID Algorithm Agility, RFC 5035 [15] и описывается далее в данном документе.<0}

{0>The sequence of the policy information field is not used in the present document.<}100{>Последовательность поля с информацией о регламенте не используется в настоящем документе.<0}

{0>This attribute shall be used in the same manner as defined above for the ESS signing-certificate attribute.<}0{>Этот атрибут должен использоваться так же, как и атрибут signing-certificate ESS, описанный выше.<0}

{0>The object identifier for this attribute is:<}0{>Идентификатор объекта данного атрибута:<0}

id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 47 }



{0>If present, the issuerAndSerialNumber in SignerIdentifier field of the SignerInfo shall match the issuerSerial field present in ESSCertIDv2.<}95{>При наличии данного атрибута значение issuerAndSerialNumber в поле SignerIdentifier структуры SignerInfo должно совпадать со значением поля issuerSerial в ESSCertIDv2.<0} {0>In addition, the certHash from ESSCertIDv2 shall match the hash of the certificate computed using the hash function specified in the hashAlgorithm field.<}0{>Кроме того, значение certHash из ESSCertIDv2 должно совпадать с хэш-значением, вычисленным с помощью функции хэширования, указанной в поле hashAlgorithm.<0} {0>The certificate identified shall be used during the signature verification process.<}100{>Опознанный сертификат должен использоваться в процессе проверки подписи.<0} {0>If the hash of the certificate does not match the certificate used to verify the signature, the signature shall be considered invalid.<}100{>Если хэш-значение сертификата не совпадает с хэш-значением сертификата, используемого для проверки подписи, подпись должна считаться недействительной.<0} {0>Implementations of the present document shall support the usage of both the signing-certificate attribute and the signing-certificate-v2 attribute, within timestamp tokens, in accordance with RFC 5035 [15].<}0{>Реализации данного документа должны поддерживать использование как атрибута signing-certificate, так и атрибута signing-certificate-v2 в штампах времени в соответствии с документом RFC 5035 [15].<0}

{0>NOTE 1:<}100{>ПРИМЕЧАНИЕ 1.<0} {0>Where an attribute certificate is used by the signer to associate a role, or other attributes of the signer, with the electronic signature; this is placed in the signer-attributes attribute as defined in clause 5.8.3.<}97{>Если атрибутный сертификат используется подписывающей стороной для связи роли или других атрибутов подписывающей стороны с электронной подписью, то данные сведения указываются в атрибуте signer-attributes, как определено в пункте 5.8.3.<0}

{0>NOTE 2:<}100{>ПРИМЕЧАНИЕ 2.<0} {0>Previous versions of the current document used the other signing certificate attribute (see clause 5.7.3.3) for the same purpose.<}0{>В предыдущих версиях данного документа для той же цели использовался другой атрибут сертификата подписи (см. пункт 5.7.3.3).<0} {0>Its use is now deprecated, since this structure is simpler.<}0{>Теперь данный атрибут не используется за счет упрощения структуры.<0}

5.7.3.3 {0>Other signing-certificate Attribute Definition<}100{>Другое определение атрибута signing-certificate<0}



{0>Earlier versions of the current document used the other signing-certificate attribute as an alternative to the ESS signing-certificate when hashing algorithms other than SHA-1 were being used.<}0{>В более ранних версиях данного документа другой атрибут signing-certificate использовался в качестве альтернативы атрибуту signing-certificate ESS при применении алгоритмов хэширования, отличных от SHA-1.<0} {0>Its use is now deprecated, since the structure of the signing-certificate-v2 attribute is simpler.<}64{>Теперь данный атрибут не используется, так как структура атрибута signing-certificate-v2 была упрощена.<0}

{0>Its description is however still present in the present document for backwards compatibility.<}0{>Но его описание все равно включено в настоящий документ для обеспечения обратной совместимости.<0}

id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1)

member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)

smime(16) id-aa(2) 19 }



{0>The other-signing-certificate attribute value has the ASN.1 syntax OtherSigningCertificate

Достарыңызбен бөлісу:
1   2   3   4   5   6   7   8   9   ...   17




©dereksiz.org 2024
әкімшілігінің қараңыз

    Басты бет