Je hebt in Thunderbird de mogelijkheid om PGP/MIME of S/MIME te gebruiken. Voor PGP/MIME kan je de plugin Enigmail gebruiken samen met GnuPG 2.1.21. S/MIME werkt ook met Outlook voor zover ik het begrijp (zonder plugin).

Om een bericht digitaal te ondertekenen, heb je je eigen secret key nodig. Om een bericht te encrypten heb je de public key van de ander nodig. Als je niemand hebt om mee te mailen, dan heb je dus ook diens public key niet. Dit is het grootste probleem met e-mail encryptie, de ander moet het ook gebruiken.

Met S/MIME heb ik helemaal geen ervaring, met PGP/MIME een beetje, maar die (Enigmail) hebben een goed gedocumenteerde site.

Ook zijn de certificaten voor PGP/MIME gratis, voor die van S/MIME moet je soms betalen bij een uitgever van certificaten.

Geen acrobat hier, en dus ook "DC" niet. Emails signeren met PKI certificaten is iets wat je minder vaak tegenkomt dan met hetzelfde met PGP/GPG (en zelfs daar weet thunderbird+enigmail niet altijd het juiste te doen).

Hoe dan ook, om te weten wat er mis is, is toch iets meer informatie nodig. Wat zegt thuderbird nou precies? Kan'ie wel een signatuur verifiëren maar vertrouwt'ie het niet, of kan'ie het signatuur geheel niet verifiëren? Hoe ziet dat certificaat eruit, wie heeft het gesigneerd?

Als dit zou werken zoals het hoort te doen, zou het de meest gebruiksvriendelijke manier van beveiligde email zijn.
Het is dan ook opmerkelijk dat met al die artikelen over beveiligde email dit hier nooit ter sprake is gekomen.

Samengevat; het is mogelijk om een zelf ondertekend certificaat (private) om te kunnen ondertekenen te importeren, maar het certificaat (publieke) om te versleutelen laat zich niet importeren. Het certificaat (private) om te ondertekenen word niet vertrouwd, hoewel deze ook in het Windows Certificaatbeheer is geplaats.

Ook de informatie van Mozilla over het gebruik van certificaten in Thunderbird komt van de koude kermis thuis.
Het mag geen naam hebben.
De vraag hier nu is of er hier mensen zijn die hier meer over kunnen verduidelijken.

Best kans dat het werkt zoals het ontworpen is, dus hopen op "werk nou maar gewoon" is een beetje veel gevraagd.

Over PKI in het algemeen? Het is een zooitje.

http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf
"Everything you Never Wanted to Know about PKI but were Forced to Find Out"

S/MIME bouwt daar op, dus dat is niet minder een zooitje. PGP/GPG is in vergelijking een stuk beter te begrijpen maar is nog steeds iets waar alleen crypto-nerds lekker mee weg kunnen. PKI is altijd een bierkaaigevecht. (Vandaar dat "standaardiseren op PKI", zoals b.v. de overheid poogde te doen, eigenlijk al van het begin af aan gedoemd is tot altijd blijven modderen.)

Aangezien OP anoniem is, is het erg lastig communiceren met OP.

Ik zou als eerste het gewoon eens standaard proberen met een vertrouwd certificaat. Email icm met een eigen PKI / self signed certificaat is eigenlijk nutteloos, aangezien de ontvanger dan ook een (public) certificaat geïmporteerd moet worden. En dat is iets wat je zelf moet onderhouden, en daarom eigenlijk niet te doen is.

Ik zou gewoon eens een test setup doen met https://www.comodo.com/home/email-security/free-email-certificate.php (via google gevonden) en het daarmee aan de praat te krijgen. Als dit werkt, weet je dat je configuratie standaard goed werkt en eigenlijk ook direct door de ontvangende partij waarschijnlijk goed werkt.

Ik heb uw advies om een gratis certificaat van Comodo op te halen opgevolgd, en inderdaad die laat zich in correct Thunderbird installeren. Helaas is het met dit certificaat niet mogelijk om een email te ondertekenen, laat staan deze te versleutelen. Thunderbird heeft geen vertrouwen in het certificaat, ook al heb ik deze uiteindelijk tijdelijk in het certificaat beheer van Windows in de map Vertrouwdebasiscertificeringsinstantie geplaatst.

Mij is verder ook niet duidelijk, waarom de gebruikers van Thunderbird niet een zelf ondertekend certificaat voor gebruik tussen henzelf en anderen mag uitwisselen en gebruiken als zijnde een vertrouwd certificaat. Vergelijkbaar met de wijze waarop PGP publieke sleutels uitwisselt, met dit onderscheid dat de eigenaar van de computer slechts éénmaal het wachtwoord hoeft in te voeren, namelijk met het importeren.

S/MIME cerificaat.

Hoe kom je er aan: http://kb.mozillazine.org/Getting_an_SMIME_certificate

Hoe installeren: http://kb.mozillazine.org/Installing_an_SMIME_certificate

ietsesiemple. No trammelanti.

Heel erg bedankt, ik had de moed na uren zoeken al opgegeven.

Redelijk zeker dat S/MIME niet de kennelijk gehoopte "makkelijker want minder wachtwoorden" functionaliteit gaat bieden over GPG. Het enige moment dat je je wachtwoord hoeft geven (naast genereren) is als jouw geheime sleutel beschikbaar moet zijn voor decryptie of signeren. En dat iedere keer als de sleutel nodig is, of je moet een key agent gebruiken.

Op dit moment ben ik aan het bestuderen of het werkelijk mogelijk is om in Thunderbird met een zelf ondertekend certificaat een handtekening, en een versleuteling uit te voeren.

Voor de geïnteresseerden, eerst de wijze waarop Microsoft Word het mogelijk maakt om een zelf ondertekend certificaat met anderen uit te wisselen

Wie in Microsoft Word een digitale handtekening aan een bestand wil toevoegen, krijgt de vraag om deze zelf te maken.
Dit gaat via een pop-up menu in het geopende bestand, en na het invullen daarvan, word dit Windows certificaat
automatisch in het Windows certificaatbeheer geplaatst in de mappen
Persoonlijk en Vertrouwde personen. De publieke sleutel van het certificaat kan worden geëxporteerd en naar anderen worden gestuurd, die deze op hun beurt heel eenvoudig in het Windows certificatenbeheer te importeren. het kan echter gebeuren dat de ontvanger de publieke sleutel nog niet heeft geïmporteerd, of zelfs heeft ontvangen. Wanneer dan het bestand wordt geopend, en met de rechtermuisknop op de optie Digitale handtekening klikt, in een menu de optie Details van handtekening klikt een popup menu krijgt, waarin hij in bovenin een gele achtergrond de optie
Klik hier als u de identiteit van deze gebruiker wilt vertrouwen. Daarop geklikt, wordt de publieke sleutel die dus in het bestand is ingesloten alsnog in het Windows certificatenbeheer in de map Vertrouwde personen geplaatst.

Om dit Windows Certificatenbeheer te openen, Start: certmgr.msc invoeren.

Zoals ik al in een eerdere reactie heb geschreven, dat ik een COMODE certificaat opgehaald, en deze liet zich naadloos in Thunderbird certificaatbeheer importeren, en in het bewuste mail account activeren. Nochtans kon ik geen versleutelde of gesigneerde mail vanuit dat account versturen. Dankzij de tip die naar de website voor het installeren van SMIME certificaten verwees, bleek dat er eerst in het Thunderbird certificaten beheer een corresponderend vertrouwenscertificaat van CMODE moest worden ge geinstalleert. In dit geval COMODO RSA Client Authentication and Secure Email CA die niet in Thunderbird CB aanwezig was. Ik vond deze in het Certificaten beheer van Internet Opties. Deze heb ik in het Thunderbird CB geïmporteerd, en nu werkt deze mail account met ondertekenen en versleutelen. Uiteraard gelet op het feit dat ik alleen maar een private en publieke sleutel van dit certificaat bezit, kan ik alleen maar naar deze account mailen.

Nu heb ik o.a. e-mails met verscheidende lettertypen en een ingesloten JPG plaatje in het tekstveld verstuurt, en deze komt onveranderd in structuur aan. Ook een PDF bijlage levert geen probleem op. De ontvanger hoeft geen wachtwoord in te vullen.

In het bewuste browser webmail account staat in het tekstveld Dit e-mailbericht heeft geen inhoud en de versleutelde inhoud staat als bijlage smime.p7m (309KB) vermeld. in dit geval omdat een PDF als bijlage is meegestuurd.

Voor gebruik door de massa zal dit niet aanslaan, omdat er teveel omslachtige handelingen moeten worden verricht.

Ik ben er nu uiteindelijk in geslaagd om door middel van een zelf ondertekend certificaat meerdere accounts in Thunderbird op één vertrouwenscertificaat geïmporteerd in het certificatiebeheer van Thunderbird de inhoud van de e-mails te versleutelen en te ondertekenen met een geldig certificaat.
Ik heb hiervoor op de website https://www.heise.de/download/product/xca-14273/download XCA gedownload.
Kies voor de optie met het certificaat Virengepruft. Het is ook te downloaden bij Sourceforge maar dan krijg je er addware bij.

Met dit programma heb ik een zelf ondertekend rootcertificaat aangemaakt, en daarna meerdere Client certificaten daaraan verbonden. Het root certificaat heb ik in de Thunderbird certificaten beheer geïmporteerd, en de afzonderlijke cliëntcertificaten in de daarvoor bestemde sectie van het beheer.

Het creëren van certificaten met XCA is eigenlijk kinderlijk eenvoudig, en ook het importeren van de certificaten in het certificatenbeheer van Thunderbird is simpel.
Voor degenen die dit ook willen proberen geef ik hier een website waar op duidelijke wijze stap voor stap wordt getoond hoe je een rootcertificaat maakt en de daaraan verbonden Clientcertificaten.
http://hmcguirk.blogspot.nl/2009/10/creating-my-own-root-ca-https-server.html

In deze uitleg sectie A. To create the Root Certificate en in sectie C. To create the HTTPS Client certificate
Het rootcertificaat exporteren als (crt) file en de Cliencertificaten als (PKCS#12 (p12) ) extensie.
Vermeld in het cliëntcertificaat die je aanmaakt, in de sectie [Subject ] wel een bestaand e-mailadres die je in Thunderbird als account hebt aangemaakt, want het cliëntcertificaat is daaraan verbonden.


Daarna het rootcertificaat importeren in Thunderbird certificatenbeheer in de sectie Organisaties
in de vertrouwensinstellingen van de rootcertificaat de optie [Dit certificaat kan e-mailgebruikers identificeren] aanvinken.
De client certificaten in de sectie [Uw certificaten] importeren, en vergeet het daarbij behorende wachtwoord niet.

Als laatste de aan de certificaten verbonden account(en) in de sectie beveiliging de certificaten activeren.

Alle versleutelde en of gesigneerde mails zijn niet te lezen in webmail van Gmail bijvoorbeeld, daar zie je in de ontvangen mail een pictogram met een hangslotje. Alleen in Thunderbird word de inhoud van de ontvangen e-mail in de originele opmaak en bijlagen zichtbaar.

Tenslotte is dit onder voorbehoud toch de meest gebruiksvriendelijk manier om je email af te schermen van nieuwsgierige blikken door o.a. Google.

8C83 D66C 5AB0 5F63 97A5 C37A 2CE0 1497 B4BB FCA5

@01:24: Het kan veel makkelijker in de toekomst. Zie https://www.security.nl/posting/390533/Google+onthult+encryptietool+voor+versleutelen+e-mails.

Ook kan je Gmail gewoon inlezen in Thunderbird met IMAP als ik het goed heb. Als Gmail je mail dan niet verminkt, kan je die gewoon lezen met Thunderbird en S/MIME.

Ook is het een beetje veel gevraagd aan andere mensen om een root certificaat van jou in Thunderbird te installeren om je signature te kunnen verifiëren. Dat geeft jou de mogelijkheid om andere public keys te installeren bij je contact personen, die dan automatisch vertrouwd worden. Je bent geen CA ;-)

Allereerst gaat dit onderwerp over het gebruik van een certificaten in Thunderbird, en het is enorm vervelend wanneer mensen het onderwerp in een totaal ander richting willen sturen.

Ook maakt u een denkfout. Iedereen moet zijn eigen zelf ondertekende root certificaat maken, en daar gelijk zijn account certificaat aan verbinden. Het root certificaat moet dan in het eigen Thunderbird certificatenbeheer sectie Organisaties worden ingevoerd, en de private-publieke certificaat in de sectie Uw Certificaten.
Het maken van deze certificaten in XCA is niet moeilijk.

Wat overblijft, en daar ben ik nog mee bezig is, hoe krijg ik mijn versleutelingscertificaat bij iemand anders in het certificatenbeheer van Thunderbird.
Volgens de informatie die ik nu heb, en dat moet ik nog in de praktijk uitproberen, is dat op de volgende wijze.
Maak een e-mail bericht , en ondertekend die e-mail met uw digitale handtekening, en verzend deze naar een persoon die
uw versleutelingscertificaat nog niet heeft. In dat bericht zit dan automatisch dit certificaat, en als het goed is importeert Thunderbird deze ook automatisch in het certificatenbeheer.

De end to end encryptie die Google in de toekomst voor e-mail zegt te gaan aanbieden zal uiteindelijk ook nog steeds voor Google leesbaar zijn, immers het is ook een verdienmodel.

Als ik het goed heb gelezen, moet je met het programma XCA een eigen rootcertificaat CA creëren, en deze moet vervolgens in het C-beheer van Thunderbird worden geimporteerd. Daarna moet ik met XCA aan het rootcertificaat een clientcertificaat creëren die daar dan ook aan verbonden is. Dit certificaat moet ik in Thunderbird C-beheer importeren, en dat is eigenlijk alles.

Hoezo toekomst de link is naar een artikel hier uit 2014 dus 3 jaar geleden. Is dit nonchalance of trollengedrag.

Ik moet een klein excuus maken aan de reactie van anoniem 09:04, die wel bijna de juiste procedure voor het gebruik van Thunderbird certificaten benoemde. Aan de andere kant ben ik ook pissig, omdat hij of zij dit niet met argumenten heeft onderbouwd. d.w.z. was het kennis van zaken, of slechts speculeren.

Iedere PC heeft zeker een kleine honderd vertrouwenscertificaten in zijn beheer, en die kunnen door iedereen ook worden geexporteert c.q. gekopieerd en worden opgeslagen waar dan ook.Deze (crt) bestanden zijn zwaar versleuteld, en alleen degene die het origineel bezit kan deze bewerken.

Implementatie in Thunderbird
De laatste procedure gaat dan ook als volgt; ieder die gebruik wil maken van certificaat versleuteling moet onderling elkaars zelf ondertekende vertrouwenscertificaat als bijlage toesturen. Deze moet net als de eigen ontworpen vertrouwenscertificaat in Thunderbird certificaatbeheer in de sectie [Organisaties] worden geïmporteerd. Dit is een simpele handeling. Om te kunnen versleutelen c.q. ondertekenen moet de eigenaar van de computer zijn private-publieke sleutel eerst in het certificaatbeheer sectie [Uw Certificaten] importeren. Het certificaat is door het email adres dat in het certificaat is opgenomen aan het account met dat email adres gekoppeld. In Accountinstellingen/Beveiliging word het juiste certificaat automatisch gevonden wanneer op de optie [Selecteren] wordt geklikt.

publieke sleutel
Wanneer de personen A en B hun vertrouwenscertificaat hebben toegestuurd, en deze hebben opgenomen in het Thunderbird certificaatbeheer, dan gaat het opnemen van de publieke sleutel als volgt. A stuurt een gewone mail naar B, maar ondertekend die mail. wanneer B dat bericht ontvangt, zal Thunderbird automatisch zoeken naar het vertrouwenscertificaat van A, en als die gevonden wordt, importeert Thunderbird de publieke sleutel die aan het mailbericht vastzit in het Thunderbird certificaatbeheer in de sectie [Personen]. visa versa.
De enige keer dat je een wachtwoord moet invoeren, is wanneer je de private-publieke sleutel in het certificaatbeheer importeert.

Uiteraard zou Mozilla Thunderbird een hedendaagse handleiding moeten maken, zowel voor het ontwerpen middels XCA van de certificaten als het exporteren en opnemen in Thunderbird. Het is dan ook onbegrijpelijk, dat Mozilla die enige jaren geleden nog hebben overwogen de ontwikkeling van Thunderbird te staken, en nu het privacy en briefgeheim van e-mails zo actueel is, deze mogelijk niet snel uit de kast haalt.

Goed dat het gelukt is en fijn dat je het even meldt.

Nu je het eenmaal doorhebt, voor deze ene taak. XCA is inderdaad een prima ding voor deze ene taak, maar het wordt anders als je, bijvoorbeeld, de boel wil kunnen scripten. Je bent blij dat je het uitgevogeld hebt, gefeliciteerd, maar het kostte veel moeite deze ene toepassing uit te vogelen en er zijn er veel meer. Dat maakt niet het hele certificatengedoe "kinderlijk eenvoudig".

Ik weet uit ervaring (zelf met XCA gewerkt ~13 jaar terug, zelf met openssl en scripting een CA opgezet, zelf het beheer gedaan en zelf het ondertussen allemaal weer vergeten, weer op moeten halen, en nog een keer vergeten) dat het gewoon ingewikkelde materie is, en PKI maakt het er niet makkelijker op. Zorg dat je goed documenteert wat je gedaan hebt zodat je later je notities nog eens na kan kijken.

Voor nauw verbonden accounts, waarbij je zelf de certificaatuitgifte kan regelen. Merk op dat alle communicanten nu afhankelijk zijn van een gecentraliseerd rootcertificaat.

Zodra je met anderen buiten je eigen nauwverbonden clubje wil communiceren loop je tegen practische problemen aan.
Bijvoorbeeld zodra je over een "organisatiegrens" heen gaat, zeg maar communicatie tussen meerdere administratieve eenheiden wil opzetten. Wie mag er de baas spelen? Ojee, politiek gekonkel.


GPG doet alle twee de sleutelparen in één stap. Je kan het wel met de hand doen als je wil, maar de standaardopzet is een ondertekensleutel en een encryptiesleutel. Dus twee publiek/private sleutelparen.

Daar zit wel een extra stap in voor je communicatiepartner: Die moet jouw sleutel signeren om daarmee expliciet aan het programma duidelijk te maken dat hij jouw sleutel vertrouwt als komende van jou. Dat doet S/MIME alleen door op rootcertificaten te vertrouwen. (GPG/PGP laat vele signaturen op een sleutel toe, PKI certificaten hebben altijd precies één signatuur, van een "hogere autoriteit", of zichzelf.)

Dat is waarom je derde partijen CA laat spelen, zodat het rootcertificaat "alvast" in hun lijstje voorkomt. Dat het vervolgens commerciële bedrijven zijn die je beschermen tegen iedereen van wie ze geen geld aannemen laten we even buiten beschouwing.

Het "eind"certificaat of het rootcertificaat?

Zoals Anoniem 20:21 zal begrijpen, hebben we het hier niet over bedrijfsmatig gebruik van certificaten als oplossing tegen meekijken door derden, maar gewoon de gemiddelde gebruiker. Tevens zal hij begrijpen dat ik geen autoriteit op dit gebied ben,of dat zelfs maar pretendeert, immers het heeft veel moeite gekost om één en ander uit te vogelen. De gemiddelde gebruiker wil een gemakkelijke methode die een terecht gevoel van veiligheid met zich meebrengt. PGP en aanverwant heeft een moeilijkheidsgraad die de mensen doet afhaken. samengevat de gewone gebruiker wil een beveiliging die volledig buiten hem of haar omgaat. Ik heb met het uitzoeken hoe dit met certificaten in Thunderbird en Microsoft Outlook mogelijk is, zeker een aantal mensen bereikt die dit nu zelf eens gaan proberen.

Natuurlijk zijn de certificaten die de gebruiker met XCA kan maken niet de meest geavanceerde, maar ze doen gewoon waarvoor ze worden gemaakt, en dat is controleren en versleutelen, zonder dat de gebruiker wachtwoorden moet onthouden, en de integriteit en opmaak van de e-mail blijft onveranderd, tot in tegenstelling met GPG bijvoorbeeld, dat alleen maar platte tekst kan versleutelen, en ontzettend ergerlijk, dat je de uitkomst altijd in een externe viewer moet bekijken.

Dat er een certificaat van degene die met je mailt in het certificaatbeheer moet worden geplaatst doet niets af aan de veiligheid. Die veiligheid is voornamelijk afhankelijk van de wijze waarop de gebruiker met zijn computer omgaat.

Vaststaat dat Google (Gmail) de grootse bij gebruik van versleuteling niet meer kan lezen wat er in de email van haar gebruikers staat. En ik durf te beweren dat als haar verdienmodel daarmee in gevaar komt zal ze snel met een end to end encryptie komen, maar dat end is dan wel weerop de mailservers van Google, zodat ze weer kunnen mee lezen.

Enigmail dwingt een wachtwoord van minimaal 8 tekens af. https://enigmail.wiki/Notes,_Tips_%26_Tricks#How_to_choose_a_good_passphrase. Maar het onderliggende GnuPG staat ook een leeg wachtwoord toe in verband met scripts! Het zou mij niets verbazen als je je wachtwoord in Enigmail leeg kunt maken met behulp van GnuPG.
Rich HTML gebruik ik zelf nooit in mailtjes, maar met PGP/MIME kun je prima attachments encrypten. Dus die Rich HTML mailtjes zullen ook wel werken.
Met Enigmail kun je alles gewoon in Thunderbird bekijken zoals gewone mail. Er komen alleen een paar regeltjes bij met informatie over je encryptie. Of er een werkende plugin voor Outlook is, dat weet ik niet. Ik vermoed van niet. Misschien dat symantec daar nog iets voor in de aanbieding heeft.

Het gehele internet wordt beveiligt door middel van certificaten. Banken, Overheid en Online winkels enz. waarmee je veilig kunt corresponderen zouden niet zonder certificaten kunnen werken. De mogelijkheid om via een zelfgemaakt certificaat je eigen emailverkeer met de door jouzelf gekozen personen veilig en anoniem voor de ogen van derden te voeren is een privilege die je zelf nu kunt creëren. Het gereedschap dat XCA heet is niet meer dan en grafische schil om Open-SSL certificaten maken voor het grote publiek toegankelijk te maken.

Laat je vooral niet gek maken door complotdenkers en trollen.

Het gehele internet? Nee... een klein uithoekje houdt nog stand. Zeg maar overal waar ofwel geen encryptie gebruikt wordt, ofwel iets anders dan PKI certificaten. Die certificaten zijn vooral populair bij websites, en, hm, dat was het wel zo'n beetje.

Je verwart dus "het wereldwijde web" en "het internet". Die toch duidelijk verschillend zijn. Het een bouwt op het ander, maar ze zijn niet hetzelfde.

Dat zou niet kunnen zonder encryptie, maar dat is niet afhankelijk van PKI "certificaten".

En afgezien van de problemen met de code, zitten er duidelijke problemen in de organisatie eromheen. Dat mag best gezegd worden.

Een privilege? Ik heb van niemand toestemming nodig.

Nouja, je moet nog steeds enigszins weten wat je doet. En grafische schillen hebben zo hun eigen beperkingen. Daar ging die eerdere opmerking over. Dat wil niet zeggen dat XCA daarmee ongeschikt is om te gebruiken. Wel dat het een nuttig gereedschap is voor een zekere deelverzameling van toepassingen, maar minder nuttig voor andere. En het blijft staan dat uitvogelen hoe je nu precies een certificaat of een CA+certificaten opzet een hoop piel- en giswerk blijft, zelfs met dat vreselijk handige XCA. Gewoon omdat de beschikbare informatie versnipperd, onduidelijk, en zelfs verwarrend is.

Je zegt eigenlijk, "het werkt, dus er zitten geen gaten in, dus werkt correct, en kan niet beter. Alle kritiek is aluhoedjesgezeik en heeft als doel je op het verkeerde been te zetten."

Ik denk dat dat zowel ernstig onconstructief is als niet thuishoort in de securitywereld.

Als je kijkt wat verschillende bedrijven als "gemiddelde gebruiker" aannemen, dan zitten we daar al ruim boven. En het blijft een hoop gedoe om het werkend te krijgen.

Dat is verder prima, en gefeliciteerd. Maar je zei ook dat het eigenlijk "kinderlijk eenvoudig" was, en dat is het gewoon niet.

Encryptie is lastige materie. De beschikbare software maakt dat nog eens een stapje ingewikkelder. Niet alleen openssl overigens, lees maar eens "Why Johnny Can't Encrypt", dat gaat over PGP. Dat gaat over "recht-op-en-neer" gebruik en nog niet eens over het "web of trust" dat er ook nog in zit. Je moet daar wel iets van weten, anders weet je niet wat allerlei parameters betekenen die je wel correct moet invullen anders kun je hele rare verassingen tegenkomen.

GPG heeft ook zo zijn eigenaardigheden. Overigens heeft die ook een soortement van XCA beschikbaar. Dat stuk software heet "kleopatra" en het zit al in de GPG4WIN bundel.

Waarom noem ik toch iedere keer PGP/GPG? Omdat dat ietsje populairder is dan S/MIME voor versleutelde email.

Dat stukje "terecht" heb je helemaal gelijk in, en... is ook gelijk waarom je niet zomaar ergens encryptie tegenaan kan gooien en "jut ist". Je moet echt even snappen waar het over gaat, tenminste in vogelvlucht.

Ik zie dat je in de verdediging schiet, onder andere door je te verbergen achter allerlei veel te formeel gestuntel in je proza.

Het is niet mijn bedoeling je aan te vallen. Wat ik wel even wil aanstippen is dat precies in de security je er niet omheen komt om nietsontziend de realiteit recht aan te kijken. Als je dat niet aankan dan loop je het risico om er later achter te komen dat je jezelf voor de gek hebt weten te houden. Als je pech hebt, kan dat in de papieren lopen.

Mwa, GPG is in mijn ervaring een stukje makkelijker, in ieder geval wat betreft sleutelbeheer en distributie. Soms zelfs té makkelijk, bijvoorbeeld bij het exporteren van andermans sleutels naar keyservers. Niet iedereen heeft daar zin in.

Maargoed, de problemen die je beschrijft loop ik niet zo snel tegenaan omdat ik bijvoorbeeld vooral kale tekst als email verstuur. Want html hoort echt niet in emails en kan makkelijk uitlopen op allerlei datalekken en andere problemen, via tracking pixels, javascript, "gebruiksvriendelijke software", en zo verder. Ook omdat ik een email client gebruik die redelijk goed met GPG geintegreerd is (mutt). Wat niet wil zeggen dat het allemaal perfect werkt. Zeker thunderbird+enigmail zitten hele rare quirks in. Maar wat jij beschrijft heb ik zelf niet gezien.

Hoe dan ook, prima dat deze opzet voor jou werkt. Verwar alleen niet de problemen met een email client met problemen met de encryptiemethode. Je kan ook een andere client pakken. Er zijn er best wel veel, en zowel thunderbird als outlook zijn niet echt de beste die je hebben kan. Ondanks hun populariteit.

Encryptiesleutels (zoals de private sleutel die bij een certificaat hoort) zonder wachtwoord betekenen dat die sleutels zelf niet versleuteld zijn (met dat wachtwoord). Dat betekent dat alle malware en andere ongenode pottekijkers ook die sleutel kunnen gebruiken, wellicht zelfs een kopietje van trekken. En met bezit van de sleutel is bezit van de identiteit van zo'n certificaat. En dus is geen wachtwoord gebruiken een risico.

Ze claimen dat ze gestopt zijn de mail van hun gebruikers te lezen. Wat dat betekent voor de toekomst van gmail? Geen idee.

Dat zou betekenen dat willekeurig welke overheid van google kan^Wgaat verwachten dat ze die encryptie ook ongedaan kan maken als een rechter dat beveelt.