Open RoelBrandDeurne opened 4 months ago
Ik zou deze nog verder willen aanscherpen.
Voorgestelde wijziging Bij publiek toegankelijke websites wordt gebruik gemaakt van ten minste publiek vertrouwde Organization Validated-certificaten.
Impact van de wijziging
Aanvullende informatie NVT
Ik zou de wijziging van Roel opnemen, zodat duidelijk is dat je aan de hand van risico's nog vrijheid hebt om een bijpassend certificaat te kiezen wat bij het niveau past. Anders heb je alleen de keuze OV of hoger en niks lagers terwijl dat in bepaalde gevallen mogelijk ook kan voorkomen.
Een voorbeeld: je hebt een arsenaal van domeinnamen waar je niets mee doet maar je toch niet weg wil doen om een of ander reden. Deze wil je laten doorverwijzen naar je hoofdwebsite. Dan zou dat betekenen dat je overal een OV-certificaat dient te hebben terwijl dit naar mijn inziens ook met een DV-certificaat zou kunnen afhankelijk van domein en risico. Wel dien je ervoor te zorgen dat alleen de betreffende organisatie of het domein dat betreffende certificaat mag aanvragen en niemand anders. Zodat je als organisatie zelf de controle blijft houden.
Nu ga ik misschien vloeken maar Let's Encrypt heeft zo'n mogelijkheid om in het CAA record (DNS) een ID op te nemen welke ervoor zorgt dat alleen het specifieke domein het certificaat kan aanvragen en niemand anders. Waardoor je toch de waarborging hebt dat niemand anders het betreffende certificaat mag aanvragen waardoor je minder risico loopt.
In het andere geval heb je alleen OV-certificaten of hoger terwijl er mogelijk ook websites/domeinen zijn welke een laag risico hebben en waar je dan toch verplicht een OV-certificaat dient te plaatsen als je het aanscherpt. Ik zou de risico beoordeling bij de organisatie laten waarbij je wel gaat voor standaard OV-certificaat maar dat je daar in bepaalde gevallen van kan afwijken afhankelijk van het risico.
Waar komt het OV-niveau eigenlijk vandaan, vertaling van PKI-overheid, of is er een directe NIS2 vertaling? Het lijkt me zeer onwenselijk om het zo op te nemen, let ook wel dat dit een dode letter gaat zijn, 95+% gaat afwijken. Voorstel is OV naar DV wijzigen.
Voor gebruikers is de OV-info in browsers nauwelijks meer te bereiken, voordelen zijn er m.i. dan ook niet meer. Voor API endpoints wordt DANE geadviseerd om certificate pinning te bewerkstelligen (zie TLS richtlijnen "Certificate pinning en DANE").
OV is niet alleen met betrekking vanuit browser kant, maar ook de uitgifte kant. (betrouwbare overheid). DV kun je ook maatregelen voornemen zoals eerder zei, maar je zou dat moeten afwegen wat je gebruikt m.b.t. het risico OV standaard en indien DV kan op basis van je risico doe je dat.
Nogmaals, het lijkt mij zeer onverstandig een maatregel op te nemen die:
OV certificaten hebben het risico meer 'handmatig' aangevraagd te worden, met alle risico's van dien m.b.t. totale onbeschikbaarheid (door HSTS kan je een expired certificaat niet meer 'bypassen', zie bijv: ), daarbij zeker gelet op:
DV met ACME verdient m.i. de voorkeur (in een dual RSA/EC certificate setup van 2 verschillende root CA's en versprongen in expire).
Het is wél belangrijker dat:
Dit laatste zou wel ergens in de BIO kunnen landen.
Beschrijf de bug
Voorgestelde wijziging Bij publiek toegankelijke websites wordt gebruik gemaakt van ten minste publiek vertrouwde Organization Validated-certificaten, tenzij uit een risicoanalyse, aansluitvoorwaarden of wetgeving blijkt dat een hogere eis nodig is of met een lagere eis kan worden volstaan.
Impact van de wijziging Verduidelijking.
Aanvullende informatie NVT