...
...
...
...
...
...
1. Inleiding
PKIOverheid stopt per 4 december 2022 met het aanbieden van publiek vertrouwde certificaten. Bij al het frontchannel verkeer binnen MedMij, alsmede mogelijk bij een deel van het backchannel verkeer, wordt gebruiktgemaakt van deze publiek vertrouwde (EV) certificaten. De beveiliging van het MedMij-verkeer moet op orde zijn, om ervoor te zorgen dat gegevens niet uitlekken. Daarom moeten nieuwe richtlijnen worden opgesteld.
Deze uitwerking is gekoppeld aan AF-1273.
2. Advies
In de discussie worden twee niveaus van certificaten besproken, namelijk Domain Validated (DV) en Organisation Validated (OV). De twee nog hogere niveaus, Extended Validated (EV) en Qualified Website Authentication Certificate (QWAC), zijn buiten scope gehouden, omdat VWS OV voorschrijft. Betreffende de certificaten moet antwoord worden gegeven op twee vragen:
Welk niveau van certificaten vereisen we binnen het MedMij netwerk?
Voor frontchannel-verkeer vereisen wij, in navolging op VWS, het gebruik van OV-certificaten van aanbieders die voldoen aan de regels vanuit AVG (GDPR).Mag er gebruikgemaakt worden van wildcard certificaten?
Nee, wildcard-certificaten mogen niet gebruikt worden.
2.1. Welk niveau van certificaten vereisen we binnen het MedMij netwerk?
Team ontwikkeling adviseert Product management te vereisen dat gebruik wordt gemaakt van OV-certificaten voor frontchannel-verkeer. We zijn ons ervan bewust dat we hiermee ingaan tegen de wens van de (een aantal) deelnemers. Team ontwikkeling heeft de verschillende opties vergeleken in is tot deze conclusie gekomen met de volgende redenen:
Strenge eisen betreffende privacy en informatiebeveiliging (veiligheid, betrouwbaarheid)
Panel borderColor black bgColor WhiteSmoke borderWidth 1px borderStyle solid In het MedMij netwerk worden persoonlijke, privacygevoelige gegevens uitgewisseld. Volgens MedMij is een hoog niveau van informatiebeveiliging van belang voor het vertrouwen in het netwerk. Hier zijn regels voor opgesteld, zie bijvoorbeeld Privacy- en informatiebeveiligingsbeleid. Om het risico op vertrouwensschade te beperken, is Domain Validation niet voldoende. De mogelijkheden tot bijvoorbeeld phishing moeten ingeperkt worden, hier dragen de OV-certificaten aan bij. Eindgebruikers kunnen door het gebruik van OV-certificaten beter controleren een partij te betrouwbaar is, waardoor zij minder snel in de trucs van phishing trappen. Dienstverleners hebben hier zelf veel baat bij, omdat het risico op datalekken verkleind wordt.
Situatie vergelijkbaar met financiële sector
Panel borderColor black bgColor WhiteSmoke borderWidth 1px borderStyle solid Ondanks dat er in de zorg (nog) geen verplichting is voor het gebruik van certificaten van een hoger niveau, kan de vergelijking worden gelegd met de financiële sector. De privacygevoeligheid van uitgewisselde gegevens is binnen het MedMij netwerk is vergelijkbaar met, zo niet hoger dan de uitgewisselde gegevens in de financiële sector. Banken zijn mede door de privacygevoeligheid van gegevens verplicht gebruik te maken van EV-certificaten, een hoger niveau dan OV. De zorgsector en MedMij moeten wel voldoen aan de AVG en de NEN7510/NEN7512. Zo vereist de AVG bijvoorbeeld:
- Duidelijk aanwijsbare en gecommuniceerde verantwoordelijke voor de gegevensverwerking (een organisatie).
- Passende beveiliging
Vragen en opmerkingen:
- Tijdens de expertgroepsessie van 13 januari 2022 werd aangegeven dat het gebruik van OV-certificaten te hanteren is in stelsels met weinig deelnemers. Zo was standpunt dat deze eisen in de financiële sector mogelijk zijn door het lage aantal banken, maar dat in een stelsel als MedMij niet houdbaar is. Volgens MedMij gaat het niet om het aantal organisaties die aan de eisen moeten voldoen, maar om de redenen achter de eis. Betrouwbaarheid is een belangrijk goed in een afsprakenstelsel als MedMij, daar horen passende maatregelen bij. Het gebruik van OV-certificaten hoort hierbij. Daarnaast gaat de vergelijking met het aantal partijen niet op. Er zijn alleen al 40+ Nederlandse banken, die allen aan zwaardere eisen moeten voldoen.
Authenticatie van beide partijen
Panel borderColor black bgColor WhiteSmoke borderWidth 1px borderStyle solid Een hoog niveau van informatiebeveiliging vereist sterke authenticatie van eindgebruiker én de aanbieder van de dienst. De aanbieder moet de eindgebruiker kunnen authenticeren, zodat voldoende zeker is dat de eindgebruiker is wie hij/zij zegt te zijn. De eindgebruiker moet ook de aanbieder kunnen authenticeren. Bij een webapplicatie wordt een aanbieder geauthenticeerd op basis van het gebruikte domein en het bijbehorende certificaat. Hierbij is minimaal een OV-certificaat noodzakelijk, omdat een DV-certificaat deze informatie niet bevat.
- Het standpunt van de deelnemers is dat niemand hier naar kijkt. Het klopt waarschijnlijk dat de meeste eindgebruikers nooit of nauwelijks op het slotje klikken om de details van de beveiliging op te vragen. Maar, moet je de beperkte groep de mogelijkheid volledig ontzeggen, omdat de meerderheid hier geen gebruik van maakt? Met het oog op het gewenste betrouwbaarheidsniveau moet deze mogelijkheid geboden worden aan personen die privacy hoog in het vaandel hebben staan.
OV verplicht volgens VWS, DV acceptabel volgens NCSC en Logius
Panel borderColor black bgColor WhiteSmoke borderWidth 1px borderStyle solid VWS geeft in de beleidslijnen aan dat OV-certificaten het minimaal te gebruiken niveau is voor de beveiliging van webapplicaties. NCSC (en tevens Logius) stelt dat DV-certificaten voldoen voor openbare websites en de meeste andere toepassingen van webcertificaten. Tevens stellen zij dat de meerwaarde van OV-certificaten beperkt is voor toepassingen waarbij een lager niveau geaccepteerd is. VWS stelt zorgspecifieke regels op, NCSC en Logius werken meer vanuit algemene context. Daarom kiezen wij de VWS beleidslijnen aan te houden.
- De verwijzing van de deelnemers naar de NCSC factsheets klopt. Echter kan de tekst op verschillende manieren worden geïnterpreteerd. Zoals de deelnemers de tekst lezen, staat er dat OV-certificaten geen meerwaarde hebben en dat DV voldoet. Er staat in de tekst:
"De meerwaarde van een OV-, EV- of QWAC-certificaat is daarmee beperkt voor toepassingen waar een lager niveau, zoals DV, ook geaccepteerd wordt". Het gaat om deze acceptatie. De meerwaarde van OV, de mogelijkheid van authenticatie van de eigenaar van het certificaat, is volgens Team ontwikkeling noodzakelijk. Ook al wordt er maar beperkt gebruik van gemaakt, toch moet een eindgebruiker de andere partij kunnen identificeren. Daarom kan in het MedMij netwerk het lagere niveau van DV niet worden geaccepteerd.
- De verwijzing van de deelnemers naar de NCSC factsheets klopt. Echter kan de tekst op verschillende manieren worden geïnterpreteerd. Zoals de deelnemers de tekst lezen, staat er dat OV-certificaten geen meerwaarde hebben en dat DV voldoet. Er staat in de tekst:
Proces versus certificaten
Panel borderColor black bgColor WhiteSmoke borderWidth 1px borderStyle solid De doeleinden van het proces (kwalificatie en acceptatie, audits) en het gebruik van certificaten lijken hetzelfde, maar zijn anders. Beiden hebben te maken met de authenticatie van de deelnemers van MedMij. Het proces laat MedMij de partij authenticeren, zodat uiteindelijk het MedMij label kan worden uitgegeven en daarmee bewijst aan de eisen van MedMij te voldoen. Hiermee is voor een eindgebruiker niet te zeggen welke organisatie eigenaar is van een webapplicatie. Authenticatie van de organisatie door de eindgebruiker kan dan ook niet uitgevoerd worden op nadat deze organisatie door MedMij is gekwalificeerd en geaccepteerd. Dat kan alleen door het gebruik van de juiste certificaten en de zekerheid die dit met zich meebrengt.
Reactie op overige vragen en standpunten deelnemers
Panel borderColor black bgColor WhiteSmoke borderWidth 1px borderStyle solid - Volgens deelnemers hebben we te maken met een schijnzekerheid, omdat de eindgebruiker niet weet welke systemen er gebruikt worden. Als bijvoorbeeld een proxy als voordeur gebruikt wordt, kunnen er allerlei verschillende systemen achter staan. Deze stelling klopt. Maar, wat er achter de voordeur gebeurt, dat is de verantwoordelijkheid van de eigenaar van de webapplicatie. Door de eindgebruiker de mogelijkheid te geven te kunnen controleren van wie de voordeur is, weet hij ook wie de verantwoordelijkheid draagt.
- Een aantal deelnemers geeft aan dat in de huidige situatie al gebruikgemaakt wordt van DV-certificaten van Lets Encrypt. Dit is tegen de huidige regels en in de nieuwe situatie tegen de beleidslijnen van VWS. Deze stellen dat de leverancier van certificaten in de zorgsector verantwoordingsplichtig moeten zijn aan de AVG of GDPR en hiermee dus in de EU gevestigd moeten zijn. Lets Encrypt is een Amerikaanse organisatie.
2.2. Mag er gebruikgemaakt worden van wildcard certificaten?
Team ontwikkeling adviseert Product management het gebruik van wildcards niet toe te staan. Hiervoor heeft Team ontwikkeling de volgende redenen.
De VWS beleidslijnen verbieden het gebruik van wildcard-certificaten.
Een wildcard certificaat is onwenselijk, omdat hiermee risico tot diefstal en misbruik wordt vergroot.
...
3. Input
Memo beleid discontinueren uitgifte pkio publieke server certificaten
Uitfasering pkio webcertificaten, wat moet u doen voor digid
https://certificaat.kpn.com/aanvragen/servercertificaten/publieke-tls-servercertificaten/
| View file | ||
|---|---|---|
|
...
3.1. Beleidslijnen VWS
Het nieuwe beleid zal de vereisten aan de PKI servercertificaten voor de zorgsector normeren op certificeringsvereisten voor de certificaatuitgevers, technische vereisten aan de certificaten en het niveau van zekerheid aan het proces op de uitgifte van de certificaten.
3.1.1. Publiek vertrouwde (publieke) certificaten
Voor burger-naar-zorgverlener contact is een publiek vertrouwd PKI certificaat noodzakelijk. Het nieuwe beleid zal de vereisten aan de PKI servercertificaten voor de zorgsector normeren op certificeringsvereisten voor de certificaatuitgevers, technische vereisten aan de certificaten en het niveau van zekerheid aan het proces op de uitgifte van de certificaten.
De (server)certificaten mogen worden geaccepteerd en gebruikt in de zorg wanneer deze voldoen aan de volgende eisen:
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 private certificaten moeten afkomstig zijn van PKI Overheid geaccrediteerde certificaat ketens.
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’.
Trust op zorgsystemen met systeem-systeem koppelingen al proactief de ‘Staat der Nederlanden Private Root CA - G1’ (te downloaden vanaf https://cert.pkioverheid.nl/) voor zover dat nog niet het geval is.
3.1.2. Niet publiek vertrouwde (private) certificaten
Voor ‘machine-to-machine’-koppelingen is de overstap naar een privaat PKIO certificaat een veilige overstap en logische overstap. Deze bieden een vergelijkbaar betrouwbaarheidsniveau en zijn nu drie jaar geldig.
De publieke certificaten kunnen ook toegepast worden voor ‘machine-to-machine’-koppelingen. Dat kan gemak opleveren in de uitrolfase met eveneens de operationele risico’s die voort kunnen komen uit de toepassing van publieke certificaten.
| Note |
|---|
De tekst bij de tweede bullet staat wel in de beleidslijnen van VWS, maar wordt niet overgenomen in het MedMij afsprakenstelsel. De eisen aan publieke certificaten en de aanbieders van deze certificaten zijn dusdanig veranderd, dat er geen beperkte lijst |
4. Mogelijke opties voor de toekomst
Verplichting voor minimaal OV certificaten
inclusief wildcards
exclusief wildcards
Mogelijk gebruik van DV certificaten
inclusief wildcards
exclusief wildcards
4.1. Beleidslijnen vanuit VWS
OV certificaten | OV wildcards certificaten | DV certificaten | DV wildcards certificaten | ||
|---|---|---|---|---|---|
1a | 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. | Op het moment van certificaat-uitgifte moet een leverancier aan deze eis voldoen. | |||
1b | De private certificaten moeten afkomstig zijn van PKI Overheid geaccrediteerde certificaat ketens. | Op het moment van certificaat-uitgifte moet een leverancier aan deze eis voldoen. | |||
2a | De ‘private key’ moet worden gegenereerd op het doelplatform waar het PKI certificaat wordt toegepast. | Op het moment van certificaat-uitgifte moet een leverancier aan deze eis voldoen. | |||
2b | Bij gebruik van publieke PKI certificaten is de toepassing van ‘Certification Authority Authorization Resource Record’ vereist. | Het gebruikte certificaat moet sowieso aan deze eis voldoen. | |||
2c | 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. | Op het moment van certificaat-uitgifte moet een leverancier aan deze eis voldoen. | |||
2d | Het gebruik van wildcard certificaten wordt niet toegestaan. | Niet mogelijk | Niet mogelijk | ||
2e | 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. | Het gebruikte certificaat moet sowieso aan deze eis voldoen. | |||
3a | 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. | Minimaal niveau | Niet mogelijk | Niet mogelijk | |
3b | De uitgever van de PKI certificaten is verantwoordingsplichtig aan de AVG en/of GDPR. | De leverancier van certificaten moet in een EU-land gevestigd zijn. | |||
4a | Veilig beheer moet zijn toegepast zoals toegelicht in ‘Factsheet Veilig beheer van digitale certificaten’. | Op het moment van certificaat-uitgifte moet een leverancier aan deze eis voldoen. | |||
4b | Trust op zorgsystemen met systeem-systeem koppelingen al proactief de ‘Staat der Nederlanden Private Root CA - G1’ (te downloaden vanaf https://cert.pkioverheid.nl/) voor zover dat nog niet het geval is. | Dit blijft zoals de huidige situatie, de uitzondering voor EV wordt verwijderd. | |||
4.2. Factsheet NCSC
OV certificaten | OV wildcards certificaten | DV certificaten | DV wildcards certificaten | ||
|---|---|---|---|---|---|
1 | Mate van controle bij uitgifte | De leverancier controleert het eigendom van de vermelde domeinnaam en de identiteit van de aanvrager. | De leverancier controleert het eigendom van de vermelde domeinnaam, maar niet de identiteit van de aanvrager. | ||
2 | Wijze waarop domeinnaam vermeld staat | Deze certificaten vermelden die identiteit van de aanvrager, zodat het voor de bezoeker van een website mogelijk is om op te vragen wie de eigenaar van de website is. | |||
3 | Stamcertificaat | ||||
4 | Te gebruiken voor | Openbare websites en de meeste andere toepassingen van webservercertificaten. | |||
5 | Meerwaarde | De meerwaarde van een OV-, EV- of QWAC-certificaat is beperkt voor toepassingen waar een lager niveau, zoals DV, ook geaccepteerd wordt. | |||
6 | Vermelding van domeinnamen | De domeinnamen waarvoor een certificaat geldt, staan vermeld in het Subject Alternative Name-veld. Voor verschillende toepassingen kunt u het beste ook verschillende certificaten gebruiken. | |||
7 | Gebruik wildcardcertificaten | In sommige toepassingen is van tevoren niet bekend welke subdomeinen er precies zullen worden aangeroepen, of wilt u niet dat deze subdomeinen openbaar worden. In zulke gevallen kunt u een wildcardcertificaat gebruiken. Dat is een certificaat dat voor alle subdomeinen van een domein tegelijk geldt. De vermelding is dan '*.example.nl'. Als u een wildcardcertificaat gebruikt, loopt u een iets groter risico dan bij een certificaat waar alle domeinnamen apart op staan. Een aanvaller die over de geheime sleutel beschikt, kan het immers ook gebruiken om andere toepassingen met een subdomein van die domeinnaam aan te vallen. Sommige certificaatleveranciers ondersteunen geen wildcardcertificaten. Overweegt u om een wildcardcertificaat te gebruiken, voer dan eerst een risicoanalyse uit. | |||
8 | Uitstraling | De meeste van uw bezoekers zullen weliswaar niet controleren wie uw webservercertificaat heeft uitgegeven, maar desondanks kan het voor u belangrijk zijn dat u hiervoor niet met zomaar een partij in zee gaat. | |||
9 | Leverancier | Voor het feitelijke veiligheidsniveau maakt het weinig uit, maar het kan voor uw bezoekers desondanks een geruststelling zijn als u een certificaat gebruikt dat bijvoorbeeld door een Nederlandse of Europese partij geleverd is. | |||
10 | Automatisering | Steeds meer certificaatleveranciers automatiseren het proces van domeinvalidatie en certificaatuitgifte, in het bijzonder bij de uitgifte van DV-certificaten. De bekendste standaard hiervoor is ACME, die is ontwikkeld en gepopulariseerd door certificaatleverancier Let's Encrypt. Het aantal leveranciers dat ACME ondersteunt is nog beperkt, maar het valt te verwachten dat dit de komende jaren zal groeien. | |||
4.3. Factsheet Logius
https://www.logius.nl/diensten/digid/documentatie/factsheet-dv-en-ov-certificaten-bij-digid
OV certificaten | OV wildcards certificaten | DV certificaten | DV wildcards certificaten | ||
|---|---|---|---|---|---|
1 | Webdienst | Toegestaan bij gebruik van een .nl domein Verplicht bij gebruik van een ander Top-Level-Domain Let op:
| Toegestaan bij gebruik van een .nl domein | ||
4.4. Vanuit de SSL/TLS community
DV | OV | |
|---|---|---|
Voordelen |
|
|
Nadelen |
|
|
Geschikt voor |
|
|
Controle |
|
|
5. Wijzigingen
De benodigde wijzigingen worden per versie van het afsprakenstelsel in een Patch of een RFC behandeld. Hierdoor ontstaan verantwoordelijkheden voor frontchannel-verkeer en voor backchannel-verkeer, waaraan alle deelnemers zich moeten houden.
RFC0064 (Patch), AF-1329 Gebruik publieke certificaten in afsprakenstelsel 1.4
RFC0065 (Patch), AF-1349 Gebruik publieke certificaten in afsprakenstelsel 1.5
6. Impact
6.1. Afsprakenstelsel
Binnen een jaar zijn de publieke certificaten van PKIoverheid niet meer te gebruiken. In het aankomende jaar wordt versie 1.4 ingetrokken, versie 1.5 verplicht en ingetrokken, versie 1.6 optioneel en verplicht, versie 1.7 optioneel. De voor deze Epic benodigde wijzigingen kunnen vanaf versie 1.6 worden doorgevoerd, de versie die tegen die tijd verplicht is. Echter, 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, lijkt het daarom beter om ook een wijziging door te voeren op de versies 1.4 en 1.5 van het afsprakenstelsel. Hierdoor worden de deelnemers verplicht direct over de benodigde wijziging na te denken en deze in te plannen. Daarnaast moeten de deelnemers goed ingelicht worden over wat er van hen verwacht wordt. Op deze manier kunnen de deelnemers op tijd klaar zijn met het doorvoeren van de wijzigingen.
6.2. Deelnemers
Alle deelnemers die de versies 1.4 en 1.5 gebruiken, moeten rekening houden met wijzigingen. Dit heeft als reden dat alle deelnemers een grafische interface, en daarmee frontchannel verkeer, hebben. De DVP's leveren een grafische interface via web, waarvan Personen gebruik kunnen maken. De DVA's implementeren allen de rol Authorization Server, waarbij ook gebruik moet worden gemaakt van een grafische vormgeving. Beiden moeten in de bestaande vorm beveiligd worden met publieke PKIoverheid certificaten, beiden moeten worden vervangen. Daarnaast worden publieke certificaten ook gebruikt voor backchannel-verkeer, iets dat in de nieuwe situatie niet meer is toegestaan. Hiervoor in de plaats moeten de deelnemers gebruikmaken van private PKIoverheid certificaten (G1).
Daarnaast moeten alle deelnemers die nieuwe certificaten gebruiken voor backchannel-verkeer deze registreren in de R&A, zodat de juiste informatie op de lijsten komt te staan.
6.3. R&A
Net als de deelnemers moet ook de R&A de juiste certificaten gebruiken. Dit betekent dat voor al het frontchannel-verkeer gebruikgemaakt moet worden van publieke certificaten die aan de nieuwe eisen voldoen. Voor al het backchannel-verkeer moet gebruikgemaakt worden van G1 certificaten.
Daarnaast moeten door de deelnemer die nieuwe certificaten gebruiken voor backchannel-verkeer deze registreren in de R&A, zodat de juiste informatie op de lijsten komt te staan.
6.4. Acceptatie
Tijdens het acceptatieproces moet worden toegezien dat deelnemers de juiste certificaten gebruiken op de productieomgeving. Andere omgevingen mogen wel DV-certificaten gebruiken.
6.5. Communicatie
In alle media moet gerefereerd worden naar de juiste beschrijving. Wat dit precies betekent is nog onbekend.
7. 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.
Dreiging | Kans | Impact | ID (intern) | Maatregelen |
|---|---|---|---|---|
Deelnemers die niet over zijn gestapt op andere publieke certificaten lopen het risico dat de webapplicatie niet zonder fouten door de browser wordt ingeladen. | Klein | Groot | Duidelijke richtlijnen in het afsprakenstelsel en deelnemers ruim van tevoren wijzen op dit risico | |
Deelnemers die EV certificaten gebruiken voor de beveiliging van backchannel-verkeer kunnen geen gegevens meer uitwisselen, omdat dit type certificaten niet meer wordt geaccepteerd. | Klein | Groot | Duidelijke richtlijnen in het afsprakenstelsel en deelnemers ruim van tevoren wijzen op dit risico |