KAZALO
1.Uvod9
1.1Pregled in področje uporabe te politike9
1.2Opredelitve pojmov in kratice11
1.3Udeleženci infrastrukture javnih ključev (PKI)13
1.3.1Uvod13
1.3.2Organ za politiko digitalnih potrdil C-ITS16
1.3.3Upravljavec seznama zaupanja vrednih potrdil17
1.3.4Pooblaščeni revizor PKI17
1.3.5Kontaktna točka C-ITS (CPOC)17
1.3.6Operativne vloge18
1.4Uporaba potrdil18
1.4.1Veljavna področja uporabe18
1.4.2Meje odgovornosti19
1.5Upravljanje politike digitalnih potrdil19
1.5.1Posodabljanje izjav CPS overiteljev digitalnih potrdil, navedenih v ECTL19
1.5.2Postopki odobritve CPS20
2Objave in odgovornosti glede repozitorija20
2.1Metode za objavo informacij o potrdilih20
2.2Čas ali pogostost objavljanja21
2.3Repozitoriji21
2.4Nadzor nad dostopom do repozitorijev21
2.5Objava informacij o potrdilih22
2.5.1Objava informacij o potrdilih s strani TLM22
2.5.2Objava informacij o potrdilih s strani izdajatelja digitalnih potrdil (CA)22
3Preverjanje istovetnosti in verodostojnosti23
3.1Določanje imen23
3.1.1Vrste imena23
3.1.1.1Imena za TLM, korenske CA, EA, AA23
3.1.1.2Imena za končne subjekte23
3.1.1.3Identifikacija potrdil23
3.1.2Zahteva za smiselnost imen23
3.1.3Uporaba anonimnih imen ali psevdonimov končnih subjektov23
3.1.4Pravila za razlago različnih oblik imen23
3.1.5Enoličnost imen24
3.2Začetno preverjanje istovetnosti24
3.2.1Metoda za dokazovanje imetništva zasebnega ključa24
3.2.2Preverjanje verodostojnosti organizacije24
3.2.2.1Preverjanje verodostojnosti organizacije korenskega CA24
3.2.2.2Preverjanje verodostojnosti organizacije TLM25
3.2.2.3Preverjanje verodostojnosti organizacije podrejenega CA25
3.2.2.4Preverjanje verodostojnosti organizacije naročnika končnega subjekta26
3.2.3Preverjanje verodostojnosti posameznega subjekta26
3.2.3.1Preverjanje verodostojnosti posameznega subjekta TLM/CA26
3.2.3.2Preverjanje verodostojnosti naročnika postaje C-ITS27
3.2.3.3Preverjanje verodostojnosti postaje C-ITS27
3.2.4Nepreverjeni podatki o naročniku27
3.2.5Preverjanje pooblastil27
3.2.5.1Preverjanje TLM, korenskega CA, EA, AA27
3.2.5.2Preverjanje naročnikov postaje C-ITS28
3.2.5.3Preverjanje postaj C-ITS28
3.2.6Merila za medsebojno povezovanje28
3.3Istovetnost in verodostojnost pri zahtevkih za obnovo28
3.3.1Istovetnost in verodostojnost pri rutinskih zahtevkih za obnovo28
3.3.1.1Potrdila TLM28
3.3.1.2Potrdila korenskega CA28
3.3.1.3Podaljšanje ali obnova potrdila EA/AA28
3.3.1.4Poverilnice za pridobitev potrdila končnih subjektov29
3.3.1.5Potrdila o avtorizaciji končnih subjektov29
3.3.2Preverjanje istovetnosti in verodostojnosti pri zahtevkih za obnovo po preklicu29
3.3.2.1Potrdila CA29
3.3.2.2Poverilnice za pridobitev potrdila končnih subjektov29
3.3.2.3Zahtevki končnih subjektov za avtorizacijo29
3.4Preverjanje istovetnosti in verodostojnosti pri zahtevku za preklic29
3.4.1Potrdila korenskega CA/EA/AA29
3.4.2Poverilnica za pridobitev potrdila postaje C-ITS30
3.4.3Potrdilo o avtorizaciji postaje C-ITS30
4Zahteve za upravljanje s potrdili skozi življenjski cikel30
4.1Prošnja za potrdilo30
4.1.1Kdo lahko vloži prošnjo za potrdilo30
4.1.1.1Korenski CA30
4.1.1.2TLM31
4.1.1.3EA in AA31
4.1.1.4Postaja C-ITS31
4.1.2Postopek za pridobitev potrdila in odgovornosti31
4.1.2.1Korenski CA31
4.1.2.2TLM32
4.1.2.3EA in AA32
4.1.2.4Postaja C-ITS32
4.2Obdelava prošnje za potrdilo33
4.2.1Postopek preverjanja istovetnosti in verodostojnosti33
4.2.1.1Postopek preverjanja istovetnosti in verodostojnosti korenskih CA33
4.2.1.2Preverjanje istovetnosti in verodostojnosti TLM33
4.2.1.3Preverjanje istovetnosti in verodostojnosti EA in AA33
4.2.1.4Preverjanje istovetnosti in verodostojnosti naročnika EE34
4.2.1.5Potrdila o avtorizaciji34
4.2.2Odobritev ali zavrnitev prošenj za potrdilo34
4.2.2.1Odobritev ali zavrnitev potrdil korenskega CA34
4.2.2.2Odobritev ali zavrnitev potrdila TLM34
4.2.2.3Odobritev ali zavrnitev potrdil EA in AA34
4.2.2.4Odobritev ali zavrnitev EC34
4.2.2.5Odobritev ali zavrnitev AT35
4.2.3Čas za obdelavo prošnje za potrdilo35
4.2.3.1Prošnja za potrdilo korenskega CA35
4.2.3.2Prošnja za potrdilo TLM35
4.2.3.3Prošnja za potrdilo EA in AA35
4.2.3.4Prošnja za EC35
4.2.3.5Prošnja za AT35
4.3Izdaja potrdila35
4.3.1Postopek CA pri izdaji potrdila35
4.3.1.1Izdajanje potrdil korenskega CA35
4.3.1.2Izdaja potrdil TLM36
4.3.1.3Izdaja potrdil EA in AA36
4.3.1.4Izdaja EC36
4.3.1.5Izdaja AT36
4.3.2Obvestilo o izdaji potrdil, ki ga CA pošlje naročniku36
4.4Prevzem potrdila37
4.4.1Izvedba prevzema potrdila37
4.4.1.1Korenski CA37
4.4.1.2TLM37
4.4.1.3EA in AA37
4.4.1.4Postaja C-ITS37
4.4.2Objava potrdila37
4.4.3Obvestilo o izdaji potrdila37
4.5Uporaba para ključev in potrdila37
4.5.1Uporaba zasebnega ključa in potrdila37
4.5.1.1Uporaba zasebnega ključa in potrdila za TLM37
4.5.1.2Uporaba zasebnega ključa in potrdil za korenske CA37
4.5.1.3Uporaba zasebnega ključa in potrdila za EA in AA37
4.5.1.4Uporaba zasebnega ključa in potrdila za končni subjekt38
4.5.2Uporaba javnega ključa in potrdila odvisne strani38
4.6Podaljšanje potrdila38
4.7Obnova potrdila (re-key)38
4.7.1Razlogi za obnovo potrdila38
4.7.2Kdo lahko zahteva obnovo38
4.7.2.1Korenski CA38
4.7.2.2TLM38
4.7.2.3EA in AA38
4.7.2.4Postaja C-ITS39
4.7.3Postopek obnove39
4.7.3.1Potrdilo TLM39
4.7.3.2Potrdilo korenskega CA39
4.7.3.3Potrdila EA in AA39
4.7.3.4Potrdila postaje C-ITS40
4.8Sprememba potrdila40
4.9Preklic in začasna razveljavitev potrdila40
4.10Preverjanje statusa potrdila40
4.10.1Operativne značilnosti40
4.10.2Razpoložljivost storitev40
4.10.3Druge možnosti40
4.11Prekinitev razmerja med imetnikom in izdajateljem40
4.12Hranjenje kopij zasebnih ključev pri zunanjih subjektih in povrnitev40
4.12.1Naročnik40
4.12.1.1Kateri par ključev se lahko hrani pri zunanjih subjektih40
4.12.1.2Kdo lahko vloži zahtevek za povrnitev40
4.12.1.3Postopek povrnitve in odgovornosti pri njem40
4.12.1.4Preverjanje istovetnosti in verodostojnosti40
4.12.1.5Odobritev ali zavrnitev zahtevkov za povrnitev40
4.12.1.6Postopka KEA in KRA med povrnitvijo para ključev41
4.12.1.7Razpoložljivost KEA in KRA41
4.12.2Ovijanje ključa seje ter politike in prakse povrnitve41
5.Upravljanje in varnostni nadzor infrastrukture41
5.1Fizično varovanje41
5.1.1Lokacija in zgradba overitelja41
5.1.1.1Korenski CA, CPOC, TLM41
5.1.1.2EA/AA42
5.1.2Fizični dostop42
5.1.2.1Korenski CA, CPOC, TLM42
5.1.2.2EA/AA43
5.1.3Napajanje in prezračevanje43
5.1.4Zaščita pred poplavo43
5.1.5Zaščita pred požari44
5.1.6Hramba nosilcev podatkov44
5.1.7Odstranjevanje odpadkov44
5.1.8Hramba na oddaljeni lokaciji44
5.1.8.1Korenski CA, CPOC in TLM44
5.1.8.2EA/AA45
5.2Postopkovni nadzor45
5.2.1Zaupanja vredne vloge45
5.2.2Število oseb za posamezne vloge45
5.2.3Preverjanje istovetnosti in verodostojnosti za opravljanje posameznih vlog46
5.2.4Nezdružljivost vlog46
5.3Nadzor nad osebjem47
5.3.1Potrebne kvalifikacije in izkušnje osebja ter njegova primernost47
5.3.2Preverjanje primernosti osebja47
5.3.3Usposabljanje osebja48
5.3.4Zahteve za redna ponovna usposabljanja48
5.3.5Menjava nalog48
5.3.6Sankcije za nedovoljena dejanja48
5.3.7Zahteve za zunanje izvajalce49
5.3.8Dostop osebja do dokumentacije49
5.4Vodenje dnevnika beleženih dogodkov49
5.4.1Vrste dogodkov, ki jih mora vsak CA zabeležiti in o njih poročati49
5.4.2Pogostost pregledov dnevnikov beleženih dogodkov50
5.4.3Čas hrambe dnevnikov beleženih dogodkov50
5.4.4Zaščita dnevnikov beleženih dogodkov51
5.4.5Varnostne kopije dnevnikov beleženih dogodkov51
5.4.6Zbiranje podatkov za dnevnike beleženih dogodkov (notranji ali zunanji)51
5.4.7Obveščanje povzročitelja dogodka51
5.4.8Ocena ranljivosti51
5.5Arhiviranje podatkov52
5.5.1Vrste arhiviranih podatkov52
5.5.2Čas hrambe53
5.5.3Zaščita arhiviranih podatkov53
5.5.4Varnostno kopiranje arhiviranih podatkov53
5.5.5Zahteva za časovno žigosanje54
5.5.6Način zbiranja arhiviranih podatkov (notranji ali zunanji)54
5.5.7Postopek za dostop do arhiviranih podatkov in njihovo preverjanje54
5.6Zamenjava ključa za elemente modela zaupanja C-ITS54
5.6.1TLM54
5.6.2Korenski CA54
5.6.3Potrdilo EA/AA54
5.6.4Revizor55
5.7Okrevalni načrt55
5.7.1Postopek v primeru vdorov in zlorabe55
5.7.2Postopek v primeru okvare strojne in programske opreme in/ali podatkov56
5.7.3Postopek v primeru ogroženega zasebnega ključa izdajatelja56
5.7.4Zmogljivosti za neprekinjeno poslovanje po nesreči56
5.8Prenehanje delovanja in prenos57
5.8.1TLM57
5.8.2Korenski CA57
5.8.3EA/AA58
6.Tehnične varnostne zahteve58
6.1Ustvaritev in namestitev para ključev58
6.1.1TLM, korenski CA, EA, AA58
6.1.2EE – premična postaja C-ITS58
6.1.3EE – nepremična postaja C-ITS59
6.1.4Kriptografske zahteve59
6.1.4.1Algoritem in dolžina ključa – podpisni algoritmi59
6.1.4.2Algoritem in dolžina ključa – algoritmi za šifriranje podatkov za pridobitev potrdila in avtorizacijo60
6.1.4.3Kriptografska prilagodljivost61
6.1.5Varna hramba zasebnih ključev61
6.1.5.1Raven korenskega CA, podrejenega CA in TLM61
6.1.5.2Končni subjekt62
6.1.6Varnostna kopija zasebnega ključa63
6.1.7Uničenje zasebnega ključa63
6.2Aktivacijski podatki63
6.3Varnostne zahteve za računalniško opremo63
6.4Tehnični nadzor življenjskega cikla63
6.5Varnostna kontrola računalniške mreže63
7.Profil potrdil, CRL in CTL63
7.1Profil potrdil63
7.2Veljavnost potrdil64
7.2.1Psevdonimna potrdila65
7.2.2Potrdila o avtorizaciji za nepremične postaje C-ITS65
7.3Preklic potrdil65
7.3.1Preklic potrdil CA, EA in AA65
7.3.2Preklic poverilnice za pridobitev potrdila66
7.3.3Preklic potrdil o avtorizaciji66
7.4Seznam preklicev potrdil66
7.5Evropski seznam zaupanja vrednih potrdil66
8Revidiranje skladnosti in ostali pregledi66
8.1Vsebina nadzora in podlaga zanj66
8.2Pogostost nadzora67
8.3Identiteta in usposobljenost revizorja67
8.4Odnos med revizorjem in revidiranim subjektom67
8.5Ukrepi kot posledica ugotovljenih nepravilnosti68
8.6Objava rezultatov68
9.Druge določbe68
9.1Pristojbine68
9.2Finančna odgovornost69
9.3Zaupnost poslovnih podatkov69
9.4Načrt varovanja osebnih podatkov69
10.Reference69
PRILOGA III
1.Uvod
1.1.Pregled in področje uporabe te politike
S to politiko digitalnih potrdil se opredeljuje model zaupanja na podlagi infrastrukture javnih ključev (Public Key Infrastructure, PKI) v okviru splošnega sistema EU za upravljanje varnostnih poverilnic C-ITS (EU CCMS). V njej so opredeljene zahteve za upravljanje potrdil javnega ključa za aplikacije C-ITS s strani izdajateljev in njihovo uporabo s strani končnih subjektov v Evropi. PKI je na najvišji ravni sestavljen iz nabora korenskih CA, ki so „omogočeni“, ker jih je upravljavec seznama zaupanja vrednih potrdil („trust list manager“, TLM) vnesel v evropski seznam zaupanja vrednih potrdil („European certificate trust list“, ECTL), ki ga izdaja in objavlja osrednji subjekt TLM (gl. oddelka 1.2 in 1.3).
Ta politika je zavezujoča za vse subjekte, ki so udeleženi v zaupanja vrednem sistemu C-ITS v Evropi. Pomaga pri ocenjevanju stopnje zaupanja, ki jo lahko ugotovi kateri koli prejemnik sporočila, avtentificiranega s potrdilom končnega subjekta PKI. Da bi omogočila oceno zaupanja v potrdila, ki jih daje na razpolago EU CCMS, vsebuje sklop zavezujočih zahtev za delovanje centralnega subjekta TLM ter sestavljanje in upravljanje ECTL. Ta dokument zato določa naslednje vidike v zvezi z ECTL:
·preverjanje istovetnosti in verodostojnosti subjektov, ki prevzemajo vloge PKI za TLM, vključno z izjavo o pooblastilih, dodeljenih vsaki vlogi;
·minimalne zahteve za lokalne varnostne prakse za TLM, vključno s fizičnim nadzorom, nadzorom osebja in postopkovnim nadzorom;
·minimalne zahteve za prakse tehnične varnosti za TLM, vključno z varnostjo računalnikov, omrežja in nadzorom nad zasnovo kriptografskega modula;
·minimalne zahteve za prakse delovanja TLM, vključno z registracijo novih potrdil korenskega CA, začasno ali trajno deregistracijo obstoječih vključenih korenskih CA, ter objavo in razširjanje posodobitev ECTL;
·profil ECTL, vključno z vsemi obveznimi in neobveznimi podatkovnimi polji v ECTL, kriptografske algoritme, ki se uporabljajo, točen format ECTL in priporočila za obdelavo ECTL;
·upravljanje potrdil ECTL skozi njihov življenjski cikel, vključno z razdeljevanjem, aktivacijo, potekom in preklicem potrdil ECTL;
·po potrebi upravljanje preklica zaupanja korenskega CA.
Ker verodostojnost ECTL ni odvisna le od samega ECTL, temveč v veliki meri tudi od korenskih CA, ki sestavljajo PKI, in njihovih podrejenih CA, so v tej politiki določene tudi minimalne zahteve, ki so obvezne za vse sodelujoče CA (korenske CA in podrejene CA). Področja zahtev so:
·identifikacija in preverjanje verodostojnosti subjektov, ki se jim podeljujejo vloge PKI (npr. varnostni uradnik, uradnik za zasebnost, varnostni administrator, upravljavec imenika in končni uporabnik), vključno z opisom nalog, odgovornosti, obveznosti in pooblastil, povezanih z vsako vlogo;
·upravljanje ključev, vključno s sprejemljivimi in obveznimi algoritmi za podpis potrdila in podpis podatkov, ter trajanje veljavnosti potrdila;
·minimalne zahteve za lokalne varnostne prakse, vključno s fizičnim nadzorom, nadzorom osebja in postopkov;
·minimalne zahteve za prakse tehnične varnosti, kot so varnost računalnikov, omrežja in nadzor nad zasnovo kriptografskega modula;
·minimalne zahteve za prakse delovanja CA, EA, AA in končnih subjektov, vključno z vidiki registracije, deregistracije (tj. umika s seznama), preklica, ogroženosti ključa, zavrnitve iz določenega razloga, posodobitve potrdila, prakse revidiranja in nerazkrivanje podatkov v zvezi z zasebnostjo;
·potrdilo in profil CRL, vključno s formati, sprejemljivimi algoritmi, obveznimi in neobveznimi podatkovnimi polji in njihovimi veljavnimi razponi vrednosti ter načinom, na katerega naj bi preveritelji obdelovali potrdila;
·redno spremljanje, poročanje, opozarjanje in ponovno vzpostavljanje nalog subjektov modela zaupanja C-ITS, da bi omogočili varno delovanje, tudi v primerih neprimernega ravnanja.
Poleg teh minimalnih zahtev se lahko subjekti, ki vodijo korenske in podrejene CA, odločijo za svoje lastne dodatne zahteve in jih navedejo v ustreznih izjavah o praksi izdajanja potrdil (CPS), če te zahteve niso v nasprotju z zahtevami potrditvene politike. Za več podatkov o preverjanju in objavljanju CPS gl. oddelek 1.5.
V CP je navedeno tudi, za katere namene se lahko uporabljajo korenski CA, podrejeni CA in potrdila, ki jih izdajajo. Določa obveznosti, ki jih imajo:
·TLM;
·korenski CA, katerega potrdila so vpisana v ECTL;
·podrejeni CA (EA in AA) korenskega CA;
·vsak član ali organizacija, ki je odgovorna za katerega od subjektov modela zaupanja C-ITS oziroma ga upravlja.
CP opredeljuje tudi obveznosti, ki jih imajo:
·TLM;
·korenski CA, katerega potrdila so vpisana v ECTL;
·podrejeni CA, ki ga je certificiral korenski CA;
·vsi končni subjekti;
·organizacija članica, ki je odgovorna za katerega od subjektov modela zaupanja C-ITS oziroma ga upravlja.
V CP so določene tudi zahteve glede dokumentiranja omejitev obveznosti v CPS vsakega korenskega CA, katerega potrdila so navedena v seznamu ECTL.
Ta CP je skladna s potrditveno politiko in okvirom praks potrjevanja, ki jih je sprejela delovna skupina za internetsko inženirstvo (IETF) [3].
1.2.Opredelitve pojmov in kratice
Uporabljajo se opredelitve pojmov iz [2], [3] in [4].
AA
|
avtorizacijski organ
|
AT
|
potrdilo o avtorizaciji
|
CA
|
overitelj digitalnih potrdil
|
CP
|
potrditvena politika
|
CPA
|
organ za politiko digitalnih potrdil C-ITS
|
CPOC
|
kontaktna točka C-ITS
|
CPS
|
izjava o praksi izdajanja potrdil
|
CRL
|
seznam preklicev potrdil
|
EA
|
organ za pridobitev potrdila
|
EC
|
poverilnica za pridobitev potrdila
|
ECIES
|
integrirana shema šifriranja z eliptično krivuljo
|
EE
|
končni subjekt (tj. postaja C-ITS)
|
ECTL
|
evropski seznam zaupanja vrednih potrdil
|
EU CCMS
|
sistem EU za upravljanje varnostnih poverilnic C-ITS
|
GDPR
|
splošna uredba o varstvu podatkov
|
HSM
|
varnostni modul strojne opreme
|
PKI
|
infrastruktura javnih ključev
|
RA
|
registracijski organ
|
podrejeni CA
|
EA in AA
|
TLM
|
upravljavec seznama zaupanja vrednih potrdil
|
Slovarček
prosilec
|
Fizična ali pravna oseba, ki zaprosi za izdajo (ali podaljšanje) potrdila. Ko je ustvarjeno začetno potrdilo (inicializacija), se namesto izraza „prosilec“ uporablja izraz „naročnik“.
Pri potrdilih, izdanim končnim subjektom, je naročnik (prosilec za potrdilo) subjekt, ki nadzoruje ali upravlja končni subjekt, ki mu je bilo izdano potrdilo, tudi če zahtevek dejansko vlaga končni subjekt.
|
avtorizacijski organ
|
Izraz „avtorizacijski organ“ (AA) v tem dokumentu ne pomeni samo posebne funkcije AA, ampak tudi pravni in/ali operativni subjekt, ki ga upravlja.
|
overitelj digitalnih potrdil
|
Overitelj digitalnih potrdil (CA) je skupen izraz za korenskega overitelja digitalnih potrdil, organ za pridobitev potrdila in avtorizacijski organ.
|
model zaupanja C-ITS
|
Ta model zaupanja C-ITS je odgovoren za vzpostavitev zaupanja med postajami C-ITS. Izvaja se z uporabo PKI, sestavljene iz korenskih CA, CPOC, TLM, EA, AA in varnega omrežja.
|
kriptografska prilagodljivost
|
Sposobnost subjektov modela zaupanja C-ITS, da CPO prilagodijo spremembam okolja ali novim prihodnjim zahtevam, npr. tako, da sčasoma spremenijo kriptografske algoritme in dolžino ključa.
|
kriptografski modul
|
Zavarovan element na podlagi strojne opreme, v katerem se ustvarjajo in/ali shranjujejo ključi, ustvarjajo naključne številke in podpisujejo ali šifrirajo podatki.
|
organ za pridobitev potrdila
|
Izraz „organ za pridobitev potrdila“ (EA) v tem dokumentu ne pomeni samo posebne funkcije EA, ampak tudi pravni in/ali operativni subjekt, ki ga upravlja.
|
Udeleženci infrastrukture javnih ključev (PKI)
|
Subjekti modela zaupanja C-ITS, tj. TLM, korenski CA, EA, AA in postaje C-ITS.
|
obnova
|
|
repozitorij
|
Repozitorij za hrambo potrdil in podatkov o potrdilih, ki jih dajo na razpolago subjekti modela zaupanja C-ITS, v skladu z opredelitvijo v oddelku 2.3.
|
korenski overitelj potrdil
|
Izraz „korenski overitelj potrdil“ (CA) v tem dokumentu ne pomeni samo posebne funkcije CA, ampak tudi pravni in/ali operativni subjekt, ki ga upravlja.
|
subjekt
|
Fizična oseba, naprava, sistem, enota ali pravna oseba, ki je v potrdilu navedena kot subjekt, tj. naročnik ali naprava, ki jo naročnik nadzoruje ali upravlja.
|
naročnik
|
Fizična ali pravna oseba, za katero se izda potrdilo in ki ga pravno zavezuje naročniška pogodba ali pogodba o uporabi.
|
naročniška pogodba
|
Pogodba med CA in prosilcem/naročnikom, v kateri so določene pravice in odgovornosti pogodbenih strank.
|
1.3.Udeleženci infrastrukture javnih ključev (PKI)
1.3.1.Uvod
Udeleženci PKI imajo v PKI vlogo, opredeljeno v tukaj predstavljeni politiki. Če ni izrecno prepovedano, lahko udeleženec prevzame več vlog hkrati. Hkratno prevzemanje določenih vlog se lahko prepove, da bi se izognili nasprotju interesov ali zagotovili ločitev nalog.
Udeleženci lahko svoje vloge tudi deloma prenesejo na druge subjekte s pogodbo o opravljanju storitev. Npr. če se podatki o statusu preklica podajajo z uporabo CRL, je CA sicer tudi izdajatelj CRL, vendar lahko odgovornost za izdajanje CRL prenese na drugega subjekta.
Vloge PKI so sestavljene iz:
·avtoritativnih vlog, tj. vsaka vloga se tvori enolično;
·operativne vloge, tj. vloge, ki se tvorijo za enega ali več subjektov.
Npr. korenski CA lahko uporablja komercialni subjekt, skupina splošnega interesa, nacionalna organizacija in/ali evropska organizacija.
Na sliki 1 je prikazana arhitektura modela zaupanja C-ITS na podlagi [2]. Arhitektura je tukaj opisana na kratko, glavni elementi pa so podrobneje opisani v oddelkih 1.3.2–6.
CPA imenuje TLM, ki je tako za vse udeležence PKI zaupanja vreden subjekt. CPA odobri delovanje korenskega CA in potrdi, da TLM lahko zaupa korenskim CA. TLM izda ECTL, na podlagi katerega vsi udeleženci PKI zaupajo odobrenim korenskim CA. Korenski CA izda potrdila EA in AA ter tako zagotovi verodostojnost njunemu delovanju. EA pošiljajoči in posredovalni postaji C-ITS (kot končnima subjektoma) izda potrdilo o pridobitvi in tako zagotovi verodostojnost njunega delovanja. AA izda AT postajam C-ITS, ker zaupa EA.
Sprejemna in posredovalna postaja C-ITS (kot posredovalna stran) lahko zaupa drugim postajam C-ITS, ker je AT izdal AA, ki mu zaupa korenski CA, temu pa zaupata TLM in CPA.
Slika 1 opisuje samo raven korenskega CA modela zaupanja C-ITS. Podrobnosti o nižjih ravneh so navedene v naslednjih oddelkih te politike digitalnih potrdil ali politikah digitalnih potrdil posameznih korenskih CA.
Na sliki 2 je prikazan pregled tokov informacij med udeleženci PKI. Z zelenimi pikami so označeni tokovi, za katere je potrebna komunikacija stroja s strojem. Tokovi informacij, označeni z rdečo barvo, imajo opredeljene varnostne zahteve.
Model zaupanja C-ITS temelji na arhitekturi z več korenskimi CA, v kateri se potrdila korenskih CA redno oddajajo (kot je prikazano spodaj) osrednji kontaktni točki (CPOC) preko varnega protokola (npr. vezna potrdila), ki ga določi CPOC.
Korenski CA lahko upravlja državna ali zasebna organizacija. Arhitektura modela zaupanja C-ITS vsebuje vsaj en korenski CA (korenski CA EU na enaki ravni kot drugi korenski CA). Na korenski CA EU prenesejo pooblastila vsi subjekti, ki sodelujejo v modelu zaupanja C-ITS in ki ne želijo vzpostaviti svojega lastnega korenskega CA. CPOC prejeta potrdila korenskega CA posreduje TLM, ki je odgovoren za zbiranje in podpisovanje seznama potrdil korenskega CA in za vračanje teh potrdil CPOC, tako da so javno dostopna vsakomur (gl. nadaljevanje).
Razmerja zaupanja med enotami v modelu zaupanja C-ITS so opisana v naslednjih slikah, preglednicah in oddelkih.
Slika 1: arhitektura modela zaupanja C-ITS
Slika 2: tokovi informacij v modelu zaupanja C-ITS
Tok ID
|
pošiljatelj
|
prejemnik
|
vsebina
|
sklic
|
(1).
|
CPA
|
TLM
|
korenski CA odobri zahtevek
|
8.
|
(2).
|
CPA
|
TLM
|
informacija o preklicu korenskega CA
|
8.5
|
(3).
|
CPA
|
korenski CA
|
posodobitve CP
|
1.5
|
(4).
|
CPA
|
korenski CA
|
odobritev/zavrnitev prošnje za korenski CA ali zahteve za spremembo CPS ali revizijski postopek.
|
8.5, 8.6
|
(5).
|
TLM
|
CPA
|
obvestilo o spremembi ECTL
|
4, 5.8.1
|
(6).
|
TLM
|
CPOC
|
potrdilo TLM
|
4.4.2
|
(7).
|
TLM
|
CPOC
|
ECTL
|
4.4.2
|
(8).
|
CPOC
|
TLM
|
informacije o potrdilu korenskega CA
|
4.3.1.1
|
(9).
|
CPOC
|
TLM
|
preklic potrdila korenskega CA
|
7.3
|
(10).
|
CPOC
|
vsi končni subjekti
|
potrdilo TLM
|
4.4.2
|
(11).
|
korenski CA
|
CPOC
|
informacije o potrdilu korenskega CA
|
4.3.1.1
|
(12).
|
korenski CA
|
CPOC
|
preklic potrdila korenskega CA
|
7.3
|
(13).
|
korenski CA
|
revizor
|
nalog za revizijo
|
8.
|
(14).
|
korenski CA
|
CPA
|
prošnja za korenski CA – začetni zahtevek
|
4.1.2.1
|
(15).
|
korenski CA
|
CPA
|
prošnja za korenski CA – spremembe CPS
|
1.5.1
|
(16).
|
korenski CA
|
CPA
|
prošnja za korenski CA – revizijsko poročilo
|
8.6
|
(17).
|
korenski CA
|
CPA
|
poročilo korenskega CA o incidentih, vključno s preklicem podrejenega CA (EA, AA)
|
Priloga III, 7.3.1
|
(18).
|
korenski CA
|
EA
|
odgovor glede potrdila EA
|
4.2.2.3
|
(19).
|
korenski CA
|
AA
|
odgovor glede potrdila AA
|
4.2.2.3
|
(20).
|
korenski CA
|
vsi
|
potrdilo EA/AA, CRL
|
4.4.2
|
(21).
|
EA
|
korenski CA
|
zahtevek EA za potrdilo
|
4.2.2.3
|
(22).
|
EA
|
Postaja C-ITS
|
odgovor glede poverilnice za pridobitev potrdila
|
4.3.1.4
|
(23).
|
EA
|
AA
|
odgovor glede avtorizacije
|
4.2.2.5
|
(24).
|
AA
|
korenski CA
|
zahtevek AA za potrdilo
|
4.2.2.3
|
(25).
|
AA
|
EA
|
zahtevek za avtorizacijo
|
4.2.2.5
|
(26).
|
AA
|
Postaja C-ITS
|
odgovor glede potrdila o avtorizaciji
|
4.3.1.5
|
(27).
|
EA
|
korenski CA
|
vložitev zahtevka
|
4.1.2.3
|
(28).
|
AA
|
korenski CA
|
vložitev zahtevka
|
4.1.2.3
|
(29).
|
korenski CA
|
EA
|
odgovor
|
4.12 in 4.2.1
|
(30).
|
korenski CA
|
AA
|
odgovor
|
4.12 in 4.2.1
|
(31).
|
Postaja C-ITS
|
EA
|
zahtevek za poverilnico za pridobitev potrdila
|
4.2.2.4
|
(32).
|
Postaja C-ITS
|
AA
|
zahtevek za potrdilo o avtorizaciji
|
4.2.2.5
|
(33).
|
proizvajalec/upravljavec
|
EA
|
registracija
|
4.2.1.4
|
(34).
|
proizvajalec/upravljavec
|
EA
|
deaktivacija
|
7.3
|
(35).
|
EA
|
proizvajalec/upravljavec
|
odgovor
|
4.2.1.4
|
(36).
|
revizor
|
korenski CA
|
poročilo
|
8.1
|
(37).
|
vsi
|
CPA
|
zahtevek za spremembo CP
|
1.5
|
(38).
|
TLM
|
CPA
|
prošnja
|
4.1.2.2
|
(39).
|
CPA
|
TLM
|
odobritev/zavrnitev
|
4.1.2.2
|
(40).
|
TLM
|
CPA
|
revizijsko poročilo
|
4.1.2.2
|
Preglednica 1:
podroben opis tokov informacij v modelu zaupanja C-ITS
1.3.2.Organ za politiko digitalnih potrdil C-ITS
(1)Organ za politiko digitalnih potrdil (CPA) C-ITS sestavljajo predstavniki javnih in zasebnih zainteresiranih strani (npr. države članice, proizvajalci vozil itd.), ki sodelujejo v modelu zaupanja C-ITS. Odgovoren je za dve podvlogi:
(1)upravljanje politike digitalnih potrdil, kamor spada med drugim:
·odobritev sedanje CP in prihodnjih zahtev za spremembo CP;
·odločanje o pregledu zahtev in priporočil za spremembo CP, ki jih podajo drugi udeleženci ali subjekti PKI;
·odločanje o objavi novih različic CP;
(2)upravljanje avtorizacij PKI, kamor spada med drugim:
·opredeljevanje postopkov odobritve CPS in revizije CA (s skupnim izrazom „postopki odobritve CA“), odločanje o njih in njihova objava;
·dovoljenje CPOC za delovanje in redno poročanje;
·dovoljenje TLM za delovanje in redno poročanje;
·odobritev CPS korenskega CA, če je v skladu s skupno in veljavno CP;
·pregled revizijskih poročil pooblaščenega revizorja PKI za vse korenske CA;
·obveščanje TLM o seznamu odobrenih ali neodobrenih korenskih CA in njihovih potrdil na podlagi prejetih poročil o odobritvi korenskih CA in rednih poročil o delu.
(2)Pooblaščeni predstavnik CPA je odgovoren za preverjanje verodostojnosti pooblaščenega predstavnika TLM in odobritev prošnje za pridobitev potrdila TLM. CPA je odgovoren za izdajo dovoljenja za delovanje TLM, kot je navedeno v tem oddelku.
1.3.3.Upravljavec seznama zaupanja vrednih potrdil (TLM)
(3)TLM je subjekt, ki ga imenuje CPA.
(4)Odgovoren je za:
·delovanje ECTL, skladno s skupno veljavno CP, in redno poročanje CPA o dejavnostih za celotno varno delovanje modela zaupanja C-ITS;
·prejemanje potrdil korenskega CA od CPOC;
·vključitev potrdil korenskega CA v ECTL ali izključitev iz njega na podlagi obvestila CPA;
·podpisovanje ECTL;
·redno in pravočasno posredovanje ECTL kontaktnim točkam.
1.3.4.Pooblaščeni revizor PKI
(5)Pooblaščeni revizor PKI je odgovoren za:
·izvedbo in organizacijo revizij korenskih CA, TLM in podrejenih CA;
·pošiljanje revizijskega poročila (o začetni ali redni reviziji) CPA v skladu z zahtevami iz oddelka 8. Revizijsko poročilo mora vsebovati priporočila pooblaščenega revizorja PKI;
·obveščanje subjekta, ki upravlja korenski CA, o (ne)uspeli izvedbi začetne ali redne revizije podrejenih CA.
·ocenjevanje skladnosti CPS s to CP.
1.3.5.Kontaktna točka C-ITS (CPOC)
(6)CPOC je subjekt, ki ga imenuje CPA. Pooblaščeni predstavnik CPA je odgovoren za preverjanje verodostojnosti pooblaščenega predstavnika CPOC in odobritev prošnje za pridobitev potrdila CPOC. CPA je odgovoren za izdajo dovoljenja za delovanje CPOC, kot je navedeno v tem oddelku.
(7)CPOC je odgovoren za:
·učinkovito in hitro vzpostavitev varne komunikacije med vsemi subjekti modela zaupanja C-ITS in prispevanju k njej;
·pregled zahtev in priporočil za postopkovne spremembe, ki jih vložijo drugi udeleženci modela zaupanja (npr. korenski CA);
·posredovanje potrdil korenskega CA upravljavcu seznama zaupanja vrednih potrdil;
·objavo skupnega sidra zaupanja (trenutni javni ključ in vezno potrdilo TLM);
·objavo ECTL.
Podrobna predstavitev ECTL je v oddelku 7.
1.3.6.Operativne vloge
(8)Subjekti, opredeljeni v [2], ki imajo operativno vlogo v skladu z opredelitvijo v RFC 3647:
Funkcionalni element
|
Vloga PKI ([3] in [4])
|
Podrobna vloga ([2])
|
korenski overitelj potrdil
|
CA/RA (registracijski organ)
|
Pošlje EA in AA dokazilo, da lahko izdaja EC ali AT.
|
organ za pridobitev potrdila
|
naročnik korenskega CA / imetnik potrdila EA
CA/RA
|
Preveri verodostojnost postaje C-ITS in ji dovoli dostop do komunikacij ITS
|
avtorizacijski organ
|
naročnik korenskega CA / imetnik potrdila AA
CA/RA
|
Pošlje postaji C-ITS dokazilo o pooblastilu, da lahko uporablja posamezne storitve ITS.
|
pošiljajoča postaja C-ITS
|
zanjo velja potrdilo končnega subjekta (EC)
|
Od EA pridobi pravice dostopa do komunikacij ITS.
Z AA se dogovori o pravicah do zahteve za storitve ITS.
Pošilja enohopna sporočila in sporočila s posredovanjem pri oddajanju.
|
posredujoča postaja C-ITS
|
posrednik / imetnik potrdila EE
|
Prejme sporočilo od pošiljajoče postaje C-ITS in ga po potrebi posreduje sprejemni postaji C-ITS.
|
sprejemna postaja C-ITS
|
posrednik
|
Sprejme oddana sporočila od pošiljajoče ali posredujoče postaje C-ITS.
|
proizvajalec
|
naročnik EA
|
Ob izdelavi namesti informacije, potrebne za upravljanje varnosti v postaji C-ITS.
|
upravljavec
|
naročnik EA/AA
|
Med upravljanjem namesti in posodablja informacije, potrebne za upravljanje varnosti v postaji C-ITS.
|
Preglednica 2: operativne vloge
Opomba: v skladu s [4] se v tej CP uporabljata različna izraza za „naročnika“, ki s CA sklene pogodbo o izdajanju potrdil, in „subjekt“, za katerega se to potrdilo uporablja. Naročniki so vsi subjekti, ki so v pogodbenem razmerju s CA. Subjekti so osebe, za katere velja potrdilo. EA/AA so naročniki in subjekti korenskega CA in lahko vložijo zahtevek za potrdila EA/AA. Postaje C-ITS so subjekti in lahko vložijo zahtevek za potrdilo končnega subjekta.
(9)Registracijski organi:
Vlogo registracijskega organa za končne subjekte opravlja EA. Nove končne subjekte (postaje C-ITS) lahko v EA registrira samo verodostojen in avtoriziran naročnik. Vlogo registracijskega organa za EA in AA opravljajo ustrezni korenski CA.
1.4.Uporaba potrdil
1.4.1.Veljavna področja uporabe
(10)Potrdila, izdana v skladu s to CP, so namenjena za potrjevanje digitalnih podpisov v sodelovalnem okviru komunikacije ITS v skladu z referenčno arhitekturo iz [2].
(11)Profili potrdil v [5] določajo uporabo potrdil za TLM, korenske CA, EA, AA in končne subjekte.
1.4.2.Meje odgovornosti
(12)Potrdila niso niti namenjena niti avtorizirana za uporabo:
·v okoliščinah, ki pomenijo kršitev katerega koli veljavnega zakona, uredbe (npr. splošne uredbe o varstvu podatkov), odloka ali vladne odredbe;
·v okoliščinah, ki pomenijo kršitev pravic drugih;
·ki bi pomenila kršitev te CP ali ustrezne naročniške pogodbe;
·v okoliščinah, v katerih bi njihova uporaba lahko neposredno povzročila smrt, telesno poškodbo ali hudo okoljsko škodo (npr. zaradi napake pri delovanju jedrskih objektov, navigaciji zrakoplovov oziroma komunikaciji z njimi ali v sistemih za nadzor orožja);
·v okoliščinah, ki so v nasprotju s splošnimi cilji večje varnosti v cestnem prometu in učinkovitejšega cestnega prevoza v Evropi.
1.5.Upravljanje politike digitalnih potrdil
1.5.1.Posodabljanje izjav CPS overiteljev digitalnih potrdil, navedenih v ECTL
(13)Vsak korenski CA, naveden v ECTL, objavi svojo CPS, ki mora biti skladna s to politiko. Doda lahko še druge zahteve, vendar poskrbi za to, da so vse zahteve iz te CP ves čas izpolnjene.
(14)Vsak korenski CA, naveden v ECTL, za svoj dokument CPS izvaja ustrezen postopek sprememb. Ključne značilnosti postopka sprememb se zabeležijo v javnem delu CPS.
(15)S postopkom sprememb se zagotovi, da se vse spremembe te CP skrbno preučijo in, če je potrebno za skladnost s CP, kakor je bila spremenjena, se CPS posodobi v roku, določenem v izvedbenem koraku postopka sprememb CP. Postopek sprememb zlasti vključuje postopke sprememb v izrednih razmerah, s katerimi se zagotavlja pravočasna izvedba sprememb CP, pomembnih za varnost.
(16)Postopek sprememb vključuje ustrezne ukrepe, s katerimi se pri vseh spremembah CPS preveri skladnost s CPS. Spremembe CPS se jasno dokumentirajo. Pred začetkom izvajanja nove različice CPS mora njeno skladnost s CP potrditi pooblaščeni revizor PKI.
(17)Korenski CA obvesti CPA o spremembah CPS in pri tem navede vsaj naslednje podatke:
·natančen opis spremembe;
·razlog za spremembo;
·poročilo pooblaščenega revizorja PKI, v katerem je potrjena skladnost s CP;
·kontaktne podatke osebe, odgovorne za CPS;
·predvidene roke za uvedbo.
1.5.2.Postopki odobritve CPS
(18)Bodoči korenski CA pred začetkom delovanja predloži svojo CPS pooblaščenemu revizorju PKI v okviru vloge za revidiranje skladnosti (tok 13) in CPA v odobritev (tok 15).
(19)Bodoči korenski CA predloži spremembe svoje CPS pooblaščenemu revizorju PKI v okviru vloge za revidiranje skladnosti (tok 13) in CPA v odobritev (tok 15), preden te spremembe začnejo učinkovati.
(20)EA/AA svojo CPS ali spremembe svoje CPS predloži korenskemu CA. Korenski CA lahko naroči potrdilo o skladnosti pri nacionalnem organu ali zasebnem subjektu, odgovornem za odobritev EA/AA, kot je opredeljeno v oddelkih 4.1.2 in 8.
(21)Pooblaščeni revizor PKI oceni CPS v skladu z oddelkom 8.
(22)Pooblaščeni revizor PKI o rezultatih ocene CPS poroča v revizijskem poročilu, kot je določeno v oddelku 8.1. CPS se sprejme ali zavrne v okviru sprejetja revizijskega poročila iz oddelkov 8.5 in 8.6.
2.Objave in odgovornosti glede repozitorija
2.1.Metode za objavo informacij o potrdilih
(23)Informacije o potrdilu se lahko v skladu z oddelkom 2.5 objavijo:
·redno ali občasno ali
·na zahtevo katerega od udeleženih subjektov.
V vsakem primeru veljajo različne stopnje nujnosti objave in zato različni roki, toda subjekti morajo biti pripravljeni na obe vrsti ureditve.
(24)Redna objava informacij o potrdilih omogoča določitev skrajnega roka, do katerega se informacije o potrdilih posodobijo za vsa vozlišča omrežja C-ITS. Pogostost objave vseh informacij o potrdilih je določena v oddelku 2.2.
(25)Na zahtevo subjektov, udeleženih v omrežju C-ITS, lahko kateri koli udeleženec začne kadar koli objavljati podatke o potrdilu in, glede na status, zahteva trenutni nabor podatkov o potrdilih, tako da postane popolnoma zaupanja vredno vozlišče omrežja C-ITS. Namen take objave je predvsem seznaniti subjekte s splošnim trenutnim stanjem informacij o potrdilih v omrežji in jim omogočiti, da komunicirajo na podlagi zaupanja do naslednje redne objave informacij.
(26)Pobudo za objavo informacij o potrdilih lahko da tudi en sam korenski CA, in sicer tako, da pošlje posodobljen nabor potrdil vsem „članom naročnikom“ omrežja C-ITS, ki redno prejemajo take informacije. To podpira delovanje CA in jim omogoča, da se obračajo na člane med rednimi in predvidenimi datumi za objavo potrdil.
(27)V oddelku 2.5 so določeni mehanizem in vsi postopki objave potrdil korenskega CA in ECTL.
(28)CPOC objavi potrdila korenskega CA (kot so navedena v ECTL in namenjena javni uporabi), potrdilo TLM in ECTL, ki jih izdaja.
(29)Korenski CA objavijo svoja potrdila EA/AA in svoje CRL ter so sposobni podpirati vse tri tukaj navedene mehanizme, da jih je mogoče objaviti za člane naročnike in odvisne strani, pri tem pa stori vse potrebno za zagotovitev varnega prenosa v skladu z oddelkom 4.
2.2.Čas ali pogostost objavljanja
(30)Zahteve glede rokov objavljanja za potrdila in CRL je treba določiti ob upoštevanju različnih omejitvenih dejavnikov za posamezna vozlišča C-ITS s splošnim ciljem upravljanja „zaupanja vrednega omrežja“ in čimprejšnjega objavljanja posodobitev za vse sodelujoče postaje C-ITS.
·Za varno delovanje omrežja C-ITS je najdaljše možno obdobje rednega objavljanja posodobljenih informacij o potrdilih (npr. spremembe sestave ECTL ali CRL) tri mesece.
·Korenski CA svoja potrdila CA in CRL objavijo čim prej po izdaji.
·Za objavo CRL se uporablja repozitorij korenskega CA.
Poleg tega se v CPS vsakega CA določi rok, do katerega bo potrdilo objavljeno, potem ko ga CA izda.
V tem oddelku je naveden samo čas ali pogostost rednega objavljanja. Sredstva povezljivosti za posodabljanje postaj C-ITS z ECTL in CRL v roku enega tedna od objave (v običajnih pogojih delovanja, npr. pokritosti z omrežjem mobilne telefonije, dejanskega obratovanja vozila) se izvaja v skladu z zahtevami v tem dokumentu.
2.3.Repozitoriji
(31)Zahteve v zvezi s strukturo repozitorijev za shranjevanje potrdil in informacijami, ki jih dajo na razpolago subjekti omrežja C-ITS, so za posamezne subjekte:
·na splošno bi moral vsak korenski CA za objavljanje potrdil za druge udeležence PKI (npr. imeniška storitev na podlagi LDAP) uporabljati repozitorij z informacijami o svojem lastnem trenutno aktivnem potrdilu EA/AA in CRL. Repozitorij vsakega korenskega CA podpira vse potrebne nadzore dostopa (oddelek 2.4) in čase za prenos (oddelek 2.2) za vsako metodo razširjanja informacij v zvezi s C-ITS;
·repozitorij TLM (npr. v katerem so shranjeni ECTL in potrdila TLM, ki jih objavi CPOC) bi moral temeljiti na mehanizmu objavljanja, s katerim bi bilo mogoče za vsako metodo razširjanja zagotoviti čase za prenos, določene v oddelku 2.2.
Zahteve za AA niso opredeljene, a morajo podpirati enake varnostne ravni kot drugi subjekti in morajo biti navedene v njihovi CPS.
2.4.Nadzor nad dostopom do repozitorijev
(32)Zahteve za nadzor dostopa do repozitorijev z informacijami o potrdilih morajo biti skladne vsaj s splošnimi standardi varnega ravnanja s podatki iz standarda ISO/IEC 27001 in z zahtevami iz oddelka 4. Poleg tega upoštevajo potrebno varnost postopka, ki jo je treba pri objavljanju informacij o potrdilih zagotoviti za posamezne korake postopka.
·Sem spada tudi uvedba repozitorija za potrdila TLM in ECTL v TLM/CPOC. Vsak CA ali upravljavec repozitorija izvaja nadzor dostopa za vse subjekte C-ITS in zunanje osebe na vsaj treh različnih ravneh (npr. javna, omejena na subjekte C-ITS, raven korenskega CA), da bi nepooblaščenim subjektom preprečil dodajanje, spreminjanje ali brisanje vpisov v repozitorij.
·Konkretni mehanizmi nadzora za vsak subjekt bi morali biti navedeni v zadevni CPS.
·Pri vsakem korenskem CA bi morala repozitorija EA in AA izpolnjevati enake zahteve glede postopkov nadzora dostopa ne glede na kraj ali pogodbeno povezavo s ponudnikom storitev, ki upravlja repozitorij.
Vsak korenski CA ali upravljavec repozitorija bi moral kot izhodišče za ravni nadzora dostopa zagotoviti najmanj tri različne ravni (npr. javno, omejeno na subjekte C-ITS, raven korenskega CA).
2.5.Objava informacij o potrdilih
2.5.1.Objava informacij o potrdilih s strani TLM
(33)TLM v skupni evropski domeni zaupanja C-ITS preko CPOC objavi naslednje informacije:
·vsa trenutno veljavna potrdila TLM za naslednje obdobje delovanja (trenutno in vezno potrdilo, če obstaja);
·informacije o točki dostopa do repozitorija CPOC za zagotovitev podpisanega seznama korenskih CA (ECTL);
·splošno informacijsko točko o ECTL in uvedbi C-ITS.
2.5.2.Objava informacij o potrdilih s strani izdajatelja digitalnih potrdil (CA)
(34)Korenski CA v skupni evropski domeni zaupanja C-ITS preko CPOC objavijo naslednje informacije:
·izdana (trenutno veljavna) potrdila korenskega CA (sedanja in pravilno obnovljena potrdila, vključno z veznim potrdilom) v repozitoriju iz oddelka 2.3;
·vse veljavne subjekte EA in AA z njihovo identifikacijsko oznako upravljavca in predvideno obdobje delovanja;
·izdana potrdila CA v repozitorijih iz oddelka 2.3;
·CRL za vsa preklicana potrdila CA, ki zajemajo njihove podrejene EA in AA;
·podatke o točki dostopa korenskega CA do podatkov o CRL in CA.
Vsi podatki o potrdilih so razvrščeni v skladu s tremi ravnmi zaupnosti, dokumenti za javnost pa morajo biti javno dostopni brez omejitev.
3.Preverjanje istovetnosti in verodostojnosti
3.1.Določanje imen
3.1.1.Vrste imena
3.1.1.1.Imena za TLM, korenske CA, EA, AA
(35)Ime v potrdilu TLM je sestavljeno iz enega samega atributa subject_name z rezervirano vrednostjo „EU_TLM“.
(36)Ime korenskih CA je sestavljeno iz enega samega atributa subject_name z vrednostjo, ki jo dodeli CPA. Za enoličnost imen je odgovoren izključno CPA, TLM pa vodi evidenco imen korenskih CA, potem ko ga obvesti CPA (odobritev, preklic/umik korenskega CA). Imena subjektov v potrdilih so omejena na 32 bajtov. Vsak korenski CA predlaga svoje ime CPA v prošnji (tok 14). Za preverjanje edinstvenosti imen je odgovoren CPA. Če ime ni edinstveno, se prošnja zavrne (tok 4).
(37)Ime v potrdilu EA/AA je lahko sestavljeno iz enega samega atributa subject_name z vrednostjo, ki jo ustvari izdajatelj potrdila. Za enoličnost imen je odgovoren izključno korenski CA, ki je izdajatelj.
(38)V potrdilih EA in AA se ne uporabljajo imena, daljša od 32 bajtov, ker je dolžina subject_name v potrdilih omejena na 32 bajtov.
(39)AT ne vsebujejo imena.
3.1.1.2.Imena za končne subjekte
(40)Vsaki postaji C-ITS se dodelita dve vrsti enotne identifikacijske oznake:
·standardna identifikacijska oznaka, ki se shrani ob začetni registraciji postaje C-ITS, zanjo pa je zadolžen proizvajalec. Ta vsebuje podniz z identiteto proizvajalca ali upravljavca, tako da je ta identifikacijska oznaka lahko enolična;
·subject_name, ki je lahko del EC postaje C-ITS in za katerega je zadolžen EA.
3.1.1.3.Identifikacija potrdil
(41)Certifikati, sestavljeni po formatu [5], se identificirajo z izračunom vrednosti HashedId8, kot je opredeljeno v [5].
3.1.2.Zahteva za smiselnost imen
Ni določeno.
3.1.3.Uporaba anonimnih imen ali psevdonimov končnih subjektov
(42)AA zagotovi, da se psevdonimnost postaje C-ITS vzpostavi tako, da postaja C-ITS dobi AT, ki ne vsebujejo imen ali podatkov, ki bi omogočili povezavo subjekta z njegovo resnično identiteto.
3.1.4.Pravila za razlago različnih oblik imen
Ni določeno.
3.1.5.Enoličnost imen
(43)Imena za TLM, korenske CA, EA, AA in standardne identifikacijske oznake za postaje C-ITS so enolične.
(44)TLM v postopku registracije korenskega CA v ECTL zagotovi, da je njegova identifikacijska oznaka potrdila (HashedId8) enolična. Korenski CA v postopku izdajanja zagotovi, da je identifikacijska oznaka potrdila (HashedId8) vsakega podrejenega CA enolična.
(45)Oznaka HashedId8 za EC mora biti v okviru CA, ki izda potrdilo, enolična. Oznaka HashedId8 za AT ni nujno enolična.
3.2.Začetno preverjanje istovetnosti
3.2.1.Metoda za dokazovanje imetništva zasebnega ključa
(46)Korenski CA dokaže, da ima pravico do imetništva zasebnega ključa, ki ustreza javnemu ključu v potrdilu z lastnim podpisom. CPOC ta dokaz preveri.
(47)EA/AA dokaže, da ima pravico do imetništva zasebnega ključa, ki ustreza javnemu ključu v potrdilu. Korenski CA ta dokaz preveri.
(48)Imetništvo novega zasebnega ključa (za obnovo) se dokaže s podpisom zahtevka z novim zasebnim ključem (notranji podpis), ki mu sledi ustvaritev zunanjega podpisa po podpisanem zahtevku s trenutno veljavnim zasebnim ključem (za zagotovitev verodostojnosti podpisa). Prosilec podpisani zahtevek za potrdilo pošlje CA, ki izdaja potrdilo, po varni komunikacijski poti. CA, ki izdaja potrdilo, preveri, ali je bil prosilčev digitalni podpis v sporočilu z zahtevkom ustvarjen z uporabo zasebnega ključa, ki ustreza javnemu ključu, pripetemu k zahtevku za potrdilo. Korenski CA v svoji CPS navede, kateri zahtevek za potrdilo in katere odgovore podpira.
3.2.2.Preverjanje verodostojnosti organizacije
3.2.2.1.Preverjanje verodostojnosti organizacije korenskega CA
(49)Korenski CA v prošnji CPA (tj. tok 14) navede identiteto organizacije in podatke za registracijo, ki jih sestavljajo:
·ime organizacije;
·poštni naslov;
·elektronski naslov;
·ime fizične kontaktne osebe v organizaciji;
·telefonska številka;
·digitalni prstni odtis (tj. zgoščevalna vrednost SHA 256) potrdila korenskega CA v tiskani obliki;
·kriptografski podatki (tj. kriptografski algoritmi, dolžina ključev) v potrdilu korenskega CA;
·vsa dovoljenja, ki jih korenski CA lahko uporablja in prenese na podrejene CA.
(50)CPA preveri identiteto organizacije in druge podatke za registracijo, ki jih navede prosilec za potrdilo, da lahko potrdilo korenskega CA vnese v ECTL.
(51)CPA pridobi neposredna dokazila ali potrdilo iz ustreznega pooblaščenega vira o identiteti (npr. imenu) in, če je primerno, posebnih atributih subjektov, ki se jim izdaja potrdilo. Dokazila se lahko predložijo v elektronski ali papirni obliki.
(52)Subjektova identiteta se ob registraciji preveri z ustreznimi sredstvi in v skladu z veljavno potrditveno politiko.
(53)Pri vsaki prošnji za potrdilo se predložijo dokazila o:
·polnem imenu organizacije (zasebna organizacija, vladni ali nekomercialni subjekt);
·nacionalno priznani registraciji ali drugih atributih, ki se lahko uporabljajo, kolikor je mogoče, za razlikovanje organizacije od drugih z enakim imenom.
Navedena pravila temeljijo na standardu TS 102 042 [4]: CA zagotovi, da se dokazila o identifikaciji naročnika in subjekta, točnosti njunega imena in z njim povezanih podatkov ustrezno preverijo v okviru opredeljene storitve ali se, če je primerno, ugotovijo s pregledom potrdil iz ustreznih pooblaščenih virov, in da so zahtevki za potrdilo točni, avtorizirani in popolni v skladu z zbranimi dokazili ali potrdilom.
3.2.2.2.Preverjanje verodostojnosti organizacije TLM
(54)Organizacija, ki upravlja TLM, poda dokazila o identifikaciji in točnosti imena in z njim povezanih podatkov, da bi omogočila ustrezno preverjanje ob začetni ustvaritvi in obnovi potrdila TLM.
(55)Subjektova identiteta se ob ustvaritvi ali obnovi potrdila preveri z ustreznimi sredstvi in v skladu z veljavno CP.
(56)Dokazila o organizaciji se podajo v skladu z oddelkom 3.2.2.1.
3.2.2.3.Preverjanje verodostojnosti organizacije podrejenega CA
(57)Korenski CA preveri identiteto organizacije in druge podatke za registracijo, ki jih navedejo prosilci za potrdilo, za potrdila podrejenih CA (EA/AA).
(58)Korenski CA vsaj:
·ugotovi, da organizacija obstaja, in sicer z uporabo najmanj ene storitve ali podatkovne zbirke tretje osebe za preverjanje istovetnosti ali, kot druga možnost, z organizacijsko dokumentacijo, ki jo je izdala ustrezna državna agencija ali priznani organ, oziroma, ki je bila taki agenciji ali organu predložena, in ki potrjuje obstoj organizacije;
·z navadno pošto ali primerljivim postopkom od prosilca zahteva potrditev določenih podatkov o organizaciji ter potrditev, da je avtoriziral prošnjo za potrdilo in da je oseba, ki vlaga prošnjo v prosilčevem imenu, za to tudi pooblaščena. Če potrdilo vsebuje ime posameznika kot pooblaščenega predstavnika organizacije, mora prosilec potrditi tudi, da je ta oseba zaposlena pri njem in da jo je pooblastil za ravnanje v njenem imenu.
(59)Postopki preverjanja za izdajo potrdil CA se dokumentirajo v CPS korenskega CA.
3.2.2.4.Preverjanje verodostojnosti organizacije naročnika končnega subjekta
(60)Preden se lahko naročnik končnih subjektov (proizvajalec/upravljavec) registrira pri zaupanja vrednem EA, da svojim končnim subjektom omogoči pošiljanje zahtevkov za potrdila o EC, EA:
·preveri istovetnost naročnikove organizacije in druge podatke za registracijo, ki jih je navedel prosilec za potrdilo;
·preveri, ali tip postaje C-ITS (tj. konkretni proizvod na podlagi blagovne znamke, modela in različice postaje C-ITS) izpolnjuje vsa merila za ocenjevanje skladnosti.
(61)EA vsaj:
·ugotovi, da organizacija obstaja, in sicer z uporabo najmanj ene storitve ali podatkovne zbirke tretje osebe za preverjanje istovetnosti ali, kot druga možnost, z organizacijsko dokumentacijo, ki jo je izdala ustrezna državna agencija ali priznani organ, oziroma, ki je bila taki agenciji ali organu predložena, in ki potrjuje obstoj organizacije;
·z navadno pošto ali primerljivim postopkom od prosilca zahteva potrditev določenih podatkov o organizaciji ter potrditev, da je avtoriziral prošnjo za potrdilo in da je oseba, ki vlaga prošnjo v njegovem imenu, za to tudi pooblaščena. Če potrdilo vsebuje ime posameznika kot pooblaščenega predstavnika organizacije, mora prosilec potrditi tudi, da je ta oseba zaposlena pri njem in da jo je pooblastil za ravnanje v njenem imenu.
(62)Postopke preverjanja za registracijo postaje C-ITS s strani njenega naročnika EA dokumentira v svoji CPS.
3.2.3.Preverjanje verodostojnosti posameznega subjekta
3.2.3.1.Preverjanje verodostojnosti posameznega subjekta TLM/CA
(63)Za preverjanje verodostojnosti posameznega subjekta (fizične osebe), določene v povezavi s pravno osebo ali organizacijo (tj. naročnikom), se predložijo dokazila o:
·celotnem imenu subjekta (vključno s priimkom in rojstnimi imeni v skladu s pravom, ki se uporablja, in nacionalnimi praksami za ugotavljanje istovetnosti);
·datumu in kraju rojstva z navedbo nacionalno priznanega identifikacijskega dokumenta ali drugih naročnikovih lastnosti, ki se morda uporabljajo, da se ta oseba čim bolj loči od drugih oseb z enakim imenom;
·polnem imenu in pravnem statusu z njo povezane pravne osebe ali druge organizacije (tj. naročnika);
·pomembnih podatkih o registraciji (npr. registracija družbe) z njo povezane pravne osebe ali druge organizacije;
·tem, da je subjekt povezan s pravno osebo ali drugo organizacijo.
Dokazila se lahko predložijo v elektronski ali papirni obliki.
(64)Pooblaščeni predstavnik korenskega CA, EA, AA ali naročnika za preveritev svoje istovetnosti predloži dokumentacijo, s katero dokaže, da dela za organizacijo (pooblastilo). Izkaže se tudi z osebnim dokumentom.
(65)Za postopek začetne pridobitve potrdila (tok 31/32) predstavnik EA/AA ustreznemu korenskemu CA predloži vse potrebne podatke (gl. oddelek 4.1.2).
(66)Osebje korenskega CA preveri istovetnost predstavnika prosilca za potrdilo in vse z njim povezane dokumente, pri čemer upošteva zahteve za „zaupanja vredno osebje“ iz oddelka 5.2.1. (Postopek preverjanja podatkov iz prošnje in ustvaritve potrdila s strani korenskega CA izvajajo „zaupanja vredne osebe“ pri korenskem CA, in sicer pod najmanj dvojnim nadzorom, saj gre za občutljive dejavnosti v smislu oddelka 5.2.2).
3.2.3.2.Preverjanje verodostojnosti naročnika postaje C-ITS
(67)Naročnike predstavljajo pooblaščeni končni uporabniki v organizaciji, ki so registrirani pri EA in AA, ki izdajata potrdila. Ti končni uporabniki, ki jih določijo organizacije (proizvajalci ali upravljavci) svojo istovetnost in verodostojnost dokažejo, preden:
·registrirajo EE pri ustreznem EA, vključno z njegovim standardnim javnim ključem, standardno identifikacijsko oznako (enotna identifikacijska oznaka) in dovoljenji v skladu z EE;
·pri AA registrirajo in pridobijo dokazilo o naročniški pogodbi, ki ga je mogoče poslati EA.
3.2.3.3.Preverjanje verodostojnosti postaje C-ITS
(68)EE, ki morajo pridobiti EC, izkažejo verodostojnost, ko podajo zahtevek za EC (tok 31), in sicer tako, da pri začetnem izkazovanju uporabijo svoj standardni zasebni ključ. EA preveri verodostojnost z uporabo standardnega javnega ključa, ki ustreza EE. Standardni javni ključi EE se dostavijo EA pred podajo začetnega zahtevka po varnem kanalu med proizvajalcem ali upravljavcem postaje C-ITS in EA (tok 33).
(69)EE, ki morajo pridobiti AT, izkažejo verodostojnost ob zahtevku za AT (tok 32) z uporabo svojega enotnega zasebnega ključa za pridobitev potrdila. AA podpis posreduje v preveritev EA (tok 25); EA ga preveri in pošlje potrditev rezultata AA (tok 23).
3.2.4.Nepreverjeni podatki o naročniku
Ni določeno.
3.2.5.Preverjanje pooblastil
3.2.5.1.Preverjanje TLM, korenskega CA, EA, AA
(70)Vsaka organizacija v CPS določi najmanj enega predstavnika (npr. varnostnega uradnika), ki je odgovoren za podajanje zahtevkov za nova potrdila in podaljšanje potrdil. Za določanje imen se uporabljajo pravila iz oddelka 3.2.3.
3.2.5.2.Preverjanje naročnikov postaje C-ITS
(71)EA pozna in odobri najmanj eno fizično osebo (npr. varnostni uradnik), ki je odgovorna za registriranje postaj C-ITS pri EA (gl. oddelek 3.2.3).
3.2.5.3.Preverjanje postaj C-ITS
(72)Naročnik postaje C-ITS lahko registrira postaje C-ITS pri določenem EA (tok 33), če ta EA preveril njegovo verodostojnost.
Če je postaja C-ITS registrirana pri EA z enotno standardno identifikacijsko oznako in standardnim javnim ključem, lahko zahteva EC z uporabo zahtevka, podpisanega s standardnim zasebnim ključem, povezanim s prej registriranim standardnim javnim ključem.
3.2.6.Merila za medsebojno povezovanje
(73)Postaja C-ITS lahko za komunikacijo med postajami C-ITS in EA (ali AA) vzpostavi varno komunikacijo z EA (ali AA), tj. izvede funkcije preverjanja verodostojnosti, zaupnosti in celovitosti, kot je določeno v [1]. Uporabljajo se lahko še drugi protokoli pod pogojem, da se izvaja [1]. EA in AA podpirata to varno komunikacijo.
(74)EA in AA podpirata zahtevke za potrdila in odgovore, ki so skladni z [1], kar omogoča varen protokol za zahtevek/odgovor za AT, ki podpira anonimnost pošiljatelja zahteve glede na AA ter nezdružljivost vlog AA in EA. Uporabljajo se lahko še drugi protokoli pod pogojem, da se izvaja [1]. Da bi preprečili razkritje dolgoročne identitete postaje C-ITS, je komunikacija med premično postajo C-ITS in EA zaupna (tj. podatki v komunikaciji so šifrirani od konca do konca).
(75)AA pošlje zahtevek za preverjanje avtorizacije (tok 25) pri vsakem zahtevku za avtorizacijo, ki ga prejme od subjekta s potrdilom EE. EA ta zahtevek potrdi glede na:
·status EE pri EA;
·veljavnost podpisa;
·zahtevane identifikacijske oznake aplikacije ITS (ITS-AID) in dovoljenja;
·status opravljanja storitve AA za naročnika.
3.3.Istovetnost in verodostojnost pri zahtevkih za obnovo
3.3.1.Istovetnost in verodostojnost pri rutinskih zahtevkih za obnovo
3.3.1.1.Potrdila TLM
(76)TLM ustvari par ključev in dve potrdili: eno je z lastnim podpisom, eno pa vezno potrdilo v skladu z oddelkom 7.
3.3.1.2.Potrdila korenskega CA
Se ne uporablja.
3.3.1.3.Podaljšanje ali obnova potrdila EA/AA
(77)EA/AA pred potekom potrdila EA/AA zahteva novo potrdilo (tok 21 / tok 24), da bi omogočil neprekinjeno rabo potrdila. EA/AA ustvari nov par ključev za nadomestitev para ključev, ki bo potekel, in podpis zahtevka za obnovo, ki vsebuje novi javni ključ s trenutno veljavnim zasebnim ključem („obnova“). EA ali AA ustvari nov par ključev in podpiše zahtevek z novim zasebnim ključem (notranji podpis), da dokaže imetništvo novega zasebnega ključa. Celotna zahteva se podpiše (kot dodatni podpis) s trenutno veljavnim zasebnim ključem (zunanji podpis) za zagotovitev celovitosti in verodostojnosti zahtevka. Če se uporablja par ključev za šifriranje in dešifriranje, se dokaže imetništvo zasebnih ključev za dešifriranje (podroben opis obnove je v oddelku 4.7.3.3).
(78)Metoda za preverjanje istovetnosti in verodostojnosti pri rutinski obnovi je enaka kot tista pri začetnem preverjanju začetne izdaje potrdila korenskega CA, kot je določeno v oddelku 3.2.2.
3.3.1.4.Poverilnice za pridobitev potrdila končnih subjektov
(79)EE pred potekom obstoječe EC zahteva novo potrdilo (tok 31), da bi omogočil neprekinjeno rabo potrdila. EE ustvari nov par ključev za nadomestitev poteklega para ključev in zahteva novo potrdilo, ki vsebuje novi javni ključ; zahtevek se podpiše s trenutno veljavnim zasebnim ključem EC.
(80)EE lahko podpiše zahtevek z novoustvarjenim zasebnim ključem (notranji podpis), da dokaže imetništvo novega zasebnega ključa. Celotni zahtevek se nato podpiše (kot dodatni podpis) s trenutno veljavnim zasebnim ključem (zunanji podpis) in se šifrira za sprejemnega EA v skladu z [1] za zagotovitev zaupnosti, celovitosti in verodostojnosti zahteve. Uporabljajo se lahko še drugi protokoli pod pogojem, da se izvaja [1].
3.3.1.5.Potrdila o avtorizaciji končnih subjektov
(81)Obnova potrdila za AT temelji na enakem postopku kot začetna avtorizacija, kot je opredeljeno v [1]. Uporabljajo se lahko še drugi protokoli pod pogojem, da se izvaja [1].
3.3.2.Preverjanje istovetnosti in verodostojnosti pri zahtevkih za obnovo po preklicu
3.3.2.1.Potrdila CA
(82)Preverjanje verodostojnosti organizacije CA pri obnovi potrdila korenskega CA, EA in AA poteka enako kot začetna izdaja potrdila CA v skladu z oddelkom 3.2.2.
3.3.2.2.Poverilnice za pridobitev potrdila končnih subjektov
(83)Preverjanje verodostojnosti EE pri obnovi potrdila o EC po preklicu poteka enako kot začetna izdaja potrdila EE v skladu z oddelkom 3.2.2.
3.3.2.3.Zahtevki končnih subjektov za avtorizacijo
Se ne uporablja, ker se AT ne preklicujejo.
3.4.Preverjanje istovetnosti in verodostojnosti pri zahtevku za preklic
3.4.1.Potrdila korenskega CA/EA/AA
(84)Pri zahtevkih za izbris potrdila korenskega CA iz ECTL korenski CA preveri verodostojnost za TLM (toka 12 in 9). Pri zahtevkih za preklic potrdila EA/AA verodostojnost preveri ustrezni korenski CA in sam podrejeni CA.
(85)Med sprejemljivimi postopki za preveritev verodostojnosti naročnikovega zahtevka za preklic so:
·podpisano sporočilo v pisni obliki na papirju z uradno glavo naročnika, s katerim se zahteva preklic, z navedbo potrdila, ki se preklicuje;
·komunikacija z naročnikom, v kateri se dajo razumna zagotovila, da je oseba ali organizacija, ki zahteva preklic, res naročnik. Taka komunikacija lahko glede na okoliščine vključuje eno ali več naslednjih oblik: e-pošta, navadna pošta ali dostava s kurirsko službo.
3.4.2.Poverilnica za pridobitev potrdila postaje C-ITS
(86)Naročnik postaje C-ITS lahko pri EA prekliče EC prej registrirane postaje C-ITS (tok 34). Naročnik, ki podaja zahtevek, ustvari zahtevek za preklic postaje C-ITS ali seznama postaj C-ITS. EA preveri verodostojnost zahtevka za preklic, preden ga obdela, in potrdi preklic postaj C-ITS in njihovih EC.
(87)EA lahko prekliče EC postaje C-ITS v skladu z oddelkom 7.3.
3.4.3.Potrdila o avtorizaciji postaje C-ITS
(88)AT se ne preklicujejo, zato njihova veljavnost ni časovno omejena. Razpon sprejemljivih obdobij veljavnosti v tej potrditveni politiki je določen v oddelku 7.
4.Zahteve za upravljanje s potrdili skozi življenjski cikel
4.1.Prošnja za potrdilo
(89)V tem oddelku so določene zahteve za začetno prošnjo za izdajo potrdila.
(90)Izraz „prošnja za potrdilo“ pomeni naslednji postopek:
·registracija in vzpostavitev razmerja zaupanja med TLM in CPA;
·registracija in vzpostavitev razmerja zaupanja med korenskim CA in CPA ter TLM, vključno z vpisom prvega potrdila korenskega CA v ECTL;
·registracija in vzpostavitev razmerja zaupanja med EA/AA in korenskim CA, vključno z izdajo novega potrdila EA/AA;
·registracija postaje C-ITS pri EA/AA s strani proizvajalca/upravljavca;
·zahtevek postaje C-ITS za EC/AT.
4.1.1.Kdo lahko vloži prošnjo za potrdilo
4.1.1.1.Korenski CA
(91)Korenski CA ustvarijo svoje lastne pare ključev in sami izdajo svoje korensko potrdilo. Korenski CA lahko vloži prošnjo za potrdilo preko svojega imenovanega predstavnika (tok 14).
4.1.1.2.TLM
(92)TLM ustvari svoje lastne pare ključev in sam izda potrdilo. Začetno ustvaritev potrdila TLM opravi predstavnik organizacije TLM pod nadzorom CPA.
4.1.1.3.EA in AA
(93)Pooblaščeni predstavnik EA ali AA lahko vloži prošnjo za zahtevek za potrdilo podrejenega CA (EA in/ali AA) pri pooblaščenem predstavniku ustreznega korenskega CA (tok 27/28).
4.1.1.4.Postaja C-ITS
(94)Naročniki registrirajo vsako postajo C-ITS pri EA v skladu z oddelkom 3.2.5.3.
(95)Vsaka postaja C-ITS, ki je registrirana pri EA, lahko pošilja zahtevke za EC (tok 31).
(96)Vsaka postaja C-ITS lahko pošilja zahtevke za AT (tok 32), ne da bi zahtevala kakršno koli izmenjavo sporočil z naročnikom. Preden postaja C-ITS zahteva AT, mora imeti EC.
4.1.2.Postopek za pridobitev potrdila in odgovornosti
(97)Dovoljenja za korenske CA in podrejene CA, ki izdajajo potrdila za posebne (državne) namene (tj. posebne premične in nepremične postaje C-ITS) lahko podelijo samo države članice, v katerih se organizacije nahajajo.
4.1.2.1.Korenski CA
(98)Po reviziji (toka 13 in 36, oddelek 8) lahko korenski CA zaprosijo CPA za vpis svojih potrdil v ECTL (tok 14). Postopek pridobivanja potrdil temelji na podpisani prošnji v papirni obliki, ki jo pooblaščeni predstavnik korenskega CA fizično dostavi CPA in ki vsebuje vsaj podatke iz oddelkov 3.2.2.1, 3.2.3 in 3.2.5.1.
(99)Prošnjo korenskega CA podpiše njegov pooblaščeni predstavnik.
(100)Pooblaščeni predstavnik korenskega CA poleg prošnje predloži CPA v odobritev izvod CPS korenskega CA (tok 15) in njegovo revizijsko poročilo (tok 16). CPA v primeru odobritve ustvari potrdilo o skladnosti ter ga pošlje CPOC/TLM in ustreznemu korenskemu CA.
(101)Pooblaščeni predstavnik korenskega CA nato predloži CPOC/TLM svojo prošnjo (ki vsebuje digitalni prstni odtis potrdila z lastnim podpisom), osebni dokument in pooblastilo. Potrdilo z lastnim podpisom se dostavi CPOC/TLM po elektronski poti. CPOC/TLM preveri vse dokumente in potrdilo z lastnim podpisom.
(102)Če je rezultat preverjanja pozitiven, TLM doda potrdilo korenskega CA v ECTL na podlagi obvestila CPA (toka 1 in 2). Postopek podrobno opiše TLM v svoji CPS.
(103)Možen bi moral biti tudi dodaten postopek za odobritev CPS in revizijskega poročila korenskega CA pri nacionalnem organu posameznih držav.
4.1.2.2.TLM
(104)TLM lahko po končani reviziji pridobi potrdilo pri CPA. Postopek pridobivanja potrdil temelji na podpisani prošnji v papirni obliki, ki jo pooblaščeni predstavnik TLM fizično dostavi CPA (tok 38) in ki vsebuje vsaj podatke iz oddelkov 3.2.2.2 in 3.2.3.
(105)Prošnjo TLM podpiše njegov pooblaščeni predstavnik.
(106)TLM najprej ustvari potrdilo z lastnim podpisom in ga po varni poti posreduje CPA. Nato predloži CPA svojo prošnjo (ki vsebuje digitalni prstni odtis potrdila z lastnim podpisom), izvod svoje CPS, osebni dokument, pooblastilo in svoje revizijsko poročilo (tok 40). CPA preveri vse dokumente in potrdilo z lastnim podpisom. Če je rezultat preverjanja vseh dokumentov, potrdila z lastnim podpisom in digitalnega prstnega odtisa pozitiven, CPA potrdi postopek pridobitve potrdila tako, da obvestilo o odobritvi pošlje TLM in CPOC (tok 39). CPA shrani podatke o prošnji, ki jih je poslal TLM. Potem se preko CPOC izda potrdilo TLM.
4.1.2.3.EA in AA
(107)EA/AA v postopku pridobitve potrdila predloži ustrezne dokumente (tj. CPS in revizijsko poročilo) ustreznemu CA v odobritev (tok 27/28). Če je rezultat preverjanja dokumentov pozitiven, korenski CA pošlje sporočilo o odobritvi ustreznim korenskim podrejenim CA (tok 29/30). Podrejeni CA (EA ali AA) nato ustreznemu korenskemu CA elektronsko posreduje svoj podpisani zahtevek in fizično dostavi svojo prošnjo (v skladu z oddelkom 3.2.2.1), pooblastilo in osebni dokument. Korenski CA preveri zahtevo in prejete dokumente (prošnjo, ki vsebuje digitalni prstni odtis, ki je zgoščevalna vrednost SHA 256 zahtevka podrejenega CA, ter pooblastilo in osebni dokument). Če je rezultat vseh preverjanj pozitiven, korenski CA izda potrdilo ustreznemu podrejenemu CA. Postopek za začetni zahtevek podrobno opiše v svoji posebni CPS.
(108)Pooblaščeni predstavnik podrejenega CA prošnji podrejenega CA priloži izvod CPS za korenski CA.
(109)Podatki se posredujejo pooblaščenemu revizorju PKI za revizijo v skladu z oddelkom 8.
(110)Če je podrejeni CA v lasti subjekta, ki ni isti kot subjekt, ki ima v lasti korenski CA, pred vložitvijo zahtevka za potrdilo podrejenega CA subjekt podrejenega CA podpiše pogodbo o storitvah korenskega CA.
4.1.2.4.Postaja C-ITS
(111)Začetno registracijo končnih subjektov (postaj C-ITS) izvede odgovorni naročnik (proizvajalec/upravljavec) z EA (toka 33 in 35) po uspešni preveritvi verodostojnosti naročnikove organizacije in enega od njenih predstavnikov v skladu z oddelkoma 3.2.2.4 in 3.2.5.2.
(112)Postaja C-ITS lahko ustvari par ključev EC (gl. oddelek 6.1) in ustvari podpisan zahtevek za EC v skladu z [1]. Uporabljajo se lahko še drugi protokoli pod pogojem, da se izvaja [1].
(113)Med registracijo običajne postaje C-ITS (za razliko od posebne premične ali nepremične postaje C-ITS) mora EA preveriti, da dovoljenja v začetnem zahtevku niso namenjena za uporabo državnih organov. Dovoljenja, namenjena za uporabo državnih organov, opredelijo ustrezne države članice. Postopek za registracijo in odgovor EA proizvajalcu/upravljavcu (toka 33 in 35) podrobno določi EA v ustrezni CPS.
(114)Postaja C-ITS pridobi potrdilo pri EA (oddelek 3.2.5.3) tako, da svoj začetni zahtevek za EC pošlje v skladu z [1].
(115)Ob začetni registraciji s strani predstavnika naročnika s preverjeno verodostojnostjo EA določi, katera AT lahko končni subjekt (npr. postaja C-ITS) pridobi. Poleg tega se vsakemu končnemu subjektu dodeli stopnja zagotovitve zaupanja, ki je povezana z izdajo potrdila končnemu subjektu v skladu z enim od profilov zaščite iz oddelka 6.1.5.2.
(116)Običajna vozila imajo samo eno postajo C-ITS, ki je registrirana pri enem EA. Vozila za posebne namene (kot so policijski avtomobili in druga vozila za posebne namene s posebnimi pravicami) se lahko registrirajo pri dodatnem EA ali imajo dodatno postajo C-ITS za avtorizacije v okviru posebnega namena. Vozila, za katera velja taka izjema, opredeli pristojna država članica. Dovoljenja za posebne premične in nepremične postaje C-ITS podeljujejo samo pristojne države članice. Kako se za ta vozila uporablja postopek glede potrdil, je določeno v CPS korenskih ali podrejenih CA, ki izdajajo potrdila za taka vozila v teh državah članicah.
(117)Če naročnik prenaša postajo C-ITS od enega EA na drugega, je lahko postaja C-ITS registrirana pri dveh (podobnih) EA.
(118)Postaja C-ITS lahko ustvari par ključev AT (gl. oddelek 6.1) in ustvari zahtevek za AT v skladu z [1]. Uporabljajo se lahko še drugi protokoli pod pogojem, da se izvaja [1].
(119)Postaje C-ITS pošljejo zahtevek za avtorizacijo na URL AA (toka 32 in 26) tako, da pošljejo vsaj zahtevane podatke iz oddelka 3.2.3.3. AA in EA potrdita avtorizacijo za vsak zahtevek v skladu z oddelkoma 3.2.6 in 4.2.2.5.
4.2.Obdelava prošnje za potrdilo
4.2.1.Postopek preverjanja istovetnosti in verodostojnosti
4.2.1.1.Postopek preverjanja istovetnosti in verodostojnosti korenskih CA
(120)Pooblaščeni predstavnik CPA je odgovoren za preverjanje verodostojnosti pooblaščenega predstavnika korenskega CA in odobritev njegovega postopka pridobitve potrdila v skladu z oddelkom 3.
4.2.1.2.Preverjanje istovetnosti in verodostojnosti TLM
(121)Pooblaščeni predstavnik CPA je odgovoren za preverjanje verodostojnosti pooblaščenega predstavnika TLM in odobritev njegove prošnje za pridobitev potrdila v skladu z oddelkom 3.
4.2.1.3.Preverjanje istovetnosti in verodostojnosti EA in AA
(122)Ustrezni korenski CA je odgovoren za preverjanje verodostojnosti pooblaščenega predstavnika EA/AA in odobritev njegove prošnje za pridobitev potrdila v skladu z oddelkom 3.
(123)Korenski CA potrdi pozitiven rezultat preverjanja prošnje z obvestilom EA/AA. EA/AA lahko potem pošlje zahtevek za potrdilo korenskemu CA (tok 21/24), ki ustreznemu EA/AA izda potrdila (tok 18/19).
4.2.1.4.Preverjanje istovetnosti in verodostojnosti naročnika EE
(124)Preden lahko postaja C-ITS zahteva potrdilo o EC, naročnik EE po varni poti posreduje EA podatke o identifikacijski oznaki postaje C-ITS (tok 33). EA preveri zahtevek in, če je rezultat preverjanja pozitiven, registrira podatke o postaji C-ITS v svoji podatkovni zbirki in to potrdi naročniku EE (tok 35). To za vsako postajo C-ITS samo enkrat opravi proizvajalec ali upravljavec. Ko je postaja C-ITS registrirana pri EA, lahko zahteva enotno potrdilo o EC, ki ga v tistem trenutku potrebuje (tok 31). EA preveri verodostojnost in preveri, ali so podatki v zahtevku za potrdilo o EC veljavni za postajo C-ITS.
4.2.1.5.Potrdila o avtorizaciji
(125)Ob zahtevkih za avtorizacijo (tok 32) mora AA v skladu z [1] preveriti verodostojnost EA, od katerega je postaja C-ITS prejela EC. Uporabljajo se lahko še drugi protokoli pod pogojem, da se izvaja [1]. Če AA ne more preveriti verodostojnosti EA, se zahtevek zavrne (tok 26). Kot predpogoj mora AA imeti potrdilo EA, da lahko preveri verodostojnost EA in preveri njegov odgovor (toka 25 in 23, oddelek 3.2.5.3).
(126)EA preveri verodostojnost postaje C-ITS, ki zahteva AT, tako, da preveri njen EC (toka 25 in 23).
4.2.2.Odobritev ali zavrnitev prošenj za potrdilo
4.2.2.1.Odobritev ali zavrnitev potrdil korenskega CA
(127)TLM vpiše potrdila korenskega CA v ECTL ali jih izbriše iz njega v skladu z odobritvijo CPA (tok 1/2).
(128)TLM bi moral po prejemu odobritve od CPA preveriti podpis, podatke in kodiranje potrdil korenskega CA (tok 1). Če je rezultat preverjanja pozitiven in če CPA da odobritev, TLM vpiše ustrezno korensko potrdilo v ECTL in obvesti CPA (tok 5).
4.2.2.2.Odobritev ali zavrnitev potrdila TLM
(129)Za odobritev ali zavrnitev potrdil TLM je odgovoren CPA.
4.2.2.3.Odobritev ali zavrnitev potrdila EA in AA
(130)Korenski CA preveri zahtevke za potrdila podrejenega CA (tok 21/24) in ustrezna poročila (ki jih izda pooblaščeni revizor PKI), ko jih prejme (tok 36, oddelek 8) od ustreznega podrejenega CA korenskega CA. Če je rezultat preverjanja zahtevka pozitiven, ustrezni korenski CA izda potrdilo EA/AA, ki je podal zahtevek (tok 18/19); v nasprotnem primeru se zahtevek zavrne in se EA/AA ne izda potrdilo.
4.2.2.4.Odobritev ali zavrnitev EC
(131)EA preveri in potrdi zahtevke za EC v skladu z oddelkoma 3.2.3.2 in 3.2.5.3.
(132)Če je zahtevek za potrdilo v skladu z [1] pravilen in veljaven, EA ustvari zahtevano potrdilo.
(133)Če je zahtevek za potrdilo neveljaven, ga EA zavrne in pošlje odgovor z navedbo razloga za zavrnitev v skladu z [1]. Če postaja C-ITS še vedno želi pridobiti EC, poda nov zahtevek za potrdilo. Uporabljajo se lahko še drugi protokoli pod pogojem, da se izvaja [1].
4.2.2.5.Odobritev ali zavrnitev AT
(134)Zahtevek za potrdilo preveri EA. AA vzpostavi komunikacijo z EA za preveritev zahtevka (tok 25). EA preveri verodostojnost postaje C-ITS, ki poda zahtevek, in preveri, ali ima pravico prejeti zahtevano AT v skladu s CP (npr. tako, da preveri status preklica in potrdi čas/regijo, veljavnost, dovoljenja, stopnjo zaupanja potrdila itd.). EA vrne odgovor glede preverjanja (tok 23) in, če je odgovor pozitiven, AA ustvari zahtevano potrdilo in ga pošlje postaji C-ITS. Če zahtevek za AT ni pravilen ali če je odgovor EA glede preverjanja negativen, AA zahtevek zavrne. Če postaja C-ITS še vedno želi pridobiti AT, poda nov zahtevek za avtorizacijo.
4.2.3.Čas za obdelavo prošnje za potrdilo
4.2.3.1.Prošnja za potrdilo korenskega CA
(135)Preverjanje istovetnosti in verodostojnosti prošnje za potrdilo se izvaja ob delovnih dneh, zanj pa velja rok, ki ga korenski CA določi v svoji CPS.
4.2.3.2.Prošnja za potrdilo TLM
(136)Prošnja za potrdilo TLM se obdela v roku, ki ga TLM določi v svoji CPS.
4.2.3.3.Prošnja za potrdilo EA in AA
(137)Preverjanje istovetnosti in verodostojnosti prošnje za potrdilo se izvaja ob delovnih dneh v skladu s sporazumom in pogodbo med korenskim CA države članice / zasebne organizacije in podrejenim CA. Prošnje za potrdilo podrejenega CA se obdela v roku, ki ga podrejeni CA določi v svoji CPS.
4.2.3.4.Prošnja za EC
(138)Prošnje za EC se obdela v roku, ki ga EA določi v svoji CPS.
4.2.3.5.Prošnja za AT
(139)Prošnje za AT se obdela v roku, ki ga AA določi v svoji CPS.
4.3.Izdaja potrdila
4.3.1.Postopek CA pri izdaji potrdila
4.3.1.1.Izdajanje potrdil korenskega CA
(140)Korenski CA izdajajo svoja lastna potrdila korenskega CA z lastnim podpisom, vezna potrdila, potrdila podrejenega CA in CRL.
(141)Korenski CA po odobritvi CPA (tok 4) pošlje svoje potrdilo TLM preko CPOC za vpis v ECTL (toka 11 in 8) (gl. oddelek 4.1.2.1). TLM preveri, ali je CPA odobril potrdilo (tok 1).
4.3.1.2.Izdaja potrdil TLM
(142)TLM izda svoj lastni TLM z lastnim podpisom in vezno potrdilo ter ga pošlje CPOC (tok 6).
4.3.1.3.Izdaja potrdil EA in AA
(143)Podrejeni CA ustvarijo podpisan zahtevek za potrdilo in ga posredujejo ustreznemu korenskemu CA (toka 21 in 24). Korenski CA preveri zahtevo in čim prej izda potrdilo podrejenemu CA, ki je podal zahtevek, v skladu s [5], kot je določeno v CPS za prakse pri običajnem delovanju, najpozneje pa v petih delovnih dneh po prejemu zahteve.
(144)Korenski CA posodobi repozitorij, ki vsebuje potrdila podrejenih CA.
4.3.1.4.Izdaja EC
(145)Postaja C-ITS pošlje EA zahtevek za EC v skladu z [1]. EA preveri verodostojnost in preveri, ali so podatki v zahtevku za potrdilo o EC veljavni za postajo C-ITS. Uporabljajo se lahko še drugi protokoli pod pogojem, da se izvaja [1].
(146)Če je rezultat preverjanja pozitiven, EA izda potrdilo v skladu z registracijo postaje C-ITS (gl. 4.2.1.4) in ga pošlje postaji C-ITS v sporočilu o odgovoru glede EC v skladu z [1]. Uporabljajo se lahko še drugi protokoli pod pogojem, da se izvaja [1].
(147)Če ni registracije, EA ustvari kodo napake in jo pošlje postaji C-ITS v sporočilu o odgovoru glede EC v skladu z [1]. Uporabljajo se lahko še drugi protokoli pod pogojem, da se izvaja [1].
(148)Zahtevki za EC in odgovori glede EC se šifrirajo za zagotovitev zaupnosti in podpišejo za zagotovitev verodostojnosti in celovitosti.
4.3.1.5.Izdaja AT
(149)Postaja C-ITS pošlje AA zahtevek za AT v skladu z [1]. AA pošlje EA zahtevek za preverjanje AT v skladu z [1]. EA pošlje AA odgovor glede preverjanja AT. Če je odgovor pozitiven, AA ustvari AT in ga pošlje postaji C-ITS v sporočilu o odgovoru glede AT v skladu z [1]. Če je odgovor negativen, AA ustvari kodo napake in jo pošlje postaji C-ITS v sporočilu o odgovoru glede AT v skladu z [1]. Uporabljajo se lahko še drugi protokoli pod pogojem, da se izvaja [1].
(150)Zahtevki za AT in odgovori glede AT se šifrirajo (potrebno samo pri premičnih postajah C-ITS) za zagotovitev zaupnosti in podpišejo za zagotovitev verodostojnosti in celovitosti.
4.3.2.Obvestilo o izdaji potrdil, ki ga CA pošlje naročniku
Se ne uporablja.
4.4.Prevzem potrdila
4.4.1.Izvedba prevzema potrdila
4.4.1.1.Korenski CA
Se ne uporablja.
4.4.1.2.TLM
Se ne uporablja.
4.4.1.3.EA in AA
(151)EA/AA v prejetem potrdilu preveri vrsto potrdila, podpis in podatke. Zavrne vsa potrdila EA/AA, ki niso pravilno preverjena, in izda nov zahtevek.
4.4.1.4.Postaja C-ITS
(152)Postaja C-ITS preveri odgovor glede EC/AT, ki ga prejme od EA/AA, glede na prvotno zahtevo, vključno s podpisom in verigo potrdil. Vse odgovore glede EC/AT, ki niso pravilno preverjeni, zavrne. V takih primerih bi morala poslati nov zahtevek za EC/AT.
4.4.2.Objava potrdila
(153)Potrdila TLM in njihova vezna potrdila se dajo na razpolago vsem udeležencem preko CPOC.
(154)Potrdila korenskega CA objavi CPOC preko ECTL, ki ga podpiše TLM.
(155)Potrdila podrejenih CA (EA in AA) objavi korenski CA.
(156)EC in AT se ne objavijo.
4.4.3.Obvestilo o izdaji potrdila
Obvestilo o izdaji potrdila se ne uporablja.
4.5.Uporaba para ključev in potrdila
4.5.1.Uporaba zasebnega ključa in potrdila
4.5.1.1.Uporaba zasebnega ključa in potrdila za TLM
(157)TLM s svojimi zasebnimi ključi podpisuje svoja lastna potrdila (potrdila TLM in vezna potrdila) ter ECTL.
(158)Udeleženci PKI s potrdilom TLM potrjujejo ECTL in potrjujejo verodostojnost TLM.
4.5.1.2.Uporaba zasebnega ključa in potrdil za korenske CA
(159)Korenski CA s svojimi zasebnimi ključi podpisujejo svoja lastna potrdila, CRL, vezna potrdila in potrdila EA/AA.
(160)Udeleženci PKI s potrdili korenskega CA potrjujejo povezana potrdila EA in AA, vezna potrdila in CRL.
4.5.1.3.Uporaba zasebnega ključa in potrdila za EA in AA
(161)EA svoje zasebne ključe uporabljajo za podpisovanje EC in dešifriranje zahtevka za pridobitev potrdila.
(162)Potrdila EA se uporabljajo za potrditev podpisa povezanih EC in šifriranje zahtevkov za EC in AT s strani EE, kot je opredeljeno v [1].
(163)AA svoje zasebne ključe uporabljajo za podpisovanje AT in dešifriranje zahtevka za AT.
(164)Potrdila AA se uporabljajo za potrditev povezanih AT in šifriranje zahtevkov za EC in AT, kot je opredeljeno v [1].
4.5.1.4.Uporaba zasebnega ključa in potrdila za končni subjekt
(165)EE uporabljajo zasebni ključ, ki ustreza veljavni EC, za podpis novega zahtevka za pridobitev potrdila, kot je opredeljeno v [1]. Novi zasebni ključ se uporablja za tvorbo notranjega podpisa v zahtevku za dokazilo imetništva zasebnega ključa, ki ustreza novemu javnem ključu EC.
(166)EE uporabljajo zasebni ključ, ki ustreza veljavni EC, za podpis zahtevka za avtorizacijo, kot je opredeljeno v [1]. Zasebni ključ, ki ustreza novemu AT, bi bilo treba uporabljati za tvorbo notranjega podpisa v zahtevku za dokazilo imetništva zasebnega ključa, ki ustreza novemu javnem ključu AT.
(167)EE uporablja zasebni ključ, ki ustreza veljavnemu AT, za podpis sporočil C-ITS, kot je opredeljeno v [5].
4.5.2.Uporaba javnega ključa in potrdila odvisne strani
(168)Odvisne strani uporabljajo zaupanja vredno verigo potrdil in povezane javne ključe za namene, navedene v potrdilih, in za preverjanje verodostojnosti zaupanja vredne skupne identitete EC in AT.
(169)Odvisna stran ne uporablja potrdil korenskega CA, EA in AA ter EC in AT, ne da bi jih predhodno preverila.
4.6.Podaljšanje potrdila
Ni dovoljeno.
4.7.Obnova potrdila (re-key)
4.7.1.Razlogi za obnovo potrdila
(170)Postopek obnove se izvede, če potrdilu poteče življenjska doba ali če zasebnemu ključu poteče doba uporabnosti, razmerje zaupanja do CA pa še vedno obstaja. V vseh primerih se ustvari in izda nov par ključev in ustrezno potrdilo.
4.7.2.Kdo lahko zahteva obnovo
4.7.2.1.Korenski CA
(171)Korenski CA ne zahteva obnove. Postopek obnove je pri korenskem CA notranji postopek, ker je njegovo potrdilo z lastnim podpisom. Korenski CA izvede obnovo z veznimi potrdili ali novo izdajo (gl. oddelek 4.3.1.1).
4.7.2.2.TLM
(172)TLM ne zahteva obnove. Postopek obnove je pri TLM notranji postopek, ker je potrdilo TLM z lastnim podpisom.
4.7.2.3.EA in AA
(173)Zahtevek za potrdilo podrejenega CA je treba vložiti pravočasno, da bi bila novo potrdilo podrejenega CA in delujoč par ključev podrejenega CA na voljo pred potekom trenutnega zasebnega ključa podrejenega CA. Pri datumu vložitve je treba upoštevati tudi čas, potreben za odobritev.
4.7.2.4.Postaja C-ITS
Se ne uporablja.
4.7.3.Postopek obnove
4.7.3.1.Potrdilo TLM
(174)TLM se odloči za obnovo na podlagi zahtev iz oddelkov 6.1 in 7.2. Postopek je podrobno opisan v njegovi CPS.
(175)TLM izvede postopek obnove pravočasno, da bi bilo mogoče novo potrdilo TLM in vezno potrdilo razposlati vsem udeležencem, še preden poteče trenutno potrdilo TLM.
(176)TLM uporablja vezna potrdila za obnovo in za zagotavljanje razmerja zaupanja novega potrdila z lastnim podpisom. Novoustvarjeno potrdilo TLM in vezno potrdilo se preneseta na CPOC.
4.7.3.2.Potrdilo korenskega CA
(177)Korenski CA se odloči za obnovo na podlagi zahtev iz oddelkov 6.1.5 in 7.2. Postopek bi moral biti določen v njegovi CPS.
(178)Korenski CA izvede postopek obnove pravočasno (pred potekom potrdila korenskega CA), da bi bilo mogoče novo potrdilo vpisati v ECTL še pred začetkom veljavnosti potrdila korenskega CA (gl. oddelek 5.6.2). Postopek obnove se izvede z veznimi potrdili ali kot začetni zahtevek.
4.7.3.3.Potrdila EA in AA
(179)EA in AA zahtevata novo potrdilo, kot sledi:
Korak
|
Označba
|
Zahtevek za obnovo
|
1.
|
Ustvaritev para ključev
|
Podrejeni CA (EA in AA) ustvarijo nove pare ključev v skladu z oddelkom 6.1.
|
2.
|
Ustvaritev zahtevka za potrdilo in notranjega podpisa
|
Podrejeni CA ustvari zahtevek za potrdilo iz novoustvarjenega javnega ključa ob upoštevanju sheme določanja imen (subject_info) iz oddelka 3, podpisnega algoritma, posebna dovoljenja za storitve (Service Specific Permissions, SSP) in neobveznega dodatnega parametra ter ustvari notranji podpis z ustreznim novim zasebnim ključem. Če je potreben šifrirni ključ, mora CA dokazati tudi, da ima ustrezen zasebni dešifrirni ključ.
|
3.
|
Ustvarjanje zunanjega podpisa
|
Celotni zahtevek se podpiše s trenutno veljavnim zasebnim ključem, s čimer se zagotovi verodostojnost podpisanega zahtevka.
|
4.
|
Pošiljanje zahtevka korenskemu CA
|
Podpisani zahtevek se pošlje ustreznemu korenskemu CA.
|
5.
|
Preverjanje zahtevka
|
Ustrezni korenski CA preveri celovitost in verodostojnost zahtevka. Najprej preveri zunanji podpis. Če je rezultat preverjanja pozitiven, preveri notranji podpis. Če obstaja dokazilo o imetništvu zasebnega dešifrirnega ključa, preveri tudi to dokazilo.
|
6.
|
Sprejetje ali zavrnitev zahtevka
|
Če je rezultat vseh preverjanj pozitiven, korenski CA odobri zahtevek; v nasprotnem primeru ga zavrne.
|
7.
|
Ustvarjanje in izdaja potrdila
|
Korenski CA ustvari novo potrdilo in ga razpošlje podrejenim CA, ki ga zahtevajo.
|
8.
|
Pošiljanje odgovora
|
Podrejeni CA pošlje korenskemu CA sporočilo o statusu (tj. ali je bilo potrdilo prejeto ali ne).
|
Preglednica 3: postopek obnove za EA in AA
(180)Korenski CA se ob samodejni obnovi za podrejene CA prepriča, da ima vložnik zahtevka zasebni ključ. Uporabljajo se ustrezni protokoli za dokazovanje imetništva zasebnih dešifrirnih ključev, npr. v skladu z opredelitvijo v standardih RFC 4210 in 4211. Pri zasebnih ključih za podpisovanje se uporablja notranji podpis.
4.7.3.4.Potrdila postaje C-ITS
Se ne uporablja za AT.
4.8.Sprememba potrdila
Ni dovoljena.
4.9.Preklic in začasna razveljavitev potrdila
Glej oddelek 7.
4.10.Preverjanje statusa potrdila
4.10.1.Operativne značilnosti
Se ne uporablja.
4.10.2.Razpoložljivost storitev
Se ne uporablja.
4.10.3.Druge možnosti
Se ne uporablja.
4.11.Prekinitev razmerja med imetnikom in izdajateljem
Se ne uporablja.
4.12.Hranjenje kopij zasebnih ključev pri zunanjih subjektih in povrnitev
4.12.1.Naročnik
4.12.1.1.Kateri par ključev se lahko hrani pri zunanjih subjektih
Se ne uporablja.
4.12.1.2.Kdo lahko vloži zahtevek za povrnitev
Se ne uporablja.
4.12.1.3.Postopek povrnitve in odgovornosti pri njem
Se ne uporablja.
4.12.1.4.Preverjanje istovetnosti in verodostojnosti
Se ne uporablja.
4.12.1.5.Odobritev ali zavrnitev zahtevkov za povrnitev
Se ne uporablja.
4.12.1.6.Postopka KEA in KRA med povrnitvijo para ključev
Se ne uporablja.
4.12.1.7.Razpoložljivost KEA in KRA
Se ne uporablja.
4.12.2.Ovijanje ključa seje ter politike in prakse povrnitve
Se ne uporablja.
5.Upravljanje in varnostni nadzor infrastrukture
(181)PKI je sestavljen iz korenskega CA, EA/AA, CPOC in TLM, vključno z njihovimi sestavnimi deli IKT (npr. omrežja in strežniki).
(182)V tem oddelku je subjekt, ki je odgovoren za katerega od elementov PKI, določen z elementom samim. Z drugimi besedami: stavek „Za izvedbo revizije je odgovoren CA.“ je enakovreden stavku „Za izvedbo revizije je odgovoren subjekt ali osebje, ki upravlja CA.“
(183)Izraz „elementi modela zaupanja C-ITS“ zajema korenski CA, TLM, EA/AA, CPOC in varno omrežje.
5.1.Fizično varovanje
(184)Vse dejavnosti modela zaupanja C-ITS se izvajajo v fizično varovanem okolju, ki odvrača od nepooblaščene uporabe občutljivih informacij in sistemov, dostopa do njih ali njihovega razkritja ter to preprečuje in odkriva. Elementi modela zaupanja C-ITS uporabljajo fizično varovanje v skladu s standardoma ISO 27001 in ISO 27005.
(185)Subjekti, ki upravljajo elemente modela zaupanja C-ITS, v svojih CPS opišejo fizično in postopkovno varovanje ter nadzor osebja. CPS zajema zlasti informacije o lokaciji in konstrukciji zgradb ter njihovem fizičnem varovanju, s katerim se zagotavlja nadzorovan dostop do vseh prostorov, ki se uporabljajo v objektu subjektov modela zaupanja C-ITS.
5.1.1.Lokacija in zgradba overitelja
5.1.1.1.Korenski CA, CPOC, TLM
(186)Lokacija in zgradba objekta, v katerem se nahajajo oprema in podatki korenskega CA, CPOC in TLM (HSM, aktivacijski podatki, varnostna kopija para ključev, računalnik, dnevnik, skript za generiranje ključev, zahtevek za potrdilo itd.) morajo izpolnjevati zahteve za stavbe, ki se uporabljajo za hranjenje dragocenih in občutljivih informacij. Korenski CA deluje na posebnem fizičnem območju, ki je ločeno od fizičnih območij drugih sestavnih delov PKI.
(187)Korenski CA, CPOC in TLM izvajajo politike in postopke, s katerimi poskrbijo za ohranjanje visoke ravni varnosti v fizičnem okolju, v katerem je nameščena oprema korenskega CA, in tako zagotovijo, da:
·je izolirana od omrežij izven modela zaupanja;
·je razdeljena v niz (vsaj dveh) varnih fizičnih območij s stopnjevano varnostjo;
·občutljivi podatki (HSM, varnostna kopija para ključev, aktivacijski podatki itd.) so shranjeni v posebnem sefu na posebnem fizičnem območju z večkratnim nadzorom dostopa.
(188)Uporabljene varnostne tehnike so zasnovane tako, da lahko vzdržijo veliko število in kombinacijo različnih oblik napada. Uporabljeni mehanizmi zajemajo vsaj:
·alarmni sistemi za varovanje območja, sistem televizije zaprtega kroga, ojačani zidovi in javljalniki gibanja;
·dvofaktorska avtentikacija (npr. pametna kartica in koda PIN) za vsako osebo in izkaznica za vstop v objekt korenskega CA in varno fizično varovano območje ter izstop iz njiju.
(189)Korenski CA, CPOC in TLM imajo pooblaščeno osebje, ki neprekinjeno nadzoruje objekt, v katerem se nahaja oprema, in sicer po načelu 7x24x365. Operativno okolje (npr. fizični objekt) ne sme nikoli ostati brez nadzora. Osebje operativnega okolja nikoli nima dostopa do varnih območij korenskih CA ali podrejenih CA, če ni pooblaščeno za to.
5.1.1.2.EA/AA
(190)Uporabljajo se iste določbe oddelka 5.1.1.1.
5.1.2.Fizični dostop
5.1.2.1.Korenski CA, CPOC, TLM
(191)Oprema in podatki (HSM, aktivacijski podatki, varnostna kopija para ključev, računalnik, dnevnik, skript za generiranje ključev, zahtevek za potrdilo itd.) so vedno zavarovani pred nepooblaščenim dostopom. Fizični mehanizmi za varovanje opreme morajo vsaj:
·ves čas ročno ali elektronsko nadzirati, da ne bi prišlo do nepooblaščenega vdora;
·zagotoviti, da ni dovoljen nepooblaščen dostop do strojne opreme in aktivacijskih podatkov;
·zagotoviti, da so vsi odstranljivi nosilci podatkov in papirji z občutljivimi podatki v obliki golega besedila varno shranjeni;
·zagotoviti, da posameznika, ki vstopi na varovano območje in ki je trajno nepooblaščen, ves čas nadzoruje pooblaščena zaposlena oseba objekta korenskega CA, CPOC in TLM;
·zagotoviti, da se vodi dnevnik dostopov in da se redno pregleduje;
·zagotoviti najmanj dva sloja stopnjevane varnosti, npr. na ravni območja, zgradbe in prostora za delovanje;
·zahtevati najmanj dva fizična nadzora dostopa z zaupanja vredno vlogo za kriptografski HSM in aktivacijske podatke.
(192)Če bo objekt, v katerem se nahaja oprema, ostal brez nadzora, se izvede varnostni pregled objekta. Pri tem pregledu se preveri vsaj:
·da je oprema v stanju, ki je ustrezno za trenutni način delovanja;
·da je pri sestavnih delih, ki niso priključeni na omrežje, vsa oprema ugasnjena.
·da so vsi varnostni vsebniki (ovojnica z zaščito pred nedovoljenim posegom, sef itd.) ustrezno zavarovani;
·da sistemi fizičnega varovanja (npr. ključavnice, pokrovi zračnikov, elektrika) pravilno delujejo;
·da je območje zavarovano pred nepooblaščenim dostopom.
(193)Odstranljive kriptografske module je treba pred hrambo deaktivirati. Kadar se taki moduli ne uporabljajo, se moduli in aktivacijski podatki za dostop do njih ali njihov zagon shranijo v sefu. Aktivacijske podatke si osebe zapomnijo ali pa se zabeležijo in shranijo s stopnjo varnosti, ki je primerljiva s kriptografskim modulom. Ne hranijo se skupaj s kriptografskim modulom, da ne bi imela samo ena oseba dostopa do zasebnega ključa.
(194)Za taka preverjanja se izrecno naloži odgovornost osebi ali skupini zaupanja vrednih vlog. Če je odgovorna skupina ljudi, se vodi dnevnik, v katerem je za vsako preverjanje zabeležena oseba, ki ga je opravila. Če v objektu niso vedno prisotne osebe, zadnja oseba, ki odide, parafira odjavni seznam, v katerem se navede datum in čas ter se potrdi, da so vsi fizični mehanizmi varovanja nameščeni in aktivirani.
5.1.2.2.EA/AA
(195)Uporabljajo se iste določbe oddelka 5.1.2.1.
5.1.3.Napajanje in prezračevanje
(196)Varni objekti elementov modela zaupanja C-ITS (korenski CA, CPOC, TLM, EA in AA) so opremljeni z zanesljivim dostopom do električne energije, ki zagotavlja delovanje brez motenj ali s samo manjšimi motnjami. Potrebne so primarne in rezervne naprave za primer izpada zunanje električne energije in za nemoteno zaustavitev opreme modela zaupanja C-ITS v primeru nezadostnega napajanja. Objekti modela zaupanja C-ITS so opremljeni s sistemi ogrevanja/zračenja/klimatizacije, da vzdržujejo temperaturo in relativno vlažnost opreme modela zaupanja C-ITS v razponu, ki omogoča delovanje. Načrt in postopki izvajanja takih zahtev se natančno opišejo v CPS elementa modela zaupanja C-ITS.
5.1.4.Zaščita pred poplavo
(197)Varni objekti elementov modela zaupanja C-ITS (korenski CA, CPOC, TLM, EA in AA) so zaščiteni tako, da je učinek izpostavljenosti vodi čim manjši. Zato v bližini ne bi smelo biti vodovodnih in odtočnih cevi. Načrt in postopki izvajanja takih zahtev se natančno opišejo v CPS elementa modela zaupanja C-ITS.
5.1.5.Zaščita pred požari
(198)Za preprečevanje škodljivega vpliva plamenov in dima so varni objekti elementov modela zaupanja C-ITS (korenskega CA, CPOC, TLM, EA in AA) ustrezno konstruirani in opremljeni; izvajajo se postopki za odpravljanje nevarnosti v zvezi z ognjem. Shranjeni nosilcev podatkov morajo biti zaščiteni pred ognjem z ognjevarnimi zabojniki.
(199)Elementi modela zaupanja C-ITS varujejo nosilce podatkov z varnostnimi kopijami kritičnih podatkov o sistemu ali drugih občutljivih informacij pred okoljskimi nevarnostmi in nepooblaščeno uporabo takih nosilcev podatkov, nepooblaščenim dostopom do njih ali njihovega nepooblaščenega razkritja. Načrt in postopki izvajanja takih zahtev se natančno opišejo v CPS elementa modela zaupanja C-ITS.
5.1.6.Hramba nosilcev podatkov
(200)Z nosilci podatkov, ki se uporabljajo v elementih modela zaupanja C-ITS (korenski CA, CPOC, TLM, EA in AA), se ravna varno, tako da so zaščiteni pred poškodbo, tatvino in nepooblaščenim dostopom. Izvajajo se postopki za ravnanje z nosilci podatkov, s katerimi se prepreči zastarelost ali poslabšanje kakovosti nosilcev podatkov v obdobju hrambe podatkov.
(201)Občutljivi podatki se zaščitijo pred dostopom, do katerega bi prišlo zaradi ponovne uporabe nosilcev podatkov (npr. izbrisane datoteke) in s katerim bi nepooblaščeni uporabniki dobili dostop do občutljivih podatkov.
(202)Vodi se seznam inventarja vseh sredstev za shranjevanje podatkov, zahteve za zaščito teh sredstev pa so usklajene z analizo tveganja. Načrt in postopki izvajanja takih zahtev se natančno opišejo v CPS elementa modela zaupanja C-ITS.
5.1.7.Odstranjevanje odpadkov
(203)Elementi modela zaupanja C-ITS (korenski CA, CPOC, TLM, EA in AA) izvajajo postopke za varno in nepovratno odstranjevanje odpadkov (papirja, nosilcev podatkov in drugih odpadkov), s katerimi preprečijo nepooblaščeno uporabo odpadkov, ki vsebujejo zaupne/zasebne podatke, dostop do takih odpadkov ali njihovo razkritje. Vsi nosilci podatkov, ki se uporabljajo za shranjevanje občutljivih informacij, kot so ključi, aktivacijski podatki ali datoteke, se pred zavrženjem uničijo. Načrt in postopki izvajanja takih zahtev se natančno opišejo v CPS elementa modela zaupanja C-ITS.
5.1.8.Hramba na oddaljeni lokaciji
5.1.8.1.Korenski CA, CPOC in TLM
(204)Po začetku delovanja korenskega CA, CPOC in TLM in po vsaki ustvaritvi novega para ključev se naredi celotna varnostna kopija sestavnih delov korenskega CA, CPOC in TLM, in sicer brez povezave z omrežjem. Redno se ustvarjajo varnostne kopije bistvenih poslovnih informacij (par ključev in CRL) ter programske opreme. Na voljo so ustrezni objekti za hrambo varnostnih kopij, s katerimi se zagotovi, da je mogoče po nesreči ali odpovedi nosilcev podatkov obnoviti vse bistvene poslovne informacije in programsko opremo. Ureditve ustvarjanja varnostnih kopij za posamezne sisteme se redno preizkušajo, da bi zagotovili, da izpolnjujejo zahteve iz načrta neprekinjenega poslovanja. Vsaj ena celotna varnostna kopija je shranjena na oddaljeni lokaciji (okrevalni načrt). Varnostna kopija je shranjena na lokaciji, na kateri sta fizično varovanje in postopkovni nadzor primerljiva s tistima, ki veljata za delujoči sistem PKI.
(205)Za dostop do podatkov iz varnostne kopije veljajo iste zahteve kot za podatke iz delujočega sistema. Podatki v varnostni kopiji se šifrirajo in shranijo na oddaljeni lokaciji. V primeru izgube vseh podatkov se podatki, potrebni za ponovno vzpostavitev delovanja korenskega CA, CPOC in TLM, v celoti obnovijo iz varnostne kopije.
(206)Varnostna kopija gradiva, podpisanega z zasebnimi ključi korenskega CA, CPOC in TLM se ne ustvarja s standardnimi mehanizmi za ustvarjanje varnostnih kopij, temveč s funkcijo kriptografskega modula za ustvarjanje varnostnih kopij.
5.1.8.2.EA/AA
(207)Za ta oddelek se uporabljajo postopki, opisani v oddelku 5.1.8.1.
5.2.Postopkovni nadzor
V tem oddelku so opisane zahteve za vloge, naloge in ugotavljanje istovetnosti osebja.
5.2.1.Zaupanja vredne vloge
(208)Za „zaupanja vredne osebe“ se štejejo zaposleni, zunanji izvajalci in svetovalci, ki so jim bile dodeljene zaupanja vredne vloge. Osebe, ki želijo postati zaupanja vredne osebe in tako dobiti zaupanja vreden položaj, izpolnjujejo zahteve za preverjanje osebja iz te potrditvene politike.
(209)Zaupanja vredne osebe uporabljajo oziroma nadzorujejo preverjanje verodostojnosti ali kriptografske dejavnosti, ki lahko bistveno vplivajo na:
·preverjanje podatkov v prošnjah za potrdila;
·odobritev, zavrnitev in siceršnjo obravnavo prošenj za potrdila ter zahtevkov za preklic ali podaljšanje;
·izdajanje ali preklic potrdil, tudi glede tega, da ima osebje dostop do delov repozitorija z omejenim dostopom, ali ravnanja s podatki o naročnikih ali njihovimi zahtevki.
(210)Zaupanja vredne vloge zajemajo med drugim:
·storitve za stranke;
·upravljanje sistema;
·posebni inženiring;
·vodstveno osebje, zadolženo za upravljanje zanesljivosti infrastrukture.
(211)CA vse zaupanja vredne vloge jasno opiše v svoji CPS.
5.2.2.Število oseb za posamezne vloge
(212)Elementi modela zaupanja C-ITS vzpostavijo, vzdržujejo in izvajajo stroge postopke nadzora, s katerimi zagotovijo nezdružljivost nalog, ki izhajajo iz zaupanja vrednih vlog, in poskrbijo za to, da je za opravljanje občutljivih nalog potrebnih več oseb. Elementi modela zaupanja C-ITS (TLM, CPOC, korenski CA, EA in AA) bi morali biti skladni s [4] iz z zahtevami iz naslednjih odstavkov.
(213)Vzpostavljeni so postopki politike in nadzora, s katerimi se zagotovi nezdružljivost nalog na podlagi delovnih pristojnosti. Za najobčutljivejše naloge, kot dostop do kriptografske strojne opreme (HSM) CA in gradiva, podpisanega s ključi, povezanega z njo, mora biti potrebna avtorizacija več zaupanja vrednih oseb.
(214)Ti postopki notranjega nadzora so zasnovani tako, da zagotovijo, da sta za fizični ali logični dostop do naprave potrebni najmanj dve zaupanja vredni osebi. Omejitve dostopa do kriptografske strojne opreme CA mora dosledno izvajati več zaupanja vrednih oseb skozi celoten življenjski cikel, od prejetja in pregleda do končnega logičnega in/ali fizičnega uničenja. Ko je modul aktiviran z operativnimi ključi, se izvedejo nadaljnji nadzori dostopa, s katerimi se ohrani deljen nadzor nad fizičnim in logičnim dostopom do naprave.
5.2.3.Preverjanje istovetnosti in verodostojnosti za opravljanje posameznih vlog
(215)Pri vseh osebah, ki jim je bila dodeljena vloga, kot je opisana v tej CP, se preveri istovetnost in verodostojnost, s čimer je zagotovljeno, da jim njihova vloga omogoča opravljanje njihovih nalog v PKI.
(216)Elementi modela zaupanja C-ITS preverijo in potrdijo istovetnost in pooblastila vseh članov osebja, ki želijo postati zaupanja vredne osebe, še preden:
·jim izdajo naprave za vstop in jim dovolijo dostop do zahtevanih objektov;
·jim dajo elektronske poverilnice za dostop do sistemov CA in opravljanje posameznih funkcij v njih.
(217)Mehanizmi za ugotavljanje istovetnosti in verodostojnosti posameznikov so opisani v CPS.
5.2.4.Nezdružljivost vlog
(218)Vloge, pri katerih morajo biti naloge ločene, so med drugim:
·odobritev, zavrnitev in preklic zahtevkov ter siceršnja obdelava prošenj za potrdilo CA;
·ustvarjanje, izdajanje in uničenje potrdila CA.
(219)Nezdružljivost vlog se lahko uveljavlja z opremo PKI, postopki ali obojim. Nobenemu posamezniku se brez odobritve korenskega CA ne sme dodeliti več kot ena identiteta.
(220)Tisti del korenskega CA in CA, ki je zadolžen za ustvarjanje potrdil in upravljanje preklica, je neodvisen od drugih organizacij, kar zadeva njegove odločitve v zvezi z vzpostavitvijo, določanjem, vzdrževanjem in prenehanjem storitev v skladu s potrditvenimi politikami, ki se uporabljajo. Zlasti osebje na višjih vodstvenih položajih, osebje na višjih položajih in osebje z zaupanja vrednimi vlogami ne sme biti izpostavljeno komercialnim, finančnim ali drugim pritiskom, ki bi lahko okrnili zaupanje v storitve, ki jih opravlja.
(221)EA in AA, ki oskrbujeta premične postaje C-ITS, sta ločena operativna subjekta z ločeno infrastrukturo IT in osebjem za upravljanje IT. EA in AA si v skladu z GDPR ne izmenjujeta osebnih podatkov, razen za avtorizacijo zahtevkov za AT. Podatke v zvezi z odobritvijo zahtevkov za AT prenašata samo preko posebnega varnega vmesnika s pomočjo protokola za potrditev avtorizacije iz [1]. Uporabljajo se lahko še drugi protokoli pod pogojem, da se izvaja [1].
(222)Dnevniki, ki jih hranita EA in AA, se lahko uporabljajo samo za preklic neustrezno delujočih EC, in sicer na podlagi AT v prestreženih zlonamernih sporočilih CAM/DENM. Ko se ugotovi, da je sporočilo CAM/DENM zlonamerno, AA poišče potrditveni ključ AT v svojih dnevnikih izdaje in pošlje EA zahtevek za preklic, ki vsebuje šifriran podpis na podlagi zasebnega ključa EC, ki je bil uporabljen pri izdaji AT. Vsi dnevniki morajo biti ustrezno zaščiteni pred dostopom nepooblaščenih oseb in jih ni dovoljeno posredovati drugim subjektom ali organom.
Opomba: v času priprave te različice CP opis funkcija za preverjanje neustreznega delovanja ni opredeljena. Funkcija za preverjanje neustreznega delovanja bo predvidoma opisana v prihodnjih različicah politike.
5.3.Nadzor nad osebjem
5.3.1.Potrebne kvalifikacije in izkušnje osebja ter njegova primernost
(223)Elementi modela zaupanja C-ITS zaposlujejo zadostno število osebja s strokovnim znanjem, izkušnjami in kvalifikacijami, ki so potrebni za nudena dela in storitve. Osebje PKI te zahteve izpolnjuje s formalnim usposabljanjem in poverilnicami, dejanskimi izkušnjami ali kombinacijo obeh. Zaupanja vredne vloge in odgovornosti, kot so navedene v CPS, so dokumentirane v opisih delovnih mest in jasno določene. Opisi delovnih mest osebja podizvajalcev pri PKI so opredeljeni tako, da se zagotovi ločevanje vlog in pooblastil, občutljivost položaja pa se določi na podlagi nalog in ravni dostopa, preverjanja primernosti in usposabljanja zaposlenih ter ozaveščanja.
5.3.2.Preverjanje primernosti osebja
(224)Elementi modela zaupanja C-ITS opravljajo preverjanja primernosti osebja, ki želijo postati osebe, vredne zaupanja. Preverjanja primernosti se za osebje na zaupanja vrednih položajih ponovijo najmanj vsakih pet let.
(225)Dejavniki, razkriti v preverjanjih primernosti, ki se jih lahko šteje za razloge za zavračanje kandidatov za zaupanja vredne položaje ali za ukrepanje proti obstoječi osebi, vredni zaupanja, vključujejo med drugim naslednje:
·napačno prikazovanje podatkov s strani kandidata ali osebe, vredne zaupanja;
·zelo neugodna ali nezanesljiva strokovna priporočila;
·nekatere kazenske obsodbe;
·znake pomanjkanja finančne vestnosti.
(226)Poročila, ki vsebujejo take informacije, ovrednoti osebje službe za človeške vire, ki sprejme razumne ukrepe glede na vrsto, obseg in pogostost vedenja, ki ga razkrije preverjanje primernosti. Taki ukrepi lahko vključujejo ukrepe različne teže, vključno s preklicem ponudb za zaposlitev kandidatom za zaupanja vredne pozicije ali prenehanje delovnega razmerja obstoječih oseb, vrednih zaupanja. Informacije, razkrite v preverjanju primernosti, ki so podlaga za tak ukrep, se uporabljajo po veljavnem pravu.
(227)Preiskovanje primernosti oseb, ki želijo postati osebe, vredne zaupanja, vključuje med drugim naslednje:
·potrditev pretekle zaposlitve;
·preverjanje strokovnih priporočil za zaposlitev v obdobju najmanj petih let;
·potrditev najvišje ali najustreznejše pridobljene stopnje izobrazbe;
·preverjanje kazenske evidence.
5.3.3.Usposabljanje osebja
(228)Elementi modela zaupanja C-ITS svojemu osebju zagotovijo potrebno usposabljanje za strokovno in zadovoljivo izpolnjevanje njihovih odgovornosti v zvezi z dejavnostmi CA.
(229)Programi usposabljanja se redno pregledujejo, usposabljanje pa obravnava zadeve, ki so relevantne za funkcije, ki jih opravlja osebje.
(230)Programi usposabljanja obravnavajo zadeve, ki so relevantne za posamezno okolje pripravnika, vključno:
·z varnostnimi načeli in mehanizmi elementov modela zaupanja C-ITS;
·z različicami strojne in programske opreme, ki se uporablja;
·z vsemi nalogami, ki naj bi jih oseba opravljala ter notranjimi in zunanjimi postopki poročanja in zaporedji;
·s poslovni procesi in poteki dela;
·s postopkom in poročanjem v primeru vdorov in zlorabe;
·z okrevalnim načrtom in neprekinjenim poslovanjem po nesreči;
·z zadostnim znanjem na področju IT.
5.3.4.Zahteve za redna ponovna usposabljanja
(231)Osebe, ki so jim dodeljene zaupanja vredne vloge morajo redno osveževati znanje, pridobljeno z usposabljanjem, z uporabo okolja za usposabljanje. Usposabljanje je treba ponoviti, kadar je potrebno, in najmanj vsaki dve leti.
(232)Elementi modela zaupanja C-ITS svojemu osebju zagotovijo osvežitveno usposabljanje in posodobitve v obsegu in pogostosti, ki sta potrebna, da vzdržujejo zahtevano raven strokovnosti za strokovno in zadovoljivo izpolnjevanje delovnih nalog.
(233)Posamezniki z zaupanja vrednimi vlogami so seznanjeni s spremembami delovanja PKI, kot je ustrezno. Vsako pomembno spremembo delovanja spremlja načrt za usposabljanje (ozaveščanje), izvajanje tega načrta pa se dokumentira.
5.3.5.Menjava nalog
(234)Ni določena, če so zagotovljene tehnične spretnosti, izkušnje in pravice dostopa. Upravljavci elementov modela zaupanja C-ITS zagotovijo, da spremembe osebja ne vplivajo na varnost sistema.
5.3.6.Sankcije za nedovoljena dejanja
(235)Elementi vsakega modela zaupanja C-ITS morajo razviti formalen disciplinski postopek, s katerim se zagotovi ustrezno sankcioniranje nedovoljenih dejanj. V resnih primerih je treba preklicati dodeljene vloge in ustrezna pooblastila.
5.3.7.Zahteve za zunanje izvajalce
(236)Elementi modela zaupanja C-ITS lahko neodvisnim izvajalcem ali svetovalcem dovolijo, da postanejo osebe, vredne zaupanja, samo v obsegu, ki je potreben za jasno opredeljeno razmerje zunanjega izvajanja, in pod pogojem, da subjekt zaupa izvajalcem ali svetovalcem v enaki meri, kot če bi bili zaposleni, ter da izpolnjujejo zahteve, ki veljajo za zaposlene.
(237)V nasprotnem primeru bodo neodvisni izvajalci in svetovalci imeli dostop do infrastrukture javnih ključev C-ITS le, če so v spremstvu in pod neposrednim nadzorom oseb, vrednih zaupanja.
5.3.8.Dostop osebja do dokumentacije
(238)Elementi modela zaupanja C-ITS svojemu osebju zagotovijo usposabljanje in dostop do dokumentacije, ki ju potrebujejo za strokovno in zadovoljivo izpolnjevanje delovnih nalog.
5.4.Vodenje dnevnika beleženih dogodkov
(239)V tem oddelku so določene zahteve v zvezi z vrstami dogodkov, ki se zabeležijo, in vodenjem dnevnikov beleženih dogodkov.
5.4.1.Vrste dogodkov, ki jih mora vsak CA zabeležiti in o njih poročati
(240)Predstavnik CA redno pregleduje dnevnike, dogodke in postopke CA.
(241)Elementi modela zaupanja C-ITS zabeležijo naslednje vrste revizijskega dogodka (če je ustrezno):
·fizični dostop do objekta – dostop fizičnih oseb do objektov bo zabeležen s shranjevanjem zahtevkov za dostop prek pametnih kartic. Za vsak ustvarjen zapis se ustvari dogodek;
·upravljanje zaupanja vrednih vlog – zabeležene bodo vse spremembe opredelitve in ravni dostopa različnih vlog, vključno s spremembo lastnosti vlog. Za vsak ustvarjen zapis se ustvari dogodek;
·logični dostop – dogodek bo ustvarjen, ko bo subjekt (npr. program) imel dostop do občutljivih območij (tj. omrežij in strežnikov);
·upravljanje varnostnih kopij – dogodek se ustvari ob vsakem uspešnem ali neuspešnem dokončanju varnostne kopije;
·upravljanje dnevnikov – dnevniki bodo shranjeni. Dogodek se ustvari, kadar velikost dnevnika preseže določeno velikost;
·podatki iz postopka preverjanja pristnosti za naročnike in elemente modela zaupanja C-ITS – dogodki bodo ustvarjeni za vsak zahtevek naročnikov in elementov modela zaupanja C-ITS za preverjanje verodostojnosti;
·sprejem in zavrnitev zahtevkov za potrdila, vključno z ustvaritvijo in podaljšanjem potrdila – dogodek se ustvari periodično s seznamom sprejetih in zavrnjenih zahtevkov za potrdila iz zadnjih sedmih dni;
·registracija proizvajalca – dogodek bo ustvarjen, ko se registrira proizvajalec;
·registracija na postaji C-ITS – dogodek bo ustvarjen, ko se registrira postaja C-ITS;
·upravljanje HSM – dogodek bo ustvarjen, ko se zabeleži varnostna kršitev HSM;
·upravljanje IT in omrežij, če se nanašajo na sisteme PKI – dogodek se ustvari, ko se zaustavi ali ponovno zažene strežnik PKI;
·upravljanje varnosti (uspešni in neuspešni poskusi dostopa do sistema PKI, opravljeni ukrepi PKI in varnostnega sistema, spremembe varnostnega profila, zrušitve sistema, okvare strojne opreme in druge nepravilnosti, požarni zid in dejavnosti usmerjevalnika); ter vstopi in izstopi iz objektov PKI);
·podatki, povezani z dogodkom, se hranijo najmanj pet let, razen če se uporabljajo nacionalni predpisi.
(242)V skladu s splošno uredbo o varstvu podatkov dnevniki beleženih dogodkov ne omogočajo dostopa do podatkov, povezanih z zasebnostjo, v zvezi z zasebnimi vozili postaje C-ITS.
(243)Kadar je mogoče, se vpisi v dnevnik beleženih varnostnih dogodkov zberejo samodejno. Kadar ni, se uporabi dnevnik, papirna oblika ali drug fizični mehanizem. Vsi elektronski in neelektronski dnevniki beleženih varnostnih dogodkov se ohranijo in dajo na voljo med revidiranji skladnosti.
(244)Vsak dogodek, povezan z življenjskim ciklom potrdila, se zabeleži tako, da ga je mogoče pripisati osebi, ki ga je izvedla. Vsi podatki v zvezi z osebno identiteto so šifrirani in zaščiteni pred nepooblaščenim dostopom.
(245)Vsak zapis beleženega dogodka vključuje najmanj (zapisano samodejno ali ročno za vsak dogodek, ki ga je treba beležiti):
·vrsto dogodka (kot na zgornjem seznamu);
·zanesljiv datum in čas, ko se je dogodek zgodil;
·rezultat dogodka – uspeh ali neuspeh, kadar je to primerno;
·identiteto subjekta in/ali operaterja, ki je dogodek povzročil, če je ustrezno;
·identiteto subjekta, na katerega je dogodek naslovljen.
5.4.2.Pogostost pregledov dnevnikov beleženih dogodkov
(246)Dnevniki beleženih dogodkov se pregledajo kot odziv na opozorila, ki izhajajo iz na nepravilnosti in vdorov v okviru sistemov CA ter redno vsako leto.
(247)Obdelava dnevnikov beleženih dogodkov je sestavljena iz pregleda dnevnikov beleženih dogodkov in dokumentiranja razloga za vse pomembne dogodke v povzetku dnevnika beleženih dogodkov. Pregledi dnevnikov beleženih dogodkov vključujejo preverjanje, da se v dnevnik ni posegalo, pregled vseh dnevniških vnosov in preiskavo opozoril ali nepravilnosti v dnevnikih. Ukrepi, sprejeti na podlagi pregledov dnevnikov beleženih dogodkov, se dokumentirajo.
(248)Dnevnik beleženih dogodkov se arhivira najmanj enkrat tedensko. Upravitelj ga ročno arhivira, če je prazen prostor za dnevnik beleženih dogodkov pod pričakovano količino podatkov iz dnevnika beleženih dogodkov, ustvarjenih v danem tednu.
5.4.3.Čas hrambe dnevnikov beleženih dogodkov
(249)Dnevniški zapisi v zvezi z življenjskim ciklom potrdila se hranijo najmanj pet let po izteku ustreznega potrdila.
5.4.4.Zaščita dnevnikov beleženih dogodkov
(250)Za celovitost in zaupnost dnevnika beleženih dogodkov jamči mehanizem za nadzor dostopa, ki temelji na vlogah. Do notranjih dnevnikov beleženih dogodkov lahko dostopajo le upravljavci; uporabniki lahko do dnevnikov beleženih dogodkov, povezanih z življenjskim ciklom potrdila, dostopajo z ustreznim dovoljenjem prek spletne strani z uporabniškim imenom. Dostop je treba dovoliti s preverjanjem verodostojnosti, ki mora zajemati več uporabnikov (najmanj dva) in potekati na najmanj dveh stopnjah. Tehnično je treba zagotoviti, da uporabniki ne morejo dostopati do svojih dnevniških datotek.
(251)Vsak vnos v dnevnik se podpiše z uporabo materiala, podpisanega s ključi HSM.
(252)Dnevniki o dogodku, ki vsebujejo informacije, s katerimi se lahko identificira osebo, kot so informacije o zasebnem vozilu, so šifrirani tako, da jih lahko preberejo samo pooblaščene osebe.
(253)Dogodki se zabeležijo tako, da jih ni mogoče enostavno izbrisati ali uničiti (razen za prenos na medije za dolgoročno shranjevanje) v obdobju, za katero je treba voditi dnevnike.
(254)Dnevniki dogodkov so zaščiteni tako, da v času trajanja hrambe ostanejo berljivi.
5.4.5.Varnostne kopije dnevnikov beleženih dogodkov
(255)Dnevniki beleženih dogodkov in povzetki se varnostno kopirajo z mehanizmi podjetja za varnostno kopiranje pod nadzorom pooblaščenih zaupanja vrednih vlog in ločeno od ustvarjanja njihovih izvornih elementov. Varnostne kopije dnevnikov beleženih dogodkov so zaščitene z enako stopnjo zaupanja, kot se uporablja za izvorne dnevnike.
5.4.6.Zbiranje podatkov za dnevnike beleženih dogodkov (notranje ali zunanje)
(256)Oprema elementov modela zaupanja C-ITS aktivira procese beleženja ob zagonu sistema in jih deaktivira šele pri njegovi zaustavitvi. Če postopki beleženja dogodkov niso na voljo, element modela zaupanja C-ITS začasno preneha delovati.
(257)Ob koncu vsakega obdobja delovanja in pri obnovi potrdil, bi bilo treba kolektivni status opreme sporočiti upravitelju dejavnosti in organu upravljanja zadevnega elementa PKI.
5.4.7.Obveščanje povzročitelja dogodka
(258)Kadar se dogodek zabeleži v sistemu zbiranja podatkov v dnevnikih beleženih dogodkov, se s tem jamči, da je dogodek povezan z zaupanja vredno vlogo.
5.4.8.Ocena ranljivosti
(259)Vloga, odgovorna za izvajanje revizij in vlog, ki so odgovorne za delovanje sistema PKI v elementih modela zaupanja C-ITS, pojasnjuje vse pomembne dogodke v povzetku dnevnika beleženih dogodkov. Taki pregledi vključujejo preverjanje, da se v dnevnik ni posegalo in da ni prekinitve ali druge izgube beleženih podatkov, nato se na kratko pregleda vse dnevniške vnose, pri čemer se temeljiteje preišče kakršna koli opozorila ali nepravilnosti v dnevnikih. Ukrepi, sprejeti na podlagi teh pregledov, se dokumentirajo.
(260)Elementi modela zaupanja C-ITS:
·izvajajo organizacijsko in/ali tehnično preverjanje na podlagi zaznavanja in preprečevanja pod nadzorom elementov modela zaupanja C-ITS za zaščito sistemov PKI pred virusi in zlonamerno programsko opremo;
·dokumentirajo in spremljajo postopek popravljanja ranljivosti, ki obravnava identifikacijo, pregled, odgovor in odpravo ranljivosti;
·so lahko predmet pregleda ranljivosti ali tak pregled opravijo;
·po vsaki spremembi sistema ali omrežja, določeni s strani elementov modela zaupanja C-ITS kot pomembni za komponente PKI ter
·najmanj enkrat mesečno na javnih in zasebnih naslovih IP javnih in zasebnih naslovih, ki jih določijo CA, CPOC kot sistemi PKI,
·opravijo penetracijski preizkus na sistemih PKI najmanj enkrat letno in po nadgradnji infrastrukture ali aplikacij ali sprememb, ki jih elementi modela zaupanja C-ITS določijo kot pomembne za komponento PKI CA;
·za spletne sisteme, zabeležijo, da je vsak pregled ranljivosti in penetracijski preizkus opravila oseba ali subjekt (ali kolektivna skupina) z znanji in spretnostmi, orodji, strokovnim znanjem, etičnim kodeksom in neodvisnostjo, ki so potrebni za zanesljiv preizkus ranljivosti ali penetracije;
·sledijo in odpravljajo ranljivosti v skladu s politikami na področju kibernetske varnosti podjetij in metodologije za zmanjševanje tveganja.
5.5.Arhiviranje podatkov
5.5.1.Vrste arhiviranih podatkov
(261)Elementi modela zaupanja C-ITS arhivirajo zapise, ki so dovolj podrobni, da ugotovijo veljavnost podpisa in pravilno delovanje PKI. Arhivirajo se najmanj naslednji zapisi o dogodkih PKI (če je ustrezno):
·dnevnik dostopa do fizičnega objekta elementov modela zaupanja C-ITS (najmanj eno leto);
·upravljanje zaupanja vrednih vlog za elemente modela zaupanja C-ITS (najmanj deset let);
·dnevnik dostopa do IT za elemente modela zaupanja C-ITS (najmanj pet let);
·ustvaritev ključa CA, dnevnik uporabe in uničenja (najmanj pet let) (ne za TLM in CPOC);
·ustvaritev potrdila, dnevnik uporabe in uničenja (najmanj dve leti);
·dnevnik zahtevkov za CPA (najmanj dve leti);
·upravljanje aktivacijskih podatkov za elemente modela zaupanja C-ITS (najmanj pet let);
·dnevnik dostopa do IT in omrežja za elemente modela zaupanja C-ITS (najmanj pet let);
·dokumentacija PKI za elemente modela zaupanja C-ITS (najmanj pet let);
·varnostno poročilo o vdorih in reviziji za elemente modela zaupanja C-ITS (najmanj deset let);
·sistemska oprema, programska oprema in konfiguracija (najmanj pet let).
(262)Elementi modela zaupanja C-ITS naslednjo dokumentacijo v zvezi z zahtevki za potrdila in preverjanjem teh zahtevkov ter z vsemi potrdili TLM, korenskih CA in CA ter ustreznim CRL hranijo najmanj sedem let po prenehanju veljavnosti katerega koli potrdila, ki temelji na navedeni dokumentaciji:
·dokumentacija o reviziji PKI, ki jo hranijo elementi modela zaupanja C-ITS;
·dokumente CPS, ki jih hranijo elementi modela zaupanja C-ITS;
·pogodba med CPA in drugimi subjekti, ki jih hranijo elementi modela zaupanja C-ITS;
·potrdila (ali druge informacije o preklicu), ki jih hranita CA in TLM;
·evidenca zahtevkov za potrdilo v korenskem sistemu CA (se ne uporablja za TLM);
·drugi podatki ali aplikacije, ki zadostujejo za preverjanje vsebine arhiva;
·vse delo, ki ga opravijo elementi modela zaupanja C-ITS in revizorji skladnosti, ter vse delo v zvezi z njimi.
(263)Subjekt CA hrani vso dokumentacijo v zvezi z zahtevki za potrdila in njihovim preverjanjem ter z vsemi potrdili in njihovim preklicem najmanj sedem let po prenehanju veljavnosti katerega koli potrdila, ki temelji na navedeni dokumentaciji:
5.5.2.Čas hrambe
(264)Brez poseganja v predpise, ki zahtevajo daljše obdobje arhiviranja, elementi modela zaupanja C-ITS hranijo vse zapise najmanj pet let po tem, ko jim je poteklo ustrezno potrdilo.
5.5.3.Zaščita arhiviranih podatkov
(265)Elementi modela zaupanja C-ITS hranijo arhiv zapisov v varnem in varovanem hrambenem objektu, ločenem od opreme CA, s fizičnim in postopkovnim varnostnim nadzorom, ki je enakovreden ali boljši od tistega, ki velja za PKI.
(266)Arhiv se s hrambo v zanesljivem sistemu zaščiti pred nepooblaščenimi vpogledi, spremembo, uničenjem ali drugim poseganjem vanj.
(267)Nosilci podatkov, ki hranijo arhivske podatke, in aplikacije, potrebne za njihovo obdelavo, se vzdržujejo tako, da se lahko do njih dostopa v obdobju, določenem v tej CP.
5.5.4.Varnostno kopiranje arhiviranih podatkov
(268)Elementi modela zaupanja C-ITS vsak dan dodatno varnostno kopirajo take informacije v sistemske arhive in vsak teden izdelovali popolne varnostne kopije. Kopije dokumentov v papirni obliki se hranijo v varnem objektu na drugi lokaciji.
5.5.5.Zahteva za časovno žigosanje
(269)Elementi modela zaupanja C-ITS, ki upravljajo zbirko podatkov o preklicu, zagotavljajo, da evidence vsebujejo informacije o času in datumu, ko se ustvarijo zapisi o preklicu. Celovitost takih informacij se bo izvajala z rešitvami, ki temeljijo na kriptografiji.
5.5.6.Način zbiranja arhiviranih podatkov (notranji ali zunanji)
(270)Način zbiranja arhiviranih podatkov je notranji.
5.5.7.Postopek za dostop do arhiviranih podatkov in njihovo preverjanje
(271)Vsi elementi modela zaupanja C-ITS dostop do arhiva dopuščajo le pooblaščenim osebam, vrednim zaupanja. Korenski CA in CA opišejo postopke za ustvarjanje, preverjanje, pakiranje, prenašanje in shranjevanje arhivskih informacij v CPS.
(272)Oprema korenskega CA in CA pred povrnitvijo informacije preveri njeno celovitost.
5.6.Zamenjava ključa za elemente modela zaupanja C-ITS
(273)Za naslednje elemente modela zaupanja C-ITS veljajo posebne zahteve za njihovo zamenjavo ključa: potrdila TLM, korenskega CA in EA/AA.
5.6.1.TLM
(274)TLM ob izteku veljavnosti ustreznega potrdila izbriše svoj zasebni ključ. Pred deaktiviranjem obstoječega veljavnega zasebnega ključa ustvari nov par ključev in ustrezno potrdilo TLM. Poskrbi, da je novo (vezno) potrdilo v ECTL vneseno dovolj zgodaj, da ga je mogoče razposlati vsem postajam C-ITS, preden postane veljavno. Vezno potrdilo in novo potrdilo z lastnim podpisom se preneseta na CPOC.
5.6.2.Korenski CA
(275)Korenski CA deaktivira in izbriše obstoječi zasebni ključ (vključno z varnostnimi kopijami ključev), tako da ne izdaja potrdil EA/AA z veljavnostjo, ki presega veljavnost potrdila korenskega CA.
(276)Korenski CA ustvari nov par ključev in ustrezni korenski CA ter vezno potrdilo pred deaktiviranjem trenutnega zasebnega ključa (vključno z varnostnimi kopijami ključev) ter ga pošlje TLM za vstavitev v ECTL. Obdobje veljavnosti novega korenskega potrdila CA se začne ob načrtovani deaktivaciji obstoječega zasebnega ključa. Korenski CA poskrbi, da je novo potrdilo v ECTL vneseno dovolj zgodaj, da ga je mogoče razposlati vsem postajam C-ITS, preden postane veljavno.
(277)Korenski CA aktivira nov zasebni ključ, ko ustrezno korensko potrdilo CA postane veljavno.
5.6.3.Potrdilo EA/AA
(278)EA/AA deaktivira obstoječi zasebni ključ, tako da ne izdaja EC/AT z veljavnostjo, ki presega veljavnost potrdila EA/AA.
(279)Pred deaktiviranjem obstoječega zasebnega ključa EA/AA ustvari nov par ključev in zahteva ustrezno potrdilo EA/AA. Obdobje veljavnosti novega potrdila EA/AA se začne ob načrtovani deaktivaciji obstoječega zasebnega ključa. EA/AA poskrbi, da se novo potrdilo lahko objavi dovolj zgodaj, da ga je mogoče razposlati vsem postajam C-ITS, preden postane veljavno.
(280)EA/AA aktivira nov zasebni ključ, ko ustrezno potrdilo EA/AA postane veljavno.
5.6.4.Revizor
Ni določb.
5.7.Okrevalni načrt
5.7.1.Postopek v primeru vdorov in zlorabe
(281)Elementi modela zaupanja C-ITS tekoče spremljajo svojo opremo, da bi odkrili morebitne poskuse vdora ali druge oblike zlorab. V takem primeru opravijo preiskavo, da ugotovijo naravo in stopnjo škode.
(282)Če osebje, odgovorno za upravljanje korenskega CA ali TLM, zazna morebiten poskus vdora v računalniški sistem ali kakšno drugo obliko zlorabe, opravi preiskavo, da ugotovi naravo in stopnjo škode. Če je bil zasebni ključ zlorabljen, se potrdilo korenskega CA prekliče. Strokovnjaki CPA za varnost IT ocenijo obseg morebitne škode, da bi ugotovili, ali je treba obnoviti PKI, ali je treba preklicati samo nekatera potrdila in/ali je bila PKI ogrožena. Poleg tega CPA določa, katere storitve je treba vzdrževati (informacije o preklicu in statusu potrdila) in kako, v skladu z načrtom neprekinjenega poslovanja CPA.
(283)Vdor, zloraba in načrt neprekinjenega poslovanja so zajeti v CPS, ki se lahko opira tudi na druge vire podjetja in načrte za izvajanje.
(284)Če osebje, odgovorno za upravljanje EA/AA/CPOC, zazna morebiten poskus vdora v računalniški sistem ali kakšno drugo obliko zlorabe, opravi preiskavo, da ugotovi naravo in stopnjo škode. Osebje, ki je odgovorno za upravljanje CA ali subjekta CPOC, oceni obseg morebitne škode, da se ugotovi, ali je treba komponento PKI obnoviti, ali je treba preklicati samo nekatera potrdila in/ali je bila komponenta PKI ogrožena. Poleg tega podrejeni subjekt CA določi, katere storitve je treba vzdrževati in kako, v skladu z načrtom neprekinjenega poslovanja podrejenega subjekta CA. Če je komponenta PKI ogrožena, subjekt CA svoj korenski CA in TLM opozori prek CPOC.
(285)Vdor, zloraba in načrt neprekinjenega poslovanja so zajeti v CPS korenskega CA ali TLM ali drugih relevantnih dokumentih v primeru CPOC, ki se lahko opira tudi na druge vire podjetja in načrte za izvajanje.
(286)Korenski CA in CA opozorita predstavnika države članice in korenski CA, s katerim imata sklenjen sporazum v okviru C-ITS, in natančno navedeta informacije o posledicah vdora, da bi jima omogočila aktiviranje lastnega načrta za obvladovanje vdorov.
5.7.2.Postopek v primeru okvare strojne in programske opreme in/ali podatkov
(287)Če se odkrije nesreča, ki preprečuje pravilno delovanje elementa modela zaupanja C-ITS, ta element začasno preneha delovati in preišče, ali je bil zasebni ključ ogrožen (razen CPOC). Okvarjena strojna oprema se čim prej nadomesti, uporabljajo pa se postopki, opisani v oddelkih 5.7.3 in 5.7.4.
(288)Okvara strojne in programske opreme in/ali podatkov se za najvišje stopnje tveganja v 24 urah sporoči korenskemu CA. Vsi drugi dogodki morajo biti vključeni v redno poročilo korenskih CA, EA in AA.
5.7.3.Postopek v primeru ogroženega zasebnega ključa izdajatelja
(289)Če je zasebni ključ korenskega CA ogrožen, izgubljen, uničen, ali se sumi, da je ogrožen, korenski CA:
·začasno preneha delovati;
·začne izvajati okrevalni načrt in načrt migracije;
·prekliče svoje potrdilo korenskega CA;
·preišče „ključno vprašanje“, ki je sprožilo zlorabo in obvesti CPA, ki prekliče korensko potrdilo CA prek TLM (glej oddelek 7);
·opozori vse naročnike, s katerimi ima sklenjen sporazum.
(290)Če je ključ EA/AA ogrožen, izgubljen, uničen, ali se sumi, da je ogrožen, EA/AA:
·začasno preneha delovati;
·prekliče svoje potrdilo;
·preišče „ključno vprašanje“ in obvesti korenski CA;
·opozori naročnike, s katerimi je sklenjen sporazum.
(291)Če je EC postaje C-ITS ali ključ AT ogrožen, izgubljen, uničen ali se sumi, da je ogrožen, EA/AA, katerega naročnik je postaja C-ITS:
·prekliče ES prizadetega ITS;
·preišče „ključno vprašanje“ in obvesti korenski CA;
·opozori naročnike, s katerimi ima sklenjen sporazum.
(292)Kadar kateri koli od algoritmov ali z njimi povezanih parametrov, ki jih uporabljajo korenski CA in/ali CA ali postaje C-ITS, postane nezadosten za preostalo predvideno uporabo, CPA (s priporočilom strokovnjakov za šifriranje) obvesti subjekt korenskega CA, s katerim ima sklenjen sporazum in spremeni uporabljene algoritme. (Za podrobnosti glej oddelek 6 in CPS korenskega CA in pod-CA.)
5.7.4.Zmogljivosti za neprekinjeno poslovanje po nesreči
(293)Elementi modela zaupanja C-ITS, ki upravljajo varne zmogljivosti za dejavnosti CA, razvijajo, preizkušajo, vzdržujejo in izvajajo okrevalni načrt po nesreči, ki je namenjen ublažitvi učinkov kakršne koli naravne nesreče ali nesreče, ki jo je povzročil človek. Ti načrti obravnavajo obnovo storitev informacijskih sistemov in ključnih poslovnih funkcij.
(294)Po vdoru z določeno stopnjo tveganja mora ogroženi CA ponovno pregledati pooblaščeni revizor PKI (glej oddelek 8).
(295)Kadar ogroženi CA ne more več delovati (npr. po hudi nesreči), je treba pripraviti načrt migracije za prenos funkcij na drug korenski CA. Za podporo načrta migracije mora biti na voljo najmanj korenski CA EU. Funkcije ogroženega CA prenehajo.
(296)Korenski CA v CPS vključijo okrevalni načrt po nesreči in načrt migracije.
5.8.Prenehanje delovanja in prenos
5.8.1.TLM
(297)TLM ne preneha delovati, lahko pa subjekt, ki upravlja TLM, prevzame drug subjekt.
(298)Če se upravljalni subjekt spremeni:
·od CPA zahteva odobritev prenosa upravljanja TLM s starega na novi subjekt;
·CPA odobri prenos upravljanja TLM;
·vsi dnevniki beleženih dogodkov in arhivirani zapisi se prenesejo s starega upravljalnega subjekta na nov subjekt.
5.8.2.Korenski CA
(299)Korenski CA ne preneha ali začne delovati, ne da bi pripravil načrt migracije (določen v ustreznem CPS), ki jamči tekoče delovanje vsem naročnikom.
(300)Če korenski CA preneha opravljati storitve:
·obvesti CPA;
·obvesti TLM, da lahko izbriše potrdilo korenskega CA iz ECTL;
·prekliče ustrezni korenski CA z izdajo CRL, v katerem je naveden sam;
·opozori korenske CA, s katerimi ima sklenjen sporazum o obnovitvi potrdil EA/AA;
·uniči zasebni ključ korenskega CA;
·sporoči zadnje informacije o statusu preklica (CRL, podpisan s korenskim CA) odvisnim stranem, pri čemer jasno navede, da gre za najnovejše informacije o preklicu;
·arhivira vse dnevnike beleženih dogodkov in druge zapise pred zaključkom PKI;
·prenese arhivirano dokumentacijo ustreznemu organu.
(301)TLM izbriše ustrezno korensko potrdilo CA iz ECTL.
5.8.3.EA/AA
(302)Če EA/AA preneha opravljati storitve, subjekt EA/AA pred prenehanjem pošlje obvestilo. EA ali AA ne preneha ali začne delovati, ne da bi pripravil načrt migracije (določen v ustreznem CPS), ki jamči tekoče delovanje vsem naročnikom. EA/AA:
·obvesti korenski CA s priporočenim pismom;
·uniči zasebni ključ CA;
·prenese svojo podatkovno zbirko na subjekt, ki ga imenuje korenski CA;
·preneha izdajati potrdila;
·med prenosom svoje podatkovne zbirke in dokler podatkovna zbirka v celoti ne deluje v novem subjektu, ohrani zmožnost odobritve zahtevkov organa za varstvo zasebnosti;
·če je bil podrejeni CA ogrožen, ga korenski CA prekliče in izda nov CRL s seznamom preklicanih podrejenih CA;
·arhivira vse dnevnike beleženih dogodkov in druge zapise pred zaključkom PKI;
·prenese arhivske zapise na subjekt, ki ga imenuje korenski CA.
(303)Če se storitve CA zaključijo, je CA odgovoren za hrambo vseh relevantnih zapisov v zvezi s potrebami sestavnih delov CA in PKI.
6.Tehnične varnostne zahteve
6.1.Ustvaritev in namestitev para ključev
6.1.1.TLM, korenski CA, EA, AA
(304)Postopek ustvaritve para ključev izpolnjuje naslednje zahteve:
·vsak udeleženec mora imeti možnost, da ustvari lastne pare ključev v skladu z oddelkoma 6.1.4 in 6.1.5;
·proces izpeljave simetričnih šifrirnih ključev in ključa MAC za zahtevke za potrdila (ECIES) se izvaja v skladu z [1] in [5];
·Proces ustvaritve ključa uporablja algoritme in dolžine ključa, opisane v oddelkih 6.1.4.1 in 6.1.4.2.
·Za proces ustvaritve para ključa veljajo zahteve za „varno shranjevanje zasebnih ključev“ (glej oddelek 6.1.5).
·Korenski CA in njihovi naročniki (podrejeni CA) zagotovijo, da se med distribucijo podrejenim registriranim subjektom CA ohrani celovitost in verodostojnost njihovih javnih ključev in vseh z njimi povezanih parametrov.
6.1.2.EE – premična postaja C-ITS
(305)Vsaka premična postaja C-ITS ustvari lastne pare ključev v skladu z oddelkoma 6.1.4 in 6.1.5;
(306)proces izpeljave simetričnih šifrirnih ključev in ključa MAC za zahtevke za potrdila (ECIES) se izvaja v skladu z [1] in [5];
(307)Procesi ustvaritve ključa uporabljajo algoritme in dolžine ključa, opisane v oddelkih 6.1.4.1 in 6.1.4.2.
(308)Za procese ustvaritve para ključa veljajo zahteve za „varno shranjevanje zasebnih ključev“ (glej oddelek 6.1.5).
6.1.3.EE – nepremična postaja C-ITS
(309)Vsaka nepremična posta C-ITS ustvari lasten par ključev v skladu z oddelkoma 6.1.4 in 6.1.5;
(310)Procesi ustvaritve ključa uporabljajo algoritme in dolžine ključa, opisane v oddelkih 6.1.4.1 in 6.1.4.2.
(311)Za procese ustvaritve para ključa veljajo zahteve za „varno shranjevanje zasebnih ključev“ (glej oddelek 6.1.5).
6.1.4.Kriptografske zahteve
(312)Vsi udeleženci PKI izpolnjujejo kriptografske zahteve, določene v naslednjih odstavkih, v zvezi z algoritmom podpisa, dolžino ključa, generatorjem naključnih števil in veznih potrdil.
6.1.4.1.Algoritem in dolžina ključa – podpisni algoritmi
(313)Vsi udeleženci PKI (EA, AA in postaje C-ITS) morajo imeti možnost, da ustvarijo pare ključev in uporabijo zasebni ključ za operacije podpisovanja z izbranimi algoritmi najpozneje dve leti po začetku veljavnosti te uredbe v skladu s preglednico 4:
(314)Vsi udeleženci PKI, ki morajo preveriti celovitost ECTL, potrdil in/ali podpisanih sporočil v skladu s svojo vlogo, kot je opredeljena v oddelku 1.3.6, podpirajo ustrezne algoritme, navedene v preglednici 5, za preverjanje. Postaje C-ITS morajo zlasti imeti možnost, da preverijo celovitost ECTL.
|
TLM
|
korenski CA
|
EA
|
AA
|
Postaja C-ITS
|
ECDSA_nistP256_with_SHA 256
|
-
|
X
|
X
|
X
|
X
|
ECDSA_brainpoolP256r1_with_SHA 256
|
-
|
X
|
X
|
X
|
X
|
ECDSA_brainpoolP384r1_with_SHA 384
|
X
|
X
|
X
|
-
|
-
|
X označuje obvezno podporo.
|
Preglednica 4: Ustvaritev parov ključev in uporaba zasebnega ključa za podpisovanje
|
TLM
|
korenski CA
|
EA
|
AA
|
Postaja C-ITS
|
ECDSA_nistP256_with_SHA 256
|
X
|
X
|
X
|
X
|
X
|
ECDSA_brainpoolP256r1_with_SHA 256
|
X
|
X
|
X
|
X
|
X
|
ECDSA_brainpoolP384r1_with_SHA 384
|
X
|
X
|
X
|
X
|
X
|
X označuje obvezno podporo.
|
Preglednica 5: Pregled preverjanja
(315)Če CPA tako sklene na podlagi na novo ugotovljenih kriptografskih pomanjkljivosti, morajo vse postaje C-ITS imeti možnost, da čim hitreje preidejo na enega od dveh algoritmov (ECDSA_nistP256_with_SHA 256 ali ECDSA_brainpoolP256_with_SHA 256). Dejanski algoritem, ki se uporablja, v CPS določi CA, ki izda potrdilo za ustrezni javni ključ, v skladu s tem CP.
6.1.4.2.Algoritem in dolžina ključa – algoritmi za šifriranje podatkov za pridobitev potrdila in avtorizacijo
(316)Vsi udeleženci PKI (EA, AA in postaje C-ITS) morajo imeti možnost, da uporabijo javne ključe za šifriranje zahtevkov/odgovorov za pridobitev potrdila in dovoljenje z izbranimi algoritmi najpozneje dve leti po začetku veljavnosti te uredbe v skladu s preglednico 6. Dejanski algoritem, ki se uporablja, se v CPS določi CA, ki izda potrdilo za ustrezni javni ključ, v skladu s to CP.
(317)Navedeni algoritmi iz preglednice 6 označujejo dolžino ključa in zgoščevalnega algoritma ter se izvajajo v skladu s [5].
|
TLM
|
korenski CA
|
EA
|
AA
|
Postaja C-ITS
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
X označuje obvezno podporo.
|
Preglednica 6: Uporaba javnih ključev za šifriranje podatkov zahtevkov za pridobitev potrdila in odgovorov nanje
(318)Vsi udeleženci PKI (EA, AA in postaje C-ITS) morajo imeti možnost, da ustvarijo pare ključev in uporabijo zasebni ključ za dešifriranje zahtevkov za pridobitev potrdila in odgovorov nanje ter dovoljenje z izbranimi algoritmi najpozneje dve leti po začetku veljavnosti te uredbe v skladu s preglednico 7:
|
TLM
|
korenski CA
|
EA
|
AA
|
Postaja C-ITS
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
X označuje obvezno podporo.
|
Preglednica 7: Ustvaritev parov ključev in uporaba zasebnega ključa za šifriranje podatkov zahtevkov za pridobitev potrdila in odgovorov nanje
6.1.4.3.Kriptografska prilagodljivost
(319)Zahteve glede dolžin ključev in algoritmov je treba sčasoma spremeniti, da se ohrani ustrezna raven varnosti. CPA spremlja potrebo po takih spremembah glede na dejanske šibke točke in najsodobnejšo kriptografijo. Če sklene, da je treba posodobiti kriptografske algoritme, pripravi, odobri in objavi posodobitev te potrditvene politike. Kadar nova izdaja tega CP kaže na spremembo algoritma in/ali dolžine ključa, CPA sprejme strategijo migracije, ki vključuje prehodna obdobja prehoda, med katerimi morajo biti podprti stari algoritmi in dolžine ključev.
(320)Da se omogoči in olajša prenos na nove algoritme in/ali dolžine ključev, se priporoča, da vsi udeleženci PKI uporabljajo strojno in/ali programsko opremo, ki je zmožna zamenjati dolžino ključev in algoritmov.
(321)Spremembe korenskih potrdil in potrdil TLM se podprejo in izvedejo s pomočjo veznih potrdil (glej oddelek 4.6), ki se uporabljajo za kritje prehodnega obdobja med starimi in novimi korenskimi potrdili („migracija modela zaupanja“).
6.1.5.Varna hramba zasebnih ključev
V tem oddelku so opisane zahteve za varno hrambo in ustvarjanje parov ključev ter naključnih številk za CA in končne subjekte. Te zahteve so opredeljene za kriptografske module in opisane v naslednjih pododdelkih.
6.1.5.1.Raven korenskega CA, podrejenega CA in TLM
(322)Kriptografski modul se uporablja za:
·ustvaritev, uporabo, upravljanje in shranjevanje zasebnih ključev;
·ustvaritev in uporabo naključnih števil (ocena funkcije ustvaritve naključnega števila je del varnostne ocene in certifikacije);
·ustvarjanje varnostnih kopij zasebnih ključev v skladu z oddelkom 6.1.6;
·izbris zasebnih ključev.
Kriptografski modul se potrdi z enim od naslednjih profilov zaščite (PP) z ravnijo zanesljivosti EAL-4 ali višjo:
·PP za HSM:
·CEN EN 419 221-2: Zaščitni profili za TSP kriptografske module – 2. del: Kriptografski modul za postopke podpisovanja CSP z varnostno kopijo;
·CEN EN 419 221-4: Zaščitni profili za TSP kriptografske module – Part 4: Kriptografski modul za postopke podpisovanja CSP brez varnostne kopije;
·CEN EN 419 221-5: Zaščitni profili za TSP kriptografske module – 5. del: Kriptografski modul za storitve zaupanja;
·PP za pametne kartice:
·CEN EN 419 211-2: Profil zaščite sredstva za varno elektronsko podpisovanje – 2. del: Sredstvo, ki generira ključ;
·CEN EN 419 211-3: Profil zaščite sredstva za varno elektronsko podpisovanje — Part 3: Sredstvo z vnosom ključa.
Za ročni dostop do kriptografskega modula se od upravljavca zahteva dvostopenjska avtentikacija. Poleg tega je za to potrebno sodelovanje dveh pooblaščenih oseb.
Izvajanje kriptografskega modula zagotovi, da ključi niso dostopni zunaj kriptografskega modula. Kriptografski modul vključuje mehanizem za nadzor dostopa, da se prepreči nepooblaščena uporaba zasebnih ključev.
6.1.5.2.Končni subjekt
(323)Kriptografski modul za EE se uporablja za:
·ustvaritev, uporabo, upravljanje in shranjevanje zasebnih ključev;
·ustvaritev in uporabo naključnih števil (ocena funkcije ustvaritve naključnega števila je del ocene in potrjevanja varnosti);
·varen izbris zasebnega ključa
(324)Kriptografski modul se zaščiti pred nedovoljeno odstranitvijo, zamenjavo ali spremembo. Vsi PP in povezani dokumenti, ki se uporabljajo za varnostno potrjevanje kriptografskega modula, se ocenijo, potrdijo in certificirajo v skladu s standardom ISO 15408, pri čemer se uporabi sporazum o vzajemnem priznavanju potrdil o varnostnih ocenah informacijske tehnologije skupine višjih uradnikov o varnosti informacijskih sistemov (SOG-IS) ali enakovredna evropska certifikacijska shema za kibernetsko varnost na podlagi relevantnega evropskega kibernetskovarnostnega okvira.
(325)Glede na pomen ohranjanja najvišje možne stopnje varnosti varnostna potrdila za kriptografski modul na podlagi skupnih meril certifikacijske sheme (ISO 15408) izda organ za ugotavljanje skladnosti, ki ga priznava upravljalni odbor v okviru sporazuma SOG-IS, ali pa jih izda organ za ugotavljanje skladnosti, ki ga pooblasti nacionalni certifikacijski organ za kibernetsko varnost države članice. Tak organ za ugotavljanje skladnosti zagotavlja najmanj enakovredne pogoje ocene varnosti, kot jih določa sporazum o vzajemnem priznavanju SOG-IS.
Opomba: povezava med kriptografskim modulom in postajo C-ITS se zaščiti.
6.1.6.Varnostna kopija zasebnega ključa
(326)Ustvaritev, hramba in uporaba varnostnih kopij zasebnih ključev izpolnjujejo zahteve najmanj za stopnjo varnosti, ki se zahteva za izvirne ključe.
(327)Varnostne kopije zasebnih ključev naredijo korenski CA, EA in AA.
(328)Varnostne kopije zasebnih ključev se ne naredijo za EC in AT.
6.1.7.Uničenje zasebnega ključa
(329)Korenski CA, EA, AA ter premične in nepremične postaje C-ITS uničijo svoj zasebni ključ in ustrezne varnostne kopije, če je bil ustvarjen in uspešno nameščen nov par ključev in ustrezno potrdilo ter je preteklo obdobje prekrivanja (če obstaja – samo CA). Zasebni ključ se uniči z mehanizmom, ki ga nudi kriptografski modul, ki se uporablja za hrambo ključev, ali v skladu z ustreznim PP, kot je naveden v oddelku 6.1.5.2.
6.2.Aktivacijski podatki
(330)Aktivacijski podatki se nanašajo na dejavnike v zvezi s preverjanjem verodostojnosti, ki so potrebni za delovanje kriptografskih modulov in preprečevanje nepooblaščenega dostopa. Pri uporabi aktivacijskih podatkov kriptografske naprave CA morata sodelovati vsaj dve osebi.
6.3.Varnostne zahteve za računalniško opremo
(331)Varnostni nadzor računalnika CA je zasnovan v skladu z visoko ravnijo varnosti, ki izpolnjuje zahteve iz standarda ISO/IEC 27002.
6.4.Tehnični nadzor življenjskega cikla
(332)Tehnični nadzor CA mora zajemati celoten življenjski cikel CA. To vključuje zlasti zahteve iz oddelka 6.1.4.3 (kriptografska prilagodljivost).
6.5.Varnostna kontrola računalniške mreže
(333)Omrežja CA (korenskega CA, EA in AA) morajo biti odporna pred napadi v skladu z zahtevami in navodili za izvajanje iz standardov ISO/IEC 27001 in ISO/IEC 27002.
(334)Razpoložljivost omrežij CA se oblikuje glede na ocenjeni promet.
7.Profil potrdil, CRL in CTL
7.1.Profil potrdil
(335)Profili potrdil, opredeljeni v [5] se uporabljajo za TLM, korenska potrdila, potrdila EA, potrdila AA, AT in EC. EA nacionalnih vlad lahko za EC uporabijo druge profile potrdil.
(336)V korenskih potrdilih CA, EA in AA se navedejo dovoljenja, za katera je tem CA (korenski CA, EA in AA) dovoljeno izdajati potrdila.
(337)Na podlagi [5]:
·vsak korenski CA uporablja svoj zasebni ključ za podpisovanje za izdajo CRL;
·TLM za izdajo ECTL uporabi svoj zasebni ključ za podpisovanje.
7.2.Veljavnost potrdil
(338)Vsi profili potrdil C-ITS vključujejo datum izdajo in izteka veljavnosti, ki predstavljajo čas veljavnosti potrdil. Na vsaki ravni PKI se potrdila ustvarijo pravočasno pred iztekom veljavnosti.
(339)Doba veljavnosti potrdil CA in EC vključuje čas prekrivanja. Potrdila TLM in korenskega CA se izdajajo in vpisujejo v ECTL največ tri mesece in najmanj mesec dni pred začetkom veljavnosti, ki temelji na času začetka veljavnost v potrdilu. Ta doba vnosa pred začetkom veljavnosti je potrebna, da je mogoče varno razposlati potrdila vsem ustreznim odvisnim stranem v skladu z oddelkom 2.2. To zagotavlja, da lahko od začetka prekrivanja vse odvisne strani preverijo sporočila, izdana z novim potrdilom.
(340)Na začetku obdobja prekrivanja se izdajo zaporedna potrdila CA, EC in AT (če je ustrezno) ter se razpošljejo ustreznim odvisnim stranem, ki jih namestijo. Med obdobjem prekrivanja se obstoječa potrdila uporabljajo le za preverjanje.
(341)Ker dobe veljavnosti, navedene v preglednici 8, ne smejo preseči dobe veljavnosti nadrejenega potrdila, se uporabljajo naslednje omejitve:
·maximumvalidity(Root CA) = privatekeyusage(Root CA) + maximumvalidity(EA,AA);
·maximumvalidity(EA) = privatekeyusage(EA) + maximumvalidity(EC);
·maximumvalidity(AA) = privatekeyusage(AA) + preloadingperiod(AT).
(342)Veljavnost (korenskih in TLM) veznih potrdil začne teči z ustrezno zasebno uporabo ključev in konča z najdaljšim časom veljavnosti korenskega CA ali TLM.
(343)Preglednica 8 kaže najdaljši čas veljavnosti za potrdila CA C-ITS (za obdobja veljavnosti glej oddelek 7.2.1).
Subjekt
|
Najdaljša doba uporabe zasebnega ključa
|
Najdaljši čas veljavnosti
|
Korenski CA
|
3 leta
|
8 leta
|
EA
|
2 leti
|
5 let
|
AA
|
4 leta
|
5 let
|
EC
|
3 leta
|
3 leta
|
TLM
|
3 leta
|
4 leta
|
Preglednica 8: Doba veljavnosti potrdil v modelu zaupanja C-ITS
7.2.1.Psevdonimna potrdila
(344)V tem okviru psevdonime izvajajo AT. Zato je v tem oddelku govora o AT namesto o psevdonimih.
(345)Zahteve iz tega oddelka veljajo samo za premične postaje C-ITS, ki pošiljajo sporočila CAM in DENM, pri katerih se uporablja tveganje za zasebnost lokacije. Za potrdila AT se ne uporabljajo posebne zahteve za AT za nepremične postaje C-ITS in premične postaje C-ITS, ki se uporabljajo za posebne funkcije, pri katerih se ne uporablja zasebnost lokacije (npr. za označena vozila za nujno pomoč in vozila organov pregona).
(346)Uporabljajo se naslednje opredelitve pojmov:
·„doba veljavnosti za AT“ – obdobje, v katerem je AT veljaven, tj. obdobje med začetnim datumom veljavnosti AT in datumom izteka veljavnosti;
·„doba vnosa pred začetkom veljavnosti za AT“ – vnos pred začetkom veljavnosti je možnost postaj C-ITS, da pridobijo AT pred začetkom dobe veljavnosti. Doba vnosa pred začetkom veljavnosti je najdaljše dovoljeno obdobje od zahtevka za AT do najpoznejšega datuma veljavnosti katerega koli zahtevanega AT;
·„obdobje uporabe za AT“ – obdobje, v katerem se AT dejansko uporablja za podpisovanje sporočil CAM/DENM;
·„največje število vzporednih AT“ – število AT, izmed katerih lahko postaja C-ITS izbira v danem trenutku pri podpisovanju sporočila CAM/DENM, tj. število različnih AT, izdanih za eno postajo C-ITS, ki veljajo hkrati.
(347)Uporabijo se naslednje zahteve:
·doba vnosa pred začetkom veljavnosti za AT ne presega treh mesecev;
·doba veljavnosti za AT ne presega enega tedna;
·največje število vzporednih AT ne presega 100 na postajo C-ITS;
·obdobje uporabe AT je odvisno od spremembe strategije AT in tega, koliko časa je vozilo v delovanju, omejeno pa je z največjim številom vzporednih AT in dobo veljavnosti. Natančneje, povprečno obdobje uporabe za eno postajo C-ITS je najmanj čas obratovanja vozila v eni dobi veljavnosti, deljen z največjim številom vzporednih AT.
7.2.2.Potrdila o avtorizaciji za nepremične postaje C-ITS
(348)Uporabljajo se opredelitve pojmov iz oddelka 7.2.1 in naslednje zahteve:
·doba vnosa pred začetkom veljavnosti za AT ne presega treh mesecev;
·največje število vzporednih AT ne presega dveh na postajo C-ITS;
7.3.Preklic potrdil
7.3.1.Preklic potrdil CA, EA in AA
Potrdila korenskega CA, EA in AA se lahko prekličejo. Preklicana potrdila korenskih CA, EA in AA se objavijo v CRL takoj, ko je mogoče in brez nepotrebnega odlašanja. Ta CRL podpiše njegov ustrezni korenski CA in uporabi profil, opisan v oddelku 7.4. Za preklic korenskih potrdil CA ustrezni korenski CA izda CRL, v katerem je naveden sam. Poleg tega se v primeru varnostne zlorabe uporablja oddelek 5.7.3. Poleg tega TLM izbriše preklicane korenske CA iz seznama zaupanja in izda nov seznam zaupanja. Pretečena potrdila se izbrišejo iz ustreznega CRL in seznama zaupanja vrednih potrdil.
(349)Potrdila se prekličejo, kadar:
·imajo korenski CA razlog za domnevo ali utemeljeno sumijo, da je bil zasebni ključ ogrožen;
·so bili korenski CA obveščeni, da je bila pogodba z naročnikom prekinjena;
·so informacije (kot so ime in zveze med CA in osebo) v potrdilu nepravilne ali so bile spremenjene;
·pride do varnostnega vdora, ki zadeva lastnika potrdila;
·je rezultat revizije (glej oddelek 8) negativen.
(350)Naročnik takoj obvesti CA o znani ali domnevni zlorabi njegovega zasebnega ključa. Zagotoviti je treba, da se potrdila prekličejo samo z verodostojnimi zahtevki.
7.3.2.Preklic poverilnice za pridobitev potrdila
(351)Preklic EC lahko sproži naročnik postaje C-ITS (tok 34) in se izvede z notranjo črno listo v zbirki podatkov o preklicu s časovnim žigom, ki ga ustvari in hrani vsak EA. Črna lista se nikoli ne objavi, ostane zaupna, uporablja pa jo lahko le ustrezni EA za preverjanje veljavnosti ustreznih EC v okviru zahtevkov za AT in nove EC.
7.3.3.Preklic potrdil o avtorizaciji
(352)Ker AT ustrezni CA ne prekličejo, imajo kratko življenjsko dobo in jih ni mogoče izdati preveč vnaprej pred začetkom veljavnosti. Dovoljene vrednosti parametra življenjskega cikla potrdila so določene v oddelku 7.2.
7.4.Seznam preklicev potrdil
(353)Oblika in vsebina CRL, ki ga izdajo korenski CA, se določi v [1].
7.5.Evropski seznam zaupanja vrednih potrdil
(354)Oblika in vsebina ECTL, ki ga izda TLM, se določi v [1].
8.Revidiranje skladnosti in ostali pregledi
8.1.Vsebina nadzora in podlaga zanj
(355)Namen revidiranja skladnosti je preveriti, da TLM, korenski CA, EA in AA delujejo v skladu s to CP. TLM, korenski CA, EA in AA za nadzor svojih CPS izberejo neodvisnega in pooblaščenega revizorja PKI. Nadzor se združi z ocenama po ISO/IEC 27001 in ISO/IEC 27002.
(356)Revidiranje skladnosti naroči korenski CA (tok 13) za sam korenski CA, za podrejeni CA pa podrejeni EA/AA.
(357)Revidiranje skladnosti za TLM naroči CPA (tok 38).
(358)Pooblaščeni revizor PKI na zahtevo izvede revidiranje skladnosti na eni od naslednjih ravni:
(1)skladnost CPS TLM, korenskih CA, EA ali AA s tem CP;
(2)skladnost predvidenih praks TLM, korenskih CA, EA ali AA CPS z njegovo CPS pred začetkom delovanja;
(3)skladnost praks TLM, korenskih CA, EA ali AA in operativnih dejavnosti z njegovim CPS med delovanjem.
(359)Revizija zajema vse zahteve iz te CP, ki jih morajo izpolnjevati TLM, korenski CA, EA in AA, ki se revidirajo. Zajema tudi dejavnost CA v PKI C-ITS, vključno z vsemi postopki, navedenimi v njegovi CPS, prostori in odgovornimi osebami.
(360)Pooblaščeni revizor PKI predloži podrobno poročilo o nadzoru korenskemu CA (tok 36), EA, AA ali CPA (tokova 16 in 40), kot je ustrezno.
8.2.Pogostost nadzora
(361)Korenski CA, TLM, EA ali AA naroči revidiranje skladnosti samega sebe pri neodvisnem in pooblaščenem revizorju PKI v naslednjih primerih:
·ob prvi vzpostavitvi (ravni skladnosti 1 in 2);
·ob vsaki spremembi CP. CPA opredeli spremembo vsebine CP in časovni načrt uvajanja ter določi potrebe po nadzorih (vključno s potrebno ravnjo skladnosti), kot je ustrezno;
·ob vsaki spremembi svoje CPS (ravni skladnosti 1, 2 in 3). Ker subjekti, ki upravljajo korenske CA, TLM in EA/AA, odločijo, katere spremembe pri izvajanju sledijo posodobitvi njihovih CPS, naročijo revidiranje skladnosti pred uvedbo navedenih sprememb. V primerih le manjših (npr. redakcijskih) sprememb CPS lahko subjekt, ki upravlja, pošlje CPA ustrezno utemeljen zahtevek za odobritev, da se preskoči raven 1, 2 ali 3 revidiranja skladnosti;
·redno in najmanj vsaka tri leta med njegovim delovanjem (raven skladnosti 3).
8.3.Identiteta in usposobljenost revizorja
(362)CA, katere skladnost se preveri, izbere neodvisno in pooblaščeno podjetje/organizacijo („revizijski organ“) ali pooblaščene revizorje PKI, da ga revidira v skladu s tem CP. Revizijski organ pooblasti in potrdi članica evropskega akreditacijskega organa.
8.4.Odnos med revizorjem in revidiranim subjektom
(363)Pooblaščeni revizor PKI je neodvisen od revidiranega subjekta.
8.5.Ukrepi kot posledica ugotovljenih nepravilnosti
(364)Kadar se v poročilu o reviziji ugotovi, da TLM ni skladen, CPA naroči TLM, da sprejme takojšnje preventivne/popravne ukrepe.
(365)Kadar korenski CA z neskladnim poročilom o reviziji vloži novo prošnjo, CPA prošnjo zavrne in pošlje ustrezno zavrnitev korenskemu CA (tok 4). V takih primerih bo korenski CA začasno ustavljen. Sprejeti mora popravne ukrepe, ponovno naročiti nadzor in vložiti nov zahtevek za odobritev CPA. Korenski CA med začasnim preklicem ne sme izdajati potrdil.
(366)V primerih redne revizije korenskega CA ali spremembe CPS korenskega CA in glede na naravo neskladnosti, opisane v poročilu o reviziji, se lahko CPA odloči za preklic korenskega CA in to odločitev sporoči TLM (tok 2), kar povzroči izbris korenskega potrdila CA iz ECTL in vključitev korenskega CA v CRL. CPA korenskemu CA pošlje ustrezno zavrnitev (tok 4). Korenski CA mora sprejeti popravne ukrepe, ponovno naročiti popolno revizijo (na ravneh 1 do 3) in vložiti nov zahtevek za odobritev CPA. Alternativno se CPA lahko odloči, da ne prekliče korenskega CA, ampak mu določi prehodno obdobje, v katerem korenski CA sprejme popravne ukrepe, ponovno naroči revizijo in ponovno pošlje poročilo o reviziji CPA. V tem primeru je treba operacijo korenskega CA začasno ustaviti in ni dovoljeno izdajati potrdil in CRL.
(367)V primeru revizije EA/AA se korenski CA odloči, ali bo poročilo sprejel ali ne. Glede na rezultat revizije se korenski CA odloči, ali bo preklical potrdilo EA/AA v skladu s pravili iz CPS korenskega CA. Korenski CA ves čas zagotavlja skladnost EA/AA s tem CP.
8.6.Objava rezultatov
(368)Korenski CA in TLM pošljeta poročilo o reviziji CPA (tok 16). Korenski CA in TLM hranita poročila o reviziji, ki sta jih naročila. CPA pošlje ustrezno odobritev ali zavrnitev (tok 4) korenskemu CA in TLM.
(369)Korenski CA pošlje potrdilo o skladnosti ustreznim EA/AA.
9.Druge določbe
9.1.Pristojbine
(370)Eno od načel uporabljanega modela zaupanja C-ITS EU je, da korenski CA skupaj v celoti financirajo redne periodične stroške delovanja CPA in osrednjih elementov (TLM in CPOC) v zvezi z dejavnostmi iz te CP.
(371)Korenski CA (vključno s korenskim CA EU) so upravičeni do pristojbin od svojih podrejenih CA.
(372)V celotnem obdobju delovanja ima vsak udeleženec modela zaupanja C-ITS dostop do najmanj enega korenskega CA, EA in AA na nediskriminatorni osnovi.
(373)Vsak korenski CA je upravičen do prenosa pristojbin, ki jih plačuje za CPA in osrednje elemente (TLM in CPOC) na registrirane udeležence modela zaupanja C-ITS, vključno s pridobljenimi in odobrenimi postajami C-ITS.
9.2.Finančna odgovornost
(374)Začetna vzpostavitev korenskega CA zajema obdobje najmanj treh let delovanja, da lahko postane član modela zaupanja C-ITS EU. CPS korenskega operaterja CA vsebuje tudi podrobne določbe o preklicu ali zaprtju korenskega CA.
(375)Vsak korenski CA mora izkazati finančno sposobnost pravnega subjekta, ki ga izvaja, za obdobje najmanj treh let. Ta načrt finančne sposobnosti je del prvotnega niza dokumentov za pridobitev potrdila in ga je treba posodobiti vsaka tri leta ter o njem poročati CPA.
(376)Vsak korenski CA mora vsako leto poročati o strukturi stroškov, ki se uporabljajo za EA/AA in vpisane ter pooblaščene postaje C-ITS, upravitelju dejavnosti in CPA, da dokaže svojo finančno vzdržnost.
(377)Vsi finančni in pravni odgovorni subjekti korenskih CA, EA, AA in osrednji elementi (CPOC in TLM) modela zaupanja C-ITS morajo svoje operativne naloge kriti z ustreznimi ravnmi zavarovanja za nadomestilo v primeru operativnih napak in za finančno nadomestilo za svoje naloge, če odpove kateri od tehničnih elementov.
9.3.Zaupnost poslovnih podatkov
(378)Zaupne in zasebne so naslednje informacije:
·evidence odobrenih in zavrnjenih prošenj za korenske CA, EA, AA;
·poročila o reviziji korenskih CA, EA, AA in TLM;
·okrevalni načrti za korenske CA, EA, AA, CPOC in TLM;
·zasebni ključi elementov modela zaupanja C-ITS (postaje C-ITS, TLM, EA, AA, korenski CA);
·vse druge informacije, ki jih CPA, korenski CA, EA, AA, TLM in CPOC označijo za zaupne.
9.4.Načrt varovanja osebnih podatkov
(379)CPS korenskih CA in EA/AA določijo načrt in zahteve za ravnanje z osebnimi podatki in zasebnost na podlagi splošne uredbe o varstvu podatkov in drugih veljavnih zakonodajnih (npr. nacionalnih) okvirov.
10.Reference
V tej prilogi se uporabljajo naslednje reference:
[1]
|
ETSI TS 102 941 V1.2.1, Inteligentni transportni sistemi (ITS) – Upravljanje varnosti, zaupanja in zasebnosti.
|
[2]
|
ETSI TS 102 940 V1.3.1, Inteligentni transportni sistemi (ITS) – Varnost, varnostna arhitektura komunikacij ITS in upravljanje varnosti.
|
[3]
|
Potrditvena politika in okvir praks izdajanja potrdil (RFC 3647, 1999).
|
[4]
|
ETSI TS 102 042 V2.4.1 Zahteve politike za overitelje digitalnih potrdil, ki izdajajo digitalna potrdila javnih ključev.
|
[5]
|
ETSI TS 103 097 V1.3.1, Inteligentni transportni sistemi (ITS) – Varnost, varnostna glava in formati potrdil.
|
[6]
|
Calder, A. (2006). Information security based on ISO 27001/ISO 1779: a management guide. (Informacijska varnost na podlagi standarda ISO 27001/ISO 1779: priročnik za upravljanje) Van Haren Publishing.
|
[7]
|
ISO, I., & Std, I. E. C. (2011). ISO 27005 (2011) – Informacijska tehnologija, varnostne tehnike, upravljanje tveganj na področju informacijske tehnologije. ISO.
|
|
|