NN 89/02 od 25.07.2002. Pravilnik o tehničkim pravilima i uvjetima povezivanja sustava certificiranja elektroničkih potpisa

MINISTARSTVO ZNANOSTI I TEHNOLOGIJE

Na teme­lju članka 34., stavka 2., Zakona o elektroničkom potpisu (»Narodne novine«, br. 10/02.) ministar znanosti i tehnologije donosi

PRAVILNIK O TEHNIČKIM PRAVILIMA I UVJETIMA POVEZIVANJA SUSTAVA CERTIFICIRANJA ELEKTRONIČKIH POTPISA

I. OPĆE ODREDBE

Članak 1.

Ovim Pravilnikom utvrđuju se tehnička pravila za osigura­nje povezanosti evidencija izdanih i opozvanih certikata davate­lja usluga certifikata u Republici Hrvatskoj.

II. ELEKTRONIČKI POTPIS

Članak 2.

Struktura elektroničkog potpisa teme­lji se na ETSI TS 101 733 V1.3.1. (2002-02) – Electronic signature formats, odnosno ETSI TS 101 733 V1.2.2. (200-12) za postojeće sustave certificira­nja, kao specifikaciji obrazaca (formata) elektroničkog potpisa.

Uz specifikaciju iz stavka 1. ovog članka, u izradi strukture elektroničkog potpisa preuzimaju se obrasci teme­ljeni na CMS (Cryptographic Message Syntax) modelu utvrđenom u dokumentu RFC 2630 te ESS (Enhanced Security Services) modelu utvrđenom u dokumentu RFC 2634.

Elektronički potpis mora sadržavati osnovna obi­lježja (atribute) utvrđene u CMS, ESS i ETSI TS 101 733 V1.3.1.

Članak 3.

Elektronički potpis mora biti ugradiv u sve raspoložive oblike računalnih zapisa.

Za potrebe automatskog prepoznava­nja vrste potpisanih podataka može se koristiti obrazac MIME-encapsulated message (Multipurpose Internet Mail Extensions- RFC-1341).

Članak 4.

Elektronički potpis koriste potpisnik i primate­lj u skladu s utvrđenom politikom uporabe potpisa.

Politika uporabe potpisa mora se iskazivati u dokumentu čit­ljivom korisnicima potpisa koji moraju imati mogućnost uvida u obveze i prava koja proizlaze iz sadržaja koji se potpisuje.

Za potrebe strojnog, odnosno automatskog obrađiva­nja elektroničkog potpisa nužno je izraditi politiku uporabe potpisa i u formatiranom obliku za potrebe izravnog preuzima­nja od strane računalnih programa (aplikacija).

Formatirani oblik politike uporabe potpisa mora biti izrađen primjenom obrasca ASN.1:1997 (Abstract Syntax Notation 1) i mora imati jedinstvenu binarno kodiranu vrijednost dobivenu kodira­njem po BER (Basic Encoding Rules)/X.209 obrascu-ISO/IEC 8825-1 ASN.1 Encoding Rules-BER.

Potpisnik i primate­lj (ovjerovite­lj) moraju koristiti istu politiku uporabe potpisa radi postiza­nja istovjetnosti potpisa kod ­nje­gove izrade i ovjere.

Za nesum­njivo identificira­nje politike uporabe potpisa u potpis se mora ugraditi identifikator ili sažetak politike uporabe potpisa.

Kod računalnih aplikacija koje koriste velik broj istorodnih dokumenata s jednom politikom uporabe elektroničkog potpisa dopušteno je unaprijed definirati ugrad­nju te politike u elektronički potpis ili je ugraditi u aplikaciju.

Članak 5.

Potpisniku u procesu potpisiva­nja mora biti predstav­ljen i opis procedure (postupka) potpisiva­nja u čit­ljivom obliku s najma­nje s­ljedećim skupom podataka:

– upozore­nje – sadržaj pravnih i drugih či­njenica povezanih s potpisiva­njem, mora biti iskazan prije čina potpisiva­nja

– izjava potpisnika – o prihvaća­nju politike uporabe potpisa i sazna­nja o sadržaju koji potpisuje

– potpisni skup podataka – dio je elektroničkog potpisa i dodaje se potpisanom elektroničkom zapisu; sadrži ime potpisnika, vrijeme i mjesto potpisiva­nja i razlog/svrhu potpisiva­nja.

Članak 6.

Svaki elektronički potpis mora sadržavati jedinstven identifikator (ime potpisnika) koji mora biti kriptografski zaštićen.

Članak 7.

Kod sustava certificira­nja koji podržavaju i koriste promet dokumenata i surad­nju računalnih aplikacija u obrascu XML (Extended Markup Language) može se prihvatiti i uporaba elek­tro­ničkog potpisa oblikovanog u skladu s XAdES (XML Advanced Electronic Signatures) dokumentom ETSI TS 101 903 V1.1.1.

Prilikom uporabe obrasca elektroničkog potpisa iz stavka 1. ovog članka, elektronički potpis mora uk­ljučivati politiku uporabe elektroničkog potpisa i biti izrađen u sustavu certificira­nja jav­nih k­ljučeva.

Članak 8.

Podaci koje sadrži elektronički potpis moraju biti kodirani jednim od tri s­ljedeća obvezna obrasca kodira­nja: DER (Definitive Encoding Rules), Base 64, CMS (Cryptographic Message Syntax) – PKCS#7.

Elektronički potpis objedi­njuje se (programski zatvara) u omotnicu primjenom jednog ili svih s­ljedećih obrazaca: PKCS #7, ISO/IEC 9796-2 (Digital Signature Schemes), S/MIME (Secure Multipurpose Internet Mail Extensions).

Svaki omot s PKCS7 strukturom mora sadržavati samo osnov­ni digitalni dokument bez zaglav­lja ili dodatnih obi­lježja za identifikaciju vrste dokumenta.

III. CERTIFIKAT

Članak 9.

Struktura certifikata teme­lji se na obrascu ITU X.509 v3 i uk­ljučuje kao obvezne atribute:

– inačicu obrasca X.509

– serijski broj

– jednoznačni identifikacijski kod (Object Identifier prema ASN.1) Općih pravila davate­lja usluga certificira­nja (ako je prethodno pridobio OID)

– oznaku (ID) algoritma izrade elektroničkog potpisa (sha1/RSA, MD5/RSA)

– ime izdavate­lja certifikata – po strukturi utvrđenoj u obras­cu X.500

– razdob­lje va­ljanosti certfikata

– ime potpisnika (korisnika certifikata) – po strukturi utvr­đe­noj u obrascu X.500

– podaci o javnom k­ljuču potpisnika

– jedinstveni identifikator izdavate­lja certifikata

– jedinstveni identifikator korisnika certifikata (potpisnika)

– dodatni atributi (prošire­nje osnovnog skupa atributa)

– elektronički potpisane prethodne podatke od strane izda­va­te­lja certifikata.

Članak 10.

Certifikat izrađen teme­ljem obrasca X.509v3 mora sadržavati i dodatne atribute (prošire­nje).

Obvezni skup dodatnih atributa je:

– identifikator k­ljuča davate­lja usluga certificira­nja

– identifikator k­ljuča potpisnika (korisnika certifikata)

– namjene uporabe k­ljuča

– politika certificira­nja

– dopunski podaci o potpisniku uk­ljučujući fizičku/poš­tan­sku i elektroničku adresu

– postupak i mjesto pristupa listi opozvanih certifikata.

Dodatni atributi (prošire­nje) moraju biti strukturirani u skladu s dokumentom ETSI 101 862 v1.2.1 – Qualified Certificate Profile i RFC 3039, koji osiguravaju međupovez­ljivost kvalificiranih certifikata.

Članak 11.

Obrazac i sadržaj kvalificiranih certifikata u skladu s odredbama Zakona o elektroničkom potpisu i smjernicama Europske unije utvrđeni su dokumentom ETSI TS 101 862 V1.2.1 (2001-06) Qualified Certificate Profile.

Primjena certifikata u okružju Internet sustava teme­lji se na obrascu RFC 2459 izvedenom iz X.509v3. Tu se pridružuju i slje­deći dodatni obrasci:

– RFC 2632 – S/MIME v3 Certificate Handling

– RFC 2633 – S/MIME v3 Message Specification

– RFC 3039 – Qualified Certificates Profiles.

Članak 12.

Svi podaci sadržani u certifikatu moraju se kodirati putem dva međupovezana modula:

1. ASN.1:1997 (Abstract Syntax Notation 1)  usklađen s ISO/IEC 8824-1:1998 kojim se opisuju podaci

2. DER (Definitve Encoding Rules) kojim se opisuje jedinstven obrazac pohrane i razmjene podataka.

Certifikati (uk­ljučujući i javne k­ljučeve potpisnika kod primjene sustava javnih k­ljučeva) moraju biti pohra­njeni u standard­nom X.509v3 formatu i biti neovisni o modelu sustava uprav­lja­nja bazama podataka.

IV. OPREMA

Članak 13.

Svaka oprema uk­ljučena u sustav certificira­nja mora biti sukladna opće prihvaćenim i u upotrebi najzastup­ljenijim obrascima.

Članak 14.

Svaka oprema mora omogućiti izdvaja­nje podataka elektro­nič­kog potpisa i certifikata u jedan od najma­nje tri osnovna obras­ca:

– DER Encoded Binary X.509 (*.cer)

– Cryptographics Message Syntax Standard PKCS#7 Certificates (*.p7b)

– Personal Information Exchange Syntax Standard PKCS#12 (*.pfx).

Članak 15.

Kod uporabe smart kartica nužna je mogućnost izdvaja­nja privatnih ključeva, certifikata i osobnih podataka u jedan od standardnih zapisa iz članka 14. ovog Pravilnika.

Kod uporabe smart kartica nužna je primjena ISO/IEC 7816 (1,2.3) te ISO 7816 (4, 5, 6, 7, 8, 9, 10) obrasca ujednačava­nja oblika, veličine i funkcionalnosti kartica i terminala za prihvat kartica.

Kod uporabe smart kartica u postupcima primjene elektro­nič­kih potpisa i certifikata nužna je primjena obrasca PKCS#15 zapisa kriptok­ljučeva, certifikata i drugih podataka (PKCS#15 smart card file format).

Uređaji/terminali za čita­nje i pisa­nje zapisa na smart kartice moraju u okružju osobnih računala imati podršku za tehničke obrasce PCMCIA i PC/SC.

Uređaji za izradu, pohranu i uporabu podataka za izradu elektro­nič­kog potpisa i ovjeru elektroničkog potpisa i certifikata u obliku k­­­­­ljučeva i drugih oblika (tokeni) moraju osigurati prik­­­­­ljučak u standardna komunikacijska suče­­­­­lja RS232, USB, Firewire, PCMCIA, Bluetooth.

Članak 16.

Oprema korisnika sustava certificira­­­­­nja mora omogućiti najma­­­­­nje sljedeće rad­­­­­nje:

– sla­­­­­nje i prima­­­­­nje elektronički potpisanih sadržaja

– provjerava­­­­­nje prim­­­­­ljenih certifikata putem liste opozvanih cerifikata

– provjerava­­­­­nje prim­­­­­ljenih certifikata putem najma­­­­­nje tri razine

– prima­­­­­nje i sla­­­­­nje kriptiranih zapisa

– upotrebu i provjeru kvalificiranih certifikata

– upotrebu smart kartica i drugih medija za kriptografsku obradu.

Članak 17.

Kod uporabe opreme u okružju računala nužna je upotreba API (Application Program Interface) programskih sklopova kojima se mora osigurati korište­­­­­nje bilo koje vrste smart kartica, PCMCIA (Personal Computer Memory Card International Association) modula, tokena i drugih uređaja.

Oprema s ugrađenim API programskim sklopovima mora izvršavati:

– izradu elektroničkog potpisa

– ovjeru elektroničkog potpisa

– oblikova­­­­­nje podataka

– komunicira­­­­­nje uređaja i podataka.

API programski sklopovi moraju se teme­­­­­ljiti na s­­­­­ljedećim kriptografskim obrascima:

– CRYPTOKI – BSAFE/PKCS (RSA) za ugrad­­­­­nju u uređaje i programe

– IDUP-API (Independent Data Unit Protection) za ugrad­­­­­nju u uređaje

– GSS-API (General Security Services) za ugrad­­­­­nju u programe.

Kod uporabe kartica Fortezza nužna je primjena RFC 2876 (Use of the KEA and SKIPJACK Algorithms in CMS) obrasca poveziva­­­­­nja procesa kriptira­­­­­nja i procesa potpisiva­­­­­nja.

Članak 18.

Svaka oprema mora omogućiti uporabu najma­­­­­nje triju osnov­na sigurnosna obrasca za izradu i ovjeru elektroničkog potpisa i izradu kriptiranih zapisa:

– Microsoft Crypto API

– Netscape Security Framework

– Entrust PKI.

Oprema bilo koje namjene uk­­­­­ljučena u sustav certificira­­­­­nja mora osigurati međudjelova­­­­­nje putem suče­­­­­lja PKCS#11 (Public Key Cryptographic Standard 11/Cryptographic Token Interface Standard – Cryptoki) neovisno o vrsti uređaja i medija kojima se izrađuje, koristi ili ovjerava elektronički potpis.

Zapisi, podaci i kriptoelementi ugrađeni u uređaje moraju biti usklađeni s obrascem PKCS#15 (Cryptographic Token Information Format) i osigurati primjenu uređaja neovisno o vrsti suče­­­­­­lja izrađenog u skladu s obrascem PKCS#11.

Članak 19.

Zapisi i elektronički potpisi izrađeni jednom opremom primjenom bilo koje­g od odabranih obrazaca moraju biti čit­­­­­ljivi primjenom druge opreme uz pretpostavku istovjetnog algoritma potpisiva­­­­­nja (DSS/DSA) ili kriptira­­­­­nja (PKCS#1-RSA).

Oprema koja se koristi u sustavu kvalificiranih certifikata mora biti sukladna FIPS PUB 104-1 Validation of Cryptographic Modules obrascu sigurnosti uređaja, programa i zapisa.

Članak 20.

Svaka oprema koja uk­­­­­ljučuje biometrijske metode identifikacije potpisnika može biti primije­­­­­njena ako se pridruži sustavu certificira­­­­­nja X.509 te ako se jedinstveno identificira sredstvo za izradu elektroničkog potpisa na taj način da se jamči da biometrijski uzorak može biti korišten samo s tim sredstvom.

V. SUSTAV CERTIFICIRANJA

Usluge certificira­­­­­nja

Članak 21.

Svaki sustav certificira­­­­­nja koji pruža usluge certificira­­­­­nja mora biti u neprekidnom radu i javno dostupan putem telekomunikacijskog sustava.

Sustav certificira­­­­­nja obuhvaća jednu ili više od s­­­­­ljedećih usluga:

– usluge re­gistracije korisnika certifikata

– usluge izdava­­­­­nja, dostave, čuva­­­­­nja i opoziva certifikata

– usluge uprav­­­­­lja­­­­­nja i čuva­­­­­nja k­­­­­ljučeva

– usluge čuva­­­­­nja potpisanih zapisa

– usluge elektroničkih imenika.

Članak 22.

Svaki sustav certificira­­­­­nja mora prihvatiti (imati sustav certificira­­­­­nja koji može prihvatiti) ulazne podatke u obrascima DER, PKCS i PEM.

Svaki sustav certificira­­­­­nja mora prihvaćati (imati sustav certificira­­­­­nja koji može uprav­­­­­ljati) minimalni skup X.509 v3 dodatnih atributa u certifikatima.

Članak 23.

Svaki sustav certificira­­­­­nja mora osigurati povezanost s drugim sustavima certificira­­­­­nja.

Svaki sustav certificira­­­­­nja mora omogućiti izravnu komunikaciju s potpisnicima uk­­­­­ljučenim u sustav certificira­­­­­nja neovisno kojem sustavu certificira­­­­­nja pripadaju.

Članak 24.

Postupak poveziva­­­­­nja sustava certificira­­­­­nja teme­­­­­lji se na primjeni dogovorenih obrazaca za s­­­­­ljedeća područja:

– certifikati

– poruke

– razmjena certifikata i poruka

– prijenos certifikata i poruka.

Certifikat ima dogovoreni obvezni format utvrđen putem obrasca X.509v3:1997.

Poruke uk­­­­­ljučuju:

– upite za izdava­­­­­nje certifikata koji se iskazuju putem obras­ca PKCS#10

– nepotpisane/potpisane/kritpirane poruke koje se iskazuju putem obrasca PKCS#7

– skupne podatke o potpisniku koji se iskazuju putem obras­ca PKCS#12 (Personal Information Exchange Syntax).

Razmjena certifikata i poruka ima dogovoreni obvezni obrazac CMC (Certificate Management Messages over CMS), pri čemu se upit za izdava­­­­­nje certifikata teme­­­­­lji na potpisanoj PKCS#109 oblikovanoj poruci, a odgovor (certifikat) na PKCS#7 nepotpisanoj ili CMS potpisanoj poruci. Sustavi certificira­­­­­nja koji imaju mogućnost tehnološke podrške mogu koristiti i CMP (Certificate Management Protocols).

Prijenos certifikata i poruka provodi se putem telekomunikacijskih sustava uz obveznu uporabu obrasca S/MIME (Secure Multipurpose Internet Mail Extensions) odnosno obrasca SSL (Secure Socket Layer).

Provjera certifikata putem liste opozvanih certifikata

Članak 25.

Opozvani certifikati moraju se upisati u listu opozvanih certifikata koja mora biti dostupna svim subjektima koji imaju pristup sustavu certificira­­­­­nja.

Lista opozvanih certifikata oblikuje se u skladu s obrascem X.509; The Directory; Authentication Framework i dokumentom RFC 2459; PKI Certificate and CRL Profile.

Članak 26.

Lista opozvanih certifikata mora sadržavati najma­­­­­nje sljede­će elemente:

– redni broj radne inačice liste

– kriptografski algoritam korišten pri izradi elektroničkog potpisa davate­­­­­lja usluga certificira­­­­­nja

– elektronički potpis davate­­­­­lja usluga certificira­­­­­nja

– ime davate­­­­­lja usluga certificira­­­­­nja

– datum izrade liste.

Svaki opozvani certifikat u Listi opozvanih certifikata sadrži:

– serijski broj dodije­­­­­ljen certifikatu kod izdava­­­­­nja

– datum opoziva (od kada certifikat više nije važeći).

Članak 27.

Svaki sustav certificira­­­­­nja mora omogućiti trenutačan i nesmetani uvid u listu opozvanih certifikata kod potvrđiva­­­­­nja va­­­­­ljanosti (od strane primate­­­­­lja elektronički potpisanog sadržaja) certifikata koje je izdao.

Elektronički imenici

Članak 28.

Svi potpisnici i subjekti sustava certificira­­­­­nja upisuju se u elektroničke imenike.

Usluge elektroničkih imenika teme­­­­­lje se na primjeni obrasca ITU-T X.500:2001 (Directory Service) – ISO/IEC 9594:2001 putem jedinstvene strukture (DIT-Directory Information Tree).

Nazivi subjekata u elektroničkom imeniku (DN) kodiraju se po obrascu ASN.1 i moraju biti izraženi sa s­­­­­ljedećom minimalnom listom atributa:

– ime subjekta u imeniku (fizička, pravna osoba) – CommonName

– naziv organizacijske jedinice – OrganizationalUnitName

– naziv pravne osobe – OrganizationName

– mjesto/adresa – LocalityName

– država – CountryName (Nazivi i oznake u skladu s obras­cem ISO 3166-1:1997+Alpha 2).

Sadržaj elektroničkog imenika mora biti izrađen primjenom obrasca kodira­­­­­nja ISO/IEC 10646 – 1:2000 Universal Multiple Octet Coded Character Set (UCS) – Basic Multiple Plane (BMP), odnosno u skladu s obrascem UTF-8 o okruže­­­­­nju Unix, Linux i srodnih operacijskih sustava.

Članak 29.

Pristup sadržajima elektroničkih imenika mora biti oblikovan u skladu s okružjem X.500 i primjenom obrasca DAP (Directory Access Protocol).

Sustavi certificira­­­­­nja mogu radi jednostavnije­g pruža­­­­­nja usluga elektroničkih imenika koristiti LDAPv3/RFC 2251 (Light­weight Directory Access Protocol) obrazac oblikova­­­­­nja i pristupa elektroničkim imenicima.

LDAP elektronički imenici mogu biti sadržajno ograničeni za jedan sustav certificira­­­­­nja.

Svaki sustav certificira­­­­­nja mora osigurati pros­­­­­ljeđiva­­­­­nje upita u elektroničke imenike drugih sustava certificira­­­­­nja. Pros­­­­­ljeđiva­­­­­nje upita može se provoditi uporabom vlastitog elektroničkog imenika ili usmjerava­­­­­njem upita davate­­­­­lju imeničkih usluga koji za ­­­­­nje­ga vodi elektronički imenik.

Poveziva­­­­­nje elektroničkih imenika koji koriste obrazac LDAP mora se provoditi primjenom obrasca LDUP (LDAP Duplication/Replication/Update Protocol) putem dva teme­­­­­ljna modula:

– Replication Information Model:2001

– Replication Update Protocol:2001.

Poveziva­­­­­nje elektroničkih imenika koji koriste obrazac X.500 mora se provoditi primjenom obrasca DISP (Directory Information Shadowing Protocol) putem primjene dogovorene strukture DIT (Directory Information Tree) objedi­­­­­njene obrascima ISO 9594 odnosno X.520:1988 (Selected Attribute Types) i X.521:1988 (Selected Object Classes).

Poveziva­­­­­nje računalnih sustava koji pružaju usluge elektro­nič­kih imenika mora se provoditi primjenom obrasca X.518:1993 kojim se definira obrazac poveziva­­­­­nje DSP (Directory System Protocol).

Članak 30.

Svaki elektronički imenik mora sadržavati dvije skupine podataka:

– jedinični skup podataka o davate­­­­­lju usluga certificira­­­­­nja, ­­­­­nje­govo jednoznačno ime (DN), ­­­­­nje­gov certifikat i podatke o listi opozvanih certifikata

– jedinični skup podataka o potpisniku, ­­­­­nje­govo jednoznačno ime (DN) i ­­­­­nje­gov certifikat.

VI. ZAVRŠNE ODREDBE

Članak 31.

Ovaj Pravilnik stupa na snagu danom objave u »Narodnim novinama« i ostaje na snazi najdu­­­­­lje dvije godine od dana stupa­­­­­nja na snagu.

Klasa: 011-02/02-01/19
Urbroj: 533-03/353-02-1
Zagreb, 19. srp­­­­­nja 2002.

Ministar znanosti i tehnologije
prof. dr. sc. Hrvoje Kra­­­­­ljević, v. r.