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

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

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)
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:

  1. 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.
  2. 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.
  3. 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 inhoudNieuwe inhoud

Juridica

Huidige inhoudNieuwe 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:

  1. de juridische rollen die partij zijn in MedMij-deelnemersovereenkomsten: Dienstverlener persoon, Dienstverlener zorgaanbieder en Stichting MedMij.
  2. 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:

  1. de juridische rollen die partij zijn in MedMij-deelnemersovereenkomsten: Dienstverlener persoon, Dienstverlener zorgaanbieder en Stichting MedMij.
  2. 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 inhoudNieuwe 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 inhoudNieuwe 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 beheerorgan