INDHOLDSFORTEGNELSE
1.Indledning9
1.1.Oversigt og anvendelsesområde for nærværende politik9
1.2.Definitioner og akronymer11
1.3.PKI-deltagere13
1.3.1.Indledning13
1.3.2.Myndighed for C-ITS-certifikatpolitik16
1.3.3.Tillidslisteforvalter17
1.3.4.Akkrediteret PKI-revisor17
1.3.5.C-ITS-kontaktpunkt (CPOC)17
1.3.6.Operationelle roller18
1.4.Certifikatanvendelse19
1.4.1.Relevante anvendelsesområder19
1.4.2.Ansvarsbegrænsninger19
1.5.Administration af certifikatpolitik19
1.5.1.Opdatering af CPS'er for CA'er angivet i ECTL'en19
1.5.2.CPS-godkendelsesprocedurer20
2.Offentliggørelses- og registeransvar20
2.1.Metoder til offentliggørelse af certifikatoplysninger20
2.2.Tidspunkt eller hyppighed for offentliggørelse21
2.3.Registre21
2.4.Adgangskontroller for registre22
2.5.Offentliggørelse af certifikatoplysninger22
2.5.1.Offentliggørelse af certifikatoplysninger af TLM'en22
2.5.2.Offentliggørelse af certifikatoplysninger af CA'er22
3.Identifikation og autentifikation23
3.1.Navngivning23
3.1.1.Typer af navne23
3.1.1.1.Navne på TLM'er, rod-CA'er, EA'er, AA'er23
3.1.1.2.Navne på slutentiteter23
3.1.1.3.Identifikation af certifikater23
3.1.2.Behov for, at navne har betydning24
3.1.3.Slutentitetens anonymitet og pseudonymitet24
3.1.4.Regler for fortolkning af forskellige navneformer24
3.1.5.Navnes entydighed24
3.2.Indledende identitetsvalidering24
3.2.1.Metode til at bevise besiddelse af privat nøgle24
3.2.2.Autentifikation af organisationsidentitet24
3.2.2.1.Autentifikation af rod-CA'ens organisationsidentitet24
3.2.2.2.Autentifikation af TLM-organisationsidentitet25
3.2.2.3.Autentifikation af sub-CA'ens organisationsidentitet25
3.2.2.4.Autentifikation af slutentiteters ansøgerorganisation26
3.2.3.Autentifikation af individuel entitet26
3.2.3.1.Autentifikation af individuel TLM-/CA-entitet26
3.2.3.2.Autentifikation af C-ITS-stationers abonnentidentiteter27
3.2.3.3.Autentifikation af C-ITS-stationers identiteter27
3.2.4.Ikke-verificerede abonnentoplysninger28
3.2.5.Validering af myndighed28
3.2.5.1.Validering af TLM, rod-CA, EA, AA28
3.2.5.2.Validering af C-ITS-stationsabonnenter28
3.2.5.3.Validering af C-ITS-stationer28
3.2.6.Kriterier for interoperabilitet28
3.3.Identifikation og autentifikation for genindlæste anmodninger29
3.3.1.Identifikation og autentifikation for rutinemæssige genindlæste anmodninger29
3.3.1.1.TLM-certifikater29
3.3.1.2.Rod-CA-certifikater29
3.3.1.3.Fornyelse eller genindlæsning af EA-/AA-certifikat29
3.3.1.4.Slutentiteters indskrivningsoplysninger29
3.3.1.5.Slutentiteternes autorisationsbilletter29
3.3.2.Identifikation og autentifikation for genindlæste anmodninger efter tilbagekaldelse30
3.3.2.1.CA-certifikater30
3.3.2.2.Slutentiteters indskrivningsoplysninger30
3.3.2.3.Slutentiteternes autorisationsanmodninger30
3.4.Identifikation og autentifikation for tilbagekaldelsesanmodning30
3.4.1.Rod-CA-/EA-/AA-certifikater30
3.4.2.Indskrivningsoplysninger for C-ITS-stationen30
3.4.3.Autorisationsbilletter for C-ITS-stationen30
4.Driftskrav til et certifikats livscyklus31
4.1.Certifikatansøgning31
4.1.1.Hvem kan indsende en certifikatansøgning31
4.1.1.1.Rod-CA'er31
4.1.1.2.TLM31
4.1.1.3.EA og AA31
4.1.1.4.C-ITS-station31
4.1.2.Indskrivningsproces og ansvarsområder31
4.1.2.1.Rod-CA'er32
4.1.2.2.TLM32
4.1.2.3.EA og AA33
4.1.2.4.C-ITS-station33
4.2.Behandling af en certifikatansøgning34
4.2.1.Udførelse af identifikations- og autentifikationsfunktioner34
4.2.1.1.Identifikation og autentifikation af rod-CA'er34
4.2.1.2.Identifikation og autentifikation af TLM'en34
4.2.1.3.Identifikation og autentifikation af EE og AA34
4.2.1.4.Identifikation og autentifikation af EE-abonnent34
4.2.1.5.Autorisationsbilletter35
4.2.2.Godkendelse eller afvisning af certifikatansøgninger35
4.2.2.1.Godkendelse eller afvisning af rod-CA-certifikater35
4.2.2.2.Godkendelse eller afvisning af TLM-certifikat35
4.2.2.3.Godkendelse eller afvisning af EA- og AA-certifikater35
4.2.2.4.Godkendelse eller afvisning af EC35
4.2.2.5.Godkendelse eller afvisning af AT35
4.2.3.Tid til behandling af certifikatansøgningen36
4.2.3.1.Rod-CA-certifikatansøgning36
4.2.3.2.TLM-certifikatansøgning36
4.2.3.3.EA- og AA-certifikatansøgning36
4.2.3.4.EC-ansøgning36
4.2.3.5.AT-ansøgning36
4.3.Certifikatudstedelse36
4.3.1.CA-handlinger under certifikatudstedelse36
4.3.1.1.Rod-CA-certifikatudstedelse36
4.3.1.2.TLM-certifikatudstedelse36
4.3.1.3.EA- og AA-certifikatudstedelse36
4.3.1.4.EC-udstedelse37
4.3.1.5.AT-udstedelse37
4.3.2.CA'ens meddelelse til abonnenten angående udstedelse af certifikater.37
4.4.Certifikataccept37
4.4.1.Udførelse af certifikataccept37
4.4.1.1.Rod-CA37
4.4.1.2.TLM37
4.4.1.3.EA og AA37
4.4.1.4.C-ITS-station37
4.4.2.Offentliggørelse af certifikatet38
4.4.3.Meddelelse om certifikatudstedelse38
4.5.Anvendelse af nøglepar og certifikat38
4.5.1.Anvendelse af privat nøgle og certifikat38
4.5.1.1.Anvendelse af privat nøgle og certifikat for TLM38
4.5.1.2.Anvendelse af privat nøgle og certifikat for rod-CA'er38
4.5.1.3.Anvendelse af privat nøgle og certifikat for EA'er og AA'er38
4.5.1.4.Anvendelse af privat nøgle og certifikat for slutentiteter38
4.5.2.Signaturmodtagers anvendelse af offentlig nøgle og certifikat39
4.6.Certifikatfornyelse39
4.7.Genindlæsning af certifikat39
4.7.1.Omstændigheder for genindlæsning af certifikat39
4.7.2.Hvem må anmode om genindlæsning39
4.7.2.1.Rod-CA39
4.7.2.2.TLM39
4.7.2.3.EA og AA39
4.7.2.4.C-ITS-station39
4.7.3.Genindlæsningsproces39
4.7.3.1.TLM-certifikat39
4.7.3.2.Rod-CA-certifikat40
4.7.3.3.EA- og AA-certifikater40
4.7.3.4.C-ITS-stationscertifikater41
4.8.Certifikatændring41
4.9.Tilbagekaldelse og suspendering af certifikat41
4.10.Certifikatstatustjenester41
4.10.1.Operative egenskaber41
4.10.2.Tjenesternes tilgængelighed41
4.10.3.Operative funktioner41
4.11.Abonnementets afslutning41
4.12.Nøgledeponering og -generhvervelse41
4.12.1.Abonnent41
4.12.1.1.Hvilke nøglepar kan deponeres41
4.12.1.2.Hvem kan indsende en ansøgning om generhvervelse41
4.12.1.3.Generhvervelsesproces og -ansvar41
4.12.1.4.Identifikation og autentifikation41
4.12.1.5.Godkendelse eller afvisning af generhvervelsesansøgninger41
4.12.1.6.KEA- og KRA-handlinger under generhvervelse af nøglepar41
4.12.1.7.KEA- og KRA-tilgængelighed41
4.12.2.Politik og praksis for indkapsling og generhvervelse af sessionsnøgle41
5.Facilitet, forvaltning og operativ betjening42
5.1.Fysiske kontrolforanstaltninger42
5.1.1.Stedets placering og konstruktion42
5.1.1.1.Rod-CA, CPOC, TLM42
5.1.1.2.EA/AA43
5.1.2.Fysisk adgang43
5.1.2.1.Rod-CA, CPOC, TLM43
5.1.2.2.EA/AA44
5.1.3.Strøm og klimaanlæg44
5.1.4.Vandeksponering44
5.1.5.Brandforebyggelse og -sikring45
5.1.6.Mediehåndtering45
5.1.7.Bortskaffelse af affald45
5.1.8.Ekstern sikkerhedskopiering45
5.1.8.1.Rod-CA, CPOC og TLM45
5.1.8.2.EA/AA46
5.2.Proceduremæssige kontrolforanstaltninger46
5.2.1.Betroede roller46
5.2.2.Antal nødvendige personer til hver opgave46
5.2.3.Identifikation og autentifikation for hver rolle47
5.2.4.Roller, der kræver adskillelse af opgaver47
5.3.Personalekontrolforanstaltninger48
5.3.1.Krav til kvalifikationer, erfaring og tilladelser48
5.3.2.Procedurer for baggrundskontrol48
5.3.3.Uddannelseskrav49
5.3.4.Efteruddannelseshyppighed og -krav49
5.3.5.Hyppighed og rækkefølge af jobrotation50
5.3.6.Sanktioner for uautoriserede handlinger50
5.3.7.Krav til uafhængige kontrahenter50
5.3.8.Dokumentation leveret til personale50
5.4.Revisionslogningsprocedurer50
5.4.1.Typer af hændelser, der skal registreres og rapporteres af hver CA50
5.4.2.Hyppighed af behandlingslog52
5.4.3.Opbevaringsperiode for revisionslog52
5.4.4.Beskyttelse af revisionslog52
5.4.5.Procedurer for sikkerhedskopiering af revisionslog52
5.4.6.Revisionsindsamlingssystem (internt eller eksternt)52
5.4.7.Meddelelse til hændelsesforårsagende subjekt53
5.4.8.Sårbarhedsvurdering53
5.5.Arkivering af optegnelser54
5.5.1.Typer af arkiverede optegnelser54
5.5.2.Opbevaringsperiode for arkiv55
5.5.3.Beskyttelse af arkiv55
5.5.4.Systemarkiv og -opbevaring56
5.5.5.Krav til tidsstempling af optegnelser56
5.5.6.Arkivindsamlingssystem (internt eller eksternt)56
5.5.7.Procedurer til indhentning og verificering af arkivoplysninger56
5.6.Nøgleombytning for C-ITS-tillidsmodellens elementer56
5.6.1.TLM56
5.6.2.Rod-CA56
5.6.3.EA-/AA-certifikat57
5.6.4.Revisor57
5.7.Kompromittering og katastrofeberedskab57
5.7.1.Håndtering af hændelser og kompromitteringer57
5.7.2.Korruption af computerressourcer, software og/eller data58
5.7.3.Procedurer for kompromittering af entiteters private nøgler58
5.7.4.Evne til forretningskontinuitet efter en katastrofe59
5.8.Afslutning og overførsel59
5.8.1.TLM59
5.8.2.Rod-CA59
5.8.3.EA/AA60
6.Tekniske sikkerhedskontroller60
6.1.Generering og installation af nøglepar60
6.1.1.TLM, rod-CA, EA, AA60
6.1.2.EE — mobil C-ITS-station61
6.1.3.EE — fast C-ITS-station61
6.1.4.Kryptografiske krav61
6.1.4.1.Algoritme og nøglelængde — signaturalgoritmer61
6.1.4.2.Algoritme og nøglelængde — krypteringsalgoritmer for indskrivning og autorisation63
6.1.4.3.Krypto-agilitet64
6.1.5.Sikker opbevaring af private nøgler64
6.1.5.1.Rod-CA-, sub-CA- og TLM-niveau64
6.1.5.2.Slutentitet65
6.1.6.Sikkerhedskopiering af private nøgler66
6.1.7.Destruktion af private nøgler66
6.2.Aktiveringsdata66
6.3.Computersikkerhedskontroller66
6.4.Tekniske kontroller af livscyklus66
6.5.Netværkssikkerhedskontroller66
7.Certifikatprofiler, CRL og CTL67
7.1.Certifikatprofil67
7.2.Certifikatgyldighed67
7.2.1.Pseudonymcertifikater68
7.2.2.Autorisationsbilletter til faste C-ITS-stationer69
7.3.Tilbagekaldelse af certifikater69
7.3.1.Tilbagekaldelse af CA-, EA- og AA-certifikater69
7.3.2.Tilbagekaldelse af indskrivningsoplysninger69
7.3.3.Tilbagekaldelse af autorisationsbilletter69
7.4.Liste over certifikattilbagekaldelser70
7.5.Europæisk certifikattillidsliste70
8.Overensstemmelsesrevision og andre vurderinger70
8.1.Emner dækket af revision og revisionsgrundlag70
8.2.Revisionernes hyppighed70
8.3.Revisorens identitet/kvalifikationer71
8.4.Revisorens relation til den reviderede entitet71
8.5.Foranstaltninger, der træffes som følge af mangler71
8.6.Meddelelse af resultater72
9.Andre bestemmelser72
9.1.Afgifter72
9.2.Økonomisk ansvar72
9.3.Fortrolighed og forretningsoplysninger72
9.4.Plan for privatliv73
10.Referencer73
BILAG III
1.Indledning
1.1.Oversigt og anvendelsesområde for denne politik
Denne certifikatpolitik definerer den europæiske C-ITS-tillidsmodel baseret på offentlig nøgleinfrastruktur (PKI) inden for anvendelsesområdet for det overordnede EU C-ITS-styringssystem til sikkerhedsoplysninger (EU CCMS). Den definerer krav til administration af offentlige nøglecertifikater til C-ITS-applikationer ved at udstede entiteter og slutentiteters brug af dem i Europa. På sit højeste niveau består PKI'en af et sæt rod-CA'er, der er "aktiveret" som følge af, at tillidslisteforvalteren (TLM) indsætter sine certifikater i ECTL ("European Certificate Trust List"), som udstedes og offentliggøres af den centrale entitets TLM (se afsnit 1.2 og 1.3).
Denne politik er bindende for alle entiteter, der deltager i det betroede C-ITS-system i Europa. Den hjælper i vurderingen af det niveau af tillid, der kan etableres i de modtagne oplysninger af en modtager af en meddelelse, som er bekræftet af et slutentitetscertifikat fra PKI'en. For at muliggøre vurdering af tillid til certifikaterne leveret af EU CCMS fremlægger den et sæt bindende krav til driften af den centrale entitets TLM og kompileringen og forvaltningen af ECTL'en. Følgeligt bestemmer dette dokument følgende aspekter vedrørende ECTL'en:
·identifikation og godkendelse af fuldmagtsgivere, der indhenter PKI-roller for TLM'en, herunder erklæringer om privilegierne allokeret til hver rolle
·mindstekrav for lokal sikkerhedspraksis for TLM'en, herunder fysiske, personalerelaterede og proceduremæssige kontrolforanstaltninger
·mindstekrav for teknisk sikkerhedspraksis for TLM'en herunder computersikkerhed, netværkssikkerhed og kontrolforanstaltninger for kryptografisk moduludvikling
·mindstekrav for operationel praksis for TLM'en, herunder registrering af nye rod-CA-certifikater, midlertidig eller permanent afmelding af eksisterende inkluderede rod-CA'er samt offentliggørelse og distribution af ECTL-opdateringer
·en ECTL-profil, herunder alle obligatoriske og valgfrie datafelter i ECTL'en, kryptografiske algoritmer, som skal anvendes, det nøjagtige ECTL-format samt anbefalinger til behandling af ECTL'en
·livscyklusforvaltning af ECTL-certifikatet, herunder distribution af ECTL-certifikater, aktivering, udløb og tilbagekaldelse
·forvaltning af tilbagekaldelse af tillid til rod-CA'er, hvor det er nødvendigt.
Eftersom ECTL'ens pålidelighed ikke udelukkende afhænger af selve ECTL'en, men i høj grad også af de rod-CA'er, der udgør PKI'en og deres subCA'er, angiver denne politik også et antal mindstekrav, som er obligatoriske for alle deltagende CA'er (rod-CA'er og subCA'er). Kravområderne er som følger:
·identifikation og godkendelse af fuldmagtsgivere, der indhenter PKI-roller (f.eks. sikkerhedsansvarlig, privatlivsansvarlig, sikkerhedsadministrator, registeradministrator og slutbruger), herunder en erklæring om opgaver, ansvar, forpligtelser og privilegier tilknyttet hver rolle
·nøgleforvaltning, herunder acceptable og obligatoriske algoritmer for certifikat- og dataunderskrivning, og perioder for certifikatgyldighed
·mindstekrav for lokal sikkerhedspraksis, herunder fysiske, personalerelaterede og proceduremæssige kontrolforanstaltninger
·mindstekrav for teknisk sikkerhedspraksis såsom computersikkerhed, netværkssikkerhed og kontrolforanstaltninger for kryptografisk moduludvikling
·mindstekrav for driftspraksis for CA'en, EA'en, AA'en og slutentiteterne, herunder aspekter af registrering, afmelding (dvs. tage af listen), tilbagekaldelse, nøglekompromis, afvisning af årsag, certifikatopdatering, revisionspraksis og fortrolighed af personlige oplysninger
·certifikat og CRL-profil, herunder formater, acceptable algoritmer, påkrævede og valgfrie datafelter og deres gyldige værdiintervaller samt hvordan kontrollører forventes at behandle certifikater
·regelmæssig overvågning, rapportering, varsling og gendannelse af C-ITS-tillidsmodelentiteterne for at etablere sikker drift, herunder i tilfælde af negativ opførsel.
Ud over disse mindstekrav kan de entiteter, der kører rod-CA'erne og subCA'erne, bestemme deres egne yderligere krav og fastsætte dem i de relevante certifikatpraksiserklæringer (CSP'er), såfremt de ikke modsiger kravene angivet i certifikatpolitikken. Se afsnit 1.5 angående detaljer om, hvordan CSP'er revideres og offentliggøres.
CP'en angiver også de formål, som rod-CA'erne subCA'erne og deres udstedte certifikater, må bruges til. Den angiver også de ansvarsområder, der pålægges:
·TLM'en
·hver enkelt rod-CA, hvis certifikater er angivet i ECTL'en
·rod-CA'ens subCA'er (EA og AA)
·hvert enkelt medlem eller hver enkelt organisation, som er ansvarlig for eller driver en af C-ITS-tillidsmodelentiteterne.
CP'en definerer også påkrævede forpligtelser gældende for:
·TLM'en
·hver enkelt rod-CA, hvis certifikater er angivet i ECTL'en
·hver subCA certificeret f en rod-CA
·alle slutentiteter
·hver medlemsorganisation, som er ansvarlig for eller driver en af C-ITS-tillidsmodelentiteterne.
Endelig angiver CP'en kravene til dokumentationen af begrænsninger af ansvar og forpligtelser i CPS'en for hver rod-CA, hvis certifikater er angivet i ECTL'en.
Denne CP er i overensstemmelse med den ramme for certifikatpolitik og certificeringspraksis, der er vedtaget af Internet Engineering Task Force (IETF) [3].
1.2.Definitioner og akronymer
Definitionerne i [2], [3] og [4] er gældende.
AA
|
autorisationsmyndighed (authorisation authority)
|
AT
|
autorisationsbillet (authorisation ticket)
|
CA
|
certificeringsmyndighed (certification authority)
|
CP
|
certifikatpolitik (certificate policy)
|
CPA
|
Myndighed for C-ITS-certifikatpolitik (C-ITS certificate policy authority)
|
CPOC
|
C-ITS-kontaktpunkt (C-ITS point of contact)
|
CPS
|
certifikatpraksiserklæring (certificate practice statement)
|
CRL
|
liste over certifikattilbagekaldelser (certificate revocation list)
|
EA
|
indskrivningsmyndighed (enrolment authority)
|
EC
|
indskrivningsoplysning (enrolment credential)
|
ECIES
|
krypteringsordning med integreret ellipsekurve (elliptic curve integrated encryption scheme)
|
EE
|
slutentitet (dvs. C-ITS-station) (end-entity (i.e. C-ITS station))
|
ECTL
|
europæisk certifikattillidsliste (European certificate trust list)
|
EU CCMS
|
EU C-ITS-styringssystem til sikkerhedsoplysninger (EU C-ITS security credential management system)
|
GDPR
|
generel forordning om databeskyttelse (General Data Protection Regulation)
|
HSM
|
hardwaresikkerhedsmodul (Hardware security module)
|
PKI
|
offentlig nøgleinfrastruktur (public key infrastructure?
|
RA
|
registreringsmyndighed (registration authority)
|
subCA
|
EA og AA
|
TLM
|
tillidslisteforvalter (trust list manager)
|
Ordliste
ansøger
|
Den naturlige person eller juridiske entitet, der ansøger om (eller søger om fornyelse af) et certifikat. Når det indledende certifikat er oprettet (initialisering), henvises der til ansøgeren som abonnenten.
Hvad angår certifikater, der er udstedt til slutentiteter, er abonnenten (certifikatansøgeren) den entitet, der kontrollerer eller betjener/opretholder den slutentitet, som certifikatet er udstedt til, selv hvis slutentiteten sender den egentlige certifikatansøgning.
|
autorisationsmyndighed
|
I dette dokument henviser betegnelsen "autorisationsmyndighed" (AA) ikke blot til AA'ens specifikke funktion, men også den juridiske og/eller operationelle entitet, der administrerer den.
|
certificeringsmyndighed
|
Rodcertificeringsmyndigheden, indskrivningsmyndigheden og autorisationsmyndigheden henvises kollektivt til som certificeringsmyndigheden (CA).
|
C-ITS-tillidsmodel
|
C-ITS-tillidsmodellen er ansvarlig for at etablere en tillidsrelation mellem C-ITS-stationer. Den implementeres ved brug af en PKI bestående af rod-CA'er, CPOC'et, TLM'en, EA'erne, AA'erne og et sikkert netværk.
|
krypto-agilitet
|
C-ITS-tillidsmodelentiteternes evne til at tilpasse CP'en til skiftende miljøer eller til nye fremtidige krav, f.eks. ved at ændre kryptografiske algoritmer og nøglelængde over tid
|
kryptografisk modul
|
Et sikkert, hardwarebaseret element, hvori nøgler genereres og/eller opbevares, tilfældige tal generes, og data underskrives eller krypteres.
|
indskrivningsmyndighed
|
I dette dokument henviser betegnelsen "indskrivningsmyndighed" (EA) ikke blot til EA'ens specifikke funktion, men også den juridiske og/eller operationelle entitet, der administrerer den.
|
PKI-deltagere
|
Entiteter i C-ITS-tillidsmodellen, dvs. TLM'en, rod-CA'er, EA'er, AA'er og C-ITS-stationer.
|
genindlæsning
|
|
register
|
Det register, der benyttes til lagring af certifikaterne og oplysninger om certifikater tilvejebragt af C-ITS-tillidsmodellens entiteter, som defineret i afsnit 2.3.
|
rodcertificeringsmyndighed
|
I dette dokument henviser betegnelsen "rodcertificeringsmyndighed" (CA) ikke blot til CA'ens specifikke funktion, men også den juridiske og/eller operationelle entitet, der administrerer den.
|
subjekt
|
Den naturlige person, anordning, system, enhed eller juridiske entitet, der er identificeret i et certifikat som subjektet, dvs. enten abonnenten eller en anordning under abonnentens kontrol og betjening.
|
abonnent
|
En naturlig person eller juridisk entitet, som certifikatet er udstedt til, og som er juridisk bundet af en abonnent eller vilkår i en brugeraftale.
|
abonnentaftale
|
En aftale mellem CA'en og ansøgeren/abonnenten, som specificerer parternes rettigheder og ansvarsområder.
|
1.3.PKI-deltagere
1.3.1.Indledning
PKI-deltagere spiller en rolle i PKI'en defineret af nærværende politik. Medmindre det er udtrykkeligt forbudt, kan en deltager påtage sig flere roller på samme tid. Det kan være forbudt for deltageren at påtage sig specifikke roller på samme tid for at undgå interessekonflikter eller for at sikre adskillelse af opgaverne.
Deltagerne kan også uddelegere dele af deres rolle til andre entiteter som en del af en servicekontrakt. Når oplysninger om tilbagekaldelsesstatus leveres via CRL'er, er CA'en f.eks. også CRL-udstederen, men den kan uddelegere ansvaret for at udstede CRL'erne til en anden entitet.
PKI-roller består af:
·autoritative roller, dvs. hver rolle instantieres entydigt
·operationelle roller, dvs. roller, som kan instantieres i en eller flere entiteter.
En rod-CA kan f.eks. implementeres af en kommerciel entitet, en fælles interessegruppe, en national organisation og/eller en europæisk organisation.
Figur 1 viser C-ITS-tillidsmodellens opbygning baseret på [2]. Denne opbygning beskrives kort her, men de vigtigste elementer beskrives i yderligere detaljer i afsnit 1.3.2 til 1.3.6.
CPA'en udpeger TLM'en, som derfor er en betroet entitet for alle PKI-deltagere. CPA'en godkender rod-CA'ens drift og bekræfter, at TLM'en kan have tillid til rod-CA('erne). TLM'en udsteder den ECTL, som giver alle PKI-deltagere tillid til de godkendte rod-CA'er. Rod-CA'erne udsteder certifikater til EA og AA, hvorved der gives tillid til deres drift. EA'en udsteder indskrivningscertifikater til udsendende og transmitterende C-ITS-stationer (som slutentiteter), hvorved der gives tillid til deres drift. AA'en udsteder AT'er til C-ITS-stationerne på baggrund af tillid til EA'en.
Den modtagende og transmitterende C-ITS-station (som transmitterende part) har tillid til andre C-ITS-stationer, eftersom AT'erne udstedes af en AA, som har tillid fra en rod-CA, som har tillid fra TLM'en og CPA'en.
Bemærk, at figur 1 kun beskriver rod-CA-niveauet i C-ITS-tillidsmodellen. Detaljerne om de nedre lag fremgår af de efterfølgende afsnit i denne CP eller CPS'en for de specifikke rod-CA'er.
Figur 2 giver et overblik over informationsstrømmene mellem PKI-deltagere. De grønne prikker angiver strømme, som kræver maskine-til-maskine-kommunikation. Informationsstrømmene i rødt har definerede sikkerhedskrav.
C-ITS-tillidsmodellen er baseret på en opbygning bestående af flere rod-CA'er, hvor rod-CA-certifikaterne transmitteres periodisk (som beskrevet nedenfor) til det centrale kontaktpunkt (CPOC) via en sikker protokol (f.eks. linkcertifikater) defineret af CPOC'et.
En rod-CA kan betjenes af en statslig eller privat organisation. C-ITS-tillidsmodellens opbygning indeholder mindst én rod-CA (EU-rod-CA'en med samme niveau som de andre rod-CA'er). EU-rod-CA'en uddelegeres af alle entiteter, der deltager i C-ITS-tillidsmodellen, og som ikke ønsker at opsætte deres egen rod-CA. CPOC'et transmitterer de modtagne rod-CA-certifikater til TML'en, som er ansvarlig for at indsamle og underskrive listen over rod-CA-certifikater og at sende dem tilbage til CPOC'et, hvilket vil gøre dem offentligt tilgængelige for alle (se nedenfor).
Tillidsrelationerne mellem entiteterne i C-ITS-tillidsmodellen er beskrevet i følgende figurer, tabeller og afsnit.
Figur 1: C-ITS-tillidsmodellens opbygning
Figur 2: C-ITS-tillidsmodellens informationsstrømme
Strøm-ID
|
Fra
|
Til
|
Indhold
|
Reference
|
(1).
|
CPA
|
TLM
|
godkendelse af rod-CA-ansøgning
|
8
|
(2).
|
CPA
|
TLM
|
information om tilbagekaldelse af rod-CA
|
8.5
|
(3).
|
CPA
|
rod-CA
|
CP-opdateringer
|
1.5
|
(4).
|
CPA
|
rod-CA
|
godkendelse/afvisning af rod-CA-ansøgningsformular eller CPS-anmodningsændringerne eller revisionsprocessen.
|
8.5, 8.6
|
(5).
|
TLM
|
CPA
|
meddelelse om ændring af ECTL
|
4, 5.8.1
|
(6).
|
TLM
|
CPOC
|
TLM-certifikat
|
4.4.2
|
(7).
|
TLM
|
CPOC
|
ECTL
|
4.4.2
|
(8).
|
CPOC
|
TLM
|
information om rod-CA-certifikat
|
4.3.1.1
|
(9).
|
CPOC
|
TLM
|
tilbagekaldelse af rod-CA-certifikat
|
7.3
|
(10).
|
CPOC
|
alle slutentiteter
|
TLM-certifikat
|
4.4.2
|
(11).
|
rod-CA
|
CPOC
|
information om rod-CA-certifikat
|
4.3.1.1
|
(12).
|
rod-CA
|
CPOC
|
tilbagekaldelse af rod-CA-certifikat
|
7.3
|
(13).
|
rod-CA
|
revisor
|
revisionsordre
|
8
|
(14).
|
rod-CA
|
CPA
|
rod-CA-ansøgningsformular — indledende anmodning
|
4.1.2.1
|
(15).
|
rod-CA
|
CPA
|
rod-CA-ansøgningsformular — CPS-ændringer
|
1.5.1
|
(16).
|
rod-CA
|
CPA
|
rod-CA-ansøgningsformular — revisionsrapport
|
8.6
|
(17).
|
rod-CA
|
CPA
|
rod-CA-hændelsesrapporter, herunder tilbagekaldelse af en underCA (EA, AA)
|
Bilag III, 7.3.1
|
(18).
|
rod-CA
|
EA
|
EA-certifikatsvar
|
4.2.2.3
|
(19).
|
rod-CA
|
AA
|
AA-certifikatsvar
|
4.2.2.3
|
(20).
|
rod-CA
|
Alle
|
EA-/AA-certifikat, CRL
|
4.4.2
|
(21).
|
EA
|
rod-CA
|
EA-certifikatanmodning
|
4.2.2.3
|
(22).
|
EA
|
C-ITS-station
|
svar til indskrivningsoplysninger
|
4.3.1.4
|
(23).
|
EA
|
AA
|
autorisationssvar
|
4.2.2.5
|
(24).
|
AA
|
rod-CA
|
AA-certifikatanmodning
|
4.2.2.3
|
(25).
|
AA
|
EA
|
autorisationsanmodning
|
4.2.2.5
|
(26).
|
AA
|
C-ITS-station
|
autorisationsbilletsvar
|
4.3.1.5
|
(27).
|
EA
|
rod-CA
|
indsendelse af anmodning
|
4.1.2.3
|
(28).
|
AA
|
rod-CA
|
indsendelse af anmodning
|
4.1.2.3
|
(29).
|
rod-CA
|
EA
|
svar
|
4.12 og 4.2.1
|
(30).
|
rod-CA
|
AA
|
svar
|
4.12 og 4.2.1
|
(31).
|
C-ITS-station
|
EA
|
anmodning om indskrivningsoplysninger
|
4.2.2.4
|
(32).
|
C-ITS-station
|
AA
|
anmodning om autorisationsbillet
|
4.2.2.5
|
(33).
|
producent/operatør
|
EA
|
registrering
|
4.2.1.4
|
(34).
|
producent/operatør
|
EA
|
deaktivering
|
7.3
|
(35).
|
EA
|
producent/operatør
|
svar
|
4.2.1.4
|
(36).
|
revisor
|
rod-CA
|
rapport
|
8.1
|
(37).
|
alle
|
CPA
|
CP-ændringsanmodninger
|
1.5
|
(38).
|
TLM
|
CPA
|
ansøgningsformular
|
4.1.2.2
|
(39).
|
CPA
|
TLM
|
godkendelse/afvisning
|
4.1.2.2
|
(40).
|
TLM
|
CPA
|
revisionsrapport
|
4.1.2.2
|
Tabel 1:
Detaljeret beskrivelse af informationsstrømme i C-ITS-tillidsmodellen
1.3.2.Myndighed for C-ITS-certifikatpolitik
(1)Myndigheden for C-ITS-certifikatpolitikken (CPA) består af repræsentanterne for offentlige og private parter (f.eks. medlemsstater, køretøjsproducenter osv.), som deltager i C-ITS-tillidsmodellen. Den er ansvarlig for to underroller:
(1)forvaltning af certifikatpolitik, herunder:
·godkendelse af den nuværende CP og fremtidige CP-ændringsanmodninger
·beslutninger angående gennemgangen af CP-ændringsanmodninger og -anbefalinger indsendt af andre PKI-deltagere eller entiteter
·beslutninger angående udgivelsen af nye CP-versioner
(2)PKI-autorisationsforvaltning, herunder:
·definition af, beslutninger angående og offentliggørelse af CPS-godkendelsen og CA-revisionsprocedurerne (kollektivt kaldet "CA-godkendelsesprocedurer")
·autorisering af CPOC'et til at operere og rapportere regelmæssigt
·autorisering af TLM'en til at operere og rapportere regelmæssigt
·godkendelse af rod-CA'ens CPS, hvis den er i overensstemmelse med den fælles og gyldige CP
·kontrol af revisionsrapporterne fra den akkrediterede PKI-revisor for alle rod-CA'er
·meddelelse til TLM'en om listen af godkendte eller ikkegodkendte rod-CA'er og deres certifikater på baggrund af de modtagne godkendelsesrapporter af rod-CA'erne og regelmæssige driftsrapporter.
(2)CPA'ens bemyndigede repræsentant har ansvaret for at bekræfte TLM'ens bemyndigede repræsentant og godkende TLM'ens ansøgningsformular for indskrivningsprocessen. CPA'en har ansvaret for at autorisere TLM'en til at operere som nævnt i dette afsnit.
1.3.3.Tillidslisteforvalter
(3)TLM'en er en enkelt entitet, som er udpeget af CPA'en.
(4)TLM'en har ansvaret for:
·driften af ECTL'en i overensstemmelse med den fælles, gyldige CP og regelmæssig aktivitetsrapportering til CPA'en for den overordnede sikre drift af CITS-tillidsmodellen.
·at modtage rod-CA-certifikater fra CPOC'et
·inklusive/eksklusive rod-CA-certifikater i ECTL'en ved meddelelse fra CPA'en
·underskrivning af ECTL'en
·regelmæssig og rettidig overførsel af ECTL'en til CPOC'et.
1.3.4.Akkrediteret PKI-revisor
(5)Den akkrediterede PKI-revisor har ansvaret for:
·at foretage og organisere revisioner af rod-CA'er, TLM'er og subCA'er
·at distribuere revisionsrapporten (fra en indledende eller periodisk revision) til CPA'en i overensstemmelse med kravene i afsnit 8 nedenfor. Revisionsrapporten skal indeholde anbefalinger fra den akkrediterede PKI-revisor
·underrette den entitet, der administrerer rod-CA'en, om den gennemførte eller ikke gennemførte udførelse af en indledende eller periodisk revision af subCA'erne
·vurdere CPS'ernes overensstemmelse med denne CP.
1.3.5.C-ITS-kontaktpunkt (CPOC)
(6)CPOC'et er en enkelt entitet, som er udpeget af CPA'en. CPA'ens bemyndigede repræsentant har ansvaret for at bekræfte CPOC'ets bemyndigede repræsentant og godkende CPOC'ets ansøgningsformular for indskrivningsprocessen. CPA'en har ansvaret for at autorisere CPOC'et til at operere som beskrevet i dette afsnit.
(7)CPOC'et har ansvaret for at:
·etablere og bidrage til den sikre kommunikationsudveksling mellem alle entiteter i C-ITS-tillidsmodellen på en effektiv og hurtig måde
·gennemgå proceduremæssige ændringsanmodninger og -anbefalinger indsendt af andre tillidsmodeldeltagere (f.eks. rod-CA'er)
·overføre rod-CA-certifikater til TLM'en
·offentliggøre det fælles tillidsanker (TLM'ens nuværende offentlige nøgle og linkcertifikat)
·offentliggøre ECTL'en.
De fuldstændige detaljer om ECTL'en kan findes i afsnit 7.
1.3.6.Operationelle roller
(8)Følgende entiteter defineret i [2] spiller en operationel rolle som defineret i RFC 3647:
Funktionelt element
|
PKI-rolle ([3] og [4] )
|
Detaljeret rolle ([2])
|
rodcertificeringsmyndighed
|
CA/RA (registreringsmyndighed)
|
Giver EA og AA bevis for, at den må udstede EC'er og AT'er
|
indskrivningsmyndighed
|
abonnent til rod-CA/subjekt i EA-certifikat
CA/RA
|
Bekræfter en C-ITS-station og giver den adgang til ITS-kommunikationen
|
autorisationsmyndighed
|
abonnent til rod-CA/subjekt i AA-certifikat
CA/RA
|
Giver en C-ITS-station autoritativt bevis på, at den må bruge specifikke ITS-tjenester
|
udsendende C-ITS-station
|
subjekt i slutentitets (EE) certifikat (EC)
|
Indhenter rettigheder fra EA for at få adgang til ITS-kommunikation
Forhandler rettigheder fra AA til at påkalde sig ITS-tjenester
Sender enkelthop og videresendte transmissionsmeddelelser
|
transmitterende (videresendende) C-ITS-station
|
transmitterende part/subjekt af EE-certifikat
|
Modtager udsendte meddelelser fra udsendende C-ITS-station og videresender dem til modtagende ITS-station, hvis det er nødvendigt
|
modtagende C-ITS-station
|
transmitterende part
|
Modtager udsendte meddelelser fra udsendende eller transmitterende C-ITS-station
|
producent
|
abonnent til EA
|
Installerer nødvendige oplysninger til sikkerhedsforvaltning i C-ITS-station ved produktion
|
operatør
|
abonnent til EA/AA
|
Installerer og opdaterer nødvendige oplysninger til sikkerhedsforvaltning i C-ITS-station under drift
|
Tabel 2: Operationelle roller
Bemærk: I henhold til [4] benyttes der i denne CP forskellige betegnelser for den "abonnent", der indgår kontrakt med CA'en for udstedelsen af certifikater, og det "subjekt", som certifikatet er gældende for. Abonnenter er alle entiteter, som har et kontraktligt forhold til en CA. Subjekter er entiteter, som certifikaterne er gældende for. EA'er/AA'er er abonnenter og subjekter til rod-CA'en og kan anmode om EA-/AA-certifikater. CITS-stationer er subjekter og kan anmode om slutentitetscertifikater.
(9)Registreringsmyndigheder:
EA'en skal udføre rollen som registreringsmyndighed for slutentiteter. Kun en bekræftet og autoriseret abonnent kan registrere nye slutentiteter (C-ITS-stationer) i en EA. De relevante rod-CA'er skal udføre rollen som registreringsmyndigheder for EA'er og AA'er.
1.4.Certifikatanvendelse
1.4.1.Relevante anvendelsesområder
(10)Certifikater udstedt under den aktuelle CP er beregnet til at blive anvendt til at validere digitale signaturer i forbindelse med samarbejdende ITS-kommunikation i overensstemmelse med referenceopbygningen i [2].
(11)Certifikatprofilerne i [5] certifikatanvendelserne for TLM'erne, rod-CA'erne, EA'erne, AA'erne og slutentiteterne.
1.4.2.Ansvarsbegrænsninger
(12)Certifikater er ikke tiltænkt og ej heller godkendt til anvendelse under:
·omstændigheder, der støder, overtræder eller omgår gældende love, forordninger (f.eks. GDPR), dekreter eller regeringskendelser
·omstændigheder, der overtræder, omgår eller krænker andres rettigheder
·overtrædelse af denne CP eller den relevante abonnentaftale
·omstændigheder, hvor deres anvendelse kunne føre direkte til dødsfald, personskade eller alvorlig miljøskade (f.eks. via fejl i driften af nukleare anlæg, luftfartsnavigation eller -kommunikation eller våbenkontrolsystemer)
·omstændigheder, der omgår de overordnede målsætninger for større vejsikkerhed og mere effektiv vejtransport i Europa.
1.5.Administration af certifikatpolitik
1.5.1.Opdatering af CPS'er for CA'er angivet i ECTL'en
(13)Hver rod-CA angivet i ECTL'en skal offentliggøre sin egen CPS, som skal være i overensstemmelse med denne politik. En rod-CA kan tilføre yderligere krav, men skal sikre, at alle kravene i denne CP altid er opfyldt.
(14)Hver rod-CA angivet i ECTL'en skal implementere en passende ændringsproces for sit CPS-dokument. Ændringsprocessens nøgleegenskaber skal dokumenteres i den offentlige del af CPS'en.
(15)Ændringsprocessen skal sikre, at alle ændringer af denne CP analyseres nøje, og, hvis det er nødvendigt for at overholde den tilpassede CP, at CPS'en opdateres inden for tidsrammen angivet i implementeringstrinnet i CP'ens ændringsproces. Navnlig skal ændringsprocessen indeholde nødændringsprocedurer, der sikrer rettidig implementering af sikkerhedsrelevante ændringer af CP'en.
(16)Ændringsprocessen skal indeholde passende foranstaltninger til verificering af CP'ens overensstemmelse for alle ændringer af CPS'en. Alle ændringer af CPS'en skal dokumenteres tydeligt. Før en ny version af en CPS implementeres, skal dens overensstemmelse med CP'en bekræftes af en akkrediteret PKI-revisor.
(17)Rod-CA'en skal give CPA'en besked om ændringer foretaget på CPS'en med mindst følgende oplysninger:
·en nøjagtig beskrivelse af ændringen
·rationalet for ændringen
·en rapport fra den akkrediterede PKI-revisor, der bekræfter overensstemmelse med CP'en
·kontaktoplysninger for den person, der er ansvarlig for CPS'en
·planlagt tidsskala for implementering.
1.5.2.CPS-godkendelsesprocedurer
(18)Før en potentiel rod-CA starter sin drift, skal den fremvise sin CPS til en akkrediteret PKI-revisor som en del af en bestilling af en overensstemmelsesrevision (strøm 13) og til CPA'en til godkendelse (strøm 15).
(19)En rod-CA skal fremvise ændringer af sin CPS til en akkrediteret PKI-revisor som en del af en bestilling af en overensstemmelsesrevision (strøm 13) og til CPA'en til godkendelse (strøm 15), før disse ændringer træder i kraft.
(20)En EA/AA skal fremvise sin CPS eller ændringer af sin CPS til rod-CA'en. Rod-CA'en kan bestille et overensstemmelsescertifikat fra det nationale organ eller den private entitet, der har ansvaret for godkendelse af EA'en/AA'en, som defineret i afsnit 4.1.2 og 8.
(21)Den akkrediterede PKI-revisor skal vurdere CPS'en i henhold til afsnit 8.
(22)Den akkrediterede PKI-revisor skal viderebringe resultaterne af CPS-vurderingen som en del af revisionsrapporten som beskrevet i afsnit 8.1. CPS'en skal accepteres eller afvises som en del af revisionsrapportens accept, der henvises til i afsnit 8.5 og 8.6.
2.Offentliggørelses- og registeransvar
2.1.Metoder til offentliggørelse af certifikatoplysninger
(23)Certifikatoplysninger kan offentliggøres jf. afsnit 2.5:
·på en regelmæssig eller periodisk måde eller
·som svar på en anmodning fra en af de deltagende entiteter.
I hvert af tilfældene er der forskellige grader af, hvor meget en offentliggørelse haster, og derfor anvendes der tidsplaner, men entiteterne skal være klar til begge typer ordninger.
(24)Regelmæssig offentliggørelse af certifikatoplysningerne gør det muligt at fastlægge en maksimal tidsfrist for, hvornår certifikatoplysninger skal være opdaterede for alle knudepunkter i C-ITS-nettet. Hyppigheden af offentliggørelsen af alle certifikatoplysningerne fastlægges i afsnit 2.2.
(25)Efter anmodning fra de entiteter, der deltager i C-ITS-nettet, må alle deltagerne begynde at offentliggøre certifikatoplysninger når som helst og afhængigt af dens status anmode om et aktuelt sæt certifikatoplysninger for at blive et fuldstændigt betroet knudepunkt i C-ITS-nettet. Formålet med en sådan offentliggørelse er primært at opdatere entiteterne om den overordnede aktuelle status for certifikatoplysningerne i nettet og gøre dem i stand til at kommunikere på et tillidsfuldt grundlag indtil den næste regelmæssige offentliggørelse af oplysningerne.
(26)En enkelt rod-CA kan også påbegynde offentliggørelsen af certifikatoplysningerne når som helst ved at sende et opdateret sæt certifikater til alle "tilmeldte medlemmer" af C-ITS-nettet, som er regelmæssige modtagere af sådanne oplysninger. Dette støtter driften af CA'erne og gør dem i stand til at henvende sig til medlemmer mellem de regelmæssige og planlagte datoer for offentliggørelse af certifikaterne.
(27)Afsnit 2.5 beskriver mekanismen og alle procedurerne for offentliggørelse af rod-CA-certifikater og ECTL'en.
(28)CPOC'et skal offentliggøre rod-CA-certifikaterne (som inkluderet i ECTL'en og tiltænkt offentligt forbrug), TLM-certifikatet og den ECTL, som det udsteder.
(29)Rod-CA'er skal offentliggøre deres EA-/AA-certifikater og CRL'er og kunne støtte alle tre mekanismer, der henvises til her, for at offentliggøre dem til deres tilmeldte medlemmer og transmitterende parter og træffe alle nødvendige foranstaltninger for at sørge for sikker transmission som henvist til i afsnit 4.
2.2.Tidspunkt eller hyppighed for offentliggørelse
(30)Kravene til offentliggørelsesplanen for certifikaterne og CRL'erne skal fastlægges med henblik på de enkelte C-ITS-knudepunkters forskellige begrænsende faktorer med den overordnede målsætning om at drive et "betroet netværk" og offentliggøre opdateringer så hurtigt som muligt til alle involverede C-ITS-stationer.
·For den regelmæssige offentliggørelse af opdaterede certifikatoplysninger (f.eks. ændringer i ECTL- eller CRL-sammensætningen) er en maksimal periode på tre måneder nødvendig for sikker drift af C-ITS-nettet.
·Rod-CA'er skal offentliggøre deres CA-certifikater og CRL'er så hurtigt som muligt efter udstedelse.
·Rod-CA-registeret skal anvendes til offentliggørelse af CRL'en.
Derudover skal CPS'en for hver CA angive den tidsperiode, et certifikat vil blive offentliggjort inden for, efter CA'en udsteder certifikatet.
Dette afsnit specificerer kun tidspunktet eller hyppigheden for den regelmæssige offentliggørelse. Tilslutningsmetoder til opdatering af C-ITS-stationer med ECTIL'en og CRL'erne senest en uge efter deres offentliggørelse (under normale driftsbetingelser, f.eks. med mobildækning, køretøj under faktisk betjening osv.) skal implementeres i henhold til kravene i dette dokument.
2.3.Registre
(31)Kravene til opbygningen af registret til opbevaring af certifikater, samt hvilke oplysninger der leveres af C-ITS-nettets entiteter, er som følger for de enkelte entiteter:
·Generelt skal hver rod-CA anvende et register over sine egne aktuelt aktive EA-/AA-certifikatoplysninger og CRL for at offentliggøre certifikater for de andre PKI-deltagere (f.eks. en LDAPbaseret registertjeneste). Registeret for hver rod-CA skal understøtte alle påkrævede adgangskontroller (afsnit 2.4) og transmissionstider (afsnit 2.2) for hver metode til distribution af C-ITS-relaterede oplysninger
·TLM'ens register (som f.eks. opbevarer ECTL- og TLM-certifikaterne offentliggjort af CPOC), bør være baseret på en offentliggørelsesmekanisme, som er i stand til at sikre transmissionstiderne angivet i afsnit 2.2 for hver distributionsmetode.
Kravene til AA'erne er ikke defineret, men de skal understøtte de samme sikkerhedsniveauer som de andre entiteter, og disse skal erklæres i deres CPS.
2.4.Adgangskontroller for registre
(32)Kravene til adgangskontrol til registre over certifikatoplysninger skal som minimum overholde de generelle standarder for sikker datahåndtering i ISO/IEC 27001 samt kravene i afsnit 4. Derudover skal de afspejle de procesrelaterede sikkerhedsbehov, der skal fastlægges for de enkelte trin i processen for offentliggørelse af certifikatoplysninger.
·Dette inkluderer implementering af registeret for TLM-certifikater og ECTL'en i TLM'en/CPOC'et. Hver CA eller registeroperatør skal implementere adgangskontroller i forbindelse med alle C-ITS-entiteterne og de eksterne parter for mindst tre forskellige niveauer (f.eks. offentligt, begrænset til C-ITS-entiteter, rod-CA-niveau) for at forhindre uautoriserede entiteter i at føje til, ændre eller slette registerindtastninger.
·De nøjagtige adgangskontrolmekanismer for den enkelte entitet bør være en del af den respektive CPS.
·For hver rod-CA skal EA- og AA-registrene overholde de samme krav til adgangskontrolprocedurer uanset stedet eller den kontraktlige forbindelse til den tjenesteudbyder, der betjener registeret.
Som startpunkt for adgangskontrolniveauerne bør hver rod-CA eller registeroperatør sørge for mindst tre forskellige niveauer (f.eks. offentligt, begrænset til C-ITS-entiteter, rod-CA-niveau).
2.5.Offentliggørelse af certifikatoplysninger
2.5.1.Offentliggørelse af certifikatoplysninger af TLM'en
(33)TLM'en i det fælles europæiske C-ITS-tillidsdomæne skal offentliggøre følgende oplysninger via CPOC'et:
·alle aktuelt gyldige TLM-certifikater for den næste driftsperiode (aktuelt certifikat og linkcertifikat, hvis de er tilgængelige)
·oplysninger om adgangspunktet, så CPOC-registeret kan levere den underskrevne liste over rod-CA'er (ECTL)
·generelt oplysningspunkt for ECTL- og C-ITS-indførelse.
2.5.2.Offentliggørelse af certifikatoplysninger af CA'er
(34)Rod-CA'erne i det fælles europæiske C-ITS-tillidsdomæne skal offentliggøre følgende oplysninger:
·udstedte (aktuelt gyldige) rod-CA-certifikater (aktuelle og korrekt genindtastede certifikater, herunder linkcertifikat) i det register, der henvises til i afsnit 2.3
·alle gyldige EA- og AA-entiteter med deres operatør-ID og planlagte driftsperiode
·udstedte CA-certifikater i de registre, der henvises til i afsnit 2.3
·CRL'erne for alle tilbagekaldte CA-certifikater, der dækker deres underordnede EA'er og AA'er
·oplysninger vedrørende rod-CA'ens adgangspunkt til CRL- og CA-oplysningerne.
Alle certifikatoplysninger skal kategoriseres i overensstemmelse med tre fortrolighedsniveauer, og dokumenter til den generelle offentlighed skal være offentligt tilgængelige uden begrænsninger.
3.Identifikation og autentifikation
3.1.Navngivning
3.1.1.Typer af navne
3.1.1.1.Navne på TLM'er, rod-CA'er, EA'er, AA'er
(35)Navnet på TLM-certifikatet skal bestå af en enkelt subject_name-attribut med den reserverede værdi "EU_TLM".
(36)Navnet for rod-CA'er skal bestå af en enkelt subject_name-attribut med en værdi tildelt af CPA'en. Navnenes entydighed er udelukkende CPA'ens ansvar, og TLM'en skal opretholde registeret over rod-CA-navne efter meddelelse fra CPA'en (godkendelse, tilbagekaldelse/fjernelse af en rod-CA). Subjektnavne i certifikater kan højst være 32 bytes. Hver rod-CA foreslår sit navn til CPA'en i ansøgningsformularen (strøm 14). CPA'en har ansvaret for at kontrollere navnets entydighed. Hvis navnet ikke er entydigt, afvises ansøgningsformularen (strøm 4).
(37)Navnet i hvert EA-/AA-certifikat kan bestå af en enkelt subject_name-attribut med en værdi genereret af udstederen af certifikatet. Navnenes entydighed er udelukkende den udstedende rod-CA's ansvar.
(38)EA- og AA-certifikaterne kan ikke benytte et navn større end 32 bytes, fordi subject_name i certifikaterne er begrænset til 32 bytes.
(39)AT'er skal ikke indeholde et navn.
3.1.1.2.Navne på slutentiteter
(40)Hver C-ITS-station skal tildeles to entydige identifikatorer:
·et kanonisk ID, der opbevares i den indledende registrering af C-ITS-stationen under producentens ansvar. Dette skal indeholde en delstreng, der identificerer producenten eller operatøren, således at denne identifikator kan være entydig
·et subject_name, som kan være en del af C-ITS-stationens EC under EA'ens ansvar.
3.1.1.3.Identifikation af certifikater
(41)Certifikater, der følger formatet i [5], skal identificeres ved at beregne en HashedId8-værdi som defineret i [5].
3.1.2.Behov for, at navne har betydning
Ingen bestemmelse.
3.1.3.Slutentitetens anonymitet og pseudonymitet
(42)AA'en skal sikre, at en C-ITS-stations pseudonymitet fastslås, ved at give C-ITS-stationen AT'er, der ikke indeholder nogen navne eller oplysninger, som kan forbinde subjektet med dets virkelige identitet.
3.1.4.Regler for fortolkning af forskellige navneformer
Ingen bestemmelse.
3.1.5.Navnes entydighed
(43)Navnene for TLM'en, rod-CA'erne, EA'erne, AA'erne og de kanoniske ID'er for C-ITS-stationer skal være entydige.
(44)I registreringsprocessen for en given rod-CA i ECTL'en skal TLM'en sikre, at dens certifikatidentifikator (HashedId8) er entydig. I udstedelsesprocessen skal rod-CA'en sikre, at certifikatidentifikatoren (HashedId8) for hver underordnet CA er entydig.
(45)HashedId8 for en EC skal være entydig inden for den udstedende CA. HashedId8 for en AT behøver ikke at være entydig.
3.2.Indledende identitetsvalidering
3.2.1.Metode til at bevise besiddelse af privat nøgle
(46)Rod-CA'en skal bevise, at den er i retmæssig besiddelse af den private nøgle, som svarer til den offentlige nøgle i det selv-underskrevne certifikat. CPOC'et skal kontrollere dette bevis.
(47)EA'en/AA'en skal bevise, at den er i retmæssig besiddelse af den private nøgle, som skal angives i certifikatet. Rod-CA'en skal kontrollere dette bevis.
(48)Besiddelse af en ny privat nøgle (til genindlæsning) skal bevises ved underskrivning af anmodningen med den nye private nøgle (indre signatur) efterfulgt af dannelse af en ydre signatur over den underskrevne anmodning med den aktuelle, gyldige private nøgle (for at garantere anmodningens ægthed). Ansøgeren skal indsende den underskrevne certifikatanmodning til den udstedende CA via sikker kommunikation. Den udstedende CA skal verificere, at ansøgerens digitale signatur på anmodningsmeddelelsen blev oprettet ved hjælp af den private nøgle, der svarer til den offentlige nøgle, som er vedhæftet certifikatanmodningen. Rod-CA'en skal specificere, hvilken certifikatanmodning og hvilke svar den støtter, i sin CPS.
3.2.2.Autentifikation af organisationsidentitet
3.2.2.1.Autentifikation af rod-CA'ens organisationsidentitet
(49)I en ansøgningsformular til CPA'en (dvs. strøm 14) skal rod-CA'en angive identiteten på organisationen og registreringsoplysningerne, som består af:
·organisationens navn
·postadresse
·e-mailadresse
·navnet på en fysisk kontaktperson i organisationen
·telefonnummer
·digitalt fingeraftryk (dvs. SHA 256-nummertegnsværdi) på rod-CA'ens certifikat i udskrevet form
·kryptografiske oplysninger (dvs. kryptografiske algoritmer, nøglelængder) i rod-CA-certifikatet
·alle tilladelser, som rod-CA'en har lov til at anvende og videregive til sub-CA'erne.
(50)CPA'en skal kontrollere identiteten på organisationen og andre registreringsoplysninger angivet af certifikatansøgeren til indføring af et rod-CA-certifikat i ECTL'en.
(51)CPA'en skal indsamle enten direkte beviser eller en attestering fra en relevant og autoriseret kilde på identiteten (f.eks. navn) og, hvis det er relevant, specifikke karakteristika for subjekter, som et certifikat udstedes til. Beviser kan indgives i form af papirdokumentation eller elektronisk dokumentation.
(52)Subjektets identitet skal verificeres på registreringstidspunktet ved passende foranstaltninger og i overensstemmelse med den nærværende certifikatpolitik.
(53)Ved hver certifikatansøgning skal der leveres beviser på:
·det fulde navn på organisationsentiteten (privat organisation, offentlig entitet eller ikke-kommerciel entitet)
·nationalt anerkendt registrering eller andre attributter, der så vidt muligt kan anvendes til at skelne organisationsentiteten fra andre med samme navn.
Reglerne ovenfor er baseret på TS 102 042 [4]: CA'en skal sikre, at beviser på abonnentens og subjektets identifikation og nøjagtigheden af deres navne og tilknyttede data enten undersøges korrekt som en del af den definerede service eller, hvor det er relevant, konkluderes via undersøgelse af attesteringer fra relevante og autoriserede kilder, og at certifikatanmodninger er nøjagtige, autoriserede og komplette i overensstemmelse med de indsamlede beviser eller attesteringer.
3.2.2.2.Autentifikation af TLM-organisationsidentitet
(54)Den organisation, der driver TLM'en, skal levere beviser på identifikationen og nøjagtigheden af navnet og tilknyttede data for at muliggøre korrekt verificering af indledende oprettelse og genindlæsning af TLM-certifikatet.
(55)Subjektets identitet skal verificeres på tidspunktet for certifikatoprettelsen eller -genindlæsningen ved passende foranstaltninger og i overensstemmelse med den nærværende CP.
(56)Organisationsbeviser skal leveres som angivet i afsnit 3.2.2.1.
3.2.2.3.Autentifikation af sub-CA'ens organisationsidentitet
(57)Rod-CA'en skal kontrollere identiteten af organisationen og andre registreringsoplysninger leveret af certifikatansøgere for sub-CA-(EA-/AA-)certifikater.
(58)Rod-CA'en skal som minimum:
·fastslå, at organisationen eksisterer, ved at benytte sig af mindst én tredjepartsidentitetsbevistjeneste eller -database eller alternativt organisationsdokumenter udstedt af eller indgivet hos det relevante statsorgan eller anerkendte myndighed, som bekræfter organisationens eksistens
·benytte sig af post eller en lignende procedure til at kræve, at certifikatansøgeren bekræfter visse oplysninger om organisationen, at den har godkendt certifikatansøgningen, og at den person, der indsender ansøgningen på ansøgerens vegne, er godkendt til dette. Hvis et certifikat indeholder navnet på en enkeltperson som en bemyndiget repræsentant for organisationen, skal organisationen også godkende, at den har denne person ansat, og at den har godkendt ham/hende til at handle på sine vegne.
(59)Valideringsprocedurer for udstedelse af CA-certifikater skal dokumenteres i en CPS under rod-CA'en.
3.2.2.4.Autentifikation af slutentiteters ansøgerorganisation
(60)Før abonnenten af slutentiteter (producent/operatør) kan registrere sig hos en betroet EA for at aktivere sine slutentiteter til afsendelse af EC-certifikatanmodninger, skal EA'en:
·kontrollere abonnentorganisationens identitet og andre registreringsoplysninger angivet af certifikatansøgeren
·kontrollere, at C-ITS-stationstypen (dvs. det konkrete produkt baseret på mærke, model og version af C-ITS-stationen) opfylder alle vurderingskriterier for overensstemmelse.
(61)EA'en skal som minimum:
·fastslå, at organisationen eksisterer, ved at benytte sig af mindst én tredjepartsidentitetsbevistjeneste eller -database eller alternativt organisationsdokumenter udstedt af eller indgivet hos det relevante statsorgan eller anerkendte myndighed, som bekræfter organisationens eksistens
·benytte sig af post eller en lignende procedure til at kræve, at certifikatansøgeren bekræfter visse oplysninger om organisationen, at den har godkendt certifikatansøgningen, og at den person, der indsender ansøgningen på organisationens vegne, er godkendt til dette. Hvis et certifikat indeholder navnet på en enkeltperson som en bemyndiget repræsentant for organisationen, skal organisationen også godkende, at den har denne person ansat, og at den har godkendt ham/hende til at handle på sine vegne.
(62)Valideringsprocedurer for registrering af en C-ITS-station af dens abonnent skal dokumenteres i EA'ens CPS.
3.2.3.Autentifikation af individuel entitet
3.2.3.1.Autentifikation af individuel TLM-/CA-entitet
(63)Til autentifikation af en individuel entitet (fysisk person), som er identificeret i forbindelse med en juridisk person eller organisationsentitet (f.eks. abonnenten), skal der fremlægges bevis for:
·emnets fulde navn (herunder efternavn og fornavne i overensstemmelse med gældende lovgivning og national identifikationspraksis)
·fødselsdato og -sted, henvisning til et nationalt anerkendt identitetsdokument eller andre af abonnentens karakteristika, som kan anvendes til i så vid udstrækning som muligt at adskille personen fra andre med samme navn
·fuldt navn og retlig status på den tilknyttede juridiske person eller anden organisationsentitet (f.eks. abonnenten)
·alle relevante registreringsoplysninger (f.eks. virksomhedsregistrering) for den tilknyttede juridiske person eller anden organisationsentitet
·bevis på, at emnet er tilknyttet den juridiske person eller en anden organisationsentitet.
Beviser kan indgives i form af papirdokumentation eller elektronisk dokumentation.
(64)For at bekræfte sin identitet skal den bemyndigede repræsentant for en rod-CA, EA, AA eller abonnent tilvejebringe dokumentation, der beviser, at han/hun arbejder for organisationen (autorisationscertifikat). Han/hun skal også fremvise et officielt ID.
(65)For den indledende tilmeldingsproces (strøm 31/32) skal en repræsentant for EA'en/AA'en fremføre alle nødvendige oplysninger for den tilsvarende rod-CA (se afsnit 4.1.2).
(66)Personalet hos rod-CA'en skal verificere identiteten på certifikatansøgerens repræsentant samt alle tilknyttede dokumenter ved brug af kravene til "betroet personale" som angivet i afsnit 5.2.1. (Rod-CA'ens proces for validering af ansøgningsoplysninger og oprettelse af certifikatet skal udføres af "betroede personer" hos rod-CA'en under mindst dobbelt tilsyn, da disse handlinger er følsomme i henhold til betydningen i afsnit 5.2.2).
3.2.3.2.Autentifikation af C-ITS-stationers abonnentidentiteter
(67)Abonnenter repræsenteres af godkendte slutbrugere i organisationen, som er registreret hos den udstedende EA og AA. Disse slutbrugere, som er udpeget af organisationer (producenter eller operatører), skal bevise deres identitet og autenticitet, før de:
·registrerer EE'en og dens tilsvarende EA, herunder dens kanoniske offentlige nøgle, kanoniske ID (entydige identifikator) og tilladelserne i henhold til EE'en
·registrerer sig hos AA'en og sikrer sig bevis på en abonnentaftale, som kan sendes til EA'en.
3.2.3.3.Autentifikation af C-ITS-stationers identiteter
(68)EE-emner fra EC'er skal bekræfte sig selv, når de anmoder om EC'er (strøm 31), ved at bruge deres kanoniske private nøgle til den indledende autentifikation. EA'en skal kontrollere autentifikationen ved hjælp af den kanoniske offentlige nøgle, som svarer til EE'en. EE'ernes kanoniske offentlige nøgler leveres til EA'en, før den indledende anmodning udføres, af en sikker kanal mellem C-ITS-stationsproducenten eller -operatøren og EA'en (strøm 33).
(69)EE-emner fra AT'er skal bekræfte sig selv, når de anmoder om AT'er (strøm 32), ved hjælp af deres entydige private indskrivningsnøgle. AA'en skal videresende signaturen til EA'en (strøm 25) til validering; EA'en skal validere den og bekræfte resultatet for AA'en (strøm 23).
3.2.4.Ikke-verificerede abonnentoplysninger
Ingen bestemmelse.
3.2.5.Validering af myndighed
3.2.5.1.Validering af TLM, rod-CA, EA, AA
(70)Alle organisationer skal identificere mindst én repræsentant (f.eks. en sikkerhedsansvarlig), som har ansvaret for at anmode om nye certifikater og fornyelser, i CPS'en. Navngivningsreglerne i afsnit 3.2.3 er gældende.
3.2.5.2.Validering af C-ITS-stationsabonnenter
(71)Mindst én fysisk person med ansvar for registrering af C-ITS-stationer hos en EA (f.eks. sikkerhedsansvarlig) skal være kendt af og godkendt af EA'en (se afsnit 3.2.3).
3.2.5.3.Validering af C-ITS-stationer
(72)En C-ITS-stations abonnent kan registrere C-ITS-stationer hos en specifik EA (strøm 33), så længe den er bekræftet hos den pågældende EA.
Hvis C-ITS-stationen er registreret hos en EA med et entydigt kanonisk ID og en kanonisk offentlig nøgle, kan den anmode om en EC ved hjælp af en anmodning underskrevet med den kanoniske private nøgle relateret til den tidligere registrerede kanoniske offentlige nøgle.
3.2.6.Kriterier for interoperabilitet
(73)For kommunikation mellem C-ITS-stationer og EA'er (eller AA'er) skal C-ITS-stationen være i stand til at oprette sikker kommunikation med EA'erne (eller AA'erne), dvs. for at implementere autentifikations-, fortroligheds- og integritetsfunktioner som angivet i [1]. Andre protokoller kan anvendes, såfremt [1] implementeres. EA'en og AA'en skal understøtte denne sikre kommunikation.
(74)EA'en og AA'en skal understøtte certifikatanmodninger og -svar, der overholder [1], som sørger for en sikker AT-anmodnings-/svarprotokol, der understøtter ansøgerens anonymitet over for AA'en og adskillelse af pligter mellem AA'en og EA'en. Andre protokoller kan anvendes, såfremt [1] implementeres. For at forhindre videregivelse af C-ITS-stationers langvarige identitet, skal kommunikationen mellem en mobil C-ITS-station og en EA være fortrolig (f.eks. skal kommunikationsdata være krypterede hele vejen igennem).
(75)AA'en skal indsende en anmodning om autorisationsvalidering (strøm 25) for hver autorisationsanmodning, den modtager fra et EE-certifikatsubjekt. EA'en skal validere denne anmodning med hensyn til:
·statussen på EE'en ved EA'en
·signaturens gyldighed
·de anmodede ITS-applikations-ID'er (ITS-AID) og -tilladelser
·statussen på AA'ens tjenesteydelser til abonnenten.
3.3.Identifikation og autentifikation for genindlæste anmodninger
3.3.1.Identifikation og autentifikation for rutinemæssige genindlæste anmodninger
3.3.1.1.TLM-certifikater
(76)TLM'en genererer et nøglepar og to certifikater: et selv-underskrevet certifikat og et linkcertifikat som beskrevet i afsnit 7.
3.3.1.2.Rod-CA-certifikater
Ikke relevant.
3.3.1.3.Fornyelse eller genindlæsning af EA-/AA-certifikat
(77)Inden udløbet af et EA-/AA-certifikat skal EA'en/AA'en anmode om et nyt certifikat (strøm 21/strøm 24) for at bibeholde kontinuiteten i certifikatanvendelsen. EA'en/AA'en skal generere et nyt nøglepar, som skal erstatte det udløbende nøglepar, og underskrive genindlæsningsanmodningen, der indeholder den nye offentlige nøgle med den aktuelle, gyldige private nøgle ("genindlæsning"). EA'en eller AA'en genererer et nyt nøglepar og underskriver anmodningen med den nye private nøgle (indre signatur) for at bevise besiddelse af den nye private nøgle. Hele anmodningen er underskrevet (overskrevet) med den aktuelle, gyldige private nøgle (ydre signatur) for at sikre anmodningens integritet og ægthed. Hvis der anvendes et krypterings- eller dekrypteringsnøglepar, skal besiddelse af private dekrypteringsnøgler bevises (se afsnit 4.7.3.3 for en detaljeret beskrivelse af genindlæsning).
(78)Metoden til identifikation og autentifikation for rutinemæssig genindlæsning er den samme som den for den indledende udstedelse af en indledende rod-CA-certifikatvalidering som beskrevet i afsnit 3.2.2.
3.3.1.4.Slutentiteters indskrivningsoplysninger
(79)Inden udløbet af en eksisterende EC skal EE'en anmode om et nyt certifikat (strøm 31) for at bibeholde kontinuiteten i certifikatanvendelsen. EE'en skal generere et nyt nøglepar, som skal erstatte det eksisterende nøglepar og anmode om et nyt certifikat, der indeholder den nye offentlige nøgle; anmodningen skal underskrives med den aktuelle, gyldige private EC-nøgle.
(80)EE'en kan underskrive anmodningen med den nyligt oprettede private nøgle (indre signatur) for at bevise besiddelse af den nye private nøgle. Hele anmodningen underskrives (overskrives) dernæst med den aktuelle, gyldige private nøgle (ydre signatur) og krypteres til den modtagende EA som angivet i [1] for at sikre anmodningens fortrolighed, integritet og ægthed. Andre protokoller kan anvendes, såfremt [1] implementeres.
3.3.1.5.Slutentiteternes autorisationsbilletter
(81)Certifikatgenindlæsningen for AT'er er baseret på samme proces som den indledende autorisation som defineret i [1]. Andre protokoller kan anvendes, såfremt [1] implementeres.
3.3.2.Identifikation og autentifikation for genindlæste anmodninger efter tilbagekaldelse
3.3.2.1.CA-certifikater
(82)Autentifikationen af en CA-organisation for rod-CA-, EA- og AA-certifikatgenindlæsninger efter tilbagekaldelse håndteres på samme måde som den indledende udstedelse af et CA-certifikat som beskrevet i afsnit 3.2.2.
3.3.2.2.Slutentiteters indskrivningsoplysninger
(83)Autentifikationen af en EE for EC-certifikatgenindlæsninger efter tilbagekaldelse håndteres på samme måde som den indledende udstedelse af et EE-certifikat som beskrevet i afsnit 3.2.2.
3.3.2.3.Slutentiteternes autorisationsanmodninger
Ikke relevant, da AT'er ikke tilbagekaldes.
3.4.Identifikation og autentifikation for tilbagekaldelsesanmodning
3.4.1.Rod-CA-/EA-/AA-certifikater
(84)Anmodninger om sletning af et rod-CA-certifikat fra ECTL'en skal autentificeres af rod-CA'en til TLM'en (strøm 12 og 9). Anmodninger om tilbagekaldelse af et EA-/AA-certifikat skal autentificeres af selve den relevante rod-CA og sub-CA.
(85)Acceptable procedurer for autentifikation af en abonnents tilbagekaldelsesanmodninger inkluderer:
·en skriftlig og underskrevet meddelelse på virksomhedsbrevpapir fra abonnenten, hvor der anmodes om en tilbagekaldelse, med henvisning til det certifikat, der skal tilbagekaldes
·kommunikation med abonnenten, hvor der leveres rimelige tilsagn for, at den person eller organisation, som anmoder om tilbagekaldelsen, faktisk er abonnenten. Afhængigt af omstændighederne kan en sådan kommunikation inkludere en eller flere af følgende: e-mail, post eller kurértjeneste.
3.4.2.Indskrivningsoplysninger for C-ITS-stationen
(86)C-ITS-stationens abonnent kan tilbagekalde EC'en for en tidligere registreret C-ITS-station hos en EA (strøm 34). Den anmodende abonnent skal oprette en anmodning om tilbagekaldelse af en given C-ITS-station eller liste over C-ITS-stationer. EA'en skal godkende tilbagekaldelsesanmodningen, før den behandles, og bekræfte tilbagekaldelsen af C-ITS-stationerne og deres EC'er.
(87)EA'en kan tilbagekalde en C-ITS-stations EC i henhold til afsnit 7.3.
3.4.3.Autorisationsbilletter for C-ITS-stationen
(88)Eftersom AT'er ikke tilbagekaldes, skal deres gyldighed begrænses til en specifik periode. Intervallet for acceptable gyldighedsperioder i denne certifikatpolitik er specificeret i afsnit 7.
4.Driftskrav til et certifikats livscyklus
4.1.Certifikatansøgning
(89)Dette afsnit beskriver kravene til en indledende anvendelse for certifikatudstedelse.
(90)Begrebet "certifikatansøgning" henviser til følgende processer:
·registrering og opsætning af et tillidsforhold mellem TLM'en og CPA'en
·registrering og opsætning af et tillidsforhold mellem rod-CA'en og CPA'en og TLM'en, herunder indføring af det første rod-CA-certifikat i ECTL'en
·registrering og opsætning af et tillidsforhold mellem EA'en/AA'en og rod-CA'en, herunder udstedelse af et nyt EA-/AA-certifikat
·registrering af C-ITS-stationen hos EA'en af producenten/operatøren
·C-ITS-stationens anmodning om EC/AT.
4.1.1.Hvem kan indsende en certifikatansøgning
4.1.1.1.Rod-CA'er
(91)Rod-CA'er genererer sine egne nøglepar og udsteder sit rodcertifikat selv. En rod-CA kan indsende en certifikatansøgning igennem sin udpegede repræsentant (strøm 14).
4.1.1.2.TLM
(92)TLM'en genererer sine egne nøglepar og udsteder sit certifikat selv. Den indledende oprettelse af TLM-certifikatet skal behandles af en repræsentant fra en TLM-organisation under CPA'ens kontrol.
4.1.1.3.EA og AA
(93)En bemyndiget repræsentant for EA'en eller AA'en kan indsende sub-CA-(EA- og/eller AA-)certifikatanmodningsansøgningen til den bemyndigede repræsentant for den relevante rod-CA (strøm 27/28).
4.1.1.4.C-ITS-station
(94)Abonnenter skal registrere hver C-ITS-station hos EA'en i henhold til afsnit 3.2.5.3.
(95)Hver C-ITS-station, som er registreret hos EA'en, kan sende EC-anmodninger (strøm 31).
(96)Hver C-ITS-station kan sende AT-anmodninger (strøm 32) uden at anmode om abonnentinteraktion. Før anmodning om en AT skal en C-ITS-station have en EC.
4.1.2.Indskrivningsproces og ansvarsområder
(97)Tilladelser til, at rod-CA'er og sub-CA'er udsteder certifikater til særlige (statslige) formål (dvs. særlige mobile og faste C-ITS-stationer), kan kun genereres af de medlemsstater, organisationerne befinder sig i.
4.1.2.1.Rod-CA'er
(98)Når rod-CA'er er blevet revideret (strøm 13 og 36, afsnit 8), kan de ansøge om at få indført deres certifikat(er) i ECTL'en hos CPA'en (strøm 14). Indskrivningsprocessen er baseret på en underskrevet manuel ansøgningsformular, som skal leveres fysisk til CPA'en af rod-CA'ens bemyndigede repræsentant og som minimum indeholde de oplysninger, der henvises til i afsnit 3.2.2.1, 3.2.3 og 3.2.5.1.
(99)Rod-CA'ens ansøgningsformular skal være underskrevet af dens bemyndigede repræsentant.
(100)Ud over ansøgningsformularen skal rod-CA'ens bemyndigede repræsentant levere en kopi af rod-CA'ens CPS (strøm 15) og dens revisionsrapport til godkendelse hos CPA'en (strøm 16). I tilfælde med positiv godkendelse genererer CPA'en et overensstemmelsescertifikat og sender det til CPOC'et/TLM'en og den tilsvarende rod-CA.
(101)Rod-CA'ens bemyndigede repræsentant skal dernæst aflevere sin ansøgningsformular (indeholdende fingeraftrykket for det selv-underskrevne certifikat), det officielle ID og et autorisationsbevis til CPOC'et/TLM'en. Det selv-underskrevne certifikat skal leveres elektronisk til CPOC'et/TLM'en. CPOC'et/TLM'en skal verificere alle dokumenter og det selv-underskrevne certifikat.
(102)I tilfælde med positive verificeringer skal TLM'en føje rod-CA'ens certifikat til ECTL'en baseret på meddelelsen fra CPA'en (strøm 1 og 2). Den detaljerede proces beskrives i TLM'ens CPS.
(103)En yderligere procedure for at få en godkendelse af en rod-CA's CPS og revisionsrapport hos et nationalt organ i specifikke lande bør være mulig.
4.1.2.2.TLM
(104)Efter revision kan TLM'en blive indskrevet med CPA'en. Indskrivningsprocessen er baseret på en underskrevet manuel ansøgningsformular, som skal leveres fysisk til CPA'en (strøm 38) af TLM'ens bemyndigede repræsentant og som minimum indeholde de oplysninger, der henvises til i afsnit 3.2.2.2 og 3.2.3.
(105)TLM'ens ansøgningsformular skal være underskrevet at dens bemyndigede repræsentant.
(106)Først genererer TLM'en sit selv-underskrevne certifikat og sender det sikkert til CPA'en. TLM'en afleverer dernæst sin ansøgningsformular (indeholdende fingeraftrykket for det selv-underskrevne certifikat), en kopi af sin CPS, et officielt ID, et autorisationsbevis og sin revisionsrapport til CPA'en (strøm 40). CPA'en skal kontrollere alle dokumenter og det selv-underskrevne certifikat. I tilfælde med positiv verificering af alle dokumenter, det selv-underskrevne certifikat og fingeraftrykket skal CPA'en bekræfte indskrivningsprocessen ved at sende sin godkendelse til TLM'en og CPOC'et (strøm 39). CPA'en skal gemme de ansøgningsoplysninger, som TLM'en har sendt. TLM-certifikatet udstedet dernæst via CPOC'et.
4.1.2.3.EA og AA
(107)Under indskrivningsprocessen skal EA'en/AA'en aflevere de relevante dokumenter (f.eks. CPS'en og revisionsrapporten) til den tilsvarende rod-CA til godkendelse (strøm 27/28). I tilfælde med positive kontroller af dokumenterne sender en rod-CA en godkendelse til de tilsvarende sub-CA'er (strøm 29/30). sub-CA'en (EA eller AA) skal dernæst sende sin underskrevne anmodning elektronisk og fysisk levere sin ansøgningsformular (i henhold til afsnit 3.2.2.1), autorisationsbevis og ID-dokument til den tilsvarende rod-CA. Rod-CA'en verificerer anmodningen og de modtagne dokumenter (ansøgningsformular indeholdende fingeraftrykket, som er SHA 256-nummertegnsværdien for sub-CA'ens anmodning, autorisationsbevis og ID-dokument). Hvis alle kontroller fører til et positivt resultat, udsteder rod-CA'en det tilsvarende sub-CA-certifikat. Detaljerede oplysninger om, hvordan en indledende anmodning udarbejdes, er beskrevet i dens specifikke CPS.
(108)Ud over sub-CA-ansøgningsformularen skal sub-CA'ens bemyndigede repræsentant vedhæfte en kopi af CPS'en til rod-CA'en.
(109)Der skal gives oplysninger til en akkrediteret PKI-revisor til revision i henhold til afsnit 8.
(110)Hvis en sub-CA ejes af en anden entitet end den, der ejer en rod-CA, skal sub-CA'ens entitet underskrive en kontrakt angående rod-CA'ens service, inden den udsteder en sub-CA-certifikatanmodning.
4.1.2.4.C-ITS-station
(111)Den indledende registrering af slutentitetssubjekter (C-ITS-stationer) skal udføres af den ansvarlige abonnent (producent/operatør) med EA'en (strøm 33 og 35) efter gennemført autentifikation af abonnentorganisationen og en af dens repræsentanter i overensstemmelse med afsnit 3.2.2.4 og 3.2.5.2.
(112)C-ITS-stationen kan generere et EC-nøglepar (se afsnit 6.1) og oprette en underskrevet EC-anmodning i henhold til [1]. Andre protokoller kan anvendes, såfremt [1] implementeres.
(113)Under registreringen af en normal C-ITS-station (i modsætning til en særlig mobil eller fast C-ITS-station) skal EA'en verificere, at tilladelserne i den indledende anmodning ikke er til statslig anvendelse. Tilladelser til statslig anvendelse defineres af de tilsvarende medlemsstater. Den detaljerede procedure for EA'ens registrering og svar til producenten/operatøren (strøm 33 og 35) skal forelægges i EA'ens tilsvarende CPS.
(114)En C-ITS-station skal indskrives hos en EA (afsnit 3.2.5.3) ved at sende sin indledende EC-anmodning i henhold til [1].
(115)Efter indledende registrering af en autentificeret abonnentrepræsentant godkender EA'en, hvilke AT'er slutentitetssubjektet (dvs. C-ITS-stationen) kan indhente. Hver slutentitet tildeles ydermere et tillidssikringsniveau, som er relateret til certificeringen af slutentiteten i henhold til en af beskyttelsesprofilerne angivet i afsnit 6.1.5.2.
(116)Regelmæssige køretøjer skal kun have én C-ITS-station, som er registreret hos én EA. Køretøjer med særlige formål (såsom politibiler og andre køretøjer med særlige formål og rettigheder) kan registreres hos en yderligere EA eller have én ekstra C-ITS-station til autorisationer inden for det særlige formåls anvendelsesområde. Køretøjer, som en sådan undtagelse gælder for, skal defineres af de ansvarlige medlemsstater. Tilladelser til særlige mobile og faste C-ITS-stationer må kun gives af den ansvarlige medlemsstat. CPS'en for rod-CA'er eller sub-CA'er, der udsteder certifikater for sådanne køretøjer i de pågældende medlemsstater, skal afgøre, hvordan certifikatprocessen gælder for sådanne køretøjer.
(117)Når abonnenten er i gang med at migrere en C-ITS-station fra én EA til en anden EA, kan C-ITS-station være registreret som to (lignende) EA'er.
(118)En C-ITS-station genererer et AT-nøglepar (se afsnit 6.1) og opretter en AT-anmodning i henhold til [1]. Andre protokoller kan anvendes, såfremt [1] implementeres.
(119)C-ITS-stationer sender en autorisationsanmodning til AA'ens URL (strøm 32 og 26) ved som minimum at sende de påkrævede oplysninger, der nævnes i afsnit 3.2.3.3). AA'en og EA'en validerer autorisationen for hver anmodning i henhold til afsnit 3.2.6 og 4.2.2.5.
4.2.Behandling af en certifikatansøgning
4.2.1.Udførelse af identifikations- og autentifikationsfunktioner
4.2.1.1.Identifikation og autentifikation af rod-CA'er
(120)CPA'ens bemyndigede repræsentant har ansvaret for at bekræfte rod-CA'ens bemyndigede repræsentant og godkende dens indskrivningsproces i henhold til afsnit 3.
4.2.1.2.Identifikation og autentifikation af TLM'en
(121)CPA'ens bemyndigede repræsentant har ansvaret for at bekræfte TLM'ens bemyndigede repræsentant og godkende dens ansøgningsformular for indskrivningsprocessen i henhold til afsnit 3.
4.2.1.3.Identifikation og autentifikation af EE og AA
(122)Den tilsvarende rod-CA har ansvaret for at bekræfte EA'ens/AA'ens bemyndigede repræsentant og godkende dens ansøgningsformular for indskrivningsprocessen i henhold til afsnit 3.
(123)Rod-CA'en skal bekræfte sin positive validering af ansøgningsformularen over for EA'en/AA'en. EA'en/AA'en kan dernæst sende en certifikatanmodning til rod-CA'en (strøm 21/24), som skal udstede certifikater til den tilsvarende EA/AA (strøm 18/19).
4.2.1.4.Identifikation og autentifikation af EE-abonnent
(124)Før en C-ITS-station kan anmode om et EC-certifikat, skal EE-abonnenten sende C-ITS-stationens identifikatoroplysninger sikkert til EA'en (strøm 33). EA'en skal verificere anmodningen og i tilfælde med positiv verificering registrere C-ITS-stationens oplysninger in sin database og bekræfte dette over for EE-abonnenten (strøm 35). Denne handling udføres kun én gang af producenten eller operatøren for hver C-ITS-station. Når en C-ITS-station er blevet registreret af en EA, kan den anmode om et enkelt EC-certifikat, som den har brug for (strøm 31), ad gangen. EA'en autentificerer og verificerer, at oplysningerne i EC-certifikatanmodningen er gyldige for en C-ITS-station.
4.2.1.5.Autorisationsbilletter
(125)Under autorisationsanmodninger (strøm 32) skal AA'en i henhold til [1] autentificere den EA, som C-ITS-stationen modtog sin EC fra. Andre protokoller kan anvendes, såfremt [1] implementeres. Hvis AA'en ikke er i stand til at autentificere EA'en, afvises anmodningen (strøm 26). Som et krav skal AA'en besidde EA-certifikatet for at autentificere EA'en og verificere dens svar (strøm 25 og 23, afsnit 3.2.5.3).
(126)EA'en autentificerer den C-ITS-station, der anmoder om en AT, ved at verificere dens EC (strøm 25 og 23).
4.2.2.Godkendelse eller afvisning af certifikatansøgninger
4.2.2.1.Godkendelse eller afvisning af rod-CA-certifikater
(127)TLM'en indfører/sletter rod-CA-certifikater i ECTL'en i overensstemmelse med godkendelsen af CPA'en (strøm 1/2).
(128)TLM'en bør verificere signaturen, oplysningerne og kodningen af rod-CA-certifikater efter at have modtaget en godkendelse fra CPA'en (strøm 1). Efter positiv validering og CPA'ens godkendelse skal TLM'en sætte det tilsvarende rodcertifikat på ECTL'en og give CPA'en besked (strøm 5).
4.2.2.2.Godkendelse eller afvisning af TLM-certifikat
(129)CPA'en har ansvaret for at godkende eller afvise TLM-certifikater.
4.2.2.3.Godkendelse eller afvisning af EA- og AA-certifikater
(130)Rod-CA'en verificerer sub-CA-certifikatanmodninger (strøm 21/24) og de relevante rapporter (udstedt af den akkrediterede PKI-revisor), når den har modtaget dem (strøm 36, afsnit 8) fra den tilsvarende sub-CA til rod-CA'en. Hvis kontrollen af anmodningerne fører til et positivt resultat, udsteder den tilsvarende rod-CA et certifikat til den anmodende EA/AA (strøm 18/19); ellers afvises anmodningen, og der udstedes ingen certifikater til EA'en/AA'en.
4.2.2.4.Godkendelse eller afvisning af EC
(131)EA'en skal verificere og validere EC-anmodninger i henhold til afsnit 3.2.3.2 og 3.2.5.3.
(132)Hvis certifikatanmodningen i henhold til [1] er korrekt og gyldig, skal EA'en generere det anmodede certifikat.
(133)Hvis certifikatanmodningen er ugyldig, afviser EA'en den og sender et svar, der beskriver årsagen til afvisningen i henhold til [1]. Hvis en C-ITS-station stadig ønsker en EC, skal den lave en ny certifikatanmodning. Andre protokoller kan anvendes, såfremt [1] implementeres.
4.2.2.5.Godkendelse eller afvisning af AT
(134)Certifikatanmodningen kontrolleres af EA'en. AA'en skal oprette kommunikation med EA'en for at validere anmodningen (strøm 25). EA'en skal autentificere den anmodende C-ITS-station og validere, hvorvidt den er berettiget til at modtage den anmodede AT efter CP'en (f.eks. ved at kontrollere tilbagekaldelsesstatussen og validere certifikatets tids-/regionsgyldighed, tilladelser, sikringsniveau osv.). EA'en skal sende et valideringssvar tilbage (strøm 23), og hvis svaret er positivt, skal AA'en generere det anmodede certifikat og sende det til C-ITS-stationen. Hvis AT-anmodningen ikke er korrekt, eller EA-valideringssvaret er negativt, afviser AA'en anmodningen. Hvis en C-ITS-station stadig kræver en AT, skal den lave en ny autorisationsanmodning.
4.2.3.Tid til behandling af certifikatansøgningen
4.2.3.1.Rod-CA-certifikatansøgning
(135)Tiden til behandling af identifikations- og autentifikationsprocessen for en certifikatansøgning ligger i løbet af arbejdsdagen og skal underlægges en maksimal tidsbegrænsning, som er fastlagt i rod-CA'ens CPS.
4.2.3.2.TLM-certifikatansøgning
(136)Behandlingen af TLM-certifikatansøgningen skal underlægges en maksimal tidsbegrænsning, som er fastlagt i TLM'ens CPS.
4.2.3.3.EA- og AA-certifikatansøgning
(137)Tiden til behandling af identifikations- og autentifikationsprocessen for en certifikatansøgning ligger i løbet af arbejdsdagen i henhold til aftalen og kontrakten mellem medlemsstatens/den private organisations rod-CA og sub-CA'en. Tiden til behandling af sub-CA-certifikatansøgninger skal underlægges en maksimal tidsbegrænsning, som er fastlagt i sub-CA'ens CPS.
4.2.3.4.EC-ansøgning
(138)Behandlingen af EC-ansøgninger skal underlægges en maksimal tidsbegrænsning, som er fastlagt i EA'ens CPS.
4.2.3.5.AT-ansøgning
(139)Behandlingen af AT-ansøgninger skal underlægges en maksimal tidsbegrænsning, som er fastlagt i AA'ens CPS.
4.3.Certifikatudstedelse
4.3.1.CA-handlinger under certifikatudstedelse
4.3.1.1.Rod-CA-certifikatudstedelse
(140)Rod-CA'er udsteder deres egne selv-underskrevne rod-CA-certifikater, linkcertifikater, sub-CA-certifikater og CRL'er.
(141)Efter CPA-godkendelse (strøm 4) sender rod-CA'en sit certifikat til TLM'en via CPOC'et, så det kan blive tilføjet ECTL'en (strøm 11 og 8) (se afsnit 4.1.2.1). TLM'en kontrollerer, hvorvidt CPA'en har godkendt certifikatet (strøm 1).
4.3.1.2.TLM-certifikatudstedelse
(142)TLM'en udsteder sit eget selv-underskrevne TLM- og linkcertifikat og sender det til CPOC'et (strøm 6).
4.3.1.3.EA- og AA-certifikatudstedelse
(143)sub-CA'erne genererer en anmodning om et underskrevet certifikat og sender den til den tilsvarende rod-CA (strøm 21 og 24). Rod-CA'en verificerer anmodningen og udsteder et certifikat til den anmodende sub-CA i henhold til [5] så hurtigt som muligt som fastlagt i CPS'en for almindelig operationel praksis, men ikke senere end fem arbejdsdage efter modtagelse af anmodningen.
(144)Rod-CA'en skal opdatere det register, der indeholder sub-CA'ernes certifikater.
4.3.1.4.EC-udstedelse
(145)C-ITS-stationen skal sende en EC-anmodning til EA'en i henhold til [1]. EA'en skal autentificere og verificere, at oplysningerne i certifikatanmodningen er gyldige for en C-ITS-station. Andre protokoller kan anvendes, såfremt [1] implementeres.
(146)I tilfælde med positiv validering skal EA'en udstede et certifikat i henhold til C-ITS-stationsregistreringen (se 4.2.1.4) og sende det til C-ITS-stationen ved hjælp af en EC-svarmeddelelse i henhold til [1]. Andre protokoller kan anvendes, såfremt [1] implementeres.
(147)Hvis der ikke er nogen registrering, skal EA'en generere en fejlkode og sende den til C-ITS-stationen ved hjælp af en EC-svarmeddelelse i henhold til [1]. Andre protokoller kan anvendes, såfremt [1] implementeres.
(148)EC-anmodninger og EC-svar skal krypteres for at sikre fortrolighed og underskrives for at sikre autentifikation og integritet.
4.3.1.5.AT-udstedelse
(149)C-ITS-stationen skal sende en AT-anmodningsmeddelelse til AA'en i henhold til [1]. AA'en skal sende en AT-valideringsanmodning til EA'en i henhold til [1]. EA'en skal sende en AT-valideringsanmodning til AA'en. I tilfælde med et positivt svar skal AA'en generere en AT og sende den til C-ITS-stationen ved hjælp af en AT-svarmeddelelse i henhold til [1]. I tilfælde med et negativt svar skal AA'en generere en fejlkode og sende den til C-ITS-stationen ved hjælp af en AT-svarmeddelelse i henhold til [1]. Andre protokoller kan anvendes, såfremt [1] implementeres.
(150)AT-anmodninger og AT-svar skal krypteres (kun nødvendigt for mobile C-ITS-stationer) for at sikre fortrolighed og underskrives for at sikre autentifikation og integritet.
4.3.2.CA'ens meddelelse til abonnenten angående udstedelse af certifikater.
Ikke relevant.
4.4.Certifikataccept
4.4.1.Udførelse af certifikataccept
4.4.1.1.Rod-CA
Ikke relevant.
4.4.1.2.TLM
Ikke relevant.
4.4.1.3.EA og AA
(151)EA'en/AA'en skal verificere certifikattypen, signaturen og oplysningerne i det modtagne certifikat. EA'en/AA'en skal kassere alle EA-/AA-certifikater, som ikke er korrekt verificeret, og udstede en ny anmodning.
4.4.1.4.C-ITS-station
(152)C-ITS-stationen skal verificere EC-/AT-svaret modtaget fra EA'en/AA'en op imod dens oprindelige anmodning, herunder signaturen og certifikatkæden. Den skal kassere alle EC-/AT-svar, som ikke er korrekt verificeret. I sådanne tilfælde bør den sende en ny EC-/AT-anmodning.
4.4.2.Offentliggørelse af certifikatet
(153)TLM-certifikater og deres linkcertifikater skal gøres tilgængelige for alle deltagere via CPOC'et.
(154)Rod-CA-certifikater offentliggøres af CPOC'et via ECTL'en, som er underskrevet af TLM'en.
(155)sub-CA'ers (EA'ers og AA'ers) certifikater offentliggøres af rod-CA'en.
(156)EC'er og AT'er offentliggøres ikke.
4.4.3.Meddelelse om certifikatudstedelse
Der er ingen meddelelser om udstedelse.
4.5.Anvendelse af nøglepar og certifikat
4.5.1.Anvendelse af privat nøgle og certifikat
4.5.1.1.Anvendelse af privat nøgle og certifikat for TLM
(157)TLM'en skal anvende sine private nøgler til at underskrive sine egne (TLM- og link-) certifikater og ECTL'en.
(158)TLM-certifikatet skal anvendes af PKI-deltagere til at verificere ECTL'en og autentificere TLM'en.
4.5.1.2.Anvendelse af privat nøgle og certifikat for rod-CA'er
(159)Rod-CA'er skal anvende deres private nøgler til at underskrive deres egne certifikater, CRL, linkcertifikater og EA-/AA-certifikaterne.
(160)Rod-CA-certifikater skal anvendes af PKI-deltagere til at verificere de tilknyttede AA- og EA-certifikater, linkcertifikater og CRL'erne.
4.5.1.3.Anvendelse af privat nøgle og certifikat for EA'er og AA'er
(161)EA'er skal anvende deres private nøgler til at underskrive EC'er og til dekryptering af indskrivningsanmodninger.
(162)EA-certifikater skal anvendes til at verificere signaturen fra de tilknyttede EC'er og til kryptering af EC- og AT-anmodninger af EE'er som defineret i [1].
(163)AA'er skal anvende deres private nøgler til at underskrive AT'er og til dekryptering af AT-anmodninger.
(164)AA-certifikater skal anvendes af EE'er til at verificere tilknyttede AT'er og til kryptering af AT-anmodninger som defineret i [1].
4.5.1.4.Anvendelse af privat nøgle og certifikat for slutentiteter
(165)EE'er skal anvende den private nøgle, der svarer til en gyldig EC, til at underskrive en ny indskrivningsanmodning som defineret i [1]. Den private nøgle skal anvendes til at opbygge den indre signatur i anmodningen for at bevise besiddelse af den private nøgle, der svarer til den nye offentlige EC-nøgle.
(166)EE'er skal anvende den private nøgle, der svarer til en gyldig EC, til at underskrive en autorisationsanmodning som defineret i [1]. Den private nøgle, der svarer til den nye AT, skal anvendes til at opbygge den indre signatur i anmodningen for at bevise besiddelse af den private nøgle, der svarer til den nye offentlige AT-nøgle.
(167)EE'er skal anvende den private nøgle, der svarer til en gyldig AT, til at underskrive C-ITS-meddelelser som defineret i [5].
4.5.2.Signaturmodtagers anvendelse af offentlig nøgle og certifikat
(168)Signaturmodtagere anvender den betroede certificeringssti og tilknyttede offentlige nøgler til formålene henvist til i certifikaterne og til at autentificere EC'ers og AT'ers betroede fælles identitet.
(169)Rod-CA-, EA- og AA-certifikater, EC'er og AT'er skal ikke anvendes uden indledende kontrol fra en signaturmodtager.
4.6.Certifikatfornyelse
Ikke tilladt.
4.7.Genindlæsning af certifikat
4.7.1.Omstændigheder for genindlæsning af certifikat
(170)Genindlæsning af certifikater skal behandles, når et certifikat når slutningen af sin levetid, eller når en privat nøgle når slutningen af sin operationelle anvendelse, men tillidsforholdet til CA'en stadig eksisterer. Et nyt nøglepar og det tilsvarende certifikat skal genereres og udstedes i alle tilfælde.
4.7.2.Hvem må anmode om genindlæsning
4.7.2.1.Rod-CA
(171)Rod-CA'en anmoder ikke om genindlæsning. Genindlæsningsprocessen er en intern proces for rod-CA'en, fordi dens certifikat er selv-underskrevet. Rod-CA'en skal genindlæse med enten linkcertifikater eller ny udstedelse (se afsnit 4.3.1.1).
4.7.2.2.TLM
(172)TLM'en anmoder ikke om genindlæsning. Genindlæsningsprocessen er intern for TLM'en, fordi dens certifikat er selv-underskrevet.
4.7.2.3.EA og AA
(173)sub-CA'ens certifikatanmodning skal indsendes rettidigt for at være sikker på, at den kan få et nyt sub-CA-certifikat og operationelt sub-CA-nøglepar før udløbet af den aktuelle private sub-CA-nøgle. Indsendelsesdatoen skal også tage hensyn til den nødvendige tid til godkendelse.
4.7.2.4.C-ITS-station
Ikke relevant.
4.7.3.Genindlæsningsproces
4.7.3.1.TLM-certifikat
(174)TLM'en vælger at genindlæse på baggrund af kravene i afsnit 6.1 og 7.2. Den detaljerede proces er beskrevet i dens CPS.
(175)TLM'en skal udføre genindlæsningsprocessen rettidigt for at muliggøre distributionen af det nye TLM-certifikat og linkcertifikat til alle deltagerne, inden det aktuelle TLM-certifikat udløber.
(176)TLM'en skal anvende linkcertifikater til genindlæsning og til at garantere tillidsforholdet til det nye selv-underskrevne certifikat. Det nyligt genererede TLM- og linkcertifikat overføres til CPOC'et.
4.7.3.2.Rod-CA-certifikat
(177)Rod-CA'en vælger at genindlæse på baggrund af kravene i afsnit 6.1.5 og 7.2. Den detaljerede proces bør være beskrevet i dens CPS.
(178)Rod-CA'en skal udføre genindlæsningsprocessen rettidigt (inden rod-CA-certifikatet udløber) for at muliggøre indføring af det nye certifikat i ECTL'en, inden rod-CA-certifikatet bliver gyldigt (se afsnit 5.6.2). Genindlæsningsprocessen skal udføres enten via linkcertifikater eller som en indledende anmodning.
4.7.3.3.EA- og AA-certifikater
(179)EA'en eller AA'en skal anmode om et nyt certifikat som følger:
Trin
|
Indikation
|
Genindlæsningsanmodning
|
1
|
Generering af nøglepar
|
sub-CA'erne (EA'er og AA'er) skal generere nye nøglepar i henhold til afsnit 6.1.
|
2
|
Generering af certifikatanmodning og indre signatur
|
sub-CA'en genererer en certifikatanmodning ud fra den nyligt genererede offentlige nøgle under hensyntagen til navngivningssystemet (subject_info) i afsnit 3, signaturens algoritme, de tjenestespecifikke tilladelser (SSP) og valgfrie ekstraparametre og genererer den indre signatur med den tilsvarende nye private nøgle. Hvis en krypteringsnøgle er nødvendig, skal sub-CA'en også bevise besiddelse af den tilsvarende private krypteringsnøgle.
|
3
|
Generer ydre signatur
|
Hele anmodningen skal underskrives med den aktuelle gyldige private nøgle for at garantere den underskrevne anmodnings ægthed.
|
4
|
Send anmodning til rod-CA
|
Den underskrevne anmodning skal indsendes til den tilsvarende rod-CA.
|
5
|
Verificering af anmodning
|
Den tilsvarende rod-CA skal verificere anmodningens integritet og ægthed. Først skal den kontrollere den ydre signatur. Hvis verificeringen er positiv, skal den kontrollere den indre signatur. Hvis der er bevis på besiddelse af den private dekrypteringsnøgle, skal den også kontrollere dette bevis.
|
6
|
Accepter eller afvis anmodning
|
Hvis alle kontroller fører til et positivt resultat, accepterer rod-CA'en anmodningen; ellers afviser den den.
|
7
|
Generer og udsted certifikat
|
Rod-CA'en genererer et nyt certifikat og distribuerer det til den anmodende sub-CA.
|
8
|
Send svar
|
sub-CA'en skal sende en statusmeddelelse (angående hvorvidt certifikatet er blevet modtaget) til rod-CA'en.
|
Tabel 3: Genindlæsningsproces for EA'er og AA'er
(180)Under automatisk genindlæsning for sub-CA'er skal rod-CA'en sikre, at den anmodende bruger rent faktisk er i besiddelse af dens private nøgle. Der skal anvendes passende protokoller for bevis på besiddelse af private dekrypteringsnøgler, f.eks. som defineret i RFC 4210 og 4211. Den indre signatur skal anvendes til private signaturnøgler.
4.7.3.4.C-ITS-stationscertifikater
Ikke relevant for AT.
4.8.Certifikatændring
Ikke tilladt.
4.9.Tilbagekaldelse og suspendering af certifikat
Se afsnit 7.
4.10.Certifikatstatustjenester
4.10.1.Operative egenskaber
Ikke relevant.
4.10.2.Tjenesternes tilgængelighed
Ikke relevant.
4.10.3.Operative funktioner
Ikke relevant.
4.11.Abonnementets afslutning
Ikke relevant.
4.12.Nøgledeponering og -generhvervelse
4.12.1.Abonnent
4.12.1.1.Hvilke nøglepar kan deponeres
Ikke relevant.
4.12.1.2.Hvem kan indsende en ansøgning om generhvervelse
Ikke relevant.
4.12.1.3.Generhvervelsesproces og -ansvar
Ikke relevant.
4.12.1.4.Identifikation og autentifikation
Ikke relevant.
4.12.1.5.Godkendelse eller afvisning af generhvervelsesansøgninger
Ikke relevant.
4.12.1.6.KEA- og KRA-handlinger under generhvervelse af nøglepar
Ikke relevant.
4.12.1.7.KEA- og KRA-tilgængelighed
Ikke relevant.
4.12.2.Politik og praksis for indkapsling og generhvervelse af sessionsnøgle
Ikke relevant.
5.Facilitet, forvaltning og operativ betjening
(181)PKI'en består af rod-CA'en, EA'en/AA'en, CPOC'et og TLM'en, herunder deres ICT-komponenter (f.eks. netværk og servere).
(182)I dette afsnit identificeres den entitet, der har ansvaret for et element i PKI'en, af elementet selv. Med andre ord betyder sætningen "CA'en har ansvaret for at udføre revisionen" det samme som "den entitet eller det personale, der administrerer CA'en, har ansvaret for at udføre …".
(183)Begrebet "elementer i C-ITS-tillidsmodellen" omfatter rod-CA'en, TLM'en, EA'en/AA'en, CPOC'et og det sikre netværk.
5.1.Fysiske kontrolforanstaltninger
(184)Alle handlinger i forbindelse med C-ITS-tillidsmodellen skal udføres i et fysisk beskyttet miljø, der forhindrer, afværger og detekterer uautoriseret brug af, adgang til eller videregivelse af følsomme oplysninger og systemer. C-ITS-tillidsmodellens elementer skal anvende fysiske sikkerhedskontrolforanstaltninger i overensstemmelse med ISO 27001 og ISO 27005.
(185)De entiteter, der administrerer C-ITS-tillidsmodellens elementer, skal beskrive de fysiske, proceduremæssige og personalemæssige sikkerhedskontrolforanstaltninger i deres CPS. Navnlig skal CPS'en dække oplysninger om stedets placering og konstruktionen af bygningerne og deres fysiske sikkerhedskontrolforanstaltninger, der garanterer kontrolleret adgang til alle rum på faciliteten, der anvendes af C-ITS-tillidsmodellens entiteter.
5.1.1.Stedets placering og konstruktion
5.1.1.1.Rod-CA, CPOC, TLM
(186)Placeringen og konstruktionen af den facilitet, der indeholder rod-CA'ens, CPOC'ets og TLM'ens udstyr og data (HSM, aktiveringsdata, sikkerhedskopi af nøglepar, computer, log, nøgleceremoni-script, certifikatanmodning osv.), skal være i overensstemmelse med faciliteter, der indeholder følsomme oplysninger af høj værdi. Rod-CA'er skal betjenes i et dedikeret fysisk område, som er adskilt fra andre PKI-komponenters fysiske områder.
(187)Rod-CA'en, CPOC'et og TLM'en skal implementere politikker og procedurer for at sikre, at der opretholdes et højt sikkerhedsniveau i det fysiske miljø, som rod-CA'en er installeret i, så det garanteres, at:
·den er isoleret fra netværk uden for tillidsmodellen
·den er adskilt i en serie af (mindst to) gradvist mere sikre fysiske omkredse
·følsomme data (HSM, sikkerhedskopier af nøglepar, aktiveringsdata osv.) opbevares et sikkert, dedikeret sted i et dedikeret fysisk område under flere former for adgangskontrol.
(188)De anvendte sikkerhedsteknikker skal være skabt til at modstå et stort antal samt kombinationer af forskellige angrebsformer. De anvendte mekanismer skal omfatte mindst:
·omkredsalarmer, fjernsyn i et lukket kredsløb, forstærkede vægge og bevægelsessensorer
·tofaktorgodkendelse (f.eks. smartcard og PIN) for alle personer og identitetsskilte, der kommer ind i eller forlader rod-CA'ens faciliteter og fysiske sikrede område.
(189)Rod-CA'en, CPOC'et og TLM'en bruger autoriseret personale til kontinuerligt at overvåge facilitetens kabinetudstyr alle timer i døgnet hele året rundt. Driftsmiljøet (f.eks. den fysiske facilitet) må aldrig efterlades uden opsyn. Driftsmiljøets personale må aldrig have afgang til rod-CA'ernes eller sub-CA'ernes sikrede områder, medmindre de er autoriseret til det.
5.1.1.2.EA/AA
(190)Der gælder de samme bestemmelser som i afsnit 5.1.1.1.
5.1.2.Fysisk adgang
5.1.2.1.Rod-CA, CPOC, TLM
(191)Udstyr og data (HSM, aktiveringsdata, sikkerhedskopi af nøglepar, computer, log, nøgleceremoni-script, certifikatanmodning osv.) skal altid være beskyttet mod uautoriseret adgang. De fysiske sikkerhedsmekanismer for udstyr skal som minimum:
·konstant overvåge, enten manuelt eller elektronisk, for uautoriseret indtrængen
·sikre, at der ikke tillades uautoriseret adgang til hardwaren og aktiveringsdataene
·sikre, at alle flytbare medier og papir, der indeholder følsomme oplysninger i klartekst, opbevares i en sikker beholder
·sikre, at alle personer, der får adgang til sikre områder, og som ikke er autoriseret på permanent basis, ikke efterlades uden opsyn af en autoriseret medarbejder fra rod-CA-, CPOC- og TLM-faciliteterne
·sikre, at en adgangslog bibeholdes og regelmæssigt efterses
·sørge for mindst to lag gradvist stigende sikkerhed, f.eks. for omkredsen, for bygningen og for driftslokalet
·kræve to fysiske adgangskontrolforanstaltninger i betroede roller til de kryptografiske HSM- og aktiveringsdata.
(192)Der skal udføres en sikkerhedskontrol af facilitetens kabinetudstyr, hvis det skal efterlades uden opsyn. Kontrollen skal som minimum verificere, at:
·udstyret er i en tilstand, der passer til den aktuelle operationsmodus
·alt udstyr er lukket ned, hvad angår offlinekomponenter
·alle sikkerhedsbeholdere (garantiforseglet konvolut, pengeskab osv.) er sikret korrekt
·fysiske sikkerhedssystemer (f.eks. dørlåse, ventilationsdæksler, elektricitet) fungerer korrekt
·området er sikret mod uautoriseret adgang.
(193)Fjernbare kryptografiske moduler skal deaktiveres inden opbevaring. Når de ikke er i brug, skal sådanne moduler og de aktiveringsdata, der anvendes til at få adgang til eller aktivere dem, anbringes et sikkert sted. Aktiveringsdata skal enten memoreres eller registreres og gemmes på en måde, som svarer til den sikkerhed, der er tildelt det kryptografiske modul. De må ikke opbevares sammen med det kryptografiske modul, så det undgås, at kun én person har adgang til den private nøgle.
(194)En person eller gruppe af betroede roller skal gøres udtrykkeligt ansvarlige for at foretage sådanne kontroller. Hvis en gruppe af personer er ansvarlig, skal der bibeholdes en log over, hvem der udfører hver kontrol. Hvis faciliteten ikke tilses kontinuerligt, skal den person, der sidst forlader den, skrive sine initialer på et udtjekningsark, angive datoen og klokkeslættet og bekræfte, at alle fysiske beskyttelsesmekanismer er på plads og aktiveret.
5.1.2.2.EA/AA
(195)Der gælder de samme bestemmelser som i afsnit 5.1.2.1.
5.1.3.Strøm og klimaanlæg
(196)Sikre faciliteter til C-ITS-tillidsmodellens elementer (rod-CA, CPOC, TLM, EA og AA) skal været udstyret med pålidelig adgang til strøm for at sikre drift med ingen eller kun mindre fejl. Primære installationer og installationer til sikkerhedskopier er nødvendige i tilfælde af eksternt strømsvigt samt mild nedlukning af C-ITS-tillidsmodellens udstyr i tilfælde af mangel på strøm. C-ITS-tillidsmodellens faciliteter skal være udstyret med varme-/ventilations-/klimaanlæg til at holde temperaturen og den relative luftfugtighed i C-ITS-tillidsmodellens udstyr inden for driftsområdet. CPS'en for C-ITS-tillidsmodellens element vil beskrive planen og processerne for implementering af sådanne krav i detaljer.
5.1.4.Vandeksponering
(197)Sikre faciliteter til C-ITS-tillidsmodellens elementer (rod-CA, CPOC, TLM, EA og AA) bør beskyttes på en måde, som mindsker påvirkningen af vandeksponering. Derfor skal vand- og faldrør undgås. CPS'en for C-ITS-tillidsmodellens element vil beskrive planen og processerne for implementering af sådanne krav i detaljer.
5.1.5.Brandforebyggelse og -sikring
(198)For at forhindre skadelig eksponering for ild eller røg skal de sikre faciliteter til C-ITS-tillidsmodellens elementer (rod-CA, CPOC, TLM, EA og AA) konstrueres og udstyres derefter, og der skal implementeres procedurer for håndtering af brandrelaterede farer. Medielageret skal beskyttes mod brand i egnede beholdere.
(199)C-ITS-tillidsmodellens elementer skal beskytte fysiske medier, der indeholder sikkerhedskopier af vigtige systemdata eller andre følsomme oplysninger fra miljøfarer og uautoriseret brug af, adgang til eller videregivelse af sådanne medier. CPS'en for C-ITS-tillidsmodellens element vil beskrive planen og processerne for implementering af sådanne krav i detaljer.
5.1.6.Mediehåndtering
(200)Medier, der anvendes i C-ITS-tillidsmodellens elementer (rod-CA, CPOC, TLM, EA og AA), håndteres sikkert for at beskytte dem mod skader, tyveri og uautoriseret adgang. Procedurer for mediehåndtering er implementeret for at beskytte medierne mod forfald og nedbrydning i den periode, som optegnelserne skal bevares i.
(201)Følsomme data skal beskyttes mod adgang som følge af genbrugte opbevaringsgenstande (f.eks. slettede filer), som kan gøre de følsomme data tilgængelige for uautoriserede brugere.
(202)Der skal bibeholdes en opgørelse over alle informationsaktiver og forelægges krav for beskyttelsen af disse aktiver, som er i overensstemmelse med risikoanalysen. CPS'en for C-ITS-tillidsmodellens element vil beskrive planen og processerne for implementering af sådanne krav i detaljer.
5.1.7.Bortskaffelse af affald
(203)C-ITS-tillidsmodellens elementer (rod-CA, CPOC, TLM, EA og AA) skal implementere procedurer for sikker og uigenkaldelig affaldsbortskaffelse (papir, medier og alt andet affald) for at forhindre uautoriseret brug af, adgang til eller videregivelse af affald, som indeholder fortrolige/private oplysninger. Alle medier anvendt til opbevaring af følsomme oplysninger, såsom nøgler, aktiveringsdata eller filer, skal destrueres, inden de frigives til bortskaffelse. CPS'en for C-ITS-tillidsmodellens element vil beskrive planen og processerne for implementering af sådanne krav i detaljer.
5.1.8.Ekstern sikkerhedskopiering
5.1.8.1.Rod-CA, CPOC og TLM
(204)Komplette sikkerhedskopier af rod-CA-, CPOC- og TLM-komponenter, som er tilstrækkelige til at gendanne systemet efter systemsvigt, gøres offline efter indførelse af rod-CA, CPOC og TLM og efter hver ny generering af nøglepar. Der laves regelmæssigt sikkerhedskopier af essentielle forretningsoplysninger (nøglepar og CRL) og software. Der sørges for tilstrækkelige sikkerhedskopieringsfaciliteter for at sikre, at alle essentielle forretningsoplysninger og software kan gendannes efter en eventuel katastrofe eller mediesvigt. Sikkerhedskopieringsordninger for individuelle systemer testes regelmæssigt for at sikre, at de opfylder kravene i planen for forretningskontinuitet. Der opbevares mindst én komplet sikkerhedskopi på en ekstern lokation (katastrofeberedskab). Sikkerhedskopien opbevares et sted med fysiske og proceduremæssige kontrolforanstaltninger, der svarer til dem i det operationelle PKI-system.
(205)Sikkerhedskopierede data er underlagt samme adgangskrav som de operationelle data. Sikkerhedskopierede data skal krypteres og opbevares eksternt. I tilfælde at et fuldstændigt tab af data skal de oplysninger, der er nødvendige for at sætte rod-CA'en, CPOC'et og TLM'en tilbage i drift, gendannes helt fra de sikkerhedskopierede data.
(206)Privat rod-CA-, CPOC- og TLM-nøglemateriale skal ikke sikkerhedskopieres ved hjælp af standardmekanismer til sikkerhedskopiering, men ved hjælp af sikkerhedskopieringsfunktionen i det kryptografiske modul.
5.1.8.2.EA/AA
(207)Processerne beskrevet i afsnit 5.1.8.1 gælder for dette afsnit.
5.2.Proceduremæssige kontrolforanstaltninger
Dette afsnit beskriver kravene til roller, opgaver og identifikation af personale.
5.2.1.Betroede roller
(208)Medarbejdere, kontrahenter og konsulenter, som er tildelt betroede roller, skal betragtes som "betroede personer". Personer, der ønsker at blive betroede personer for at opnå en betroet stilling, skal opfylde screeningskravene i denne certifikatpolitik.
(209)Betroede personer har adgang til eller kontrollerer autentifikation eller kryptografiske handlinger, som væsentligt kan påvirke:
·validering af oplysninger i certifikatansøgninger
·accept, afvisning eller andre former for behandling af certifikatansøgninger, tilbagekaldelsesanmodninger eller fornyelsesanmodninger
·udstedelse af tilbagekaldelse af certifikater, herunder personale, der har adgang til begrænsede andele af deres register eller håndteringen af abonnentoplysninger eller -anmodninger.
(210)Betroede roller omfatter, men er ikke begrænset til:
·kundeservice
·systemadministration
·designeret ingeniørarbejde
·ledere pålagt forvaltningen af infrastrukturel troværdighed.
(211)CA'en skal give tydelige beskrivelser af alle betroede roller i sin CPS.
5.2.2.Antal nødvendige personer til hver opgave
(212)C-ITS-tillidsmodellens elementer skal etablere, opretholde og håndhæve strenge kontrolprocedurer for at sikre adskillelse af opgaver på baggrund af betroede roller og for at sikre, at flere betroede personer er nødvendige for at udføre følsomme opgaver. C-ITS-tillidsmodellens elementer (TLM, CPOC, rod-CA, EA og AA) skal overholde [4] og kravene i følgende afsnit.
(213)Der er fastsat politik- og kontrolprocedurer for at sikre adskillelse af opgaver på baggrund af jobansvar. De mest følsomme opgaver, såsom adgang til og forvaltninge af CA'ens kryptografiske hardware (HSM) og dens tilknyttede nøglemateriale, skal kræve autorisation fra flere betroede personer.
(214)Disse interne kontrolprocedurer skal designes til at sikre, at mindst to betroede personer er nødvendige for at få fysisk eller logisk adgang til enheden. Begrænsninger på adgang til CA'ens kryptografiske hardware skal håndhæves strengt af flere betroede personer igennem dens livscyklus fra indgående modtagelse og inspektion til endelig logisk og/eller fysisk destruktion. Når et modul er aktiveret med operationelle nøgler, påkaldes der yderligere adgangskontrolforanstaltninger for at bibeholde opdelt kontrol over både den fysiske og logiske adgang til enheden.
5.2.3.Identifikation og autentifikation for hver rolle
(215)Alle personer, der er tildelt en rolle som beskrevet i denne CP, identificeres og autentificeres for at kunne garantere, at rollen gør dem i stand til at udføre deres PKI-opgaver.
(216)C-ITS-tillidsmodellens elementer skal verificere og bekræfte identiteten og autorisationen af alt personale, der ønsker at blive betroede personer, før de:
·får udstedt deres adgangsenheder og bliver tildelt adgang til de nødvendige faciliteter
·får tildelt elektroniske legitimationsoplysninger, så de kan få adgang til og udføre specifikke funktioner på CA-systemerne.
(217)CPS'en beskriver de mekanismer, der anvendes til at identificere og autentificere enkeltpersoner.
5.2.4.Roller, der kræver adskillelse af opgaver
(218)Roller, der kræver adskillelse af opgaver, inkluderer (men er ikke begrænset til):
·accept, afvisning og tilbagekaldelse af anmodninger samt andre former for behandling af CA-certifikatansøgninger
·generering, udstedelse og destruktion af et CA-certifikat.
(219)Adskillelse af opgaver kan håndhæves ved hjælp af PKI-udstyr, -procedurer eller begge. Ingen enkeltperson skal tildeles mere end én identitet, medmindre dette er godkendt af rod-CA'en.
(220)Den del af rod-CA'en og CA'en, der har at gøre med certifikatoprettelse og forvaltning af tilbagekaldelser, skal være uafhængig af andre organisationer, hvad angår dens beslutninger angående oprettelse, tilvejebringelse, opretholdelse og suspendering af tjenester i overensstemmelse med de gældende certifikatpolitikker. Navnlig skal dens seniorleder, senioransatte og ansatte i betroede roller være fri for kommercielt, finansielt eller andre former for pres, der kan have en utilsigtet indflydelse på tilliden i de tjenester, den yder.
(221)EA'en og AA'en, der tjener mobile C-ITS-stationer, skal være separate driftsentiteter med separate IT-infrastruktur- og IT-forvaltningsteams. I overensstemmelse med GDPR skal EA'en og AA'en ikke udveksle personlige data, undtagen til autorisation af AT-anmodninger. De skal kun overføre data vedrørende godkendelse af AT-anmodninger ved brug af autorisationsvalideringsprotokollen fra [1] via en dedikeret sikker grænseflade. Andre protokoller kan anvendes, såfremt [1] implementeres.
(222)De logfiler, der opbevares af EA'en og AA'en, må udelukkende anvendes til tilbagekaldelse af EC'er, der opfører sig forkert, baseret på AT'er i opfangede ondsindede CAM-/DENM-meddelelser. Når en CAM-/DENM-meddelelse er blevet identificeret som ondsindet, vil AA'en slå AT'ens verifikationsnøgle op i sine udstedelseslogfiler og indsende en tilbagekaldelsesanmodning til EA'en indeholdende den krypterede signatur under EC'ens private nøgle, som blev brugt under udstedelsen af AT'en. Alle logfiler skal være tilstrækkeligt beskyttet mod adgang fra uautoriserede parter og må ikke deles med andre entiteter eller myndigheder.
Bemærk: På tidspunktet for udarbejdelse af udkastet til denne version af CP'en, er designet af den funktion, der opfører sig forkert, ikke blevet defineret. Det er planen potentielt at designe den funktion, der opfører sig forkert, i fremtidige versioner af politikken.
5.3.Personalekontrolforanstaltninger
5.3.1.Krav til kvalifikationer, erfaring og tilladelser
(223)C-ITS-tillidsmodellens elementer har ansat et tilstrækkeligt antal ansatte med den ekspertviden, de erfaringer og de kvalifikationer, der er nødvendige for de tilbudte jobfunktioner og tjenester. PKI-personale opfylder disse krav igennem formel undervisning og kvalifikationer, faktisk erfaring eller en kombination af begge. Betroede roller og ansvarsområder, som defineret i CPS'en, er dokumenteret i jobbeskrivelserne og tydeligt identificeret. Underkontrahenter blandt PKI-personalet har jobbeskrivelser, der er defineret, så der sikres adskillelse af opgaver og privilegier, og positionsfølsomhed er bestemt på baggrund af opgaver og adgangsniveauer, baggrundsscreening og medarbejderuddannelse og -forståelse.
5.3.2.Procedurer for baggrundskontrol
(224)C-ITS-tillidsmodellens elementer skal udføre baggrundskontrol af personale, der ønsker at blive betroede personer. Baggrundskontroller skal gentages for personale, der bestrider betroede stillinger, mindst hvert femte år.
(225)De faktorer, der afsløres ved en baggrundskontrol, som kan betragtes som grundlag for at afvise kandidater til betroede stillinger eller for at træffe foranstaltninger mod en eksisterende betroet person, inkluderer (men er ikke begrænset til) følgende:
·vildledning foretaget af kandidaten eller den betroede person
·yderst negative eller upålidelige professionelle referencer
·bestemte straffedomme
·indikationer på mangel på økonomisk ansvar.
(226)Rapporter, der indeholder sådanne oplysninger, skal evalueres af HR-personalet, som skal træffe rimelige foranstaltninger på baggrund af typen, størrelsen og hyppigheden af den adfærd, baggrundskontrollen har afdækket. Sådanne foranstaltninger kan omfatte foranstaltninger op til og inklusive annullering af ansættelsestilbud til kandidater til betroede stillinger eller afbrydelse af ansættelsen af eksisterende betroede personer. Brugen af oplysninger afsløret ved en baggrundskontrol som grundlag for sådanne foranstaltninger er underlagt gældende lovgivning.
(227)Baggrundsundersøgelser af personer, der ønsker at blive en betroet person, inkluderer, men er ikke begrænset til:
·bekræftelse af tidligere ansættelse
·en kontrol af professionelle referencer, der dækker deres ansættelse over en periode på mindst fem år
·en bekræftelse af den højeste og mest relevante opnåede uddannelse
·en søgning i kriminalregistret.
5.3.3.Uddannelseskrav
(228)C-ITS-tillidsmodellens elementer skal give deres personale den undervisning, der er nødvendig for at kunne opfylde deres ansvar vedrørende CA-operationer på kompetent og tilfredsstillende vis.
(229)Undervisningsprogrammer skal gennemgås regelmæssigt, og deres undervisning skal berøre anliggender, der er relevante for de funktioner, der udføres af personalet.
(230)Undervisningsprogrammer skal berøre anliggender, der er relevante for det specifikke miljø, der undervises i, herunder:
·C-ITS-tillidsmodellens elementers sikkerhedsprincipper og -mekanismer
·anvendte hardware- og softwareversioner
·alle de opgaver, som en person forventes at udføre, samt interne og eksterne rapporteringsprocesser og -sekvenser
·PKI-forretningsprocesser og -arbejdsstrømme
·rapportering og håndtering af hændelser og kompromitteringer
·procedurer for katastrofeberedskab og forretningskontinuitet
·tilstrækkelig IT-viden.
5.3.4.Efteruddannelseshyppighed og -krav
(231)Personer i betroede roller har pligt til at genopfriske den viden, de har anskaffet sig igennem undervisning og på løbende basis, ved hjælp af et undervisningsmiljø. Undervisningen skal gentages, når det vurderes nødvendigt og mindst hvert andet år.
(232)C-ITS-tillidsmodellens elementer skal give deres ansatte genopfriskende undervisning og opdateringer i det omfang og med den hyppighed, der er nødvendig for at sikre, at de bibeholder det færdighedsniveau, der er nødvendigt for at opfylde deres jobansvar kompetent og tilfredsstillende.
(233)Enkeltpersoner i betroede roller skal være opmærksomme på ændringer i PKI-driften, hvor det er relevant. Alle væsentlige ændringer af driften skal ledsages af en undervisningsplan (forståelse), og udførelsen af denne plan skal dokumenteres.
5.3.5.Hyppighed og rækkefølge af jobrotation
(234)Ingen bestemmelser, så længe de tekniske færdigheder, erfaringer og adgangsrettigheder er sikret. Administratorerne af C-ITS-tillidsmodellens elementer skal sikre, at ændringer af personalet ikke påvirker systemets sikkerhed.
5.3.6.Sanktioner for uautoriserede handlinger
(235)Hver C-ITS-tillidsmodels elementer skal udvikle en formel disciplinær proces for at sikre, at uautoriserede handlinger sanktioneres behørigt. I alvorlige tilfælde skal rolletildelingerne og de tilhørende privilegier trækkes tilbage.
5.3.7.Krav til uafhængige kontrahenter
(236)C-ITS-tillidsmodellens elementer må kun lade uafhængige kontrahenter eller konsulenter blive betroede personer i det omfang, der er nødvendigt for at imødekomme tydeligt definerede udliciteringsrelationer og på betingelse af, at entiteten har tillid til kontrahenterne eller konsulenterne i samme omfang, som hvis de var medarbejdere, og at de vil opfylde de krav, der gælder for medarbejdere.
(237)Ellers må uafhængige kontrahenter og konsulenter kun have adgang til sikre C-ITS PKI-faciliteter, hvis de ledsages og er under direkte opsyn af betroede personer.
5.3.8.Dokumentation leveret til personale
(238)C-ITS-tillidsmodellens elementer skal give deres personale nødvendig undervisning og adgang til den dokumentation, de har brug for, for at kunne opfylde deres jobansvar på kompetent og tilfredsstillende vis.
5.4.Revisionslogningsprocedurer
(239)Dette afsnit beskriver krav vedrørende de typer hændelser, der skal registreres, samt forvaltningen af revisionslogfiler.
5.4.1.Typer af hændelser, der skal registreres og rapporteres af hver CA
(240)En CA-repræsentant skal gennemgå CA-logfilerne, -hændelserne og -procedurerne regelmæssigt.
(241)C-ITS-tillidsmodellens elementer skal registrere følgende typer revisionshændelser (hvis det er relevant):
·fysisk facilitetsadgang – fysiske personers adgang til faciliteterne vil blive registreret ved at opbevare adgangsanmodningerne via smartcards. Der vil blive oprettet en hændelse, hver gang der oprettes en registrering
·forvaltning af betroede roller – enhver ændring af definitionen af og niveauet for adgang foretaget af de forskellige roller bliver registreret, herunder ændring af rollernes egenskaber. Der vil blive oprettet en hændelse, hver gang der oprettes en registrering
·logisk adgang – der vil blive oprettet en hændelse, når en entitet (f.eks. et program) har adgang til følsomme områder (dvs. netværk og servere)
·forvaltning af sikkerhedskopier – der vil blive oprettet en hændelse, hver gang der gennemføres en sikkerhedskopiering, enten med eller uden succes
·logforvaltning – logfiler vil blive gemt. Der vil blive oprettet en hændelse, når logfilens størrelse overstiger en specifik størrelse
·data fra autentifikationsprocessen for abonnenter og C-ITS-tillidsmodellens elementer – der vil blive oprettet hændelser for hver autentifikationsanmodning fra abonnenter og C-ITS-tillidsmodellens elementer
·accept og afvisning af certifikatanmodninger, herunder certifikatoprettelse og -fornyelse – der vil regelmæssigt blive oprettet en hændelse med en liste over accepterede og afviste certifikatanmodninger i de forudgående syv dage
·producentregistrering – der vil blive oprettet en hændelse, når en producent registreres
·C-ITS-stationsregistrering – der vil blive oprettet en hændelse, når en C-ITS-station registreres
·HSM-forvaltning – der vil blive oprettet en hændelse, når der registreres et brud på HSM-sikkerheden
·IT- og netværksforvaltning, som de angår PKI-systemer – der vil blive oprettet en hændelse, når en PKI-server lukkes ned eller genstartes
·sikkerhedsforvaltning (succesfulde og ikke succesfulde forsøg på adgang til PKI-systemet, handlinger udført på PKI- og sikkerhedssystemet, systemnedbrud, hardwaresvigt og andre uregelmæssigheder, firewall- og routeraktiviteter samt adgang til og udgang fra PKI-faciliteter)
·hændelsesrelaterede data vil blive opbevaret i mindst fem år, medmindre der gælder yderligere nationale regler.
(242)I overensstemmelse med GDPR må revisionslogfilerne ikke give adgang til privatlivsrelaterede data vedrørende private C-ITS-stationskøretøjer.
(243)Sikkerhedsrevisionslogfiler skal indsamles automatisk, hvor det er muligt. Hvor det ikke er muligt, skal der anvendes en logbog, papirformular eller anden fysisk mekanisme. Alle sikkerhedsrevisonslogfiler, både elektroniske og ikke-elektroniske, skal beholdes og gøres tilgængelige i forbindelse med overensstemmelsesrevisioner.
(244)Hver hændelse relateret til et certifikats livscyklus logges på en sådan måde, at den kan tilskrives den person, der udførte den. Alle data vedrørende personlig identitet er krypteret og beskyttet mod uautoriseret adgang.
(245)Hver revisionsoptegnelse indeholder følgende (registreret automatisk eller manuelt for hver reviderbar hændelse):
·type hændelse (som fra ovenstående liste)
·betroet dato og klokkeslæt, hvor hændelsen fandt sted
·resultat af hændelsen – succes eller mislykket, hvor det er relevant
·identiteten på den entitet og/eller operatør, der forårsagede hændelsen, hvis det er relevant
·identiteten på den entitet, som hændelsen er henvendt til.
5.4.2.Hyppighed af behandlingslog
(246)Revisionslogfiler skal gennemgås som svar på varslinger baseret på uregelmæssigheder og hændelser i CA-systemerne og derudover regelmæssigt hvert år.
(247)Revisionslogbehandlingen skal bestå af en gennemgang af revisionslogfilerne og dokumentere årsagen til alle væsentlige hændelser i en revisionslogopsummering. Revisionsloggennemgange skal indeholde en verificering af, at loggen ikke er forfalsket, en inspektion af alle logindtastninger og en undersøgelse af alle varslinger og uregelmæssigheder i logfilerne. Foranstaltninger truffet på baggrund af revisionsloggennemgange skal dokumenteres.
(248)Revisionsloggen arkiveres mindst én gang om ugen. En administrator skal arkivere den manuelt, hvis den frie diskplads til revisionslogfiler er under den forventede størrelse på revisionslogdata produceret den pågældende uge.
5.4.3.Opbevaringsperiode for revisionslog
(249)Logoptegnelser vedrørende certifikaters livscyklusser opbevares i mindst fem år, efter det tilsvarende certifikat udløber.
5.4.4.Beskyttelse af revisionslog
(250)Revisionsloggens integritet og fortrolighed garanteres af en rollebaseret adgangskontrolmekanisme. Interne revisionslogfiler må kun tilgås af administratorer; revisionslogfiler vedrørende certifikaters livscyklusser kan også tilgås af brugere med den relevante autorisation via en webside med brugerlogin. Adgang skal tildeles med autentifikation fra flere brugere (mindst to brugere) og på mindst to niveauer. Det skal sikres teknisk, at brugere ikke kan få adgang til deres egne logfiler.
(251)Hver logindtastning skal underskrives med nøglemateriale fra HSM.
(252)Hændelseslogfiler, der indeholder oplysninger, som kan føre til personlig identifikation, såsom et privat køretøj, er krypteret på en sådan måde, at kun autoriserede personer kan læse dem.
(253)Hændelser registreres på en sådan måde, at de ikke let kan slettes eller destrueres (undtagen ved overførsel til langtidsmedier) i den periode, hvori logfilerne skal opbevares.
(254)Hændelseslogfiler beskyttes på en sådan måde, at de forbliver læselige i hele deres opbevaringsperiode.
5.4.5.Procedurer for sikkerhedskopiering af revisionslog
(255)Revisionslogfiler og opsummeringer sikkerhedskopieres via virksomhedens sikkerhedskopieringsmekanismer under kontrol af autoriserede betroede roller, adskilt fra deres komponentkildeoprettelse. Sikkerhedskopier af revisionslogfiler beskyttes med samme niveau af tillid som det, der gælder for de oprindelige logfiler.
5.4.6.Revisionsindsamlingssystem (internt eller eksternt)
(256)Udstyret til C-ITS-tillidsmodellens elementer skal aktivere revisionsprocesserne ved systemopstart og kun deaktivere dem ved systemnedlukning. Hvis revisionsprocesser ikke er tilgængelige, skal C-ITS-tillidsmodellens element suspendere sin drift.
(257)Når hver driftsperiode er slut, og ved genindlæsning af certifikater, bør udstyrets samlede status rapporteres til driftslederen og det styrende driftsorgan for det respektive PKI-element.
5.4.7.Meddelelse til hændelsesforårsagende subjekt
(258)Hvis en hændelse er logget af revisionsindsamlingssystemet, garanterer det, at hændelsen er tilknyttet en betroet rolle.
5.4.8.Sårbarhedsvurdering
(259)Den rolle, der står i spidsen for at udføre revisioner, og de roller, der står i spidsen for at realisere PKI-systemdrift i C-ITS-tillidsmodellens elementer, forklarer alle væsentlige hændelser i en revisionslogopsummering. Sådanne gennemgange involverer verificering af, at loggen ikke er blevet forfalsket, og at der ikke er manglende kontinuitet eller andet tab af revisionsdata, og derefter et kort eftersyn af alle logindtastninger og en mere grunding undersøgelse af alle varslinger eller uregelmæssigheder i logfilerne. Foranstaltninger, der træffes som følge af disse gennemgange, dokumenteres.
(260)C-ITS-tillidsmodellens elementer skal:
·implementere organisatoriske og/eller tekniske detektions- og forebyggelseskontroller under kontrollen af C-ITS-tillidsmodellens elementer for at beskytte PKI-systemet mod vira og skadelig software
·dokumentere og følge en sårbarhedskorrektionsproces, der håndterer identifikation af, gennemgang af, svar på og afhjælpning af sårbarheder
·gennemgå eller foretage en sårbarhedsscanning:
·efter alle system- eller netværksændringer fastslået af C-ITS-tillidsmodellens elementer som værende væsentlige for PKI-komponenter samt
·mindst én gang om måneden på offentlige eller private IP-adresser identificeret som PKI'ens systemer af CA'en og CPOC'et,
·gennemgå en indtrængningstest på PKI'ens systemer som minimum på årlig basis og efter infrastrukturs- eller applikationsopgraderinger eller ændringer, som C-ITS-tillidsmodellens elementer har fastslået som værende væsentlige for CA'ens PKI-komponent
·for onlinesystemer registrere beviser på, at hver sårbarhedsscanning og indtrængningstest blev udført af en person eller entitet (eller samlet gruppe af disse) med de nødvendige færdigheder, værktøjer, kompetencer, etiske principper og uafhængighed til at udføre en pålidelig sårbarheds- eller indtrængningstest
·spore og afhjælpe sårbarheder i overensstemmelse med virksomhedens politikker for cybersikkerhed og metoder til risikoreduktion.
5.5.Arkivering af optegnelser
5.5.1.Typer af arkiverede optegnelser
(261)C-ITS-tillidsmodellens elementer skal arkivere optegnelser, der er detaljerede nok til at fastslå gyldigheden af en signatur og af PKI'ens korrekte drift. Som minimum skal følgende PKI-hændelsesoptegnelser arkiveres (hvis det er relevant):
·log over C-ITS-tillidsmodellens elementers fysiske adgang til faciliteten (mindst ét år)
·log over forvaltning af betroede roller for C-ITS-tillidsmodellens elementer (mindst 10 år)
·log over IT-adgang for C-ITS-tillidsmodellens elementer (mindst fem år)
·log over oprettelse, brug og destruktion af CA-nøgler (mindst fem år) (ikke for TLM og CPOC)
·log over oprettelse, brug og destruktion af certifikater (mindst to år)
·log over CPA-anmodninger (mindst to år)
·log over forvaltning af aktiveringsdata for C-ITS-tillidsmodellens elementer (mindst fem år)
·log over IT og netværk for C-ITS-tillidsmodellens elementer (mindst fem år)
·log over PKI-dokumentation for C-ITS-tillidsmodellens elementer (mindst fem år)
·sikkerhedshændelses- og revisionsrapport for C-ITS-tillidsmodellens elementer (mindst 10 år)
·systemudstyr, software og konfiguration (mindst fem år)
(262)C-ITS-tillidsmodellens elementer skal opbevare følgende dokumentation vedrørende certifikatanmodninger og verificeringen deraf samt alle TLM-, rod-CA- og CA-certifikater og deres CRL'er i mindst syv år, efter et hvilket som helst certifikat baseret på denne dokumentation holder op med at være gyldigt:
·PKI-revisionsdokumentation opbevaret af C-ITS-tillidsmodellens elementer
·CPS-dokumenter opbevaret af C-ITS-tillidsmodellens elementer
·kontrakt mellem CPA'en og andre entiteter opbevaret af C-ITS-tillidsmodellens elementer
·certifikater (eller andre tilbagekaldelsesoplysninger) opbevaret af CA'en og TLM'en
·optegnelser over certifikatanmodninger i rod-CA-systemet (ikke relevant for TLM'en)
·andre data eller applikationer, der er tilstrækkelige til at verificere arkivindhold
·alt arbejde relateret til eller fra C-ITS-tillidsmodellens elementer og overensstemmelsesrevisorer.
(263)CA-entiteten skal opbevare al dokumentation vedrørende certifikatanmodninger og verificeringen deraf samt alle certifikater og tilbagekaldelser deraf i mindst syv år, efter et hvilket som helst certifikat baseret på denne dokumentation holder op med at være gyldigt.
5.5.2.Opbevaringsperiode for arkiv
(264)Med forbehold af forordninger, der kræver en længere arkiveringsperiode, skal C-ITS-tillidsmodellens elementer opbevare alle optegnelser i mindst fem år, efter det tilsvarende certifikat er udløbet.
5.5.3.Beskyttelse af arkiv
(265)C-ITS-tillidsmodellens elementer skal opbevare arkivet med optegnelser på en sikker, forsvarlig opbevaringsfacilitet, som er adskilt fra CA-udstyret, og som har fysiske og proceduremæssige sikkerhedskontrolforanstaltninger svarende til eller bedre end PKI'ens.
(266)Arkivet skal være beskyttet mod uautoriseret visning, ændring, sletning eller andre former for forfalskning ved opbevaring i et sikkert system.
(267)De medier, der opbevarer de arkivdata og applikationer, der er nødvendige for at behandle dem, skal bibeholdes for at sikre, at de kan tilgås i den periode, der er angivet i denne CP.
5.5.4.Systemarkiv og -opbevaring
(268)C-ITS-tillidsmodellens elementer skal trinvist sikkerhedskopiere systemarkiver med sådanne oplysninger dagligt og lave komplette sikkerhedskopier ugentligt. Kopier af papirbaserede optegnelser skal bibeholdes på en sikker ekstern facilitet.
5.5.5.Krav til tidsstempling af optegnelser
(269)Elementer af C-ITS-tillidsmodellen, som administrerer en tilbagekaldelsesdatabase, skal sikre, at optegnelserne indeholder oplysninger om det klokkeslæt og den dato, hvor tilbagekaldelsesoptegnelserne blev oprettet. Integriteten af sådanne oplysninger vil blive implementeret med kryptografibaserede løsninger.
5.5.6.Arkivindsamlingssystem (internt eller eksternt)
(270)Arkivindsamlingssystemet er internt.
5.5.7.Procedurer til indhentning og verificering af arkivoplysninger
(271)Alle C-ITS-tillidsmodellens elementer må kun give autoriserede betroede personer adgang til arkivet. Rod-CA'er og CA'er skal beskrive procedurerne for oprettelse, verificering, pakning, overførsel og opbevaring af arkivoplysninger i CPS'en.
(272)Rod-CA- og CA-udstyr skal verificere integriteten af oplysningerne, før de gemmes igen.
5.6.Nøgleombytning for C-ITS-tillidsmodellens elementer
(273)Følgende elementer af C-ITS-tillidsmodellen har specifikke krav til deres nøgleombytning: TLM-, rod-CA- og EA-/AA-certifikater.
5.6.1.TLM
(274)TLM'en skal slette sin private nøgle ved udløbet af det tilsvarende certifikat. Den skal generere et nyt nøglepar og et tilsvarende TLM-certifikat, før den aktuelle, gyldige private nøgle deaktiveres. Den skal sørge for, at det nye (link-)certifikat indsættes i ECTL'en, så det kan nå at blive distribueret til alle C-ITS-stationer, før det bliver gyldigt. Linkcertifikatet og det nye selv-underskrevne certifikat overføres til CPOC'et.
5.6.2.Rod-CA
(275)Rod-CA'en skal deaktivere og slette den aktuelle private nøgle (herunder sikkerhedskopierede nøgler), så den ikke udsteder EA-/AA-certifikater med en gyldighed, der strækker sig ud over rod-CA-certifikatets gyldighed.
(276)Rod-CA'en skal generere et nyt nøglepar og tilsvarende rod-CA- og linkcertifikat før deaktivering af den aktuelle private nøgle (herunder sikkerhedskopierede nøgler) og sende det til TLM'en til indsættelse i ECTL'en. Gyldighedsperioden for det nye rod-CA-certifikat skal starte ved den planlagte deaktivering af den aktuelle private nøgle. Rod-CA'en skal sørge for, at det nye certifikat indsættes i ECTL'en, så det kan nå at blive distribueret til alle C-ITS-stationer, før det bliver gyldigt.
(277)Rod-CA'en skal aktivere den nye private nøgle, når det tilsvarende rod-CA-certifikat bliver gyldigt.
5.6.3.EA-/AA-certifikat
(278)EA'en/AA'en skal deaktivere den aktuelle private nøgle, så den ikke udsteder EC'er/AT'er med en gyldighed, der strækker sig ud over EA'ens/AA'ens gyldighed.
(279)EA'en/AA'en skal generere et nyt nøglepar og anmode om et tilsvarende EA-/AA-certifikat, før den aktuelle private nøgle deaktiveres. Gyldighedsperioden for det nye EA-/AA-certifikat skal starte ved den planlagte deaktivering af den aktuelle private nøgle. EA'en/AA'en skal sørge for, at det nye certifikat offentliggøres, så det kan nå at blive distribueret til alle C-ITS-stationer, før det bliver gyldigt.
(280)EA'en/AA'en skal aktivere den nye private nøgle, når det tilsvarende EA-/AA-certifikat bliver gyldigt.
5.6.4.Revisor
Ingen bestemmelser.
5.7.Kompromittering og katastrofeberedskab
5.7.1.Håndtering af hændelser og kompromitteringer
(281)C-ITS-tillidsmodellens elementer skal overvåge deres udstyr løbende, så de kan detektere potentielle hackingforsøg eller andre former for kompromittering. Ved en sådan hændelse skal de undersøge med henblik på at fastslå skadens art og omfang.
(282)Hvis det personale, der har ansvaret for forvaltningen af rod-CA'en eller TLM'en, detekterer et potentielt hackingforsøg eller en anden form for kompromittering, skal de undersøge dette med henblik på at fastslå skadens art og omfang. Hvis den private nøgle kompromitteres, skal rod-CA-certifikatet tilbagekaldes. CPA'ens IT-sikkerhedseksperter skal vurdere omfanget af den potentielle skade for at fastslå, hvorvidt PKI'en skal genopbygges, hvorvidt det blot er nogle af certifikaterne, der skal tilbagekaldes, og/eller hvorvidt PKI'en er kompromitteret. CPA'en fastslår derudover, hvilke tjenester, der skal bibeholdes (oplysninger om tilbagekaldelse og certifikatstatus), samt hvordan, i henhold til CPA'ens plan for forretningskontinuitet.
(283)Hændelser, kompromitteringer og forretningskontinuitet er dækket i CPS'en, som muligvis også forlader sig på andre virksomhedsressourcer og -planer for implementeringen.
(284)Hvis det personale, der har ansvaret for forvaltningen af EA'en/AA'en/CPOC'et, detekterer et potentielt hackingforsøg eller en anden form for kompromittering, skal de undersøge dette med henblik på at fastslå skadens art og omfang. Det personale, der har ansvaret for forvaltningen af CA- eller CPOC-entiteten, skal vurdere omfanget af den potentielle skade for at fastslå, hvorvidt PKI-komponenten skal genopbygges, hvorvidt det blot er nogle af certifikaterne, der skal tilbagekaldes, og/eller hvorvidt PKI-komponenten er kompromitteret. Derudover fastslår sub-CA-entiteten, hvilke tjenester der skal bibeholdes, samt hvordan, i henhold til sub-CA-entitetens plan for forretningskontinuitet. Hvis en PKI-komponent er kompromitteret, skal CA-entiteten underrette sin egen rod-CA og TLM'en via CPOC'et.
(285)Hændelser, kompromitteringer og forretningskontinuitet er dækket i rod-CA'ens eller TLM'ens CPS eller andre relevante dokumenter, hvad angår CPOC'et, som også muligvis forlader sig på andre virksomhedsressourcer og -planer for deres implementering.
(286)Rod-CA'en og CA'en skal med præcise oplysninger omkring hændelsens konsekvenser underrette hver medlemsstatsrepræsentant og rod-CA, som de har en aftale med i C-ITS-kontekst, for at give dem mulighed for at aktivere deres egen plan for hændelseshåndtering.
5.7.2.Korruption af computerressourcer, software og/eller data
(287)Hvis der opdages en katastrofe, som forhindrer korrekt drift af et af elementerne i C-ITS-tillidsmodellen, skal dette element suspendere sin drift og undersøge, hvorvidt den private nøgle er blevet kompromitteret (undtagen CPOC). Defekt hardware skal udskiftes så hurtigt som muligt efter procedurerne beskrevet i afsnit 5.7.3 og 5.7.4.
(288)Korruption af computerressourcer, software og/eller data skal rapporteres til rod-CA'en inden for 24 timer for de højeste risikoniveauer. Alle andre hændelser skal medtages i den periodiske rapport for rod-CA'en, EA'erne og AA'erne.
5.7.3.Procedurer for kompromittering af entiteters private nøgler
(289)Hvis en rod-CA's private nøgle kompromitteres, mistes, destrueres eller mistænkes for at være kompromitteret, skal rod-CA'en:
·afbryde sin drift
·starte katastrofeberedskabs- og migrationsplanen
·tilbagekalde sit rod-CA-certifikat
·undersøge "nøgleproblemet", der genererede kompromitteringen og give besked til CPA'en, som vil tilbagekalde rod-CA-certifikatet via TLM'en (se afsnit 7)
·underrette alle abonnenter, som den har en aftale med.
(290)Hvis en EA's/AA's nøgle kompromitteres, mistes, destrueres eller mistænkes for at være kompromitteret, skal EA'en/AA'en:
·afbryde sin drift
·tilbagekalde sit eget certifikat
·undersøge "nøgleproblemet" og give besked til rod-CA'en
·underrette abonnenter, som der eksisterer en aftale med.
(291)Hvis en C-ITS-stations EC- eller AT-nøgle kompromitteres, mistes, destrueres eller mistænkes for at være kompromitteret, skal den EA/AA, som C-ITS-stationen er tilmeldt:
·tilbagekalde EC'en for den påvirkede ITS
·undersøge "nøgleproblemet" og give besked til rod-CA'en
·give besked til abonnenter, som den har en aftale med.
(292)Hvis nogen af algoritmerne eller de tilknyttede parametre, der anvendes af rod-CA'en og/eller CA'en eller C-ITS-stationerne, blive utilstrækkelige til deres resterende tiltænkte brug, skal CPA'en (med en anbefaling fra kryptografieksperter) informere den rod-CA-entitet, som den har en aftale med, og ændre de anvendte algoritmer. (Se afsnit 6 og CPS'erne for rod-CA'en og sub-CA'en for detaljer).
5.7.4.Evne til forretningskontinuitet efter en katastrofe
(293)Elementer i C-ITS-tillidsmodellen, der driver sikre faciliteter til CA-drift, skal udvikle, teste, opretholde og implementere en katastrofeberedskabsplan beregnet til at afbøde virkningen af enhver form for naturlig eller menneskeskabt katastrofe. Sådanne planer adresserer genoprettelsen af informationssystemtjenester og primære forretningsfunktioner.
(294)Efter en hændelse på et vist risikoniveau skal den kompromitterede CA revideres igen af en akkrediteret PKI-revisor (se afsnit 8).
(295)Hvis den kompromitterede CA ikke er i stand til at operere længere (f.eks. efter en alvorlig hændelse), skal der udarbejdes en migreringsplan for overførslen af dens funktioner til en anden rod-CA. Som minimum skal EU-rod-CA'en stå til rådighed til understøttelse af migreringsplanen. Den kompromitterede CA skal standse sine funktioner.
(296)Rod-CA'erne skal medtage katastrofeberedskabsplanen og migreringsplanen i CPS'en.
5.8.Afslutning og overførsel
5.8.1.TLM
(297)TLM'en skal ikke afslutte sin drift, men en entitet, der administrerer TLM'en kan overtage en anden entitet.
(298)Hvis den administrerende entitet ændres:
·skal den anmode om CPA'ens godkendelse af en ændring af TLM-forvaltningen fra den gamle entitet til den nye entitet
·skal CPA'en godkende ændringen af TLM-forvaltningen
·skal alle revisionslogfiler og arkiverede optegnelser overføres fra den gamle forvaltningsentitet til den nye entitet.
5.8.2.Rod-CA
(299)Rod-CA'en skal ikke afslutte/starte driften uden at fastlægge en migreringsplan (beskrevet i den relevante CPS), der garanterer fortsat drift for alle abonnenter.
(300)Hvis rod-CA-tjenesten afsluttes, skal rod-CA'en:
·give besked til CPA'en
·give besked til TLM'en, så den kan slette rod-CA-certifikatet fra ECTL'en
·tilbagekalde den tilsvarende rod-CA ved at udstede en CRL, der indeholder rod-CA'en selv
·underrette rod-CA'er, med hvilke den har en aftale om fornyelse af EA-/AA-certifikater
·destruere rod-CA'ens private nøgle
·kommunikere de sidste oplysninger om tilbagekaldelsesstatus (CRL underskrevet af rod-CA) til signaturmodtageren, hvor det tydeligt angives, at det er de seneste tilbagekaldelsesoplysninger
·arkivere alle revisionslogfiler og andre optegnelser inden afslutning af PKI'en
·overføre arkiverede optegnelser til en passende myndighed.
(301)TLM'en skal slette det tilsvarende rod-CA-certifikat fra ECTL'en.
5.8.3.EA/AA
(302)Hvis EA-/AA-tjenesten afsluttes, giver EA-/AA-entiteten besked inden afslutningen. En EA eller AA skal ikke afslutte/starte driften uden at fastlægge en migreringsplan (beskrevet i den relevante CPS), der garanterer fortsat drift for alle abonnenter. EA'en/AA'en skal:
·informere rod-CA'en via anbefalet brev
·destruere CA'ens private nøgle
·overføre sin database til den entitet, der er udpeget af rod-CA'en
·stoppe udstedelse af certifikater
·bibeholde kapaciteten til at autorisere anmodninger fra den ansvarlige private myndighed under overførslen af sin database, og indtil databasen er helt funktionsdygtig i en ny entitet
·hvis en sub-CA er blevet kompromitteret, skal rod-CA'en tilbagekalde sub-CA'en og udstede en ny CRL med en liste over tilbagekaldte sub-CA'er
·arkivere alle revisionslogfiler og andre optegnelser inden afslutning af PKI'en
·overføre arkiverede optegnelser til en entitet, der er udpeget af rod-CA'en
(303)Hvis CA'ens tjenester afsluttes, skal CA'en have ansvaret for at beholde alle relevante optegnelser vedrørende CA- og PKI-komponenternes behov.
6.Tekniske sikkerhedskontroller
6.1.Generering og installation af nøglepar
6.1.1.TLM, rod-CA, EA, AA
(304)Processen for generering af nøglepar skal opfylde følgende krav:
·hver deltager skal være i stand til at generere sine egne nøglepar i henhold til afsnit 6.1.4 og 6.1.5
·processen for afledning af symmetriske krypteringsnøgler og en MAC-nøgle til certifikatanmodninger (ECIES) skal udføres i overensstemmelse med [1] og [5]
·processen for nøglegenerering skal anvende de algoritmer og nøglelængder, der er beskrevet i afsnit 6.1.4.1 og 6.1.4.2
·processen for generering af nøglepar skal være underlagt kravene for "sikker opbevaring af private nøgler" (se afsnit 6.1.5)
·rod-CA'erne og deres abonnenter (sub-CA'er) skal sikre, at integriteten og ægtheden af deres offentlige nøgler og alle tilknyttede parametre bibeholdes under distribution af sub-CA-registrerede entiteter
6.1.2.EE — mobil C-ITS-station
(305)Hver mobil C-ITS-station skal generere sine egne nøglepar i henhold til afsnit 6.1.4 og 6.1.5.
(306)Processen for afledning af symmetriske krypteringsnøgler og en MAC-nøgle til certifikatanmodninger (ECIES) skal udføres i overensstemmelse med [1] og [5]
(307)Processerne for nøglegenerering skal anvende de algoritmer og nøglelængder, der er beskrevet i afsnit 6.1.4.1 og 6.1.4.2.
(308)Processerne for generering af nøglepar skal være underlagt kravene for "sikker opbevaring af private nøgler" (se afsnit 6.1.5).
6.1.3.EE — fast C-ITS-station
(309)Hver fast C-ITS-station skal generere sit eget nøglepar i henhold til afsnit 6.1.4 og 6.1.5.
(310)Processerne for nøglegenerering skal anvende de algoritmer og nøglelængder, der er beskrevet i afsnit 6.1.4.1 og 6.1.4.2.
(311)Processerne for generering af nøglepar skal være underlagt kravene for "sikker opbevaring af private nøgler" (se afsnit 6.1.5).
6.1.4.Kryptografiske krav
(312)Alle PKI-deltagere skal opfylde de kryptografiske krav, der er beskrevet i de følgende afsnit, hvad angår signaturalgoritme, nøglelængde, generator for tilfældige tal og linkcertifikater.
6.1.4.1.Algoritme og nøglelængde — signaturalgoritmer
(313)Alle PKI-deltagere (TLM, rod-CA, EA, AA og C-ITS-stationer) skal være i stand til at generere nøglepar og anvende den private nøgle til at underskrive operationer med udvalgte algoritmer senest to år efter denne forordnings ikrafttræden i henhold til tabel 4.
(314)Alle PKI-deltagere, som skal kontrollere integriteten af ECTL'en, certifikater og/eller underskrevne meddelelser i henhold til deres rolle som defineret i afsnit 1.3.6, skal understøtte de tilsvarende algoritmer angivet i tabel 5 til verificering. Navnlig skal C-ITS-stationer være i stand til at kontrollere ECTL'ens integritet.
|
TLM
|
rod-CA
|
EA
|
AA
|
C-ITS-station
|
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 angiver obligatorisk støtte
|
Tabel 4: Generering af nøglepar og anvendelse af privat nøgle til underskrivning af operationer
|
TLM
|
rod-CA
|
EA
|
AA
|
C-ITS-station
|
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 angiver obligatorisk støtte
|
Tabel 5: Verificeringsoversigt
(315)Hvis CPA'en på baggrund af nyligt fundne kryptografiske svagheder beslutter det, skal alle C-ITS-stationer være til stand til at skifte til én af de to algoritmer (ECDSA_nistP256_with_SHA 256 eller ECDSA_brainpoolP256_with_SHA 256) så hurtigt som muligt. De(n) faktiske algoritme(r), der anvendes, skal fastslås i CPS'en for den CA, der udsteder certifikatet for den tilsvarende offentlige nøgle i henhold til denne CP.
6.1.4.2.Algoritme og nøglelængde — krypteringsalgoritmer for indskrivning og autorisation
(316)Alle PKI-deltagere (EA, AA og C-ITS-stationer) skal være i stand til at anvende offentlige nøgler til kryptering af indskrivnings- og autorisationsanmodninger/-svar med udvalgte algoritmer senest to år efter denne forordnings ikrafttræden i henhold til tabel 6. De(n) faktiske algoritme(r), der anvendes, skal fastslås i CPS'en for den CA, der udsteder certifikatet for den tilsvarende offentlige nøgle i henhold til denne CP.
(317)De nævnte algoritmer i tabel 6 angiver nøglelængden og nummertegnsalgoritmelængden og skal implementeres i henhold til [5].
|
TLM
|
rod-CA
|
EA
|
AA
|
C-ITS-station
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
X angiver obligatorisk støtte
|
Tabel 6: Anvendelse af offentlige nøgler til kryptering af indskrivnings- og autorisationsanmodninger/-svar
(318)Alle PKI-deltagere (EA, AA og C-ITS-stationer) skal være i stand til at generere nøglepar og anvende den private nøgle til dekryptering af indskrivnings- og autorisationsanmodninger/-svar med udvalgte algoritmer senest to år efter denne forordnings ikrafttræden i henhold til tabel 7:
|
TLM
|
rod-CA
|
EA
|
AA
|
C-ITS-station
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
X angiver obligatorisk støtte
|
Tabel 7: Generering af nøglepar og anvendelse af privat nøgle til dekryptering af indskrivnings- og autorisationsanmodninger/-svar
6.1.4.3.Krypto-agilitet
(319)Krav til nøglelængder og algoritmer skal ændres over tid for at opretholde et passende sikkerhedsniveau. CPA'en skal overvåge behovet for sådanne ændringer med hensyn til faktiske sårbarheder og den mest avancerede kryptografi. Den vil udarbejde et udkast, godkende og offentliggøre en opdatering af denne certifikatpolitik, hvis den beslutter, at de kryptografiske algoritmer skal opdateres. Hvis en ny udgave af denne CP signalerer en ændring af algoritmen og/eller nøglelængden, vil CPA'en indføre en migreringsstrategi, som indeholder overgangsperioder, hvorunder gamle algoritmer og nøglelængder skal understøttes.
(320)For at muliggøre og fremme overførslen af nye algoritmer og/eller nøglelængder anbefales det, at alle PKI-deltagere implementerer hardware og/eller software, som er i stand til at ombytte nøglelængder og algoritmer.
(321)Ændringer af rod- og TLM-certifikater skal understøttes og udføres ved hjælp af linkcertifikater (se afsnit 4.6), som anvendes til at dække overgangsperioden mellem de gamle og nye rodcertifikater ("migrering af tillidsmodellen").
6.1.5.Sikker opbevaring af private nøgler
Dette afsnit beskriver kravene til sikker opbevaring og generering af nøglepar og tilfældige tal til CA'er og slutentiteter. Disse krav er defineret for kryptografiske moduler og beskrevet i følgende underafsnit.
6.1.5.1.Rod-CA-, sub-CA- og TLM-niveau
(322)Et kryptografisk modul skal anvendes til:
·generering, anvendelse, forvaltning og opbevaring af private nøgler
·generering og anvendelse af tilfældige tal (vurdering af funktionen til generering af tilfældige tal skal være en del af sikkerhedsevalueringen og -certificeringen)
·oprettelse af sikkerhedskopier af private nøgler i henhold til afsnit 6.1.6
·sletning af private nøgler.
Det kryptografiske modul skal være certificeret med én af følgende beskyttelsesprofiler (PP'er) med sikringsniveau EAL-4 eller højere:
·PP'er for HSM'er:
·CEN EN 419 221-2: Beskyttelsesprofiler til kryptografiske TSP-moduler — Del 2: Kryptografisk modul for CSP-underskrivningsoperationer med sikkerhedskopi
·CEN EN 419 221-4: Beskyttelsesprofiler til kryptografiske TSP-moduler — Del 4: Kryptografisk modul for CSP-underskrivningsoperationer uden sikkerhedskopi
·CEN EN 419 221-5: Beskyttelsesprofiler til kryptografiske TSP-moduler — Del 5: Kryptografisk modul til tillidstjenester
·PP'er for smartcards:
·CEN EN 419 211-2: Beskyttelsesprofiler til sikker signaturoprettelsesenhed — Del 2: Enhed med nøglegenerering
·CEN EN 419 211-3: Beskyttelsesprofiler til sikker signaturoprettelsesenhed — Del 3: Enhed med nøgleimport.
Manuel adgang til det kryptografiske modul skal kræve tofaktorgodkendelse af administratoren. Dette skal desuden kræve involvering af to autoriserede personer.
Implementering af et kryptografisk modul skal sikre, at nøglerne ikke kan tilgås uden for det kryptografiske modul. Det kryptografiske modul skal indeholde en adgangskontrolmekanisme for at undgå uautoriseret brug af private nøgler.
6.1.5.2.Slutentitet
(323)Et kryptografisk modul for EE'er skal anvendes til:
·generering, anvendelse, forvaltning og opbevaring af private nøgler
·generering og anvendelse af tilfældige tal (vurdering af funktionen til generering af tilfældige tal skal være en del af sikkerhedsevalueringen og -certificeringen)
·sikker sletning af en privat nøgle.
(324)Det kryptografiske modul skal beskyttes mod uautoriseret fjernelse, udskiftning og ændring. Alle PP'er og relaterede dokumenter, der er relevante for sikkerhedscertificeringen af det kryptografiske modul, skal evalueres, valideres og certificeres i henhold til ISO 15408 ved anvendelse af Gruppen af Højtstående Embedsmænd vedrørende Informationssystemers Sikkerheds (SOG-IS) aftale om gensidig anerkendelse af sikkerhedsevalueringscertifikater for informationssikkerhed eller en tilsvarende europæisk certificeringsordning for cybersikkerhed under de relevante europæiske cybersikkerhedsrammer.
(325)På grund af vigtigheden af at opretholde det højest mulige sikkerhedsniveau skal sikkerhedscertifikater for det kryptografiske modul udstedes i henhold til certificeringsordningen for fælles kriterier (ISO 15408) af et overensstemmelsesvurderingsorgan anerkendt af forvaltningsudvalget for SOG-IS-aftalen eller udstedt af overensstemmelsesvurderingsorgan, der er akkrediteret af en medlemsstats nationale cybersikkerhedscertificeringsmyndighed. Et sådant overensstemmelsesvurderingsorgan skal som minimum give tilsvarende betingelser for sikkerhedsevaluering som omhandlet i SOG-IS-aftalen om gensidig anerkendelse.
Bemærk: Forbindelsen mellem det kryptografiske modul og C-ITS-stationen skal beskyttes.
6.1.6.Sikkerhedskopiering af private nøgler
(326)Generering, opbevaring og anvendelse af sikkerhedskopier af private nøgler skal som minimum opfylde kravene for det sikkerhedsniveau, der kræves for de oprindelige nøgler.
(327)Sikkerhedskopier af private nøgler skal foretages af rod-CA'er, EA'er og AA'er.
(328)Sikkerhedskopier af private nøgler skal ikke foretages for EC'er og AT'er.
6.1.7.Destruktion af private nøgler
(329)Rod-CA'erne, EA'erne, AA'erne og de mobile og faste C-ITS-stationer skal destruere deres private nøgle og alle tilsvarende sikkerhedskopier, hvis et nyt nøglepar og et tilsvarende certifikat er blevet genereret og installeret med succes, og overlapningstiden (hvis der er nogen — kun CA) er gået. Den private nøgle skal destrueres ved hjælp af den mekanisme, der tilbydes af det kryptografiske modul og anvendes til nøgleopbevaring eller som beskrevet i den tilsvarende PP, der henvises til i afsnit 6.1.5.2.
6.2.Aktiveringsdata
(330)Aktiveringsdata henviser til autentifikationsfaktorer, der er nødvendige for at drive kryptografiske moduler for at undgå uautoriseret adgang. Anvendelsen af aktiveringsdataene på en CA's kryptografiske enhed skal kræve handling fra to autoriserede personer.
6.3.Computersikkerhedskontroller
(331)CA'ens computersikkerhedskontroller skal være udviklet i overensstemmelse med det højeste sikkerhedsniveau ved at overholde kravene i ISO/IEC 27002.
6.4.Tekniske kontroller af livscyklus
(332)CA'ens tekniske kontroller skal dække hele CA'ens livscyklus. Navnlig skal dette inkludere kravene i afsnit 6.1.4.3 ("Krypto-agilitet").
6.5.Netværkssikkerhedskontroller
(333)CA'ernes (rod-CA, EA og AA) netværk skal forstærkes mod angreb i overensstemmelse med kravene og implementeringsretningslinjerne i ISO/IEC 27001 og ISO/IEC 27002.
(334)CA'ernes netværks tilgængelighed skal udvikles med henblik på den anslåede trafik.
7.Certifikatprofiler, CRL og CTL
7.1.Certifikatprofil
(335)Certifikatprofilerne defineret i [5] skal anvendes til TLM'en, rodcertifikaterne, EA-certifikaterne, AA-certifikaterne, AT'erne og EC'erne. Nationale statslige EA'er kan anvende andre certifikatprofiler til EC'er.
(336)Rod-CA-, EA- og AA-certifikater skal angive tilladelserne, for hvilke disse CA'er (rod-CA'er, EA'er og AA'er) har lov til at udstede certifikater.
(337)På baggrund af [5]:
·skal hver rod-CA anvende sin egen private underskrivningsnøgle til at udstede CRL'er
·skal TLM'en anvende sin egen private underskrivningsnøgle til at udstede ECTL'en.
7.2.Certifikatgyldighed
(338)Alle C-ITS-certifikatprofiler skal indeholde en udstedelses- og en udløbsdato, som repræsenterer certifikatets gyldighedsperiode. På hvert PKI-niveau skal certifikater genereres i god tid inden udløb.
(339)Gyldighedsperioden for CA- og EC-certifikater skal indeholde en overlapningsperiode. TLM- og rod-CA-certifikater skal udstedes og placeres på ECTL'en i højst tre måneder og mindst én måned, før deres gyldighed begynder, baseret på certifikatets starttidspunkt. Denne fase til forudindlæsning er nødvendig for sikkert at kunne distribuere certifikaterne til alle tilsvarende signaturmodtagere i henhold til afsnit 2.2. Dette sikrer, at alle signaturmodtagere allerede er i stand til at verificere meddelelser udstedt med et nyt certifikat fra starten af overlapningsperioden.
(340)I starten af overlapningsperioden skal de efterfølgende CA-, EC- og AT-certifikater udstedet (hvis det er relevant), distribueres til og installeres af de tilsvarende signaturmodtagere. I løbet af overlapningsperioden skal det aktuelle certifikat kun anvendes til verificering.
(341)Da gyldighedsperioderne angivet i tabel 8 ikke må overskride det overordnede certifikat, gælder følgende begrænsninger:
·maksimalgyldighed(Rod-CA) = privatnøgleanvendelse(Rod-CA) + maksimalgyldighed(EA,AA)
·maksimalgyldighed(EA) = privatnøgleanvendelse(EA) + maksimalgyldighed(EC)
·maksimalgyldighed(AA) = privatnøgleanvendelse(AA) + maksimalgyldighed(AT)
(342)Gyldigheden af (rod- og TLM-) linkcertifikater starter ved anvendelsen af den tilsvarende private nøgle og slutter ved den maksimale gyldighedsperiode for rod-CA'en eller TLM'en.
(343)Tabel 8 viser den maksimale gyldighedsperioden for C-ITS CA-certifikater (se afsnit 7.2.1 for AT-gyldighedsperioder).
Entitet
|
Maksimal anvendelsesperiode for privat nøgle
|
Maksimal gyldighedsperiode
|
Rod-CA
|
3 år
|
8 år
|
EA
|
2 år
|
5 år
|
AA
|
4 år
|
5 år
|
EC
|
3 år
|
3 år
|
TLM
|
3 år
|
4 år
|
Tabel 8: Gyldighedsperioder for certifikaterne i C-ITS-tillidsmodellen
7.2.1.Pseudonymcertifikater
(344)I denne kontekst implementeres pseudonymer af AT'erne. Som følge heraf henviser dette afsnit til AT'er frem for pseudonymer.
(345)Kravene beskrevet i dette afsnit gælder kun for AT'er fra mobile C-ITS-stationer, der sender CAM- og DEMN-meddelelser, hvor risikoen ved lokationsfortrolighed er gældende. Ingen specifikke krav på AT-certifikater gælder for AT'er for faste C-ITS-stationer og mobile C-ITS-stationer, der anvendes til specifikke funktioner, hvor lokationsfortrolighed ikke er gældende (f.eks. afmærkede nød eller politikøretøjer).
(346)I denne forordning forstås ved:
·"gyldighedsperiode for AT'er" — perioden, hvori en AT er gyldig, dvs. perioden mellem AT'ens startdato og dens udløbsdato
·"forudindlæsningsperiode for AT'er" — forudindlæsning er den mulighed, C-ITS-stationer har for at indhente AT'er, før gyldighedsperioden starter. Forudindlæsningsperioden er den maksimalt tilladte tidsperiode fra anmodningen om AT'er til den seneste dato for gyldighedsophør for enhver anmodet AT
·"anvendelsesperiode for AT'er — perioden, hvori en AT anvendes effektivt til at underskrive CAM-/DEMN-meddelelser
·"maksimalt antal parallelle AT'er" — antallet af AT'er, hvorfra en C-ITS-station kan vælge når som helst, når den underskriver en CAM-/DEMN-meddelelse, dvs. antallet af forskellige AT'er udstedt til én C-ITS-station, som er gyldig på det pågældende tidspunkt.
(347)Følgende krav finder anvendelse:
·forudindlæsningsperioden for AT'er skal ikke overstige tre måneder
·gyldighedsperioden for AT'er skal ikke overstige én uge
·det maksimale antal parallelle AT'er skal ikke overstige 100 pr. C-ITS-station
·en AT's anvendelsesperiode afhænger af AT-ændringsstrategien og den tid, et køretøj er i drift, men er begrænset af det maksimale antal parallelle AT'er og gyldighedsperioden. Mere specifikt er en C-ITS-stations gennemsnitlige anvendelsesperiode som minimum køretøjets driftstid i løbet af én gyldighedsperiode divideret med det maksimale antal parallelle AT'er.
7.2.2.Autorisationsbilletter til faste C-ITS-stationer
(348)Definitionerne i afsnit 7.2.1 og de følgende krav finder anvendelse:
·forudindlæsningsperioden for AT'er skal ikke overstige tre måneder
·det maksimale antal parallelle AT'er skal ikke overstige to pr. C-ITS-station.
7.3.Tilbagekaldelse af certifikater
7.3.1.Tilbagekaldelse af CA-, EA- og AA-certifikater
Rod-CA-, EA- og AA-certifikater skal kunne tilbagekaldes. Tilbagekaldte certifikater fra CA'er, EA'er og AA'er skal offentliggøres på en CRL så hurtigt som muligt og uden unødig forsinkelse. Denne CRL skal underskrives af sin tilsvarende rod-CA og anvende profilen beskrevet i afsnit 7.4. Hvad angår tilbagekaldelse af rod-CA-certifikater, udsteder den tilsvarende rod-CA en CRL, der indeholder sig selv. I tilfælde med en sikkerhedskompromittering gælder desuden afsnit 5.7.3. Desuden skal TLM'en fjerne tilbagekaldte rod-CA'er fra tillidslisten og udstede en ny tillidsliste. Udløbne certifikater skal fjernes fra den tilsvarende CRL og tillidsliste.
(349)Certifikater tilbagekaldes, når:
·rod-CA'erne har årsag til at tro eller stærkt mistænker, at den tilsvarende private nøgle er blevet kompromitteret
·rod-CA'erne er blevet underrettet om, at kontrakten med abonnenten er blevet afbrudt
·oplysninger (såsom navn og tilknytning mellem CA og subjekt) i certifikatet er forkerte eller er blevet ændret
·der finder en sikkerhedshændelse sted, som påvirker certifikatets ejer
·en revision (se afsnit 8) fører til et negativt resultat.
(350)Abonnenten skal omgående give CA'en besked om en kendt eller mistænkt kompromittering af deres private nøgle. Det skal sikres, at kun autentificerede anmodninger fører til tilbagekaldte certifikater.
7.3.2.Tilbagekaldelse af indskrivningsoplysninger
(351)Tilbagekaldelse af EC'er kan påbegyndes af C-ITS-stationens abonnent (strøm 34) og skal implementeres af en intern sortliste i en tilbagekaldelsesdatabase med et tidsstempel, som genereres og opretholdes af hver EA. Sortlisten offentliggøres aldrig og skal holdes fortrolig og kun anvendes af den tilsvarende EA til at verificere validiteten af de tilsvarende EC'er i forbindelse med anmodninger om AT'er og nye EC'er.
7.3.3.Tilbagekaldelse af autorisationsbilletter
(352)Da AT'er ikke tilbagekaldes af de tilsvarende CA'er, skal de have en kort levetid, og de kan ikke udstedes for lang tid i forvejen, før de bliver gyldige. De tilladte parameterværdier for certifikatets livscyklus er angivet i afsnit 7.2.
7.4.Liste over certifikattilbagekaldelser
(353)Formatet og indholdet af den CRL, der er udstedt af rod-CA'er, skal være som beskrevet i [1].
7.5.Europæisk certifikattillidsliste
(354)Formatet og indholdet af den ECTL, der er udstedt af TLM'en, skal være som beskrevet i [1].
8.Overensstemmelsesrevision og andre vurderinger
8.1.Emner dækket af revision og revisionsgrundlag
(355)Formålet med en overensstemmelsesrevision er at verificere, at TLM'en, rod-CA'erne, EA'erne og AA'erne opererer i overensstemmelse med denne CP. TLM'en, rod-CA'erne, EA'erne og AA'erne skal vælge en udpeget fungerende og akkrediteret PKI-revisor til at revidere deres CPS. Revisionen skal kombineres med en vurdering af overensstemmelse med ISO/IEC 27001 og ISO/IEC 27002.
(356)En overensstemmelsesrevision bestilles af en rod-CA (strøm 13) til rod-CA'en selv og til en sub-CA af dens underordnede EA/AA.
(357)En overensstemmelsesrevision af TLM'en bestilles af CPA'en (strøm 38).
(358)Efter anmodning skal en akkrediteret PKI-revisor udføre en overensstemmelsesrevision på et af følgende niveauer:
(1)overensstemmelse af TLM'ernes, rod-CA'ernes, EA'ernes eller AA'ernes CPS med denne CP
(2)overensstemmelse af TLM'ernes, rod-CA'ernes, EA'ernes eller AA'ernes tilsigtede praksis med dens CPS inden drift
(3)overensstemmelse af TLM'ernes, rod-CA'ernes, EA'ernes eller AA'ernes praksis og operationelle aktiviteter med dens CPS under drift
(359)Revisionen skal dække alle krav i denne CP for at kunne opfyldes af de TLM'er, rod-CA'er, EA'er og AA'er, der skal revideres. Den skal også dække driften af CA'en i C-ITS PKI'en, herunder alle processer nævnt i dens CPS, præmisserne og de ansvarlige personer.
(360)Den akkrediterede PKI-revisor skal aflevere en detaljeret revisionsrapport til rod-CA'en (strøm 36), EA'en, AA'en eller CPA'en (strøm 16 og 40), alt efter hvad der er relevant.
8.2.Revisionernes hyppighed
(361)En rod-CA, TLM, EA eller AA skal bestille en overensstemmelsesrevision af sig selv fra en uafhængig og akkrediteret PKI-revisor i følgende tilfælde:
·ved første opsætning (overensstemmelsesniveau 1 og 2)
·ved hver ændring af CP'en. CPA'en skal følgeligt definere CP-ændringens indhold og tidsplanen for indførelsen og fastslå behovet for revisioner (herunder det nødvendige overensstemmelsesniveau)
·ved hver ændring af dens CPS (overensstemmelsesniveau 1, 2 og 3). Eftersom rod-CA'ernes, TLM'ernes og EA'ernes/AA'ernes administrerende entiteter beslutter, hvilke implementeringsændringer, der følger opdateringen af deres CPS, skal de bestille en overensstemmelsesrevision, før disse ændringer implementeres. I tilfælde med kun mindre ændringer af CPS'en (f.eks. af redaktionel karakter), kan den administrerende entitet sende CPS'en en behørigt retfærdiggjort anmodning om dens godkendelse for at springe over trin 1, 2 eller 3 i overensstemmelsesrevisionen
·regelmæssigt og mindst hvert tredje år i løbet af dens drift (overensstemmelsesniveau 3).
8.3.Revisorens identitet/kvalifikationer
(362)Den CA, der skal revideres, skal vælge en uafhængigt fungerende og akkrediteret virksomhed/organisation ("revisionsorgan") eller akkrediteret PKI-revisor til at revidere den i overensstemmelse med denne CP. Revisionsorganet skal være akkrediteret og certificeret af et medlem af Den Europæiske Organisation for Akkreditering.
8.4.Revisorens relation til den reviderede entitet
(363)Den akkrediterede PKI-revisor skal være uafhængig af den reviderede entitet.
8.5.Foranstaltninger, der træffes som følge af mangler
(364)Hvis en revisionsrapport finder, at TLM'en ikke overholder kravene, skal CPA'en bede TLM'en om at træffe øjeblikkelige forebyggende/korrigerende foranstaltninger.
(365)Hvis en rod-CA med en revisionsrapport, der ikke overholder kravene, udarbejder en ny ansøgning, skal CPA'en afvise ansøgningen og sende en tilsvarende afvisning til rod-CA'en (strøm 4). I sådanne tilfælde vil rod-CA'en blive suspenderet. Den skal foretage korrigerende foranstaltninger, bestille revisionen igen og udarbejde en ny ansøgning til CPA-godkendelse. Rod-CA'en skal ikke have tilladelse til at udstede certifikater under suspenderingen.
(366)I tilfælde med en almindelig rod-CA-revision eller en ændring af en rod-CA's CPS og afhængigt af karakteren af den manglende overholdelse beskrevet i revisionsrapporten kan CPA'en beslutte at tilbagekalde rod-CA'en og meddele denne beslutning til TLM'en (strøm 2), hvorved rod-CA-certifikatet slettes fra ECTL'en, og rod-CA'en indsættes på CRL'en. CPA'en skal sende en tilsvarende afvisning til rod-CA'en (strøm 4). Rod-CA'en skal foretage korrigerende foranstaltninger, bestille en fuld revision igen (niveau 1 til 3) og udarbejde en ny ansøgning til CPA-godkendelse. Alternativt kan CPA'en beslutte ikke at tilbagekalde rod-CA'en, men give den en toleranceperiode, hvor rod-CA'en skal træffe korrigerende foranstaltninger, bestille en ny revision og indsende revisionsrapporten til CPA'en igen. I dette tilfælde skal rod-CA'ens drift suspenderes, og den må ikke udstede certifikater og CRL'er.
(367)I tilfælde af en EA-/AA-revision skal rod-CA'en beslutte, hvorvidt den vil acceptere rapporten. Afhængigt af revisionsresultatet skal rod-CA'en beslutte, hvorvidt den vil tilbagekalde EA-/AA-certifikatet i overensstemmelse med reglerne i rod-CA'ens CPS. Rod-CA'en skal altid sikre EA'ens/AA'ens overholdelse af denne CP.
8.6.Meddelelse af resultater
(368)Rod-CA'en og TLM'en skal sende revisionsrapporten til CPA'en (strøm 16). Rod-CA'en og TLM'en skal opbevare alle revisionsrapporter, de har bestilt. CPA'en skal sende en tilsvarende godkendelse eller afvisning (strøm 4) til rod-CA'en og TLM'en.
(369)Rod-CA'en skal sende et overensstemmelsescertifikat til den tilsvarende EA/AA.
9.Andre bestemmelser
9.1.Afgifter
(370)Et af principperne i den implementerede EU C-ITS-tillidsmodel er, at rod-CA'erne sammen fuldstændigt finansierer de almindelige tilbagevendende driftsomkostninger til CPA'en og de centrale elementer (TLM og CPOC) knyttet til aktiviteterne beskrevet i denne CP.
(371)Rod-CA'erne (herunder EU-rod-CA'en) har ret til at opkræve afgifter fra deres sub-CA'er.
(372)Igennem deres driftsperiode skal hver deltager i C-ITS-tillidsmodellen have adgang til mindst én rod-CA, EA og AA uden forskelsbehandling.
(373)Hver rod-CA har ret til at videreføre de afgifter, den betaler for CPA'en og de centrale elementer (TLM og CPOC), til de registrerede deltagere i C-ITS-tillidsmodellen, herunder de indskrevne og autoriserede C-ITS-stationer.
9.2.Økonomisk ansvar
(374)Den indledende oprettelse af en rod-CA skal dække en periode på mindst tre års drift, før den kan blive medlem af EU C-ITS-tillidsmodel. En rod-CA-operatørs CPS skal også indeholde detaljerede bestemmelser vedrørende tilbagekaldelse eller lukning af en rod-CA.
(375)Hver rod-CA skal demonstrere den finansielle levedygtighed af den juridiske entitet, der implementerer den i mindst tre år. Denne plan for finansiel levedygtighed er en del af det indledende sæt dokumenter til indskrivning og skal opdateres hvert tredje år og rapporteres til CPA'en.
(376)Hver rod-CA skal rapportere strukturen af de opkrævninger, der pålægges EA'er/AA'er og de indskrevne og autoriserede C-ITS-stationer hvert år, til driftslederen og CPA'en for at demonstrere sin finansielle bæredygtighed.
(377)Alle økonomisk og juridisk ansvarlige entiteter fra rod-CA'en, EA'en, AA'en og de centrale elementer (CPOC og TLM) fra C-ITS-tillidsmodellen skal dække deres operationelle pligter med tilstrækkelige forsikringsniveauer for at kompensere for operationelle fejl og finansiel genoprettelse af deres pligter, hvis et af de tekniske elementer svigter.
9.3.Fortrolighed og forretningsoplysninger
(378)Følgende skal holdes fortroligt og privat:
·ansøgningsoptegnelser for rod-CA, EA og AA, både godkendte og afviste
·rod-CA-, EA-, AA- og TLM-revisionsrapporter
·rod-CA'ers, EA'ers, AA'ers, CPOC'ers og TLM'ers katastrofeberedskabsplaner
·private nøgler for C-ITS-tillidsmodellens elementer (C-ITS-stationer, TLM, EA, AA, rod-CA'er)
·alle andre oplysninger identificeret som værende fortrolige af CPA'en, rod-CA'erne, EA'en, AA'en, TLM'en og CPOC'et.
9.4.Plan for privatliv
(379)Rod-CA'ernes og EA'ernes/AA'ernes CPS'er skal beskrive planen og kravene for behandling behandlingen af personlige oplysninger og privatliv på baggrund af GDPR og andre gældende juridiske (f.eks. nationale) rammer.
10.Referencer
I dette bilag henvises til følgende referencer:
[1]
|
ETSI TS 102 941 V1.2.1, Intelligente transportsystemer (ITS) – sikkerhed, tillid og forvaltning af privatliv (ETSI TS 102 941 V1.2.1, Intelligent transport systems (ITS) – security, trust and privacy management).
|
[2]
|
ETSI TS 102 940 V1.3.1, Intelligente transportsystemer (ITS) – sikkerhed, sikkerhedsopbygning af ITS-kommunikation og forvaltning af sikkerhed (ETSI TS 102 940 V1.3.1, Intelligent transport systems (ITS) – security, ITS communications security architecture and security management).
|
[3]
|
Ramme for certifikatpolitik og certificeringspraksisser (RFC 3647, 1999) (Certificate policy and certification practices framework (RFC 3647, 1999)).
|
[4]
|
ETSI TS 102 042 V2.4.1 Politiske krav til certificeringsmyndigheder, der udsteder offentlige nøglecertifikater (ETSI TS 102 042 V2.4.1 Policy requirements for certification authorities issuing public key certificates).
|
[5]
|
ETSI TS 103 097 V1.3.1, Intelligent transport systems (ITS) – sikkerhed, sikkerhedshoved og certifikatformater (ETSI TS 103 097 V1.3.1, Intelligent transport systems (ITS) – security, security header and certificate formats).
|
[6]
|
Calder, A. (2006). Informationssikkerhed baseret på ISO 27001/ISO 1779: en forvaltningsvejledning. Van Haren Publishing (Calder, A. (2006). Information security based on ISO 27001/ISO 1779: a management guide. Van Haren Publishing).
|
[7]
|
ISO, I., & Std, I. E. C. (2011). ISO 27005 (2011) – informationsteknologi, sikkerhedsteknikker, risikostyring af informationssikkerhed. ISO (ISO, I., & Std, I. E. C. (2011). ISO 27005 (2011) – information technology, security techniques, information security risk management. ISO).
|
|
|