Digitális aláírás szolgáltatások architektúrája
Gerencsér András
Budapesti Közgazdaságtudományi és Államigazgatási Egyetem,
Információrendszerek Tanszék
h6389ger@helka.iif.hu
A biztonságos elektronikus kommunikáció és kereskedelem egyik lényegi feltételének ismeri már a közvélemény is a digitális, vagy másként elektronikus aláírásnak nevezett eljárást. Az alábbiakban bemutatjuk, hogy a digitális aláírások használatát biztosító szolgáltatásokhoz milyen környezeti és szolgáltatási feltételek, követelmények ismertek, és milyen a mindezek teljesítéséhez szükséges infrastruktúra felépítése, milyen szabványosítási törekvések támogatják. Az infrastruktúra fejlesztéséhez meg kell határozni az architektúrát.
1.	Bevezetés
Az Internet technológiát alkalmazó, összekapcsolódó hálózatok és információs rendszerek szabványos, elosztott biztonsági architektúrájának kialakítása sok évre visszanyúló, hosszú folyamat, az ezredforuló idején azonban az elektronikus aláírás törvényi szintű szabályozása az architektúra bizonyos összetevőire a közvélemény és a politikusok figyelmét is ráirányítja. Az elektronikus aláírás jogi kérdéseinek rendezése felgyorsíthatja a biztonságos üzenetkezelés és az elektronikus kereskedelem hazai elterjedését is, azonban hiba lenne azt gondolni, hogy ezzel minden feltétel teljesült. Közismert, hogy az elektronikus aláírás a kétkulcsos titkosítás alkalmazására épül, ezért használata elképzelhetetlen a támogató nyilvános kulcsú infrastruktúra (a továbbiakban PKI) megfelelő fejlettsége nélkül, azaz a digitális aláírás szolgáltatás lényegében PKI szolgáltatás, ahol jelenleg az RSA féle megoldás a legelterjedtebben használatos.
A PKI szolgáltatásai az azonosítás, jogosítás, titkosítás és a digitális aláírások kulcs menedzsmentjének fontos, általános eszközévé válnak számos Internet/intranet alkalmazásban, beleértve a biztonságos üzenetkezelést és az elektronikus kereskedelmet. A PKI menedzselését illetően azonban jelentős kérdések még megválaszolatlanok, ezért a szervezetek fejlesztőinek, beruházóinak megfontoltan kell dönteniük, miként, mikor és hol telepítsenek PKI termékeket. Sok szállító terméke nem fedi le teljesen a szervezet infrastrukturális igényeit és még időbe telik, míg a konzisztens, PKI szabványú elemek teljes mértékben rendelkezésre állnak. Addig is a PKI-t igénylő alkalmazások fontossága miatt fel kell készülni az együttműködésre képes, hatékony infrastruktúrák elkerülhetetlen telepítésére. 
A PKI jellemzőinek és a használata során felmerülő potenciális problémáinak megértésével jobban felkészülhetünk alkalmazására. Már évek óta, mikor a kliens személyi számítógépekre telepítjük a Netscape Navigátor, vagy a Microsoft Internet Explorer böngészőket, egyben telepítjük a WEB szerverek tanúsítványait is a nyilvános kulcsaikkal együtt, amely biztosítja az SSL alapú kommunikációt vagy a Java és ActiveX szoftverek digitális aláírás ellenőrzését. A csoportmunkát támogató Lotus Notes szintén a nyilvános titkosítást alkalmazza. A PKI licencek tekintetében az RSA kapcsolatokkal rendelkező VeriSign-t és a Northern Telecom érdekeltségű Entrust-ot érdemes megemlíteni. A következő lépés az infrastruktúra fejlesztésében a szervezeten belüli kulcs menedzsment és név/címtár szolgáltatások használatának elősegítése. Ezeket pedig a Microsoft Windows 2000 natívan tartalmazza.
Az elektronikus aláírások használatának elterjedését biztosító jelentős fejlesztések és beruházások kudarcait elkerülni, illetve kezelni csak a kellő időben elvégzett architektúra tervezéssel lehet. Az architektúra tervezés figyelembe veszi a megrendelő/tulajdonos és a felhasználó/előfizető közötti lánc minden szereplőjének igényeit és meghatározza a rendszer összes elemét, valamint kapcsolatukat. A szabványokon és ajánlásokon alapuló architektúra mindenki számára érthetően közvetíti a feladatokat és jellemzőiket. 
Jelen írásban az együttműködésre képes hazai PKI architektúra megvalósításának feltételeit tekintjük át, az architektúra tervezés lényegi jellemzőinek fényében. Az informatikai architektúra tervezésről a szerző négy éven át a BKÁE Vezetőképző Intézetében tartott előadásai szolgálhatnak részletekkel.(1)
2.	A PKI jellemzői
A nagyvállalatok, központi költségvetési szervek biztonságos, elosztott alkalmazásai, mint a közgazdasági tervező, humánpolitikai-bérszámfejtési rendszerek (ellátási lánc irányítás), a biztonságos elektronikus üzenetkezelés és mind az ami az elektronikus kormányzat, illetve elektronikus kereskedelem (e-government, e-business) fogalomkörébe tartozik, de ezen túlmenően is a virtuális privát hálózatok és intranet alkalmazások alapeleme a nyilvános kulcsú infrastruktúra. A PKI az Internet (TCP/IP) technológiát alkalmazó valamennyi hálózat biztonságosságának feltételeit nyújtja, lehetővé téve a megbízható és hiteles, távoli szolgáltatásokat (kommunikációt és adatfeldolgozást) is. A szolgáltatásokhoz a titkosító kódolás és a digitális aláírás alkalmazásával biztosítható a szigorú felhasználói azonosítás (authentication), az adatok védelme (confidentiality and privacy) és teljessége (integrity), valamint a letagadhatatlanság (non-repudiation). A PKI lényegében meghatározott biztonsági szolgáltatások köre, amely lehetővé teszi a nyilvános vagy másképpen nevezve kétkulcsos, aszimmetrikus titkosítás és az X.509-es ITU-T ajánlás szerinti ISO/IEC 9594-8 szabványos tanúsítványok használatát az elosztott információs rendszerekben és biztosítja a kulcsok, tanúsítványok, és használati irányelveik (policy) menedzsmentjét.
A szervezet alkalmazottjai, illetve a szervezet információs rendszereit használó külső partnerek, polgárok elvárják, hogy a rendszerek és a bennük tárolt adatok, információk megbízható módon, az év 365 napján és biztonságosan rendelkezésükre álljanak. Ezt a jó PKI a digitális tanúsítványokkal, illetve más minősített elektronikus jogosítványokkal biztosítja, lehetővé téve az ellenőrzött belépést az információs rendszerekbe, a titkosított üzenetkezelést és adatátvitelt a szervezet számára lényeges alkalmazások esetén. A követelmények teljesítésére a cég/szervezet minősített on-line PKI szolgáltatást kell üzemeltessen, amely alkalmas a felhasználók azonosítására (authentication), a jogosultságaik szerinti tevékenységek engedélyezésére (authorization) és a digitális aláírások kulcsainak menedzselésére a legkülönbözőbb Internet/intranet alkalmazásokban. A szervezeti PKI célja az adatvagyon védelme a hitelesítés, a bizalmasság, a letagadhatatlanság, a teljesség és a rendelkezésre állás megteremtésével.
Bár a PKI alapszolgáltatása a nyilvános kulcsok biztosítása, azonban a nyilvános kulcsokat a kulcskibocsátó digitális tanúsítványba csomagolja. A digitális tanúsítvány védi a nyilvános kulcs sértetlenségét, és egyben hitelesítési lehetőséget biztosít, mivel a felhasználó nyilvános kulcsán kívül egy sor attribútumot tartalmazhat, mint a felhasználó megkülönböztetett nevét és más azonosítást segítő adatait, valamint jogosultságait, a kulcs érvényességét, stb. A nyilvános kulcs hitelességét a kulcskibocsátó, a tanúsító hatóság (a továbbiakban CA, Certificate Authority), saját privát kulcsával képzett digitális aláírása bizonyítja a tanúsítványon. 
A PKI-ban egyidejűleg minden felhasználónak legalább két kulcs párral kell rendelkeznie. Bármelyik pillanatban a felhasználónak kell egy kulcs pár a titkosításra és a megfejtésre, és egy másik kulcs pár a digitális aláírásra és az aláírás ellenőrzésére. A nyilvános kulcsú titkosítás szépsége éppen abban van, hogy széles körben hozzáférhetővé teszi a bizalmas, hiteles információkat és ehhez az emberek és rendszerek nyilvános kulcsaikat nyílt, nem hiteles környezetben tárolhatják, csupán a kulcs pár privát felét kell szigorúan őrizniük. A tanúsítvány hitelességéről a kibocsátó CA titkos kulcsával készített aláírásának a nyilvános kulcsával történő ellenőrzésével győződhet meg a használó. A kibocsátó aláírásával igazolja autentikusságát és korrektségét, melyet például az állami tanúsító hatóság esetén a polgárok bizalma, illetve privát tanúsító hatóságnál a tanúsítvány irányelvek tisztességes betartása és a tanúsító hierarchia hitelesít, amelyhez esetleg kapcsolódik. A közszolgálati CA-knak meghatározott bizalmi felelőssége van jogállásuk következtében, mindezeket bizonyos jogszabályok és jogosítványok tovább erősíthetik. A privát CA-k ugyanakkor rugalmasabban tudják alakítani üzletpolitikájukat és gyakorlatukat a felhasználói igények függvényében.
Műszaki szempontból a PKI nyújtja azt a technológiát, infrastruktúrát és eljárást, amely meghatározó mértékben lehetővé teszi az elosztott alkalmazásokban a digitális aláírások és/vagy a nyilvános kulcsú titkosítás használatát. A PKI fő funkciója az elektronikus iratok, vagy más elektronikus adatátvitel titkosítására, illetve szignálására, aláírására, vagy az információs forrásokhoz való hozzáférés engedélyezéséhez a felhasználók személyének előzetes azonosítása alapján a szükséges nyilvános kulcsok pontos és megbízható kiosztása.
Általános tévedés, amit sokan gondolnak, hogy a PKI valami tárgyiasítható dolog, pedig valójában a PKI egy lehetőség, amely a nyilvános kulcsok közzétételét, menedzselését és használatát könnyíti meg. A PKI szolgáltatás azonban jogi és pénzügyi felelősséggel jár, és igen jelentősek a bizalmi szempontok sikerességében. A szolgáltatónak biztosítania kell a teljes információtechnológiai hátteret beleértve az informatikai rendszereket, távközlést, adatbázisokat, de ezen túlmenően a telephely fizikai biztonságát, az "Internet-biztos" belső hálózatokat, a magas rendelkezésre állást biztosító redundáns rendszereket, a katasztrófatűrő képességet, a PKI szakterület szakértőit, életképes PKI joggyakorlatot, és financiálisan biztos PKI szavatosság védelmet. A költségek és a felelősség megosztására integrált, hierarchikus rendszereket használnak elterjedten. 
A PKI telepítésére a legalkalmasabb az operációs rendszer. Az operációs rendszerek már egy sor más infrastruktúrát is támogatnak, mint például a hálózati nyomtatást, a háttértárolókról letölthető fájlszolgáltatásokat. A PKI esetében az operációs rendszer a hálózat biztonságos, de transzparens és egyszerű használatát biztosítja.
A PKI tanúsító hatóság (CA) telepítésének első napjától a legmagasabb biztonsági követelmények szerint kell eljárni, amelyek szigorúbbak az általános titkosított adatátviteli és feldolgozó rendszerekre előírt követelményeknél. Ez akkor is igaz, ha az első telepítés idején nincsenek szenzitív, védendő állományok, azonban a későbbiekben bármikor szükséges lehet igénybevétele az igen értékes információk védelmére. 
Tekintve, hogy a CA szigorú biztonsági feltételeket támaszt, az épület és az üzemeltetés költségei sok vállalkozás számára elriasztóak. A CA funkció külső kézbe adása nem feltétlen megoldás, mivel a vállalatok legtöbbször teljes irányítási, ellenőrzési jogot akarnak gyakorolni a nyilvános kulcsú infrastruktúrájuk felett, hogy meghatározhassák, ki kaphat tanúsítványt, mi legyen a tanúsítvány tartalma, hogyan és miképp vonható vissza a tanúsítvány és a CA mindennapi üzemeltetését is kézben tarthassák. Erre nyújt megoldást a távoli, biztonságos háttér számítóközpont, amely a napi mentésekkel és visszaellenőrzésekkel, lényegében a CA adatbázisainak megkettőzésével viszonylag olcsó és minden vállalat számára testre szabható megoldást biztosít. 
A PKI terméket, szolgáltatást alkalmazó szervezet biztonsági tartományokat alakíthat ki, melyekben egy tanúsító hatóság a tanúsítvány és kulcs kibocsátást ellátja. Minősített kapcsolati viszonyt hozhat létre a szervezet, különböző biztonsági tartományokkal egy CA hierarchián belül, vagy akár kereszttanúsítással más CA-kkal. Alapkövetelmény a szabvány alapú átjárhatóság, azaz a nyílt együttműködés a hálózatok között. 
3.	PKI szolgáltatási környezet
A PKI szolgáltatási környezete három féle lehet. A leglényegesebb feladatok, melyek ellátása minden környezetben szükséges a tanúsítványgenerálás, a tanúsítványterjesztés és a tanúsítványmenedzsment.
1.	Szervezeti környezet
 A szervezet által meghatározott környezetben a végfelhasználói alkalmazásokig bezárólag konzisztens és átlátható biztonságot kell teremteni. Ebben a környezetben a szervezet a legnagyobb mértékű ellenőrzési jogokkal és lehetőségekkel rendelkezik, amely biztosítja, hogy mind az infrastrukturális, mind a végfelhasználói alkalmazások beruházásainál érvényre juttassák az együttműködő PKI megoldások elterjesztését. 
2.	Szervezetek közötti környezet
A szervezetek közötti környezetet azok a szervezetek közötti kapcsolatok jellemzik, amelyekkel ezek biztosítják a szervezetek közötti un.. B2B vagy B2G elektronikus kereskedelemhez szükséges hiteles és biztonságos infrastruktúrát. Minden szervezet a saját erőforrásai felett rendelkezik, mind az infrastruktúra, mind a végfelhasználói alkalmazások együtt kell működjenek más PKI-kkal.
3.	A fogyasztói környezet
A fogyasztói környezetet azok a szervezetek alakítják, amelyek fogyasztóikkal Internetes elektronikus kereskedelmet - B2C - kívánnak kialakítani, de ide kell sorolnunk az elektronikus kormányzat, vagy az e-demokrácia különböző, az állampolgár és a közigazgatási szervek között kialakítandó, kapcsolatokat is. Az infrastruktúra fejlesztése során a szervezetnek együtt kell működnie fogyasztóival az alkalmazások széles körét - jellemzően WEB böngészőket és elektronikus levelezést - támogatva.
4.	A PKI szolgáltatással szemben támasztott lényegi követelmények
Címszavakban a következő követelmények teljesítése szükséges: 
•	Megbízható PKI technológia: ebbe bele tartozik a tanúsítvány kibocsátás és életciklus menedzsment, a különféle tanúsítvány típusok előállítása és működtetése, a megfelelő nyilvántartási tevékenységek, a rekordok tárolása, a címtárak integrálása és a kulcsok menedzselése a legkritikusabb üzemeltetési és terhelési viszonyok között is.
•	Nyílt architektúra, amely a nemzetközi piac legjobb alkalmazásaira épül: biztosítani kell valamennyi régi és bármilyen új alkalmazással az együttműködést, elkerülve a végfelhasználói rendszereken az alkalmazás specifikus szoftverek telepítését, és lehetőséget kell adni a szükséges együttműködésre a szervezeten kívüli rendszerekkel. 
•	Magas fokú rendelkezésre állás és méretezhetőség: a PKI-nak 7x24 órán át rendelkezésre kell állnia, minden felhasználó számára, beleértve a rendszereket, hálózatokat, a felhasználók segítését, a folyamatos, katasztrófatűrő működést, jelentős többlet beruházások nélkül. 
•	Biztonságos üzemeltetési infrastruktúra: a PKI üzemeltetése különleges feladatokat ró a kockázatkezelésre. Biztosítani kell, hogy a szervezet jó hírnevét sem erkölcsi, jogi, sem anyagi vonatkozásban ne veszélyeztesse az Internet kapcsolat és a szervezet szenzitív információi a legmegbízhatóbb, hacker-álló PKI védelmet megkapják.
•	Alkalmasság a külső kapcsolatok kezelésére: a PKI különböző szervezeteket, közösségeket szolgálhat ki egy zárt hálózaton belül, több privát hálózat között és azokon kívül az Internetről is. 
5.	PKI szolgáltatások
A PKI célja a hitelt érdemlően működő, biztonságos hálózati környezet kialakítása és működtetése. Ezt a célt a kulcs- és tanúsítványszolgáltatásokkal éri el, amelyek biztosítják a legkülönbözőbb elektronikus alkalmazásokban a titkosítás és a digitális aláírások használatát. Alapvető követelmény a PKI-ban az átláthatóság minden felhasználó számára. Az átláthatóság azt jelenti ebben az esetben, hogy a titkosítás, vagy a digitális aláírás sikeres alkalmazásához a felhasználónak nem kell ismernie, hogy a PKI miként kezeli a tanúsítványokat és kulcsokat, de tökéletesen és követhetően megbízhat a rendszerben. 
A leglényegesebb PKI szolgáltatások:
•	Kulcsok menedzselése: alapesetként egy új kulcs kibocsátása, a meglévő kulcsok frissítése vagy visszavonása, és a különböző kulcs kibocsátóktól származó kulcsokhoz kapcsolt biztonsági szintek menedzselése.
•	Kulcsok nyilvánossága: a PKI ügyfelei számára a nyilvános kulcsok megtalálására és letöltésére, valamint, az adott kulcs érvényességére jól meghatározott eljárást ajánl. Amennyiben bármely felhasználó nem képes hozzáférni a kulcsokhoz, és tisztázni, hogy érvényesek-e, nem tudja használni a nyilvános kulcsú szolgáltatásokat.
•	Kulcsok használata: a PKI a kulcsok használatának egyszerű módját nyújtja, nem csupán azzal, hogy a felhasználónak rendelkezésére bocsátja a szükséges kulcsot, hanem könnyen kezelhető alkalmazásokat is biztosít, amelyekkel végrehajthatók a nyilvános kulcsú titkosítási műveletek, biztosítva az elektronikus levelezés, az elektronikus kereskedelem és a hálózatok titkosságát, megbízhatóságát. 
•	Kiegészítő szolgáltatások: a menedzselt PKI további - az alapvető szolgáltatásokkal együttműködni képes - szolgáltatásokat is biztosíthat. Ezek általában az elektronikus kereskedelem sokféle alkalmazását támogatják. Ilyenek például az időbélyegző, a privilégiumok menedzselése, vagy az automatikus regisztrációs hatóságok.
Mára a PKI minden hálózatbiztonsági megoldás alapja, bele értve az információ források WEB böngészős hozzáférésének ellenőrzését, a titkosított elektronikus üzeneteket, a digitális aláírások és munkafolyamatok különböző formáit, a tűzfalakat, a virtuális privát hálózatok útvonal-irányítóit, könyvtár struktúrákat és a szervezeti alkalmazások egyszerű szignálását.
6.	PKI modellek
A tanúsítványok és kulcs menedzsment szempontjából a hierarchikus (VeriSign, Netscape, Microsoft), a hálózati (Entrust) és a WEB központú (PGP) modell koncepciók terjedtek el. Napjainkra úgy tűnik, hogy a hierarchikus megoldás alkalmazása kerül előtérbe hatékonysága és más piaci tényezők folytán. A hierarchikus megoldáson belül az alábbi két modell lehetséges:
•	A független megoldás, a piacon kínált szoftverrel önálló PKI szolgáltatás kialakítása. Ekkor az üzemeltető szervezet százszázalékos felelősséget vállal mindamellett, hogy a PKI kialakítás teljes költségét is maga fedezi. A kiválasztott szállító támogatási készségén és szoftverén múlik, hogy az üzemeltetés mindennapjaiban, a különféle biztonsági veszélyhelyzetek, éjszakai üzemzavarok, felhasználói csúcsterhelések, hacker támadások problémáit, vagy a mindezek elhárítására alkalmazott tűzoltó intézkedéseket, módosításokat hogyan tűri a rendszer.
•	A másik modell az integrált PKI, amely megtartja az adott szervezet által használt PKI szoftver és hardver állomány saját felelősségű ellenőrzött működtetését, azonban a saját PKI rendszer kompatíbilis kapcsolatban áll más bevált alkalmazásokból, tanúsítvány kibocsátó szolgáltatásokból és infrastruktúrákból kialakított, magas fokú rendelkezésre állással és nagy biztonsággal jellemezhető PKI gerinchálózattal, amely lehetővé teszi a függetlenül kontrollált rendszerek mellett a felelősség megosztását.
A fenti modellek azonban a szervezet/vállalat feladatainak, struktúrájának, sőt outsourcing politikájának függvényében tovább alakulhatnak:
•	Az önálló, vállalati tanúsító hatóság esetében akár a szervezeten kívüli cég is elláthatja a CA feladatait.
•	A nagyvállalati tanúsító hatóság saját cégén belül elsődleges hatóság, azonban akár ennek alárendelt regisztrációs és elosztó központok, vagy alárendelt tanúsító hatóságok is lehetnek a vállalaton belül a funkcionális és földrajzi megosztottság szerint.
•	A heterogén modell a szervezetek közötti biztonságos kommunikáció érdekében külső kapcsolatokat, kölcsönös tanúsítást is lehetővé tesz a felelősségi viszony megállapodások függvényében.
7.	PKI architektúra elemei
A nyilvános kulcsú infrastruktúra architektúrális elemei a digitális tanúsítványok létrehozását, ellenőrzését, továbbítását és használatát biztosítják.  
7.1.	Tanúsítvány alanya és használója. 	A legalapvetőbb PKI architektúra elem a tanúsítvány alanya, amely jobbára (minősített esetben kizárólag) egy személy, bár bármely jogi személyiségnek - beleértve egy céget, rendszert és alkalmazást - lehet tanúsított nyilvános kulcsa. (pl. a szervernek). A személy vagy szoftver lehet tehát a tanúsítvány alanya, ugyanakkor más egyedekkel együtt a felhasználója is a tanúsítványoknak, amikor ellenőrzi a nyilvános kulcs használatával egy digitális aláírás valódiságát. A jól felépített PKI architektúra a következő funkcionális elemeket tartalmazza:
7.2.	Tanúsító hatóságok (CA). 	A nyilvános kulcsú titkosítás abban az esetben használható, ha a felhasználókat - akik más felekkel valamilyen kapcsolatot építenek ki - biztosítani tudjuk, hogy kapcsolatuk biztonságos, azaz a felek azonossága és kulcsai érvényesek és hitelt érdemlőek. Ez a bizonyosság megköveteli, hogy a PKI minden felhasználója regisztrált azonosítóval rendelkezzen. Ezek az azonosítók a digitális formában tárolt nyilvános kulcsú tanúsítványok. A tanúsító hatóság az előfizetője számára tanúsítványokat bocsát ki, amelyekben egy sor adatot saját privát kulcsú digitális aláírásával tanúsít. Ezek között hiteles információt nyújt a következőkről:
•	Az előfizető un. megkülönböztetett neve (DN: Distinguished Name), amely tartalmazza a nevet és valami kiegészítő attribútumot, amely segítségével az előfizető egyértelműen azonosítható. 
•	Az előfizető nyilvános kulcsa. Ennek segítségével kódolhatják mások az előfizetőnek szánt üzeneteket, illetve ellenőrizhetik digitális aláírását és üzeneteinek teljességét.
•	A tanúsítvány érvényességének tartama. (pl. a kibocsátás és a lejárat napja).
•	Azoknak a felhasználási céloknak a tanúsítása, amikre a nyilvános kulcs használható. (pl. titkosító kódolásra, illetve digitális aláírás ellenőrzésére vagy mindkettőre)
Bár a tanúsító egy személy is lehet, elnevezéséből következően egy feljebb álló hatósági feladatot ellátó intézményről van szó. A tanúsítvány előállításakor a CA játssza a biztonsági hatóság szerepét a PKI-ban, majd betölti a hiteles harmadik fél (Trusted Third Party) funkcióját. A struktúrát a harmadik fél általi hitelesítésként ismerik. A felhasználó azonosításához szükséges nevét és más adatait a két kulccsal a tanúsító hatóságot megtestesítő emberek, folyamatok és eszközök kapcsolják egybe és tanúsítják a hatóság privát kulcsával aláírt tanúsítványukkal. A CA digitális aláírása a tanúsítványon biztosítja, hogy a tartalom bármilyen hamisítása könnyen észrevehető. Egészen addig, míg a CA aláírása a tanúsítványon azonosítható, a tanúsítvány teljessége nem sérült. Az alaphelyzetben a tanúsító hatóság a felhasználók meghatározott köre számára bocsát ki nyilvános kulcsot hordozó tanúsítványt. A felhasználók közössége alkotja az un.. biztonsági tartományt (security domain). Minden CA maga dönti el (bizonyos szabványok, illetve jogszabályok és ajánlások betartása mellett), milyen attribútumokat vesz fel a tanúsítványba, illetve, hogy ezek valódiságát miként ellenőrzi. A CA kezeli a kibocsátott tanúsítványok visszavonási listáját (CRL, Certificate Revocation List) is, amely az adott nyilvános kulcs érvénytelenségét hirdeti, valamely jól hozzáférhető módon, kibocsátó pontok alkalmazásával. 
7.3.	Regisztrációs hatóságok (RA).  Az RA önállósága lehetséges változat, jobbára a CA egy alárendelt szerveréről van szó, amelyre a CA a felhasználók regisztrációjával kapcsolatos menedzselési funkciót delegálja. Elosztott WAN környezetben azonban hasznos lehet az egy CA tanúsításos felügyelete melletti LAN-onkénti RA telepítése, bár ez a biztonsági láncot megnyújtja.
7.4.	PKI adattárak (repository).  Alapesetben legalább két fontos adattárat alkalmaz a PKI architektúra. Először is a tanúsító hatóság a kibocsátott, érvényes kulcsok biztonsági másolatainak tárolására és a lejárt, visszavont kulcsok archiválására a CA-val azonosan magas védettségi fokon, hálózatról el nem érhető, külön elzárt helyiségben, épületben adatbázist tart fenn. Másrészt a tanúsítványokat és a visszavonási listákat egy nyilvánosan könnyen elérhető adatbázisban kell tárolni, és elosztásukat biztosítani. Erre gyakorta relációs adatbázisokat használtak bár a PKI adattárakra a leglogikusabb megoldás a Lightweight Directory Access Protocol (LDAP) alapú név/címtár szolgáltatás implementálása. 	
Logikailag ötféle adattárat különböztetnek meg a PKI-ban, melyek azonban változatos fizikai megvalósítást jelenthetnek:
	MY a használó saját, vagy gépének tanúsítványát és hozzá tartozó privát kulcsot tárolja.
	CA a tanúsítási láncban a kibocsátó vagy közbenső hatóságok által kiadott tanúsítványokat tárolja.
	TRUST a minősített CA-k nyilvántartását biztosító CTL -eket (Certificate Trust List) őrzi. A listák digitális aláírással vannak ellátva, így nyílt hálózatokon is továbbíthatóak.
	ROOT a minősített, gyökér CA által aláírt tanúsítványokat tárolja.
	UserDS a tanúsítvány adattárak logikai szerkezetét tárolja a külső adattárak elérésnek egyszerűsítése céljából.
Név/címtár (directory) integráció A név/címtárak igen lényegesek a PKI működése szempontjából. Tekintve, hogy a tanúsítvány teljessége ellenőrizhető a CA digitális aláírásának a nyilvános kulccsal történő összevetésével a tanúsítvány önmagában biztonságos és teljesen nyilvános formában közreadható (pl. nyilvánosan elérhető címtár rendszereken). Az a felhasználó, amelyik a címtárból egy tanúsítvánnyal letölt egy nyilvános kulcsot, biztos lehet abban, hogy a nyilvános kulcs érvényes. Azaz a felhasználók bizonyosak lehetnek abban, hogy a tanúsítvány és a hozzá kapcsolt nyilvános kulcs ahhoz az egyedhez tartozik, amelyet a DN, megkülönböztetett név azonosít. Továbbá a felhasználó biztos lehet abban, hogy a nyilvános kulcs érvényességi idején belül van, és a nyilvános kulcs biztonságosan használható a CA által tanúsított módon. A tanúsítványokat a megbízható harmadik felet képviselő tanúsító hatóság, vagy akár a felhasználók cége is hozzáférhetővé kell tegye, hogy azokat a különböző alkalmazások lehívhassák és használhassák. A tárolást és szétosztást biztosító adattárak hálózati szolgáltatást is végeznek, tehát nem egyszerű adatbázisok. Alapkövetelmény ma már az LDAP támogatása. 
A legtöbb szállító PKI terméke LDAP alapú kapcsolatokat használ nemcsak a tanúsítványok, de a CA-k és más PKI elemek szempontjából lényeges címtár adatok előállítására, menedzselésére és olvasására. Hasonló módon alapkövetelmény a név/címtárak replikációja is. Fontos lehetőség, melyet a PKI támogat, a multimaster replikáció. Tekintve, hogy a PKI termékek a név/címtárat használják a kulcsok tárolására, elosztására, keresésére, letöltésére, ezért a PKI termékek telepítése különleges követelményeket támaszt a név/címtárakkal szemben. A CA-k a név/címtárba többféle adatot jegyeznek be (pl. hol tartja karban az általa irányított biztonsági tartományt, kik a kereszttanúsítók, hol vannak a saját, illetve más tartományok visszavonási listái, de bejegyzi a felhasználók tanúsítványát is, mint a felhasználó objektumának attribútumát, stb.), és mindezeket a napi gyakorlat szerint módosítani is szükséges. A PKI termékek jellemzően támogatják az ITU-T X.500 (X.520, X.521 és X.509) alapvető név/címtár (ISO/IEC 9594 szabvány család) objektum osztályokat és attribútumokat. Az elmúlt évek során ipari szabvánnyá vált az LDAP az Internet alapú PKI címtárak kezelésére. 
A fentieken túlmenően a címtárak más adatok, pl. a visszavonási listák tárolásra, terjesztésére is alkalmasak.
Visszavonási listák (CRL). Az alkalmazási szoftver a tanúsítvány kibocsátó aláírásának ellenőrzésén túl célszerűen megvizsgálja, hogy a felhasználás pillanatában érvényes-e egyáltalában a tanúsítvány. A hitelességüket elvesztett tanúsítványokat  a CA köteles visszavonni. Erre a lejárati idő előtt is számtalan ok szolgálhat. Például a tanúsítványnak megfelelő nyílt kulcshoz tartozó valamelyik privát kulcsot - akár az aláíró, akár a megfejtő privát kulcsot.- kompromittálják. Más esetben a szervezeti biztonsági szabályzat előírhatja, hogy a cégtől kilépők tanúsítványait vissza kell vonni. Ilyenkor a rendszer használóinak tudomására kell hozni, hogy a kérdéses tanúsítványok nem tekinthetők biztonságosnak. Tekintve, hogy a visszahívás állapotát a tanúsítvány alkalmazása előtt kell ellenőrizni, a PKI-nak jól méretezhető visszavonási rendszert kell tartalmaznia. A CA-nak visszavonási rendszerében nagy biztonsággal működtetnie kell az általa kibocsátott minden tanúsítványra a visszahívási információk terjesztését. Ennek a módja a biztonságos tanúsítvány visszavonási lista (CRL, Certificate Revocation List) fenntartása és terjesztése a címtár segítségével. Másik módszer az Online Certificate Status Protocol (OCSP) alkalmazása, főként nagy értékű tranzakciók esetére, amelyben a szerver az ügyfelek kéréseire adja meg a választ. Bármely megoldást választják, a lényeg, hogy az ügyfél oldali szoftvernek a felhasználó nevében automatikusan le kell tudni ellenőrizni a tanúsítványokat, nincsenek-e a visszahívási listán.
7.5.	Tanúsítvány kibocsátó pontok. A CA alapesetben a második típusú adattárból (név/címtárból) biztosítja a tanúsítványok és a visszavonási listák szervezeten belüli és kívüli elérhetőségét. A jó tanúsító hatóság a kibocsátó pontok replikációjával megteremti a felhasználók számára a hierarchiába tartozó valamennyi tanúsítvány automatikus letölthetőségét. A kibocsátó pont bármilyen fajta név/címtár szolgáltatást használhat a gyártófüggő operációs rendszerhez kapcsolttól az  X.500, illetve LDAP szabványos megoldásig, de a tanúsítványokat és a visszavonási listákat közzé teheti WEB lapokon, intelligens kártyákon, hajlékony vagy CD-ROM lemezeken is. 
7.6.	Kulcs és tanúsítványmenedzselési eszközök. A menedzselési eszközök biztosítják a kiadott tanúsítványok különböző adatainak kötelező nyilvántartását. A lejárt vagy visszavont kulcsokat tartalmazó tanúsítványokat hosszú időre archiválni kell, hogy a titkos levelek, vagy a digitálisan aláírt dokumentumok használatát hosszú távon biztosítani lehessen. A tanúsítványok és hozzájuk tartozó kulcsok archiválását, visszaállítását, megújítását a biztonsági másolatok és a visszaállíthatóság segítik. Biztosítani kell a tanúsító és kibocsátó tevékenységének felügyeletére a lehetőséget, amihez elengedhetetlen a menedzsment, az adminisztráció és az audit eszközeinek használata. Fontos a kulcs és tanúsítvány menedzsment központosítása a lehető legteljesebb mértékben. A központosítás és a lehető legkevesebb CA bevezetésére törekvés jelentősen csökkentheti a biztonsági kockázatot. A nagyszámú tanúsítványt kibocsátó CA hierarchia kiépítésére vállalkozó szervezeteknek a PKI technológia gyors változásával járó kockázati problémákra is fel kell készülniük. A felhasználóknak meg kell szokniuk a név/címtár (directory) szolgáltatások, mint a PKI alapelemének használatát. Ezen szolgáltatások nélkül sokkal nehezebb bevezetni és hatékonyan menedzselni a PKI-t. A PKI szervezeten belüli használatához elengedhetetlen a kulcsmenedzsment tökéletes működése. Fontos hangsúlyozni a különbséget a kulcs menedzsment és a tanúsítvány menedzsment között. A kulcs menedzsment a hosszú távú méretezés szempontjából fontos.
A kulcs és tanúsítvány menedzselés területei:
•	Kulcsok visszaállíthatóságának biztosítása.
•	A letagadhatatlanság biztosítása.
•	A kulcsok és tanúsítványok frissítése.
•	Kereszttanúsítás.
Nehéz egyidejűleg eleget tenni a kulcs visszaállíthatóság és a letagadhatatlanság követelményeinek. Ismeretes, hogy a kulcs pároknak különböző funkciói lehetnek. Az egyik párt az adatok titkosítására és megfejtésére használják, ezt "titkosító kulcs párnak" hívják. A másik kulcs pár az adatok digitális aláírására és az aláírások ellenőrzésére használható, ez az "aláíró kulcs pár". A visszaállíthatóság érdekében a megfejtő kulcsok biztonságos tárolását kell megoldani. A letagadhatatlanság biztosításához azonban az aláíró kulcsról nem készíthető másolat és a kulcs minden pillanatban a felhasználó kizárólagos ellenőrzése alatt kell, legyen. 
Kulcsok visszaállítása. A tanúsítvány érvényességének lejártakor a megújításhoz a CA felhasználhatja a kérelmező meglévő, már ellenőrzött adatait, esetleg új nyilvános kulcsot is generál. A PKI archív adattár másik lehetősége a kulcs pár visszaállíthatóságának biztosítása, amely csak szigorúan ellenőrzötten, a tulajdonos tudtával és beleegyezésével történhet, pl. elvesztés, megsemmisülés esetén. Ettől eltérően előfordulhat kulcs visszaállítás, ha a kulcsot cég/intézmény felhatalmazásából hivatalos dokumentumokra, stb. használták, illetve bírósági, ügyészi intézkedésre nemzetbiztonsági vagy más súlyos büntetőeljárás során. A kulcs visszaállítással nemcsak a privát kulcs használója személyesíthető meg, de a titkosított elektronikus levelei is elolvashatók.
A két kulcsos titkosítást, digitális aláírást alkalmazó személyek, szerveztek jogos igénye, hogy a titkosított adatokat akkor is megfejthessék, ha elveszítik a privát kulcsukat. Ez azt jelenti, hogy az adott vállalat, amelyhez a felhasználó tartozik megköveteli a megfejtő kulcsok biztonsági másolatainak tárolását és helyreállíthatóságukat. Ennek két oka is van.
Elsőként említhető az az eset, mikor a felhasználó elfelejti jelszavát. A szervezete számára katasztrofális lehet, ha valamelyik alkalmazottja elfelejtve a hozzáférési jelszavát, örökre elveszít valamely titkosított információt. Megfordítva az is előfordulhat, hogy a felhasználó értékes, szenzitív információkat nem titkosít attól való félelmében, hogy azok elveszhetnek, ha elfelejti a megfejtéshez szükséges jelszavat.
Másrészt a felhasználó elveszítheti, elronthatja, tönkre teheti a megfejtő kulcsokat tartalmazó és tároló eszközöket. Például, ha a megfejtő kulcs mágneses tárolón vagy kártyán van, a mágneses tér sérülhet. A titkosított információk ilyen elvesztése ismét csak végzetes lehet. A felhasználókat óvni kell adataik titkosításától, anélkül, hogy a megfejtő kulcsokról biztonsági másolatot készítettek volna.
Vegyük észre, hogy az eddigiekben nem volt szó az aláíró kulcs pár biztonsági másolatáról és visszaállíthatóságáról. Kizárólag a felhasználó megfejtő kulcsairól szükséges másolatot készíteni. Addig, míg egy hiteles szolgáltató - CA - biztonságosan kezeli a felhasználók megfejtő kulcsait, a biztonság nem sérül, de a felhasználó adatai bármikor visszafejthetőek. Ugyanakkor az aláíró kulcsoknak a titkosító kulcsokétól eltérő követelményei vannak. Az aláíró kulcsok másolása tönkre teszi a PKI alapvető működését.
Letagadhatatlanság. A letagadhatatlanság követelménye azt jelenti, hogy a felek nem tudják eredményesen megtagadni, illetve letagadni a részvételüket a tranzakcióban. A papír alapú tranzakciókban a kézaláírás biztosítja a letagadhatatlanságot. A digitális világban a digitális aláírás veszi át a toll alapú aláírás szerepét. Amennyiben az egyik fél visszautasítja a tranzakciót, a letagadás esete merülhet fel (például valaki azt mondja, hogy ellopták bankkártyáját, ez azt jelenti, hogy ő elhárítja a felelősséget minden tranzakció kapcsán, ami a letiltás után létesül.) 
A digitális aláírás az elektronikus kereskedelem (e-government, e-business) minden formájában szükséges. A letagadhatatlanság legalapvetőbb követelménye, hogy a digitális aláíráshoz használt kulcs - az aláíró kulcs generálása és tárolása biztonságos módon történjen a felhasználó kizárólagos ellenőrzése mellett. 
Nem engedhető meg az aláíró kulcs másolása. Ellentétben a titkosító kulcs párral nincs semmiféle műszaki vagy szervezeti indok az aláíró kulcsok biztonsági másolására vagy tárolására, ha a felhasználó elfelejti jelszavát, vagy elveszíti, tönkre teszi aláíró kulcsait. Ilyen esetekben elfogadható, hogy a felhasználó számára új aláíró kulcsokat generáljanak, és attól kezdve azokat használja. 
Frissítés. Egy idő múlva a felhasználóknak számos kulcs párja lehet, melyeket megfelelő módon menedzselni kell. A kulcsok ugyanis nem örök életűek, azokat időről időre frissíteni kell. Ennek kapcsán biztosítani kell a kulcsok frissítését, és az indokolt esetekben kezelni kell a kulcs párok történeti adatait.
A kulcs párok frissítésének a felhasználó számára átláthatónak kell lennie, azaz nem kell ismernie a folyamatot, azonban biztosítani kell az automatikus frissítést a lejárati idő előtt, hogy a kulcs lejárta miatt ne legyen megtagadható az igényelt szolgáltatás. A titkosító kulcs pár frissítésekor a korábbi kulcs pár történetét meg kell őrizni. Ez a kulcs történet biztosítja, hogy a felhasználó bármelyik régi kulcsával titkosított adatát vissza tudja fejteni, ugyanis csak a titkosító kulcs saját megfejtő párjával lehet visszaállítani bármely titkosított információt. A kulcs történetet ugyanolyan biztonságosan kell üzemeltetni, mint a kulcsok biztonsági másolatainak tárolását, vagy a visszaállító rendszert.
Az aláíró kulcs pár frissítésekor a lejárt aláíró kulcsot biztonságos módon meg kell semmisíteni. A megsemmisítéssel megakadályozható, hogy bárki más hozzáférhessen az aláíró kulcshoz. Ez az eljárás indokolt, hiszen nincs szükség a régi aláíró kulcs visszaállításra, csupán a nyilvános kulcs megőrzésére az ellenőrzés céljából.
Kereszttanúsítás. A harmadik tanúsító fél felelősségi viszonyait a különböző tanúsítási tartományok között ki lehet terjeszteni a kereszttanúsítással, vagy PKI hálózattal. Például két, különböző tanúsítóhoz tartozó kereskedelmi partner azt kívánja, hogy a másik CA által kibocsátott tanúsítványt kölcsönösen ellenőrizni lehessen a kétoldalú kapcsolatban. Más esetben egy földrajzilag szétszórt egységekkel rendelkező nagyvállalat a megfelelő helyi CA-kat úgy tudja igénybe venni, ha a regionális CA-k hierarchikusan alá vannak rendelve a kereszttanúsítással a gyökér CA-nak a megbízható elektronikus kapcsolatok segítségével. 
A kereszttanúsítás két műveletet takar. Az első, nem sűrűn ismételt tevékenység a két CA közötti tanúsítási viszony létrehozása. A kölcsönös, kétoldalú kereszttanúsítás esetén a két CA biztonságosan kicseréli ellenőrző kulcsait. Ezek azok a kulcsok, amelyeket a tanúsítványon lévő elektronikus aláírás valódiságának ellenőrzésére használnak. A művelethez tartozik még egy kereszttanúsítvány kibocsátása, amelyet mindegyik CA a másik ellenőrző kulcsával ír alá. Amennyiben hierarchikus kereszttanúsításról van szó, a magasabban álló CA tanúsítja az alacsonyabban állót, az alacsonyabban álló ellenőrző kulcsával.
A másik műveletet az ügyfél oldali szoftver hajtja végre. Ezt a műveletet gyakorta végzik, amikor egy felhasználó, kereszt tanúsított CA által kibocsátott tanúsítványát ellenőrzik. Az eljárást elterjedten "a bizalmi lánc végigjárásának" nevezik. A lánc a kereszttanúsítvány ellenőrzések listájára vonatkozik, amelyet az ellenőrző felhasználó saját kibocsátó CA-ja kulcsának végig kell járni, hogy a másik felhasználó tanúsítványa kibocsátó CA-jának kulcsát leellenőrizze. A bizalmi láncon végigjárva mindenegyes kereszttanúsítványt ellenőrizni kell, hogy még érvényben van-e. Akár a felhasználói, akár a kereszttanúsítványok bármikor visszavonhatók, erről sokszor megfeledkeznek.
7.7.	Alkalmazások a kulcs használatának biztosítására. A felhasználók részére könnyen kezelhető, szabványos megoldásokkal lehetővé kell tenni a digitális tanúsítványokkal a titkosítást, elektronikus aláírást, illetve más CA-k által kibocsátott tanúsítvány hitelesítésének ellenőrzését.  A PKI követelmények tárgyalása során gyakran lebecsülik a felhasználói oldal szoftverkövetelményeit, kizárólag a CA elemmel foglakoznak. Végeredményben azonban a PKI értéke akkor jelentkezik csak, ha a felhasználók használhatják is a titkosításra és az elektronikus aláírásra. Egyértelmű, tehát, hogy a PKI-nak tartalmaznia kell egy olyan szoftvert, amely a felhasználó asztali, személyi számítógépes környezetében konzisztensen és átláthatóan használható (akár elektronikus levelezéshez, böngészéshez, fájlok, könyvtárak titkosításához), ezzel csökkentve a PKI működési költségeit. Természetesen a felhasználói, ügyfél oldali szoftvernek a PKI minden elemével együtt kell tudni működni. Az alábbiakban összefoglaljuk az ügyfél oldali szoftverrel szemben támasztott követelményeket:
Nyilvános kulcsú tanúsítványok. A hiteles harmadik fél alkalmazásához minden PKI-t használó alkalmazásban a tanúsítványokat konzisztens, hitelt érdemlő módon kell használni. Az ügyfél oldali szoftvernek kell ellenőriznie a tanúsító hatóság, a CA tanúsítványon lévő elektronikus aláírásának hitelességét, és meggyőződni arról, hogy az érvényességi tartamán belül van.
Biztonsági kulcs másolat és visszaállítás. A PKI-nak támogatnia kell a megfejtő kulcsok másolatainak tárolását és visszaállíthatóságukat, hogy biztosítsa felhasználóit az adatvesztéstől. Az adminisztratív költségekre tekintettel elfogadhatatlan, hogy minden alkalmazás saját tárolási és visszaállító rendszert használjon, inkább meg kell követelni, hogy az alkalmazás együtt tudjon működni egy közös rendszerrel. Az ügyfél oldali szoftver és a közös biztonsági másolattároló és visszaállító rendszer közötti kapcsolatnak biztonságosnak kell lennie, valamint az együttműködés módja legyen konzisztens minden PKI alkalmazásra.
A letagadhatatlanság megvalósításának támogatása. A letagadhatatlanság alapvető biztosítására az ügyfél oldali szoftvernek kell generálnia az elektronikus aláíráshoz szükséges kulcs párt. Ezen túlmenően az ügyfél oldali szoftvernek kell biztosítania, hogy az aláíró kulcsokat semmilyen körülmények között se lehessen másolni, és mindig a felhasználó ellenőrzése alatt maradjanak. Ennek a funkciónak is konzisztensnek kell lennie minden PKI alkalmazásban.
A kulcs párok automatikus frissítése. Az átláthatóság biztosítására az ügyfél oldali szoftvernek kell kezdeményeznie a felhasználó kulcsainak automatikus frissítését. Ezt a műveletet az adott szervezet biztonsági irányelveivel (policy) összhangban kell végrehajtani. A felhasználó számára nem elfogadható, ha neki kell nyilvántartania, mikor kell frissíteni kulcsait. Ennek elkerülésére az ügyfél oldali szoftvernek kell minden PKI alkalmazásra vonatkozóan átláthatóan és konzisztensen frissítenie a kulcsokat.
A kulcstörténetek menedzselése. A felhasználó számára a titkosított adatokhoz való, az időbeliségtől független, könnyű hozzáférés biztosítására a PKI alkalmazásoknak kezelni kell a felhasználó kulcsainak történeti adatait. Az ügyfél oldali szoftvernek képesnek kell lennie a felhasználó történeti kulcs adatainak reprodukálására a közös adattárból.
Méretezhető tanúsítvány adattár. A tanúsítványok terjesztési költségeinek minimalizálása céljából minden PKI alkalmazásnak közös, méretezhető tanúsítvány adattárat kell használnia. A közös adattárból történő tanúsítvány reprodukálás átlátszó megvalósítása javítja a PKI használhatóságát. Drága és bonyolult, ha az alkalmazások különböző tanúsítvány adattárakat igényelnek. 
Tanúsítvány visszavonás. A PKI alkalmazásoknak együtt kell működniük egy közös és méretezhető tanúsítvány visszavonási rendszerrel. Tekintve, hogy a hitelességmenedzsment miatt a tanúsítvány visszavonás központosított, az ügyfél oldali szoftvernek minden alkalmazásban konzisztensen és átláthatóan együtt kell működnie a tanúsítvány visszavonási rendszerrel.
A kereszttanúsítás támogatása. A hitelességmenedzsment irányelvek (policy) támogatására minden PKI alkalmazásnak közös kereszttanúsítási modell alapján kell működnie, hogy a kereszthivatkozásra meghatározottak teljesüljenek. Ismeretes, hogy a kereszthivatkozás lehetőséget nyújt a PKI-ban, hogy egy idegen tanúsító hatóság által kibocsátott tanúsítványt hitelesként fogadjunk el. Így az ügyféloldali szoftvernek kell leellenőriznie, hogy biztosan nincs egyetlen kereszttanúsítvány sem a "hitelességi láncban", amelyet visszavontak. 
A fenti követelmények az ügyfél oldali szoftver és a PKI elemek közötti együttműködésre vonatkoznak. További követelmények lehetnek, amelyek függetlenek az infrastruktúra architektúrális elemeitől. Például az ügyfél oldali szoftvernek kell biztosítania, hogy a felhasználó titkosíthassa, vagy visszafejthesse információit még akkor is, ha nem áll on-line kapcsolatban a PKI elemeivel. A maximális használhatóság (adott költségek melletti) biztosítására az ügyfél oldali szoftver többféle kulcstároló hardvereszköz típust kell támogasson (például intelligens kártyát, PC kártyát, biztonsági fájlokat, stb.) Biztosítani kell, hogy a felhasználó bármilyen PKI alkalmazásnál egyetlen fajta kulcs tároló eszközt használhasson. 
7.8.	Hardvertámogatás. 	A PKI alkalmazások biztonságos és felhasználóbarát megoldásait jelentik a különböző kriptográfiai hardver eszközök, mint az intelligens kártyák, PC kártyák, PCI kártyák, melyek a szoftveres megoldásoknál gyorsabb, nagyobb kapacitású és biztonságosabb műveletekre képesek, ugyanakkor a követelmények szerint különböző teljesítményűek. Alapvető követelmény, hogy a CA-t támogató kritikus alkalmazások a tanúsítványok aláírásához hardveres kriptográfiai modulokat használjanak, mivel a szoftveres alkalmazások ki vannak téve a beavatkozásnak és a visszaéléseknek.
7.9.	A hatóságok fizikai és hálózati védelme: 	A CA-k, RA-k és az archív adattárak jelentős bizalmi elemek, melyek kockázati tényezőjét a kiadott, kezelt tanúsítványok értéke határozza meg. Ezek fizikai elkülönítését, a működést biztosító objektum védelmét biztosítani kell úgy, hogy csak a felhatalmazott személyek férhessenek hozzá. A privát kulcsok tárolására biztonságos, nem hálózatra kapcsolt hardveregységet kell alkalmazni, ez vonatkozik a különleges óvó rendszabályokat igényelő gyökér kulcsokra is, amelyek az alapját képezik több CA összekapcsolásának és általában hosszabb élettartamúak. További követelmény a CA tanúsítvány kiadási és a kulcs aláírási folyamat szigorúan ellenőrzött és auditált végrehajtása, melyhez elengedhetetlen a megosztott kulcs, azaz több, meghatározó, hatósági kulcstulajdonos.
•	A szigorú biztonsági szabályok teljes arzenálját ugyancsak érvénybe kell léptetni, beleértve a CA-nak helyet adó objektumok (helyiség, épület és berendezések) fizikai biztonságát, a személyi biztonsági intézkedéseket (ebbe értve a CA-hoz hozzáférő személyi állomány átfogó ellenőrzését és a különleges képzést), a folyamat kontrollt, hogy kikényszerítse olyan irányelvek végrehajtását, mint az összes szenzitív funkció kettős ellenőrzése. A biztonságos objektum tipikusan 7x24 órás alapon kell üzemeljen, és katasztrófa utáni teljes helyreállítást biztosító mentésekkel kell rendelkezzen.
8.	PKI együttműködés biztosítása, szabványosítási kérdések
Az architektúra az elemek összekapcsolhatóságát azok, illetve kapcsolódó felületeik szabványos kivitelével biztosítja. A PKI azonban még nem rendelkezik mindenre kiterjedő szabványokkal. Nem mondható el, hogy az infrastruktúra a szó valódi értelmében is azt jelenti, amit elvárnánk, pedig a fejlesztés már hosszú utat megtett, kezdve az IETF 1993-ban kiadott RFC 1422-es PEM, (Privacy Enhanced Specification) előírásaival, amelyek ITU-T X.509-es alapú PKI-t határoztak már meg az Internetes környezetre. A PKI népszerűségét, széleskörű használhatóságát azonban nem a szabványok döntik el, bár kölcsönösen hatnak egymásra. A PKI és a PKI felhasználók szempontjából a kulcskérdések, melyek a szabványosítási törekvések megértését is segítik a tanúsítási hierarchiák, a tanúsítvány és kulcs menedzsment és a méretezhetőség.
Az infrastruktúra fogalma azt sugallja, hogy a különböző PKI-k összekapcsolhatók, együtt tudnak működni. Ennek legfontosabb feltétele, hogy le tudjuk képezni a hitelesítési-bizalmi viszonyt a szervezetek között (azaz ki kit és mire tanúsít), és ezt hosszú távon fenntartsuk. Manapság három tanúsítási modell versenyez, melyek között a PKI működéséről jelentős felfogásbeli, elméleti különbség van, ami végső soron nem támogatja az együttműködést. Ezt csak adminisztratív intézkedésekkel, megfelelő átjárók majdani kialakításával lehet orvosolni, ha meghatározott üzleti érdekekből különböző modellek terjednek el, amelyek együttműködését mégiscsak biztosítani kell.
Az ipar még nem érte el az együttműködés biztosításához elégséges szabványosítási szintet. A PKI együttműködést biztosító protokollok a szolgáltatási környezet függvényében a táblázatban kerültek összefoglalásra.
Környezet	Szabványok az alkalmazási területenként	
	Tanúsítványgenerálás	Tanúsítványterjesztés	Tanúsítványmenedzsment	
Szervezeti	X.509, 
PKIX RFC 2459, ETSI TS 101 862	LDAP RFC 2559	PKIX-CMP RFC 2510	
Szervezetek közötti	X.509, 
PKIX RFC 2459, ETSI TS 101 862	LDAP RFC 2559, S/MIME RFC 2312	PKIX-CMP RFC 2510, 
PKCS #7/#10	
Fogyasztói környezet	X.509 v3, nincs szabvány a visszavonás ellenőrzésre, de előkészítés alatt van	S/MIME RFC 2312	nincs szabvány a menedzsmentre, de előkészítés alatt van; lekérdezésre PKCS #7/#10	
PKIX-CMP: PKIX Cerificate Management Protocol
LDAP: Lightweight Directory Access Protocol
A biztonsági területen a szabványok nem elegendőek, sokkal inkább un.. profilokat állítanak össze, amelyek a konkrét alkalmazási irányelvek függvényében a technológiák szabványos kombinációi.
A legtöbb manapság használt tanúsítvány alapja az ITU (International Telecommunications Union) X.509 ajánlása, az ISO/IEC 9594-8 szabvány. A tanúsítvány a személyről vagy egyedről (például szerverről) tartalmaz információkat és a nyilvános kulcsát, valamint a tanúsítványt kibocsátó CA választott adatait, azonban nem PKI Internet szabvány. A PKI termékeket és szolgáltatásokat használják számos hitelesítő és jogosító alkalmazásban, valamint a WEB-en elterjedt Secure Sockets Layer (SSL), Secure/Multimedia Internet Mail Extensions (S/MIME), Secure Electronic Transactions (SET), és mind a Java mind az ActiveX kódazonosító szolgáltatások specifikálják és használják a PKI-t. A Transport Layer Security szabvány szerint (TLS, az SSL-en alapuló IETF szabvány az erős azonosításra) a WEB böngészők és szerverek titkosított kommunikációs csatornáinak felépítésére használják a nyilvános kulcsú titkosítást és a tanúsítványokat. Az IPSec az IP alapú kommunikáció beépített, csomag szintű titkosítást használó megoldása a hálózati forgalom automatikus, transzparens titkosítására. Főként a hálózati útvonal-irányítók között használják, PKI alapon. 
Egy sor meglévő és a jövőben bevezetendő szabványt érdemes figyelembe venni. Ilyenek az RSA cég Public Key Cryptography Standards (PKCS) szabványai(11), amelyek sok lényeges PKI elemet definiálnak. Az Internet Engineering Task Force (IETF) égisze alatt, a Public Key Infrastructure working group (PKIX, 1995) egy sor ajánlást (RFC-t) dolgozott ki a nyilvános kulcsú infrastruktúrák együttműködésének biztosítására(9): nevezetesen az X.509-es profilok alkalmazásáról(12), a működési protokollokról(13), a menedzselési protokollokról(14), a tanúsítvány irányelvekről és használati szabályokról(15), és elkészítették a tervezetet az időbélyegzésről is. Az ETSI (European Telecommunications Standards Institute) szintén aktív a témában 1998 óta, alapvetően az IETF-et követi. Ugyanakkor számos más, régóta bevált biztonsági megoldás (pl. Kerberos alapú azonosítás) megmarad. A GSS-API szabvány és a Simple Public Key Mechanism (a GSS API plug-in, melyet az RFC 2025 definiál) biztosítja a Kerberos és a PKI rendszerek együttműködését az egyszeri bejelentkezésre. 
9.	PKI szabványok alkalmazásonként
Elektronikus aláírások a PKI alapelemei. A CA-k a nyilvános kulcs tulajdonos jogosultságának tanúsítására aláírják a tanúsítványt. Az alkalmazások ezt követően az adott nyilvános kulcsot fogják használni. Az együttműködő aláírási technológiákhoz szükséges az RSA féle PKCS#7, mint az elektronikus aláírások alapja. A legtöbb szállító ezt alkalmazza, de az USA Szövetségi Kormány megpróbál bevezetni egy külön digitális aláírási szabványt, a DSA-t (Digital Signature Algorithm). A DSA a DSS-hez (Digital Signature Standard) kapcsolódik, amely a PKCS#7 versenytársa. Egyelőre az RSA ellenáll.
A titkosítás és a digitális aláírások elterjedése nem mondható általánosnak, de ahol vannak, ott az RSA PKCS-ek de facto szabványok, melyeket a cég menedzsel és nem adta át az Internet közösségnek, mint RFC-ket, legalábbis amíg a szabadalom védettsége fennáll. Az USA Kormány azonban megköveteli a DSA használatát a hivatalaiban.
Tanúsítvány és CRL formátumok. Alapkövetelmény a szabványos formátum, hogy a sokféle szállító különböző alkalmazásai használni tudják. Az X.509 szabványos formátumot biztosít, azonban ez nem az Internet, hanem az ITU-T szabványa. Az X.509 széles keret ad, melynek speciális részegységei támogathatják a kívánt együttműködő képességet. Az IETF PKIX munkacsoport RFC 2459-e (12), meghatározza az X.509 tanúsítványok és CLR-ek alkalmazását az Internet PKI architektúrában. Lényeges elemei a tanúsítvány profil, tanúsítvány kiterjesztési profil, CRL és CRL kiterjesztés profil, tanúsítási útvonal ellenőrzés, és az algoritmustámogatás. Ide sorolandók az ETSI TS 101 862 és TS 101 733 szabványok is.
Tanúsítvány visszaállítási protokollok. Az X.509-es tanúsítványt használó végrendszereknek szükségük van a tanúsítványra, a CRL-re és más információkra. Ezeket a CA által fenntartott adattárból tudják megszerezni. A PKIX munkacsoport a visszavonási információk on-line elérése módszert dolgozott ki, amelyhez azonban jól meghatározott kommunikációs protokoll is szükséges. Ezt tartalmazza a PKIX RFC 2559 (13). Fontosabb eleme a tanúsítvány és CRL visszaállítás. Teljesen eltérő megoldást ajánl az Online Certificate Status Protocol (RFC 2560) a szenzitív alkalmazásokhoz. 
Tanúsítvány menedzselési protokollok. A tanúsítvány és CRL visszaállításon túlmenően a PKI elemeknek kommunikálniuk kell egymással az alapvető menedzselési funkciók ellátására. Például az alkalmazások, emberek tanúsítványokat kérnek a CA-tól, valamint a CA-k egymást tanúsíthatják, amely kereszttanúsítás ugyancsak meghatározott adatcserét jelent. Ezen a területen két fontos szabványosítási törekvés ismert. Az RSA PKCS#10 a CA-tól a tanúsítvány lekérdezés alapszintaxisát biztosítja. Ugyanakkor a PKIX munkacsoport az RFC 2510-ben (14) szabványos üzenetformátum készletet határozott meg egy sor menedzsment funkció támogatására, valamint az üzenetek transzponálására a különböző protokollok között. 
10.	PKI irányelvek, szabályok
A koncepcionális kérdések lényeges szerepet játszanak egy üzemelő PKI működésében. A szervezeti PKI esetében a működési irányelvek szükségesek az eredményességhez, amelyek meghatározzák a tanúsítványok használatát, adminisztrációját és menedzsmentjét. Gyakorta ezeknek az irányelveknek kell irányítani a szervezetnél kiadott és használt, valamint a szervezeten kívülről származó tanúsítványok használatát és elfogadását. Általánosságban kétféle irányelv van a nyilvános kulcsú infrastruktúrában. Elsőként említendők a tanúsítvány irányelvek, amely a tanúsítványok használatát szabályozzák. A CA-k irányelveket határoznak meg, az általuk kiadott tanúsítványok használatára, attól függően, hogy az Interneten működő nyilvános CA-ról, vagy egy szervezet privát CA-járól van-e szó. Másodszor a CA-knak meg kell határozniuk a Certificate Practice Statement-et (CPS), a tanúsítványgyakorlat szabályát. Bár ez a két irányelv mind célját, mind kiterjedését tekintve különböző, mégis szorosan összefüggnek, és fontos szerepet töltenek be a PKI fejlődésben.
A PKIX munkacsoport az RFC 2527-ben (15) pontosan meghatározza a két irányelv közötti viszonyt, keretrendszert dolgozva ki, hogy segítse azok munkáját, akik ilyen irányelvek megírásával foglakoznak. A keretrendszer meghatározza azokat az elemeket, amelyeket a CA-nak figyelembe kell venni a tanúsítvány irányelvek, vagy a CPS megfogalmazásakor.
10.1.	Tanúsítvány irányelvek
Az X.509 definíciója szerint a tanúsítvány irányelvek "meghatározott szabályok gyűjteménye, amely a tanúsítvány alkalmazhatóságára vonatkozik egy azonos biztonsági követelményekkel jellemezhető meghatározott közösségen, és/vagy alkalmazási osztályon belül." Például a tanúsítvány irányelvek meghatározhatják, hogy az alkalmazások milyen tanúsítvány típust használhatnak egy adott ártartományba tartozó árucikkek kereskedelmében. Így a tanúsítványt használó (alkalmazás vagy személy) a tanúsítási irányelvek alapján eldöntheti elfogadhat-e egy tanúsítványt az adott célra. A tanúsítvány irányelvek a CA-k akkreditálásának alapját is jelentik. Ha például egy CA tanúsít egy másik CA-t, a tanúsító CA a tanúsítvány irányelveket használja azon irányelvek és funkciók összeállítására, amelyeken a hitelesítési viszony alapul.
Akár a tanúsítvány kibocsátója, akár a felhasználója el kell fogadjon, egy közös tanúsítvány irányelvet, ezért az X.509 az irányelvek azonosításához, az egyedi Objektum Azonosítók regisztrálására, egy módszert tartalmaz. Az X.509 a tanúsítvány formátumában meghatározza az irányelv mezőket is, amelyeket az RFC 2459 az Internet használatra is bevezet. Ezek a mezők tartalmazzák a tanúsítvány irányelv kiterjesztéseket, az irányelv leképezési kiterjesztéseket és az irányelv korlátozási kiterjesztéseket is.
10.2.	CPS, a tanúsítvány gyakorlat szabályozása
Útmutató tervezet készült a digitális aláírások jogi kérdéseinek és koncepcióinak meghatározására. Ez a tanúsítvány gyakorlat szabályozását a következők szerint határozza meg: "egy gyakorlati szabályzat, amelyet a tanúsító hatóság alkalmaz a tanúsítványok kibocsátásakor." Így a CPS általában sokkal részletezőbb, mint az irányelvek, biztosítja a CA gyakorlatának részletes ismertetését, beleszámítva a szolgáltatás kínálatot és a tanúsítványok életciklus menedzsmentjét.
Mivel a CPS kritikus CA funkciók részleteit ismerteti a tanúsítványhasználók számára (mindegy, hogy a CA tanúsítja őket, vagy azok, akik használják a tanúsítványt), a CPS-t használhatják a CA hitelességének értékelésre. Például a CA-knak nincs jogi akkreditációja, így a CPS fontos eszközzé vált a CA hitelességének megítélésére.
10.3.	Együttműködési képesség
Az RFC 2527 specifikáció meghatározza, hogy a CPS nem képezi a CA-k közötti együttműködés alapját. A szervezetek - különösen azok, amelyek nyilvános vagy szervezetek közötti CA-kat üzemeltetnek - a CPS-t használva dokumentálják gyakorlatukat. 
Másrészt a specifikáció szerint a tanúsítvány irányelvek az együttműködés alapjaiként szolgálhatnak. Például az egyetlen CPS-el rendelkező CA többféle tanúsítvány irányelvet is meghatározhat. A CA-k különböző alkalmazásokhoz, vagy különböző felhasználói közösségekhez különböző irányelveket használhatnak. Viszont többféle CA különböző CPS-ekkel ugyanazt a tanúsítási iránylevet használhatja. Így a tanúsítvány irányelveket szervezetek között is lehet alkalmazni és általánosságban is a nyilvános Internetre, ezzel a tanúsítvány irányelveket a CA-knak és alkalmazásoknak együttműködési bázisként kell elismerniük. 
Jelenleg azonban kicsi a kilátás nagy számú szabványos irányelvre. A szabványosítás nemcsak megköveteli a szállítók megegyezését a szintaxisról, de az azonosító objektum regisztrációját is, amely egyedi minden irányelv esetén. Manapság ezért is tanácsos az irányelv készítéséhez figyelembe venni az RFC 2527 specifikációit.
10.4.	Útmutatók
A PKIX munkacsoport RFC 2527 specifikációi a gyakorlat és az irányelvek követelményeinek meghatározásakor egy keretrendszerrel segítik a szervezeteket és személyeket, hogy elkészíthessék saját tanúsítvány irányelveiket és a tanúsítvány gyakorlatuk ügyrendjét, a CPS-üket. A gyakorlat és irányelvek kérdéscsoportokban sokféle témára listákat állítottak össze, amelyekre kötelező irányelveket meghatározni. A specifikáció szerint azonban a CA-knak nem kell minden definiált témát felvállalni, de meg kell fontolni egy ellenőrző lista kialakítását az irányelvek és ügyrendek meghatározásakor. A témák a következők lehetnek:
•	Az elsődleges komponensek amelyekre az irányelvek vonatkoznak (pl a CA-k).
•	A CA-hoz forduló igénylő azonosítási és jogosítási folyamatai, amelyekhez a kezdeti regisztráció, a kulcsfrissítés, (mind a rutin, mind a visszavonás utáni) és a visszavonási bejelentések; tartoznak.
•	A kulcs menedzsment és a biztonsági intézkedések. A CA-k kötelesek védeni a kulcsaikat és jelszavaikat, ideértve a kulcsgenerálást, a privát kulcsok védelmét és a kulcs menedzsment más vonatkozásait, azaz a kulcsok aktív élettartama, és a kulcsok archiválásával kapcsolatos kérdések.
•	Az úgynevezett nem technikai kontroll, amelyet a CA használ a működése biztonságossá tételére. Ez tartalmazza a fizikai kontrollt (azaz a CA rendszerek elhelyezésére szolgáló épület és helyiség típusa, milyensége), működési kontrollt (a bizalmi szerepek meghatározása a CA-k között és kötelezettségeik), és a személyi kontrollt (bele értve az alkalmazottak háttér ellenőrzését és a megbízhatósági vizsgálatokat, képzési követelményeket, munkaköri rotációt, a jogosulatlan tevékenységek szankcionálását, és a szerződéses személyzet kapcsolati követelményeit).
•	A CA-k által használt technikai biztonsági kontroll a működésük biztonságossá tételére. Ebbe tartozik a számítógépes biztonsági kontroll (azaz a hiteles rendszerek használata és a jogosultság ellenőrzés), hálózati biztonság (azaz a tűzfalak), és az életciklus biztonság kontrollja (azaz a szoftver fejlesztési környezet biztonsága és módszertana).
•	A CA-k működési követelményei, bele értve a tanúsítványigénylési irányelveket; a tanúsítvány kibocsátást; a tanúsítvány elfogadását; a tanúsítvány felfüggesztését és visszavonását; a biztonsági auditokat.
•	Általános feltételek, amelyek a jogi és általános szabályozások széles skáláját tartalmazza, azaz a szavatosság, kötelezettségek, pénzügyi felelősség, képviselet és szankcionálás.
•	Tanúsítvány és CRL profilok, amelyek meghatározzák a CA által használt tanúsítvány és CRL formátumokat. Tekintve, hogy az X.509 tanúsítvány és CRL formátumok szabványok, a CA-k saját irányelv információikba csatolhatják az általuk kibocsátott tanúsítványokon alkalmazott speciális profilokat, verziókat és kiterjesztéseket.
•	Utolsó téma az adminisztráció, amely meghatározza, hogy a CA miként tartja karban saját ügyrendjét és irányelveit, bele értve, hogy további információkért kivel kell felvenni a kapcsolatot, az irányelvek megváltoztatásának folyamatát, és a nyilvánosságra hozatal és az értesítések kezelésének folyamatát.
Végezetül a PKIX RFC 2527 az ügyrendekre és irányelvekre egy vázlatot tartalmaz, amelyet a munkacsoport ellenőrzési listaként (vagy tovább fejlesztve szabványos formátumként) javasolt a CA-knak saját tanúsítvány irányelveik és ügyrendjük elkészítéséhez. A CA-k használhatják a vázlatot a különböző tanúsítvány irányelvek összehasonlítására a kereszttanúsítások alkalmával (például az azonosság feltérképezésére), a CPS összevetésére a tanúsítvány irányelvek definícióival, annak biztosítására, hogy a CPS hűen valósítja meg az irányelvekben leírtakat, vagy akár két CPS összevetésére.
11.	Összefoglalás
Az elektronikus aláírás használatához országos és nemzetközi szinten is együttműködésre képes nyilvános kulcsú infrastruktúrákat kell kialakítani. Ehhez a biztonságos elektronikus levelezést és az elektronikus kereskedelmet támogató architektúrát kell tervezni, amely kezelni képes a gyorsan változó technológiával járó kockázatot. Az architektúra figyelembe veszi a szolgáltatási környezetet, a szolgáltatásokkal szemben támasztott követelményeket és a legjobb technológiák, a meglévő szabványok valamint a szabványosítási törekvések ismeretében, hosszabb távon is előnyös megoldást javasolhat a ma még nem eléggé érett PKI ipar termékei telepítésére. 
12.	Javasolt irodalom
(1) Gerencsér András: Architektúrák az informatikában, Jegyzet a BKÁE Vezetőképző Intézet informatikai menedzser hallgatói számára, 1999.
(2) Lewis, Jamie: Public Key Infrastructure Architecture v1, 9 Jul 1997, The Burton Group, www.tbg.com
(3) Entrust Technologies: Trusted Public-Key Infrastructures, ver. 1.2, August 2000, www.entrust.com
(4) VeriSign, Inc. Public-Key Infrastructure (PKI) –The VeriSign Difference. 1999, www.verisign.com/repository/
(5) Ford, Warwick,  and Baum, Michael S.: Secure Electronic Commerce: Building the Infrastructure for Digital Signatures and Encryption,  Prentice-Hall, 1997.
(6) "The VeriSign WorldTrust PKI Architecture," VeriSign White Paper #98-05, 1998.
(7) Microsoft  Corp.:MS Windows 2000 Public-Key Infrastructure, White Paper 
(8) Microsoft Corporation.: Windows 2000 Certificate Services, March 31, 2000
(9) PKIX Internet draft, Internet X.509 Public Key Infrastructure, ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-06.txt, November 2000. 
(10) S/MIME:RFC 2630: "Cryptographic Message Syntax," RFC 2633: "S/MIME Version 3 Message Specification," RFC 2312: "S/MIME Version 3 Certificate Handling,"
(11) RSA Laboratories: PKCS-1 "RSA Encryption" (RFC 2313), PKCS-7 "Cryptographic Message Syntax Standard",PKCS-10, "Certification Request Syntax Standard." http://www.rsasecurity.com/rsalabs/pkcs/index.html
(12) RFC 2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, January 1999, ftp://ftp.isi.edu/in-notes/rfc2459.txt Új PKIX tervezet az RFC 2459 frissítésére: Internet Public Key Infrastructure X.509 Certificate and CRL Profile, ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-04.txt, January 2001. 
(13) RFC 2559: Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2, April 1999. ftp://ftp.isi.edu/in-notes/rfc2559.txt. Új PKIX tervezet az RFC 2559 frissítésére: Internet X.509 PKI Operational Protocols - LDAPv3  ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ldap-v3-03.txt, September 2000.
 (14) RFC 2510: Internet X.509 Public Key Infrastructure Certificate Management Protocols, ftp://ftp.isi.edu/in-notes/rfc2510.txt, March 1999. Új PKIX tervezet az RFC 2510 frissítésére, RFC 2510bis-03 2001 február! 
(15) RFC 2527: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework ftp://ftp.isi.edu/in-notes/rfc2527.txt, March 1999.