INHOUDSOPGAVE
1.Inleiding9
1.1.Overzicht en toepassingsgebied van deze regels9
1.2.Definities en afkortingen11
1.3.PKI-deelnemers13
1.3.1.Inleiding13
1.3.2.Instantie voor het C-ITS-certificaatbeleid16
1.3.3.Beheerder van de lijst van vertrouwde entiteiten17
1.3.4.Geaccrediteerde PKI-auditeur17
1.3.5.C-ITS-contactpunt17
1.3.6.Operationele taken18
1.4.Certificaatgebruik18
1.4.1.Toepasselijke gebruiksgebieden18
1.4.2.Aansprakelijkheidsgrenzen19
1.5.Beheer certificaatbeleid19
1.5.1.Bijwerking van in de ECTL opgenomen CPS van CA19
1.5.2.Procedures voor de goedkeuring van de CPS20
2.Verantwoordelijkheden voor de publicatie en databanken20
2.1.Methoden voor de publicatie van certificaatinformatie20
2.2.Tijdstip en frequentie van publicatie21
2.3.Databanken21
2.4.Controle op de toegang tot databanken21
2.5.Publicatie van certificaatinformatie22
2.5.1.Publicatie van certificaatinformatie door de TLM22
2.5.2.Publicatie van certificaatinformatie door CA’s22
3.Identificatie en authenticatie23
3.1.Naamgeving23
3.1.1.Soorten namen23
3.1.1.1.Namen van TLM, root-CA’s, EA’s, AA’s23
3.1.1.2.Namen van eindentiteiten23
3.1.1.3.Identificatie van certificaten23
3.1.2.Behoefte aan betekenisvolle namen23
3.1.3.Anonimiteit en pseudoniemen van eindentiteiten23
3.1.4.Regels voor de interpretatie van naamformulieren23
3.1.5.Uniek karakter van namen24
3.2.Validatie van de oorspronkelijke identiteit24
3.2.1.Methode om het bezit van een private sleutel aan te tonen24
3.2.2.Authenticatie van de identiteit van de instantie24
3.2.2.1.Authenticatie van de identiteit van de root-CA24
3.2.2.2.Authenticatie van de identiteit van de TLM25
3.2.2.3.Authenticatie van de identiteit van de sub-CA25
3.2.2.4.Authenticatie van de eindentiteit als organisatie waarbij de abonnees zijn aangesloten26
3.2.3.Authenticatie van afzonderlijke entiteiten26
3.2.3.1.Authenticatie van afzonderlijke TLM-CA-entiteiten26
3.2.3.2.Authenticatie van de identiteit van de abonnees van C-ITS-stations27
3.2.3.3.Authenticatie van de identiteit van C-ITS-stations27
3.2.4.Niet-gecontroleerde informatie over abonnees27
3.2.5.Valideren van de autoriteit27
3.2.5.1.Valideren van TLM, root-CA, EA en AA27
3.2.5.2.Valideren van abonnees van C-ITS-stations28
3.2.5.3.Valideren van C-ITS-stations28
3.2.6.Interoperabiliteitscriteria28
3.3.Identificatie en authenticatie van aanvragen van nieuwe sleutels28
3.3.1.Identificatie en authenticatie van routineaanvragen van nieuwe sleutels28
3.3.1.1.TLM-certificaten28
3.3.1.2.root-CA-certificaat28
3.3.1.3.Vernieuwing van een EA/AA-certificaat of vernieuwing van de sleutel28
3.3.1.4.Inschrijvingsbewijs eindentiteiten29
3.3.1.5.Autorisatiebewijzen van eindentiteiten29
3.3.2.Identificatie en authenticatie van aanvragen van nieuwe sleutels na intrekkingen29
3.3.2.1.CA-certificaten29
3.3.2.2.Inschrijvingsbewijs eindentiteiten29
3.3.2.3.Autorisatieverzoeken van eindentiteiten29
3.4.Identificatie en authenticatie voor intrekkingsverzoeken29
3.4.1.Root-CA/EA/AA-certificaat29
3.4.2.Inschrijvingsbewijs C-ITS-station30
3.4.3.Autorisatiebewijs C-ITS-station30
4.Operationele eisen inzake de levenscyclus van certificaten30
4.1.Certificaataanvraag30
4.1.1.Wie kan een certificaataanvraag indienen?30
4.1.1.1.Root-CA30
4.1.1.2.TLM31
4.1.1.3.EA en AA31
4.1.1.4.C-ITS-station31
4.1.2.Inschrijvingsproces en verantwoordelijkheden31
4.1.2.1.Root-CA31
4.1.2.2.TLM32
4.1.2.3.EA en AA32
4.1.2.4.C-ITS-station32
4.2.Verwerking van certificaataanvragen33
4.2.1.Uitvoeren van de identificatie- en authenticatiefuncties33
4.2.1.1.Identificatie en authenticatie van root-CA’s33
4.2.1.2.Identificatie en authenticatie van de TLM33
4.2.1.3.Identificatie en authenticatie van EA en AA33
4.2.1.4.Identificatie en authenticatie van de EE-abonnee34
4.2.1.5.Autorisatiebewijs34
4.2.2.Goedkeuring of afwijzing van certificaataanvragen34
4.2.2.1.Goedkeuring of afwijzing van root-CA-certificaten34
4.2.2.2.Goedkeuring of afwijzing van TLM-certificaten34
4.2.2.3.Goedkeuring of afwijzing van EA- en AA-certificaten34
4.2.2.4.Goedkeuring of afwijzing van de EC34
4.2.2.5.Goedkeuring of afwijzing van AT35
4.2.3.Termijn voor de verwerking van een certificaataanvraag35
4.2.3.1.Aanvraag van een root-CA-certificaat35
4.2.3.2.Aanvraag van een TLM-certificaat35
4.2.3.3.Aanvraag van een EA- en AA-certificaat35
4.2.3.4.Aanvraag van een EC35
4.2.3.5.Aanvraag van een AT35
4.3.Afgifte van certificaten35
4.3.1.CA-acties tijdens de afgifte van certificaten35
4.3.1.1.Afgifte van een Root-CA-certificaat35
4.3.1.2.Afgifte van een TLM-certificaat36
4.3.1.3.Afgifte van een EA- en AA-certificaat36
4.3.1.4.EC-afgifte36
4.3.1.5.AT-afgifte36
4.3.2.Kennisgeving van certificaatafgiften aan abonnees door CA's36
4.4.Aanvaarding van het certificaat.37
4.4.1.Proces voor de aanvaarding van certificaten37
4.4.1.1.Root-CA37
4.4.1.2.TLM37
4.4.1.3.EA en AA37
4.4.1.4.C-ITS-station37
4.4.2.Publicatie van certificaten37
4.4.3.Kennisgeving van de afgifte van certificaten37
4.5.Sleutelpaar en gebruik van certificaten37
4.5.1.Private sleutel en gebruik van certificaten37
4.5.1.1.Private sleutel en gebruik van certificaten voor TLM37
4.5.1.2.Private sleutel en gebruik van certificaten voor root-CA’s37
4.5.1.3.Private sleutel en gebruik van certificaten voor AA’s37
4.5.1.4.Private sleutel en gebruik van certificaten voor eindentiteiten38
4.5.2.Gebruik van certificaten en openbare sleutels door een vertrouwende partij38
4.6.Vernieuwing van een certificaat38
4.7.Vernieuwing van de certificaatsleutel38
4.7.1.Omstandigheden voor de vernieuwing van de certificaatsleutel38
4.7.2.Wie kan een nieuwe sleutel aanvragen?38
4.7.2.1.Root-CA38
4.7.2.2.TLM38
4.7.2.3.EA en AA38
4.7.2.4.C-ITS-station39
4.7.3.Vernieuwing van een sleutel39
4.7.3.1.TLM-certificaat39
4.7.3.2.Root-CA-certificaat39
4.7.3.3.EA- en AA-certificaten39
4.7.3.4.C-ITS-stationcertificaat40
4.8.Wijziging van een certificaat40
4.9.Schorsing en intrekking van certificaten40
4.10.Certificaatstatusdiensten40
4.10.1.Operationele kenmerken40
4.10.2.Beschikbaarheid van de dienst40
4.10.3.Facultatieve functies40
4.11.Einde van het abonnement40
4.12.Bewaren en herstellen van sleutels40
4.12.1.Abonnee40
4.12.1.1.Welk sleutelpaar kan worden bewaard?40
4.12.1.2.Wie kan een herstelaanvraag indienen?40
4.12.1.3.Herstelprocedure en verantwoordelijkheden40
4.12.1.4.Identificatie en authenticatie40
4.12.1.5.Goedkeuring of afwijzing van herstelaanvragen40
4.12.1.6.KEA- en KRA-handelingen tijdens het bewaren van sleutels41
4.12.1.7.KEA en KRA beschikbaarheid41
4.12.2.Beleid en praktijken inzake de inkapseling van sessiesleutels41
5.Faciliteit, beheer en operationele controles41
5.1.Fysieke controles41
5.1.1.Bouw en locatie van de site41
5.1.1.1.Root-CA, CPOC, TLM41
5.1.1.2.EA/AA42
5.1.2.Fysieke toegang42
5.1.2.1.Root-CA, CPOC, TLM42
5.1.2.2.EA/AA43
5.1.3.Stroomvoorziening en airconditioning43
5.1.4.Bescherming tegen waterschade43
5.1.5.Brandpreventie en bescherming 44
5.1.6.Beheer van gegevensdragers44
5.1.7.Afvalverwijdering44
5.1.8.Back-up op andere locatie44
5.1.8.1.Root-CA, CPOC en TLM44
5.1.8.2.EA/AA45
5.2.Procedurele controles45
5.2.1.Vertrouwensfuncties45
5.2.2.Aantal vereiste personen per taak45
5.2.3.Identificatie en authenticatie voor elke rol46
5.2.4.Regels inzake de scheiding van functies46
5.3.Personeelscontroles47
5.3.1.Eisen inzake kwalificaties, ervaring en veiligheidsscreening47
5.3.2.Procedures voor antecedentenonderzoek47
5.3.3.Opleidingsvereisten48
5.3.4.Voorschriften inzake nascholingsfrequentie48
5.3.5.Frequentie en sequentie van jobrotatie48
5.3.6.Sancties voor onrechtmatige handelingen48
5.3.7.Eisen ten aanzien van onafhankelijke contractanten49
5.3.8.Aan het personeel verstrekte documentatie49
5.4.Procedures voor het loggen van audits49
5.4.1.Door elke CA te registreren en te rapporteren voorvallen49
5.4.2.Frequentie voor de verwerking van logbestanden50
5.4.3.Bewaartermijn voor auditlogbestanden50
5.4.4.Bescherming van auditlogbestanden51
5.4.5.Back-upprocedures van auditlogbestanden51
5.4.6.Systeem voor de registratie van auditgegevens (intern of extern)51
5.4.7.Kennisgeving aan een subject dat een voorval veroorzaakt51
5.4.8.Kwetsbaarheidsbeoordeling51
5.5.Archiveren van gegevens52
5.5.1.Soorten gearchiveerde gegevens52
5.5.2.Bewaartermijn van archieven53
5.5.3.Bescherming van archieven53
5.5.4.Systeemarchief en opslag53
5.5.5.Eisen inzake de datering van gegevens54
5.5.6.Systeem voor de registratie van archiefgegevens (intern of extern)54
5.5.7.Procedures voor het opvragen en controleren van archiefgegevens54
5.6.Verwisseling van sleutels voor elementen van het C-ITS-samenwerkingsmodel54
5.6.1.TLM54
5.6.2.Root-CA54
5.6.3.EA-/AA- certificaat54
5.6.4.Auditeur55
5.7.Herstel na incidenten en bedreigingen55
5.7.1.Afhandeling van incidenten en bedreigingen55
5.7.2.Besmetting van computers, software en/of gegevens56
5.7.3.Procedure in geval van compromittering van private sleutels van entiteiten56
5.7.4.Bedrijfscontinuïteit na een ramp56
5.8.Opzegging en overdracht57
5.8.1.TLM57
5.8.2.Root-CA57
5.8.3.EA/AA58
6.Technische beveiligingscontroles58
6.1.Genereren en installeren van sleutelparen58
6.1.1.TLM, root-CA, EA, AA58
6.1.2.EE — mobiel C-ITS-station58
6.1.3.EE — vast C-ITS-station59
6.1.4.Cryptografische vereisten59
6.1.4.1.Algoritme en sleutellengte — handtekeningalgoritmes59
6.1.4.2.Algoritme en sleutellengte — versleutelingsalgoritmes voor inschrijving en autorisatie60
6.1.4.3.Cryptoflexibiliteit61
6.1.5.Beveiligde opslag van private sleutels61
6.1.5.1.Root-CA, sub-CA en TLM-niveau61
6.1.5.2.Eindentiteit62
6.1.6.Back-up van private sleutels63
6.1.7.Vernietiging van private sleutels63
6.2.Activeringsgegevens63
6.3.Technische beveiligingscontroles63
6.4.Levenscyclus van technische controles63
6.5.Controles van de netwerkbeveiliging63
7.Certificaatprofielen, CRL en CTL63
7.1.Certificaatprofiel63
7.2.Geldigheid certificaat64
7.2.1.Pseudoniem certificaten65
7.2.2.Autorisatiebewijzen voor vaste C-ITS-stations65
7.3.Intrekking van certificaten65
7.3.1.Intrekking van CA-, EA- en AA-certificaten65
7.3.2.Intrekking van inschrijvingsbewijzen66
7.3.3.Intrekking van autorisatiebewijzen66
7.4.Lijst van ingetrokken certificaten66
7.5.Europese vertrouwenslijst van certificaten66
8.Conformiteitsaudit en andere beoordelingen66
8.1.Aan audit onderworpen thema's en grondslag van de audit66
8.2.Auditfrequentie67
8.3.De identiteit / kwalificaties van auditeurs67
8.4.Relatie tussen de auditeur en de gecontroleerde entiteit67
8.5.Naar aanleiding van een tekortkoming getroffen maatregelen68
8.6.Bekendmaking van de resultaten68
9.Andere bepalingen68
9.1.Vergoedingen68
9.2.Financiële aansprakelijkheid69
9.3.Vertrouwelijkheid van bedrijfsinformatie69
9.4.Privacyplan69
10.Referenties69
BIJLAGE III
1.Inleiding
1.1.Overzicht en toepassingsgebied van het certificaatbeleid
Het certificaatbeleid definieert het Europees samenwerkingsmodel voor C-ITS op basis van openbare sleutelinfrastructuur (Public Key Infrastructure, PKI) binnen de werkingssfeer van het algemene systeem van de EU voor het beheer van C-ITS-beveiligingsgegevens (EU-CCMS). Het bevat voorschriften voor het beheer van de publieke sleutelcertificaten van C-ITS-toepassingen door uitgevende entiteiten en voor het gebruik daarvan door eindentiteiten in Europa. Op het hoogste niveau bestaat de PKI uit een reeks root-CA’s die geactiveerd worden doordat de beheerder van de vertrouwenslijst (Trust List Manager, TLM) hun certificaten heeft toegevoegd aan de Europese lijst van betrouwbare certificaten (European Certificate Trust List, ECTL), die door de centrale TLM-entiteit wordt opgesteld en gepubliceerd (zie de punten 1.2 en 1.3).
Dit beleid is bindend voor alle entiteiten die deelnemen aan het op vertrouwen gebaseerde Europese C-ITS-systeem. Het helpt bij de beoordeling van het vertrouwen dat kan worden gesteld in de informatie die wordt ontvangen door een ontvanger van een bericht dat door een PKI-eindgebruikerscertificaat is geauthenticeerd. Om de betrouwbaarheid van door het EU-CCMS verstrekte certificaten te kunnen beoordelen, worden bindende eisen vastgesteld voor de exploitatie van de centrale TLM-entiteit en de samenstelling en het beheer van de ECTL. Bijgevolg bestrijkt dit document de volgende aspecten in verband met de ECTL:
·identificatie en authenticatie van de verantwoordelijken waaraan PKI-rollen voor de TLM worden toegekend, met vermelding van de aan elke rol gekoppelde bevoegdheden;
·minimumeisen voor de lokale beveiligingspraktijken van de TLM, met inbegrip van fysieke, personeels- en procedurele controles;
·minimumeisen voor de technische beveiligingspraktijken van de TLM, inclusief computer- en netwerkbeveiliging en controles bij de ontwikkeling van encryptiemodules;
·minimumeisen voor operationele praktijken van de TLM, met inbegrip van de registratie van nieuwe root-CA-certificaten, de tijdelijke of permanente intrekking van bestaande root-CA’s en de publicatie en verspreiding van ECTL-actualiseringen;
·een ECTL-profiel, met inbegrip van alle verplichte en facultatieve datavelden in de ECTL, de cryptografische algoritmes die moeten worden gebruikt, het exacte ECTL-formaat en aanbevelingen voor de verwerking van de ECTL;
·levenscyclusbeheer van ECTL-certificaten, met inbegrip van het afgeven, activeren, verstrijken en intrekken van ECTL-certificaten;
·beheer van de intrekking van het vertrouwen in root-CA’s, indien nodig.
Aangezien de betrouwbaarheid van de ECTL niet alleen afhangt van de ECTL zelf, maar ook in grote mate bepaald wordt door de onderliggende root-CA’s en hun subCA’s, die samen de PKI vormen, voorziet dit beleid ook in minimumeisen die bindend zijn voor alle deelnemende CA’s (root-CA’s en subCA’s). De eisen bestrijken het volgende:
·identificatie en authenticatie van de verantwoordelijken voor de aanvraag van PKI-rollen (veiligheids of privacyverantwoordelijke, veiligheidsbeheerder, directory-beheerder en eindgebruikers), met inbegrip van de aan elke rol gekoppelde plichten, verantwoordelijkheden, aansprakelijkheden en bevoegdheden;
·sleutelbeheer, met inbegrip van de ondertekening van aanvaardbare en verplichte algoritmen voor de ondertekening van data en algoritmes, en de geldigheidstermijn van certificaten;
·minimumeisen voor lokale beveiliging, met inbegrip van fysieke, personele en procedurele controles;
·minimumeisen voor technische beveiliging, zoals computer- en netwerkbeveiliging en controles bij de ontwikkeling van encryptiemodules;
·minimumeisen voor de operationele werking van CA’s, EA’s, AA’s en eindentiteiten, met inbegrip van aspecten van registratie, uitschrijving (schrapping), intrekking, sleutel-compromittering, ontslag om gegronde reden, actualisering van certificaten, auditpraktijken en nietopenbaarmaking van privacygerelateerde informatie;
·certificaat en CRL-profiel, met inbegrip van formaten, aanvaardbare algoritmes, verplichte en facultatieve datavelden en hun gegevensbereik, en de manier waarop verificateurs geacht worden certificaten te verwerken;
·verplichtingen van de entiteiten in het vertrouwensmodel met betrekking tot regelmatige monitoring, rapportage, waarschuwing en herstel, teneinde een veilige werking te waarborgen, ook in gevallen van wangedrag.
In aanvulling op deze minimumvereisten, mogen de entiteiten die de root-CA’s en subCA’s beheren, aanvullende eisen vaststellen en opnemen in relevante certificaatpraktijkverklaringen (Certificate Practice Statement, CPS), mits die eisen niet indruisen tegen de eisen die in het certificaatbeleid zijn vervat. Zie deel 1.5 voor nadere toelichting over de manier waarop die CPS worden gecontroleerd en gepubliceerd.
In de CP wordt ook vermeld voor welke doelstellingen de root-CA’s, subCA’s en hun certificaten moeten worden gebruikt. Het bevat de lijst van verplichtingen voor:
·de TLM;
·elke root-CA waarvan de certificaten zijn opgenomen in de ECTL;
·de root-CA’s en subCA’s (EA en AA);
·elk lid of elke organisatie die verantwoordelijk is voor een entiteit van het C-ITS-samenwerkingsmodel, of die een dergelijke entiteit exploiteert.
In de CP zijn ook de bindende verplichtingen gedefinieerd voor:
·de TLM;
·elke root-CA waarvan de certificaten zijn opgenomen in de ECTL;
·elke door een root-CA gecertificeerde subCA;
·alle eindentiteiten;
·elke lidorganisatie die verantwoordelijk is voor een entiteit van het C-ITS-samenwerkingsmodel, of die een dergelijke entiteit exploiteert.
Ten slotte zijn in de CP regels vastgesteld met betrekking tot de documentatie van beperkingen van de aansprakelijkheden en verplichtingen in de CPS van elke root-CA waarvan de certificaten in de ECTL zijn opgenomen.
De CP is in overeenstemming met het door de Internet Engineering Task Force (IETF) vastgestelde certificaatbeleid en -praktijkkader [3].
1.2.Definities en afkortingen
De definities in [2], [3] en [4] zijn van toepassing.
|
AA
|
Autorisatie-instantie (authorisation authority)
|
|
AT
|
Autorisatiebewijs (authorisation ticket)
|
|
CA
|
Certificeringsinstantie (certification authority)
|
|
CP
|
Certificaatbeleid (certificate policy)
|
|
CPA
|
Instantie voor het C-ITS-certificaatbeleid (C-ITS certificate policy authority)
|
|
CPOC
|
C-ITS-contactpunt (C-ITS point of contact)
|
|
CPS
|
Verklaring inzake de certificaatpraktijk (certificate practice statement)
|
|
CRL
|
Lijst van ingetrokken certificaten (certificate revocation list)
|
|
EA
|
Inschrijvingsinstantie (enrolment authority)
|
|
EC
|
Inschrijvingsauthenticatie (enrolment credential)
|
|
ECIES
|
Elliptische curve van de geïntegreerde encryptieregeling (elliptic curve integrated encryption scheme)
|
|
EE
|
Eindentiteit (= C-ITS-station)
|
|
ECTL
|
Europese lijst van vertrouwde certificaten (European certificate trust list)
|
|
EU CCMS
|
EU-Systeem voor het beheer van C-ITS-beveiligingsauthenticaties (EU C-ITS security credential management system)
|
|
GDPR
|
Algemene verordening gegevensbescherming (General Data Protection Regulation)
|
|
HSM
|
Hardwarebeveiligingsmodule (Hardware security module)
|
|
PKI
|
Openbare sleutelinfrastructuur (public key infrastructure)
|
|
RA
|
Registratie-instantie (registration authority)
|
|
subCA
|
EA en AA
|
|
TLM
|
Beheerder van de lijst van vertrouwde entiteiten (trust list manager)
|
Woordenlijst
|
Aanvrager
|
Een natuurlijke persoon of juridische entiteit die (de vernieuwing van) een certificaat aanvraagt. Zodra het oorspronkelijke certificaat wordt gecreëerd (de initialisatie), wordt de aanvrager aangeduid als de abonnee.
Voor certificaten die aan eindentiteiten worden afgegeven, is de abonnee (certificaataanvrager) de entiteit die de zeggenschap uitoefent over de eindentiteit waaraan het certificaat is afgegeven of die deze entiteit exploiteert/onderhoudt, zelfs indien die eindentiteit de eigenlijke certificaataanvraag verstuurt.
|
|
Autorisatie-instantie
|
In dit document heeft de term „ autorisatie-instantie” (AA) niet alleen betrekking op de specifieke functie van de AA, maar ook op de wettelijke en/of operationele entiteit voor het beheer daarvan.
|
|
Certificeringsinstantie
|
De rootcertificeringsinstantie, de inschrijvingsinstantie en de autorisatie-instantie vormen samen de certificeringsinstantie (CA).
|
|
C-ITS-samenwerkingsmodel
|
Het C-ITS-samenwerkingsmodel is verantwoordelijk voor het tot stand brengen van een vertrouwensrelatie tussen C-ITS-stations. Het wordt geïmplementeerd via het gebruik van een PKI, die bestaat uit root-CA’s, het CPOC, de TLM, EA’s, AA’s en een beveiligd netwerk.
|
|
Cryptovermogen
|
Het vermogen van het C-ITS-samenwerkingsmodel om de CP aan te passen aan veranderende omgevingen of nieuwe toekomstige behoeften, bijvoorbeeld door de cryptografische algoritmes en sleutellengte na verloop van tijd te wijzigen.
|
|
Cryptografische module
|
Een veilig element op basis van hardware waarin de sleutels worden gegenereerd en/of opgeslagen, willekeurige getallen worden gegenereerd en gegevens worden ondertekend of versleuteld.
|
|
Inschrijvingsinstantie
|
In dit document heeft de term „inschrijvingsinstantie” (EA) niet alleen betrekking op de specifieke functie van de EA, maar ook op de wettelijke en/of operationele entiteit voor het beheer daarvan.
|
|
PKI-deelnemers
|
Elementen van het C-ITS-samenwerkingsmodel, d.w.z. de TLM, root-CA’s, EA’s, AA’s en C-ITS-stations.
|
|
Vernieuwing van een sleutel
|
|
|
Databank
|
De databank die wordt gebruikt voor de opslag van certificaten en informatie over door de entiteiten van het C-ITS-samenwerkingsmodel verleende certificaten als gedefinieerd in deel 2.3.
|
|
Rootcertificeringsinstantie
|
In dit document heeft de term „rootcertificeringsinstantie” (CA) niet alleen betrekking op de specifieke functie van de CA, maar ook op de wettelijke en/of operationele entiteit voor het beheer daarvan.
|
|
Subject
|
In het certificaat als subject geïndentificeerd(e) natuurlijke persoon, apparaat, systeem, eenheid of juridische entiteit, d.w.z. hetzij de abonnee, hetzij het apparaat dat door de abonnee wordt bediend en beheerd.
|
|
Abonnee
|
Een natuurlijke persoon of juridische entiteit waaraan een certificaat is afgegeven en die juridisch gebonden is door een abonnement of gebruiksvoorwaarden.
|
|
Abonnement
|
Een overeenkomst tussen de CA en de aanvrager/abonnee, waarin de rechten en plichten van de partijen zijn gespecificeerd.
|
1.3.PKI-deelnemers
1.3.1.Inleiding
PKI-deelnemers spelen een rol in de door dit beleid gedefinieerde PKI. Tenzij dat expliciet wordt verboden, mag een partij verschillende rollen tegelijk vervullen. Om belangenconflicten te vermijden en de scheiding van functies te waarborgen, kan het verboden worden verschillende rollen tegelijk te vervullen.
Partijen kunnen delen van hun rollen middels een dienstencontract aan andere entiteiten delegeren. Wanneer informatie over de intrekkingsstatus bijvoorbeeld aan de hand van CRL’s wordt verstrekt, is de CA ook de instantie die de CRL aanmaakt maar kan zij de verantwoordelijkheid voor de aanmaak van CRL’s aan een andere entiteit delegeren.
De PKI-rollen omvatten:
·gezaghebbende rollen, d.w.z. elke rol is aan één enkele instantie toegewezen;
·operationele rollen, d.w.z. rollen die door één of meer entiteiten kunnen worden vervuld.
De rol van root-CA kan bijvoorbeeld worden vervuld door een commerciële entiteit: een belangengroep, een nationale organisatie en/of een Europese organisatie.
Figuur 1 toont de architectuur van het C-ITS-samenwerkingsmodel op basis van [2]. De architectuur wordt hier kort beschreven, maar de belangrijkste elementen zijn nader beschreven in de punten 1.3.2 tot en met 1.3.6.
De CPA wijst de TLM aan, die bijgevolg door alle PKI-deelnemers als een betrouwbare entiteit wordt beschouwd. De CPA keurt de root-CA-werking goed en bevestigt dat de TLM de root-CA(‘s) kan vertrouwen. De TLM genereert de ECTL die alle PKI-deelnemers vertrouwen biedt in de goedgekeurde root-CA’s. De root-CA stuurt certificaten naar de EA en de AA ter bevestiging van het vertrouwen in hun werking. De EA stuurt inschrijvingscertificaten naar de verzendende en doorsturende C-ITS-stations (als eindentiteiten), ter bevestiging van het vertrouwen in hun werking. De AA stuurt AT’s naar de C-ITS-stations op basis van vertrouwen in de EA.
De ontvangende en doorsturende C-ITS-stations (als doorgevende partij) kunnen de andere C-ITS-stations vertrouwen aangezien de AT’s worden gegenereerd door een AA die door een root-CA wordt vertrouwd, die op haar beurt het vertrouwen geniet van de TLM en CPA.
Noot: figuur 1 beschrijft uitsluitend het root-CA-niveau van het C-ITS-samenwerkingsmodel. De lagere niveaus zijn gedetailleerd omschreven in de volgende hoofdstukken van dit CP of de CPS van de specifieke root-CA’s.
Figuur 2 geeft de informatiestromen tussen de PKI-deelnemers weer. De groene stippen duiden op stromen die communicatie tussen machines vereisen. De informatiestromen in het rood hebben vastgelegde beveiligingseisen.
Het C-ITS-samenwerkingsmodel is gebaseerd op een meervoudige root-CA-architectuur, waarbij de root-CA-certificaten periodiek worden doorgegeven (zie hierna) aan het centrale contactpunt (CPOC), via een beveiligd door het CPOC gedefinieerd protocol (bv. certificaten).
Een root-CA kan worden geëxploiteerd door een publieke of een particuliere organisatie. De architectuur van het C-ITS-samenwerkingsmodel bevat ten minste één root-CA (de root-CA van de EU, met hetzelfde niveau als de andere root-CA’s). De root-CA is gedelegeerd door alle entiteiten die aan het C-ITS-samenwerkingsmodel deelnemen zonder een eigen root-CA op te zetten. Het CPOC verstuurt de ontvangen root-CA-certificaten naar de TLM, die de lijst van root-CA-certificaten opmaakt en ondertekent en die certificaten terugstuurt naar het CPOC, dat ze openbaar maakt (zie hierna).
De vertrouwensrelaties tussen de entiteiten van het C-ITS-samenwerkingsmodel zijn beschreven in de volgende figuren, tabellen en afdelingen.
Figuur 1: Architectuur C-ITS-samenwerkingsmodel
Figuur 2: Informatiestromen C-ITS-samenwerkingsmodel
|
Stroom-ID
|
Van
|
Naar
|
Inhoud
|
Referentie
|
|
(1).
|
CPA
|
TLM
|
Goedkeuring van root-CA toepassing
|
8
|
|
(2).
|
CPA
|
TLM
|
Informatie over de intrekking van de root-CA
|
8.5
|
|
(3).
|
CPA
|
Root-CA
|
CP-updates
|
1.5
|
|
(4).
|
CPA
|
Root-CA
|
goedkeuring/verwerping van het root-CA-aanvraagformulier of de CPS vraagt wijzigingen of het auditproces.
|
8.5, 8.6
|
|
(5).
|
TLM
|
CPA
|
Kennisgeving van wijziging van ECTL
|
4, 5.8.1
|
|
(6).
|
TLM
|
CPOC
|
TLM-certificaat
|
4.4.2
|
|
(7).
|
TLM
|
CPOC
|
ECTL
|
4.4.2
|
|
(8).
|
CPOC
|
TLM
|
Informatie betreffende het root-CA-certificaat
|
4.3.1.1
|
|
(9).
|
CPOC
|
TLM
|
Intrekking van het root-CA-certificaat
|
7.3
|
|
(10).
|
CPOC
|
Alle eindentiteiten
|
TLM-certificaat
|
4.4.2
|
|
(11).
|
Root-CA
|
CPOC
|
Informatie betreffende het root-CA-certificaat
|
4.3.1.1
|
|
(12).
|
Root-CA
|
CPOC
|
Intrekking van het root-CA-certificaat
|
7.3
|
|
(13).
|
Root-CA
|
Auditeur
|
Auditopdracht
|
8
|
|
(14).
|
Root-CA
|
CPA
|
Root-CA aanvraagformulier — eerste aanvraag
|
4.1.2.1
|
|
(15).
|
Root-CA
|
CPA
|
Root-CA aanvraagformulier — CPS-wijzigingen
|
1.5.1
|
|
(16).
|
Root-CA
|
CPA
|
Root-CA aanvraagformulier — auditrapport
|
8.6
|
|
(17).
|
Root-CA
|
CPA
|
Root-CA-incidentrapporten, m.i.v. de intrekking van een subCA (EA, AA)
|
Bijlage III, 7.3.1
|
|
(18).
|
Root-CA
|
EA
|
EA-certificaatrespons
|
4.2.2.3
|
|
(19).
|
Root-CA
|
AA
|
AA-certificaatrespons
|
4.2.2.3
|
|
(20).
|
Root-CA
|
Alle
|
EA-/AA- certificaat, CRL
|
4.4.2
|
|
(21).
|
EA
|
Root-CA
|
EA-certificaataanvraag
|
4.2.2.3
|
|
(22).
|
EA
|
C-ITS-station
|
Inschrijvingsauthenticatierespons
|
4.3.1.4
|
|
(23).
|
EA
|
AA
|
Autorisatierespons
|
4.2.2.5
|
|
(24).
|
AA
|
Root-CA
|
AA-certificaataanvraag
|
4.2.2.3
|
|
(25).
|
AA
|
EA
|
Autorisatieverzoek
|
4.2.2.5
|
|
(26).
|
AA
|
C-ITS-station
|
Autorisatiebewijsrespons
|
4.3.1.5
|
|
(27).
|
EA
|
Root-CA
|
Indiening aanvraag
|
4.1.2.3
|
|
(28).
|
AA
|
Root-CA
|
Indiening aanvraag
|
4.1.2.3
|
|
(29).
|
Foot-CA
|
EA
|
Respons
|
4.12 en 4.2.1
|
|
(30).
|
Root-CA
|
AA
|
Respons
|
4.12 en 4.2.1
|
|
(31).
|
C-ITS-station
|
EA
|
Inschrijvingsauthenticatieverzoek
|
4.2.2.4
|
|
(32).
|
C-ITS-station
|
AA
|
Autorisatiebewijsverzoek
|
4.2.2.5
|
|
(33).
|
Fabrikant/exploitant
|
EA
|
Registratie
|
4.2.1.4
|
|
(34).
|
Fabrikant/exploitant
|
EA
|
Deactivering
|
7.3
|
|
(35).
|
EA
|
Fabrikant/exploitant
|
Respons
|
4.2.1.4
|
|
(36).
|
Auditeur
|
Root-CA
|
Rapport
|
8.1
|
|
(37).
|
Alle
|
CPA
|
CP-wijzigingsverzoeken
|
1.5
|
|
(38).
|
TLM
|
CPA
|
Aanvraagformulier
|
4.1.2.2
|
|
(39).
|
CPA
|
TLM
|
Goedkeuring/verwerping
|
4.1.2.2
|
|
(40).
|
TLM
|
CPA
|
Auditrapport
|
4.1.2.2
|
Tabel 1:
Gedetailleerde beschrijving van de informatiestromen binnen het C-ITS-samenwerkingsmodel
1.3.2.Instantie voor het C-ITS-certificaatbeleid
(1)De instantie voor het C-ITS certificaatbeleid (CPA) is samengesteld uit vertegenwoordigers van de overheid en particuliere belanghebbenden (bv. lidstaten, voertuigconstructeurs, enz.) die aan het CITS-samenwerkingsmodel deelnemen.
(1)Het beheer van het certificaatbeleid, waaronder:
·de goedkeuring van de huidige CP en toekomstige verzoeken tot wijziging van de CP;
·beslissen over de beoordeling van CP-wijzigingsverzoeken en door andere PKI-deelnemers of entiteiten ingediende aanbevelingen;
·beslissen over de release van nieuwe CP-versies;
(2)Beheer van de PKI-autorisaties, waaronder:
·definiëren, bepalen en publiceren van de CPS-autorisatie- en CA-controleprocedures (hierna samen: „CA-autorisatieprocedures”);
·het CPOC toestaan te werken en regelmatig te rapporteren;
·de TLM toestaan te werken en regelmatig te rapporteren;
·goedkeuring van de CPS van de root-CA als die in overeenstemming is met de gemeenschappelijke en geldige CP;
·analyse van de auditrapporten van de geaccrediteerde PKI-auditeur voor alle root-CA’s;
·kennisgeving aan de TLM van de lijst van erkende of nieterkende root-CA’s en hun certificaten op basis van de ontvangen goedkeuringsrapporten van de root-CA’s en regelmatige operationele rapporten.
(2)De gemachtigde vertegenwoordiger van de CPA is verantwoordelijk voor de authenticatie van de gemachtigde vertegenwoordiger van de TLM en de goedkeuring van de aanvraagformulieren van het TLM-inschrijvingsproces. De CPA is verantwoordelijk voor de autorisatie van de werking van de TLM als vermeld in dit hoofdstuk
1.3.3.Beheerder van de lijst van vertrouwde entiteiten
(3)De TLM is een door de CPA aangestelde entiteit.
(4)De TLM is belast met:
·de werking van de ECTL overeenkomstig de gemeenschappelijke geldige CP en regelmatige rapportage aan de CPA met het oog op de algemene veilige werking van het CITS-samenwerkingsmodel;
·de ontvangst van root-CA’s van het CPOC;
·de opname van CA-certificaten in/de schrapping van CA-certificaten uit de ECTL na kennisgeving door de CPA;
·de ondertekening van de ECTL;
·de regelmatige en tijdige verzending van de ECTL naar het CPOC.
1.3.4.Geaccrediteerde PKI-auditeur
(5)De geaccrediteerde PKI-auditeur is belast met:
·de uitvoering of organisatie van audits van root-CA’s, de TLM en subCA’s;
·de verspreiding van het auditrapport (van een eerste of periodieke audit) naar de CPA overeenkomstig de voorschriften in deel 8 hieronder. Het auditrapport bevat aanbevelingen van de geaccrediteerde PKI auditeur;
·kennisgeving van een geslaagde of mislukte uitvoering van een initiële of periodieke audit van de subCA’s aan de entiteit die de root-CA beheert;
·de beoordeling van de conformiteit van de CPS met deze CP.
1.3.5.C-ITS-contactpunt (CPOC)
(6)Het CPOC is één door de CPA aangestelde entiteit. De gemachtigde vertegenwoordiger van de CPA is verantwoordelijk voor de authenticatie van de gemachtigde vertegenwoordiger van het CPOC en de goedkeuring van de aanvraagformulieren van het CPOC-inschrijvingsproces. De CPA is verantwoordelijk voor de autorisatie van de werking van het CPOC als beschreven in dit hoofdstuk.
(7)Het CPOC is belast met:
·de totstandbrenging van en bijdrage aan een snelle en efficiënte beveiligde communicatie tussen alle entiteiten van het C-ITS-samenwerkingsmodel;
·de beoordeling van verzoeken en aanbevelingen voor procedurele wijzigingen die worden ingediend door andere deelnemers aan het samenwerkingsmodel (bv. root-CA’s);
·de verzending van root-CA’s naar het CPOC;
·de bekendmaking van het gemeenschappelijke trust anchor (huidige openbare sleutel en verbindingscertificaat van de TLM);
·bekendmaking van de ECTL.
De ECTL is nader omschreven in deel 7.
1.3.6.Operationele taken
(8)De volgende in [2] gedefinieerde entiteiten vervullen een operationele taak als gedefinieerd in RFC 3647:
|
Functioneel element
|
PKI-rol ([3] en [4])
|
Gedetailleerde rol ([2])
|
|
Rootcertificeringsinstantie
|
CA/RA (registratie-instantie)
|
Levert de EA en AA bewijs dat zij EC’s of AT’s mogen afgeven
|
|
Inschrijvingsinstantie
|
Abonnee van een root-CA/subject van EA-certificaat
CA/RA
|
Authenticeert een C-ITS-station en verleent toegang tot ITS-communicatie
|
|
Autorisatie-instantie
|
Abonnee bij een root-CA/subject van AA-certificaat
CA/RA
|
Verleent een C-ITS-station een autorisatie om specifieke ITS-diensten te mogen gebruiken
|
|
Verzendend C-ITS-station
|
subject van een certificaat (EC) van een eindentiteit (EE)
|
Verwerft EA-rechten om toegang te krijgen tot ITS-communicatie
Onderhandelt over rechten van AA voor het gebruik van ITS-diensten
Stuurt rechtstreekse en doorgestuurde omroepberichten
|
|
Doorsturend (transmissie) C-ITS-station
|
Doorsturende partij / subject van een EE-certificaat
|
Ontvangt door C-ITS-stations uitgezonden omroepberichten en stuurt die indien nodig naar ontvangende C-ITS-stations
|
|
Ontvangend C-ITS-station
|
Doorsturende partij
|
Ontvangt omroepberichten van verzendende of doorsturende C-ITS-stations
|
|
Fabrikant
|
Abonnee van een EA
|
Installeert de noodzakelijke informatie voor veiligheidsbeheer in C-ITS-stations in productie
|
|
Exploitant
|
Abonnee van een EA / AA
|
Installeert en actualiseert tijdens de werking de noodzakelijke informatie voor veiligheidsbeheer in C-ITS-stations
|
Tabel 2: Operationele taken
Noot: overeenkomstig [4] worden verschillende termen gebruikt voor de "abonnee” die met de CA een contract heeft gesloten voor de afgifte van certificaten en het “subject” van dat certificaat. Abonnees zijn alle entiteiten die een contractuele relatie hebben met een CA. Subjecten zijn entiteiten waarop die certificaten betrekking hebben. EA/AA’s zijn abonnees en subjecten van de root-CA en kunnen EA/AA-certificaten aanvragen. CITS-stations zijn subjecten en kunnen eindentiteitcertificaten aanvragen.
(9)Registratie-instanties:
De EA treedt op als registratie-instantie voor eindentiteiten. Alleen een geauthenticeerde en geautoriseerde abonnee kan nieuwe eindentiteiten (C-ITS) bij een EA registreren. De betrokken root-CA’s treden op als registratie-instantie voor EA’s en AA’s.
1.4.Certificaatgebruik
1.4.1.Toepasselijke gebruiksgebieden
(10)Certificaten die zijn afgegeven in het kader van de huidige CP zijn bedoeld om te worden gebruikt voor het valideren van digitale handtekeningen in de context van coöperatieve ITS-communicatie overeenkomstig de referentiearchitectuur van [2].
(11)De certificaatprofielen in [5] bepalen het certificaatgebruik voor de TLM, root-CA’s, EA’s, AA’s en eindentiteiten.
1.4.2.Aansprakelijkheidsgrenzen
(12)Certificaten zijn niet bedoeld en mogen niet worden gebruikt voor:
·strafbare feiten, overtredingen of inbreuken op toepasselijke wetten, verordeningen (o.a. GDPR), decreten of regeringsbesluiten;
·inbreuken op, schendingen van of de aantasting van rechten van anderen;
·inbreuken op deze CP of het relevante contract met de abonnee;
·handelingen die rechtstreeks kunnen leiden tot overlijden, letsel of ernstige milieuschade (bv. door incidenten bij de exploitatie van nucleaire installaties, luchtvaartnavigatie of -communicatie, of controlesystemen van wapens);
·handelingen die afbreuk doen aan de algemene doelstellingen om de verkeersveiligheid te bevorderen en het wegvervoer in Europa efficiënter te maken.
1.5.Beheer certificaatbeleid
1.5.1.Bijwerking van in de ECTL opgenomen CPS van CA's
(13)Elke in de ECTL vermelde root-CA publiceert haar eigen CPS, die in overeenstemming moet zijn met dit beleid. Een root-CA kan aanvullende eisen toevoegen, maar zorgt ervoor dat alle vereisten van dit certificaatbeleid te allen tijde worden nageleefd.
(14)Elke in de ECTL opgesomde root-CA implementeert een passend wijzigingsproces van haar CPS-document. De belangrijkste eigenschappen van het veranderingsproces worden gedocumenteerd in het openbare deel van de CPS.
(15)Het veranderingsproces moet ervoor zorgen dat alle wijzigingen in deze CP zorgvuldig worden geanalyseerd en, indien dat nodig is voor de naleving van de CP als gewijzigd, dat de CPS wordt bijgewerkt binnen de in de implementatiestap van het veranderingsproces voor de CP vastgestelde termijn. Het veranderingsproces voorziet in spoedprocedures voor wijzigingen om de tijdige invoering van wijzigingen van de CP die relevant zijn voor de veiligheid.
(16)Het veranderingsproces omvat passende maatregelen om de conformiteit van alle wijzigingen van de CPS met de CP te controleren. Alle wijzigingen van de CPS worden duidelijk gedocumenteerd. Alvorens een nieuwe versie van de CPS wordt ingevoerd, moet de conformiteit daarvan met de CP door een geaccrediteerde PKI-auditeur worden bevestigd.
(17)De root-CA stelt de CPA in kennis van elke wijziging in de CPS en deelt ten minste de volgende informatie mee:
·een nauwkeurige beschrijving van de wijziging;
·de reden voor de wijziging;
·een rapport van de geaccrediteerde PKI-auditeur, waarin de conformiteit met de CP wordt bevestigd;
·de contactgegevens van de persoon die voor de CPS verantwoordelijk is;
·het geplande tijdschema voor de uitvoering.
1.5.2.Procedure voor de goedkeuring van CPS
(18)Vóór het begin van haar activiteiten, legt een prospectieve root-CA haar CPS voor aan een geaccrediteerde PKI-auditeur als deel van een aanvraag van een conformiteitsaudit (stroom 13) en aan de CPA voor goedkeuring (stroom 15).
(19)Alvorens de wijzigingen in werking treden, legt een root-CA wijzigingen van haar CPS voor aan een geaccrediteerde PKI-auditeur als deel van een aanvraag van een conformiteitsaudit (stroom 13) en aan de CPA voor goedkeuring (stroom 15).
(20)Een EA/AA legt haar CPS of wijzigingen in haar CPS voor aan de root-CA. De root-CA kan een conformiteitscertificaat aanvragen bij de nationale instantie of private entiteit die belast is met de goedkeuring van de EA/AA als gedefinieerd in punt 4.1.2 en deel 8.
(21)De geaccrediteerde PKI-auditeur beoordeelt de CPS overeenkomstig deel 8.
(22)De geaccrediteerde PKI-auditeur deelt de resultaten van de CPS-beoordeling mee als onderdeel van het auditrapport, als uiteengezet in punt 8.1. De CPS word aanvaard of verworpen als onderdeel van de aanvaarding van het auditrapport als bedoeld in de punten 8.5 en 8.6 .
2.Verantwoordelijkheden voor de publicatie en databanken
2.1.Methoden voor de publicatie van certificaatinformatie
(23)Certificaatinformatie kan worden bekendgemaakt overeenkomstig punt 2.5:
·geregeld of periodiek; of
·in antwoord op een aanvraag van één van de deelnemende entiteiten.
In elke zaak, gelden verschillende gradaties van spoedeisendheid en derhalve tijdschema’s voor openbaarmaking; de entiteiten moeten op die twee soorten situaties kunnen inspelen.
(24)De regelmatige bekendmaking van certificaatinformatie maakt het mogelijk om een uiterste termijn vast te stellen waarbinnen de certificaatinformatie voor alle knooppunten van het C-ITS-netwerk wordt bijgewerkt. De frequentie van de bekendmaking van alle certificaatinformatie is bepaald in punt 2.2.
(25)Op verzoek van de entiteiten die deelnemen aan het C-ITS-netwerk, kan elke deelnemer op elk moment certificaatinformatie publiceren en, afhankelijk van haar status, de huidige certificaatinformatie opvragen om een volledig betrouwbaar knooppunt van het C-ITS-netwerk te worden. Het doel van die bekendmaking is voornamelijk entiteiten te informeren over de algehele actuele status van certificaatinformatie in het netwerk en hen de mogelijkheid te bieden op een betrouwbare basis te communiceren in afwachting van de volgende regelmatige bekendmaking van de informatie.
(26)Eén root-CA kan op elk moment de bekendmaking van certificaatinformatie initiëren door een geactualiseerde reeks certificaten te sturen naar alle “geabonneerde leden” van het C-ITS-netwerk die dergelijke informatie op regelmatige basis ontvangen. Dit ondersteunt de activiteiten van de CA’s en stelt hen in staat tussen de regelmatige en de geplande publicatiedatums van de certificaten met hun leden te communiceren.
(27)Punt 2.5 beschrijft het mechanisme en alle procedures voor de publicatie van de ECTL en root-CA-certificaten.
(28)Het CPOC publiceert de root-CA-certificaten (als opgenomen in de ECTL en bestemd voor openbaar gebruik), het TLM-certificaat en de ECTL die het genereert.
(29)Root-CA’s publiceren hun EA/AA-certificaten en CRL’s en zijn in staat alle drie hier bedoelde mechanismen voor de bekendmaking daarvan aan hun geabonneerde leden en doorsturende partijen te ondersteunen, waarbij alle nodige stappen worden genomen om een veilige overdracht als bedoeld in deel 4 te waarborgen.
2.2.Tijdstip en frequentie van publicatie
(30)De eisen inzake het tijdschema voor de publicatie van certificaten en CRL’s worden bepaald in het licht van de diverse beperkingen van de afzonderlijke C-ITS-knooppunten, met de algemene doelstelling om een veilig netwerk te exploiteren en bijwerkingen zo snel mogelijk in alle betrokken C-ITS-stations te publiceren.
·Om de veilige werking an het C-ITS-netwerk te waarborgen, is voor de regelmatige publicatie van bijgewerkte certificaatinformatie (bv. wijzigingen van de ECTL of CRL-samenstelling) een maximumtermijn van drie maanden vereist.
·Root-CA’s publiceren hun CA-certificaten en CRL’s zo spoedig mogelijk na afgifte.
·Voor de publicatie van de CRL wordt gebruik gemaakt van de databank van de root-CA.
Bovendien wordt voor elke CA in de CPS gespecificeerd binnen welke termijn een certificaat na afgifte door de CA wordt gepubliceerd.
In dit deel worden alleen het tijdstip of de frequentie van de regelmatige publicaties gespecificeerd. De connectiviteit voor het updaten van de C-ITS-stations binnen een week na de publicatie van de ECTL en CRL’s (onder normale bedrijfsomstandigheden, bv. met mobiele dekking, voertuig echt in werking, enz.) wordt geïmplementeerd overeenkomstig de vereisten in dit document.
2.3.Databanken
(31)De voorschriften betreffende de structuur van de databanken voor de opslag van certificaten en de informatie die door de entiteiten van het C-ITS-netwerk wordt verstrekt, zijn de volgende voor de afzonderlijke entiteiten:
·in het algemeen moet elke root-CA voor de publicatie van de certificaten voor de andere PKI-deelnemers (bv. een LDAPbased directory-dienst) gebruik maken van een databank van haar eigen actieve EA/AA-certificaatinformatie en CRL. De databank van elke root-CA ondersteunt alle vereiste toegangscontroles (punt 2.4) en transmissietijden (deel 2.2) voor elke methode voor de verspreiding van C-ITSgerelateerde informatie;
·de TLM-databank (waarin bijvoorbeeld de door het CPOC gepubliceerde ECTL- en TLM-certificaten worden opgeslagen) moet worden gebaseerd op een publicatiemechanisme dat de in punt 2.2 vastgestelde verzendtijden voor elke distributiemethode kan waarborgen.
Er worden geen eisen voor AA’s gedefinieerd, maar zij moeten dezelfde veiligheidsniveaus ondersteunen als de overige entiteiten en die moeten in hun CPS worden aangegeven.
2.4.Controle op de toegang tot databanken
(32)De vereisten inzake de controle op de toegang tot databanken met certificaatinformatie voldoen ten minste aan de algemene normen voor een veilige verwerking van informatie als beschreven in ISO/IEC 27001 en aan de voorschriften in deel 4. Bovendien weerspiegelen zij de behoeften inzake de procesbeveiliging die moeten worden vastgesteld voor de afzonderlijke stappen voor de publicatie van certificaatinformatie.
·Dit omvat ook de implementatie van de databank van TLM-certificaten en de ECTL in de TLM/het CPOC. Elke CA of databankbeheerder implementeert alle toegangscontroles in verband alle C-ITS-entiteiten en externe partijen voor ten minste drie verschillende niveaus (bv. openbaar, alleen voor C-ITS-entiteiten, root-CA-niveau) om te voorkomen dat niet-geautoriseerde entiteiten gegevens in de databank kunnen toevoegen, wijzigen of verwijderen.
·De exacte mechanismen voor toegangscontrole van de interne entiteit worden in de receptieve CPS opgenomen.
·Voor elke root-CA moeten de EA- en AA-databanken voldoen aan dezelfde eisen inzake de procedures voor toegangscontroles, ongeacht de plaats of de contractuele band met de dienstverlener die de databank beheert.
Als uitgangspunt voor de toegangscontroleniveaus moet elke root-CA of databankbeheerder ten minste drie verschillende niveaus aanbieden (bv. openbaar, alleen voor C-ITS-entiteiten, root-CA-niveau).
2.5.Publicatie van certificaatinformatie
2.5.1.Publicatie van certificaatinformatie door de TLM
(33)De TLM in het Europees gemeenschappelijk C-ITS-samenwerkingsdomein publiceert de volgende informatie via het CPOC:
·alle op dit moment geldige TLM-certificaten voor de volgende werkingsperiode (huidige en verbindingscertificaat indien beschikbaar);
·informatie over het toegangspunt voor het CPOC-databank voor het verstrekken van de ondertekende lijst van root-CA’s (ECTL);
·algemeen informatiepunt voor de uitrol van C-ITS en ECTL.
2.5.2.Publicatie van certificaatinformatie door CA’s
(34)Root-CA’s in het Europees gemeenschappelijk C-ITS-samenwerkingsdomein publiceren de volgende informatie:
·afgegeven (op dat moment geldige) root-CAcertificaten (lopende en correct hersleutelde certificaten, met inbegrip van een verbindingscertificaat) in de databank als bedoeld in punt 2.3;
·alle geldige EA- en AA-entiteiten, met hun exploitant-ID en geplande werkingstermijn;
·afgegeven CA-certificaten in de in punt 2.3 bedoelde databanken;
·de CRL’s voor alle ingetrokken CA-certificaten die betrekking hebben op hun ondergeschikte EA’s en AA’s;
·informatie over het toegangspunt van root-CA’s tot de CRL- en CA-informatie.
Alle certificaatinformatie wordt gecategoriseerd overeenkomstig de drie niveaus van vertrouwelijkheid; documenten voor het grote publiek moeten zonder beperkingen toegankelijk zijn.
3.Identificatie en authenticatie
3.1.Naamgeving
3.1.1.Soorten namen
3.1.1.1.Namen van TLM, root-CA’s, EA’s en AA’s
(35)De naam in het TLM-certificaat bestaat uit een enkel subject_name attribuut met een gereserveerde waarde „EU_TLM”.
(36)De naam van root-CA’s bestaat uit één subject_name attribuut met een door de CPA toegekende waarde. Het unieke karakter van namen is een exclusieve verantwoordelijkheid van de CPA; de TLM werkt de databank van root-CA-namen bij na kennisgeving door de CPA (goedkeuring, intrekking/schrapping van een root-CA). Subjectnamen in certificaten bestaan uit maximum 32 bytes. Elke root-CA stelt zijn naam voor aan de CPA via het aanvraagformulier (stroom 14). De CPA controleert of de naam uniek is. Indien de naam niet uniek is, wordt het aanvraagformulier afgewezen (stroom 4).
(37)De naam van elk EA/AA-certificaat kan bestaan uit één subject_name-attribuut met een door de certificaatverlener gegenereerde waarde. Het unieke karakter van de naam is de exclusieve verantwoordelijkheid van de verlenende root-CA.
(38)De benaming van EA- en AA-certificaten telt niet meer dan 32 bytes, aangezien de subject_name in certificaten beperkt is tot 32 bytes.
(39)AT’s bevatten geen naam.
3.1.1.2.Namen van eindentiteiten
(40)Elke C-ITS-station krijgt twee soorten unieke identificatiecodes:
·een canonieke ID, die bij de eerste registratie wordt opgeslagen onder de verantwoordelijkheid van de fabrikant. Die bevat een tekenreeks voor de identificatie van de fabrikant of exploitant, zodat die identificatiecode uniek kan zijn;
·een subject_name, die deel kan uitmaken van de EC van het C-ITS-station, onder de verantwoordelijkheid van de EA.
3.1.1.3.Identificatie van certificaten
(41)Certificaten overeenkomstig het in punt [5] vastgestelde formaat worden geïdentificeerd aan de hand van een HashedId8-waarde als gedefinieerd in [5].
3.1.2.Behoefte aan betekenisvolle namen
Geen bepaling.
3.1.3.Anonimiteit en pseudonimiteit van eindentiteiten
(42)De AA waarborgt dat de pseudonimiteit van een C-ITS-station wordt vastgesteld door aan het C-ITS-station AT’s toe te kennen die geen namen of informatie bevatten waarmee het subject aan zijn werkelijke identiteit kan worden gekoppeld.
3.1.4.Regels voor de interpretatie van naamformulieren
Geen bepaling.
3.1.5.Uniek karakter van namen
(43)Namen voor de TLM, root-CA’s, EA’s, AA’s en canonieke ID’s voor C-ITS-stations zijn uniek.
(44)De TLM waarborgt tijdens het registratieproces van een root-CA in de ECTL dat zijn certificaat-ID (HashedId8) uniek is. De root-CA zorgt er tijdens de toekenningsprocedure voor dat het certificaat-ID (HashedId8) van elke ondergeschikte CA uniek is.
(45)De HashedId8 van een EC is uniek binnen de uitgevende CA. De HashedId8 van een AT moet niet uniek zijn.
3.2.Validatie van de oorspronkelijke identiteit
3.2.1.Methode om het bezit van een private sleutel aan te tonen
(46)De root-CA bewijst dat zij in het bezit is van de private sleutel die overeenstemt met de openbare sleutel in het zelf ondertekend certificaat. Het CPOC controleert dit bewijs.
(47)De EA/AA bewijst dat zij de rechtmatige bezitter is van de private sleutel die overeenstemt met de openbare sleutel die in het certificaat moet worden genoemd. De root-CA controleert dit bewijs.
(48)Het bezit van een nieuwe private sleutel (voor het vernieuwen van een sleutel) wordt aangetoond door de ondertekening van de aanvraag met de nieuwe private sleutel (interne ondertekening), gevolgd door een externe handtekening met de huidige geldige private sleutel (om de authenticiteit van de aanvraag te waarborgen). De aanvrager dient de ondertekende certificaataanvraag via een beveiligde communicatie in bij de uitgevende CA. De uitgevende CA controleert of de digitale handtekening op de aanvraag gegenereerd is met de private sleutel die overeenstemt met de openbare sleutel die bij de certificaataanvraag is gevoegd. De root-CA specificeert in haar CPS welke certificaataanvragen en -antwoorden zij ondersteunt.
3.2.2.Authenticatie van de identiteit van de organisatie
3.2.2.1.Authenticatie van de identiteit van de root-CA
(49)In een aanvraagformulier aan de CPA (stroom 14), verstrekt de root-CA de identiteit van de organisatie en de registratiegegevens, bestaande uit:
·naam van de organisatie:
·postadres;
·e-mailadres;
·naam van een contactpersoon van de organisatie;
·telefoonnummer;
·gedrukte digitale vingerafdruk (d.w.z. SHA 256 hash-waarde) van het root-CA-certificaat;
·cryptografische informatie (d.w.z. cryptografische algoritmes, sleutellengtes) in het root-CA-certificaat;
·alle machtigingen die de root-CA mag gebruiken en mag doorgeven aan de subCA’s.
(50)Alvorens een root-CA in de ECTL op te nemen, controleert de CPA de identiteit van de organisatie en andere registratiegegevens die door de aanvrager van een certificaat zijn verstrekt.
(51)De CPA verzamelt hetzij rechtstreeks bewijs, hetzij een verklaring door een geschikte en erkende bron, van de identiteit (bv. naam) en, indien van toepassing, eventuele specifieke kenmerken van de subjecten waaraan een certificaat wordt verleend. Bewijzen mogen op papier of in de vorm van elektronische documenten worden ingediend.
(52)De identiteit van het subject wordt met passende middelen en overeenkomstig het huidige certificaatbeleid geverifieerd op het tijdstip van registratie.
(53)In elke certificaataanvraag wordt bewijs geleverd van:
·de volledige naam van de organisatie (particuliere organisatie, overheidsinstantie of niet-commerciële entiteit);
·nationaal erkende registratie of andere kenmerken die, voor zover mogelijk, mogen worden gebruikt om een onderscheid te maken tussen de organisatie en andere entiteiten met dezelfde naam.
De bovenstaande regels zijn gebaseerd op TS 102 042 [4]: De CA zorgt ervoor dat het bewijs van de identiteit van de abonnee en het subject en de correctheid van hun namen en bijbehorende gegevens naar behoren wordt onderzocht als onderdeel van de gedefinieerde dienst of, in voorkomend geval, door middel van onderzoek van de verklaringen van geschikte en erkende bronnen, en dat de certificaataanvragen volledig, geoorloofd en correct zijn conform de verzamelde bewijzen of attesten.
3.2.2.2.Authenticatie van de identiteit van de TLM
(54)De organisatie die de TLM exploiteert, levert bewijs van de identificatie en de juistheid van de naam en de bijbehorende gegevens zodat een passende controle kan plaatsvinden bij het genereren van het oorspronkelijke certificaat of een nieuwe sleutel voor het TLM-certificaat.
(55)De identiteit van het subject wordt met passende middelen en overeenkomstig het huidige certificaatbeleid geverifieerd bij het genereren van het oorspronkelijke certificaat en bij het genereren van een nieuwe sleutel.
(56)De bewijzen van de organisatie worden verstrekt zoals gespecificeerd in punt 3.2.2.1.
3.2.2.3.Authenticatie van de identiteit van de subCA
(57)De root-CA controleert de identiteit van de organisatie en andere door aanvragers van subCA (EA/AA)-certificaten verstrekte registratiegegevens.
(58)De root-CA zal minstens:
·bepalen of de organisatie bestaat door ten minste gebruik te maken van één identificatiedienst of databank van een derde partij, of, als alternatief, door het bevoegde overheidsagentschap of de erkende organisatie afgegeven of bewaarde organisatorische documenten die het bestaan van de organisatie bevestigen;
·de certificaataanvrager per gewone post of via een vergelijkbare procedure verzoeken om bepaalde informatie over de organisatie te bevestigen en te bevestigen dat hij ingestemd heeft met de certificaataanvraag en dat de persoon die de aanvraag namens de aanvrager indient daartoe gemachtigd is. Wanneer een certificaat de naam van een persoon als gemachtigde vertegenwoordiger van de organisatie bevat, moet tevens worden bevestigd dat de organisatie die persoon in dienst heeft en gemachtigd heeft namens haar op te treden.
(59)De valideringsprocedures voor de afgifte van CA-certificaten worden beschreven in een CPS van de root-CA.
3.2.2.4.Authenticatie van de eindentiteit als organisatie waarbij de abonnees zijn aangesloten
(60)Alvorens abonnees van eindentiteiten (fabrikanten/exploitanten) zich bij een vertrouwde EA kunnen inschrijven om hun eindentiteiten in staat te stellen EC-certificaataanvragen te verzenden, controleert de EA:
·de identiteit van de organisatie van de abonnee en andere registratiegegevens die door de certificaataanvrager zijn verstrekt;
·of het C-ITS-station (d.w.z. het concrete product op basis van een merk, model en versie van het C-ITS-station) aan alle beoordelingscriteria voldoet.
(61)De EA zal ten minste:
·bepalen of de organisatie bestaat door ten minste gebruik te maken van één identificatiedienst of databank van een derde partij, of, als alternatief, door het bevoegde overheidsagentschap of de erkende organisatie afgegeven organisatorische documenten die het bestaan van de organisatie bevestigen;
·de certificaataanvrager per gewone post of via een vergelijkbare procedure verzoeken om bepaalde informatie over de organisatie te bevestigen, en te bevestigen dat hij ingestemd heeft met de certificaataanvraag en dat de persoon die de aanvraag namens de aanvrager indient daartoe gemachtigd is. Wanneer een certificaat de naam van een persoon als gemachtigde vertegenwoordiger van de organisatie bevat, moet tevens worden bevestigd dat de organisatie die persoon in dienst heeft en gemachtigd heeft namens haar op te treden.
(62)De valideringsprocedures voor de registratie van een C-ITS-station door haar abonnees worden gedocumenteerd in een CPS van de EA.
3.2.3.Authenticatie van afzonderlijke entiteiten
3.2.3.1.Authenticatie van afzonderlijke TLM/CA-entiteiten
(63)Voor de authenticatie van een individuele entiteit (natuurlijke persoon) die geïdentificeerd wordt in verband met een rechtspersoon of een organisatie (bv. de abonnee), moet bewijs worden geleverd:
·van de volledige naam van de betrokkene (waaronder achternaam en voornamen, overeenkomstig het toepasselijke recht en de nationale identificatiepraktijken);
·van de geboortedatum en -plaats, verwijzing naar een nationaal erkend identiteitsbewijs of andere kenmerken van de abonnee die mogen worden gebruikt, voor zover mogelijk, om onderscheid te maken tussen de persoon en andere personen met dezelfde naam;
·van de volledige naam en de wettelijke status van de betrokken rechtspersoon of andere organisatie (bijv. de abonnee);
·van alle andere relevante registratiegegevens (bijv. inschrijving van bedrijven) van de betrokken rechtspersoon of andere organisatie;
·dat de betrokkene geassocieerd is met de rechtspersoon of andere organisatorische entiteit.
Bewijzen mogen op papier of in de vorm van elektronische documenten worden ingediend.
(64)Om zijn/haar identiteit te verifiëren, verstrekt de gemachtigde vertegenwoordiger van een root-CA, EA, AA of abonnee documentatie waaruit blijkt dat hij/zij voor de organisatie werkt (machtiging). Hij/zij legt ook een officieel identiteitsbewijs over.
(65)Voor het eerste inschrijvingsproces (stroom 31/32), verstrekt een vertegenwoordiger van de EA/AA alle nodige informatie aan de bijbehorende root-CA (zie punt 4.1.2).
(66)Het personeel van de root-CA verifieert de identiteit van de vertegenwoordiger van de certificaataanvrager en alle bijbehorende documenten en handelt daarbij conform de vereisten van „betrouwbaar personeel” als beschreven in punt 5.2.1. (Aangezien het gaat om gevoelige taken als bedoeld in punt 5.2.2, wordt het proces voor de validatie van de aanvraaginformatie en het genereren van het certificaat door de root-CA uitgevoerd door „betrouwbare personen” van de root-CA, onder ten minste tweevoudig toezicht).
3.2.3.2.Authenticatie van de identiteit van de abonnees van C-ITS-stations
(67)Abonnees worden vertegenwoordigd door gemachtigde eindgebruikers in de organisatie die zijn geregistreerd bij de afgifte van EA en AA. De door organisaties aangewezen eindgebruikers (fabrikanten of exploitanten) bewijzen hun identiteit en authenticiteit vóór:
·de registratie van de EE bij de overeenkomstige EA, met inbegrip van haar canonieke openbare sleutel, canonieke ID (uniek identificatiecode) en de machtigingen overeenkomstig de EE;
·de registratie van de AA en het bewijs van de abonnee-overeenkomst die naar de EA kan worden verstuurd.
3.2.3.3.Authenticatie van de identiteit van C-ITS-stations
(68)EE-subjecten van EC authenticeren zich bij de aanvraag van een EC (stroom 31) met behulp van hun canonieke private sleutel voor de eerste authenticatie. De EA controleert de authenticatie middels de canonieke openbare sleutel die overeenstemt met de EE. De canonieke openbare sleutels van de EE’s worden aan de EA bezorgd vóór de eerste aanvraag uitgevoerd is, via een veilig kanaal tussen de fabrikant van het C-ITS-station en de exploitant van de EA (stroom 33).
(69)EE-subjecten van AT’s authenticeren zichzelf bij AT-aanvragen (stroom 32) met behulp van hun unieke private inschrijvingssleutel. De AA stuurt de handtekening ter validering door naar de EA (stroom 25); de EA valideert ze en bevestigt het resultaat aan de AA (stroom 23).
3.2.4.Niet-gecontroleerde informatie over abonnees
Geen bepaling.
3.2.5.Valideren van de autoriteit
3.2.5.1.Valideren van TLM, root-CA, EA en AA
(70)Elke organisatie vermeldt in de CPS ten minste één vertegenwoordiger (bijv. een veiligheidsverantwoordelijke) die verantwoordelijk is voor de aanvraag van nieuwe certificaten en de vernieuwing van certificaten. De naamgevingsregels in punt 3.2.3 zijn van toepassing.
3.2.5.2.Valideren van abonnees van C-ITS-stations
(71)Ten minste één natuurlijke persoon die verantwoordelijk is voor de inschrijving van C-ITS-stations bij een EA (b.v. de veiligheidsverantwoordelijke) moet bekend zijn bij en goedgekeurd zijn door de EA (zie punt).
3.2.5.3.Valideren van C-ITS-stations
(72)Een abonnee van een C-ITS-station kan C-ITS-stations registreren bij een specifieke EA (stroom 33) zolang hij bij die EA is geauthenticeerd.
Wanneer het C-ITS-station bij een EA is ingeschreven met een unieke canonieke ID en een canonieke openbare sleutel, kan het een EC aanvragen middels een aanvraag die is ondertekend met de canonieke private sleutel die gelinkt is aan de eerder geregistreerde canonieke openbare sleutel.
3.2.6.Interoperabiliteitscriteria
(73)Voor communicatie tussen C-ITS en EA’s (of AA’s) moet het C-ITS-station een beveiligde communicatie tot stand kunnen brengen met de EA’s (of AA’s), d.w.z. voor de authenticatie-, vertrouwelijkheids- en integriteitsfuncties, als gespecificeerd in [1]. Er mogen andere protocollen worden gebruikt als [1] wordt uitgevoerd. De EA en de AA ondersteunen de beveiligde communicatie.
(74)De EA en de AA ondersteunen certificaataanvragen en antwoorden die voldoen aan [1], dat voorziet in een beveiligd AT-protocol voor aanvragen/antwoorden dat de anonimiteit van de aanvrager ten opzichte van de AA en de scheiding van functies tussen de AA en EA ondersteunt. Er mogen andere protocollen worden gebruikt op voorwaarde dat [1] wordt uitgevoerd. Om te voorkomen dat de identiteit van C-ITS-stations op lange termijn openbaar wordt gemaakt, is de communicatie tussen een mobiel C-ITS-station en de EA vertrouwelijk (b.v. communicatiegegevens worden van eind tot eind versleuteld).
(75)De AA dient een autorisatievalideringsverzoek in (stroom 25) voor elk autorisatieverzoek dat het van een EE-certificaatsubject ontvangt. De EA valideert dit verzoek met betrekking tot:
·de status van de EE bij de EA;
·de geldigheid van de handtekening;
·de gevraagde ITS-toepassings-ID’s (ITS-AID) en machtigingen;
·de status van de dienstverlening van de AA aan de abonnee.
3.3.Identificatie en authenticatie van aanvragen van nieuwe sleutels
3.3.1.Identificatie en authenticatie van routineaanvragen van nieuwe sleutels
3.3.1.1.TLM-certificaten
(76)De TLM genereert een sleutelpaar en twee certificaten: een zelf ondertekend en een verbindingscertificaat als bedoeld in deel 7.
3.3.1.2.root-CA-certificaat
Niet van toepassing.
3.3.1.3.Vernieuwing van een EA/AA-certificaat of vernieuwing van de sleutel
(77)Vóór het verstrijken van een EA/AA-certificaat, vraagt de EA/AA een nieuw certificaat (stroom 21/stroom 24) aan om de continuïteit van het certificaatgebruik te waarborgen. De EA/AA genereert een nieuw sleutelpaar ter vervanging van het verstrijkende sleutelpaar en ondertekent de aanvraag van de nieuwe sleutel, die de nieuwe openbare sleutel bevat met de huidige geldige private sleutel („rekeying”). De EA of AA genereert een nieuw sleutelpaar en ondertekent de aanvraag met de nieuwe private sleutel (interne handtekening) om te bewijzen dat zij de nieuwe private sleutel bezit. De volledige aanvraag wordt ondertekend (overtekend) met de huidige geldige private sleutel (externe handtekening) om de integriteit en de authenticiteit van de aanvraag te waarborgen. Indien een encryptie- en decryptiesleutelpaar wordt gebruikt, wordt bewijs geleverd van het bezit van de private encryptiesleutels (voor een gedetailleerde beschrijving van het vernieuwen van sleutels, zie punt 4.7.3.3).
(78)De indentificatie- en authenticatiemethode voor de routineprocedure om een nieuwe sleutel te genereren is dezelfde als voor de validering van de afgifte van een eerste root-CA-certificaat, zoals beschreven in punt 3.2.2.
3.3.1.4.Inschrijvingsbewijs eindentiteiten
(79)Vóór het verstrijken van de geldigheidstermijn van een bestaande EC, vraagt de EE een nieuw certificaat (stroom 31) aan om de continuïteit van het certificaatgebruik te waarborgen. De EE genereert een nieuw sleutelpaar ter vervanging van het verstrijkende sleutelpaar en een nieuw certificaat met de nieuwe openbare sleutel; de aanvraag wordt ondertekend met de huidige geldige private EC-sleutel.
(80)De EE kan de aanvraag ondertekenen met de gegenereerde nieuwe private sleutel (interne handtekening) om te bewijzen dat zij de nieuwe private sleutel bezit. De volledige aanvraag wordt daarna ondertekend (overtekend) met de huidige geldige private sleutel (externe handtekening) en versleuteld verzonden naar de ontvangende EA als gespecificeerd in [1] om de integriteit en de authenticiteit van de aanvraag te waarborgen. Er mogen andere protocollen worden gebruikt op voorwaarde dat [1] wordt uitgevoerd.
3.3.1.5.Autorisatiebewijzen van eindentiteiten
(81)De certificaathersleuteling voor AT’s is gebaseerd op dezelfde procedure als de oorspronkelijke autorisatie, zoals gedefinieerd in [1]. Er mogen andere protocollen worden gebruikt op voorwaarde dat [1] wordt uitgevoerd.
3.3.2.Identificatie en authenticatie van aanvragen van nieuwe sleutels na intrekkingen
3.3.2.1.CA-certificaten
(82)De authenticatie van een CA-organisatie voor de aanmaak van een nieuwe sleutel voor rootCA, EA en AA-certificaten na intrekking wordt op dezelfde manier behandeld als de eerste afgifte van een CA-certificaat, zoals uiteengezet in punt 3.2.2.
3.3.2.2.Inschrijvingsbewijs eindentiteiten
(83)De authenticatie van een EE voor de aanmaak van een nieuwe sleutel voor een EC-certificaat na intrekking wordt op dezelfde manier behandeld als de eerste afgifte van een EE-certificaat, zoals uiteengezet in punt 3.2.2.
3.3.2.3.Autorisatieverzoeken van eindentiteiten
Niet van toepassing, aangezien AT’s niet worden ingetrokken.
3.4.Identificatie en authenticatie voor intrekkingsverzoeken
3.4.1.Root-CA/EA/AA-certificaat
(84)Aanvragen om een root-CA-certificaat te schrappen in de ECTL worden door de root-CA geauthenticeerd bij de TLM (stromen 12 en 9). Aanvragen om intrekking van een EA/AA-certificaat worden geauthenticeerd door de relevante root-CA en subCA zelf.
(85)Aanvaardbare procedures voor de authenticatie van intrekkingsverzoeken van abonnees omvatten:
·een schriftelijke en ondertekend verzoek tot intrekking in de huisstijl van de onderneming van de abonnee, met verwijzing naar het certificaat dat moet worden ingetrokken;
·communicatie met de abonnee die redelijke zekerheid verschaft dat de persoon of organisatie die de intrekking vraagt ook daadwerkelijk de abonnee is. Afhankelijk van de omstandigheden, kan die communicatie op één of meer van de volgende manieren verlopen: per e-mail, post of koerier.
3.4.2.Inschrijvingsbewijs C-ITS-station
(86)De abonnee van het C-ITS-station kan de EC van een reeds geregistreerd CITS station intrekken bij een EA (stroom 34). De verzoekende abonnee creëert een verzoek tot intrekking van een bepaald C-ITS-station of een lijst van C-ITS-stations. De EA authenticeert de intrekking vóór de verwerking van de aanvraag en bevestigt de intrekking van de C-ITS-stations en hun EC’s.
(87)De EA kan de EC van een C-ITS-station intrekken overeenkomstig punt 7.3
3.4.3.Autorisatiebewijs C-ITS-station
(88)Aangezien AT’s niet worden ingetrokken, zijn zij slechts een beperkte termijn geldig. De aanvaardbare geldigheidstermijnen in dit certificaatbeleid zijn gespecificeerd in deel 7.
4.Operationele eisen inzake de levenscyclus van certificaten
4.1.Certificaataanvraag
(89)In dit deel worden de voorwaarden uiteengezet voor een eerste aanvraag van een certificaat.
(90)De term „certificaataanvraag” heeft betrekking op de volgende processen:
·de registratie en instelling van een vertrouwensband tussen de TLM en de CPA;
·de registratie en instelling van een vertrouwensband tussen de root-CA en de CPA en TLM, m.i.v. de invoer van het eerste root-CA-certificaat in de ECTL;
·de registratie en instelling van een vertrouwensband tussen de EA/AA en de root-CA, m.i.v. de afgifte van een nieuw EA/AA-certificaat;
·de registratie door de fabrikant/exploitant van het C-ITS-station bij de EA;
·de aanvraag van een EC/AT voor het C-ITS-station.
4.1.1.Wie kan een certificaataanvraag indienen?
4.1.1.1.Root-CA’s
(91)root-CA’s genereren hun eigen sleutelparen en geven zelf hun rootcertificaten af. Een root-CA kan via zijn aangewezen vertegenwoordiger een certificaataanvraag indienen (stroom 14).
4.1.1.2.TLM
(92)De TLM genereert zijn eigen sleutelparen en geeft zelf zijn certificaat af. De oorspronkelijke aanmaak van een TLM-certificaat wordt verwerkt door een vertegenwoordiger van de TLM onder toezicht van de CPA.
4.1.1.3.EA en AA
(93)Een gemachtigde vertegenwoordiger van de EA of AA kan een aanvraag van een subCA (EA en/of AA)-certificaat indienen bij de gemachtigde vertegenwoordiger van de desbetreffende root-CA (stroom 27/28).
4.1.1.4.C-ITS-station
(94)Abonnees registreren elk C-ITS-station bij de EA overeenkomstig punt 3.2.5.3.
(95)Elk bij de EA geregistreerd C-ITS-station kan EC-aanvragen verzenden (stroom 31).
(96)Elk C-ITS-station kan AT-aanvragen verzenden (stroom 32) zonder tussenkomst van de abonnee. Alvorens een AT aan te vragen, moeten C-ITS-stations een EC hebben.
4.1.2.Inschrijvingsproces en verantwoordelijkheden
(97)Machtigingen voor root-CA’s en sub-CA's die voor bijzondere (overheids)doelstellingen certificaten afgeven (speciale mobiele en vaste C-ITS-stations) kunnen uitsluitend worden verleend door de lidstaten waar de organisaties zijn gevestigd.
4.1.2.1.Root-CA’s
(98)Nadat een audit van de root-CA’s is uitgevoerd, (stroom 13 en 36, deel 8), kunnen zij verzoeken hun certificaten bij de CPA op te nemen in de ECTL (stroom 14). Het inschrijvingsproces verloopt op basis van een ondertekend papieren aanvraagformulier dat door de gemachtigde vertegenwoordiger van de root-CA persoonlijk wordt ingediend bij de CPA en dat ten minste de informatie bevat als bedoeld in de punten 3.2.2.1, 3.2.3 en 3.2.5.1.
(99)Het aanvraagformulier van de root-CA wordt ondertekend door zijn gemachtigde vertegenwoordiger.
(100)Naast het aanvraagformulier, verstrekt de gemachtigde vertegenwoordiger van de root-CA de CPA voor goedkeuring een afschrift van de CPS van de root-CA (stroom 15) en zijn auditrapport (stroom 16). Als die documenten worden goedgekeurd, genereert de CPA een conformiteitscertificaat en zendt zij dit naar het CPOC/de TLM en de overeenkomstige root-CA.
(101)De gemachtigde vertegenwoordiger van de root-CA dient daarna zijn aanvraagformulier (met de vingerafdruk van het zelf ondertekende certificaat), de officiële identiteitskaart en een autorisatiebewijs in bij het CPOC/TLM. Het zelf ondertekend certificaat wordt via elektronische weg ingediend bij het CPOC/de TLM. Het CPOC/de TLM controleert alle documenten en het zelf ondertekend certificaat.
(102)Als de resultaten van de controles positief zijn, stuurt de TLM het root-CA-certificaat naar de ECTL op basis van een kennisgeving door de CPA (stromen 1 en 2). Het proces is nauwkeurig beschreven in de CPS van de TLM.
(103)Een aanvullende procedure om een goedkeuring te krijgen van de CPS en het auditrapport van een root-CA bij een nationale instantie van specifieke landen moet mogelijk zijn.
4.1.2.2.TLM
(104)Nadat een audit van de TLM is uitgevoerd, kan de TLM zich laten inschrijven bij de CPA. Het inschrijvingsproces verloopt op basis van een ondertekend papieren aanvraagformulier dat door de gemachtigde vertegenwoordiger van de TLM persoonlijk wordt ingediend bij de CPA (stroom 38) en dat ten minste de informatie bevat als bedoeld in de punten 3.2.2.2 en 3.2.3.
(105)De gemachtigde vertegenwoordiger van de TLM ondertekent het aanvraagformulier van de TLM.
(106)Ten eerste genereert de TLM zijn eigen zelf ondertekend certificaat en verzendt hij dit op een beveiligde manier naar de CPA. Vervolgens dient de TLM zijn aanvraagformulier (met de vingerafdruk van het zelf ondertekend certificaat), een kopie van de CPS, een officieel identiteitsbewijs, een autorisatiebewijs en zijn auditrapport in bij de CPA (stroom 40). De CPA controleert alle documenten en het zelf ondertekend certificaat. Als het resultaat van de controle van alle documenten, het zelf ondertekend certificaat en de vingerafdruk positief is, bevestigt de CPA het inschrijvingsproces door zijn goedkeuring naar de TLM en het CPOC (stroom 39) te verzenden. De CPA bewaart de door de TLM verstuurde aanvraaggegevens. Het TLM-certificaat wordt daarna afgegeven via het CPOC.
4.1.2.3.EA en AA
(107)Tijdens het inschrijvingsproces, legt de EA/AA de relevante documenten (bv. de CPS en het auditrapport) ter goedkeuring voor aan de root-CA (stroom 27/28). Als het resultaat van de controle van de documenten positief is, stuurt de root-CA een goedkeuring naar de overeenkomstige sub-CA’s (stroom 29/30). De sub-CA (EA of AA) verzendt vervolgens haar ondertekende aanvraag via elektronische weg en dient haar aanvraagformulier (overeenkomstig punt 3.2.2.1), autorisatiebewijs en identiteitsbewijs persoonlijk in bij de overeenkomstige root-CA. De root-CA controleert de aanvraag en de ingediende documenten (aanvraagformulier met de vingerafdruk, namelijk de SHA 256-waarde van de sub-CA-aanvraag, het autorisatiebewijs en het identiteitsdocument). Als het resultaat van alle controles positief is, geeft de root-CA het overeenkomstige sub-CA-certificaat af. In haar specifieke CPS is nauwkeurig omschreven hoe een eerste aanvraag moet gebeuren.
(108)Naast het aanvraagformulier van de sub-CA, voegt de gemachtigde vertegenwoordiger van de sub-CA een kopie van de CPS bij de root-CA.
(109)Aan een geaccrediteerde PKI-auditeur wordt informatie verstrekt met het oog op een audit overeenkomstig deel 8.
(110)Indien een sub-CA eigendom is van een andere entiteit dan de entiteit die eigenaar is van een root-CA, ondertekent de entiteit van de sub-CA vóór de afgifte van een certificaataanvraag een contract met betrekking tot de root-CA-dienst.
4.1.2.4.C-ITS-station
(111)De oorspronkelijke registratie van eindentiteitsubjecten (C-ITS) gebeurt door de verantwoordelijke abonnee (fabrikant/exploitant) bij de EA (stromen 33 en 35) na een succesvolle authenticatie van de geabonneerde organisatie en één van haar vertegenwoordigers overeenkomstig de punten 3.2.2.4 en 3.2.5.2.
(112)Een C-ITS-station kan een sleutelpaar (zie punt 6.1) en een ondertekende aanvraag genereren overeenkomstig [1]. Er mogen andere protocollen worden gebruikt op voorwaarde dat [1] wordt uitgevoerd.
(113)Tijdens de registratie van een normaal C-ITS-station (in tegenstelling tot een speciaal mobiel of vast C-ITS-station), moet de EA nagaan of de in de oorspronkelijke aanvraag opgenomen machtigingen niet voor overheidsgebruik zijn bestemd. Machtigingen voor overheidsgebruik worden gedefinieerd door de betrokken lidstaten. De gedetailleerde procedure voor de registratie en het antwoord van de EA aan fabrikanten/exploitanten (stromen 33 en 35) is beschreven in de desbetreffende CPS van de EA.
(114)Een C-ITS-station wordt ingeschreven bij een EA (punt 3.2.5.3) door de verzending van zijn oorspronkelijke aanvraag overeenkomstig [1].
(115)Bij eerste registratie door een geauthenticeerde vertegenwoordiger van de abonnee, keurt de EA goed welke AT’s het eindentiteitsubject (d.w.z. het C-ITS-station) kan krijgen. Voorts wordt aan elke eindentiteit een betrouwbaarheidsniveau toegekend, dat gekoppeld is aan de certificering van de eindentiteit overeenkomstig een van de beschermingsprofielen in punt 6.1.5.2.
(116)Reguliere voertuigen hebben slechts één C-ITS-station dat bij één EA is geregistreerd. Bijzondere voertuigen (zoals politiewagens en andere bijzondere voertuigen met specifieke rechten) kunnen bij een aanvullende EA worden geregistreerd of over één extra C-ITS-station beschikken voor autorisaties binnen het toepassingsgebied van hun bijzondere bestemming. De verantwoordelijke lidstaten definiëren welke voertuigen onder een dergelijke vrijstelling vallen. Machtigingen voor speciale mobiele en vaste C-ITS-stations worden slechts door één verantwoordelijke lidstaat verleend. De CPS van root-CA’s of subCA’s die in die lidstaten certificaten voor dergelijke voertuigen afgeven, bepalen hoe het certificeringsproces op die voertuigen moet worden toegepast.
(117)Wanneer de abonnee bezig is met de migratie van een C-ITS-station van één EA naar een andere EA, mag het C-ITS-station bij twee (soortgelijke) EA’s zijn ingeschreven.
(118)Een C-ITS-station genereert een AT-sleutelpaar (zie punt 6.1) en een AT-aanvraag overeenkomstig [1]. Er mogen andere protocollen worden gebruikt op voorwaarde dat [1] wordt uitgevoerd.
(119)C-ITS-stations zenden een autorisatieverzoek naar de URL van de AA (stromen 32 en 26) door ten minste de vereiste gegevens als bedoeld in punt 3.2.3.3 te versturen. De AA en EA valideren de autorisatie van elk verzoek overeenkomstig de punten 3.2.6 en 4.2.2.5.
4.2.Verwerking van certificaataanvragen
4.2.1.Uitvoeren van de identificatie- en authenticatiefuncties
4.2.1.1.Identificatie en authenticatie van root-CA’s
(120)De gemachtigde vertegenwoordiger van de CPA is verantwoordelijk voor de authenticatie van de gemachtigde vertegenwoordiger van de root-CA en voor de goedkeuring van zijn inschrijvingsproces overeenkomstig deel 3.
4.2.1.2.Identificatie en authenticatie van de TLM
(121)De gemachtigde vertegenwoordiger van de CPA is verantwoordelijk voor de authenticatie van de gemachtigde vertegenwoordiger van de TLM en voor de goedkeuring van het aanvraagformulier voor het inschrijvingsproces overeenkomstig deel 3.
4.2.1.3.Identificatie en authenticatie van EA en AA
(122)De overeenkomstige root-CA is verantwoordelijk voor de authenticatie van de gemachtigde vertegenwoordiger van de EA/AA en voor de goedkeuring van het aanvraagformulier voor het inschrijvingsproces overeenkomstig deel 3.
(123)De root-CA bevestigt de validering van het aanvraagformulier aan de EA/AA. De EA/AA zendt vervolgens een certificaataanvraag naar de root-CA (stroom 21/24), die certificaten afgeeft aan de overeenkomstige EA/AA (stroom 18/19).
4.2.1.4.Identificatie en authenticatie van de EE-abonnee
(124)Voordat een C-ITS-station een certificaat kan aanvragen, verzendt de EE de identificatiecode van het C-ITS-station op beveiligde wijze naar de EA (stroom 33). De EA controleert de aanvraag. Als het resultaat van die controle positief is, registreert zij de informatie over het C-ITS-station in haar databank en bevestigt zij dit aan de EE-abonnee (stroom 35). Deze bewerking gebeurt slechts eenmaal door de fabrikant of exploitant van elk C-ITS-station. Zodra een C-ITS-station bij een EA is ingeschreven, kan het het op dat moment vereiste afzonderlijk EC-certificaat aanvragen (stroom 31). De EA authenticeert en controleert of de informatie in de aanvraag van een EC-certificaat geldig is voor een C-ITS-station.
4.2.1.5.Autorisatiebewijs
(125)Tijdens de autorisatieverzoeken (stroom 32), overeenkomstig [1], authenticeert de AA de EA waarvan het C-ITS-station de EC heeft ontvangen. Er mogen andere protocollen worden gebruikt op voorwaarde dat [1] wordt uitgevoerd. Indien de AA de EA niet kan authenticeren, wordt de aanvraag afgewezen (stroom 26). Als vereiste moet de AA beschikken over het EA-certificaat om de EA te authenticeren en haar respons te controleren (stromen 25 en 23, punt 3.2.5.3).
(126)De EA authenticeert het C-ITS-station dat een AT aanvraagt door zijn EC te controleren (stromen 25 en 23).
4.2.2.Goedkeuring of afwijzing van certificaataanvragen
4.2.2.1.Goedkeuring of afwijzing van root-CA-certificaten
(127)De CA-certificaten worden door de TLM in de ECTL ingevoerd/verwijderd overeenkomstig de goedkeuring van de CPA (stroom 1/2).
(128)De TLM controleert de handtekening, informatie en codering van root-CA-certificaten na ontvangst van een goedkeuring van de CPA (stroom 1). Na validering en goedkeuring door de CPA, voert de TLM het overeenkomstige root-certificaat in in de ECTL en stelt hij de CPA daarvan in kennis (stroom 5).
4.2.2.2.Goedkeuring of afwijzing van TLM-certificaten
(129)De CPA is verantwoordelijk voor de goedkeuring of afwijzing van TLM certificaten.
4.2.2.3.Goedkeuring of afwijzing van EA- en AA-certificaten
(130)De root-CA verifieert aanvragen van sub-CA-certificaten (stroom 21/24) en de desbetreffende verslagen (afgegeven door de geaccrediteerde PKI-auditeur) na ontvangst (stroom 36, deel 8) van de overeenkomstige sub-CA van de root-CA. Indien het resultaat van die controle positief is, zendt de overeenkomstige CA een certificaat naar de verzoekende EA/AA (stroom 18/19); zoniet wordt de aanvraag afgewezen en wordt geen certificaat afgegeven aan de EA/AA.
4.2.2.4.Goedkeuring of afwijzing van EC
(131)De EA verifieert en valideert de EC-verzoeken overeenkomstig de punten 3.2.3.2 en 3.2.5.3.
(132)Indien de certificaataanvraag overeenkomstig [1] correct en geldig is, geeft de EA het gevraagde certificaat af.
(133)Wanneer de certificaataanvraag ongeldig is, weigert de EA de aanvraag en stuurt zij een antwoord met de reden voor de weigering overeenkomstig [1]. Indien een C-ITS-station nog steeds een EC verlangt, moet het een nieuwe certificaataanvraag indienen. Er mogen andere protocollen worden gebruikt op voorwaarde dat [1] wordt uitgevoerd.
4.2.2.5.Goedkeuring of afwijzing van AT
(134)De certificaataanvraag wordt gecontroleerd door de EA. De AA communiceert met de EA voor de validering van de aanvraag (stroom 25). De EA authenticeert het aanvragende C-ITS-station en valideert of het overeenkomstig de CP recht heeft op de gevraagde AT (bv. door het controleren van de intrekkingsstatus en het valideren van de periodieke en geografische geldigheid van het certificaat, de machtigingen, het betrouwbaarheidsniveau, enz.). De EA antwoordt met een valideringsrespons (stroom 23) en, als die respons positief is, genereert de AA het aangevraagde certificaat C-ITS en stuurt zij dit door naar het C-ITS-station. Indien de AT-aanvraag niet correct is of de valideringsrespons van de EA negatief is, wijst de AA de aanvraag af. Indien een C-ITS-station nog steeds een AT nodig heeft, moet het een nieuwe autorisatieaanvraag indienen.
4.2.3.Termijn voor de verwerking van een certificaataanvraag
4.2.3.1.Aanvraag van een root-CA-certificaat
(135)De termijn voor de uitvoering van het identificatie- en authenticatieproces van een certificaataanvraag heeft alleen betrekking op werkdagen en mag de in de CPS van de root-CA bepaalde maximumtermijn niet overschrijden.
4.2.3.2.Aanvraag van een TLM-certificaat
(136)Voor de verwerking van de aanvraag van een TLM-certificaat geldt de in de CPS van de TLM vastgestelde maximumtermijn.
4.2.3.3.Aanvraag van een EA- en AA-certificaat
(137)De termijn voor de uitvoering van het identificatie- en authenticatieproces van een certificaataanvraag heeft alleen betrekking op werkdagen en stemt overeen met de overeenkomst en het contract tussen de root-CA van de lidstaat/particuliere organisatie en de subCA. De termijn voor de verwerking van de sub-CA-certificaten hangt af van de in de CPS van de sub-CA vastgestelde maximumtermijn.
4.2.3.4.Aanvraag van een EC
(138)Voor de verwerking van een EC-aanvraag geldt de in de CPS van de EA vastgestelde maximumtermijn.
4.2.3.5.Aanvraag van een AT
(139)Voor de verwerking van een AT-aanvraag geldt de in de CPS van de AA vastgestelde maximumtermijn.
4.3.Afgifte van certificaten
4.3.1.CA-acties tijdens de afgifte van certificaten
4.3.1.1.Afgifte van een Root-CA-certificaat
(140)Root-CA’s geven eigen zelf ondertekende root-CA-certificaten, verbindingscertificaten, sub-CA-certificaten en CRL’s af.
(141)Na goedkeuring door de CPA (stroom 4), stuurt de root-CA zijn certificaat naar de TLM via het CPOC voor toevoeging aan de ECTL (stromen 11 en 8) (zie 4.1.2.1). De TLM controleert of de CPA het certificaat heeft goedgekeurd (stroom 1).
4.3.1.2.Afgifte van een TLM-certificaat
(142)De TLM geeft zijn eigen zelf ondertekend TLM- en verbindingscertificaat af en zendt dit naar het CPOC (stroom 6).
4.3.1.3.Afgifte van een EA- en AA-certificaat
(143)De sub-CA’s genereren een ondertekende certificaataanvraag en sturen die door naar de overeenkomstige root-CA (stromen 21 en 24). De root-CA verifieert de aanvraag en geeft zo snel mogelijk een certificaat af aan de verzoekende sub-CA overeenkomstig [5], zoals vastgelegd in de CPS voor gebruikelijke operationele praktijken, doch uiterlijk vijf werkdagen na ontvangst van de aanvraag.
(144)De root-CA werkt de databank met subCA-certificaten bij.
4.3.1.4.Afgifte van EC
(145)Het C-ITS-station stuurt de EA een EC-aanvraag overeenkomstig [1]. De EA authenticeert en controleert of de informatie in de certificaataanvraag geldig is voor een C-ITS-station. Er mogen andere protocollen worden gebruikt op voorwaarde dat [1] wordt uitgevoerd.
(146)Indien het resultaat van de validering positief is, geeft de EA een certificaat af overeenkomstig de registratie van het C-ITS-station (zie 4.2.1.4) en stuurt zij die naar het C-ITS-station via een EC-antwoordbericht overeenkomstig [1]. Er mogen andere protocollen worden gebruikt op voorwaarde dat [1] wordt uitgevoerd.
(147)Als er geen registratie is, genereert de EA een foutcode en zendt zij die naar het C-ITS-station via een EC-antwoordbericht overeenkomstig [1]. Er mogen andere protocollen worden gebruikt op voorwaarde dat [1] wordt uitgevoerd.
(148)EC-aanvragen en EC-antwoorden worden versleuteld om de vertrouwelijkheid te waarborgen en ondertekend om de authenticatie en integriteit te waarborgen.
4.3.1.5.Afgifte van AT
(149)Het C-ITS-station stuurt de AA een AT-aanvraagbericht overeenkomstig [1]. De AA zendt naar de EA een AT-valideringsverzoek overeenkomstig [1]. De EA zendt een AT-valideringsverzoek naar de AA. Als het antwoord positief is, genereert de AA een AT en stuurt het die naar het C-ITS-station via een AT-antwoordbericht overeenkomstig [1]. Als het antwoord negatief is, genereert de AA een foutcode en stuurt het die naar het C-ITS-station via een AT-antwoordbericht overeenkomstig [1]. Er mogen andere protocollen worden gebruikt, voor zover [1] wordt uitgevoerd.
(150)AT-aanvragen en AT-antwoorden worden versleuteld (alleen vereist voor mobiele CITS-stations) om de vertrouwelijkheid te waarborgen en ondertekend om de authenticatie en integriteit te waarborgen.
4.3.2.Kennisgeving van certificaatafgiften aan abonnees door CA's
Niet van toepassing.
4.4.Aanvaarding van het certificaat
4.4.1.Proces voor de aanvaarding van certificaten
4.4.1.1.Root-CA
Niet van toepassing.
4.4.1.2.TLM
Niet van toepassing.
4.4.1.3.EA en AA
(151)De EA/AA controleert het type certificaat, de ondertekening en de informatie in het ontvangen certificaat. De EA/AA verwerpt alle EA/AA-certificaten die niet correct zijn gecontroleerd en genereert een nieuwe aanvraag.
4.4.1.4.C-ITS-station
(152)Het C-ITS-station toetst het van de EA/AA ontvangen EC/AT-antwoordbericht aan haar oorspronkelijke aanvraag, met inbegrip van de handtekening en de certificaatketen. Zij verwerpt alle EC/AT-antwoorden die niet correct zijn gecontroleerd. In dergelijke gevallen moet het een nieuwe EC/AT-aanvraag sturen.
4.4.2.Publicatie van certificaten
(153)TLM-certificaten en hun verbindingscertificaten worden via het CPOC ter beschikking gesteld van alle deelnemers.
(154)Root-CA-certificaten worden door het CPOC gepubliceerd via de ECTL, die door de TLM is ondertekend.
(155)Sub-CA- (EA en AA)-certificaten worden gepubliceerd door de root-CA.
(156)EC’s en AT’s worden niet gepubliceerd.
4.4.3.Kennisgeving van de afgifte van certificaten
Er wordt geen kennisgeving gedaan van een afgifte.
4.5.Sleutelpaar en gebruik van certificaten
4.5.1.Particuliere sleutel en gebruik van certificaten
4.5.1.1.Particuliere sleutel en gebruik van certificaten voor TLM
(157)De TLM gebruikt zijn eigen private sleutels voor de ondertekening van zijn eigen certificaten (TLM- en verbinding) en de ECTL.
(158)Het TLM-certificaat wordt door PKI-deelnemers gebruikt om de ECTL te controleren en de TLM te authenticeren.
4.5.1.2.Particuliere sleutel en gebruik van certificaten voor root-CA’s
(159)Root-CA’s gebruiken hun private sleutels om hun eigen certificaten, CRL, verbindingscertificaten en de EA/AA-certificaten te ondertekenen.
(160)Root-CA-certificaten worden door PKI-deelnemers gebruikt om de bijbehorende AA- en EA-certificaten, verbindingscertificaten en CRL’s te verifiëren.
4.5.1.3.Particuliere sleutel en gebruik van certificaten voor AA’s
(161)EA’s gebruiken hun private sleutels om EC’s te ondertekenen en voor de decryptie van inschrijvingsaanvragen.
(162)EA-certificaten worden gebruikt om de handtekening van bijbehorende EC’s te verifiëren en voor de encryptie van EC- en AC-aanvragen door de EE’s als gedefinieerd in [1].
(163)AA’s gebruiken hun private sleutels om AT’s te ondertekenen en voor de decryptie van AT-aanvragen.
(164)AA-certificaten worden door de EE’s gebruikt om bijbehorende AT’s te verifiëren en voor de encryptie van AT-aanvragen als gedefinieerd in [1].
4.5.1.4.Particuliere sleutel en gebruik van certificaten voor eindentiteiten
(165)EE’s gebruiken de private sleutel die overeenstemt met een geldig EC voor de ondertekening van een nieuwe inschrijvingsaanvraag als gedefinieerd in [1]. De nieuwe private sleutel wordt gebruikt om een interne handtekening te plaatsen op de aanvraag om het bezit te bewijzen van de private sleutel die overeenstemt met de nieuwe openbare EC-sleutel.
(166)EE’s gebruiken de private sleutel die overeenstemt met een geldig EC voor de ondertekening van een nieuw autorisatieverzoek als gedefinieerd in [1]. De private sleutel die overeenstemt met de nieuwe AT wordt gebruikt om een interne handtekening te plaatsen op de aanvraag om het bezit te bewijzen van de private sleutel die overeenstemt met de nieuwe openbare AT-sleutel.
(167)EE’s gebruiken de private sleutel die overeenstemt met een passende AT voor de ondertekening van C-ITS-boodschappen als gedefinieerd in [5].
4.5.2.Gebruik van certificaten en openbare sleutels door een vertrouwende partij
(168)Vertrouwende partijen gebruiken het betrouwbare certificeringspad en de bijbehorende openbare sleutels voor de doeleinden als bedoeld in de certificaten en voor de authenticatie van de betrouwbare gemeenschappelijke identiteit van de EC’s en AT’s.
(169)Root-CA, EA- en AA-certificaten, EC’s en AT’s worden niet gebruikt zonder voorafgaande controle door een vertrouwende partij.
4.6.Vernieuwing van een certificaat
Niet toegestaan.
4.7.Vernieuwing van een certificaatsleutel
4.7.1.Omstandigheden voor een vernieuwing van de certificaatsleutel
(170)Er wordt een nieuwe certificaatsleutel aangemaakt wanneer een certificaat het einde van zijn levensduur bereikt of als een private sleutel het einde van zijn operationeel gebruik bereikt maar de vertrouwensrelatie met de CA nog steeds bestaat. In all gevallen wordt een nieuw sleutelpaar en overeenkomstig certificaat gegenereerd.
4.7.2.Wie kan een nieuwe sleutel aanvragen?
4.7.2.1.Root-CA
(171)De root-CA vraagt geen nieuwe sleutel. Het vernieuwen van de sleutel is voor de root-CA een intern proces aangezien zij haar certificaat zelf ondertekent. De root-CA vernieuwt een sleutel hetzij met een verbindingscertificaat, hetzij door een nieuwe afgifte (zie punt 4.3.1.1).
4.7.2.2.TLM
(172)De TLM vraagt geen nieuwe sleutel. Het vernieuwen van de sleutel is voor de TLM een intern proces aangezien de TLM zijn certificaat zelf ondertekent.
4.7.2.3.EA en AA
(173)De aanvraag voor een sub-CA-certificaat moet tijdig worden ingediend om vóór het verstrijken van de huidige private sub-CA-sleutel zeker te beschikken over een nieuw sub-CA-certificaat en operationeel sub-CA-sleutelpaar. Bij de indieningsdatum moet ook rekening worden gehouden met de vereiste goedkeuringstermijn.
4.7.2.4.C-ITS-station
Niet van toepassing.
4.7.3.Vernieuwing van een sleutel
4.7.3.1.TLM-certificaat
(174)De TLM besluit een sleutel te vernieuwen op basis van de vereisten in de punten 6.1 en 7.2. De procedure is uitvoerig beschreven in zijn CPS.
(175)De TLM voert het proces voor de aanmaak van een nieuwe sleutel tijdig uit om ervoor te zorgen dat het nieuwe TLM-certificaat en verbindingscertificaat onder alle deelnemers kunnen worden verspreid voordat het huidige TLM-certificaat verstrijkt.
(176)De TLM gebruikt verbindingscertificaten voor het aanmaken van nieuwe sleutels en om de vertrouwensrelatie van het nieuwe zelf ondertekende certificaat te waarborgen. De nieuwe TLM en het verbindingscertificaat worden doorgegeven aan het CPOC.
4.7.3.2.Root-CA-certificaat
(177)De TLM besluit een sleutel te vernieuwen op basis van de vereisten in de punten 6.1 en 7.2. De procedure is uitvoerig beschreven in zijn CPS.
(178)De root-CA voert het proces voor de vernieuwing van de sleutel tijdig uit (vóór het root-CA-certificaat verstrijkt) zodat het nieuwe certificaat in de ECTL kan worden ingevoerd vóór het root-CA-certificaat geldig wordt (zie punt 5.6.2). De vernieuwing van de sleutel gebeurt hetzij via het verbindingscertificaat, hetzij zoals de oorspronkelijk aanvraag.
4.7.3.3.EA- en AA-certificaten
(179)De EA of AA vragen als volgt een nieuw certificaat aan:
|
Stap
|
Aanduiding
|
Aanvraag vernieuwing sleutel
|
|
1
|
Genereren sleutelpaar
|
De sub-CA’s (EA’s en AA’s) genereren nieuwe sleutelparen overeenkomstig punt 6.1.
|
|
2
|
Genereren van certificaataanvragen en interne handtekeningen
|
De sub-CA genereert een certificaataanvraag op basis van de nieuwe openbare sleutel in het licht van de naamgevingsregeling (subject_info) in deel 3, het handtekeningsalgoritme, de service-specifieke machtigingen (SSP) en facultatieve aanvullende parameters, en genereert de interne handtekening met de overeenkomstige nieuwe private sleutel. Als een encryptiesleutel vereist is, moet de sub-CA het bezit van de overeenkomstige private decryptiesleutel aantonen.
|
|
3
|
Externe handtekening genereren
|
De volledige aanvraag wordt ondertekend met de huidige geldige private sleutel om de authenticiteit van het ondertekende verzoek te garanderen.
|
|
4
|
Aanvraag verzenden aan de root-CA
|
De ondertekende aanvraag wordt ingediend bij de overeenkomstige root-CA.
|
|
5
|
Verificatie van een aanvraag
|
De overeenkomstige root-CA controleert de integriteit en de authenticiteit van de aanvraag. Ten eerste controleert zij de externe handtekening. Indien het resultaat van die controle positief is, wordt de interne handtekening gecontroleerd. Als er bewijs bestaat van het bezit van de private decryptiesleutel, controleert zij ook dat bewijs.
|
|
6
|
Aanvraag aanvaarden of afwijzen
|
Als het resultaat van alle controles positief is, aanvaardt de root-CA de aanvraag; zoniet wijst zij de aanvraag af.
|
|
7
|
Genereren en afgeven certificaat
|
De root-CA genereert een nieuw certificaat en verspreidt het naar de verzoekende sub-CA.
|
|
8
|
Antwoord verzenden
|
De sub-CA zendt een statusbericht (certificaat al dan niet ontvangen) naar de root-CA.
|
Tabel 3: Proces voor de vernieuwing van een sleutel voor de EA’s en AA’s
(180)Tijdens de automatische vernieuwing voor sub-CA’s, ziet de root-CA erop toe dat de aanvrager inderdaad in het bezit is van de private sleutel. Er worden passende protocollen voor het bewijs van private encryptiesleutels toegepast, bv. als gedefinieerd in RFC 4210 en 4211. Voor private ondertekeningssleutels wordt de interne handtekening gebruikt.
4.7.3.4.C-ITS-stationcertificaat
Niet van toepassing voor AT
4.8.Wijziging van een certificaat
Niet toegestaan.
4.9.Schorsing en intrekking van certificaten
Zie afdeling 7
4.10.Certificaatstatusdiensten
4.10.1.Operationele kenmerken
Niet van toepassing.
4.10.2.Beschikbaarheid van de dienst
Niet van toepassing.
4.10.3.Facultatieve functies
Niet van toepassing.
4.11.Einde van het abonnement
Niet van toepassing.
4.12.Bewaren en herstellen van sleutels
4.12.1.Abonnee
4.12.1.1.Welk sleutelpaar kan worden bewaard?
Niet van toepassing.
4.12.1.2.Wie kan een herstelaanvraag indienen?
Niet van toepassing.
4.12.1.3.Herstelprocedure en verantwoordelijkheden
Niet van toepassing.
4.12.1.4.Identificatie en authenticatie
Niet van toepassing.
4.12.1.5.Goedkeuring of afwijzing van herstelaanvragen
Niet van toepassing.
4.12.1.6.KEA- en KRA-handelingen tijdens het bewaren van sleutels
Niet van toepassing.
4.12.1.7.KEA en KRA beschikbaarheid
Niet van toepassing.
4.12.2.Beleid en praktijken inzake de inkapseling van sessiesleutels
Niet van toepassing.
5.Faciliteit, beheer en operationele controles
(181)De PKI bestaat uit de root-CA, de EA/AA, het CPOC en de TLM, m.i.v. hun ICT-componenten (bv. netwerken en servers).
(182)In dit deel wordt de entiteit die verantwoordelijk is voor een onderdeel van de PKI geïdentificeerd aan de hand van dat onderdeel zelf. Met andere woorden, de zin „de CA is verantwoordelijk voor de uitvoering van de audit” betekent hetzelfde als „de entiteit of persoon die de CA beheert is verantwoordelijk voor ...”.
(183)De term „onderdelen van het C-ITS-samenwerkingsmodel” omvat de root-CA, de TLM, de EA/AA, het CPOC en het beveiligde netwerk.
5.1.Fysieke controles
(184)Alle handelingen met het C-ITS-samenwerkingsmodel worden uitgevoerd in een fysiek beveiligde omgeving die ongeoorloofd(e) gebruik van, toegang tot of verspreiding van gevoelige informatie of systemen ontmoedigt, voorkomt en detecteert. Onderdelen van het C-ITS-samenwerkingsmodel gebruiken fysieke beveiligingscontroles overeenkomstig ISO 27001 en ISO 27005.
(185)De entiteiten die de onderdelen van het C-ITS-samenwerkingsmodel beheren, beschrijven de fysieke, procedurele en personele beveiligingscontroles in hun CPS. De CPS bevat informatie over de locatie en de bouw en locatie van de gebouwen en de fysieke beveiliging om de gecontroleerde toegang tot alle lokalen in de faciliteit van de entiteiten van het C-ITS-samenwerkingsmodel te waarborgen.
5.1.1.Bouw en locatie van de site
5.1.1.1.Root-CA, CPOC, TLM
(186)De locatie en bouw van de faciliteit waarin de rootCA, het CPOC en de TLM-apparatuur en -gegevens (HSM, activeringsgegevens, back-up van sleutelparen, computers, logbestanden, sleutelceremoniescript, certificaataanvragen, enz.) worden ondergebracht, voldoen aan de normen voor faciliteiten voor hoogwaardige en gevoelige informatie. Root-CA’s worden geëxploiteerd in een fysieke ruimte die afgescheiden is van fysieke ruimtes voor andere PKI-onderdelen.
(187)De root-CA, het CPOC en de TLM implementeren een beleid en procedures om te waarborgen dat een hoog veiligheidsniveau wordt gehandhaafd in de fysieke omgeving waarin de apparatuur van de root-CA is geïnstalleerd, om te garanderen dat:
·zij niet verbonden is met netwerken buiten het samenwerkingsmodel;
·zij is opgesplitst in een reeks (van ten minste twee) steeds beter beveiligde perimeters;
·gevoelige gegevens (HSM, back-up van sleutelparen, activeringsgegevens, enz.) worden opgeslagen in een afzonderlijke kluis die zich bevindt in een fysieke ruimte die middels meerdere toegangscontroles is beveiligd.
(188)De gebruikte beveiligingstechnieken worden ontworpen om bestand te zijn tegen een groot aantal en de combinatie van verschillende soorten aanvallen. De gebruikte mechanismen omvatten ten minste:
·perimeteralarmen, cameratoezicht, versterkte muren en bewegingsdetectoren;
·dubbele authenticatie (bv. chipkaart en PIN) voor elke persoon en een badge om de root-CA-faciliteiten en de beveiligde fysieke beveiligde zone te betreden of te verlaten.
(189)De root-CA, het CPOC en de TLM doen een beroep op gemachtigd personeel voor permanente monitoring (op 7x24x365 basis) van de faciliteit waar de apparatuur zich bevindt. De operationele omgeving (bv. fysieke faciliteit) wordt nooit onbeheerd achtergelaten. Personeelsleden van de operationele omgeving hebben nooit toegang tot de beveiligde zones van root-CA’s of sub-CA’s, tenzij zij daarvoor toestemming hebben gekregen.
5.1.1.2.EA/AA
(190)Dezelfde bepalingen van punt 5.1.1.1 zijn van toepassing.
5.1.2.Fysieke toegang
5.1.2.1.Root-CA, CPOC, TLM
(191)Apparatuur en gegevens (HSM, activeringsgegevens, back-ups van sleutelparen, computers, logbestanden, sleutelceremoniescripts, certificaataanvragen, enz.) moeten te allen tijde worden beschermd tegen toegang door onbevoegden. De mechanismen voor de fysieke beveiliging van apparatuur moeten ten minste:
·permanent persoonlijk of elektronisch toezicht houden op toegang door onbevoegden;
·waarborgen dat onbevoegden geen toegang krijgen tot de hardware en activeringsgegevens;
·ervoor zorgen dat alle verwijderbare media en papieren documenten met gevoelige tekstgegevens in een beveiligde houder worden bewaard;
·ervoor zorgen dat elke persoon die de beveiligde ruimtes betreedt en die geen permanente toegang heeft tot die ruimtes steeds onder toezicht staat van een gemachtigde werknemer van de root-CA, het CPOC en de TLM-faciliteiten;
·ervoor zorgen dat een toegangsregistratie wordt bijgehouden en regelmatig wordt gecontroleerd;
·voorzien in ten minste twee niveaus van steeds strengere beveiliging, bv. van het terrein, het gebouw en de controlekamer;
·twee betrouwbare fysieke toegangscontroles vereisen voor toegang tot cryptografische HSM en activeringsgegevens.
(192)Er wordt een beveiligingscontrole van de faciliteit met apparatuur uitgevoerd wanneer niemand in die faciliteit aanwezig is. Daarbij wordt ten minste gecontroleerd dat:
·de apparatuur zich in een staat bevindt die geschikt is voor de huidige werkingsmodus;
·voor offline-onderdelen, alle uitrusting is uitgeschakeld;
·elke beveiligde houder (verzegelde envelop, kluis, enz.) goed beveiligd is;
·fysieke beveiligingssystemen (bv. deursloten, verluchtingsroosters, elektriciteit) naar behoren functioneren;
·het gebied beveiligd is tegen ongeoorloofde toegang.
(193)Verwijderbare cryptografische modules worden vóór opslag gedeactiveerd. Wanneer zij niet gebruikt worden, worden dergelijke modules en de gegevens om ze te activeren in een kluis bewaard. Activeringsgegevens worden hetzij geregistreerd, hetzij bewaard en opgeslagen in het geheugen op een wijze die evenredig is met de beveiliging van de cryptografische module. Zij worden niet samen met de cryptografische module opgeslagen, teneinde te voorkomen dat slechts één persoon toegang heeft tot de private sleutel.
(194)Een persoon of groep betrouwbare personen krijgt de expliciete verantwoordelijkheid voor het verrichten van die controles. Wanneer een groep mensen verantwoordelijk is, wordt een logboek bijgehouden van de persoon die elke controle verricht. Indien er geen permanente aanwezigheid is in de faciliteit, tekent de laatste persoon een uitmeldingsformulier met vermelding van datum en tijd en bevestigt hij dat alle nodige fysieke beveiligingsmechanismen aanwezig en geactiveerd zijn.
5.1.2.2.EA/AA
(195)Dezelfde bepalingen van punt 5.1.2.1 zijn van toepassing.
5.1.3.Stroomvoorziening en airconditioning
(196)De beveiligde ruimten voor onderdelen van het C-ITS-samenwerkingsmodel (root-CA, CPOC, TLM, EA en AA) worden uitgerust met een betrouwbare stroomvoorziening om een storingsvrije werking of een werking zonder grote storingen te waarborgen. Er moeten primaire en backupinstallaties aanwezig zijn voor externe stroomonderbrekingen en voor een vlotte uitschakeling van de apparatuur van het C-ITS-samenwerkingsmodel bij een stroomtekort. Faciliteiten van het CITS-samenwerkingsmodel worden uitgerust met verwarming/ventilatie/airconditioning om de temperatuur en relatieve vochtigheid van de C-ITS-apparatuur binnen het operationele bereik te houden. Het CPS van het onderdeel van het C-ITS-samenwerkingsmodel bevat een gedetailleerde beschrijving van het plan en de processen om de vereisten na te leven.
5.1.4.Bescherming tegen waterschade
(197)De beveiligde ruimten voor onderdelen van het C-ITS-samenwerkingsmodel (root-CA, CPOC, TLM, EA en AA) worden beschermd om de impact van een blootstelling aan water zoveel mogelijk te beperken. Om die reden moeten water en -afvoerleidingen worden vermeden. Het CPS van het onderdeel van het C-ITS-samenwerkingsmodel bevat een gedetailleerde beschrijving van het plan en de processen om de vereisten na te leven.
5.1.5.Brandpreventie en bescherming
(198)Om schadelijke blootstelling aan vlammen of vuur te voorkomen, worden de beveiligde ruimten voor onderdelen van het CITS-samenwerkingsmodel (rootCA, CPOC, TLM, EA en de AA) dienovereenkomstig gebouwd en uitgerust en worden procedures ontwikkeld om brandgevaar aan te pakken. Gegevensdragers moeten in passende houders worden beschermd tegen brand.
(199)De onderdelen van het C-ITS-samenwerkingsmodel beschermen fysieke dragers met back-ups van kritieke systeemgegevens of andere gevoelige informatie tegen omgevingsrisico’s en ongeoorloofd gebruik van, ongeoorloofde toegang tot of ongeoorloofde verspreiding van die dragers. Het CPS van het onderdeel van het C-ITS-samenwerkingsmodel bevat een gedetailleerde beschrijving van het plan en de processen om de vereisten na te leven.
5.1.6.Beheer van gegevensdragers
(200)Gegevensdragers die worden gebruikt in het C-ITS-samenwerkingsmodel (root-CA, CPOC, TLM, EA en AA) worden veilig behandeld om hen te beschermen tegen beschadiging, diefstal of ongeoorloofde toegang. Er worden procedures voor het beheer van gegevensdragers opgezet om die dragers te beschermen tegen veroudering en kwaliteitsverlies gedurende de termijn tijdens dewelke gegevens moeten worden bewaard.
(201)Gevoelige gegevens worden beschermd tegen toegang ten gevolge van het hergebruik van gegevensdragers (bijvoorbeeld gewiste bestanden), waardoor de gevoelige gegevens toegankelijk zouden kunnen worden voor niet-gemachtigde gebruikers.
(202)Er wordt een inventaris van alle IT-activa bijgehouden met de eisen voor de bescherming van die activa overeenkomstig de risicoanalyse. Het CPS van het onderdeel van het C-ITS-samenwerkingsmodel bevat een gedetailleerde beschrijving van het plan en de processen om de vereisten na te leven.
5.1.7.Afvalverwijdering
(203)De onderdelen van het C-ITS-samenwerkingsmodel (root-CA, CPOC, TLM, EA en AA) implementeren procedures voor een beveiligde en onomkeerbare verwijdering van afval (papier, dragers of ander afval) ter voorkoming van ongeoorloofd gebruik van, ongeoorloofde toegang tot of ongeoorloofde verspreiding van afval dat vertrouwelijke/private informatie bevat. Alle dragers die worden gebruikt voor de opslag van gevoelige informatie, zoals sleutels, activeringsgegevens of dossiers, worden voor de vrijgave voor verwijdering vernietigd. Het CPS van het onderdeel van het C-ITS-samenwerkingsmodel bevat een gedetailleerde beschrijving van het plan en de processen om de vereisten na te leven.
5.1.8.Back-up op andere locatie
5.1.8.1.Root-CA, CPOC en TLM
(204)Volledige back-ups van de root-CA-, CPOC- en TLM-componenten, toereikend om na een systeemstoring te herstarten, worden offline gemaakt na de uitrol van de rootCA, het CPOC en de TLM en na elke aanmaak van een nieuw sleutelpaar. Er worden regelmatig back-ups gemaakt van essentiële bedrijfsinformatie (sleutelpaar en CRL) en software. Er wordt voorzien in adequate back-upfaciliteiten om te waarborgen dat alle essentiële bedrijfsinformatie en software kan worden gerecupereerd na een ramp of het falen van een gegevensdrager. Back-upvoorzieningen voor individuele systemen worden regelmatig getest om te waarborgen dat zij aan de eisen van het bedrijfscontinuïteitsplan voldoen. Ten minste één volledige back-upkopie wordt opgeslagen op een externe locatie (noodherstel). De back-upkopie wordt bewaard op een plaats met een fysieke en procedurele beveiliging die in verhouding staat tot die van het operationele PKI-systeem.
(205)Voor back-upgegevens gelden dezelfde voorschriften als voor de toegang tot operationele gegevens. Back-upgegevens worden versleuteld en opgeslagen op een andere locatie. In geval van volledig verlies van gegevens, worden de voor de herstart van de root-CA, CPOC en TLM benodigde gegevens volledig gerecupereerd uit de back-upgegevens.
(206)Van private root-CA-, CPOC- en TLM-sleutelgegevens wordt geen back-up gemaakt via de standaard back-upmechanismen maar via de back-upfunctie van de cryptografische module.
5.1.8.2.EA/AA
(207)De in punt 5.1.8.1 beschreven processen zijn op dit punt van toepassing.
5.2.Procedurele controles
In dit hoofdstuk worden de eisen inzake de rollen, plichten en identificatie van personeel beschreven.
5.2.1.Vertrouwensfuncties
(208)Werknemers, contractanten en consultants die met een vertrouwensfunctie zijn belast, worden als „betrouwbare personen” beschouwd. Personen die betrouwbare personen willen worden door een vertrouwensfunctie te verwerven, moeten aan de screeningeisen van dit certificaatbeleid voldoen.
(209)Betrouwbare personen hebben toegang tot of beheren de authenticatie van cryptografische bewerkingen die een materiële impact kunnen hebben op:
·de validering van informatie in certificaataanvragen;
·de aanvaarding, verwerping of andere verwerking van certificaataanvragen, of aanvragen tot intrekking of vernieuwing;
·de afgifte of intrekking van certificaten, met inbegrip van personeel dat toegang heeft tot beperkt toegankelijke delen van het register of de behandeling van informatie over of vragen van abonnees.
(210)Betrouwbare rollen omvatten onder meer:
·klantenservice;
·systeembeheer;
·specifieke ontwikkeling;
·leidinggevend personeel dat belast is met het beheer van de infrastructurele betrouwbaarheid.
(211)De CA neemt in haar CPS een duidelijke beschrijving van alle vertrouwensfuncties op.
5.2.2.Aantal vereiste personen per taak
(212)De onderdelen van het C-ITS-samenwerkingsmodel ontwikkelen, onderhouden en handhaven strikte controleprocedures om de scheiding van functies op basis van vertrouwensrollen te waarborgen en ervoor te zorgen dat verschillende betrouwbare personen vereist zijn om gevoelige taken uit te voeren. De elementen van het C-ITS-samenwerkingsmodel (TLM, CPOC, root-CA, EA en de AA) moeten voldoen aan [4] en de eisen in de onderstaande paragrafen.
(213)Er bestaan een beleid en procedures om de scheiding van rechten op basis van de taakomschrijving te waarborgen. Voor de meest gevoelige taken, zoals de toegang tot en het beheer van cryptografische hardware van de CA (HSM) en de bijbehorende sleutelelementen, moet de instemming van meerdere betrouwbare personen vereist zijn.
(214)De interne controleprocedures worden zodanig ontworpen dat ten minste twee betrouwbare personen vereist zijn voor een fysieke of logische toegang tot het apparaat. Beperkingen op de toegang tot cryptografische hardware van de CA moeten strikt worden gehandhaafd door meerdere betrouwbare personen gedurende de volledige levenscyclus van die hardware, van inspectie bij ontvangst tot de uiteindelijke logische en/of fysieke vernietiging. Zodra een module met operationele sleutels wordt geactiveerd, worden verdere toegangscontroles ingesteld om de scheiding tussen controle op de fysieke en logische toegang tot de apparatuur te handhaven.
5.2.3.Identificatie en authenticatie voor elke rol
(215)Alle personen aan wie een rol is toegekend, als beschreven in deze CP, worden geïdentificeerd en geauthenticeerd om te garanderen dat de rol hen in staat stelt zich van hun PKI-verplichtingen te kwijten.
(216)Onderdelen van het C-ITS-samenwerkingsmodel verifiëren en bevestigen de identiteit en machtiging van alle personeelsleden die als betrouwbare personen erkend willen worden alvorens zij:
·de toegangsmiddelen ontvangen en toegang krijgen tot de nodige faciliteiten;
·elektronische rechten krijgen voor de toegang tot en de uitvoering van specifieke verrichtingen op CA-systemen.
(217)De mechanismen die worden gebruikt voor de identificatie en authenticatie van personen worden beschreven in de CPS.
5.2.4.Regels inzake de scheiding van functies
(218)Tot de rollen die een scheiding van functies vereisen, behoren onder meer:
·het aanvaarden, afwijzen of intrekken van aanvragen, en andere acties voor de verwerking van CA-certificaataanvragen;
·het genereren, afgeven en vernietigen van een CA-certificaat.
(219)De scheiding van taken kan worden gehandhaafd middels de PKI-apparatuur en/of procedures. Aan een persoon wordt slechts één identiteit toegekend, tenzij de root-CA ermee ingestemd heeft meer identiteiten te verlenen.
(220)Het deel van de root-CA en CA dat verband houdt met het beheer van het genereren en intrekken van certificaten is onafhankelijk van andere organisaties voor zijn besluiten over de oprichting, levering, instandhouding en schorsing van diensten overeenkomstig het toepasselijke certificaatbeleid. Met name zijn directeur/directrice, leidinggevenden en personeelsleden met een vertrouwensfunctie mogen geen commerciële, financiële of andere druk ervaren die het vertrouwen in de door hen verleende diensten kan ondermijnen.
(221)De EA en de AA, die ten dienste staan van mobiele C-ITS-stations, zijn afzonderlijke operationele entiteiten, met gescheiden IT-infrastructuur en IT-managementteams. Overeenkomstig de GDPR wisselen de EA en AA geen persoonsgegevens uit, behalve voor de autorisatie van AT-aanvragen. Zij sturen gegevens over de goedkeuring van AT-aanvragen uitsluitend via een beveiligde interface door middels het validatieprotocol voor autorisaties [1]. Er mogen andere protocollen worden gebruikt op voorwaarde dat [1] wordt uitgevoerd.
(222)De door de EA en AA opgeslagen logbestanden mogen uitsluitend worden gebruikt voor het intrekken van EC’s na wangedrag op basis van op de AT onderschepte kwaadwillige CAM/DENM-berichten. Nadat een CAM/DENM-bericht als kwaadaardig is aangemerkt, zoekt de AA in zijn afgiftelogs de controlesleutel van de AT op en dient zij bij de EA een intrekkingsverzoek in met de versleutelde handtekening onder de private EC-sleutel die bij de afgifte van de AT is gebruikt. Alle logbestanden moeten op passende wijze worden beschermd tegen toegang door onbevoegde partijen en mogen niet met andere entiteiten of instanties worden gedeeld.
Noot: op het moment waarop dit CP is opgesteld, was het ontwerp van de wangedragfunctie niet gedefinieerd. Het is de bedoeling de potentiële vorm van de wangedragfunctie te omschrijven bij toekomstige herzieningen van het beleid.
5.3.Personeelscontroles
5.3.1.Eisen inzake kwalificaties, ervaring en veiligheidsscreening
(223)Elementen van het C-ITS-samenwerkingsmodel hebben voldoende personeelsleden in dienst met de vereiste deskundigheid, ervaring en kwalificaties voor de aangeboden diensten en functies. PKI-personeel vervult die eisen via formele opleidingen en erkenningen, reële ervaring of een combinatie van de twee. Vertrouwde rollen en verantwoordelijkheden, zoals aangegeven in de CPS, worden beschreven in de functieomschrijvingen en duidelijk geïdentificeerd. De functieomschrijvingen van subcontractanten van PKI-personeel waarborgen de scheiding van plichten en rechten; de gevoeligheid van functies wordt bepaald op basis van de plichten en toegangsniveaus, een achtergrondscreening en personeelsopleiding en -bewustmaking.
5.3.2.Procedures voor achtergrondonderzoek
(224)Elementen van het C-ITS-samenwerkingsmodel voeren achtergrondonderzoeken uit van personeelsleden die willen worden erkend als betrouwbare personen. Die achtergrondonderzoeken van personeelsleden met een vertrouwensfunctie worden minstens om de vijf jaar herhaald.
(225)Factoren die bij een achtergrondonderzoek aanleiding kunnen zijn om kandidaturen voor vertrouwensfuncties te weigeren of stappen tegen bestaande betrouwbare personen te ondernemen zijn (onder meer):
·leugenachtige verklaringen door de kandidaat of de vertrouwenspersoon;
·zeer ongunstige of onbetrouwbare professionele referenties;
·strafrechtelijke veroordelingen;
·aanwijzingen van een gebrek aan financiële verantwoordelijkheid.
(226)Verslagen die dergelijke informatie bevatten, worden beoordeeld door HR-personeel, dat redelijke maatregelen neemt in het licht van de aard, de omvang en de frequentie van het gedrag dat het achtergrondonderzoek aan het licht heeft gebracht. Dergelijke maatregelen kunnen bestaan uit de annuleringen van jobaanbiedingen aan de kandidaten voor vertrouwensfuncties of het ontslag van bestaande betrouwbare personen. Het gebruik van de informatie uit een achtergrondonderzoek als basis voor een dergelijke handeling is onderworpen aan de toepasselijke wetgeving.
(227)Het achtergrondonderzoek van personen die als vertrouwenspersoon willen worden erkend omvat onder meer:
·de bevestiging van de eerdere jobs;
·een controle van de professionele referenties gedurende ten minste vijf jaar;
·een bevestiging van de hoogste of meest relevante behaalde diploma’s;
·een raadpleging van het strafregister.
5.3.3.Opleidingsvereisten
(228)Elementen van het C-ITS-samenwerkingsmodel verstrekken hun personeel de vereiste opleiding om zich op bekwame en bevredigende wijze van hun verantwoordelijkheden in verband met CA-activiteiten te kwijten.
(229)De opleidingsprogramma’s worden op gezette tijden herzien en hun opleiding behandelt kwesties die relevant zijn voor de taken die worden verricht door hun personeel.
(230)Opleidingsprogramma’s behandelen kwesties die relevant zijn voor de specifieke omgeving van het personeelslid, met inbegrip van:
·beveiligingsbeginselen en -mechanismen van de elementen van het C-ITS-samenwerkingsmodel;
·de gebruikte hard- en softwareversies;
·alle plichten die de persoon dient te vervullen en de interne rapportageprocessen en -cycli;
·PKI-bedrijfsprocessen en workflows;
·de rapportage en afhandeling van incidenten en gevaarlijke situaties;
·procedures voor bedrijfscontinuïteit en dossierherstel;
·voldoende IT-kennis.
5.3.4.Voorschriften inzake nascholingsfrequentie
(231)Personen die een vertrouwensfunctie bekleden, dienen hun tijdens opleidingen opgedane kennis permanent op te frissen in een opleidingsomgeving. Opleiding moet worden herhaald wanneer dit noodzakelijk wordt geacht en ten minste om de twee jaar.
(232)Elementen van het C-ITS-samenwerkingsmodel verstrekken hun personeel bijscholing en updates zo vaak als nodig is om ervoor te zorgen dat zij het vereiste niveau van bekwaamheid behouden om zich op deskundige en bevredigende wijze van hun taken te kwijten.
(233)Personen in een vertrouwensfunctie zijn desgevallend op de hoogte van wijzigingen in de PKI-activiteiten. Significante wijzigingen van de activiteiten gaan gepaard met een opleidingsplan (bewustmaking), waarvan de uitvoering wordt gedocumenteerd.
5.3.5.Frequentie en sequentie van jobrotatie
(234)Geen regels voor zover de technische vaardigheden, ervaring en toegangsrechten gewaarborgd zijn. De beheerders van het C-ITS-samenwerkingsmodel zorgen ervoor dat personeelswijzigingen geen impact hebben op de veiligheid van het systeem.
5.3.6.Sancties voor onrechtmatige handelingen
(235)Elk element van het C-ITS-samenwerkingsmodel ontwikkelt een formele disciplinaire procedure om ervoor te zorgen dat onrechtmatige handelingen op passende wijze worden gesanctioneerd In ernstige gevallen worden de toegekende rollen en bevoegdheden ingetrokken.
5.3.7.Eisen ten aanzien van onafhankelijke contractanten
(236)Elementen van het C-ITS-samenwerkingsmodel mogen onafhankelijke contractanten of consultants slechts toestaan betrouwbare personen te worden voor zover zulks nodig is in het kader van een duidelijk omschreven uitbestedingsverhouding en op voorwaarde dat de entiteit evenveel vertrouwen heeft in die contractanten en consultants als in haar eigen werknemers en dat zij voldoen aan de eisen die op haar werknemers van toepassing zijn.
(237)Zoniet wordt aan onafhankelijke contractanten en consultants slechts toegang verleend tot beveiligde C-ITS PKI-faciliteiten onder begeleiding en toezicht van betrouwbare personen.
5.3.8.Aan het personeel verstrekte documentatie
(238)Elementen van het C-ITS-samenwerkingsmodel bieden hun personeel de vereiste opleiding en toegang tot de documentatie die zij nodig hebben om hun verantwoordelijkheden vakkundig en naar behoren uit te oefenen.
5.4.Procedures voor de registratie van audits
(239)In dit deel wordt beschreven welke voorvallen moeten worden geregistreerd en hoe logbestanden van audits moeten worden beheerd.
5.4.1.Door elke CA te registreren en te rapporteren voorvallen
(240)Een vertegenwoordiger van de CA bekijkt regelmatig de CA-logbestanden, voorvallen en procedures.
(241)Elementen van het C-ITS-samenwerkingsmodel registreren de volgende soorten voorvallen (indien van toepassing):
·fysieke toegang tot faciliteiten — de toegang van natuurlijke personen tot de faciliteiten wordt geregistreerd door het bewaren van de toegangsaanvragen via chipkaarten. Bij elke aanmaak van een record wordt een voorval gecreëerd;
·beheer van vertrouwensfuncties — alle wijzigingen van de definitie en toegang van de verschillende rollen worden geregistreerd, met inbegrip van wijzigingen van de inhoud van de rollen. Bij elke aanmaak van een record wordt een voorval gecreëerd;
·logische toegang — er wordt een voorval gegenereerd wanneer een entiteit (bv. een programma) toegang heeft tot gevoelige zones (d.w.z. netwerken en servers);
·back-upbeheer — er wordt een voorval gecreëerd telkens een back-up is voltooid, met of zonder succes;
·beheer van logbestanden — logbestanden worden opgeslagen. Er wordt een voorval gecreëerd wanneer de omvang van het logbestand een specifieke omvang overschrijdt;
·gegevens van de authenticatieprocedure voor abonnees en entiteiten van het C-ITS-samenwerkingsmodel — er wordt een voorval gegenereerd voor elk authenticatieverzoek door abonnees en elementen van het C-ITS-samenwerkingsmodel;
·aanvaarding en afwijzing van certificaataanvragen, met inbegrip van de aanmaak en vernieuwing van certificaten — er wordt periodiek een voorval gegenereerd met een lijst van de tijdens de zeven voorafgaande dagen goedgekeurde en afgewezen certificaataanvragen;
·registratie fabrikant — er wordt een voorval gecreëerd wanneer een fabrikant wordt geregistreerd;
·registratie C-ITS-station — er wordt een voorval gecreëerd wanneer een C-ITS-station wordt geregistreerd;
·HSM-beheer — er wordt een voorval gecreëerd wanneer een HSM-beveiligingsincident wordt geregistreerd;
·IT- en netwerkbeheer in verband met PKI-systemen — er wordt een voorval gecreëerd wanneer een PKI-server wordt uitgeschakeld of herstart;
·beveiligingsmanagement (geslaagde en mislukte toegangspogingen tot het PKI-systeem, uitgevoerde PKI- en beveiligingsacties, profielwijzigingen, systeemcrashes, hardwareproblemen en andere storingen, firewall- en routeractiviteiten; en het betreden en verlaten van de PKI-faciliteiten);
·gegevens in verband met voorvallen worden minstens vijf jaar bewaard, tenzij er aanvullende nationale regels gelden.
(242)Overeenkomstig de GDPR bieden de logbestanden van audits geen toegang tot privacygerelateerde gegevens betreffende privévoertuigen als C-ITS-station.
(243)Indien mogelijk worden logbestanden in verband met beveiliging automatisch verzameld. Als dat niet mogelijk is, wordt een logboek, papieren formulier of een ander fysiek mechanisme gebruikt. Alle logbestanden van beveiligingsaudits, zowel elektronische als niet-elektronische, worden bewaard en beschikbaar gesteld tijdens conformiteitsaudits.
(244)Bij de registratie van voorvallen in verband met de levenscyclus van een certificaat wordt ervoor gezorgd dat zichtbaar is wie de handeling heeft uitgevoerd. Alle gegevens met betrekking tot een persoonlijke identiteit worden versleuteld en beschermd tegen onrechtmatige toegang.
(245)Elk auditlogbestand omvat ten minste het volgende (automatisch of manueel geregistreerd voor elk controleerbaar voorval):
·soort voorval (uit de lijst hierboven);
·betrouwbare datum en tijd waarop het voorval zich heeft voorgedaan;
·resultaat van het voorval— geslaagd of mislukt;
·identiteit van de entiteit en/of de operator die het voorval heeft veroorzaakt en, indien van toepassing;
·identiteit van de entiteit aan wie het voorval is gericht.
5.4.2.Frequentie voor de verwerking van logbestanden
(246)Auditlogbestanden worden onderzocht na meldingen van onregelmatigheden en incidenten binnen het CA-systeem; voorts gebeurt dat jaarlijks.
(247)De verwerking van auditlogbestanden omvat een analyse van die bestanden en het documenteren van de reden van alle belangrijke gebeurtenissen in een samenvatting van de auditlog. De evaluatie van auditlogbestanden omvat een verificatie dat er niet met het logbestand is geknoeid, een inspectie van alle registraties en een onderzoek van alle meldingen of onregelmatigheden in de logbestanden. De maatregelen die worden genomen op basis van een evaluatie van een auditlogbestand worden gedocumenteerd.
(248)Auditlogbestanden worden ten minste wekelijks gearchiveerd. Een beheerder archiveert het bestand manueel als de beschikbare schijfruimte voor het auditlogbestand kleiner is dan de hoeveelheid auditloggegevens die naar verwachting die week zijn geproduceerd.
5.4.3.Bewaartermijn voor auditlogbestanden
(249)Logbestanden met betrekking tot certificaatlevenscycli worden bewaard tot minstens vijf jaar net het verstrijken van het overeenkomstige certificaat.
5.4.4.Bescherming van auditlogbestanden
(250)De integriteit en vertrouwelijkheid van de auditlogbestanden wordt gegarandeerd door een aan de rol gekoppeld mechanisme voor toegangscontrole. Interne auditlogbestanden zijn alleen toegankelijk voor beheerders; logbestanden in verband met de levenscyclus van certificaten mogen ook via een webpagina met een userlogin toegankelijk zijn voor gemachtigde gebruikers. Toegang moet worden verleend met een meergebruikersauthenticatie (ten minste twee gebruikers) op minstens twee niveaus. Technisch moet worden gewaarborgd dat gebruikers geen toegang hebben tot hun eigen logbestanden.
(251)Elk logbestand wordt ondertekend met HSM-sleutelelementen.
(252)Logbestanden van voorvallen die kunnen leiden tot persoonlijke identificatie, van bv. een privévoertuig, worden versleuteld zodat zij alleen door gemachtigde personen kunnen worden gelezen.
(253)Voorvallen worden op dusdanige wijze geregistreerd dat zij niet gemakkelijk kunnen worden gewist of vernietigd (tenzij voor overdracht naar langdurige dragers) binnen de termijn tijdens dewelke de logbestanden moeten worden bewaard.
(254)Logbestanden worden beschermd zodat zij gedurende hun volledige opslagtermijn leesbaar blijven.
5.4.5.Back-upprocedures van auditlogbestanden
(255)Van auditlogbestanden en samenvattingen wordt een back-up gemaakt via de back-upmechanismen van de onderneming, onder toezicht van gemachtigde betrouwbare personen, gescheiden van de brongeneratie van hun componenten. Back-ups van auditlogbestanden worden beschermd met hetzelfde vertrouwelijkheidsniveau als dat voor de oorspronkelijke bestanden.
5.4.6.Systeem voor de registratie van auditgegevens (intern of extern)
(256)De uitrusting van het C-ITS-samenwerkingsmodel activeert de auditprocessen bij het opstarten van het systeem en deactiveert deze pas bij het uitschakelen daarvan. Indien er geen auditprocessen beschikbaar zijn, schorst het element van het C-ITS-samenwerkingsmodel zijn werking.
(257)Aan het einde van elke werkingsperiode en bij het vernieuwen van certificaten, moet de collectieve status van apparatuur worden gerapporteerd aan de operations manager en het bestuursorgaan van het respectieve PKI-element.
5.4.7.Kennisgeving aan een subject dat een voorval veroorzaakt
(258)Wanneer een voorval door het auditregistratiesysteem wordt geregistreerd, wordt gewaarborgd dat dit aan een vertrouwde rol wordt gekoppeld.
5.4.8.Kwetsbaarheidsbeoordeling
(259)De rol die belast is met het uitvoeren van de audit en de rollen die verantwoordelijk zijn voor de werking van het PKI-systeem binnen de elementen van het CITS-samenwerkingsmodel verklaren alle belangrijke voorvallen in een samenvatting van de auditlogbestanden. Bij dergelijke evaluaties wordt gecontroleerd of er niet met het logbestand is geknoeid en of er geen sprake is van onderbrekingen in of verlies van de auditgegevens; alle loggegevens worden oppervlakkig gecontroleerd, gevolgd door een grondige analyse van meldingen of onregelmatigheden in de loggegevens. Naar aanleiding van die evaluatie genomen maatregelen worden gedocumenteerd.
(260)Elementen van het C-ITS-samenwerkingsmodel:
·implementeren organisatorische en/of technische detectie en preventieve controles onder toezicht van de elementen van het C-ITS-samenwerkingsmodel om de PKI-systemen te beschermen tegen virussen en malware;
·documenteren en zien toe op het proces voor het wegwerken van kwetsbaarheden dat betrekking heeft op de identificatie, evaluatie, respons en remediëring van kwetsbaarheden;
·ondergaan of voeren een kwetsbaarheidsanalyse uit:
·na elke systeem- of netwerkwijziging die door de elementen van het C-ITS-samenwerkingsmodel als significant voor PKI-onderdelen is aangemerkt; en
·ten minste eenmaal per maand, op openbare en private IP-adressen die door de CA, het CPOC als PKI-systemen zijn geïdentificeerd;
·worden onderworpen aan een indringingstest van PKI-systemen, minstens jaarlijks en na infrastructuur- of toepassingsupgrades of wijzigingen die door de elementen van het C-ITS-samenwerkingsmodel als significant voor de PKI-componenten van CA’s zijn aangemerkt;
·voor onlinesystemen, registreren bewijzen dat elke kwetsbaarheidsscan en indringingstest is uitgevoerd door een persoon of een entiteit (of collectieve groep daarvan) die beschikt over de voor de uitvoering van een betrouwbare kwetsbaarheids- of indringingstest vereiste vaardigheden, tools, bekwaamheid, ethische code en onafhankelijkheid;
·sporen kwetsbaarheden op en remediëren deze overeenkomstig het cyberbeveiligingsbeleid van de onderneming en de methode voor het beperken van risico’s.
5.5.Archiveren van gegevens
5.5.1.Soorten gearchiveerde gegevens
(261)Elementen van het C-ITS-samenwerkingsmodel archiveren voldoende nauwkeurige gegevens om de geldigheid van de handtekening en de goede werking van de PKI te kunnen vaststellen. Er worden gegevens van ten minste de volgende PKI-voorvallen gearchiveerd (indien van toepassing):
·logbestanden van de fysieke toegang tot de faciliteit van elementen van het C-ITS-samenwerkingsmodel (minimaal 1 jaar);
·logbestanden van het beheer van vertrouwensfuncties logbestanden voor elementen van het C-ITS-samenwerkingsmodel (minimaal 10 jaar);
·logbestanden van de IT-toegang van elementen van het C-ITS-samenwerkingsmodel (minimaal 5 jaar);
·logbestanden van de aanmaak, het gebruik en de vernietiging van een CA-sleutel (minimaal 5 jaar) (niet voor TLM en CPOC);
·logbestanden van de aanmaak, het gebruik en de vernietiging van certificaten (minimaal 2 jaar);
·logbestanden van CPA-aanvragen (minimaal 2 jaar);
·logbestanden van het beheer van activeringsgegevens voor elementen van het C-ITS-samenwerkingsmodel (minimaal 5 jaar);
·logbestanden van de IT en het netwerk van elementen van het C-ITS-samenwerkingsmodel (minimaal 5 jaar);
·PKI-documentatie van elementen van het C-ITS-samenwerkingsmodel (minimaal 5 jaar);
·veiligheidsincidenten en auditrapporten voor elementen van het C-ITS-samenwerkingsmodel (minimaal 10 jaar);
·apparatuur, software en de configuratie van het systeem (minimaal 5 jaar).
(262)De elementen van het C-ITS-samenwerkingsmodel bewaren de volgende documentatie met betrekking tot certificaataanvragen en de verificatie daarvan, en alle TLM-, root-CA- en CA-certificaten en CRL daarvan, gedurende ten minste zeven jaar na het einde van de geldigheid van alle certificaten op basis van die documentatie:
·door elementen van het C-ITS-samenwerkingsmodel bewaarde documentatie van PKI-audits;
·door elementen van het C-ITS-samenwerkingsmodel bewaarde CPS-documenten;
·door elementen van het C-ITS-samenwerkingsmodel bewaarde contracten tussen de CPA en andere entiteiten;
·door de CA en TLM bewaarde certificaten (of andere intrekkingsgegevens);
·gegevens van certificaataanvragen in het root-CA-systeem (niet van toepassing voor de TLM);
·andere toereikende gegevens of toepassingen om de inhoud van archieven te controleren;
·alle werkzaamheden in verband met confomiteitsauditeurs van elementen van het C-ITS-samenwerkingsmodel.
(263)De CA-entiteit bewaart alle documentatie met betrekking tot certificaataanvragen en de verificatie daarvan, en alle certificaten en intrekkingen daarvan, tot ten minste zeven jaar na het einde van de geldigheid van alle certificaten op basis van die documentatie.
5.5.2.Bewaartermijn van archieven
(264)Onverminderd de voorschriften op basis waarvan een langere archiveringstermijn vereist is, bewaren elementen van het C-ITS-samenwerkingsmodel alle gegevens tot ten minste vijf jaar na het verstrijken van het desbetreffende certificaat.
5.5.3.Bescherming van archieven
(265)Elementen van het C-ITS-samenwerkingsmodel bewaren het gegevensarchief in een veilige, beveiligde opslagfaciliteit die gescheiden is van de CA-apparatuur, met fysieke en procedurele beveiligingscontroles die vergelijkbaar zijn met of beter zijn dan die van de PKI.
(266)Het archief wordt beschermd tegen ongeoorloofde inzage, wijziging, schrapping of andere manipulaties door opslag in een betrouwbaar systeem.
(267)De dragers waarop de archiefgegevens zijn geplaatst en de toepassingen die nodig zijn om die gegevens te verwerken worden onderhouden om ervoor te zorgen dat zij gedurende de in dit CP bepaalde periode toegankelijk blijven.
5.5.4.Systeemarchief en opslag
(268)Elementen van het C-ITS-samenwerkingsmodel zetten van die informatie dagelijks stapsgewijs back-upsysteemarchieven op en maken wekelijks een volledige back-up. Afschriften van gegevens op papier worden bewaard in een beveiligde ruimte op een andere locatie.
5.5.5.Eisen inzake de datering van gegevens
(269)Elementen van het C-ITS-samenwerkingsmodel zorgen ervoor dat de gegevens informatie bevatten over het tijdstip en de datum waarop de intrekkingsgegevens werden gecreëerd. De integriteit van die informatie wordt geïmplementeerd met oplossingen op cryptografische basis.
5.5.6.Systeem voor de registratie van archiefgegevens (intern of extern)
(270)Het archiveringssysteem is intern.
5.5.7.Procedures voor het opvragen en controleren van archiefgegevens
(271)Alle elementen van het C-ITS-samenwerkingsmodel verlenen alleen gemachtigde betrouwbare personen toegang tot de archieven. Root-CA’s en CA’s beschrijven de procedures voor het creëren, controleren, verpakken, verzenden en opslaan van archiefgegevens in de CPS.
(272)De apparatuur van root-CA’s en CA’s controleert de integriteit van de informatie vooraleer die wordt hersteld.
5.6.Verwisseling van sleutels voor elementen van het C-ITS-samenwerkingsmodel
(273)De volgende elementen van het C-ITS-samenwerkingsmodel hebben specifieke vereisten voor de verwisseling van hun sleutels: TLM-, root-CA en EA/AA-certificaten.
5.6.1.TLM
(274)De TLM verwijdert zijn private sleutel bij het verstrijken van het overeenkomstige certificaat. Hij genereert een nieuw sleutelpaar en overeenkomstig TLM-certificaat alvorens de huidige geldige private sleutel te deactiveren. Hij ziet er op toe dat het nieuwe (verbindings)certificaat tijdig wordt ingevoerd in de ECTL zodat het vóór het geldig wordt naar alle C-ITS-stations wordt verspreid. Het verbindingscertificaat en het nieuw zelf ondertekend certificaat worden doorgestuurd naar het CPOC.
5.6.2.Root-CA
(275)De root-CA deactiveert en verwijdert de huidige private sleutel (met inbegrip van de back-upsleutels), zodat het geen EA/AA-certificaten afgeeft waarvan de geldigheidstermijn verder reikt dan de geldigheidstermijn van het root-CA-certificaat.
(276)Het root-CA genereert een nieuw sleutelpaar en overeenkomstig root-CA- en verbindingscertificaat alvorens het de huidige private sleutel (met inbegrip van de back-upsleutels) deactiveert en stuurt dit door naar de TLM voor opname in de ECTL. De geldigheidstermijn van het nieuwe root-CA-certificaat begint op het tijdstip van de geplande deactivering van de huidige private sleutel. De root-CA ziet er op toe dat het nieuwe certificaat tijdig wordt ingevoerd in de ECTL zodat het vóór het geldig wordt naar alle C-ITS-stations wordt verspreid.
(277)De root-CA activeert de nieuwe private sleutel wanneer het overeenkomstige root-CA-certificaat geldig wordt.
5.6.3.EA-/AA-certificaat
(278)De EA/AA deactiveren de huidige private sleutel zodat hij geen EC’s/AT’s afgeeft waarvan de geldigheidstermijn verder reikt dan de geldigheidstermijn van het EA/AA-certificaat.
(279)De EA/AA genereert een nieuw sleutelpaar en vraagt een overeenkomstig EA/AA-certificaat aan alvorens de huidige private sleutel te deactiveren. De geldigheidstermijn van het nieuwe EA/AA-certificaat begint op het tijdstip van de geplande deactivering van de huidige private sleutel. De EA/AA ziet erop toe dat het nieuwe certificaat tijdig kan worden gepubliceerd zodat het vóór het geldig wordt naar alle C-ITS-stations wordt verspreid.
(280)De EA/AA activeert de nieuwe private sleutel wanneer het overeenkomstige root-EA/AA-certificaat geldig wordt.
5.6.4.Auditeur
Geen bepalingen.
5.7.Herstel na incidenten en bedreigingen
5.7.1.Afhandeling van incidenten en compromitteringen
(281)Elementen van het C-ITS-samenwerkingsmodel monitoren hun uitrusting op permanente basis om potentiële gevallen van hacking of andere compromitteringen op te sporen. In een dergelijk geval stellen zij een onderzoek in om de aard en omvang van de schade te bepalen.
(282)Indien het personeel dat verantwoordelijk is voor het beheer van de root-CA of TLM een potentiële poging tot hacking of andere vorm van compromittering opmerkt, stelt het een onderzoek in om de aard en omvang van de schade te bepalen. In geval van compromittering van de private sleutel, wordt het root-CA-certificaat ingetrokken. De IT-beveiligingsdeskundigen van de CPA beoordelen de omvang van de mogelijke schade teneinde te bepalen of de PKI moet worden heropgebouwd, of slechts een aantal certificaten moeten worden ingetrokken en/of de PKI gecompromitteerd is. Bovendien bepaalt de CPA welke diensten moeten worden gehandhaafd (intrekking en informatie certificaatstatus) en op welke manier, overeenkomstig het bedrijfscontinuïteitsplan van de CPA.
(283)Incidenten, compromitteringen en de bedrijfscontinuïteit worden behandeld in de CPS, waarbij ook een beroep kan worden gedaan op andere middelen en plannen van de onderneming.
(284)Indien het personeel dat verantwoordelijk is voor het beheer van de EA/AA/CPOC een potentiële poging tot hacking of een andere vorm van compromittering opmerkt, stelt het een onderzoek in om de aard en omvang van de schade te bepalen. Het personeel dat verantwoordelijk is voor het beheer van de CA- of CPOC-entiteit beoordeelt de omvang van de mogelijke schade teneinde te bepalen of de PKI-component moet worden heropgebouwd, of slechts een aantal certificaten moeten worden ingetrokken en/of de PKI-component gecompromitteerd is. Bovendien bepaalt de sub-CA-entiteit welke diensten moeten worden gehandhaafd en hoe, overeenkomstig het bedrijfscontinuïteitsplan van de sub-CA-entiteit. Indien een PKI-component gecompromitteerd is, alarmeert de CA-entiteit haar eigen root-CA en de TLM via het CPOC.
(285)Incidenten, compromitteringen en de bedrijfscontinuïteit worden behandeld in de CPS van de root-CA, de TLM of andere relevante documenten in het geval van het CPOC, dat voor de uitvoering daarvan ook een beroep kan doen op andere middelen en plannen van de onderneming.
(286)De root-CA en CA alarmeren, met nauwkeurige informatie over de gevolgen van het incident, elke vertegenwoordiger van een lidstaat en root-CA waarmee zij binnen de C-ITS-context een overeenkomst hebben zodat zij hun eigen plan voor incidentenbeheer kunnen activeren.
5.7.2.Besmetting van computers, software en/of gegevens
(287)Als een ramp wordt ontdekt die de goede werking van een element van het C-ITS-samenwerkingsmodel belemmert, schorst dat element zijn activiteiten en onderzoekt het of de private sleutel gecompromitteerd is (behalve CPOC). Defecte hardware wordt zo snel mogelijk vervangen en de in de punten 5.7.3 en 5.7.4 beschreven procedures zijn van toepassing.
(288)Voor de hoogste risiconiveaus wordt besmetting van computers, software en/of gegevens binnen 24 uur gerapporteerd aan de root-CA. Alle andere gebeurtenissen worden opgenomen in de periodieke verslagen van de root-CA, EA’s en AA’s.
5.7.3.Procedure in geval van compromittering van private sleutels van entiteiten
(289)Indien de private sleutel van een root-CA gecompromitteerd, verloren of vernietigd is of verdacht wordt gecompromitteerd te zijn, neemt de root-CA de volgende stappen:
·de werking van die sleutel schorsen;
·het noodherstel- en migratieplan activeren;
·haar root-CA-certificaat intrekken;
·onderzoeken welk probleem aan de basis ligt van de compromittering van de sleutel en kennisgeving daarvan doen aan de CPA, die het root-CA certificaat via de TLM intrekt (zie deel 7);
·waarschuwen van alle abonnees waarmee zij een overeenkomst heeft.
(290)Indien een EA/AA-sleutel gecompromitteerd, verloren of vernietigd is of ervan verdacht wordt gecompromitteerd te zijn, neemt de EA/AA, root-CA de volgende stappen:
·de werking van die sleutel schorsen;
·haar eigen certificaat intrekken;
·het sleutelprobleem onderzoeken en kennisgeving daarvan doen aan de root-CA;
·waarschuwen van de abonnees waarmee zij een overeenkomst heeft.
(291)Als de EC- of AT-sleutel van een C-ITS-station gecompromitteerd, verloren of vernietigd is of ervan verdacht wordt gecompromitteerd te zijn, neemt de EA/AA waarbij het C-ITS-station is aangesloten de volgende stappen:
·de EC van het getroffen ITS intrekken;
·het sleutelprobleem onderzoeken en kennisgeving daarvan doen aan de root-CA;
·waarschuwen van de abonnees waarmee zij een overeenkomst heeft.
(292)Indien een algoritme of gerelateerde parameter die door de root-CA en/of CA of C-ITS-stations worden gebruikt, ontoereikend wordt voor het resterende bedoelde gebruik, informeert de CPA (met een aanbeveling van cryptografische deskundigen) de root-CA-entiteit waarmee zij een overeenkomst heeft en wijzigt zij de gebruikte algoritmes (voor nadere informatie zie deel 6 en de CPS van de root-CA en sub-CA).
5.7.4.Bedrijfscontinuïteit na een ramp
(293)De elementen van het C-ITS-samenwerkingsmodel die beveiligde faciliteiten voor CA-activiteiten exploiteren, ontwikkelen, testen, onderhouden en implementeren een noodherstelplan dat tot doel heeft de gevolgen van natuurrampen en door de mens veroorzaakte rampen te beperken. Dergelijke plannen zijn gericht op het herstel van de IT-systeemdiensten en belangrijke bedrijfsfuncties.
(294)Na een incident van een bepaald risiconiveau moet een nieuwe audit van de gecompromitteerde CA worden verricht door een geaccrediteerde PKIauditeur (zie deel 8).
(295)Als de gecompromitteerde CA niet langer kan functioneren (bv. na een ernstig incident), wordt een migratieplan opgesteld voor de overdracht van haar taken aan een andere root-CA.Ten minste de root-CA van de EU moet beschikbaar zijn om het migratieplan te ondersteunen. De gecompromitteerde CA beëindigt haar activiteiten.
(296)De root-CA neemt het noodherstelplan en het migratieplan op in de CPS.
5.8.Opzegging en overdracht
5.8.1.TLM
(297)De TLM beëindigt zijn werking niet maar een entiteit die de TLM beheert, kan een andere entiteit overnemen.
(298)Als de beherende entiteit verandert:
·vraagt zij de CPA om goedkeuring van de overdracht van het TLM-beheer van de oude entiteit naar de nieuwe entiteit;
·keurt de CPA de wijziging van het TLM-beheer goed;
·worden alle auditlogbestanden en gearchiveerde gegevens overgedragen van de oude beheersentiteit naar de nieuwe entiteit.
5.8.2.Root-CA
(299)De root-CA begint/beëindigt haar activiteiten niet zonder de vaststelling van een migratieplan (als omschreven in de relevante CPS) dat de blijvende werking voor alle abonnees waarborgt
(300)In geval van beëindiging van de root-CA-dienst, neemt de root-CA de volgende stappen:
·kennisgeving aan de CPA;
·kennisgeving aan de TLM, zodat die het root-CA-certificaat uit de ECTL kan verwijderen;
·intrekken van de overeenkomstige root-CA’s door de uitgifte van een CRL waarin zij zelf is opgenomen;
·waarschuwen van de root-CA’s waarmee zij een overeenkomst heeft voor de vernieuwing van EA/AA-certificaten;
·vernietigen van de private root-CA-sleutel;
·meedelen van de laatste informatie over de intrekkingsstatus (CRL ondertekend door de root-CA) aan de vertrouwende partij, waarbij duidelijk wordt aangegeven dat het om de laatste intrekkingsinformatie gaat;
·archiveren van alle auditlogbestanden en andere gegevens vóór de beëindiging van de PKI;
·overdragen van gearchiveerde gegevens aan een bevoegde autoriteit.
(301)De TLM verwijdert het overeenkomstige root-CA-certificaat uit de ECTL.
5.8.3.EA/AA
(302)In geval van beëindiging van de EA/AA-dienst, doet de EA/AA-entiteit een voorafgaande kennisgeving. De EA of AA begint/beëindigt haar activiteiten niet zonder de vaststelling van een migratieplan (als omschreven in de relevante CPS) dat de blijvende werking voor alle abonnees waarborgt De EA/AA:
·informeert de root-CA per aangetekende brief;
·vernietigt de private CA-sleutel;
·draagt haar databank over aan de door de root-CA aangewezen entiteit;
·stopt met de afgifte van certificaten;
·handhaaft tijdens de overdracht van haar databank en tot de databank volledig operationeel is, de mogelijkheid om vragen van de verantwoordelijke privacy-instantie te autoriseren;
·wanneer een sub-CA gecompromitteerd is, trekt de root-CA het sub-CA in en publiceert zij een CRL met de ingetrokken sub-CA’s;
·archiveert alle auditlogbestanden en andere gegevens vooraleer de PKI te beëindigen;
·draagt de gearchiveerde gegevens over aan een door de root-CA aangewezen entiteit.
(303)In geval van de beëindiging van de CA-diensten, is de CA verantwoordelijk voor het bijhouden van de relevante gegevens over de behoeften van de CA- en PKI-componenten.
6.Technische beveiligingscontroles
6.1.Genereren en installeren van sleutelparen
6.1.1.TLM, root-CA, EA, AA
(304)Het proces voor het genereren van sleutelparen moet voldoen aan de volgende eisen:
·elke deelnemer kan zijn eigen sleutelparen genereren overeenkomstig de punten 6.1.4 en 6.1.5;
·het proces voor het afleiden van symmetrische encryptiesleutels en een MAC-sleutel voor certificaataanvragen (ECIES) wordt uitgevoerd overeenkomstig [1] en [5];
·het proces voor het genereren van de sleutel maakt gebruikt van de algoritmes en sleutellengtes als beschreven in de punten 6.1.4.1 en 6.1.4.2;
·het proces voor het genereren van sleutelparen voldoet aan de eisen inzake de „veilige opslag van privésleutels” (zie punt 6.1.5);
·de root-CA’s en hun abonnees (sub-CA’s) waarborgen dat de integriteit en authenticiteit van hun publieke sleutels en de daarmee verbonden parameters tijdens de verspreiding naar de geregistreerde sub-CA-entiteiten gehandhaafd blijven.
6.1.2.EE — Mobiel C-ITS-station
(305)Elk mobiel C-ITS-station genereert zijn eigen sleutelparen overeenkomstig de punten 6.1.4 en 6.1.5.
(306)Het proces voor het afleiden van symmetrische encryptiesleutels en een MAC-sleutel voor certificaataanvragen (ECIES) wordt uitgevoerd overeenkomstig [1] en [5].
(307)De processen voor het genereren van de sleutel maken gebruik van de algoritmes en sleutellengtes als beschreven in de punten 6.1.4.1 en 6.1.4.2.
(308)De processen voor het genereren van sleutelparen voldoen aan de eisen inzake de „veilige opslag van privésleutels” (zie punt 6.1.5).
6.1.3.EE — Vast C-ITS-station
(309)Elk vast C-ITS-station genereert zijn eigen sleutelpaar overeenkomstig de punten 6.1.4 en 6.1.5.
(310)De processen voor het genereren van de sleutel maken gebruik van de algoritmes en sleutellengtes als beschreven in de punten 6.1.4.1 en 6.1.4.2.
(311)De processen voor het genereren van sleutelparen voldoen aan de eisen inzake de „veilige opslag van privésleutels” (zie punt 6.1.5).
6.1.4.Cryptografische vereisten
(312)Alle PKI-deelnemers moeten voldoen aan de in de volgende paragrafen beschreven cryptografische vereisten met betrekking tot het handtekeningalgoritme, de sleutellengte, de willekeurige nummergenerator en de verbindingscertificaten.
6.1.4.1.Algoritme en sleutellengte — Handtekeningalgoritmes
(313)Alle PKI-deelnemers (TLM, root-CA, EA, AA en C-ITS-stations) zijn uiterlijk twee jaar na de inwerkingtreding van deze verordening in staat sleutelparen te genereren en een private sleutel te gebruiken voor de ondertekening van verrichtingen met geselecteerde algoritmes, overeenkomstig tabel 4.
(314)Alle PKI-deelnemers die de integriteit van de ECTL, certificaten en/of ondertekende berichten overeenkomstig hun rol moeten controleren als gedefinieerd in punt 1.3.6, ondersteunen de in tabel 5 voor controle genoemde overeenkomstige algoritmes. Met name C-ITS-stations moeten de integriteit van de ECTL kunnen controleren.
|
|
TLM
|
Root-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 betekent verplichte ondersteuning
|
Tabel 4: Genereren van sleutelparen en ondertekening met de private sleutel
|
|
TLM
|
Root-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 betekent verplichte ondersteuning
|
Tabel 5: Controleoverzicht
(315)Als de CPA daartoe besluit op basis van recentelijk geconstateerde cryptografische tekortkomingen, kunnen alle C-ITS-stations zo snel mogelijk omschakelen naar één van de twee algoritmes (ECDSA_nistP256_with_SHA 256 of ECDSA_brainpoolP256_with_SHA 256). Welk(e) algoritme(s) werkelijk worden gebruikt, wordt bepaald in de CPS van de CA die het certificaat voor de overeenkomstige openbare sleutel afgeeft, overeenkomstig dit CP.
6.1.4.2.Algoritme en sleutellengte — versleutelingsalgoritmes voor inschrijving en autorisatie
(316)Alle PKI-deelnemers (EA, AA en C-ITS-stations) zijn uiterlijk twee jaar na de inwerkingtreding van deze verordening in staat openbare sleutels te gebruiken om inschrijvings- en autorisatieaanvragen/-antwoorden te versleutelen met geselecteerde algoritmes, overeenkomstig tabel 6. Welke algoritmes werkelijk worden gebruikt, wordt bepaald in de CPS van de CA die het certificaat voor de overeenkomstige openbare sleutel afgeeft, overeenkomstig dit CP.
(317)De in tabel 6 genoemde algoritmes geven de sleutellengte en de lengte van het hash-algoritme weer en worden toegepast overeenkomstig [5].
|
|
TLM
|
Root-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 betekent verplichte ondersteuning
|
Tabel 6: Gebruik van openbare sleutels voor de encryptie van inschrijvings- en autorisatieaanvragen/-antwoorden
(318)Alle PKI-deelnemers (EA, AA en C-ITS-stations) zijn uiterlijk twee jaar na de inwerkingtreding van deze verordening in staat sleutelparen te genereren en een private sleutel te gebruiken voor de decryptie van inschrijvings- en autorisatieaanvragen/-antwoorden met geselecteerde algoritmes, overeenkomstig tabel 7.
|
|
TLM
|
Root-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 betekent verplichte ondersteuning
|
Tabel 7: Genereren van sleutelparen en gebruik van private sleutels voor de decryptie van inschrijvings- en autorisatieaanvragen/-antwoorden
6.1.4.3.Cryptoflexibiliteit
(319)Voorschriften inzake de lengte van de sleutels en algoritmes moeten in de loop van de tijd worden veranderd om een adequaat beveiligingsniveau te handhaven. De CPA monitort de behoefte van die wijzigingen in het licht van de echte kwetsbaarheden en geavanceerde cryptografie. Zij redigeert, valideert en publiceert een actualisering van dit certificaatbeleid als zij besluit dat de cryptografische algoritmes moeten worden bijgewerkt. Wanneer in een nieuwe versie van dit CP een wijziging van het algoritme en/of de sleutellengte wordt gesignaleerd, bepaalt de CPA een migratiestrategie met een overgangsperiode tijdens dewelke ook de oude algoritmes en sleutellengte nog moeten worden ondersteund.
(320)Om de overdracht van nieuwe algoritmes en/of sleutellengtes mogelijk te maken en te faciliteren, wordt aanbevolen dat alle PKI-deelnemers hard- en/of software gebruiken die een omschakeling van de sleutellengtes en algoritmes mogelijk maakt.
(321)Wijzigingen van root- en TLM-certificaten worden ondersteund en uitgevoerd met behulp van verbindingscertificaten (zie punt 4.6), die gebruikt worden om de overgangstermijn tussen de oude en de nieuwe rootcertificaten te overbruggen („migratie van het samenwerkingsmodel”).
6.1.5.Beveiligde opslag van private sleutels
Dit punt beschrijft de eisen voor de beveiligde opslag en het genereren van sleutelparen en willekeurige getallen voor CA’s en eindentiteiten. Deze eisen zijn gedefinieerd voor cryptografische modules en worden beschreven in de volgende punten.
6.1.5.1.Root-CA, sub-CA en TLM-niveau
(322)Er wordt een cryptografische module gebruikt voor:
·het genereren, gebruiken, beheren en opslaan van private sleutels;
·het genereren en gebruiken van willekeurige getallen (het genereren van willekeurige getallen wordt beoordeeld als onderdeel van de beveiligingsbeoordeling en -certificering);
·het creëren van back-ups van private sleutels overeenkomstig punt 6.1.6;
·het verwijderen van private sleutels.
De cryptografische module wordt gecertificeerd met een van de volgende beschermingsprofielen (PP’s), met zekerheidsniveau EAL-4 of hoger:
·Beschermingsprofielen voor HSMs:
·CEN EN 419 221-2: Protection profiles for TSP cryptographic modules – Part 2: Cryptographic module for CSP signing operations with backup
·CEN EN 419 221-4: Protection profiles for TSP cryptographic modules – Part 4: Cryptographic module for CSP signing operations without backup;
·CEN EN 419 221-5: Protection profiles for TSP cryptographic modules – Part 5: Cryptographic module for trust services;
·Beschermingsprofielen voor chipcards:
·CEN EN 419 211-2: Protection profiles for secure signature creation device – Part 2: Device with key generation;
·CEN EN 419 211-3: Protection profiles for secure signature creation device — Part 3: Device with key import.
De manuele toegang tot de cryptografische module vereist een tweevoudige authenticatie door de beheerder. Dit vereist bovendien de betrokkenheid van twee gemachtigde personen.
De implementatie van een cryptografische module zorgt ervoor dat de sleutels niet toegankelijk zijn buiten de cryptografische module. De cryptografische module omvat een toegangscontrolemechanisme ter voorkoming van ongeoorloofd gebruik van private sleutels.
6.1.5.2.Eindentiteit
(323)Er wordt een cryptografische module voor EE’s gebruikt voor:
·het genereren, gebruiken, beheren en opslaan van private sleutels;
·het genereren en gebruiken van willekeurige getallen (het genereren van willekeurige getallen wordt beoordeeld als onderdeel van de beveiligingscertificering en -beoordeling);
·het beveiligd verwijderen van private sleutels.
(324)De cryptografische module wordt beschermd tegen ongeoorloofde verwijdering, vervanging en wijziging. Alle PP’s en gerelateerde documenten die van toepassing zijn op de beveiligingscertificering van de cryptografische module worden beoordeeld, gevalideerd en gecertificeerd overeenkomstig ISO 15408, met toepassing van de Mutual recognition agreement of information technology security evaluation certificates of the Senior Officials Group on Information Systems Security (Overeenkomst inzake wederzijdse erkenning van IT-beveiligingsbeoordelingscertificaten – SOG-IS), of een gelijkwaardige Europese regeling voor cyberbeveiligingscertificering in het kader van het Europese kader voor cyberbeveiliging.
(325)Gezien het belang om het hoogst mogelijke beveiligingsniveau in stand te houden, worden beveiligingscertificaten voor de cryptografische module afgegeven op basis van de criteria van de gemeenschappelijke certificatieregeling (ISO 15408), hetzij door een conformiteitsbeoordelingsinstantie die in het kader van de SOG-IS-overeenkomst door het beheerscomité is erkend, hetzij door een conformiteitsbeoordelingsinstantie die geaccrediteerd is door de cyberbeveiligingscertificeringsinstantie van een lidstaat. Een conformiteitsbeoordelingsinstantie hanteert ten minste gelijkwaardige eisen voor de beoordeling van de veiligheid als die waarin de SOG-IS-overeenkomst inzake wederzijdse erkenning voorziet.
Noot: de link tussen de cryptografische module en het C-ITS-station wordt beschermd.
6.1.6.Backup van private sleutels
(326)Het maken, opslaan en gebruiken van back-ups van private sleutels voldoet ten minste aan de eisen van het voor de oorspronkelijke sleutels vereiste beveiligingsniveau.
(327)Back-ups van private sleutels worden gemaakt door root-CA’s, EA’s en AA’s.
(328)Er worden geen back-ups van private sleutels gemaakt voor EC’s en AT’s.
6.1.7.Vernietiging van private sleutels
(329)Root-CA’s, EA’s en AA’s, en de mobiele en vaste C-ITS-stations vernietigen hun private sleutel en alle overeenkomstige back-ups, als er een nieuw sleutelpaar en overeenkomstig certificaat is gegenereerd en met succes is geïnstalleerd en de eventuele tijdsoverlap (alleen voor CA) is verstreken. De private sleutel wordt vernietigd met behulp van het mechanisme voor de cryptografische module die wordt gebruikt voor de centrale opslag of zoals beschreven in de overeenkomstige PP als bedoeld in punt 6.1.5.2.
6.2.Activeringsgegevens
(330)Activeringsgevens hebben betrekking op de vereiste authenticatiefactoren om cryptografische modules te beschermen tegen ongeoorloofde toegang. Het gebruik van activeringsgegevens van een cryptografisch toestel van de CA vergt handelingen van twee gemachtigde personen.
6.3.Technische beveiligingscontroles
(331)De computerbeveiligingscontroles van CA’s worden ontwikkeld in overeenstemming met het hoge veiligheidsniveau door de naleving van ISO/IEC 27002.
6.4.Levenscyclus van technische controles
(332)De technische controles van CA’s bestrijken de volledige levenscyclus van de CA. Dit omvat met name de eisen van punt 6.1.4.3 (cryptovermogen).
6.5.Controles van de netwerkbeveiliging
(333)De netwerken van de CA’s (root-CA, EA en AA) worden gewapend tegen aanvallen in overeenstemming met de vereisten en implementatierichtsnoeren van ISO/IEC 27001 en ISO/IEC 27002.
(334)De beschikbaarheid van de CA-netwerken wordt afgestemd op het geraamde verkeer.
7.Certificaatprofielen, CRL en CTL
7.1.Certificaatprofiel
(335)De in [5] gedefinieerde certificaatprofielen worden gebruikt voor de TLM, rootcertificaten, EA-certificaten, AA-certificaten, AT’s en EC’s. EA’s van nationale overheden mogen voor EC’s andere certificaatprofielen gebruiken.
(336)In de root-CA-, EA- en AA-certificaten wordt vermeld voor welke bevoegdheden de CA’s (root-CA’s, EA en AA) certificaten mogen afgeven.
(337)Op basis van [5]:
·ondertekent elke root-CA met zijn eigen private sleutel voor de opstelling van CRL’s;
·gebruikt de TLM zijn eigen private sleutel voor de opstelling van de ECTL.
7.2.Geldigheid certificaat
(338)Alle C-ITS-certificaatprofielen bevatten een afgifte- en vervaldatum, die de geldigheidstermijn van het certificaat weergeven. Op PKI-niveau worden certificaten tijdig vóór het verstrijken gegenereerd.
(339)De geldigheidstermijn van de CA- en EC-certificaten omvat een tijdsoverlapping. TLM- en root-CA-certificaten worden afgegeven en in de ECTL opgenomen en dit ten vroegste drie maanden en uiterlijk één maand vóór het begin van de geldigheid op basis van de in het certificaat vermelde startdatum. Deze preloadfase is nodig om de certificaten overeenkomstig punt 2.2 op een veilige manier te verspreiden naar de vertrouwende partijen. Dit zorgt ervoor dat alle vertrouwende partijen, vanaf het begin van de overlaptijd, in staat zijn de met een nieuw certificaat verzonden berichten te controleren.
(340)Aan het begin van de overlapping in de tijd, worden de opeenvolgende CA-, EC en AT-certificaten afgegeven (indien van toepassing), verspreid onder en geïnstalleerd door de vertrouwende partijen. Tijdens de overlaptermijn wordt het huidige certificaat uitsluitend gebruikt voor verificatie.
(341)Aangezien de in tabel 8 vermelde geldigheidstermijnen niet langer mogen zijn dan de geldigheidstermijn van het superieure certificaat, gelden de volgende beperkingen:
·maximumvalidity(Root CA) = privatekeyusage(Root CA) + maximumvalidity(EA,AA);
·maximumvalidity(EA) = privatekeyusage(EA) + maximumvalidity(EC);
·maximumvalidity(AA) = privatekeyusage(AA) + preloadingperiod(AT).
(342)De geldigheid van (root- en TLM)-verbindingscertificaten begint bij het gebruik van de overeenkomstige private sleutel en eindigt als de maximale geldigheidstermijn van de root-CA of -TLM bereikt is.
(343)Tabel 8 geeft een overzicht van de maximale geldigheidstermijn van C-ITS-CA-certificaten (voor de geldigheidstermijn van AT, zie punt 7.2.1).
|
Entiteit
|
Max. gebruiksduur private sleutels
|
Maximale geldigheidstermijn
|
|
Root-CA
|
3 jaar
|
8 jaar
|
|
EA
|
2 jaar
|
5 jaar
|
|
AA
|
4 jaar
|
5 jaar
|
|
EC
|
3 jaar
|
3 jaar
|
|
TLM
|
3 jaar
|
4 jaar
|
Tabel 8: Geldigheidsperiode van de certificaten in het C-ITS-samenwerkingsmodel
7.2.1.Pseudoniem certificaten
(344)In deze context worden pseudoniemen geïmplementeerd door AT’s. Bijgevolg heeft dit punt betrekking op AT’s in plaats van op pseudoniemen.
(345)De eisen in dit punt gelden alleen voor AT’s van mobiele C-ITS-stations die CAM en DENM-berichten verzenden, waarbij er sprake is van een risico inzake de locatieprivacy. Er gelden geen specifieke AT-certificaten voor AT van vaste C-ITS-stations en mobiele C-ITS-stations die voor bijzondere functies worden gebruikt, waarbij de locatieprivacy geen rol speelt (bv. herkenbare noodhulp en handhavingsvoertuigen).
(346)De volgende definities zijn van toepassing:
·„geldigheidstermijn van AT’s”: de periode waarvoor een AT geldig is, d.w.z. de periode tussen de begin- en de vervaldatum van de AT.
·„preloadtermijn van AT’s”: preloading is de mogelijkheid voor C-ITS-stations om de AT’s te ontvangen voor de start van de geldigheidstermijn. De preloadtermijn is de maximale termijn tussen de aanvraag van AT’s en het laatste datum waarop de geldigheid van een aangevraagde AT verstrijkt;
·„gebruik voor AT’s”: de periode waarin een AT daadwerkelijk wordt gebruikt om CAM/DENM-berichten te ondertekenen;
·„maximale aantal parallelle AT’s”: het aantal AT’s waaruit een C-ITS-station op elk moment kan kiezen bij het ondertekenen van een CAM/DENM-bericht, d.w.z. het aantal tegelijkertijd geldige verschillende AT’s die aan één C-ITS-station zijn afgegeven.
(347)De volgende voorschriften zijn van toepassing:
·de preloadtermijn voor AT’s bedraagt maximaal drie maanden;
·de geldigheidstermijn voor AT’s bedraagt niet meer dan één week;
·het maximale aantal parallelle AT’s bedraagt niet meer dan 100 per C-ITS-station;
·de gebruikstermijn van een AT is afhankelijk van de AT-wijzigingsstrategie en de termijn dat een voertuig in bedrijf is, maar wordt beperkt door het maximale aantal parallelle AT’s en de geldigheidstermijn. Meer in het bijzonder is de gemiddelde gebruiksperiode voor een C-ITS-station ten minste gelijk aan de operationele tijd van een voertuig tijdens één geldigheidstermijn, gedeeld door het maximumaantal parallelle AT’s.
7.2.2.Autorisatiebewijzen voor vaste C-ITS-stations
(348)De definities in punt 7.2.1 en de volgende voorschriften zijn van toepassing:
·de preloadtermijn voor AT’s bedraagt maximaal drie maanden;
·het maximale aantal parallelle AT’s bedraagt niet meer dan twee per C-ITS-station;
7.3.Intrekking van certificaten
7.3.1.Intrekking van CA-, EA- en AA-certificaten
Root-CA, EA- en AA-certificaten kunnen worden ingetrokken. Ingetrokken certificaten van root-CA’s, EA’s en AA’s worden onverwijld en zonder onnodige vertraging gepubliceerd in een CRL. De CRL wordt ondertekend door de overeenkomstige root-CA en het in punt 7.4 beschreven profiel. Voor de intrekking van root-CA-certificaten, genereert de overeenkomstige root-CA een CRL waarin ze zelf voorkomt. Als de beveiliging gecompromitteerd is, is bovendien punt 5.7.3 van toepassing. Bovendien verwijdert de TLM ingetrokken root-CA’s uit de vertrouwenslijst en genereert hij een nieuwe vertrouwenslijst. Vervallen certificaten worden verwijderd uit de overeenkomstige CRL en vertrouwenslijst.
(349)Certificaten worden ingetrokken als:
·de root-CA’s redenen hebben om te geloven of een sterk vermoeden hebben dat de overeenkomstige private sleutels gecompromitteerd zijn;
·de root-CA’s in kennis zijn gesteld van de beëindiging van het contract met de abonnee;
·gegevens (zoals naam en link tussen de CA en het subject) in het certificaat fout of gewijzigd zijn;
·er een veiligheidsincident plaatsvindt dat gevolgen heeft voor de certificaateigenaar;
·het resultaat van een audit negatief is (zie deel 8).
(350)Abonnees stellen de CA onmiddellijk in kennis van een bekende of vermoedelijke compromittering van een private sleutel. Er moet op worden toegezien dat certificaten alleen worden ingetrokken op basis van geauthenticeerde verzoeken.
7.3.2.Intrekking van inschrijvingsbewijzen
(351)De intrekking van de EC’s kan worden ingeleid door de abonnee van een C-ITS-station (stroom 34) en wordt geïmplementeerd door een interne zwarte lijst in een gedateerde intrekkingsdatabank, die door elke EA wordt gegenereerd en onderhouden. De zwarte lijst wordt nooit gepubliceerd, blijft vertrouwelijk en wordt slechts gebruikt door de overeenkomstige EA om de geldigheid van de overeenkomstige EC’s te verifiëren in de context van aanvragen van AT’s en nieuwe EC’s.
7.3.3.Intrekking van autorisatiebewijzen
(352)Aangezien AT’s niet door de betrokken CA’s worden ingetrokken, hebben zij een korte levensduur en kunnen ze slechts kort voordat ze geldig worden, worden afgegeven. De toegestane levenscyclusparameters voor certificaten zijn opgenomen in punt 7.2.
7.4.Lijst van ingetrokken certificaten
(353)De vorm en de inhoud van de door de root-CA gegenereerde CRL zijn vastgesteld in [1].
7.5.Gezamenlijke Europese certificaatlijst
(354)De vorm en de inhoud van de door de TLM gegenereerde ECTL zijn vastgesteld in [1].
8.Conformiteitsaudit en andere beoordelingen
8.1.Aan audit onderworpen thema's en grondslag van de audit
(355)Het doel van een conformiteitsaudit is na te gaan of de TLM, root-CA’s, EA’s en AA’s overeenkomstig dit CP functioneren. De TLM, root-CA’s, EA’s en AA’s selecteren een onafhankelijke geaccrediteerde PKI auditeur om een audit van hun CPS uit te voeren. Die audit wordt gecombineerd met een ISO/IEC 27001- en ISO/IEC 27002- beoordeling.
(356)Een conformiteitsaudit van de root-CA wordt aangevraagd door de root-CA zelf (stroom 13); voor een sub-CA gebeurt dat door haar ondergeschikte EA/AA.
(357)Een conformiteitsaudit voor de TLM wordt aangevraagd door de CPA (stroom 38).
(358)Indien daarom wordt verzocht, voert een geaccrediteerde PKI-auditeur een conformiteitsaudit uit op één van de volgende niveaus:
(1)conformiteit van de CPS van TLM’s, root-CA’s, EA’s of AA’s CPS met dit CP;
(2)conformiteit van de geplande praktijk van TLM’s, root-CA’s, EA’s of AA’s met zijn of haar CPS voor de aanvang van de activiteiten;
(3)conformiteit van de praktijk en operationele activiteiten van TLM’s, root-CA’s, EA’s of AA’s met zijn of haar CPS tijdens de activiteiten.
(359)De audit bestrijkt alle vereisten van dit CP waaraan de te controleren TLM, root-CA’s, EA’s en AA’s en EA’s moeten voldoen. De audit heeft ook betrekking op de werking van de CA binnen de C-ITS-PKI, met inbegrip van alle in de CPS genoemde processen, de gebouwen en de verantwoordelijke personen.
(360)De geaccrediteerde PKI-auditeur verstrekt een gedetailleerd verslag van de audit aan de root-CA (stroom 36), EA, AA of CPA (stromen 16 en 40), voor zover van toepassing.
8.2.Auditfrequentie
(361)Een root-CA, TLM, EA of AA laat zichzelf aan een conformiteitsaudit door een onafhankelijke en geaccrediteerde PKI-auditeur ontwerpen in de volgende gevallen:
·bij haar eerste oprichting (conformiteitsniveaus 1 en 2);
·bij elke wijziging van het CP. De CPA definieert de inhoud van CP-wijzigingen en het tijdschema voor de uitrol en bepaalt de overeenkomstige auditbehoeften (inclusief het vereiste conformiteitsniveau);
·bij elke wijziging van haar CPS (conformiteitsniveaus 1, 2 en 3). Aangezien de beherende entiteiten van root-CA’s, de TLM en EA’s/AA’s beslissen welke implementatiewijzigingen na de update van hun CPS gebeuren, vragen zij een conformiteitsaudit aan vooraleer die wijzigingen worden geïmplementeerd. Indien de wijzigingen van de CPS slechts minimaal zijn (bv. van redactionele aard), kan de beherende entiteit bij de CPA een gemotiveerde aanvraag indienen om de niveaus 1, 2 of 3 van de conformiteitsaudits te mogen overslaan;
·regelmatig, namelijk ten minste om de drie jaar tijdens de activiteiten (niveau 3).
8.3.Identiteit / kwalificaties van auditeurs
(362)De CA waarvan een audit moet worden uitgevoerd, selecteert een onafhankelijke en geaccrediteerde onderneming/organisatie (“auditinstantie”) of een geaccrediteerde PKI-auditeur waardoor zij overeenkomstig dit CP een audit van zichzelf laat uitvoeren. De auditinstantie wordt geaccrediteerd en gecertificeerd door een lid van de Europese accreditatie-instantie.
8.4.Relatie tussen de auditeur en de gecontroleerde entiteit
(363)De geaccrediteerde PKI-auditeur is onafhankelijk van de gecontroleerde entiteit.
8.5.Naar aanleiding van een tekortkoming getroffen maatregelen
(364)Indien in een auditrapport wordt geconcludeerd dat een TLM niet conform is, geeft de CPA de TLM de opdracht onmiddellijk preventieve/corrigerende maatregelen te nemen.
(365)Als een root-CA met een niet-conform auditrapport een nieuwe aanvraag indient, wijst de CPA die aanvraag af en stuurt zij een overeenkomstige afwijzing naar de root-CA (stroom 4). In dergelijke gevallen wordt de root-CA geschorst. Zij dient corrigerende maatregelen te nemen, een nieuwe audit aan te vragen en een nieuwe CPA-erkenning te vragen. Een root-CA mag tijdens de schorsing geen certificaten afgeven.
(366)In het geval van een regelmatige audit van een root-CA of een wijziging van de CPS van een rootCA, en afhankelijk van de aard van de in het auditrapport beschreven tekortkoming, kan de CPA besluiten het root-CA in te trekken en dit besluit mee te delen aan de TLM (stroom 2), hetgeen leidt tot de schrapping van het root-CA-certificaat uit de ECTL en toevoeging van het root-CA aan de CRL. De CPA stuurt een overeenkomstige afwijzing naar de root-CA (stroom 4). De root-CA dient corrigerende maatregelen te treffen, een nieuwe audit (niveaus 1 t.e.m. 3) aan te vragen en een nieuwe CPA-erkenning aan te vragen. Als alternatief kan de CPA besluiten het root-CA niet in te trekken en een coulancetermijn vaststellen waarin de root-CA corrigerende maatregelen moet nemen, een nieuwe audit moet aanvragen en het auditrapport moet indienen bij de CPA. In dit geval moet de werking van de root-CA worden geschorst en mag zij geen certificaten en CRL’s meer genereren.
(367)In geval van een EA/AA-audit, beslist de root-CA het verslag al dan niet te aanvaarden. Afhankelijk van het resultaat van de audit, beslist de root-CA het EA/AA-certificaat al dan niet in te trekken overeenkomstig de voorschriften van de CPS van de root-CA. De root-CA waarborgt te allen tijde de naleving van dit CP door de EA/AA.
8.6.Bekendmaking van de resultaten
(368)De root-CA en de TLM sturen het auditrapport naar de CPA (stroom 16). De root-CA en TLM bewaren alle auditrapporten die zij hebben besteld. De CPA stuurt een overeenkomstige goedkeuring of afwijzing (stroom 4) naar de root-CA en TLM.
(369)De root-CA stuurt een conformiteitscertificaat naar de overeenkomstige EA/AA.
9.Andere bepalingen
9.1.Vergoedingen
(370)Eén beginsel van het C-ITS-samenwerkingsmodel van de EU is dat de root-CA’s samen de volledige recurrente kosten financieren van de werking van de CPA en de centrale elementen (TLM en CPOC) met betrekking tot de in dit certificaatbeleid geschetste activiteiten.
(371)De root-CA’s (waaronder de EU-root-CA) heeft het recht sub-CA’s een vergoeding te vragen.
(372)Gedurende de hele werkingsperiode heeft elke deelnemer van het C-ITS-samenwerkingsmodel op nietdiscriminerende basis toegang tot ten minste één root-CA, EA en AA.
(373)Elke root-CA mag de vergoedingen die het betaalt voor de CPA en de centrale elementen (TLM en CPOC) doorberekenen aan de geregistreerde deelnemers van het C-ITS-samenwerkingsmodel, waaronder de ingeschreven en geautoriseerde C-ITS-stations.
9.2.Financiële aansprakelijkheid
(374)De oorspronkelijke invoering van een root-CA bestrijkt een werkingsperiode van ten minste drie jaar om lid te worden van het C-ITS-samenwerkingsmodel van de EU. De CPS van een root-CA-exploitant bevat ook gedetailleerde bepalingen inzake de intrekking of beëindiging van de root-CA.
(375)Elke root-CA moet de financiële levensvatbaarheid van de juridische entiteit die haar opzet voor een periode van ten minste drie jaar aantonen. Het financiële plan maakt deel uit van de eerste inschrijvingsdocumenten en moet om de drie jaar worden geactualiseerd en bij de CPA worden ingediend.
(376)Elke root-CA bezorgt de operations manager en de CPA jaarlijks een overzicht van de structuur van de vergoedingen voor EA’s/AA’s en de ingeschreven en geautoriseerde C-ITS-stations om haar financiële duurzaamheid te staven.
(377)Alle financieel en juridisch verantwoordelijke entiteiten van de root-CA, EA, AA en de centrale elementen (CPOC en TLM) van het C-ITS-samenwerkingsmodel moeten voorzien in een toereikende verzekeringsdekking van hun operationele taken ter compensatie van operationele fouten en financieel herstel van hun activiteiten bij faling van één van de technische elementen.
9.3.Vertrouwelijkheid van bedrijfsinformatie
(378)De volgende informatie blijft vertrouwelijk en privé:
·informatie over al dan niet goedgekeurde aanvragen van root-CA’s, EA’s en AA’s;
·auditrapporten van root-CA’s, EA’s, AA’s en TLM’s;
·noodherstelplannen van Cas’, East’, Aas’, Coks’ en TLM’s;
·private sleutels van de elementen van het C-ITS-samenwerkingsmodel (C-ITS-stations, TLM, EA, AA, root-CA’s);
·alle andere informatie die als vertrouwelijk is aangemerkt door de CPA, root-CA’s, EA, AA, TLM en CPOC.
9.4.Privacyplan
(379)De CPS van de root-CA’s en de EA/AA’s bevatten een plan en de vereisten inzake de behandeling van persoonsgegevens en privacy op basis van de GDPR en andere toepasselijke (bv. nationale) regelgeving.
10.Referenties
In deze bijlage worden de onderstaande referentienormen gebruikt:
|
[1]
|
ETSI TS 102 941 V1.2.1, Intelligent transport systems (ITS) – security, trust and privacy management.
|
|
[2]
|
ETSI TS 102 940 V1.3.1, Intelligent transport systems (ITS) – security, ITS communications security architecture and security management.
|
|
[3]
|
Certificate policy and certification practices framework (RFC 3647, 1999).
|
|
[4]
|
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) – security, security header and certificate formats.
|
|
[6]
|
Calder, A. (2006). Information security based on ISO 27001/ISO 1779: a management guide. Van Haren Publishing.
|
|
[7]
|
ISO, I., & Sta, I. E. C. (2011). ISO 27005 (2011) – information technology, security technicus, information security risk management. ISO.
|
