Een Public Key Infrastructure (PKI) is een reeks rollen, beleid, hardware, software en procedures die nodig zijn voor het maken, beheren, distribueren, gebruiken, opslaan en intrekken van digitale certificaten en voor het beheren van encryptie met publieke sleutels.

Het doel van een PKI is om een veilige elektronische overdracht van informatie voor een reeks netwerkactiviteiten, zoals e-commerce, internetbankieren en vertrouwelijke e-mail, te faciliteren. Het is vereist voor activiteiten waarbij eenvoudige wachtwoorden een ontoereikende authenticatiemethode zijn en er meer rigoureus bewijs nodig is om de identiteit van de bij de communicatie betrokken partijen te bevestigen en de overgedragen informatie te valideren.

Afbeelding: “Public-Key-Infrastructure.svg”, gecreëerd door Chris (Chrkl), gelicentieerd onder de Creative Commons Naamsvermelding-GelijkDelen 3.0 Unported-licentie (CC BY‑SA 3.0). Bron: https://commons.wikimedia.org/wiki/File:Public-Key-Infrastructure.svg(commons.wikimedia.org in Bing)

In cryptografie is een PKI een regeling die publieke sleutels verbindt met de respectievelijke identiteiten van entiteiten (zoals mensen en organisaties). De binding komt tot stand via een proces van registratie en uitgifte van certificaten bij en door een certificaatautoriteit (CA). Afhankelijk van het garantieniveau van de binding, kan dit worden uitgevoerd door een geautomatiseerd proces of onder menselijk toezicht. Als dit via een netwerk gebeurt, moet er een veilig certificaatregistratie- of certificaatbeheerprotocol zoals CMP worden gebruikt.

De PKI-rol die door een CA kan worden gedelegeerd om een geldige en correcte registratie te verzekeren, wordt een registratieautoriteit (RA) genoemd. Een RA is verantwoordelijk voor het aanvaarden van aanvragen voor digitale certificaten en het authentiseren van de entiteit die de aanvraag indient. RFC 3647 van de Internet Engineering Task Force definieert een RA als “Een entiteit die verantwoordelijk is voor één of meer van de volgende functies: de identificatie en authenticatie van certificaataanvragers, het goedkeuren of afwijzen van certificaataanvragen, het initiëren van certificaatintrekkingen of schorsingen onder bepaalde omstandigheden, het verwerken van verzoeken van abonnees om hun certificaten in te trekken of te schorsen, en het goedkeuren of afwijzen van verzoeken van abonnees om hun certificaten te vernieuwen of opnieuw te keyen. RA's ondertekenen of geven echter geen certificaten uit (d.w.z., een RA heeft bepaalde taken gedelegeerd in naam van een CA).”Hoewel Microsoft misschien heeft verwezen naar een ondergeschikte CA als een RA, is dit onjuist volgens de X.509 PKI-standaarden. RA's hebben niet de ondertekeningsbevoegdheid van een CA en beheren alleen het doorlichten en verstrekken van certificaten. Dus in het geval van Microsoft PKI wordt de RA-functionaliteit geleverd door de Microsoft Certificate Services website of door Active Directory Certificate Services die Microsoft Enterprise CA en certificaatbeleid afdwingt door middel van certificaatsjablonen en de certificaatinschrijving beheert (handmatig of automatisch). In het geval van Microsoft Standalone CA's bestaat de functie van RA niet aangezien alle procedures die de CA controleren gebaseerd zijn op de administratie- en toegangsprocedure die geassocieerd zijn met het systeem dat de CA host en de CA zelf in plaats van Active Directory. De meeste commerciële PKI-oplossingen die niet van Microsoft zijn, bieden een stand-alone RA-component.

Een entiteit moet binnen elk CA-domein uniek identificeerbaar zijn op basis van informatie over die entiteit. Een externe validatieautoriteit (VA) kan deze entiteitsinformatie namens de CA verstrekken.

De X.509-standaard definieert het meest gebruikte formaat voor openbare-sleutelcertificaten.

Capaciteiten

PKI biedt “vertrouwensdiensten” – in gewoon taalvertrouwen in de acties of uitkomsten van entiteiten, hetzij personen of computers. De doelstellingen van vertrouwensdiensten respecteren een of meer van de volgende mogelijkheden: Vertrouwelijkheid, Integriteit en Authenticiteit (VIA).

Vertrouwelijkheid: Garantie dat geen enkele entiteit kwaadwillig of onbewust een payload in platte tekst kan bekijken. Gegevens worden versleuteld om ze geheim te maken, zodat ze, zelfs als ze worden gelezen, als onzin overkomen. Waarschijnlijk het meest voorkomende gebruik van PKI voor vertrouwelijkheidsdoeleinden is in de context van Transport Layer Security (TLS). TLS is een mogelijkheid die de beveiliging van gegevens tijdens transport, oftewel tijdens verzending, onderbouwt. Een klassiek voorbeeld van TLS voor vertrouwelijkheid is wanneer een webbrowser wordt gebruikt om in te loggen op een dienst die wordt gehost op een internetgebaseerde website door een wachtwoord in te voeren.

Integriteit: Garandeert dat als een entiteit de verzonden gegevens ook maar enigszins verandert (manipuleert), dit duidelijk zichtbaar is omdat de integriteit ervan in gevaar zou zijn gebracht. Vaak is het niet van het grootste belang om te voorkomen dat de integriteit in gevaar komt (manipulatiebestendig), maar het is wel van het grootste belang dat er duidelijk bewijs is dat dit is gebeurd als de integriteit in gevaar komt (manipulatieaantoonbaar).

Authenticiteit: Zekerheid dat een entiteit het volgende heeft: i) zekerheid over waarmee het verbinding maakt; en/of ii) kan haar eigen legitimiteit bewijzen bij het verbinden met een beveiligde dienst. De eerste wordt aangeduid als servercertificaatauthenticatie, doorgaans gebruikt bij het inloggen op een webserver. De laatste wordt aangewezen als clientcertificaatauthenticatie, bijvoorbeeld gebruikt bij het inloggen met een smartcard waarop een digitaal certificaat en een privésleutel zijn opgeslagen.

Ontwerp

Publieke-sleutelcryptografie is een cryptografische techniek die entiteiten in staat stelt veilig te communiceren op een onzeker openbaar netwerk, en betrouwbaar de identiteit van een entiteit te verifiëren via digitale handtekeningen.

Een Public Key Infrastructure (PKI) is een systeem voor het aanmaken, opslaan en distribueren van digitale certificaten, die worden gebruikt om te verifiëren dat een bepaalde publieke sleutel behoort tot een bepaalde entiteit. De PKI maakt digitale certificaten aan die publieke sleutels koppelen aan entiteiten, slaat deze certificaten veilig op in een centrale opslagplaats en trekt ze zo nodig in.

Een PKI bestaat uit:

  • Een certificeringsinstantie (CA), die de digitale certificaten opslaat, uitgeeft en ondertekent;
  • Een registratieautoriteit (RA), die de identiteit verifieert van entiteiten die hun digitale certificaten laten opslaan bij de CA;
  • Een centrale directory, een veilige locatie waarin sleutels worden opgeslagen en geïndexeerd;
  • Een certificaatbeheersysteem, dat zaken regelt zoals de toegang tot opgeslagen certificaten of de aflevering van uit te geven certificaten;
  • Een certificaatbeleid, dat de vereisten van de PKI met betrekking tot zijn procedures stelt. Het doel ervan is om buitenstaanders in staat te stellen het vertrouwen van de PKI te analyseren.

Certificeringsmethoden

Certificaatautoriteiten

Hoofdartikel: Certificeringsinstantie

De primaire rol van de CA is het digitaal ondertekenen en publiceren van de publieke sleutel die aan een bepaalde gebruiker is gekoppeld. Dit gebeurt met de eigen privésleutel van de CA, zodat het vertrouwen in de gebruikerssleutel afhangt van het vertrouwen in de geldigheid van de sleutel van de CA. Wanneer de CA een derde partij is, gescheiden van de gebruiker en het systeem, wordt deze de Registration Authority (RA) genoemd, die al dan niet gescheiden kan zijn van de CA. De sleutel-naar-gebruiker koppeling wordt vastgesteld, afhankelijk van het niveau van zekerheid van de koppeling, door middel van software of onder menselijk toezicht.

De term 'trusted third party' (TTP) kan ook gebruikt worden voor een certificaatautoriteit (CA). Bovendien wordt PKI zelf vaak gebruikt als synoniem voor een CA-implementatie.

Certificaatintrekking

Hoofdartikel: Certificaatintrekking

Een certificaat kan worden ingetrokken voordat het vervalt, wat aangeeft dat het niet langer geldig is. Zonder intrekking zou een aanvaller een dergelijk gecompromitteerd of verkeerd uitgegeven certificaat tot de vervaldatum kunnen misbruiken. Daarom is intrekking een belangrijk onderdeel van een publieke sleutelinfra. Intrekking wordt uitgevoerd door de uitgevende certificeringsinstantie, die een cryptografisch geauthentiseerde verklaring van intrekking produceert.

Voor het distribueren van intrekkingsinformatie aan clients, staat de tijdigheid van de detectie van intrekking (en dus het venster waarbinnen een aanvaller een gecompromitteerd certificaat kan misbruiken) in wisselwerking met het resourcegebruik bij het bevragen van intrekkingsstatussen en privacyzorgen. Als intrekkingsinformatie niet beschikbaar is (hetzij door een ongeval of een aanval), moeten clients beslissen of ze zich strikt onthouden en een certificaat behandelen alsof het is ingetrokken (en zo de beschikbaarheid verminderen) of dat ze zich flexibel opstellen en het als niet-ingetrokken behandelen (en aanvallers de mogelijkheid geven om intrekking te omzeilen).

Vanwege de kosten van intrekkingcontroles en de impact op de beschikbaarheid van potentieel onbetrouwbare externe services, beperken webbrowsers de intrekkingcontroles die ze uitvoeren en zullen ze bij falen een 'fail-soft'-strategie volgen. Certificaatintrekkinglijsten zijn te bandbreedte-kostbaar voor routinematig gebruik, en het Online Certificate Status Protocol (OCSP) introduceert verbindingslatentie en privacyproblemen. Andere schema's zijn voorgesteld, maar zijn nog niet succesvol geïmplementeerd om 'fail-hard'-controles mogelijk te maken.

Marktaandeel emittent

In dit model van vertrouwensrelaties is een CA een vertrouwde derde partij - vertrouwd door zowel het subject (eigenaar) van het certificaat als door de partij die op het certificaat vertrouwt.

Volgens het NetCraft-rapport van 2015, de industriestandaard voor het monitoren van actieve Transport Layer Security (TLS)-certificaten, staat dat “Hoewel het wereldwijde [TLS]-ecosysteem concurrerend is, wordt het gedomineerd door een handvol grote CA's — drie certificeringsinstanties (Symantec, Sectigo, GoDaddy) zijn goed voor driekwart van alle uitgegeven [TLS]-certificaten op publiek toegankelijke webservers. De toppositie is ingenomen door Symantec (of VeriSign voordat het door Symantec werd gekocht) sinds [onze] enquête begon, met momenteel iets minder dan een derde van alle certificaten. Om het effect van verschillende methodologieën te illustreren, gaf Symantec onder de miljoen drukste sites 44% van de geldige, vertrouwde certificaten die in gebruik zijn uit — aanzienlijk meer dan zijn totale marktaandeel.”

Na grote problemen met het beheer van de uitgifte van certificaten, vertrouwden alle belangrijke spelers geleidelijk de door Symantec uitgegeven certificaten niet meer, beginnend in 2017 en voltooid in 2021.

Tijdelijke certificaten en single sign-on

Deze aanpak omvat een server die fungeert als een offline certificeringsinstantie binnen een single sign-on systeem. Een single sign-on server geeft digitale certificaten uit aan het clientsysteem, maar slaat ze nooit op. Gebruikers kunnen programma's, etc. uitvoeren met het tijdelijke certificaat. Deze oplossingsvariant komt vaak voor met X.509-gebaseerde certificaten.

Vanaf sep 2020 is de geldigheid van TLS-certificaten teruggebracht naar 13 maanden.

Web van vertrouwen

Hoofdartikel: Web of trust

Een alternatieve benadering van het probleem van openbare authenticatie van publieke sleutelinformatie is het web-of-trust-schema, dat zelfondertekende certificaten en getuigenissen van derden van die certificaten gebruikt. De enkelvoudige term “web of trust” impliceert niet het bestaan van één enkel web of trust, of gemeenschappelijk vertrouwenspunt, maar eerder een van de vele potentieel afzonderlijke “webs of trust”. Voorbeelden van implementaties van deze benadering zijn PGP (Pretty Good Privacy) en GnuPG (een implementatie van OpenPGP, de gestandaardiseerde specificatie van PGP). Omdat PGP en implementaties het gebruik van digitale e-mailondertekeningen voor zelfpublicatie van publieke sleutelinformatie toestaan, is het relatief eenvoudig om je eigen web of trust te implementeren.

Een van de voordelen van het web of trust, zoals in PGP, is dat het kan samenwerken met een PKI CA die volledig vertrouwd wordt door alle partijen in een domein (zoals een interne CA in een bedrijf) en die bereid is certificaten te garanderen, als een vertrouwde introducent. Als het “web of trust” volledig wordt vertrouwd, dan, vanwege de aard van een web of trust, betekent het vertrouwen van één certificaat het verlenen van vertrouwen aan alle certificaten in dat web. Een PKI is slechts zo waardevol als de standaarden en procedures die de uitgifte van certificaten controleren en het opnemen van PGP of een persoonlijk geïnstalleerd web of trust kan de betrouwbaarheid van de implementatie van PKI van die onderneming of dat domein aanzienlijk verminderen.

Het web of trust concept werd voor het eerst voorgesteld door PGP-maker Phil Zimmermann in 1992 in de handleiding voor PGP versie 2.0:

Na verloop van tijd zul je sleutels verzamelen van andere mensen die je misschien wilt aanwijzen als vertrouwde introducé. Alle anderen zullen hun eigen vertrouwde introducers kiezen. En iedereen zal geleidelijk aan een verzameling certificerende handtekeningen van andere mensen verzamelen en samen met hun sleutel verspreiden, met de verwachting dat iedereen die het ontvangt ten minste één of twee van de handtekeningen zal vertrouwen. Dit zal leiden tot het ontstaan van een gedecentraliseerd fouttolerant web van vertrouwen voor alle publieke sleutels.

Eenvoudige Public Key Infrastructuur

Hoofdartikel: Simple public-key infrastructure

Een ander alternatief, dat zich niet bezighoudt met openbare authenticatie van publieke sleutelinformatie, is de Simple Public Key Infrastructure (SPKI), die voortkwam uit drie onafhankelijke inspanningen om de complexiteit van X.509 en het web van vertrouwen van PGP te overwinnen. SPKI associeert geen gebruikers met personen, aangezien de sleutel degene is die wordt vertrouwd, in plaats van de persoon. SPKI maakt geen gebruik van enig concept van vertrouwen, aangezien de verificateur ook de uitgever is. Dit wordt in de SPKI-terminologie een “autorisatieloop” genoemd, waarbij autorisatie integraal deel uitmaakt van het ontwerp. Dit type PKI is bijzonder nuttig voor het maken van integraties van PKI die niet afhankelijk zijn van derden voor certificeringsautorisatie, certificaatinformatie, enz.; een goed voorbeeld hiervan is een air-gapped netwerk in een kantoor.

Gedecentraliseerde PKI

Gedecentraliseerde identificeerders (DID's) elimineren de afhankelijkheid van gecentraliseerde registers voor identificeerders, evenals van gecentraliseerde certificeringsinstanties voor sleutelbeheer, wat de standaard is in hiërarchische PKI. In gevallen waarin het DID-register een gedistribueerd grootboek is, kan elke entiteit als zijn eigen root-autoriteit fungeren. Deze architectuur wordt gedecentraliseerde PKI (DPKI) genoemd.

Geschiedenis

Ontwikkelingen in PKI vonden plaats in de vroege jaren 70 bij de Britse inlichtingendienst GCHQ, waar James Ellis, Clifford Cocks en anderen belangrijke ontdekkingen deden met betrekking tot encryptie-algoritmen en sleuteldistributie. Omdat de ontwikkelingen bij GCHQ zeer geheim zijn, bleven de resultaten van dit werk geheim en werden ze pas halverwege de jaren 90 publiekelijk erkend.

De openbaarmaking van zowel beveiligde sleuteluitwisseling als asymmetrische sleutelalgoritmen in 1976 door Diffie, Hellman, Rivest, Shamir en Adleman veranderde veilige communicatie volledig. Met de verdere ontwikkeling van digitale elektronische communicatie met hoge snelheid (het internet en zijn voorgangers) werd de behoefte duidelijk aan manieren waarop gebruikers veilig met elkaar konden communiceren, en als verdere consequentie daarvan, aan manieren waarop gebruikers er zeker van konden zijn met wie ze daadwerkelijk communiceerden.

Verschillende cryptografische protocollen werden uitgevonden en geanalyseerd waarin nieuwe cryptografische primitieven effectief konden worden gebruikt. Met de uitvinding van het World Wide Web en de snelle verspreiding ervan werd de behoefte aan authenticatie en veilige communicatie nog groter. Commerciële redenen alleen al (bijv. e-commerce, online toegang tot propriëtaire databases vanaf webbrowsers) waren voldoende. Taher Elgamal en anderen bij Netscape ontwikkelden het SSL-protocol (‘https’ in web-URL's); dit omvatte sleuteluitwisseling, serverauthenticatie (vóór v3, slechts éénrichtingsverkeer) enzovoort. Er werd aldus een PKI-structuur gecreëerd voor webgebruikers/sites die veilige communicatie wensten.

Leveranciers en ondernemers zagen de mogelijkheid van een grote markt, startten bedrijven (of nieuwe projecten bij bestaande bedrijven) en begonnen te ijveren voor wettelijke erkenning en bescherming tegen aansprakelijkheid. Een technologieproject van de American Bar Association publiceerde een uitgebreide analyse van enkele voorzienbare juridische aspecten van PKI-operaties (zie ABA digitale handtekeningrichtlijnen), en kort daarna begonnen verschillende Amerikaanse staten (Utah als eerste in 1995) en andere jurisdicties over de hele wereld wetten aan te nemen en regelgeving in te voeren. Consumentengroepen stelden vragen over privacy, toegang en aansprakelijkheid, die in sommige rechtsgebieden meer werden overwogen dan in andere.

De ingevoerde wetten en regelgeving verschilden, er waren technische en operationele problemen bij het succesvol commercieel omzetten van PKI-schema's, en de vooruitgang is veel langzamer verlopen dan pioniers zich hadden voorgesteld.

In de eerste paar jaar van de 21e eeuw was de onderliggende cryptografische engineering duidelijk niet eenvoudig correct te implementeren. Operationele procedures (handmatig of automatisch) waren niet eenvoudig correct te ontwerpen (nog zelfs als dat zo ontworpen was, om ze perfect uit te voeren, wat de engineering vereiste). De bestaande standaarden waren ontoereikend.

PKI-leveranciers hebben een markt gevonden, maar het is niet helemaal de markt die in het midden van de jaren negentig werd voorzien, en deze is zowel langzamer gegroeid als op enigszins andere manieren dan werd verwacht. PKI's hebben enkele van de problemen die ze moesten oplossen niet opgelost, en verschillende grote leveranciers zijn failliet gegaan of zijn overgenomen door anderen. PKI heeft het meeste succes gehad in overheidsimplementaties; de tot nu toe grootste PKI-implementatie is de PKI-infrastructuur van de Defense Information Systems Agency (DISA) voor het Common Access Cards-programma.

Gebruikt

PKI's van de ene of andere soort, en van diverse leveranciers, hebben vele toepassingen, waaronder het leveren van publieke sleutels en koppelingen aan gebruikersidentiteiten, die gebruikt worden voor:

Encryptie en/of afzenderauthenticatie van e-mailberichten (bijvoorbeeld met OpenPGP of S/MIME);

Encryptie en/of authenticatie van documenten (bijvoorbeeld de standaarden voor XML-handtekeningen of XML-encryptie als documenten zijn gecodeerd als XML);

Authenticatie van gebruikers bij applicaties (bijvoorbeeld inloggen met een smartcard, clientauthenticatie met SSL/TLS). Er is experimenteel gebruik voor digitaal ondertekende HTTP-authenticatie in de projecten Enigform en mod_openpgp;

Het opstarten van veilige communicatieprotocollen, zoals Internet Key Exchange (IKE) en SSL/TLS. In beide gevallen maakt de initiële opzet van een veilig kanaal (een “security association”) gebruik van asymmetrische sleutelmethoden, d.w.z. publieke sleutelmethoden, terwijl de eigenlijke communicatie gebruikmaakt van snellere symmetrische sleutelmethoden, d.w.z. geheime sleutelmethoden.;

Mobiele handtekeningen zijn elektronische handtekeningen die worden gecreëerd met een mobiel apparaat en gebruikmaken van handtekening- of certificeringsdiensten in een locatie-onafhankelijke telecommunicatieomgeving;

Internet of Things vereist veilige communicatie tussen wederzijds vertrouwde apparaten. Een Public Key Infrastructure (PKI) stelt apparaten in staat X.509-certificaten te verkrijgen en te vernieuwen, die worden gebruikt om vertrouwen tussen apparaten tot stand te brengen en communicatie te versleutelen met behulp van TLS.

Open source implementaties

OpenSSL is de eenvoudigste vorm van CA en tool voor PKI. Het is een toolkit, ontwikkeld in C, die is inbegrepen in alle grote Linux-distributies, en zowel kan worden gebruikt om uw eigen (eenvoudige) CA te bouwen als om applicaties PKI-geschikt te maken. (Apache gelicentieerd)

EJBCA is een uitgebreide, enterprise-ready CA-implementatie ontwikkeld in Java. Het kan worden gebruikt om een CA op te zetten, zowel voor intern gebruik als als dienst. (LGPL-gelicentieerd)

XiPKI, CA en OCSP responder. Met SHA-3 ondersteuning, geïmplementeerd in Java. (Apache licentie)

XCA is een grafische interface en database. XCA gebruikt OpenSSL voor de onderliggende PKI-bewerkingen.

DogTag is een volwaardige Certificate Authority (CA) die is ontwikkeld en wordt onderhouden als onderdeel van het Fedora Project.

CFSSL open source toolkit ontwikkeld door CloudFlare voor het ondertekenen, verifiëren en bundelen van TLS-certificaten. (BSD 2-clausule gelicentieerd)

Kluisprogramma voor het veilig beheren van geheimen (inclusief TLS-certificaten) ontwikkeld door HashiCorp (Mozilla Public License 2.0 gelicentieerd)

Boulder, een ACME-gebaseerde CA geschreven in Go. Boulder is de software die Let’s Encrypt draait.

Kritiek

Zie ook: X.509 § Beveiliging, Comodo Group § Inbreukincident 2011 en Diginotar § Uitgifte van frauduleuze certificaten

Sommigen beweren dat het aanschaffen van certificaten voor het beveiligen van websites met SSL/TLS en software met code signing een kostbare onderneming is voor kleine bedrijven. Echter, de opkomst van gratis alternatieven, zoals Let's Encrypt, heeft dit veranderd. HTTP/2, de nieuwste versie van het HTTP-protocol, staat in theorie onbeveiligde verbindingen toe; in de praktijk hebben grote browserbedrijven duidelijk gemaakt dat ze dit protocol alleen zouden ondersteunen via een PKI-beveiligde TLS-verbinding. Webbrowserimplementaties van HTTP/2, waaronder Chrome, Firefox, Opera en Edge, ondersteunen HTTP/2 alleen via TLS door gebruik te maken van de ALPN-extensie van het TLS-protocol. Dit zou betekenen dat website-eigenaren, om de snelheidsvoordelen van HTTP/2 te benutten, gedwongen zouden worden SSL/TLS-certificaten te kopen die door bedrijven worden gecontroleerd.

Momenteel worden de meeste webbrowsers geleverd met vooraf geïnstalleerde tussenliggende certificaten uitgegeven en ondertekend door een certificeringsinstantie, door publieke sleutels die zijn gecertificeerd door zogenaamde rootcertificaten. Dit betekent dat browsers een groot aantal verschillende certificaatproviders moeten meedragen, wat het risico op een sleutelcompromis vergroot.

Wanneer een sleutel bekend is om gecompromitteerd te zijn, kan deze worden opgelost door het certificaat in te trekken, maar een dergelijke compromittering is niet gemakkelijk detecteerbaar en kan een enorme beveiligingsinbreuk zijn. Browsers moeten een beveiligingspatch uitbrengen om tussenliggende certificaten in te trekken die zijn uitgegeven door een gecompromitteerde root certificaatautoriteit.

Gebaseerd op het Wikipedia-artikel “Public key infrastructure”, beschikbaar onder de Creative Commons Naamsvermelding-Gelijk Delen 4.0 Internationale licentie (CC BY‑SA 4.0). Bron: https://en.wikipedia.org/wiki/Public_key_infrastructure