Samenvatting

Waarom is deze RFC nodig?	PKIOverheid stopt per 4 december 2022 met het aanbieden van publieke certificaten. Bij al het frontchannel verkeer binnen MedMij, alsmede mogelijk bij een deel van het backchannel verkeer, wordt gebruiktgemaakt van deze publieke (EV) certificaten.
Oplossingsrichting	Deelnemers moeten voor 4 december 2022 overgestapt zijn naar andere publieke certificaten voor frontchannel verkeer. Deze certificaten moeten aan een nieuwe set van eisen voldoen, die zijn overgenomen uit de beleidslijnen van VWS. Daarnaast moeten publieke certificaten die gebruikt worden voor backchannel verkeer vervangen worden door PKIoverheid private (G1) certificaten. Nieuwe deelnemers moeten direct gebruikmaken van andere publieke certificaten voor frontchannelverkeer, voor backchannel verkeer gebruiken zij direct PKIoverheid private (G1) certificaten.
RACI	Responsible: Casper van der Harst Accountable: Egbert van Gelder Consulted Ontwikkelteam (ontwikkeling@medmij.nl) Security Management (secmgt@medmij.nl) Acceptatie (acceptatie@medmij.nl) Stelselregie Deelnemers (Expertgroepsessie) Informed Communicatie Loket (info@medmij.nl) Leveranciersmanagement
Aanpassing van	Afsprakenstel versie 1.4
Impact op rollen	MedMij Beheer, DVP, DVA
Impact op beheer	Bestaand proces moet gevolgd worden.
Impact op RnA	Bestaand proces moet gevolgd worden.
Impact op Acceptatie	Proces blijft hetzelfde, controle op de certificaten wordt net wat anders.
PIA noodzakelijk
Gerelateerd aan (Andere RFCs, PIM issues)	AF-1329, Gebruik publieke certificaten in afsprakenstelsel 1.4 RFC0065 (Patch), AF-1349 Gebruik publieke certificaten in afsprakenstelsel 1.5
Motivatie verkorte RFC procedure (patch)	Binnen een jaar zijn de publieke certificaten van PKIoverheid niet meer te gebruiken. 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, is daarom gekozen een wijziging door te voeren op de versies 1.4 en 1.5 van het afsprakenstelsel.

Uitwerking epic

Uitwerking Epic AF-1273, PKIoverheid stopt met uitgeven publiek vertrouwde webserver (SSL/TLS) certificaten

Wijzigingen afsprakenstelsel

In de architectuur van het afsprakenstelsel wordt een overzicht gegeven van de rollen op de verschillende lagen. Hierbij wordt ook PKIOverheid TSP genoemd. Omdat PKIOverheid nu niet meer alle certificaten zal aanbieden, moet dit aangepast worden. Hiervoor zijn drie opties:

Voor PKI TSP wordt een generieke rol beschreven, waarin de aanbieder niet meer genoemd wordt. Dit heeft als voordeel dat het rollenmodel niets zegt over implementatie en altijd te hanteren is. In de verantwoordelijkheden moet/kan wel naar specifieke partijen (bijvoorbeeld PKIoverheid) verwezen worden, om hiermee aan de eis te kunnen voldoen dat PKIoverheid nog wel de leverancier is van de backchannel-certificaten.
Naast PKIOverheid TSP benoemen we een tweede, meer generieke, rol, voor het leveren van frontchannel-certificaten. In de verantwoordelijkheden worden voor de verschillende rollen de zaken verduidelijkt.
In het rollenmodel worden de verwijzingen naar TSP volledig verwijderd. Dit is conform de aanpak in 1.5.0. De keuze is hierbij TSP weg te laten, omdat PKI een stelsel is waarvan MedMij gebruikmaakt. Het heeft niet een speciale rol, anders dan benoemd kan worden in de verantwoordelijkheden betreffende nodes en verkeer. De impact op het model is echter wel groot, omdat de TSP rol op netwerk niveau gekoppeld is met functies en gegevens. Deze moeten ook anders ingericht worden.

Om de impact op deze versie van het afsprakenstelsel zo klein mogelijk te houden, wordt gekozen voor de eerste optie. Dit betekent dat in het rollenmodel de verwijzing naar PKIoverheid TSP vervangen wordt door Trust Service Provider. Dit moet ook op de verschillende lagen worden doorgevoerd. In de verantwoordelijkheden zal wel verwezen worden naar PKIOverheid, omdat dit voor het backchannelverkeer de enige infrastructuur is om te gebruiken.

Architectuur en technische specificaties

Huidige inhoud	Nieuwe inhoud

Juridica

Huidige inhoud

Nieuwe inhoud

In deze laag staan de juridische rollen, als juridische basis voor de rollen op andere lagen van de architectuur. De reden dat deze laag in deze architectuur is opgenomen is dat haar rollen voor de samenhang tussen de verschillende architectuurlagen zorgen en de architectuur geborgd moet zijn in de juridische rollen in het MedMij Afsprakenstelsel. Bij een juridische rol horen verplichtingen voor het spelen van rollen op verschillende architectuurlagen.

De rollen die we hier in de architectuur noemen vallen uiteen in twee groepen:

de juridische rollen die partij zijn in MedMij-deelnemersovereenkomsten: Dienstverlener persoon, Dienstverlener zorgaanbieder en Stichting MedMij.
de juridische rollen die geen partij zijn in MedMij-deelnemersovereenkomsten, maar niettemin een uitvoerende verplichting hebben in de architectuur. Dat betekent dat de toepasselijke deelnemersovereenkomst van een deelnemer zal eisen dat deze een juridische relatie aangaat met die juridische rol. Het gaat hier om:
- Persoon en Zorgaanbieder, wiens onderlinge informatierelatie door MedMij-verkeer wordt bediend;
- Authenticatie Provider ZA, die voor Zorgaanbieders de authenticatie verzorgt van Personen die zich bij de Zorgaanbieder aandienen;
- PKIoverheid TSP, die certificaten uitgeeft waarmee het verkeer op het MedMij-netwerk betrouwbaar gemaakt kan worden.

In de architectuur van het afsprakenstelsel heeft de Persoon een operationele rol bij authenticatie en autorisatie van het gegevensverkeer. De Zorgaanbieder wordt operationeel geheel vertegenwoordigd door de Dienstverlener Zorgaanbieder.

In deze laag staan de juridische rollen, als juridische basis voor de rollen op andere lagen van de architectuur. De reden dat deze laag in deze architectuur is opgenomen is dat haar rollen voor de samenhang tussen de verschillende architectuurlagen zorgen en de architectuur geborgd moet zijn in de juridische rollen in het MedMij Afsprakenstelsel. Bij een juridische rol horen verplichtingen voor het spelen van rollen op verschillende architectuurlagen.

De rollen die we hier in de architectuur noemen vallen uiteen in twee groepen:

de juridische rollen die partij zijn in MedMij-deelnemersovereenkomsten: Dienstverlener persoon, Dienstverlener zorgaanbieder en Stichting MedMij.
de juridische rollen die geen partij zijn in MedMij-deelnemersovereenkomsten, maar niettemin een uitvoerende verplichting hebben in de architectuur. Dat betekent dat de toepasselijke deelnemersovereenkomst van een deelnemer zal eisen dat deze een juridische relatie aangaat met die juridische rol. Het gaat hier om:
- Persoon en Zorgaanbieder, wiens onderlinge informatierelatie door MedMij-verkeer wordt bediend;
- Authenticatie Provider ZA, die voor Zorgaanbieders de authenticatie verzorgt van Personen die zich bij de Zorgaanbieder aandienen;
- Trust Service Provider, die certificaten uitgeeft waarmee het verkeer op het MedMij-netwerk betrouwbaar gemaakt kan worden.

In de architectuur van het afsprakenstelsel heeft de Persoon een operationele rol bij authenticatie en autorisatie van het gegevensverkeer. De Zorgaanbieder wordt operationeel geheel vertegenwoordigd door de Dienstverlener Zorgaanbieder.

Applicatie

Huidige inhoud

Nieuwe inhoud

De OAuth Client en OAuth Authorization Server gebruiken voor al hun onderlinge verkeer PKIoverheid-certificaten, en wel servercertificaten, ten behoeve van de authenticatie van de andere server in een uitwisseling.

Toelichting

Dit is een maatregel tegen beveiligingsrisico's 4.4.1.1, 4.4.1.3, 4.4.1.4 en 4.4.1.5 in RFC 6819. De PKI-certificaten worden in deze release van het MedMij Afsprakenstelsel gebruik voor twee doelen op de Netwerklaag: authenticatie van servers en versleuteling, waarmee de vertrouwelijkheid en integriteit van de inhoud van het gegevensverkeer wordt geborgd.

De OAuth Client en OAuth Authorization Server gebruiken voor al hun onderlinge verkeer PKI-certificaten, en wel servercertificaten, ten behoeve van de authenticatie van de andere server in een uitwisseling.

Toelichting

Dit is een maatregel tegen beveiligingsrisico's 4.4.1.1, 4.4.1.3, 4.4.1.4 en 4.4.1.5 in RFC 6819. De PKI-certificaten worden in deze release van het MedMij Afsprakenstelsel gebruik voor twee doelen op de Netwerklaag: authenticatie van servers en versleuteling, waarmee de vertrouwelijkheid en integriteit van de inhoud van het gegevensverkeer wordt geborgd.

Netwerk

Huidige inhoud Nieuwe inhoud

Toelichting

Op deze laag worden de infrastructurele rollen (Nodes) op het MedMij-netwerk bepaald en voorzien van verantwoordelijkheden op het gebied van versleuteling, authenticatie van Nodes en autorisatie van Nodes. Met dat laatste wordt bedoeld dat er steeds opnieuw moet worden vastgesteld dat een Node gerechtigd is zich te bewegen op het MedMij-netwerk. Voor versleuteling en authenticatie worden PKI-certificaten gebruikt.

Autorisatie zou op grofweg twee manieren in het MedMij Afsprakenstelsel kunnen worden opgenomen:

via diezelfde PKI-certificaten, waarin aan de domeinnaam van de houder van het certificaat gezien kan worden of het om een MedMij Node gaat, door daarvan te eisen dat die domeinnaam de vorm <dienstverlener>.medmij.nl heeft;
via een door MedMij-zelf beheerde lijst van geautoriseerde MedMij Nodes (een whitelist).

De voordelen van de eerste optie zouden zijn dat:

er zo maximaal gebruik wordt gemaakt van afspraken die ook voor andere doeleinden al nodig zijn, namelijk het gebruik van PKI-certificaten;
zo de mate van operationele centrale betrokkenheid van de Stichting MedMij wordt geminimaliseerd, en dus de kosten en risico's daarvan. In de tweede optie zou Stichting MedMij zelf een lijst moeten gaan beheren en ontsluiten naar alle servers om het operationele verkeer mogelijk te maken. In de eerste optie is alleen een name service nodig voor de medmij.nl-domeinnamen. Dat laatste is een goed gestandaardiseerde, goed begrepen en goed uit te besteden service, die lagere kosten, lagere risico's en minder afhankelijkheid voor de deelnemers met zich mee zal brengen;
MedMij zich zo maximaal houdt aan haar architectuurprincipe P6: MedMij spreekt alleen af wat nodig is.

Toch is voor de tweede optie gekozen, omdat de voor de eerste optie benodigde controle over de hostnames en de certificaten alleen met ongewenste bijeffecten gepaard zou gaan. De volgende opties zijn daarbij verkend:

De MedMij-beheerorganisatie wordt Registration Authority (RA) in PKIoverheid, jegens alle betrokken Certificate Authorities (CA's). PKIoverheid kent echter die mogelijkheid niet.
De MedMij-beheerorganisatie geeft een domeinverklaring af, zodat deelnemers zelf een subdomein onder .medmij.nl kunnen aanvragen bij een CA. Daarmee heeft de beheerorganisatie wel invloed op de uitgifte van een certificaat, maar laten intrekken is niet mogelijk, tenzij er sprake is van misbruik. Er is immers geen juridische relatie tussen de eigenaar van het domein (de beheerorganisatie) en de CA.
Analoog aan de wijze waarop door sommigen beroepsgebonden certificaten worden uitgegeven, is een maatwerk-certificeringsdienst denkbaar. In de voorwaarden van het product (geldend vanaf de aanvraag van het certificaat) wordt dan expliciet geregeld dat wanneer de inschrijving in een extern register wegvalt, het certificaat door de CA wordt ingetrokken. Dat vereist dat de registerhouder (beheerorganisatie) wijzigingen doorgeeft aan alle CA's. Dit is economisch pas interessant bij een aanzienlijke hoeveelheid certificaathouders, waarvan in MedMij voorlopig geen sprake zal zijn.
MedMij zou een eigen PKI-omgeving kunnen inrichten (afwijkend van PKIOverheid). Dit is niet verder verkend, vanwege de complexiteit en verantwoordelijkheid die op de schouders van de beheerorganisatie zou rusten.
De Stichting MedMij zou zelf houder kunnen zijn van alle certificaten, waarbij deelnemers gemandateerd worden voor beheerstaken rond hun eigen subset van certificaten. De Stichting kan certificaten intrekken. Identificatie van de dienstverlener naar de gebruiker is niet mogelijk, want de certificaten staan op naam van Stichting MedMij.
Er zou een custom field gebruikt kunnen worden in certificaten. De MedMij Beheerorganisatie zou de controle kunnen krijgen over de wijze waarop met dit veld wordt omgegaan. Dit vereist waarschijnlijk afspraken met alle CA's. Dit geeft controle op het uitgeven van certificaten, maar geeft de beheerorganisatie geen mogelijkheden het certificaat te laten intrekken.

De Nodes op Netwerk-niveau worden geïdentificeerd met een hostname. Omdat dus ook elke PGO Node en ZA Node bij één Dienstverlener hoort, is aan de hostname de Dienstverlener te herkennen.

In het persoonsdomein geldt zo dat:

één Dienstverlener Persoon één of meerdere Uitgevers verzorgt en elke Uitgever verzorgd wordt door één Dienstverlener Persoon;
één Uitgever door één of meerdere PGO Servers wordt gerealiseerd en elke PGO Server één Uitgever realiseert;
één PGO Server door één of meerdere PGO Nodes wordt ondersteund en elke PGO Node één PGO Server ondersteunt.

Zo kan dus ook in de OAuth Clientlist de hostname van een PGO Node geassocieerd worden met één (gebruikersvriendelijke naam van de) PGO Server .

In het zorgaanbiedersdomein geldt zo dat:

één Dienstverlener Zorgaanbieder één of meerdere Bronnen en/of Lezers verzorgt en elke Bron en/of Lezer verzorgd wordt door één Dienstverlener Zorgaanbieder;
één Bron en/of Lezer door één of meer combinaties van één Authorization Server en één Resource Server wordt gerealiseerd en elke combinatie van één Authorization Server en één Resource Server één Bron en/of Lezer realiseert;
één Authorization Server, net als één Resource Server, door één of meerdere ZA Nodes wordt ondersteund;
elke ZA Node hetzij één Authorization Server ondersteunt, hetzij één Resource Server , hetzij de combinatie van één Authorization Server en één Resource Server ondersteunt;
elke ZA Node één of meerdere endpoints kent en elk endpoint hoort bij één ZA Node, zodanig dat de hostname in een endpoint-adres de hostname van die ZA Node is.

Toelichting

Op deze laag worden de infrastructurele rollen (Nodes) op het MedMij-netwerk bepaald en voorzien van verantwoordelijkheden op het gebied van versleuteling, authenticatie van Nodes en autorisatie van Nodes. Met dat laatste wordt bedoeld dat er steeds opnieuw moet worden vastgesteld dat een Node gerechtigd is zich te bewegen op het MedMij-netwerk. Voor versleuteling en authenticatie worden PKI-certificaten gebruikt.

Autorisatie zou op grofweg twee manieren in het MedMij Afsprakenstelsel kunnen worden opgenomen:

via diezelfde PKI-certificaten, waarin aan de domeinnaam van de houder van het certificaat gezien kan worden of het om een MedMij Node gaat, door daarvan te eisen dat die domeinnaam de vorm <dienstverlener>.medmij.nl heeft;
via een door MedMij-zelf beheerde lijst van geautoriseerde MedMij Nodes (een whitelist).

De voordelen van de eerste optie zouden zijn dat:

er zo maximaal gebruik wordt gemaakt van afspraken die ook voor andere doeleinden al nodig zijn, namelijk het gebruik van PKI-certificaten;
zo de mate van operationele centrale betrokkenheid van de Stichting MedMij wordt geminimaliseerd, en dus de kosten en risico's daarvan. In de tweede optie zou Stichting MedMij zelf een lijst moeten gaan beheren en ontsluiten naar alle servers om het operationele verkeer mogelijk te maken. In de eerste optie is alleen een name service nodig voor de medmij.nl-domeinnamen. Dat laatste is een goed gestandaardiseerde, goed begrepen en goed uit te besteden service, die lagere kosten, lagere risico's en minder afhankelijkheid voor de deelnemers met zich mee zal brengen;
MedMij zich zo maximaal houdt aan haar architectuurprincipe P6: MedMij spreekt alleen af wat nodig is.

Toch is voor de tweede optie gekozen, omdat de voor de eerste optie benodigde controle over de hostnames en de certificaten alleen met ongewenste bijeffecten gepaard zou gaan. De volgende opties zijn daarbij verkend:

De MedMij-beheerorganisatie wordt Registration Authority (RA) in PKIoverheid, jegens alle betrokken Certificate Authorities (CA's). PKIoverheid kent echter die mogelijkheid niet.
De MedMij-beheerorganisatie geeft een domeinverklaring af, zodat deelnemers zelf een subdomein onder .medmij.nl kunnen aanvragen bij een CA. Daarmee heeft de beheerorganisatie wel invloed op de uitgifte van een certificaat, maar laten intrekken is niet mogelijk, tenzij er sprake is van misbruik. Er is immers geen juridische relatie tussen de eigenaar van het domein (de beheerorganisatie) en de CA.
Analoog aan de wijze waarop door sommigen beroepsgebonden certificaten worden uitgegeven, is een maatwerk-certificeringsdienst denkbaar. In de voorwaarden van het product (geldend vanaf de aanvraag van het certificaat) wordt dan expliciet geregeld dat wanneer de inschrijving in een extern register wegvalt, het certificaat door de CA wordt ingetrokken. Dat vereist dat de registerhouder (beheerorganisatie) wijzigingen doorgeeft aan alle CA's. Dit is economisch pas interessant bij een aanzienlijke hoeveelheid certificaathouders, waarvan in MedMij voorlopig geen sprake zal zijn.
MedMij zou een eigen PKI-omgeving kunnen inrichten. Dit is niet verder verkend, vanwege de complexiteit en verantwoordelijkheid die op de schouders van de beheerorganisatie zou rusten.
De Stichting MedMij zou zelf houder kunnen zijn van alle certificaten, waarbij deelnemers gemandateerd worden voor beheerstaken rond hun eigen subset van certificaten. De Stichting kan certificaten intrekken. Identificatie van de dienstverlener naar de gebruiker is niet mogelijk, want de certificaten staan op naam van Stichting MedMij.
Er zou een custom field gebruikt kunnen worden in certificaten. De MedMij Beheerorganisatie zou de controle kunnen krijgen over de wijze waarop met dit veld wordt omgegaan. Dit vereist waarschijnlijk afspraken met alle CA's. Dit geeft controle op het uitgeven van certificaten, maar geeft de beheerorganisatie geen mogelijkheden het certificaat te laten intrekken.

De Nodes op Netwerk-niveau worden geïdentificeerd met een hostname. Omdat dus ook elke PGO Node en ZA Node bij één Dienstverlener hoort, is aan de hostname de Dienstverlener te herkennen.

In het persoonsdomein geldt zo dat:

één Dienstverlener Persoon één of meerdere Uitgevers verzorgt en elke Uitgever verzorgd wordt door één Dienstverlener Persoon;
één Uitgever door één of meerdere PGO Servers wordt gerealiseerd en elke PGO Server één Uitgever realiseert;
één PGO Server door één of meerdere PGO Nodes wordt ondersteund en elke PGO Node één PGO Server ondersteunt.

Zo kan dus ook in de OAuth Clientlist de hostname van een PGO Node geassocieerd worden met één (gebruikersvriendelijke naam van de) PGO Server .

In het zorgaanbiedersdomein geldt zo dat:

één Dienstverlener Zorgaanbieder één of meerdere Bronnen en/of Lezers verzorgt en elke Bron en/of Lezer verzorgd wordt door één Dienstverlener Zorgaanbieder;
één Bron en/of Lezer door één of meer combinaties van één Authorization Server en één Resource Server wordt gerealiseerd en elke combinatie van één Authorization Server en één Resource Server één Bron en/of Lezer realiseert;
één Authorization Server, net als één Resource Server, door één of meerdere ZA Nodes wordt ondersteund;
elke ZA Node hetzij één Authorization Server ondersteunt, hetzij één Resource Server , hetzij de combinatie van één Authorization Server en één Resource Server ondersteunt;
elke ZA Node één of meerdere endpoints kent en elk endpoint hoort bij één ZA Node, zodanig dat de hostname in een endpoint-adres de hostname van die ZA Node is.

Een of meerdere PKIoverheid TSP's treden op als PKIoverheid TSP. Een of meerdere PKIoverheid Trust Service Providers treden op als Trust Server Provider voor de uitgifte van certificaten die bij backchannel-verkeer gebruikt moeten worden.

Een of meerdere Trust Service Providers treden op als Trust Server Provider voor de uitgifte van certificaten die bij frontchannel-verkeer gebruikt moeten worden.

	frontchannel- verkeer	uitgaand backchannel-verkeer	inkomend backchannel-verkeer
versleuteling volgens TLS, met PKIoverheid-certificaat	altijd
identificatie op basis van ...	`redirect_uri` of Zorgaanbiederslijst		PKIoverheid- certificaat
authenticatie, op basis van PKIoverheid-certificaat, van ...	alleen de TLS-server	TLS-client én TLS-server
autorisatie op basis van controle tegen de Whitelist	niet	voorafgaand aan de TLS-handshake	zie verantwoordelijkheid 14a

	frontchannel- verkeer	uitgaand backchannel-verkeer	inkomend backchannel-verkeer
versleuteling volgens TLS	altijd
identificatie op basis van ...	`redirect_uri` of Zorgaanbiederslijst		PKIoverheid- certificaat
authenticatie, op basis van PKI-certificaat, van ...	alleen de TLS-server	TLS-client én TLS-server
autorisatie op basis van controle tegen de Whitelist	niet	voorafgaand aan de TLS-handshake	zie verantwoordelijkheid 14a

Alle certificaathouders verbinden zich aan de op hen toepasselijke eisen van het PKIoverheid-stelsel. Een organisatie mag meerdere certificaten hebben.

Toelichting

De keuze voor de PKI-standaard past bij principe P19 van het MedMij Afsprakenstelsel. Er bestaan andere manieren voor, en ideeën over, het borgen van vertrouwen in een netwerk van geautomatiseerde systemen, maar deze zijn nog lang niet zo bewezen als PKI, dat wereldwijd wordt ondersteund, en wereldwijd is beproefd, door overheden en marktspelers.

Bij gebruik van de PKI-standaard doet zich de vraag voor van welk(e) PKI-stelsel(s) gebruik gemaakt kan of moet worden. Zo'n PKI-stelsel voorziet in een hiërarchie van organisaties die certificaten uitgeven, zodanig dat de betrouwbaarheid van de certificaten van zo'n organisatie leunt op de betrouwbaarheid van de eerst-hogere organisatie in die hiërarchie, doordat de certificaten van de lagere-in-hiërarchie een handtekening hebben van die van de hogere-in-hiërarchie. Aan de top van zo'n hiërarchie staat een zogenoemde root Certificate Authority (root CA) die zijn betrouwbaarheid niet aan een hogere kan ontlenen, zijn eigen (stam)certificaten tekent, en zo een steunpilaar is van het vertrouwen in het hele betreffende PKI-stelsel.

Het MedMij Afsprakenstelsel had ervoor kunnen kiezen een PKI-stelsel specifiek voor MedMij in te richten, maar de kosten daarvan, voor zichzelf en voor haar deelnemers, wegen niet op tegen de voordelen, onder de voorwaarde dat er een ander geschikt PKI-stelsel voorhanden is. Deelnemers zullen met hun services immers ook in andere afsprakenstelsels betrokken kunnen zijn dan dat van MedMij. Zo'n keuze past bovendien niet bij principe P6.

Omdat het MedMij-netwerk een nationale en maatschappelijk kritische infrastructuur is, met hoge eisen aan betrouwbaarheid, kiest het MedMij Afsprakenstelsel voor het momenteel enige PKI-stelsel waarin de betrouwbaarheid uiteindelijk steunt op een Nederlandse publiekrechtelijke rechtspersoon: PKIoverheid met de Staat der Nederlanden als root CA. Zo is de governance van de root CA transparant en toegankelijk belegd.

Het MedMij Afsprakenstelsel bouwt voor het door hem aan zijn deelnemers geboden vertrouwen dus mede op het PKIoverheid-stelsel, op het door dat stelsel vastgestelde programma van eisen voor de in dat stelsel betrokken TSP's en op de certificatiehiërarchie van PKIoverheid. Deelnemers in het MedMij Afsprakenstelsel zullen dus service-certificaten moeten betrekken bij een bij PKIoverheid aangesloten TSP die bij haar past.

Alle certificaathouders verbinden zich aan de op hen toepasselijke eisen van het PKI-stelsel. Een organisatie mag meerdere certificaten hebben.

Toelichting

De keuze voor de PKI-standaard past bij principe P19 van het MedMij Afsprakenstelsel. Er bestaan andere manieren voor, en ideeën over, het borgen van vertrouwen in een netwerk van geautomatiseerde systemen, maar deze zijn nog lang niet zo bewezen als PKI, dat wereldwijd wordt ondersteund, en wereldwijd is beproefd, door overheden en marktspelers.

Bij gebruik van de PKI-standaard doet zich de vraag voor van welk(e) PKI-stelsel(s) gebruik gemaakt kan of moet worden. Zo'n PKI-stelsel voorziet in een hiërarchie van organisaties die certificaten uitgeven, zodanig dat de betrouwbaarheid van de certificaten van zo'n organisatie leunt op de betrouwbaarheid van de eerst-hogere organisatie in die hiërarchie, doordat de certificaten van de lagere-in-hiërarchie een handtekening hebben van die van de hogere-in-hiërarchie. Aan de top van zo'n hiërarchie staat een zogenoemde root Certificate Authority (root CA) die zijn betrouwbaarheid niet aan een hogere kan ontlenen, zijn eigen (stam)certificaten tekent, en zo een steunpilaar is van het vertrouwen in het hele betreffende PKI-stelsel.

Het MedMij Afsprakenstelsel had ervoor kunnen kiezen een PKI-stelsel specifiek voor MedMij in te richten, maar de kosten daarvan, voor zichzelf en voor haar deelnemers, wegen niet op tegen de voordelen, onder de voorwaarde dat er een ander geschikt PKI-stelsel voorhanden is. Deelnemers zullen met hun services immers ook in andere afsprakenstelsels betrokken kunnen zijn dan dat van MedMij. Zo'n keuze past bovendien niet bij principe P6.

Omdat het MedMij-netwerk een nationale en maatschappelijk kritische infrastructuur is, met hoge eisen aan betrouwbaarheid, kiest het MedMij Afsprakenstelsel voor het momenteel enige PKI-stelsel waarin de betrouwbaarheid uiteindelijk steunt op een Nederlandse publiekrechtelijke rechtspersoon: PKIoverheid met de Staat der Nederlanden als root CA. Zo is de governance van de root CA transparant en toegankelijk belegd.

Het MedMij Afsprakenstelsel bouwt ondermeer voor het door hem aan zijn deelnemers geboden vertrouwen dus mede op het PKIoverheid-stelsel, op het door dat stelsel vastgestelde programma van eisen voor de in dat stelsel betrokken TSP's en op de certificatiehiërarchie van PKIoverheid. Deelnemers in het MedMij Afsprakenstelsel zullen dus service-certificaten moeten betrekken bij een bij PKIoverheid aangesloten TSP die bij haar past.

Om zich te kunnen authenticeren en autoriseren op het MedMij-netwerk, kunnen elke PGO Node, elke ZA Node en de MedMij Stelselnode een PKIoverheid-certificaat overleggen, en wel een server-certificaat van een PKIoverheid TSP.

Voor authenticatie en autorisatie bij backchannel-verkeer op het MedMij-netwerk, kunnen elke PGO Node, elke ZA Node en de MedMij Stelselnode een PKIoverheid-certificaat overleggen, en wel een G1-certificaat van een PKIoverheid TSP.

Private Root CA (per medio 2020 de standaard voor m2m)
- Stamcertificaat
  - Staat der Nederlanden Private Root CA - G1
- Domein Private Services, maar alleen de volgende:
  - Staat der Nederlanden Private Services CA - G1
  - KPN PKIoverheid Private Services CA - G1
  - QuoVadis PKIoverheid Private Services CA - G1
  - Digidentity BV PKIoverheid Private Services CA - G1

Partijen die op <DATUM> al Deelnemer van MedMij waren en gebruikmaken van een publiek certificaat voor de beveiliging van hun backchannel-verkeer, kunnen dit certificaat tot uiterlijk 4 december 2022 gebruiken. Hierna is het gebruik van een privaat (G1) certificaat van PKIoverheid ook voor deze deelnemers verplicht voor de beveiliging van al het backchannel-verkeer.

Stamcertificaat
- Staat der Nederlanden EV Root CA
Intermediair Domein Server CA 2020
- QuoVadis PKIoverheid Server CA 2020
- Digidentity PKIoverheid Server CA 2020
- KPN PKIoverheid Server CA 2020

Voor authenticatie en autorisatie bij frontchannel-verkeer tussen productieomgevingen op het MedMij-netwerk, kunnen elke PGO Node, elke ZA Node en de MedMij Stelselnode een PKI-certificaat overleggen dat aan de volgende eisen voldoet:

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.
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.
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.
Beheer:
1. Veilig beheer moet zijn toegepast zoals toegelicht in ‘Factsheet Veilig beheer van digitale certificaten’.

Partijen die op <DATUM> al Deelnemer van MedMij waren en gebruikmaken van een publiek certificaat voor de beveiliging van hun frontchannel-verkeer, kunnen dit certificaat tot uiterlijk 4 december 2022 gebruiken. Hierna is het gebruik van publiek certificaat dat voldoet aan de hierboven genoemde eisen verplicht.

Stamcertificaat
- Staat der Nederlanden EV Root CA
Intermediair Domein Server CA 2020
- QuoVadis PKIoverheid Server CA 2020
- Digidentity PKIoverheid Server CA 2020
- KPN PKIoverheid Server CA 2020

ZA Node, PGO Node en MedMij Stelselnode valideren tijdens de TLS-handshake aan het begin van een TLS-sessie of het een PKIoverheid-certificaat is en controleren bij de Certification Authority of het ontvangen certificaat geldig is, op basis van CRL of OCSP. In geval van het falen van één van deze controles wordt het certificaat niet geaccepteerd en de TLS-sessie niet gestart. ZA Node, PGO Node en MedMij Stelselnode valideren tijdens de TLS-handshake bij backchannel-verkeer aan het begin van een TLS-sessie of het een PKIoverheid-certificaat is en controleren bij de Certification Authority of het ontvangen certificaat geldig is, op basis van CRL of OCSP. In geval van het falen van één van deze controles wordt het certificaat niet geaccepteerd en de TLS-sessie niet gestart.

Voor alle frontchannel (internet-facing) verkeer moeten deelnemers een PKIoverheid-certificaat van het type 'publiek' toepassen, uitgegeven door de volgende keten en/of opvolgende generaties:

- Stamcertificaat
  - Staat der Nederlanden EV Root CA
- Intermediair Domein Server CA 2020
  - QuoVadis PKIoverheid Server CA 2020
  - Digidentity PKIoverheid Server CA 2020
  - KPN PKIoverheid Server CA 2020

Voor alle backchannel verkeer (machine2machine) moeten deelnemers een PKIoverheid-certificaat van het type 'privaat' toepassen, uitgegeven door de volgende keten en/of opvolgende generaties:

- Private Root CA (per medio 2020 de standaard voor m2m)
  - Stamcertificaat
    - Staat der Nederlanden Private Root CA - G1
  - Domein Private Services, maar alleen de volgende:
    - Staat der Nederlanden Private Services CA - G1
    - KPN PKIoverheid Private Services CA - G1
    - QuoVadis PKIoverheid Private Services CA - G1
    - Digidentity BV PKIoverheid Private Services CA - G1

In navolging op Logius kunnen in het MedMij-netwerk de onder 'EV-Root' uitgegeven certificaten tijdelijk worden gebruikt voor machine2machine toepassingen. Een toekomstvaste oplossing voor machine2machine toepassingen is het gebruik van G1 certificaten.

Het voornemen is deze uitzondering te schrappen, zodra Logius het gebruik van de onder 'EV-Root' uitgegeven certificaten niet meer accepteert voor machine2machine toepassingen. Dit kan al dan niet met behulp van een snel door te voeren patch op het MedMij Afsprakenstelsel.

PKIoverheid certificaten moeten (in ieder geval op productie en acceptatie omgevingen) als complete keten inclusief alle intermediate certificaten worden verstuurd en gecontroleerd. Een certificaat keten bestaat uit het certificaat zelf, aangevuld met alle intermediate certificaten die worden meegeleverd door de CSP, de uitgevende instantie van het betreffende certificaat. Het root certificaat moet niet meegeleverd worden (dit is al aanwezig in de truststore van de tegenpartij). De PKI-certificaten moeten (in ieder geval op productie en acceptatie omgevingen) bij backchannel-verkeer als complete keten, inclusief alle intermediate certificaten, worden verstuurd en gecontroleerd. Een certificaat keten bestaat uit het certificaat zelf, aangevuld met alle intermediate certificaten die worden meegeleverd door de CSP, de uitgevende instantie van het betreffende certificaat. Het root certificaat moet niet meegeleverd worden (dit is al aanwezig in de truststore van de tegenpartij).

Principe's

Principe		Principe
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal		11 Stelselfuncties worden vanaf de start ingevuld
2 Dienstverleners zijn transparant over de gegevensdiensten		12 Het afsprakenstelsel is een groeimodel
3 Dienstverleners concurreren op de functionaliteiten		13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders
4 Dienstverleners zijn aanspreekbaar door de gebruiker		14 Uitwisseling is een keuze
5 De persoon wisselt gegevens uit met de zorgaanbieder		15 Het MedMij-netwerk is gebruiksrechten-neutraal
6 MedMij spreekt alleen af wat nodig is		16 De burger regisseert zijn gezondheidsinformatie als uitgever
7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener		17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld
9 De dienstverleners zijn deelnemers van het afsprakenstelsel		18 Afspraken worden aantoonbaar nageleefd en gehandhaafd
10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling		19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat
Toelichting

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.

Dreiging	Kans	Impact	DreigingsID (intern)	Maatregelen
Nieuwe deelnemers nemen toch een publiek vertrouwd PKIoverheid certificaat af, waardoor ze binnen een jaar extra kosten maken om over te schakelen naar een andere aanbieder	Klein	Klein		Nieuwe deelnemers goed informeren in het voortraject.

Bijlagen

	File	Modified
Labels No labels Preview View	PNG File MedMij, 1.3.0, Architectuur Afsprakenstelsel MedMij-Totaaloverzicht.png	Dec 10, 2021 by Casper van der Harst
Labels No labels Preview View	PNG File Juridica Architectuur Afsprakenstelsel MedMij (draw.io, 12 juli 2019).png	Dec 10, 2021 by Casper van der Harst
Labels No labels Preview View	PNG File MedMij, 1.3.0, Architectuur Afsprakenstelsel MedMij-Netwerk.png	Dec 10, 2021 by Casper van der Harst
Labels drawio Preview View	File Architectuur MedMij afsprakenstelsel draw.io diagram	Dec 10, 2021 by Casper van der Harst
Labels No labels Preview View	PNG File Architectuur MedMij afsprakenstelsel.png Architectuur MedMij afsprakenstelsel exported to image	Dec 10, 2021 by Casper van der Harst
Labels No labels Preview View	PNG File Architectuur MedMij afsprakenstelsel-e55512c87abedfc7215c8ef06ff2f57d380a878b.png draw.io aspect image	Dec 10, 2021 by Casper van der Harst
Labels No labels Preview View	PNG File Architectuur MedMij afsprakenstelsel-14aad9ad297164aebac5bd7e32e19ab25dca16ef.png draw.io aspect image	Dec 10, 2021 by Casper van der Harst
Labels No labels Preview View	PNG File Architectuur MedMij afsprakenstelsel-f987d80804e40b902ac8816ee9aebc972381cc21.png draw.io aspect image	Dec 10, 2021 by Casper van der Harst

Download All

Goedkeuring

Beoordelaar	Datum	Toelichting	Beoordelaar	Datum	Toelichting
Productmanager Stichting MedMij			Productmanager Beheerorganisatie
Leadarchitect Stichting MedMij			Leadarchitect Beheerorganisatie
Ontwerpteam
Deelnemersraad			Eigenaarsraad

MedMij Change Management

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

Samenvatting

Uitwerking epic

Wijzigingen afsprakenstelsel

Architectuur en technische specificaties

Juridica

Applicatie

Netwerk

Principe's

Risico's

Bijlagen

Goedkeuring