Verantwoordelijkheden, Core | TLS en certificaten
| Al het verkeer over het MedMij-netwerk is beveiligd en versleuteld met Transport Layer Security (TLS). | core.tls.300 |
| Er wordt gebruikgemaakt van TLS-versies en -algoritmen die zijn geclassificeerd als "goed" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 van het NCSC. Indien meerdere TLS-versies als "goed" geclassificeerd zijn, moet minimaal de laagste TLS-versie worden ondersteund. Hogere TLS-versies mogen worden aangeboden. | core.tls.301 |
| Van verantwoordelijkheid core.tls.301 kan in het MedMij Afsprakenstelsel worden afgeweken, indien dit expliciet benoemd wordt in nadere eisen binnen de afsprakenset. | core.tls.302 |
| Gebruik van TLS False Start is verboden. Toelichting | core.tls.303 |
| Bij de TLS-handshake moet de hoogste toegestane TLS-versie gekozen worden die beide partijen ondersteunen. | core.tls.304 |
| Als invulling van core.tls.302 geldt, in afwijking van core.tls.301: TLS 1.2 moet door elke deelnemer ondersteund worden. TLS 1.3 moet door elke deelnemer ondersteund worden, indien redelijkerwijs mogelijk.
TLS 1.2 TLS 1.3 wordt in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 van het NCSC als enige met "goed" geclassificeerd. Daarmee is dit de enige TLS-versie die volgens eis 1b ondersteund mag worden. Bij deze release van dit afsprakenstelsel kan TLS 1.3 niet door alle deelnemers ondersteund worden, omdat dit niet wordt aangeboden in door sommigen gebruikte componenten. Daarom maken we gebruik van de mogelijkheid die regel 1c biedt om een afwijkende regeling te treffen. De afwijkende regeling bestaat eruit dat TLS 1.3 door iedere deelnemer aangeboden moet worden, indien redelijkerwijs mogelijk. Om redenen van interoperabiliteit moet iedere deelnemer TLS 1.2 blijven ondersteunen. Het voornemen is deze afwijking te schrappen zodra TLS 1.3 breed ondersteund wordt, waardoor verantwoordelijkheid 1b weer onverkort geldt en TLS 1.3 de enige toegestane versie wordt. Dit kan al dan niet met behulp van een snel door te voeren patch op het MedMij Afsprakenstelsel.
| core.tls.305 |
| 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. | core.tls.314 |
| 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: 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: De ‘private key’ moet worden gegenereerd op het doelplatform waar het PKI certificaat wordt toegepast. Bij gebruik van publieke PKI certificaten is de toepassing van ‘Certification Authority Authorization Resource Record’ vereist. 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. Het gebruik van wildcard certificaten wordt niet toegestaan. 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: 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. De uitgever van de PKI certificaten is verantwoordingsplichtig aan de AVG en/of GDPR.
Beheer: Veilig beheer moet zijn toegepast zoals toegelicht in ‘Factsheet Veilig beheer van digitale certificaten’.
| core.tls.315 |
| Alle certificaathouders verbinden zich aan de op hen toepasselijke eisen van het PKI-stelsel waarvan zij een certificaat afnemen. Een organisatie mag meerdere certificaten hebben. Toelichting Alle certificaathouders verbinden zich aan de op hen toepasselijke eisen van het PKI-stelsel waarvan zij een certificaat afnemen. Een organisatie mag meerdere certificaten hebben. De keuze voor de PKI-standaard past bij principe 19 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 de beveiliging van al het backchannel-verkeer 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 voor private G1 certificaten van PKIoverheid. Deelnemers in het MedMij Afsprakenstelsel zullen dus service-certificaten moeten betrekken bij een bij PKIoverheid aangesloten TSP die bij haar past. | core.tls.307 | 10. | Tijdens de handshake van TLS, wordt door de TLS-server in de server hello-stap aan de TLS-client: in geval van backchannel-verkeer, altijd een verzoek om een certificaat gedaan. Indien de TLS-client daarop geen certificaat overlegt, wordt de handshake onmiddellijk afgebroken. in geval van frontchannel-verkeer, nooit een verzoek om een certificaat gedaan.
Bij backchannel-verkeer vindt dus twee-wegauthenticatie plaats, bij frontchannel-verkeer een-wegauthenticatie. | core.tls.308 | 11. | Alle Backchannel Nodes 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. | core.tls.309 | 12. | In geval van het gebruik van OCSP in het kader van verantwoordelijkheid core.tls.309 mag de OCSP response vastgeniet zitten aan het certificaat (OCSP Stapling). Omdat het vastnieten van OCSP-antwoorden (stapling) is toegestaan, zal iedere Node welke een certificaat moet controleren het vastnieten in zoverre moeten ondersteunen dat het alleen het feit dat er een vastgeniet OCSP antwoord gebruikt wordt niet mag leiden tot een foutmelding of het anderszins plots beëindigen van de TLS handshake of sessie. Toelichting Het laten vastnieten van een OCSP-antwoord aan het certificaat is toegestaan in het Afsprakenstelsel MedMij. De ontvanger mag dit OCSP-antwoord gebruiken maar kan de controle of het certificaat ingetrokken is ook op een andere manier uitvoeren. Wanneer ervoor gekozen is om de controle alleen via OCSP uit te voeren kan het voorkomen dat een OCSP responder geen of niet tijdig een antwoord geeft. In dat geval kan ervoor gekozen worden om de TLS sessie toch op te zetten (soft-fail). Het primaire mechanisme binnen het MedMij Afsprakenstelsel om te bepalen of nodes elkaar mogen benaderen is de Whitelist-controle.
Voor alle eisen gerelateerd aan PKIoverheid-certificaten, zie https://www.logius.nl/domeinen/toegang/aansluiten-als-trust-service-provider . | core.tls.310 | 13. | Met inachtneming van verantwoordelijkheid core.tls.309, accepteren Backchannel Nodes PKIoverheid certficaten van elkaar door het stamcertificaat van de hiërarchie 'Staat der Nederlanden Private Root CA - G1', zoals gepubliceerd op https://cert.pkioverheid.nl/ , te vertrouwen, zolang de geldigheidsdatum niet is verlopen en het stamcertificaat NIET is ingetrokken;
Uitzondering Tot 4 december 2022 moeten alle Deelnemers ook de certificaten uit de hiërarchie 'Staat der Nederlanden EV', zoals gepubliceerd op https://cert.pkioverheid.nl/ , accepteren. Dit doen zij door ook van deze hiërarchie het stamcertificaat te vertrouwen. Na 4 december 2022 mag dit stamcertificaat niet meer vertrouwd worden.
| core.tls.311 | 14. | PKI-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). | core.tls.313 |
| TLS en certificaten
| Al het verkeer over het MedMij-netwerk is beveiligd en versleuteld met Transport Layer Security (TLS). | core.tls.300 |
| Er wordt gebruikgemaakt van TLS-versies en geassocieerde configuratieparameters, zoals algoritmen, die zijn geclassificeerd als "goed" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 TLS richtlijnen versie mei 2025 van het NCSC. Indien meerdere TLS-versies als "goed" geclassificeerd zijn, moet minimaal de laagste TLS-versie worden ondersteund. Hogere TLS-versies mogen worden aangeboden. | core.tls.301 |
| Van verantwoordelijkheid core.tls.301 kan in het MedMij Afsprakenstelsel worden afgeweken, indien dit expliciet benoemd wordt in nadere eisen binnen de afsprakenset. | core.tls.302 | 4. | Gebruik van TLS False Start is verboden. | core.tls.303 | 5. | Bij de TLS-handshake moet de hoogste toegestane TLS-versie gekozen worden die beide partijen ondersteunen. | core.tls.304 | 6. | Als invulling van core.tls.302 geldt, in afwijking van core.tls.301: TLS 1.2moet door elke deelnemer ondersteund worden.
TLS 1.3 moet door elke deelnemer ondersteund worden. TLS 1.2 moet door elke client ondersteund worden. TLS 1.2 mag door elke server ondersteund worden. TLS 1.3 moet door elke deelnemer ondersteund worden, indien redelijkerwijs mogelijk.
TLS 1.2
TLS 1.3 wordt in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 door het NCSC als enige met "goed" geclassificeerd. Daarmee is dit de enige TLS-versie die volgens eis 1b ondersteund mag worden. Bij deze release van dit afsprakenstelsel kan TLS 1.3 niet door alle deelnemers ondersteund worden, omdat dit niet wordt aangeboden in door sommigen gebruikte componenten. DaaromOmdat het uitfaseren van TLS 1.2 mogelijk disruptief is voor ons netwerk maken we tijdelijk nog gebruik van de mogelijkheid die regel 1c biedt om een afwijkende regeling te treffen. De afwijkende regeling bestaat eruit dat TLS 1.3 door iedere deelnemer aangeboden moet worden, indien redelijkerwijs mogelijk. alle deelnemers TLS 1.3 zo snel mogelijk implementeren, maar clients nog wel TLS 1.2 moeten ondersteunen. Om redenen van interoperabiliteit moet iedere deelnemer TLS 1.2 blijven ondersteunen. MedMij is van plan door middel van logging & testen TLS 1.2 gedurende 2026 gefaseerd uit te schakelen op het netwerk. Het voornemen is deze afwijking te schrappen zodra TLS 1.3 breed ondersteund wordt, waardoor Hierna geldt verantwoordelijkheid 1b weer onverkort geldt en is TLS 1.3 de enige toegestane versie wordt. Dit kan al dan niet met behulp van een snel door te voeren patch op het MedMij Afsprakenstelsel.
| core.tls.305 | | 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.
| core.tls.314
| 7. | 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: 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: De ‘private key’ moet worden gegenereerd op het doelplatform waar het PKI certificaat wordt toegepast. Bij gebruik van publieke PKI certificaten is de toepassing van ‘Certification Authority Authorization Resource Record’ vereist. 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. Het gebruik van wildcard certificaten wordt niet toegestaan. 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: 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. De uitgever van de PKI certificaten is verantwoordingsplichtig aan de AVG en/of GDPR.
Beheer: Veilig beheer moet zijn toegepast zoals toegelicht in ‘Factsheet Veilig beheer van digitale certificaten’.
| core.tls.315 | 8. | Alle certificaathouders verbinden zich aan de op hen toepasselijke eisen van het PKI-stelsel waarvan zij een certificaat afnemen. Een organisatie mag meerdere certificaten hebben. Toelichting Alle certificaathouders verbinden zich aan de op hen toepasselijke eisen van het PKI-stelsel waarvan zij een certificaat afnemen. Een organisatie mag meerdere certificaten hebben. De keuze voor de PKI-standaard past bij principe 19 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 de beveiliging van al het backchannel-verkeer 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 onder meer 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 voor private G1 certificaten van PKIoverheid. Deelnemers in het MedMij Afsprakenstelsel zullen dus service-certificaten moeten betrekken bij een bij PKIoverheid aangesloten TSP die bij haar past. | core.tls.307 | 9. | Tijdens de handshake van TLS, wordt door de TLS-server in de server hello-stap aan de TLS-client: in geval van backchannel-verkeer, altijd een verzoek om een certificaat gedaan. Indien de TLS-client daarop geen certificaat overlegt, wordt de handshake onmiddellijk afgebroken. in geval van frontchannel-verkeer, nooit een verzoek om een certificaat gedaan.
Bij backchannel-verkeer vindt dus twee-wegauthenticatie plaats, bij frontchannel-verkeer een-wegauthenticatie. | core.tls.308 | 10. | Alle Backchannel Nodes valideren tijdens de TLS-handshake bij backchannel-verkeer aan het begin van een TLS-sessie of het ontvangen certificaat op het MedMij-netwerk toegestaan is (zie core.tls.311).een PKIoverheid-certificaat is en Daarnaast controleren zij 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 Indien de controle faalt wordt het certificaat niet geaccepteerd en wordt de TLS-sessie niet gestart.
CRL`- lijsten voor PKIoverheid-certificaten zijn te vinden op https://crl.pkioverheid.nl/ en in het ‘X509v3 CRL Distribution Points’ veld in het ontvangen certificaat.
| core.tls.309 | 11. | In geval van het gebruik van OCSP in het kader van verantwoordelijkheid core.tls.309 mag de OCSP response vastgeniet zitten aan het certificaat (OCSP Stapling). Omdat het vastnieten van OCSP-antwoorden (stapling) is toegestaan, zal iedere Node welke een certificaat moet controleren het vastnieten in zoverre moeten ondersteunen dat het alleen het feit dat er een vastgeniet OCSP antwoord gebruikt wordt niet mag leiden tot een foutmelding of het anderszins plots beëindigen van de TLS handshake of sessie. Toelichting Het laten vastnieten van een OCSP-antwoord aan het certificaat is toegestaan in het Afsprakenstelsel van MedMij. De ontvanger mag dit OCSP-antwoord gebruiken maar kan de controle of het certificaat ingetrokken is ook op een andere manier uitvoeren. Wanneer ervoor gekozen is om de controle alleen via OCSP uit te voeren kan het voorkomen dat een OCSP responder geen of niet tijdig een antwoord geeft. In dat geval kan ervoor gekozen worden om de TLS sessie toch op te zetten (soft-fail). Het primaire mechanisme binnen het MedMij Afsprakenstelsel om te bepalen of nodes elkaar mogen benaderen is de Whitelist-controle. Voor alle eisen gerelateerd aan PKIoverheid-certificaten, zie https://www.logius.nl/domeinen/toegang/aansluiten-als-trust-service-provider . | core.tls.310 | 12. | Met inachtneming van verantwoordelijkheid core.tls.309, accepteren Backchannel Nodes enkel PKIoverheid certificaten voor backchannel-verkeer op het MedMij-netwerk. Hierbij zijn alleen certificaten die bestemd zijn voor server authenticatie (machine-to-machine, internal connections) toegestaan en waarvoor de Extended Key Usage (EKU) de waarde ‘TLS Web Server Authentication’ bevat. Daarnaast moet het ontvangen certificaat nog geldig zijn en moet het stamcertificaat NIET zijn ingetrokken. van elkaar door het stamcertificaat van de hiërarchie 'Staat der Nederlanden Private Root CA - G1', zoals gepubliceerd op https://cert.pkioverheid.nl/ , te vertrouwen, zolang de geldigheidsdatum niet is verlopen en het stamcertificaat NIET is ingetrokken; Uitwisseling is alleen toegestaan als het ontvangen certificaat direct getekend is door, of in haar certificate chain heeft, een van de volgende stamcertificaten:
Certificaten die niet aan bovenstaande eisen voldoen moeten expliciet worden geweigerd. Uitzondering
Tot 4 december 2022 moeten alle Deelnemers ook de certificaten uit de hiërarchie 'Staat der Nederlanden EV', zoals gepubliceerd op https://cert.pkioverheid.nl/ , accepteren. Dit doen zij door ook van deze hiërarchie het stamcertificaat te vertrouwen. Na 4 december 2022 mag dit stamcertificaat niet meer vertrouwd worden.
| core.tls.311 | 13. | PKI-certificaten moeten (in ieder geval op productie en acceptatieomgevingen) als complete keten inclusief alle intermediate certificaten worden verstuurd en gecontroleerd. Een certificaatketen 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). | core.tls.313 |
|
