Квалифициран електронен подпис – проблеми на OID на информационните системи. Лош подпис Неуспешна проверка на подписа Липсващ идентификатор на обект OID Декриптиране на Oid

Когато влезете в личния си акаунт, за да поискате QEP, се показва съобщение « Компютърът не е конфигуриран . За да продължите, отидете на страницата с настройки на компютъра и следвайте предложените стъпки » . След като отидете на страницата с настройки и инсталирате всички необходими компоненти лична сметкаотново се появява съобщението, че компютърът не е конфигуриран.

За да коригирате грешката, трябва:

1. Добавете адреса на вашия личен акаунт https://i.kontur-ca.ru към надеждните сайтове. За това:

Изберете менюто "Старт" > "Контролен панел" > "Опции за интернет";
Отидете в раздела „Сигурност“, изберете елемента „Надеждни сайтове“ (или „Надеждни сайтове“) и кликнете върху бутона „Възли“;
Посочете следния адрес на възел https://i.kontur-ca.ru в полето Добавяне към зона и щракнете върху бутона Добавяне.

Ако този адрес вече е в списъка с надеждни сайтове, преминете към следващата стъпка.

2. Проверете дали адресът на личния акаунт https://i.kontur-ca.ru е определен като надежден:

Ако се използва Internet Explorer версия 8, след като сте на страницата за оторизация, трябва да проверите дали квадратчето за отметка Trusted Sites е в долната част на страницата. Ако няма отметка, но има надпис « Интернет”, тогава адресът https://i.kontur-ca.ru не е добавен към надеждни сайтове.

Ако се използва Internet Explorer версия 9 и по-нова, тогава, когато сте на страницата за оторизация, трябва да щракнете с десния бутон навсякъде на страницата, изберете „Свойства“. В прозореца, който се отваря, редът "Зона" трябва да съдържа надписа "Надежден сайт". В противен случай адресът https://i.kontur-ca.ru не е добавен към надеждни сайтове.

Ако адресът на личния акаунт не е определен като надежден, тогава трябва да се свържете със системния администратор с молба за добавяне на адреса https://i.kontur-ca.ru към надеждните сайтове.

3. Проверете дали можете да влезете в личния си акаунт. Ако грешката се повтаря, тогава трябва да стартирате помощната програма RegOids от връзката. Тази помощна програма автоматично ще конфигурира настройките на OID в системния регистър на компютъра. Можете също така ръчно да импортирате един от клоновете на системния регистър, в зависимост от битовостта на инсталираната операционна система:

4. Проверете дали компютърът използва администраторски права (за да проверите, отидете на Старт - Контролен панел - Потребителски акаунти и семейна безопасност - Потребителски акаунти). Ако правата не са достатъчни, трябва да дадете на потребителя пълни права, за това се свържете с вашия администратор.

5. След като завършите стъпка 3, е необходимо да рестартирате компютъра и да проверите входа на личния акаунт.

Ако никоя от инструкциите не помогна, тогава трябва да се свържете техническа поддръжкапо адреса [имейл защитен]Писмото трябва да посочи:

1. Номер на диагнозата.

За да направите това, трябва да отидете на диагностичния портал наhttps://help.kontur.ru , Натисни бутона "Стартиране на диагностика » . След като процесът на проверка приключи, диагностичният номер ще се покаже на екрана. Посочете присвоения референтен номер в писмото.

2. Екранна снимка на прозореца с грешката (когато използвате Internet Explorer версия 9 и по-висока, трябва да прикачите и екранна снимка на прозореца "Properties" - вижте точка 2).

3. Експортирайте и прикачете следните клонове на регистъра:

32-битова: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo
64-битов: HKLM\SOFTWARE\Wow6432Node\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo

Общи положения.
Изборът на метод за представяне на определени данни и допълнителни ограничения върху състава на полетата на сертификата се основава на следните принципи:
Международни препоръки. Този документ е разработен, като се вземат предвид международните препоръки:
- RFC 3280 (актуализиране на RFC 2459) Интернет X.509 публична ключова инфраструктура. Сертификат и профил на списъка с анулирани сертификати (CRL).
- RFC 3039 Интернет X.509 публична ключова инфраструктура. Профил на квалифициран сертификат – това RFC предлага Общи изискваниякъм синтаксиса (композицията) на сертификати, чието използване е правно значимо.

Състав и предназначение на полетата на сертификата.

Този раздел предоставя описание на основните полета на сертификат за публичен ключ, който е в съответствие със Закона за електронния цифров подпис от 10.01.2002 г.

Концепциите, обозначенията и терминологията, използвани в този раздел, се основават на RFC 3280 и RFC 3039, които от своя страна са базирани на ITU-T X.509 Препоръка версия 3. Съдържанието на раздела не копира съдържанието на тези документи , а само посочва разликите и характеристиките на използването на сертификати за полета, които изпълняват изискванията за състава на EDS сертификата, посочени в член 6 от Закона за EDS.

За всички полета на сертификат, които изискват низови стойности на руски език, за предпочитане е да използвате универсалното UTF-8 кодиране (тип UTF8String).

Целта на този раздел е да дефинира състава и предназначението на полетата на сертификата, без да се вземат предвид изискванията на конкретен сертифициращ орган. Документите, уреждащи работата на сертифициращ орган, могат да ограничат състава на полетата на сертификата и набора от атрибути, използвани за идентифициране на CA и притежателите на сертификати ключове за подпис.

версия
Всички издадени сертификати трябва даимат версия 3.

Сериен номер
Поле SerialNumber трябва дасъдържат „... уникален регистрационен номер на сертификата за ключ за подпис“ (чл. 6, т. 1, ал. 1). Уникалността на номера на сертификата трябва да се спазва в рамките на даден сертифициращ орган (CA).

Валидност
Поле за валидност трябва дасъдържат "... датите на началото и изтичането на срока на валидност на сертификата за ключ за подпис, намиращ се в регистъра на удостоверителния център" (чл. 6, клауза 1, алинея 1).

SubjectPublicKeyInfo
поле subjectPublicKeyInfo трябва дасъдържат „...публичния ключ на електронния цифров подпис“ (чл. 6, т. 1, ал. 3).

Издател
Федералният закон „За EDS“ предполага издаването на сертификати само на физически лица, тази разпоредба се прилага и за сертификати на самите УО и сертификати за ресурси. За да се спазят формалните изисквания на Федералния закон, се предлага да се посочи в атрибутите на CA и ресурсните сертификати истинската информация за организацията, като се има предвид, че такъв сертификат се издава на упълномощено лице от CA или ресурса и посочената информация трябва да се тълкува и регистрира като удостоверение за псевдоним, което е разрешено от Федералния закон „За EDS“.
Поле Издател трябва дауникално идентифицират организацията, издала сертификата, и съдържат официално регистрираното име на организацията.
Следните атрибути могат да се използват за идентификация:

име на държава	(ид-на 6)
stateOrProvinceName	(ид-на 8)
име на местност	(ид-на 7)
Наименование на организацията	(ид-на 10)
име на организационна единица	(ид-на 11)
пощенски адрес	(ид-на 16)
сериен номер	(ид-на 5)

Поле Издател трябва дане забравяйте да включите атрибути, описващи „името и местоположението на сертифициращия орган, издал сертификата за ключ за подпис“ (член 6, клауза 1, параграф 5).

Име трябва дапосочени в атрибута organizationName. Когато използвате атрибута organizationName може би

CA местоположение може бида бъдат посочени с помощта на набор от атрибути countryName, stateOrProvinceName, localityName (всеки от които е незадължителен) или с помощта на единичен атрибут postalAddress. По някой от горните методи, местоположението на CA трябва да присъствав сертификата.

трябва дасъдържа юридическия адрес на сертифициращия орган. Интервал (знак "0x20") трябва да се използва като разделител.

поле атрибут предмет сериен номер трябва дада се използва при сблъсъци на имена.

Предмет
За представяне на DN (отличително име) на собственика на сертификата можесе използват следните атрибути:

име на държава	(ид-на 6)
stateOrProvinceName	(ид-на 8)
име на местност	(ид-на 7)
Наименование на организацията	(ид-на 10)
име на организационна единица	(ид-на 11)
заглавие	(ид-на 12)
често срещано име	(id-на 3)
псевдоним	(ид-на 65)
сериен номер	(ид-на 5)
пощенски адрес	(ид-на 16)

За да се спазят формалните изисквания на Федералния закон, се предлага да се посочи в атрибутите на CA и ресурсните сертификати истинската информация за организацията, като се има предвид, че такъв сертификат се издава на упълномощено лице от CA или ресурса и посочената информация трябва да се тълкува и регистрира като удостоверение за псевдоним, което е разрешено от Федералния закон „За EDS“.

предметно поле трябва дазадължително трябва да съдържа следната информация: „фамилия, собствено име и бащино име на притежателя на сертификата за ключ за подпис или псевдоним на притежателя“ (чл. 6, т. 1, ал. 2).

Фамилия, име и бащино име на собственика трябва дасе съдържат в атрибута commonName и съвпадат с посочените в паспорта. Интервал (знак "0x20") трябва да се използва като разделител.

Псевдоним на собственика трябва дасъдържащ се в атрибута на псевдонима.

Използването на един от тези атрибути изключва използването на другия.

Останалите атрибути не са задължителни.

„Ако е необходимо, сертификатът за ключ за подпис, въз основа на подкрепящи документи, посочва длъжността (с името и местоположението на организацията, в която е установена тази длъжност) ...“ (член 6, клауза 2).

Заглавие на притежателя на сертификата трябва дапосочени в атрибута заглавие. Стойност на атрибута трябва дасъответстват на записа в документите, потвърждаващи длъжността, установена за притежателя на сертификата.

Атрибутът заглавие, съгласно RFC 3039, трябва дада бъдат включени в разширението subjectDirectoryAttributes. Въпреки това, този документ (и RFC 3280) позволява да бъде включен в полето за тема.

Задължително при използване на атрибута title трябва давключват атрибути, описващи името и местоположението на организацията, в която е установена длъжността.

Име на компания трябва дапосочени в атрибута organizationName. Стойност на атрибута трябва дасъвпадат с наименованието на организацията в учредителните или други еквивалентни документи. Когато използвате атрибута organizationName може биизползва се и атрибута organizationalUnitName.

Местоположение на организацията може бида бъдат посочени с помощта на набор от атрибути countryName, stateOrProvinceName, localityName (всеки от които е незадължителен) или с помощта на единичен атрибут postalAddress.

Атрибутът postalAddress, ако се използва, трябва дасъдържа юридическия адрес на организацията или адреса на пребиваване на собственика на сертификата за ключ за подпис (за физическо лице).

Ако присъства атрибута organizationName, атрибутите countryName, stateOrProvinceName, localityName и postalAddress трябва дада се тълкува като местоположението на организацията.

Незадължителни атрибути на полето за тема (countryName, stateOrProvinceName, localityName, organizationName, organizationalUnitName, title, postalAddress) можебъде включено, ако е определено от разпоредбите на CA, вместо полето за предмет в разширението subjectDirectoryAttributes (вижте клауза 3.8.1). В този случай те не трябвада бъдат включени в предмета и не могасе използва за разграничаване между собствениците на подписващи сертификати за ключове.

атрибут serialNumber трябва дада бъде включено в полето за тема на сертификата в случай на конфликт на имена. Той също може бисе включва, ако това е определено от правилника на удостоверителния център.

атрибут serialNumber може би:

да бъдат произволни (възложени от самия сертифициращ орган);
съдържат идентификатор (номер), определен от държавна (или друга) организация (например TIN, серия и номер на паспорт, номер на лична карта и др.).

Необходими разширения
трябва давключват следните разширения:
- KeyUsage (id-ce 15)
- CertificatePolicies (id-ce 32)
1. KeyUsage
  За да може сертификат да се използва за проверка на цифров подпис, в разширението keyUsage трябва датрябва да бъдат зададени битовете digitalSignature(0) и nonRepuduation(1).
  CertificatePolicies
  Разширението certificatePolicies е предназначено да дефинира обхвата на правно приложимото приложение на сертификат.
  „... името на EDS инструментите, с които се използва този публичен ключ ...“ (чл. 6, клауза 1, алинея 4), „... информация за връзката, при изпълнението на която електронен документ с електронен цифров подписще има правно значение ... "(член 6, клауза 1, параграф 6) и други данни, регулиращи процедурата за получаване и използване на сертификати за ключове за подпис, може да бъденаличен в CPSuri (Certificate Practice Statement URI), посочен в това разширение.

Опционални разширения
Като част от сертификата за ключ за подписване можевключват всякакви други разширения. При включването на разширения в сертификата за ключ на EDS е необходимо да се осигури последователност и недвусмисленост на информацията, представена в сертификата.
Този документ не уточнява използването на разширения, различни от разширението subjectDirectoryAttributes (id-ce 9).

SubjectDirectoryAttributes
разширение subjectDirectoryAttributes може бисъдържат атрибути, които допълват информацията, предоставена в полето за тема.
В допълнение към атрибутите, изброени в RFC 3039, се препоръчва следните атрибути да се поддържат в разширението subjectDirectoryAttributes:

квалификация	{-}
име на държава	(ид-на 6)
stateOrProvinceName	(ид-на 8)
име на местност	(ид-на 7)
Наименование на организацията	(ид-на 10)
име на организационна единица	(ид-на 11)
заглавие	(ид-на 12)
пощенски адрес	(ид-на 16)

„Ако е необходимо, сертификатът за ключ за подпис, въз основа на подкрепящи документи, посочва ... квалификацията на собственика на сертификата за ключ за подпис“ (чл. 6, клауза 2).

Данни за квалификацията на собственика на сертификата за ключ EDS трябва дапосочени в квалификационния атрибут. Този атрибут не е дефиниран в международни препоръки (вижте точка 2) и подлежи на регистрация.

Ако атрибутите countryName, stateOrProvinceName, localityName, organizationName, organizationalUnitName, title, postalAddress са включени в разширението subjectDirectoryAttributes, те не трябвада бъдат включени в тематичното поле.

За съхраняване на друга информация за собственика на сертификата за ключ за подпис можеизползвайте други (вече регистрирани или подлежащи на регистрация) атрибути, които не противоречат на ограниченията, наложени от разширението на сертификатаPolicies и други документи, регулиращи работата на УО.

Приложение ASN1

id-at: OID стойност: 2.5.4
OID описание: X.500 типове атрибути.
id-ce: OID стойност: 2.5.29
OID описание:Идентификатор на обект за разширения на сертификат версия 3.

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)
Типът атрибут serialNumber, когато присъства, ТРЯБВА да се използва за разграничаване между имена, където полето за тема иначе би било идентично. Този атрибут няма дефинирана семантика, освен да гарантира уникалността на имената на субектите. МОЖЕ да съдържа номер или код, присвоен от CA, или идентификатор, присвоен от правителство или граждански орган. Отговорност на CA е да гарантира, че serialNumber е достатъчен за разрешаване на всякакви сблъсъци с имена на обекти.

2.5.4.3 - id-at-commonName

OID стойност: 2.5.4.3

OID описание:Типът атрибут на общото име указва идентификатор на обект. Общото име не е име на директория; това е (възможно двусмислено) име, с което обектът е общоизвестен в някакъв ограничен обхват (като организация) и съответства на конвенциите за именуване на страната или културата, с която е свързан.

CommonName ATTRIBUTE::= ( ПОДТИП НА име СЪС СИНТАКСИС DirectoryString (ub-common-name) ID (id-at-commonName) )

(RFC 3039: Профил на квалифициран сертификат)
OID стойност: 2.5.4.65

псевдоним АТРИБУТ::= ( ПОДТИП НА име СЪС СИНТАКСИС DirectoryString ID (id-at-pseudonym) )

OID стойност: 2.5.29.17

OID описание: id-ce-subjectAltName Това разширение съдържа едно или повече алтернативни имена, като се използва някоя от различните форми на имена за обекта, който е обвързан от CA със сертифицирания публичен ключ.

SubjectAltName РАЗШИРЕНИЕ::= ( СИНТАКСИС GeneralNames ИДЕНТИФИЦИРАН ОТ id-ce-subjectAltName ) GeneralNames::= РАЗМЕР НА ПОСЛЕДОВАТЕЛНОСТ (1..МАКС.) ОТ GeneralName GeneralName::= ИЗБОР ( otherName ЕКЗЕМПЛЯР НА OTHER-NAME, rfc822Name IA5String, dNSName IA5String, ( *) x400Address ORAddress, directoryName Name, ediPartyName EDIPartyName, uniformResourceIdentifier IA5String, IPAddress OCTET STRING, registeredID OBJECT IDENTIFIER ) (*) – произволен низ. OTHER-NAME::= SEQUENCE ( type-id OBJECT IDENTIFIER value EXPLICIT ANY DEFINED BY type-id )

OID стойност: 2.5.4.16

OID описание:Типът атрибут "Пощенски адрес" указва адресната информация за физическата доставка на пощенски съобщения от пощенския орган до посочения обект. Стойността на атрибут за пощенски адрес обикновено ще бъде съставена от избрани атрибути от версия 1 на неформатиран пощенски O/R адрес на MHS съгласно CCITT Rec F.401 и ограничена до 6 реда от по 30 знака всеки, включително име на пощенска държава. Обикновено информацията, съдържаща се в такъв адрес, може да включва името на получателя, улица, град, щат или провинция, пощенски код и евентуално номер на пощенска кутия в зависимост от специфичните изисквания на посочения обект.

PostalAddress АТРИБУТ::= ( СЪС СИНТАКСИС PostalAddress EQUALITY ПРАВИЛО ЗА СЪОТВЕТСТВИЕ caseIgnoreListMatch SUBSTRINGS ПРАВИЛО ЗА СЪОТВЕТСТВИЕ caseIgnoreListSubstringsMatch ID id-at-postalAddress ) PostalAddress::= РАЗМЕР НА ПОСЛЕДОВАТЕЛНОСТТА (1..ub-postal-address) OF DirectoryString (ub-postal)

OID стойност: 2.5.4.12

OID описание:Типът атрибут Title указва определената позиция или функция на обекта в организацията. Стойността на атрибут за Title е низ.

Заглавие АТРИБУТ::= ( ПОДТИП НА име СЪС СИНТАКСИС DirectoryString (ub-title) ID id-at-title ) id-ce-certificatePolicies ОБЕКТЕН ИДЕНТИФИКАТОР::= ( id-ce 32 ) certificatePolicies::= РАЗМЕР НА ПОСЛЕДОВАТЕЛНОСТ (1.. Max) на политиката на политиката Политика Информация :: = Последователност (Политически идентификатор CertPolicyId, Политически квалификации Размер на последователността (1..MAX) на PolicyQualifierInfo Незадължително) CERTPOLICYID :: = Обект идентификатор PolicyQualifierInfo :: = Последователност (PolicyqualifierId PolicyQualifierId, квалификатор, определен от политически квалификатор) - за квалификатори на интернет политика id-qt ИДЕНТИФИКАТОР НА ОБЕКТ::= ( id-pkix 2 ) id-qt-cps ИДЕНТИФИКАТОР НА ОБЕКТ::= ( id-qt 1 ) id-qt-unotice ИДЕНТИФИКАТОР НА ОБЕКТ::= ( id-qt 2 ) PolicyQualifierId::= ИДЕНТИФИКАТОР НА ОБЕКТ (id-qt-cps | id-qt-unotice) Квалификатор::= ИЗБОР ( cPSuri CPSuri, userNotice UserNotice ) CPSuri::= IA5String UserNotice::= ПОСЛЕДОВАТЕЛНОСТ ( noticeRef NoticeReference ИЗБОР, explicitText DisplayText ИЗБОР) 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)) )

Вадим Малих
02.10.2013

Преди време в групата на Форум Рус във Фейсбук имаше дискусия относно използването на информационни системиах авторитети (дискусията не беше по темата, можете да я видите в коментарите по-долу). Същността на спора е, че поради OID (идентификатор на обект - идентификатор на обект) на информационни системи, които трябва да бъдат регистрирани в удостоверения за квалифициран електронен подпис (УЕ) на длъжностни лица, същите тези УИ трябва да се сменят дори по-често от веднъж на ден. година (което е продиктувано от изискванията за сигурност) , а това от своя страна води до допълнителни сложности и разходи, тъй като повечето органи работят с търговски УО, без да имат свои собствени. Проблемът се изостря от липсата на общо разбиране за това какви точно са тези OID предоставят и колко са необходими и/или задължителни.

По време на спора моят опонент ме предупреди, че поради непознаване на някои от основите на предметната област, мога да попадна в определени правни проблеми в бъдеще. Не можех да пренебрегна такова предупреждение от колега, затова реших отново да проуча внимателно тази тема и да се уверя, че разбирам всичко и го правя правилно. По-долу са някои от резултатите от тази екскурзия в предметна област. Може би някой ще се заинтересува.

Започвайки с основните концепции, електронното подписване се основава на асиметрични алгоритми за криптиране. Основната характеристика на тези алгоритми е, че се използват два различни ключа за криптиране и декриптиране на съобщение. Широката публика е по-запозната със симетричните алгоритми, когато криптираме и дешифрираме съобщение с един и същ ключ (или парола), например архивираме файл с парола или защитаваме документ на MS Word.

Много неща се основават на асиметрични алгоритми за криптиране, въпреки че самият факт, че се използват различни ключове за криптиране и декриптиране, все още не би позволил никакво полезно приложение на тези алгоритми. За да направят това, те трябва да имат някои допълнителни свойства. Първо, ключовете не трябва да бъдат изчислими, т.е. ако знаете един ключ, не можете да изчислите втория. Също така е много важно различните ключове за криптиране да съответстват на различни ключове за декриптиране и обратното – само един ключ за криптиране да съответства на един ключ за декриптиране.

Какъв е действителният подпис? В крайна сметка трябва да подпишем документа, а не да го шифроваме. Първо трябва да разберете какво е подпис и защо е необходим. Когато поставите своя собственоръчен подпис върху хартиен документ, вие по този начин гарантирате, че вие (а не някой друг) сте видели (и сте съгласни) този конкретен документ (а не някой друг). Най-важното свойствоподписи - неотказ. Това означава, че след като подпишете документа, не можете да се откажете от този факт по-късно. При хартиен подпис ще ви осъди почерковата експертиза, при електронен – математически методи, базирани на асиметрични алгоритми за криптиране.

Как работи всичко, накратко. Взимаме асиметричен алгоритъм за криптиране, генерираме двойка ключове (за криптиране и декриптиране). Даваме ключа за криптиране на лицето, което ще подпише документите. Винаги трябва да го държи при себе си и да не го дава на никого. Следователно той се нарича "частен" ключ. Ние даваме друг ключ (дешифриране) на всеки, така че той е „отворен“. Когато подписва документ, човек трябва да го криптира със своя частен ключ. Самият документ всъщност не е шифрован, тъй като може да бъде доста голям и всъщност не е необходимо да го шифроваме. Следователно за документа се получава хеш - това е определена числова последователност с висока степен на вероятност, различна за различните документи, като "пръстов отпечатък" на документа. Той е криптиран с личния ключ на подписващия. Този шифрован хеш е електронен подписдокумент. Сега, разполагайки с документ, подпис и публичен ключ, всеки може лесно да провери дали този конкретен документ е подписан с този конкретен частен ключ. За да направим това, отново получаваме хеша на документа, дешифрираме подписа с публичния ключ и сравняваме. Трябва да се получат две еднакви числови поредици.

Всичко това е чудесно, но до момента сме получили неопровержение на подписа за частния ключ, тоест доказали сме, че документът е подписан с определен ключ. Трябва да докажем, че е подписано от конкретно лице. За да направите това, има центрове за сертифициране и цифрови сертификати. Най-важното нещо, което прави сертифициращият орган е, че удостоверява, че частният ключ принадлежи на конкретно лице. За да гарантира това, сертификационният център е този, който генерира двойки ключове и ги издава лично на собствениците (има опции чрез пълномощник, дистанционно, но това са подробности). Заедно с ключовете се генерира цифров сертификат - това е електронен документ (понякога неговото хартиено представяне), който съдържа информация за собственика на ключа, самия ключ, сертифициращия орган и друга информация. Собственикът, като правило, получава цялата тази доброта на защитен носител (смарт карта, ru-токен и т.н.), който съдържа частен ключ и сертификат с вграден публичен ключ. Самият носител трябва винаги да се съхранява при вас, а сертификатът за публичен ключ, копиран от него, може да бъде предоставен на всеки, за да може да провери електронния ви подпис.

И така, подписването се извършва с частен ключ, а проверката на подписа с публичен ключ. Следователно изразът "документът е подписан от набора от OID" (звучащ в горния спор) е безсмислен. Само два ключа участват в процедурата за подписване и проверка, в 63-FZ те са именувани съответно - ключът за подпис и ключът за проверка на подписа.

И какви са тези прословути OID? Форматът на цифровия сертификат X.509 позволява в него да се съхраняват разширения. Това са някои незадължителни атрибути, които могат да се използват за съхраняване на допълнителна информация. Всеки такъв атрибут е обект, който се определя от идентификатор от йерархичната директория. Оттук OID - Идентификатор на обект. Няма смисъл да се задълбочаваме в природата на самите OID. Всъщност това е допълнителна информация, която може да присъства в сертификата.

Тези допълнителни атрибути могат да се използват за различни цели. Те могат или да предоставят допълнителна информация за собственика, ключове, CA, или да носят допълнителна информация за приложения и услуги, които използват този сертификат. Най-честата употреба е за ролеви контрол на достъпа. Например, в сертификата може да се посочи, че собственикът на ключа е ръководителят на организацията и това ще му даде възможност незабавно да получи достъп до необходимите функции и информация във всички ИС, без да се налага да се свързва с администраторите на всяка IS и промяна на настройките за достъп. Всичко това, разбира се, при условие, че всички тези IS използват сертификата на потребителя за оторизация и анализират един и същи атрибут по един и същи начин (по тази причина атрибутите се избират от директорията, а не се задават произволно).

Поради различните приложения получаваме два сертификата, които са напълно различни по естество. Единият - удостоверява, че съм Аз и това винаги е така. За добро може да се издава един или повече пъти в живота, като паспорт. Въпреки това, поради несъвършенството на съществуващите криптографски алгоритми, за целите на сигурността тези сертификати сега трябва да се преиздават всяка година. Вторият вид сертификат управлява допълнителна информация и може да се променя много по-често от дори веднъж годишно. Може да се сравни с телефонна карта. позицията е променена, електронна поща, телефон - трябва да направите нови визитки.

В света тези два вида сертификати се наричат съответно Public Key Certificate (PKC) и Attribute Certificate (или Authorization Certificate - AC). Сертификат от втория вид може да се издава много по-често от първия, от друга организация, и трябва да бъде по-достъпен и по-лесен за получаване от сертификат за личен "публичен ключ". Във всеки случай, това е, което препоръчва RFC 3281, посветено на този тип сертификати. Сертификатът от втория вид трябва да съдържа само връзка към сертификата за публичен ключ, така че системата, която го използва за оторизиране на потребителя, да може първо да идентифицира лицето, използващо PKC.

Сега нека се приближим до нашата реалност. На законодателно ниво проблемите, свързани с използването на електронни подписи в Руска федерация, се регулират от два основни документа - Закон на Руската федерация от 06.04.2011 г. № 63-FZ „За електронния подпис“ и Заповед на Федералната служба за сигурност на Руската федерация от 27.12.2011 г. № 63-FZ. 795 „За одобряване на изискванията за формата на квалифициран сертификат на ключа за проверка на електронния подпис“. Съставът на квалифициран сертификат е описан в 795-та заповед (Част II „Изисквания към набора от полета на квалифициран сертификат“) и не съдържа изисквания за атрибути, които контролират оторизацията във всяка информационна система. Като допълнителни задължителни атрибути е посочена само информация, която ви позволява да идентифицирате физическо или юридическо лице в Руската федерация (TIN, SNILS и др.). Въпреки че нито законът, нито заповедта на FSB забраняват включването на друга информация в квалифициран сертификат.

Както можете да видите, никакви законодателни норми не диктуват задължителното присъствие в квалифициран сертификат на атрибути, свързани с оторизация във всяка информационна система. Откъде идват тези изисквания? И те идват от разработчици (или "собственици") специфични системи. Да вземем например „Указания за използване на електронен подпис в междуведомствено електронно взаимодействие (версия 4.3)“, публикувани на технологичния портал SMEV. Всъщност в параграф 6 от този документ четем: „При изготвянето на информация за формиране на сертификат EP-SP е необходимо да се определи необходимостта от искане на информация от Rosreestr (извлечение от USRR). Ако е необходимо такова искане, OID трябва да бъде посочен в полето „Подобрен ключ“ (OID=2.5.29.37) в сертификата ES-SP съгласно изискванията на Rosreestr. Тоест, информационната система Rosreestr използва този атрибут, за да определи информацията, която може да бъде издадена на собственика на сертификата. Същият документ обаче съдържа важна забележка, а именно това изискване е валидно до пълното стартиране на ESIA (единна услуга за разрешение в държавни системи) и свързването на системата Rosreestr към него. Това е важна забележка, имайте я предвид.

Няма да се занимавам с други IP-та, използвани в държавата. органи. Подозирам, че ситуацията е подобна. Порталът за обществени поръчки, електронните платформи за търговия, различните счетоводни и финансови приложения също могат да изискват наличието на определени допълнителни OID в потребителския сертификат. В същото време твърдението, че като записвам OID на информационната система в сертификата, по някакъв начин делегирам отговорност на сертификационния център, меко казано, е неправилно. СО въвежда тези данни в сертификата според моето заявление. Ако позицията ми се е променила и съм забравил да подам заявление за отнемане на старото и издаване на ново удостоверение, КО не носи отговорност за моята забрава. В допълнение, законът 63-FZ директно възлага отговорността за неправилното използване на сертификата на неговия собственик. В параграф 6 на член 17 гласим:
Притежателят на квалифициран сертификат трябва:
1) не използвайте ключа за електронен подпис и незабавно се свържете с акредитирания удостоверителен център, издал квалифицираното удостоверение, за прекратяване на това удостоверение, ако има причина да смятате, че е нарушена поверителността на ключа за електронен подпис;
2) да използва квалифициран електронен подпис в съответствие с ограниченията, съдържащи се в квалифицираното удостоверение (ако са установени такива).

Необходимостта в сертификата да се съхранява информация за ролите и достъпите на потребителя в конкретни информационни системи води до проблем, който предизвика спорове във Facebook, а именно сертификатът трябва да се преиздава много по-често, отколкото изискват изискванията за сигурност на личния електронен подпис . Позицията се промени - преиздаваме сертификата. Появи се нов IS - преиздаваме сертификата. Имаше нужда да поискаме информация от IS на нова организация (Rosreestr) - преиздаваме сертификата.

Има 100% попадение в концепцията, наречена в света Attribute Certificate (или Authorization Certificate), която беше спомената по-горе и в която се препоръчва издаването на тези сертификати от друг сертифициращ орган (Attribute Authority, за разлика от Certificate Authority - обикновен CA, който издава квалифицирани ES сертификати) и по опростен начин. Самото удостоверение не трябва да съдържа ключ за електронен подпис и информация за собственика. Вместо това съдържа връзка към сертификата за публичен ключ на собственика, от който можете да получите останалата необходима информация за лицето.

Трябва да се отбележи, че тази схема също има много ограничено приложение и не решава всички проблеми. Какво ще стане, ако следващата информационна система реши да използва същото поле на сертификата „Подобрен ключ“ (OID=2.5.29.37), което вече е заето от стойността на Rosreestr, за своите нужди? Въвеждането на две различни стойности в едно поле няма да работи. Затова ще трябва да пуснем друг АС! Друг проблем е свързан с краткия живот на PKC (една година). Ако имаме няколко АС (които съдържат връзка към личен сертификат), всички те ще трябва да бъдат преиздадени след изтичане на PKC. За ефективното използване на AC е необходим център за авторизация на един потребител във всички информационни системи и всички приложения трябва да използват атрибути на сертификати по последователен и еднакъв начин.

Такъв единен разрешителен център за държавата. органи вече съществуват - това е ОВОСС. Спомнете си бележката относно OID на Rosreestr. В бъдеще те ще бъдат заменени с информация от ESIA. Други информационни системи, в които работят държавни служители, също трябва да направят същото. Вместо да се използва AC за оторизация, е необходимо да се интегрира с ESIA и да получават необходимата информация от там ESIA трябва да може да обвърже квалифициран ES сертификат с акаунт, така че информационните системи да могат да удостоверяват потребителя с помощта на личен ключ и да го упълномощават (осигурявайки достъп до приложението) чрез ESIA. Такава система изглежда по-универсална и надеждна от използването на полета за сертификати и в бъдеще ще автоматизира управлението на достъпа. Ако бъде създадена единна система за кадрови досиета на държавните служители, ESIA ще може да взема информация за правомощията на дадено лице директно от там. Лице, преместено на друга позиция - автоматично губи достъп до една система и получава друга. той продължава да използва своя ES ключ за подписване на документи, нищо не трябва да се преиздава.

В съответствие с техническите условия за CJSC AEI PRIME за разкриване на информация за ценни книжа и други финансови инструменти, одобрени от Банката на Русия (), електронни документисъдържащи обществена информация, трябва да бъдат подписани от субекта на разкриване на информация с усъвършенстван квалифициран електронен подпис (виж клауза 1.7 от Техническите условия). Това изискване е в сила от 1 февруари 2017 г.

В момента е започнал тестов период за прилагане на електронен подпис на PRIME disclosure server, който ще продължи до 31 януари 2017 г. включително.

За да тестват функционалността, клиентите на PRIME могат да използват всеки сертификат за ES ключ, получен преди това за това юридическо лице.

От 1 февруари 2017 г., по изискване на Техническите условия (виж клаузи 1.7. и 9.6.), квалифицираното удостоверение на ключа за проверка на електронния подпис на потребителя трябва да отговаря на изискванията за формата на квалифицираното удостоверение, установени със Заповед на Федералната служба за сигурност на Русия от 27 декември 2011 г. № 795 „Относно изискванията за одобрение на формата на квалифициран сертификат на ключа за проверка на електронния подпис. Подобрено разширение на потребителския сертификат за ключ ( идентификатор на обект 2.5.29.37) трябва да съдържа идентификатора на обекта за разкриване ГЛАВЕН - OID 1.2.643.6.42.5.5.5

Влизането в личния акаунт на потребителя за разкриване на информация "PRIME" ще се извършва с помощта на ВХОД и ПАРОЛА, получени преди това от клиента.

Действията на клиента за публикуване на съобщения в канала за разкриване на информация, публикуване на документи на страница в Интернет, извършване на промени в регистрационната карта на издателя в системата за разкриване на информация трябва да бъдат потвърдени с електронен подпис.

За да използвате ES на сървъра за разкриване на информация PRIME, клиентът трябва първо да инсталира приставката (инсталацията е безплатна за потребителите и не отнема много време). Вижте инструкциите за инсталиране на приставката по-долу.

В личния акаунт на потребителя за разкриване на информация, след като клиентът инсталира приставката, при попълване на формуляри за публикуване на съобщение в емисията за разкриване на информация или поставяне на документ в Интернет, както и при промяна на данните в регистрационната карта, ще се появят допълнителни полета „Електронен подпис на документ“, където ще е необходимо да изберете показаното в съответното служебно поле сертификат за ключ за подписване и да натиснете бутона „Подписване“. По този начин клиентът ще потвърди действията си по разкриване на информация или извършване на промени в регистрационната си карта.

След като подпише съобщението с електронен подпис, клиентът трябва да натисне бутона „Публикуване“.
След като подпише документа с електронен подпис, клиентът трябва да натисне бутона „Добавяне на документ“.
След подписване на промените в регистрационната карта с електронен подпис, клиентът трябва да натисне бутона „Изпращане на формуляр за идентификация“.

Моля, имайте предвид, че всички съобщения, изпратени от клиенти чрез техния личен акаунт чрез оторизацията „Тестов вход (работа с ES)“, ще бъдат публикувани в канала за разкриване на информация в работен режим. Всички документи, поставени от клиенти чрез техния личен акаунт чрез оторизацията „Тестово въвеждане (работа с ES)“, ще бъдат автоматично публикувани на страниците на емитентите в работен режим.

В противен случай процедурата на емитента в личния акаунт на сървъра за разкриване на информация PRIME не се променя.