Nënshkrimi elektronik i kualifikuar - problemet e OID-ve të sistemeve të informacionit. Nënshkrimi i keq Verifikimi i dështuar i nënshkrimit Mungon identifikuesi i objektit Deshifrimi OID OID

Kur futni llogarinë tuaj personale për të kërkuar një QEP, shfaqet një mesazh « Kompjuteri nuk është konfiguruar . Për të vazhduar, shkoni te faqja e cilësimeve të kompjuterit dhe ndiqni hapat e sugjeruar » . Pasi të shkoni në faqen e cilësimeve dhe të instaloni të gjithë komponentët e nevojshëm llogari personale shfaqet sërish mesazhi se kompjuteri nuk është i konfiguruar.

Për të rregulluar gabimin, duhet:

1. Shtoni adresën e llogarisë suaj personale https://i.kontur-ca.ru në nyjet e besuara. Për këtë:

Zgjidhni menunë "Start" > "Control Panel" > "Internet Options";
Shkoni te skeda "Siguria", zgjidhni elementin "Sajte të besuara" (ose "Sajte të besuara") dhe klikoni në butonin "Nyjet";
Specifikoni adresën e mëposhtme të nyjës https://i.kontur-ca.ru në fushën Shto në zonën dhe klikoni butonin Shto.

Nëse kjo adresë është tashmë në listën e sajteve të besuara, shkoni në hapin tjetër.

2. Kontrolloni që adresa e llogarisë personale https://i.kontur-ca.ru të përcaktohet si e besueshme:

Nëse përdoret versioni 8 i Internet Explorer, atëherë, duke qenë në faqen e autorizimit, duhet të kontrolloni nëse kutia e kontrollit "Sajtet e besuara" është në fund të faqes. Nëse nuk ka kuti, por ka një mbishkrim « Internet”, atëherë adresa https://i.kontur-ca.ru nuk është shtuar në faqet e besuara.

Nëse përdoret Internet Explorer versioni 9 dhe më i lartë, atëherë, duke qenë në faqen e autorizimit, duhet të klikoni me të djathtën kudo në faqe, zgjidhni "Properties". Në dritaren që hapet, rreshti "Zone" duhet të përmbajë mbishkrimin "Sajte të besuara". Përndryshe, adresa https://i.kontur-ca.ru nuk është shtuar në faqet e besuara.

Nëse adresa e llogarisë personale nuk përcaktohet si e besueshme, atëherë duhet të kontaktoni administratorin e sistemit me një kërkesë për të shtuar adresën https://i.kontur-ca.ru në faqet e besuara.

3. Kontrolloni nëse mund të identifikoheni në llogarinë tuaj personale. Nëse gabimi përsëritet, atëherë duhet të ekzekutoni programin RegOids nga lidhja. Ky mjet do të konfigurojë automatikisht cilësimet OID në regjistrin e kompjuterit. Ju gjithashtu mund të importoni manualisht një nga degët e regjistrit, në varësi të bitness të sistemit operativ të instaluar:

4. Kontrolloni që kompjuteri po përdor të drejtat e administratorit (për të kontrolluar, shkoni te Fillimi - Paneli i kontrollit - Llogaritë e përdoruesve dhe siguria familjare - Llogaritë e përdoruesve). Nëse të drejtat nuk janë të mjaftueshme, duhet t'i jepni përdoruesit të drejta të plota, për këtë, kontaktoni administratorin tuaj.

5. Pas përfundimit të hapit 3, është e nevojshme të rinisni kompjuterin dhe të kontrolloni hyrjen në Llogarinë Personale.

Nëse asnjë nga udhëzimet nuk ju ndihmoi, atëherë duhet të kontaktoni mbeshtetje teknike nga adresa [email i mbrojtur] Letra duhet të tregojë:

1. Numri i diagnozës.

Për ta bërë këtë, duhet të shkoni në portalin diagnostik nëhttps://help.kontur.ru , Shtyp butonin " Filloni Diagnostifikimin » . Pasi të përfundojë procesi i verifikimit, numri i diagnostikimit do të shfaqet në ekran. Specifikoni numrin e referencës së caktuar në letër.

2. Pamja e ekranit të dritares me gabimin (kur përdorni versionin 9 të Internet Explorer dhe më të lartë, duhet të bashkëngjitni gjithashtu një pamje të dritares "Properties" - shikoni pikën 2).

3. Eksportoni dhe bashkëngjitni degët e mëposhtme të regjistrit:

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

Dispozitat e përgjithshme.
Zgjedhja e një metode për paraqitjen e të dhënave të caktuara dhe kufizimet shtesë në përbërjen e fushave të certifikatës bazohet në parimet e mëposhtme:
Rekomandimet ndërkombëtare. Ky dokument është zhvilluar duke marrë parasysh rekomandimet ndërkombëtare:
- RFC 3280 (duke përditësuar RFC 2459) Internet X.509 Infrastruktura e çelësit publik. Profili i certifikatës dhe i listës së revokimit të certifikatave (CRL).
- RFC 3039 Internet X.509 Infrastruktura e çelësit publik. Profili i certifikatës së kualifikuar - Ky RFC propozon Kërkesat e përgjithshme tek sintaksa (përbërja) e certifikatave, përdorimi i të cilave është ligjërisht i rëndësishëm.

Përbërja dhe qëllimi i fushave të certifikatës.

Ky seksion jep një përshkrim të fushave kryesore të një certifikate me çelës publik që është në përputhje me ligjin "Për nënshkrimin dixhital elektronik" datë 10.01.2002.

Konceptet, shënimet dhe terminologjia e përdorur në këtë seksion bazohen në RFC 3280 dhe RFC 3039, të cilat, nga ana tjetër, bazohen në versionin 3 të rekomandimit ITU-T X.509. Përmbajtja e seksionit nuk kopjon përmbajtjen e këtyre dokumenteve , por tregon vetëm dallimet dhe veçoritë e përdorimit të certifikatave të fushave që zbatojnë kërkesat për përbërjen e certifikatës EDS të përcaktuara në nenin 6 të ligjit EDS.

Për të gjitha fushat e certifikatës që kërkojnë vlera të vargut në gjuhën ruse, preferohet të përdoret kodimi universal UTF-8 (lloj UTF8String).

Qëllimi i këtij seksioni është të përcaktojë përbërjen dhe qëllimin e fushave të certifikatës pa marrë parasysh kërkesat e një autoriteti të caktuar certifikues. Dokumentet që rregullojnë funksionimin e një autoriteti certifikues mund të kufizojnë përbërjen e fushave të certifikatës dhe grupin e atributeve të përdorura për të identifikuar CA dhe mbajtësit e certifikatës çelësat e nënshkrimit.

version
Të gjitha certifikatat e lëshuara duhet kanë versionin 3.

Numër serik
Fusha Serial Number duhet përmbajnë "... një numër unik regjistrimi të certifikatës së çelësit të nënshkrimit" (neni 6, pika 1, paragrafi 1). Unike e numrit të certifikatës duhet të respektohet brenda një autoriteti të caktuar certifikues (CA).

Vlefshmëria
Fusha e vlefshmërisë duhet përmbajnë "... datat e fillimit dhe skadimit të periudhës së vlefshmërisë së certifikatës së çelësit të nënshkrimit të vendosur në regjistrin e qendrës së certifikimit" (neni 6, pika 1, paragrafi 1).

SubjectPublicKeyInfo
Fusha e subjektitPublicKeyInfo duhet përmbajnë "... çelësin publik të nënshkrimit elektronik dixhital" (neni 6, pika 1, paragrafi 3).

Lëshuesi
Ligji Federal "Për EDS" supozon lëshimin e certifikatave vetëm për individët, kjo dispozitë vlen edhe për certifikatat e vetë CA-ve dhe certifikatat e burimeve. Për të përmbushur kërkesat formale të Ligjit Federal, propozohet të tregohet në atributet e AK-së dhe certifikatave të burimeve informacioni real i organizatës, duke pasur parasysh që një certifikatë e tillë i lëshohet një individi të autorizuar të AK-së ose të Burimit dhe informacioni i specifikuar duhet të interpretohet dhe regjistrohet si një certifikatë për një pseudonim, i cili lejohet nga Ligji Federal "Për EDS".
Fusha e lëshuesit duhet identifikoni në mënyrë unike organizatën që ka lëshuar certifikatën dhe përmban emrin e regjistruar zyrtarisht të organizatës.
Atributet e mëposhtme mund të përdoren për identifikim:

Emri i vendit	(id-në 6)
shtetiOrProvincaEmri	(id-në 8)
Emri i lokalitetit	(id-në 7)
Emri i Organizatës	(id-në 10)
emri i njësisë organizative	(id-në 11)
adresa postale	(id-në 16)
numër serik	(id-në 5)

Fusha e lëshuesit duhet sigurohuni që të përfshini atributet që përshkruajnë "emrin dhe vendndodhjen e autoritetit certifikues që ka lëshuar certifikatën e çelësit të nënshkrimit" (neni 6, pika 1, paragrafi 5).

Emri duhet specifikuar në atributin Emri i organizatës. Kur përdorni atributin Emri i organizatës ndoshta

Vendndodhja e CA ndoshta të specifikohet duke përdorur një grup atributesh countryName, stateOr ProvinceName, localityName (secila prej të cilave është opsionale) ose duke përdorur një atribut të vetëm postalAddress. Me ndonjë nga metodat e mësipërme, vendndodhja e AK-së duhet të jetë i pranishëm në certifikatë.

duhet përmbajnë adresën ligjore të autoritetit certifikues. Një hapësirë (karakteri "0x20") duhet të përdoret si ndarës.

atributi i fushës së subjektit Numri i serisë duhet të përdoret në përplasjet e emrave.

subjekt
Për të përfaqësuar DN (Emri i dalluar) i zotëruesit të certifikatës mund përdoren atributet e mëposhtme:

Emri i vendit	(id-në 6)
shtetiOrProvincaEmri	(id-në 8)
Emri i lokalitetit	(id-në 7)
Emri i Organizatës	(id-në 10)
emri i njësisë organizative	(id-në 11)
titullin	(id-në 12)
emer i perbashket	(id-në 3)
pseudonim	(id-në 65)
numër serik	(id-në 5)
adresa postale	(id-në 16)

Për të përmbushur kërkesat formale të Ligjit Federal, propozohet të tregohet në atributet e AK-së dhe certifikatave të burimeve informacioni real i organizatës, duke pasur parasysh që një certifikatë e tillë i lëshohet një individi të autorizuar të AK-së ose të Burimit dhe informacioni i specifikuar duhet të interpretohet dhe regjistrohet si një certifikatë për një pseudonim, i cili lejohet nga Ligji Federal "Për EDS".

fusha lëndore duhetështë e detyrueshme të përmbajë të dhënat e mëposhtme: "mbiemri, emri dhe patronimika e pronarit të certifikatës së çelësit të nënshkrimit ose pseudonimit të pronarit" (neni 6, pika 1, paragrafi 2).

Mbiemri, emri dhe patronimi i pronarit duhet të përfshihet në atributin commonName dhe të përputhet me ato të specifikuara në pasaportë. Një hapësirë (karakteri "0x20") duhet të përdoret si ndarës.

Pseudonimi i pronarit duhet të përfshira në atributin alias.

Përdorimi i njërit prej këtyre atributeve përjashton përdorimin e tjetrit.

Pjesa tjetër e atributeve janë opsionale.

"Nëse është e nevojshme, certifikata e çelësit të nënshkrimit, në bazë të dokumenteve mbështetëse, tregon pozicionin (me emrin dhe vendndodhjen e organizatës në të cilën është krijuar ky pozicion) ..." (neni 6, pika 2).

Titulli i mbajtësit të certifikatës duhet specifikuar në atributin e titullit. Vlera e atributit duhet korrespondojnë me hyrjen në dokumentet që konfirmojnë pozicionin e vendosur për mbajtësin e certifikatës.

Atributi i titullit, sipas RFC 3039, duhet të përfshihet në shtrirjen SubjectDirectoryAttributes. Megjithatë, ky dokument (dhe RFC 3280) lejon që ai të përfshihet në fushën e temës.

Kërkohet kur përdoret atributi i titullit duhet përfshijnë atribute që përshkruajnë emrin dhe vendndodhjen e organizatës në të cilën pozicioni është krijuar.

Emri i kompanisë duhet specifikuar në atributin Emri i organizatës. Vlera e atributit duhet përkojnë me emrin e organizatës në themelimin ose dokumente të tjera ekuivalente. Kur përdorni atributin Emri i organizatës ndoshta përdoret gjithashtu atributi organizativUnitName.

Vendndodhja e organizatës ndoshta të specifikohet duke përdorur një grup atributesh countryName, stateOr ProvinceName, localityName (secila prej të cilave është opsionale) ose duke përdorur një atribut të vetëm postalAddress.

Atributi postalAddress, nëse përdoret, duhet përmbajnë adresën ligjore të organizatës ose adresën e vendbanimit të pronarit të certifikatës së çelësit të nënshkrimit (për një individ).

Nëse atributi i organizatës është i pranishëm, atributet emri i vendit, emri i shtetitOr Province, i lokalitetitName dhe postalAddress duhet interpretohet si vendndodhja e organizatës.

Atributet opsionale të fushës së temës (emri i vendit, emri i shtetit ose i krahinës, emri i lokalitetit, emri i organizatës, emri i njësisë së organizatës, titulli, adresa postare) mund të përfshihet, nëse përcaktohet nga rregulloret e AK-së, në vend të fushës së temës në shtrirjen SubjektiDirectoryAttributes (shih pikën 3.8.1). Në këtë rast ata nuk duhet të përfshihen në lëndë dhe nuk mundet të përdoret për të bërë dallimin midis pronarëve të nënshkrimit të certifikatave kryesore.

atributi serialNumber duhet të përfshihet në fushën e subjektit të certifikatës në rast të përplasjes së emrit. Ai gjithashtu ndoshta përfshihet nëse përcaktohet nga rregulloret e qendrës së certifikimit.

atributi serialNumber ndoshta:

të jetë arbitrar (i caktuar nga vetë autoriteti certifikues);
përmbajnë një identifikues (numër) të caktuar nga një organizatë shtetërore (ose tjetër) (për shembull, TIN, seria dhe numri i pasaportës, numri i kartës së identitetit, etj.).

Zgjerimet e kërkuara
duhet përfshini shtesat e mëposhtme:
- Përdorimi i çelësit (id-ce 15)
- Politikat e Certifikatës (id-ce 32)
1. Përdorimi i çelësit
  Në mënyrë që një certifikatë të përdoret për të verifikuar një nënshkrim dixhital, në shtesën keyUsage duhet duhet të vendosen bitet DigitalSignature(0) dhe nonRepuduation(1).
  Politikat e Certifikatës
  Zgjerimi i politikave të certifikatës synon të përcaktojë shtrirjen e zbatimit ligjor përkatës të një certifikate.
  "... emri i mjeteve EDS me të cilat përdoret ky çelës publik ..." (neni 6, pika 1, paragrafi 4), "... informacion në lidhje me marrëdhëniet në zbatimin e të cilave një dokument elektronik me një elektronike nënshkrim dixhital do të ketë rëndësi juridike...” (neni 6 pika 1 paragrafi 6) dhe të dhëna të tjera që rregullojnë procedurën për marrjen dhe përdorimin e certifikatave kyçe të nënshkrimit, mund te jete në dispozicion në CPSuri (Deklarata e praktikës së certifikatës URI) e specifikuar në këtë shtesë.

Zgjerime opsionale
Si pjesë e certifikatës së çelësit të nënshkrimit mund përfshijnë çdo shtesë tjetër. Kur përfshini shtesat në certifikatën e çelësit EDS, është e nevojshme të sigurohet konsistenca dhe paqartësia e informacionit të paraqitur në certifikatë.
Ky dokument nuk specifikon përdorimin e shtesave të tjera përveç shtesës "subjectDirectoryAttributes" (id-ce 9).

SubjectDirectoryAtributet
Zgjerimi i subjektitDirectoryAttributes ndoshta përmbajnë atribute që plotësojnë informacionin e dhënë në fushën e temës.
Përveç atributeve të listuara në RFC 3039, atributet e mëposhtme rekomandohen të mbështeten në shtesën subjectDirectoryAttributes:

kualifikim	{-}
Emri i vendit	(id-në 6)
shtetiOrProvincaEmri	(id-në 8)
Emri i lokalitetit	(id-në 7)
Emri i Organizatës	(id-në 10)
emri i njësisë organizative	(id-në 11)
titullin	(id-në 12)
adresa postale	(id-në 16)

"Nëse është e nevojshme, certifikata e çelësit të nënshkrimit, në bazë të dokumenteve mbështetëse, tregon ... kualifikimet e pronarit të certifikatës së çelësit të nënshkrimit" (neni 6, pika 2).

Të dhëna për kualifikimin e pronarit të certifikatës së çelësit EDS duhet specifikuar në atributin e kualifikimit. Ky atribut nuk është i përcaktuar në rekomandimet ndërkombëtare (shih pikën 2) dhe i nënshtrohet regjistrimit.

Nëse atributet emri i vendit, emri i shtetitOr Province, i lokalitetit, emri i organizatës, emri i njësisë, titulli, adresa postare përfshihen në shtrirjen SubjektiDirectoryAttributes, ato nuk duhet të përfshihen në fushën e lëndës.

Për të ruajtur informacione të tjera në lidhje me zotëruesin e certifikatës së çelësit të nënshkrimit mund përdorni atribute të tjera (tashmë të regjistruara ose subjekt regjistrimi) që nuk bien ndesh me kufizimet e vendosura nga zgjatja e politikave të certifikatës dhe dokumentet e tjera që rregullojnë punën e AK-së.

Aplikimi ASN1

ID-në: Vlera OID: 2.5.4
Përshkrimi i OID: Llojet e atributeve X.500.
id-ce: Vlera OID: 2.5.29
Përshkrimi i OID: Identifikuesi i objektit për shtesat e certifikatës së versionit 3.

2.5.4.5 id-at-numri serial Atributi i numrit të serisë::= ( ME SINTAX Printable String (MADËSIA (1..64)) RREGULLI I BARAZISË SË PËRQASHTIMIT caseIgnoreMatch SUNSTRINGS RREGULLAT E RREGULLAVE TË PËRputhshme InjorojNënvargjet Përputhje ID-në id-at-serialNumber )

(RFC 3039)
Lloji i atributit serialNumber, kur është i pranishëm, duhet të përdoret për të dalluar emrat ku fusha e subjektit do të ishte ndryshe identike. Ky atribut nuk ka semantikë të përcaktuar përtej sigurimit të unike të emrave të subjekteve. Ai MUND të përmbajë një numër ose kod të caktuar nga AK ose një identifikues të caktuar nga një autoritet qeveritar ose civil. Është përgjegjësi e AK-së të sigurojë që numri i serisë është i mjaftueshëm për të zgjidhur çdo përplasje të emrit të subjektit.

2.5.4.3 - id-at-commonName

Vlera OID: 2.5.4.3

Përshkrimi i OID: Lloji i atributit të emrit të përbashkët specifikon një identifikues të një objekti. Një emër i zakonshëm nuk është një emër drejtorie; është një emër (ndoshta i paqartë) me të cilin objekti njihet zakonisht në një fushë të kufizuar (siç është një organizatë) dhe përputhet me konventat e emërtimit të vendit ose kulturës me të cilën lidhet.

ATRIBUTI CommonName::= ( NËNTIPI I emrit ME SINTAX DirectoryString (ub-common-name) ID (id-at-commonName) )

(RFC 3039: Profili i certifikatës së kualifikuar)
Vlera OID: 2.5.4.65

pseudonimi ATRIBUTE::= ( NËNTIPI I emrit ME ID SINTAX DirectoryString (id-at-pseudonim) )

Vlera OID: 2.5.29.17

Përshkrimi i OID: id-ce-subjectAltName Kjo shtesë përmban një ose më shumë emra alternativë, duke përdorur cilindo prej formave të ndryshme të emrave, për entitetin që është i lidhur nga CA me çelësin publik të certifikuar.

SubjectAltName EXTENSION::= ( SINTAKSË Emrat e Përgjithshëm IDENTIFIKUARA NGA id-ce-subjectAltName ) Emrat e Përgjithshëm::= SIZE SEKUENCA (1..MAX) E Emrit të Përgjithshëm Emri i Përgjithshëm::= ZGJIDHJA (Një tjetër Emri INSTANCE,25, NDËRKOMBËTARE, NDËRKOMBËTARE, NDËRKOMBËTARE, NDËRKOMBËTARE, NDËRKOMBËTARE, 25, 25 *) x400 Adresa ORAadresa, direktori Emri Emri, ediPartyName EDIPartyName, uniformIdentifikuesi i burimit IA5String, IPadresa OCTET STRING, IDENTIFIKU I OBJEKTIT të regjistruar) (*) – varg arbitrar. TJETËR-EMRI::= RADHË (ID-i i tipit Vlera e IDENTIFIKATORIT TË OBJEKTIT EXPLICIT TË PËRKUFIZUAR NGA lloji-id)

Vlera OID: 2.5.4.16

Përshkrimi i OID: Lloji i atributit të Adresës Postare specifikon informacionin e adresës për dërgimin fizik të mesazheve postare nga autoriteti postar tek objekti i emërtuar. Një vlerë atributi për adresën postare zakonisht do të përbëhet nga atribute të zgjedhura nga versioni 1 i Adresës O/R postare të paformatuar MHS sipas CCITT Rec F.401 dhe i kufizuar në 6 rreshta me 30 karaktere secila, duke përfshirë një emër të shtetit postar. Normalisht, informacioni i përfshirë në një adresë të tillë mund të përfshijë emrin e adresuesit, adresën e rrugës, qytetin, shtetin ose krahinën, kodin postar dhe mundësisht numrin e kutisë postare në varësi të kërkesave specifike të objektit të emërtuar.

ATRIBUTI I Adresës Postare::= ( ME SINTAKSË RREGULLI I PËRQASHTIMIT TË BARAZISË TË Adresës Postare caseIgnoreListMatch RREGULLAT E PËRQASHTIMIT TË NËNSTRINGSVE caseIgnoreListNënvargjeve ID-ja e përputhjes id-at-postaladresa ) Adresa Postare::= SQUARE-postaly)str.

Vlera OID: 2.5.4.12

Përshkrimi i OID: Lloji i atributit Titulli specifikon pozicionin ose funksionin e caktuar të objektit brenda një organizate. Një vlerë atributi për Titullin është vargu.

Titulli ATTRIBUTE::= ( NËNTIPI I emrit ME SINTAX DirectoryString (nëntitull) ID id-at-title ) id-ce-certificatePolicies OBJEKTI IDENTIFIKUESI::= ( id-ce 32 ) certifikataPolicies::= SEKUENCA.IZE.IZE. Max) e politikës së politikës së informacionit Informacioni :: = sekuenca (CertPolicyId i PolicyIdentifikuesit, Madhësia e Sekuencave të Politikave (1..Max) e PolicyQualifierInfo Opsionale) Certifikata) për kualifikuesit e politikave të internetit id-qt IDENTIFIKUESI I OBJEKTIT::= ( id-pkix 2 ) id-qt-cps IDENTIFIKUESI I OBJEKTIT::= ( id-qt 1 ) id-qt-unotice IDENTIFIKUESI I OBJEKTIT::= ( id-qt 2 ) PolicyQualifierId::= IDENTIFIKU I OBJEKTIT (id-qt-cps | id-qt-unotice) Kualifikuesi::= ZGJIDHJE ( cPSuri CPSuri, userNotice UserNotice ) CPSuri:: IA5 String Njoftimi i përdoruesit::= SEQUENCE (Njoftimi NjoftimRefTextTIONALReferencë, Njoftimi OPittionALTeksti i referencës) Referenca e Njoftimit::= SEKUENCA ( organi zation DisplayText, njoftimNumrat SEKUENCA E INTEGER ) DisplayText::= ZGJEDHJA (visibleString String (SIZE (1..200)), bmpString BMPString (SIZE (1..200)), utf8String UTF8String (SIZE200))

Vadim Malykh
02.10.2013

Pak kohë më parë, në grupin Forum Rus në Facebook, u diskutua për përdorimin e sistemet e informacionit ah autoritetet (diskutimi ishte jashtë temës, mund ta shihni në komentet më poshtë). Thelbi i mosmarrëveshjes është se për shkak të OID-ve (identifikuesi i objektit - identifikuesi i objektit) të sistemeve të informacionit që duhet të regjistrohen në certifikatat e nënshkrimeve elektronike të kualifikuara (ES) të zyrtarëve, të njëjtat ES duhet të ndryshohen edhe më shpesh se një herë vit (i cili diktohet nga kërkesat e sigurisë), dhe kjo, nga ana tjetër, çon në kompleksitete dhe kosto shtesë, pasi shumica e autoriteteve punojnë me AK komerciale pa pasur të tyren. Problemi përkeqësohet nga mungesa e një kuptimi të përbashkët se çfarë saktësisht këto OID-të ofrojnë dhe sa të nevojshme dhe/ose të detyrueshme janë ato.

Gjatë debatit, kundërshtari im më paralajmëroi se për shkak të mosnjohjes së disa prej bazave të fushës së lëndës, mund të kem disa probleme me ligjin në të ardhmen. Nuk mund ta injoroja një paralajmërim të tillë nga një koleg, kështu që vendosa ta studioj përsëri me kujdes këtë temë dhe të sigurohem që të kuptoj gjithçka dhe ta bëj siç duhet. Më poshtë janë disa nga rezultatet e këtij ekskursioni në fusha lëndore. Ndoshta dikush do të jetë i interesuar.

Duke filluar me konceptet bazë, nënshkrimi elektronik bazohet në algoritme të enkriptimit asimetrik. Tipari kryesor i këtyre algoritmeve është se dy çelësa të ndryshëm përdoren për të enkriptuar dhe deshifruar një mesazh. Publiku i gjerë është më i njohur me algoritmet simetrike, kur enkriptojmë dhe deshifrojmë një mesazh me të njëjtin çelës (ose fjalëkalim), për shembull, arkivojmë një skedar me një fjalëkalim ose mbrojmë një dokument MS Word.

Shumë gjëra bazohen në algoritme të enkriptimit asimetrik, megjithëse fakti i thjeshtë që çelësat e ndryshëm përdoren për enkriptim dhe deshifrim nuk do të lejonte ende ndonjë aplikim të dobishëm të këtyre algoritmeve. Për ta bërë këtë, ata duhet të kenë disa veti shtesë. Së pari, çelësat nuk duhet të jenë të llogaritshëm, domethënë nëse e dini një çelës, nuk mund të llogarisni të dytin. Është gjithashtu shumë e rëndësishme që çelësat e ndryshëm të enkriptimit të korrespondojnë me çelësa të ndryshëm deshifrimi dhe anasjelltas - vetëm një çelës kriptimi korrespondon me një çelës deshifrimi.

Cili është nënshkrimi aktual? Në fund të fundit, ne duhet të nënshkruajmë dokumentin, jo ta kodojmë atë. Së pari ju duhet të kuptoni se çfarë është një nënshkrim dhe pse është e nevojshme. Kur vendosni nënshkrimin tuaj të shkruar me dorë në një dokument letre, ju siguroni në këtë mënyrë se keni qenë ju (dhe jo dikush tjetër) që keni parë (dhe pranoni) këtë dokument të veçantë (dhe jo ndonjë tjetër). Prona më e rëndësishme nënshkrime - mospranim. Kjo do të thotë që pasi të nënshkruani dokumentin, nuk mund të hiqni dorë nga ai fakt më vonë. Në rastin e një nënshkrimi në letër, ekspertiza e shkrimit të dorës do t'ju dënojë, në rastin e një nënshkrimi elektronik, metodat matematikore të bazuara në algoritme të enkriptimit asimetrik.

Si funksionon gjithçka, me pak fjalë. Ne marrim një algoritëm asimetrik të kriptimit, gjenerojmë një palë çelësash (për kriptim dhe deshifrim). Ne ia japim çelësin e enkriptimit personit që do të nënshkruajë dokumentet. Ai duhet ta mbajë gjithmonë me vete dhe të mos ia japë askujt. Prandaj, quhet çelësi "privat". Ne i japim një çelës tjetër (deshifrimi) për të gjithë, kështu që ai është "i hapur". Kur nënshkruan një dokument, një person duhet ta kodojë atë me çelësin e tij privat. Nuk është vetë dokumenti që është në të vërtetë i koduar, pasi mund të jetë mjaft i madh dhe ne në fakt nuk kemi nevojë ta kodojmë atë. Prandaj, për dokumentin merret një hash - kjo është një sekuencë e caktuar numerike me një shkallë të lartë probabiliteti të ndryshme për dokumente të ndryshme, si një "gjurmë gishti" e dokumentit. Është i koduar me çelësin privat të nënshkruesit. Ky hash i koduar është nënshkrim elektronik dokument. Tani, duke pasur një dokument, një nënshkrim dhe një çelës publik, çdokush mund të verifikojë lehtësisht se ky dokument i veçantë është nënshkruar me këtë çelës të veçantë privat. Për ta bërë këtë, ne përsëri marrim hash-in e dokumentit, deshifrojmë nënshkrimin me çelësin publik dhe krahasojmë. Duhet të marrë dy sekuenca numerike identike.

E gjithë kjo është e shkëlqyeshme, por deri më tani kemi marrë mospranim të nënshkrimit për çelësin privat, domethënë kemi vërtetuar se dokumenti është i nënshkruar nga një çelës specifik. Duhet të vërtetojmë se është nënshkruar nga një person specifik. Për ta bërë këtë, ekzistojnë qendra certifikimi dhe certifikata dixhitale. Gjëja më e rëndësishme që bën një autoritet certifikues është që të vërtetojë se çelësi privat i përket një personi specifik. Për ta garantuar këtë, është qendra e certifikimit që gjeneron çiftet e çelësave dhe ua lëshon ato personalisht pronarëve (ka opsione me prokurë, nga distanca, por këto janë detaje). Së bashku me çelësat, gjenerohet një certifikatë dixhitale - ky është një dokument elektronik (nganjëherë përfaqësimi i tij në letër), i cili përmban informacione për pronarin e çelësit, vetë çelësin, autoritetin e certifikimit dhe disa informacione të tjera. Pronari, si rregull, i merr të gjitha këto të mira në një medium të sigurt (kartë inteligjente, ru-token, e kështu me radhë), i cili përmban një çelës privat dhe një certifikatë me një çelës publik të ngulitur. Vetë operatori duhet të mbahet gjithmonë me ju dhe certifikata e çelësit publik të kopjuar prej tij mund t'u jepet të gjithëve në mënyrë që ata të verifikojnë nënshkrimin tuaj elektronik.

Pra, nënshkrimi bëhet me çelës privat, dhe verifikimi i nënshkrimit me çelës publik. Prandaj, shprehja "dokumenti nënshkruhet nga grupi i OID-ve" (që tingëllon në mosmarrëveshjen e mësipërme) është i pakuptimtë. Vetëm dy çelësa përfshihen në procedurën e nënshkrimit dhe verifikimit, në 63-FZ ato emërohen në përputhje me rrethanat - çelësi i nënshkrimit dhe çelësi i verifikimit të nënshkrimit.

Dhe cilat janë këto OID famëkeqe? Formati i certifikatës dixhitale X.509 lejon që shtesat të ruhen në të. Këto janë disa atribute opsionale që mund të përdoren për të ruajtur informacione shtesë. Çdo atribut i tillë është një objekt që specifikohet nga një identifikues nga drejtoria hierarkike. Prandaj OID - Identifikuesi i objektit. Nuk ka kuptim të thellohemi në natyrën e vetë OID-ve. Në fakt, ky është një informacion shtesë që mund të jetë i pranishëm në certifikatë.

Këto atribute shtesë mund të përdoren për qëllime të ndryshme. Ata ose mund të japin informacion shtesë për pronarin, çelësat, CA, ose të mbajnë disa informacione shtesë për aplikacionet dhe shërbimet që përdorin këtë certifikatë. Përdorimi më i zakonshëm është për kontrollin e aksesit të bazuar në role. Për shembull, në certifikatë mund të thuhet se pronari i çelësit është kreu i organizatës, dhe kjo do t'i japë atij mundësinë që të aksesojë menjëherë funksionet dhe informacionin e nevojshëm në të gjitha IS, pa pasur nevojë të kontaktojë me administratorët e secilit. IS dhe ndryshoni cilësimet e qasjes. E gjithë kjo, natyrisht, me kusht që të gjitha këto IS të përdorin certifikatën e përdoruesit për autorizim dhe të analizojnë të njëjtin atribut në të njëjtën mënyrë (për këtë arsye, atributet zgjidhen nga direktoria dhe nuk vendosen në mënyrë arbitrare).

Për shkak të aplikimeve të ndryshme, ne marrim dy certifikata që janë krejtësisht të ndryshme në natyrë. Një - vërteton se unë jam unë, dhe kështu është gjithmonë. Për mirë, mund të lëshohej një ose më shumë herë në jetë, si një pasaportë. Megjithatë, për shkak të papërsosmërisë së algoritmeve ekzistuese kriptografike, për qëllime sigurie, këto certifikata tani duhet të ribotohen çdo vit. Lloji i dytë i certifikatës menaxhon informacion shtesë dhe mund të ndryshojë shumë më shpesh se edhe një herë në vit. Mund të krahasohet me kartë telefonike. pozicioni i ndryshuar, Email, telefon - ju duhet të bëni karta të reja biznesi.

Në botë, këto dy lloje certifikatash quhen përkatësisht Certifikata e çelësit publik (PKC) dhe Certifikata e Atributit (ose Certifikata e Autorizimit - AC). Një certifikatë e llojit të dytë mund të lëshohet shumë më shpesh se e para, nga një organizatë tjetër, dhe duhet të jetë më e aksesueshme dhe më e lehtë për t'u marrë se një certifikatë personale "çelës publik". Në çdo rast, kjo është ajo që rekomandon RFC 3281, kushtuar këtij lloji të certifikatës. Certifikata e llojit të dytë duhet të përmbajë vetëm një lidhje me certifikatën e çelësit publik, në mënyrë që sistemi që e përdor atë për të autorizuar përdoruesin të mund të identifikojë fillimisht personin që përdor PKC.

Tani le t'i afrohemi realitetit tonë. Në nivel legjislativ, çështjet që lidhen me përdorimin e nënshkrimeve elektronike në Federata Ruse, rregullohen nga dy dokumente kryesore - Ligji i Federatës Ruse i 04/06/2011 Nr. 63-FZ "Për Nënshkrimin Elektronik" dhe Urdhri i Shërbimit Federal të Sigurisë së Federatës Ruse i datës 27.12.2011 Nr. 795 "Për miratimin e kërkesave për formularin e një certifikate të kualifikuar të çelësit të verifikimit të nënshkrimit elektronik". Përbërja e një certifikate të kualifikuar përshkruhet në rendin 795 (Pjesa II "Kërkesat për grupin e fushave të një certifikate të kualifikuar") dhe nuk përmban kërkesa për atributet që kontrollojnë autorizimin në çdo sistem informacioni. Si atribute shtesë të detyrueshme, tregohet vetëm informacioni që ju lejon të identifikoni një person fizik ose juridik në Federatën Ruse (TIN, SNILS, etj.). Edhe pse as ligji dhe as urdhri i FSB-së nuk ndalojnë përfshirjen e informacioneve të tjera në një certifikatë të kualifikuar.

Siç mund ta shihni, asnjë normë legjislative nuk dikton praninë e detyrueshme në një certifikatë të kualifikuar të atributeve që lidhen me autorizimin në çdo sistem informacioni. Nga vijnë këto kërkesa? Dhe ato vijnë nga zhvilluesit (ose "pronarët") sisteme specifike. Le të marrim për shembull "Udhëzimet për përdorimin e një nënshkrimi elektronik në ndërveprimin elektronik ndërdepartamental (versioni 4.3)", të postuara në portalin e teknologjisë SMEV. Në të vërtetë, në paragrafin 6 të këtij dokumenti lexojmë: "Kur përgatitni informacionin për formimin e një certifikate EP-SP, është e nevojshme të përcaktohet nevoja për të kërkuar informacion nga Rosreestr (ekstrakt nga USRR). Nëse një kërkesë e tillë është e nevojshme, OID duhet të tregohet në fushën "Çelësi i përmirësuar" (OID=2.5.29.37) në certifikatën ES-SP sipas kërkesave të Rosreestr.". Kjo do të thotë, sistemi i informacionit Rosreestr përdor këtë atribut për të përcaktuar informacionin që mund t'i lëshohet pronarit të certifikatës. Sidoqoftë, i njëjti dokument përmban një shënim të rëndësishëm, domethënë, kjo kërkesë është e vlefshme deri në fillimin e plotë të VNMS-së (shërbim i vetëm autorizimi në sistemet shtetërore) dhe lidhjen e sistemit Rosreestr me të. Ky është një shënim i rëndësishëm, mbani në mend.

Unë nuk do të merrem me IP të tjera të përdorura në shtet. organet. Dyshoj se situata është e ngjashme. Portali i prokurimit publik, platformat elektronike të tregtimit, aplikacionet e ndryshme të kontabilitetit dhe financiar mund të kërkojnë gjithashtu praninë e disa OID-ve shtesë në certifikatën e përdoruesit. Në të njëjtën kohë, deklarata se duke shkruar OID të sistemit të informacionit në certifikatë, në një farë mënyre i delegoj përgjegjësinë qendrës së certifikimit, për ta thënë më butë, është e pasaktë. AK-ja i fut këto të dhëna në certifikatë sipas aplikimit tim. Nëse pozicioni im ka ndryshuar, dhe kam harruar të aplikoj për revokimin e të vjetrës dhe lëshimin e një certifikate të re, AK nuk mund të mbajë përgjegjësi për harresën time. Për më tepër, ligji 63-FZ cakton drejtpërdrejt përgjegjësinë për përdorimin e gabuar të certifikatës tek pronari i saj. Në paragrafin 6 të nenit 17 lexojmë:
Mbajtësi i një certifikate të kualifikuar duhet:
1) mos përdorni çelësin e nënshkrimit elektronik dhe kontaktoni menjëherë qendrën e akredituar të certifikimit që ka lëshuar certifikatën e kualifikuar për të përfunduar këtë certifikatë nëse ka arsye për të besuar se është shkelur konfidencialiteti i çelësit të nënshkrimit elektronik;
2) përdorni një nënshkrim elektronik të kualifikuar në përputhje me kufizimet e përfshira në certifikatën e kualifikuar (nëse vendosen kufizime të tilla).

Nevoja për të ruajtur informacionin në lidhje me rolet dhe akseset e përdoruesit në sisteme specifike informacioni në certifikatë çon në një problem që shkaktoi një mosmarrëveshje në Facebook, domethënë, certifikata duhet të rilëshohet shumë më shpesh sesa kërkesat e sigurisë për një elektronik personal. nënshkrim diktojnë. Pozicioni ka ndryshuar - ne rilëshojmë certifikatën. Është shfaqur një IS i ri - ne rilëshojmë certifikatën. Kishte nevojë për të kërkuar informacion nga IS e një organizate të re (Rosreestr) - ne rilëshojmë certifikatën.

Ka një goditje 100% në konceptin e quajtur në botë Certifikata e Atributit (ose Certifikata e Autorizimit), e cila u përmend më lart dhe në të cilën rekomandohet lëshimi i këtyre certifikatave nga një autoritet tjetër certifikues (Autoriteti i Atributit, në ndryshim nga Autoriteti i Certifikatës - një AK të rregullt që lëshon certifikata të kualifikuara ES) dhe në mënyrë të thjeshtuar. Vetë kjo certifikatë nuk duhet të përmbajë një çelës nënshkrimi elektronik dhe informacion për pronarin. Në vend të kësaj, ai përmban një lidhje me certifikatën e çelësit publik të pronarit, nga e cila mund të merrni pjesën tjetër të informacionit të nevojshëm për personin.

Duhet theksuar se edhe kjo skemë ka një aplikim shumë të kufizuar dhe nuk i zgjidh të gjitha problemet. Po nëse sistemi tjetër i informacionit vendos të përdorë të njëjtën fushë certifikate “Çelësi i përmirësuar” (OID=2.5.29.37), e cila tashmë është e zënë nga vlera Rosreestr, për nevojat e saj? Futja e dy vlerave të ndryshme në një fushë nuk do të funksionojë. Prandaj, do të na duhet të lëshojmë një tjetër AC! Një problem tjetër lidhet me jetëgjatësinë e shkurtër të PKC (një vit). Nëse kemi disa AC (të cilat përmbajnë një lidhje me një certifikatë personale), të gjitha do të duhet të ribotohen pas skadimit të PKC. Për përdorimin efektiv të AC, kërkohet një qendër e vetme autorizimi përdoruesi në të gjitha sistemet e informacionit dhe të gjitha aplikacionet duhet të përdorin atributet e certifikatës në një mënyrë të qëndrueshme dhe uniforme.

Një qendër e tillë e vetme autorizimi për shtetin. Autoritetet tashmë ekzistojnë - kjo është VNMS. Kujtoni shënimin në lidhje me OID-të e Rosreestr. Në të ardhmen, ato do të zëvendësohen me informacion nga VNMS. Sisteme të tjera informacioni në të cilat punojnë nëpunësit civilë duhet të bëjnë gjithashtu të njëjtën gjë. Në vend që të përdorni AC për autorizim, është e nevojshme të integrohen me VNMS dhe të marrë informacionin e nevojshëm nga atje VNMS duhet të jetë në gjendje të lidh një certifikatë të kualifikuar ES me një llogari, kështu që sistemet e informacionit do të jenë në gjendje të vërtetojnë përdoruesin duke përdorur një çelës personal dhe ta autorizojnë atë (duke siguruar akses në aplikacion) nëpërmjet VNMS. Një sistem i tillë duket të jetë më universal dhe më i besueshëm se përdorimi i fushave të certifikatave dhe në të ardhmen, ai do të automatizojë menaxhimin e aksesit. Nëse krijohet një sistem i unifikuar i të dhënave të personelit të nëpunësve civilë, VNMS do të jetë në gjendje të marrë informacion rreth kompetencat e një personi direkt nga atje.Një person i transferuar në një pozicion tjetër - humbi automatikisht aksesin në një sistem dhe fitoi një tjetër. ai vazhdon të përdorë çelësin e tij ES për të nënshkruar dokumentet, asgjë nuk duhet të ribotohet.

Në përputhje me Kushtet Teknike për CJSC AEI PRIME për të zbuluar informacion mbi letrat me vlerë dhe instrumente të tjera financiare të miratuara nga Banka e Rusisë (), dokumente elektronike që përmban informacion publik duhet të nënshkruhet nga subjekti i zbulimit të informacionit me një nënshkrim elektronik të kualifikuar të zgjeruar (shih pikën 1.7 të kushteve teknike). Kjo kërkesë hyn në fuqi nga 1 shkurt 2017.

Aktualisht në serverin e zbulimit PRIME ka nisur një periudhë testimi për aplikimin e nënshkrimit elektronik, e cila do të zgjasë deri më 31 janar 2017 përfshirëse.

Për të testuar funksionalitetin, klientët PRIME mund të përdorin çdo certifikatë kyçe ES e marrë më parë për këtë person juridik.

Nga data 1 shkurt 2017, me kërkesë të Kushteve Teknike (shih pikat 1.7. dhe 9.6.), certifikata e kualifikuar e çelësit të verifikimit të nënshkrimit elektronik të përdoruesit duhet të përputhet me kërkesat për formën e një certifikate të kualifikuar të përcaktuar me Urdhrin e Shërbimi Federal i Sigurisë i Rusisë, datë 27 dhjetor 2011 Nr. 795 "Për kërkesat e miratimit për formularin e një certifikate të kualifikuar të çelësit të verifikimit të nënshkrimit elektronik. Shtesa e zgjeruar e certifikatës së përdoruesit kyç ( identifikues i objektit 2.5.29.37) duhet të përmbajë identifikuesin e objektit të zbulimit PRIME - OID 1.2.643.6.42.5.5.5

Hyrja në llogarinë personale të përdoruesit të zbulimit të informacionit "PRIME" do të kryhet duke përdorur LOGIN dhe PASSWORD të marra më parë nga klienti.

Veprimet e klientit për të publikuar mesazhe në Furnizimin e Zbulimit të Informacionit, për të postuar dokumente në një faqe në internet, për të bërë ndryshime në kartën e regjistrimit të emetuesit në sistemin e zbulimit të informacionit duhet të konfirmohen me një nënshkrim elektronik.

Për të përdorur ES në serverin e zbulimit të informacionit PRIME, klienti duhet së pari të instalojë plug-in-in (instalimi është falas për përdoruesit dhe nuk kërkon shumë kohë). Shikoni udhëzimet e instalimit të shtojcave më poshtë.

Në llogarinë personale të përdoruesit të zbulimit të informacionit, pasi klienti instalon plug-in, kur plotësoni formularët për publikimin e një mesazhi në burimin e zbulimit të informacionit ose vendosjen e një dokumenti në internet, si dhe kur ndryshoni të dhënat e kartës së regjistrimit, Do të shfaqen fusha shtesë "Nënshkrimi elektronik i dokumentit", ku do të jetë e nevojshme të zgjidhni atë që shfaqet në certifikatën e çelësit të nënshkrimit të fushës së shërbimit përkatës dhe të klikoni butonin "Sign". Në këtë mënyrë, klienti do të konfirmojë veprimet e tij për të zbuluar informacionin ose për të bërë ndryshime në kartën e tij të regjistrimit.

Pas nënshkrimit të mesazhit me nënshkrim elektronik, klienti duhet të klikojë butonin "Publikoni".
Pas nënshkrimit të dokumentit me nënshkrim elektronik, klienti duhet të klikojë butonin "Shto dokument".
Pas nënshkrimit të ndryshimeve në kartën e regjistrimit me nënshkrim elektronik, klienti duhet të klikojë butonin "Dërgo formularin e identifikimit".

Ju lutemi vini re se të gjitha mesazhet e dërguara nga klientët përmes llogarisë së tyre personale përmes autorizimit "Test identifikimi (punoni me ES)" do të publikohen në Furnizimin e Zbulimit të Informacionit në modalitetin e punës. Të gjitha dokumentet e vendosura nga klientët përmes llogarisë së tyre personale përmes autorizimit "Hyrja në test (punë me ES)" do të postohen automatikisht në faqet e lëshuesve në modalitetin e punës.

Përndryshe, procedura për veprimet e emetuesit në llogarinë personale në serverin e zbulimit të informacionit PRIME nuk ndryshon.