RDW Dienst Wegverkeer CP$

RDW Dienst Wegverkeer CP$ RDW Certification Practice Statement

RDW Europaweg 205 2711 ER ZOETERMEER Postbus 777 2700 AT ZOETERMEER Maart 2014

Pagina opzettelijk leeg gelaten. This page intentionally left blank.

2

Nederlands

3

English

35

Titel: Versie/datum: Atitorisatie: Datum ingang: Onderhoud: Classificatie: Aantal pagina’s:

RDW Dienst Wegverkeer Certification Practice Statement 8 / Maart 2014 Directie RDW 1 oktober 2006 RDW openbaar 36

© 2006, RDW, Veendam. Niets uit deze uitgave mag worden verveetvoudigd en/of openbaar gemaakt zonder voorafgaande schriftelijke toestemming van de RDW.

3

Inleiding 1.1 1.2 1.3 1.4 1.5 1.6

2.

Inhoudsopgave 6

.

Algemeen Documentnaam en Identificatie Bij RDW-PKI betrokken partijen Toepasbaarheid Contact gegevens Definities en acroniemen

.

Publicatie en repository verplichtingen 2.1 2.2 2.3 2.4

Repository Publicatie van certificaat informatie Tijd of frequentie van publicatie Toegangscontrols van repositories

Identificatie en authenticatie

3. 3. 1 3.2 3.3 3.4

4.

Naamgeving Initïële validatie van de identiteit Identificatie en authenticatie voor vervanging van een certificaat Identificatie en authenticatie voor verzoek tot intrekking

Operationele vereisten voor de certificaat levenscyclus

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4. 11 4.12

Certificaat aanvraag Certificaat aanvraag verwerking Certificaat uitgifte Certificaat acceptatie Sleutelpaar en certificaat toepassing Certificaat heruitgifte Certificaat vervanging Certificaat aanpassing Certificaat intrekking en suspensie Certificaat status services Einde van de vermelding als certificaathouder Sleutel Escrow en herstel

Algemene, fysieke en operationele beheersmaatregelen

5 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8

Fysieke beheersmaatregelen Procedurele beheersmaatregelen Personele beheermaatregelen Audit logging procedures Archivering van documenten Verstrekken van RDW PKI Sleutels Compromitteren van de privé-sleutel en calamiteitenbeheersing CAbeëindiging

Technische beveiliging

6 6.1 6.2 6.3 6.4 6.5 6.6 6.7

Genereren en installeren sleutelpaar Bescherming van privésleutels Overige aspecten van sleutelbeheer Activeringsdata Computer beveiligingsmaatregelen Technische beheersmaatregelen in de levenscyclus Netwerk beveiliging beheersmaatregelen

6 6 6 7 $ $

8 $ 8 8 $

9 9 9 11 11

12 12 12 12 13 13 13 14 14 15 17 17 17

17 17 18 19 19 20 20 20 21

21 21 22 23 23 23 23 24

4

6.7 6.8

Netwerk beveiliging beheersmaatregelen Tijdstempelen

Certificaat, CRL en OCSP profiel

7. 7.1 7.2 7.3

Certificaatprofiel CRL-profiel OCSP-profiel

Compliance audit en overige analyses

$ 8.1 8.2 8.3 8.4 8.5 8.6

Frequentie en redenen van audit Identiteit/Kwaliteit van auditor Relatie tussen auditor en object van audit Onderwerpen van audit Acties naar aanleiding van onvolkomenheid Communicatie van resultaten

Overige onderneming S- en wettelijke zaken

9 9.1 9.2 9.3 9.4

9.5 9.6 9.7 9.8 9.9 9.10 9.11 9.12 9.13 9.14 9.15

10. 11. 11.1 11.2

Kosten Financiële verantwoordelijkheid Vertrouwelijkheid Privacy van persoonlijke informatie Intellectuele eigendomsrechten Vertegenwoordiging en waarborg Disclaimers van waarborgen Uitsluiting van aansprakelijkheid Compensatie Geldigheidsduur en beëindiging Individuele toelichting en communicatie met betrokkenen Amendementen Beslechting van geschillen Toepasselijk recht Positie binnen bestaande wetgeving

Formele goedkeuring/Formal approval Bijlagen/Appendices Gebruikte afkortingen / Abbreviations used Verklarende woordenljst / Glossary

24 24

24 24 27 28

2$ 2$ 2$ 28 2$ 2$ 2$

28 2$ 2$ 29 29 30 30 30 30 31 31 31 31 32 32 32

63 64 64 64

5

1.

Inleiding

1.1

Algemeen Dit Certification Practice Statement is opgesteld als raamwerk voor de toepassing van certificaten die worden uitgegeven door de “RDW Dienst Wegverkeer PKI”. Dit CPS beschrijft de procedures, technieken en juridische randvoorwaarden die de RDW hanteert bij het beheer van de “RDW Dienst Wegverkeer PKI”. De structuur van dit CPS is in overeenstemming met de internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework (RFC3647). Een verklarende woordenlijst is opgenomen als bijlage.

1.2

Documentnaam en Identificatie De naamgeving van dit CPS is de “RDW Dienst Wegverkeer Certtfication Practice Staternent”. Er is geen object identifier aan dit CPS toegekend of geregistreerd.

1.3

Bij RDW-PKI betrokken partijen

1.3.1

Certtfication Authority De RDW PKI bestaat uit verschillende certificaatketens. Elke CA binnen de RDW Dienst Wegverkeer PKI handelt conform specifieke procedures die in verband staan met hun taak. Binnen de RDW PKI zijn de volgende CA’ s operationeel: RDW Dienst Wegverkeer Root CA RDW Issuing CA 1 > RDW Acc Issuing CA 1 De RDW Dienst Wegverkeer Root is de CA die het eerste certificaat uitgeeft binnen een certificaatketen. De RDW Dienst Wegverkeer Root CA ondertekent de certificaten van de onderliggende CA’ s binnen de RDW Dienst Wegverkeer PKI. De RDW Issuing CA 1 is de CA die certificaten uitgeeft aan eindentiteiten binnen de RDW Dienst Wegverkeer PKI. Deze CA wordt in de rest van dit document de Issuing CA genoemd. De RDW Acc Issuing CA 1 is ingericht overeenkomstig de RDW Issuing CA 1 en wordt gebruikt om na een wijziging de correcte werking van de PKI te testen.

1.3.2

Registration Authority

Binnen de RDW zijn de volgende Registration Authorities actief: Unit Rijbewijzen voor certificaten die worden uitgegeven aan gemeenteambtenaren ten behoeve van beveiligde gegevensuitwisseling en toegang tot het rijbewijzen register. Unit Erkenning en Toezicht voor certificaten die worden uitgegeven aan (erkende) bedrijven en verzekeringsmaatschappijen ten behoeve van toegang tot RDW applicaties.

6

Unit Informatieverstrekking voor certificaten die worden uitgegeven aan diverse organisaties die een relatie met de RDW hebben ten behoeve van het opzetten van een beveiligde verbinding tussen de Organisatie en de RDW. 1.3.3

Eindentiteiteit

Als eindentiteiten binnen de RDW Dienst Wegverkeer PKI worden aangemerkt: aanvragers en certificaathouders. De binnen de RDW PKI operationele eindentiteiten zijn: 1

2

1.3.4

Aanvragers i. Alle gemeenteambtenaren die online toegang wensen tot RDW applicaties. ii. Alle organisaties die erkend zijn door de RDW of op andere wijze als klant van de RDW worden benoemd die toegang wensen tot RDW applicaties. iii. Alle organisaties die als klant van de RDW worden benoemd die een beveiligde verbinding met de RDW op willen zetten. iv. Alle RDW medewerkers die toegang wensen tot RDW applicaties. Certificaathouders i. De aanvragers aan wie door de RDW een certificaat is uitgegeven.

Retyiitg parties

Binnen de RDW wordt als relying party aangemerkt: > De RDW zelf bij de beveiliging van de datacommunicatie ten behoeve van het wijzigen en raadplegen van registers, die door de RDW bij of krachtens wettelijke taak worden beheerd. 1.3.5

Overige betrokken partijen

Er zijn geen overige partijen betrokken. 1.4

Toepasbaarheid

1.4.1

Bedoelde toepassing

Bij de uitgifte van een certificaat wordt aangegeven voor welke toepassing het certificaat dient. Er worden de volgende certificaattypen onderscheiden: Productiecertificaten uitgegeven door de RDW Issuing CA 1 1 De Issuing CA gebruikt zijn privésleutel uitsluitend voor het uitgeven van certificaten en het digitaal ondertekenen van CRL’s zoals in dit CPS is omschreven. De uitgegeven productiecertificaten ten behoeve van eindentiteiten binnen de RDW PKI zijn uitsluitend bedoeld voor identificatie, authenticatie en digitale ondertekening van en door de eindentiteit ten behoeve van: 1.1 toegang tot RDW-applicaties, het raadplegen en wijzigen van registers die door de RDW bij of krachtens 1.2 wettelijke taak worden beheerd en waarvoor de RDW verantwoordelijk is, het beveiligen van gegevensuitwisseling tussen eindentiteiten en de RDW. 1.3 Acceptatiecertificaten worden uitgegeven door de RDW Issuing CA 1 2 Acceptatiecertificaten worden uitsluitend gebruikt om te testen na een wijziging. 1.4.2

Niet toegestane toepassing

Alle toepassingen die afwijken van de genoemde toepassingen in 1.4.1 zijn niet toegestaan.

7

1.5 1.5.1

Contact gegevens Verantwoordelijke organisatie

De RDW is verantwoordelijk voor het beheer van dit CPS. 1.5.2

Contactpersoon

Het volgende organisatieonderdeel is bij de RDW verantwoordelijk voor het beheer (onderhoud en interpretatie) van dit CPS. RDW CA Unit Voertuigregi stratie en Documenten Postbus 30000 9640 RA Veendam 1.5.3

Persoon die toepasbaarheid CPS bepaalt voor Certijicate Policies (CPs)

De RDW maakt geen gebruik van Certificate Policies. Uitwerking van de voorwaarden die verbonden zijn aan het gebruik van certificaten zijn neergelegd in deze CPS. 1.5.4

CPS instel?zrniltgprocedures

De CA en RA’s hebben ingestemd met dit CPS. 1.6

Definities en acroniemen Een lijst met gebruikte definities is opgenomen in paragraaf 11.2.

2.

Publicatie en repository verplichtingen

2.1

Repository De repository met uitgegeven certificaten wordt niet gepubliceerd of beschikbaar gesteld aan partijen buiten de RDW. De Issuing CA publiceert de lijst met ingetrokken certificaten (CRL) en stelt deze ter beschikking ten behoeve van de vaststelling van de geldigheid van een certificaat.

2.2

Publicatie van certificaat informatie Documenten inzake het gedetailleerde beheer van de RDW PKI worden door de RDW als vertrouwelijk bestempeld en zullen niet worden geopenbaard aan het publiek. De lijst met uitgegeven certificaten wordt niet gepubliceerd of beschikbaar gesteld aan partijen buiten de RDW.

2.3

Tijd of frequentie van publicatie 1. De Issuing CA publiceert een CRL iedere keer als een eindentiteit certificaat wordt ingetrokken en minimaal één keer per uur. Volgens de ETSI normering moet dit minimaal lx per dag. De CRL heeft een geldigheidsduur van 7 dagen. 2. De publicatie van de CP$ geschiedt volgens de bepalingen in paragraaf 9.12. 3. Indien de CPS gewijzigd wordt zullen alle entiteiten binnen de RDW PKI, met inachtneming van paragraaf 9.12 hiervan op de hoogte worden gesteld.

2.4

Toegangscontrols van repositories Deze zijn niet van toepassing buiten de RDW, binnen de RDW zijn hiervoor interne procedures opgesteld.

8

3.

Identificatie en authenticatie

3.1

Naamgeving

3.1.1

Type namen

Elke entiteit heeft een Distinguished Name (DN) die is opgenomen in het “certificate subject name’ veld, zoals gedefinieerd in de X.500 standaard voor DN’s. Zie voor de certificaatprofielen paragraaf 7.1. 3.1.2

Zinvolle naal?tgeving

De namen die gebruikt worden binnen de RDW PKI komen overeen met de entiteit. De namen zijn door de relying party uniek identificeerbaar met de entiteit. 3.1.3

Anonimiteit ofpseudoniiniteit van subscribers

Niet van toepassing. 3.1.4

Regels voor het interpretereit van de naamgeving

Zie paragraaf. 3.1.1. 3.1.5

Unieke naamgeving

Alle gecertificeerde namen zijn uniek. 3.1.6

Herkenning, attthenticatie en de rot van inerkeitrechten

Voor regels ten aanzien van merkenrechten en geschillenbeslechting ten aanzien van naamgeving geldt de procedure zoals beschreven in paragraaf 9.13 en 9.14.

3.2

Initiële validatie van de identiteit

3.2.1

Aantonen bezit van een privésteutel

De privésleutel als onderdeel van het certificaat zal na het aanvragen: 1. Persoonlijk aan de eindentiteit worden overhandigd in het geval de eindentiteit een ABR of een RDW medewerker is. 2. Worden verzonden naar de ABR in geval de eindentiteit een RIJA is (zie paragraaf 4.3). De ABR overhandigt de privésleutel persoonlijk aan de RIJA. 3. Voor bedrijven die een certificaat op cd-rom aanvragen ten behoeve van toegang tot RDW diensten wordt de cd-rom verzonden naar de directie van het betreffende bedrijf. 4. Voor klanten die een smartcard aanvragen voor seifservice of een cd-rom ten behoeve van het opzetten van een beveiligde verbinding, wordt deze toegezonden aan de opgegeven contactpersoon van de betreffende Organisatie. Voor alle eindentiteiten wordt vermoed dat de entiteit binnen twee weken na verzending van het certificaat in het bezit is van de privésleutel. 3.2.2

Authenticatie van de organisatie

Voor wat betreft de procedure voor het aanvragen van een certificaat bij de betrokken RA zal worden aangesloten bij de reeds bestaande procedures binnen de RDW.

1

Authenticatie van gemeente ambtenaren ten behoeve van de afgifte van rijbewijzen De initiële authenticatie van de aanvrager door de RA vindt plaats als onderdeel van de procedure die wordt gehanteerd in het geval een gemeente in aanmerking wenst te komen voor beveiligde gegevensuitwisseling en toegang tot het rijbewijzen register. De 9

vaststelling van de identiteit en authenticiteit van de aanvrager geschiedt op basis van een kopie van het legitimatiebewijs, een pasfoto en ondertekening door een bevoegd persoon en de certificaathouder zelf. Een bevoegd persoon is degene die toestemming mag geven voor het aanvragen van een certificaat. In het geval van een certificaat voor een ABR is de bevoegd persoon de burgemeester van de betreffende gemeente. In het geval van een certificaat voor een RIJA is de bevoegd persoon een ABR van de betreffende gemeente.

3.2.3

2

Authenticatfe van bedrijven ten behoeve van toegang tot RDW diensten De initiële authenticatie van de aanvrager door de RA vindt plaats als onderdeel van de procedure die wordt gehanteerd in het geval een bedrijf in aanmerking wenst te komen voor een RDW erkenning. De vaststelling van de identiteit en authenticiteit van de aanvrager geschiedt op basis van inschrijving in de Kamer van Koophandel en een bezoek aan het bedrijf door een bedrijvencontroleur van de RDW.

3

Authenticatie van organisaties ten behoeve van een beveiligde verbinding met de RDW De initiële authenticatie van de aanvrager door de RA vindt plaats als onderdeel van de procedure die wordt gehanteerd in het geval een organisatie in aanmerking wenst te komen voor een beveiligde verbinding met de RDW. De vaststelling van de identiteit en authenticiteit van de aanvrager geschiedt op basis van de kenmerken van het verzoek en beoordeling van het type Organisatie. Deze organisaties kunnen kiezen voor een certificaat op smartcard waarmee via selfservice een servicecertificaat gedownload kan worden of voor een servicecertificaat op cd-rom.

4

Authenticatie van aanvragers intern de RDW De authenticatie van de aanvragers van certificaten die uitgegeven worden aan medewerkers van de RDW, vindt plaats op basis van opdrachtverstrekking door een bevoegd persoon (manager of gemandateerde).

Authenticatie van natuurlijke personen

Er worden certificaten uitgegeven aan natuurlijke personen, mits deze als medewerker verbonden zijn aan een Nederlandse gemeente of de RDW. 3.2.4

Niet-gevertfleerde certificaathouder informatie

De certificaathouder verklaart de gegevens zoals die door hem verstrekt zijn aan de RDW naar waarheid te hebben opgegeven. 3.2.5

Vatidatie van de autoriteit

De RA controleert of de persoon of Organisatie die zelf een certificaat aanvraagt of die toestemming geeft voor het aanvragen van een certificaat, hiertoe bevoegd is. Dit betekent dat in het geval van een ABR certificaat de bevoegd persoon daadwerkelijk de burgemeester van de betreffende gemeente is. In het geval van een RIJA certificaat wordt bepaald of de bevoegd persoon daadwerkelijk bekend is als ABR van de betreffende gemeente. Wanneer het een erkend bedrijf, verzekeringsmaatschappij of gevolmachtigde betreft, moet deze als erkenninghouder of zakelijke klant geregistreerd zijn bij de RDW. Bij een overige Organisatie moet deze voldoen aan de door de RDW gestelde voorwaarden zoals vastgelegd in procedures van het betreffende organisatieonderdeel. Voor RDW medewerkers is de bevoegd persoon de teammanager of hoofd keuringsstation of een door die personen bevoegde gemandateerde.

10

3.2.6

Criteria voor inter-operatie

Niet van toepassing. 3.3

Identificatie en authenticatie voor vervanging van een certificaat

3.3.1

Identificatie eit authenlicatie voor routilternatige vervanging

Vervanging van een certificaat betekent het genereren van een nieuw sleutelpaar en certificaat voorafgaand aan het verstrijken van de geldigheidsduur van een certificaat. Bij certificaten voor gemeenteambtenaren en organisaties die seifservice uitvoeren geldt: Onverminderd de eigen verantwoordelijkheid van de certificaathouder voor het tijdig aanvragen van een nieuw certificaat, waarschuwt de RDW CA de certificaathouder tijdig voorafgaand aan het verstrijken van de geldigheidsduur van het bestaande certificaat, zodat de certificaathouder het certificaat kan vervangen conform de procedure voor initiële registratie (zie paragraaf 3.2). In geval van certificaten voor (erkende) bedrijven, verzekeringsmaatschappijen, gevolmachtigden en organisaties die een servicecertificaat op cd-rom ontvangen geldt: De RDW CA vervangt het certificaat tijdig voorafgaand aan het verstrijken van de geldigheidsduur van het bestaande certificaat, zonder de certificaathouder hiervan op de hoogte te stellen, anders dan door het verzenden van het nieuwe certificaat. De CA zal slechts certificaten vervangen indien op het moment van vervanging de betreffende eindentiteiten nog steeds voldoen aan de door de RDW aan hen gestelde eisen, zoals beschreven onder paragraaf 3.2.2 en paragraaf 3.2.3. Het vervangingsproces voorziet in een controle procedure daaromtrent. 3.3.2

Identificatie en authenticatie voor vervaitging na intrekking

Vervanging na de intrekking van een certificaat betekent het genereren van een nieuw sleutelpaar en certificaat nadat het certificaat is ingetrokken. De RDW kan een certificaat intrekken in het kader van het toezicht op de verwerking van gegevens in het register, het toezicht op de uitvoering van de wettelijke regeling(en), in het kader van de controle op de rechtmatigheid van de toegang tot de bij of krachtens de wet door de RDW beheerde registers of een certificaat intrekken om procedurele en/of technische redenen. Eventuele vervanging zal dan plaatsvinden conform de procedure voor initiële registratie (zie paragraaf 3.2).Intrekking op verzoek van de certificaathouder kan worden gevolgd door een vervanging. Deze vervanging zal plaatsvinden conform de procedure voor initiële registratie. 3.4

Identificatie en authenticatie voor verzoek tot intrekking 1. De RDW kan in het kader van het toezicht op de verwerking van gegevens in het register of op de uitvoering van de wettelijke regeling(en) een certificaat intrekken. 2. De RDW kan een certificaat intrekken in het geval een eindentiteit niet langer voldoet aan de wettelijke regelingen ten aanzien van de door de RDW aan hem gestelde eisen en voorwaarden of een certificaat intrekken om procedurele en/of technische redenen. 3. De RDW kan een certificaat intrekken in het kader van de interne procedures als opgesteld voor certificaten welke vallen onder de beheersrege}ing(en). 4. Een eindentiteit kan ook zelf een verzoek indienen tot intrekking van zijn certificaat, bijvoorbeeld indien zijn privésleutel is gecompromitteerd. 5. Aanvragen voor intrekldng moeten altijd schriftelijk, via een fax of via een e-mail bij de RA worden ingediend.

11

4.

Operationele vereisten voor de certificaat levenscyclus

4.1

Certificaat aanvraag Indien de aanvrager een verzoek indient voor het verkrijgen van een certificaat dan moet dit gedaan worden bij de verantwoordelijke RA.

4.1.1

Mogelijke aanvragers van een certificaat

Een aanvraag voor een certificaat kan worden ingediend door: een gemeenteambtenaar, waarbij altijd toestemming gegeven moet worden door een bevoegd persoon binnen de betreffende gemeente. een Organisatie die erkend is door de RDW of op andere wijze als klant van de RDW wordt benoemd die toegang wenst tot RDW applicaties. een Organisatie die als klant van de RDW wordt benoemd die een beveiligde verbinding met de RDW op wil zetten. een medewerker van de RDW. De uitgifte van certificaten aan medewerkers van de RDW is vastgelegd in interne procedures. -

-

-

-

4.1.2

Registratie proces en verantwoordelijkheden

Een binnenkomende aanvraag wordt door de RA beoordeeld en geregistreerd.

4.2 4.2.1

Certificaat aanvraag verwerking Uitt’oeren identificatie en authenticatie functies

De RA beoordeelt of de aanvraag volledig is ingevuld en indien van toepassing, is ingediend met toestemming van een bevoegd persoon. 4.2.2

Goedkeuring of afwijzing van de certificaat aanvraag

Bij goedkeuring van de aanvraag zal deze verder in behandeling worden genomen door de CA. Wanneer de aanvraag wordt afgewezen, zal de RA de aanvraag tezamen met een begeleidend schrijven retour sturen. 4.2.3

Tijd voor het verwerken van de certificaat aanvraag

Een aanvraag voor een certificaat zal binnen 6 werkdagen worden afgehandeld. Indien dit niet mogelijk blijkt te zijn, zal de aanvrager hiervan op de hoogte worden gebracht door de RA.

4.3 4.3.1

Certificaat uitgifte GA activiteiten bij certificaat uitgifte

Als onderdeel van de certificaat uitgifte voor eindentiteiten wordt een publiek / privaat sleutelpaar gegenereerd, waarna een certificaat wordt geproduceerd op basis van de publieke sleutel en de aanvraag gegevens van de entiteit. Het moment waarop de Issuing CA een certificaat aanmaakt, geldt als de datum en het tijdstip van afgifte van het certificaat en blijkt uit de logbestanden van het afgifteproces. Na het genereren van het certificaat geeft de Issuing CA het certificaat uit. De uitgifte vindt plaats doordat het certificaat en het gegenereerde publiek / privaat sleutelpaar vastgelegd worden op een cd-rom of een smartcard of in een pfx-bestand online beschikbaar wordt gesteld. Het sleutelpaar wordt door een Hardware Security Module (HSM) gegenereerd, de privésleutel wordt hieruit geëxporteerd en tijdelijk in een PKCS#12 opgeslagen. De cd-rom, smartcard en het pfx-bestand

12

worden beveiligd met een pincode die na het vastieggen van het certificaat en het sleutelpaar wordt gegenereerd. In geval van een ABR wordt vdér afgifte van de smartcard de identiteit vastgesteld, middels de zogenaamde ‘face-to-face controle’. In geval van een RIJA, wordt de smartcard per post aan de ABR toegestuurd. De ABR is er verantwoordelijk voor dat de aan hem verstrekte smartcard aan de juiste, op de smartcard vermelde, certificaathouder wordt afgegeven. Hiertoe zal de ABR zich, véér afgifte van de smartcard, van de identiteit van de certificaathouder moeten vergewissen. In geval van een Organisatie die erkend is door de RDW wordt de cd-rom met daarop het clientcertificaat of de cd-rom met het servicecertificaat per post aan de geregistreerde aanvrager toegestuurd. Wanneer de organisatie zelf het servicecertificaat wil kunnen downloaden, wordt de daarvoor benodigde smartcard per post aan de geregistreerde aanvrager verzonden.

4.4 4.4.1

Certificaat acceptatie Certificaat acceptatie

De aanvrager ontvangt het certificaat dat is vastgelegd op een smartcard of cd-rom. De aanvrager heeft bij het aanvragen van de smartcard reeds verklaard akkoord te zijn met de gebruikersvoorwaarden die van toepassing zijn op het gebruik van het certificaat. De gebruikersvoorwaarden zijn beschikbaar via de website van de RDW. De privésleutel op de smartcard is beschermd door een initiële pincode. Voordat de smartcard wordt ontvangen, ontvangt de aanvrager de initiële pincode. Bij een certificaat op smartcard moet voor het eerste gebruik de initiële pincode door de certificaathouder worden gewijzigd. De privésleutel op de cd-rom is beschermd door een installatiepincode. De installatiepincode wordt 1 werkdag na het versturen van de cd-rom naar de aanvrager verzonden. De privésleutel van het servicecertificaat dat gedownload wordt, is beschermd door een door de aanvrager zelf gekozen pincode. 4.4.2

Publicatie van het certificaat door de CA

Uitgegeven certificaten zullen niet door de CA worden gepubliceerd. 4.4.3

Kennisgeving van de certificaat uitgifte door de CA aan andere entiteiten

De CA zal andere entiteiten niet op de hoogte brengen van de certificaat uitgifte.

4.5

Sleutelpaar en certificaat toepassing

4.5.1

Certtficaathouderprivé sleutel en certificaat toepassing

De certificaathouder zorgt voor een adequate bescherming van zijn certificaat met privé sleutel en de bijbehorende pincode. De certificaathouder zal het certificaat en het hierbij behorende sleutelpaar uitsluitend gebruiken voor het doel zoals omschreven in paragraaf 1.4 (toepasbaarheid).

4.6

Certificaat heruitgifte

4.6.1

Redenen voor heruitgifte certificaat

Heruitgifte van certificaten zal niet plaats vinden. 4.6.2

Mogelijke aanvragers voor certificering van een niettwe publieke sleutel

Niet van toepassing.

13

4.6.3

Verwerken aait vragen voor heruitgifie certificaat


Kennisgeving van Izerttitgifte certificaat aan de eindentiteit


Acceptatie van een hentitgegeven certificaat


Publicatie van het herititgegeven certificaat door de CA


Kennisgeving vait uitgifte niettw certificaat door de CA aan andere entiteiten


4.7

Certificaat vervanging

4.7.1

Redeiteiz voor vervanging certificaat

Vervanging kan plaats vinden bij wijziging van certificaatgegevens, hij naderend einde van de geldigheid, wanneer het certificaat of de pincode niet zijn ontvangen of vermist zijn. 4.7.2

Mogelijke aanvragers voor vervanging

Een aanvraag voor vervanging van een certificaat kan worden ingediend door de certificaathouder zelf (in geval van certificaathouder 2 en 3 in paragraaf 3.2.2) of door de bevoegd vertegenwoordiger van een certificaathouder (in geval van certificaathouder 1 en 4 in paragraaf 3.2.2). 4.7.3

Verwerken aanvragen voor vervanging certificaat

Het verwerken van een aanvraag voor vervanging van een certificaat zal plaatsvinden overeenkomstig de verwerking van een eerste aanvraag voor een certificaat (zie paragraaf 3.2). Dit betekent dat de RA de aanvraag voor vervanging zal beoordelen en registreren en dat de Issuing CA het vervangende certificaat uitgeeft. 4.7.4

Kenutisgeving van uitgifte nieuw certificaat aan eindentiteit

De certificaathouder zal op de hoogte worden gebracht van de uitgifte van het nieuwe certificaat door het ontvangen van dit nieuwe certificaat. 4.7.5

Acceptatie van een vervangingscertificaat

Zie paragraaf 4.4.1. 4.7.6

Publicatie van het vervangingscertificaat door de CA

Uitgegeven certificaten zullen niet door de CA worden gepubliceerd. 4.7.7

Kennisgeving van uitgifte nieitw certificaat door de CA aan andere entiteiten

De CA zal andere entiteiten niet op de hoogte brengen van de certificaat uitgifte.

4.8

Certificaat aanpassing

4.8.1

Redenen voor aanpassing certificaat

Indien de inhoud van een certificaat en/of voor de inhoud van het certificaat relevante gegevens niet (meer) overeenkomen met de werkelijkheid (bijvoorbeeld na naamswijziging), moet de certificaathouder of de Organisatie die voor deze certificaathouder verantwoordelijk is, dit

14

aangeven bij de RA middels het indienen van een verzoek tot vervanging van het certificaat. Het is de verantwoordelijkheid van de certificaathouder om de RA hiervan op de hoogte te stellen. Bij een aanpassing van de gegevens zal het volledige certificaat vervangen worden, van aanpassing van het bestaande certificaat is dus geen sprake. 4.8.2

Mogelijke aanvragers voor aanpassing van het certificaat


Verwerkeit aanvragen voor aanpassing certificaat


Kennisgeving van uitgifte nieuw certificaat aan de eindentiteit


Acceptatie van een aangepast certificaat


Publicatie van het aangepaste certificaat door de CA


Kennisgeving van uitgifte nieuw certificaat door de (‘4 aait andere entiteiten


Certificaat intrekking en suspensie De CA is verantwoordelijk voor de intrekking van certificaten. Intrekking vindt plaats doordat de Issuing CA het ingetrokken certificaat toevoegt aan de CRL. Na de intrekking van het certificaat wordt de certificaathouder hiervan op de hoogte gesteld. Suspensie is niet van toepassing.

4.9.1

Redenen voor intrekking

Geldige redenen voor de intrekking van een certificaat zijn: 1. Compromittering of verlies van de privésleutel of van de pincode die in samenhang met de privésleutel toegang geven tot de RDW applicaties of een verbinding met de RDW. Na compromittering moet het gebruik van de privésleutel onmiddellijk en permanent worden gestaakt. 2. Op verzoek van de certificaathouder: bij vermissing of beschadiging van de drager van het certificaat of blokkade van de pincode. 3. Door de voor de certificaathouder verantwoordelijke Organisatie, indien de houder van het certificaat niet langer namens die Organisatie mag optreden bijv. na een functiewijziging of het beëindigen van het dienstverband. 4. Het door de eindentiteit niet langer voldoen aan de door de RDW aan hem gestelde eisen en voorwaarden of om procedurele en/of technische redenen. 5. De certificaathouder voldoet niet aan zijn verplichtingen zoals beschreven in dit CPS; intrekking vindt in deze situatie slechts plaats nadat de certificaathouder in de gelegenheid is gesteld zijn zienswijze daarover kenbaar te maken. De certificaathouder is in alle gevallen aansprakelijk voor de schade die is ontstaan door het te laat intrekken of vervangen van een certificaat, ongeacht of de noodzaak tot het intrekken of vervangen aan hem kan worden toegerekend.

15

4.9.2

Mogelijke aanvragers voor iittrekking van een certificaat

De 1. 2. 3. 4. 4.9.3

volgende entiteiten zijn bevoegd om een verzoek tot intrekking in te dienen: deCA, deRA, de certificaathouder, de voor een certificaathouder verantwoordelijke Organisatie of gemandateerde persoon.

Procedure voor eeit verzoek tot intrekking

De entiteit die een verzoek tot intrekking van een certificaat indient kan dit alleen doen door middel van het indienen van een schriftelijk verzoek, een verzoek per fax of per e-mail aan de betreffende RDW RA. In geval van certificaathouder 1 en 4 uit paragraaf 3.2.2. geldt dat bij een verzoek tot intrekking van het eigen certificaat, de RA het schriftelijke verzoek zal verifiëren door de certificaathouder terug te bellen op het bij de RA bekende telefoonnummer. Een certificaathouder die in het bezit is van een smartcard voor self-service is zelf verantwoordelijk voor het intrekken van een certificaat dat via download is verkregen. De RA geeft onverwijid kennis van een gehonoreerd verzoek tot intrekking van het certificaat aan de CA en verzoekt met bekwame spoed van de intrekking melding te maken in de CRL. Het vermelden van de intrekking in de CRL geeft de datum en het tijdstip van intrekking van het certificaat aan. 4.9.4

Geldigheidsperiode van een verzoek tot intrekking

De RDW behandelt een verzoek tot intrekking zo spoedig mogelijk na ontvangst van het verzoek. Bij mogelijke compromittering zal de RDW, na ontvangst van het verzoek, het verzoek tot intrekking terstond afhandelen (op werkdagen). 4.9.5

Tijd waarin de CA de aanvraag voor intrekking moet verwerken

De CA verwerkt de aanvraag voor intrekking zo spoedig mogelijk, maar uiterlijk binnen 1 werkdag na ontvangst van het verzoek. 4.9.6

Vereisten voor onli,te checken van intrekking voor relying party

Het certificaat op smartcard uitgegeven door de Issuing CA bevat een CRL Distribution Point (CDP). 4.9.7

CRL uitgifte frequentie

De CRL wordt na iedere intrekking bijgewerkt en ieder uur gedistribueerd. 4.9.8

Maximum potentieel voor CRL

De CRL is niet gebonden aan een maximum aantal. 4.9.9

Online intrekking


Vereisten voor online checken van intrekking

De server die de CRL beschikbaar stelt, is minimaal dubbel uitgevoerd op twee verschillende locaties. Deze server is 7 dagen per week en 24 uur per dag beschikbaar. De CRL is te raadplegen op: littp://www-diensten.rdw.nI/crt!rdwissuinca 1 .crl 4.9.11

Andere vormen van publiceren intrekkingstatus


16

4.9.12

Speciale vereisten bij Ii erttitgtfte na contprolltitteriltg


Redeneit voor schorsing

Schorsing van het certificaat is niet mogelijk. 4.9.14

Mogelijke aanvragers voor scÏtorsiitg


Procedure voor een verzoek tot schorsing


Beperkingen op de schorsingsperiode


4.10 4.10.1

Certificaat status services Operationele kenmerken

De status van een certificaat is alleen opvraagbaar wanneer er sprake is van intrekking. Afgezien van de CRL vindt publicatie van de status niet plaats. 4.10.2

Beschikbaarheid van de service

Zie paragraaf 4.9.10. 4.10.3

Operationele eigenschappen


4.11

Einde van de vermelding als certificaathouder Na intrekking van het certificaat is men niet meer als certificaathouder aan de Issuing CA verbonden.

4.12

Sleutel Escrow en herstel

4.12.1

Sleutel escrow en herstel beleid

Er vindt geen escrowing plaats van privé sleutels van CA of eindentiteiten. 4.12.2

Sessie sleutel inkapseling en herstel beleid eit praktijk


5

Algemene, fysieke en operationele beheersmaatregelen

5.1

Fysieke beheersmaatregelen De RDW draagt zorg voor een adequate fysieke, procedurele en personele informatiebeveiliging om de risico’s op verlies, beschadiging en compromittering van essentiële componenten van de CA dienstverlening tot een minimum te beperken. Dit geldt in het bijzonder voor de omgeving van de Issuing CA, waar de certificaten worden uitgegeven.

17

De fysieke, procedurele en personele beveiligingsmaatregelen zijn beschreven in interne procedures van de RDW. Deze worden minimaal én keer per jaar geaudit. Relevante bevindingen zullen worden gepubliceerd in het RDW jaarverslag. Fysieke toegang wordt alleen verleend aan personen die verantwoordelijk zijn voor het aanmaken van certificaten. Deze personen zijn werkzaam bij de RDW en in het bezit van een certificaat om afgifte van certificaten aan eind-entiteiten mogelijk te maken. De ruimte waarin de certificaten worden aangemaakt is afgesloten. De server(s) waarop het certificaat management systeem en de Issuing CA staan, staan in een fysiek beveiligde computerruimte voorzien van noodstroom, airconditioning, brandmelder, brandbiusinstallatie enz. De RDW Dienst Wegverkeer Root CA staat offline in een inbraakwerende kluis in een zeer beperkt toegankelijke ruimte. De smartcards die nodig zijn voor het beheer van de CA’s zijn gekoppeld aan personen. De back up van de Issuing CA is versleuteld en wordt op twee externe RDW-locaties bewaard. De back-up van de RDW Dienst Wegverkeer Root CA wordt in versleutelde vorm op een externe locatie in een beveiligde ruimte in een kluis bewaard. 5.2

Procedurele beheersmaatregelen Onderstaande rollen worden onderscheiden: 1. Eigenaar van de RDW Dienst Wegverkeer PM 2. PKI-administrator belast met het technisch beheer van de PKI-omgeving inclusief het Certificaat Management Systeem 3. CA smartcardhouders, van de smartcards waarover het sleutelmateriaal van de RDW Dienst Wegverkeer Root CA en Issuing CA is verdeeld (split key) 4. Security Manager 5. IT-auditor; voert in opdracht van de eigenaar c.q. directie IT-audits uit op de RDW Dienst Wegverkeer PKI 6. Medewerkers belast met het functioneel beheer van het certificaat management systeem mci. het toekennen van autorisaties 7. Kwaliteitsmedewerkers belast met de noodzakelijke operationele controles Voor het uitvoeren van onderstaande acties zijn minimaal 3 personen noodzakelijk, ieder met een eigen smartcard die benodigd is. Dit betreft: 1. inrichten en door de RDW Dienst Wegverkeer Root CA signen van een onderliggende Issuing CA 2. starten van de PKI-services (booten) 3. terugzetten van de back-up van de security world 4. laden van het sleutelmateriaal van de admin smartcards in een (nieuwe) HSM Voor alle niet hiervoor genoemde beheerhandelingen zijn minimaal 2 personen noodzakelijk (dual control), waarvan 1 PKI-administrator en 1 getuige. Voor het uitvoeren van deze handelingen is een administrator certificaat noodzakelijk. Dit certificaat wordt bewaard op een FWS 140-2 level 3 USB-token. De procedure voor gebruik van dit administrator certificaat borgt dat altijd twee personen aanwezig zijn. In het certificaat management systeem worden de volgende rollen onderscheiden: 1. PM-administrator, belast met het technisch beheer van het certificaat management systeem.

18

2.

3. 4. 5. 6.

RA medewerker, verantwoordelijk voor beoordelen van aanvragen, registreren van Organisatie en/of persoonsgegevens, aanmaken van verzoeken voor certificaatuitgifte en certificaatintrekking. CA medewerker, verantwoordelijk voor uitgifte en intrekking van certificaten en verzending van certificaten en pincodes. Functioneel beheerder, verantwoordelijk voor functioneel beheer van het certificaat management systeem. Operator, verantwoordelijk voor het aanmaken van cd-roms met certificaten. Helpdeskmedewerker, heeft toegang tot het raadplegen van gegevens van certificaathouders en ingetrokken certificaten.

5.3

Personele beheermaatregelen Alle medewerkers die een rol invullen genoemd in paragraaf 5.2 hebben voldoende kennis en ervaring om de opgedragen taken adequaat in te vullen en hebben een geheimhoudingsverklaring ondertekent. Via contracten en toezicht wordt geborgd dat bovenstaande ook geldt voor personeel van betrokken leveranciers.

5.4

Audit logging procedures

5.4.1

Gebeurtenissen die worden getogd

De volgende gebeurtenissen worden binnen de RDW PKI gelogd, hetzij automatisch hetzij handmatig: Rond de certificaat levenscyclus • de aanvraag van een certificaat de gegevens waartegen de eindentiteit werd geauthenticeerd aanpassing van persoonlijke gegevens van een certificaathouder de generatie van een publiek / privaat sleutelpaar voor een eindentiteit de generatie van een certificaat de uitgifte van een certificaat het intrekken van certificaten de generatie van CRLs Rond het beheer van de CA sleutels binnen de RDW PKI • sleutel generatie, back-up, recovery en vernietiging beveiligingsrelevante gebeurtenissen rond de gebruikte HSM, zoals initialisatie en vernietiging. Beveiligingsrelevante gebeurtenissen bij de CA en RA systemen • fysieke toegang tot CA systemen succesvolle en niet succesvolle aanlogpogingen PKI of systeem relevante gebeurtenissen systeem opstart, uitval of shutdown Beveiligingsrelevante gebeurtenissen bij het certificaat management systeem • succesvolle en geweigerde aanlogpogingen opvoeren gebruikers en opvoeren en wijzigen van autorisaties en alle beveiligingsrelevante parameters en instellingen —

—

—

—

—

—

—

—

—

—

—

—

—

—

—

—

Gebeurtenissen gaan vergezeld met elementen waaruit het volgende kan worden afgeleid: datum en tijd van de gebeurtenis identiteit van de bron die de gebeurtenis veroorzaakt identiteit van de bron die de gebeurtenis logt

—

—

—

19

De logs worden twee jaar bewaard. Audit logs zijn beschermd tegen ongeautoriseerde inzage, wijziging, verwijdering en vernietiging door gebruik te maken van een combinatie van fysieke en logische toegangbeveiliging. Van de digitale audit logs wordt een back-up gemaakt. De RDW verplicht zich niet tot kennisgeving rond gebeurtenissen die gelogd zijn in de richting van de eindentiteit of de Organisatie waar deze toe behoort. Kennisgeving zal slechts plaatsvinden indien de RDW dit noodzakelijk acht. In het kader van de beoordeling van de audit logs wordt bepaald of er sprake is van zwakheden in de beveiliging in de RDW PKI omgeving. Geconstateerde (mogelijke) zwakheden worden opgevolgd. Deze beoordelingen en de mogelijk geconstateerde zwakheden worden vastgelegd. 5.5

Archivering van documenten Een overzicht van de gebeurtenissen die worden gearchiveerd is beschreven in interne procedures van de RDW en zijn in overeenstemming met relevante weten regelgeving, waaronder de Archiefwet 1995. Er zijn maatregelen genomen die waarborgen dat het archief zodanig wordt bewaard, dat verlies in redelijkheid is uitgesloten. De RDW verplicht zich niet tot kennisgeving rond de archivering in de richting van de eindentiteit of de Organisatie waar deze toe behoort. Kennisgeving zal slechts plaatsvinden indien de RDW dit noodzakelijk acht. Alle gebeurtenissen zoals beschreven in paragraaf 5.4.1 worden voorzien van een tijdsmarkering. Alle gearchiveerde gebeurtenissen worden intern opgeslagen. De zaken genoemd in paragraaf 5.4.1 worden periodiek gecontroleerd op integriteit. Deze controles vinden jaarlijks plaats in het kader van de reguliere IT-audit.

5.6

Verstrekken van RDW PKI Sleutels De publieke sleutels die deel uit maken van de RDW PKI (trust certificaten) worden bij het aanmaken van de drager van het certificaat hieraan toegevoegd. Bij een eventuele wijziging van de publieke sleutels is paragraaf 3.3 van toepassing. De RDW geeft geen certificaten uit met een levensduur die langer is dan die van één der bovenliggende CA’s, te weten de RDW Dienst Wegverkeer Root CA of Issuing CA. Dit betekent dat er een tijdstip ontstaat dat de certificaten van de bovenliggende CA’s nog wel geldig zijn, maar dat er geen nieuwe eindentiteit certificaten kunnen worden uitgegeven. Tijdig voor dit tijdstip zal de RDW zorg dragen dat de betreffende CA sleutels worden vervangen. De procedures rond revocatie en de publicatie van CRLs inzake de vervangen CA’s blijven van kracht tijdens de resterende levensduur van de certificaten van deze CA’ s.

5.7

Compromitteren van de privé-sleutel en calamiteitenbeheersing De back-up- en recoveryprocedures in geval van calamiteiten zijn onderdeel van de interne procedures van de RDW zoals neergelegd in de RDW-calamiteitenplanning. De RDW verplicht zich niet tot kennisgeving rond de genoemde procedures in de richting van de eindentiteit of de Organisatie waar deze toe behoort. Kennisgeving zal slechts plaatsvinden indien de RDW dit noodzakelijk acht.

20

De RDW heeft toereikende maatregelen genomen die in redelijkheid waarborgen dat bij gecorrumpeerde computers, software en/of data, de dienstverlening binnen de gemaakte afspraken kan worden hersteld. In geval van compromittering van de privésleutel van de RDW Dienst Wegverkeer Root CA of de Issuing CA zal de RDW zich inspannen om zo spoedig mogelijk alle entiteiten binnen de RDW PKI in te lichten. De eindgebruiker moet het gebruik van de openbare sleutel van de Issuing CA dan onmiddellijk en permanent staken. In geval van compromittering of verlies van de privésleutel van een eindentiteit zal deze zo spoedig mogelijk een verzoek tot intrekking van het certificaat indienen bij de RA. De procedures met betrekking tot uitwijkrnogeljkheden zijn beschreven in interne procedures van de RDW. De RDW verplicht zich niet tot kennisgeving rond de genoemde procedures in de richting van de eindentiteit of de Organisatie waar deze toe behoort. Kennisgeving zal slechts plaatsvinden indien de RDW dit noodzakelijk acht.

5.8

CA beëindiging Bij beëindigen van de Issuing CA’s activiteiten draagt deze CA zorg voor de volgende handelingen: 1. De Issuing CA informeert de RDW Dienst Wegverkeer Root CA van het voornemen om haar activiteiten als CA te staken, 2. De CA stelt alle entiteiten binnen de RDW PKI op de hoogte van haar voornemen om haar activiteiten als Issuing CA te staken, minimaal 60 werkdagen voorafgaand hieraan. 3. Alle niet verlopen certificaten uitgegeven door de Issuing CA worden ingetrokken conform de procedures genoemd in paragraaf 4.9. 4. De CA dient een verzoek in ter intrekking van het Issuing CA certificaat bij de RDW Dienst Wegverkeer Root CA.

6

Technische beveiliging

6.1

Genereren en installeren sleutelpaar

6.1.1

Genereren steutetpaar

1. 2.

6.1.2

De sleutelparen van de CA’ s binnen de RDW PKI worden in een HSM gegenereerd en bewaard. De sleutelparen van de eindentiteiten worden in een H$M gegenereerd en tijdelijk opgeslagen in een database als PKCS#12 bestand. Nadat de sleutelparen op de cd-rom of de smartcard zijn gezet, worden deze in de database gewist.

Aflevering van privésleutel aan eindentiteit

Zie paragraaf 3.2.1. De privésleutel is beveiligd met een initiële pincode die minimaal een dag voor het verzenden van de smartcard of minimaal 1 dag na het verzenden van de cd-rom, per post aan de eindentiteit zal worden toegestuurd. De initiële pincode is voor de RDW niet zichtbaar en niet reproduceerbaar. 6.1.3

Aflevering van publieke stetttet aan de CA

Niet van toepassing. Eindentiteiten hoeven hun publieke sleutel niet naar de CA te sturen.

21

6.1.4

Aflevering van de pttbtieke sleutel vaiz de CA aan eindentiteiten

De publieke sleutel van de CA wordt op dezelfde wijze afgeleverd als de privésleutel van de eindentiteit. 6.1.5

Stettteltengten

Zie paragraaf 7.1. 6.1.6

Paraineters ten behoeve van het genereren van publieke sleutels en controle kwaliteit

Zie paragraaf 7.1 6.1.7

Gebruik publieke sletttels

De publieke sleutel behorende bij het certificaat van een eindentiteit is uitsluitend bestemd voor doelen zoals beschreven in paragraaf 1.4.1. In de extensie van het certificaat zijn deze doelen vastgelegd.

6.2

Bescherming van privésleutels 1. Algemeen 1.1 De RUW Dienst Wegverkeer Root CA en de Issuing CA zorgen voor adequate bescherming van de privésleutels. 1.2 Het genereren, beschermen en eventueel vernietigen van CA privésleutels vindt plaats door middel van een HSM, volgens FIPS 140-2 level 3. Toegang is alleen mogelijk met behulp van de sleutelparen op minimaal 2 uit $ smartcards. 1.3 De CA privésleutels worden gegenereerd in de cryptografische module (HSM) waarin ze worden gebruikt. Slechts in het geval van recovery is er sprake van invoer van een privésleutel. Deze vindt plaats door de versleutelde inhoud van de HSM die hersteld moet worden beschikbaar te stellen aan een nieuwe HSM en deze in te lezen. De privésleutel komt nooit buiten de HSM. Hiertoe dienen naast de PKI administrator en een getuige minimaal drie CA smartcardhouders aanwezig te zijn. FIPS level 3 blijft altijd gewaarborgd. 1.4 Privésleutels van de CA’s worden alleen vernietigd bij het beëindigen van de dienstverlening van de RDW Dienst Wegverkeer Root CA. Dit vindt plaats door de HSM’s te initialiseren en alle back-ups te vernietigen. Hiervan zal een protocol worden opgesteld onder toezicht van een getuige. 1.5 Beheer van privésleutels van CA’s is slechts mogelijk in de fysieke aanwezigheid van minimaal drie daartoe geautoriseerde RDW PKI medewerkers. Zie paragraaf 5.2. 1.6 Er vindt geen escrowing van privésleutels van CA of eindentiteiten plaats. 1.7 Van CA privésleutels is een back-up gemaakt in versleutelde vorm, die alleen weer teruggezet kan worden met behulp van drie CA smartcardhouders en 1 PKI administrator. 2. Eindentiteit 2.1 De eindentiteit is exclusief verantwoordelijk voor het beschermen van zijn privésleutel, zoals deze op de drager van het certificaat staat, door middel van een pincode. De privésleutel van de eindentiteit kan gebruikt worden op het moment dat de juiste pincode is ingevoerd. De eindentiteit dient de drager van het certificaat zorgvuldig te bewaren en de pincode geheim te houden. Verlies, mogelijke compromittering of beschadiging van de drager van het certificaat of bijbehorende pincode of beëindiging van functie dient terstond aan de RA te worden gemeld (zie paragraaf 1.5.2). De pincode is willekeurig en bestaat voor certificaten op smartcard uit 5 cijfers, voor clientcertificaten op cd-rom uit 6 cijfers, voor download servicecertificaten uit $ cijfers en voor servicecertificaten op cd-rom uit 10 cijfers, waarbij gekozen wordt uit de cijfers 0 tot en met 9.

22

2.2 Vernietigen van de privésleutels van eindentiteiten kan alleen door de certificaathouder zelf worden uitgevoerd, door het feitelijk vernietigen van de cd-rom of smartcard. 2.3 Van de privésleutel van de eindentiteiten wordt geen back-up gemaakt. 2.4 De privésleutels van eindentiteiten worden niet opgeslagen in de cryptografische module, maar op de cd-rom of smartcard voor eindentiteiten. 6.3

Overige aspecten van sleutelbeheer

6.3.1

Arcitivering publieke sleutels

1. 2. 6.3.2

Periode van gebruik sleutels

1. 2. 3. 4.

6.4 6.4.1

De publieke sleutels van de CA’s worden gearchiveerd. De publieke sleutels van de eindentiteiten worden gearchiveerd. De geldigheidsduur van het RDW Dienst Wegverkeer Root CA certificaat bedraagt 15 jaar. De geldigheidsduur van het Issuing CA certificaat bedraagt 15 jaar. De geldigheidsduur van het certificaat van een eindentiteit op een smartcard bedraagt 5 jaar. De geldigheidsduur van het certificaat van een eindentiteit op een cd-rom of gedownload bedraagt 2 jaar.

Activeringsdata Geiteratie en installatie

De privésleutels van eindentiteiten zijn beveiligd door een pincode op het PKCS#12 bestand en na plaatsing op de cd-rom of smartcard door de pincode van de cd-rom of smartcard. Eindentiteiten dienen bij de eerste ingebruikname van de smartcard hun privésleutels te beveiligen met een door hen zelf te kiezen pincode. Ook een gedownload servicecertificaat dient te worden beveiligd middels een zeifgekozen pincode. 6.4.2

Bescherming van activeringsdata

De pincode die dient ter beveiliging van de privésleutel dient uniek en onvoorspelbaar te zijn en van een zodanige lengte zodat deze in verhouding staat met de sleutel die beveiligd wordt. De pincode van certificaten op smartcard moet uit 5 karakters bestaan. De pincode van clientcertificaten op cd-rom moet uit 6 karakters bestaan. Voor download servicecertificaten geldt $ karakters en voor servicecertificaten op cd-rom 10 karakters. Deze karakters kunnen zijn: de cijfers 0 t/m 9. De initiële pincode behorende bij de cd-rom of smartcard voor een eindentiteit wordt uitsluitend geprint op een pinmailer en afzonderlijk van de cd-rom of smartcard naar de certificaataanvrager gezonden. 6.5

Computer beveiligingsmaatregelen De specifieke technische beveiligingsmaatregelen zijn beschreven in interne procedures van de RDW. Computersystemen worden ingericht en beheerd conform procedures die waarborgen dat het vereiste beveiligingsniveau wordt geborgd.

6.6

Technische beheersmaatregelen in de levenscyclus OTAP-, Change- en Securitymanagement procedures borgen dat bij wijzigingen het vastgestelde beveiligingsniveau blijft gehandhaafd.

23

6.7

Netwerk beveiliging beheersmaatregelen Beveiligingsmaatregelen op netwerkniveau borgen dat toegang tot de CA-server alleen mogelijk is voor geautoriseerde protocollen en vanaf expliciet geautoriseerde werkplekken en servers.

6.8

Tijdstempelen Niet van toepassing.

7.

Certificaat, CRL en OCSP profiel.

7.1

Certificaatprofiel

Alle certificaten die worden uitgegeven betreffen X.509 versie 3 certificaten. Deze certificaten bevatten de volgende velden: Inhoud RDW Dienst Wegverkeer Root CA certificaat Version Path length Life time Key length Certificate signature algorithm Hash algorithm Key usage

Key usage extension Netscape certificate type Issuer Distinguished name Country (C) Organization (0) Location (L) Common Name (CN) Subject Country (C) Organization (0) Location (L) Organizational Unit (OU) Corn mon Name (CN) CDP CRL Validity Renewal CPS

Inhoud RDW Issuing CA 1 certificaat Version Path length Life time Key length Cerificate signature algorithm Hash algorithm Key usage

3 (is gelijk aan X.509 versie 3) no constraint 15 years 2048 shal RSA shal digital signature Certificate signing 0ff line CRL signing CRL signing critical -

NL RDW Groningen Self Signed NL RDW Groningen not used RDW Dienst Wegverkeer Root CA na. 18 months 12 months http:/www.diensten.rdw.nl/cps/RDWDienstWegverkeerCPS.pdf

3 (is gelijk aan X.509 versie 3) no constraint 15 years 2048 shal RSA shal digital sig nature Certificate signing 0ff line CRL signing CRL signing

24

Key usage extension Netscape certificate type Issuer Distinguished name Country (C) Organization (0) Location (L) Common Name (CN) Subject Country (C) Organization (0) Location (L) Organisational Unit (OU) Common Name (CN) CDP CRL Validity Renewal CPS

critical -

NL RDW Groningen RDW Dienst Wegverkeer Root CA NL RDW Groningen not used RDW Issuing CA 1 http://www.diensten. rdw.nI/crl/RDWDienstWegverkeerRootCA.crl 7days 1 hour http:/www.diensten.rdw.nI/cps/RDWDienstWegverkeerCPS.pdf

Inhoud van certificaten van RDW-medewerkers op smartcard (RIW Smartcard Intern) 3 (is gelijk aan X.509 versie 3) Version no constraint Path length 5 years Life time 1024 Key length shal RSA Cerificate signature algorithm shal Hash algorithm digital signature Key usage Key encipherment Data encipherment Key agreement critical Key usage extension SSL CA, S/MIME CA, Object signing CA Netscape certificate type Issuer Distinguished name NL Country (C) RDW Organization (0) Groningen Location (L) RDW Issuing CA 1 Common Name (CN)* Subject NL Country (C) RDW Organization (0) Common Name (CN)

Inhoud certificaten van eindentiteiten op smartcard (RDW Smartcard) 3 (is gelijk aan X.509 versie 3) Version no constraint Path length 5 years Life time 1024 Key Iength shal RSA Cerificate signature algorithm shal Hash algorithm digital signature Key usage Key encipherment Data encipherment Key agreement critical Key usage extension SSL CA, S/MIME CA, Object signing CA Netscape certificate type Issuer Distinguished name NL Country (C) RDW Organization (0) Groningen Location (L) RDW Issuing CA 1 Common Name (CN)*

25

Subject Country (C) Organization (0) Common Name (CN) Serial Number

NL http://www.diensten. rdw. nI/crl/RDWlssuinqCAl .crl

Validity Renewal

n.a. n.a.

CDP CRL

Inhoud clientcertificaten van eindentiteiten op cd-rom (RDW Client) Version Path length Life time Key length Cerificate signature algorithm Hash algorithm Key usage

Key usage extension Netscape certificate type lssuer Distinguished name Country(C) Organization (0) Location (L) Common Name (CN)* Subject Country CC) Organization (0) Common Name (CN)

3 (is gelijk aan X.509 versie 3) no constraint 2 years 1024 shal RSA shal digital sig nature Key encipherment Data encipherment critical SSL Client Authentication, SMIME (aO) NL RDW Groningen RDW Issuing CA 1 NL RDW Diensten -

Inhoud certificaten van eindentiteiten op smartcard voor self-service (SelfService Smartcard) Version Path length Life time Key length Cerificate signature algorithm Hash algorithm Key usage

Key usage extension Netscape certificate type Issuer Distinguished name Country (C) Organization (0) Location (L) Common Name (CN)* Subject Country(C) Organization (0) Organizational Unit (OU) Common Name (CN) Serial Number

3 (is gelijk aan X.509 versie 3) no constraint 5 years 1024 shal RSA shal digital signature Key encipherment Data encipherment Key agreement critical SSL CA, S/MIME CA, Object signing CA NL RDW Groningen RDW Issuing CA 1 NL

Inhoud servicecertificaten van eindentiteiten op cd-rom (RDW Services) Version

3 (is gelijk aan X.509 versie 3)

26

Path length Life time Key ength Cerificate signature algorithm Hash algorithm Key usage

Key usage extension Netscape certificate type Issuer Distinguished name Country (C) Organization (0) Location (L) Common Name (CN)* Subject Country (0) Organization (0) Organizational Unit (OU) Common Name (CN) Serial Number

7.1.1

no constraint 2 years 1024 shal RSA shal digital signature Key encipherment Data encipherment critical SSL Client Authentication, SMIME (aO) NL RDW Groningen RDW Issuing CA 1 NL

Versie nttinmers

De CA genereert X.509 versie 3 certificaten. 7.1.2

Certificaat extensies

De certificaten binnen de RDW PKI bevatten X.509v3-extensies. Zie paragraaf 7.1. 7.1.3

Atgoritme object identifiers


Vormen van de naamgeving

Zie paragraaf 3.1 en verder. 7.1.5

Beperkingen aan de naamgeving

Zie paragraaf 3.1 en verder. 7.1.6

Certificaat beleid object identificatie


Gebruik van beleid beperkingen extensie

Deze extensie wordt niet gebruikt. 7.1.8

Beleid beperkiitgen syntaxis en betekenis


Betekenis voor de aflzandeliitg van kritieke certificaat beleid extensie


7.2 7.2.1

CRE-profiel Versienuininer CRL

De Certificate Revocation List wordt gepubliceerd in het X.509 v3-formaat. 7.2.2

CRL en CRL-entry extensies


27

7.3

OCSP-profiel Niet van toepassing.

$

Compliance audit en overige analyses

8.1

Frequentie en redenen van audit Jaarlijks vindt een audit plaats waarbij wordt nagegaan of de bepalingen in dit CP$ door de CA en RA worden nageleefd.

8.2

IdentiteitlKwaliteit van auditor De audit zal worden uitgevoerd door een onafhankelijke IT-Auditor (RE).

8.3

Relatie tussen auditor en object van audit De auditor zal volledig onafhankelijk zijn en op geen enkele wijze verbonden zijn aan de partij die het voorwerp is van de audit.

8.4

Onderwerpen van audit De naleving van dit CPS en de bijbehorende procedures en technieken in opzet, bestaan en werking zijn het object van de audit.

8.5

Acties naar aanleiding van onvolkomenheid Indien er naar aanleiding van de audit onvolkomenheden of gebreken worden vastgesteld, zal de RDW zo spoedig mogelijk tot herstel van deze onvolkomenheden of gebreken overgaan. Nadat herstel van de onvolkomenheden of gebreken heeft plaatsgevonden zal er opnieuw een audit plaatsvinden.

8.6

Communicatie van resultaten De relevante resultaten van de audit zijn terug te vinden in het jaarverslag van de RDW.

9

Overige ondernemings- en wettelijke zaken

9.1

Kosten Voor de instandhouding van de beveiliging van de online aansluiting wordt jaarlijks een beveiligingstarief in rekening gebracht. Dit tarief is te vinden in de Staatscourant onder het tarievenbesluit RDW.

9.2

Financiële verantwoordelijkheid

9.2.1

Vrijwaring door relyingparties


Vertrouwde relaties


28

9.2.3

Administratieve proceditres

Niet van toepassing. 9.3 9.3.1

Vertrouwelfjkheid Vertrott welijke informatie

Onder vertrouwelijke informatie wordt verstaan: persoonsgegevens, 1.1. correspondentie met eindentiteiten 1.2. privésleutels en de hierbij behorende pincodes, 1.3. gegevens over de certificaathouder zoals de RDW die registreert, 1.4. bedrijfs- of fabricage gegevens, 1.5. redenen van de intrekking van een certificaat 1.6. audit logs 1.7. gedetailleerde documentatie inzake het beheer van de RDW PKI 1.8. audit rapporten door interne of externe auditors. 1.9. 9.3.2

Niet vertrouwelijke informatie

Als niet vertrouwelijke informatie wordt alle overige informatie aangemerkt. 9.3.3

Verantwoordetrjkheid om vertrouwelijke informatie te beschermen

Vertrouwelijke informatie wordt niet vrijgegeven, tenzij hiertoe een wettelijke plicht bestaat. 9.4

Privacy van persoonlijke informatie

9.4.1

Privacy plan

De verwerking van persoonsgegevens door de RA en de Issuing CA geschiedt conform de Wet bescherming persoonsgegevens. 9.4.2

Informatie gekwalificeerd als privé

Certificaathouders die inzage wensen in hun Organisatie- of persoonsgegevens, dienen hiertoe een verzoek in te dienen bij de RDW. Het verzoek dient schriftelijk naar de RA te worden gestuurd. 9.4.3

Informatie niet gekwalificeerd als privé

Alle informatie die niet gerelateerd is aan de Organisatie- of persoonsgegevens van certificaathouders. 9.4.4

Verantwoordelijkheid om privé informatie te beschermen

De RDW is verantwoordelijk voor het beschermen van privé informatie. 9.4.5

Signaleren en goedkeuren gebruik privé imiformnatie

De RDW behoudt zich het recht voor, om tot het vrijgeven van vertrouwelijke informatie over te gaan op grond van andere omstandigheden, die naar haar oordeel daartoe aanleiding kunnen geven. Alvorens tot vrijgeven van informatie wordt overgegaan zullen betrokkenen in de gelegenheid worden gesteld om hun zienswijze kenbaar te maken. 9.4.6

Overige redenen voor vrijgeven van informatie


29

9.5

Intellectuele eigendomsrechten 1. Het auteursrecht met betrekking tot dit CPS berust bij de RDW. 2. De CA is rechthebbende ten aanzien van het openbaren, verveelvoudigen of iedere andere beheersactiviteit met betrekking tot de certificaten die hij heeft uitgegeven. 3. Binnen de ROW PKI berusten alle rechten, die mogelijkerwijs kunnen worden gevestigd op sleutelparen, bij de CA.

9.6

Vertegenwoordiging en waarborg

9.6.1

CA vertegenwoordiging en waarborgen

De CA garandeert zijn dienstverlening uit te voeren conform dit CPS. De CA verklaart dat de informatie in het certificaat correct is, voor zover deze bij de CA bekend is. 9.6.2

RA vertegenwoordiging en waarborgen

De RA en de namens de RA optredende organisatieonderdelen garanderen hun dienstverlening uit te voeren conform dit CPS. De RA verklaart dat een certificaat niet wordt uitgereikt zonder een aanvraag daartoe. De RA verricht de noodzakelijke validatie- en authenticatieprocedures en zal hierbij de gegevens in de certificaataanvraag, die de RA heeft ontvangen van de aanvrager, correct weergeven. 9.6.3

Eindentiteit vertegenwoordiging en waarborgen

De eindentiteit dient het aanvraagformulier naar waarheid in te vullen, de smartcard strikt persoonlijk te gebruiken en de cd-rom alleen voor de aanvragende organisatie. De certificaathouder is aansprakelijk voor schade voortvloeiend uit aan hem toerekenbaar handelen in strijd met zijn verplichtingen zoals beschreven in paragraaf 1.4. 9.6.4

Retying party vertegenwoordiging en waarborgen

De RDW als relying party is verplicht na te gaan of een eindentiteit certificaat geldig is, door: • Verificatie van de digitale handtekening op het eindcertificaat en van de certificaten in het certificatie pad waaronder het eindcertificaat is afgegeven. • Verificatie dat het eindcertificaat niet ingetrokken is door gebruik te maken van een geldige CRL verstrekt door de RDW, zie paragraaf 2.3. De relying party accepteert door het gebruik van een RDW eindentiteit certificaat de limitering van aansprakelijkheid en garanties zoals beschreven in dit CPS, alsmede de bepalingen uit de gebruikersvoorwaarden en de overige bij de uitreiking van het certificaat verstrekte informatie. De relying party vertrouwt er op dat de informatie zoals deze in het certificaat is opgenomen, correct is. 9.6.5

Vertegenwoordiging en waarborgen van andere betrokkenen


Disclaimers van waarborgen Expliciete waarborgen zullen niet worden gegarandeerd.

9.8

Uitsluiting van aansprakelijkheid De RDW is niet aansprakelijk voor schade, direct of indirect voortvloeiend uit het gebruik van een RDW certificaat voor andere doeleinden dan waarvoor het is uitgegeven (zie paragraaf 1.4). De RDW is niet aansprakelijk voor vertraging en gebreken in de uitvoering van de werkzaamheden die te wijten zijn aan (technische) storingen zoals transmissiefouten, storingen aan apparatuur en systeemprogrammatuur, defecten in de apparatuur en

30

programmatuur, opzet zoals fraude, illegaal gebruik van programmatuur, sabotage, diefstal van gegevens en bedieningsfouten door derden, fouten van derden met als gevolg netwerkuitval, stroomuitval, brand, blikseminslag, aanzienlijke waterschade, een breuk in een telefoonkabel, oorlogsgeweld of natuurrampen en meer in het algemeen oorzaken die niet de redelijk in acht te nemen zorg van de RDW betreffen. 9.9

Compensatie In het geval schade geleden wordt door een derde partij, zal op basis van de bepalingen in dit CPS worden bepaald wie hiervoor verantwoordelijk gesteld moet worden. Indien dit niet mogelijk is, zal de bevoegde rechtbank te Groningen uitspraak doen.

9.10

Geldigheidsduur en beëindiging

9.10.1

Getdigheidsdirur

Zie paragraaf 7.1. 9.10.2

Beëindiging

Na het verstrijken van de geldigheidsduur zal het certificaat worden beëindigd. De certificaathouder zal tijdig op de hoogte worden gesteld van het bereiken van het einde van de geldigheidsduur. 9.10.3

Effect van beëiitdigiizg eit voortbestaan

Bij beëindiging van het certificaat van een eindentiteit, heeft deze de mogelijkheid om middels het aanvragen van een vervangend certificaat te kunnen voortbestaan als certificaathouder. 9.11

Individuele toelichting en communicatie met betrokkenen Wanneer een individuele toelichting gewenst is, kan contact worden opgenomen met de CA (zie paragraaf 1.5).

9.12

Amendementen

9.12.1

Procedure voor amendement

Dit CPS wordt uitgegeven door en onder verantwoordelijkheid van de algemeen directeur van de RDW. De procedure voor wijzigingen en goedkeuringen van het CPS is als volgt: 1. Voorstellen tot wijziging kunnen worden ingediend door de organisatieonderdelen van de RDW aan wie de uitvoering van de CA of RA taken conform dit CPS is opgedragen dan wel organisatieonderdelen ten behoeve waarvan de Issuing CA wordt ingezet; 2. De algemeen directeur is verantwoordelijk voor de verwerking van de voorstellen. Hij kan zich hierbij laten adviseren door inhoudelijk experts, onder andere op technisch, procedureel, commercieel en juridisch gebied. Uiteindelijk beslist de algemeen directeur of een voorstel tot wijziging wordt doorgevoerd; en Indien het voorstel is goedgekeurd, laat de algemeen directeur het CPS aanpassen. Indien 3. voor inwerkingtreding voorafgaande in kennis stelling van de certificaathouders noodzakelijk is, draagt de algemeen directeur tevens hiervoor de verantwoordelijkheid. De wijziging treedt in werking vijf werkdagen nadat de nieuwe CPS door de RDW bekend is gemaakt door publicatie op de internetsite van de RDW. 9.12.2

Kennisgevingmn echanisme en periode

31

Indien er bepalingen uit dit CPS gewijzigd worden waarvan de wijziging van invloed is op de rechten, verplichtingen en bevoegdheden van de entiteiten binnen de PKI zal de RDW deze wijzigingen publiceren en bekendmaken op de internetsite van de RDW. 9.12.3

Ontstandigheden waaronder Oject Idenfifler veranderd utoet wordeit

Voor wat betreft wijziging van bepalingen van het CPS die geen materiële gevolgen hebben voor entiteiten binnen de PKI is de RDW niet verplicht om deze wijzigingen kenbaar te maken aan de entiteiten binnen haar PKI. De RDW zal de herziene CPS publiceren op haar website. 9.13

Beslechting van geschillen Alle geschillen voortvloeiend uit of verband houdend met CPS en/of gebruikersvoorwaarden worden beslecht door de bevoegde rechtbank te Groningen. Alvorens een geschil voor te leggen aan de bevoegde rechtbank zullen partijen proberen om samen in goed overleg tot een oplossing te komen.

9.14

Toepasselijk recht Op de bepalingen in dit CPS en op de RDW gebmikersvoorwaarden is Nederlands recht van toepassing. Indien een van de bepalingen van dit CPS in strijd met de wet zou blijken te zijn, blijven de overige bepalingen van dit CPS onverminderd van kracht, voor zover deze bepalingen, gelet op de inhoud en de strekking van die bepalingen, niet in onverbrekelijk verband met die bepalingen staan.

9.15

Positie binnen bestaande wetgeving Alle betrokken partijen binnen de RDW-PKI dienen zich te houden aan specifieke wetgeving met betrekking tot PKI’s zoals deze is opgenomen in het Nederlands recht.

32

Table of contents Introduction

1. 1.1 1.2 1.3 1.4 1.5 1.6

General Document name and Identification Partjes involved in RDW PKI Applicability Contact information Definitions and acronyms

Publication and Repository Obligations

2. 2.1 2.2 2.3 2.4

Repository Publication of certificate information Time or frequency of publication Repository access control

Identification and authentication

3. 3.1 3.2 3.3 3.4

Naming Initial validation of identity Identification and authentication for replacement of a certificate Identification and authentication for withdrawal request

Operational requirements for the certificate life-cycle

4. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12

Application for certificate Processing of certificate application Certificate issue Certificate acceptance Key pair and use of certificate Certificatereissue Certificate replacement Certificate modification Certificate withdrawal and suspension Certificate status services End of registration as certificate holder Key escrow and recovery

General, physical and operational administration measures

5 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8

Physical administration measures Procedural administration measures Personnel administration measures Audit logging procedures Archiving of documents Distribution of RDW PKI keys Compromise of the private key and incident management CA termination

Technical security

6 6.1 6.2 6.3 6.4 6.5

Generation and installation of key pair Protection of private keys Other aspects of key administration Activation data Computer security measures

35 35 35 35 36 37 37

37 37 37 37 3$

39 39 39 41 41

42 42 42 42 43 43 43 44 44 45 47 47 47

48 48 4$ 49 49 50 50 50 51

51 51 52 53 53 53

33

6.6 6.7 6.8

Technical administration measures during the life-cycle Network security administration measures Time stamping

Certificate, CRL and OCSP profile

7. 7.1 7.2 7.3

$ 8.1 8.2 8.3 8.4 8.5 8.6

9 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 9.11 9.12 9.13 9.14 9.15

10. 11. 11.1 11.2

Certificateprofile CRL profile OCSPprofile

53 54 54

54 54 57 58

Compliance audit and other analyses

58

Frequency and reasons for audit Identity/Quality of auditor Relationship between auditor and subject of audit Subjects of audit Actions motivated by deficiency Communication of resuits

5$ 58 58 58 58 58

Other commercial and legal matters

58

Costs Financial responsibility Confidentiality Privacy of personal information Intellectual property rights Representation and guarantee Guarantee disclaimers Exclusion of liability Compensation Validity period and termination Individual explanation and communication with parties involved Amendments Settiement of disputes Applicable law Position within existing legislation

Formele goedkeuring/Formal approval Bij lagen/Appendices Gebruikte aficortingen / Abbreviations used Verklarende woordenljst / Glossary

5$ 59 59 59 60 60 61 61 61 61 61 61 62 62 62

63 64 64 64

34

Introduction 1.1

General This Certïficatjon Practice Statement has been drafted as a framework for use of certificates issued by the “RDW Pttblic Key Infrastructure”. The RDW is the Dutch vehicle approval and information authority. This CPS describes the procedures, techniques and judicial principles that the RDW implements in administering the “RDW PKT’. The structure of this CPS is in accordance with the Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework (RFC3647). A glossary is included as an appendix.

1.2

Document name and Identification The name of this CPS is the “RDW Certification Practice Statement”. No object identifier has been registered or allocated to this CPS.

1.3

Partjes involved in RDW PKI

1.3.1

Certifïcation Authority The RDW PKI consists of various certificate chains. Each certification authority (CA) within the RDW PKI acts according to specific procedures that are related to their task. The following CAs are operational within the RDW PKI: RDW Root CA RDW Issuing CA 1 RDW Acc Issuing CA 1 The RDW Root is the CA that issues the first certificate within a certificate chain. The RDW Root CA signs the certificates of the underlying CAs within the RDW PKI. The RDW Issuing CA 1 is the CA that issues certificates to end entities within the RDW PKI. This CA is referred to as the Issuing CA in the rest of this document. The RDW Acc Issuing CA 1 has been set up in the same way as the RDW Issuing CA 1 and is used to test the correct operation of the PKI after a change.

1.3.2

Registration Attthority

The following Registration Authorities (RAs) are operational within the RDW: Driving Licences Unit (Unit Rijbewijzen) for certificates that are issued to municipal officials for the purposes of secured data exchange and access to the driving licences register.

35

Approvals and Supervision Unit (Unit Erkenning en Toezicht) for certificates that are issued to (recognised) businesses and insurance companies for the purposes of access to RDW applications. Supply of Information Unit (Unit Informatieverstrekking) for certificates that are issued to various organisations that have a relationship with the RDW for the purposes of setting up a secured connection between said organisation and the RDW. 1.3.3

End entities

Applicants and certificate holders are considered as end entities within the RDW PKI. The operational end entities within the RDW PKI are: 1

2

1.3.4

Applicants i. All municipal officials who require online access to RDW applications. ii. All organisations that are recognised by the RDW or are nominated in another way as dient of the RDW, which require access to RDW applications. iii. All organisations nominated as dient of the RDW that wish to set up a secured connection witli the RDW. iv. All RDW staff who require access to RDW applications. Certificate holders i. The applicants to whom a certificate is issued by the RDW.

Retying partjes

Within the RDW, the relying party is considered to be: The RDW itself in protecting the data communication for the purposes of altering and consulting registers, which are maintained by the RDW as or pursuant to a legal duty. 1.3.5

Other parties involved

No other party is involved.

1.4

Applicability

1.4.1

Intendedpurpose

When issuing a certificate, the purpose it is to serve is indicated. The following certificate types are distinguished: Production certificates issued by the RDW Issuing CA 1 1 The Issuing CA uses ïts private key only for the issue of certificates and the digital signing of CRLs as is described in this CPS. The production certificates issued for use by end entities within the RDW PKI are solely intended for identification, authentication and digital signing of and by the end entity for the purposes of: 1.1 access to RDW applications, 1.2 consulting and altering registers, which are maintained by the RDW as or pursuant to a legal duty, and for which the RDW is responsible, 1.3 the protection of data exchange between end entities and the RDW. Acceptance certificates issued by the RDW Issuing CA 1 2 Acceptance certificates are only used for testing after a change. 1.4.2

Prohibited use

All applications that deviate from those listed in 1.4.1 are prohibited.

36

1.5

Contact information

1.5.1

Respoitsible organisation

The RDW is responsible for the implementation of this CPS. 1.5.2

Contact person The following organisation unit at the RDW is responsible for the implementation (maintenance and interpretation) of this CPS: RDW CA Vehicle Registration and Documents Unit P0 Box 30000 9640 RA Veendam, The Netherlands

1.5.3

Person who determines the appticabitity of this CPS for CertiJïcate Policies (CPs)

The RDW makes no use of Certificate Policies. The elaboration of the conditions linked to the use of certificates is laid down in this CPS. 1.5.4.

CPS endorsernent procedure

The CA and RAs have endorsed this CPS.

1.6

Definitions and acronyms A list of the definitions used in inciuded in section 11.2.

2.

Publication and Repository Obligations

2.1

Repository The repository of issued certificates is neither published nor made available to parties outside the RDW. The Issuing CA publishes the list of withdrawn certificates (CRL) and makes the said list available for the purposes of establishing the validity of a certificate.

2.2

Publication of certificate information Documents concerning the detailed administration of the RDW PKI are characterised by the RDW as confidential and will not be revealed to the public. The list of issued certificates is neither published nor made available to parties outside the RDW.

2.3

Time or frequency of publication 1. The Issuing CA publishes a CRL each time an end entity certificate is withdrawn, and at least once an hour. According to the ETSI standard, this should happen at least once a day. The CRL has a validity period of seven days. 2. The publication of the CPS happens according to the stipulations in section 9.12. 3. When the CPS is akered, all entities within the RDW PKI are informed of this, in accordance with section 9.12.

37

2.4

Repository access control This is not applicable outside the RDW; within the RDW, internal procedures have been set up for this.

38

3.

Identification and authentication

3.1

Naming

3.1.1

Types of izaine

Every entity has a Distinguished Name (DN) which is included in the “certificate subject name” field, as defined in the X.500 standard for DNs. For the certificate profiles, see section 7.1. 3.1.2

Sensible naming

Each name that is used within the RDW PKI corresponds to the relevant entity. The names are uniquely identifiable with the entity by the relying party. 3.1.3

Anonymity or pseudonyrnity of subscribers

Not applicable. 3.1.4

Rutes for interpretation of nalning

See section 3.1.1. 3.1.5

Unique

nal?ting

All certified names are unique. 3.1.6

Recognition, authentication and the rote of tradernark rights

For rules with regard to trademark rights and dispute settiement with regard to naming, the procedure as described in sections 9.13 and 9.14 appiles.

3.2

Initial validation of identity

3.2.1

Evidence ofpossession of a private key

After application, the private key will as part of the certificate: 1. be handed over personally to the end entity where the said entity is an ABR (authorised to authorise access) or an RDW staff member. 2. be sent to the ABR when the end entity is an RIJA (issuer of driving licences, see section 4.3). The ABR hands the private key over to the RIJA personally. 3. For businesses that apply for a certificate on CD-rom for the purposes of access to RDW services, the said CD-rom is sent to the management of the business concemed. 4. For customers who request a smartcard for self-service or a CD-rom for the purposes of setting up a secured connection, this is sent to the nominated contact person of the organisation concerned. It is assumed for all end entities that the said entity is in possession of the private key within two weeks of sending the certificate. 3.2.2

Authentication of the organisation

As regards the procedure for applying for a certificate for the RA concemed, a link will be made with the already exi sting procedures within the RDW. 1

Authentication of municipal officials for the purposes of issuing driving licences The initial authentication of the applicant by the RA happens as part of the procedure that is used in the case where a municipality wishes to be considered for secured data

39

exchange and access to the register of licences. The establishment of the identity and authenticity of the applicant occurs based 011 a copy of the identity document, a passport photo and signature by an authorised person and the certificate holder himself. An authorised person is one who may give approval for application for a certificate. In the case of a certificate for an ABR, the authorised person is the mayor of the municipality concerned. In the case of a certificate for an RIJA, the authorised person is an ABR from the municipality concerned.

3.2.3

2

Authentication of businesses for the purposes of access to RDW services The initial authentication of the applicant by the RA happens as part of the procedure that is used in the case where a business wishes to be considered for RDW recognition. The establïshment of the identity and authenticity of the applicant occurs based on registration with the Chamber of Commerce and a visit to the business by an RDW business inspector.

3

Authentication of organisations for the purposes of a secured connection with the RDW The initial authentication of the applicant by the RA happens as part of the procedure that is used in the case where an organisation wishes to be considered for a secured connection with the RDW. The establishment of the identity and authenticity of the applicant occurs based mi the characteristics of the request and assessment of the type of organisation. These organisations can opt for a certificate on a smartcard, with whïch a service certificate can be downloaded via self-service, or for a service certificate on CD-rom.

4

Authentication of applicants internal to the RDW The authefltication of applicants for certificates which are issued to RDW staff takes place based on an instruction issued by an authorised person (manager or deputy).

Authentication of natura! persons

Certificates are issued to natural persons, providing they are cofitracted as staff to a Netherlands municipality or the RDW. 3.2.4

Non-vertjied certtficate holder information

The certificate holder declares the information provided by him to the RDW to be the truth. 3.2.5

Vatidation of the authority

The RA checks whether the person or orgaflisation that requests a certificate himself/itself, or who/which gives permission to apply for a certificate, is authorised to do so. This means in the case of a certificate for an ABR that the authorised person really is the mayor of the municipality concerned. 1fl the case of a certificate for an RIJA, it is determined that the authorised person really is recognised as an ABR from the municipality concerned. 1f the case concerns a recognised business, insurance company or an authorised representative, this must be registered as a recognifion holder or business customer of the RDW. For any other organisation, it must comply with the conditions stipulated by the RDW, as laid down in the procedures of the organisational unit concerned. For RDW staff, the authorised person is the team manager or head of the inspection station or someone deputised by the said persons.

40

3.2.6

Criteria for interoperation

Not applicable.

3.3

Identification and authentication for replacement of a certificate

3.3.1

Identification and autltenücation for rotttiite reptaceinent

Replacement of a certificate means the generation of a new key pair and certificate prior to the expiry of a certificate’s validity period. For certificates for municipal officials and organisations that operate self-service, it applies that: Without prejudice to the certificate holder’s own responsibility to apply in good time for a new certificate, the RDW CA warns the certificate holder in good time prior to the expiry of the existing certificate’ s validity period, so that the certificate holder can replace the certificate according to the procedure for initial registration (see section 3.2). In the case of certificates for (recognised) businesses, insurance companies, authorised representatives or organisations that apply for a service certificate on CD-rom, it applies that: The RDW CA replaces the certificate in good time prior to the expiry of the existing certificate’s validity period, without informing the certificate holder of this, other than by sending the new certificate. The CA will only replace certificates, if at the time of replacement, the end entities stil comply with the requirements imposed on them by the RDW, as described in sections 3.2.2 and 3.2.3. The replacement process features a check procedure for this. 3.3.2

Identification and authentication for reptacernent after withdrawat

Replacement of a certificate after withdrawal means the generation of a new key pair and certificate after the certificate is withdrawn. The RDW may withdraw a certificate in the context of the supervision of processing of data in the register, supervision of the implementation of the legal regulation(s), in the context of checldng on the legality of the access to registers managed by the RDW by or pursuant to the law, or for procedural and/or technical reasons. Any replacement will then occur according to the initial registration procedure (see section 3.2). Withdrawal on the certificate holder’s request may be followed by replacement. This replacement will occur according to the initial registration procedure.

3.4

Identification and authentication for withdrawal request 1. The RDW may withdraw a certificate in the context of the supervision of processing data in the register, or of the implementation of the legal regulation(s). 2. The RDW may withdraw a certificate in the case where an end entity no longer complies with the legal regulations with regard to the requirements and conditions imposed on him by the RDW, or for procedural and/or technical reasons. 3. The RDW may withdraw a certificate in the context of the intemal procedures as defined for certificates that come under the administration regulation(s). 4. An end entity may also submit a request itself for the withdrawal of its certificate, for example if its private key has been compromised. 5. Requests for withdrawal must always be submitted to the RA in writing, by fax or e-mail.

41

4.

Operational requirements for the certificate life-cycle

4.1

Application for certificate An applicant must submit an application to obtain a certificate to the responsible RA.

4.1.1

Possibte applicants for a certtficate

An applicatïon for a certificate may be submitted by: a municipal official, whereby approval must always be provided by an authorised person within the municipality concerned. an organisation that is recognised by the RDW or is nominated in another way as dient of the RDW, which requires access to RDW applications. an organisation nominated as dient of the RDW that wishes to set up a secured connection with the RDW. an RDW staff member. The issue of certificates to RDW staff is laid down in internal procedures. -

-

-

-

4.1.2

Registration process and responsibitities

A received application is assessed and registered by the RA.

4.2

Processing of certificate application

4.2.1

Implementation of identtjïcation and authentication functions

The RA assesses whether the application has been fully completed, and if applicable, whether it has been submitted with an authorised person’ s approval. 4.2.2

Approval or rejection of the certrficate apptication

Upon approval of the application, it will be dealt with further by the CA. 1f it is rejected, the RA will return the application together with an explanatory letter. 4.2.3

Time to process the certtficate apptication

An application for a certificate will be dealt with within six working days. 1f this proves to be impossible, the applicant will be informed of the fact by the RA.

4.3 4.3.1

Certificate issue CA activities in certtflcate issue

As part of the certificate issue for end entities, a public/private key pair is generated, after which a certificate is produced based on the public key and the entity’ s application details. The time when the Issuing CA creates a certificate applies as the date and time of issue of the certificate and is apparent from the issue process log files. After the generation of the certificate the Issuing CA issues it. The issuance takes place by recording the certificate and generated public/private key pair on a CD-rom or smartcard or in a pfx file made available online. The key pair is generated by a Hardware Security Module (HSM); the private key is exported from this and stored temporarily in a PKCS#12. The CD-rom, smartcard or pfx file is protected with a PIN code which is generated after recording the certificate and key pair.

42

In the case of an ABR, the identity is established prior to issue of the smartcard, using what is known as a ‘face-to-face check’. In the case of an RIJA, the smartcard is sent by post to the ABR. The ABR is responsible for ensunng that the smartcard provided to him is issued to the correct certificate holder, as stated on the said smartcard. To this end, the ABR will have to satisfy himself of the identity of the certificate holder, before issue of the smartcard. In the case of an organisation that is recognised by the RDW, the CD-rom with the dient certificate or the service certificate on it is sent by post to the registered applicant. When the organisation wishes to be able to download the service certificate itself, the smartcard necessary for this is sent by post to the registered applicant.

4.4 4.4.1

Certificate acceptance Certificate acceptance

The applicant receives the certificate that is recorded on a smartcard or CD-rom. During application for the smartcard, the applicant has already declared his assent to the user conditions that are applicable to the use of the certificate. The said user conditions are available via the RDW’ s website. The private key on the smartcard is protected with an initial PIN code. Before the smartcard is received, the applicant receives the initial PIN code. for a certificate on a smartcard, before the first use, the initial PIN code must be altered by the certificate holder. The private key on the CD rom is protected with an installation PEN code. The installation PEN code is sent to the applicant one day after the CD-rom is dispatched. The private key of the service certificate that is downloaded is protected by a PIN code selected by the applicant himself. 4.4.2

Publication of the certzjïcate by the €A

Issued certificates will not be published by the CA. 4.4.3

Nottflcation to other entities of issue of certificate by the CA

The CA will not inform other entities of the certificate issue.

4.5 4.5.1

Key pair and use of certificate Certtficate holder’s private key and tise of certificate

The certificate holder ensures an adequate protection of his certificate with private key and its associated PEN code. The certificate holder will only use the certificate and the associated key pair for the purpose as described in section 1.4 (applicability).

4.6

Certificate reissue

4.6.1

Reasons for certtjïcate reissue

No reissue of certificates will occur. 4.6.2

Possibte applicants for certification of a new public key

Not applicable.

43

4.6.3

Processing requests for certtjïcate reissue


Nottjïcation of certtjïcate reisstte to end entity


Acceptance of a reisstted certtjïcate

Not applïcable. 4.6.6

Pubtication of the reisstced cerhficate by the CA


Nottfication to other entities of issue of new certijicate by tite CA

Not applicable.

4.7

Certificate replacement

4.7.1

Reasons for certtjïcate reptacernent

Replacement may happen due to alteration of certificate details, the approaching end of the validity, or when the certificate or PIN code have been mislaid or not received. 4.7.2

Possibte appticants for reptacernent

An application for replacement of a certificate may be submitted by the certificate holder himself (in the case of certificate holder 2 or 3 in section 3.2.2) or by the authorised representative of a certificate holder (in the case of certificate holder 1 or 4 in section 3.2.2). 4.7.3

Processing apptications for certzficate reptacernent

The processing of a request for replacement of a certificate will happen in the same way as the processing of a first request for a certificate (see section 3.2). This means that the RA will evaluate and record the application for replacement, and that the Issuing CA will issue the replacement certificate. 4.7.4

Notijïcation of issue of new certtjïcate to end entity

The certificate holder will be informed of the issue of the new certificate through the receipt of the said certificate. 4.7.5

Acceptance of a reptacement certtjïcate

See section 4.4.1. 4.7.6

Pttbtication of the reptacernent certificate by the CA

Issued certificates will not be published by the CA. 4.7.7

Nottfication to other entities of issue of new certificate by the CA

The CA will not inform other entities of the certificate issue.

4.8

Certificate modification

4.8.1

Reasons for certtjïcate inodification

1f the contents of a certificate andlor information relevant to the contents of the certificate do not or no longer conespond with reality (for example due to a name change), the certificate holder or

44

the organisation responsible for the said certificate holder must notify this to the RA by means of submitting a request for replacement of the certificate. It is the certificate holder’s responsibility to inform the RA of this. For an aheration to the information, the entire certificate will be replaced; there is therefore no question of modifying the existing certificate. 4.8.2

Possible appticants for modification to the certificate


Processing apptications for certtficate 1?todtjïcatiolz


Notification of issue of new certzjïcate to end entity


Acceptaitce of a modtfled certificate


Pttbtication of the modijïed certificate by the CA


Nottfication to other entities of issite of new cerüjïcate by tite CA

Not applicable.

4.9

Certificate withdrawal and suspension The CA is responsible for the withdrawal of certificates. Withdrawal takes place by the Issuing CA adding the withdrawn certificate to the CRL. After withdrawal of the certificate, the certificate holder is informed of this. Suspension is not applicable.

4.9.1

Reasons for withdrawat

Valid reasons for withdrawing a certificate are: 1. Compromisation or loss of the PIN code which in combination with the private key provides access to the RDW applications or a connection with the RDW. After being compromised, the use of the private key must be immediately and permanently stopped. 2. By request of the certificate holder: due to loss of or damage to the certificate carrier or blockage of the PIN code. 3. By the organisation responsible for the certificate holder, if the certificate holder is no longer allowed to represent the organisation, e.g. after a change of post or when leaving employment. 4. 1f the end entity no longer complies with the requirements and conditions imposed on him by the RDW, or for procedural and/or technical reasons. 5. 1f the certificate holder does not fulfil his obligations as described in this CPS; withdrawal in this case only takes place after the certificate holder has been given the chance to make known his view of the matter. The certificate holder is liable in every case for any damage that arises due to tardy withdrawal or replacement of a certificate, regardless of whether the necessity to withdraw or replace can be attributed to him.

45

4.9.2

Possible appticants for withdra wal of a certificate

The following entities are authorised to submit a request for withdrawal: 1. theCA, 2. theRA, 3. the certificate holder, 4. the organisation or a deputised person responsible for a certificate holder. 4.9.3

Procedure for a withdra wal apptication

The entity that submits a request for the withdrawal of a certificate can only do this by means of submitting a written, faxed or e-mailed request to the relevant RDW RA. In the case of certificate holders 1 or 4 from section 3.2.2, it applies that, for a request for withdrawal of their own certificate, the RA will verify the written request for withdrawal by ringing the certificate holder back on the phone number known to the RA. A certificate holder who is in possession of a smartcard for self-service is himself responsible for the withdrawal of a certificate obtained via download. The RA promptly confirms an honoured request for withdrawal of a certificate to the CA and requests it to notify the withdrawal in the CRL with all due speed. The notification of withdrawal in the CRL indicates the date and time of withdrawal of the certificate. 4.9.4

Validity period of a withdrawat reqitest

The RDW will handle a withdrawal request as soon as possible after the request is received. In the case of possible compromise, the RDW will handle a withdrawal request immediately upon receipt of the request (on working days). 4.9.5

Time within which tite C4 must process a reqitestfor withdra wat

The CA will process a request for withdrawal as quickly as possible, in any case no later than one working day after receipt of the request. 4.9.6

Requirements for ontine checking of withdrawat for retying party

A certificate issued by the Issuing CA on smartcard contains a CRL Distribution Point (CDP). 4.9.7

CRL issuefrequency

The CRL is updated after each withdrawal and distributed every hour. 4.9.8

Maxünuin potentiat for CRL

The CRL is not tied to a maximum number. 4.9.9

Ontine withdrawal


Requirements for ontine checking of withdrawat

The server that makes the CRL available is implemented at least in duplicate at two different locations. This server is available 7 days per week, 24 hours a day. The CRL may be consulted via: http://wwwctiensten.rdw.n1/cr1Jrdwissuiiigca 1 cr1 4.9.11

Otherformsforpublishing withdra wat status

Not applicable.

46

4.9.12

Special requirements for reisstte after coinpromisatioit


Reasons for sttspeitsion

Suspension of the certificate is not possible. 4.9.14

Possibte applicants for suspeizsioit


Proceditre for a suspension apptication


Restrictions on the sttspelzsion period

Not applicable.

4.10

Certificate status services

4.10.1

Operationat cltaracteristics

A certificate’s status may only be called up in the case of withdrawal. No publication of the status takes place other than via the CRL. 4.10.2

Availabitity of the service

See section 4.9.10. 4.10.3

Operationatproperties

Not applicable.

4.11

End of registration as certificate holder After withdrawal of the certificate, no relationship with the Issuing CA as certificate holder exists any longer.

4.12

Key escrow and recovery

4.12.1

Key escrow and recovery policy

No escrowing of private keys of the CA or end entities takes place. 4.12.2

Session key encapsutation and recoverypolicy and practice

Not applicable.

47

5

General, pliysical and operational administration measures

5.1

Physical administration measures The RDW ensures adequate physical, procedural and personnel-related information protection to restrict the risks of loss or compromise of or damage to essential components of the CA service provision to a minimum. This applies in particular to the Issuing CA’s environment, where the certificates are issued. The physical, procedural and personnel-related information protection measures are described in RDW internal procedures. These are audited at least once a year. Relevant findings will be published in the RDW annual report. Physical access is only permitted to persons who are responsible for creating certificates. These persons are employed at the RDW and possess a certificate to enable the issue of certificates to end entities. The place in which the certificates are created is locked. The server(s) on which the certificate management system and the Issuing CA run are in a physically-secured computer room provided with emergency power, air conditioning, fire alarm, fire extinguisher system etc. The RDW Root CA is offline in an intruder-resistant safe in a place with extremely limited access. The smartcards that are necessary for the administration of the CAs are linked to individuals. The backup of the Issuing CA is encrypted and is stored at two external RDW locations. The backup of the RDW Root CA is stored in encrypted form at an external location in a safe in a secured place.

5.2

Procedural administration measures The roles below are distinguished: 1. Owner of the RDW PKI 2. PKI administrator, charged with the technical administration of the PKI environment, inciuding the Certificate Management System. 3. CA smartcard holders, of the smartcards over which the key material of the RDW Root CA and Issuing CA is split (split key) 4. Security Manager 5. IT auditor; carries Out IT audits on the RDW PKI by order of the owner or management 6. Staff charged with the functional administration of the certificate management system inciuding the assignment of authorisations 7. Quality staff charged with the necessary operational checks. To carry out the actions below, at least three people are necessary, each of whom needs his own smartcard. This concerns: 1. setting up an underlying Issuing CA and having it signed by the RDW Root CA 2. starting of the PKI services (booting) 3. restoring the security world from a backup 4. loading of the key material from the admin smartcards ïnto a (new) HSM. For all the administration actions not listed above, at least two people are necessary (dual control), of whom one is a PKI administrator and one a witness. An administrator certificate is necessary to

4$

carry out these actions. This certificate is stored on a FIPS 140-2 level 3 USB token. The procedure for use of this administrator certificate ensures that two people are always present. The foÏlowing roles are distinguished in the certificate management system: 1. PKI administrator, charged with the technical administration of the certificate management system. 2. RA staff member, responsible for evaluating applications, registering organisational and/or personal information, creating requests for certificate issue and certificate withdrawal. 3. CA staff member, responsible for the issue and withdrawal of certificates and the sending of certificates and P1N codes. 4. Functional administrator, responsible for the functional administration of the certificate management system. 5. Operator, responsible for creating CD-roms with certificates. 6. Helpdesk staff member, has access to consult data 011 certificate holders and withdrawn certificates.

5.3

Personnel administration measures All staff who fili a role specified in section 5.2 have sufficient knowledge and experience to carry out adequately the tasks assigned to them and have signed a confidentiality agreement. It is ensured via contracts and supervision that the above also applies to the personnel of suppliers involved.

5.4

Audit logging procedures

5.4.1

Events that are togged The following events are logged within the RDW PKI, either automatically or manually: • Concerning the certificate life-cycle application for a certificate the information against which the end entity was authenticated modification of a certificate holder’s personal information the generation of a public/private key pair for an end entity the generation of a certificate the issue of a certificate the withdrawal of certificates the generation of CRLs • Concerning the administration of the CA keys within the RDW PKI key generation, backup, recovery and deletion security-relevant occurrences regarding the HSM used, such as initialisation and deletion. • Security-relevant occurrences on CA and RA systems physical access to CA systems successful and unsuccessful login attempts PKI- or system-relevant occurrences system startup, failure or shutdown • Security-relevant occurrences on the certificate management system successful and denied login attempts addition of users and addition and alteration of authorisations and all security-relevant parameters and settings. -

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

49

Events are accompanied by elements from which the following may be deduced: date and time of event identity of the source that caused the event identity of the source that logged the event.

-

-

-

The logs are retained for two years. Audit logs are protected against unauthorised access, alteration, removal or deletion by making use of a combination of physical and logical access control. A backup is made of the digital audit logs. The RDW does not oblige itself to make notification about logged events to the end entity or organisation to which it belongs. Notification will only occur if the RDW considers it necessary. In the context of the evaluation of the audit logs, it is determined whether there are weaknesses in the security of the RDW PKI environment. (Possible) weaknesses spotted are followed up. These evaluations and the possible weaknesses observed will be recorded.

5.5

Archiving of documents An overview of the events that are archived is described in the RDW’s internal procedures; these are in conformity with the relevant legislation and regulations, including the Dutch Public Records Act 1995. Measures are taken that ensure that the archive is stored in such a way that loss is effectively excluded. The RDW does not oblige itself to make notification about archiving to the end entity or organisation to which it belongs. Notification will only occur if the RDW considers it necessary. All events as described in section 5.4.1 are proved with a time marking. All archived events are stored internally. The matters listed in section 5.4.1 are checked periodically for integrity. These checks take place annually in the context of the normal IT audit.

5.6

Distribution of RDW PKI keys The public keys that form part of the RDW PKI (trust certificates) are added to the carrier of the certificate when it is created. Section 3.3 is applicable to any change to the public keys. The RDW issues no certificates with a lifetime that is longer than that of either of the overlying CAs, namely the RDW Root CA or Issuing CA. This means that an occasion will arise when the certificates of the overlying CAs are still valid, but that no new end entity certificates can be issued. The RDW will ensure that the CA keys concerned are replaced in good time before the said occasion. The procedures about revocation and publication of CRLs concerning the replaced CAs remain in force during the remaining lifetime of the certificates of the said CAs.

5.7

Compromise of the private key and incident management The backup and recovery procedures in case of incident are part of the RDW’ s internal procedures as stipulated in the RDW incident plan. The RDW does not oblige itself to make notification about the said procedures to the end entity or organisation to which it belongs. Notification will only occur if the RDW considers it necessary.

50

The RDW bas taken adequate precautions to ensure effectively that if computers, software and/or data are corrupted, the service provision can be recovered within the agreements made. In the case of compromise of the private key of the RDW Root CA or the Issuing CA, the RDW will act to inform all entities within the RDW PKI as soon as possible. The end-user must then stop the use of the Issuing CA’s public key immediately and permanently. In the case of compromise or loss of an end entity’s private key, said entity must submit a reqtiest to withdraw the certificate to the RA as soon as possible. The procedures with respect to possible exceptions are described in RDW intemal procedures. The RDW does not oblige itself to make notification about the said procedures to the end entity or organisation to which it belongs. Notification will only occur if the RDW considers it necessary.

5.8

CA termination Upon termination of the Issuing CA’s activities, the said CA takes care of the following actions: 1. The Issuing CA informs the RDW Root CA of its intention to cease its activities as CA. 2. The CA informs all entities within the RDW PKI of its intention to cease its activities as Issuing CA, at least 60 working days in advance of the cessation. 3. All non-expired certificates issued by the Issuing CA are withdrawn according to the procedures specified in section 4.9. 4. The CA submits a request for withdrawal of the Issuing CA certificate to the RDW Root CA.

6

Technical security

6.1

Generation and installation of key pair

6.1.1

Key pair generation

1. 2.

6.1.2

The key pairs of the CAs within the RDW PKI are generated and stored within an HSM. The end entities’ key pairs are generated in an HSM and temporarily stored in a database as a PKCS#12 file. After the key pairs have been placed on the CD-rom or smartcard they are deleted from the database.

Suppty ofprivate key to end entity

See section 3.2.1. The private key is protected with an initial PIN code that will be sent by post to the end entity, either at least one day before the smartcard is sent, or at least one day after sending the CD-rom. The initial PIN code is not visible to and not reproducible for the RDW. 6.1.3

Suppty ofpublic key to CA

Not applicable. End entities do not have to send their public key to the CA.

51

6.1.4

Supply of CA ‘s public key to end entities

The CA’s public key is provided in the same way as the end entity’s private key. 6.1.5

Key lengths

See section 7.1. 6.1.6

Parameters for dle pitrposes of generation ofpublic keys and qttatity checking


Use ofpublic keys

The public key associated with an end entity’s certificate is only intended for the purposes as described in section 1.4.1. The purposes are recorded in the extension to the certificate.

6.2

Protection of private keys 1. General 1.1 The RDW Root CA and the Issuing CA ensure adequate protection of the private keys. 1.2 The generation, protection and possibly destruction of the CA private keys take place by means of an HSM, in conformity with FIPS 140-2 level 3. Access is only possible with the aid of the key pairs on at least two of eight smartcards. 1.3 The CA private keys are generated within the cryptographic module (HSM) in which they are used. Entry of a private key is only considered in the case of recovery. This takes place by making the encrypted contents of the HSM that must be recovered available to a new HSM, and reading them in. The private key never comes outside the HSM. For this, the PKI administrator and a witness and also at least three CA smartcard holders must be present. FIPS level 3 always remains guaranteed. 1.4 The CAs’ private keys are only destroyed upon termination of the service provision of the RDW Root CA. This takes place by initialising the HSMs and destroying all backups. A protocol for this will be drafted under supervision of a witness. 1.5 Administration of CAs’ private keys is only possible in the physical presence of at least three RDW PKI staff authorised for the purpose. See section 5.2. 1.6 No escrowing of private keys of the CA or end entities takes place. 1.7 A backup of CA private keys is made in encrypted form, and this can only be restored with the help of three CA smartcard holders and one PKI administrator. 2. End entity 2.1 The end entity is exclusively responsible for the protection of its private key, as this is stored on the certificate carrier, by means of a PIN code. The end entity’s private key can be used when the correct PIN code is entered. The end entity must keep the certificate carrier carefully and keep the PIN code secret. Loss, possible compromise of or damage to the certificate carrier or associated PIN code or termination of position must be notified immediately to the RA (see section 1.5.2). The PIN code is arbitrary, and consists for a certificate on a smartcard of five digits, for dient certificates 011 CD-rom of six digits, for download service certificates of 8 digits, and for service certificates on CD-rom of ten digits, which digits may be chosen to be between 0 and 9. 2.2 Destruction of an end entity’s private key can only be carried Out by the certificate holder himself, by actually destroying the CD-rom or smartcard. 2.3 No backup is made of end entities’ private keys. 2.4 End entities’ private keys are not stored in the cryptographic module, but on the CD-rom or smartcard for end entities.

52

6.3

Other aspects of key administration

6.3.1

Archiving pijblic keys

1. 2. 6.3.2

CAs’ public keys are archived. End entities’ public keys are archived.

Period of ttse of keys

1. 2. 3. 4.

The The The The

validity period of the RDW Root CA certificate is 15 years. validity period of the Issuing CA certificate is 15 years. validity period of an end entity’s certificate 011 a smartcard is 5 years. validity period of an end entity’ s certificate on a CD-rom or downloaded is 2 years.

6.4

Activation data

6.4.1

Generation and instattation

End entities’ private keys are protected with a P1N code on the PKCS#12 file and after placement on the CD-rom or smartcard by the PIN code of the said CD-rom or smartcard. Upon first use of the smartcard, end entities must protect their private keys with a PIN code they choose themselves. A downloaded service certificate must also be protected with a self-chosen PN code. 6.4.2

Protection of activation data

The PIN code that serves to protect the private key must be unique and non-predictable and of such a length that it is in proportion to the key that must be protected. The PIN code of certificates on smartcard must comprise live characters. The PIN code of dient certificates on CD-rom must comprise six characters. For downloaded service certificates, eight characters applies and for service certificates on CD-rom, ten characters. These characters may be: the digits 0 to 9. The initial PIN code associated with the CD-rom or smartcard for an end entity is printed solely on a PIN-mailer and sent to the certificate applicant separately from the CD-rom or smartcard.

6.5

Computer security measures The specific technical security measures are described in RDW internal procedures. Computer systems are set up and administered according to procedures that ensure that the required protection level is safeguarded.

6.6

Technical administration measures during the life-cycle OTAP, Change and Security management procedures ensure that during changes the stipulated protection level remains enforced.

53

6.7

Network security administration measures Security measures at network level ensure that access to the CA server is only possible for authorised protocols and oniy from explicitly authorised workpiaces and servers.

6.8

Time stamping Not applicable.

7.

Certificate, CRL and OCSP profile

7.1

Certificate profile

All certificates that are issued are X.509 version 3 certificates. These certificates contain the following fields: Contents of RDW Root CA certificate Version Path length Life time Key length Certificate signature algorithm Hash algorithm Key usage

Key usage extension Netscape certificate type Issuer Distinguished name Country (0) Organization (0) Location (L) Common Name (CN) Subject Country (0) Organization (0) Location (L) Organizational Unit (OU) Common Name (CN) CDP CRL Validity Renewal CPS

3 (is identical to X.509 version 3) no constraint 15 years 2048 shal RSA shal digital signature Certificate signing 0ff line CRL signing CRL signing critical -

NL RDW Groningen Self Signed NL RDW Groningen not used RDW Dienst Wegverkeer Root CA n.a. 18 months 12 months http:/www.diensten.rdw.nl/cps/RDWDienstWegverkeeroPS.pdf

Contents of RDW Issuing CA 1 certificate Version Path length Life time Key length Certificate signature algorithm Hash algorithm Key usage

3 (is identical to X.509 version 3) no constraint 15 years 2048 shal RSA shal digital signature Certificate signing 0ff line CRL signing

54

Key usage extension Netscape certificate type Issuer Distinguished name Country (0) Organization (0) Location (L) Common Name (CN) Subject Country (C) Organization (0) Location (L) Organizational Unit (OU) Common Name (CN) CDP CRL Validity Renewal CPS

CRL signing critical

NL RDW Groningen RDW Dienst Wegverkeer Root CA NL RDW Groningen not used RDW Issuing CA 1 http://www.diensten.rdw.nI/crl/RDWDienstWegverkeerRootCA.crl 7 days 1 hour http://www. diensten.rdw.nI/cps/RDWDienstWegverkeerCPS.pdf

Contents of RDW employee certificate on smartcard (RDW Internal Smartcard) 3 (is identical to X.509 version 3) Version no constraint Path Iength 5 years Life time 1024 Key Iength shal RSA Certificate signature algorithm shal Hash algorithm digital sig nature Key usage Key encipherment Data encipherment Key agreement critical Key usage extension SSL CA, S/MIME CA, Object signing CA Netscape certificate type Issuer Distinguished name NL Country (C) RDW Organization (0) Groningen Location (L) RDW issuing CA 1 Common Name (CN)* Subject NL Country (C) RDW Organization (0) Common Name (CN) Contents of end entity certificate Version Path Iength Life time Key length Certificate signature algorithm Hash algorithm Key usage

Key usage extension Netscape certificate type Issuer Distinguished name Country (C) Organization (0) Location (L) Common Name (CN)*

0fl

smartcard (RDW Smartcard) 3 (is identical to X.509 version 3) no constraint 5 years 1024 shal RSA shal digital signature Key encipherment Data encipherment Key agreement critica! SSL CA, S/MIME CA, Object signing CA NL RDW Groningen RDW Issuing CA 1

55

Subject Country (C) Organization (0) Common Name (CN) Serial Number

NL http:llwww.diensten.rdw.nI/crl/RDWIssuingCAl .crl

CDP CRL

Validity n.a. Renewaln.a.

Contents of dient certificate on CD-rom (RDW dient) Version 3 (is identical to X.509 version 3) Path length no constraint Life time 2 years Key Iength 1024 Certificate signature algorithm shal RSA Hash algorithm shal Key usage digital signature Key encipherment Data encipherment Key agreement Key usage extension critical Netscape certificate type SSL Client Authentication, S/MIME (aO) Issuer Distinguished name Country (C) NL Organization (0) RDW Location (L) Groningen RDW Issuing CA 1 Common Name (CN)* Subject Country (C) NL Organization (0) Common Name (CN) RDW Diensten -

Contents of end entity certificate Version Path Iength Life time Key Iength Certificate signature algorithm Hash algorithm Key usage

Key usage extension Netscape certificate type Issuer Distinguished name Country (C) Organization (0) Location (L) Common Name (CN)* Subject Country (C) Organization (0) Organizational Unit (OU) Common Name (CN) Serial Number

011

smartcard for self-service (SeifService Smartcard) 3 (is identical to X.509 version 3) no constraint 5 years 1024 shal RSA shal digital signature Key encipherment Data encipherment Key agreement critical SSL CA, S/MIME CA, Object signing CA NL RDW Groningen RDW Issuing CA 1 NL <Surname>

56

Contents of end entity service certificate on CD-rom (RDW Services) Version Path length Life time Key Iength Certificate signature algorithm Hash algorithm Key usage

Key usage extension Netscape certificate type Issuer Distinguished name Country (0) Organization (0) Location (L) Common Name (CN)* Subject Country (0) Organization (0) Organizational Unit (OU) Common name (CN) Serial Number

7.1.1

3 (is identical to X.509 version 3) no constraint 2 years 1024 shal RSA shal digital signature Key encipherment Data encipherment critical SSL Client Authentication, S/MIME (aO) NL RDW Groningen RDW Issuing CA 1 NL

Version numbers

The CA generates X.509 version 3 certificates. 7.1.2

Certificate extensions

The certificates within the RDW PKI contain X.509v3 extensions. See section 7.1. 7.1.3

Atgorithrn object idenüflers


Namingforms

See section 3.1 et seq. 7.1.5

7.1.6

Naming restrictions See section 3.1 et seq. Certtflcate object identification poticy


Use ofpoticy on extension resfrictions

This extension is not used. 7.1.8

Poticy on syntax and lltealzing restrictions


Iinptication for deating with criticat certificate poticy extension

Not applicable.

7.2 7.2.1

CRL profile CRL version number

The Certificate Revocation List is published in X.509 v3 format.

57

7.2.2

CRL tutd CRL entry extensions

Not applicable.

7.3

OCSP profile Not applicable.

$

Compliance audit and other analyses

8.1

Frequency and reasons for audit An audit takes place annually, in which it is investigated whether the stipulations in this CPS are fulfilled by the CA and RA.

8.2

Identity/Quality of auditor The audit will be carried Out by an independent IT auditor (RE).

8.3

Relationship between auditor and subject of audit The auditor must be completely independent and not be connected in any way with the party that is subject to the audit.

8.4

Subjects of audit Compliance with this CPS and the associated procedures and techniques during setup, existence and operation are the subject of audit.

8.5

Actions motivated by deficiency 1f defects or deficiencies are established motivated by the audit, the RDW must take action as quickly as possible to remedy the said defects or deficiencies. After remedy of the defects or deficiencies has been done, another audit will take place.

8.6

Communication of resuits The relevant results of the audit may be found in the RDW’ s annual report.

9

Other commercial and legal matters

9.1

Costs A protection charge will be levied annually to maintain the protection of the online connection. This charge may be found in the Netherlands Government Gazette in the Decree on RDW Charges (Tarievenbestuit RDW.

58

9.2

Financi al responsibulity

9.2.1

Indeinnity by retying partjes


Trttsted retationships


Administrative procedures

Not applicable.

9.3

Confidentiality

9.3.1

Confidentiat information

Confidential information is taken to mean: personal information 1.1 1.2 correspondence with end entities private keys and their associated PIN codes 1.3 information about the certificate holder as recorded by the RDW 1.4 commercial or manufacturing data 1.5 reasons for withdrawing a certificate 1.6 1.7. auditlogs detailed documentation concerning the administration of the RDW PKI 1.8 audit reports from internal or external auditors. 1.9 9.3.2

Non-confidentiat information

All other information is considered to be non-confidential information. 9.3.3

Responsibility to protect confidentiat information

Confidential information is not released, unless there is a legal obligation to do so.

9.4

Privacy of personal information

9.4.1

Privacy plan

The processing of personal information by the RA and Issuing CA happens in accordance witli the Dutch Personal Data Protection Act. 9.4.2

Information ctasstfled as private

Certificate holders who wish to consult their organisational or personal details must submit an application to do so to the RDW. This request must be submitted to the RA in writing. 9.4.3

Information not classifled asprivate

All information not related to certifïcate holders’ organisational or personal information. 9.4.4

Responsibitity to protectprivate informatioiz

The RDW is responsible for the protection of private information.

59

9.4.5

Nottjïcation and approval of tite itse ofprivate information

The RDW retains the right to proceed to reveal confidential information based on other circumstances which in its opinion provide motivation to do so. Before proceeding to release information, the parties concerned will be given the opportunity to state their opiflion on the matter. 9.4.6

Otiter reasons to release information

Not applicable.

9.5

Intellectual property riglits 1. Copyright with respect to this CPS lodges with the RDW. 2. The CA is empowered with regard to the publication, duplication or any other administrative activity with respect to the certificates it has issued. 3. Within the RDW PKI, all rights which can possibly be vested in key pairs lodge with the CA.

9.6

Representation and guarantee

9.6.1

CA representation and gitarantees

The CA guarantees to carry Out its service provision in accordance with this CPS. The CA declares that the information in the certificate is correct, insofar as this is known to the CA. 9.6.2

RA representation and gzzarantees

The RA and organisational units acting on behalf of the RA guarantee to carry out their service provision in accordance with this CPS. The RA declares that no certificate will be issued without an application for it. The RA performs the necessary validation and authentication procedures and will in this reproduce correctly the information in the certificate application which the RA received from the applicant. 9.6.3

End entity representation and guarantees

The end entity must complete the application form truthfully, use the smartcard strictly personally, and the CD-rom only for the requesting organisation. The certificate holder is liable for damage resulting from actions attributable to lijm in conflict with his obligations as described in section 1.4. 9.6.4

Relying party representation and gtcarantees

As relying party, the RDW is obliged to investigate whether an end entity certificate is valid, by: • Verification of the digital signature on the end certificate and of the certificates in the certification path through which the end certificate was issued. • Verification that the end certificate has not been withdrawn by making use of a valid CRL as issued by the RDW; see section 2.3. Through the use of an RDW end entity certificate, the relying party accepts the limitation of liability and guarantees as described in this CPS, as well as the stipulations in the user conditions and the other information provided when the certificate is issued. The relying party trusts that the information that is inciuded in the certificate is correct. 9.6.5

Representation and guarantees of other partjes involved

Not applicable.

60

9.7

Guarantee disclaimers No explicit guarantees are given.

9.8

Exclusion of liability The RDW is not liable for damage arising directly or indirectly from the use of an RDW certificate for purposes other than those for which it was issued (see section 1.4). The RDW is not liable for delays or deficiencies in the execution of activities which may be attributed to (technical) faults such as transmission errors, equipment or system software failure, defects in the equipment or software, intent such as fraud, ïllegal use of software, sabotage, theft of data or operating faults by third parties, third party enors with resultant network failure, power failure, fire, lightning strike, significant water damage, a break in a telephone cable, acts of war or natural disasters or further, in general, causes that cannot reasonably be considered as a concern of the RDW.

9.9

Compensation In the case that damage is suffered by a third party, it will be determined based on the stipulations in this CPS who should be held responsible for it. 1f this is not possible, the authorised court in Groningen will pronounce on the matter.

9.10

Validity period and termination

9.10.1

Vatidity period


Terinination

After the validity period expires, the certificate will be terminated. The certificate holder will be informed timeously of the expiry of the validity period. 9.10.3

Effect of terinination and continttance

When an end entity’ s certificate is terminated, the said entity has the opportunity of continuance as a certificate holder by means of applying for a replacement certificate. 9.11

Individual explanation and communication with partjes involved 1f an individual explanation is required, contact can be made with the CA (see section 1.5).

9.12

Amendments

9.12.1

Ainendrn eitt procedure

This CPS is published by and under the responsibility of the RDW’s managing director. The procedure for amendments to and approvals of the CPS is as follows: 1. Change proposals may be submitted by the RDW organisational units to which the implementation of the CA or RA duties according to this CPS have been assigned or by organisational units for the purposes of which the Issuing CA is used; 2. The managing director is responsible for dealing with the proposals. In this he may seek advice from experts on matters of detail, inciuding in the technical, procedural, commercial and legal fields. The managing director will ultimately decide whether a change proposal is implemented; and 3. 1f the proposal is approved, the managing director will have this CPS amended. 1f prior notification to the certificate holders is necessary before entry into force, the managing

61

director will equally carry the responsibility for this. The amendment will enter into force five working days after the new CPS has been made known by the RDW through publication on the RDW Internet site. 9.12.2

Nottflcation mechanisrn and period

1f stipulations in this CPS are amended such that the changes affect the rights, obligations or authorities of the entities within the PKI, the RDW will publish the said changes and make them known on the RDW’s Intemet site. 9.12.3

Circumstances in which Object Identifier bas to be changed

As regards amendments to stipulations in the CPS that have no material consequences for entities within the PKI, the RDW is not obliged to make the said amendments known to the entities within its PKI. The RDW will publish the revised CPS on its website. 9.13

Settiement of disputes All disputes arising from or having connection with the CPS and/or user conditions will be settied by the competent court in Groningen. Before taking a dispute to the competent court, parties will attempt to achieve a solution together in proper consultation.

9.14

Applicable law Dutch law is applicable to the stipulations in this CPS and to the RDW user conditions. 1f one of the stipulations in this CPS should prove to be in conflict with the law, the other stipulations in this CPS shall remain in full force, insofar as the said stipulations, taking into account the content and purpose of the first-mentioned stipulation, are not indissolubly linked to the first-mentioned stipulation.

9.15

Position within existing legislation All parties concerned within the RDW PKI must obey specific legislation with respect to PKIs as this is inciuded in Dutch law.

62

10.

Formele goedkeuringfFormal approval

Akkoord direci

Datum/Date:

RDW Managing director:

2So3. -2o/t

63

11.

Bijlagen/Appendices.

11.1

Gebruikte afkortingen / Abbreviations used CA Certification Authority CPS Certification Practice Statement CRL Certificate Revocation List Identifier 1V IETF Internet Engineering Task Force ITU International Telecommunication Union HTTPS Hypertext Transfer Protocol over SSL HSM Hardware Security Module PKCS Public-Key Cryptography Standards PKIX Public-Key Infrastructure X.509 Public Key Infrastructure PKI RA Registration Authority RFC Request for Comment SSL/TLS Secure Sockets Layer / Transport Layer Security

11.2

Verklarende woordenhijst / Glossary

Nederlands_____________ Aanvrager Een entiteit die een certificaat aanvraagt bij een RA.

English Applfcant An entity that applies to an RA for a certificate.

ABR Autorisatie Bevoegd medewerker Rijbewijzen, certificaathouder die bevoegd is om andere medewerkers die in het bezit zijn van een ABR of RIJA smartcard te autoriseren voor toegang tot RDW systemen.

ABR Dutch abbreviation for Authorisation-Authorised Driving Licence Unit staff member, a certificate holder with the authority to authorise other staff members who are in possession of an ABR or RIJA smartcard to access RDW systems.

Audit Een procedure uitgevoerd door een auditor waarbij wordt nagegaan of de bepalingen in de CPS worden nageleefd.

Audit A procedure carried Out by an auditor in which it is investigated whether the stipulations in the CPS are complied with.

Authenticatie Het proces om de identiteit van een eindentiteit of de integriteit van bepaalde informatie te bevestigen.

Authentication The process of confirming the identity of an end entity or the integrity of certain information.

Autorisatie De bevoegdheid die wordt verleend om toegang te krijgen tot de RDW informatiesystemen.

Authorisation The granting of authority to obtain access to the RDW information systems.

64

Beheersregeling(en) Regelingen met een intern karakter in het kader van de uitvoering van wettelijke regelingen.

Administration regulations Regulations of an internal character in the context of the implementation of statutory regulations.

Certificaat (digitaal certificaat) Een publieke sleutel certificaat dat de publieke sleutel van een entiteit bindt aan de identiteitvan deze entiteit en dat de geldigheid van de corresponderende privésleutel aanduidt. Een certificaat biedt waarborgen omtrent de identiteit van eindentiteiten door het gebruik van een gegenereerd sleutelpaar bestaande uit een privésleutel en een publieke sleutel. Deze gewaarborgde identiteit wordt onder meer gebruikt bij het vaststellen van bevoegdheden bij elektronische (data)communicatie.

Certificate (digital certificate) A public key certificate that links an entity’s public key to the identity of the said entity and that demonstrates the validity of the corresponding private key. A certificate provides guarantees concerning the identity of end entities through the use of a generated key pair consisting of a private and a public key. This guaranteed identity is used for purposes including the establishment of authorities in electronic (data) communication.

Certification Authority (CA) Een vertrouwde autoriteit die certificaten creëert en uitgeeft. Certificaat extensie Extensie-velden in X.509 versie 3 certificaten. Certificaathouder De eindentiteit, CA of RA die in het bezit is van de privésleutel die correspondeert met een publieke sleutel. Certificaat keten Een geordende lijst van certificaten die nodig zijn om een certificaat te valideren. Een certificaat keten bestaat uit certificaten van eindentiteiten, certificaten van CA’s die de certificaten van eindentiteiten hebben ondertekend en certificaten van CA’s die de certificaten van onderliggende CA’s hebben ondertekend. Certificaat management Certificaat management omvat onder andere de opslag, verspreiding, publicatie en intrekking van certificaten. Certificate Revocation List (CRL) Een door de CA getekende lijst met ingetrokken certificaten. Certificate Policy (CP) Een gedetailleerde beschrijving binnen welke gebruiksgebieden, voor welke toepassingen en

Certification Authority (CA) A trusted authority which creates and issues certificates. Certificate extension Extension fields in X.509 version 3 certificates. Certificate holder The end entity, CA or RA who is in possession of the private key which corresponds with a public key. Certificate chain An ordered list of certificates which are necessary to validate a certificate. A certificate chain (also known as a certification path) consists of end entities’ certificates, certificates of CAs that have signed the end entities’ certificates, and certificates of CAs that have signed the certificates of underlying CAs. Certificate management Certificate management inciudes the storage, distribution, publication and withdrawal of certificates. Certificate Revocation List (CRL) A list of withdrawn certificates signed by the CA. Certificate Policy (CP) A detailed description of within which usage fields, for what applications and for what objectives certificates are issued.

65

voor welke doeleinden certificaten worden uitgegeven. Certificatie Het proces van certificaatuitgifte door een CA. Certification Practice Statement (CPS) Een gedetailleerde beschrijving van de praktijken die de CA hanteert bij het uitgeven van certificaten. Client systeem Dit is het systeem van de eindentiteit die aanvragen doet bij de webserver. Compromittering Het verlies van de vertrouweljkheid van de privésleutel; bijvoorbeeld indien een onbevoegde persoon een kopie van de sleutel verkrijgt. Distinguished name Een set van gegevens die een eindentiteit identificeren. Eindentiteit Een certificaathouder of een aanvrager, die geen CA of RA is.

Gebruikersvoorwaarden Document met de verplichtingen voor de eindentiteit die als geaccepteerd wordt beschouwd zodra het certificaat wordt aangevraagd. Genereren van een sleutelpaar Het proces van het creëren van een publieke en privésleutel. Identificatie Het proces ter bevestiging van de identiteit van een eindentiteit. Object identifier Een uniek nummer dat gekoppeld kan worden aan dit CP$. Pincode Een unieke code die de aanvrager in staat stelt het door hem aangevraagde certificaat te activeren.

Certification The process of certificate issuance by a CA. Certification Practice Statement (CPS) A detailed description of the practices that the CA employs in the issue of certificates.

Client system This is the end entity’ s system which makes applications to the web server. Compromisation The loss of the confidentiality of the private key; for example if an unauthorised person obtains a copy of the key. Distinguished name A set of data to identify an end entity.

End entity A certificate holder or an applicant who/which is not a CA or RA.

User conditions Document with the obligations for the end entity which are considered as accepted when the certificate is applied for. Key Pair generation The process of creating a public and a private key. Identification The process of verifying an end entity’ s identity.

Object identifier A unique number that can be linked to this CPS.

PIN code A unique code that makes it possible for an applicant to activate the certificate he has applied for.

66

Privésleutel Een door middel van een wiskundig programma gegenereerde code die door de certificaathouder geheim wordt gehouden. Public Key Infrastructure (PKI) Het geheel van hardware, software, personen, procedures en beleid die noodzakelijk zijn voor het creëren, managen, opslaan, distribueren en herroepen van certificaten gebaseerd op public key cryptografie. Publieke sleutel Een door middel van een wiskundig programma gegenereerde code die openbaar is en die is opgenomen in het certificaat. Registration Authority (Rk) Een entiteit die verantwoordelijk is voor de identificatie en authenticatie van eindentiteiten. Een RA ondertekent geen certificaten en geeft geen certificaten uit. Relying party Een persoon of Organisatie die handelt op basis van vertrouwen in een certificaat en op basis daarvan toegang verleent tot de online RDW dienstverlening. Repository Een online database met relevante informatie met betrekking tot de PKI. In een repository kunnen de CRL of een lijst met uitgegeven certificaten worden gepubliceerd. Root CA De CA die het eerste certificaat in een certificaat keten uitgeeft. RIJA Medewerker RIJbewijs Afgifte, wordt door de ABR geautoriseerd voor het verkrijgen van toegang tot RDW systemen ten behoeve van afgifte van rijbewijzen. Service certificaat Een RDW-certificaat gekoppeld aan een server om zekerheid te geven omtrent de identiteit van de server van de wederpartij.

Private key A code generated by a mathematical program that is kept secret by the certificate holder.

Public Key Infrastructure (PEl) The entirety of hardware, software, people, procedures and policy that is necessary to create, manage, store, distribute and revoke certificates, based on public key cryptography.

Public key A code generated by a mathematical program that is public and is included in the certificate.

Registration Authority (Rk) An entity that is responsible for the identification and authentication of end entities. An RA neither signs nor issues certificates.

Relying party A person or organisation that acts on the basis of trust in a certificate and based on that provides access to the RDW online service provision.

Repository An online database with relevant information with respect to the PKI. The CRL or a list of issued certificates can be published in a repository. Root CA The CA that issues the first certificate within a certificate chain. RIJA Dutch abbreviation for Driving Licence Issue Unit staff member, is authorised by an ABR for access to RDW systems for the purposes of the issue of dri ving licences. Service certificate An RDW certificate linked to a server to provide certainty regarding the identity of the other party’s server.

67

Key pair Sleutelpaar

A public key and its associated private key.

Een publieke sleutel en een hierbij behorende privésleutel.

Secure Socket Layer (55E) / TES Secure Socket Layer (55E) / TES Een cryptografisch protocol dat het mogelijk maakt om op een veilige manier gegevens via het intemet te kunnen versturen (HTTPS).

A cryptographic protocol that makes it possible to transmit data over the Intemet in a secure manner (HTTPS).

Web server Webserver Een computersysteem dat reageert op verzoek van dient systemen.

A computer system that reacts to requests from dient systems.

X.509 X.509 De standaard van de ITU-T (International Telecommunications Union-T) voor digitale certificaten. X.509 versie 3 verwijst naar certificaten die extensies bevatten of kunnen bevatten.

The standard for digital certificates from the ITU-T (International Telecommunications Union-T). X.509 version 3 refers to certificates that contain or could contain extensions

68

RDW Dienst Wegverkeer CP$

Recommend Documents