Door Anoniem: Voor particulier gebruik is er niet echt een meerwaarde te bedenken. Voor activisten die vertrouwelijk met elkaar willen mailen, is er Mailvelope, vrij gemakkelijk te installeren als extensie in Firefox en Chrome. Ook is aan te bevelen het gebruik van zelfondertekende Certificaten, maar dan moet je kiezen voor een mailcliënt als Thunderbird of Microsoft Outlook, of een zakelijk mailaccount bij Google Gmail, die in dat geval het gebruik van Certificaten toestaat. Ik bedoel hier niet de TLS (Transport Layer Security) want die wordt standaard al gebruikt, maar het SSL ( Secure Sockets Layer) certificaat.
De term "SSL certificaat" kan verwarrend zijn in je laatste zin. Formeel zijn digitale cerificaten gestandaardiseerd door de ITU (International Telecommunications Union) in X.509.
Belangrijk: het primaire doel van een X.509 certificaat is
authenricatie (niet versleutelen). Dat je een public key in een certificaat ook voor versleuteling kunt gebruiken, is bijzaak.
Je kunt zo'n X.509 certificaat prima vergelijken met een kopie van een paspoort (iedereen kan dit in handen hebben, dus dat bewijst niet de identiteit van degene die zo'n kopie bezit), en een private key met het originele paspoort. Door een wiskundige truc kan de eigenaar van de private key aantonen dat zij deze in bezit heeft, zonder die private key (of het originele paspoort) ooit uit handen te geven (in tegenstelling tot een paspoort mag je een private key nooit aan iemand anders laten zien, dus daar gaat de vergelijking mank).
Vereenvoudigd bestaat een X.509 certificaat (of digitaal certificaat) uit:
1) Eenduidig identificerende gegevens van de eigenaar van een uniek asymmetrisch sleutelpaar (public + private key);
2) De public key;
3) Administratieve gegevens;
4) Een digitale handtekening geplaast door een certificaatverstrekker, een "Trusted Third Party" (de ontvanger van zo'n certificaat moet erop kunnen vertrouwen dat de gegevens in het certificaat juist zijn, met name dat de certificaatverstrekker heeft gecontroleerd dat de public key echt van de geïdentificeerde partij is - en dus niet van een persoon of organisatie die zich voordoet als).
Eén van de "Administratieve gegevens" is het gebruiksdoel. Hoewel meerdere gebruiksdoelen in 1 certificaat mogelijk zijn, is dit niet gebruikelijk. Bekende gebruiksdoelen (of "soorten") certificaten zijn die voor webservers, codesigning, e-mail en certificaatverstrekkers (CA = Certificate Authority). Software die certificaten verwerkt hoort een certificaat dat voor een ander doel wordt gebruikt, te weigeren.
Een webservercertificaat wordt ook wel een "SSL certificaat" genoemd omdat deze wordt gebruikt voor het authenticeren van https webservers - die aanvankelijk SSL verbindingen gebruikten, maar tegenwoordig TLS. Essentieel in zo'n servercertificaat is dat onder de identificerende gegevens 1 of meer domeinnamen (zoals security.nl en www.security.nl) worden genoemd, waar het certificaat dus voor geldt. Maar het kan hierbij ook om een mailserver gaan (bijv. mail.security.nl) waarmee mailservers onderling kunnen authenticeren.
Een e-mail certificaat, ook bekend als S/MIME certificaat, moet (minstens 1) e-mail adres bevatten. Het is m.i. onjuist om zo'n certificaat een "SSL certificaat" te noemen, want daar heeft het niets mee te maken.
Aanvulling/correctie 20171013 06:16: Dat een S/MIME certificaat minstens 1 e-mail adres moet bevatten, had ik fout; mijn excuses. Volgens de laatste specificatie die ik kan vinden,
https://tools.ietf.org/html/rfc5750 punt 3,
hoeft een S/MIME certificaat helemaal geen email adres te bevatten:
End-entity certificates MAY contain an Internet mail address [...]
Receiving agents MUST recognize and accept certificates that contain no email address [...]
Ook lijken andere identificerende gegevens niet vereist, met als gevolg dat een e-mail certificaat niks meer dan een wrapper (envelopje) om een losse public key hoeft te zijn (m.i. bizar). Dit wordt bevestigd in instructies die ik op internet vind om met openssl een e-mail CSR (certificate signing request) te generen, zoals
https://henrytodd.org/notes/2013/generating-your-own-keys-with-smime/. Het nut van een certificaat zonder identificerende eigenschappen ontgaat mij volledig en druist bovendien in tegen het doel van een certificaat, uit
https://tools.ietf.org/html/rfc5280:
Users of a public key require confidence that the associated private key is owned by the correct remote subject (person or system) with which an encryption or digital signature mechanism will be used. This confidence is obtained through the use of public key certificates, which are data structures that bind public key values to subjects. The binding is asserted by having a trusted CA digitally sign each certificate.
Zonder identificerend gegeven in een certificaat valt er voor een ontvanger niks te verifiëren. Certificaatverstrekkers zouden zo'n CSR eigenlijk niet moeten ondertekenen, maar aangezien dit een geldgedreven business is en de specs zuigen, gebeurt dit ongetwijfeld wel.
In dat laatste kader, uit
https://henrytodd.org/notes/2013/generating-your-own-keys-with-smime/:
Every Certificate Authority (CA) offering free personal email certificates that I’ve seen generates the private key for you. I understand that they do this to simplify support and cut costs, but frankly you’re nuts if you’d trust that sort of setup.
In een code signing certificaat moeten de gegevens van de eigenaar uniek zijn zodat verwarring over de ondertekenaar van een bestand kan worden uitgesloten (in tegenstelling tot domeinnamen en e-mail adressen die van zichzelf uniek zijn, geldt dit natuurlijk niet voor persoonsnamen als Jan Jansen en bedrijfsnamen als HiTec).
In tegenstelling tot de hierboven genoemde "end entity" (toepassings-) certificaten, zijn CA certificaten bijzonder omdat deze worden ingezet bij het digitaal ondertekenen van (door certificaatverstrekkers) uitgegeven certificaten. Vaak is hierbij sprake van een vertrouwensketen (chain of trust) met 1 of meer intermediate (tussenliggende) certificaten:
Root cert -> Intermediate cert 1 -> Intermediate cert 2 -> End Entity cert
Hierbij is "Intermediate cert 1" digitaal ondertekend met de private key behorende bij de public key in het Root certificaat, "Intermediate cert 2" is ondertekend met de private key behorende bij de public key in "Intermediate cert 1" en is het "End Entity cert" ondertekend met de private key horende bij de public key in "Intermediate cert 2".
Als jij het root certificaat, dat met jouw besturingssysteem (of webbrowser of Java) is meegeleverd, vertrouwt, en de "andere kant" stuurt jou -naast haar end entity certificaat- ook alle gebruikte intermediate certificaten, dan kan jouw computer door de keten af te lopen, vaststellen of het om een vertrouwd end entity certificaat gaat.
Net zoals certificaatverstrekkers hun (strikt geheime) private keys gebruiken om certificaten digitaal te signeren, kun jij jouw private key(s) gebruiken om jouw e-mails digitaal te ondertekenen. Als de ontvanger via de chain of trust vastelt dat de public key (in het meegeleverde end entity certificaat) van jou is, weet zij redelijk zeker dat jij die mail geschreven moet hebben.
Als je wilt dat uitsluitend een persoon die jij vertrouwt jouw mail kan lezen, kun jij die mail versleutelen met de public key uit het certificaat van de ontvanger [1]. Je moet dan wel zeker weten dat het certificaat echt van de door jou bedoelde persoon is (zit de Jan Jansen die jij bedoelt bij gmail, bij hotmail of ergens anders?). Je kunt zo'n mail, naast versleutelen, ook signeren (met jouw private key) zodat de ontvanger zeker weet dat jij de afzender bent.
[1] Feitelijk genereert jouw computer een random sleutel voor symmetrische encryptie (bijv. AES) waarmee de mail en evt. bijlagen worden versleuteld.
Die symmetrische sleutel wordt met de public key van de ontvanger versleuteld en het resultaat wordt meegestuurd. De ontvanger pakt de symmetrische sleutel uit met haar private key en kan zo de mail en evt. bijlagen ontsleutelen.
Terugkomend op jouw eerste zin:
Door Anoniem: Voor particulier gebruik is er niet echt een meerwaarde te bedenken.
Nou en of. Als alle e-mails digitaal ondertekend zouden zijn en jou dat zekerheid zou geven over de werkelijke,
real life identiteit van afzenders (wie is de persoon of organisatie met dit afzender e-mail adres), zouden phishers het veel moeilijker hebben: ze zouden voor elke phishing mail ongeautoriseerde toegang tot een e-mail account moeten hebben
en digitaal moeten kunnen signeren met de private key van de echte eigenaar van het account.
Daarnaast heeft het pas zin om vertrouwelijke e-mails versleuteld te verzenden als je zeker weet dat de ontvanger echt is wie zij zegt dat zij is, zodat je die versleutelde mail niet naar een bedrieger stuurt (een verkeerd e-mail account dus waarvan jij de public key gebruikt voor het versleutelen).
De redenen dat we nauwelijks e-mails digitaal signeren en/of versleutelen zijn onder meer:
1) Aanvankelijk waren er geen standaarden voor waardoor mail client software het niet ondersteunde;
2) De manier om van een PGP key vast te stellen wie de werkelijke eigenaar is, schaalt niet. Bovendien is PGP voor de meeste mensen zo ingewikkeld dat de foutkans zeer groot is en daarnaast ondersteint Outlook PGP niet (alleen met een plugin en dat werkte, toen ik het gebruikte, maar matig);
3) Doordat je gratis een S/MIME certificaat (in elk geval van Comodo) kunt krijgen als je toegang hebt tot een e-mail account, en mail clients zelden aangeven hoe de de certificaatverstrekker gecontroleerd heeft dat een certificaat niet via onrechtmatige toegang (tot een e-mail account) is verkregen, zijn S/MIME certificaten nagenoeg waardeloos. Zulke certificaten zijn vergelijkbaar met DV (Domain Validated) certificaten voor webservers; deze koppelen slechts 1 identificerend gegeven aan een sleutelpaar (nl. domeinnaam of e-mail adres) zonder dat gecheckt is of de aanvrager de legitieme eigenaar van de webserver of e-mail account is;
4) Vanaf het moment dat je digitaal gesigneerde mails gaat verzenden, zou je dit
voor altijd moeten blijven doen, en ontvangers zouden
elke mail die van jou afkomstig
lijkt maar niet digitaal is ondertekend, als nep moeten beschouwen. Maar ij heb een Outlook versie gezien die alle uitgaande e-mail ondertekende met S/MIME, maar niet vergaderverzoeken (waar ook bijlagen bij kunnen zitten). Waardeloze implementaties vormen dus ook een probleem. Maar het belangrijkste is dat mail clients nu
niet waarschuwen als een niet digitaal gesigneerde e-mail afkomstig lijkt van een individu die haar e-mails wel altijd ondertekent (vergelijkbaar met dat webbrowsers tegenwoordig waarschuwen voor http waar https gebruikt zou moeten worden);
5) De meeste mensen begrijpen het concept achter private en public keys niet, of willen dit niet begrijpen. En dat is m.i. zeer onverstandig, want het is een basisbouwsteen voor digitale communicatie. Dat snappen gaat je voordeel opleveren, niet snappen (en verkeerd gebruiken) gaat je vroeger of later geld kosten.