## Pravilnik o tehničkim pravilima i uvjetima povezivanja sustava certificiranja elektroničkih potpisa

### NN 89/2002 (25.7.2002.), Pravilnik o tehničkim pravilima i uvjetima povezivanja sustava certificiranja elektroničkih potpisa

# MINISTARSTVO ZNANOSTI I TEHNOLOGIJE

1472

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.

Pravilnik, NN 89/2002-1472