Qualified electronic signature - problems of OIDs of information systems. Bad signature Signature failed verification Missing object identifier OID Oid decryption

When you enter your personal account to request a QEP, a message is displayed « Computer not configured . To proceed, go to the computer settings page and follow the suggested steps » . After going to the settings page and installing all the necessary components in personal account the message that the computer is not configured again appears.

To fix the error, you must:

1. Add the address of your personal account https://i.kontur-ca.ru to the trusted nodes. For this:

Select the menu "Start" > "Control Panel" > "Internet Options";
Go to the "Security" tab, select the element "Trusted sites" (or "Trusted sites") and click on the "Nodes" button;
Specify the following node address https://i.kontur-ca.ru in the Add to zone field and click the Add button.

If this address is already in the list of trusted sites, go to the next step.

2. Check that the address of the personal account https://i.kontur-ca.ru is defined as reliable:

If Internet Explorer version 8 is used, then, being on the authorization page, you should check if the Trusted Sites checkbox is at the bottom of the page. If there is no checkbox, but there is an inscription « Internet”, then the address https://i.kontur-ca.ru has not been added to trusted sites.

If Internet Explorer version 9 and higher is used, then, being on the authorization page, you should right-click anywhere on the page, select "Properties". In the window that opens, the "Zone" line should contain the inscription "Trusted Sites". Otherwise, the address https://i.kontur-ca.ru has not been added to trusted sites.

If the personal account address is not defined as reliable, then you should contact the system administrator with a request to add the address https://i.kontur-ca.ru to the trusted sites.

3. Check if you can log in to your Personal Account. If the error repeats, then you should run the RegOids utility from the link. This utility will automatically configure the OID settings in the computer's registry. You can also manually import one of the registry branches, depending on the bitness of the installed operating system:

4. Check that the computer is using administrator rights (to check, go to Start - Control Panel - User Accounts and Family Safety - User Accounts). If the rights are not enough, you need to give the user full rights, for this, contact your administrator.

5. After completing step 3, it is necessary to restart the computer and check the entrance to the Personal Account.

If none of the instructions helped, then you should contact technical support by the address [email protected] The letter must indicate:

1. Diagnosis number.

To do this, you need to go to the diagnostic portal athttps://help.kontur.ru , press the button « Start Diagnostics » . Once the verification process is completed, the diagnostic number will be displayed on the screen. Specify the assigned reference number in the letter.

2. Screenshot of the window with the error (when using Internet Explorer version 9 and higher, you must also attach a screenshot of the "Properties" window - see point 2).

3. Export and attach the following registry branches:

32-bit: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo
64-bit: HKLM\SOFTWARE\Wow6432Node\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo

General provisions.
The choice of a method for presenting certain data and additional restrictions on the composition of certificate fields is based on the following principles:
International recommendations. This document has been developed taking into account international recommendations:
- RFC 3280 (updating RFC 2459) Internet X.509 Public Key Infrastructure. Certificate and Certificate Revocation List (CRL) Profile.
- RFC 3039 Internet X.509 Public Key Infrastructure. Qualified Certificate Profile - This RFC proposes General requirements to the syntax (composition) of certificates, the use of which is legally significant.

Composition and purpose of certificate fields.

This section provides a description of the main fields of a public key certificate that complies with the Law "On Electronic Digital Signature" dated 10.01.2002.

The concepts, notations and terminology used in this section are based on RFC 3280 and RFC 3039, which, in turn, are based on ITU-T X.509 Recommendation version 3. The content of the section does not copy the content of these documents, but only indicates the differences and features of the use of fields certificates that implement the requirements for the composition of the EDS certificate set forth in Article 6 of the EDS Law.

For all certificate fields that require Russian-language string values, it is preferable to use the universal UTF-8 encoding (UTF8String type).

The purpose of this section is to define the composition and purpose of the certificate fields without taking into account the requirements of a particular certification authority. Documents governing the operation of a certification authority may limit the composition of the certificate fields and the set of attributes used to identify the CA and certificate holders signature keys.

version
All issued certificates must have version 3.

SerialNumber
SerialNumber field must contain "... a unique registration number of the signature key certificate" (Article 6, clause 1, paragraph 1). The uniqueness of the certificate number must be respected within a given certification authority (CA).

Validity
Validity field must contain "... the dates of the beginning and expiration of the validity period of the signature key certificate located in the register of the certification center" (Article 6, clause 1, paragraph 1).

SubjectPublicKeyInfo
subjectPublicKeyInfo field must contain "... the public key of the electronic digital signature" (Article 6, clause 1, paragraph 3).

Issuer
The Federal Law "On EDS" assumes the issuance of certificates only to individuals, this provision also applies to certificates of the CAs themselves and certificates of resources. To comply with the formal requirements of the Federal Law, it is proposed to indicate in the attributes of the CA and resource certificates the real information of the organization, considering that such a certificate is issued to an authorized individual of the CA or the Resource and the specified information should be interpreted and registered as a certificate for a pseudonym, which is allowed by the Federal Law "On EDS".
Issuer field must uniquely identify the organization that issued the certificate and contain the officially registered name of the organization.
The following attributes can be used for identification:

countryName	(id-at 6)
stateOrProvinceName	(id-at 8)
localityName	(id-at 7)
organizationName	(id-at 10)
organizationalUnitName	(id-at 11)
postalAddress	(id-at 16)
serialNumber	(id-at 5)

Issuer field must be sure to include attributes describing "the name and location of the certification authority that issued the signature key certificate" (Article 6, clause 1, paragraph 5).

Name must specified in the organizationName attribute. When using the organizationName attribute maybe

CA location maybe be specified using a set of countryName, stateOrProvinceName, localityName attributes (each of which is optional) or using a single postalAddress attribute. By any of the above methods, the location of the CA must be present in the certificate.

must contain the legal address of the certification authority. A space (character "0x20") must be used as a delimiter.

field attribute subject serialNumber must be used in name collisions.

Subject
To represent the DN (Distinguished Name) of the certificate owner may the following attributes are used:

countryName	(id-at 6)
stateOrProvinceName	(id-at 8)
localityName	(id-at 7)
organizationName	(id-at 10)
organizationalUnitName	(id-at 11)
title	(id-at 12)
common name	(id-at 3)
pseudonym	(id-at 65)
serialNumber	(id-at 5)
postalAddress	(id-at 16)

To comply with the formal requirements of the Federal Law, it is proposed to indicate in the attributes of the CA and resource certificates the real information of the organization, considering that such a certificate is issued to an authorized individual of the CA or the Resource and the specified information should be interpreted and registered as a certificate for a pseudonym, which is allowed by the Federal Law "On EDS".

subject field must it is obligatory to contain the following information: "last name, first name and patronymic of the owner of the signature key certificate or pseudonym of the owner" (Article 6, clause 1, paragraph 2).

Surname, name and patronymic of the owner must be contained in the commonName attribute and match those specified in the passport. A space (character "0x20") must be used as a delimiter.

Owner alias must contained in the alias attribute.

The use of one of these attributes precludes the use of the other.

The rest of the attributes are optional.

"If necessary, the signature key certificate, on the basis of supporting documents, indicates the position (with the name and location of the organization in which this position is established) ..." (Article 6, clause 2).

Title of the certificate holder must specified in the title attribute. Attribute value must correspond to the entry in the documents confirming the position established for the certificate holder.

The title attribute, according to RFC 3039, must be included in the subjectDirectoryAttributes extension. However, this document (and RFC 3280) allows it to be included in the subject field.

Required when using the title attribute must include attributes describing the name and location of the organization in which the position is established.

Name of company must specified in the organizationName attribute. Attribute value must coincide with the name of the organization in the founding or other equivalent documents. When using the organizationName attribute maybe the organizationalUnitName attribute is also used.

Location of the organization maybe be specified using a set of countryName, stateOrProvinceName, localityName attributes (each of which is optional) or using a single postalAddress attribute.

The postalAddress attribute, if used, must contain the legal address of the organization or the address of residence of the owner of the signature key certificate (for an individual).

If the organizationName attribute is present, the countryName, stateOrProvinceName, localityName, and postalAddress attributes must be interpreted as the location of the organization.

Optional attributes of the subject field (countryName, stateOrProvinceName, localityName, organizationName, organizationalUnitName, title, postalAddress) may be included, if it is determined by the regulations of the CA, instead of the subject field in the subjectDirectoryAttributes extension (see clause 3.8.1). In this case they should not be included in the subject and can not be used to distinguish between the owners of signing key certificates.

serialNumber attribute must be included in the subject field of the certificate in the event of a name collision. He also maybe be included if it is determined by the regulations of the certification center.

serialNumber attribute maybe:

be arbitrary (assigned by the certification authority itself);
contain an identifier (number) assigned by a state (or other) organization (for example, TIN, passport series and number, identity card number, etc.).

Required Extensions
must include the following extensions:
- KeyUsage (id-ce 15)
- CertificatePolicies (id-ce 32)
1. KeyUsage
  In order for a certificate to be used to verify a digital signature, in the keyUsage extension must the digitalSignature(0) and nonRepuduation(1) bits must be set.
  CertificatePolicies
  The certificatePolicies extension is intended to define the scope of the legally relevant application of a certificate.
  "... the name of the EDS tools with which this public key is used ..." (Article 6, clause 1, paragraph 4), "... information about the relationship in the implementation of which an electronic document with an electronic digital signature will have legal significance ... "(Article 6, clause 1, paragraph 6) and other data regulating the procedure for obtaining and using signature key certificates, can be available at the CPSuri (Certificate Practice Statement URI) specified in this extension.

Optional Extensions
As part of the signing key certificate may include any other extensions. When including extensions in the EDS key certificate, it is necessary to ensure the consistency and unambiguity of the information presented in the certificate.
This document does not specify the use of extensions other than the subjectDirectoryAttributes (id-ce 9) extension.

SubjectDirectoryAttributes
subjectDirectoryAttributes extension maybe contain attributes that supplement the information provided in the subject field.
In addition to the attributes listed in RFC 3039, the following attributes are recommended to be supported in the subjectDirectoryAttributes extension:

qualification	{-}
countryName	(id-at 6)
stateOrProvinceName	(id-at 8)
localityName	(id-at 7)
organizationName	(id-at 10)
organizationalUnitName	(id-at 11)
title	(id-at 12)
postalAddress	(id-at 16)

"If necessary, the signature key certificate, on the basis of supporting documents, indicates ... the qualifications of the owner of the signature key certificate" (Article 6, clause 2).

Data on the qualification of the owner of the EDS key certificate must specified in the qualification attribute. This attribute is not defined in international recommendations (see clause 2) and is subject to registration.

If the countryName, stateOrProvinceName, localityName, organizationName, organizationalUnitName, title, postalAddress attributes are included in the subjectDirectoryAttributes extension, they should not be included in the subject field.

To store other information about the owner of the signature key certificate may use other (already registered or subject to registration) attributes that do not contradict the restrictions imposed by the certificatePolicies extension and other documents regulating the work of the CA.

ASN1 application

id-at: OID value: 2.5.4
OID description: X.500 attribute types.
id-ce: OID value: 2.5.29
OID description: Object Identifier for Version 3 certificate extensions.

2.5.4.5 id-at-serialNumber serialNumber ATTRIBUTE::= ( WITH SYNTAX PrintableString(SIZE (1..64)) EQUALITY MATCHING RULE caseIgnoreMatch SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch ID id-at-serialNumber )

(RFC 3039)
The serialNumber attribute type SHALL, when present, be used to differentiate between names where the subject field would otherwise be identical. This attribute has no defined semantics beyond ensuring uniqueness of subject names. It MAY contain a number or code assigned by the CA or an identifier assigned by a government or civil authority. It is the CA's responsibility to ensure that the serialNumber is sufficient to resolve any subject name collisions.

2.5.4.3 - id-at-commonName

OID value: 2.5.4.3

OID description: The common name attribute type specifies an identifier of an object. A common name is not a directory name; it is a (possibly ambiguous) name by which the object is commonly known in some limited scope (such as an organization) and conforms to the naming conventions of the country or culture with which it is associated.

CommonName ATTRIBUTE::= ( SUBTYPE OF name WITH SYNTAX DirectoryString (ub-common-name) ID (id-at-commonName) )

(RFC 3039 : Qualified Certificate Profile)
OID value: 2.5.4.65

pseudonym ATTRIBUTE::= ( SUBTYPE OF name WITH SYNTAX DirectoryString ID (id-at-pseudonym) )

OID value: 2.5.29.17

OID description: id-ce-subjectAltName This extension contains one or more alternative names, using any of a variety of name forms, for the entity that is bound by the CA to the certified public key.

SubjectAltName EXTENSION::= ( SYNTAX GeneralNames IDENTIFIED BY id-ce-subjectAltName ) GeneralNames::= SEQUENCE SIZE (1..MAX) OF GeneralName GeneralName::= CHOICE ( otherName INSTANCE OF OTHER-NAME, rfc822Name IA5String, dNSName IA5String, ( *) x400Address ORAddress, directoryName Name, ediPartyName EDIPartyName, uniformResourceIdentifier IA5String, IPAddress OCTET STRING, registeredID OBJECT IDENTIFIER ) (*) – arbitrary string. OTHER-NAME::= SEQUENCE ( type-id OBJECT IDENTIFIER value EXPLICIT ANY DEFINED BY type-id )

OID value: 2.5.4.16

OID description: The Postal Address attribute type specifies the address information for the physical delivery of postal messages by the postal authority to the named object. An attribute value for Postal Address will be typically composed of selected attributes from the MHS Unformatted Postal O/R Address version 1 according to CCITT Rec F.401 and limited to 6 lines of 30 characters each, including a Postal Country Name. Normally the information contained in such an address could include an addressee's name, street address, city, state or province, postal code and possibly a Post Office Box number depending on the specific requirements of the named object.

PostalAddress ATTRIBUTE::= ( WITH SYNTAX PostalAddress EQUALITY MATCHING RULE caseIgnoreListMatch SUBSTRINGS MATCHING RULE caseIgnoreListSubstringsMatch ID id-at-postalAddress ) PostalAddress::= SEQUENCE SIZE (1..ub-postal-address) OF DirectoryString (ub-postal-string)

OID value: 2.5.4.12

OID description: The Title attribute type specifies the designated position or function of the object within an organization. An attribute value for Title is string.

Title ATTRIBUTE::= ( SUBTYPE OF name WITH SYNTAX DirectoryString (ub-title) ID id-at-title ) id-ce-certificatePolicies OBJECT IDENTIFIER::= ( id-ce 32 ) certificatePolicies::= SEQUENCE SIZE (1.. MAX) OF PolicyInformation PolicyInformation::= SEQUENCE ( policyIdentifier CertPolicyId, policyQualifiers SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo OPTIONAL ) CertPolicyId::= OBJECT IDENTIFIER PolicyQualifierInfo::= SEQUENCE ( policyQualifierId PolicyQualifierId, qualifier ANY DEFINED BY policyQualifierId ) -- policyQualifiers for Internet policy qualifiers id-qt OBJECT IDENTIFIER::= ( id-pkix 2 ) id-qt-cps OBJECT IDENTIFIER::= ( id-qt 1 ) id-qt-unotice OBJECT IDENTIFIER::= ( id-qt 2 ) PolicyQualifierId::= OBJECT IDENTIFIER (id-qt-cps | id-qt-unotice) Qualifier::= CHOICE ( cPSuri CPSuri, userNotice UserNotice ) CPSuri::= IA5String UserNotice::= SEQUENCE ( noticeRef NoticeReference OPTIONAL, explicitText DisplayText OPTIONAL) NoticeReference::= SEQUENCE ( organi zation DisplayText, noticeNumbers SEQUENCE OF INTEGER ) DisplayText::= CHOICE ( visibleString VisibleString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)), utf8String UTF8String (SIZE (1..200)) )

Vadim Malykh
02.10.2013

Some time ago, in the Forum Rus group on Facebook, there was a discussion on the use of information systems ah authorities (the discussion was off topic, you can see it in the comments below). The essence of the dispute is that due to OIDs (object identifier - object identifier) of information systems that must be registered in qualified electronic signature certificates (ES) of officials, these same ES have to be changed even more often than once a year (which is dictated by security requirements) , and this, in turn, leads to additional complexities and costs, since most authorities work with commercial CAs without having their own.The problem is exacerbated by the lack of a common understanding of what exactly these OIDs provide and how necessary and / or mandatory they are.

During the course of the argument, my opponent warned me that due to ignorance of some of the fundamentals of the subject area, I could get into certain legal problems in the future. I could not ignore such a warning from a colleague, so I decided to carefully study this topic again and make sure that I understand everything and do it right. Below are some of the results of this excursion into subject area. Perhaps someone will be interested.

Starting with basic concepts, electronic signing is based on asymmetric encryption algorithms. The main feature of these algorithms is that two different keys are used to encrypt and decrypt a message. The general public is more familiar with symmetric algorithms, when we encrypt and decrypt a message with the same key (or password), for example, we archive a file with a password or protect a MS Word document.

Many things are based on asymmetric encryption algorithms, although the mere fact that different keys are used for encryption and decryption would not yet allow for any useful application of these algorithms. To do this, they must have some additional properties. First, the keys must not be computable, that is, if you know one key, you cannot calculate the second one. It is also very important that different encryption keys correspond to different decryption keys and vice versa - only one encryption key corresponds to one decryption key.

What is the actual signature? After all, we need to sign the document, not encrypt it. First you need to understand what a signature is and why it is needed. When you put your handwritten signature on a paper document, you thereby assure that it was you (and not someone else) who saw (and agrees to) this particular document (and not some other). The most important property signatures - non-repudiation. This means that once you sign the document, you cannot waive that fact later. In the case of a paper signature, handwriting expertise will convict you, in the case of an electronic one, mathematical methods based on asymmetric encryption algorithms.

How it all works, in a nutshell. We take an asymmetric encryption algorithm, generate a key pair (for encryption and decryption). We give the encryption key to the person who will sign the documents. He must always keep it with him and not give it to anyone. Therefore, it is called the "private" key. We give another key (decryption) to everyone, so it is “open”. When signing a document, a person must encrypt it with their private key. It is not the document itself that is actually encrypted, since it can be quite large, and we don't actually need to encrypt it. Therefore, a hash is obtained for the document - this is a certain numerical sequence with a high degree of probability different for different documents, like a "fingerprint" of the document. It is encrypted with the signer's private key. This encrypted hash is electronic signature document. Now, having a document, a signature, and a public key, anyone can easily verify that this particular document was signed with this particular private key. To do this, we again get the hash of the document, decrypt the signature with the public key and compare. Should get two identical numeric sequences.

All this is great, but so far we have obtained non-repudiation of the signature for the private key, that is, we have proved that the document is signed by a specific key. We need to prove that it was signed by a specific person. To do this, there are certification centers and digital certificates. The most important thing that a certification authority does is that it certifies that the private key belongs to a specific person. To guarantee this, it is the certification center that generates key pairs and issues them personally to the owners (there are options by proxy, remotely, but these are details). Together with the keys, a digital certificate is generated - this is an electronic document (sometimes its paper representation), which contains information about the owner of the key, the key itself, the certification authority and some other information. The owner, as a rule, receives all this goodness on a secure medium (smart card, ru-token, and so on), which contains a private key and a certificate with an embedded public key. The carrier itself must always be kept with you, and the public key certificate copied from it can be given to everyone so that they can verify your electronic signature.

So, signing is done with a private key, and signature verification with a public key. Therefore, the phrase "the document is signed by the set of OIDs" (sounded in the above dispute) is meaningless. Only two keys are involved in the signing and verification procedure, in 63-FZ they are named accordingly - the signature key and the signature verification key.

And what are these notorious OIDs? The X.509 digital certificate format allows extensions to be stored in it. These are some optional attributes that can be used to store additional information. Each such attribute is an object that is specified by an identifier from the hierarchical directory. Hence OID - Object Identifier. It makes no sense to delve into the nature of the OIDs themselves. In fact, this is some additional information that may be present in the certificate.

These additional attributes can be used for various purposes. They can either provide additional information about the owner, keys, CA, or carry some additional information for applications and services that use this certificate. The most common use is for role-based access control. For example, it can be stated in the certificate that the owner of the key is the head of the organization, and this will give him the opportunity to immediately access the necessary functions and information in all ISs, without having to contact the administrators of each IS and change access settings. All this, of course, provided that all these ISs use the user's certificate for authorization and analyze the same attribute in the same way (for this reason, the attributes are selected from the directory, and not set arbitrarily).

Due to different applications, we receive two certificates that are completely different in nature. One - certifies that I am I, and this is always the case. For good, it could be issued one or more times in a lifetime, like a passport. However, due to the imperfection of existing cryptographic algorithms, for security purposes, these certificates now need to be reissued every year. The second kind of certificate manages additional information and can change much more often than even once a year. It can be compared with calling card. position changed, Email, phone - you need to make new business cards.

In the world, these two types of certificates are called respectively Public Key Certificate (PKC) and Attribute Certificate (or Authorization Certificate - AC). A certificate of the second kind can be issued much more often than the first, by another organization, and should be more accessible and easier to obtain than a personal "public key" certificate. In any case, this is what RFC 3281 recommends, dedicated to this type of certificate. The certificate of the second kind should contain only a link to the public key certificate so that the system using it to authorize the user can first identify the person using PKC.

Now let's move closer to our reality. At the legislative level, issues related to the use of electronic signatures in Russian Federation, are regulated by two main documents - the Law of the Russian Federation of 04/06/2011 No. 63-FZ "On Electronic Signature" and the Order of the Federal Security Service of the Russian Federation of 12/27/2011 No. 795 "On Approval of the Requirements for the Form of a Qualified Certificate of the Electronic Signature Verification Key". The composition of a qualified certificate is described in the 795th order (Part II "Requirements for the set of fields of a qualified certificate") and it does not contain requirements for attributes that control authorization in any information systems. As additional mandatory attributes, only information is indicated that allows you to identify an individual or legal entity in the Russian Federation (TIN, SNILS, etc.). Although neither the law nor the order of the FSB prohibit the inclusion of other information in a qualified certificate.

As you can see, no legislative norms dictate the mandatory presence in a qualified certificate of attributes related to authorization in any information systems. Where do these requirements come from? And they come from developers (or "owners") specific systems. Let's take for example "Guidelines for the use of an electronic signature in interdepartmental electronic interaction (version 4.3)", posted on the SMEV technology portal. Indeed, in paragraph 6 of this document we read: “When preparing information for the formation of an EP-SP certificate, it is necessary to determine the need to request information from the Rosreestr (extract from the USRR). If such a request is necessary, the OID must be indicated in the “Improved key” field (OID=2.5.29.37) in the ES-SP certificate according to the requirements of Rosreestr.”. That is, the Rosreestr information system uses this attribute to determine the information that can be issued to the certificate owner. However, the same document contains an important note, namely, this requirement is valid until the full launch of the ESIA (single authorization service in state systems) and the connection of the Rosreestr system to it. This is an important note, keep it in mind.

I will not deal with other IPs used in the state. organs. I suspect the situation is similar. The public procurement portal, electronic trading platforms, various accounting and financial applications may also require the presence of certain additional OIDs in the user certificate. At the same time, the statement that by writing the OID of the information system in the certificate, I somehow delegate responsibility to the certification center, to put it mildly, is incorrect. The CA enters this data into the certificate according to my application. If my position has changed, and I forgot to apply for the revocation of the old one and the issuance of a new certificate, the CA cannot be held responsible for my forgetfulness. In addition, the law 63-FZ directly assigns responsibility for the incorrect use of the certificate to its owner. In paragraph 6 of article 17 we read:
The holder of a qualified certificate must:
1) do not use the electronic signature key and immediately contact the accredited certification center that issued the qualified certificate to terminate this certificate if there is reason to believe that the confidentiality of the electronic signature key has been violated;
2) use a qualified electronic signature in accordance with the restrictions contained in the qualified certificate (if such restrictions are established).

The need to store in the certificate information about the user's roles and accesses in specific information systems leads to a problem that caused a dispute on Facebook, namely, the certificate has to be reissued much more often than the security requirements for a personal electronic signature dictate. The position has changed - we reissue the certificate. A new IS has appeared - we reissue the certificate. There was a need to request information from the IS of a new organization (Rosreestr) - we reissue the certificate.

There is a 100% hit in the concept called in the world Attribute Certificate (or Authorization Certificate), which was mentioned above and in which it is recommended to issue these certificates by another certification authority (Attribute Autority, in contrast to the Certificate Authority - a regular CA that issues qualified ES certificates) and in a simplified way. This certificate itself should not contain the electronic signature key and information about the owner. Instead, it contains a link to the owner's public key certificate, from which you can get the rest of the necessary information about the person.

It should be noted that this scheme also has a very limited application and does not solve all problems. What if the next information system decides to use the same certificate field “Improved key” (OID=2.5.29.37), which is already occupied by the Rosreestr value, for its needs? Entering two different values in one field will not work. Therefore, we will have to release another AC! Another problem is related to the short lifetime of PKC (one year). If we have several ACs (which contain a link to a personal certificate), they will all have to be reissued after the PKC expires. For the effective use of AC, a single user authorization center is required in all information systems, and all applications must use certificate attributes in a consistent and uniform way.

Such a single authorization center for the state. authorities already exist - this is the ESIA. Recall the note regarding Rosreestr's OIDs. In the future, they will be replaced by information from the ESIA. Other information systems in which civil servants work should also do the same. Instead of using AC for authorization, it is necessary to integrate with the ESIA and receive the necessary information from there ESIA should be able to bind a qualified ES certificate to an account, so information systems will be able to authenticate the user using a personal key, and authorize him (providing access to the application) through the ESIA.Such a system seems to be more universal and reliable than the use of certificate fields, and in the future, it will automate access management.If a unified system of personnel records of civil servants is created, the ESIA will be able to take information about the powers of a person directly from there.A person transferred to another position - automatically lost access to one system and gained another. about he continues to use his ES key to sign documents, nothing needs to be reissued.

In accordance with the Technical Conditions for CJSC AEI PRIME to Disclose Information on Securities and Other Financial Instruments approved by the Bank of Russia (), electronic documents containing public information must be signed by the subject of information disclosure with an enhanced qualified electronic signature (see clause 1.7 of the Technical Conditions). This requirement is effective from February 1, 2017.

Currently, a test period for the application of an electronic signature has begun on the PRIME disclosure server, which will last until January 31, 2017 inclusive.

To test the functionality, PRIME customers can use any ES key certificate previously received for this legal entity.

From February 1, 2017, at the request of the Technical Conditions (see clauses 1.7. and 9.6.), the qualified certificate of the user’s electronic signature verification key must comply with the requirements for the form of a qualified certificate established by Order of the Federal Security Service of Russia dated December 27, 2011 No. 795 “On Approval Requirements for the Form of a Qualified Certificate of the Electronic Signature Verification Key. Enhanced Key User Certificate Extension ( object identifier 2.5.29.37) must contain the disclosure object identifier PRIME - OID 1.2.643.6.42.5.5.5

Login to the personal account of the user of information disclosure "PRIME" will be carried out using the LOGIN and PASSWORD previously received by the client.

The client's actions to publish messages in the Information Disclosure Feed, post documents on a page on the Internet, make changes to the issuer's registration card in the information disclosure system must be confirmed by an electronic signature.

To use the ES on the PRIME information disclosure server, the client must first install the plug-in (installation is free for users and does not take much time). See the plugin installation instructions below.

In the personal account of the information disclosure user, after the client installs the plug-in, when filling out forms for publishing a message in the information disclosure feed or placing a document on the Internet, as well as when changing the registration card data, additional fields “Document electronic signature” will appear, where it will be necessary to select the one displayed in the corresponding service field signing key certificate and click the "Sign" button. In this way, the client will confirm his actions to disclose information or make changes to his registration card.

After signing the message with an electronic signature, the client must click the "Publish" button
After signing the document with an electronic signature, the client must click the "Add Document" button.
After signing the changes in the registration card with an electronic signature, the client must click the "Send identification form" button.

Please note that all messages sent by clients through their personal account through the "Test login (work with ES)" authorization will be published in the Information Disclosure Feed in working mode. All documents placed by clients through their personal account through the "Test entry (work with ES)" authorization will be automatically posted on the pages of issuers in working mode.

Otherwise, the procedure for the issuer's actions in the personal account on the PRIME information disclosure server does not change.