Document toolboxDocument toolbox

RFC0034 Wijziging eisen aan PKIo root certificaten (1.1.2)

Samenvatting

Waarom is deze RFC nodig?

Het CA/Browser Forum constateerde in juli wereldwijd 293 intermediate server certificaten niet aan de Baseline Requirements voldoen. Servercertificaten missen een extensie die volgens de richtlijnen wel aanwezig moet zijn: “id-pkix-ocsp-nocheck”. De lijst bevat ook 29 PKIoverheid intermediate certificaten die door Logius zijn uitgegeven. Logius heeft met NCSC en certificaatverstrekkers (TSP’s) actieplan opgesteld om de certificaten weer aan de richtlijn te laten voldoen en aan het CA/Browser Forum voorgelegd. In plaats van certificaten intrekken worden certificaten opnieuw uitgegeven op basis van dezelfde sleutel (CSR), met de juiste instellingen. Gevolg is dat eindgebruikerscertificaten vervangen moeten worden; voor MedMij deelnemers en beheerorganisatie betekent dit dat alle G3 certificaten moeten worden vervangen.
De 'G3 boom' wordt vervangen door de nieuwe 'Extended Validation boom'; daarnaast wil Logius in het kader van functiescheiding dat voor M2M toepassingen private certificates uit de G1 boom toegepast gaan worden. 

Oplossingsrichting

In MedMij werden tot nu toe alleen PKIoverheid certificaten van de G3 boom toegestaan (G2 boom was al eerder opgeheven). Om in lijn te komen met de nieuwe Logius richtlijnen, moeten zowel certificaten uit de volgende bomen opgenomen worden in de trust stores van deelnemers en beheerorganisatie: G3 (zijn al opgenomen), EV (vervanging van G3) én G1 (vervanging van G3 op backchannel).

Idealiter wordt deze verruiming zodanig verwoord dat MedMij zich conformeert en verwijst naar eisen die Logius PKI-Overheid stelt (in plaats van zelf expliciete uitspraken daarover op te nemen in het AS).

Aanpassing van

Afsprakenstelsel eisen 

Impact op rollen

DVP, DVZA, beheerorganisatie

Impact op beheer

Coördineren van de certifcaat-wissel (buiten scope RFC)

Impact op RnA

Aanpassing van de truststore op alle nodes

Impact op Acceptatie

Aanpassing van de truststore op alle test omgevingen

Gerelateerd aan (Andere RFCs, PIM issues)
Eigenaar
Implementatietermijn

1 oktober: NB ook toepassen op 1.1.2 en 1.2.0!

Motivatie verkorte RFC procedure (patch)

Eis vanuit Logius en CA/browser forum. Niet voldoen betekent dat er gewerkt gaat worden met ongeldige certificaten.

Goedkeuring

BeoordelaarDatumToelichtingBeoordelaarDatumToelichting
Productmanager Stichting MedMij

Productmanager Beheerorganisatie

Leadarchitect Stichting MedMij

Leadarchitect Beheerorganisatie

Ontwerpteam




Deelnemersraad

Eigenaarsraad

Principe's

Principe
Principe

1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal

Neutraal

11 Stelselfuncties worden vanaf de start ingevuld

Neutraal

2 Dienstverleners zijn transparant over de gegevensdiensten 

Neutraal

12 Het afsprakenstelsel is een groeimodel

Neutraal

Dienstverleners concurreren op de functionaliteiten

Neutraal

13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders

Neutraal

Dienstverleners zijn aanspreekbaar door de gebruiker

Neutraal

14 Uitwisseling is een keuze

Neutraal

De persoon wisselt gegevens uit met de zorgaanbieder

Neutraal

15 Het MedMij-netwerk is gebruiksrechten-neutraal

Neutraal

MedMij spreekt alleen af wat nodig is

Positief

16 De burger regisseert zijn gezondheidsinformatie als uitgever

Neutraal

De persoon en de zorgaanbieder kiezen hun eigen dienstverlener

Neutraal

17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld

Neutraal

De dienstverleners zijn deelnemers van het afsprakenstelsel

Neutraal

18 Afspraken worden aantoonbaar nageleefd en gehandhaafd

Neutraal

10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling

Neutraal

19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat

Neutraal

Uitwerking

Op pagina /wiki/spaces/MedMijAfsprakenstelsel120/pages/135105065 aanpassen:

6c. Met inachtneming van verantwoordelijkheid 6a, accepteren ZA Node,PGO NodeenMedMij Stelselnodezowel G2- als G3-certificaten PKIoverheid certficaten van elkaar door:

  • alle root-certificaten te vertrouwen zoals gepubliceerd op https://cert.pkioverheid.nl/;
    • waarvan de geldigheidsdatum niet is verlopen en die NIET zijn ingetrokken;
    • met uitzondering van de onderstaande root certificaten (deze zijn NIET toegestaan): 
      • de zogenaamde 'TEST' certificaten
      • Alle roots gemarkeerd met 'Persoon'
  • deelnemers moeten alle valide domein en TSP certificaten onder PKIo hiërarchie opnemen in de truststore; zie hiervoor https://cert.pkioverheid.nl/;
    • met uitzondering van (deze roots moeten NIET opgenomen worden):
      • Organisatie Persoon
      • Burger
      • Autonome apparaten
      • Private Personen
    • ook de zogenaamde intermediate-certificaten moeten worden opgenomen in de truststore
  • de root-certificatenStaat der Nederlanden Root CA - G2 en Staat der Nederlanden Root CA - G3, zoals gepubliceerd ophttps://cert.pkioverheid.nl, te vertrouwen;
  • allePKIoverheid TSP-en domeincertificaten onder de respectievelijke G2- en G3-hiërarchieën te herkennen en te vertrouwen, voor zover zij volgens https://cert.pkioverheid.nl:
    • onder het G3-Domein Organisatie Services vallen en van het type Server zijn, of onder het G2-Domein Organisatie vallen;
    • niet ingetrokken zijn.
  • op G2 en G3 toepasselijke veranderingen op https://cert.pkioverheid.nl binnen tien werkdagen te verwerken en te hanteren.

Toelichting

PKIoverheid TSP'sgeven certificaten uit onder verschillende root-certificaten van de Staat der Nederlanden: een oude (G2) en een nieuwe (G3). De classificatie van soorten certificaten (domeinen) verschilt tussen G2 en G3. De geldigheid van G2-certificaten zal uiterlijk eindigen op 22 maart 2020. Hoewel er dus geen G2-certificaten meer kunnen worden uitgegeven met een geldigheid van drie jaar, moet het vooralsnog mogelijk zijn oudere G2-certificaten te gebruiken voor MedMij-doeleinden. Waar PKIoverheid-certificaten moet worden geaccepteerd, moeten die dus G2- of G3-certificaten kunnen zijn. Het MedMij Afsprakenstelsel heeft geen redenen extra beperkingen op te leggen ten opzichte van hoe PKIoverheid de transitie van G2 naar G3 maakt.

Verantwoordelijkheid 6c komt overeen met eisen dienaangaande van hetAfsprakenstelsel eHerkenning, met dien verstande dat in het MedMij Afsprakenstelsel EV-certificaten niet te hoeven worden geaccepteerd. In de uitgebreidere validatie van certificaathouders waarvan sprake is bij EV-certificaten, wordt voorzien in het acceptatieproces van deelnemers in het MedMij Afsprakenstelsel.

  • "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:
    • Stamcertificaat
      • Staat der Nederlanden EV Root CA
    • Intermediair Domein Server CA 2020
      • QuoVadis PKIoverheid Server CA 2020
      • Digidentity PKIoverheid Server CA 2020
      • KPN PKIoverheid Server CA 2020
  • Voor alle backchannel verkeer (machine2machine) moeten deelnemers een PKIoverheid-certificaat van het type 'privaat' toepassen, uitgegeven door de volgende keten en/of opvolgende generaties:
    • Private Root CA (per medio 2020 de standaard voor m2m)
      • Stamcertificaat
        • Staat der Nederlanden Private Root CA - G1
      • Domein Private Services, maar alleen de volgende:
        • Staat der Nederlanden Private Services CA - G1
        • KPN PKIoverheid Private Services CA - G1
        • QuoVadis PKIoverheid Private Services CA - G1
        • Digidentity BV PKIoverheid Private Services CA - G1

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.

6d. 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).


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.

DreigingKansImpactDreigingsID (intern)Maatregelen
Verstoring in de dienstverlening door niet afgestemde uitvoering door individuele deelnemersr

H

H

Communicatie

Bijlagen

  File Modified
No files shared here yet.