RFC0007 Controle op ingetrokken certificaten

Samenvatting

Waarom is deze RFC nodig?	De vraag ligt voor om de gekozen richting in het afsprakenstelsel MedMij voor de controle op ingetrokken (herroepen) certificaten (X.509v3) te heroverwegen.
Oplossingsrichting	Het afsprakenstelsel MedMij wil bij voorkeur toekomstvast zijn in de gestelde eisen. Dit is een argument voor een hoger abstractie niveau (scenario 1) in beschrijving in het afsprakenstelsel. Een hoger abstractie niveau betekent dat het acceptatie proces in de praktijk met meer verschillende oplossingen/foutmeldingen moet kunnen werken. Dit vergt meer van het acceptatieproces. Dit is een argument om de controle op meer detailniveau te beschrijven en dus voor scenario 2. OCSP is mede ontwikkeld omdat CRL lijsten vanwege de lengte onwerkbaar werden. Echter de lengte van de CRL lijsten binnen PKI.Overheid zijn bescheiden. Dit is een argument om zowel OCSP als CRL toe te staan. PKI.Overheid stelt CRL verplicht en maakt OCSP optioneel voor Trust Service Providers (TSP ook wel Certificate Authorities (CA’s) genoemd). Voor Extended Validation (EV) is OCSP wel verplicht. In de opzet van het afsprakenstelsel MedMij is de PKI.Overheid EV Root echter nog niet vertrouwd. Het ligt voor de hand om vanuit het afsprakenstelsel de richtlijnen van PKI.Overheid te volgen. Dit is een argument om CRL ook toe te staan. Het primaire mechanisme binnen MedMij om te bepalen welke nodes met elkaar mogen communiceren is de Whitelist (WHL). Het intrekken van certificaten is voor MedMij Beheer een minder rechtstreeks mechanisme wat waarschijnlijk trager werkt bij incidenten dan de Whitelist. Omdat het een secundair mechanisme betreft ligt het voor de hand om het op een hoger niveau te beschrijven. Dit is een argument voor scenario 1. Samenvattend zijn er twee argumenten om zowel CRL als OCSP toe te staan twee argumenten voor scenario 1 en één argument voor scenario 2. Het toestaan van zowel CRL als OCSP is het makkelijkst in scenario 1. Hierdoor wordt het advies om scenario 1 uit te werken.
Aanpassing van	De huidige versie (1.1.2) van het afsprakenstelsel vereist het volgende: 6a. 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, op basis van OCSP, of het ontvangen certificaat geldig is. In geval van het falen van één van deze controles, of het uitblijven van een controleresultaat, wordt het certificaat niet geaccepteerd en de TLS-sessie niet gestart. Zie https://vzvz.atlassian.net/wiki/display/PUBLIC/Netwerk
Impact op rollen	Alle nodes van MedMij deelnemers
Impact op beheer
Gerelateerd aan (Jira issues)	AF-706, 530, 819, 1105, 996, 1107
Eigenaar	Johan Hobelman
Implementatietermijn
Motivatie verkorte RFC procedure (patch)

Goedkeuring

Beoordelaar	Datum	Reactie	Toelichting
Productmanager
Ontwerpteam
?

Principe's

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

Uitwerking

Op pagina Netwerk aanpassen:

6a Wanneer door een TLS-client of een TLS-server een certificaat ontvangen wordt dan MOET er gecontroleerd worden of het certificaat niet ingetrokken is. Deze controle MOET plaatsvinden door middel van een CRL of een OCSP antwoord. Het OCSP antwoord MAG vastgeniet zitten (zogenaamd OCSP stapling) aan het certificaat.
Wanneer het certificaat ingetrokken is dan MOET de TLS sessie beëindigd worden en er MAG NIET een inhoudelijke verwerking van data plaatsvinden.

Voorstel toelichtingstekst: Het vastnieten van een OCSP antwoord aan het certificaat is toegestaan in het afsprakenstelsel MedMij. De andere kant van de TLS communicatie mag dit OCSP antwoord gebruiken maar kan de controle of het certificaat ingetrokken is ook op een andere manier uitvoeren.

Wanneer er gekozen is om de controle alleen via OCSP uit te voeren kan het incidenteel voorkomen dat een OCSP responder geen of niet tijdig een antwoord geeft. In dat geval kan teruggevallen worden op de whitelistcontrole die het MedMij afsprakenstelsel primair gebruikt om te bepalen of nodes elkaar mogen benaderen.

PKI.Overheid is binnen MedMij verplicht. Voor alle eisen gerelateerd aan PKIO certificaten wordt naar het programma van eisen van PKI.Overheid gekeken (https://www.logius.nl/diensten/pkioverheid/aansluiten-als-tsp/pogramma-van-eisen )

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.

Bijlagen

	Bestand	Gewijzigd

MedMij Change Management