Embed Size (px)
Citation preview
7510/19 ADD 3 rk
TREE.2.A CS
Rada Evropské unie
Brusel 14. března 2019 (OR. en) 7510/19 ADD 3 TRANS 199 DELACT 68
PRŮVODNÍ POZNÁMKA
Odesílatel: Jordi AYET PUIGARNAU, ředitel, za generálního tajemníka Evropské komise
Příjemce: Jeppe TRANHOLM-MIKKELSEN, generální tajemník Rady Evropské unie
Č. dok. Komise: C(2019) 1789 final - Annex 3
Předmět: PŘÍLOHA nařízení Komise v přenesené pravomoci, kterým se doplňuje směrnice Evropského parlamentu a Rady 2010/40/EU, pokud jde o zavádění a provozní využívání kooperativních inteligentních dopravních systémů
Delegace naleznou v příloze dokument C(2019) 1789 final - Annex 3.
Příloha: C(2019) 1789 final - Annex 3
CS CS
EVROPSKÁ KOMISE
V Bruselu dne 13.3.2019
C(2019) 1789 final
ANNEX 3
PŘÍLOHA
nařízení Komise v přenesené pravomoci,
kterým se doplňuje směrnice Evropského parlamentu a Rady 2010/40/EU, pokud jde o
zavádění a provozní využívání kooperativních inteligentních dopravních systémů
{SEC(2019) 100 final} - {SWD(2019) 95 final} - {SWD(2019) 96 final}
CS 1 CS
OBSAH
1. Úvod ............................................................................................................................. 9
1.1 Přehled a oblast působnosti této politiky ..................................................................... 9
1.2 Definice a zkratky ...................................................................................................... 11
1.3 Účastníci PKI ............................................................................................................. 13
1.3.1 Úvod ........................................................................................................................... 13
1.3.2 Orgán pro certifikační politiku C-ITS ........................................................................ 16
1.3.3 Správce seznamu důvěryhodných subjektů ............................................................... 17
1.3.4 Akreditovaný auditor PKI .......................................................................................... 17
1.3.5 Kontaktní místo C-ITS (CPOC) ................................................................................. 17
1.3.6 Provozní role .............................................................................................................. 18
1.4 Použití certifikátu ....................................................................................................... 18
1.4.1 Příslušné oblasti použití ............................................................................................. 18
1.4.2 Rozsah odpovědnosti ................................................................................................. 19
1.5 Správa certifikační politiky ........................................................................................ 19
1.5.1 Aktualizace CPS certifikačních autorit uvedených v ECTL ...................................... 19
1.5.2 Schvalovací postupy CPS .......................................................................................... 20
2. Povinnosti v oblasti zveřejňování a úložišť ............................................................... 20
2.1 Metody zveřejňování informací o certifikátech ......................................................... 20
2.2 Čas nebo četnost zveřejňování ................................................................................... 21
2.3 Úložiště ...................................................................................................................... 21
2.4 Kontroly přístupu do úložišť ...................................................................................... 21
2.5 Zveřejňování informací o certifikátu ......................................................................... 22
2.5.1 Zveřejňování informací o certifikátu správcem seznamu důvěryhodných subjektů .. 22
2.5.2 Zveřejňování informací o certifikátu certifikačními autoritami ................................. 22
3. Identifikace a autentizace ........................................................................................... 23
3.1 Pojmenovávání ........................................................................................................... 23
3.1.1 Druhy názvu ............................................................................................................... 23
3.1.1.1 Názvy TLM, kořenových CA, EA, AA ..................................................................... 23
3.1.1.2 Názvy koncových subjektů ........................................................................................ 23
3.1.1.3 Identifikace certifikátů ............................................................................................... 23
3.1.2 Požadavek na smysluplnost názvů ............................................................................. 23
3.1.3 Anonymita a pseudonymita koncových subjektů ...................................................... 23
3.1.4 Pravidla pro výklad různých forem názvů ................................................................. 23
3.1.5 Jedinečnost názvů ....................................................................................................... 24
CS 2 CS
3.2 Počáteční potvrzení totožnosti ................................................................................... 24
3.2.1 Metoda prokazování vlastnictví soukromého klíče .................................................... 24
3.2.2 Autentizace totožnosti organizace .............................................................................. 24
3.2.2.1 Autentizace totožnosti organizace kořenových CA ................................................... 24
3.2.2.2 Autentizace totožnosti organizace TLM .................................................................... 25
3.2.2.3 Autentizace totožnosti organizace podřízených CA .................................................. 25
3.2.2.4 Autentizace účastnické organizace koncových subjektů ........................................... 26
3.2.3 Autentizace jednotlivého subjektu ............................................................................. 26
3.2.3.1 Autentizace jednotlivého subjektu TLM / CA ........................................................... 26
3.2.3.2 Autentizace totožnosti účastníka stanic C-ITS .......................................................... 27
3.2.3.3 Autentizace totožnosti stanice C-ITS ......................................................................... 27
3.2.4 Neověřené informace o účastníkovi ........................................................................... 27
3.2.5 Validace autority ........................................................................................................ 27
3.2.5.1 Validace TLM, kořenové CA, EA, AA...................................................................... 27
3.2.5.2 Validace účastníků stanice C-ITS .............................................................................. 28
3.2.5.3 Validace stanice C-ITS .............................................................................................. 28
3.2.6 Kritéria pro interoperabilitu ....................................................................................... 28
3.3 Identifikace a autentizace žádostí o změnu klíče ....................................................... 28
3.3.1 Identifikace a autentizace žádostí o rutinní změnu klíče ........................................... 28
3.3.1.1 Certifikáty TLM ......................................................................................................... 28
3.3.1.2 Certifikáty kořenové CA ............................................................................................ 28
3.3.1.3 Obnova certifikátu nebo změna klíče EA/AA ........................................................... 28
3.3.1.4 Oprávnění koncových subjektů k registraci ............................................................... 29
3.3.1.5 Autorizační potvrzení koncových subjektů ................................................................ 29
3.3.2 Identifikace a autentizace žádostí o změnu klíče po odvolání ................................... 29
3.3.2.1 Certifikáty CA ............................................................................................................ 29
3.3.2.2 Oprávnění koncových subjektů k registraci ............................................................... 29
3.3.2.3 Žádosti koncových subjektů o autorizaci ................................................................... 29
3.4 Identifikace a autentizace pro žádost o odvolání ....................................................... 29
3.4.1 Certifikáty kořenové CA/EA/AA ............................................................................... 29
3.4.2 Oprávnění stanice C-ITS k registraci ......................................................................... 30
3.4.3 Potvrzení o autorizaci stanice C-ITS.......................................................................... 30
4. Provozní požadavky na životní cyklus certifikátu ..................................................... 30
4.1 Žádost o certifikát ...................................................................................................... 30
4.1.1 Kdo může podat žádost o certifikát ............................................................................ 30
CS 3 CS
4.1.1.1 Kořenové CA ............................................................................................................. 30
4.1.1.2 TLM ........................................................................................................................... 31
4.1.1.3 EA a AA ..................................................................................................................... 31
4.1.1.4 Stanice C-ITS ............................................................................................................. 31
4.1.2 Proces a povinnosti registrace .................................................................................... 31
4.1.2.1 Kořenové CA ............................................................................................................. 31
4.1.2.2 TLM ........................................................................................................................... 32
4.1.2.3 EA a AA ..................................................................................................................... 32
4.1.2.4 Stanice C-ITS ............................................................................................................. 32
4.2 Zpracování žádosti o certifikát ................................................................................... 33
4.2.1 Vykonávání funkcí identifikace a autentizace ........................................................... 33
4.2.1.1 Identifikace a autentizace kořenových CA ................................................................ 33
4.2.1.2 Identifikace a autentizace správce seznamu důvěryhodných subjektů ...................... 33
4.2.1.3 Identifikace a autentizace EA a AA ........................................................................... 33
4.2.1.4 Identifikace a autentizace účastníka EE ..................................................................... 34
4.2.1.5 Potvrzení o autorizaci ................................................................................................. 34
4.2.2 Schválení nebo zamítnutí žádostí o certifikát ............................................................ 34
4.2.2.1 Schválení nebo zamítnutí certifikátů kořenové CA ................................................... 34
4.2.2.2 Schválení nebo zamítnutí certifikátu správce seznamu důvěryhodných subjektů ..... 34
4.2.2.3 Schválení nebo zamítnutí certifikátů EA a AA .......................................................... 34
4.2.2.4 Schválení nebo zamítnutí oprávnění .......................................................................... 34
4.2.2.5 Schválení nebo zamítnutí potvrzení o autorizaci ....................................................... 35
4.2.3 Doba pro zpracování žádosti o certifikát ................................................................... 35
4.2.3.1 Žádost o certifikát kořenové CA ................................................................................ 35
4.2.3.2 Žádost o certifikát TLM ............................................................................................. 35
4.2.3.3 Žádost o certifikát EA a AA ....................................................................................... 35
4.2.3.4 Žádost o EC ................................................................................................................ 35
4.2.3.5 Žádost o AT................................................................................................................ 35
4.3 Vydávání certifikátu ................................................................................................... 35
4.3.1 Úkony CA v průběhu vydávání certifikátu ................................................................ 35
4.3.1.1 Vydávání certifikátu kořenové CA ............................................................................ 35
4.3.1.2 Vydávání certifikátu TLM ......................................................................................... 36
4.3.1.3 Vydávání certifikátu EA a AA ................................................................................... 36
4.3.1.4 Vydávání oprávnění ................................................................................................... 36
4.3.1.5 Vydávání potvrzení o autorizaci ................................................................................ 36
CS 4 CS
4.3.2 Oznámení CA účastníkovi o vydání certifikátů ......................................................... 36
4.4 Přijetí certifikátu ......................................................................................................... 37
4.4.1 Převzetí certifikátu ..................................................................................................... 37
4.4.1.1 Kořenová CA ............................................................................................................. 37
4.4.1.2 TLM ........................................................................................................................... 37
4.4.1.3 EA a AA ..................................................................................................................... 37
4.4.1.4 Stanice C-ITS ............................................................................................................. 37
4.4.2 Zveřejnění certifikátu ................................................................................................. 37
4.4.3 Oznámení o vydání certifikátu ................................................................................... 37
4.5 Použití páru klíčů a certifikátu ................................................................................... 37
4.5.1 Použití soukromého klíče a certifikátu ....................................................................... 37
4.5.1.1 Použití soukromého klíče a certifikátu pro TLM ....................................................... 37
4.5.1.2 Použití soukromého klíče a certifikátů pro kořenové CA .......................................... 37
4.5.1.3 Použití soukromého klíče a certifikátu registrující a autorizační autoritou ............... 37
4.5.1.4 Použití soukromého klíče a certifikátu koncovým subjektem ................................... 38
4.5.2 Použití veřejného klíče a certifikátu spoléhající se stranou ....................................... 38
4.6 Obnova certifikátu ...................................................................................................... 38
4.7 Změna klíče certifikátu .............................................................................................. 38
4.7.1 Okolnosti pro změnu klíče certifikátu ........................................................................ 38
4.7.2 Kdo může požádat o změnu klíče .............................................................................. 38
4.7.2.1 Kořenová CA ............................................................................................................. 38
4.7.2.2 TLM ........................................................................................................................... 38
4.7.2.3 EA a AA ..................................................................................................................... 38
4.7.2.4 Stanice C-ITS ............................................................................................................. 39
4.7.3 Proces změny klíče ..................................................................................................... 39
4.7.3.1 Certifikát TLM ........................................................................................................... 39
4.7.3.2 Certifikát kořenové CA .............................................................................................. 39
4.7.3.3 Certifikáty EA a AA ................................................................................................... 39
4.7.3.4 Certifikáty stanice C-ITS ........................................................................................... 40
4.8 Změna v certifikátu .................................................................................................... 40
4.9 Odvolání a pozastavení platnosti certifikátu .............................................................. 40
4.10 Služby ověřování stavu certifikátu ............................................................................. 40
4.10.1 Provozní charakteristiky ............................................................................................. 40
4.10.2 Dostupnost služby ...................................................................................................... 40
4.10.3 Volitelné prvky ........................................................................................................... 40
CS 5 CS
4.11 Ukončení účasti .......................................................................................................... 40
4.12 Úschova klíče u třetí strany a jeho obnova ................................................................ 40
4.12.1 Účastník ...................................................................................................................... 40
4.12.1.1 Jaký pár klíčů lze uschovat u třetí strany ................................................................... 40
4.12.1.2 Kdo může podat žádost o obnovu .............................................................................. 40
4.12.1.3 Proces a povinnosti obnovy ....................................................................................... 40
4.12.1.4 Identifikace a autentizace ........................................................................................... 40
4.12.1.5 Schválení nebo zamítnutí žádostí o obnovu ............................................................... 40
4.12.1.6 Akce KEA a KRA v průběhu obnovy páru klíčů ....................................................... 41
4.12.1.7 Dostupnost akcí KEA a KRA .................................................................................... 41
4.12.2 Politika a postupy enkapsulace a obnovy klíče relace ............................................... 41
5. Kontroly zařízení, kontroly řízení a provozní kontroly ............................................. 41
5.1 Fyzické kontroly ......................................................................................................... 41
5.1.1 Umístění a konstrukce ................................................................................................ 41
5.1.1.1 Kořenová CA, CPOC, TLM....................................................................................... 41
5.1.1.2 EA/AA........................................................................................................................ 42
5.2.1 Fyzický přístup ........................................................................................................... 42
5.1.2.1 Kořenová CA, CPOC, TLM....................................................................................... 42
5.1.2.2 EA/AA........................................................................................................................ 43
5.1.3 Napájení a klimatizace ............................................................................................... 43
5.1.4 Vystavení vodě ........................................................................................................... 43
5.1.5 Protipožární opatření a ochrana ................................................................................. 44
5.1.6 Správa médií ............................................................................................................... 44
5.1.7 Likvidace odpadu ....................................................................................................... 44
5.1.8 Záloha mimo pracoviště ............................................................................................. 44
5.1.8.1 Kořenová CA, CPOC a TLM ..................................................................................... 44
5.1.8.2 EA/AA........................................................................................................................ 45
5.2 Procedurální kontroly ................................................................................................. 45
5.2.1 Důvěryhodné role ....................................................................................................... 45
5.2.2 Počet osob požadovaný pro každý úkol ..................................................................... 45
5.3.2 Identifikace a autentizace pro každou roli ................................................................. 46
5.4.2 Role vyžadující oddělení povinností .......................................................................... 46
5.3 Kontroly pracovníků .................................................................................................. 47
5.3.1 Požadavky na kvalifikace, zkušenosti a ověření spolehlivosti ................................... 47
5.3.2 Postupy ověření spolehlivosti .................................................................................... 47
CS 6 CS
5.3.3 Požadavky na výcvik .................................................................................................. 48
5.4.3 Četnost rekvalifikace a požadavky na ni .................................................................... 48
5.5.3 Četnost rotace pracovních míst a jejich pořadí .......................................................... 48
5.3.6 Sankce za neautorizované činnosti ............................................................................. 48
5.3.7 Požadavky na nezávislé dodavatele ........................................................................... 49
5.3.8 Dokumentace poskytovaná pracovníkům .................................................................. 49
5.4 Postupy protokolování auditu .................................................................................... 49
5.4.1 Typy událostí, které mají být zaznamenávány a oznamovány každou CA ................ 49
5.4.2 Četnost zpracování protokolu .................................................................................... 50
5.4.3 Doba uchovávání auditního protokolu ....................................................................... 50
5.4.4 Ochrana auditního protokolu...................................................................................... 51
5.5.4 Postupy zálohování auditního protokolu .................................................................... 51
5.4.6 Auditní systém sběru údajů (interní nebo externí) ..................................................... 51
5.4.7 Oznámení subjektu, který událost způsobil ............................................................... 51
5.4.8 Hodnocení zranitelnosti ............................................................................................. 51
5.5 Archivace záznamů .................................................................................................... 52
5.5.1 Typy archivovaných záznamů .................................................................................... 52
5.5.2 Doba uchovávání v archivu ........................................................................................ 53
5.5.3 Ochrana archivu ......................................................................................................... 53
5.5.4 Systémový archiv a uchovávání ................................................................................. 53
5.5.5 Požadavky na časová razítka záznamů ...................................................................... 54
5.5.6 Systém archivace (interní nebo externí) ..................................................................... 54
5.5.7 Postupy získávání a ověřování archivních informací ................................................. 54
5.6 Změna klíčů pro prvky C-ITS modelu služeb vytvářejících důvěru .......................... 54
5.6.1 TLM ........................................................................................................................... 54
5.6.2 Kořenová CA ............................................................................................................. 54
5.6.3 Certifikát EA/AA ....................................................................................................... 54
5.6.4 Auditor ....................................................................................................................... 55
5.7 Obnova po ohrožení a havárii .................................................................................... 55
5.7.1 Řešení incidentů a ohrožení ....................................................................................... 55
5.7.2 Porušení výpočetních zdrojů, softwaru a/nebo dat .................................................... 56
5.7.3 Postupy při ohrožení soukromého klíče subjektu ...................................................... 56
5.7.4 Schopnosti kontinuity činnosti po havárii .................................................................. 56
5.8 Ukončení a převod ..................................................................................................... 57
5.8.1 TLM ........................................................................................................................... 57
CS 7 CS
5.8.2 Kořenová CA ............................................................................................................. 57
5.8.3 EA/AA........................................................................................................................ 58
6. Technické bezpečnostní kontroly ............................................................................... 58
6.1 Generování a instalace páru klíčů .............................................................................. 58
6.1.1 TLM, kořenová CA, EA, AA ..................................................................................... 58
6.1.2 Koncový subjekt – mobilní stanice C-ITS ................................................................. 58
6.1.3 Koncový subjekt – pevné stanice C-ITS .................................................................... 59
6.1.4 Kryptografické požadavky ......................................................................................... 59
6.1.4.1 Algoritmus a délka klíče – algoritmy podpisu ........................................................... 59
6.1.4.2 Algoritmus a délka klíče – šifrovací algoritmy pro registraci a autorizaci ................ 60
6.1.4.3 Kryptoagilita .............................................................................................................. 61
6.1.5 Bezpečné uchovávání soukromých klíčů ................................................................... 61
6.1.5.1 Úroveň kořenové CA, podřízené CA a TLM ............................................................. 61
6.1.5.2 Koncový subjekt......................................................................................................... 62
6.1.6 Zálohování soukromých klíčů .................................................................................... 63
6.1.7 Likvidace soukromých klíčů ...................................................................................... 63
6.2 Aktivační údaje .......................................................................................................... 63
6.3 Počítačové bezpečnostní kontroly .............................................................................. 63
6.4 Technické kontroly životního cyklu ........................................................................... 63
6.5 Bezpečnostní kontroly sítě ......................................................................................... 63
7. Profily certifikátů, CRL a CTL .................................................................................. 63
7.1 Profil certifikátu ......................................................................................................... 63
7.2 Platnost certifikátu ..................................................................................................... 64
7.2.1 Certifikáty pseudonymu ............................................................................................. 65
7.2.2 Autorizační potvrzení pro pevné stanice C-ITS ......................................................... 65
7.3 Odvolání certifikátů ................................................................................................... 65
7.3.1 Odvolání certifikátů CA, EA a AA ............................................................................ 65
7.3.2 Odvolání oprávnění k registraci ................................................................................. 66
7.3.3 Odvolání potvrzení o autorizaci ................................................................................. 66
7.4 Seznam odvolaných certifikátů .................................................................................. 66
7.5 Evropský seznam důvěryhodných certifikátů ............................................................ 66
8. Audit souladu a další posouzení ................................................................................. 66
8.1 Témata auditu a základ auditu.................................................................................... 66
8.2 Četnost auditů............................................................................................................. 67
8.3 Totožnost/kvalifikace auditora ................................................................................... 67
CS 8 CS
8.4 Vztah auditora k auditovanému subjektu ................................................................... 67
8.5 Opatření přijatá v důsledku nedostatku ...................................................................... 68
8.6 Sdělování výsledků .................................................................................................... 68
9. Jiná ustanovení ........................................................................................................... 68
9.1 Poplatky...................................................................................................................... 68
9.2 Finanční odpovědnost ................................................................................................ 69
9.3 Důvěrnost obchodních informací ............................................................................... 69
9.4 Plán ochrany soukromí ............................................................................................... 69
10. Odkazy ....................................................................................................................... 69
CS 9 CS
PŘÍLOHA III
1. ÚVOD
1.1. Přehled a oblast působnosti této politiky
Tato certifikační politika definuje evropský C-ITS model C-ITS služeb vytvářejících
důvěru založený na infrastruktuře veřejných klíčů (PKI) v rámci celkového systému
správy bezpečnostních oprávnění pro EU C-ITS (EU CCMS). Definuje rovněž
požadavky na správu certifikátů veřejných klíčů pro aplikace C-ITS vydávajícími
subjekty a jejich využívání koncovými subjekty v Evropě. Na nejvyšší úrovni se PKI
skládá ze souboru kořenových certifikačních autorit „umožněných“ tím, že správce
seznamu důvěryhodných subjektů (TLM) vložil jejich certifikáty do evropského
seznamu důvěryhodných certifikátů (ECTL), který vydává a zveřejňuje centrální
subjekt TLM (viz oddíly 1.2 a 1.3).
Tato politika je závazná pro všechny subjekty zapojené do C-ITS systému služeb
vytvářejících důvěru v Evropě. Pomáhá při posuzování úrovně důvěry, kterou může
u obdržených informací stanovit kterýkoli příjemce zprávy ověřené certifikátem
koncového subjektu PKI. Aby bylo možné posoudit důvěru v certifikáty poskytnuté
EU CCMS, stanoví závazný soubor požadavků pro provoz centrálního subjektu TLM
a pro sestavování a správu ECTL. V důsledku toho tímto dokumentem řídí
následující aspekty ECTL:
• identifikace a autentizace hlavních účastníků, kteří získávají role PKI pro
TLM, včetně popisu privilegií přidělených každé roli,
• minimální požadavky na místní bezpečnostní postupy TLM, včetně fyzických
kontrol, kontrol pracovníků a procedurálních kontrol,
• minimální požadavky na postupy technické bezpečnosti TLM, včetně
počítačových bezpečnostních kontrol, kontrol bezpečnosti sítě a technických
kontrol kryptografického modulu,
• minimální požadavky na provozní postupy TLM, včetně registrace nových
certifikátů kořenových CA, dočasné nebo trvalé deregistrace stávajících
zařazených kořenových CA a zveřejňování a distribuce aktualizací ECTL,
• profil ECTL včetně všech povinných a nepovinných datových polí v ECTL,
kryptografických algoritmů, které mají být použity, přesného formátu ECTL a
doporučení pro zpracování ECTL,
• správa životního cyklu certifikátu ECTL, včetně distribuce certifikátů ECTL,
jejich aktivace, konec platnosti a odvolání;
• v případě potřeby správa odvolání důvěry kořenových CA.
Vzhledem k tomu, že důvěryhodnost ECTL nezávisí pouze na ECTL samotném, ale
do značné míry také na kořenových CA, z nichž se skládá PKI, a jejich podřízených
CA, stanoví tato politika rovněž minimální požadavky, které jsou povinné pro
všechny zúčastněné CA (kořenové CA a podřízené CA). Jedná se o tyto požadavky:
• identifikace a autentizace hlavních účastníků, kteří získávají role PKI (např.
bezpečnostní referent, referent pro ochranu soukromí, bezpečnostní správce,
správce adresáře a konečný uživatel), včetně popisu povinností, odpovědností,
závazků a privilegií spojených s každou rolí,
CS 10 CS
• správa klíčů, včetně přijatelných a povinných algoritmů pro podepisování
certifikátů a dat a dob platnosti certifikátů,
• minimální požadavky na místní bezpečnostní postupy, včetně fyzických
kontrol, kontrol pracovníků a procedurálních kontrol,
• minimální požadavky na postupy technické bezpečnosti, jako jsou kontroly
bezpečnosti počítačů, kontroly bezpečnosti sítě a technické kontroly
kryptografického modulu,
• minimální požadavky na provozní postupy CA, EA, AA a koncových subjektů,
včetně aspektů registrace, deregistrace (tj. vyřazení ze seznamu), odvolání,
ohrožení klíče, důvodného odmítnutí, aktualizace certifikátu, auditních postupů
a nezveřejnění soukromých informací,
• profil certifikátu a CRL, včetně formátů, přijatelných algoritmů, povinných a
nepovinných datových polí a jejich platných rozsahů hodnot a toho, jak mají
ověřovatelé certifikáty zpracovávat,
• pravidelné sledování, hlášení, varování a obnovení povinností subjektů C-ITS
modelu služeb vytvářejících důvěru za účelem zřízení bezpečného provozu, a
to i v případech pochybení.
Kromě těchto minimálních požadavků mohou subjekty, které provozují kořenové CA
a podřízené CA, rozhodovat o svých vlastních dodatečných požadavcích a
stanovovat je v příslušných prohlášeních o certifikačním postupu (CPS) za
předpokladu, že nejsou v rozporu s požadavky stanovenými v certifikační politice.
Podrobnosti o auditu a zveřejňování CPS viz oddíl 1.5.
Certifikační politika stanoví rovněž účely, pro které mohou být kořenové CA,
podřízené CA a jimi vydané certifikáty použity. Stanoví odpovědnosti, které na sebe
bere:
• správce seznamu důvěryhodných subjektů (TLM),
• každá kořenová CA, jejíž certifikáty jsou uvedeny v ECTL,
• podřízené CA kořenové CA (EA a AA),
• každý člen nebo organizace odpovědná za jeden ze subjektů C-ITS modelu
služeb vytvářejících důvěru nebo jej provozující.
Certifikační politika (CP) definuje rovněž závazné povinnosti vztahující se na:
• správce seznamu důvěryhodných subjektů (TLM),
• každou kořenovou CA, jejíž certifikáty jsou uvedeny v ECTL,
• každou podřízenou CA certifikovanou kořenovou CA,
• všechny koncové subjekty,
• každou členskou organizaci odpovědnou za jeden ze subjektů C-ITS modelu
služeb vytvářejících důvěru nebo jej provozující.
CP také stanoví požadavky, pokud jde o dokumentaci omezení odpovědností a
povinností v prohlášení o certifikačním postupu (CPS) každé kořenové CA, jejíž
certifikáty jsou uvedeny v ECTL.
CS 11 CS
Tato CP je v souladu s certifikační politikou a rámcem certifikačních postupů
přijatými Komisí pro technickou stránku internetu (IETF) [3].
1.2. Definice a zkratky
Platí definice uvedené v [2], [3] a [4].
AA autorizační autorita (authorisation authority)
AT potvrzení o autorizaci (authorisation ticket)
CA certifikační autorita (certification authority)
CP certifikační politika (certificate policy)
CPA orgán pro certifikační politiku C-ITS (C-ITS certificate policy authority)
CPOC kontaktní místo C-ITS (C-ITS point of contact)
CPS prohlášení o certifikačním postupu (certificate practice statement)
CRL seznam odvolaných certifikátů (certificate revocation list)
EA registrující autorita (enrolment authority)
EC oprávnění k registraci (enrolment credential)
ECIES integrovaný šifrovací systém pomocí eliptických křivek (elliptic curve integrated encryption
scheme)
EE koncový subjekt (tj. stanice C-ITS) (end-entity (i.e. C-ITS station))
ECTL evropský seznam důvěryhodných certifikátů (European certificate trust list)
EU CCMS systém správy bezpečnostních oprávnění pro EU C-ITS (EU C-ITS security credential
management systém)
GDPR obecné nařízení o ochraně údajů (General Data Protection Regulation)
HSM hardwarový bezpečnostní modul (Hardware security module)
PKI infrastruktura veřejných klíčů (public key infrastructure)
RA registrační autorita (registration authority)
podřízená CA EA a AA
TLM správce seznamu důvěryhodných entit (trust list manager)
CS 12 CS
Glosář
žadatel Fyzická nebo právnická osoba žádající o certifikát (příp. jeho obnovení). Po vytvoření iniciačního
certifikátu (inicializaci) se žadatel označuje jako účastník.
U certifikátů vydaných koncovým subjektům je účastníkem (žadatelem o certifikát) osoba, která
ovládá nebo provozuje/udržuje koncový subjekt, pro který je certifikát vydán, a to i v případě, že
vlastní žádost o certifikát odesílá koncový subjekt.
autorizační
autorita
Pojem „autorizační autorita“ (AA) odkazuje v tomto dokumentu nejen na konkrétní funkci AA,
ale také na právní a/nebo provozní subjekt, který ji spravuje.
certifikační
autorita
Kořenová certifikační autorita, registrující autorita a autorizační autorita jsou souhrnně
označovány jako certifikační autorita (CA).
C-ITS model
služeb
vytvářejících
důvěru
C-ITS model služeb vytvářejících důvěru slouží k navázání důvěryhodného vztahu mezi stanicemi
C-ITS. Je implementován za použití PKI, která se skládá z CA, CPOC, TLM, EA, AA a
zabezpečené sítě.
kryptoagilita Schopnost subjektů C-ITS modelu služeb vytvářejících důvěru přizpůsobit CP měnícím se
prostředím nebo novým budoucím požadavkům, např. změnou kryptografických algoritmů a
délkou klíčů v průběhu času.
kryptografický
modul
Zabezpečený hardwarový prvek, v němž jsou generovány a/nebo uloženy kryptografické klíče,
generována náhodná čísla a podepisována nebo šifrována data.
registrující
autorita
Pojem „registrující autorita“ (EA) odkazuje v tomto dokumentu nejen na konkrétní funkci EA, ale
také na právní a/nebo provozní subjekt, který ji spravuje.
účastníci PKI Subjekty C-ITS modelu služeb vytvářejících důvěru, tj. TLM, kořenové CA, EA, AA a stanice C-
ITS.
změna klíče Tato podkomponenta se používá k popisu určitých prvků vztahujících se k účastníkovi nebo
jinému aktérovi, který generuje nový pár klíčů a žádá o vydání nového certifikátu, kterým
certifikuje nový veřejný klíč, jak je popsáno v [8].
úložiště Úložiště používané k ukládání certifikátů poskytnutých subjekty C-ITS modelu služeb
vytvářejících důvěru a informací o těchto certifikátech, jak je definováno v oddíle 2.3.
kořenová
certifikační
autorita
Pojem „kořenová certifikační autorita“ (CA) odkazuje v tomto dokumentu nejen na konkrétní
funkci CA, ale také na právní a/nebo provozní subjekt, který ji spravuje.
subjekt Fyzická osoba, zařízení, systém, jednotka nebo právnická osoba identifikovaná v certifikátu jako
subjekt, tj. buď účastník, nebo zařízení účastníkem ovládané a provozované.
účastník Fyzická nebo právnická osoba, které je vydán certifikát a která je právně vázána smlouvou o
účastnictví nebo všeobecnými podmínkami použití.
účastnická
smlouva
Smlouva mezi CA a žadatelem/účastníkem, která specifikuje práva a povinnosti smluvních stran.
CS 13 CS
1.3. Účastníci PKI
1.3.1. Úvod
Účastníci PKI hrají v PKI roli definovanou touto politikou. Není-li to výslovně
zakázáno, může účastník převzít současně několik rolí. Může mu být zakázáno
převzít ve stejném čase konkrétní role, aby nedocházelo ke střetům zájmů nebo aby
bylo zajištěno oddělení funkcí.
Účastníci mohou části své role rovněž přenést na jiné subjekty v rámci smlouvy o
poskytování služeb. Pokud se například informace o stavu odvolání poskytují pomocí
CRL, CA je rovněž vydavatelem CRL, odpovědnost za vydání CRL však může
přenést na jiný subjekt.
Role PKI sestávají z:
• autoritativních rolí, tj. každá role je jedinečně vytvořená instance;
• provozních rolí, tj. rolí, jejichž instanci lze vytvořit v jednom nebo více
subjektech.
Například kořenová CA může být implementována podnikatelským subjektem,
zájmovou skupinou, národní organizací a/nebo evropskou organizací.
Obrázek 1 znázorňuje architekturu C-ITS modelu služeb vytvářejících důvěru
založenou na [2]. Architektura je stručně popsána zde, hlavní prvky jsou však
podrobněji popsány v oddílech 1.3.2 až 1.3.6.
CPA jmenuje TLM, což je tudíž důvěryhodný subjekt pro všechny účastníky PKI.
CPA schvaluje fungování kořenové CA a potvrzuje, že TLM může důvěřovat
kořenové CA (kořenovým CA). TLM vydává ECTL, jenž poskytuje všem
účastníkům PKI důvěru ve schválené kořenové CA. Kořenová CA vydává certifikáty
autoritám EA a AA, čímž zajišťuje důvěru v jejich fungování. EA vydává certifikáty
o registraci vysílajícím a předávajícím stanicím C-ITS (jako koncovým subjektům),
čímž zajišťuje důvěru v jejich fungování. AA vydává potvrzení o autorizaci (AT)
stanicím C-ITS na základě důvěry v EA.
Přijímající a předávající stanice C-ITS (jako předávající strana) může důvěřovat
ostatním stanicím C-ITS, protože AT jsou vydávána autoritou AA, které důvěřuje
kořenová CA, které důvěřují TLM a CPA.
Obrázek 1 popisuje pouze úroveň kořenové CA C-ITS modelu služeb vytvářejících
důvěru. Podrobnosti o nižších vrstvách jsou uvedeny v následujících oddílech této
CP nebo v CPS konkrétních kořenových CA.
Obrázek 2 znázorňuje přehled informačních toků mezi účastníky PKI. Zelené tečky
označují toky, které vyžadují komunikace stroj-stroj. Informační toky v červené
barvě mají definované bezpečnostní požadavky.
C-ITS model služeb vytvářejících důvěru je založen na architektuře několika
kořenových CA, kde jsou certifikáty kořenové CA předávány pravidelně (jak je
stanoveno níže) do centrálního kontaktního místa (CPOC) prostřednictvím
zabezpečeného protokolu (např. spojovacích certifikátů) definovaného CPOC.
Kořenovou CA může provozovat státní nebo soukromá organizace. Architektura C-
ITS modelu služeb vytvářejících důvěru obsahuje alespoň jednu kořenovou CA
(kořenová CA EU se stejnou úrovní jako ostatní kořenové CA). Na kořenovou CA
EU delegují všechny subjekty, které se účastní C-ITS modelu služeb vytvářejících
CS 14 CS
důvěru a které nechtějí zřídit svou vlastní kořenovou CA. CPOC přenáší přijaté
certifikáty kořenové CA na TLM, který odpovídá za shromažďování a podepisování
seznamu certifikátů kořenových CA a za jejich zaslání zpět do CPOC, které je
zpřístupní veřejnosti (viz níže).
Vztahy důvěry mezi subjekty v C-ITS modelu služeb vytvářejících důvěru jsou
popsány na následujících obrázcích, tabulkách a oddílech.
Obrázek 1: Architektura C-ITS modelu služeb vytvářejících důvěru
Obrázek 2: Toky informací v C-ITS modelu služeb vytvářejících důvěru
TLM
Orgán pro certifikační politiku C-ITS
Popis:TLM … správce seznamu důvěryhodných subjektůCPOC … kontaktní místo C-ITS CA … certifikační autorita EA … registrující autoritaAA … autorizační autorita
. . . koř. CA EU
Další kořenové CA provozované v Evropě orgány členských států nebo soukromými organizacemi, které konkrétním uživatelům poskytují certifikáty.
společné evropské prvky
… vztah důvěry
koř. CA Nkoř. CA 1 koř. CA 2
CPOC
EA AA EA AAEA AA EA AAEA AAEA AAEA AA
EA AAEA AA
orgán pro certifikační politiku C-ITS
TLM
CPOC
kořenová CA
(37) požadavky na změnu CP (všechny)
(5) změna ECTL
(1) schválení / (2) odvolání
kořen. CA
(7) ECTL(6) TLM
cert.(8) informace o certifikátu kořen. CA(9) odvolání kořen. CA
(11) informace o certifikátu kořen. CA(12) odvolání certifikátu kořen. CA
(3) aktualizace CP(4) schválení / zamítnutí
(14) formulář žádosti(15) změny CPS +(16) zpráva o auditu(17) zpráva (incidenty)
úložiště CPOCTLM cert
ECTL
akreditovaný auditor PKI (36) zpráva
(13) pokyn
úložiště kořen. CAcertifikát (EA)/CA
CRL EA AA
(21) žádost o cert EA (1
8)
od
po
věď
(24) žádst o
cert. EA
(19
) o
dp
ově
ď
(23) autorizační odpověď
(25) autorizační žádost
stanice C-ITS
(31) žádost
o registraci (22) odpověď
(33) registrace(34) deaktivace
(32) žádost o autentizaci
(26) odpověď
výrobce / provozovatel
(27) podánížádosti
(30
) o
dp
ově
ď(28) podánížádosti
(29
) o
dp
ově
ď
(38) formulář žádosti(40) zpráva o auditu
(39) schválení /zamítnutí
CS 15 CS
CS 16 CS
ID toku Od K Obsah Odkaz
(1). CPA TLM schválení žádosti kořenové CA 8
(2). CPA TLM informace o odvolání kořenové CA 8.5
(3). CPA kořenová
CA
aktualizace CP 1.5
(4). CPA kořenová
CA
schválení/zamítnutí formuláře žádosti kořenové
CA nebo změn žádosti CPS nebo auditního
procesu
8.5, 8.6
(5). TLM CPA oznámení o změně ECTL 4, 5.8.1
(6). TLM CPOC certifikát TLM 4.4.2
(7). TLM CPOC ECTL 4.4.2
(8). CPOC TLM informace o certifikátu kořenové CA 4.3.1.1
(9). CPOC TLM odvolání certifikátu kořenové CA 7.3
(10). CPOC všechny
koncové
subjekty
certifikát TLM 4.4.2
(11). kořenová CA CPOC informace o certifikátu kořenové CA 4.3.1.1
(12). kořenová CA CPOC odvolání certifikátu kořenové CA 7.3
(13). kořenová CA auditor pokyn k auditu 8
(14). kořenová CA CPA formulář žádosti kořenové CA – počáteční žádost 4.1.2.1
(15). kořenová CA CPA formulář žádosti kořenové CA – změny CPS 1.5.1
(16). kořenová CA CPA formulář žádosti kořenové CA – zpráva o auditu 8.6
(17). kořenová CA CPA zprávy o incidentu kořenové CA, včetně odvolání
podřízené CA (EA, AA)
příloha III, 7.3.1
(18). kořenová CA EA odpověď na certifikát EA 4.2.2.3
(19). kořenová CA AA odpověď na certifikát AA 4.2.2.3
(20). kořenová CA vše certifikát EA/AA, CRL 4.4.2
(21). EA kořenová
CA
žádost o certifikát EA 4.2.2.3
(22). EA stanice C-
ITS
odpověď na oprávnění k registraci 4.3.1.4
(23). EA AA odpověď na autorizaci 4.2.2.5
(24). AA kořenová
CA
žádost o certifikát AA 4.2.2.3
(25). AA EA žádost o autorizaci 4.2.2.5
(26). AA stanice C-
ITS
odpověď na potvrzení o autorizaci 4.3.1.5
CS 17 CS
(27). EA kořenová
CA
předložení žádosti 4.1.2.3
(28). AA kořenová
CA
předložení žádosti 4.1.2.3
(29). kořenová CA EA odpověď 4.12 a 4.2.1
(30). kořenová CA AA odpověď 4.12 a 4.2.1
(31). stanice C-ITS EA žádost o oprávnění k registraci 4.2.2.4
(32). stanice C-ITS AA žádost o potvrzení o autorizaci 4.2.2.5
(33). výrobce /
provozovatel
EA registrace 4.2.1.4
(34). výrobce /
provozovatel
EA deaktivace 7.3
(35). EA výrobce /
provozovat
el
odpověď 4.2.1.4
(36). auditor kořenová
CA
zpráva 8.1
(37). vše CPA žádosti o změnu CP 1.5
(38). TLM CPA formulář žádosti 4.1.2.2
(39). CPA TLM schválení/zamítnutí 4.1.2.2
(40). TLM CPA zpráva o auditu 4.1.2.2
Tabulka 1: Podrobný popis toků informací v C-ITS modelu služeb vytvářejících důvěru
1.3.2. Orgán pro certifikační politiku C-ITS
1) Orgán pro certifikační politiku C-ITS (CPA) se skládá ze zástupců veřejných a
soukromých zúčastněných stran (např. členských států, výrobců vozidel atd.),
které se účastní C-ITS modelu služeb vytvářejících důvěru. Je odpovědný za
dvě dílčí role:
1) řízení certifikační politiky, včetně:
• schvalování stávající CP a budoucích žádostí o změnu CP;
• rozhodování o přezkumu žádostí o změnu CP a o doporučeních
předložených jinými účastníky nebo subjekty PKI;
• rozhodování o vydání nových verzí CP;
2) správu autorizací PKI, včetně:
• definování schvalovacích postupů CPS a auditu CA (společně
označovaných jako „schvalovací postupy CA“), rozhodování o nich a
jejich zveřejňování;
• autorizace provozu a pravidelného podávání zpráv CPOC;
• autorizace provozu a pravidelného podávání zpráv TLM;
CS 18 CS
• schvalování CPS kořenové CA, je-li v souladu se společnou a platnou
CP;
• kontrola zpráv o auditu akreditovaných auditorů PKI pro všechny
kořenové CA;
• informování TLM o seznamu schválených nebo neschválených
kořenových CA a jejich certifikátů na základě obdržených zpráv o
schválení kořenových CA a pravidelných zpráv o činnosti.
2) Autorizovaný zástupce CPA odpovídá za autentizaci autorizovaného zástupce
TLM a za schválení formuláře žádosti procesu registrace TLM. CPA odpovídá
za autorizaci provozu TLM, jak je uvedeno v tomto oddíle.
1.3.3. Správce seznamu důvěryhodných subjektů
3) Správce seznamu důvěryhodných subjektů (TLM) je jediný subjekt jmenovaný
CPA.
4) TLM odpovídá za:
• fungování ECTL v souladu se společnou platnou CP a pravidelnou
zprávou o činnosti CPA, pokud jde o celkové bezpečné fungování CITS
modelu služeb vytvářejících důvěru,
• přijetí certifikátů kořenových CA od CPOC,
• zahrnutí certifikátů kořenových CA do ECTL či jejich vyloučení na
základě oznámení CPA,
• podepisování ECTL,
• pravidelný a včasný přenos ECTL na CPOC.
1.3.4. Akreditovaný auditor PKI
5) Akreditovaný auditor PKI odpovídá za:
• provádění nebo organizování auditů kořenových CA, TLM a podřízených
CA;
• distribuci zprávy o auditu (z počátečního nebo pravidelného auditu) CPA
v souladu s požadavky v oddíle 8. Zpráva o auditu musí zahrnovat
doporučení akreditovaných auditorů PKI,
• oznámení subjektu řídícímu kořenovou CA o úspěšném nebo
neúspěšném provedení počátečního nebo pravidelného auditu
podřízených CA;
• posouzení souladu CPS s touto CP.
1.3.5. Kontaktní místo C-ITS (CPOC)
6) Kontaktní místo C-ITS (CPOC) je jediný subjekt jmenovaný CPA.
Autorizovaný zástupce CPA odpovídá za autentizaci autorizovaného zástupce
CPOC a za schválení formuláře žádosti procesu registrace CPOC. CPA
odpovídá za autorizaci provozu CPOC, jak je uvedeno v tomto oddíle.
7) CPOC odpovídá za:
• zřízení účinné a rychlé bezpečné komunikační výměny mezi všemi
subjekty C-ITS modelu služeb vytvářejících důvěru a přispívání do ní;
CS 19 CS
• přezkum žádostí o procedurální změnu a doporučení předložených
ostatními účastníky modelu služeb vytvářejících důvěru (např.
kořenovými CA);
• předávání certifikátů kořenových CA do TLM;
• zveřejňování společného „trust anchor“ (aktuální veřejný klíč a spojovací
certifikát TLM);
• zveřejnění ECTL.
Úplné údaje o ECTL jsou uvedeny v oddíle 7.
1.3.6. Provozní role
8) Provozní roli, jak je definována v RFC 3647, hrají tyto subjekty vymezené v
[2]:
Funkční prvek Role PKI ([3] a [4]) Podrobná role ([2])
kořenová certifikační autorita CA/RA (registrační
autorita) Poskytuje EA a AA doklad, že může vydávat EC nebo
AT.
registrující autorita účastník kořenové CA /
subjekt certifikátu EA
CA/RA
Autentizuje stanici C-ITS a uděluje jí přístup ke
komunikacím ITS
autorizační autorita účastník kořenové CA /
subjekt certifikátu AA
CA/RA
Poskytuje stanici C-ITS autoritativní doklad, že může
používat konkrétní služby ITS.
zasílající stanice C-ITS subjekt certifikátu
koncového subjektu (EE)
(EC)
Získává od EA práva k přístupu ke komunikacím ITS.
Vyjednává s AA práva na používání služeb ITS.
Vysílá zprávy jednoduchým přeposláním a předáváním.
předávající (přeposílající)
stanice C-ITS předávací strana / subjekt
certifikátu EE Přijímá vysílanou zprávu od zasílající stanice C-ITS a
předává ji dle potřeby přijímající stanici C-ITS
přijímající stanice C-ITS předávající strana Přijímá vysílanou zprávu od zasílající nebo předávající
stanice C-ITS
výrobce účastník EA Instaluje do stanice C-ITS během výroby informace
nezbytné pro řízení bezpečnosti
provozovatel účastník EA / AA Instaluje a aktualizuje ve stanici C-ITS během provozu
nezbytné informace pro řízení bezpečnosti
Tabulka 2: Provozní role
Pozn.: V souladu s [4] se v této CP používají odlišné pojmy pro „účastníka“, který
uzavírá smlouvu s CA na vydání certifikátů, a „subjekt“, na který se certifikát
vztahuje. „Účastníky“ jsou všechny subjekty, které mají smluvní vztah s CA.
„Subjekty“ jsou subjekty, na něž se certifikát vztahuje. EA/AA jsou účastníky a
subjekty kořenové CA a mohou žádat o certifikáty EA/AA. Stanice C-ITS jsou
subjekty a mohou žádat o certifikáty koncového subjektu.
9) Registrační autority:
EA má plnit úlohu registrační autority pro koncové subjekty. Registrovat nové
koncové subjekty (stanice C-ITS) v EA může pouze autentizovaný a
CS 20 CS
autorizovaný účastník. Příslušné kořenové CA mají plnit úlohu registračních
autorit pro EA a AA.
1.4. Použití certifikátu
1.4.1. Příslušné oblasti použití
10) Certifikáty vydané podle aktuální CP jsou určeny k validaci digitálních podpisů
v oblasti komunikace kooperativních ITS v souladu s referenční architekturou
v [2].
11) Profily certifikátů v [5] určují použití certifikátů pro TLM, kořenové CA, EA,
AA a koncové subjekty.
1.4.2. Rozsah odpovědnosti
12) Certifikáty nejsou určeny ani povoleny k použití:
• za okolností, které porušují nebo narušují platný zákon, předpis (např.
GDPR), vyhlášku nebo nařízení vlády,
• za okolností, které porušují nebo narušují práva jiných osob,
• v rozporu s touto CP nebo příslušnou účastnickou smlouvou,
• za všech okolností, za kterých by jejich použití mohlo přímo vést k úmrtí,
ke zranění osob nebo k závažným škodám na životním prostředí (např.
při provozu jaderných zařízení, letecké navigace nebo komunikace či
systémů kontroly zbraní),
• za okolností, které jsou v rozporu s celkovými cíli větší bezpečnosti
silničního provozu a efektivnější silniční dopravy v Evropě.
1.5. Správa certifikační politiky
1.5.1. Aktualizace CPS certifikačních autorit uvedených v ECTL
13) Každá kořenová CA uvedená v ECTL zveřejní svou vlastní CPS, která musí
být v souladu s touto politikou. Kořenová CA může doplnit další požadavky,
musí však zajistit, aby byly vždy splněny všechny požadavky této CP.
14) Každá kořenová CA uvedená v ECTL zavede pro svůj dokument CPS vhodný
postup změn. Klíčové vlastnosti postupu změn musí být zdokumentovány ve
veřejné části CPS.
15) Postup změn musí zajistit, aby všechny změny této CP byly pečlivě
zanalyzovány, a pokud to bude potřeba pro soulad se změněnou CP, aby CPS
bylo aktualizováno v časovém rámci stanoveném v kroku implementace
postupu změny CP. Proces změny musí zejména zahrnovat postupy změny v
nouzi, který zajistí včasnou implementaci změn CP souvisejících s bezpečností.
16) Postup změn zahrnuje pro všechny změny CPS vhodná opatření k ověření
souladu s CP. Veškeré změny CPS musí být jasně zdokumentovány. Před
implementací nové verze CPS musí být její soulad s CP potvrzen
akreditovaným auditorem PKI.
17) Kořenová CA oznámí CPA každou změnu provedenou v CPS spolu s alespoň
těmito informacemi:
• přesný popis změny,
CS 21 CS
• odůvodnění změny,
• zpráva akreditovaného auditora PKI, která potvrzuje soulad s CP,
• kontaktní údaje osoby odpovědné za CPS,
• plánovaný časový rámec provádění.
1.5.2. Schvalovací postupy CPS
18) Před zahájením činnosti předloží potenciální kořenová CA svou CPS
akreditovanému auditorovi PKI jako součást pokynu k auditu souladu (tok 13)
a CPA ke schválení (tok 15).
19) Kořenová CA předloží změny ve své CPS akreditovanému auditorovi PKI jako
součást pokynu k auditu souladu (tok 13) a CPA ke schválení (tok 15) před
tím, než tyto změny nabudou účinku.
20) EA/AA předloží svůj CPS nebo změny CPS kořenové CA. Kořenová CA může
od vnitrostátního orgánu nebo soukromého subjektu odpovědného za
schvalování EA/AA, jak je definováno v oddíle 4.1.2 a 8, objednat certifikát o
shodě.
21) Akreditovaný auditor PKI posoudí CPS v souladu s oddílem 8.
22) Akreditovaný auditor PKI sdělí výsledky posouzení CPS v rámci zprávy
o auditu, jak je stanoveno v oddíle 8.1. CPS bude přijato nebo zamítnuto
v rámci přijetí zprávy o auditu, jak je uvedeno v oddílech 8.5 a 8.6.
2. POVINNOSTI V OBLASTI ZVEŘEJŇOVÁNÍ A ÚLOŽIŠŤ
2.1. Metody zveřejňování informací o certifikátech
23) Informace o certifikátu lze podle oddílu 2.5 zveřejňovat:
• pravidelně čili periodicky, nebo
• jako odpověď na žádost jednoho z účastnících se subjektů.
V každém z případů platí různé stupně naléhavosti zveřejnění, a tudíž i různé
harmonogramy, ale subjekty musí být připraveny na obě metody.
24) Pravidelné zveřejňování informací o certifikátu umožňuje určit maximální
lhůtu, v níž jsou informace o certifikátu aktualizovány pro všechny uzly sítě C-
ITS. Frekvence zveřejňování všech informací o certifikátu je stanovena
v oddíle 2.2.
25) Na žádost subjektů účastnících se sítě C-ITS může kterýkoliv z účastníků
kdykoli začít zveřejňovat informace z certifikátu a – v závislosti na svém stavu
– požádat o aktuální soubor informací o certifikátu, aby se z něj stal plně
důvěryhodný uzel sítě C-ITS. Účelem takového zveřejnění je především podat
subjektům aktuální informace o celkovém aktuálním stavu informací o
certifikátu v síti a umožnit jim, aby do příštího pravidelného zveřejnění
informací mohly spolu komunikovat na základě důvěry.
26) Jedna kořenová CA může rovněž kdykoli zahájit zveřejňování informací o
certifikátech tím, že zašle aktualizovaný soubor certifikátů všem „zapsaným
členům“ sítě C-ITS, kteří jsou pravidelnými příjemci těchto informací. To
CS 22 CS
podporuje fungování certifikačních autorit a umožňuje jim, aby oslovovaly
členy mezi pravidelnými a plánovanými daty zveřejňování certifikátů.
27) Oddíl 2.5 stanoví mechanismus a všechny postupy pro zveřejňování certifikátů
kořenových CA a ECTL.
28) CPOC zveřejní certifikáty kořenových CA (uvedené v ECTL a určené pro
veřejnou potřebu), certifikát TLM a ECTL, které vydává.
29) Kořenové CA zveřejní své certifikáty EA/AA a CRL jsou schopny podporovat
všechny tři zde uvedené mechanismy pro jejich zveřejňování svým zapsaným
členům a spoléhajícím se stranám a přijmou veškerá nezbytná opatření
k zajištění bezpečného přenosu, jak je uvedeno v oddíle 4.
2.2. Čas nebo četnost zveřejňování
30) Požadavky na harmonogram zveřejňování pro certifikáty a CRL musí být
stanoveny s ohledem na různé omezující faktory jednotných uzlů C-ITS,
přičemž celkovým cílem je provozování „důvěryhodné sítě“ a zveřejňování
aktualizací pro všechny zapojené stanice C-ITS co nejrychleji.
• Pro pravidelné zveřejňování aktualizovaných informací o certifikátech
(např. změn ve složení ECTL nebo CRL) se pro bezpečné fungování sítě
C-ITS požaduje maximální doba tří měsíců.
• Kořenové CA zveřejní své certifikáty CA a CRL co nejdříve po jejich
vydání.
• Pro zveřejnění CRL se použije úložiště kořenové CA.
CPS kromě toho stanoví pro každou CA dobu, během které bude certifikát
zveřejněn poté, co jej CA vydá.
Tento oddíl stanoví pouze čas nebo četnost pravidelného zveřejňování. V
souladu s požadavky v tomto dokumentu musí být implementovány prostředky
propojitelnosti pro aktualizaci stanice C-ITS o ECTL a CRL během jednoho
týdne po jejich zveřejnění (za normálních provozních podmínek, např. s
celulárním pokrytím, vozidlo za skutečného provozu atd.).
2.3. Úložiště
31) Požadavky na strukturu úložiště pro ukládání certifikátů a na to, jaké informace
subjekty sítě C-ITS poskytují, jsou pro jednotlivé subjekty tyto:
• obecně by každá kořenová CA měla používat úložiště svých vlastních v
současnosti aktivních informací o certifikátech EA/AA a CRL s cílem
zveřejňovat certifikáty pro ostatní účastníky PKI (např. adresářové služby
založené na LDAP). Úložiště každé kořenové CA podporuje všechny
požadované kontroly přístupu (oddíl 2.4) a časy přenosu (oddíl 2.2) pro
každou metodu distribuce informací týkajících se C-ITS,
• úložiště TLM (kam se ukládají například ECTL a certifikáty TLM
zveřejněné CPOC) by mělo být založeno na mechanismu zveřejňování,
který dokáže zajistit časy přenosu stanovené v oddíle 2.2 pro každou
metodu distribuce.
Požadavky AA nejsou definovány, ale musí podporovat stejné úrovně
bezpečnosti jako ostatní subjekty a tyto úrovně musí být deklarovány v jejich
CPS.
CS 23 CS
2.4. Kontroly přístupu do úložišť
32) Požadavky na kontrolu přístupu informací o certifikátech do úložišť musí
splňovat alespoň obecné normy pro bezpečné nakládání s informacemi
stanovené v normě ISO/IEC 27001 a požadavky v oddíle 4. Kromě toho musí
odrážet procesní potřeby bezpečnosti, jež mají být stanoveny pro jednotlivé
kroky procesu při zveřejňování informací o certifikátu.
• To zahrnuje implementaci úložiště certifikátů TLM a ECTL v
TLM/CPOC. Každá CA nebo provozovatel úložiště implementuje u
všech subjektů C-ITS a externích stran kontroly přístupu pro nejméně tři
různé úrovně (např. veřejnou, omezenou na subjekty C-ITS, úroveň
kořenové CA), aby neoprávněným subjektům zabránil přidávat záznamy
do úložiště, měnit je nebo mazat.
• Přesné mechanismy kontroly přístupu jednotlivého subjektu by měly být
součástí příslušného CPS.
• Pro každou kořenovou CA musí úložiště EA a AA splňovat stejné
požadavky na postupy kontroly přístupu bez ohledu na místo nebo
smluvní vztah k poskytovateli služeb, který úložiště provozuje.
Jako výchozí bod pro úroveň kontroly přístupu by každá kořenová CA nebo
provozovatel úložiště měl poskytnout alespoň tři různé úrovně (např. veřejnou,
omezenou na subjekty C-ITS, úroveň kořenových CA).
2.5. Zveřejňování informací o certifikátu
2.5.1. Zveřejňování informací o certifikátu správcem seznamu důvěryhodných subjektů
33) Správce seznamu důvěryhodných subjektů (TLM) v evropské společné oblasti
důvěry C-ITS zveřejní prostřednictvím CPOC tyto informace:
• všechny aktuálně platné certifikáty TLM pro další provozní období
(aktuální a spojovací certifikát, jsou-li k dispozici),
• informace o přístupovém bodu k úložišti CPOC s cílem poskytnout
podepsaný seznam kořenových CA (ECTL),
• obecné informační místo pro ECTL a zavádění C-ITS.
2.5.2. Zveřejňování informací o certifikátu certifikačními autoritami
34) Kořenové CA v evropské společné oblasti důvěry C-ITS zveřejňují tyto
informace:
• vydané (v současnosti platné) certifikáty kořenových CA (aktuální
a správně překlíčované certifikáty, včetně spojovacího certifikátu)
v úložišti uvedeném v oddíle 2.3,
• všechny platné subjekty EA/AA s identifikačním kódem jejich
provozovatele a plánovanou dobou provozu,
• vydané certifikáty CA v úložištích uvedených v oddíle 2.3,
• CRL pro všechny odvolané certifikáty CA, které se vztahují na jejich
podřízené EA a AA,
• informace o přístupu k CRL a informacím o CA konkrétní kořenové CA.
CS 24 CS
Veškeré informace o certifikátech musí být kategorizovány v souladu se třemi
úrovněmi důvěrnosti a dokumenty pro širokou veřejnost musí být bez omezení
veřejně dostupné.
3. IDENTIFIKACE A AUTENTIZACE
3.1. Pojmenovávání
3.1.1. Druhy názvu
3.1.1.1. Názvy TLM, kořenových CA, EA, AA
35) Název v certifikátu TLM obsahuje jediný atribut názvu subjektu
(subject_name) s vyhrazenou hodnotou „EU_TLM“.
36) Název kořenových CA se skládá z jediného atributu subject_name, jehož
hodnotu přiděluje CPA. Jedinečnost názvů je výlučnou odpovědností CPA a
TLM vede rejstřík názvů kořenových CA na základě oznámení CPA
(schválení, odvolání/odstranění kořenové CA). Názvy subjektů v certifikátech
jsou omezeny na 32 bajtů. Každá kořenová CA navrhuje svůj název CPA ve
formuláři žádosti (tok 14). Za kontrolu jedinečnosti názvu odpovídá CPA.
Není-li název jedinečný, žádost se zamítne (tok 4).
37) Název v každém certifikátu EA/AA může sestávat z jediného atributu
subject_name s hodnotou vygenerovanou vydavatelem certifikátu. Jedinečnost
názvů je výhradní odpovědností vydávající kořenové CA.
38) Certifikáty EA a AA nesmějí používat název větší než 32 bajtů, protože atribut
subject_name v certifikátech je omezen na 32 bajtů.
39) Potvrzení o autorizaci (AT) nesmí obsahovat název.
3.1.1.2. Názvy koncových subjektů
40) Každé stanici C-ITS se přidělí dva druhy jedinečného identifikátoru:
• kanonický identifikátor, který je uložen při původní registraci stanice C-
ITS na odpovědnost výrobce. Obsahuje dílčí řetězec, který identifikuje
výrobce nebo provozovatele, aby tento identifikátor mohl být jedinečný,
• atribut „subject_name“, jenž může být součástí oprávnění (EC) stanice
C-ITS, v odpovědnosti EA.
3.1.1.3. Identifikace certifikátů
41) Certifikáty řídící se formátem v [5] se identifikují výpočtem hodnoty
HashedI8, jak je definováno v [5].
3.1.2. Požadavek na smysluplnost názvů
Není stanoveno.
3.1.3. Anonymita a pseudonymita koncových subjektů
42) AA zajistí, aby byla zřízena pseudonymita stanice C-ITS tím, že stanice C-ITS
poskytne AT, které neobsahují žádné názvy ani informace, které by subjekt
mohly spojovat s jeho skutečnou identitou.
3.1.4. Pravidla pro výklad různých forem názvů
Není stanoveno.
CS 25 CS
3.1.5. Jedinečnost názvů
43) Názvy TLM, kořenových CA, EA, AA a kanonické identifikátory stanic C-ITS
musí být jedinečné.
44) TLM zajistí v registračním procesu dané kořenové CA v ECTL, aby jeho
identifikátor certifikátu (HashedI8) byl jedinečný. Kořenová CA zajistí v
procesu vydávání, aby identifikátor certifikátu (HashedI8) každé podřízené CA
byl jedinečný.
45) HashedI8 v oprávnění (EC) musí být v rámci vydávající CA jedinečný.
HashedId8 v potvrzení o autorizaci (AT) nemusí být jedinečný.
3.2. Počáteční potvrzení totožnosti
3.2.1. Metoda prokazování vlastnictví soukromého klíče
46) Kořenová CA prokáže, že oprávněně drží soukromý klíč odpovídající
veřejnému klíči v samopodepsaném certifikátu. CPOC tento důkaz zkontroluje.
47) EA/AA prokáže, že oprávněně drží soukromý klíč odpovídající veřejnému
klíči, který má být uveden v certifikátu. Kořenová CA tento důkaz zkontroluje.
48) Vlastnictví nového soukromého klíče (pro změnu klíče) se prokazuje podpisem
žádosti s novým soukromým klíčem (vnitřním podpisem), načež následuje
generování vnějšího podpisu podepsané žádosti se současným platným
soukromým klíčem (aby byla zaručena autenticita žádosti). Žadatel předloží
podepsanou žádost o certifikát vydávající CA prostřednictvím zabezpečené
komunikace. Vydávající CA ověří, že žadatelův digitální podpis ve zprávě o
žádosti byl vytvořen s použitím soukromého klíče odpovídajícího veřejnému
klíči připojenému k žádosti o certifikát. Kořenová CA ve svém CPS upřesní,
kterou žádost o certifikát a odpovědi podporuje.
3.2.2. Autentizace totožnosti organizace
3.2.2.1. Autentizace totožnosti organizace kořenových CA
49) Ve formuláři žádosti pro CPA (tj. tok 14) uvede kořenová CA totožnost
organizace a informace o registraci složené z:
• názvu organizace,
• poštovní adresy,
• e-mailové adresy,
• jména fyzické kontaktní osoby v organizaci,
• telefonního čísla,
• digitální otisk (tj. SHA 256 hashvalue) certifikátu kořenové CA v tištěné
podobě,
• kryptografických informací (tj. kryptografických algoritmů, délek klíčů)
v certifikátu kořenové CA,
• všech povolení, která kořenová CA smí používat a předávat podřízeným
CA.
50) CPA zkontroluje totožnost organizace a jiné informace o registraci poskytnuté
žadatelem o certifikát pro vložení nového certifikátu kořenové CA do ECTL.
CS 26 CS
51) CPA shromažďuje přímé důkazy nebo osvědčení o totožnosti z vhodného a
oprávněného zdroje (např. název) a případně veškeré specifické atributy
subjektů, kterým se certifikát vydává. Předložené důkazy mohou mít formu
tištěné nebo elektronické dokumentace.
52) Totožnost subjektu se v okamžiku registrace ověřuje vhodnými prostředky a v
souladu s aktuální certifikační politikou.
53) Při každé žádosti o certifikát se předkládají důkazy o:
• úplném názvu organizačního subjektu (soukromá organizace, vládní
subjekt nebo nekomerční subjekt);
• vnitrostátně uznané registraci nebo jiných atributech, které mohou být
případně použity k odlišení organizačního subjektu od jiných subjektů se
stejným názvem.
Výše uvedená pravidla vycházejí z TS 102 042 [2]: CA zajistí, aby důkazy o
identifikaci a přesnosti názvů a souvisejících údajů účastníka a subjektu byly řádně
přezkoumány v rámci definované služby, nebo případně vyvozeny prostřednictvím
přezkoumání osvědčení z vhodných a oprávněných zdrojů, a aby žádosti o certifikát
byly přesné, schválené a úplné v souladu se shromážděnými důkazy nebo
osvědčeními.
3.2.2.2. Autentizace totožnosti organizace TLM
54) Organizace provozující TLM doloží identifikaci a přesnost názvu a
souvisejících údajů, aby umožnila vhodné ověření při původním vytvoření a
změně klíče certifikátu TLM.
55) Totožnost subjektu musí být v době vytváření certifikátu nebo změny klíče
ověřena vhodnými prostředky a v souladu s aktuální CP.
56) Důkazy organizace se poskytnou tak, jak je uvedeno v oddíle 3.2.2.1.
3.2.2.3. Autentizace totožnosti organizace podřízených CA
57) Kořenová CA kontroluje totožnost organizace a další informace o registraci
poskytnuté žadateli o certifikát pro certifikáty podřízených CA (EA/AA).
58) Kořenová CA musí přinejmenším:
• určit, zda organizace existuje, a to s použitím alespoň jedné služby nebo
databáze třetí strany pro prokazování totožnosti nebo alternativně
organizační dokumentace vydané příslušnou vládní agenturou nebo
uznávaným orgánem nebo u nich podanou, která potvrzuje existenci
organizace,
• použít poštovní službu nebo jiný srovnatelný postup, který vyžaduje, aby
žadatel o certifikát potvrdil některé informace o organizaci, to, že
autorizoval žádost o certifikát, a to, že osoba podávající žádost jménem
žadatele je k tomu oprávněna. Pokud certifikát obsahuje jméno osoby
jako autorizovaného zástupce organizace, musí rovněž potvrdit, že tuto
osobu zaměstnává a že jej pověřila, aby jednal jejím jménem.
59) Postupy validace pro vydávání certifikátů CA musí být zdokumentovány v
CPS kořenové CA.
CS 27 CS
3.2.2.4. Autentizace účastnické organizace koncových subjektů
60) Nežli se účastník koncových subjektů (výrobce/provozovatel) může
zaregistrovat u důvěryhodné EA, aby jeho koncové subjekty mohly zasílat
žádosti o certifikát EC, EA musí:
• zkontrolovat totožnost účastnické organizace a další informace o
registraci poskytnuté žadatelem o certifikát,
• zkontrolovat, že typ stanice C-ITS (tj. konkrétní výrobek založený na
značce, modelu a verzi stanice C-ITS) splňuje všechna kritéria pro
posouzení souladu.
61) EA musí minimálně:
• určit, zda organizace existuje, a to s použitím alespoň jedné služby nebo
databáze třetí strany pro prokazování totožnosti nebo alternativně
organizační dokumentace vydané příslušnou vládní agenturou nebo
uznávaným orgánem nebo u nich podanou, která potvrzuje existenci
organizace,
• použít poštovní službu nebo jiný srovnatelný postup, který vyžaduje, aby
žadatel o certifikát potvrdil některé informace o organizaci, to, že
autorizoval žádost o certifikát, a to, že osoba podávající žádost jeho
jménem je k tomu oprávněna. Pokud certifikát obsahuje jméno osoby
jako autorizovaného zástupce organizace, musí rovněž potvrdit, že tuto
osobu zaměstnává a že jej pověřila, aby jednal jejím jménem.
62) Postupy validace pro registraci stanice C-ITS jejím účastníkem musí být
zdokumentovány v CPS EA.
3.2.3. Autentizace jednotlivého subjektu
3.2.3.1. Autentizace jednotlivého subjektu TLM / CA
63) Pro autentizaci jednotlivého subjektu (fyzické osoby) identifikovaného ve
spojení s právnickou osobou nebo organizačním subjektem (např. účastníkem)
musí být předloženy doklady o:
• úplném jménu subjektu (včetně příjmení a jména, v souladu s platnými
právními předpisy a vnitrostátními identifikačními postupy),
• datu a místu narození, odkazu na vnitrostátně uznávaný průkaz totožnosti
nebo jiné atributy účastníka, které mohou být případně použity k odlišení
osoby od jiných se stejným jménem,
• úplném názvu a právním postavení přidružené právnické osoby nebo
jiného organizačního subjektu (např. účastníka),
• všech příslušných informacích o registraci (např. registrace společnosti)
přidružené právnické osoby nebo jiného organizačního subjektu,
• dokladech o tom, že je subjekt spojen s právnickou osobou nebo jiným
organizačním subjektem.
Předložené důkazy mohou mít formu tištěné nebo elektronické dokumentace.
64) K ověření své totožnosti předloží autorizovaný zástupce kořenové CA, EA, AA
nebo účastníka dokumentaci prokazující, že pro organizaci pracuje (osvědčení
o autorizaci). Musí rovněž předložit úřední průkaz totožnosti.
CS 28 CS
65) Pro prvotní proces registrace (tok 31/32) poskytne zástupce EA/AA příslušné
kořenové CA veškeré potřebné informace (viz oddíl 4.1.2).
66) Pracovníci kořenové CA ověří totožnost zástupce žadatele o certifikát
a všechny související dokumenty s použitím požadavků na „důvěryhodné
pracovníky“ stanovených v oddíle 5.2.1. (Proces validování informací o žádosti
a generování certifikátu kořenovou CA provádějí „důvěryhodné osoby“
u kořenové CA, a to alespoň pod dvojím dohledem, neboť se jedná o citlivé
operace ve smyslu oddílu 5.2.2).
3.2.3.2. Autentizace totožnosti účastníka stanic C-ITS
67) Účastníci jsou zastoupeni autorizovanými konečnými uživateli v organizaci,
kteří jsou registrováni u vydávající EA a AA. Tito koneční uživatelé určení
organizacemi (výrobci nebo provozovateli) musí prokázat svou totožnost a
autenticitu před:
• registrací EE v její příslušné EA, včetně jeho kanonického veřejného
klíče, kanonického ID (jedinečného identifikátoru) a povolení v souladu s
EE,
• registrací v AA a prokázáním účastnické smlouvy, která může být
zaslána EA.
3.2.3.3. Autentizace totožnosti stanice C-ITS
68) subjekty EE, na které se vztahují oprávnění (EC), musí při žádosti o EC (tok
31) prokázat svou totožnost za použití svého kanonického soukromého klíče
pro prvotní autentizaci. EA zkontroluje autentizaci pomocí kanonického
veřejného klíče, který odpovídá EE. Kanonické veřejné klíče EE jsou předány
EA před provedením prvotní žádosti zabezpečeným kanálem mezi výrobcem
nebo provozovatelem stanice C-ITS a EA (tok 33).
69) EE, na které se vztahují potvrzení o autorizaci (AT), musí při žádosti o AT (tok
32) prokázat svou totožnost za použití svého jedinečného soukromého klíče pro
registraci. AA předá podpis k validaci EA (tok 25); EA jej validuje a potvrdí
výsledek AA (tok 23).
3.2.4. Neověřené informace o účastníkovi
Není stanoveno.
3.2.5. Validace autority
3.2.5.1. Validace TLM, kořenové CA, EA, AA
70) V CPS musí každá organizace určit alespoň jednoho zástupce (např. úředníka
pro bezpečnost) odpovědného za vyžádání nových certifikátů a obnovení.
Použijí se pravidla pro pojmenovávání v oddíle 3.2.3.
3.2.5.2. Validace účastníků stanice C-ITS
71) Musí být známa a EA schválena alespoň jedna fyzická osoba odpovědná za
registraci stanice C-ITS u EA (např. úředník pro bezpečnost) (viz oddíl 3.2.3).
3.2.5.3. Validace stanice C-ITS
72) Účastník stanice C-ITS může registrovat stanici C-ITS u konkrétní EA (tok
33), je-li u této EA autentizován.
CS 29 CS
Je-li stanice C-ITS registrována u EA jedinečným kanonickým ID a
kanonickým veřejným klíčem, může požádat o oprávnění k registraci (EC)
pomocí žádosti podepsané kanonickým soukromým klíčem souvisejícím s
dříve registrovaným kanonickým veřejným klíčem.
3.2.6. Kritéria pro interoperabilitu
73) Pro komunikaci mezi stanicemi C-ITS a EA (nebo AA) musí být stanice C-ITS
schopna zajistit bezpečnou komunikaci s EA (nebo AA), tj. provádět funkce
autentizace, důvěrnosti a integrity, jak je upřesněno v [1]. Za předpokladu, že
bude implementováno [1], mohou být použity jiné protokoly. EA a AA musí
tuto bezpečnou komunikaci podporovat.
74) EA a AA musí podporovat žádosti o certifikát a odpovědi, které jsou v souladu
s [1], což poskytuje bezpečný AT protokol žádosti/odpovědi, jenž podporuje
anonymitu žadatele vůči AA a oddělení povinností mezi AA a EA. Za
předpokladu, že bude implementováno [1], mohou být použity jiné protokoly.
Aby se zabránilo zpřístupnění dlouhodobé totožnosti stanice C-ITS, musí být
komunikace mezi mobilní stanicí C-ITS a EA důvěrná (např. komunikační data
musí být šifrována mezi koncovými body).
75) Pro každou žádost o autorizaci, kterou obdrží od subjektu certifikátu EE,
předloží AA žádost o validaci autorizace (tok 25). EA tuto žádost validuje s
ohledem na:
• stav EE v EA,
• platnost podpisu,
• požadované aplikační ID ITS (ITS-AID) a povolení,
• stav poskytování služby AA účastníkovi.
3.3. Identifikace a autentizace žádostí o změnu klíče
3.3.1. Identifikace a autentizace žádostí o rutinní změnu klíče
3.3.1.1. Certifikáty TLM
76) TLM generuje pár klíčů a dva certifikáty: jeden samopodepsaný a jeden
spojovací certifikát uvedený v oddíle 7.
3.3.1.2. Certifikáty kořenové CA
Nepoužije se.
3.3.1.3. Obnova certifikátu nebo změna klíče EA/AA
77) Aby byla zachována kontinuita používání certifikátu, požádá EA/AA před
uplynutím platnosti certifikátu EA/AA o nový certifikát (tok 21 / tok 24).
EA/AA generuje nový pár klíčů s cílem nahradit pár klíčů pozbývající platnosti
a podepsat žádost o změnu klíče obsahující nový veřejný klíč spolu aktuálním
platným soukromým klíčem („změna klíče“). EA nebo AA generuje nový pár
klíčů a podepisuje žádost novým soukromým klíčem (vnitřní podpis), aby
prokázal vlastnictví nového soukromého klíče. Celá žádost je přepodepsána
aktuálním platným soukromým klíčem (vnějším podpisem), aby byla zajištěna
integrita a autenticita žádosti. Je-li použit pár klíčů pro šifrování a dešifrování,
musí se prokázat vlastnictví soukromých klíčů dešifrování (podrobný popis
změny klíče viz oddíl 4.7.3.3).
CS 30 CS
78) Metoda identifikace a autentizace pro rutinní změnu klíče je stejná jako metoda
pro původní vydání prvotního certifikátu kořenové CA, jak je stanovena
v oddíle 3.2.2.
3.3.1.4. Oprávnění koncových subjektů k registraci
79) Aby byla zachována kontinuita používání certifikátu, požádá EE před
uplynutím platnosti stávajícího EC o nový certifikát (tok 31). EE generuje nový
pár klíčů s cílem nahradit pár klíčů pozbývající platnosti a požádat o nový
certifikát obsahující nový veřejný klíč; žádost musí být podepsána aktuálním
platným soukromým klíčem EC.
80) EE může žádost podepsat nově vytvořeným soukromým klíčem (vnitřní
podpis), aby prokázal vlastnictví nového soukromého klíče. Celá žádost je poté
přepodepsána aktuálním platným soukromým klíčem (vnějším podpisem)
a zašifrována pro přijímající EA tak, jak je upřesněno v [1], s cílem zajistit
důvěrnost, integritu a autenticitu žádosti. Za předpokladu, že bude
implementováno [1], mohou být použity jiné protokoly.
3.3.1.5. Autorizační potvrzení koncových subjektů
81) Změna klíče certifikátu pro AT je založena na stejném postupu jako původní
autorizace, jak je definováno v [1]. Za předpokladu, že bude implementováno
[1], mohou být použity jiné protokoly.
3.3.2. Identifikace a autentizace žádostí o změnu klíče po odvolání
3.3.2.1. Certifikáty CA
82) Autentizace organizace CA pro změnu klíče certifikátu kořenové CA, EA a AA
po odvolání se provádí stejným způsobem jako původní vydání certifikátu CA,
jak je stanoveno v oddíle 3.2.2.
3.3.2.2. Oprávnění koncových subjektů k registraci
83) Autentizace EE pro změnu klíče certifikátu EC po odvolání se provádí stejným
způsobem jako původní vydání certifikátu EE, jak je stanoveno v oddíle 3.2.2.
3.3.2.3. Žádosti koncových subjektů o autorizaci
Není použitelné, protože potvrzení o autorizaci (AT) se neodvolávají.
3.4. Identifikace a autentizace pro žádost o odvolání
3.4.1. Certifikáty kořenové CA/EA/AA
84) Žádosti o vymazání certifikátu kořenové CA z ECTL musí být autentizovány
kořenovou CA vůči TLM (toky 12 a 9). Žádosti o odvolání certifikátu EA/AA
musí být autentizovány příslušnou kořenovou CA a samotnou podřízenou CA.
85) Přijatelné postupy pro autentizaci žádostí účastníka o odvolání zahrnují:
• písemná a podepsaná zpráva účastníka na podnikovém dopisním papíru
požadující odvolání s odkazem na certifikát, který má být odvolán,
• komunikace s účastníkem poskytující přiměřená ujištění, že osoba nebo
organizace, která žádá o odvolání, je opravdu účastník. V závislosti na
okolnostech může taková komunikace zahrnovat jeden nebo více z těchto
prvků: e-mail, poštovní zásilku nebo kurýrní službu.
CS 31 CS
3.4.2. Oprávnění stanice C-ITS k registraci
86) Účastník stanice C-ITS může odvolat oprávnění (EC) dříve registrované
stanice C-ITS u EA (tok 34). Žádající účastník vypracuje žádost o odvolání
dané stanice C-ITS nebo seznamu stanic C-ITS. EA před zpracováním žádosti
žádost o odvolání autentizuje a potvrdí odvolání stanice C-ITS a jejích EC.
87) EA může odvolat EC stanice C-ITS v souladu s oddílem 7.3.
3.4.3. Potvrzení o autorizaci stanice C-ITS
88) Jelikož AT nejsou odvolávána, jejich platnost se omezí na určité období.
Rozsah přijatelných dob platnosti v této certifikační politice je upřesněn
v oddíle 7.
4. PROVOZNÍ POŽADAVKY NA ŽIVOTNÍ CYKLUS CERTIFIKÁTU
4.1. Žádost o certifikát
89) Tento oddíl stanoví požadavky na prvotní žádost o vydání certifikátu.
90) Termínem „žádost o certifikát“ se rozumí tyto procesy:
• registrace a zřízení vztahu důvěry mezi TLM a CPA,
• registrace a zřízení vztahu důvěry mezi kořenovou CA, CPA a TLM,
včetně vložení prvního certifikátu kořenové CA do ECTL,
• registrace a zřízení vztahu důvěry mezi EA/AA a kořenovou CA, včetně
vydání nového certifikátu EA/AA,
• registrace stanice C-ITS u EA výrobcem/provozovatelem,
• žádost stanice C-ITS o EC/AT.
4.1.1. Kdo může podat žádost o certifikát
4.1.1.1. Kořenové CA
91) Kořenové CA generují své vlastní páry klíčů a samy vydávají svůj kořenový
certifikát. Kořenová CA může podat žádost o certifikát prostřednictvím svého
pověřeného zástupce (tok 14).
4.1.1.2. TLM
92) TLM generuje své vlastní páry klíčů a sám vydává svůj certifikát. Původní
vytvoření certifikátu TLM zpracovává zástupce organizace TLM pod
dohledem CPA.
4.1.1.3. EA a AA
93) Autorizovaný zástupce EA nebo AA může předložit žádost o certifikát
podřízené CA (EA a/nebo AA) autorizovanému zástupci příslušné kořenové
CA (toky 27/28).
4.1.1.4. Stanice C-ITS
94) Účastníci registrují každou stanici C-ITS u EA v souladu s oddílem 3.2.5.3.
95) Každá stanice C-ITS registrovaná u EA může zasílat žádosti o EC (tok 31).
CS 32 CS
96) Každá stanice C-ITS může zasílat žádosti o AT (tok 32), aniž by vyžadovala
jakoukoli interakci účastníků. Před podáním žádosti o AT musí mít stanice C-
ITS oprávnění (EC).
4.1.2. Proces a povinnosti registrace
97) Povolení pro kořenové CA a podřízené CA vydávající certifikáty pro zvláštní
(vládní) účely (tj. zvláštní mobilní a pevné stanice C-ITS) mohou udělovat
pouze členské státy, ve kterých se tyto organizace nacházejí.
4.1.2.1. Kořenové CA
98) Po absolvování auditu (tok 13 a 36, oddíl 8) mohou kořenové CA požádat
o vložení svých certifikátů do ECTL v CPA (tok 14). Proces registrace je
založen na ručně podepsaném formuláři žádosti, který je fyzicky dodán CPA
autorizovaným zástupcem kořenové CA a který obsahuje alespoň informace
uvedené v oddílech 3.2.2.1, 3.2.3 a 3.2.5.1.
99) Formulář žádosti kořenové CA musí být podepsán autorizovaným zástupcem
CA.
100) Kromě formuláře žádosti poskytne autorizovaný zástupce kořenové CA orgánu
CPA ke schválení (tok 16) kopii CPS kořenové CA (tok 15) a jeho zprávu o
auditu. V případech pozitivního schválení CPA generuje a zasílá CPOC/TLM a
odpovídající kořenové CA certifikát o shodě.
101) Autorizovaný zástupce kořenové CA pak přinese formulář žádosti (obsahující
otisk samopodepsaného certifikátu), úřední průkaz totožnosti a doklad o
autorizaci CPOC/TLM. Samopodepsaný certifikát musí být CPOC/TLM
doručen elektronicky. CPOC/TLM ověří veškeré dokumenty a samopodepsaný
certifikát.
102) V případě pozitivních ověření doplní TLM na základě oznámení CPA (toky 1 a
2) certifikát kořenové CA do ECTL. Podrobný postup je popsán v CPS TLM.
103) Měl by být možný dodatečný postup pro získání schválení CPS a zprávy o
auditu kořenové CA u vnitrostátního orgánu konkrétních zemí.
4.1.2.2. TLM
104) Po absolvování auditu se TLM může zapsat u CPA. Proces registrace je
založen na podepsaném manuálním formuláři žádosti, který je autorizovaným
zástupcem TLM fyzicky doručen CPA (tok 38) a obsahuje alespoň informace
uvedené v oddílech 3.2.2.2 a 3.2.3.
105) Formulář žádosti TLM musí být podepsán jeho autorizovaným zástupcem.
106) TLM nejprve generuje svůj samopodepsaný certifikát a zasílá jej bezpečně
CPA. Poté TLM předloží CPA svůj formulář žádosti (obsahující otisk
samopodepsaného certifikátu), kopii svého CPS, úřední průkaz totožnosti,
doklad o autorizaci a zprávu o auditu (tok 40). CPA ověří veškeré dokumenty a
samopodepsaný certifikát. V případech pozitivního ověření všech dokumentů,
samopodepsaného certifikátu a otisku potvrdí CPA proces registrace zasláním
svého souhlasu TLM a CPOC (tok 39). CPA uchovává informace o žádosti
zaslané TLM. Certifikát TLM je pak vydán prostřednictvím CPOC.
CS 33 CS
4.1.2.3. EA a AA
107) Během procesu registrace přinese EA/AA příslušné kořenové CA ke schválení
příslušné dokumenty (např. CPS a zprávu o auditu) (tok 27/28). V případech
pozitivních kontrol dokumentů zašle kořenová CA odpovídajícím podřízeným
CA schválení (toky 29/30). Podřízená CA (EA nebo AA) poté zašle svou
podepsanou žádost elektronicky a fyzicky dodá odpovídající kořenové CA svůj
formulář žádosti (v souladu s oddílem 3.2.2.1), doklad o autorizaci a doklad
totožnosti. Kořenová CA ověřuje žádost a obdržené dokumenty (formulář
žádosti obsahující otisk, což je SHA 256 hashvalue žádosti podřízené CA,
doklad o autorizaci a doklad totožnosti). Vedou-li všechny kontroly k
pozitivnímu výsledku, vydá kořenová CA odpovídající certifikát podřízené
CA. Podrobné informace, jak provést prvotní žádost, jsou popsány v jejím
konkrétním CPS.
108) Kromě formuláře žádosti podřízené CA přiloží autorizovaný zástupce
podřízené CA kopii CPS kořenové CA.
109) Informace se poskytují akreditovanému auditorovi PKI pro audit v souladu
s oddílem 8.
110) Je-li podřízená CA ve vlastnictví jiného subjektu než subjektu, který vlastní
kořenovou CA, musí před tím, než vydá žádost o certifikát podřízené CA,
podepsat smlouvu ohledně služby kořenové CA.
4.1.2.4. Stanice C-ITS
111) Původní registraci subjektů koncových subjektů (stanice C-ITS) provádí
odpovědný účastník (výrobce/provozovatel) s EA (toky 33 a 35) po úspěšné
autentizaci organizace účastníka a jednoho z jejích zástupců v souladu s oddíly
3.2.2.4 a 3.2.5.2.
112) Stanice C-ITS může generovat pár klíčů EC (viz oddíl 6.1) a vytvořit
podepsanou žádost o EC v souladu s [1]. Za předpokladu, že bude
implementováno [1], mohou být použity jiné protokoly.
113) Během registrace běžné stanice C-ITS (oproti zvláštní mobilní nebo pevné
stanici C-ITS) musí EA ověřit, zda povolení v původní žádosti nejsou pro
vládní použití. Povolení pro vládní použití jsou definována příslušnými
členskými státy. Podrobný postup registrace a odpovědi EA
výrobci/provozovateli (toky 33 a 35) se stanoví v příslušném CPS EA.
114) Stanice C-ITS se zapíše u EA (oddíl 3.2.5.3) zasláním své původní žádosti o
EC v souladu s [1].
115) Po původní registraci autentizovaným zástupcem účastníka EA schválí, která
potvrzení o autorizaci (AT) může subjekt koncového subjektu (tj. stanice C-
ITS) získat. Každému koncovému subjektu je dále přidělena úroveň
důvěryhodnosti, která se vztahuje k certifikaci koncového subjektu v souladu s
jedním z profilů ochrany uvedených v oddíle 6.1.5.2.
116) Běžná vozidla mají pouze jednu stanici C-ITS, která je registrována u jedné
EA. Vozidla zvláštního určení (jako jsou policejní vozy a jiná speciální vozidla
se zvláštními právy) mohou být registrována u další EA nebo mohou mít v
rámci zvláštního určení další stanici C-ITS pro autorizace. Vozidla, na něž se
tato výjimka vztahuje, jsou vymezena odpovědnými členskými státy. Povolení
pro zvláštní mobilní a pevné stanice C-ITS udělují pouze odpovědné členské
CS 34 CS
státy. Jakým způsobem se proces certifikace vztahuje na tato vozidla, určí CPS
kořenových CA nebo podřízených CA, které vydávají certifikáty pro tato
vozidla v uvedených členských státech.
117) Je-li účastník v procesu migrace stanice C-ITS z jedné EA do jiné EA, může
být stanice C-ITS zaregistrována u dvou (podobných) EA.
118) Stanice C-ITS generuje pár klíčů AT (viz oddíl 6.1) a vytvoří žádost o AT v
souladu s [1]. Za předpokladu, že bude implementováno [1], mohou být
použity jiné protokoly.
119) Stanice C-ITS zašlou žádost o autorizaci na adresu URL AA (toky 32 a 26) tak,
že zašlou alespoň požadované informace uvedené v oddíle 3.2.3.3. AA a EA
validují autorizaci každé žádosti v souladu s oddíly 3.2.6 a 4.2.2.5.
4.2. Zpracování žádosti o certifikát
4.2.1. Vykonávání funkcí identifikace a autentizace
4.2.1.1. Identifikace a autentizace kořenových CA
120) Autorizovaný zástupce CPA odpovídá za autentizaci autorizovaného zástupce
kořenové CA a za schválení procesu registrace v souladu s oddílem 3.
4.2.1.2. Identifikace a autentizace správce seznamu důvěryhodných subjektů
121) Autorizovaný zástupce CPA odpovídá za autentizaci autorizovaného zástupce
TLM a za schválení jeho formuláře žádosti pro proces registrace v souladu
s oddílem 3.
4.2.1.3. Identifikace a autentizace EA a AA
122) Odpovídající kořenová CA je odpovědná za autentizaci autorizovaného
zástupce EA/AA a za schválení jeho formuláře žádosti pro proces registrace
v souladu s oddílem 3.
123) Kořenová CA potvrdí kladnou validaci formuláře žádosti pro EA/AA. EA/AA
pak mohou zaslat žádost o certifikát kořenové CA (tok 21/24), který vydává
certifikáty odpovídající EA/AA (tok 18/19).
4.2.1.4. Identifikace a autentizace účastníka EE
124) Před tím než může stanice C-ITS požádat o certifikát EC, musí účastník EE
bezpečně přenést informace o ID stanice C-ITS na EA (tok 33). EA žádost
ověří a v případě pozitivního ověření zaregistruje informace o stanici C-ITS do
své databáze a potvrdí to účastníkovi EE (tok 35). Tuto operaci provádí
výrobce nebo provozovatel pro každou stanici C-ITS pouze jednou. Jakmile je
stanice C-ITS zaregistrována EA, může si vyžádat jediný certifikát EC, který v
daném čase potřebuje (tok 31). EA autentizuje a ověří, že informace v žádosti o
certifikát EC jsou pro stanici C-ITS platné.
4.2.1.5. Potvrzení o autorizaci
125) Během žádostí o autorizaci (tok 32) musí AA v souladu s [1] autentizovat EA,
od které stanice C-ITS obdržela své oprávnění (EC). Za předpokladu, že bude
implementováno [1], mohou být použity jiné protokoly. Není-li AA schopna
autentizovat EA, žádost se zamítne (tok 26). Je nutné, aby AA vlastnila
certifikát EA pro autentizaci EA a ověření jeho odpovědi (toky 25 a 23,
oddíl 3.2.5.3).
CS 35 CS
126) EA autentizuje stanici C-ITS, která žádá o AT tím, že ověří její EC (toky 25 a
23).
4.2.2. Schválení nebo zamítnutí žádostí o certifikát
4.2.2.1. Schválení nebo zamítnutí certifikátů kořenové CA
127) TLM vkládá do ECTL / maže v ECTL certifikáty kořenové CA v souladu se
schválením CPA (tok 1/2).
128) TLM by měl po obdržení schválení CPA (tok 1) ověřit podpis, informace a
kódování certifikátů kořenové CA. Po pozitivní validaci a schválení CPA vloží
TLM odpovídající kořenový certifikát do ECTL a oznámí to CPA (tok 5).
4.2.2.2. Schválení nebo zamítnutí certifikátu TLM
129) CPA odpovídá za schvalování nebo zamítání certifikátů TLM.
4.2.2.3. Schválení nebo zamítnutí certifikátů EA a AA
130) Kořenová CA ověřuje žádosti o certifikát podřízené CA (toky 21/24)
a příslušné zprávy (vydané akreditovaným auditorem PKI) o jejich přijetí (tok
36, oddíl 8) od odpovídající podřízené CA kořenové CA. Jestliže kontrola
žádosti vede k pozitivnímu výsledku, příslušná kořenová CA vydá certifikát
žádající EA/AA (tok 18/19); v opačném případě je žádost zamítnuta a EA/AA
není vydán žádný certifikát.
4.2.2.4. Schválení nebo zamítnutí oprávnění
131) EA ověří a validuje žádosti o EC podle oddílů 3.2.3.2 a 3.2.5.3.
132) Je-li žádost o certifikát v souladu s [1] správná a platná, EA generuje
požadovaný certifikát.
133) Je-li žádost o certifikát neplatná, EA ji zamítne a zašle odpověď uvádějící
důvod zamítnutí v souladu s [1]. Pokud si stanice C-ITS stále přeje EC, musí
podat novou žádost o certifikát. Za předpokladu, že bude implementováno [1],
mohou být použity jiné protokoly.
4.2.2.5. Schválení nebo zamítnutí potvrzení o autorizaci
134) Žádost o certifikát kontroluje EA. AA zřídí komunikaci s EA s cílem validovat
žádost (tok 25). EA autentizuje žádající stanici C-ITS a validuje, zda má právo
obdržet požadované AT na základě CP (např. kontrolou stavu odvolání a
validací platnosti certifikátu pro dobu/region, povolení, úroveň zabezpečení
atd.). EA vrátí odpověď validace (tok 23), a je-li odpověď kladná, AA
vygeneruje požadovaný certifikát a předá jej stanici C-ITS. Není-li žádost o AT
správná nebo je odpověď validace EA záporná, AA žádost zamítne. Pokud
stanice C-ITS nadále požaduje AT, musí podat novou žádost o autorizaci.
4.2.3. Doba pro zpracování žádosti o certifikát
4.2.3.1. Žádost o certifikát kořenové CA
135) Doba pro zpracování procesu identifikace a autentizace žádosti o certifikát je
během pracovního dne a vztahuje se na ni maximální lhůta stanovená v CPS
kořenové CA.
CS 36 CS
4.2.3.2. Žádost o certifikát TLM
136) Na zpracování žádosti o certifikát TLM se vztahuje maximální lhůta stanovená
v CPS TLM.
4.2.3.3. Žádost o certifikát EA a AA
137) Doba pro zpracování procesu identifikace a autentizace žádosti o certifikát je
během pracovního dne v souladu s dohodou a smlouvou mezi členským státem
/ soukromou organizací kořenové CA a podřízené CA. Na dobu pro zpracování
žádosti o certifikát podřízené CA se vztahuje maximální lhůta stanovená v CPS
podřízené CA.
4.2.3.4. Žádost o EC
138) Na zpracování žádostí o EC se vztahuje maximální lhůta stanovená v CPS EA.
4.2.3.5. Žádost o AT
139) Na zpracování žádostí o AT se vztahuje maximální lhůta stanovená v CPS AA.
4.3. Vydávání certifikátu
4.3.1. Úkony CA v průběhu vydávání certifikátu
4.3.1.1. Vydávání certifikátu kořenové CA
140) Kořenové CA vydávají své vlastní samopodepsané certifikáty kořenové CA,
spojovací certifikáty, certifikáty podřízené CA a CRL.
141) Po schválení CPA (tok 4) zašle kořenová CA certifikát prostřednictvím CPOC
správci seznamu důvěryhodných subjektů (TLM), aby byl přidán do ECTL
(toky 11 a 8) (viz oddíl 4.1.2.1). TLM zkontroluje, zda CPA certifikát schválil
(tok 1).
4.3.1.2. Vydávání certifikátu TLM
142) TLM vydává svůj vlastní samopodepsaný certifikát TLM a spojovací certifikát
a posílá jej na CPOC (tok 6).
4.3.1.3. Vydávání certifikátu EA a AA
143) Podřízené CA generují podepsanou žádost o certifikát a předají ji odpovídající
kořenové CA (toky 21 a 24). Kořenová CA ověří žádost a vydá certifikát
žádající podřízené CA v souladu s [5] co nejdříve, jak stanoví CPS pro obvyklé
provozní postupy, avšak nejpozději pět pracovních dnů po obdržení žádosti.
144) Kořenová CA aktualizuje úložiště obsahující certifikáty podřízených CA.
4.3.1.4. Vydávání oprávnění
145) Stanice C-ITS zašle EA žádost o EC v souladu s [1]. EA autentizuje a ověří, že
informace v žádosti o certifikát jsou pro stanici C-ITS platné. Za předpokladu,
že bude implementováno [1], mohou být použity jiné protokoly.
146) V případě kladné validace vydá EA certifikát v souladu s registrací stanice C-
ITS (viz 4.2.1.4) a zašle jej stanici C-ITS pomocí zprávy odpovědi na EC
v souladu s [1]. Za předpokladu, že bude implementováno [1], mohou být
použity jiné protokoly.
CS 37 CS
147) Neexistuje-li registrace, EA vygeneruje kód chyby a zašle jej pomocí zprávy
odpovědi na EC stanici C-ITS v souladu s [1]. Za předpokladu, že bude
implementováno [1], mohou být použity jiné protokoly.
148) Žádosti o EC a odpovědi na EC musí být šifrovány, aby se zajistila důvěrnost,
a podepsány, aby se zajistila autentizace a integrita.
4.3.1.5. Vydávání potvrzení o autorizaci
149) Stanice C-ITS zašle zprávu o žádosti o potvrzení o autorizaci (AT) v souladu s
[1]. AA zašle EA žádost o validaci AT v souladu s [1]. EA zašle AA odpověď
validace AT. V případech kladné odpovědi AA generuje AT a zašle jej stanici
C-ITS zprávou odpovědi AT v souladu s [1]. V případech záporné odpovědi
vygeneruje AA kód chyby a zašle jej stanici C-ITS zprávou odpovědi AT
v souladu s [1]. Za předpokladu, že bude implementováno [1], mohou být
použity jiné protokoly.
150) Žádosti o AT a odpovědi AT musí být šifrovány (nezbytné pouze pro mobilní
stanice C-ITS), aby se zajistila důvěrnost, a podepsány, aby se zajistila
autentizace a integrita.
4.3.2. Oznámení CA účastníkovi o vydání certifikátů
Nepoužije se.
4.4. Přijetí certifikátu
4.4.1. Převzetí certifikátu
4.4.1.1. Kořenová CA
Nepoužije se.
4.4.1.2. TLM
Nepoužije se.
4.4.1.3. EA a AA
151) EA/AA ověří druh certifikátu, podpis a informace v přijatém certifikátu.
EA/AA odstraní všechny certifikáty EA/AA, které nejsou správně ověřeny, a
vydá novou žádost.
4.4.1.4. Stanice C-ITS
152) Stanice C-ITS ověří odpověď EC/AT od EA/AA oproti původní žádostí, včetně
podpisu a řetězce certifikátů. Odstraní veškeré odpovědi EC/AT, které nejsou
správně ověřeny. V takových případech by měla zaslat novou žádost o EC/AT.
4.4.2. Zveřejnění certifikátu
153) Certifikáty TLM a jejich spojovací certifikáty jsou prostřednictvím CPOC
zpřístupněny všem účastníkům.
154) Certifikáty kořenové CA jsou zveřejňovány CPOC prostřednictvím ECTL,
který je podepsán TLM.
155) Certifikáty podřízených CA (EA a AA) zveřejňuje kořenová CA.
156) EC a AT se nezveřejňují.
4.4.3. Oznámení o vydání certifikátu
Neexistují žádná oznámení o vydání.
CS 38 CS
4.5. Použití páru klíčů a certifikátu
4.5.1. Použití soukromého klíče a certifikátu
4.5.1.1. Použití soukromého klíče a certifikátu pro TLM
157) TLM používá své soukromé klíče k podpisu svých vlastních (TLM a
spojovacích) certifikátů a ECTL.
158) Certifikát TLM používají účastníci PKI k ověření ECTL a autentizaci TLM.
4.5.1.2. Použití soukromého klíče a certifikátů pro kořenové CA
159) Kořenové CA používají své soukromé klíče k podpisu svých vlastních
certifikátů, CRL, spojovacích certifikátů a certifikátů EA/AA.
160) Účastníci PKI používají certifikáty kořenových CA k ověření souvisejících
certifikátů AA a EA, spojovacích certifikátů a CRL.
4.5.1.3. Použití soukromého klíče a certifikátu registrující a autorizační autoritou
161) EA používají své soukromé klíče k podpisu EC a k dešifrování žádosti o
registraci.
162) Certifikáty EA se použijí k ověření podpisu souvisejících EC a AT a k
šifrování žádostí o EC a AT, jak je definováno v [1].
163) AA využijí své soukromé klíče k podpisu AT a k dešifrování žádosti o AT.
164) Certifikáty AA se použijí k ověření souvisejících AT a k šifrování žádostí o
AT, jak je definováno v [1].
4.5.1.4. Použití soukromého klíče a certifikátu koncovým subjektem
165) EE použijí soukromý klíč odpovídající platnému EC k podpisu nové žádosti o
registraci definované v [1]. Nový soukromý klíč se použije k vybudování
vnitřního podpisu pro prokázání vlastnictví soukromého klíče, který odpovídá
novému veřejnému klíči EC.
166) EE použijí soukromý klíč odpovídající platnému EC k podpisu žádosti o
autorizaci, jak je definováno v [1]. Soukromý klíč odpovídající novému AT by
se měl použít k vybudování vnitřního podpisu pro prokázání vlastnictví
soukromého klíče, který odpovídá novému veřejnému klíči AT.
167) EE použije soukromý klíč odpovídající vhodnému AT k podpisu zpráv C-ITS,
jak je definováno v [5].
4.5.2. Použití veřejného klíče a certifikátu spoléhající se stranou
168) Spoléhající se strany používají cestu důvěryhodné certifikace a související
veřejné klíče pro účely uvedené v certifikátech a pro autentizaci důvěryhodné
společné totožnosti EC a AT.
169) Certifikáty kořenové CA, EA a AA, EC a AT se nepoužijí bez předběžné
kontroly spoléhající se strany.
4.6. Obnova certifikátu
Není povoleno.
CS 39 CS
4.7. Změna klíče certifikátu
4.7.1. Okolnosti pro změnu klíče certifikátu
170) Změna klíče certifikátu se zpracuje, když certifikát dosáhne konce své
životnosti nebo když soukromý klíč dosáhne konce provozního použití, avšak
stále existuje vztah důvěry s CA. Ve všech případech musí být generován a
vydán nový pár klíčů a odpovídající certifikát.
4.7.2. Kdo může požádat o změnu klíče
4.7.2.1. Kořenová CA
171) Kořenová CA nepožaduje změnu klíče. Proces změny klíče je pro kořenovou
CA interním procesem, protože jeho certifikát je samopodepsaný. Kořenová
CA překlíčuje klíče buď na spojovací certifikáty, nebo na nové vydání (viz
oddíl 4.3.1.1).
4.7.2.2. TLM
172) TLM nepožaduje změnu klíče. Proces změny klíče je pro TLM interním
procesem, protože certifikát TLM je samopodepsaný.
4.7.2.3. EA a AA
173) Žádost o certifikát podřízené CA musí být předložena včas, aby bylo jisté, že
bude dostupný nový certifikát podřízené CA a funkční pár klíčů před ztrátou
platnosti stávajícího soukromého klíče podřízené CA. Datum předložení musí
zohlednit také dobu potřebnou ke schválení.
4.7.2.4. Stanice C-ITS
Nepoužije se.
4.7.3. Proces změny klíče
4.7.3.1. Certifikát TLM
174) TLM rozhoduje o změně klíče na základě požadavků uvedených v oddílech 6.1
a 7.2. Podrobný postup je stanoven v jeho CPS.
175) TLM provede včas proces změny klíče, aby umožnil distribuci nového
certifikátu TLM a spojovacího certifikátu všem účastníkům před skončením
platnosti stávajícího certifikátu TLM.
176) TLM použije spojovací certifikáty pro změnu klíče a pro zaručení vztahu
důvěry k novému samopodepsanému certifikátu. Nově generovaný certifikát
TLM a spojovací certifikát se přenese na CPOC.
4.7.3.2. Certifikát kořenové CA
177) Kořenová CA rozhoduje o změně klíče na základě požadavků oddílů 6.1.5 a
7.2. Podrobný postup by měl být vymezen v její CPS.
178) V zájmu umožnění vložení nového certifikátu do ECTL před vstupem
certifikátu kořenové CA v platnost (viz oddíl 5.6.2) provádí kořenová CA
proces změny klíče včas (před uplynutím platnosti certifikátu kořenového CA).
Proces změny klíče se provádí buď pomocí spojovacích certifikátů, nebo jako
prvotní žádost.
CS 40 CS
4.7.3.3. Certifikáty EA a AA
179) EA nebo AA požádají o nový certifikát takto:
Krok Označení Žádost o změnu klíče
1 Generování párů klíčů Podřízené CA (EA a AA) generují nové páry klíčů v souladu s oddílem
6.1.
2 Generování žádosti o
certifikát a vnitřního
podpisu
Podřízená CA generuje žádost o certifikát z nově generovaného
veřejného klíče s ohledem na pravidla pojmenovávání (subject_info)
podle oddílu 3, algoritmus podpisu, povolení specifické pro službu
(SSP) a volitelný dodatečný parametr a generuje vnitřní podpis s
odpovídajícím novým soukromým klíčem. Je-li požadován šifrovací
klíč, musí podřízená CA rovněž prokázat vlastnictví odpovídajícího
soukromého dešifrovacího klíče.
3 Generování vnějšího
podpisu
Celá žádost musí být podepsána aktuálním platným soukromým klíčem,
aby byla zaručena autenticita podepsané žádosti.
4 Odeslání žádosti kořenové
CA
Podepsaná žádost se předkládá odpovídající kořenové CA.
5 Ověření žádosti Odpovídající kořenová CA ověří integritu a autenticitu žádosti. Nejprve
zkontroluje vnější podpis. Pokud je ověření pozitivní, zkontroluje vnitřní
podpis. Existuje-li důkaz o držení soukromého dešifrovacího klíče,
zkontroluje rovněž tento důkaz.
6 Přijetí nebo zamítnutí
žádosti
Vedou-li všechny kontroly k pozitivnímu výsledku, kořenová CA žádost
přijímá; v opačném případě ji zamítne.
7 Generování a vydání
certifikátu
Kořenová CA generuje nový certifikát a distribuuje jej žádající
podřízené CA.
8 Odeslání odpovědi Podřízená CA zašle kořenové CA zprávu o stavu (zda certifikát
obdržela, či nikoli).
Tabulka 3: Proces změny klíče pro EA a AA
180) Během automatické změny klíče pro podřízené CA zajistí kořenová CA, aby
žadatel skutečně vlastnil svůj soukromý klíč. Použijí se vhodné protokoly pro
důkaz vlastnictví soukromých dešifrovacích klíčů, například podle definice v
RFC 4210 a 4211. U soukromých podpisových klíčů by měl být použit vnitřní
podpis.
4.7.3.4. Certifikáty stanice C-ITS
Nepoužije se pro AT.
4.8. Změna v certifikátu
Není povoleno.
4.9. Odvolání a pozastavení platnosti certifikátu
Viz oddíl 7.
4.10. Služby ověřování stavu certifikátu
4.10.1. Provozní charakteristiky
Nepoužije se.
4.10.2. Dostupnost služby
Nepoužije se.
CS 41 CS
4.10.3. Volitelné prvky
Nepoužije se.
4.11. Ukončení účasti
Nepoužije se.
4.12. Úschova klíče u třetí strany a jeho obnova
4.12.1. Účastník
4.12.1.1. Jaký pár klíčů lze uschovat u třetí strany
Nepoužije se.
4.12.1.2. Kdo může podat žádost o obnovu
Nepoužije se.
4.12.1.3. Proces a povinnosti obnovy
Nepoužije se.
4.12.1.4. Identifikace a autentizace
Nepoužije se.
4.12.1.5. Schválení nebo zamítnutí žádostí o obnovu
Nepoužije se.
4.12.1.6. Akce KEA a KRA v průběhu obnovy páru klíčů
Nepoužije se.
4.12.1.7. Dostupnost akcí KEA a KRA
Nepoužije se.
4.12.2. Politika a postupy enkapsulace a obnovy klíče relace
Nepoužije se.
5. KONTROLY ZAŘÍZENÍ, KONTROLY ŘÍZENÍ A PROVOZNÍ KONTROLY
181) PKI se skládá z kořenové CA, EA/AA, CPOC a TLM, včetně jejich komponent
informačních a komunikačních technologií (např. sítí a serverů).
182) V tomto oddíle je subjekt odpovědný za prvek PKI označen samotným prvkem.
Jinými slovy, věta „CA odpovídá za provedení auditu“ se rovná větě „subjekt
nebo pracovníci spravující CA odpovídají za provedení...“.
183) Termín „prvky C-ITS modelu služeb vytvářejících důvěru“ zahrnuje
kořenovou CA, TLM, EA/AA, CPOC a zabezpečenou síť.
5.1. Fyzické kontroly
184) Všechny operace C-ITS modelu služeb vytvářejících důvěru musí být
prováděny ve fyzicky chráněném prostředí, které odrazuje od neoprávněného
používání citlivých informací nebo systémů, přístupu k nim a jejich
zpřístupnění, brání mu a detekuje jej. Prvky C-ITS modelu služeb vytvářejících
důvěru používají fyzické bezpečnostní kontroly v souladu s ISO 27001 a ISO
27005.
CS 42 CS
185) Subjekty, které spravují prvky C-ITS modelu služeb vytvářejících důvěru,
popíší ve svých CPS fyzické, procedurální a bezpečnostní kontroly. CPS
zahrnuje zejména informace o umístění a konstrukci budov a jejich fyzických
bezpečnostních kontrolách, které zaručují řízený přístup do všech místností
používaných v zařízení subjektů C-ITS modelu služeb vytvářejících důvěru.
5.1.1. Umístění a konstrukce
5.1.1.1. Kořenová CA, CPOC, TLM
186) Umístění a konstrukce zařízení pro umístění vybavení a dat kořenové CA,
CPOC a TLM (HSM, aktivační údaje, zálohování páru klíčů, počítač, protokol,
skript klíčové ceremonie, žádost o certifikát atd.) musí být v souladu se
zařízeními používanými k umístění citlivých informací s vysokou hodnotou.
Kořenová CA se provozuje ve vyhrazené fyzické oblasti oddělené od jiných
fyzických prostor komponent PKI.
CS 43 CS
187) Kořenová CA, CPOC a TLM implementují politiky a postupy s cílem zajistit,
že ve fyzickém prostředí, v němž je nainstalováno zařízení kořenové CA, bude
udržována vysoká úroveň bezpečnosti, aby bylo zaručeno, že:
• je izolováno od sítí mimo model služeb vytvářejících důvěru;
• je rozděleno do řad (alespoň dvou) postupně bezpečnějších fyzických
obvodů;
• citlivé údaje (HSM, záloha párů klíčů, aktivační údaje atd.) se uchovávají
ve vyhrazeném bezpečném fyzickém prostoru pod vícenásobnou
kontrolou přístupu.
188) Používané bezpečnostní techniky musí být navrženy tak, aby odolaly
vysokému počtu a kombinaci různých forem útoků. Používané mechanismy
musí zahrnovat alespoň:
• obvodová poplašná zařízení, uzavřené televizní okruhy, zesílené stěny a
detektory pohybu,
• dvoufaktorovou autentizaci (např. čipová karta a PIN) pro každou osobu
a průkaz pro vstup a opuštění zařízení kořenové CA a bezpečné fyzické
zabezpečené oblasti.
189) Kořenová CA, CPOC a TLM používají pověřené pracovníky k nepřetržitému
průběžnému sledování zařízení, kde je umístěno vybavení, i mimo obvyklé
pracovní doby po celý rok. Provozní prostředí (např. fyzické zařízení) není
nikdy ponecháno bez dozoru. Pracovníci provozního prostředí nemají nikdy
přístup do zabezpečených oblastí kořenových CA nebo podřízených CA, pokud
nejsou pověřeni.
5.1.1.2. EA/AA
190) Použijí se stejná ustanovení oddílu 5.1.1.1.
5.1.2. Fyzický přístup
5.1.2.1. Kořenová CA, CPOC, TLM
191) Zařízení a data (HSM, aktivační údaje, záloha páru klíčů, počítač, protokol,
skript klíčové ceremonie, žádost o certifikát atd.) musí být vždy chráněny před
neoprávněným přístupem. Fyzické bezpečnostní mechanismy musí
přinejmenším:
• neustále manuálně nebo elektronicky sledovat neoprávněné vniknutí,
• zajistit, aby nebyl povolen žádný neoprávněný přístup k hardwarovým a
aktivačním údajům,
• zajistit, aby všechna přenosná média a papír obsahující citlivé informace
prostým textem byly uloženy v zabezpečeném kontejneru,
• zajistit, aby žádná osoba vstupující do bezpečných oblastí, která není
trvale pověřena, nebyla ponechána bez dohledu pověřeného zaměstnance
zařízení kořenové CA, CPOC a TLM,
• zajistit, aby byl pravidelně udržován a kontrolován přístupový protokol,
• poskytovat alespoň dvě vrstvy postupně se zvyšující bezpečnosti, např.
na úrovni obvodu, budovy a operační místnosti,
CS 44 CS
• vyžadovat dvě kontroly fyzického přístupu ke kryptografickým, HSM a
aktivačním datům prováděné důvěryhodnými rolemi.
192) Má-li být vybavení pro umístění zařízení ponecháno bez dozoru, musí být
provedena jeho bezpečnostní kontrola. Tato kontrola musí minimálně ověřit,
zda:
• je vybavení ve stavu vhodném pro aktuální provozní režim,
• jsou v případě off-line komponent všechna zařízení vypnuta,
• jsou veškeré bezpečnostní kontejnery (obálka odolná proti nedovolené
manipulaci, trezor atd.) řádně zajištěny,
• fyzické bezpečnostní systémy (např. zámky dveří, kryty ventilace,
elektrická energie) fungují správně,
• je tato oblast zabezpečena proti neoprávněnému přístupu.
193) Odnímatelné kryptografické moduly se před uskladněním deaktivují. Pokud se
nepoužívají, musí být tyto moduly a aktivační údaje používané pro přístup k
nim nebo jejich aktivaci umístěny v trezoru. Aktivační údaje se buď
memorizují, nebo zaznamenají a uloží způsobem odpovídajícím zabezpečení,
které se poskytuje kryptografickému modulu. Nesmějí být uloženy spolu s
kryptografickým modulem, aby se zabránilo tomu, že přístup k soukromému
klíči bude mít pouze jedna osoba.
194) Za provedení těchto kontrol musí být výslovně odpovědná osoba nebo skupina
důvěryhodných rolí. Je-li odpovědná skupina osob, vede se protokol, který
identifikuje osobu, jež provádí každou kontrolu. Není-li zařízení nepřetržitě
dozorováno, musí poslední osoba, která odchází, parafovat odhlašovací list,
který uvádí datum a čas, a potvrdí, že byly zavedeny a aktivovány všechny
nezbytné mechanismy fyzické ochrany.
5.1.2.2. EA/AA
195) Použijí se stejná ustanovení oddílu 5.1.2.1.
5.1.3. Napájení a klimatizace
196) Zabezpečená zařízení prvků C-ITS modelu služeb vytvářejících důvěru
(kořenovou CA, CPOC, TLM, EA a AA) musí být vybavena spolehlivým
přístupem k elektrické energii pro zajištění provozu bez poruch či s drobnými
poruchami. Jsou nutná primární a záložní zařízení pro případ výpadku vnější
energie a hladkého odstavení vybavení C-ITS modelu služeb vytvářejících
důvěru v případě nedostatku energie. Zařízení C-ITS modelu služeb
vytvářejících důvěru musí být vybavena topným, ventilačním a klimatizačním
systémem, aby byla zachována teplota a relativní vlhkost vybavení C-ITS
modelu služeb vytvářejících důvěru v provozním rozsahu. CPS prvků C-ITS
modelu služeb vytvářejících důvěru budou podrobně popisovat plán a postupy
pro provádění těchto požadavků.
5.1.4. Vystavení vodě
197) Zabezpečená zařízení prvků C-ITS modelu služeb vytvářejících důvěru
(kořenová CA, CPOC, TLM, EA a AA) by měla být chráněna způsobem, který
minimalizuje vliv vystavení vodě. Z tohoto důvodu je třeba se vyhnout potrubí
na vodu a odpadnímu potrubí. CPS prvků C-ITS modelu služeb vytvářejících
CS 45 CS
důvěru budou podrobně popisovat plán a postupy pro provádění těchto
požadavků.
5.1.5. Protipožární opatření a ochrana
198) Aby se předešlo ničivému vlivu plamenů nebo kouře, musí být zabezpečená
zařízení prvků C-ITS modelu služeb vytvářejících důvěru (kořenová CA,
CPOC, TLM, EA a AA) konstruována a vybavena odpovídajícím způsobem a
musí být prováděny postupy pro řešení hrozeb souvisejících s požáry.
Paměťová média by měla být chráněna před požárem ve vhodných
kontejnerech.
199) Prvky C-ITS modelu služeb vytvářejících důvěru chrání fyzická média
obsahující zálohu kritických systémových dat nebo jakékoli jiné citlivé
informace před přírodními nebezpečími a neoprávněným použitím, přístupem k
nim nebo jejich zveřejněním. CPS prvků C-ITS modelu služeb vytvářejících
důvěru budou podrobně popisovat plán a postupy pro provádění těchto
požadavků.
5.1.6. Správa médií
200) S médii používanými v prvcích C-ITS modelu služeb vytvářejících důvěru
(kořenové CA, CPOC, TLM, EA a AA) se nakládá bezpečně, aby byla
chráněna před poškozením, krádeží a neoprávněným přístupem. Implementují
se postupy pro správu médií pro ochranu proti zastarávání a zhoršování stavu
médií po dobu, po kterou je nutné uchovávat záznamy.
201) Citlivé údaje se chrání proti přístupu v důsledku opětovného použití dočasných
pamětí (např. vymazaných souborů), které mohou zpřístupnit citlivé údaje
neoprávněným uživatelům.
202) Udržuje se soupis všech informačních aktiv a musí být stanoveny požadavky
na ochranu těchto aktiv, které jsou v souladu s analýzou rizik. CPS prvků C-
ITS modelu služeb vytvářejících důvěru budou podrobně popisovat plán a
postupy pro provádění těchto požadavků.
5.1.7. Likvidace odpadu
203) Prvky C-ITS modelu služeb vytvářejících důvěru (kořenová CA, CPOC, TLM,
EA a AA) implementují postupy pro bezpečnou a nevratnou likvidaci odpadu
(papíru, médií nebo jakéhokoli jiného odpadu), aby se zabránilo
neoprávněnému použití odpadů obsahujících důvěrné/soukromé informace,
přístupu k nim nebo jejich zveřejnění. Všechna média používaná k uchovávání
citlivých informací, jako jsou klíče, aktivační údaje nebo soubory, se před
uvolněním k likvidaci zničí. CPS prvků C-ITS modelu služeb vytvářejících
důvěru budou podrobně popisovat plán a postupy pro provádění těchto
požadavků.
5.1.8. Záloha mimo pracoviště
5.1.8.1. Kořenová CA, CPOC a TLM
204) Plné zálohy komponent kořenových CA, CPOC a TLM, které jsou dostatečné
pro zotavení po selhání systému, se provádí off-line po zavedení kořenových
CA, CPOC a TLM a po každém novém generování páru klíčů. Pravidelně se
provádějí záložní kopie důležitých obchodních informací (pár klíčů a CRL) a
programového vybavení. Jsou k dispozici odpovídající záložní zařízení, aby se
CS 46 CS
zajistilo, že po havárii nebo selhání médií lze obnovit veškeré důležité
obchodní informace a programové vybavení. Pravidelně se testují zálohovací
režimy pro jednotlivé systémy, aby se zajistilo, že splňují požadavky plánu
kontinuity provozu. Alespoň jedna úplná záložní kopie je uložena mimo
pracoviště (obnova po haváriích). Záložní kopie je uložena v místě, kde fyzické
a procedurální kontroly odpovídají kontrolám provozního systému PKI.
205) Zálohované údaje podléhají stejným požadavkům na přístup jako provozní
údaje. Zálohované údaje musí být šifrovány a uloženy mimo pracoviště. V
případě úplné ztráty dat musí být informace potřebné pro uvedení kořenové
CA, CPOC a TLM zpět do provozu plně obnoveny ze zálohovaných dat.
206) Materiál soukromých klíčů kořenové CA, CPOC a TLM se nesmí zálohovat
pomocí standardních záložních mechanismů, ale pomocí záložní funkce
kryptografického modulu.
5.1.8.2. EA/AA
207) Pro tento oddíl platí postupy popsané v oddíle 5.1.8.1.
5.2. Procedurální kontroly
Tento oddíl popisuje požadavky na role, povinnosti a identifikaci pracovníků.
5.2.1. Důvěryhodné role
208) Zaměstnanci, externí dodavatelé a konzultanti, kterým jsou přiděleny
důvěryhodné role, se považují za „důvěryhodné osoby“. Osoby, které se chtějí
stát se důvěryhodnými, aby získaly důvěryhodné postavení, musí splňovat
požadavky této certifikační politiky na prověřování.
209) Důvěryhodné osoby mají přístup k autentizačním či kryptografickým operacím
(nebo je kontrolují), které mohou podstatně ovlivnit:
• validaci informací v žádostech o certifikát,
• přijetí, zamítnutí nebo jiné zpracování žádostí o certifikát, žádostí o
odvolání nebo žádostí o obnovu,
• vydávání nebo odvolávání certifikátů, včetně pracovníků, kteří mají
přístup k omezeným částem jejich úložiště, nebo nakládání s
informacemi o účastníkovi či žádostmi účastníka.
210) Důvěryhodné role zahrnují mimo jiné:
• zákaznické služby,
• správu systému,
• pověřené inženýrství,
• vedoucí pracovníky, kteří jsou pověřeni řízením důvěryhodnosti
infrastruktury.
211) Certifikační autorita poskytne jasné popisy všech důvěryhodných rolí ve své
CPS.
5.2.2. Počet osob požadovaný pro každý úkol
212) Prvky C-ITS modelu služeb vytvářejících důvěru musí zřídit, udržovat a
prosazovat přísné postupy kontroly, aby bylo zajištěno oddělení povinností na
CS 47 CS
základě důvěryhodných rolí a to, že k provádění citlivých úkolů je zapotřebí
několika důvěryhodných osob. Prvky C-ITS modelu služeb vytvářejících
důvěru (TLM, CPOC, kořenová CA, EA a AA) by měly splňovat [4]
a požadavky následujících odstavců.
213) Jsou zavedeny postupy politiky a kontroly, které zajišťují oddělení povinností
na základě z pracovní odpovědnosti. Nejcitlivější úkoly, jako je přístup ke
kryptografickému hardwaru CA (hardwarový bezpečnostní modul – HSM) a
jeho souvisejícímu klíčovému materiálu a jejich řízení, musí vyžadovat
zmocnění několika důvěryhodných osob.
214) Tyto postupy vnitřní kontroly jsou navrženy tak, aby zajistily, že jsou pro
fyzický nebo logický přístup k zařízení vyžadovány alespoň dvě důvěryhodné
osoby. Omezení přístupu ke kryptografickému hardwaru CA musí být přísně
prosazováno několika důvěryhodnými osobami po celou dobu jeho životního
cyklu, a to od vstupního převzetí a inspekce až po konečnou logickou a/nebo
fyzickou likvidaci. Jakmile je modul aktivován provozními klíči, jsou
zavedeny další kontroly přístupu s cílem zachovat rozdělenou kontrolu nad
fyzickým a logickým přístupem k zařízení.
5.2.3. Identifikace a autentizace pro každou roli
215) Všechny osoby, kterým byla přidělena role, jak je popsáno v této CP, jsou
identifikovány a autentizovány, aby bylo zaručeno, že jim tato role umožní
plnění jejich povinností v rámci PKI.
216) Prvky C-ITS modelu služeb vytvářejících důvěru musí ověřit a potvrdit
totožnost a zmocnění všech pracovníků, kteří se chtějí stát důvěryhodnými
osobami, dříve než jsou jim:
• vydána jejich zařízení pro přístup a poskytnut přístup k požadovaným
zařízením,
• přidělena elektronická oprávnění pro přístup a vykonávání specifických
funkcí v systémech CA.
217) CPS popisuje mechanismy používané k identifikaci a autentizaci jednotlivců.
5.2.4. Role vyžadující oddělení povinností
218) Role vyžadující oddělení povinností zahrnují (mimo jiné):
• přijetí, zamítnutí a odvolání žádostí a jiné zpracování žádostí o certifikát
CA,
• generování, vydávání a likvidaci certifikátu CA.
219) Oddělení povinností může být prosazováno s použitím vybavení PKI, postupů
nebo obojího. Žádnému jednotlivci nesmí být přidělena více než jedna
totožnost, není-li to schváleno kořenovou CA.
220) Část kořenové CA a CA, která se zabývá generováním certifikátů a správou
odvolávání, musí být při svém rozhodování týkajícím se zřizování,
poskytování, udržování a pozastavování služeb v souladu s platnou certifikační
politikou nezávislá na jiných organizacích. Zejména její vyšší vedoucí
pracovník, vedoucí pracovníci a pracovníci v důvěryhodných úlohách nesmí
podléhat žádným komerčním, finančním nebo jiným tlakům, které by mohly
nepříznivě ovlivnit důvěru ve služby, které poskytuje.
CS 48 CS
221) EA a AA, které slouží mobilním stanicím C-ITS, jsou samostatné provozní
subjekty se samostatnými týmy infrastruktury IT a řízení IT. V souladu s
GDPR si EA a AA nesmějí vyměňovat žádné osobní údaje s výjimkou
povolování žádostí o AT. Údaje týkající se schvalování žádostí o AT si
předávají pouze s použitím protokolu pro validaci autorizace dle [1] přes
vyhrazené bezpečné rozhraní. Za předpokladu, že bude implementováno [1],
mohou být použity jiné protokoly.
222) Protokolové soubory uložené EA a AA mohou být použity výhradně pro účel
odvolání EC porušujících pravidla na základě AT v zachycených zlovolných
zprávách CAM/DENM. Poté, co byla zpráva CAM/DENM identifikována jako
zlovolná, vyhledá AA ve svých protokolech o vydávání klíč pro ověřování AT
a předloží EA žádost o odvolání obsahující zašifrovaný podpis pro soukromý
klíč EC, který byl použit při vydání AT. Všechny protokolové soubory musí
být odpovídajícím způsobem chráněny před přístupem neoprávněných stran a
nesmí být sdíleny s jinými subjekty nebo orgány.
Pozn.: V době sepsání této verze CP není koncepce funkce porušení pravidel /
pochybení definována. V budoucích revizích této politiky je plánováno
případně koncipovat funkci porušení pravidel / pochybení.
5.3. Kontroly pracovníků
5.3.1. Požadavky na kvalifikace, zkušenosti a ověření spolehlivosti
223) Prvky C-ITS modelu služeb vytvářejících důvěru zaměstnávají dostatečný
počet pracovníků s odbornými znalostmi, zkušenostmi a kvalifikacemi
potřebnými pro pracovní funkce a nabízené služby. Pracovníci PKI splňují tyto
požadavky prostřednictvím oficiálního výcviku a oprávnění, vlastních
zkušeností nebo kombinací obojího. Důvěryhodné role a povinnosti, jak jsou
upřesněny v CPS, jsou zdokumentovány v popisech práce a jasně stanoveny.
Pracovníci PKI, kteří jsou subdodavateli, mají popisy práce definovány tak,
aby zajistily oddělení povinností a výsad, a citlivost postavení se určuje na
základě povinností a úrovní přístupu, ověření spolehlivosti a školení a
povědomí zaměstnanců.
5.3.2. Postupy ověření spolehlivosti
224) Prvky C-ITS modelu služeb vytvářejících důvěru provádí ověření spolehlivosti
pracovníků, kteří se chtějí stát důvěryhodnými osobami. U pracovníků, kteří
zastávají důvěryhodné funkce, se ověření spolehlivosti opakují nejméně jednou
za pět let.
225) Faktory zjištěné při ověření spolehlivosti, které mohou být považovány za
důvody pro odmítnutí kandidátů na důvěryhodné pozice nebo pro přijetí
opatření vůči stávající důvěryhodné osobě, zahrnují (mimo jiné):
• poskytnutí nesprávných informací kandidátem nebo důvěryhodnou
osobou,
• velmi nepříznivá nebo nespolehlivá pracovní doporučení,
• některé rozsudky v trestních věcech,
• známky nedostatečné finanční odpovědnosti.
226) Zprávy obsahující tyto informace vyhodnotí pracovníci v oblasti lidských
zdrojů, kteří přijmou přiměřená opatření s ohledem na druh, rozsah a četnost
CS 49 CS
chování zjištěného ověřením spolehlivosti. Může jít o opatření až po a včetně
odvolání nabídek zaměstnání učiněných kandidátům na důvěryhodné pozice
nebo ukončení pracovního poměru stávajících důvěryhodných osob. Použití
informací zjištěných při ověření spolehlivosti jako základu pro takové opatření
podléhá platným právním předpisům.
227) Osobní prověrka osob, které se chtějí stát důvěryhodnými, zahrnuje mimo jiné:
• potvrzení předchozího zaměstnání,
• kontrolu pracovních doporučení vztahujících se na jejich zaměstnání po
dobu nejméně pěti let,
• potvrzení nejvyššího nebo nejvýznamnějšího stupně dosaženého
vzdělání,
• výpis z rejstříku trestů.
5.3.3. Požadavky na výcvik
228) Prvky C-ITS modelu služeb vytvářejících důvěru poskytnou svým
pracovníkům potřebnou odbornou přípravu, aby mohli kvalifikovaně a
uspokojivě plnit své povinnosti související s činnostmi CA.
229) Programy odborné přípravy jsou pravidelně přezkoumávány a jejich výcvik se
zabývá otázkami, které se týkají funkcí vykonávaných zúčastněnými
pracovníky.
230) Programy odborné přípravy se týkají záležitostí důležitých pro konkrétní
prostředí školené osoby, včetně:
• bezpečnostních zásad a mechanismů prvků C-ITS modelu služeb
vytvářejících důvěru,
• používaných verzí hardwaru a softwaru,
• všech povinností, které má osoba plnit, a interních a externích procesů a
sekvencí podávání zpráv,
• obchodních procesů a postupů PKI,
• hlášení incidentů a ohrožení a nakládání s nimi,
• postupů pro obnovu po haváriích a kontinuitu provozu,
• dostatečných znalostí v oblasti IT.
5.3.4. Četnost rekvalifikace a požadavky na ni
231) Osoby, kterým jsou přiděleny důvěryhodné úlohy, jsou povinny si ve
vzdělávacím prostředí průběžně osvěžovat znalosti, které získali v rámci
odborné přípravy. Odborná příprava se musí opakovat, kdykoli je to
považováno za potřebné, a alespoň každé dva roky.
232) Prvky C-ITS modelu služeb vytvářejících důvěru poskytnou svým
pracovníkům opakovací školení a aktualizace v rozsahu a frekvenci potřebné k
tomu, aby se zajistilo, že si udržují požadovanou úroveň odborné způsobilosti,
aby své pracovní povinnosti mohli plnit kvalifikovaně a uspokojivě.
233) Osoby v důvěryhodných úlohách musí být dle potřeby informovány o změnách
v činnostech PKI. Každou významnou změnu činností musí doprovázet plán
CS 50 CS
odborné přípravy (informovanosti) a provedení tohoto plánu musí být
zdokumentováno.
5.3.5. Četnost rotace pracovních míst a jejich pořadí
234) Není stanoveno, pokud jsou zajištěny technické dovednosti, zkušenosti a
přístupová práva. Správci prvků C-ITS modelu služeb vytvářejících důvěru
zajistí, aby personální změny neměly vliv na bezpečnost systému.
5.3.6. Sankce za neautorizované činnosti
235) Každý z prvků C-ITS modelu služeb vytvářejících důvěru musí vyvinout
formální disciplinární řízení s cílem zajistit, aby neoprávněné činnosti byly
odpovídajícím způsobem postihovány. V závažných případech je třeba
odejmout přidělení rolí a odpovídající výsady.
5.3.7. Požadavky na nezávislé dodavatele
236) Prvky C-ITS modelu služeb vytvářejících důvěru mohou nezávislým
dodavatelům nebo konzultantům povolit, aby se stali důvěryhodnými osobami,
pouze v rozsahu nezbytném pro jasně definované vztahy externího poskytování
služeb a pod podmínkou, že daný subjekt dodavatelům nebo konzultantům
důvěřuje ve stejném rozsahu, jako kdyby byli zaměstnanci, a že oni splňují
požadavky vztahující se na zaměstnance.
237) V opačném případě mají nezávislí dodavatelé a konzultanti do zabezpečených
zařízení C-ITS PKI přístup, pouze pokud jsou doprovázeni důvěryhodnými
osobami a jsou pod jejich přímým dozorem.
5.3.8. Dokumentace poskytovaná pracovníkům
238) Prvky C-ITS modelu služeb vytvářejících důvěru poskytnou svým
pracovníkům nezbytnou odbornou přípravu a přístup k dokumentaci, kterou
potřebují, aby kvalifikovaně a uspokojivě plnili své pracovní povinnosti.
5.4. Postupy protokolování auditu
239) Tento oddíl stanoví požadavky týkající se typů událostí, které mají být
zaznamenávány, a správy auditních protokolů.
5.4.1. Typy událostí, které mají být zaznamenávány a oznamovány každou CA
240) Zástupce CA pravidelně přezkoumává protokoly, události a postupy CA.
241) Prvky C-ITS modelu služeb vytvářejících důvěru zaznamenávají následující
typy kontrolních událostí (je-li to relevantní):
• fyzický přístup k zařízením – přístup fyzických osob k zařízením se
zaznamená ukládáním žádostí o přístup pomocí čipových karet. Událost
bude vytvořena pokaždé, když dojde k vytvoření záznamu,
• správa důvěryhodných úloh – bude zaznamenána každá změna v definici
a úrovni přístupu různých rolí, včetně úpravy atributů úloh. Událost bude
vytvořena pokaždé, když dojde k vytvoření záznamu,
• logický přístup – událost bude generována, když má subjekt (např.
program) přístup k citlivým oblastem (tj. sítím a serverům),
• správa záloh – událost se vytvoří pokaždé, když je dokončena záloha, a
to buď úspěšně, nebo neúspěšně,
CS 51 CS
• správa protokolů – protokoly budou uloženy. Událost se vytvoří, když
protokol překročí určitou velikost,
• údaje z procesu autentizace účastníků a prvků C-ITS modelu služeb
vytvářejících důvěru – budou generovány události pro každou žádost o
autentizaci účastníků a prvků C-ITS modelu služeb vytvářejících důvěru,
• přijetí a zamítnutí žádostí o certifikát, včetně vytvoření a obnovy
certifikátu – událost bude pravidelně generována se seznamem přijatých
a zamítnutých žádostí o certifikát v předchozích sedmi dnech,
• registrace výrobce – událost se vytvoří v okamžiku registrace výrobce,
• registrace stanice C-ITS – událost se vytvoří v okamžiku registrace
stanice C-ITS,
• správa HSM – událost se vytvoří v okamžiku, kdy je zaznamenáno
narušení zabezpečení hardwarového bezpečnostního modulu,
• správa IT a sítě, pokud náleží k systémům PKI – událost se vytvoří v
okamžiku, kdy je server PKI odstaven nebo znovu nastartován,
• řízení bezpečnosti (úspěšné a neúspěšné pokusy o přístup k PKI,
provedené činnosti PKI a bezpečnostního systému, změny
bezpečnostního profilu, zhroucení systému, selhání hardwaru a jiné
anomálie, činnosti firewallu a routeru a vstupy do zařízení PKI a
odchody z nich),
• údaje týkající se událostí budou uchovávány po dobu nejméně pěti let,
pokud se neuplatní další vnitrostátní pravidla.
242) V souladu s GDPR neumožňují auditní protokoly přístup k údajům týkajícím
se soukromí ohledně soukromých vozidel stanic C-ITS.
243) Je-li to možné, jsou protokoly bezpečnostních auditů shromažďovány
automaticky. Kde to možné není, použije se protokolový deník, papírový
formulář nebo jiný fyzický mechanismus. Uchovávají se všechny protokoly
bezpečnostních auditů, elektronické i neelektronické, a zpřístupňují se během
auditů souladu.
244) Každá událost spojená s životním cyklem certifikátu je zaznamenána tak, aby
bylo možné ji přičíst osobě, která ji provedla. Všechny údaje týkající se osobní
totožnosti jsou šifrovány a chráněny před neoprávněným přístupem.
245) Každý kontrolní záznam obsahuje přinejmenším tyto údaje (které jsou pro
každou událost podléhající auditu automaticky nebo ručně zaznamenány):
• druh události (podle seznamu uvedeného výše),
• důvěryhodné datum a čas, kdy k události došlo,
• výsledek události – úspěch či případně neúspěch,
• případně totožnost subjektu a/nebo provozovatele, který událost způsobil,
• totožnost subjektu, jehož se událost týká.
CS 52 CS
5.4.2. Četnost zpracování protokolu
246) Auditní protokoly se přezkoumávají v reakci na upozornění založená na
nesrovnalostech a incidentech v rámci systémů CA a navíc pravidelně každý
rok.
247) Zpracování auditních protokolů sestává z jejich přezkumu a dokumentování
důvodu všech významných událostí ve shrnutí auditního protokolu. Přezkumy
auditních protokolů zahrnují ověření, že s protokolem nebylo nedovoleně
manipulováno, kontrolu všech položek protokolu a šetření veškerých
upozornění nebo nesrovnalostí v protokolech. Opatření přijatá na základě
přezkumů kontrolních záznamů musí být zdokumentována.
248) Auditní protokol je nejméně jednou týdně archivován. Je-li volný diskový
prostor pro auditní protokol menší než očekávaný objem údajů auditního
protokolu vytvořený v daném týdnu, správce jej archivuje manuálně.
5.4.3. Doba uchovávání auditního protokolu
249) Kontrolní záznamy týkající se životních cyklů certifikátů se uchovávají po
dobu nejméně pěti let od skončení platnosti příslušného certifikátu.
5.4.4. Ochrana auditního protokolu
250) Integrita a důvěrnost auditního protokolu je zaručena kontrolním
mechanismem přístupu na základě role. Přístup k interním auditním
protokolům mají pouze správci; k auditním protokolům týkajícím se životního
cyklu certifikátů mohou mít přístup také uživatelé s příslušnou autorizací
prostřednictvím webové stránky s uživatelským přihlášením. Musí být zajištěn
přístup více uživatelů (alespoň 2 uživatelé) a nejméně dvouúrovňová
autentizace. Je nutné technicky zajistit, aby uživatelé neměli přístup ke svým
vlastním protokolovým souborům.
251) Každá položka protokolu se podepíše pomocí klíčového materiálu z HSM.
252) Protokoly o událostech obsahující informace, které mohou vést k osobní
identifikaci, například soukromého vozidla, jsou šifrovány tak, že je mohou
přečíst pouze oprávněné osoby.
253) Události jsou zaprotokolovány tak, aby je nebylo možné snadno vymazat nebo
zlikvidovat (s výjimkou přenosu na dlouhodobá média) během období, po které
se protokoly musí uchovávat.
254) Protokoly o událostech jsou chráněny tak, aby byly čitelné po dobu svého
uložení.
5.4.5. Postupy zálohování auditního protokolu
255) Auditní protokoly a shrnutí jsou zálohovány pomocí podnikových
zálohovacích mechanismů, které jsou pod kontrolou oprávněných
důvěryhodných rolí oddělených od jejich generování zdrojů komponent.
Zálohy auditního protokolu jsou chráněny se stejnou úrovní důvěry, jaká platí
pro původní protokoly.
5.4.6. Auditní systém sběru údajů (interní nebo externí)
256) Vybavení prvků C-ITS modelu služeb vytvářejících důvěru aktivuje auditní
procesy při spuštění systému a deaktivuje je pouze při odstávce systému.
CS 53 CS
Nejsou-li auditní procesy k dispozici, prvek C-ITS modelu služeb vytvářejících
důvěru přeruší svou činnost.
257) Na konci každého provozního období a při změně klíčů certifikátů by měl být
provoznímu manažerovi a řídicímu orgánu příslušného prvku PKI vykázán
společný stav zařízení.
5.4.7. Oznámení subjektu, který událost způsobil
258) Je-li událost zaznamenána systémem auditního sběru, zaručuje to, že je událost
spojena s důvěryhodnou rolí.
5.4.8. Hodnocení zranitelnosti
259) Role odpovědná za provádění auditu a role odpovědné za realizaci provozu
systému PKI v prvcích C-ITS modelu služeb vytvářejících důvěru vysvětlují
všechny významné události ve shrnutí auditních protokolů. Součástí těchto
přezkumů je ověření, zda s protokolem nebylo nedovoleně manipulováno a zda
nedošlo k narušení kontinuity nebo jiné ztrátě auditních údajů, a poté stručná
kontrola všech položek protokolů a důkladnější prošetření jakýchkoli
upozornění či nesrovnalostí v protokolech. Opatření přijatá v důsledku těchto
přezkumů jsou zdokumentována.
CS 54 CS
260) Prvky C-ITS modelu služeb vytvářejících důvěru musí:
• provádět organizační a/nebo technické detekční a preventivní kontroly
pod kontrolou prvků C-ITS modelu služeb vytvářejících důvěru za
účelem ochrany systémů PKI proti virům a škodlivému softwaru,
• dokumentovat proces nápravy zranitelnosti, který se zabývá identifikací a
přezkumem zranitelných míst, reakcí na ně a jejich nápravou, a řídit se
jím,
• podstoupit nebo provést kontrolu zranitelnosti,
• po všech změnách systému nebo sítě, které prvky C-ITS modelu
služeb vytvářejících důvěru určí jako významné pro komponenty
PKI, a
• alespoň jednou měsíčně na veřejných a soukromých IP adresách
určených CA a CPOC jako systémy PKI,
• podstoupit zkoušku průrazem systémů PKI alespoň jednou ročně a po
modernizaci nebo úpravách infrastruktury nebo aplikace určených prvky
C-ITS modelu služeb vytvářejících důvěru jako významné pro
komponenty PKI CA,
• u on-line systémů zaznamenávat důkazy o tom, že každá kontrola
zranitelnosti a zkouška průrazem byla provedena osobou nebo subjektem
(či jejich kolektivní skupinou) s dovednostmi, nástroji, odbornou
způsobilostí, etickým kodexem a nezávislostí, jež jsou nezbytné pro
zajištění spolehlivé kontroly zranitelnosti či zkoušky průrazem,
• sledovat a napravit zranitelná místa v souladu s podnikovou politikou v
oblasti kybernetické bezpečnosti a s metodikou snižování rizika.
5.5. Archivace záznamů
5.5.1. Typy archivovaných záznamů
261) Prvky C-ITS modelu služeb vytvářejících důvěru archivují záznamy dostatečně
podrobné pro stanovení platnosti podpisu a řádného provozu PKI. Archivují se
minimálně tyto záznamy událostí PKI (jsou-li příslušné):
• protokol fyzického přístupu k prvkům C-ITS modelu služeb vytvářejících
důvěru (nejméně jeden rok),
• protokol řízení důvěryhodných rolí pro prvky C-ITS modelu služeb
vytvářejících důvěru (nejméně 10 let),
• protokol přístupu k IT pro prvky C-ITS modelu služeb vytvářejících
důvěru (nejméně pět let),
• protokol vytvoření, používání a likvidace klíče CA (minimálně pět let)
(ne pro TLM a CPOC),
• protokol vytvoření, používání a likvidace certifikátu (nejméně dva roky),
• protokol žádosti CPA (nejméně dva roky),
• protokol správy aktivačních údajů pro prvky C-ITS modelu služeb
vytvářejících důvěru (nejméně pět let),
CS 55 CS
• protokol IT a sítě pro prvky C-ITS modelu služeb vytvářejících důvěru
(nejméně pět let),
• dokumentace PKI pro prvky C-ITS modelu služeb vytvářejících důvěru
(nejméně pět let),
• zpráva o bezpečnostních incidentech a auditu pro prvky C-ITS modelu
služeb vytvářejících důvěru (nejméně 10 let),
• systémové vybavení, software a konfigurace (nejméně pět let).
262) Prvky C-ITS modelu služeb vytvářejících důvěru uchovávají tuto dokumentaci
týkající se žádostí o certifikát a jejich ověřování a všech certifikátů TLM,
kořenových CA a CA a jejich CRL po dobu nejméně sedmi let po ukončení
platnosti jakéhokoli certifikátu založeného na této dokumentaci:
• dokumentace k auditu PKI vedená prvky C-ITS modelu služeb
vytvářejících důvěru,
• dokumenty CPS vedené prvky C-ITS modelu služeb vytvářejících
důvěru,
• smlouva mezi CPA a jinými subjekty uchovávaná prvky C-ITS modelu
služeb vytvářejících důvěru,
• certifikáty (nebo jiné informace o odvolání) vedené CA a TLM,
• záznamy žádostí o certifikát v systému kořenové CA (nevztahuje se na
TLM),
• jiné údaje nebo žádosti dostatečné k ověření obsahu archivu,
• veškerá práce související s prvky C-ITS modelu služeb vytvářejících
důvěru a auditory souladu, nebo jimi prováděná.
263) Subjekt CA uchovává veškerou dokumentaci týkající se žádostí o certifikát a
jejich ověřování a všech certifikátů a jejich odvolání po dobu nejméně sedmi
let po ukončení platnosti jakéhokoli certifikátu založeného na této
dokumentaci.
5.5.2. Doba uchovávání v archivu
264) Aniž jsou dotčeny předpisy, které vyžadují delší dobu archivace, prvky C-ITS
modelu služeb vytvářejících důvěru uchovávají všechny záznamy po dobu
nejméně pěti let po uplynutí doby platnosti příslušného certifikátu.
5.5.3. Ochrana archivu
265) Prvky C-ITS modelu služeb vytvářejících důvěru uchovávají archiv záznamů v
bezpečném a zabezpečeném skladovacím zařízení, které je oddělené od
vybavení CA, s fyzickými a procedurálními bezpečnostními kontrolami, které
jsou rovnocenné nebo lepší než kontroly PKI.
266) Archiv musí být chráněn proti neoprávněnému prohlížení, pozměňování,
mazání nebo jiné nedovolené manipulaci uložením v důvěryhodném systému.
267) Média, na kterých se archivní údaje nachází, a aplikace nutné k jejich
zpracování se uchovávají, aby se zajistilo, že k nim bude možný přístup po
dobu stanovenou v této CP.
CS 56 CS
5.5.4. Systémový archiv a uchovávání
268) Prvky C-ITS modelu služeb vytvářejících důvěru každodenně inkrementálně
zálohují systémové archivy těchto informací a každý týden provádí úplné
zálohy. Kopie záznamů v listinné podobě se uchovávají v zabezpečeném
zařízení mimo pracoviště.
5.5.5. Požadavky na časová razítka záznamů
269) Prvky C-ITS modelu služeb vytvářejících důvěru, které spravují databázi
odvolání, zajistí, aby záznamy obsahovaly informace o času a datu, kdy byly
záznamy o odvolání vytvořeny. Integrita těchto informací bude provedena
pomocí řešení založených na šifrování.
5.5.6. Systém archivace (interní nebo externí)
270) Systém archivace je interní.
5.5.7. Postupy získávání a ověřování archivních informací
271) Všechny prvky C-ITS modelu služeb vytvářejících důvěru umožní přístup do
archivu pouze oprávněným důvěryhodným osobám. Kořenové CA a CA popíší
postupy vytváření, ověřování, balení, předávání a ukládání archivních
informací v CPS.
272) Vybavení kořenových CA a CA ověří integritu informací před jejich
obnovením.
5.6. Změna klíčů pro prvky C-ITS modelu služeb vytvářejících důvěru
273) Uvedené prvky C-ITS modelu služeb vytvářejících důvěru mají specifické
požadavky na změnu svých klíčů: certifikáty TLM, kořenové CA a EA/AA.
5.6.1. TLM
274) TLM smaže svůj soukromý klíč po uplynutí platnosti odpovídajícího
certifikátu. Před deaktivací stávajícího platného soukromého klíče generuje
nový pár klíčů a odpovídající certifikát TLM. Dbá na to, aby nový (spojovací)
certifikát byl včas vložen do ECTL, aby byl distribuován všem stanicím C-ITS
před tím, než se stane platným. Spojovací certifikát a nový samopodepsaný
certifikát se převádí do CPOC.
5.6.2. Kořenová CA
275) Kořenová CA deaktivuje a vymaže stávající soukromý klíč (včetně záložních
klíčů), aby nevydávala certifikáty EA/AA s platností, která přesahuje platnost
certifikátu kořenové CA.
276) Kořenová CA generuje před deaktivací stávajícího soukromého klíče (včetně
záložních klíčů) nový pár klíčů a odpovídající certifikát kořenové CA a
spojovací certifikát a zašle je TLM k vložení do ECTL. Doba platnosti nového
certifikátu kořenové CA začíná běžet od plánované deaktivace stávajícího
soukromého klíče. Kořenová CA dbá na to, aby byl nový certifikát včas vložen
do ECTL, aby byl distribuován všem zařízením C-ITS před tím, než se stane
platným.
277) Kořenová CA aktivuje nový soukromý klíč, jakmile se odpovídající základní
certifikát kořenové CA stane platným.
CS 57 CS
5.6.3. Certifikát EA/AA
278) EA/AA deaktivuje stávající soukromý klíč, aby nevydával certifikáty EC/AT s
platností, která přesahuje platnost certifikátu EA/AA.
279) EA/AA generuje nový pár klíčů a před deaktivací stávajícího soukromého klíče
si vyžádá odpovídající certifikát EA/AA. Doba platnosti nového certifikátu
EA/AA začíná běžet od plánované deaktivace stávajícího soukromého klíče.
EA/AA dbá na to, aby mohl být nový certifikát včas zveřejněn, aby byl
distribuován všem stanicím C-ITS před tím, než se stane platným.
280) Když se odpovídající certifikát EA/AA stane platným, EA/AA aktivuje nový
soukromý klíč.
5.6.4. Auditor
Žádná ustanovení.
5.7. Obnova po ohrožení a havárii
5.7.1. Řešení incidentů a ohrožení
281) Prvky C-ITS modelu služeb vytvářejících důvěru monitorují průběžně své
vybavení, aby odhalily možné hackerské pokusy nebo jiné formy ohrožení. V
takovém případě provedou šetření s cílem určit povahu a stupeň poškození.
282) Odhalí-li pracovníci odpovědní za řízení kořenové CA nebo TLM možný
hackerský pokus nebo jinou formu ohrožení, provedou šetření s cílem určit
povahu a stupeň poškození. Je-li ohrožen soukromý klíč, odvolá se certifikát
kořenové CA. Odborníci na bezpečnost IT v CPA posoudí rozsah možných
škod, aby určili, zda musí být PKI přestavěna, zda musí být pouze odvolány
některé certifikáty a/nebo zda došlo k ohrožení PKI. CPA dále v souladu s
plánem zachování provozu CPA určí, které služby mají být zachovány
(informace o odvolání a stavu certifikátů), a jak.
283) Na incident, ohrožení a zachování provozu se vztahuje CPS, které pro svou
implementaci může spoléhat také na jiné zdroje podniku a plány.
284) Odhalí-li pracovníci odpovědní za řízení EA/AA/CPOC možný hackerský
pokus nebo jinou formu ohrožení, provedou šetření s cílem určit povahu a
stupeň poškození. Pracovníci odpovědní za řízení subjektu CA nebo CPOC
posoudí rozsah možných škod s cílem určit, zda musí být komponenta PKI
přestavěna, zda musí být pouze odvolány některé certifikáty a/nebo zda byla
ohrožena komponenta PKI. Subjekt podřízené CA navíc určí, které služby mají
být v souladu s plánem zachování provozu subjektu podřízené CA zachovány,
a jak. Je-li ohrožena komponenta PKI, subjekt CA upozorní svou vlastní
kořenovou CA a TLM prostřednictvím CPOC.
285) Na incident, ohrožení a zachování provozu se vztahuje CPS kořenové CA nebo
TLM či jiné příslušné dokumenty v případě CPOC, které se může rovněž
spoléhat na jiné zdroje podniku a plány svého provádění.
286) Kořenová CA a CA upozorní s přesnými informacemi o důsledcích incidentu
zástupce každého členského státu a kořenovou CA, s nímž mají dohodu v
kontextu C-ITS, aby jim umožnil aktivovat jejich vlastní plán pro řešení
incidentů.
CS 58 CS
5.7.2. Porušení výpočetních zdrojů, softwaru a/nebo dat
287) Je-li zjištěna havárie, která brání řádnému fungování prvku C-ITS modelu
služeb vytvářejících důvěru, zastaví tento prvek svou činnost a prošetří, zda
došlo k ohrožení soukromého klíče (s výjimkou CPOC). Vadný hardware se co
nejrychleji vymění a použijí se postupy popsané v oddílech 5.7.3 a 5.7.4.
288) Porušení výpočetních zdrojů, softwaru a/nebo dat se kořenové CA hlásí do 24
hodin v případě nejvyšší úrovně rizika. Všechny ostatní události musí být
zahrnuty do pravidelné zprávy kořenové CA, EA a AA.
5.7.3. Postupy při ohrožení soukromého klíče subjektu
289) Je-li soukromý klíč kořenové CA ohrožen, ztracen, zničen nebo existuje
podezření na jeho ohrožení, musí kořenová CA:
• pozastavit svůj provoz,
• zahájit plán obnovy po havárii a migrace,
• odvolat svůj certifikát kořenové CA,
• prošetřit „klíčovou otázku“, která vedla k ohrožení, a upozornit CPA,
který certifikát kořenového CA odvolá prostřednictvím TLM (viz oddíl
7),
• upozornit všechny účastníky, s nimiž má dohodu.
290) Je-li klíč EA/AA ohrožen, ztracen, zničen nebo existuje-li podezření, že je
ohrožen, musí EA/AA:
• pozastavit svůj provoz,
• odvolat svůj vlastní certifikát,
• vyšetřit „klíčovou otázku“ a uvědomit o ní kořenovou CA,
• upozornit účastníky, s nimiž existuje dohoda.
291) Je-li klíč EC nebo AT stanice C-ITS ohrožen, ztracen, zničen nebo existuje-li
podezření na jeho ohrožení, musí EA/AA, u které je stanice C-ITS zapsána:
• odvolat EC dotčeného ITS,
• vyšetřit „klíčovou otázku“ a uvědomit o ní kořenovou CA,
• upozornit účastníky, s nimiž má dohodu.
292) Pokud se některý z algoritmů nebo souvisejících parametrů používaných
kořenovou CA a/nebo CA či stanicemi C-ITS stane pro zbývající zamýšlené
použití nedostatečným, musí CPA (s doporučením odborníků na šifrování)
informovat subjekt kořenové CA, s nímž má dohodu, a změnit použité
algoritmy. (Podrobnosti viz oddíl 6 a CPS kořenové CA a podřízené CA).
5.7.4. Schopnosti kontinuity činnosti po havárii
293) Prvky C-ITS modelu služeb vytvářejících důvěru, které provozují zabezpečené
zařízení pro provoz CA, vypracují, přezkouší, udržují a provádí plán obnovy po
havárii určený ke zmírnění následků jakýchkoli přírodních nebo člověkem
způsobených katastrof. Tyto plány řeší obnovu služeb informačních systémů a
klíčových obchodních funkcí.
CS 59 CS
294) Po incidentu s určitou úrovní rizika musí být ohrožená CA podrobena
opakovanému auditu akreditovaným auditorem PKI (viz oddíl 8).
295) V případě, že ohrožená CA nemůže dále fungovat (např. po vážném incidentu),
musí být vypracován plán migrace pro převedení jejích funkcí na jinou
kořenovou CA. Na podporu plánu migrace musí být k dispozici alespoň
kořenová CA EU. Ohrožená CA musí své funkce ukončit.
296) Kořenová CA zahrne plán obnovy po havárii a plán migrace do CPS.
5.8. Ukončení a převod
5.8.1. TLM
297) TLM nesmí ukončit svůj provoz, ale subjekt, který TLM řídí, může převzít jiný
subjekt.
298) V případě změny řídícího subjektu:
• požádá CPA o schválení změny řízení TLM ze starého subjektu na nový
subjekt,
• CPA schválí změnu řízení TLM,
• všechny auditní protokoly a archivované záznamy se převedou ze starého
řídícího subjektu na nový.
5.8.2. Kořenová CA
299) Kořenová CA nesmí ukončit/zahájit svůj provoz, aniž by připravila plán
migrace (stanovený v příslušné CPS), který zaručuje nepřetržitý provoz pro
všechny účastníky.
300) V případě ukončení služby kořenové CA musí kořenová CA:
• uvědomit CPA,
• uvědomit TLM, aby mohl vymazat certifikát kořenové CA z ECTL,
• odvolat odpovídající kořenovou CA tím, že vydá CRL, který obsahuje ji
samou,
• upozornit kořenové CA, s nimiž má dohodu o obnově certifikátů EA/AA,
• zlikvidovat soukromý klíč kořenové CA,
• sdělit spoléhající se straně poslední informace o stavu odvolání (CRL
podepsaný kořenovou CA), přičemž jasně uvede, že se jedná o nejnovější
informace o odvolání,
• archivovat veškeré auditní protokoly a jiné záznamy před ukončením
PKI,
• předat archivované záznamy příslušnému orgánu.
301) TLM vymaže odpovídající certifikát kořenové CA z ECTL.
5.8.3. EA/AA
302) V případě ukončení služby EA/AA poskytne subjekt EA/AA oznámení před
ukončením. EA nebo AA nesmí ukončit/zahájit svůj provoz, aniž by zřídila
plán migrace (stanovený v příslušném CPS), který zaručuje průběžný provoz
pro všechny účastníky. EA/AA musí:
CS 60 CS
• informovat kořenovou CA doporučeným dopisem,
• zlikvidovat soukromý klíč CA,
• přenést svou databázi do subjektu jmenovaného kořenovou CA,
• přestat vydávat certifikáty,
• během předávání své databáze a až do doby, kdy je databáze plně funkční
v novém subjektu, zachovat schopnost autorizovat žádosti orgánu
odpovědného za ochranu soukromí,
• pokud byla ohrožena podřízená CA, kořenová CA podřízenou CA odvolá
a vydá nový CRL se seznamem odvolaných podřízených CA,
• archivovat veškeré auditní protokoly a jiné záznamy před ukončením
PKI,
• přenést archivované záznamy do subjektu jmenovaného kořenovou CA.
303) V případě ukončení služeb CA je CA odpovědná za vedení veškerých
příslušných záznamů týkajících se potřeb CA a komponent PKI.
6. TECHNICKÉ BEZPEČNOSTNÍ KONTROLY
6.1. Generování a instalace páru klíčů
6.1.1. TLM, kořenová CA, EA, AA
304) Proces generování páru klíčů musí splňovat tyto požadavky:
• každý účastník je schopen generovat vlastní páry klíčů v souladu s oddíly
6.1.4 a 6.1.5,
• proces odvozování symetrických šifrovacích klíčů a klíče MAC pro
žádosti o certifikát (ECIES) se provádí v souladu s [1] a [5],
• proces generování klíčů používá algoritmy a délky klíčů popsané
v oddílech 6.1.4.1 a 6.1.4.2,
• na proces generování párů klíčů se vztahují požadavky na „bezpečné
uchovávání soukromých klíčů“ (viz oddíl 6.1.5),
• kořenové CA a jejich účastníci (podřízené CA) zajistí, aby byly integrita
a autenticita jejich veřejných klíčů a s nimi související parametry
zachovány v průběhu distribuce subjektům registrovaným podřízeným
CA.
6.1.2. Koncový subjekt – mobilní stanice C-ITS
305) Každá mobilní stanice C-ITS generuje své vlastní páry klíčů v souladu s oddíly
6.1.4 a 6.1.5.
306) Proces odvozování symetrických šifrovacích klíčů a klíče MAC pro žádosti
o certifikát (ECIES) se provádí v souladu s [1] a [5].
307) Proces generování klíčů používá algoritmy a délky klíčů popsané v oddílech
6.1.4.1 a 6.1.4.2.
308) Na procesy generování párů klíčů se vztahují požadavky na „bezpečné
uchovávání soukromých klíčů“ (viz oddíl 6.1.5).
CS 61 CS
6.1.3. Koncový subjekt – pevné stanice C-ITS
309) Každá pevná stanice C-ITS generuje své vlastní páry klíčů v souladu s oddíly
6.1.4 a 6.1.5.
310) Proces generování klíčů používá algoritmy a délky klíčů popsané v oddílech
6.1.4.1 a 6.1.4.2.
311) Na procesy generování párů klíčů se vztahují požadavky na „bezpečné
uchovávání soukromých klíčů“ (viz oddíl 6.1.5).
6.1.4. Kryptografické požadavky
312) Účastníci PKI musí splňovat kryptografické požadavky stanovené
v následujících odstavcích, pokud jde o algoritmus podpisu, délku klíče,
generátor náhodných čísel a spojovací certifikáty.
6.1.4.1. Algoritmus a délka klíče – algoritmy podpisu
313) Všichni účastníci PKI (TLM, kořenový CA, EA, AA a stanice C-ITS) musí být
schopni generovat páry klíčů a používat soukromý klíč pro podepisování
operací s vybranými algoritmy nejpozději dva roky po vstupu tohoto nařízení
v platnost v souladu s tabulkou 4.
314) Všichni účastníci PKI, kteří musí kontrolovat integritu ECTL, certifikátů
a/nebo podepsaných zpráv v souladu s jejich rolí, jak je definována v oddíle
1.3.6, podpoří odpovídající algoritmy uvedené v tabulce 5 pro ověření.
Zejména stanice C-ITS musí být schopny ověřit integritu ECTL.
TLM kořenová
CA
EA AA Stanice
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 povinnou podporu
Tabulka 4: Generování párů klíčů a využití soukromého klíče pro podepisování operací
CS 62 CS
TLM kořenová
CA
EA AA Stanice
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 povinnou podporu
Tabulka 5: Přehled ověření
315) Pokud tak CPA rozhodne na základě nově zjištěných nedostatků v oblasti
šifrování, musí být všechna zařízení C-ITS schopna přejít co nejdříve na jeden
ze dvou algoritmů (ECDSA_nistP256_s_SHA 256 nebo
ECDSA_brainpoolP256_s_SHA 256). Skutečný algoritmus (algoritmy), který
(které) je (jsou) použit(y), se určí v CPS CA, která vydává certifikát pro
odpovídající veřejný klíč v souladu s touto CP.
6.1.4.2. Algoritmus a délka klíče – šifrovací algoritmy pro registraci a autorizaci
316) Všichni účastníci PKI (EA, AO a stanice C-ITS) musí být schopni používat
veřejné klíče k šifrování žádostí o / odpovědí na registraci a autorizaci
s vybranými algoritmy nejpozději dva roky po vstupu tohoto nařízení
v platnost v souladu s tabulkou 6. Skutečný algoritmus (algoritmy), který
(které) je (jsou) použit(y), se určí v CPS CA, která vydává certifikát pro
odpovídající veřejný klíč v souladu s touto CP.
317) Jmenovitě uvedené algoritmy v tabulce 6 uvádějí délku klíče a délku algoritmu
hash a provádějí se v souladu s [5].
TLM kořenová
CA
EA AA Stanice
C-ITS
ECIES_nistP256_with_AES 128_CCM - - X X X
ECIES_brainpoolP256r1_with_AES 128_CCM - - X X X
X označuje povinnou podporu
Tabulka 6: Používání veřejných klíčů pro šifrování žádostí o / odpovědí na registraci a autorizaci
CS 63 CS
318) Všichni účastníci PKI (EA, AA a stanice C-ITS) musí mít možnost generovat
klíčové páry a používat soukromý klíč k dekódování žádostí o / odpovědí
na registraci a autorizaci s vybranými algoritmy nejpozději dva roky po vstupu
tohoto nařízení v platnost v souladu s tabulkou 7:
TLM kořenová
CA
EA AA Stanice
C-ITS
ECIES_nistP256_with_AES 128_CCM - - X X X
ECIES_brainpoolP256r1_with_AES 128_CCM - - X X X
X označuje povinnou podporu
Tabulka 7: Generování párů klíčů a používání soukromého klíče pro dekódování žádostí o / odpovědí na
registraci a autorizaci
6.1.4.3. Kryptoagilita
319) Požadavky týkající se délek klíčů a algoritmů se musí v průběhu času měnit
tak, aby byla zachována přiměřená úroveň bezpečnosti. CPA sleduje potřebu
těchto změn s ohledem na skutečnou zranitelnost a současnou kryptografii.
Pokud se rozhodne, že kryptografické algoritmy by měly být aktualizovány,
vypracuje, schválí a zveřejní aktualizaci této certifikační politiky. Pokud nové
vydání této CP signalizuje změnu algoritmu a/nebo délky klíče, CPA přijme
strategii migrace, která zahrnuje přechodná období, během nichž musí být
podporovány staré algoritmy a klíčové délky.
320) S cílem umožnit a usnadnit přechod na nové algoritmy a/nebo délky klíčů se
doporučuje, aby všichni účastníci PKI zavedli hardware a/nebo software
umožňující přepínání délek klíčů a algoritmů.
321) Změny kořenových certifikátů a certifikátů TLM jsou podporovány
a prováděny za pomoci spojovacích certifikátů (viz oddíl 4.6), které se
používají k pokrytí přechodného období mezi starými a novými kořenovými
certifikáty („migrace modelu služeb vytvářejících důvěru“).
6.1.5. Bezpečné uchovávání soukromých klíčů
Tento oddíl popisuje požadavky na bezpečné uchovávání a generování párů klíčů a
náhodných čísel pro CA a koncové subjekty. Tyto požadavky jsou definovány pro
kryptografické moduly a popsány v následujících pododdílech.
6.1.5.1. Úroveň kořenové CA, podřízené CA a TLM
322) Kryptografický modul se použije pro:
• generování, používání, správu a ukládání soukromých klíčů,
• generování a používání náhodných čísel (posouzení funkce generování
náhodných čísel je součástí hodnocení a certifikace bezpečnosti),
• zálohování soukromých klíčů v souladu s oddílem 6.1.6,
• mazání soukromých klíčů.
Kryptografický modul musí být certifikován jedním z těchto profilů ochrany
(PP) s úrovní záruky EAL-4 nebo vyšší:
CS 64 CS
• PP pro HSM:
• CEN EN 419 221-2: Profily ochrany pro TSP kryptografické
moduly – Část 2: Kryptografický modul pro podepisování operací
CSP se zálohou,
• CEN EN 419 221-4: Profily ochrany pro TSP kryptografické
moduly – Část 4: Kryptografický modul pro podepisování operací
CSP bez zálohy,
• CEN EN 419 221-5: Profily ochrany pro TSP kryptografické
moduly – Část 5: Kryptografický modul pro důvěryhodné služby,
• PP pro čipové karty:
• CEN EN 419 211-2: Profil ochrany pro zařízení vytvářející
bezpečný podpis – Část 2: Přístroje na generování klíče,
• CEN EN 419 211-3: Profil ochrany pro zařízení vytvářející
bezpečný podpis – Část 3: Přístroje na přenos klíče.
Manuální přístup ke kryptografickým modulům vyžaduje dvoufaktorovou
autentizaci od správce. Dále vyžaduje zapojení dvou autorizovaných osob.
Implementace kryptografického modulu zajistí, aby klíče nebyly přístupné
mimo kryptografický modul. Kryptografický modul musí zahrnovat
mechanismus kontroly přístupu, aby se zabránilo neoprávněnému používání
soukromých klíčů.
6.1.5.2. Koncový subjekt
323) Kryptografický modul pro koncové subjekty se použije pro:
• generování, používání, správu a ukládání soukromých klíčů,
• generování a používání náhodných čísel (posouzení funkce generování
náhodných čísel je součástí hodnocení a certifikace bezpečnosti),
• bezpečné mazání soukromého klíče.
324) Kryptografický modul je chráněn proti neoprávněnému odstranění, nahrazení a
změnám. Všechny profily ochrany a související dokumenty použitelné pro
certifikaci bezpečnosti stanic C-ITS musí být vyhodnoceny, validovány a
certifikovány v souladu s normou ISO 15408 za použití dohody o vzájemném
uznávání certifikátů hodnocení bezpečnosti informačních technologií skupiny
vyšších úředníků pro bezpečnost informačních systémů (SOG-IS) nebo
rovnocenného evropského systému certifikace kybernetické bezpečnosti v
rámci příslušného evropského rámce kybernetické bezpečnosti.
325) Jelikož je důležité zachovat co nejvyšší možnou úroveň bezpečnosti, vydává
bezpečnostní certifikáty kryptografickým modulům v rámci certifikace podle
společných kritérií (ISO 15408) subjekt posuzování shody uznaný řídicím
výborem v rámci dohody SOG-IS, nebo subjekt posuzování shody
akreditovaný vnitrostátním orgánem členského státu pro certifikaci
kybernetické bezpečnosti. Tento subjekt posuzování shody zajišťuje alespoň
rovnocenné podmínky hodnocení bezpečnosti jako podmínky podle dohody
SOG-IS o vzájemném uznávání.
CS 65 CS
Pozn.: Spojení mezi kryptografickým modulem a stanicí C-ITS musí být
chráněno.
6.1.6. Zálohování soukromých klíčů
326) Generování, ukládání a využívání záloh soukromých klíčů musí splňovat
požadavky alespoň na úrovni bezpečnosti, která je vyžadována pro původní
klíče.
327) Zálohy soukromých klíčů musí provádět kořenové CA, EA a AA.
328) Zálohy soukromých klíčů se neprovádí pro EC a AT.
6.1.7. Likvidace soukromých klíčů
329) Kořenové CA, EA, AA a mobilní a pevné stanice C-ITS zlikvidují svůj
soukromý klíč a všechny odpovídající zálohy, pokud byl generován a úspěšně
instalován nový pár klíčů a odpovídající certifikát a pokud čas překrytí (pokud
existuje – pouze CA) již uplynul. Soukromý klíč se likviduje pomocí
mechanismu, který nabízí kryptografický modul použitý pro uchovávání klíčů,
nebo jak je popsáno v odpovídajícím PP uvedeném v oddíle 6.1.5.2.
6.2. Aktivační údaje
330) Aktivační údaje odkazují na autentizační faktory, které jsou požadovány pro
provoz kryptografických modulů, aby se zabránilo neoprávněnému přístupu.
Použití aktivačních údajů pro kryptografické zařízení CA vyžaduje akci dvou
autorizovaných osob.
6.3. Počítačové bezpečnostní kontroly
331) Počítačové bezpečnostní kontroly CA jsou navrženy v souladu s vysokou
úrovní bezpečnosti a dodržují požadavky normy ISO/IEC 27002.
6.4. Technické kontroly životního cyklu
332) Technické kontroly CA zahrnují celý životní cyklus CA. Patří sem zejména
požadavky oddílu 6.1.4.3 („Kryptoagilita“).
6.5. Bezpečnostní kontroly sítě
333) Sítě CA (kořenových CA, EA a AA) musí být odolné proti útokům v souladu s
požadavky a prováděcími pokyny norem ISO/IEC 27001 a ISO/IEC 27002.
334) Dostupnost sítí CA musí být navržena s ohledem na odhadovaný provoz.
7. PROFILY CERTIFIKÁTŮ, CRL A CTL
7.1. Profil certifikátu
335) Profily certifikátů definované v [5] se použijí pro certifikáty TLM, kořenové
certifikáty, certifikáty EA, certifikáty AA, AT a EC. Vnitrostátní vládní EA
mohou pro EC použít i jiné profily certifikátů.
336) Certifikáty kořenové CA, EA a AA uvedou povolení, pro která jsou tyto
certifikační autority (kořenové CA, EA a AA) oprávněny vydávat certifikáty.
337) Na základě [5]:
• každá kořenová CA použije k vydávání CRL svůj vlastní podpisový
soukromý klíč,
CS 66 CS
• TLM použije k vydání ECTL svůj vlastní podpisový soukromý klíč.
7.2. Platnost certifikátu
338) Všechny profily certifikátu C-ITS musí zahrnovat datum vydání a datum
ukončení platnosti, jež představují dobu platnosti certifikátu. Certifikáty budou
na každé úrovni PKI generovány s dostatečným předstihem před uplynutím
platnosti.
339) Doba platnosti certifikátů CA a EC zahrnuje dobu překrytí. Certifikáty TLM a
certifikáty kořenové CA se vydávají a vkládají do ECTL nejvýše tři měsíce a
nejméně jeden měsíc před začátkem platnosti certifikátu na základě doby
zahájení uvedené v certifikátu. Tato fáze zavádění je nutná pro bezpečnou
distribuci certifikátů všem odpovídajícím spoléhajícím se stranám v souladu
s oddílem 2.2. Tím je zajištěno, že od začátku doby překrývání jsou všechny
spoléhající se strany již schopny ověřit zprávy vydané s novým certifikátem.
340) Na začátku období, ve kterém se překrývají, se vydávají následné certifikáty
CA, ES a AT (v příslušných případech), které jsou distribuovány spoléhajícím
se stranám a které tyto strany instalují. Během doby překrývání se aktuální
certifikát použije pouze pro ověření.
341) Vzhledem k tomu, že doba platnosti uvedená v tabulce 8 nesmí přesáhnout
dobu platnosti nadřízeného certifikátu, platí tato omezení:
• maximumvalidity(Root CA) = privatekeyusage(Root CA) +
maximumvalidity(EA,AA),
• maximumvalidity(EA) = privatekeyusage(EA) + maximumvalidity(EC),
• maximumvalidity(AA) = privatekeyusage(AA) + preloadingperiod(AT).
342) Platnost spojovacích certifikátů (kořenových a TLM) začíná použitím
odpovídajícího soukromého klíče a končí maximální dobou platnosti kořenové
CA nebo TLM.
343) Tabulka 8 uvádí maximální dobu platnosti certifikátů CA C-ITS (doby
platnosti AT, viz oddíl 7.2.1).
Subjekt Max. doba použití soukromého
klíče
Maximální doba
platnosti
Kořenová CA 3 roky 8 let
EA 2 roky 5 let
AA 4 roky 5 let
EC 3 roky 3 roky
TLM 3 roky 4 roky
Tabulka 8: Doby platnosti certifikátů v C-ITS modelu služeb vytvářejících důvěru
7.2.1. Certifikáty pseudonymu
344) V tomto kontextu se pseudonymy implementují pomocí AT. Proto tento oddíl
odkazuje na AT, nikoli na pseudonymy.
CS 67 CS
345) Požadavky stanovené v tomto oddíle se vztahují pouze na AT mobilních
stanicích C-ITS, které zasílají zprávy CAM a DENM, pro které platí riziko
soukromí lokality. Pro AT neplatí žádné zvláštní požadavky na certifikáty AT
pro pevné stanice C-ITS a mobilní stanice C-ITS používané pro zvláštní
funkce, kde soukromí lokality není použitelné (např. u vozidel s označením
„pohotovost“ a „policie“).
346) Použijí se tyto definice:
• „doba platnosti AT“ – doba, po kterou je AT platné, tj. doba mezi
počátečním datem AT a datem skončení jeho platnosti,
• „fáze nahrávání AT“ – nahrávání (preload) je možnost, aby stanice C-ITS
získaly AT před tím, než začíná jeho doba platnosti. Fáze nahrávání je
maximální povolenou dobou od žádosti o AT do nejzazšího konce
platnosti jakéhokoli vyžádaného AT,
• „doba používání AT“ – doba, během které se AT používá k podpisu
zpráv CAM/DENM,
• „maximální počet paralelních AT“ – počet AT, z nichž si stanice C-ITS
může kdykoli vybrat, když podepisuje zprávu CAM/DENM, tj. počet
různých AT vydaných jedné stanici C-ITS, které jsou platné současně.
347) Platí tyto požadavky:
• fáze nahrávání AT nesmí překročit tři měsíce,
• doba platnosti AT nesmí překročit jeden týden,
• maximální počet paralelních AT nesmí na stanici C-ITS překročit 100,
• doba používání AT závisí na strategii změny AT a na době, kdy je
vozidlo v provozu, ale je omezeno maximálním počtem paralelních AT a
dobou platnosti. Konkrétně průměrná doba používání jedné stanice C-
ITS je alespoň provozní doba vozidla v jednom období platnosti
vydělená maximálním počtem paralelních AT.
7.2.2. Autorizační potvrzení pro pevné stanice C-ITS
348) Použijí se definice uvedené v oddíle 7.2.1 a tyto požadavky:
• fáze nahrávání AT nesmí překročit tři měsíce,
• maximální počet paralelních AT nesmí překročit dvě na jednu stanici C-
ITS.
7.3. Odvolání certifikátů
7.3.1. Odvolání certifikátů CA, EA a AA
Certifikáty kořenové CA, EA a AA jsou odvolatelné. Odvolané certifikáty
kořenových CA, EA a AA se zveřejňují v CRL co nejdříve a bez zbytečného
odkladu. Tento CRL podepisuje odpovídající kořenový CA a používá profil popsaný
v oddíle 7.4. Pro odvolání certifikátů kořenových CA vydá odpovídající kořenová
CA CRL, který jej obsahuje. Kromě toho se v případě bezpečnostního ohrožení
použije oddíl 5.7.3. TLM musí navíc odstranit odvolané kořenové CA ze seznamu
důvěryhodných subjektů a vydat nový seznam důvěryhodných subjektů. Certifikáty s
prošlým datem platnosti se odstraní z příslušného CRL a seznamu důvěryhodných
subjektů.
CS 68 CS
349) Certifikáty se odvolají, pokud:
• kořenové CA mají důvod domnívat se nebo mít silné podezření, že
příslušný soukromý klíč byl ohrožen,
• kořenovým CA bylo oznámeno, že smlouva s účastníkem byla ukončena,
• informace v certifikátu (jako název a spojení mezi CA a subjektem) jsou
nesprávné nebo se změnily,
• dojde k bezpečnostnímu incidentu, který má vliv na majitele certifikátu,
• výsledek auditu (viz oddíl 8) je negativní.
350) Účastník neprodleně uvědomí CA o známém nebo domnělém ohrožení svého
soukromého klíče. Musí být zaručeno, že pouze autentizované žádosti budou
mít za následek odvolání certifikátů.
7.3.2. Odvolání oprávnění k registraci
351) Odvolání EC může být iniciováno účastníkem stanice C-ITS (tok 34) a provádí
se formou vnitřní černé listiny v databázi odvolání s časovým razítkem, kterou
generuje a udržuje každá EA. Černá listina není nikdy zveřejněna a je důvěrná
a použije ji pouze příslušná EA, aby ověřil platnost odpovídajících EC v
souvislosti s žádostmi o AT a nové EC.
7.3.3. Odvolání potvrzení o autorizaci
352) Jelikož AT nejsou příslušnými CA odvolávána, mají krátkou životnost a
nemohou být vydávána příliš dlouho před tím, než se stanou platnými.
Přípustné hodnoty parametrů životního cyklu certifikátu jsou stanoveny
v oddíle 7.2.
7.4. Seznam odvolaných certifikátů
353) Formát a obsah CRL vydaného kořenovou CA jsou stanoveny v [1].
7.5. Evropský seznam důvěryhodných certifikátů
354) Formát a obsah ECTL vydaného TLM jsou stanoveny v [1].
8. AUDIT SOULADU A DALŠÍ POSOUZENÍ
8.1. Témata auditu a základ auditu
355) Účelem auditu souladu je ověřit, že TLM, kořenové CA, EA a AA fungují v
souladu s CP. TLM, kořenové CA, EA a AA vyberou nezávisle jednajícího a
akreditovaného auditora PKI k provedení auditu jejich CPS. Audit je
kombinován s posouzením podle norem ISO/IEC 27001 a ISO/IEC 27002.
356) Audit souladu zadává kořenová CA (tok 13) pro sebe a podřízená EA/AA pro
podřízenou CA.
357) Audit souladu pro TLM zadává CPA (tok 38).
358) Akreditovaný auditor PKI musí v případě, že je o to požádán, provést audit
souladu na jedné z těchto úrovní:
1) soulad CPS TLM, kořenové CA, EA nebo AA s touto CP,
2) soulad plánované praxe TLM, kořenové CA, EA nebo AA s CPS před
uvedením do provozu,
CS 69 CS
3) soulad praxe a provozních činností TLM, kořenové CA, EA nebo AA s
CPS během provozu.
359) Audit musí pokrývat všechny požadavky této CP, které musí splňovat TLM,
kořenové CA, EA a AA, u nichž má být proveden audit. Zahrnuje rovněž
fungování CA v PKI C-ITS, včetně všech procesů uvedených v její CPS,
prostor a odpovědných osob.
360) Akreditovaný auditor PKI poskytne podrobnou zprávu o auditu dle potřeby
kořenové CA (tok 36), EA, AA nebo CPA (tok 16 a 40).
8.2. Četnost auditů
361) Kořenová CA, TLM, EA nebo AA zadává audit svého souladu u nezávislého a
akreditovaného auditora PKI v těchto případech:
• při svém prvním zřízení (úrovně souladu 1 a 2),
• při každé změně CP. CPA definuje obsah změny CP a časový plán
zavedení a odpovídajícím způsobem určuje potřeby auditů (včetně
nezbytné úrovně souladu),
• při každé změně své CPS (úrovně souladu 1, 2 a 3). Jelikož řídicí
subjekty kořenových CA, TLM a EA/AA rozhodují, jaké změny
implementace následují po aktualizaci jejich CPS, objednají audit
souladu před provedením těchto změn. V případech pouze drobných
změn CPS (např. změn redakčního charakteru) může řídicí subjekt zaslat
CPA řádně odůvodněnou žádost o jeho souhlas s vynecháním auditů
souladu úrovně 1, 2 nebo 3,
• pravidelně a nejméně jednou za tři roky v průběhu fungování (úroveň
souladu úrovně 3).
8.3. Totožnost/kvalifikace auditora
362) CA, která má být předmětem auditu, vybere pro audit v souladu s touto
certifikační politikou nezávisle působící a akreditovanou společnost/organizaci
(dále jen „auditní subjekt“) nebo akreditované auditory PKI1.
8.4. Vztah auditora k auditovanému subjektu
363) Akreditovaný auditor PKI musí být nezávislý na auditovaném subjektu.
8.5. Opatření přijatá v důsledku nedostatku
364) Zjistí-li zpráva o auditu, že TLM není v souladu, přikáže CPA TLM, aby
okamžitě přijal preventivní/nápravná opatření.
365) Podá-li kořenová CA s nevyhovující zprávou o auditu novou žádost, CPA
žádost zamítne a zašle odpovídající zamítnutí kořenové CA (tok 4). V takových
případech bude kořenová CA pozastavena. Musí přijmout nápravná opatření,
znovu objednat audit a podat novou žádost o schválení CPA. Kořenová CA
nesmí během pozastavení vydávat certifikáty.
366) V případech pravidelného auditu kořenové CA nebo změny CPS CA a v
závislosti na povaze nesouladu popsaného ve zprávě o auditu může CPA
1 Členové evropského akreditačního orgánu European Accreditation Body jsou uvedeni na stránkách:
http://www.european-accreditation.org/ea-members
CS 70 CS
rozhodnout o odvolání kořenové CA a toto rozhodnutí sdělit TLM (tok 2), což
povede k vymazání certifikátu kořenové CA z ECTL a vložení kořenové CA
do CRL. CPA zašle kořenové CA odpovídající zamítnutí (tok 4). Kořenová CA
musí přijmout nápravná opatření, znovu zadat úplný audit (úroveň 1 až 3) a
podat novou žádost o schválení CPA. Alternativně může CPA rozhodnout, že
kořenovou CA neodvolá, ale poskytne jí odklad, během kterého musí kořenová
CA přijmout nápravná opatření, znovu zadat audit a předložit CPA zprávu o
auditu. V tomto případě musí být provoz kořenové CA pozastaven a není
povoleno vydávat certifikáty a CRL.
367) V případě auditu EA/AA rozhodne kořenová CA, zda zprávu přijme, či nikoli.
V závislosti na výsledku auditu musí kořenová CA rozhodnout, zda zruší
certifikát EA/AA v souladu s pravidly v CPS kořenové CA. Kořenová CA
vždy zajistí soulad EA/AA s touto CP.
8.6. Sdělování výsledků
368) Kořenová CA a TLM zasílají zprávu o auditu CPA (tok 16). Kořenová CA a
TLM uloží všechny zprávy o auditu, které objednaly. CPA zašle kořenové CA
a TLM odpovídající schválení nebo zamítnutí (tok 4).
369) Kořenová CA zašle odpovídající EA/AA certifikát o shodě.
9. JINÁ USTANOVENÍ
9.1. Poplatky
370) Jednou ze zásad implementovaného EU C-ITS modelu služeb vytvářejících
důvěru je to, že kořenové CA společně plně financují pravidelné běžné náklady
na provoz CPA a centrálních prvků (TLM a CPOC) souvisejících s činnostmi
stanovenými v této CP.
371) Kořenové CA (včetně kořenové CA EU) jsou oprávněny vybírat poplatky od
svých podřízených CA.
372) Během celé své doby provozování musí mít každý účastník C-ITS modelu
služeb vytvářejících důvěru přístup na nediskriminačním základě k alespoň
jedné kořenové CA, EA a AA.
373) Každá kořenová CA má právo přenést poplatky, které platí za CPA a centrální
prvky (TLM a CPOC), na registrované účastníky C-ITS modelu služeb
vytvářejících důvěru, včetně zapsaných a schválených stanic C-ITS.
9.2. Finanční odpovědnost
374) Prvotní zřízení kořenové CA pokrývá období nejméně tří let provozu, aby se
mohla stát členem EU C-ITS modelu služeb vytvářejících důvěru. CPS
provozovatele kořenové CA musí rovněž obsahovat podrobná ustanovení
týkající se odvolání nebo uzavření kořenové CA.
375) Každá kořenová CA musí prokázat finanční životaschopnost právního
subjektu, který ji implementuje, po dobu nejméně tří let. Tento plán finanční
životaschopnosti je součástí základního souboru dokumentů k registraci a musí
být každé tři roky aktualizován a oznámen CPA.
376) Aby prokázala svou finanční udržitelnost, musí každá kořenová CA každý rok
provoznímu řediteli a CPA hlásit strukturu poplatků, které uplatňuje na EA/AA
a registrované a schválené stanice C-ITS.
CS 71 CS
377) Všechny finanční a právně odpovědné subjekty kořenové CA, EA, AA a
centrálních prvků (CPOC a TLM) C-ITS modelu služeb vytvářejících důvěru
musí přiměřeně pojistit své provozní činnosti, aby byly vykompenzovány
provozní chyby a finanční náklady na zotavení takové provozní činnosti, pokud
jeden z technických prvků selže.
9.3. Důvěrnost obchodních informací
378) Níže uvedené položky se považují za důvěrné a soukromé:
• záznamy žádostí kořenové CA, EA a AA bez ohledu na to, zda byly
schváleny nebo zamítnuty,
• zprávy o auditu kořenové CA, EA, AA a TLM,
• plány obnovy po havárii kořenové CA, EA, AA, CPOC a TLM,
• soukromé klíče prvků C-ITS modelu služeb vytvářejících důvěru (stanice
C-ITS, TLM, EA, AA, kořenové CA),
• jakékoli další informace označené jako důvěrné CPA, kořenovými CA,
EA, AA, TLM a CPOC.
9.4. Plán ochrany soukromí
379) CPS kořenových CA a EA/AA stanoví plán a požadavky týkající se zacházení
s osobními informacemi a soukromí na základě GDPR a jiných platných
právních rámců (např. vnitrostátních).
10. ODKAZY
V této příloze jsou použity následující odkazy.
[1] ETSI TS 102 941 V1.2.1, Intelligent transport systems (ITS) – security, trust
and privacy management [Inteligentní dopravní systémy (ITS) – bezpečnost,
důvěra a správa soukromí]
[2] ETSI TS 102 940 V1.3.1, Intelligent transport systems (ITS) – security, ITS
communications security architecture and security management [Inteligentní
dopravní systémy (ITS) – bezpečnost, architektura bezpečnosti komunikací ITS
a správa bezpečnosti]
[3] Certificate policy and certification practices framework [Certifikační politika a
rámec certifikačního postupu] (RFC 3647, 1999)
[4] ETSI TS 102 042 V2.4.1 Policy requirements for certification authorities
issuing public key certificates [Požadavky na politiku certifikačních autorit
vydávajících certifikáty veřejných klíčů]
[5] ETSI TS 103 097 V1.3.1, Intelligent transport systems (ITS) – security,
security header and certificate formats [Inteligentní dopravní systémy (ITS) –
bezpečnost, bezpečnostní záhlaví a formáty certifikátů]
[6] Calder, A. (2006). Information security based on ISO 27001/ISO 1779: a
management guide [Bezpečnost informací na základě normy ISO 27001/ISO
1779: průvodce pro vedení organizace]. Van Haren Publishing.
CS 72 CS
[7] ISO, I., & Std, I. E. C. (2011). ISO 27005 (2011) – Informační technologie –
Bezpečnostní techniky – Řízení rizik bezpečnosti informací. ISO.
![DIO · 2020. 6. 12. · kudqlfh ~sudy ii]h s hfkrgqp vylvop grsudyqt ]qdþhqt vwiydmtft vylvop grsudyqtkr ]qdþhqt sorfkd grþdvqpkr fkrgqtnx sorfkd ~sudy ii]h 9êãnryê v\vwpp %](https://img.pdfslide.tips/doc/110x75/5fcf55d42757336a4f4f6911/dio-2020-6-12-kudqlfh-sudy-iih-s-hfkrgqp-vylvop-grsudyqt-qdhqt-vwiydmtft.jpg)
![· kodyqt slot h þlqqrvwl vsrohþqrvwl +odyqtp ~nr ohp mh s lsudylw d uhdol]rydw v\vwpp y]g oiydftfk ... srudq qt e\ p o eêw rph]](https://img.pdfslide.tips/doc/110x75/5aeedc397f8b9a455691a870/slot-h-lqqrvwl-vsrohqrvwl-odyqtp-nr-ohp-mh-s-lsudylw-d-uhdolrydw-vvwpp-yg-oiydftfk.jpg)
![OOP 67 PÅŽepravnà tanky úēinné · 2019-03-04 · 2sdw hqt rehfqp srydk\ þ 223 & vwdwlfnê p lft v\vwpp v\vwpp vhvwiydmtft ] yodvwqtkr p lftkr wdqnx d mhkr s tsrmqêfk](https://img.pdfslide.tips/doc/110x75/5ede22dead6a402d66696da6/oop-67-pepravnf-tanky-faoeinnf-2019-03-04-2sdw-hqt-rehfqp-srydk.jpg)
![stest1.etnetera.czstest1.etnetera.cz/ad/current/content/data_files/automatizacni... · 8quhvwulfwhg .rqwdnw\ 'lvwulexwr 7l 7d]hqt goh dehfhg\ plnurv\vwpp\ y nxvryïfk pqr uvwytfk](https://img.pdfslide.tips/doc/110x75/5c173d5d09d3f263628d5b6c/-8quhvwulfwhg-rqwdnw-lvwulexwr-7l-7dhqt-goh-dehfhg-plnurvvwpp-y-nxvryifk.jpg)
![’8$3OXV 5. ’8$3OXV 57 - Kotle na uhlí a dřevo ...€¦ · ’8$3oxv )6. ’8$3oxv )67’8$3oxv5 oqhs tprwrsqŒ]ivreqtn 1dyŒyrg\ur]g orydþhdwurmfhvwqpkryhqwloxs lsrmlwwrsqŒv\vwpp](https://img.pdfslide.tips/doc/110x75/5ae0f58f7f8b9a97518de4d7/83oxv-5-83oxv-57-kotle-na-uhl-a-drevo-83oxv-6-83oxv.jpg)
![VWpPX -$ . D -$ -106K - Webnodefiles.underprotection.webnode.cz/200000052-b7652b85dc/ja-10xk_mlj... · 3rsodfkryê ]deh]shþrydft v\vwpp dg\ -$%/27521 mh xuþhq yêkudgq n prqwiål](https://img.pdfslide.tips/doc/110x75/5b84c9307f8b9a317e8c95b4/vwppx-d-106k-3rsodfkrye-dehshbrydft-vvwpp-dg-27521-mh-xubhq.jpg)
![VWpP$ - download.spstrplz.cz · Modul y 3. Technologie %êW~ VS ãQêY SUiFL]QDPHQi9 êXND ± Motiva ce & S timula ce =iNODGQtSULQFLS ± OHSãtSRUR]XP Qt SG -MCS/Endrijaitis, Lisa](https://img.pdfslide.tips/doc/110x75/5b864aeb7f8b9a162d8ca5ba/vwpp-modul-y-3-technologie-ew-vs-aqey-suiflqdphqi9-exnd-motiva.jpg)
