Slaat nergens op dit gaat werkelijk niks oplossen.
Zorg voor betere revoke mogelijkheden en plan audit momenten in als dat al niet gebeurt.

De gene die geen ruk geven om veiligheid zullen hier ook niks van aantrekken terwijl de gene die wel omgeven het werk enkel lastiger gemaakt wordt en het feitelijk niks oplevert.

Waarom niet beperken tot 45 uur of 45 minuten of nóg beter: 45 seconden!

Misschien kunnen we naar een situatie waarbij we een certificaat gaan aanvragen en installeren voor elke bezoeker, duurt het even wat langer voor de site op je scherm staat maar dan is het wel echt goed veilig hoor.

De A in CIA zal hiermee sterk onder druk komen te staan. Of dat nu een verbetering is? En waarom wordt dit gedaan: worden de asymetrische encryptie algoritmes massaal gekraakt door quantum computers op dit moment? En als dat zo is, dan lost dit toch niets op? Richt je eerder op het correct uitgeven van dit soort certificaten zodat er meer zekerheid is met wie je contact hebt, dat is volgens mij een groter issue dan de gebruikte encryptie.

Terwijl internetters steeds vaker niet anoniem mogen zijn op internet (*), mogen eigenaren van websites dat wel.

Hier ziet u voorbeelden van domeinnamen van veelal anonieme dropshippers wiens webshops binnenkort live gaan (en vaak veel korter dan 45 dagen bestaan): https://www.virustotal.com/gui/ip-address/23.227.38.66/relations (zie ook https://pointer.kro-ncrv.nl/dropshippers-betrouwbare-juwelenhuizen-plastic-nepsieraden-china-online-misleiding).

Een voorbeeld, sinds enkele dagen live: https://danour.nl. Lovende reviews op Trustpilot (aldus Danour zélf), maar zojuist nog onvindbaar op https://nl.trustpilot.com/review/danour.nl. Voorheen bekend als https://shoppingfusion.nl. En dit zijn nog relatief "brave" partijen (zo kan het ook: https://www.virustotal.com/gui/ip-address/213.226.123.47/relations).

Zomaar twee voorbeelden van krankzinnige anonieme domeinnamen die weer worden witgewassen bij parkeerders: https://crt.sh/?q=com-id20341.info en https://crt.sh/?q=confirms329922.com.

(*) Voorbeeld, uit https://youtube.com/watch?v=3oqu5WqmS5Y ("Bar Laat" van dinsdagavond):

Zie https://infosec.exchange/@ErikvanStraten/113323164774075780 (en followup) waarom.

De uitzending is overigens gewoon (zonder inloggen) te bekijken in https://npo.nl/start/serie/bar-laat/seizoen-1/bar-laat_31/afspelen, het -vermoedelijk- voor jongeren ongeschikte deel vanaf 27:05.

En dit heeft wat te maken met TLS lease duur? Wat is je punt?

Even uitspellen. :Confidentiality, Integrity, Availability. (niet Central Intelligence Agency, wat ik een moment dacht en de opmerking niet kon plaatsen).

Nee, het heeft natuurlijk niks met quantum hype te maken.


Maar precies wel met dit probleem - kortlevende certificaten mitigeren de impact van (onvermijdelijk) gelekte/gehackte/onterecht uitgegeven certificaten .

Tip : zoek de meest voorkomende factoren als achtergronden van een voorgestelde wijziging, niet meest obscure tech-hype-hippe beloften.

Dit lost niets op.
Er is nog nooit een certificaat gekraakt.
dit is risico verhogend.

Zeker ook als meeneemt wat Erik (hierboven) aangeeft. (en wat hij terecht zo vaak heeft verkondigd)
De BigTech TLS certificaten zijn geautomatiseerd ten koste van eigenaar-validatie.
En dat schaadt (let op: dat schaadt, nog een keer zeggen? Dat schaadt enorm) elke web gebruiker die in wezen geslachtofferd wordt door BigTech om BigTech's monopolydrang te bevredigen.

dit bevordert alleen maar de macht van bigtech (monopolydrang)
niet alleen ten koste van webeigenaren, maar vooral ook van web bezoekers (immers steeds weer en meer validatie pings).
Dan heeft BigTech ook geen cookies meer nodig om bezoekers te tracken. Leuke omzeiling van privacy wetten.
Het verdienmodel kan zomaar bestaan uit weten welke ip adressen welke websites bezoeken (en nog wat meer info) Dan kan je toch ongewenste reclame pushen.
En daarvoor moet het alle niet-BigTech CA's het zo moeilijk mogelijk worden gemaakt.

gebeurt (al wat langer) met smime certificaten

dus binnenkort kunnen we geen smime certificaten vanaf een hardware token gebruiken, want te duur

wat kan je er aan doen? Zodra je last krijgt van de korte levensduur certificaten, dan Apple (en andere bigtech) links laten liggen.
Nog beter: in EU verband alle (ook langer geldend zijnde) EU geaccordeerde CA's (dus ook andere dan QWAC) verplichtend door BigTech laten erkennen. Dat kan gewoon.

ik hoor graag commentaar.

Zoals Anoniem om 19:43 al aangaf: totale onzin.

1) Noem mij eens een paar voorbeelden van "gelekte/gehackte certificaten" die tot significante schade bij meerdere (onafhankelijke) bezoekers van websites hebben geleid. Probleem: aan uitsluitend een private key plus certificaat (voor een domeinnaam van een ander) heeft een aanvaller niets. Immers, er is een tweede aanval (Attacker in the Middle) nodig om ervoor te zorgen dat slachtoffers op de nepwebsite terechtkomen.

2) Daarentegen hebben onterecht uitgegeven certificaten wél tot significante financiële schade bij bezoekers van websites geleid (*). Een levensduur van 45 i.p.v. 90 dagen helpt in dergelijke gevallen geen moer; de slag wordt binnen enkele uren geslagen. Dat deze aanvallen succesvol zijn komt doordat de aanvaller slechts één aanval hoeft uit te voeren om zowel minstens één DV-certificaatverstrekker als daarna bezoekers naar diens website te loodsen: in de praktijk ofwel door ongeautoriseerd DNS-records te wijzigen, ofwel middels BGP-hijacks.

Eén van de redenen om de levensduur van certificaten te verlagen is dat de kosten van betrouwbare en snelle OCSP-servers hoog zijn (certificaten zijn natuurlijk niet echt gratis, zie [1]). De "deal" bestaat uit de suggestie dat 45 dagen een redelijke vervanger is voor revocation en OCSP (net zo onzinnig als elke n maanden je wachtwoord moeten wijzigen omdat het kan zijn afgekeken of kan zijn gelekt). Echter, de belangrijkste reden om geen OCSP meer te willen, is waarschijnlijk dat, bij gelijkblijvende laadtijd van een webpagina, de browser meer advertentiemateriaal kan downloaden indien de OCSP-check wordt overgeslagen.

Mocht iemand het nog niet doorhebben: big tech verzint voortdurend maatregelen die, naar verwachting, tot hoger winsten leiden. Vervolgens wordt verzonnen hoe dergelijke maatregelen het beste aan consumenten kunnen worden "verkocht" (zoals destijds "Stripe, Inc") - trucs waar vaak ook schijnbaar intelligente techneuten instinken ("beter voor uw privacy", "veel veiliger" etc).

[1] https://infosec.exchange/@ErikvanStraten/112914047006977222

(*) Links naar voorbeelden zijn te vinden in #3/3 in de draad beginnend met [1].

Geen goed idee: vervangen van een certificaat kost geld en resources. It-ers hebben het al druk genoeg met andere security zaken, dus dit gaat weer ten koste van ander werk.
En waar praten we over: Apple levert zakelijk alleen telefoontjes en laptops. Ze leveren geen emailoplossingen, software of firewalls. Het is het meest overgewaardeerde bedrijf ter wereld.

Dit zegt toch eigenlijk genoeg?

Ik heb voldoende appliances in beheer, waar ik handmatig de certificaten moet vervangen. Of waar ze niet alle ACME mogelijkheden ondersteunden. Denk bijvoorbeeld aan ILO,DRAC, Printers om even iets snel te noemen.

Nog afgezien van mogelijk plugin issues https://github.com/home-assistant/addons/issues/3801 die ook nog eens heel erg snel aangepakt moeten worden.

En wat betreft Agility?


Wel degelijk, maar het is niet de enigste reden. De migratie van SHA1 naar SHA256 zo'n 10 jaar geleden duurde jaren. Met de staat zoals het nu is, gaat het straks echt mis. Waarom? Automatisering van certificaten is een low priority.

Wij CAs proberen bedrijven er al jaren aan te helpen, maar het blijft een low priority, met diverse outages als gevolg.


Zijn we incidenten als Heartbleed, Debian Weak Keys, de ROCA Vulnerability, de Close-Primes vulnerability al weer vergeten?

ROCA en Close-Primes zijn niet eens zo heel oud, we (als industrie) hebben alleen erg veel geluk gehad dat de aantallen qua impact laag waren. Dat hoeft de volgende keer niet zo te zijn.


Daar ben ik het niet mee eens. Het voorstel verlaagt de Domain Control validatie naar 10 dagen (zeer terecht!), maar organizatie validatie maar naar 398 dagen, dus dat kan nog altijd 1x per jaar gedaan worden, en heeft dus totaal geen impact hierop.


Validatie pings voor bezoekers?


Care to explain? S/MIME kan voor 3 jaar worden uitgegeven, vanaf volgend jaar voor 2 jaar, dat lijkt me meer dan genoeg.


Hoe is dat te duur? Een hardware token is niet gelimiteerd op 1 certificaat en private key. Key Management is essentieel.


ETSI werkt redelijk samen met het CA/Browser Forum. Daarbij, als je QWACs wilt hebben die in browsers geldig zijn, zul je alsnog aan de Baseline Requirements vast zitten.



Multi Perspective Issuance Corroboration is verplicht voor CA's vanaf volgend jaar, iets wat de BGP-hijack factor vrijwel volledig weghaalt.


Dat klopt niet. OCSP is al optioneel, als CRLs beschikbaar zijn. Daarnaast zijn zowel OCSP en CRL optioneel indien het een Short-Lived certificate betreft, echter moeten die dan 10 dagen of korter geldig zijn. 45 dagen valt hier niet onder, en zal dat ook niet doen.


De belangrijkste reden dat OCSP wegvalt, en CRLs juist weer terug komen, is privacy overwegingen. CAs kunnen mogelijk tracken welk IP welke website wanneer bezoekt.

Je bent Private CA nodig, niet Public CA.

@Martijn,

Ik ben anoniem 19:43.
Jij werkt bij een TSP. Ik ook. Bij een interne TSP met publieke werking.
Ik heb dus ook te maken met de gevolgen van de keuzes. Daarom is PKI voor mij een middel dat een hoger doel dient. Namelijk aantoonbare veiligheid creëren.
Als je mij wilt spreken, ga dan naar de vertegenwoordiger van jouw organisatie die is aangesloten bij het PKI Consortium. Laat maar vragen aan de voorzitter of de plv voorzitter.


Tav agility.
Inderdaad, vele TSP organisaties verwijten klanten dat zij onvoldoende agility hebben om certificaten te vervangen.
Zoals dokters verwijten dat mensen nog steeds sterke drank kopen. Dat mensen nog steeds roken.
Intern de organisatie waar ik werk organiseer ik wel degelijk agility. Ook tav certificaten.
Maar draai de boel aub niet om. Dat betekend dat je best klanten mag vragen om agility te organiseren, maar je kan het niet afdwingen.
PKI heeft inmiddels de status bereikt dat het tot systeem falen kan leiden. Als jouw organisatie wil voorkomen dat jullie klanten naar de rechter stappen (zoals die medische firma in de USA Digicert heeft gedaagd en gewonnen), dan zou je in het geheel geen certificaten meer moeten verkopen aan klanten die tav agility onvolwassen zijn. Kijken hoe lang je het vol houdt.

Tav Quantum hype.
Natuurlijk heeft dit niets met de quantum hype te maken. Althans, niet het verkorten van de levensduur certificaten.
Quantum is natuurlijk wel een probleem. Daarom ook dat NIST (pas onlangs) de post quantum crypto algoritmes heeft vastgesteld. In Nederland bestaat een programma dat heet Hybrid Approach Post Quantum Crypto (weet de volledige naam niet meer). Het gaat erom dat een nieuwe generatie zowel traditionele PKI bevat als ook post quantum crypto.

Daarnaast spreek je over de lange transitietijd van SHA1 naar SHA256.
Dat is zo. lange transitietijd. Maar begrijp wel waar dat vandaan komt.
1. Mijn organisatie was de eerste die overging naar 2k sleutels en SHA256. En toen we die wilden gebruiken in onze IT systemen kon dat niet. Die waren nog zo ver. Daarmee heb ik een belangrijke les geleerd. en die snap jij nu ook.
2. De US-DoD was zo ongeveer de laatste die overging naar SHA256. Dat kwam omdat zoveel (in wapensystemen) embedded systemen gebruik maakten van Sha1. Een inkoopcontract van wapensystemen gaat nooit over PKI agility. Als dat wel zou moeten (ook), dan mag je dat ook eisen voor alle mogelijke veranderingen. Dan kom je niet meer tot contracten.

Over er is nog nooit een certificaat gekraakt.
Ja, ik herken de kwetsbaarheden die je noemt. Dan nog is er nooit zo een certificaat gekraakt.
En om die kans te verkleinen bestaan inmiddels richtlijnen waarmee deze risico's naar 0 zijn gereduceerd.
In onze PKI hebben we onderzocht hoeveel near-prime situaties zich hebben voorgedaan. exact nul.
Ook als een enkel certificaat kwetsbaar zou zijn, dan is dat snel te vervangen. Het betreft er dan namelijk een enkele.

Over de verschillen in domein validatie en organisatie
Je zou gelijk hebben als bezoekers in één oogopslag het verschil kunnen zien.
En als website eigenaren zich hierdoor zouden laten leiden.
Het tegendeel is het geval. Extended validatie had vroeger een groene URL. Dat is door BigTech weggehaald. Daarmee konden bezoekers niet in één opslag meer zien dat het een betrouwbare site zal zijn (immers eigenaar is op te sporen). Dat is er nu dus niet meer. Het gevolg is geweest dat extended validation feitelijk verdwenen is. Pas daarna kon BigTech geautomatiseerd certificaten leveren. Dat kost bijna geen werk en kan dus gratis zijn (LetsEncrypt) . En daarmee kan BigTech de grootste CA zijn die alle validatie pingen kan afvangen. The winner takes all. Einde privacy.

Over bezoeker als verdienmodel
Alle TSP'n (ook LetsEncrypt) heeft een validatie string in de certificaten.
Als ik als bezoeker een website bezoek, dan gaat automatisch (althans voor gewone burger) een validatieverzoek (de bezoekersping, maar nu uitgeschreven) naar de CA (de Validatie Authority). Dat verzoek bevat minimaal het IP adres van de verzoeker. In mijn voorbeeld mijn IP adres. En er gaat nog meer info mee. Zoals info over welk OS, etc.

Over s/Mime
Like to explain. ;-)
Zoals je zegt. s/Mime gaat naar 2 jaar (825 dagen). Buiten het feit dat dit helemaal niets verbeterd voor eindgebruikers is het ook nog eens schadelijk. Overigens meer vereisten vanuit CABForum zijn schadelijk.
Binnen Europa bestaat eIDAS. eIDAS borgt de zekerheden, herkenning en erkenning voor gekwalificeerde handtekeningen. Die kunnen alleen bestaan in een gecertificeerde HSM. Zo'n HSM kan ook op een smarcard zitten. De zekerheden in zo'n HSM (ook op smartcard) is onderhavig aan heel zware zekerheden (ETSI EN 419 221) en worden via common criteria (ISO/IEC 15408) beoordeeld.
Mijn KPN certificaat kostte mij 450 Euro excl BTW. Over 3 jaar is dat 150 euro per jaar. Over 2 jaar is dat 225 euro per jaar. Hoeveel mensen zijn dan nog bereid zo'n gekwalificeerde handtekening te kopen.
Alle Europese digitale identiteit smartcards worden met de eis feitelijk onbruikbaar voor mail.
Alle Amerikaanse overheden gebruiken FIPS201 kaarten die een geldigheid hebben van 3 jaar. Ook die certificaten worden onbruikbaar voor mail.
Denk je nu echt dat inkorting van 1045 dagen naar 825 dagen de samenleving helpt om veiliger te worden?

Dit is een probleem met CABForum. Zij besluiten zonder nagedacht te hebben over de gevolgen voor de samenleving.
Ik geloof ten zeerste dat de BigTech macht dominant is in CABForum en dat daarmee BigTech alleen maar de eigen verdienmodellen aan het versterken zijn (ten koste van de samenleving).
Prove my wrong.

Over samenwerking ETSI, Enisa en CABForum
Het klopt dat inmiddels (beter) wordt samengewerkt.
QWAC moet verplichtend opgenomen worden in de trust stores van BigTech. Gelukkig maar.
Dat zou ook moeten gelden voor alle door Europese instanties goed bevonden TSP'n voor alle soorten certificaten. (die door Europa zijn ingeregeld.)
Omdat dit nu niet geldt voor gekwalificeerde handtekeningen kan blijkbaar CABForum besluiten om de Europese certificaten buiten spel te zetten.

Over OCSP vs CRL.
In vele gevallen is CRL de betere oplossing. Maar is allerminst anoniem.
CRL zou mijn voorkeur hebben als machines met elkaar communiceren.
OCSP is weliswaar nog minder privacy minded, maar dat past dan ook in de doelstelling van OCSP.
Als je met OCSP validatie een document of email onderteken, dan wordt dat bestand enkele kB's groter. Maar de ondertekenaar is toch al (heel bedoeld bekend).
Als je met een CRL validatie een document of email onderteken, dan kan dat bestand ineens vele MB's groter worden . Immers, dan wordt de CRL van dat moment in het ondertekende document opgenomen.

Over de belangrijkste reden OCP vs privacy.
Ongeacht of een CA een OCSP response of een CRL terug stuurt, in alle gevallen moet de CA weten waarheen dat moet gaan. Dat is minimaal het IP adres van de gebruiker. De gebruiker (behoudends de hierin opgeleiden) heeft altijd niet in de gaten dat zo'n validatie request uit gaat naar de CA.


Graag ga ik met je het gesprek aan.
Via jullie vertegenwoordiger bij het PKI Consortium kan je me vinden.

o, ik zal hier en daar wel type foutjes gemaakt hebben
en ook onvolledig zijn
dat heb je nu eenmaal met schriftelijke communicatie waarbij je elkaar niet inde poppetjes van de ogen kijk

Ter verduidelijking, gewonnen omdat de andere partij niet is gehoord in de zaak, en de medische firma niet het volledige contract heeft laten zien, waarin duidelijk stond wanneer de CA het recht had om in te trekken.


Een inkoopcontract van wapensystemen zal ook nimmer niet over Public CA gaan. Ik hoor zo vaak dit of vergelijkbaar argument. Ander voorbeeld: "Ja maar ons systeem voor toegang tot het pand kan niet zomaar nieuwe SSL certificaten installeren." Sorry, maar als je daarvoor Public CA gebruikt, doe je iets vreselijks fout.


Certificaten gekraakt, nee. Keys gelekt en keys gekraakt? Wel degelijk. De close-primes vulnerability maakt dat juist mogelijk.


EV gaf aan wie er achter de site zat. Het gaf nooit aan of het een betrouwbaar bedrijf was.


Dat doet OCSP. OCSP gaat er uit.


Dat jou leverancier je hetzelfde wil rekenen voor een van 2 jaar als een voor 3 jaar, is iets wat je met hun zult moeten oplossen. ;) De QSCD tokens kosten nou niet echt heel veel.


Ja. 3 jaar voor het niet opnieuw valideren van bedrijfsgegevens is gewoon te lang.


Helaas schrik ik nogal van wat sommige TSPs uitgeven. En ze komen er vaak mee weg omdat er geen CT requirement is.


Eens. Het grote verschil in privacy is echter dat de CA bij OCSP ook kan zien welke website er wordt bezocht, en bij CRLs doorgaans niet.


Je ziet m'n naam, voel je vrij me te mailen. ;)

Je hebt duidelijk geen idee waar je over praat.

In de eerste plaats vereisen dat soort incidenten direct ingrijpen en niet gemiddeld 22,5 dagen wachten. Bovendien lijkt er geen eis te bestaan dat bij elke nieuw certificaat van een nieuw sleutelpaar gebruik gemaakt wordt; het verplicht eerder vernieuwen van een certificaat biedt dus geen garantie dat er van een nieuw sleutelpaar gebruik gemaakt zal worden.

Voorbeelden voor dat laatste punt:
1) tweakers.net: zelfde sleutelpaar sinds 2021-08-04.
https://crt.sh/?spkisha256=2fddfadff8bd22ba1b8a7822df9a12cce0293627b95388e517bb3376c3126ae7

2) boschconnectedcontrol.com (ook https://crt.sh/?Identity=oauth.boschconnectedcontrol.com&exclude=expired): zelfde sleutelpaar sinds 2019-04-27.
https://crt.sh/?spkisha256=9bfca9af02788c866e335e07a0b49ea53c2fe55554d3ff3b38a349d4ff2d775d

3) lapcatsoftware.com: zelfde sleutelpaar sinds 2016-08-09.
https://crt.sh/?spkisha256=fc3000b7ac56a2a7a1f808e8960ed9c5d9e1e16ca6362538ef86db0ae6dd5e98

4) Compleet feestvarken: Fastly. Niet alleen jáááren dezelfde sleutelparen gebruiken, maar ook nog eens voor tienduizenden domeinnamen. Eerder schreef ik in https://security.nl/posting/852933 onder meer:

Je kunt zo'n link vinden door bijv. https://crt.sh/?q=zorgapp.hemazorgverzekering.nl te openen en op een willkeurig nummer in de linker kolom te drukken, zoals (op dit moment) de bovenste: https://crt.sh/?id=14550204519. De link onder "Subject Public Key Info" is nummer "(1)" hierboven.

Meer dan 100 domeinnamen per certificaat kan ook (582 als ik goed geteld heb), zie bijvoorbeeld https://crt.sh/?id=7293782180.

Vraag, wat is volgens jou het doel van een https servercertificaat (bij verbindingen die van Forward Secrecy gebruikmaken)?

1) Het versleutelen van de verbinding;

2) Dat je redelijk zeker weet dat jouw browser een veilige verbinding heeft met ofwel direct de bedoelde server, of een proxyserver (waarvan je geen idee hebt van wie die is en wie er allemaal meekijken) met de in de adresbalk van jouw browser getoonde domeinnaam;

3) Dat je redelijk zeker weet dat jouw browser een veilige verbinding heeft met de daadwerkelijk door jou bedoelde server op basis van de in de adresbalk van jouw browser getoonde domeinnaam;

4) Dat je redelijk zeker weet dat jouw browser een veilige verbinding heeft met een server van een door jou bedoelde organisatie;

5) Iets anders (ik verneem het graag).

Helemaal mee eens! En hoe zorgen we er voor dat klanten dat direct kunnen doen? Door automatisering te aan te moedigen.

Ik ben anoniem 19:43

Je mist nog steeds het punt bewust bekwame slechteriken net zo gemakkelijk een certificaat kunnen verkrijgen van een domein dat lijkt op een legitieme website.
Gewone burgers willen betrouwbaarheid. Niet alleen transmissiebeveiliging.
Betrouwbaarheid ontstaat alleen dan als een website eigenaar op te sporen is. Ales een frauduleus persoon een certificaat krijgt voor een domein én die bewust bekwame slechterik is op te sporen, dan gaan die frauduleuze websites ook verdwijnen. 100%? Nee natuurlijk niet, maar de meesten zullen toch verdwijnen.

Bekend krijgen van de eigenaar website kan met OV en EV. Alleen zit hier nog geen wettelijke bescherming in .
Die wettelijke bescherming komt weer wel met de QWAC. Denk aan aansprakelijkheid, erkenning, doorwerking, etc.

Wat Erik steeds zegt: DV biedt voor de burger geen (of volstrekt) onvoldoende bescherming.
en: zonder kennis van de eigenaar van de website is elke voorziening onvoldoende (ten aanzien van dit topic)

Nog een quote vanuit de 16e CA dag bij Enisa (vrije vertaling)
Dean Coclin van Digicert zei dat DV onvoldoende bescherming biedt.
namelijk transmissiebeveiliging is onvoldoende in deze maatschappij
minimaal is ook authentication nodig om opsporing mogelijk te maken
QWAC is niet perfect, niet slecht. QWAC kan werken.

Ik ben anoniem 19:43

@Martijn

ik wil je graag mailen, maar ken niet de formatering van emailadressen van jouw organisatie.


Inhoudelijk reageren

inzake jouw uitspraak
Ter verduidelijking, gewonnen omdat de andere partij niet is gehoord in de zaak, en de medische firma niet het volledige contract heeft laten zien, waarin duidelijk stond wanneer de CA het recht had om in te trekken.

Blijkbaar heeft DigiCert ingezien dat het medische bedrijf een punt heeft.
Dan over het contract.
- de intrekkingstijd is eenduidig afgedwongen door het CABForum. Anders wordt de CA van DigiCert niet opgenomen in de trust stores.
- Dit deel van het contract tussen DigCert en het medische bedrijf is een wurg-element. Wurg-elementen worden bij uitstek door rechters terzijde geschoven als het maatschappelijk belang dat verijst. En dat is hier gebeurt.

Tijdens de DigiNotar crisis zou Nederland op slot gezet zijn als Microsoft jouw uitleg van het contract zou hebben afgedwongen. Dan zou iedereen zien dat Microsoft niet alleen de Nederlandse maatschappij op slot kan zetten én het ook zou doen. Dat zou onmiddellijk het einde zijn van de business van Microsoft. Wie wil er immers een auto waarvan de slotenfabrikant dat merk auto onmiddellijk kan uitzetten en dat ook heeft gedaan.

De schade in Nederland zou zijn:
- geen operationele ziekenhuizen meer
- geen export meer
- geen import meer
- geen bankwezen
- geen notariaat
- etc
- etc
Begrijp je nu het systeemrisico?
Dit speelde ook bij dat Amerikaanse medische bedrijf.

Overigens
Op dit moment speelt juist vanwege deze redenen de discussie over delayed revocation.
in PKI Consortium
bij zo'n beetje alle CA's
bij CABForum
etc


Inzake
Een inkoopcontract van wapensystemen zal ook nimmer niet over Public CA gaan. Ik hoor zo vaak dit of vergelijkbaar argument. Ander voorbeeld: "Ja maar ons systeem voor toegang tot het pand kan niet zomaar nieuwe SSL certificaten installeren." Sorry, maar als je daarvoor Public CA gebruikt, doe je iets vreselijks fout.

Mijn voorbeeld van wapensystemen is slechts als illustratie bedoeld. Dat heb jij ook gezien (ik acht je daarvoor slim genoeg)
Maar goed. wat je zegt, het klopt voor een groot gedeelte, maar nooit volledig.
Privaat en publiek zijn voor een belangrijk deel goed van elkaar te scheiden. Maar zeker niet volledig.
Hier gaat het met name om de doorwerking in het publieke domein.

Ga nou niet een spelletje spelen zoals verwoordt door Prof Dr Andre Wierdsma in zijn emiritaatsrede "Vrijmoedig Positie Kiezen).
7.5. Plek der Moeite: heroverwegen van kaders
7.5.1. Disciplinering en uitsluiting: weg van de Plek der Moeite
Zo voelt het een beetje.
Overigens: die rede is vrij te downloaden


Inzake Certificaten gekraakt, nee. Keys gelekt en keys gekraakt? Wel degelijk. De close-primes vulnerability maakt dat juist mogelijk.

Near Primes zijn inderdaad te door te rekenen. Dat is echter nooit in een operationele omgeving gebeurd.
Vanaf de ontdekking van de Near Prime kwetsbaarheid zijn internationaal maatregelen genomen om Rear Primes te voorkomen. Bijvoorbeeld linters. en er zijn meer mogelijkheden.

Feitelijk: er is (in de operationele praktijk) nog nooit certificaten gekraakt.


Inzake Dat doet OCSP. OCSP gaat er uit.

Dit is werkelijk een gedachte van iemand die alleen maar met website certificaten bezig is.
Er zijn veel meer toepassingen.
Mijn punt is ook juist dat CABForum (eigenlijk BigTech) het Publiele PKI aan het kapen is. Zonder over de gevolgen voor anderen na te denken. mijn mening: Lineair fundamentalisme. Of noem het Professioneel Narcisme. Van Bigtech. Niet van grote CA's. Grote CA's zijn ook slachtoffer van het professioneel narcisme van BigTech. En velen snappen dit nog niet.


Inzake Dat jou leverancier je hetzelfde wil rekenen voor een van 2 jaar als een voor 3 jaar, is iets wat je met hun zult moeten oplossen. ;) De QSCD tokens kosten nou niet echt heel veel.

Ik weet precies waar de kostendrivers zitten. Ik weet ook precies waar de terugverdienmogelijkheden zitten.
Eea neemt niet weg dat een QSCD (smartcard) veel veiliger is dan andere manieren van s/MIME certificaten.
Apple (BigTech) heeft haar macht ontplooid om de smartcards weg te managen. Ten koste van een veiliger samenleving.

Gelukkig ziet Europa dit ook. De reactie vanuit Europa is de EU Wallet.
Is dit beter dan een smartcard?
- tav veiligheid zeker niet.
- tav gebruikersvriendelijkheid en schaalbaarheid zeker wel.


Inzake Ja. 3 jaar voor het niet opnieuw valideren van bedrijfsgegevens is gewoon te lang.

Nee dat is niet zo. Mensen werken vaak veel langer dan 3 jaar voor een organisatie.
Als mensen weg gaan bij een organisatie dan is de subscriber (de organisatie) bevoegd de smartcard (het certificaat) van de subject (medewerker) in te trekken.

Nogmaals, je lijkt uitsluitend te denken vanuit webpagina's. Niet ook vanuit andere toepassingen. Ergo een illustratie van het kapen van Publiek PKI.


Inzake Helaas schrik ik nogal van wat sommige TSPs uitgeven. En ze komen er vaak mee weg omdat er geen CT requirement is.

Certificate Transparacy is inderdaad niet verplicht vanuit eIDAS. Ik heb Enisa en Etsi verzocht na te gaan of dit niet alsnog kan worden ingeregeld. En daarvoor ook de negatieve effecten eerst te beoordelen (ik ken een aantal voordelen, maar heb geen onderzoek gedaan naar nadelen).
In ieder geval is CT (waarschijnlijk) wel geschikt voor webpagina's (die immers toch al voor ieder publiek moeten zijn).
CT lijkt me onwenselijk voor persoonsgebonden certificaten (s/MIME). Dat zou indruisen tegen bescherming van alle s/MIME certificaathouders (privacy).


Inzake Eens. Het grote verschil in privacy is echter dat de CA bij OCSP ook kan zien welke website er wordt bezocht, en bij CRLs doorgaans niet.

Dat denk je maar.

Nogmaals: ik wil graag contact.
en wil dan wel zeker weten dat jij ook jij bent.
Daarna mag je mij volledig kennen.

Koop geen KIA alle dealers kunnen wereldwijd op kenteken of VIN een auto blokketen, of alle sloten openen.
Kort geleden is een security fix op hun website gedaan omdat iedereen vrij simpel een account kon aanmaken en daarna omsmurfen naar een dealer account...
Ga er maar vanuit dat alle auto's waar een modem inzit ook deze mogelijkheid hebben.
( beter bekend als diefstal preventie, en open tbv hulpverlening na ongeval)

Goh unieke crl per certificaat lost dat ook op.

En wat te doen tegen een xIVD die bij Staat der Nederlanden een certificaat aan laat maken voor google.com, facebook.com etc?
Al of niet met een unieke CRL?

Terwijl ik nog flabbergasted ben van het absurde "antwoord" van Martijn Katerbarg in https://security.nl/posting/862633:

Als er niet zoveel third party websites zouden meekijken, er niet zoveel websites bij big tech waren gehost en er niet steed meer netwerkverkeer via clubs als Cloudflare of Fastly zou lopen, zou ik verleid kunnen worden om te denken dat "privacy" mogelijk is op internet, en OCSP-stapling aanraden.

Hoewel (vooral mobiele) browsers steeds minder informatie over certificaten prijsgeven, kun je vaak nog wel zien wie de uitgever is. Sowieso "krijgen" we vroeger of later ChatControl, dan heeft de overheid helemaal geen certificaten meer nodig om te zien wat jij uitvreet op internet.

Alleen al omdat Apple het voorstelt: Nee gaan we niet doen.

Opmerkelijk dat hier niet meer mensen achter deze maatregel staan...
Volgens mij snappen mensen hier niet waarom deze levensduur verlaagt wordt?

Historisch gezien is er voldoende misgegaan met certificaten. Kortere certificaten = minder lang een probleem.
Maar een van de grootste problemen dat opgelost wordt is, luie onveilige systeembeheerders.

Heel veel organisaties zitten vast in ouderwetse legacy procedures zoals handmatig certificaten vervangen. Als je dat in 2024 nog doet dan snap je natuurlijk helemaal niets van automatisering. Hiermee forceert men die luie systeembeheerders eens een keer echt na te gaan denken... Het is de enige mogelijkheid om die groep mensen in beweging te krijgen.

Levensduur zegt niet zoveel, wel een hoger algoritme en correcte implementatie.


Aha, maar de meeste fouten liggen niet aan de levensduur van certificaten maar vooral verkeerde implementatie.


Aha, dus je snapt certificaten niet, dus je snapt dan niets van automatisering? Ok bijzonder inzicht....

Inderdaad bijzonder...

Je geeft zelf aan dat verkeerde implementatie de reden is van de meeste problemen.
Ik geef aan dat de meeste problemen komen door luie onveilige systeembeheerders. Korte-lopende certificaten forceert automatisering wat het probleem van onveilige configuraties kan voorkomen.

Maar je leeft blijkbaar zo buiten de praktijk dat je niet snapt dat een systeembeheerder die iets handmatig 1x per jaar moet doen, veel fouten maakt? Laat staan met de handleiding van zijn voorganger?

Door certificaten te automatiseren voorkom je configuratie fouten en verkeerde implementaties.

Het is hier inderdaad een bijzondere commentsectie. Allemaal technische discussie terwijl het grootste probleem hier (zoals altijd) de mens is.

Dat blijkt ook wel uit jouw reactie. Gelijk struisvogelpolitiek en verdedigen in plaats van nadenken.