A Tanúsítványok visszavonási listája azoknak a tanúsítványoknak a listája, amelyeket a hitelesítésszolgáltató visszavontként jelölt meg . A tanúsítvány-visszavonási listák (CRL-ek) annak meghatározására szolgálnak, hogy a felhasználó vagy a CA tanúsítványát visszavonták-e kulcskompromittálódás miatt. A COS fontos tulajdonsága, hogy csak a le nem járt tanúsítványokról tartalmaz információkat.
A PKI ( nyilvános kulcsú infrastruktúra ) létrehozásának története Whitfield Diffie és Martin Hellman nyilvános kulcsú titkosítással kapcsolatos eredeti munkájához nyúlik vissza , amely a nyilvános fájlok könyvtárát javasolja, amelyet a felhasználók használhatnak más felhasználók nyilvános kulcsainak megtalálására.
Confelder 1978-ban felvetette a tanúsítványok koncepcióját, felismerve ennek a megközelítésnek néhány hátrányát, köztük azt, hogy a címtár-hozzáférés letiltása megakadályozza a felhasználók biztonságos kommunikációját . A tanúsítványok elválasztják az aláírási és keresési funkciókat, lehetővé téve a hitelesítésszolgáltató számára, hogy egy nevet társítsa a kulcshoz digitális aláírással, majd az eredményül kapott tanúsítványt egy lerakatban tárolja. Mivel a tárhely replikálható és hibatűrővé tehető, a CA megközelítés kiküszöböli a címtárak tartósságával kapcsolatos számos problémát.
Néhány évvel azután, hogy Confelder publikálta disszertációját, a fejlesztők beépítették a tanúsítvány használatát az X.500 -ba, a monopolhelyzetben lévő távközlési vállalatok által üzemeltetett, megnevezett entitások globális címtárába. Az X.500 címtár egy hierarchikus adatbázis-modellt javasol, amelynek elérési útját a relatív megkülönböztető név (RDN) komponensek sorozata határozza meg, amelyek együttesen megkülönböztető nevet (DN) alkotnak. A címtárhoz való hozzáférés védelme érdekében a fejlesztők különféle hozzáférés-ellenőrzési mechanizmusokat javasoltak, az egyszerű jelszó-alapú intézkedésektől a digitális aláírások használatának viszonylag új megközelítéséig. Ez a szabvány, amelyet az X.500 tartalmaz , az X.509v1 szabvány volt . Jelenleg van egy x.509v3 verzió.
A fejlesztők az SOS koncepcióját az 1970-es években használt hitelkártya feketelistákra alapozták. A hitelkártya-társaságok időszakonként füzeteket nyomtattak a törölt kártyaszámokkal, és szétosztották a kereskedőknek, azzal az elvárással, hogy elfogadás előtt ellenőrizzék a feketelistán szereplő összes kártyát. Ugyanazok a problémák, amelyek a hitelkártyák tiltólistáját érintették, ma is érintik az SOS-t.
A hitelesítő hatóság időszakonként kiad egy listát, amelyet közzétesz az adattárban. Minden COS tartalmaz egy nextUpdate mezőt, amely jelzi a következő COS kiadásának időpontját. Minden olyan támaszkodó fél, akinek szüksége van a tanúsítvány állapotára vonatkozó információra, és még nem rendelkezik aktuális CRL-lel, megkapja az aktuális listát az áruházból. Ha az ügyfél által ellenőrzött tanúsítvány nem szerepel a listában, akkor a munka a szokásos módon folytatódik, és a kulcs érvényesített tanúsítványnak minősül. Ha a tanúsítvány megvan, akkor a kulcs érvénytelennek minősül, és nem megbízható.
A teljesítmény javítása érdekében a CRL másolatai több üzletben is eloszthatók. Minden érintett félnek szüksége van a legfrissebb listára az ellenőrzés elvégzéséhez. Miután az érintett fél megkapta a legfrissebb segélykérő üzenetet, nem kell további információkat kérnie az adattártól, amíg új segélykérést nem bocsátanak ki. Ennek eredményeként a COS érvényességi időtartama alatt (vagyis a legfrissebb) minden érintett fél legfeljebb egy kérést küld a COS tárhelyére. Ez a kérés először az aktuális SOS kiadása után történik.
Van egy delta-SOS mechanizmus is, amely az RFC 2459 -ben meghatározott opcionális mechanizmus, amely felhasználható a visszavonási információk terjesztésének javítására. A delta CRL-ek viszonylag kis méretűek, és csak azokat a változtatásokat tartalmazzák a tanúsítvány-visszavonási listákban, amelyek az abszolút lista (teljes CRL) utolsó verziójának hitelesítésszolgáltató általi összeállítása óta történtek. Mivel a delta-CRL-ek kicsik, a PKI-kliensek gyakrabban tudják letölteni őket, mint a teljes CRL-eket, így a hitelesítésszolgáltató pontosabb információkkal látja el ügyfeleit a visszavont tanúsítványokról.
Néhány probléma megnehezíti az SOS-sel való munkát. A COS bizonyos esetekben megbízhatatlan a tanúsítvány állapotának terjesztésére. A kritikus alkalmazások azonnali visszavonást – pontosabban valós idejű tanúsítványállapot-információt – igényelnek, és a CRL-ek több okból sem mindig oldják meg ezt az alapvető problémát.
Az SOS főbb problémái:
Az SOS számos más gyakorlati problémával is küzd. Az időszerű állapotfrissítések biztosítása érdekében a szervernek a lehető leggyakrabban kell SOS-t kiadnia. Az SOS kiadása azonban megnöveli a szerver és az azt továbbító hálózat, illetve kisebb mértékben az azt fogadó kliens terhelését. Például 10 millió ügyfél percenként egyszer 1 MB SOS-t tölt le = forgalom ~ 150 GB / s. Ezért ez egy költséges művelet. A SOS percenkénti egyszeri kiadása mérsékelten időszerű visszavonást biztosít hatalmas többletköltség rovására, mivel minden érintett fél új SOS-t tölt le (sok esetben ez a feladat a Delta SOS-re hárul, és a probléma megoldódik). Másrészt, ha a kibocsátást egy órára vagy egy napra halasztják, az nem biztosítja az időben történő visszavonást, feltéve, hogy bizonyos tanúsítványokat ebben az időszakban visszavontak.
A CRL-ekből hiányoznak azok a mechanizmusok is, amelyek a függő feleket a visszavonás ellenőrzéséért felszámítanák. Amikor egy tanúsító hatóság tanúsítványt állít ki, díjat számít fel a felhasználónak. A CA által felszámított összeg általában attól függ, hogy mennyit ellenőriz a tanúsítvány kiadása előtt. Másrészt a felhasználók elvárják a hitelesítésszolgáltatóktól, hogy ingyenesen hozzanak létre és adják ki a SOC-kat. Sem a felhasználó, sem a hitelesítésszolgáltató nem tudja egyértelműen megmondani, hogy ki fogja ellenőrizni a tanúsítványt, milyen gyakorisággal, milyen késleltetés fogadható el. Ez a helyzet aktív elrettentő eszközként szolgál a CA-k számára, hogy nagymértékben az SOS-re összpontosítsanak, mivel ezek létrehozásához és terjesztéséhez feldolgozási időre, egy vagy több szerverre és jelentős hálózati sávszélességre van szükségük.
Jelenleg az SOS számos analógja létezik, amelyek nem rendelkeznek az SOS hátrányaival, ugyanakkor megvannak a maguk sajátosságai.
Az egyik analóg az OCSP - Online Certificate Status Protocol . Ez a megoldás valós idejű választ ad a kiszolgálótól az adott kért tanúsítványra vonatkozóan. Ez a megközelítés számos, az SOS-ben rejlő problémát megold azáltal, hogy egyszeri, friss SOS-t hoz létre, kérésenként egyetlen bejegyzéssel. Ezzel szemben a COS-alapú modell megköveteli a támaszkodó felektől, hogy ismételten nagy mennyiségű irreleváns rekordot gyűjtsenek be, hogy állapotinformációkat szerezzenek a szükséges tanúsítványhoz. Az OCSP -nek azonban ára van. Ahelyett, hogy a COS-t háttérbeli offline műveletként készítené elő, a CA-nak mostantól tanúsítványkeresést és pszeudo-COS-generálási műveletet kell végrehajtania minden kérésnél. Az OCSP költséghatékonysága érdekében a CA-nak díjat kell felszámítania minden egyes visszavonási ellenőrzésért. Az OCSP ezt a problémát úgy oldja meg, hogy számlázási célból aláírja a feladó azonosítási kérelmeket.
Ennek a módszernek is megvannak a maga hátrányai. Az OCSP fő hátránya, hogy az érvényességi kérés egyszerű igen vagy nem válasza helyett több nem ortogonális tanúsítvány állapotértéket használ , mivel nem tud igazán pontos választ adni. Ez a kétértelműség legalább részben az eredeti COS-alapú tanúsítványállapot-mechanizmusból ered. Mivel a COS csak negatív eredményt tud adni, az a tény, hogy egy tanúsítvány nem szerepel a COS-ben, nem jelenti azt, hogy valaha is kiadták vagy még érvényes.
A feketelista alapú megközelítésekkel, mint például a COS és az OCSP, a fő probléma az, hogy rossz kérdést tesznek fel. Ahelyett, hogy azt kérdeznék: „Érvényes-e a tanúsítvány?”, azt kérdezik: „Visszavonták a tanúsítványt?”, mert ez az egyetlen kérdés, amelyre a feketelista válaszolhat.
Az OCSP egy harmadik fél (CA) számára is közzéteszi az ügyfél kapcsolati előzményeit.
OCSP tűzés OCSP tűzés . Kiküszöböli az OCSP-kérés újraküldésének szükségességét, mivel magával a tanúsítvánnyal együtt OCSP-választ ad ki. Ezt OCSP tűzésnek nevezik, mert a kiszolgálónak "tűznie" kell az OCSP választ a tanúsítvánnyal, és együtt kell kiadnia azokat. Amikor létrejön a kapcsolat, a szerver elküldi a tanúsítványláncát a kliensnek a megfelelő OCSP-válaszokkal együtt. Az OCSP válasz csak rövid ideig érvényes, és a hitelesítésszolgáltató aláírja a tanúsítványhoz hasonlóan. Ezzel az OCSP adatvédelmi problémája is megszűnik, mivel a válaszadó nem fér hozzá a weboldal látogatóinak adataihoz. Nem széles körben alkalmazzák, a szerverek mindössze 3%-a támogatja az OCSP tűzést.
A nyilvános kulcsú infrastruktúra egyik lehetséges alkalmazása a HTTPS . Sok böngésző két fő megközelítést használ: SOS és OCSP. A Mozilla Firefox nem tölti le automatikusan az SOS-t. A böngésző OCSP segítségével ellenőrzi, hogy a tanúsítványt visszavonták-e. Az Internet Explorer és az Opera sokkal alaposabb munkát végez; mindkettő támogatja az OCSP-t és a CRL-t, és minden típusú tanúsítványra megfelelő ellenőrzéseket végeznek. De ebben a tesztben az SOS-t főleg tartalékként használják.
A PKI, és különösen az SOS alkalmazásának fontos területe az elektronikus aláírás . A tanúsítvány igazolja, hogy a nyilvános és a privát kulcs a tulajdonosához tartozik. A tanúsítvány visszavonása azt jelenti, hogy a kulcsot feltörték .
Az ellenőrzési algoritmus a következő: