1. Inleiding

PKIOverheid stopt per 4 december 2022 met het aanbieden van publiek vertrouwde certificaten. Bij al het frontchannel verkeer binnen MedMij, alsmede mogelijk bij een deel van het backchannel verkeer, wordt gebruiktgemaakt van deze publiek vertrouwde (EV) certificaten. De beveiliging van het MedMij-verkeer moet op orde zijn, om ervoor te zorgen dat gegevens niet uitlekken. Daarom moeten nieuwe richtlijnen worden opgesteld.

Deze uitwerking is gekoppeld aan AF-1273.

2. Advies

In de discussie worden twee niveaus van certificaten besproken, namelijk Domain Validated (DV) en Organisation Validated (OV). De twee nog hogere niveaus, Extended Validated (EV) en Qualified Website Authentication Certificate (QWAC), zijn buiten scope gehouden, omdat VWS OV voorschrijft. Betreffende de certificaten moet antwoord worden gegeven op twee vragen:

1. Welk niveau van certificaten vereisen we binnen het MedMij netwerk?
   Voor frontchannel-verkeer vereisen wij, in navolging op VWS, het gebruik van OV-certificaten van aanbieders die voldoen aan de regels vanuit AVG (GDPR).

2. Mag er gebruikgemaakt worden van wildcard certificaten?
   Nee, wildcard-certificaten mogen niet gebruikt worden.

2.1. Welk niveau van certificaten vereisen we binnen het MedMij netwerk?

Team ontwikkeling adviseert Product management te vereisen dat gebruik wordt gemaakt van OV-certificaten voor frontchannel-verkeer. We zijn ons ervan bewust dat we hiermee ingaan tegen de wens van de (een aantal) deelnemers. Team ontwikkeling heeft de verschillende opties vergeleken in is tot deze conclusie gekomen met de volgende redenen:

1. Strenge eisen betreffende privacy en informatiebeveiliging (veiligheid, betrouwbaarheid)

   In het MedMij netwerk worden persoonlijke, privacygevoelige gegevens uitgewisseld. Volgens MedMij is een hoog niveau van informatiebeveiliging van belang voor het vertrouwen in het netwerk. Hier zijn regels voor opgesteld, zie bijvoorbeeld Privacy- en informatiebeveiligingsbeleid. Om het risico op vertrouwensschade te beperken, is Domain Validation niet voldoende. De mogelijkheden tot bijvoorbeeld phishing moeten ingeperkt worden, hier dragen de OV-certificaten aan bij. Eindgebruikers kunnen door het gebruik van OV-certificaten beter controleren een partij te betrouwbaar is, waardoor zij minder snel in de trucs van phishing trappen. Dienstverleners hebben hier zelf veel baat bij, omdat het risico op datalekken verkleind wordt.

   
   

2. Situatie vergelijkbaar met financiële sector

   Ondanks dat er in de zorg (nog) geen verplichting is voor het gebruik van certificaten van een hoger niveau, kan de vergelijking worden gelegd met de financiële sector. De privacygevoeligheid van uitgewisselde gegevens is binnen het MedMij netwerk is vergelijkbaar met, zo niet hoger dan de uitgewisselde gegevens in de financiële sector. Banken zijn mede door de privacygevoeligheid van gegevens verplicht gebruik te maken van EV-certificaten, een hoger niveau dan OV.  De zorgsector en MedMij moeten wel voldoen aan de AVG en de NEN7510/NEN7512. Zo vereist de AVG bijvoorbeeld:

   • Duidelijk aanwijsbare en gecommuniceerde verantwoordelijke voor de gegevensverwerking (een organisatie).
   • Passende beveiliging

   Vragen en opmerkingen:

   • Tijdens de expertgroepsessie van 13 januari 2022 werd aangegeven dat het gebruik van OV-certificaten te hanteren is in stelsels met weinig deelnemers. Zo was standpunt dat deze eisen in de financiële sector mogelijk zijn door het lage aantal banken, maar dat in een stelsel als MedMij niet houdbaar is. Volgens MedMij gaat het niet om het aantal organisaties die aan de eisen moeten voldoen, maar om de redenen achter de eis. Betrouwbaarheid is een belangrijk goed in een afsprakenstelsel als MedMij, daar horen passende maatregelen bij. Het gebruik van OV-certificaten hoort hierbij. Daarnaast gaat de vergelijking met het aantal partijen niet op. Er zijn alleen al 40+ Nederlandse banken, die allen aan zwaardere eisen moeten voldoen.

   
   

3. Authenticatie van beide partijen

   Een hoog niveau van informatiebeveiliging vereist sterke authenticatie van eindgebruiker én de aanbieder van de dienst.  De aanbieder moet de eindgebruiker kunnen authenticeren, zodat voldoende zeker is dat de eindgebruiker is wie hij/zij zegt te zijn. De eindgebruiker moet ook de aanbieder kunnen authenticeren. Bij een webapplicatie wordt een aanbieder geauthenticeerd op basis van het gebruikte domein en het bijbehorende certificaat. Hierbij is minimaal een OV-certificaat noodzakelijk, omdat een DV-certificaat deze informatie niet bevat.

   • Het standpunt van de deelnemers is dat niemand hier naar kijkt. Het klopt waarschijnlijk dat de meeste eindgebruikers nooit of nauwelijks op het slotje klikken om de details van de beveiliging op te vragen. Maar, moet je de beperkte groep de mogelijkheid volledig ontzeggen, omdat de meerderheid hier geen gebruik van maakt? Met het oog op het gewenste betrouwbaarheidsniveau moet deze mogelijkheid geboden worden aan personen die privacy hoog in het vaandel hebben staan.

   
   

4. OV verplicht volgens VWS, DV acceptabel volgens NCSC en Logius

   VWS geeft in de beleidslijnen aan dat OV-certificaten het minimaal te gebruiken niveau is voor de beveiliging van webapplicaties. NCSC (en tevens Logius) stelt dat DV-certificaten voldoen voor openbare websites en de meeste andere toepassingen van webcertificaten. Tevens stellen zij dat de meerwaarde van OV-certificaten beperkt is voor toepassingen waarbij een lager niveau geaccepteerd is. VWS stelt zorgspecifieke regels op, NCSC en Logius werken meer vanuit algemene context. Daarom kiezen wij de VWS beleidslijnen aan te houden.

   • De verwijzing van de deelnemers naar de NCSC factsheets klopt. Echter kan de tekst op verschillende manieren worden geïnterpreteerd. Zoals de deelnemers de tekst lezen, staat er dat OV-certificaten geen meerwaarde hebben en dat DV voldoet. Er staat in de tekst:
     "De meerwaarde van een OV-, EV- of QWAC-certificaat is daarmee beperkt voor toepassingen waar een lager niveau, zoals DV, ook geaccepteerd wordt". Het gaat om deze acceptatie. De meerwaarde van OV, de mogelijkheid van authenticatie van de eigenaar van het certificaat, is volgens Team ontwikkeling noodzakelijk. Ook al wordt er maar beperkt gebruik van gemaakt, toch moet een eindgebruiker de andere partij kunnen identificeren. Daarom kan in het MedMij netwerk het lagere niveau van DV niet worden geaccepteerd.

   
   

5. Proces versus certificaten

   De doeleinden van het proces (kwalificatie en acceptatie, audits) en het gebruik van certificaten lijken hetzelfde, maar zijn anders. Beiden hebben te maken met de authenticatie van de deelnemers van MedMij. Het proces laat MedMij de partij authenticeren, zodat uiteindelijk het MedMij label kan worden uitgegeven en daarmee bewijst aan de eisen van MedMij te voldoen. Hiermee is voor een eindgebruiker niet te zeggen welke organisatie eigenaar is van een webapplicatie. Authenticatie van de organisatie door de eindgebruiker kan dan ook niet uitgevoerd worden op nadat deze organisatie door MedMij is gekwalificeerd en geaccepteerd. Dat kan alleen door het gebruik van de juiste certificaten en de zekerheid die dit met zich meebrengt.

   
   

6. Reactie op overige vragen en standpunten deelnemers

   • Volgens deelnemers hebben we te maken met een schijnzekerheid, omdat de eindgebruiker niet weet welke systemen er gebruikt worden. Als bijvoorbeeld een proxy als voordeur gebruikt wordt, kunnen er allerlei verschillende systemen achter staan. Deze stelling klopt. Maar, wat er achter de voordeur gebeurt, dat is de verantwoordelijkheid van de eigenaar van de webapplicatie. Door de eindgebruiker de mogelijkheid te geven te kunnen controleren van wie de voordeur is, weet hij ook wie de verantwoordelijkheid draagt.
   • Een aantal deelnemers geeft aan dat in de huidige situatie al gebruikgemaakt wordt van DV-certificaten van Lets Encrypt. Dit is tegen de huidige regels en in de nieuwe situatie tegen de beleidslijnen van VWS. Deze stellen dat de leverancier van certificaten in de zorgsector  verantwoordingsplichtig moeten zijn aan de AVG of GDPR en hiermee dus in de EU gevestigd moeten zijn. Lets Encrypt is een Amerikaanse organisatie.

   
   

2.2. Mag er gebruikgemaakt worden van wildcard certificaten?

Team ontwikkeling adviseert Product management het gebruik van wildcards niet toe te staan. Hiervoor heeft Team ontwikkeling de volgende redenen.

• De VWS beleidslijnen verbieden het gebruik van wildcard-certificaten.

• Een wildcard certificaat is onwenselijk, omdat hiermee risico tot diefstal en misbruik wordt vergroot.

3. Input

• Memo beleid discontinueren uitgifte pkio publieke server certificaten

• NCSC Factsheet pkioverheid stopt met webcertificaten

• Uitfasering pkio webcertificaten, wat moet u doen voor digid

• Factsheet - DV en OV certificaten bij DigiD

• https://certificaat.kpn.com/aanvragen/servercertificaten/publieke-tls-servercertificaten/

3.1. Beleidslijnen VWS

Het nieuwe beleid zal de vereisten aan de PKI servercertificaten voor de zorgsector normeren op certificeringsvereisten voor de certificaatuitgevers, technische vereisten aan de certificaten en het niveau van zekerheid aan het proces op de uitgifte van de certificaten.

3.1.1. Publiek vertrouwde (publieke) certificaten

Voor burger-naar-zorgverlener contact is een publiek vertrouwd PKI certificaat noodzakelijk. Het nieuwe beleid zal de vereisten aan de PKI servercertificaten voor de zorgsector normeren op certificeringsvereisten voor de certificaatuitgevers, technische vereisten aan de certificaten en het niveau van zekerheid aan het proces op de uitgifte van de certificaten.

De (server)certificaten mogen worden geaccepteerd en gebruikt in de zorg wanneer deze voldoen aan de volgende eisen:

1. De vereisten aan de certificaat leverancier voor PKI certificaten zijn:

   1. De meest up-to-date WebTrust audit is succesvol doorlopen en de certificering is geldig voor de ‘Certificatie Authority’ op iedere schakel in de keten van ondertekeningen tot en met de uitgifte processen.

   2. De private certificaten moeten afkomstig zijn van PKI Overheid geaccrediteerde certificaat ketens.

2. De technische vereisten zijn:

   1. De ‘private key’ moet worden gegenereerd op het doelplatform waar het PKI certificaat wordt toegepast.

   2. Bij gebruik van publieke PKI certificaten is de toepassing van ‘Certification Authority Authorization Resource Record’ vereist.

   3. Het toepassen van DNSSEC op de gebruikte domeinen is vereist onder de voorwaarden van pas-toe-of-leg-uit. Strengere eisen kunnen worden gesteld vanuit aanvullende kaders, zoals aansluitvoorwaarden.

   4. Het gebruik van wildcard certificaten wordt niet toegestaan.

   5. Het gebruik van ‘multi-domain’-certificaten is toegestaan, onder de voorwaarde dat de eigenaar van het certificaat gelijk is aan de eigenaar van alle domeinen die opgenomen zijn in de Subject Alt Name DNS waarden van het certificaat.

3. Uitgifte:

   1. Het zekerheidsuitgifte niveau moet minimaal op het OV-niveau (Organisation Validated) of met hogere zekerheid zijn uitgegeven voor publieke PKI webserver certificaten wanneer persoonsgegevens van bijzondere aard worden verwerkt. Dit is relevant voor de aanschaf van het certificaat en dit valt achteraf te controleren op het bestaan van Policy Object Identifiers (OIDs) die markeren welk type certificaat het betreft.

   2. De uitgever van de PKI certificaten is verantwoordingsplichtig aan de AVG en/of GDPR.

4. Beheer:

   1. Veilig beheer moet zijn toegepast zoals toegelicht in ‘Factsheet Veilig beheer van digitale certificaten’.

   2. Trust op zorgsystemen met systeem-systeem koppelingen al proactief de ‘Staat der Nederlanden Private Root CA - G1’ (te downloaden vanaf https://cert.pkioverheid.nl/) voor zover dat nog niet het geval is.

3.1.2. Niet publiek vertrouwde (private) certificaten

• Voor ‘machine-to-machine’-koppelingen is de overstap naar een privaat PKIO certificaat een veilige overstap en logische overstap. Deze bieden een vergelijkbaar betrouwbaarheidsniveau en zijn nu drie jaar geldig.

• De publieke certificaten kunnen ook toegepast worden voor ‘machine-to-machine’-koppelingen. Dat kan gemak opleveren in de uitrolfase met eveneens de operationele risico’s die voort kunnen komen uit de toepassing van publieke certificaten.

4. Mogelijke opties voor de toekomst

1. Verplichting voor minimaal OV certificaten

   1. inclusief wildcards

   2. exclusief wildcards

2. Mogelijk gebruik van DV certificaten

   1. inclusief wildcards

   2. exclusief wildcards

4.1. Beleidslijnen vanuit VWS

https://www.rijksoverheid.nl/ministeries/ministerie-van-volksgezondheid-welzijn-en-sport/documenten/brieven/2021/12/15/memo-beleid-discontinueren-uitgifte-pkio-publieke-server-certificaten

4.2. Factsheet NCSC

https://www.ncsc.nl/documenten/factsheets/2021/september/29/factsheet-pkioverheid-stopt-met-webcertificaten

4.3. Factsheet Logius

https://www.logius.nl/diensten/digid/documentatie/factsheet-dv-en-ov-certificaten-bij-digid

4.4. Vanuit de SSL/TLS community

5. Wijzigingen

De benodigde wijzigingen worden per versie van het afsprakenstelsel in een Patch of een RFC behandeld.  Hierdoor ontstaan verantwoordelijkheden voor frontchannel-verkeer en voor backchannel-verkeer, waaraan alle deelnemers zich moeten houden.

• RFC0064 (Patch), AF-1329 Gebruik publieke certificaten in afsprakenstelsel 1.4

• RFC0065 (Patch), AF-1349 Gebruik publieke certificaten in afsprakenstelsel 1.5

6. Impact

6.1. Afsprakenstelsel

Binnen een jaar zijn de publieke certificaten van PKIoverheid niet meer te gebruiken. In het aankomende jaar wordt versie 1.4 ingetrokken, versie 1.5 verplicht en ingetrokken, versie 1.6 optioneel en verplicht, versie 1.7 optioneel. De voor deze Epic benodigde wijzigingen kunnen vanaf versie 1.6 worden doorgevoerd, de versie die tegen die tijd verplicht is. Echter, het is van belang de deelnemers in het aankomende jaar goed te begeleiden en te informeren. Om de deelnemers goed voor te bereiden op deze wijziging, lijkt het daarom beter om ook een wijziging door te voeren op de versies 1.4 en 1.5 van het afsprakenstelsel. Hierdoor worden de deelnemers verplicht direct over de benodigde wijziging na te denken en deze in te plannen. Daarnaast moeten de deelnemers goed ingelicht worden over wat er van hen verwacht wordt. Op deze manier kunnen de deelnemers op tijd klaar zijn met het doorvoeren van de wijzigingen.

6.2. Deelnemers

Alle deelnemers die de versies 1.4 en 1.5 gebruiken, moeten rekening houden met wijzigingen. Dit heeft als reden dat alle deelnemers een grafische interface, en daarmee frontchannel verkeer, hebben. De DVP's leveren een grafische interface via web, waarvan Personen gebruik kunnen maken. De DVA's implementeren allen de rol Authorization Server, waarbij ook gebruik moet worden gemaakt van een grafische vormgeving. Beiden moeten in de bestaande vorm beveiligd worden met publieke PKIoverheid certificaten, beiden moeten worden vervangen. Daarnaast worden publieke certificaten ook gebruikt voor backchannel-verkeer, iets dat in de nieuwe situatie niet meer is toegestaan. Hiervoor in de plaats moeten de deelnemers gebruikmaken van private PKIoverheid certificaten (G1).

Daarnaast moeten alle deelnemers die nieuwe certificaten gebruiken voor backchannel-verkeer deze registreren in de R&A, zodat de juiste informatie op de lijsten komt te staan.

6.3. R&A

Net als de deelnemers moet ook de R&A de juiste certificaten gebruiken. Dit betekent dat voor al het frontchannel-verkeer gebruikgemaakt moet worden van publieke certificaten die aan de nieuwe eisen voldoen. Voor al het backchannel-verkeer moet gebruikgemaakt worden van G1 certificaten.

Daarnaast moeten door de deelnemer die nieuwe certificaten gebruiken voor backchannel-verkeer deze registreren in de R&A, zodat de juiste informatie op de lijsten komt te staan.

6.4. Acceptatie

Tijdens het acceptatieproces moet worden toegezien dat deelnemers de juiste certificaten gebruiken op de productieomgeving. Andere omgevingen mogen wel DV-certificaten gebruiken.

6.5. Communicatie

In alle media moet gerefereerd worden naar de juiste beschrijving. Wat dit precies betekent is nog onbekend.

7. Risico's

Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.