Versions Compared

Old Version 3

changes.mady.by.user Former user

Saved on

compared with

New Version Current

changes.mady.by.user Johan Hobelman

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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://afsprakenstelselvzvz.medmijatlassian.nlnet/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)


...

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. << optie: beschrijven foutmeldingen, hier of in de toelichting? >> 

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 )

...