Let op: deze space is geëxporteerd op 5-03-2025.
Wijzigingen worden niet meer meegenomen.
RFC0064 (Patch), AF-1329 Gebruik publieke certificaten in afsprakenstelsel 1.4
- Martin Wilmink
1. 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. |
RACI |
|
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) | |
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. |
2. Uitwerking epic
3. 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.
3.1. Architectuur en technische specificaties
Huidige inhoud | Nieuwe inhoud |
|---|---|
 |
3.2. 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:
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:
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. |
3.3. 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. 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. 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. |
3.4. Netwerk
Huidige inhoud | Nieuwe inhoud | ||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
 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:
De voordelen van de eerste optie zouden zijn dat:
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 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:
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:
| 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:
De voordelen van de eerste optie zouden zijn dat:
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 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:
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:
| ||||||||||||||||||||||||||||||||||||||||
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. | |||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||
Alle certificaathouders verbinden zich aan de op hen toepasselijke eisen van het PKIoverheid-stelsel. Een organisatie mag meerdere certificaten hebben. 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. 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.
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.
| ||||||||||||||||||||||||||||||||||||||||
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:
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.
| |||||||||||||||||||||||||||||||||||||||||
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:
Voor alle backchannel verkeer (machine2machine) moeten deelnemers een PKIoverheid-certificaat van het type 'privaat' toepassen, uitgegeven door de volgende keten en/of opvolgende generaties:
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). | ||||||||||||||||||||||||||||||||||||||||
4. 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 | |||
5. 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. |
6. Bijlagen
.png?api=v2){kind=link}
7. Goedkeuring
Beoordelaar | Datum | Toelichting | Beoordelaar | Datum | Toelichting |
|---|---|---|---|---|---|
Productmanager Stichting MedMij | Productmanager Beheerorganisatie | ||||
Leadarchitect Stichting MedMij | Leadarchitect Beheerorganisatie | ||||
Ontwerpteam | |||||
Deelnemersraad | Eigenaarsraad |